Есть ли у TON мемпул? Что видно до попадания в блок

Спросите в чате разработчиков «есть ли у TON мемпул?» — и получите два уверенных ответа. Первый: «Нет, в TON мемпула нет». Второй: «Есть, вот pending-транзакция из toncenter». Оба в чём-то правы. В TON нет единого общесетевого пула неподтверждённых транзакций, который держит и согласует каждая нода, как в Bitcoin. Но сообщение существует до того, как попадёт в блок, ноды его видят, и в это окно можно заглянуть через несколько API.

В статье разберём, что слово «мемпул» означает применительно к TON, почему pending у toncenter — это эмуляция, а не хранимый объект, что может и чего не может показать поток сообщений до блока, и как устроен поток мемпула TONNode — начиная с ограничений.

Что такое «мемпул» в TON

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

TON начинается с другой единицы. Пользователь никогда не отправляет «транзакцию». Приложение-кошелёк подписывает внешнее сообщение (external message) и передаёт его ноде. По формулировке docs.ton.org, внешние сообщения «отправляются извне блокчейна и поэтому имеют лишь необязательный внешний адрес отправителя». Контракт-получатель — для пользователя это контракт кошелька — проверяет подпись и seqno, вызывает ACCEPT, и только тогда появляется транзакция: «при обработке входящего внешнего сообщения транзакция создаётся, только если контракт принимает сообщение».

Отсюда три следствия, из-за которых «мемпул TON» — вольное выражение, а не объект протокола.

• Торговаться нечем. Внешнее сообщение не несёт оплаты от отправителя. За газ платит контракт-получатель после ACCEPT, пользуясь газовым кредитом, который даёт ему сначала проверить сообщение. Никакая очередь не упорядочена по цене, потому что цены у сообщения нет.
• Единой очереди нет. TON шардирован: аккаунт принадлежит шардчейну, с префикса которого начинается его адрес, и сообщение, адресованное кошельку, важно только нодам, которые собирают блоки этого шарда. Нода, получившая внешнее сообщение, рассылает его в публичном оверлее, и документация отмечает, что «валидаторы делятся ими друг с другом и могут случайно (или намеренно) доставить сообщение несколько раз». Каждая нода хранит то, что услышала; согласованного набора нет нигде.
• Отклонённое сообщение не оставляет следа. Если контракт не принял сообщение — подпись неверна, seqno уже использован, valid_until истёк, нечем платить, — транзакция не создаётся, и ни один блок не фиксирует попытку.

Поэтому честная расшифровка слов «мемпул TON» такая: внешние сообщения, которые какая-то нода получила и разослала, но ни один блок ещё не включил. Это окно в несколько секунд, с каждой ноды оно выглядит по-разному, и часть его содержимого никогда не исполнится. Именно это окно и показывает поток мемпула.

Почему pending у toncenter — это эмуляция

В API v3 toncenter есть GET /api/v3/pendingTransactions — по документации, «запрос pending-транзакций по заданным фильтрам», по аккаунту или по trace id. Его Streaming API отдаёт события с полем finality: pending, confirmed или finalized, и первый уровень определён точно: «pending — результат эмуляции или спекулятивного исполнения. Это состояние может быть инвалидировано».

Ключевое слово — эмуляция. Pending-транзакция у toncenter не выловлена из очереди ноды и не показана как есть. Индексатор берёт внешнее сообщение, прогоняет его по текущему состоянию аккаунта так, как это сделал бы валидатор, и публикует предсказанную транзакцию и действия, которые она произведёт. Когда приходит настоящий блок, событие отдаётся повторно как confirmed, позже как finalized; если предсказание не сбылось, следует уведомление trace_invalidated. Подписки — по адресам: операция subscribe в WebSocket принимает список addresses, который «можно оставить пустым только при подписке на trace, для остальных типов событий он обязателен».

Это отличный ответ на вопрос, который задаёт большинство продуктов: прошёл ли платёж моего пользователя и можно ли показать его на секунду раньше? Чего он не даёт — сырого потока сети до блока: всех сообщений всех кошельков, включая те, что никогда не исполнятся, до какой-либо эмуляции. Это два разных продукта, и полезно понимать, какой из них вы покупаете.

Что может и чего не может показать поток мемпула TON

Поток мемпула — тот самый второй продукт: нода, которая пересылает внешние сообщения в момент, когда их слышит. Прежде чем строить на нём что-то, ограничения важнее возможностей. Ниже они взяты из раздела «Качество данных» в документации.

Покрытие частичное. В потоке то, что одна нода получает из публичного оверлея. Сообщение, которое до неё не дошло, в потоке отсутствует, и его отсутствие ничего не доказывает. TONNode не публикует цифр полноты и скорости и не заявляет, что видит сообщения первым.

