TOLK о будущем: Как Александр Кирсанов делает блокчейн TON доступнее для разработчиков

Александр Кирсанов — разработчик с внушительным бэкграундом, преемник разработки компилятора KPHP и один из главных инженеров, стоящих за производительностью VK. Сегодня он присоединяется к команде TON Core, где будет заниматься разработкой TOLK — нового языка программирования, созданного на базе FunC, для упрощения разработки на блокчейне TON.

TON, разработанный братьями Дуровыми, известен как один из самых передовых блокчейнов с высокой масштабируемостью и продуманной архитектурой. Основной язык для создания смарт-контрактов — FunC — представляет собой мощный инструмент, который, тем не менее, считается трудным для освоения из-за своего “непривычного синтаксиса”, особенно для разработчиков, работающих с более популярными языками.

Александр стремится изменить это, создавая fork (копию) FunC под названием TOLK, который был анонсирован в рамках The Gateway 2024 в Дубае. Новый язык обещает снизить порог входа и приблизить разработку на TON к привычным для большинства синтаксисам. Подход TOLK, по сути, заключается в создании простого внешнего синтаксиса при сохранении всей функциональной глубины и безопасности, заложенной в FunC. Это позволит более широкому кругу разработчиков освоить технологии TON и ускорить создание сложных и надёжных смарт-контрактов, сохраняя высокую производительность и безопасность блокчейна.

Мы взяли у Александра интервью, в котором он поделился своим взглядом на сложности и потенциал FunC, процесс разработки TOLK и вызовы, которые он планирует преодолеть для создания по-настоящему революционного языка программирования для TON.

— Ох, во ВКонтакте у меня сложная судьба, я даже в свое время и фронтенд писал, и лендосы верстал! Но, конечно же, основной мой “продукт” — это компилятор KPHP. Для тех, кто не знает: весь бэкенд ВКонтакте написан на собственном языке. Самую-самую первую версию сделала ещё команда Дурова (как и собственные базы данных, или “движки”, о которых мы неоднократно рассказывали). Когда в 2014-м полностью сменился штат разработки, не один год ушёл на восстановление утерянных знаний. И примерно в те годы, я решил возродить из пепла KPHP. Сначала один, потом с небольшой командой, но за несколько лет мы сделали из изначальной технологии продукт совершенно иного уровня. Мы покрыли весь синтаксис PHP в рамках компилируемости и вышли за его пределы; мы провели гигантскую работу над рантайм-оптимизациями; мы обросли тулингом и плагинами для IDE; мы вышли в Open Source и стали совершенно открытыми.

Благодаря этому, бэкенд ВКонтакте стало писать в разы приятнее и быстрее, в том числе и при сотнях человек штата. 7 лет работы во ВКонтакте оставили большой след как во мне, так и в компании.

— Так вот! Поскольку один язык, изначально придуманный Николаем Дуровым с командой, мне удалось вывести на заметно иной уровень, я подумал — а почему бы не заняться другим языком тех же авторов? Только уже в мировом масштабе.

На этих основаниях мы и сошлись с командой TON Core. Самый главный язык в TON для написания смарт-контрактов — FunC. Как и многое в недрах TON, он спроектирован и написан Николаем. Удастся ли мне применить предыдущий опыт здесь, в TON’е? Скоро увидим.

— Да, многие разработчики находят FunC сложным. Но я бы сказал даже, слово “сложный” — неправильное. Правильное — “своеобразный”. Вы же знаете, как расшифровывается FunC? Нет, это не “весёлый си”, как многие думают. Это — “функциональный си”— Functional C.

Так вот, FunC — для настоящих ниндзя. Если ты владеешь Lisp’ом и Haskell’ем, ты кайфанёшь. А вот если ты из JavaScript / Go / Kotlin — тут-то и поджидают проблемы. Многое в нём покажется непривычным. И проблема в том, что эта борьба с синтаксисом может подкосить твою мотивацию углубляться в TON. Хотя, если ты пройдёшь этот путь, — то, конечно же, осознаешь, почему всё сделано именно так.

Про “ограничения” мы, конечно, можем поговорить, но это будет уже оффтопик. Потому что придётся уходить в отличия от высокоуровневых языков. А здесь всё-таки не об этом, а о “сложностях”, которые, по факту, лишь непривычность вкупе с низкоуровневостью.

— О, с форком интересно. Изначально предполагалось как раз сам FunC и развивать. Более того, я даже делал большой PR FunC v0.5.0. И нарисовал роадмап, что можно хорошего сделать в языке, компиляторе, тулинге, TVM-ке. И вот тогда мы поняли, что как раз наша цель — сделать язык, который больше похож на мейнстримовые, чем на функциональный или Си. Оставляя всю красоту и сложность внутри, не нарушая изначальные идеи Николая, — по возможности убрать “языковой барьер” и упросить порог входа.

Поэтому мы решили не трогать FunC. Оставить его как есть, каким он всегда был. Но сделать его форк — и развивать под новым именем. Название TOLK я придумывал почти 2 месяца. Так что самая ближайшая цель — это как раз сделать более привычный синтаксис (похожий на TypeScript), вообще не меняя ядро. Чтобы убрать большинство именно синтаксических граблей, на которые наступают неподготовленные новички. Собственно, к моменту гейтвея я сильно продвинулся в этом направлении.

Да, чуть не забыл. Первый релиз TOLK’а будет версии v0.6 — метафора к несбывшемуся FunC v0.5.

— KPHP и TOLK сравнивать вообще неправильно, они лежат в разных плоскостях. Если первый — это высокоуровневый язык со скрещенным рантаймом для реалтайм обработки запросов в высоконагруженных проектах с максимальной утилизацией голого железа, то FunC/Tolk — это низкоуровневый доменно-специфичный язык с таргетом в TVM. Тут принципиально различается примерно всё. Кроме буквы K :)

Но тем не менее, какой-то опыт переиспользуем. А именно — в том, что такое языки и для чего они нужны. Потому что я люблю языки. Я обожаю языки. И я их делаю для себя. Я много писал на PHP (в том числе и бэкенда ВКонтакте) — и делал KPHP, чтобы самому было удобнее. Здесь я, после закрытия достаточно очевидных потребностей, тоже хочу углубиться в проблематику написания асинхронных контрактов в целом — и как бы мне хотелось это видеть.

— Тут в вопросе всё же намешаны понятия. Язык — это маленькая часть большой технологии. И “знать язык” для девелопера — это маленькая часть большой задачи. Поясню, что я имею в виду. Для разработки на TON тебе нужно изучить: как хранятся данные и как рассчитываются комиссии; что такое адреса и как они формируются; про шардирование и асинхронную природу TONа — короче, все вот эти архитектурные вещи. В обычном Web2 мы архитектуру учимся проектировать годами, а приходя в TON, это всё обрушивается как снег на голову.

Язык — вторичен. Он лишь средство выражения мысли. А для этого ты должен понимать, что ты хочешь выразить :) И во всех децентрализованных сервисах 95% работы — это именно проектирование и работа вне кода. Как и в высоконагруженных приложениях. Это моя любимая тема в ответы на всякие “Ха-ха, ВКонтакте на PHP”.

Поэтому “реальные улучшения” можем пощупать, только опустившись до уровня, где язык уже имеет значение. Это либо рутинный процесс (когда ты и так знаешь, просто хочешь побыстрее), либо начинающий (когда ты ещё не знаешь, но пытаешься — большинство кейсов в TON). В первом случае имеет большее значение семантика, во втором — синтаксис. Поначалу у меня фокус на втором. Как первичные боли закроем, он перестроится на первый.

(И под звёздочкой — вышенаписанное верно, пока язык не начинает инкапсулировать части технологии).

Как-то философский ответ получился. Ну ладно, выглядит вроде солидно :)

— С учётом того, что я работал над Tolk несколько месяцев в полной изоляции, обратной связи у меня было ровно 0 :) Ну ничего, скоро получу, и сполна.

А теперь давай поговорим серьёзно. И снова не про язык, а про порог входа. Ибо это является камнем преткновения для многих новичков в TON.

