Ви знаєте: очікуваний час між двома блоками біткойнів становить в середньому \(10\) хвилин. Тепер ви робите важливу транзакцію біткойн і з нетерпінням чекаєте, щоб побачити, чи з’явиться вона в наступному блоці та коли:
e50bfacc95975a4e7545d83d8954645f
Оскільки ви не перевірили, коли попередній блок був завершений, ви насправді очікуєте в середньому \( \frac{t}{2} = \frac{10}{2} = 5 \) хвилин часу очікування. Після закінчення \(5\) довгих хвилин перевірте, коли був фактично завершений останній блок:
e50bfacc95975a4e7545d83d8954645f
Останній блок уже завершено \(7\) хвилин тому. Тепер, коли ви знаєте цю інформацію, очікуваний час змінюється з \(5\) хвилин на загальну суму \(10\) хвилин. Це означає: приблизно через \(3\) хвилини це, ймовірно, буде поки що. Ви віддаєте команду знову і знову. І чекати. Ще через \(10\) хвилин виникає відчуття, що щось не так.
Але потім ти це згадаєш Парадокс очікування:
Якщо автобуси курсують у середньому кожні \(t\) хвилин, час очікування випадкового часу прибуття на автобусну зупинку не відповідає \(\frac{t}{2}\) хвилин, але у випадку експоненціально розподіленого відстані \(t\) .
Поява блоків біткойн є процесом Пуассона і тому розподіляється по експоненції. Оскільки процеси Пуассона не мають пам’яті, наступний блок також завершується в середньому за \(10\) хвилин. Це завжди актуально – незалежно від того, як довго ми чекали. Якість безпам’яті поширюється як назад, так і вперед у часі.
Як це може бути?
Для цього розглянемо два наступні твердження:
- A) Фактичний середній час очікування між двома блоками становить \(10\) хвилин, а не \(20\) хвилин.
- B) Якщо вибрано випадковий момент часу, ми очікуємо, що попередній блок \(10\) хвилин у минулому, а наступний блок \(10\) хвилин у майбутньому. Отже, ми можемо очікувати час очікування \(20\) хвилин між блоками.
Перевіряємо обидва твердження.
Для цього ми спочатку витягуємо відповідні дані, зокрема час, коли блоки були завершені, у файл TXT (що буде виконано з локально запущеним повним вузлом на основі bitcoind ).:
e50bfacc95975a4e7545d83d8954645f
Це дає нам наступний текстовий файл , який ми обробляємо далі та зберігаємо в /time.txt . Для цього з файлом /Cargo.toml використовується наступна програма Rust:
e50bfacc95975a4e7545d83d8954645f
Файл /src/main.rs містить фактичну логіку тесту:
e50bfacc95975a4e7545d83d8954645f
Встановлюємо залежності, збираємо програму і запускаємо її:
e50bfacc95975a4e7545d83d8954645f
Дійсно, обидва твердження є істинними, коли ми аналізуємо результат:
e50bfacc95975a4e7545d83d8954645f
Це також можна інтуїтивно пояснити наступним чином: якщо час блокування істотно змінюється, конкретний час очікування змінюється - якщо ми виконуємо транзакцію у випадковий момент часу, ймовірність того, що ми опинимся в інтервалі, в якому ми виконуємо транзакцію, вища. час очікування перевищує 10 хвилин, оскільки ці інтервали також займають більше місця на часовій шкалі через більший час.