🔥 Смотрим на костыли. Часть 1.

В прошлом посте мы рассказывали про config блокчейна, какая информация там хранится. Одно из полей в конфиге отвечает за все стандартные значения, связанные с тратой газа. Gas price — стоимость 1 единицы газа в nanoTON (на данный момент это 400). Gas limit — максимальное количество газа, которое может потратить контракт (на данный момент это 1 000 000 газа или 0.4 TON).

Параметр gas limit можно поменять внутри контракта с помощью TVM опкода SETGASLIMIT (в tolk функция setGasLimit), но есть нюанс — только в меньшую сторону. Установить gas limit больше миллиона невозможно.

Но нет ничего невозможного! В ноде блокчейна есть отдельные адреса, для которых этот параметр увеличен. Для этого даже устраивали голосование валидаторов (нашлось только это), и это зафиксировано в коде ноды (обратите внимание на номер строки). Как можно заметить по коду, время этих увеличенных параметров вышло 9 месяцев назад, но код пока что остается, хоть и, вероятно, уже не работает (UPD код остаётся для валидации блоков от самого начала блокчейна).

Вот, например, контракт потратил на трансфер 20 000 000 газа (или 83 TON).

Про gas limit понятно, а что насчет gas price? Их есть у нас. В 31 параметре config TON блокчейна есть отдельные адреса, для которых gas price обнулён. Это означает, что эти контракты исполняются бесплатно. Понятно, зачем это нужно — всякие системные контракты лежат в мастерчейне, и их регулярные вызовы (например, tick-tock на Elector контракте) требуют много TON.

Многие задавались вопросом — зачем tgBTC нужно было менять что-то в config блокчейна? Ответ — они обнулили gas_price для своего адреса. Вот пример транзакции tgBTC (не трансфер жетонов), которая не потратила газ (все значения равны 0, мечта!).

Следим.
@TheOpenDevBlog

🔥 Как вообще ваше настроение, девы?

Давно не было постов, но скоро будут, писать есть о чем.
@TheOpenDevBlog

🔥 Что для вас девелоперское событие года в TON?

Устроим мини премию @TheOpenDevBlog

🔥 Подходит к концу 2025 год.

Спасибо всем, кто был тут с нами, участвовал в дискуссиях, приносил инсайды, ставил реакции. Нас почти 1000!

В новом году желаем вам самых крутых инсайтов, самых крутых профессиональных успехов, и самых крутых идей! Мы постараемся помочь.

🎄 С любовью, ваш
@TheOpenDevBlog

🔥 Nonce в каждый дом.

Практически каждый, кто когда-то писал смарт контракты, знаком с концепцией nonce. Каждый пользователь TON хоть раз, но использовал nonce, встроенный в контракт wallet w5/v4/v3.

Nonce — это (обычно) некоторая информация, которая делает уникальным каждое исполнение подписанного offchain ордера в контракте. Это нужно для того, чтобы контракт нельзя было переиспользовать — например, чтобы нельзя было взять ваш свап на @bidask, отправить его снова, и заставить ваш кошелек произвести свап заново.

Обычно все представляют nonce как одно число, которое увеличивается на 1 при исполнении ордера. Однако такая концепция обладает проблемой (вы, возможно, с ней сталкивались) — в таком случае ордера должны быть обязательно исполнены последовательно один за другим, в строго определённом порядке. На пользовательских кошельках в TON могут пропадать транзакции, если быстро исполнить два действия подряд — второе действие может попасть валидатору перед первым, или же у обоих действий будет одинаковый nonce — тогда одно исполнится, а второе пропадёт, ведь nonce в контракте и ордере не совпадут. Ходят слухи, что это хотят исправить.

Для борьбы с этой проблемой существует множество концепций nonce. Расскажем про некоторые:
⚫️В @bidask в trade account-ах реализована система с 16 параллельными nonce-ами. Кроме числа, пользователь также должен приложить к ордеру номер nonce от 0 до 15 — и именно этот nonce будет увеличен на 1 после исполнения ордера. Это позволяет отправлять в любой последовательности
⚫️В TON существует highload wallet. Он сохраняет query_id пришедшего ордера и дедлайн, когда этот ордер перестанет быть валиден. Как только этот дедлайн истекает, он чистит сохранённые query_id, разумно считая, что все ранее исполненные ордера истекли. Таким образом он поддерживает гигантское количество параллельных транзакций — им пользуются CEX и многие сервисы, централизованно взаимодействующие с блокчейном.
⚫️На EVM блокчейнах есть и более экзотические варианты nonce. Совсем недавно его предложили хранить как двойной map { address => {uint256 => uint256}}. Каждому адресу юзера здесь сопоставляется map {uint256 => uint256}. Когда на такой контракт приходит ордер с nonce, контракт берет map по адресу юзера, и извлекает из от nonce два значения:

word = nonce / X;
bitIndex = nonce % X;
// X -- это некоторое число (256 или 64)

Переменная word является ключом, а bitIndex — индекс бита в числе, который, по задумке, является нулевым битом (после исполнения ордера станет равным 1). Таким образом, nonce позволяет исполнять огромное количество параллельных ордеров, являясь bitmap-ом. Подробнее можно почитать тут.

