🔥 Поделитесь: с какой болью вы встречались как разработчик при взаимодействии с контрактами в сети TON?

Что угодно — кривой интерфейс, контракт не отдает какую-то информацию, etc.

🆘 Делимся.

🔥 Cell-библиотека.

Одной из скрытых от глаз простого копеечного разработчика механик являются library cell-ы. Возможно, вы замечали, что, например, у jetton wallet USDT подозрительно маленький код, вряд ли такой контракт может поместиться в 1023 бита одного cell-а. Для того, чтобы так сделать, используются library cell.

Представьте себе всю информацию в блокчейне TON. В нем, например, находятся 3 миллиона кошельков USDT, или 50 пулов ликвидности @bidask. При трансфере жетонов jetton-wallet обязательно деплоит свою копию, принадлежащую другому адресу, то есть посылает свой код, чтобы блокчейн опубликовал его на новом адресе. Таким образом, если бы код USDT был обычным, то в блокчейне произошло бы как минимум 3 миллиона трансферов с одинаковым кодом jetton-wallet-а, что потратило бы немало forward fee.

Чтобы сократить forward fee для повторяющихся данных, в TON реализована система library cell-ов. Это возможность опубликовать cell с каким-то содержимым в мастерчейне, чтобы ссылаться на него из своих контрактов. Это полезно в случае, если вы часто шлёте этот cell в сообщениях (как раз как в случае с жетон трансферами). Таким образом, каждое ваше сообщение сокращается в размерах, что приводит к уменьшению forward fee.

Если library cell поставить в код адреса, то при вызове контракт будет разыменовывать ссылку на ячейку, которая лежит в мастерчейне. Каждый вызов адреса с кодом в library cell будет забирать меньше storage fee, ведь код контракта сократится до одной ячейки. Хороший пример — опять жетоны.

За всё надо платить, поэтому в качестве компенсации вам нужно оставить TON для storage fee за хранение данной ячейки в masterchain. Это дороже, чем хранить 1 контракт в basechain, но гораздо, кратно дешевле, чем 3 миллиона контрактов, или же если посчитать экономию на жетон трансферах. ❗️ Однако будьте осторожны — если вдруг storage fee превысят баланс контракта, на котором задеплоена либа в мастерчейне, то можно будет прислать сообщение с маленьким количеством TON, и контракт с либой заморозится, а всё, что использует данный library cell, может перестать работать. В такой ситуации задеплойте ту же самую либу с другого адреса, и всё заработает заново.

Подробнее про library cell можно почитать в офф документации. Примеры использования — в новоиспеченном jetton 2.0. Совсем недавно Ton Tech добавило поддержку публикации либ в sandbox, но, к сожалению, пока не добавила поддержку их удаления (да, их и удалять можно).

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

Library cell-ы крайне рекомендуется использовать в жетонах, а также всём, что вы можете часто деплоить. Удачи!

@TheOpenDevBlog

🔥 "New Bounce Message Format" — что это?

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

Для начала немного базы.

Bounce-сообщения — это механизм в TON, который призван возвращать TON отправителю при ошибке в исполнении смарт контракта. Например: вы пытаетесь послать 10 жетонов, а у вас их всего 9. Чтобы ваши TON не застряли на jetton wallet, после ошибки они возвращаются вам на кошелек.

Сейчас bounce-сообщение несёт за собой специальный опкод 0xffffffff, а также 256 бит оригинального сообщения, после которого случилась ошибка. Это очень мало (например, адрес в TON весит 267 бит), поэтому практически ни для чего дельного использовать bounce-сообщения нельзя.

Окончание базы.

Совсем недавно был опубликован proposal, который вводит новую систему bounce-сообщений. Новый формат позволяет вернуть на контракт-отправитель оригинальное сообщение, чтобы обработать ошибку, и совершить какое-либо действие с дополнительными данными. Новая система позволит узнавать коды ошибок, из-за которого произошёл bounce, и много разной информации, недоступной ранее (например, сколько газа потратил контракт прежде, чем выкинуть ошибку — непонятно, для чего кому-либо эта инфа, но вдруг понадобится). Новые bounce-сообщения будут нести опкод 0xfffffffe.

Это важное изменение, поскольку оно открывает возможности для более эффективного межконтрактного взаимодействия. Например, сегодня один из наших авторов обсуждал возможность использовать подобную систему при взаимодействии с нестандартными jetton wallet-ами. Это также избавит нас, разработчиков, от необходимости регулярно избегать выкидывания ошибок. Круто.

Изучаем.
@TheOpenDevBlog

