Bitcoin Core

Павло продає книжки за біткоїни. Клієнтка показує підтвердження на телефоні, але він хоче знати, чи справді надійшов платіж і чи є він у коректному блоці. Можна звернутися до публічного оглядача або скористатися гаманцем, підключеним до власного вузла. Bitcoin Core — програма, яка забезпечує роботу такого вузла. Тут вузол — це комп’ютер із програмою, яка самостійно перевіряє правила Bitcoin, а блок — група транзакцій, додана до спільної історії. Дані вона отримує від інших, але їхню коректність оцінює сама. Павло — умовний приклад: сенс у тому, щоб замінити просту довіру до чужого повідомлення власною перевіркою. Встановлення програми не робить його майнером, не дарує BTC і не дозволяє скасовувати чужі платежі. Код відкритий за ліцензією MIT: його можна вивчати, змінювати й поширювати відповідно до її умов. [1] [16]

Ці ролі легко сплутати, адже Bitcoin Core може виконувати обидві. Вузол перевіряє історію та нові блоки. Гаманець відстежує відповідні кошти, створює адреси й готує транзакції; якщо керує приватними ключами, може й підписувати ними. Приватний ключ — секретні дані, за допомогою яких гаманець створює цифровий підпис, що дозволяє витратити відповідні біткоїни. Сам ключ іншим вузлам не надсилають. Проте Core працює і зовсім без гаманця. Павло може платити через іншу сумісну програму, а власний вузол використовувати як джерело перевірених даних; інколи потрібне додаткове програмне забезпечення. Сам запуск Core не перенаправляє всі інші гаманці до його вузла. Орієнтири в назвах: bitcoin-qt має графічний інтерфейс, bitcoind працює у фоні, а bitcoin-cli передає програмі команди. [12] [17]

Новий вузол спочатку має наздогнати історію. Це Initial Block Download, скорочено IBD, тобто початкове завантаження блоків. Під час звичайної синхронізації він завантажує блоки й перевіряє зв’язки між ними, роботу майнерів та правила транзакцій. Так формується chainstate: власний облік ще не витрачених виходів, які називають UTXO. Вихід транзакції задає суму й умови її витрачання, наприклад необхідний підпис. Він залишається в цьому обліку, доки інша транзакція його не витратить. Це не перелік імен і банківських рахунків. Швидкість залежить від комп’ютера, диска та зв’язку, тому повільний початок не обов’язково означає несправність. Перед перевіркою поточних платежів Павло чекає завершення синхронізації.

Важливе уточнення: assumevalid за певних умов дозволяє пропускати перевірки скриптів, тобто умов витрачання, у давній частині історії; -assumevalid=0 вимикає це скорочення. Інша функція, AssumeUTXO, дозволяє почати з перевіреного знімка стану, а давнішу історію обробити у фоні. Знімок зберігає стан UTXO на момент певного блоку. Програма спершу порівнює його hash, тобто цифровий відбиток, з очікуваним значенням у своєму коді; це ще не означає завершення самостійної перевірки всієї попередньої історії. Передумови різні, тому не кожна інсталяція від самого початку виконала однаковий набір перевірок. [9] [10] [12] [17]

Після синхронізації Core й далі отримує дані від підключених вузлів, які називають peers. Прийняті непідтверджені транзакції зберігає у своєму Mempool — тимчасовій черзі очікування. Наявність у ній ще не є підтвердженням у блоці, а склад черги може відрізнятися між вузлами. Новий блок Core перевіряє. Серед коректних ланцюгів-кандидатів він обирає найбільшу накопичену роботу, а не голоси комп’ютерів чи просто кількість блоків. Тому Павло розрізняє «бачу платіж» і «платіж підтверджено». Власний вузол не гарантує негайного включення транзакції й не усуває реорганізацій, коли інша коректна гілка замінює частину історії, яку вузол відстежував. [16]