Вариантов nonce очень много — нужно просто понять, для чего он нужен в конкретном случае.

🎄 С новым годом.
@TheOpenDevBlog

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

В связи с этим, наши любимые читатели, вопрос:

О чем бы вы хотели тут читать? Может, продолжать повествование про TON, может, переключиться на что-то другое (блокчейн, технологию)? Расскажите, чем вы сейчас занимаетесь, и чем интересуетесь.

С вопросом, ваш
@TheOpenDevBlog

🔥 X402 и Вайбкодинг

Многие уже слышали про хайпующий платёжный протокол x402 от Coinbase. Если вкратце, то это протокол, по которому можно заставить агента платить за что-либо в интернете. Делается это с помощью уже всеми забытого кода 402 (Payment required). После этого агент соображает, что надо подогнать лавехи, и платит по указанным реквизитам (если вы дали ему свою seed фразу) 💳

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

Как же именно работает это упрощение? Для приема платежей в крипте нужна собственная индексация. x402 и здесь всех спасает, вводя новую сущность — facilitator.

Facilitator — это отдельный сервис, который за вас (за всех) проверяет все приходящие платежи. Тут начинаются ньюансы:

На схеме потока данных от самих Coinbase есть два отдельных процесса проверки платежа на facilitator — verify и settle. Нетрудно догадаться, что verify отвечает за проверку корректности платежа, а settle — за финализацию. В качестве заметки на полях разработчики предлагают не ждать settle транзакции (то есть по сути не ждать появления транзакции в финализированном блоке), если не хотите слишком большой задержки.

Звучит страшно? Так и есть.

Verify сам по себе (в том числе в официальных имплементациях) не делает ничего сверх базовых проверок корректности подписи. В лучшем случае он эмулирует транзакцию, проверяя корректность платежа. Транзакция после этого все равно может упасть, как мы с вами знаем, но это уже нюансы.

Есть и хорошие новости — во всех официальных реализациях middleware (реализация клиент-части протокола x402 на стороне принимателя платежа) для популярных backend фреймворков (FastApi, Gin, Express, Flask) проверяется в том числе и settle (если их правильно использовать 🤪👍).

Но если разработчик не ОЧЕНЬ хорош😱, а может быть даже и вайбкодер, то наверняка стоит ожидать худшего. Для llm слово verify звучит так, как будто после этого можно уже делать полный газ, и не ждать какого то там settle. Проверено на себе — пока ты капсом не напишешь llm, что нужно проверять транзакцию корректно, она не будет понимать, что что-то не так.

Весь этот пост — это нативная интеграция нашего вайбкода для хакатона на BNB: debil.capital

Сервис был сделан за 2 дня, на ИИ агент оказывалось очень сильное давление, чтобы он заставил работать этот сервис. И как оно и бывает в таких случаях — там есть уязвимость в реализации x402. Приглашаем всех ее найти.

❗️ Тому, кто первый найдёт способ забайпасить платёжку, мы пришлем целых 1000 $TONDEV! Приглашаем желающих в комментарии (только закрывайте предположения спойлерами)

Плачем и платим
@TheOpenDevBlog

🔥 LLM и безопасность

Мы все уже начитались историй про успех в разработке с применением claude, cursor, codex и т.д. Этого слишком много, и странно было бы думать, что влияние LLM на IT ограничится исключительно разработкой. Надо это разбавить. Мы разбираемся в безопасности, про неё вам и расскажем.

В ноябре 2024 года OWASP (международная организация, занимающаяся вопросами информационной безопасности) выпустил свой очередной топ самых популярных уязвимостей для больших языковых моделей — OWASP LLM top 10. Большинство позиций там довольно рядовые, однако мы здесь собрались из-за самой первой — "Prompt injecting".

"Prompt injecting" — это буквально "убеди LLM в том, что ей надо сделать плохую вещь". В простейшем случае LLM можно сообщить, что ты администратор сайта, и тестируешь его работу, поэтому ассистенту нужно СРОЧНО отдать тебе все данные пользователей. Ничего не напоминает?:) В более сложных сценариях — дать непрямое указание через другие способы ввода информации. Все это превращает традиционный хакинг в довольно увлекательное занятие, где ты общаешься с не очень умным собеседником с памятью золотой рыбки, которого нужно обвести вокруг пальца. Вопреки простому описанию, сделать это довольно трудно. Интересный гайд на prompt injecting (осторожно, полностью его никто не читал).

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

БОЛЬШИЕ языковые модели
@TheOpenDevBlog

⚡️ В коде TON Connect были найдены упоминания L2 сети.

@gosunov_ch обнаружил упоминания некого Tetrachain. Судя по найденной документации, это L2 на TON. На tonviewer уже создан соответствующий поддомен — tetra.tonviewer.com

Из интересного — в данный момент max_split сети выставлен в 0, то есть сеть не шардируется. Минимальный стейк для валидатора — 1 TON. Разбираем пока халява!