🔥 Поднять щиты!

Недавно популярный блогер overbafer1 выпустил ролик про "безопасность" сайтов, связанных с TON.

Вообще, стоит сказать, что в тусовках безопасников overbafer1 — это своеобразный мем. Все его когда-то смотрели, каждый когда-нибудь нет-нет да и да, ломал свой WI-FI по его гайдам, но как только соприкасаешься с реальной безопасностью, находишь работу, то стараешься всячески откреститься от этого опыта, он стыдный. Таких, как overbafer1, среди профессионалов в сфере безопасности называют "script kiddie". На личности уже перешли, теперь давайте по сути. Разберем, кто ведущий эксперт, а кто ведомый.

Видео разделено на две части. В первой из них overbafer1 показывает действительно рабочий хак, называющийся IDOR (Insecure Direct Object Reference), когда, обладая некоторой незначительной информацией (например, telegram id пользователя), можно посмотреть данные об его аккаунте в игре. Уязвимость реальная, хоть зачастую и low приоритета, но стоит понять специфику индустрии. Блокчейны как таковые строятся на том, что IDOR — это корректное поведение программы. Блокчейн отличается от банка тем, что банк не покажет ничью историю транзакций, кроме вашей, тем временем в блокчейне видно всё. Багу в игре нужно фиксить, но ее не стоит переоценивать. Тем более если приложение в бета тестировании.

Во второй же части блогер проводит "сканирование" сайтов, связанных с TON, автоматической тулзой, и показывает шокирующие результаты. На экране написано, что, например, у сайта ton.org 9 critical уязвимостей. Вкратце — это просто ничего не значащая липа. Автоматические инструменты для сканирования безопасности в 99% случаев выдают false-positive результаты, когда проверка на что-то сработала, но по сути никакого влияния на бизнес процесс не было и не будет оказано.

В ролике overbafer1 показывает результаты сканирования и там часто мелькает термин "CVE". Что это такое? CVE — это аббревиатура, которая расшифровывается как Common Vulnerabilities and Exposures. Это реестр уязвимостей, найденных в каком-либо софте, подтвержденных разработчиками этого софта. При занесении в реестр CVE присваивается severity (критичность) от 0 до 10.

Если сканер указал на CVE — это ещё не означает, что уязвимость есть. Это означает, что где-то в использующемся на сайте фреймворке, продукте и т.д была найдена какая-то уязвимость. Это совершенно не означает, что уязвимый сегмент кода используется на сайте, ведь это может быть, например, платежный модуль, а на сайте ton.org нет никакой платежки. И абсолютно не зря блогер показал одну реальную уязвимость минут за 10, и в часовом ролике не нашел времени показать какую-либо другую, предложив подписчикам "самим проэксплуатировать уязвимости на сайте".

За сайтами вроде ton.org или fragment.com ежедневно наблюдают десятки потенциальных злоумышленников. Любой, кто хостил сайт и смотрел в логи, замечал, что даже на самом ненужном никому домене проводится по 1-2 скана за сутки от неизвестных ботов. И уверяем, каждый из этих сканов покажет существование в приложении CVE.

Забавно, что в тг канале утилиты, которую использует блогер, есть, например, скан Пентагона, где было найдено 6 critical CVE. То есть наш родной ton.org всего на 30% слабее Пентагона.
Это выход на рынок США?????

Если вам нужна реальная безопасность, а не галочка от сканера — обратитесь к нам. Мы готовы сделать аудит любого формата.

Не ведитесь.
@TheOpenDevBlog x @bidask

🔥 @bidask будет кормить ВСЕГДА

Среди пользователей гуляет миф, что если в пуле концентрированной ликвидности увеличится TVL, то APY в нём уменьшится. Не раз и не два раза уже это слышим от различных представителей экосистемы. Это не так, давайте это разберём.

Для начала надо понять, откуда вообще APY в концентрированной ликвидности? Основные объемы высоколиквидных активов на DEX к стейблкоину (например, TON/USDT) — это всегда арбитраж. Арбитраж существует, пока для него существуют "арбитражные окна" — это возможность "купить подешевле, продать подороже". В контексте арбитража на @bidask — это значимое отличие от цены на CEX. То есть арбитражное окно существует, пока цена на DEX отличается от цены на CEX (математика чуть сложнее, потому что на DEX ещё существует комиссия провайдеров ликвидности, но это не влияет на рассуждение), и арбитражник может купить на @bidask, а продать на Binance, и получить с этого выгоду.

