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 jam estis finita antaŭ \(7\) minutoj. Nun kiam vi konas ĉi tiun informon, la atendata tempo ŝanĝiĝas de \(5\) minutoj al totalo de \(10\) minutoj. Tio signifas: Post ĉirkaŭ \(3\) minutoj verŝajne estos ĝis nun. Vi eldonas la komandon denove kaj denove. Kaj atendu. Post aliaj \(10\) minutoj vi havas la senton, ke io estas malĝusta.
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 ( farota 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 sekva Rust- programo estas uzata por tio kun la dosiero /Cargo.toml:
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.