Припустімо, вузол Павла не прийняв непідтверджену транзакцію до Mempool. Це не означає, що вона ніколи не може потрапити до коректного блоку. Правила консенсусу визначають коректність блоків і витрачання коштів. Локальна relay policy додає умови приймання та передавання непідтверджених транзакцій, зокрема для захисту ресурсів від перевантаження. До транзакцій усередині отриманого блоку ця політика не застосовується так само: там вирішальними є правила консенсусу. Різні налаштування Mempool самі по собі не розділяють мережу. Це розмежування допомагає читати суперечки про Core, не сприймаючи кожну опцію як зміну грошових правил. [13]

Core зберігає дані блоків, стан вузла й, за потреби, гаманці. Pruning звільняє місце, видаляючи після обробки старі файли блоків і дані для скасування їхніх змін. Нові блоки вузол перевіряє й далі, просто вже не має всього архіву під рукою. Історичні запити чи повторний пошук давніх платежів можуть вимагати нового завантаження. Індекси прискорюють пошук; наприклад, txindex несумісний із pruning. Їх варто обирати під завдання вузла. Головна відмінність інша: публічні блоки можна завантажити знову, але втрачені приватні ключі з них не відновити. Гаманець Core потребує власної безпечної резервної копії. Коли програма працює, використовуйте функцію резервування, наприклад backupwallet, а не просто копіюйте базу даних, у яку ще записуються дані. [11] [12]

Павло починає з офіційного сайту й читає інструкції для обраного релізу. Контрольна сума SHA-256 — відбиток завантаженого файлу: вона виявляє відмінність від очікуваного. Сама по собі вона не говорить, хто опублікував цей відбиток. Тому перевіряють також цифрові підписи й належність ключів підпису. Якщо зловмисник підсунув програму та власну контрольну суму, їхній збіг не зупиняє атаку. Для глибшої перевірки проєкт використовує відтворювані збірки: незалежні люди можуть отримати однакові файли з того самого коду й порівняти результати. Guix допомагає узгодити середовище збірки. Це посилює перевірку походження програми, але не доводить відсутність помилок у коді. [8] [7]

Core має JSON-RPC — інтерфейс, через який інші програми можуть ним керувати. Він корисний для запитів про стан та інтеграції сервісів, але залежно від гаманців і прав може дозволяти також операції з коштами. Дані входу не слід віддавати нібито помічникові. Інтерфейс сам не шифрує мережевий трафік і не призначений для відкритого інтернету. Звичайний зв’язок з іншими вузлами Bitcoin — це не те саме, що відкриття цих засобів керування. Для локального доступу Core також використовує тимчасові дані у файлі .cookie. Віддалене керування потребує захищеного з’єднання й обмеженого доступу за документацією. Щоб спробувати вузол, не потрібно відкривати його адміністративний інтерфейс усьому світові. [14]

Запропонувати зміну коду може кожен. Інші учасники її читають, тестують та обговорюють; відповідальні за репозиторій maintainers можуть об’єднувати прийняті зміни. Це не дає їм дистанційного керування вузлом Павла. Оператор сам обирає програму. Але цей вибір не є бюлетенем, яким одна людина переписує правила для всіх: несумісна зміна може відокремити її вузол. Bitcoin Core — важлива реалізація правил, а не компанія, що володіє всією мережею. Читаючи оголошення, розрізняйте пропозицію, прийняття в код, випуск програми й фактичне використання. Між цими кроками може бути довгий шлях. [15]

Можна почати з вузла без власних приватних ключів. Павло перевіряє файл і підписи, чекає завершення IBD та переконується, що обраний гаманець справді бере дані з його вузла. Далі стежить за з’єднаннями, новими блоками й вільним місцем. Перед оновленням читає release notes — опис змін і можливих умов переходу; якщо користується гаманцем, перевіряє резервну копію та відновлення. У разі проблем допомагає діагностичний файл debug.log, який не варто бездумно публікувати. Pruning, індекси та RPC мають відповідати використанню, а не сліпо скопійованій інструкції. Власний вузол має бути зрозумілим інструментом перевірки. Для першої невеликої купівлі він не обов’язковий, але корисний, коли хочете розуміти, чому вважаєте свої платежі коректними. [12] [14]