44 / 736RULES

Правила консенсусу

Правила, за якими кожен Full Node самостійно перевіряє транзакції та блоки, не покладаючись на майнера чи постачальника гаманця.

Правила консенсусу визначають, які транзакції та блоки може прийняти Bitcoin. Кожен Full Node — програма, що самостійно перевіряє мережу, — застосовує їх незалежно. Зокрема, перевіряє, чи не витрачаються ті самі кошти повторно, чи виконано умови витрачання, записані мовою Bitcoin Script, і чи має блок коректний Proof of Work — доказ знайденого розв’язку майнінгового завдання. Також він контролює кількість новостворених біткоїнів. Більша обчислювальна потужність не дає майнеру права обходити ці правила.

Уявіть, що хтось витрачає ті самі кошти з попереднього платежу спочатку на оплату вам, а потім — магазину. Обидві витрати не можуть належати до коректної історії. Щоб це перевірити, вузол відстежує виходи транзакцій: записи сум та умов, за яких їх можна витратити. Отримавши блок, вузол перевіряє його відповідність власним правилам, а не те, хто його рекомендував. Зокрема, перевіряє доступність виходів, які витрачаються, умови Bitcoin Script разом із потрібними підписами, Proof of Work і дозволену винагороду майнера. Порушення правила означає відхилення. Підтримка компанії чи більшість голосів в інтернеті результату не змінюють. [1]

Майнер обирає транзакції та шукає блок, а Full Node незалежно перевіряє результат. Розробники можуть запропонувати зміну й випустити програму, але сам по собі цей крок не змінює правил інших вузлів. Оператор обирає, яке програмне забезпечення запускати. Його вибір визначає, що приймає власний вузол, а не що мусять прийняти всі інші. [2] [1]

Вузол має також правила для непідтверджених транзакцій: що зберігати в Mempool, локальному наборі транзакцій, які чекають на підтвердження, і що передавати іншим вузлам. Ці локальні правила називають policy; вони можуть бути суворішими за консенсус. Відмова прийняти транзакцію до мемпулу сама по собі не означає, що вона була б нечинною в блоці. Під час перевірки блоків політика ретрансляції не застосовується. [3]

Soft Fork посилює правила: блоки, чинні за новими правилами, відповідають і старим. Проте старі вузли не перевіряють нових умов. Натомість Hard Fork може дозволити блок, який старі вузли відхилять. Механізм активації допомагає координувати зміну, але не гарантує загальної згоди й не замінює рішення операторів про вибір програми. [4]

Власний Full Node дає змогу перевіряти отримані блоки, а не покладатися на сайт оглядача блоків. Вузол може знати кілька гілок — різних продовжень спільної історії. Серед коректних гілок він обирає за chainwork: сумою роботи, зарахованої кожному блоку відповідно до складності його видобутку. Це не вимірювання фактично спожитої електроенергії і не простий підрахунок блоків. Більша робота не виправдовує порушення правил. Щоб вузли отримували однаковий результат, вони мають однаково застосовувати правила навіть у незвичних випадках. Помилка програми може призвести до того, що вони прийматимуть різні блоки. [4] [5]

Вузол може відмовитися поширювати транзакцію із замалою комісією. Але якщо майнер включить її до блоку й транзакція та блок відповідатимуть консенсусу, вузол прийме блок. Якщо ж майнер нарахує собі більше за дозволену кількість нових біткоїнів, яку називають Block Subsidy, разом із комісіями транзакцій у блоці, вузол відхилить блок навіть із правильним Proof of Work. Різниця полягає в причині відхилення, а не в репутації майнера. [3] [1]

Для повної картини прочитайте також Full Node, Soft Fork, Proof of Work, Bitcoin Core, Bitcoin Script, Mempool. На цю статтю також посилаються 21 Million, Soft Fork, Hard Fork, BIP (Bitcoin Improvement Proposal).

DOC · 001Bitcoin Core — Block validationПервинне джерело DOC · 002Bitcoin whitepaperПервинне джерело DOC · 003Bitcoin Core — Transaction Relay PolicyДокументація DOC · 004Bitcoin Developer Guide — Consensus Rule ChangesДокументація DOC · 005Bitcoin Core — Chainwork calculationПервинне джерело
Переглянуто: Спочатку джерела · Не інвестиційна порада