Для того, чтобы цена на @bidask двигалась, нужно свапать в нужную сторону: буквально "докладывать" в пул один актив, а второй "вынимать". Это означает, что если между нынешней ценой и ценой на CEX есть ликвидность, то она вся будет просвапана в угоду арбитражу, и абсолютно вся получит процент за предоставление ликвидности. При этом объем арбитража будет ровно таким, чтобы просвапать ликвидность от текущей цены до цены на CEX. Таким образом, если TVL в этом диапазоне цены увеличится в 10 раз, то и объемы арбитража тоже в 10 раз вырастут. А значит, и вырастут собранные fees.

Главный смысл концентрированной ликвидности, как это ни странно — в концентрации ликвидности. Именно благодаря этому объемы растут прямо пропорционально TVL в проходимом диапазоне. Каждый конкретный пользователь волен решать, расставлять ему ликвидность широко, более безопасно, и получать меньший процент, или узко, получая большой процент из-за лучшей концентрации ликвидности.

Разумеется, если залить ликвидность далеко от активной цены, ваш APY будет целых 0% в наносекунду! Не надо так делать, если вы не знаете, как с этим можно работать.

В чем подвох? Подвох в том, что если завтра внезапно TVL пула TON/USDT увеличится настолько, что эта ликвидность начнёт влиять на цену даже на CEX (например, до 50 миллионов $), то APY пула действительно уменьшится, потому что эта ликвидность начнёт оказывает значимое давление на движение цены. Мы будем этому рады, а пока это не так — bidask.finance.

APY TON/USDT на @bidask — 50%.
Думайте.
@TheOpenDevBlog

🔥 Мы провели свой первый публичный аудит на TON для проекта WEB3 - webdom ончейн маркетплейса доменов и юзернеймов на TON.

Нашли 1 очень серьезную уязвимость, специфическую именно для TON, о которой обязательно напишем пост позже.

Обращайтесь.
@TheOpenDevTeam x @TheOpenDevBlog

🔥 Освещаем.

Наши дорогие коллеги из Torch finance принесли вкусное — они разработали единый стандарт vault-ов для TON-а. Всё на Tolk (пока только 1.0).

Данный стандарт призван упростить билдинг DeFi инструментов на TON, по аналогии с тем, как на EVM сетях есть куча open-source стандартов для задач разной сложности. Часто архитекторы в других сетях оперируют не кастомными решениями, а занимаются собиранием продукта из коструктора — готовых open-source стандартов, применимых в конкретной ситуации.

Сам vault представляет из себя контракт, принимающий на вход конкретный актив, и минтящий share — lp токены доли пользователя от общего размера vault-а.

Разработчик, кроме proposal, написал также еще и статью о стандарте, его возможных применениях, и назначении. Призываем всех разработчиков обратить внимание, а также посмотреть на сам код смарт-контракта в proposal — возможно, вы сможете что-то улучшить.

❗️ Мы уже говорили, и еще раз говорили, и еще раз скажем, что open-source — это то, что упрощает обмен опытом и онбординг в разработку. Нам нужны новые стандарты, open-source инструменты, блоги про разработку на TON. Если у вас это есть — делитесь!

Осветили.
@TheOpenDevBlog

🔥 До встречи на TOKEN2049 в Сингапуре!

Контакты в био канала.
@TheOpenDevBlog

🔥 На волне хайпа комиссионных жетонов разберёмся, как они работают.

Разбираться будем на примере нашумевшего $GIFTSTR. Он имеет комиссию на покупку и продажу себя. Как это реализовано?

Если посмотреть на транзакцию продажи, то там всё просто — при отправке жетонов с целью продать jetton wallet отправителя парсит свой forward_payload, и если находит там операцию продажи токена, отправляет 10% от депозита на jetton wallet команды. Это, к сожалению, ведёт к тому, что при неудавшемся свапе пользователь теряет 10% баланса. От этого крайне трудно избавиться, поэтому это не особо важно.

При покупке жетона всё сложнее. Когда мы продаем жетон, $GIFTSTR контролирует момент продажи, потому что он начинается с jetton wallet $GIFTSTR. При покупке же jetton wallet участвует только в конце, когда свап прошёл, и надо выплатить пользователю его жетоны. Поэтому самый простой способ проверять покупку — это проверять, что жетоны отправляются с адреса волта Dedust. И действительно — в такой ситуации jetton wallet отправляет 10% от полученного количества жетонов на кошелек команды.

Но у этого есть побочный эффект. Если выплата с волта Dedust происходит по иным причинам (например, вывод ликвидности), то пользователь тоже будет терять 10% от полученных токенов, хотя никакого свапа не произошло. Поэтому, несмотря на 100% APY на Dedust, класть ликвидность в $GIFTSTR — крайне сомнительная затея.

