Biliyorsunuz: İki Bitcoin bloğu arasındaki beklenen süre ortalama \(10\) dakikadır. Şimdi önemli bir Bitcoin işlemi yapıyorsunuz ve bir sonraki blokta görünüp görünmediğini ve ne zaman görüneceğini merakla bekliyorsunuz.:
e50bfacc95975a4e7545d83d8954645f
Önceki bloğun ne zaman tamamlandığını kontrol etmediğiniz için, aslında ortalama \( \frac{t}{2} = \frac{10}{2} = 5 \) dakikalık bir bekleme süresi beklersiniz. \(5\) uzun dakika geçtikten sonra, son bloğun gerçekten ne zaman tamamlandığını kontrol edin:
e50bfacc95975a4e7545d83d8954645f
Son blok zaten \(7\) dakika önce tamamlandı. Artık bu bilgiyi bildiğinize göre, beklenen süre \(5\) dakikadan toplam \(10\) dakikaya değişir. Bunun anlamı: Yaklaşık \(3\) dakika içinde muhtemelen şimdiye kadar olacak. Komutu tekrar tekrar veriyorsunuz. Ve bekle. Başka bir \(10\) dakika sonra bir şeylerin yanlış olduğu hissine kapılıyorsunuz.
Ama sonra bunu hatırlıyorsun Bekleme paradoksu:
Otobüsler ortalama olarak her \(t\) dakikada bir çalışıyorsa, otobüs durağında rastgele bir varış zamanı için bekleme süresi \(\frac{t}{2}\) dakikaya karşılık gelmez, ancak üstel dağılım durumunda mesafeler \(t\) .
Bitcoin blok oluşumları bir Poisson sürecidir ve bu nedenle katlanarak dağıtılır. Poisson işlemleri hafızasız olduğu için bir sonraki blok da ortalama \(10\) dakikada tamamlanır. Bu her zaman geçerlidir - ne kadar beklersek bekleyelim. Hafızasızlığın kalitesi zamanda hem geriye hem de ileriye doğru geçerlidir.
Nasıl olabilir?
Bunu yapmak için aşağıdaki iki ifadeyi dikkate alıyoruz.:
- A) iki blok arasındaki gerçek ortalama bekleme süresi \(10\) dakika değil \(20\) dakika.
- B) Zamanda rastgele bir nokta seçilirse, önceki bloğun \(10\) dakikasını geçmişte ve sonraki bloğun \(10\) dakikasını gelecekte olmasını bekleriz. Yani bloklar arasında \(20\) dakikalık bir bekleme süresi bekleyebiliriz.
Her iki ifadeyi de kontrol ediyoruz.
Bunu yapmak için önce ilgili verileri, özellikle de blokların tamamlandığı zamanları bir TXT dosyasına ( bitcoind tabanlı yerel olarak çalışan bir tam düğümle gerçekleştirilecek ) çıkarıyoruz.:
e50bfacc95975a4e7545d83d8954645f
Bu bize, şimdi daha fazla işleyip /time.txt içinde sakladığımız aşağıdaki metin dosyasını verir . Bunun için /Cargo.toml dosyası ile aşağıdaki Rust programı kullanılmaktadır.:
e50bfacc95975a4e7545d83d8954645f
/src/main.rs dosyası gerçek test mantığını içerir:
e50bfacc95975a4e7545d83d8954645f
Bağımlılıkları kuruyoruz, programı oluşturuyoruz ve başlatıyoruz:
e50bfacc95975a4e7545d83d8954645f
Aslında, çıktıyı analiz ettiğimizde her iki ifade de doğrudur.:
e50bfacc95975a4e7545d83d8954645f
Bu aynı zamanda sezgisel olarak şu şekilde açıklanabilir: Blok süreleri önemli ölçüde değişirse, belirli bekleme süresi değişir - işlemi rastgele bir zamanda gerçekleştirirsek, işlemin bittiği bir aralığa girme olasılığımız daha yüksektir. bekleme süresi 10 dakikadan uzundur çünkü bu aralıklar da daha uzun süre nedeniyle zaman çizelgesinde daha fazla yer kaplar.