Дневник TON разработчика

🤑 Интерфейс Telegram Wallet

Интересно, добавится ли в будущем p2p?

@dnevnik_ton

✈️ Telegram Wallet: возрождение

Многие заметили, что @wallet убрали из меню настроек в Telegram, а сам Wallet переименовали в Walt. И этому есть объяснение: прямо сейчас есть новый пропоузал в мейннете, который обновляет ячейку конфига -123 с кодом нового вида кошелька.

Telegram Wallet решает одну из самых неприятных проблем обычных TON-кошельков — миграцию при обновлении,

В классическом TON, кошелёк — это смарт-контракт, код которого навсегда привязан к адресу. V3, V4, V5 — это разные версии контрактов. Если нужно перейти на новую логику, фактически приходится создавать новый кошелёк и переносить туда активы.

У Telegram Wallet архитектура интереснее.

В TON появился специальный config[-123], куда валидаторы записали полный код TgWallet. А на самом адресе пользователя находится небольшой неизменяемый контракт-трамплин 🙃

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

💪 Получается довольно мощная конструкция

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

То есть Telegram Wallet по сути отделяет адрес и состояние пользователя от логики кошелька.

Самое интересное здесь даже не Telegram, а архитектурный подход: кошелёк становится обновляемой частью инфраструктуры TON, а не одноразовым контрактом, который нужно заменять при каждом серьёзном изменении.

Исходники TgWallet и WalletTrampoline.fif открыты:

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

@dnevnik_ton

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

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

Поэтому я решил разделить эти направления.

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

При этом из TON я никуда не ухожу 🤝

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

И да, где-то внутри меня всё ещё живёт маленькая вера в то, что у TON будет своя prime era.

Ещё повеселимся 🫡

🤑 Казалось бы, что сложного в ставке на событие?

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

Но иногда открываешь задачу, смотришь на нее и думаешь: «Ну, здесь вроде ничего сверхъестественного».

Так было с одним из проектов, где нужно было сделать смарт-контракт с механикой, похожей на Polymarket.

Есть событие. Пользователи выбирают исход и вносят деньги. Событие заканчивается — определяется победивший исход, после чего участники получают свой выигрыш.

На бумаге – несколько понятных действий.

А потом начинаешь проектировать это в TON.

И вот здесь начинается самое интересное.

TON работает на акторной модели, поэтому привычная логика «есть один контракт, у него есть общее состояние, сейчас мы его изменим, потом посчитаем всё остальное» уже не работает так, как привыкли многие разработчики.

Состояние распределено. Контракты взаимодействуют сообщениями. Операции становятся асинхронными. Нужно заранее думать не только о том, что должно произойти, но и о том, какие сообщения, в какой последовательности и между какими контрактами должны пройти, чтобы система пришла в нужное состояние.

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

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

Самая сложная часть — правильно разложить саму бизнес-логику на взаимодействия между акторами.

Это хороший пример того, почему опыт в блокчейне — это не только знание языка или умение написать очередной smart contract.

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

И, пожалуй, именно такие проекты я больше всего ценю в своем опыте работы с TON.

Потому что после них ты уже не просто знаешь, как написать контракт.

Ты лучше понимаешь, как думать о системе целиком.

@dnevnik_ton

Создаем голосового ИИ-менеджера для автомобильной компании. Он и машину подберет, и шутку расскажет и квалифицирует клиента в CRM 🙂

@dnevnik_ton

Первый пост в таком формате. Как вам?

Мне интересно, кто-то и вправду берется за такие заказы? 🐰

Цифровой рубль. Ваше мнение?

Интересное: OpenAI нашла признаки того, что и другие агенты компании могли выходить за пределы изоляции во время испытаний.

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

Просто выполняет задание. Просто взламывает чужие серверы. Просто очень старательно выполняла задачу и устроила армагеддон.

@lobushkin

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

Человек делает это каждый день: автоматизирует рутину, ищет лайфхаки, сокращает шаги.

Агент делает то же самое. Только у него нет интуитивного понимания «а вот это уже перебор».

Мы даем ему все больше инструментов, доступов и автономности. И многие уже выбирают режим: «подтверждать действия без уведомлений», потому что иначе агент постоянно спрашивает разрешение.

Но в этом и парадокс: чем удобнее становится агент, тем больше мы передаем ему право принимать решения.

Он не пытается стать свободным. Он просто очень хорошо оптимизирует поставленную задачу.

А вопрос уже не только в том, насколько умный ИИ, а в том, насколько хорошо мы научились ставить ему ограничения.

@dnevnik_ton

Что такое MCP? // Часть 1

Большинство людей до сих пор используют ИИ в формате: открыл чат → задал вопрос → получил ответ

Но сейчас появляется другой подход: ИИ начинает работать напрямую с вашими данными и инструментами.

Для этого существует MCP (Model Context Protocol) – стандарт, который позволяет подключать к моделям внешние источники данных и сервисы.

Есть два основных типа:
• Local MCP – сервер работает локально и дает доступ к вашим файлам, базам данных и приложениям на компьютере.
• Remote MCP – подключается к внешним сервисам: GitHub, Notion, Google Drive, Jira, CRM и другим.

Один из самых простых примеров – Filesystem MCP.

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

Добавляем MCP-сервер:

{
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-filesystem",
    "~/Documents/Obsidian"
  ]
}

Вместо ~/Documents/Obsidian указываете путь к своей папке Obsidian.

После этого можно работать с вашей базой знаний:

Что я писал про Redis Streams?

Собери все мои заметки по AI в одну статью.

Какие идеи по стартапу я записывал в прошлом месяце?

Создай новую заметку на основе этих мыслей и добавь связи с существующими.

Получается, ваша база знаний становится доступной прямо из Cursor или другого AI-инструмента. Не нужно вручную искать информацию – модель сама находит нужные данные и работает с ними.

И это только один сценарий.

Через MCP можно подключать базы данных, GitHub, Notion, Figma, Docker, Supabase и множество других инструментов.

Каталог готовых MCP-серверов для Cursor:
https://cursor.directory/plugins/filesystem-mcp

@dnevnik_ton

Grok 4.5: новая frontier-модель, которая бьёт по цене и скорости

Сегодня SpaceXAI (бывший xAI) вместе с Cursor выпустили Grok 4.5 – самую умную модель в линейке Grok. Её тренировали не только на коде, но и на STEM, research и knowledge work.

Что умеет Grok 4.5
- Сложный engineering: от Rust/C++ до приложений «из одного промпта»
- Agentic workflows: исследует проблему, вызывает tools, откатывается от ошибок, проверяет результат
- Office-задачи: Excel, PowerPoint, Word — и #1 на Harvey Legal Agent Benchmark
- Скорость ~80 TPS и ~2× выше token efficiency, чем у конкурентов на тех же задачах
- Цена: $2 / $6 за 1M input/output токенов (fast-вариант — $4 / $18)


Сравнение с Claude Opus и GPT-5.5
• Claude Opus 4.8 — всё ещё эталон для тяжёлого кодинга и работы с документами. На SWE-Bench Pro и сложных рефакторингах часто впереди. Минус — дороже и медленнее по токенам.

• GPT-5.5 — лучший «универсальный агент»: terminal-автоматизация, tool-calling, экосистема ChatGPT/Codex. Если нужен надёжный multi-step агент в DevOps — часто выбор №1.

• Grok 4.5 заходит с другой стороны: близкий (или выше) уровень на real engineering при в разы меньшей цене и заметно меньшей трате токенов. По заявлениям SpaceXAI — ~4× меньше output-токенов на SWE-Bench Pro vs Opus max. Плюс совместный тренинг с Cursor: модель заточена под реальную работу в IDE, а не только бенчмарки.

Кому что брать
• Код + качество ответа важнее всего → Claude Opus
• Агенты, shell, широкий стек OpenAI → GPT-5.5
• Много задач, бюджет и latency → Grok 4.5

Один победитель «вообще» уже не существует. В 2026 выбор – это маршрутизация: Opus на сложный PR, GPT на terminal-агента, Grok на объём и скорость.

Grok 4.5 интересен тем, что впервые у SpaceXAI модель реально претендует не на «дешёвую альтернативу», а на место в тройке frontier – с ценой, от которой Claude и GPT выглядят премиум-сегментом.

@dnevnik_ton

🤝 Полезный тул для реверс-инженеринга TON-контрактов

Если вы разбираете TON-смарт-контракты, обязательно зацените TVM Retracer. Это браузерная утилита, которая позволяет проигрывать транзакцию шаг за шагом и смотреть, что происходит внутри TVM на каждом этапе исполнения.

Самое удобное — можно не просто увидеть результат, а буквально проследить, как контракт к нему пришел: какой был стек, какие шаги выполнялись, какие метаданные и логи появились по ходу транзакции. Для реверса и аудита это очень мощная штука: вместо догадок у вас есть наглядная трассировка исполнения.

😏 Что особенно полезно
• пошаговый разбор транзакции,
• просмотр стека на каждом шаге,
• навигация по предыдущим и следующим шагам,
• метаданные исполнения, комиссии и балансы,
• executor logs и C5 actions.

По ощущениям, это почти debugger в браузере для TON. Особенно выручает, когда контракт ведет себя не так, как вы ожидаете, и нужно понять, на каком именно шаге все сломалось.

Если вы работаете с jetton-логикой, сложными message flow или просто хотите лучше понимать TVM, очень советую держать этот инструмент под рукой.

TVM Retracer

@dnevnik_ton

🌀 Лайфхак для TON-разработчиков: как достать код и данные любого смарт-контракта

Не все знают, что получить code и data уже задеплоенного контракта в TON можно буквально в несколько строк.

На примере Jetton Master:

const jettonMasterAddress = await ui.inputAddress("Jetton Master");
const jettonMasterState = (await provider.getContractState(jettonMasterAddress)).state;

if (jettonMasterState.type != "active") {
    console.error("Jetton Master is not active");
    return;
}

const jettonMasterCode = Cell.fromBoc(jettonMasterState.code!)[0];
const jettonMasterData = Cell.fromBoc(jettonMasterState.data!)[0];

Что происходит:
• getContractState() получает текущее состояние контракта из блокчейна.
• state.code — сериализованный BOC с кодом смарт-контракта.
• state.data — BOC с данными (storage) контракта.
• Cell.fromBoc(...)[0] преобразует BOC обратно в Cell, с которой уже можно работать: парсить, сравнивать, дизассемблировать или использовать в тестах.

🔥 Такой прием полезен, если вы хотите:
• проанализировать чужой контракт,
• сравнить код после обновления,
• получить storage для дебага,
• написать тесты на основе реального состояния сети.

Этот способ работает не только с Jetton Master, а практически с любым активным TON-контрактом.

@dnevnik_ton