Miért választották a cél blokkidőnek 10 percet?

A wiki szerint 10 percet választottak “kompromisszumnak”.

Miért pont tíz perc? Ez egy kompromisszum, amelyet Satoshi választott az új blokkok terjedési idejének a nagy hálózatokban és a láncszakadások miatt pazarolt munka mennyisége között.

Az eredeti Satoshi cikkben azonban a lemezterületigény kiszámításához 10 percet csupán feltételezünk.

A tranzakció nélküli blokk fejléc körülbelül 80 bájt lenne. Ha feltételezzük, hogy blokkokat generálunk 10 percenként, akkor 80 bájt * 6 * 24 * 365 = 4,2 MB évente.

Van olyan beszélgetés máshol, amely elmagyarázza, hogyan érkezett a 10 perces blokkidő?

Megjegyzések

  • Úgy gondolom, hogy ha a 10 perces blokkolási követelmény valamilyen oknál fogva problémásnak bizonyul, és a legtöbb bányász & felhasználó egyetért, akkor ez a jövőben csökkenthető.
  • Mike Hearn elmagyarázta nekem egyszer, hogy Satoshi a blokk terjedési idejét 1 percre becsülte, és 10 perces blokkintervallumokat választott, mert ” pazarlás ” A bányamunka 10% -a tisztességes összeg volt. Jelenleg a blokkterjesztési idő sokkal, de sokkal gyorsabb.
  • @pinhead Mit értesz pontosan azzal, hogy a bányamunka 10% -át pazaroljuk?
  • @FivePoints ebben az összefüggésben azt értjük, hogy 10 A kitermelt blokkok% -a ” elveszíti a versenyt ” egy másik, közel azonos időben bányászott blokkkal szemben, és elavulttá válik, vagyis a bányász soha nem lesz felhasználható, és a bányász által a blokk előállításához felhasznált energia el fog pazarolni.
  • A @pinhead-nek van értelme, de hogyan számolták ki ezt a 10% -ot? Ez egyszerűen (késés / blokkidő)?

Válasz

A 10 perces blokkok egyszerűen kompromisszumot jelentenek.

Rövidebb blokkidő:

  • PRO – gyorsabb 1 megerősítési idő (hogy megvédje a 0 megerősítést igénylő kettős kiadásoktól)
  • PRO – Kevesebb kifizetési szórás a bányászok számára (kevesebb a nagy medencékre való támaszkodás)
  • CON – Megnövelt sávszélességet igényel (csomópontok közötti kommunikáció)
  • CON – Több villa, hosszabb villa és hosszabb újraszervezési idő
  • CON – A nyers haspower nagyobb része pazarolódik el, ami alacsonyabb hatékony biztonságot eredményez.

10 percnél hosszabb blokkintervallum cél esetén az előnyök és hátrányok megfordulnak.

A rövidebb idő legnagyobb előnye a blokkidő a csökkentett 1 megerősítési idő. Míg egy gyorsabb blokk “1” megerősítő tranzakciója kevésbé erős, mint egy hosszabb blokk “1” megerősítő tranzakciója, akkor is jobb, mint bármely blokk 0 megerősíti a tranzakciót.

Az első megerősítés sebessége óriási előnynek tűnhet, de a valóságban a legtöbb alacsony értékű és időérzékeny tranzakció esetében, például egy csésze kávé vásárlásakor, egy taxi fizetéséért vagy egy automatából, a kettős kiadások kockázata nagyon alacsony. Ne feledje, hogy a hitelkártyák elfogadása nem kockázat nélküli, azonban a kereskedők már régóta elfogadják, hogy némi veszteséggel kell szembenézniük, azonban ha ezek a veszteségek minimálisak, akkor ez csak üzleti tevékenység költségének tekinthető. Ennyi kereskedő egyszerűen elfogadhat 0 megerősítést igénylő tranzakciókat anélkül, hogy nagyobb kockázatot jelentene magának, mint a hitelkártya-csalások miatt.

A másik tényező, amely csökkenti a rövidebb célblokk-intervallumok valós lehetőségeit, sok kereskedő számára , még a “gyorsabb” megerősítési idők még mindig nem elég gyorsak. Egy értékesítési pont tranzakció esetében az átlagos 2 perces visszaigazolási idő még mindig lényegesen hosszabb, mint amit a legtöbb kereskedő működőképesnek tartana. Az átlagos hitelkártya-tranzakció körülbelül 20 percet vesz igénybe. másodperc (beleértve az ügyfelek késéseit is). Az egész iparág jelentős forrásokat költött néhány másodpercnyi borotválkozásra. Mindazok a változások, amelyek lehetővé teszik az ügyfelek számára a kártya ellopását, az ujjhúzást, mielőtt az összes elem fel van dobva, és nem igényelnek alacsony értékű aláírást borotváljon el néhány másodpercet a már gyors folyamattól, és ezeknek a változtatásoknak a költségeit elfogadhatónak tartják a fizetés hatékonyságának enyhe javítása érdekében.