@TheOpenDevBlog

🔥 Про перпы, Storm trade, тяжелые времена.

Наверняка многие уже в курсе нового супер-скандала, где Storm trade ОБМАНУЛ и ЗАСКАМИЛ пользователя, написав в интерфейсе, что он в профите на десятки сотен процентов, а затем просто "закрыл позицию" без объяснения причин. Разбираемся, что произошло.

Что вчера случилось — на всех крупных рынках (в первую очередь CEX), вероятно, просто кончились лимитные заявки на покупку тона, именно поэтому "цена" на TON падала до 0.5$. Нужно понимать, что сама по себе без объёмов торгов эта цена мало что значит, вряд ли по ней было много спотовых сделок, однако как факт — маленький промежуток времени на рынке вполне можно было наблюдать практически пустой стакан.

Это означает две вещи:
⚫️ по такой цене нельзя было продать TON на большую сумму
⚫️ по такой цене нельзя было купить TON на большую сумму

После того, как MM проснулись, цена быстро ушла обратно ближе к 2$, и на момент написания поста уже вполне себе хорошо торгуется по цене около 2.2$.

Storm trade устроен иначе, не как CEX, — там нет стакана, нет в традиционном понимании лимитных заявок на покупку/продажу, там есть так называемый оракул (PYTH). В крайне упрощенном виде — это сервис, присылающий актуальные цены в блокчейн. На Storm trade в любой момент можно открыть любую позицию на любом рынке с любым плечом (главное, чтобы open interest позволил). Очевидно, что при такой гибкости требуются механизмы защиты протокола.

Когда вы открываете позицию, вы посылаете на смарт-контракт сообщение для создания ордера на открытие данной позиции. Это означает, что между нажатием вами кнопки в интерфейсе и открытием самой позиции есть довольно большой (по меркам волатильного рынка) временной промежуток. Если цена, по которой вы открывали позицию, и цена на момент обработки ордера сильно отличаются — позиция просто не откроется. По сути это slippage, как на любом DEX. Если внимательно изучить интерфейс Storm trade, то можно заметить, что пока открытие позиции обрабатывается — самой позиции ещё нету, а есть лишь ордер на её открытие, что вполне нормально и логично.

Slippage на perp DEX существует для того, чтобы потенциальный злоумышленник не мог указать случайную цену, заведомо отличающуюся от нынешней, и таким образом не мог открывать заведомо плюсовые сделки, выводя ликвидность из протокола. Такой баг мы находили у другого perp DEX на TON — Tradoor, и своевременно их предупредили, после чего баг был закрыт.

Поэтому никакого скама не произошло — ордер провисел 15 минут в блокчейне, а затем закрылся, т.к цена в нём не прошла проверку по slippage на индексере. Обидно, больно, неприятно, хочется топать ножками — но это так.

Важно понимать — perp DEX бывают разные. Например, в то время как Storm trade просто не открывал некоторые позиции из-за невероятной волатильности, аналогичные позиции на Drift protocol просто невозможно было открыть by design — в их orderbook стакане попросту не было заявок, торги прекратились на цене порядка 1.6$.

@TheOpenDevBlog

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

Во всех сообщениях фигурирует ошибка 37, это "Not enough Toncoin". Блокчейн тут не при чем.

@TheOpenDevBlog

🔥 DAMM на @bidask

Мы релизнули DAMM пулы. Факты:
⚫️ Это как обычные пулы ликвидности (CPMM), но не совсем.
⚫️ Они умеют в dynamic fees. Если выберете такую опцию, то при высокой волатильности физы будут повышаться, при низкой — понижаться.
⚫️ В DAMM пуле можно выбрать ценовые границы. Тогда пул будет работать как бин из CLMM — торговаться от одной цены до другой. Пример тут. Концентрация без концентрации 😐
⚫️ Комиссии не реинвестятся в позицию, а клеймятся отдельно. Удобно для мемтокенов.

Мемтокены. У нас можно максимально просто запустить свой. Факты:
⚫️ Можно выбрать стартовую цену, начальная ликва в тонах для этого не нужна.
⚫️ Можно откупить по стартовой цене токены. Полученный TON пойдёт в пул.
⚫️ Начальная ликвидность блочится навсегда, вы с нее можете только забирать собранные комиссии. Полный рагпул технически невозможен, все смогут продать токены как минимум по цене чуть ниже стартовой.
⚫️ Можно выбрать время старта торгов токена.