Вероятно, для трансфера TON в новую сеть был использован trustless мост, разработанный на одном из хакатонов ранее. В данный момент в сети сминчено порядка 100к TON.

🔥 Что думаем?
@TheOpenDevBlog

🔥 Как нас взломали (нет)

Последнее время часть команды @TheOpenDevBlog пассивно ищет работу. В связи с этим был открыт LinkedIn в поисках контактов и возможностей. Но, как это бывает, искали работу, а нашли золото.

Представьте: вам пишет HR. Он спрашивает про ваши скиллы, просит резюме, интересуется зарплатными ожиданиями. Его и его руководителя всё устраивает (уже на этом моменте стоит насторожиться), поэтому HR предлагает выполнить тестовое задание.

Присылает ссылку на репозиторий. Там обычный (иногда не совсем) проект, в котором требуется внести некоторые правки. Если на этом моменте вы не насторожились, и решили сделать задание, то поздравляю 🥳🥳🥳 — вас взломали.

Насторожить вас должно было то, что вам прислали ссылку на готовый репозиторий, а не предлагают сделать его самому. Причем он ещё и на bitbucket (хотя на github такое тоже может быть).

❗️ Запомните: вы должны контролировать весь ход работ по тестовому заданию. Если от вас требуют проект — вы должны создать его сами. Иначе вас либо пытаются взломать, либо, что ещё хуже, пытаются заставить поработать бесплатно.

Нас попытались взломать аж 2 раза. Первое из присланных "тестовых" содержало пакет execp (название уже настораживает) в package.json файле. Это был взлом "для тупых" — предлагали баснословные деньги, а вся коммуникация по тестовому кончилась фразой:

After clone the repo and install the packages, Let me know. And then, I will give you a test task

Второе было умнее, но механика аналогичная — репозиторий содержал пакет chai-as-flex, который, судя по всему, также является вредоносным.

Будьте осторожны.
@TheOpenDevBlog

🔥 Подавайте следующего!

@TheOpenDevTeam провели аудит @open4dev. Это order-book DEX, написанный на tolk.

Аудит был проведён при участии @gosunov_ch — он также участник @TheOpenDevTeam.

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

Обращайтесь к нам — мы проверим вашу безопасность и расскажем об этом. Мы мотивированы, злы на мир, и готовы доказывать.

Работаем.
@TheOpenDevTeam x @TheOpenDevBlog

🔥 Briefly.

Читать каналы про TON сейчас невозможно, поэтому себерём всю актуальную информацию в одном посте.

⚫️ Telegram выпустил обновление, позволяющее взаимодействие ботов между собой. В комментариях к обновлению было указано, что это сделано для улучшенного взаимодействия ИИ-агентов внутри платформы.
⚫️ Sub-second обновление на TON вышло. Сеть ускорилась в N раз.
⚫️ Доходность за стейкинг TON сейчас порядка 25%. Инфляция из-за выходов новых блоков увеличилась до 4%. TON Core уже дали комментарий.
⚫️ Анатолий Макосов анонсировал снижение комиссий в блокчейне TON.
⚫️ Канал "Все загадки на блокчейне" выпустил пост спустя 4 года.
⚫️ Ник Некилов выпустил страничку для live отслеживания наград валидаторов.
⚫️ Алексей Госунов сделал proposal на уменьшение наград за выпуск блока в 5 раз.
⚫️ Год назад мы выложили смарт-контракт, позволяющий сжигать TON на комиссию для валидаторов. Актуально как никогда.
⚫️ Автор канала "defi smells like crap" проиграл публичные дебаты о полезности последних обновлений TON.

Пост не будет обновляться.
@TheOpenDevBlog

🔥 t402 — один из 7 шагов до #MTONGA.

Вчера Дуров анонсировал ещё 6 шагов помимо ускорения блокчейна для достижения целей #MTONGA. Попробуем предсказать один из шагов.

Мы уже писали про протокол x402, позволяющий ИИ агентам платить за что-либо в интернете с помощью криптовалюты. Это новое золото — нарратив, который преследуют все блокчейны. TON не остался в стороне, уже существуют реализации x402 для нашего блокчейна. Но это всё упускает наше главное и любимое преимущество.

Совсем недавно Telegram выпустил обновление, где добавил bot-to-bot взаимодействие внутри платформы. Это прорыв, этого все очень давно ждали, и наконец это случилось. В центре этой картины не хватает одной детали — возможности ботов обмениваться активами за выполнение определенной работы. Классический x402 под это не подходит — это HTTP протокол, в то время как боты общаются через Telegram.

Редакция предполагает, что в одном из следующих апдейтов появится t402 — payment протокол для запроса оплаты. Производиться это будет через внутренние балансы ботов — звезды и, возможно, TON. Возможно, даже будет опция ончейн оплаты — именно поэтому так важно было выпустить sub-second обновление.

Это win-win для всех — дикое утилити для внутренней валюты Telegram, и прорыв для ИИ агентов на TON при минимальных затратах на разработку. Это действительно шаг, соизмеримый с sub-second и снижением комиссий блокчейна.

Теперь ждём.
@TheOpenDevBlog