A másik tényező i s hogy a célintervallum csökkentése csak csökkenti az átlagos megerősítési időt, de felük hosszabb lesz, és a farok nagyon hosszú lehet. A blokkok véletlenszerű jellege miatt a blokkok kb. 15% -a hosszabb lesz, mint a cél kétszerese, 3% -a hosszabb, mint a cél háromszorosa, és> 7,5 perc, és kb. 0.5% -a hosszabb, mint a cél négyszerese. Ez a bizonytalanság megnehezíti az időérzékeny vállalkozások számára, hogy politikailag megvárják a megerősítéseket. Miután a legtöbb tranzakció 30 másodperc alatt megerősítést nyert, de néhány percig tart, az ügyfelek csalódottságához vezetnek az értékesítés helyén.

Ha a BTC gazdasága elég nagyra nő, akkor a „zöld címek” kiterjesztett használatát tapasztalhatjuk, hogy megerősítés nélkül kielégítsük az azonnali elfogadás szükségességét. Ilyen szolgáltatásokat nagyvállalatok nyújthatnak, és csalás elleni biztosítással fedezhetik őket (tranzakciónként kicsi összegért). Ez egy életképesebb 0-megerősítő megoldás lenne, mint a blokkintervallum egyszerű csökkentése.

Ennek ellenére a 10 perces cél valószínűleg túl konzervatív volt, és vannak előnyei a rövidebb blokkidőnek.

Megjegyzések

  • A hibád az, hogy szerinted ” kettős kiadási támadás ” jelentése: ” 51% -os támadás “. Megpróbálhatja megduplázni kevesebbel, de ‘ nem garantálja a sikert. Minél több blokk várt, annál kisebb az esélye. Az > 50% az a pont, ahol ‘ garantálja az esetleges sikert, függetlenül attól, hogy hány blokkot várnak. Az 50% -os < 50% -os támadás esetén a siker valószínűsége a blokkok számától és nem az időtől függ. Ez a rövidebb blokkok előnye.
  • A rövidebb blokkidőnek még kevesebb előnye van a bányászok számára. Ezenkívül a rövid blokkok extra tárhelye elhanyagolható, mivel az adatok zöme a tranzakciók, nem pedig a blokkok fejlécei.
  • Van néhány elírási hiba: A ” Hosszabb blokkidő ” legyen ” CON ” és ” PRO ” helyett ” PRO ” és ” RRO “.
  • @MeniRosenfeld Köszönöm a javításokat, és szórási különbségeket adtam hozzá, és eltávolítottam a tárolási különbségeket korrekt vagy, a különbségek meglehetősen kicsiek lesznek. Az időalapú szempontot is eltávolítottam, mert bár hallottam, hogy további megerősítésekre van szükségem, nem rendelkezem végleges ismeretekkel.

