115 / 736NC

Nakamoto Consensus

Як Bitcoin узгоджує історію платежів

У Bitcoin немає центрального бухгалтера. Спільна історія виникає завдяки незалежній перевірці, майнінгу та вибору дійсного ланцюга з найбільшою накопиченою роботою.

Nakamoto Consensus — це назва способу, яким Bitcoin узгоджує спільну дійсну історію транзакцій без центрального арбітра. Full Node, комп’ютер із програмою, яка перевіряє правила, спочатку відкидає недійсні блоки. Потім серед дійсних гілок обирає ту, де накопичено найбільше роботи. Нові підтвердження за певних безпекових умов підвищують упевненість у платежі, але не роблять його миттєво незворотним.

Анна платить Петру. Вона могла б підписати й іншу транзакцію, що витрачає ті самі кошти на користь Єви. Підписати тут означає за допомогою приватного ключа, секретного числового значення, створити перевірний доказ дозволу на платіж. Інші можуть перевірити підпис, не знаючи цього секрету. Обидва підписи можуть бути справжніми, проте обидва платежі не можуть увійти до однієї дійсної історії. До того ж Петро та Єва можуть отримати повідомлення в різному порядку. Отже, Bitcoin потрібна не лише перевірка підписів, а й спосіб узгодити порядок і не допустити подвійної витрати. Nakamoto Consensus поєднує правила, Proof of Work, вибір гілки та винагороди майнерам. У білій книзі Сатоші, початковому технічному описі Bitcoin, цієї пізнішої назви немає. [1] [4]

Петрів Full Node — не бюлетень для голосування. Блок об’єднує транзакції в пакет, який додають до спільної історії. Вихід транзакції — це запис суми й умов, за яких її згодом можна витратити. Програма Full Node самостійно перевіряє транзакції та блоки: чи виходи транзакцій досі невитрачені, чи виконано умови їх витрачання та чи не створюється більше біткоїнів, ніж дозволено. Майнер може запропонувати блок, але не обійти ці перевірки на власний розсуд. Недійсний блок залишається недійсним навіть із величезною роботою за ним. Гілки порівнюють лише серед дійсних варіантів; спільна історія передбачає сумісні правила учасників. [2] [3]

Якби кожен підключений комп’ютер мав голос, нападник міг би створити багато нібито незалежних учасників. Це називається Sybil Attack. Proof of Work замість підрахунку імен пов’язує вагу гілки з обчислювальною роботою, яку можна перевірити. Майнери знову й знову обчислюють хеші, цифрові відбитки даних, шукаючи результат, що відповідає заданій умові. Спроби потребують енергії й обладнання, а знайдений результат легко перевірити. Багато мережевих ідентичностей самі собою не додають роботи; це не перевірка паспортів і не голосування всіх вузлів. [1] [4]

Майнер складає блок-кандидат і змінює його заголовок, стислий опис блока, доки числове значення хешу заголовка не стане меншим або рівним допустимій цілі. Він не розв’язує корисне рівняння й не зламує шифрування, а шукає рідкісний результат. Два майнери можуть досягти успіху майже одночасно. Частина мережі спочатку побачить один блок, інша — другий, і ненадовго виникнуть дві дійсні гілки. Саме собою це не аварія. За нормального поширення блоків подальша робота дозволяє вузлам зійтися на сильнішій гілці. [1] [8]

Силу гілки вимірює chainwork: сума роботи, приписаної її блокам за їхніми цільовими значеннями. Це не лічильник електрики й не журнал фактичних спроб. Одному майнеру могло пощастити відразу, іншому довелося довго чекати; за однакової цілі їхні дійсні блоки мають однакову вагу. Full Node обирає доступну дійсну гілку з найбільшою сумою. Тому «найдовший ланцюг» означає найбільшу роботу, не обов’язково кількість блоків. Перехід на іншу гілку називають реорганізацією; платіж із відкинутого блока може потрапити до нового, якщо залишається дійсним. [1] [2] [3] [7]

