Tolk vs TL-B: хватит переводить схемы, пора моделировать типы
Если вы переходите в Tolk из FunC, первое естественное желание — найти знакомые ориентиры. Разработчики часто спрашивают: где тут аналог TL-B, как сгенерировать TL-B-схему из структуры Tolk, куда положить block.tlb в проекте. Такое мышление логично в мире FunC — но в Tolk оно уводит не туда. Причина простая: типовая система Tolk спроектирована как замена TL-B, а не как его надстройка.
Почему TL-B так прочно укоренился в TON
TL-B стал стандартом в экосистеме TON из-за особенностей FunC. FunC — это императивный, низкоуровневый язык. Контракты в нём вручную:
- парсят ячейки и срезы,
- проверяют структуру данных в рантайме,
- обеспечивают корректность формата через код, а не через декларации.
Сам код контракта не описывает свои входы, сообщения и хранилище декларативно. Поэтому TL-B появился как компенсирующий слой — формальное описание того, какие данные допустимы, как они устроены и как организовано хранилище.
Со временем TL-B фактически стал схемным языком для FunC-контрактов — как для разработчиков, так и для туллинга. В такой модели разделение было логичным: код — для логики, TL-B — для структуры.
Что меняется в Tolk
В Tolk структура больше не живёт «снаружи языка». Она встроена прямо в код. Сообщения и хранилище описываются через struct, и эти определения:
Сериализация и десериализация автоматически следуют из этих типов. Нет отдельной схемы, нет дублирования логики парсинга, нет расхождений. Tolk-структура уже выполняет ту роль, которую раньше играл TL-B.
Туллинг строится вокруг типов
Весь туллинг Tolk опирается на типовую систему:
TL-B в этих процессах не участвует — он для этого просто не предназначен.
Похожесть есть, но системы разные
На первый взгляд TL-B и Tolk кажутся похожими:
Именно это сходство часто создаёт иллюзию, что одно можно механически перевести в другое. Но различия принципиальные.
TL-B содержит конструкции для описания протокольного уровня:
Это оправдано для описания блоков и сообщений на уровне протокола.
Tolk, в свою очередь, поддерживает вещи, которых TL-B никогда не задумывался описывать:
- type aliases,
- enum’ы,
- inline-union’ы с автогенерацией префиксных деревьев,
- tensors,
- кастомную сериализацию,
- address? как «internal или none», а не «maybe T».
Это отражает разницу в природе систем: Tolk — язык программирования со статической типизацией, TL-B — схемный язык для бинарных форматов.
Где TL-B всё ещё нужен
TL-B по-прежнему отлично подходит для описания внутренних структур протокола TON. Файлы вроде block.tlb — его естественная среда. Но API контрактов, форматы сообщений и модели взаимодействия — это уже другая область. Здесь типовая система Tolk является источником истины. Всё будущее развитие туллинга Tolk строится на предположении, что контракты типизированы внутри языка, а не описаны внешними схемами. Если вы:
- описываете интерфейсы контрактов,
- задаёте форматы сообщений для dApp’ов,
- моделируете layout хранилища,
— вся эта работа делается в Tolk, а не в TL-B.
Как связать Tolk и сериализацию
Если хочется понять, как типы Tolk соотносятся с низкоуровневой сериализацией TON, в документации TON есть раздел Overall serialization. Важно учитывать: там используются императивные правила сериализации, которые принципиально отличаются от декларативных TL-B-схем.
Смена мышления
Переход с FunC на Tolk — это не только новый синтаксис. Это отказ от привычки «переводить схемы» и переход к моделированию данных прямо в языке. В Tolk типовая система и есть схема. Когда это осознаёшь — вся экосистема начинает складываться в цельную картину.
Полезные материалы для разработчиков
Примеры контрактов (token, NFT, Wallet на TOLK)
Примеры реальных контрактов тут
Конвертер FunC-to-TOLK (инструмент для миграции)
Сравнительный анализ FunC vs. TOLK (данные по расходу газа)
Документация: система типов и union (для понимания сериализации TL-схем)
Telegram-канал языка: @tolk_lang
Подписывайтесь на наш Telegram-канал @toncishub