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

Имею бэкграунд в evm/svm, распределенных системах и zk.

gh -> @Kaladin13
ld -> @maksim-lagus
tg -> @tiredofbeeing

Все мнения мои собственные.

Консенсус в Тоне, обзорно

За время существования Тона в опенсорсе, консенсус, описанный Николаем в catchain.pdf, обсуждался меньше всего. В этом посте разберемся как валидаторы договариваются о принятии новых блоков, почему в Тоне не бывает форков (finality = latency) и как можно это потрогать.

Пдф описывает два протокола - собственно сам Кэтчейн и BCP (Block Consensus Protocol).

Несмотря на крутое название, Кэтчейн не является консенсусом в Тоне - описанный протокол вообще не связан с блокчейном и описывает как нужно обрабатывать зависимости между абстрактными сообщениями.

Вспомните npm или maven: каждое сообщение в Кэтчейне несёт с собой package.json, в котором лежат записи вида @node1/message-2 и @node2/message-3. Обработать входящее сообщение можно только после получения и обработки указанных зависимостей. Кэтчейн ничего не знает про стейки и валидацию блоков, он служит транспортом для BCP.

BCP - это PoS консенсус из семейства алгоритмов византийской отказоустойчивости (BFT). Это означает что сеть может продолжать успешную работу (выбирать одни и те же валидные блоки в одинаковом порядке) при наличии >= 2/3 “хороших” нод (взвешенный кворум по размеру стейков валидаторов).

Есть два семейства PoS алгоритмов:
1. C легкой генерацией блоков, разрешенными форками и их последующим разрешением
2. Со сложным согласованием выбора блока, при этом с отсутствием (почти) форков.

BCP относится ко вторым - чтобы нода посчитала блок принятым локально, она должна увидеть:

1. Пропоуз блока (Submit)
2. Кворум по валидации блока (Approve)
3. Кворум по голосованию за блок (Vote)
4. Кворум пре-коммитов на блок (PreCommit)
5. Кворум коммитов за блок (Commit)

Форков и ролл-бэков не бывает - блок финализируется до того как может появиться конкурентная ветка.

Для желающих разобраться во всем этом, мною была реализована визуальная интерактивная симуляция консенсуса Тона:
https://docs.ton.org/foundations/consensus/catchain-visualizer

Фидбэк приветствуется, ругать -> сюда, хвалить -> сюда

А вас же тоже бесят мнемоники?

Мне они всегда не нравились, цифровые хранилища для них ненадежны, физические и потерять можно, а кроме селф-кастоди я ни во что не верю. В эти новогодние праздники я решил с этим разобраться.

В блокчейнах с EOA моделью у пользователей особо нет выбора - кошельки и логика их подписей заданы внешне, на уровне протокола, и у разработчиков нет возможности изменить их ончейн логику.

Однако в Тоне кошельки - смарт контракты, и это означает что мы можем контролировать их поведение. Исторически мы пошли самым проторенным путем - те же самые bip сидфразы и мнемоники.

Я считаю, что можно лучше и интереснее, поэтому представляю вам новый тип кошельков на Тоне - Telegram Wallet.

В одном из недавних апи патчей Телеграм без анонсов добавили новый вид проверки валидности данных в Тма - через публичную криптографию, Ed25519 подписи, которые как раз нативно поддержаны в TVM.

Я написал смарт контракт для кошелька, который работает на Телеграм подписях вместо подписей от мнемоники юзера, таким образом создавая новую секьюрити модель:

⁃ Кошелек без мнемоники, для подтверждения транзанкции нужно зайти в Телеграм и подписать через Тма
⁃ Сохранен весь функционал V5 - gasless, плагины, 255 сообщений за транзу
⁃ Без ущерба для безопасности: работает replay protection с секно, эксипрейшн с valid_until
⁃ Контракт шардирован по tg_user_id и tma_id, тг подписи валидны только для контракта этого юзера

Главное отличие Telegram Wallet от торговых ботов или Тма кошельков бирж (которые тоже работают без мнемоник) в том, что они просто хранят вашу ту же самую ‘green bread satoshi durov …’ сидку на бэке, автоматически подписывая транзы за вас. Тут же - идейно другой механизм работы, в котором этих ненавистных 24 слов просто нет, подписи работают по-другому, через тг.

Минусы такого подхода:
⁃ Завязка на Телеграм и Тма (вдруг свой приватный ключ потеряют или приложение забанят)
⁃ Завязка на свой Телеграм аккаунт (тоже могут забанить или просто утопить телефон с симкой)

Плюсы:
⁃ Не нужно сохранять мнемонику
⁃ Можно делать нативные кошельки под Тма
⁃ Весело

Вдобавок к контракту я написал интеграцию Telegram Wallet в протокол Ton Connect, и даже сделал демо фронтенд для такого нового типа кошельков - можно подключиться к любому даппу и через привычный UI делать декс свапы и всё остальное.

Код контракта - https://github.com/Kaladin13/telegram-wallet, пример задеплоенного кошелька

Под конец открытые вопросы на подумать:
⁃ Зачем и для кого Телеграм изначально добавляли такой функционал? (не для меня.)
⁃ Как можно решить описанные мной минусы
⁃ Другое применение ончейн тг подписей

Формальная верификация в Тоне

Сама идея формального рассуждения восходит к Готфриду Лейбницу (XVII век), который мечтал о создании универсального языка, способного свести все споры к вычислениям. Идея в том, чтобы привести математическое доказательство того, что система ведёт себя строго в соответствии со своей спецификацией, а не просто проверка на отдельных примерах.

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

