Bitcoin: консенсус и политика приёма транзакций
Веб-разработчик часто воспринимает отказ RPC как единый ответ «транзакция неправильная». Для Bitcoin важно различать обязательные правила допустимой истории и локальные правила приёма неподтверждённых кандидатов. В уроке построим классификацию ошибок, которая помогает объяснять состояние оплаты без ложных обещаний.
Библиотека всё ещё ожидает 30 000 сатоши. Рассмотрим несколько условных кандидатов и ответы разных узлов. Это мысленные примеры; попытки отправки и проверки mempool не выполняются.
Два уровня правил
Правила консенсуса определяют, какие блоки и транзакционные расходования узел может признать допустимыми в проверяемой истории. Примеры принципиальных ограничений — невозможность повторно потратить один выход в выбранной истории, необходимость удовлетворить условие расходования и ограничения создания средств. Нарушение таких правил не исправляется повышением комиссии.
Политика mempool определяет, какие неподтверждённые транзакции узел готов хранить и распространять при своих настройках. Она учитывает ресурсные ограничения, обычные формы расходования, ставки, зависимости и правила обработки кандидатов. Два узла могут по-разному принять операцию в свою очередь, сохраняя способность согласиться с допустимым блоком.
Для нашей модели это означает две независимые формулировки: «не подходит выбранному источнику для распространения» и «не может быть признана допустимой по обязательным правилам». В диагностике нужно показывать конкретную причину, а не заменять её общим словом «блокчейн отказал».
Примеры различий
Кандидат A пытается создать библиотеке 30 000 и сдаче 51 000 из входа 80 000. Сумма выходов превышает сумму входов. Это нарушение сохранения средств для обычной транзакции. Наличие подписи или высокая заявленная комиссия не меняет арифметику.
Кандидат B правильно распоряжается 80 000 и имеет действительную подпись, но его ставка не соответствует текущим условиям локального приёма. Узел может не сохранить его в mempool. Этот ответ требует рассмотреть комиссию и политику источника; он не равнозначен примеру A.
Кандидат C расходует выход, которого источник не знает в доступной истории и очереди. Возможны разные причины: ошибочная ссылка, отсутствие родителя, иной сетевой контекст. Приложение не должно сразу объявлять «вход выдуман», пока не классифицирует отсутствие данных. При этом неизвестность не является достаточным основанием принимать оплату.
| Наблюдение | Корректный вывод для интерфейса |
|---|---|
| Нарушение обязательного правила | Кандидат не является допустимым по этой причине |
| Отказ по политике источника | Источник не принимает кандидата в очередь |
| Недоступен источник | Свежий результат неизвестен |
| Получен идентификатор отправки | Отправляющий маршрут получил ответ, включение ещё не доказано |
Версия — часть диагностики
Политики развиваются вместе с Bitcoin Core. Старый обучающий материал может описывать прежние ограничения цепочек неподтверждённых транзакций или другую модель замены. Нельзя превращать его числовой параметр в вечное правило протокола. Для воспроизводимой лаборатории записываем версию бинарного файла и конфигурацию.
В этой серии справочник RPC закреплён на Core 31.0. Это профиль чтения документации, а не утверждение, что у каждого читателя уже установлен именно такой узел. Перед будущим выполнением читатель должен сверить собственную версию и встроенную справку. Мы сейчас не устанавливаем и не запускаем программное обеспечение.
При сохранении ошибки полезны метод, параметры без секретов, код, текст причины и сетевой контекст. Если RPC-адаптер выдаёт только HTTP 500, он теряет данные, необходимые для различения проблемы авторизации, неподдерживаемого метода и отказа транзакции. Однако подробности секретов, путей и приватных данных не должны попадать в публичный ответ страницы.
Что сайт вправе проверять
Сервер библиотеки не обязан самостоятельно повторять весь консенсус в JavaScript. Он использует собственный проверяющий узел как источник сетевого состояния и выполняет прикладные проверки назначения, суммы и политики принятия. Дублирование части правил вручную опасно, если разработчик считает эту часть полноценной альтернативой узлу.
Например, парсер транзакции способен посчитать суммы известных входов и выходов. Но если он получил стоимость входа из недоверенного поля браузера, проверка не имеет нужного основания. Узел знает предыдущие выходы из проверенного состояния. Поэтому происхождение данных важнее красивого результата функции.
Аналогично библиотека может декодировать адрес и сравнить его со скриптом. Такая проверка подтверждает назначение в её модели, но не подтверждает, что транзакция будет включена в блок. Сумма, подпись, состояние входа и принадлежность цепочке остаются отдельными условиями.
Замена без магического флага
Некоторые версии и конфигурации mempool по-разному обрабатывают замену кандидатов. Сигнализация через sequence имеет исторический смысл, но сам флаг не является глобальным запретом на конкурирующее расходование. Даже кандидат, который интерфейс называет незаменяемым, не получает гарантии неизменности всей будущей истории.
Для библиотеки достаточно сохранять наблюдения конфликтующих расходований и определять фактический выход в выбранной цепочке. Если новый кандидат уменьшил оплату до 20 000, старая запись 30 000 не должна продолжать учитываться как независимый платёж. Объекты связаны общим входом и конкурируют, хотя имеют разные идентификаторы.
При обсуждении комиссий и замены с читателем следует направлять его к возможностям собственного кошелька. Веб-сайт не запрашивает приватный ключ для «исправления» платежа. Сервис может показать состояние и точную сумму, но подготовка нового расходования принадлежит уполномоченному подписанту.
Практическая запись правила
Запишем в досье три категории: consensus_invalid, policy_rejected и observation_unknown. Это внутренние объясняющие категории, а не буквальные коды каждого RPC. Адаптер преобразует реальные ответы осторожно и сохраняет исходную причину для внутреннего анализа.
Проверка категории должна сопровождаться сохранением исходной причины. Если адаптер не знает значение нового кода, он сообщает неизвестный тип отказа внутреннему журналу и не присваивает уверенно консенсусную недопустимость. Такая осторожная обработка делает обновление источника объяснимым и сохраняет возможность дальнейшего предметного разбора.
Классификация правил рассматривается в документе политики Bitcoin Core, а методы диагностики описаны в RPC-справочнике. Теперь отказ перестаёт быть одним непрозрачным событием. Следующий урок разберёт сам механизм условий расходования — Bitcoin Script.