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]