Pending не значит «включено». Сообщение checked прошло проверки ноды при широковещании, а не исполнение валидатором. В одной 90-минутной выборке в октябре 2026 примерно каждое пятое checked-сообщение так и не было принято в блокчейн.

Ранние сообщения не проверены. Самый ранний хук ноды срабатывает до её проверки подписи при широковещании, в точке, где любой пир оверлея может подсунуть байты. Поток отдаёт их как "path":"early","unverified":true — по умолчанию, потому что для некоторых задач выигрыш во времени важнее уверенности. Всё, что действует автоматически, либо шлёт "include_unverified":false, либо ждёт копию checked с тем же cell_hash.

parsed — на лучшее усилие. Разобранное тело кошелька (v4r2, v5r1, highload_v3, перевод жетона, своп на DEX) выводится только из байтов сообщения; состояние блокчейна не читается. Контракт, имитирующий раскладку кошелька, может быть размечен неверно.

Дубликаты бывают. Один и тот же cell_hash может прийти как early, затем как checked, ещё раз после переподключения и изредка после окна дедупликации. Обработка должна быть идемпотентной по cell_hash.

Часть сообщений отбрасывается намеренно: BoC больше 65 535 байт, BoC, не являющиеся внешними сообщениями, и адреса назначения не вида addr_std.

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

Как устроен поток мемпула TONNode

Поток TONNode — один WebSocket: wss://mempool.tonnode.io/v1/stream. Сервер авторизуется заголовком Authorization: Bearer tnmp_…. Браузер заголовки на WebSocket ставить не умеет, поэтому бэкенд, который хранит ключ, запрашивает у POST /v1/ticket одноразовый тикет на 30 секунд и передаёт полученные subprotocols в new WebSocket(url, subprotocols). Первое сообщение на каждом соединении — hello, пример из документации:

{"v":1,"type":"hello","contract":"1.1","epoch":"9f3c1a7be2d04c11","head_seq":123456,"oldest_seq":118020,
 "ts_gw_us":1791322891600000,"key_id":"0123456789ab",
 "limits":{"max_conn":3,"max_filters":null,"delay_ms":0,"replay_limit":null}}

Пока клиент не подписался, ничего не доставляется. Фильтры необязательны и объединяются через ИЛИ: dest (кошелёк-отправитель), out_dest (куда кошелёк отправляет), op (код операции, например 0x0f8a7ea5 для переводов жетонов) и pool (пул DeDust). "filters":{} — весь поток; подписка вмещает до 10 000 записей, а повторный subscribe заменяет фильтры без повтора событий. Подписка со всеми четырьмя видами фильтров и отказом от ранних сообщений:

{"v":1,"type":"subscribe",
 "filters":{"dest":["0:2a18ac1734f34579e6a6c2a9e738bb5799d21e7a73ef106895c00c34549a9167"],
            "out_dest":["EQB3ncyBUTjZUA5EnFKR5_EnOMI9V1tTEAAPaiU71gc4TiUt"],
            "op":["0x0f8a7ea5"],
            "pool":["0:a0d1bc3a139cbc6b39a3e3633f74476be441343f9d0fd88b949fca0327b65a75"]},
 "include_unverified":false}

Сервер подтверждает подписку числом уникальных записей и точкой, с которой начнётся доставка:

{"v":1,"type":"subscribed","filters":4,"include_unverified":false,"from_seq":123451}

Дальше приходит по одному JSON-объекту на сообщение, в порядке seq: сырой boc, его хеши (cell_hash, нормализованный по TEP-467 norm_hash, sha256), кошелёк назначения, path и unverified, две метки времени и, если раскладка тела распознана, parsed с типом кошелька, seqno, valid_until и исходящими переводами, переводами жетонов и распознанными свопами STON.fi и DeDust.

Повтор. Сервер хранит последние ~60 секунд событий, не больше 64 МиБ. После обрыва переподключитесь, отправьте resume с epoch и последним обработанным seq — и получите пропущенное через новые фильтры. Событие gap сообщает, что пропущено и почему: slow, source_reconnect или ring.

Тарифы. Не считается ничего, кроме одновременных соединений на одном ключе. Test: 7 дней, 1 соединение, $5. Start: 30 дней, 1 соединение, $15. Pro: 30 дней, 3 соединения, $30. Business: 30 дней, 10 соединений, $100. Больше 10 соединений — по запросу. Без квоты на сообщения, без добавленной задержки, фильтры и повтор включены, бесплатного тарифа нет. Ключ покупается в консоли с того же баланса, что и тарифы нод; полная таблица — на странице цен.

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

Полные потребители на Node.js, Python и Go, браузерный сценарий с тикетами, справочник полей и коды ошибок — в документации потока мемпула.

Честное сравнение с TonAPI streaming и toncenter streaming