Данная техника наиболее полезна в областях с критическими требованиями к корректности и безопасности, такие как: медицина, ПО для шахт, финансы и блокчейны.

Верификация в веб3 актуальна как никогда - десятки команд занимаются доказательствами на эфире, был создан Lean Foundation для формализации всего протокола, llm агенты исключительно хорошо формируют теоремы.

В Тоне тоже есть industry-level исследования по этой теме - движок символьного исполнения TSA. TSA моделирует семантику TVM на уровне байткода, учитывая все возможные пути исполнения. Неважно насколько обфусцирован код контракта или запутана логика бранчей - если существует путь исполнения который не соответствует заданной спеке - то движок его найдет с любым стейтом.

В написании чекеров для Тона есть несколько сложных моментов:
• Асинхронная акторная модель в кросс-контрактном анализе
• Зубодробительный расчет комиссий сети (storage fee, fwd fee, … - их все нужно символьно эмулировать)
• > 900 инструкций в TVM

Используя TSA, я формально верифицировал ключевые свойства в стандарте жеттонов TEP-74 и написал сервис для проверки контрактов в сети на символьное соответствие спеке.

Полностью стандарт не так интересен (например burn и mint), поэтому я сделал фокус на самом важном для пользователей - трансфере.

На уровне чекеров я проверяю жеттон-кошельки на следующие свойства:
• Трансфер может быть отправлен на любой произвольный адрес (свойство ханнипотов)
• В результате трансфера баланс получателя меняется ровно на поле amount (свойство tax жеттонов)
• Нельзя заблокировать трансферы по флагу (вообще это считается governance, но свойство опасное)
• Гет методы отдают реальный стейт (sanity check)

Демка - https://verify.lagus.cooking
Код - https://github.com/Kaladin13/formal-verification-jetton

Вопросы на подумать:
• Можно ли обмануть мои чекеры по этим свойствам и как
• Какое есть фундаментальное ограничение в форм верифе на Тоне
• Можно ли верифицировать электор

Прямо сейчас в мейннете идет голосование изменение 30 параметра конфига и включение Catchain 2.0 - нового Simplex-like долгожданного sub-second консенсуса.

Это фундаментальное изменение нашего блокчейна, которое также поменяет внутренний протокол через который общаются валидаторы (RLDP -> QUIC).

Сделал сайт через который можно в прямом эфире следить за прогрессом голосования валидаторов:
https://vote.lagus.cooking/

Держим кулачки.

Voting is now live on mainnet for a change to config parameter 30 and the activation of Catchain 2.0, a new sub-second consensus with ~400ms block-time.

This is a fundamental change to our blockchain, allowing validators to communicate internally with each other using QUIC protocol.

There is a website where you can track the validator voting progress in real time:
https://vote.lagus.cooking/

Fingers crossed.

У нас в мейннете еще одно важное голосование за снижение сетевых комиссий. Давайте разберемся за что именно голосуем и почему станет дешевле.

Изменяются три некритических параметра конфига: 18, 21, 25.

1. 18 параметр - цены на сторадж, то есть за хранение информации в аккаунтах на блокчейне. Обновление цен в бейзчейне:
Было: 1 nanoton за bit каждые 65536 sec, 500 nanoton/cell/65536s
Стало: 0 nanoton за bit каждые 65536 sec, 135 nanoton/cell/65536s

Интересно что цена за бит не в мастерчейне теперь 0, то есть весь прайс аккаунтов складывается из количества ячеек в стейте.

2. 21 параметр - цены и лимиты на исполнение кода контрактов, то есть сколько стоит выполнение инструкций TVM. Лимиты не меняются, а вот дифф цен:
Flat gas price: 100 gas for 40,000 nanoton -> 100 gas for 6,667 nanoton
Gas price: 400 nanoton/gas -> 66.666672 nanoton/gas

3. 25 параметр - цены за отправку сообщений между контрактами в бейзчейне. Стоимость сообщения считается как "базовое значение + сумма битов/ячеек сообщения * коэффициент". Дифф:
Base forwarding fee: 400,000 nanoton -> 66,667 nanoton
Bit forwarding price: 400 nanoton/bit -> 66.666672 nanoton/bit
Cell forwarding price: 40,000 nanoton/cell -> 6,666.666672 nanoton/cell

Как результат - станет дешевле хранить данные, отправлять сообщения и исполнять смарт контракты, то есть будут затронуты все состовляющие сетевых комиссий контрактов в Тоне.

Смотрим в прямом эфире: https://vote.lagus.cooking/

P.S. Странные новые значения комиссий вида 67.67 получаются из-за того, что награды в Тоне делятся между валидаторами разных шардов (а часть вообще сжигается). В связи с этим, для того чтобы получить настоящие цифры, которые будут платить юзеры, приходится делить на 2^16 и потом округлять.

Я пришел в Тон экосистему летом 24 года когда она была в прайме. Тогда в блокчейн пришло много новых разработчиков, однако спустя 2 года из них остались единицы. Одна из причин - сложность ончейн разработки и состояние дев тулинга для неё.

Последние полгода я работаю в команде Тон Кора и занимаюсь смарт контрактами и инструментами для них. Сегодня мы релизнули гейм-ченджер для разработки на Тоне - тулчейн Acton.

Это большой и сложный технический продукт, который включает в себя:
• рантайм для Толк тестов
• нативный дебаггер
• скиллы для AI агентов
• ABI + автоген враперов
• faucet + Толк скриптинг

Респект остальной нашей команде, мы очень жесткие ребят.

Сейчас начинается новый цикл и я верю что подобные улучшения экосистемы правда могут поменять игру.

Это только начало. mtonga.