می دانید: زمان مورد انتظار بین دو بلاک بیت کوین به طور متوسط \(10\) دقیقه است. اکنون شما در حال انجام یک تراکنش مهم بیت کوین هستید و مشتاقانه منتظر هستید که ببینید آیا و کی در بلوک بعدی ظاهر می شود یا خیر:
e50bfacc95975a4e7545d83d8954645f
از آنجایی که زمان تکمیل بلوک قبلی را بررسی نکردهاید، در واقع انتظار دارید میانگین زمان انتظار \( \frac{t}{2} = \frac{10}{2} = 5 \) دقیقه باشد. پس از سپری شدن \(5\) دقیقه طولانی، بررسی کنید که آخرین بلوک واقعاً چه زمانی کامل شده است:
e50bfacc95975a4e7545d83d8954645f
آخرین بلوک \(7\) دقیقه قبل تکمیل شد. اکنون که این اطلاعات را می دانید، زمان مورد انتظار از \(5\) دقیقه به \(10\) دقیقه در کل تغییر می کند. این بدان معناست که: احتمالاً در حدود \(3\) دقیقه آماده خواهد شد. شما دستور را بارها و بارها صادر می کنید. و صبر کن بعد از \(10\) دقیقه دیگر احساس می کنید چیزی اشتباه است.
ولی بعدش یادت میاد پارادوکس انتظار:
اگر اتوبوس ها به طور متوسط هر \(t\) دقیقه کار کنند، زمان انتظار برای یک زمان رسیدن تصادفی در ایستگاه اتوبوس با \(\frac{t}{2}\) دقیقه مطابقت ندارد، اما در مورد توزیع نمایی فواصل \(t\) .
وقوع بلاک بیت کوین یک فرآیند پواسون است و بنابراین به صورت نمایی توزیع می شود. از آنجایی که فرآیندهای پواسون بدون حافظه هستند، بلوک بعدی نیز به طور متوسط در \(10\) دقیقه تکمیل می شود. این همیشه صدق می کند - مهم نیست چقدر منتظر بوده ایم. کیفیت بی حافظه هم به عقب و هم به جلو در زمان اعمال می شود.
چطور ممکنه؟
برای این کار دو عبارت زیر را در نظر می گیریم:
- الف) میانگین زمان انتظار واقعی بین دو بلوک \(10\) دقیقه است نه \(20\) دقیقه.
- ب) اگر یک نقطه تصادفی در زمان انتخاب شود، انتظار داریم که بلوک قبلی \(10\) دقیقه در گذشته و بلوک بعدی \(10\) دقیقه در آینده باشد. بنابراین ما می توانیم انتظار زمان انتظار \(20\) دقیقه بین بلوک ها را داشته باشیم.
ما هر دو عبارت را بررسی می کنیم.
برای انجام این کار، ابتدا دادههای مربوطه را استخراج میکنیم، بهویژه زمانهایی که بلوکها تکمیل میشوند، در یک فایل TXT (با یک گره کامل در حال اجرا محلی بر اساس bitcoind اجرا شود).:
e50bfacc95975a4e7545d83d8954645f
این فایل متنی زیر را به ما می دهد که اکنون آن را بیشتر پردازش کرده و در /time.txt ذخیره می کنیم. برای این منظور از برنامه Rust زیر با فایل /Cargo.toml استفاده می شود:
e50bfacc95975a4e7545d83d8954645f
فایل /src/main.rs حاوی منطق آزمون واقعی است:
e50bfacc95975a4e7545d83d8954645f
وابستگی ها را نصب می کنیم، برنامه را می سازیم و شروع می کنیم:
e50bfacc95975a4e7545d83d8954645f
در واقع، وقتی خروجی را تجزیه و تحلیل می کنیم، هر دو عبارت درست هستند:
e50bfacc95975a4e7545d83d8954645f
این را میتوان به صورت شهودی به صورت زیر توضیح داد: اگر زمانهای بلوک بهطور قابلتوجهی متفاوت باشد، زمان انتظار خاص تغییر میکند - اگر تراکنش را در یک نقطه زمانی تصادفی انجام دهیم، احتمال اینکه در بازهای قرار بگیریم بیشتر است. زمان انتظار بیشتر از 10 دقیقه است زیرا این فواصل نیز به دلیل زمان طولانیتر، فضای بیشتری را در جدول زمانی اشغال میکنند.