Elég sok más ismert különbség van.

  • Nagyon szép frissítés, bárcsak újra fel tudnám szavazni. 😉
  • Válasz

    A wiki egy részét is frusztrálónak találtam, és csak szerkesztettem. Nagyra értékelem a javításokat. Íme, amit írtam:

    Satoshi kifejezetten tíz percet választott kompromisszumként az első megerősítési idő és a a láncszakadások miatt pazarolt munka. Miután blokkot bányásztak, időbe telik, mire a többi bányász megtudja, és addig valójában az új blokk ellen versenyeznek, ahelyett, hogy hozzáadnák. Ha valaki egy másik új blokkot bányász ki a régi blokklánc alapján, akkor a hálózat csak a kettő egyikét tudja elfogadni, és az összes munka, amely a másik blokkba került, kárba veszik. Például, ha a bányászok átlagosan 1 percet vesznek igénybe az új blokkok megismeréséhez, és 10 percenként jönnek az új blokkok, akkor a teljes hálózat a munkájának körülbelül 10% -át pazarolja. A blokkok közötti idő meghosszabbítása csökkenti ezt a pazarlást.

    Gondolatkísérletként mi lenne, ha a Bitcoin hálózat a Marsot is kiterjesztené? Pályájuk legtávolabbi pontjaitól körülbelül 20 percet vesz igénybe, amíg a jel a Földről a Marsra halad. Mivel az új blokkok között csak 10 perc áll rendelkezésre, a Mars bányászai mindig 2 háztömbnyire maradnának a Föld bányászai mögött. Szinte lehetetlen lenne hozzájárulniuk a blokklánchoz. Ha együtt akarunk működni az ilyen típusú késésekkel, akkor legalább néhány órára van szükségünk az új blokkok között.

    Megjegyzések

    Válasz

    Mivel a bitcoinok az első kriptovaluta, amely blokkgenerálást és így tovább használ, feltételezhetjük, hogy 10 perc önkényesen választott. Jó lenne minden olyan érték, amely elég nagy ahhoz, hogy az új blokkot a hálózaton keresztül terjessze, mielőtt egy másik bányász valószínűleg új blokkot generálna. A másik végén a blokkoknak nem szabad túl szűknek lenniük, mivel túl sok időbe telik a megerősítések megszerzése. Egy órányi számítást biztonságosnak tartanak a beavatkozástól, így az idő elegáns részekre bontása 10 percet adhat.

    Valószínűleg nincs elérhető vita erről a témáról, mivel az első Bitcoin verziót egyedül Satoshi készítette, így amíg nem fedi fel valódi kilétét vagy visszatér a közösséghez, a pontos okokat nem lehet biztosan kitalálni.

    Megjegyzések

    • Az elemzés a Satoshi-ban ‘ papír egyáltalán nem ‘ t kapcsolódik a várakozási időhöz – ez kizárólag a magas hashrate hosszú ideig történő fenntartásának gyakorlatiasságától függ idő.Megbeszélte a várakozásra kerülő blokkok mennyiségét – például megmutatta, hogy ha a címzett 6 blokkot vár, és a támadó a hálózat hashate-jének 10% -ával rendelkezik, akkor ez kettős a kiadási kísérletnek csak < 0,025% esélye van a sikerre. Blokkonként 1 perc alatt ez 6 perc stb.

    Válasz

    AFAICS, az egyetlen lehetséges előny a hosszabb blokkidő a sávszélesség rezsicsökkenését okozza a blokklánc-szétválás kisebb valószínűsége miatt.

    Még kétlem is, hogy ez a kompromisszum, mert ha a tranzakciós adatok a legnagyobbak, akkor az ellensúlyozó hatás rövidebb blokk idők kevesebb adatot továbbítanak.

    Nagyon szkeptikus vagyok abban, hogy több munkát kell pazarolni rövidebb blokkidővel, ha a nehézséget kalibrálják wrt a konszenzus elérésének ideje. Matematikailag a bányászok az újonnan létrehozott blokkok százalékos arányát keresik, nagyjából a rendszer hash-teljesítményének százalékos arányában, függetlenül attól, hogy a munkájuk nehézségei és a (véletlenszerű) árva láncok között mekkora a szerencséjük aránya.

    van egy bizonyíték, kétlem az állítást, miszerint a rövidebb blokkidők hosszabb időket hoznak létre a konszenzus eléréséhez (azaz az újraszervezési felosztásokhoz), mert például ha négyszer több osztás van a blokkidő 1/4 részével, akkor nagyjából 7 több közelítő megérkezni egyetértés az azonos időtartamú.

    Mivel visszafordíthatatlansága függvénye blokkok száma mdash; ̶ nem idő- és a hátránya késések tranzakciók, ̶ úgy tűnik, egy rövidebb blokk idő ̶c̶o̶m̶p̶e̶l̶l̶i̶n̶g̶.̶

    Örülnék, ha downvoters lenne legalább próbálja meg d erõsítsék logikájukat a válaszom alatti megjegyzéssel. Ez lehetőséget ad arra, hogy megvitassam őket, és megmutassam nekik, miért gondolom, hogy tévednek (vagy beismerem a hibámat). A lényeg az, hogy megbizonyosodjunk arról, hogy együttesen van-e megfelelő logikánk.

    Megjegyzések

    • Ez a válasz figyelmen kívül hagyja a blokkátvitel és a blokkellenőrzés költségeit. . Mivel ez az idő nagyjából fix összeg egy teljes blokknál, ez egy rövidebb blokkintervallum nagyobb relatív része, mint egy hosszabb blokkintervallum.
    • @Murch, ezt a választ néhány nappal vagy héttel később írtam. a blokkláncok, a kriptográfia és a Bitcoin tanulmányozásának kezdeményezése. Nézeteim ezért jelentősen megváltoztak. Ha feltételezzük, hogy a blokkonkénti tranzakció volumene magasabb blokkfrekvencia mellett csökken, akkor az állítás, hogy az állandó terjedési & ellenőrzési idő nem megfelelő. Craig Wright azt állította, hogy a Bitcoin hálózat nagyjából egy másodperc alatt terjed a hashrate 99% -ára .
    • Mivel gyakorlatilag az összes bányász csatlakozik a Fiberhez, és a közzétett adatok azt sugallják, hogy ‘ csak kissé lassabb, mint a fénysebesség, < 1 másodperc nem nehéz azt állítani … Az idei év legjelentősebb hatása azonban valószínűleg hogy a bányászok a Bitcoin Core legújabb verziójára frissítettek, hogy jelezzék a segwit aktiválását. Az év elején még mindig több árva blokkot láthattunk hetente. Blokkidő pl. 60 másodperc visszavett volna minket naponta több árva blokkba. Mivel az adatokat meg kell nézni, ‘ zavarba ejtő, hogy látszólag tagadja a hatást.
    • @Murch, a SegWit csökkentette-e az átlagos blokkméretet 10-es tényező? Ha nem, akkor feltehetően az általad hivatkozott adatok nem foglalkoznak a véleményemmel. Most már értem (nem mintha 2016-ban tettem volna, amikor ezt a választ írtam), hogy a rövidebb blokkidők aszimmetrikus előnyöket is jelentenek a hashrát koalíciók, például olyan poolok számára, amelyek azonnal látják nyerő blokkjaikat (nincs terjesztési késedelem). Tehát a túlzott árvák önző bányászatok lehetnek. Ne feledje, hogy az Ethereum GHOST-változata ennek részleges megoldása.

    Vélemény, hozzászólás?

    Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük