Разработчикам смарт-контрактов, которые с точки зрения логики оперируют с TON (например, принимают его в качестве оплаты), нужно всегда считаться с workchain адреса, с которым они оперируют.
Допустим, вы разрабатываете смарт-контракт и рассчитываете комиссии на операции, хардкодите (чего делать вроде как не советуется, но все, кажется, делают) и проверяете их в коде контракта, а потом в том же коде отправляете транзакцию с точным значением TON на указанный пользователем адрес (с message mode 1 или, еще хуже, 65). В такой ситуации, если вы точно подгоняете комиссии, чтобы пользователь ни в коем случае не переплатил, этот же самый пользователь может вас обмануть.
Дело в том, что в блокчейне TON есть так называемые workchains. Обычно адреса, с которыми мы оперируем, начинаются с "0:". Этот 0 означает, что контракт функционирует в workchain с номером 0. Кроме нулевого, в TON также есть Masterchain, адреса которого начинаются с "-1" (например, вот). Он нужен для системных контрактов блокчейна, пользователи с ним взаимодействовать обычно не должны. Комиссии в Masterchain заметно выше (например, вот тут я заплатил за обычный перевод 0.012 TON при том, что обычно он стоит в 5-6 раз меньше), поэтому если в сообщении вы платите комиссию за пользователя, то пользователь может обмануть, указав адрес из Masterchain, таким образом потратив с вашего контракта больше, чем прислал и должен был получить.
Все это может привести к ошибкам с математикой, т.к ваш баланс на контракте уменьшается больше, чем вы ожидаете. А также в TON есть механизм удаления контрактов, которые не могут оплатить свое хранение в блокчейне, поэтому также это может привести к полной потере данных смарт-контракта. Поэтому даже если вы напрямую с TON не оперируете, эта уязвимость может вам сильно навредить.
Для исключения таких ошибок в контракте стандарта jetton используют функцию force_chain. Также, насколько я знаю, в FunC есть возможность ограничить затрачиваемый газ, но я в этом не разбираюсь, подскажите в комментариях.
Допустим, вы разрабатываете смарт-контракт и рассчитываете комиссии на операции, хардкодите (чего делать вроде как не советуется, но все, кажется, делают) и проверяете их в коде контракта, а потом в том же коде отправляете транзакцию с точным значением TON на указанный пользователем адрес (с message mode 1 или, еще хуже, 65). В такой ситуации, если вы точно подгоняете комиссии, чтобы пользователь ни в коем случае не переплатил, этот же самый пользователь может вас обмануть.
Дело в том, что в блокчейне TON есть так называемые workchains. Обычно адреса, с которыми мы оперируем, начинаются с "0:". Этот 0 означает, что контракт функционирует в workchain с номером 0. Кроме нулевого, в TON также есть Masterchain, адреса которого начинаются с "-1" (например, вот). Он нужен для системных контрактов блокчейна, пользователи с ним взаимодействовать обычно не должны. Комиссии в Masterchain заметно выше (например, вот тут я заплатил за обычный перевод 0.012 TON при том, что обычно он стоит в 5-6 раз меньше), поэтому если в сообщении вы платите комиссию за пользователя, то пользователь может обмануть, указав адрес из Masterchain, таким образом потратив с вашего контракта больше, чем прислал и должен был получить.
Все это может привести к ошибкам с математикой, т.к ваш баланс на контракте уменьшается больше, чем вы ожидаете. А также в TON есть механизм удаления контрактов, которые не могут оплатить свое хранение в блокчейне, поэтому также это может привести к полной потере данных смарт-контракта. Поэтому даже если вы напрямую с TON не оперируете, эта уязвимость может вам сильно навредить.
Для исключения таких ошибок в контракте стандарта jetton используют функцию force_chain. Также, насколько я знаю, в FunC есть возможность ограничить затрачиваемый газ, но я в этом не разбираюсь, подскажите в комментариях.
Если у кого-то есть отзывы по работе ton accelerator, обратитесь, пожалуйста, ко мне в личку, очень нужно проконсультироваться.
Выплаты за поставку ликвидности от DeDust.io
Многие наверняка видели, что DeDust спустя несколько лет всё же соизволил выплатить награды поставщикам ликвидности (те, которые не с фарма). Про то, насколько это невероятная вещь вообще говорить смысла мало, я лично недополучил около 1000$ из-за того что с момента вывода ликвидности из некоторых пар курс этих монет успел упасть во много раз 🙃.
Давайте лучше разберём более интересную вещь. Некоторые, возможно, заходили на DefiLlama и смотрели красивые графики проектов.
Что мы знаем насчёт DeDust - поставщикам ликвидности он никаких денег не выплачивал, однако на графиках по прибыли протокола и собранным fees мы видим просто идеальную картинку - revenue протокола на протяжении всего времени был ровно 20% от общих собранных комиссий.
Хотя, очевидно, это не может быть правдой - поставщикам ликвидности выплатили деньги только несколько дней назад, и то, по формулам, которые сложно понять наверняка.
Что же получается, DeFiLlama врёт нам? Краткий ответ - да.
Но всё не так просто. Чтобы DeFiLlama брала откуда-то информацию, авторы проектов должны написать свой так называемый адаптер. Все адаптеры хранятся в одном большом репозитории. В этих адаптерах авторы проектов сами пишут скрипты, чтобы подавать различную информацию о своих проектах (TVL, Revenue, Value flow и т.д).
Как же DeDust берёт информацию о собранных комиссиях и доходе протокола? Очень просто, со своей собственной API! Они просто берут свою собственную информацию о собранных комиссиях, и буквально умножают её в скрипте на 0.2. На самом деле из-за своей архитектуры они вынуждены делать тоже самое даже для расчёта TVL. Проверить, честно ли они это делают, очень сложно, однако мы можем попробовать посмотреть на tonalytica, где увидим TVL DeDust в 26.6m тон, то есть примерно $142.5m. Однако на DefiLlama через их API мы видим число в $189.99m на момент написания поста. Откуда взялись эти 47 миллионов долларов TVL? Предполагаю, что в TVL они также могут записывать средства, заблокированные на фарминг пулов, но наверняка знает только сама команда DeDust.
Стоит отметить, что это не выходящая из нормы практика, многие проекты делают также - те же STON.fi например (хотя у них различие между информацией с api и тоналитикой не такая существенная). Это в целом объяснимо, когда информация слишком сложная для получения из блокчейна напрямую. Хотя, например, у EVAA TVL берётся исключительно из блокчейна напрямую. Да и у команды Storm Trade получилось брать всю информацию кроме объёма торгов напрямую с блокчейна (TVL) и с redoubt (Fees, Revenue).
И как обычно, не стоит верить всем графикам в интернете, и проводите собственный dyor!
Многие наверняка видели, что DeDust спустя несколько лет всё же соизволил выплатить награды поставщикам ликвидности (те, которые не с фарма). Про то, насколько это невероятная вещь вообще говорить смысла мало, я лично недополучил около 1000$ из-за того что с момента вывода ликвидности из некоторых пар курс этих монет успел упасть во много раз 🙃.
Давайте лучше разберём более интересную вещь. Некоторые, возможно, заходили на DefiLlama и смотрели красивые графики проектов.
Что мы знаем насчёт DeDust - поставщикам ликвидности он никаких денег не выплачивал, однако на графиках по прибыли протокола и собранным fees мы видим просто идеальную картинку - revenue протокола на протяжении всего времени был ровно 20% от общих собранных комиссий.
Хотя, очевидно, это не может быть правдой - поставщикам ликвидности выплатили деньги только несколько дней назад, и то, по формулам, которые сложно понять наверняка.
Что же получается, DeFiLlama врёт нам? Краткий ответ - да.
Но всё не так просто. Чтобы DeFiLlama брала откуда-то информацию, авторы проектов должны написать свой так называемый адаптер. Все адаптеры хранятся в одном большом репозитории. В этих адаптерах авторы проектов сами пишут скрипты, чтобы подавать различную информацию о своих проектах (TVL, Revenue, Value flow и т.д).
Как же DeDust берёт информацию о собранных комиссиях и доходе протокола? Очень просто, со своей собственной API! Они просто берут свою собственную информацию о собранных комиссиях, и буквально умножают её в скрипте на 0.2. На самом деле из-за своей архитектуры они вынуждены делать тоже самое даже для расчёта TVL. Проверить, честно ли они это делают, очень сложно, однако мы можем попробовать посмотреть на tonalytica, где увидим TVL DeDust в 26.6m тон, то есть примерно $142.5m. Однако на DefiLlama через их API мы видим число в $189.99m на момент написания поста. Откуда взялись эти 47 миллионов долларов TVL? Предполагаю, что в TVL они также могут записывать средства, заблокированные на фарминг пулов, но наверняка знает только сама команда DeDust.
Стоит отметить, что это не выходящая из нормы практика, многие проекты делают также - те же STON.fi например (хотя у них различие между информацией с api и тоналитикой не такая существенная). Это в целом объяснимо, когда информация слишком сложная для получения из блокчейна напрямую. Хотя, например, у EVAA TVL берётся исключительно из блокчейна напрямую. Да и у команды Storm Trade получилось брать всю информацию кроме объёма торгов напрямую с блокчейна (TVL) и с redoubt (Fees, Revenue).
И как обычно, не стоит верить всем графикам в интернете, и проводите собственный dyor!
The Open Dev Blog
Выплаты за поставку ликвидности от DeDust.io Многие наверняка видели, что DeDust спустя несколько лет всё же соизволил выплатить награды поставщикам ликвидности (те, которые не с фарма). Про то, насколько это невероятная вещь вообще говорить смысла мало,…
В комментариях правильно написали что график и дата дефилламы по Revenue и Fees как раз есть только с момента, как Дедаст всё “починил”. Поэтому касательно этого графика возможно вопросов и нет.
Хотя опять же, исходного кода Dedust всё ещё нет, информация на дефилламу поступает только с собственной апи от Дедаста, можем только верить 😋
Поинт остаётся тем же - проверяйте откуда берётся информация на DeFiLlama, она может браться далеко не обязательно с блокчейна
Хотя опять же, исходного кода Dedust всё ещё нет, информация на дефилламу поступает только с собственной апи от Дедаста, можем только верить 😋
Поинт остаётся тем же - проверяйте откуда берётся информация на DeFiLlama, она может браться далеко не обязательно с блокчейна
Мы не пропали, мы билдили!
Мы разрабатываем Bidask Protocol — DEX от TheOpenDevBlog!
Уникальность Bidask в том, что он первым на TON имплементирует концентрированную ликвидность: позволяет вкладывать ваши средства с гораздо большей эффективностью и гибко подстраиваться под свою финансовую стратегию. Больше можно почитать в whitepaper-е проекта на нашем сайте, там всё очень подробно описано!
Мы с удовольствем пообщаемся со всеми, кому будет интересен наш проект, а также презентуем Bidask Protocol на ближайшем буткемпе в Москве.
Шильте. Реактите. Интересуйтесь.
@bidask — @TheOpenDevBlog
Мы разрабатываем Bidask Protocol — DEX от TheOpenDevBlog!
Уникальность Bidask в том, что он первым на TON имплементирует концентрированную ликвидность: позволяет вкладывать ваши средства с гораздо большей эффективностью и гибко подстраиваться под свою финансовую стратегию. Больше можно почитать в whitepaper-е проекта на нашем сайте, там всё очень подробно описано!
Мы с удовольствем пообщаемся со всеми, кому будет интересен наш проект, а также презентуем Bidask Protocol на ближайшем буткемпе в Москве.
Шильте. Реактите. Интересуйтесь.
@bidask — @TheOpenDevBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Bidask Protocol
🎉 Bidask Protocol — winner of the Moscow Bootcamp!
This Sunday, Moscow hosted one of the bootcamps from the Hackers League Hackathon 2024, and Bidask took first place! We extend our heartfelt thanks to everyone for their support and belief in our project, and we also congratulate the other finalists.
Out team continue to work and are looking forward to victory at the Hackaton final!
Join our new era of DeFi on TON!
This Sunday, Moscow hosted one of the bootcamps from the Hackers League Hackathon 2024, and Bidask took first place! We extend our heartfelt thanks to everyone for their support and belief in our project, and we also congratulate the other finalists.
Out team continue to work and are looking forward to victory at the Hackaton final!
Join our new era of DeFi on TON!
Мы давно ничего не писали в канал, т.к все темы для постов, записанные в заметки, требуют большого погружения и ресерча. Если вы хотите ускорить появление постов — закиньте нам звезд, но это не инвестиционная рекомендация.
НО! Нас можно будет найти на TON Gateway. Обсудить с нами желательно всё, но для удобства мы составили список активностей, в которых мы принимаем участие:
⚫️ Мы очень активно заняты разработкой @bidask. Это наш основной проект, мы бросили на него все силы. Это очень серьёзный финансовый инструмент, который откроет пользователям на TON глаза на то, как реально должен использоваться DeFi. Мы открыты к сотрудничеству.
⚫️ Часть нашей команды участвует в разработке @circus_game. Это не наш проект, но мы в большой степени отвечаем за его техническую часть. Мы можем связать с владельцами для сотрудничества.
⚫️ Мы готовы проводить аудиты и консультации. У нас крайне мощный бэкграунд в безопасности как web2, так и web3, а также возможность привлечь к проекту дополнительные силы в случае, если компетенций основной команды не хватает (крайне редко). Мы уже консультировали ряд крупных и очень крупных проектов в разных блокчейнах.
Наши контакты в био канала.
До встречи!🌞
НО! Нас можно будет найти на TON Gateway. Обсудить с нами желательно всё, но для удобства мы составили список активностей, в которых мы принимаем участие:
Наши контакты в био канала.
До встречи!
Please open Telegram to view this post
VIEW IN TELEGRAM
На TON орудуют сэндвич боты.
Недавно ко мне обратились с проблемой — якобы в TON есть рабочий MEV. И им постоянно бреют работяг при покупке низколиквидных токенов. Как это работает: вы пытаетесь свапнуть токен на DEX или агрегаторе, отправляете транзакцию, а потом видите, что кто-то в блокчейне купил прямо перед вами и продал сразу после вас.
Я этим очень заинтересовался, поскольку все мы знаем, что MEV-а на TON не существует, но при этом боты довольно стабильно встают до пользователя и сразу после. Начал разбираться.
Выяснилось, конечно, что никакой это не MEV, а сэндвич боты работают по принципу обыкновенных снайперов:
⚫️ Они используют кошелёк в том же шарде, что и vault дедаста или роутер ston fi. Этим они обгоняют большинство аккаунтов в сети, ведь на сообщение из одного шарда в другой тратится гораздо больше времени, чем если всё происходит в одном.
⚫️ Если кошелек пользователя находится в одном шарде с контрактами DEX-ов, снайперы отправляют сообщение сразу с нескольких кошельков, тем самым увеличивая шансы на обгон пользователя просто за счёт количества. При этом повторной покупки не случается, т.к у них настроен slippage, и проходит ровно один свап. Поэтому боты выглядят в блокчейне как на картинке.
⚫️ Если пользователя снайпят через dedust, то в сообщении сразу происходит обратный свап, как тут. Кошелёк отправил на DEX тоны, и в той же цепочке сообщений получил в ответ чуть больше тонов. Бесплатные деньги, не иначе.
Мы проконсультировали независимую команду разработчиков, и они пообещали в скором времени выкатить решение для обхода этой проблемы. Подробности раскрывать не можем, т.к, очевидно, снайперы могут к ним приготовиться.
Поэтому мы, как и все, ждём анонса.
@TheOpenDevBlog
Недавно ко мне обратились с проблемой — якобы в TON есть рабочий MEV. И им постоянно бреют работяг при покупке низколиквидных токенов. Как это работает: вы пытаетесь свапнуть токен на DEX или агрегаторе, отправляете транзакцию, а потом видите, что кто-то в блокчейне купил прямо перед вами и продал сразу после вас.
Я этим очень заинтересовался, поскольку все мы знаем, что MEV-а на TON не существует, но при этом боты довольно стабильно встают до пользователя и сразу после. Начал разбираться.
Выяснилось, конечно, что никакой это не MEV, а сэндвич боты работают по принципу обыкновенных снайперов:
Мы проконсультировали независимую команду разработчиков, и они пообещали в скором времени выкатить решение для обхода этой проблемы. Подробности раскрывать не можем, т.к, очевидно, снайперы могут к ним приготовиться.
Поэтому мы, как и все, ждём анонса.
@TheOpenDevBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня мы выпустили пост про иную модель проскальзывания (slippage-а), которую мы имплементировали в @bidask.
При обмене токенов через автоматический маркет-мейкер (AMM) цена, по которой происходит обмен, испытывает движение в невыгодную сторону, называемое проскальзыванием. Пользователи имеют возможность указывать допустимое проскальзывание, чтобы не совершить невыгодный обмен или не стать жертвой сэндвич-атаки.
В EVM-сетях и на v2 DEX мы привыкли, что выход за границы указанной цены полностью откатывает всю транзакцию, как будто пользователь не совершал обмен и не тратил токенов.
В Bidask Protocol, в силу мультиконтрактной архитектуры протокола и атомарности транзакций в тоне, такое невозможно, ведь свап может затрагивать несколько контрактов с ликвидностью. Чтобы сделать "нормальный" slippage, пришлось бы идти обратно по всем контрактам и "отменять" транзакцию, и еще учитывать, что другой пользователь уже мог начать обменивать после нас. Это очень непрактично и дорого, поэтому мы поступили хитрее.
Вместо этого, свап в Bidask Protocol осуществляется по модели partial execution, при которой токены обмениваются до тех пор, пока цена устраивает пользователя, т.е. не превышает указанный slippage. Пользователь получает токены нового актива, которые удалось свапнуть, и несвапнутые токены старого.
С точки зрения пользовательского опыта это всё тот же slippage, даже удобнее, потому что вы не испытаете слетевших транзакций и потратите меньше газа, если вдруг фронтэнд показывает цену с задержкой или на рынке большая волатильность.
@bidask — @TheOpenDevBlog
При обмене токенов через автоматический маркет-мейкер (AMM) цена, по которой происходит обмен, испытывает движение в невыгодную сторону, называемое проскальзыванием. Пользователи имеют возможность указывать допустимое проскальзывание, чтобы не совершить невыгодный обмен или не стать жертвой сэндвич-атаки.
В EVM-сетях и на v2 DEX мы привыкли, что выход за границы указанной цены полностью откатывает всю транзакцию, как будто пользователь не совершал обмен и не тратил токенов.
В Bidask Protocol, в силу мультиконтрактной архитектуры протокола и атомарности транзакций в тоне, такое невозможно, ведь свап может затрагивать несколько контрактов с ликвидностью. Чтобы сделать "нормальный" slippage, пришлось бы идти обратно по всем контрактам и "отменять" транзакцию, и еще учитывать, что другой пользователь уже мог начать обменивать после нас. Это очень непрактично и дорого, поэтому мы поступили хитрее.
Вместо этого, свап в Bidask Protocol осуществляется по модели partial execution, при которой токены обмениваются до тех пор, пока цена устраивает пользователя, т.е. не превышает указанный slippage. Пользователь получает токены нового актива, которые удалось свапнуть, и несвапнутые токены старого.
С точки зрения пользовательского опыта это всё тот же slippage, даже удобнее, потому что вы не испытаете слетевших транзакций и потратите меньше газа, если вдруг фронтэнд показывает цену с задержкой или на рынке большая волатильность.
@bidask — @TheOpenDevBlog
The Open Dev Blog
На TON орудуют сэндвич боты. Недавно ко мне обратились с проблемой — якобы в TON есть рабочий MEV. И им постоянно бреют работяг при покупке низколиквидных токенов. Как это работает: вы пытаетесь свапнуть токен на DEX или агрегаторе, отправляете транзакцию…
В комментариях спросили, как получить адрес в конкретном шарде. Мы решили подойти к вопросу обстоятельно, и запилили для вас простую страничку.
На ней вы можете вставить нужный вам адрес, и набрутить себе кошелёк в том же шарде блокчейна. Осторожно, это может занять больше 5 секунд! На выходе вы получите адрес вашего нового кошелька и seed фразу для него (как на картинке).
Важно понимать, что наличие такого кошелька не убережёт вас от снайпинга, но сильно повысит ваши шансы быть первее других пользователей при обмене токенов.
Важно!!! Сайт не собирает seed фразы, все вычисления происходят в вашем браузере, но если вам особенно важна безопасность, то поднимите страничку локально, использовав ее исходный код.
@bidask x @TheOpenDevBlog
На ней вы можете вставить нужный вам адрес, и набрутить себе кошелёк в том же шарде блокчейна. Осторожно, это может занять больше 5 секунд! На выходе вы получите адрес вашего нового кошелька и seed фразу для него (как на картинке).
Важно понимать, что наличие такого кошелька не убережёт вас от снайпинга, но сильно повысит ваши шансы быть первее других пользователей при обмене токенов.
Важно!!! Сайт не собирает seed фразы, все вычисления происходят в вашем браузере, но если вам особенно важна безопасность, то поднимите страничку локально, использовав ее исходный код.
@bidask x @TheOpenDevBlog
Долгое время благодаря не разбирающимся в технологии людям существовал нарратив о том, что концентрированная ликвидность на TON невозможна. Конечно, это было неправдой, и такие выводы приходили людям только потому, что они очень плоско смотрели на возможности блокчейна. В своё время именно благодаря этому нарративу мы решили сделать @bidask.
Однако какой финансовый механизм на блокчейне TON действительно нереализуем? Ответ — flash loans.
Перевод вас не собьёт с толку, это буквально «мгновенный кредит». В крипте мы привыкли, что кредиты нам выдают только под залог наших средств, как это происходит на AAVE или EVAA. Но благодаря технологичному подходу к управлению средствами на EVM сетях появился способ занять деньги, провести с ними некоторую манипуляцию, и вернуть обратно с процентами в рамках одной транзакции. Если у вас не получится вернуть деньги, вам просто не выдадут кредит. Из-за того, что вся цепочка транзакции в EVM сетях происходит «одновременно», конечный результат исполнения можно проверить. Это нонсенс, кредит с нулевым риском, ведь фактически заёмщик возвращает кредит моментально сразу после его взятия.
В мирных целях flash loans нужны, например, арбитражерам, если они видят большой спред на двух разных DEX, но покрыть его своими средствами не могут. В такой ситуации можно взять мгновенный кредит, проарбитражить, и вернуть с процентом какую угодно сумму, разницу забрать себе. Этот механизм доступен практически каждому, кто способен искать вилки и писать смарт контракты.
На TON сообщения движутся асинхронно, и нельзя проверить результат всей цепочки исполнения, находясь в её начале. Из-за этого механизм flash loan-а в чистом виде абсолютно нереализуем. Flash loan — потеря для экосистемы, однако асинхронность и шардирование блокчейна — ещё большие приобретения.
Кстати, очень часто flash loan использовался для атак на DeFi. Подробнее об этом можно почитать тут.
@bidask x @TheOpenDevBlog
Однако какой финансовый механизм на блокчейне TON действительно нереализуем? Ответ — flash loans.
Перевод вас не собьёт с толку, это буквально «мгновенный кредит». В крипте мы привыкли, что кредиты нам выдают только под залог наших средств, как это происходит на AAVE или EVAA. Но благодаря технологичному подходу к управлению средствами на EVM сетях появился способ занять деньги, провести с ними некоторую манипуляцию, и вернуть обратно с процентами в рамках одной транзакции. Если у вас не получится вернуть деньги, вам просто не выдадут кредит. Из-за того, что вся цепочка транзакции в EVM сетях происходит «одновременно», конечный результат исполнения можно проверить. Это нонсенс, кредит с нулевым риском, ведь фактически заёмщик возвращает кредит моментально сразу после его взятия.
В мирных целях flash loans нужны, например, арбитражерам, если они видят большой спред на двух разных DEX, но покрыть его своими средствами не могут. В такой ситуации можно взять мгновенный кредит, проарбитражить, и вернуть с процентом какую угодно сумму, разницу забрать себе. Этот механизм доступен практически каждому, кто способен искать вилки и писать смарт контракты.
На TON сообщения движутся асинхронно, и нельзя проверить результат всей цепочки исполнения, находясь в её начале. Из-за этого механизм flash loan-а в чистом виде абсолютно нереализуем. Flash loan — потеря для экосистемы, однако асинхронность и шардирование блокчейна — ещё большие приобретения.
Кстати, очень часто flash loan использовался для атак на DeFi. Подробнее об этом можно почитать тут.
@bidask x @TheOpenDevBlog
Известно, что Tether на EVM блокчейнах умеет блокировать или изымать USDT на кошельках, если посчитает это нужным. Обычно это происходит при совершении каких либо преступлений владельцем кошелька.
TON этот механизм не обошел стороной, у jetton wallet USDT тоже есть опция быть заблокированным. Собственно, поэтому стандарт в tonviewer подписывается как «jetton wallet governed».
Но вот к реализации этого механизма есть вопросы. На EVM сетях всё просто — у токена есть один единственный смарт контракт, при обращении к нему нужный адрес блокируется. В TON всё не так, и чтобы заблокировать баланс конкретного адреса, нужно обратиться напрямую к его jetton wallet-у.
Это происходит так: админ Tether USDT обращается к jetton master, jetton master обращается к нужному jetton wallet, jetton wallet блокируется. Проблема данного механизма в том, что уже на этапе транзакции к jetton master злоумышленник может переместить свои токены на другой кошелек, или вовсе продать их на DEX, и выйти в TON. Достаточно лишь следить за транзакциями на jetton master и искать там сообщения на изменение статуса своего кошелька. Проблема усугубится, если jetton wallet злоумышленника находится в другом шарде относительно jetton master USDT. Тогда вообще «заснайпить» блокировку кошелька совершенно несложно, ведь транзакция из одного шарда в другой будет идти достаточно долго.
Прецедентов блокировки USDT на TON пока не было, мы проверили.
Думайте.
@bidask x @TheOpenDevBlog
TON этот механизм не обошел стороной, у jetton wallet USDT тоже есть опция быть заблокированным. Собственно, поэтому стандарт в tonviewer подписывается как «jetton wallet governed».
Но вот к реализации этого механизма есть вопросы. На EVM сетях всё просто — у токена есть один единственный смарт контракт, при обращении к нему нужный адрес блокируется. В TON всё не так, и чтобы заблокировать баланс конкретного адреса, нужно обратиться напрямую к его jetton wallet-у.
Это происходит так: админ Tether USDT обращается к jetton master, jetton master обращается к нужному jetton wallet, jetton wallet блокируется. Проблема данного механизма в том, что уже на этапе транзакции к jetton master злоумышленник может переместить свои токены на другой кошелек, или вовсе продать их на DEX, и выйти в TON. Достаточно лишь следить за транзакциями на jetton master и искать там сообщения на изменение статуса своего кошелька. Проблема усугубится, если jetton wallet злоумышленника находится в другом шарде относительно jetton master USDT. Тогда вообще «заснайпить» блокировку кошелька совершенно несложно, ведь транзакция из одного шарда в другой будет идти достаточно долго.
Прецедентов блокировки USDT на TON пока не было, мы проверили.
Думайте.
@bidask x @TheOpenDevBlog
Принято считать, что на TON невозможен MEV — Maximal Extractable Value (или как он ранее расшифровывался, Miner Extractable Value) — механизм "подкупа" валидаторов через увеличение выплачиваемой им комиссии с целью выгодной для подкупающего манипуляции порядком транзакций в блоке.
Это используется, например, для получения преимущества перед другими при арбитраже, ликвидациях, или например в знаменитых "сэндвич"-атаках, при которых валидатор помещает транзакцию "жертвы" между транзакциями атакующего — отсюда, собственно, и название.
В TON комиссии за транзакцию фиксированы, высокий спрос регулируется шардингом. Поэтому варьировать комиссию, как на EVM, не получится. А переменные по типу
Когда вы совершаете действие через обычный кошелек, вы посылаете ему сообщение, а перед ним 512 бит, которые отвечают за подпись вашего сообщения. Таким образом, никто, включая валидатора, не может поменять ваше действие, ведь тогда ваша подпись станет недействительной. Приватный ключ от wallet-а хранится только у вас. Таким образом гарантируется, что контроль над вашим кошельком имеете только вы.
🔥 Отсюда рождается новая идея — MEV-кошелек. Задумка в том, чтобы добавить в тело сообщения место, которое не покрывается подписью, а следовательно даёт валидатору возможность вписать туда любое значение при выгрузке из мемпула, а именно — адрес своего кошелька. Например, на скрине считываемый
Такой механизм, в отличие от простого увеличения комиссии, открывает возможность условной выплаты, то есть, например, только в случае, если операция, ради которой платилась взятка, действительно закончилась финансовой выгодой. Это может проверяться при получении результатов атаки на кошельке. Валидатор таким образом становится сам заинтересован в наиболее эффективном расположении транзакции.
Однако для функционирования подобного кошелька требуется модификация софта, которым пользуются валидаторы, для того, чтобы автоматически обрабатывать транзакции на подобные кошельки и подставлять нужный адрес, а также сортировать их для поиска собственной выгоды.
Пускай данный пост, а также экономический интерес подстегнёт подобную разработку. Приносим извинения за доставленные неудобства!
@bidask x @TheOpenDevBlog
Это используется, например, для получения преимущества перед другими при арбитраже, ликвидациях, или например в знаменитых "сэндвич"-атаках, при которых валидатор помещает транзакцию "жертвы" между транзакциями атакующего — отсюда, собственно, и название.
В TON комиссии за транзакцию фиксированы, высокий спрос регулируется шардингом. Поэтому варьировать комиссию, как на EVM, не получится. А переменные по типу
block.coinbase в Solidity (адрес кошелька валидатора, выпускающего блок) контрактам на TON недоступны. Конечно, остаётся возможность договориться с валидатором лично, но это не стандартизированный подход. В документации TVM есть обещание добавить команду BUYGAS, но никаких подробностей не дают.Когда вы совершаете действие через обычный кошелек, вы посылаете ему сообщение, а перед ним 512 бит, которые отвечают за подпись вашего сообщения. Таким образом, никто, включая валидатора, не может поменять ваше действие, ведь тогда ваша подпись станет недействительной. Приватный ключ от wallet-а хранится только у вас. Таким образом гарантируется, что контроль над вашим кошельком имеете только вы.
validator_reward_address не попадает в подписанное тело сообщения для wallet w5, поэтому валидатор может его подменить.Такой механизм, в отличие от простого увеличения комиссии, открывает возможность условной выплаты, то есть, например, только в случае, если операция, ради которой платилась взятка, действительно закончилась финансовой выгодой. Это может проверяться при получении результатов атаки на кошельке. Валидатор таким образом становится сам заинтересован в наиболее эффективном расположении транзакции.
Однако для функционирования подобного кошелька требуется модификация софта, которым пользуются валидаторы, для того, чтобы автоматически обрабатывать транзакции на подобные кошельки и подставлять нужный адрес, а также сортировать их для поиска собственной выгоды.
Пускай данный пост, а также экономический интерес подстегнёт подобную разработку. Приносим извинения за доставленные неудобства!
@bidask x @TheOpenDevBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
Год получился, как это обычно бывает, насыщенным. Николай Дуров, наконец, передумал и решил, что в Cell будет 1025 бит, а в Int — 255. Сказал, что "перепутал и не понял, как так получилось, а тут как раз повод — 2025 год".
Мы появились, подписали на себя самых крутых персон в экосистеме TON, выполнили несколько крупных заказов и, наконец, разработали @bidask.
У нас есть очень большие новости сразу по ряду направлений, которыми мы пока не можем делиться, однако можем заверить — в 2025 году мы приумножим свой успех и расскажем вам ещё больше нового!
Вам остается только ждать, поздравлять нас звездами и репостами, бесплатным шиллом по приваткам и вашими респектами.
🩵 Спасибо вам за этот прекрасный (полу)год! Поздравляем вас и ваших близких с Новым Годом, пусть в нём всех нас ждет TON по 20, и Solana по 0, конечно же.
Думайте.
@TheOpenDevBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
На EVM сетях есть большое количество стандартов, заточенных под решение разных проблем — от обычных токенов до ERC-1155, который совмещает в себе токены и NFT. Идея выпуска стандартов перекочевала и на TON, однако, как будто, с фальстартом, поскольку к ним уже сейчас есть множество вопросов.
В этом посте вместе с @pcrafter разберем TEP-74, стандарт жетона, его проблемы, что в нём можно поменять, и как его дополнить:
Кроме того, неясна роль excess-сообщений. Кроме возврата TON, они могли бы нести информацию хотя бы о количестве присылаемых токенов, но сейчас, если контракт-источник не послал forward_ton_amount, то ончейн узнать о пришедших жетонах нельзя.
Это, например, очень сильно ограничивало во взаимодействиях со ston-fi v1, ведь там контракт роутера по умолчанию слал жетоны с forward_ton_amount, равным 0, и не было никакой возможности оперировать с пришедшими от свапа жетонами. Фактически, это делало ончейн взаимодействие с протоколом невозможным.
И при этом альтернатив нет. С нынешними жетонами, которые минтятся на minter.ton.org и т.д (даже с USDT), крайне сложно работать.
Меняйте TON. Не на USDT.
@TheOpenDevBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
Как бесплатно достать ключ для tonapi? Взять его в tonkeeper!
Заходим сюда (ссылка была получена через вкладку network в инспекторе - при каждом обновлении интерфейса приложение делает туда запрос) и берем ключ из параметра tonApiV2Key. Там же можно найти и эндпоинт для tonapi — keeper.tonapi.io. Может, у него аптайм выше стандартного)
Ключ лимитирован 100 запросами в секунду, но только для одного ip (подсчитано вручную, не точно). Для сравнения — бесплатный tonapi (без ключа) можно использовать только 1 раз в секунду.
Вообще, так можно позаимствовать ключ у какого угодно проекта, который использует tonapi на фронтенде. Стоимость ключа для проекта от активности не повышается, поэтому вы таким образом никому не навредите.
Также стоит помнить, что ключи tonapi могут быть ограничены по Origin (домен сайта с которого должны отправляться запросы). В случае с tonkeeper это не так, а если найденный ключ всё же ограничен по домену — для использования его вне браузеров всегда можно добавить требуемый домен в header Origin.
The Open Network.
@TheOpenDevBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Многие разработчики на TON думают, что мод 64 в сообщении гарантирует, что баланс контракта останется таким же, как и до сообщения. И модом 64 они прикрываются, когда нужно отправить ровно 1 сообщение, не поменяв баланс контракта. Короче, используют мод 64 как гарант, что контракт со временем не обнулит свой баланс.
Ирония в том, что на самом деле мод 64 гарантирует, что баланс контракта НЕ УВЕЛИЧИТСЯ.
А всё дело в storage fee. Нюанс в том, что storage fee (плата за хранение информации в блокчейне) взимается с контракта до запуска TVM, то есть контролировать или отследить этот процесс невозможно. Таким образом, мод 64 рассчитывает, что баланс контракта останется таким же, как и ПОСЛЕ снятия storage fee с баланса. То есть
balance_after <= balance_before.Решений много, но глобально они все опираются на механизм
raw_reserve и мод сообщения 128. Для того, чтобы держать баланс контракта всегда одинаковым, нужно при каждом вызове, где нужно будет отправить сообщение, использовать
raw_reserve(<нужный баланс>, 0), а в самом последнем сообщении на контракте использовать мод 128. Таким образом, последнее сообщение заберет с собой все остатки баланса, кроме зарезервированного, и это гарантирует (почти), что баланс контракта не изменится.При таком решении очень важно понимать, что пользователь может прислать недостаточно газа (с учетом storage fee), и контракт упадет, потому что ему либо не хватит на резерв, либо на сообщение.
Вообще, у
raw_reserve тоже есть разные моды, советуем ознакомиться.@TheOpenDevBlog
Please open Telegram to view this post
VIEW IN TELEGRAM