Lagus research

Вместе с релизом Acton 1.2 сегодня, мы представляем Acton Studio - набор тулзов для работы со всем стеком Тона, не останавливаясь на уровне контрактов.

Одна из главных фич релиза это Simulator, быстрая локальная симуляция реальной сети aka Ganache. Внешне эта сеть ведёт себя как полноценная нода Тона - поднят бридж для тон коннекта, работает лайт апи и тонцентр, есть мастерчейн и персистентные блоки. В такой среде очень удобно работать не только на уровне контрактов, но и тестировать всю систему в целом, вместе с бэкендом, индексацией и фронтом даппок.

При работе в Солане с Anchor я очень часто использовал фикстуры, предиктабл стейт для аккаунтов в локальной сети который берётся из мейннета. В Acton Studio мы пошли дальше, при запуске Симулятора вы можете в локальном UI выбрать от какого блока вы хотите форкнуть состояние вашей новой сети и переопределить любые нужные вам аккаунты.

Обновляемся и пробуем:

acton up

Как будет работать Telegram Wallet?

Обычный кошелёк в Тоне - это программа, навсегда зашитая в конкретный адрес.

V3, V4 и V5 отличаются кодом, форматом данных и интерфейсами. Чтобы перейти на следующую версию, пользователю фактически нужно задеплоить новый контракт, получить новый адрес и перенести туда активы. Старый V4 не превратится в V5 после обновления клиента - код аккаунта уже находится в блокчейне и останется прежним.

Создание нового кошелька, миграция всех активов и запись новой мнемоники - сложная для юзера операция (+помним про сбт). Даже спустя два года после релиза V5, только ~25% кошельков перешли на эту версию, против ~50% на V4.

У Telegram Wallet другой стиль, архитектура без painful migrations.

Валидаторы приняли пропоузал о добавлении нового отрицательного параметра config[-123]. Внутри него лежит ячейка с кодом контракта TgWallet (не либа или хэш, именно полный код). То есть реализация кошелька теперь хранится там же, где адреса системных контрактов, настройки консенсуса и другие параметры, изменяемые голосованием валидаторов.

Как это работает?

При создании кошелька на адрес пользователя будет деплоится не полный код, а небольшой неизменяемый контракт-трамплин. При получении любого сообщения он достаёт актуальный код кошелька из config[-123] и передаёт ему управление.

Из этого следуют несколько интересных свойств:

• адрес кошелька не меняется при обновлении логики
• пользователю не нужно создавать новый кошелёк и переносить туда свои ассеты
• сторадж фи платятся только за небольшой код трамплина
• старые данные остаются в каждом юзер контракте и при необходимости лениво мигрируются при первой валидной операции

При этом сам трамплин остаётся неизменным. Его ончейн код хэш не обновляется, он всегда исполняет код, находящийся в config[-123].

Так Telegram Wallet - обновляемая через консенсус часть инфраструктуры TON.

Код: https://github.com/ton-blockchain/tg-wallet-contract

Следить за прогрессом очень интересного пропоузала можно на https://vote.lagus.cooking

https://t.me/durov/533 👀🤫

Два месяца назад мы релизнули Acton v1.0 и v1.1 через пару недель. За это время было 2k+ уникальных установок cli, мы раздали 2000 грам через фасет за >1k реквестов и репозиторий получил 400 звёзд 🗣🗣🗣

Многие продуктовые команды в экосистеме начали использовать Acton в своих процессах разработки, также приятно видеть адопшен и в опен-сорсе:
• SekaiCTF с Acton таской на Тоне
• Permissionless zk от @resistortools
• Chainlink бридж

Следующие шаги - дальнейшнее развитие тех идей которые были заложены в мае.

Появившееся на релизе ABI сейчас используется только локально, для генерации враперов и парсинга сообщений. Мы хотим сделать его экосистемным стандартом описания всех интерфейсов для контрактов, заменив в этом TL-B. Таким образом любой разработчик сможет сделать распознаваемые всеми эксплорерами/апишками/кошельками контракты через децентрализованный верифаер, без пр-ов и апрувов от кого-либо. Другие разработчики смогут также дергать типизированные гет методы и писать коннекторы используя ABI.

Другое направление фокуса - локальная headless нода, симулятор реальной сети, аналог ganache/anvil для Тона. Она позволит без долгого сетапа у себя в окружении запускать и тестировать весь стэк dapp приложений - от контрактов до UI и индексеров.

Также мы работаем над developer-first эксплорером, который можно будет поднимать локально для работы с ABI и time-travel дебага трейсов из реальной сети.

Если вы пользовались Актоном или в целом писали контракты на Тоне в последнее время, то можете поделиться фидбэком в комменты, например что круто 🚀 или чего не хватает🥀

Я пришел в Тон экосистему летом 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, 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.

Прямо сейчас в мейннете идет голосование изменение 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

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

Channel photo updated

Channel created