Окна до блока касаются три сервиса, и они не взаимозаменяемы. TonAPI Streaming API предлагал GET /v2/sse/mempool и WebSocket-метод subscribe_mempool с необязательным фильтром по аккаунтам; его собственная документация теперь открывается словами: «Streaming API устарел — для обновлений в реальном времени используйте Webhooks API». Toncenter Streaming API по адресу wss://toncenter.com/api/streaming/v2/ws отдаёт транзакции, действия, трейсы и изменения состояния с уровнем финальности; pending-события эмулируются и могут быть инвалидированы, а подписки требуют адреса для всего, кроме трейсов. Поток мемпула TONNode отдаёт сырые внешние сообщения в том виде, в каком их получает одна нода, целиком или по фильтрам, без эмуляции и без отслеживания финальности.

Ни один из трёх не публикует цифру, по которой можно сравнить покрытие, и TONNode тоже. Измеряйте на собственном трафике, прежде чем решать.

Кому нужен поток мемпула, а кому нет

Скорее всего, нужен, если:

• у вас DEX или торговый бот, и секунды между рассылкой свопа и его исполнением — ваше преимущество, при условии include_unverified:false или шага подтверждения до того, как что-то сдвинется;
• вы следите за набором кошельков или пулом и хотите видеть перевод или своп в момент рассылки, а не когда придёт блок;
• вы изучаете сеть: частоту сообщений, версии кошельков, какие DEX-роутеры загружены, сколько сообщений никогда не исполняется.

Не нужен, если:

• вы определяете платежи. Платёж — это транзакция в блоке; читайте её через get_transactions и никогда не отмечайте заказ оплаченным по pending-сообщению;
• вы показываете балансы или историю. У мемпула нет состояния; для этого есть глава про лайтсерверы и история транзакций по lt и хешу;
• вам нужно каждое сообщение или собственные отправки через лайтсерверы TONNode. Покрытие частично по самой природе оверлея, а ваших отправок в потоке нет по замыслу.

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

FAQ

Есть ли у TON мемпул?

Единого глобального — нет. В TON нет общесетевого пула неподтверждённых транзакций, который держит и согласует каждая нода. Есть набор внешних сообщений, которые конкретная нода получила из публичного оверлея и ещё не увидела в блоке; у каждой ноды он свой, живёт несколько секунд и содержит сообщения, которые никогда не исполнятся.

Можно ли увидеть pending-транзакции в TON?

Да, в двух смыслах. Toncenter показывает pending-транзакции и действия, полученные эмуляцией внешнего сообщения на текущем состоянии, по адресам, и может позже их инвалидировать. Поток мемпула, такой как у TONNode, показывает сами сырые внешние сообщения, как их слышит нода, до любого исполнения. Ни то, ни другое не является подтверждённой транзакцией — ею является только блок.

Почему pending-сообщение не попало в блок?

Потому что транзакция создаётся, только если контракт-получатель принял сообщение. Кошелёк отклоняет неверную подпись, уже использованный seqno, истёкший valid_until или сообщение, за которое нечем платить, и отклонённое сообщение не оставляет следа в блокчейне. Сообщение может и потеряться, не дойдя до нод, которые собирают блоки этого шарда. В одной 90-минутной выборке в октябре 2026 примерно каждое пятое checked-сообщение в потоке TONNode так и не было принято.

Полный ли поток мемпула TON?

Нет, и полным не может быть ни один поток. В потоке TONNode то, что одна нода получает из публичного оверлея; сообщение, которое до неё не дошло, в потоке отсутствует. TONNode не публикует цифр полноты и скорости и не заявляет, что видит сообщения первым. Отсутствие в потоке никогда не доказывает, что чего-то не было.

Что означает unverified в потоке?

Это раннее сообщение, записанное до проверки подписи ноды при широковещании, в точке, где любой пир оверлея может подсунуть байты, — оно может оказаться мусором или подделкой. Ранние сообщения доставляются по умолчанию; подписка с "include_unverified": false получает только checked-сообщения, которые прошли проверки ноды, но не исполнены валидатором.

Сколько стоит поток мемпула TONNode?

Тарифы считаются по одновременным соединениям на одном ключе: Test — 7 дней, 1 соединение, $5; Start — 30 дней, 1 соединение, $15; Pro — 30 дней, 3 соединения, $30; Business — 30 дней, 10 соединений, $100. Квоты на сообщения нет, добавленной задержки нет, бесплатного тарифа нет.

Прежде чем подключаться

Перечитайте раздел «Качество данных», решите, нужны ли вам ранние сообщения вообще, сделайте обработку идемпотентной по cell_hash и подтверждайте в блокчейне до того, как сдвинутся деньги. Если всё сходится — ключ Test стоит $5 за 7 дней на странице цен. Если нет — правильный инструмент это приватный доступ к лайтсерверам, который читает подтверждённое состояние, и именно он нужен большинству продуктов.