Все, что вам нужно знать о пуле транзакций

Как вы, наверное, знаете, прежде чем транзакция попадает к майнерам, узлы ретранслируют ее друг другу, пока она не распространится по сети. Транзакции, которые еще не были обработаны и подтверждены майнерами, хранятся в памяти узлов в пуле (mempool). Просмотрев пул транзакций, узел может решить, следует ли ему ретранслировать новую полученную транзакцию.

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

Как транзакции попадают в пул

Прежде чем поместить транзакцию в свой пул, узел должен выполнить следующие действия.

1. Проверить правильность синтаксиса транзакции.
2. Убедиться, что списки входов и выходов транзакции не пусты.
3. Убедиться, что размер транзакции в байтах меньше, чем максимальный размер блока.
4. Убедиться, что все выходы и их сумма являются допустимыми денежными значениями.
5. Убедиться, что транзакция не является coinbase-транзакцией.
6. Убедиться, что значение nLockTime не превышает максимальное целое число (INT_MAX), что размер транзакции составляет как минимум 100 байтов и что количество операндов подписи меньше или равно 2.
7. Отклонить транзакцию, если алгоритм scriptSig или scriptPubKey выполняет в ней какие-либо нестандартные действия.
8. Отклонить транзакцию, если транзакция уже есть в пуле или главной ветви блока.
9. Отклонить транзакцию, если какой-либо из ее входов ссылается на выход другой транзакции в пуле.
10. Найти для каждого входа транзакции в главной ветви блока или пуле транзакцию с соответствующим выходом. Если у какого-либо входа ее нет, добавить транзакцию в группу «транзакций-сирот».
11. Для каждого входа: если транзакция с соответствующим выходом является coinbase-транзакцией, убедиться, что она имеет как минимум 100 (COINBASE_MATURITY) подтверждений, в противном случае отклонить транзакцию.
12. Для каждого входа: если соответствующего входу выхода не существует, отклонить транзакцию.
13. Используя транзакции с соответствующими выходами, убедиться, что каждый вход и сумма являются допустимыми денежными значениями.
14. Если сумма входов меньше, чем сумма выходов, отклонить транзакцию.
15. Если комиссия за транзакцию (определяемая как разность между суммой входов и суммой выходов) слишком мала для включения транзакции в пустой блок, отклонить транзакцию.
16. Проверить правильность алгоритма scriptPubKey для каждого входа и, если какая-либо из проверок завершается неудачей, отклонить транзакцию.
17. Добавить транзакцию в пул.
18. Если транзакция адресована самому узлу, добавить ее в кошелек.
19. Ретранслировать транзакцию другим узлам.
20. Для каждой транзакции-сироты, в которой текущая транзакция используется в качестве одного из входов, рекурсивно выполнить все 20 описанных этапов.

Если транзакция проходит все эти проверки, она помещается в пул и узел начинает ретранслировать ее. Если нет, транзакция не ретранслируется.

Как получение нового блока влияет на состояние пула

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

Транзакции, которых нет в новом блоке, остаются в пуле узла и повторно не ретранслируются, т. е. узел ретранслирует транзакцию только тогда, когда она добавляется в пул. Если транзакция не подтверждается за несколько блоков, ответственность за ее ретрансляцию возлагается на кошелек.

Что происходит при исчерпании памяти узла

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

В более поздних версиях bitcoind (0.12+) при приближении размера пула к объему доступной памяти узел задает минимальную комиссию. Транзакции, в которых комиссия на 1 КБ данных не достигает этого порога, немедленно удаляются из пула, после чего в пул допускаются только транзакции с достаточной комиссией.

Со временем узел снижает пороговую комиссию, постепенно возвращая его к значению minrelayfee. За пороговой комиссией можно следить с помощью RPC-команды getmempoolinfo. Ниже показан пример изменения минимальной комиссии пула за случайный интервал времени.

Источник: kaiko.com