Чи є у 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 днів на сторінці цін. Якщо ні — правильний інструмент це приватний доступ до лайтсерверів, який читає підтверджений стан, і саме він потрібен більшості продуктів.