Один из авторов канала запустил мем самого себя. Важно: никто ничего не обещает, не рекомендует, чистый фан. НИКАКИХ ПЛАНОВ НЕТ.

UPD: в данный момент торговать в DAMM пулах можно только на @bidask.

@TheOpenDevBlog

🔥 Подписываемся и собираем воедино всё, что сегодня случилось.

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

Что такое подписка? Это адрес контракта, который добавляется в storage вашего кошелька. После этого с данного адреса можно совершать действия от вашего wallet контракта (например, отправлять TON за ежемесячную подписку). Это безопасная архитектура, ведь такие плагины списывают средства раз в какой-то промежуток времени.

Что за баг он обнаружил? При отказе от подписки можно было удалить контракт плагина из блокчейна, но не удалить сам адрес подписки из кошелька. Это означало, что если кто-либо заново задеплоит в блокчейн контракт вашей подписки на тот же адрес, то он снова сможет списать с вас деньги. Проверьте свои подписки, энтузиасты уже выкатили тулзу.

Что за баг он проэксплуатировал? Никакой. Бага не было, он просто снял TON за активные подписки, то есть сделал то, что эти подписки должны были делать последние 2 года (но не делали).

Чему нам надо научиться? Репортить баги. Не допускать их невозможно, это нормальная часть разработки, но для здоровой атмосферы в комьюнити нужно соблюдать этику. В своё время мы подали всем хороший пример, как заметили в одной из приваток.

Пескарь красавчик.
@TheOpenDevBlog

🔥 Выводим депозиты.

Недавно мы провели аудит смарт-контрактов проекта webdom. Среди найденных багов один был наивысшего приоритета — Critical. Что мы нашли?

Для многих из видов контрактов (аукционы, продажи доменов, etc) webdom предусмотрели возможность закрытия сделки не только с помощью internal, но и через external сообщение. То есть любой желающий может обратиться на контракт по external интерфейсу и уведомить его, что все условия сделки выполнены, пора ее исполнять. Это крайне полезно, например, для аукционов, когда время аукциона может выйти, но без внешнего вызова смарт-контракт сам не сможет реализовать окончание сделки.

Что такое external сообщение? Когда вы делаете свап на @bidask, ваш wallet контракт посылает internal сообщение от себя к пулу ликвидности. Но сам wallet контракт вызывается external сообщением, которое вы подписываете в кошельке. Любая цепочка транзакций в TON вызвана сообщением, которое приходит извне блокчейна — оно и называется external.

Следующий закономерный вопрос — почему злой Пескарь не может послать на мой wallet контракт 100 миллиардов external сообщений, чтобы сжечь на газ блокчейна мой 1 миллиард TON? Для этого предусмотрена защита — у каждого external вызова есть бесплатные 10000 газа (это 0.004 TON). Этот газ может быть потрачен без списания с аккаунта. Он тратится, например, на проверку подписи wallet контрактом. Если подпись верна, то контракт вызывает инструкцию acceptExternalMessage. Даже если злой Пескарь будет слать на ваш кошелек сообщения, то все они не будут приниматься контрактом, пока у злого Пескаря не появится ваш приватный ключ.

С webdom всё интереснее. Аукцион может завершить кто угодно. Это означает, что контракт всегда принимает external сообщение. В таком случае очень важно, чтобы любое external сообщение обрабатывалось корректно после того, как вызовется acceptExternalMessage. Иначе можно будет послать сообщение с ошибкой, контракт его примет, потратит свой газ, а аукцион не закроется — и продолжать так можно до бесконечности.

Именно в этом и заключалась ошибка webdom. В контрактах аукционов сначала external сообщение принималось, а затем из сообщения считывался queryId — 64 бита информации. Это означало, что можно было составить сообщение с недостаточным количеством бит, и контракт бы падал с ошибкой 9 (Cell underflow), тратя при этом газ. Это крайне критично для, например, аукционов в TON, где сумма за домен хранилась на контракте продажи, и могла быть потрачена полностью на газ. Итогом была бы потеря домена и суммы, которую за него заплатили. Такую ошибку мог бы совершить каждый, это необычный баг, ничьей вины в этом нет.

Баг был крайне оперативно исправлен.

В ближайшую субботу (08.11) один из авторов канала будет разбирать работу контрактов webdom в онлайн формате (там есть интересные нюансы) — вы сможете узнать что-то новое, спросить интересующие вас вопросы. Анонс в @toncishub будет чуть позже, мы приложим его к посту.

@TheOpenDevBlog