Коли платіж Анни потрапляє до прийнятого блока, він має одне підтвердження. Кожен наступний блок додає ще одне. Для заміни цієї історії конкурентна гілка мала б наздогнати її роботу. За чесної більшості обчислювальної потужності та достатньо швидкого поширення блоків ризик успішного переписування зазвичай зменшується з глибиною. Це ймовірнісна остаточність: дедалі більша впевненість, а не математична неможливість зміни. Скільки підтверджень чекатиме Петро, залежить також від суми та ризику платежу. Універсального числа, безпечного за будь-яких обставин, немає. [1] [4]

Якби з появою швидших машин умова не змінювалася, блоки виникали б частіше. Тому Difficulty Adjustment в основній мережі перераховує ціль кожні 2016 блоків за попередніми часовими мітками. Мета — у середньому десять хвилин на блок, приблизно два тижні на такий відрізок. Окремий блок може з’явитися значно раніше чи пізніше. Перерахунок запускає кількість блоків, не дата в календарі: якщо раптово зникає багато потужності, наступного перерахунку доведеться чекати довше. Це не миттєвий регулятор і не точний годинник. [2] [8]

Нові біткоїни, тобто блокова субсидія, та комісії винагороджують майнерів за блоки, які залишаються в прийнятій історії. Це спонукає її продовжувати, але не замінює безпекових припущень. Більшість потужності може реорганізувати дійсні гілки, пропускати платежі й намагатися скасувати власну витрату. Вона не може змусити Full Node прийняти недійсний підпис, надмірну емісію чи витрату чужих коштів без дозволу. Поріг 50% теж не перемикач безпеки: деякі атаки мають шанси й нижче нього. Сама винагорода не створює чесності. [1] [2] [3]

Повернімося до Петра. Якщо нападник контролює всі з’єднання його вузла, він може показувати неповну картину подій. Eclipse Attack означає саме таку мережеву ізоляцію; кількість підтверджень тоді може означати не те саме, що за доброго зв’язку з рештою мережі. Розділення мережі на відокремлені частини також ускладнює згоду. Безпека залежить не лише від потужності нападника, а й від поширення повідомлень та чесної перевірки. Дослідження Bitcoin Backbone явно моделюють ці умови. Відсоток потужності без мережевих припущень не пояснює безпеку повністю. [4]

Класичні методи BFT (Byzantine Fault Tolerance) прагнуть згоди навіть за наявності несправних або зловмисних учасників і часто передбачають заздалегідь відому групу. Приклади OM (Oral Messages) та PBFT (Practical Byzantine Fault Tolerance) мають власні умови й правила обміну повідомленнями. Bitcoin забезпечує відкриту участь завдяки роботі та ймовірнісному усталенню історії; це не просто нова назва тих методів. Вибір сильнішої дійсної гілки також не змінює правил дійсності. Для зміни правил учасники мають прийняти відповідне програмне забезпечення й сумісні умови. Майнери допомагають визначити, яка дійсна історія продовжиться, а не що всі зобов’язані вважати дійсним. [5] [6] [9]

Для повної картини прочитайте також Bitcoin, Proof of Work, Difficulty Adjustment, Правила консенсусу, Майнінг, Full Node. На цю статтю також посилаються Bit Gold, Reusable Proofs of Work, Byzantine Generals Problem, Sybil Attack.

DOC · 001Satoshi Nakamoto — Bitcoin: A Peer-to-Peer Electronic Cash SystemПервинне джерело DOC · 002Bitcoin Developer Guide — Block ChainДокументація DOC · 003Bitcoin Core v29.0 — Chainstate validationДокументація DOC · 004The Bitcoin Backbone ProtocolПервинне джерело DOC · 005The Byzantine Generals ProblemПервинне джерело DOC · 006Bitcoin Optech — Soft fork activationПервинне джерело DOC · 007Bitcoin Core v29.0 — Block proof and chainworkПервинне джерело DOC · 008Bitcoin Core v29.0 — Proof of Work and retargetingПервинне джерело DOC · 009Castro & Liskov — Practical Byzantine Fault Tolerance (1999)Первинне джерело
Переглянуто: Спочатку джерела · Не інвестиційна порада