Біткойн безпекова вразливість: атака на спотворення часу

Нещодавно розробник Біткойну Антуан Пуансо запропонував м'яке хард-форк рішення під назвою "Велике очищення консенсусу". Ця пропозиція має на меті виправити кілька вразливостей та слабкостей, які тривалий час існують у протоколі Біткойну, зокрема, проблему повторних транзакцій, яку ми нещодавно обговорювали, а також більш серйозну вразливість "атака на спотворення часу", яку ми розглянемо в цій статті.

Механізм захисту часових позначок блоків Біткойн

Перед обговоренням атак на спотворення часу, нам потрібно зрозуміти поточні правила захисту від маніпуляцій з часом:

1. Медіана минулого часу (MPT) правило: Часова мітка блоку повинна бути пізніше, ніж медіана часу для попередніх 11 блоків.

2. Правила часу блоків у майбутньому: Часова мітка блоку не повинна перевищувати 2 години від медіанної часу серед рівноправних вузлів. Максимально допустима різниця між часом вузла та локальним системним годинником становить 90 хвилин.

Правила MPT запобігають тому, щоб часові мітки блоків були занадто далекими від минулого, тоді як правила майбутніх блоків обмежують часові мітки, щоб вони не заходили занадто далеко в майбутнє. Варто зазначити, що неможливо впровадити механізм, подібний до правил майбутніх блоків, для запобігання часовим міткам минулого, оскільки це може вплинути на початкову синхронізацію блокчейну. Атака на часову спотворення якраз і використовує можливість підробки давніх часових міток.

Помилка "на один" Сатоші Накамото

Складність налаштування Біткойна складає 2016 блоків, що приблизно дорівнює двом тижням, враховуючи цільовий час видобутку блоку в 10 хвилин. Під час розрахунку налаштування складності видобутку протокол розраховує різницю між часовими мітками першого та останнього блоку в 2016-блоковому вікні. Це 2016-блокове вікно фактично містить 2015 інтервалів блоків (тобто 2016 мінус 1). Таким чином, правильний цільовий час має становити 60 секунд × 10 хвилин × 2015 інтервалів = 1,209,000 секунд. Однак протокол Біткойна використовує число 2016 для розрахунку цілі: 60 секунд × 10 хвилин × 2016 = 1,209,600 секунд. Це типовий випадок помилки на одиницю, можливо, Сатоші Накамото переплутав концепцію блоку та інтервалу між блоками.

Ця помилка призвела до того, що цільовий час перевищив належний на 0,05%. Насправді, цільовий інтервал часу для Біткойн не 10 хвилин, а 10 хвилин і 0,3 секунди. Хоча ця помилка здається незначною, з моменту запуску Біткойн середній інтервал між блоками завжди становив 9 хвилин 36 секунд, що явно менше 10 хвилин. Це в основному пов'язано з тим, що з 2009 року середня обчислювальна потужність постійно зростала. Це також пояснює, чому нещодавнє зменшення винагороди за блок відбулося в квітні 2024 року, а не в січні 2025 року. Ми насправді випередили графік. В довгостроковій перспективі, коли ціна та обчислювальна потужність стабілізуються, ця похибка в 0,3 секунди може допомогти нам повернутися до запланованого графіка.

Атака спотворення часу

Атака на спотворення часу була вперше виявлена приблизно в 2011 році, вона використовує помилку Сатоші у розрахунках складності. Припустимо, що видобуток повністю централізований, майнери можуть встановлювати будь-які часові мітки в межах, дозволених протоколом. Зловмисник встановлює часові мітки більшості блоків на одну секунду раніше, ніж у попередньому блоці, щоб якомога повільніше просувати час блокчейну, дотримуючись правил MTP. Щоб максимально сповільнити просування часу, майнери можуть підтримувати однакову часову мітку протягом шести блоків, а потім у сьомому блоці збільшити час на одну секунду, і так повторювати.

Ця атака призведе до того, що час блокчейну буде все більше відставати від реального часу, а складність постійно зростатиме, ускладнюючи видобуток. Однак, щоб посилити ефект атаки, в останньому блоці кожного періоду коригування складності, майнери встановлять мітку часу на реальний світовий час. Потім мітка часу першого блоку нового періоду коригування складності буде встановлена назад у минуле, всього на секунду раніше, ніж передостанній блок попереднього періоду. Ця операція все ще відповідає правилам MTP, оскільки окремі аномалії не вплинуть на медіану 11 блоків.

Після реалізації цієї атаки, перший цикл складності не зазнає змін. Але з другого циклу коригування складність почне знижуватися. У цей момент майнери можуть створювати блоки з надшвидкою швидкістю, можливо, за короткий час створюючи велику кількість Біткойн, що призведе до отримання неправомірної вигоди.

Розробка можливостей атаки та виклики

Хоча теоретично така атака є руйнівною, на практиці її реалізація стикається з багатьма викликами:

1. Можливо, потрібно контролювати більшість обчислювальної потужності.
2. Існування чесних майнерів ускладнить атаки.
3. Правила MTP і часові мітки чесних майнерів обмежують ступінь зворотного виклику зловмисних часових міток.
4. Якщо чесний майнер згенерує перший блок будь-якого вікна корекції складності, атака цього циклу стане неефективною.
5. Процес атаки є видимим для всіх, що може дати спільноті достатньо часу для впровадження термінового м'якого хард-форку.

Рішення

Існує кілька можливих способів виправити цю вразливість:

1. Змінити алгоритм корекції складності, обчислити часовий проміжок між блоками в різних вікнах 2016 року та повністю виправити помилку "недостатньо один". Проте це може вимагати жорсткого хардфорку.

2. Скасувати правила MTP, вимагати, щоб час завжди рухався вперед у кожному блоці. Але це може призвести до того, що час застрягне в далекому майбутньому та створить проблеми для майнерів, які використовують системний годинник.

3. Простішим рішенням є вимога до часу першого блоку нового періоду складності не бути раніше ніж за певну кількість хвилин до останнього блоку попереднього періоду. У пропозиції великого консенсусу Пуансо цей час встановлено на 2 години.

Це 2-годинне обмеження має такі переваги:

• Максимально знизити ризик випадкових недійсних блоків
• відповідати правилам часових позначок блокчейну майбутнього
• У порівнянні з поточними правилами, це більш консервативна зміна
• 0.6% корекція досить мала

Хоча це все ще дозволяє зловмисникам маніпулювати складністю приблизно на 0,6% за кожен цикл, це буде лише одноразова зміна, яку не можна накопичувати. Загалом, це рішення досягло хорошого балансу між захистом безпеки мережі та підтримкою стабільності системи.