ABI
Описание интерфейса смарт-контракта — какие методы он принимает и какие сообщения понимает. В TON, в отличие от EVM, единого ABI-стандарта нет: формат зависит от языка контракта.
Синонимы: application binary interface, абх, контрактный интерфейс
ABI (Application Binary Interface) — машиночитаемое описание того, как внешний код общается со смарт-контрактом: какие сообщения он принимает, какие get-методы можно вызвать, какие у них аргументы и возвращаемые типы. На основании ABI dApp, кошелёк или индексер строит транзакции и парсит ответы.
ABI в EVM и почему в TON всё иначе
В Ethereum-совместимых сетях ABI давно стандартизирован: Solidity-компилятор всегда выдаёт JSON фиксированной формы, любой инструмент (ethers.js, web3.js, эксплореры) этот JSON понимает. Это и есть «ABI как единый протокол».
В TON ситуация принципиально другая:
- Базового ABI-стандарта на уровне сети нет. TVM не требует от контракта публиковать его интерфейс — на цепочке хранится только скомпилированный код.
- Формат ABI определяется языком контракта. Разные языки и тулчейны генерируют свои описания, и пользоваться ими надо в рамках их же экосистемы.
- Вместо общесетевого ABI есть стандартизованные opcode-ы для распространённых сообщений (Jetton transfer, NFT transfer и т. п.) — они описаны в TEP-ах и обязательны для совместимых контрактов.
Что генерируют разные языки
- Tact — выдаёт JSON-описание получаемых сообщений (с opcode и схемой полей) и список get-методов с типизированными параметрами. Это ABI в привычном смысле; есть кодген клиентов под TypeScript и другие языки.
- Tolk — также генерирует ABI как часть тулчейна, идеологически близко к Tact.
- FunC — низкоуровневый язык, ABI как такового не выдаёт. Разработчик описывает интерфейс контракта вручную: какие opcode принимает, какие get-методы есть, какие у них сигнатуры. Эта документация — фактически ABI «по договорённости».
Как dApp вызывает контракт
С точки зрения вызывающего кода в TON ABI распадается на две части:
- Get-методы — read-only вызовы, выполняются на узле без транзакции. На вход идут параметры, на выход — стек значений TVM. Чтобы вызвать get-метод, нужно знать его имя/идентификатор и сигнатуру стека.
- Внутренние сообщения — write-операции, оформляются как транзакция от кошелька к контракту. Тело сообщения начинается с opcode (32-битный u32 префикс), который контракт распознаёт и решает, какой обработчик вызвать. Дальше идут типизированные поля по схеме, описанной в ABI.
Практически
Если вы интегрируете контракт, написанный на Tact или Tolk, скорее всего вам отдадут готовый ABI-файл и сгенерированный TS-клиент. Если контракт на FunC — придётся пользоваться ручной спецификацией от автора и собирать сообщения через ton-core или аналог. В обоих случаях стандартные сообщения (Jetton transfer, NFT-операции) лучше использовать через утилиты SDK, а не собирать вручную: они подчиняются TEP-ам, и формат у всех совместимых контрактов одинаков.