Пока ты новичок, ты всегда делаешь ошибки. Не важно, TON это или не TON. Так вот, очень важно уметь новичка сквозь эти ошибки проводить — чтобы он понимал их причину и как их исправлять. Допустим, ты вызвал функцию с двумя аргументами вместо трёх. Ошибся, бывает. И если компилятор тебе скажет “вот тут два аргумента вместо трёх”, ты сразу поймёшь, что не так. А если компилятор укажет в другое место и скажет “ошибка унификации типов тензоров разных размерностей”, ты будешь смотреть в экран и тупить. FunC часто таким грешит. Нет, формально он, конечно, прав, потому что ошибка именно в этом — и функциональщик сразу разберётся, что не так, но скорее всего, ты будешь смотреть и тупить.

Или пример с TVM. Вот пусть я написал код, он компилируется и запускается. Но я случайно считываю 64 бита из слайса вместо 32, что приводит к ошибке в рантайме. Я запускаю контракт и вижу: “TVM exception 9: cell underflow”. Всё. Что это значит? Где мне искать ошибку? Вот и непонятно. А что я действительно хочу увидеть — это номер строчки в FunC-файле, на которой упало; стектрейс, каким образом дошло до туда управление; и т. п.

Поэтому очень важно, на протяжении всего пути пользователя, грамотно реагировать на ошибки. У Tolk’а нужно сделать человекочитаемые ошибки (сейчас это почти не так, т. к. под капотом FunC). Нужны какие-то дебаг- символы и стектрейсы в TVM. Нужен дебаггер, чтоб по шагам из IDE ходить. И так далее. Я это всё прекрасно понимаю — и туда тоже буду углубляться. Заметьте, это снова не про язык — это про тулинг и порог входа. И по опыту KPHP, это отнимает не меньшее количество времени. Потому что не менее важно.

Собственно, это один из аспектов словосочетания “сделать из технологии продукт”.

— Тут на самом деле всё крайне просто, отвечу кратко. Мы же помним, что Tolk — это “FunC под капотом, но похож на TypeScript снаружи ”. Tolk, как и FunC, компилируется в Fift-код (который потом уже в TVM байткод переводится). Поэтому для самой виртуальной машины совершенно нет разницы, на чём написан контракт, она оперирует только байт-кодом. Хоть на фифте и пиши. Я знаю как минимум одного человека, который это умеет. Как максимум — думаю, тоже одного. Все его знают :)

А если смотреть про тулинг, то уже сейчас:

— Мы решили не трогать FunC. Оставить высеченным в камне, ровно таким, каким видел его Николай Дуров. Если будут критичные баги — конечно, исправим. Но активной разработки не планируется. Все написанные на FunC контракты по-прежнему будут работать, естественно. И его по-прежнему можно будет использовать.

Но поскольку TOLK позволяет делать ровно то же самое, без оверхеда на газ (и при всех будущих изменениях должен позволять) — новичков постепенно будем “приземлять” на TOLK. FunC мы скоро задепрекейтим по избежание путаницы.

— Это похоже на последний вопрос, поэтому давайте подытожим, что у нас накопилось.

Ближайшие цели — синтаксические. На данный момент уже очень много чего сделано. Дальше есть несколько очевидных пунктов (про систему типов, ошибки компиляции, stdlib). Есть несколько менее очевидных пунктов (структуры с автоупаковкой в ячейки, честные методы, TL-интеграции). Есть работа над порогом входа помимо языка (TVM, TL/B, плагины, тулчейн).

И есть в одном из ответов выше такая сносочка в стиле Айзека Азимова: “вышенаписанное верно, пока язык не начинает инкапсулировать части технологии”. Под этой сносочкой и кроются долгосрочные, слишком пока ещё туманные, цели. Сегодня здесь без конкретики. А то понаобещаю тут, а потом делать придётся :) Хотя ладно, куда я денусь-то. За этим и прихожу.

И поэтому, кстати! Я с огромным удовольствием пообщаюсь с теми, кто писал на FunC сложные взаимосвязанные контракты. Чтобы впитать их боли (более высокоуровневые, нежели синтаксис) и подумать, а как бы это могло бы быть по-другому.

Проект TOLK, запущенный Александром Кирсановым, открывает новую главу в развитии экосистемы TON. Опираясь на свои годы работы с высоконагруженными системами, Александр создаёт язык, который способен сделать блокчейн TON ближе к разработчикам, сняв барьер в виде специфического синтаксиса FunC. Но речь не просто о том, чтобы упростить процесс — TOLK сохраняет всю мощь оригинального языка, что делает его подходящим как для новичков, так и для опытных специалистов.

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

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