Vi scias: La atendata tempo inter du Bitcoin-blokoj estas averaĝe \(10\) minutoj. Nun vi faras gravan Bitcoin-transakcion kaj atendas fervore por vidi ĉu kaj kiam ĝi aperas en la sekva bloko:
e50bfacc95975a4e7545d83d8954645f
Ĉar vi ne kontrolis kiam la antaŭa bloko estis finita, vi efektive atendas mezumon de \( \frac{t}{2} = \frac{10}{2} = 5 \) minutoj da atendotempo. Post kiam \(5\) longaj minutoj pasis, kontrolu kiam la lasta bloko efektive estis finita:
e50bfacc95975a4e7545d83d8954645f
La lasta bloko estis finita antaŭ \(7\) minutoj. Nun kiam vi konas ĉi tiun informon, la atendata tempo ŝanĝiĝas de \(5\) minutoj al \(10\) minutoj entute. Tio signifas: Ĝi verŝajne estos preta post ĉirkaŭ \(3\) minutoj. Vi eldonas la komandon denove kaj denove. Kaj atendu. Post aliaj \(10\) minutoj oni komencas senti, ke io misas.
Sed tiam vi memoras tion Atendante paradokso:
Se aŭtobusoj veturas averaĝe ĉiujn \(t\) minutojn, la atendotempo por hazarda alventempo ĉe la bushaltejo ne respondas al \(\frac{t}{2}\) minutoj, sed en la kazo de eksponente distribuitaj. distancoj \(t\) .
Bitcoin-blokaj okazoj estas Poisson-procezo kaj tial estas eksponente distribuitaj. Ĉar Poisson-procezoj estas senmemoraj, la sekva bloko ankaŭ estas kompletigita en \(10\) minutoj averaĝe. Tio ĉiam validas - negrave kiom longe ni atendis. La kvalito de senmemoreco validas kaj malantaŭen kaj antaŭen en tempo.
Kiel tio povas esti?
Por fari tion, ni konsideras la sekvajn du deklarojn:
- A) La reala averaĝa atendotempo inter du blokoj estas \(10\) minutoj, ne \(20\) minutoj.
- B) Se hazarda punkto en tempo estas elektita, ni atendas ke la antaŭa bloko \(10\) minutoj en la pasinteco kaj la sekva bloko \(10\) minutoj en la estonteco. Do ni povas atendi atendan tempon de \(20\) minutoj inter la blokoj.
Ni kontrolas ambaŭ deklarojn.
Por fari tion, ni unue ĉerpas la koncernajn datumojn, specife la tempojn kiam la blokoj estis kompletigitaj, en TXT-dosieron (efektivitan per loke funkcianta plena nodo bazita sur bitcoind ).:
e50bfacc95975a4e7545d83d8954645f
Ĉi tio donas al ni la sekvan tekstdosieron , kiun ni nun prilaboras plu kaj konservas en /time.txt . La jena Rust- programo kun la dosiero /Cargo.toml estas uzata por ĉi tiu celo:
e50bfacc95975a4e7545d83d8954645f
La dosiero /src/main.rs enhavas la realan testlogikon:
e50bfacc95975a4e7545d83d8954645f
Ni instalas la dependecojn, konstruas la programon kaj komencas ĝin:
e50bfacc95975a4e7545d83d8954645f
Efektive, ambaŭ deklaroj estas veraj kiam ni analizas la produktaĵon:
e50bfacc95975a4e7545d83d8954645f
Ĉi tio ankaŭ povas esti klarigita intuicie jene: Se la bloktempoj varias signife, la specifa atendotempo varias - se ni efektivigas la transakcion en hazarda momento en tempo, la probableco estas pli alta ke ni finiĝos en intervalo en kiu la atendotempo estas pli longa ol 10 minutoj estas ĉar ĉi tiuj intervaloj ankaŭ okupas pli da spaco sur la templinio pro la pli longa tempo.