Перейти к содержанию

Mempool Bitcoin: политика приёма транзакций узлом

После отправки транзакция обычно сначала появляется в очереди ожидающих операций — mempool. Разработчик страницы оплаты может увидеть её через узел и решить, что платёж уже завершён. В уроке научимся описывать это состояние точнее и не превращать локальное наблюдение в обещание включения в блок.

Библиотека ожидает выход на 30 000 сатоши. Рассматриваем три узла с собственными очередями и одну подготовленную транзакцию PAYMENT_A. Узлы здесь представлены моделью; сетевые процессы и команды текущей работой не запускаются.

Очередь каждого узла

Mempool хранит транзакции, которые узел рассматривает как кандидатов для дальнейшего распространения и включения. Это локальное состояние. Узел A мог уже получить нашу транзакцию, узел B ещё не получил, а узел C отверг по собственной политике. В сети нет единственной общей таблицы mempool, которую сайт мог бы считать окончательным источником всех ожидающих операций.

Отсутствие транзакции в одном ответе не означает, что отправитель ничего не сделал. Он мог отправить в другой узел, получить временный сетевой сбой или подготовить транзакцию без её распространения. Для интерфейса правильнее состояние «наш источник пока не наблюдает перевод» с временем последней сверки.

Наличие в очереди тоже ограничено. Транзакция может быть вытеснена при изменении условий хранения, заменена допустимым кандидатом или исключена из-за подтверждения конфликтующего расходования. Поэтому поле «обнаружен» полезно, но не совпадает с состоянием «принят к выдаче доступа».

Допустимость и распространение

Узел проверяет обязательные сетевые правила, а также применяет политику приёма в mempool. Политика может быть строже в отношении определённых форм, комиссий и связей неподтверждённых транзакций. Она помогает ограничивать ресурсы и поддерживать обычные сценарии, но не является полным определением того, что допустимо в блоке.

Для нашего сайта это означает: ответ с отказом по политике одного узла не всегда доказывает нарушение консенсуса. В то же время транзакция, нарушающая обязательные правила, не становится допустимой оттого, что отправитель нашёл другой интерфейс отправки. Причину ошибки следует сохранять вместе с методом и версией источника.

Не будем фиксировать в учебной статье вечные значения минимальной ставки или ограничения очереди. Они зависят от версии и конфигурации. Закреплённый справочник Core 31.0 помогает понять поля ответов, однако фактический профиль вашей лаборатории должен отдельно записывать бинарную версию и настройки.

Состояния платежа

Построим небольшой маршрут наблюдения:

не наблюдается
      ↓
виден в mempool
      ↓
включён в выбранный блок
      ↓
достигнут прикладной порог подтверждений

Стрелки не гарантируют движение только вниз. Включённая транзакция может оказаться вне выбранной ветви после реорганизации. Неподтверждённая может исчезнуть. Приложение должно сохранять сведения о наблюдении и пересчитывать текущее состояние, а не добавлять необратимые флаги после каждого удачного запроса.

Сценарий A: узел видит 30 000 на адрес счёта, подтверждений нет. Показываем читателю обнаруженную сумму и ожидание блока. Сценарий B: видны только 20 000. Показываем частичную оплату, сохраняя тот же сетевой статус. Сценарий C: первоначальный кандидат исчез и появился другой, использующий тот же вход. Проверяем фактический новый выход библиотеке и связь конфликтующих наблюдений.

Такое разделение позволяет не путать две оси: сумму заказа и степень сетевого принятия. Полная сумма может быть неподтверждённой, а частичная сумма — подтверждённой многими блоками. Одна надпись «обрабатывается» часто скрывает это различие и затрудняет поддержку.

Комиссия не покупает точное время

Ставка комиссии влияет на привлекательность транзакции для включения при действующих условиях. Однако оценка не является бронированием места в конкретном блоке. Интервал между блоками случаен, конкурирующий спрос меняется, а узлы и майнеры могут применять разные стратегии.

Для библиотеки нельзя обещать «курс откроется через десять минут», выводя это из одного наблюдения mempool. Лучше сообщить правило: доступ выдаётся после выбранного числа подтверждений, текущее наблюдение обновлено в указанное время. Если транзакция долго ожидает, объяснить возможное изменение комиссии средствами кошелька отправителя, а не предоставлять сайту его ключи.

Связанные неподтверждённые транзакции дополнительно усложняют оценку. Дочерняя операция расходует выход родителя; её судьба зависит от доступности предшествующей структуры. Размер отдельной транзакции и собственная комиссия не всегда объясняют порядок выбора всего связанного набора. Конкретные правила пакетов и очередей зависят от версии Core.

Что хранит наблюдатель

Запись наблюдения включает сеть, идентификатор транзакции, время запроса, источник и результат. Для исходящего действия отдельно полезно хранить момент подготовки, результат отправки и факт дальнейшего появления. Если RPC вернул тайм-аут во время отправки, нельзя сразу создавать новую независимую оплату: прежняя могла уже распространиться.

При входящих платежах библиотека не обязана полагаться на присланный читателем txid. Наблюдающий кошелёк может обнаружить собственные выходы самостоятельно. Пользовательское сообщение остаётся удобной подсказкой для поиска, но не определяет сумму и назначение.

Проверка будущей реализации должна включать отсутствие данных, появление кандидата, его исчезновение и последующее подтверждение. Сейчас это описанные ожидаемые маршруты, а не результаты выполненного эксперимента. Их смысл — заранее отделить сетевое наблюдение от коммерческого действия.

Независимые наблюдатели

Допустим, источник A видит кандидат, а B пока нет. Не усредняем ответы до состояния «наполовину оплачен»: они описывают доступность данных, а не долю суммы. Можно сохранить оба наблюдения с их временем и ролью, затем следовать заранее выбранной политике основного источника. Если источники нужны для резервирования, досье определяет условия переключения и последующую сверку истории. Временная недоступность A не делает B автоматически полным эквивалентом его кошелькового набора. Сеть, назначения и обработанный диапазон должны совпасть. Это особенно полезно после аварии, когда новый наблюдатель ещё не закончил восстановление.

Текущие поля очереди приведены в getmempoolentry и getmempoolinfo. После урока карточка счёта может честно показать неподтверждённый перевод, не объявляя окончательную оплату. Теперь рассмотрим структуру блока, в который кандидат может быть включён.

Оглавление серии