Tudod: A várható idő két Bitcoin blokk között átlagosan \(10\) perc. Most egy fontos Bitcoin-tranzakciót hajt végre, és kíváncsian várja, hogy megjelenik-e és mikor jelenik meg a következő blokkban:
e50bfacc95975a4e7545d83d8954645f
Mivel nem ellenőrizte, hogy az előző blokk mikor fejeződött be, valójában átlagosan \( \frac{t}{2} = \frac{10}{2} = 5 \) perc várakozási időre számít. Miután \(5\) hosszú perc eltelt, ellenőrizze, hogy az utolsó blokk mikor fejeződött be:
e50bfacc95975a4e7545d83d8954645f
Az utolsó blokk már befejeződött \(7\) perce. Most, hogy ismeri ezt az információt, a várható idő \(5\) percről összesen \(10\) percre változik. Ez azt jelenti: Körülbelül \(3\) perc múlva valószínűleg eddig lesz. Újra és újra kiadja a parancsot. És várj. Újabb \(10\) perc múlva az az érzése, hogy valami nincs rendben.
De aztán eszedbe jut Várakozási paradoxon:
Ha az autóbuszok átlagosan \(t\) percenként járnak, akkor a véletlenszerű érkezési idő várakozási ideje a megállóban nem \(\frac{t}{2}\) percnek felel meg, hanem exponenciális eloszlás esetén távolságok \(t\) .
A Bitcoin blokk előfordulása Poisson-folyamat, ezért exponenciális eloszlásúak. Mivel a Poisson-folyamatok memória nélküliek, a következő blokk is átlagosan \(10\) perc alatt elkészül. Ez mindig érvényes – nem számít, mennyi ideig várunk. Az emlékezettelenség minősége időben visszafelé és előre is érvényesül.
Hogy lehetséges?
Ehhez a következő két állítást vesszük figyelembe:
- A) A tényleges átlagos várakozási idő két blokk között \(10\) perc, nem \(20\) perc.
- B) Ha véletlenszerű időpontot választunk, akkor azt várjuk, hogy az előző blokk \(10\) perc a múltban, a következő blokk \(10\) perc a jövőben. Így a blokkok között \(20\) perc várakozási időre számíthatunk.
Mindkét állítást ellenőrizzük.
Ehhez először TXT fájlba bontjuk ki a vonatkozó adatokat, konkrétan a blokkok befejezésének időpontját (a bitcoind alapú, helyileg futó teljes csomóponttal kell végrehajtani):
e50bfacc95975a4e7545d83d8954645f
Ez a következő szövegfájlt kapja , amelyet most tovább dolgozunk, és a /time.txt fájlban tárolunk . Ehhez a következő Rust programot használjuk a /Cargo.toml fájllal:
e50bfacc95975a4e7545d83d8954645f
A /src/main.rs fájl tartalmazza a tényleges tesztlogikát:
e50bfacc95975a4e7545d83d8954645f
Telepítjük a függőségeket, elkészítjük a programot és elindítjuk:
e50bfacc95975a4e7545d83d8954645f
Valójában mindkét állítás igaz, ha a kimenetet elemezzük:
e50bfacc95975a4e7545d83d8954645f
Ez intuitív módon a következőképpen is magyarázható: Ha a blokkidők jelentősen változnak, a fajlagos várakozási idő változik - ha véletlenszerű időpontban hajtjuk végre a tranzakciót, nagyobb a valószínűsége annak, hogy olyan intervallumba kerülünk, amelyben a A várakozási idő 10 percnél hosszabb, mert ezek az intervallumok a hosszabb idő miatt több helyet foglalnak el az idővonalon.