Lagus research

Я пришел в Тон экосистему летом 24 года когда она была в прайме. Тогда в блокчейн пришло много новых разработчиков, однако спустя 2 года из них остались единицы. Одна из причин - сложность ончейн разработки и состояние дев тулинга для неё. Последние полгода я работаю в команде Тон Кора и занимаюсь смарт контрактами и инструментами для них. Сегодня мы релизнули гейм-ченджер для разработки на Тоне - тулчейн Acton. Это большой и сложный технический продукт, который включает в себя: • рантайм для Толк тестов • нативный дебаггер • скиллы для AI агентов • ABI + автоген враперов • faucet + Толк скриптинг Респект остальной нашей команде, мы очень жесткие ребят. Сейчас начинается новый цикл и я верю что подобные улучшения экосистемы правда могут поменять игру. Это только начало. mtonga.

У нас в мейннете еще одно важное голосование за снижение сетевых комиссий. Давайте разберемся за что именно голосуем и почему станет дешевле. Изменяются три некритических параметра конфига: 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 и потом округлять.

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, and it will also replace the internal protocol validators use to communicate with each other, moving from RLDP to QUIC. There is a website where you can track the validator voting progress in real time: https://vote.lagus.cooking/ Fingers crossed.

Прямо сейчас в мейннете идет голосование изменение 30 параметра конфига и включение Catchain 2.0 - нового Simplex-like долгожданного sub-second консенсуса. Это фундаментальное изменение нашего блокчейна, которое также поменяет внутренний протокол через который общаются валидаторы (RLDP -> QUIC) и сделает сильный шаг в сторону от оригинального вайтпейпера. Сделал сайт через который можно в прямом эфире следить за прогрессом голосования валидаторов: https://vote.lagus.cooking/ Держим кулачки.

Формальная верификация в Тоне Сама идея формального рассуждения восходит к Готфриду Лейбницу (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 Вопросы на подумать: • Можно ли обмануть мои чекеры по этим свойствам и как • Какое есть фундаментальное ограничение в форм верифе на Тоне • Можно ли верифицировать электор

А вас же тоже бесят мнемоники? Мне они всегда не нравились, цифровые хранилища для них ненадежны, физические и потерять можно, а кроме селф-кастоди я ни во что не верю. В эти новогодние праздники я решил с этим разобраться. В блокчейнах с 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, пример задеплоенного кошелька Под конец открытые вопросы на подумать: ⁃ Зачем и для кого Телеграм изначально добавляли такой функционал? (не для меня.) ⁃ Как можно решить описанные мной минусы ⁃ Другое применение ончейн тг подписей

Консенсус в Тоне, обзорно За время существования Тона в опенсорсе, консенсус, описанный Николаем в 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 Фидбэк приветствуется, ругать -> сюда, хвалить -> сюда

Всем привет, меня зовут Максим, это мой технический блог посвященный разработке и ресерчу в асинхронном блокчейне Тон. Буду писать про контракты, консенсус, ончейн секьюрити и экосистему. Имею бэкграунд в evm/svm, распределенных системах и zk. gh -> @Kaladin13 ld -> @maksim-lagus tg -> @tiredofbeeing Все мнения мои собственные.