Що таке блокчейн Bitcoin на рівні даних
У найпростішій моделі блокчейн — це ланцюг блоків. Кожен блок має заголовок і набір транзакцій; у заголовку записано хеш попереднього блока. Якщо змінити старий блок, зміниться його хеш, і посилання в наступному блоці більше не збігатиметься.
Це не означає, що дані фізично лежать в одному файлі на одному сервері. Копії ланцюга зберігають тисячі вузлів, які можуть завантажувати, перевіряти й відхиляти блоки за однаковими правилами. Консенсус — це не голосування за красиву історію, а відтворення правил перевірки та вибір ланцюга з найбільшою сукупною Proof of Work.
- блок має header і транзакції
- кожен header містить hash попереднього блока
- вузол може перевірити ланцюг локально
- ланцюг із найбільшою сукупною роботою має пріоритет
Анатомія заголовка блока
Заголовок Bitcoin-блока має фіксований набір полів: version, previous block hash, Merkle root, time, nBits і nonce. Разом вони утворюють 80 байтів, які майнер подає на double-SHA-256. Після зміни будь-якого поля змінюється результат хешування.
nBits — компактний запис target, а nonce — лише один із параметрів пошуку. Тому майнер не обмежений чотирма мільярдами варіантів nonce: коли діапазон вичерпано, змінюють coinbase і Merkle root, оновлюють час або отримують новий job від пулу.
- version — версія й сигнали правил
- previous hash — зв’язок із попереднім блоком
- Merkle root — компактний відбиток транзакцій
- nBits і nonce — параметри Proof of Work
Merkle tree: як тисячі транзакцій стискаються в один root
Щоб не записувати в заголовок усі транзакції, Bitcoin спочатку хешує кожну транзакцію, а потім попарно хешує сусідні значення, поки не залишиться один Merkle root. Якщо кількість елементів на рівні непарна, останній хеш дублюється для побудови наступного рівня.
Перевага Merkle tree — у короткому доказі включення. Користувачу не потрібно передавати весь блок, щоб перевірити, що транзакція входить до набору: достатньо транзакції, шляху сусідніх хешів і root. Це одна з причин, чому спрощені клієнти можуть працювати з меншим обсягом даних, хоча мають інші припущення довіри.
- листки дерева — txid транзакцій
- внутрішні вузли — хеші пар
- root входить до block header
- Merkle proof доводить включення без повного списку
Транзакції, inputs, outputs і UTXO
Транзакція не каже «баланс адреси став таким». Вона витрачає попередні outputs і створює нові. Вхід містить посилання на попередній txid та індекс output, а також scriptSig або witness-дані, потрібні для перевірки умови витрати. Вихід задає суму й scriptPubKey.
UTXO існує доти, доки інша прийнята транзакція не витратить його. Набір UTXO — це стан, із яким вузол порівнює нову транзакцію. Саме тому подвійна витрата виявляється як спроба послатися на вже використаний output, а не як конфлікт двох чисел балансу.
- UTXO — стан невитрачених виходів
- input посилається на попередній output
- output створює нову умову витрати
- комісія — різниця між сумою inputs та outputs
Шлях транзакції: від гаманця до mempool
Після підпису транзакція передається через peer-to-peer мережу. Кожен вузол може мати власний mempool, тому немає єдиної глобальної черги. Вузол перевіряє формат, скрипти, підписи, доступність UTXO, fee policy і відсутність конфлікту з уже прийнятими транзакціями.
Транзакція може бути видима в одному експлорері, але ще не потрапити до блока. Майнери будують власний candidate block і вибирають транзакції за локальною політикою, зазвичай віддаючи перевагу більшому fee rate. Якщо попит зростає, low-fee транзакції можуть залишатися в mempool довше.
- mempool локальний для кожного вузла
- прийняття в mempool ще не є підтвердженням
- майнер сам формує candidate block
- fee rate вимірює ціну block space
Як Proof of Work вибирає одну гілку
Якщо два майнери майже одночасно знаходять блоки на одній висоті, частина вузлів спочатку бачить одну гілку, а частина — іншу. Коли з’являється наступний блок, мережа отримує ланцюг із більшою сукупною роботою. Коротша гілка стає stale або orphaned, а її транзакції можуть повернутися до mempool, якщо ще дійсні.
Термін «найдовший ланцюг» часто спрощує правило. Важлива не кількість блоків сама по собі, а найбільша сукупна Proof of Work. Через це confirmations не перетворюють транзакцію на незмінну миттєво, а лише зменшують імовірність практичного reorg.
- короткі forks — нормальна властивість розподіленої мережі
- stale block не обов’язково означає шахрайство
- консенсус орієнтується на сукупну роботу
- глибина блока — практичний показник ризику reorg
Підтвердження, finality і double-spend
Перше підтвердження з’являється, коли транзакція входить до прийнятого блока. Друге — коли поверх нього додається наступний блок, і так далі. Для невеликих платежів інколи достатньо одного підтвердження за політикою сервісу, а для великих сум користувачі чекають більше.
Bitcoin має probabilistic finality. Навіть глибокий блок теоретично може бути переписаний, але для цього потрібно наздогнати чесний ланцюг за сукупною роботою. Окремо існують replace-by-fee та конфліктні непідтверджені транзакції: до включення в блок статус платежу не варто плутати з остаточним розрахунком.
- 0 confirmations — транзакція лише в mempool або ще не побачена
- 1 confirmation — транзакція в прийнятому блоці
- наступні блоки збільшують економічну ціну reorg
- finality у Bitcoin імовірнісна, а не миттєва
SPV, pruning і різні способи зберігати історію
Повний вузол може зберігати весь блокчейн і перевіряти кожен блок від genesis. Pruned node після перевірки видаляє старі повні дані блоків, залишаючи стан і потрібні метадані. SPV-клієнт працює з block headers і Merkle proofs, покладаючись на мережеві джерела для частини інформації.
Ці режими не рівнозначні за рівнем самостійної перевірки. Експлорер може мати індекси, API та власну політику, зручну для пошуку, але користувачеві варто знати, чи він бачить дані власного вузла, чужого API або біржової бази.
- full node перевіряє повну історію
- pruned node економить диск після перевірки
- SPV перевіряє заголовки та Merkle proofs
- експлорер — інтерфейс до даних, а не сам консенсус
Що означає атака на блокчейн на практиці
Зміна старого блока змінює його хеш, ламає посилання наступного блока й вимагає повторити Proof of Work для всієї переписаної гілки. Атакувальнику також потрібно наздогнати або випередити чесний ланцюг. Вартість залежить від хешрейту, часу, доступної електроенергії та того, наскільки глибоко розташований блок.
Атака 51% може дозволити цензурувати транзакції або організовувати подвійні витрати власних коштів, але не дає приватних ключів і не змушує вузли приймати неправильні підписи чи надлишкову емісію. Вузли й Proof of Work захищають різні межі системи.
- хеш попереднього блока створює зв’язок
- Proof of Work робить переписування дорогим
- вузли відхиляють порушення правил транзакцій
- безпека не дорівнює гарантії ціни або безпеки біржі
Як читати блок у блок-експлорері
Починай із висоти, hash, timestamp, previous hash, Merkle root, difficulty, nonce і розміру блока. Потім дивись на кількість транзакцій, total fees, coinbase, вагу та confirmations. В окремій транзакції перевіряй inputs, outputs, script/witness, fee rate і блок включення.
Для майнера корисно додати економічний контекст: винагороду блока, поточний хешрейт, difficulty, розподіл пулів і доступний block space. [SHA-256 у Bitcoin](sha-256-u-bitcoin) пояснює, як заголовок потрапляє в Proof of Work, а [пули](oglyad-mayning-puliv) — як індивідуальна робота перетворюється на виплату.
- порівнюй previous hash і висоту
- відділяй block subsidy від fees
- дивись на confirmations, а не лише на час
- не приймай біржовий баланс за UTXO без виведення
Блок Bitcoin як конструкція з двох частин
Header забезпечує зв’язок і Proof of Work, а body містить транзакції.
Від UTXO до підтвердження
Статус коштів змінюється не через баланс-таблицю, а через послідовність витрат і нових виходів.
Логіка підтверджень
Кожен новий блок додає роботу поверх попереднього, але не створює абсолютної миттєвої фінальності.
| Елемент | Роль у блокчейні | Що перевіряє вузол |
|---|---|---|
| Previous block hash | З’єднує блок із попереднім | Чи збігається посилання і відомий попередник |
| Merkle root | Представляє всі транзакції | Чи відповідає root фактичному списку txid |
| nBits / target | Визначає поріг Proof of Work | Чи достатньо малий double-SHA-256 |
| Coinbase | Створює дозволену винагороду й може містити extraNonce | Чи не перевищує subsidy + fees |
| UTXO set | Поточний стан витратних виходів | Чи inputs існують і не витрачені |
| Mempool | Локальний набір непідтверджених tx | Формат, підписи, policy та конфлікти |
| Confirmation | Глибина транзакції в ланцюзі | Наскільки багато роботи додано поверх |
Реальні фото та джерела
Ці фотографії та схеми взяті з відкритих публічних архівів. Відкрий посилання на джерело, щоб перевірити автора й ліцензію.
Хочеш одразу перевірити цифри для свого ASIC?
Відкрити калькулятор →
