Принято считать, что на TON невозможен MEV — Maximal Extractable Value (или как он ранее расшифровывался, Miner Extractable Value) — механизм "подкупа" валидаторов через увеличение выплачиваемой им комиссии с целью выгодной для подкупающего манипуляции порядком транзакций в блоке.
Это используется, например, для получения преимущества перед другими при арбитраже, ликвидациях, или например в знаменитых "сэндвич"-атаках, при которых валидатор помещает транзакцию "жертвы" между транзакциями атакующего — отсюда, собственно, и название.

В TON комиссии за транзакцию фиксированы, высокий спрос регулируется шардингом. Поэтому варьировать комиссию, как на EVM, не получится. А переменные по типу block.coinbase в Solidity (адрес кошелька валидатора, выпускающего блок) контрактам на TON недоступны. Конечно, остаётся возможность договориться с валидатором лично, но это не стандартизированный подход. В документации TVM есть обещание добавить команду BUYGAS, но никаких подробностей не дают.

Когда вы совершаете действие через обычный кошелек, вы посылаете ему сообщение, а перед ним 512 бит, которые отвечают за подпись вашего сообщения. Таким образом, никто, включая валидатора, не может поменять ваше действие, ведь тогда ваша подпись станет недействительной. Приватный ключ от wallet-а хранится только у вас. Таким образом гарантируется, что контроль над вашим кошельком имеете только вы.

🔥 Отсюда рождается новая идея — MEV-кошелек. Задумка в том, чтобы добавить в тело сообщения место, которое не покрывается подписью, а следовательно даёт валидатору возможность вписать туда любое значение при выгрузке из мемпула, а именно — адрес своего кошелька. Например, на скрине считываемый validator_reward_address не попадает в подписанное тело сообщения для wallet w5, поэтому валидатор может его подменить.

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

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

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

@bidask x @TheOpenDevBlog

🔥🎉 @TheOpenDevBlog подводит итоги.

Год получился, как это обычно бывает, насыщенным. Николай Дуров, наконец, передумал и решил, что в Cell будет 1025 бит, а в Int — 255. Сказал, что "перепутал и не понял, как так получилось, а тут как раз повод — 2025 год".

Мы появились, подписали на себя самых крутых персон в экосистеме TON, выполнили несколько крупных заказов и, наконец, разработали @bidask.

У нас есть очень большие новости сразу по ряду направлений, которыми мы пока не можем делиться, однако можем заверить — в 2025 году мы приумножим свой успех и расскажем вам ещё больше нового!

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

🩵 Спасибо вам за этот прекрасный (полу)год! Поздравляем вас и ваших близких с Новым Годом, пусть в нём всех нас ждет TON по 20, и Solana по 0, конечно же.

Думайте.
@TheOpenDevBlog

🔥 Сколько мы бы не защищали тут TON, культура разработки в нашем блокчейне ещё на совсем низком уровне.
На EVM сетях есть большое количество стандартов, заточенных под решение разных проблем — от обычных токенов до ERC-1155, который совмещает в себе токены и NFT. Идея выпуска стандартов перекочевала и на TON, однако, как будто, с фальстартом, поскольку к ним уже сейчас есть множество вопросов.
В этом посте вместе с @pcrafter разберем TEP-74, стандарт жетона, его проблемы, что в нём можно поменять, и как его дополнить:

⚫️ В нынешнем стандарте нет опции не деплоить jetton-wallet получателя. Это было бы полезно для того, чтобы уменьшить стоимость пересылки жетонов в случае, если у получателя уже есть кошелек. Решение может быть простое — иметь в интерфейсе посылания жетонов такую опцию, которая будет автоматически заполняться кошельками (tonkeeper и т.д) для удобства пользователя.

⚫️ Нынешний стандарт вообще не поддерживает работу с балансом jetton-wallet. Ни возможности ончейн узнать, сколько у тебя жетонов, ни возможности отправить сразу все жетоны, сколько бы их там не было, нет. Это очень сильно ограничивает при написании смарт-контрактов, работающих с жетонами.
Кроме того, неясна роль excess-сообщений. Кроме возврата TON, они могли бы нести информацию хотя бы о количестве присылаемых токенов, но сейчас, если контракт-источник не послал forward_ton_amount, то ончейн узнать о пришедших жетонах нельзя.
Это, например, очень сильно ограничивало во взаимодействиях со ston-fi v1, ведь там контракт роутера по умолчанию слал жетоны с forward_ton_amount, равным 0, и не было никакой возможности оперировать с пришедшими от свапа жетонами. Фактически, это делало ончейн взаимодействие с протоколом невозможным.

⚫️TEP-74 поддерживает forward payload, но не поддерживает возможность деплоить контракт получателя. А представьте, как было бы удобно! Можешь сразу деплоить контракт по ту сторону, исполнить его, и получить результат.

⚫️ Хранение своего кода в стейте контракта не обязательно. Мало кто знает (мы сами узнали совсем недавно), что в TVM есть инструкция MYCODE, которая позволяет контракту получать свой собственный код в виде cell.

⚫️ Кажется, что контракт jetton-wallet оставляет себе слишком много TON для газа. Например, в @bidask стоимость свапа в рамках одного бина составляет 0.06 TON, из которых 0.01(а то и все 0.02) остаются мертвым грузом на jetton-wallet-ах. Посмотрите на jetton-wallet-ы на DEX, на любом активно использующемся контракте лежит много навсегда заблокированных TON. Например, на кошельке USDT dedust лежит 6к$ в оставшихся комиссиях.

И при этом альтернатив нет. С нынешними жетонами, которые минтятся на minter.ton.org и т.д (даже с USDT), крайне сложно работать.

Меняйте TON. Не на USDT.
@TheOpenDevBlog

🔥 Перед очень большими новостями небольшой лайфхак вам на затравку.

Как бесплатно достать ключ для tonapi? Взять его в tonkeeper!

Заходим сюда (ссылка была получена через вкладку network в инспекторе - при каждом обновлении интерфейса приложение делает туда запрос) и берем ключ из параметра tonApiV2Key. Там же можно найти и эндпоинт для tonapi — keeper.tonapi.io. Может, у него аптайм выше стандартного)

Ключ лимитирован 100 запросами в секунду, но только для одного ip (подсчитано вручную, не точно). Для сравнения — бесплатный tonapi (без ключа) можно использовать только 1 раз в секунду.

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

Также стоит помнить, что ключи tonapi могут быть ограничены по Origin (домен сайта с которого должны отправляться запросы). В случае с tonkeeper это не так, а если найденный ключ всё же ограничен по домену — для использования его вне браузеров всегда можно добавить требуемый домен в header Origin.

The Open Network.
@TheOpenDevBlog

👍 DWF Labs х Bidask

😱😱😱😱😱

🔥 Делимся находками в процессе разработки @bidask

Многие разработчики на 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

🔥 Главная идея DEX с концентрированной ликвидностью — это эффективность использования капитала. Но что такое вообще эффективность капитала?

Проще всего её представить в контексте обычной модели Uniswap. Предположим, пользователь открывает позицию на $10к на пару ETH\USDT в пуле с LP fee 0.3% на средний диапазон (1500-2000). Спустя месяц количество заработанных комиссий у него составляет приблизительно $600 (реальные числа с revert.finance). Таким образом его капитал за месяц был использован для свапов на общую сумму равную 600/0.003 = $200к, то есть полностью 20 раз!
Если же зайти на любой CPMM DEX, то там капитал на любой аналогичной высоколиквидной паре за месяц будет использован точно в разы меньше.

Остаётся вопрос: как ещё можно увеличивать показатель эффективности капитала?

Первый вариант — это манипулирование уровнями комиссий в пуле. Например очевидно, что если комиссий вообще не будет (ни комиссий протокола, ни комиссий для провайдеров ликвидности) — то почти наверняка вырастут объёмы торгов и эффективность капитала как следствие (если забыть, что комиссий мы не получим 😀). Комиссии lp провайдеров убирать бессмысленно, а вот с комиссиями протокола разъяснять долго — есть очень подробный ресёрч при содействии Uniswap Foundation на эту тему. Существует также опция использования динамических комиссий, больше всего в этом преуспела Meteora на солане — и её успешный опыт мы активно перенимаем в @bidask.

Очень важной опцией является использование автоматического реинвестирования заработанных комиссий обратно в позицию ликвидности. Да, это работает само собой в любом CPMM DEX, однако для CLMM это редкость, хотя это дает ощутимый прирост к доходности.

Предположим, вы просто положили деньги в банк под 12% годовых. Если вы получаете их ровно раз в год, то ваша доходность за год будет составлять как раз 12%. Если же будете получать их каждый месяц и реинвестировать - доходность будет уже ~12.68%, если же реинвестирование будет происходить непрерывно то это уже ~12.74%. Формула для подсчета APY при непрерывном реинвестировании: e^APR - 1.

Казалось бы, разница не такая большая для 12% годовых, чтобы о ней думать. Однако если представить ситуацию, которая вполне возможна при поставке концентрированной ликвидности на достаточно широкий диапазон, что актуальная цена не вышла из него в течении года — это будут вполне реалистичные 20-30% годовых.
Для 30% годовых непрерывное реинвестирование комиссий приведёт уже к 35% годовым вместо 30%, к 64% вместо 50% без реинвестирования, и так далее.

Учитывая, что существуют киты, которые не так следят за IL, а лишь ждут, пока комиссии полностью не окупят вкладываемую ими ликвидность — подобный буст процентов доходности вполне может сократить годик-другой до цели в 100% ROI.

Над всем этим мы думали на старте разработки @bidask — и реализовали автоматическое реинвестирование комиссий. И даже у невероятно крутой Meteora, с которой нас принято сравнивать, такой киллер фичи нет — в этом мы круче.

🔥 Нас можно будет найти на Token 2049.

Наши контакты в био канала.
До встречи! 🌞

🔥 Пока в TON, как обычно, происходит балаган, устроим себе пикник во время пира — расскажем про интересный, но уходящий от нас нюанс в разработке смарт контрактов на нашем любимом устаревшем отставшем от жизни и времени и всех конкурентов недоязыке программирования FunC.

В некоторых проектах может потребоваться проверить, что один адрес НЕ равен другому. Многие эту проблему решают очень просто:
ifnot (equal_slices(address1, address2))

Фатальная ошибка.

Нюанс кроется буквально в названии функции — equal_slices не проверяет равенство адресов, она проверяет равенство слайсов.
Дело в том, что в TON существует больше одного способа записать адрес в slice, чтобы он корректно считался ~load_msg_addr — addr_std и addr_var. Если записать адрес двумя разными способами, а потом считать, то получится два разных, не равных друг другу слайса, хотя адрес один.

Что же делать? На самом деле, решение простое — кроме equal_slices также проверять, что длина адресов — 267 бит, ведь это длина addr_std.

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

К сожалению или к счастью, addr_var очень скоро нас покинет. Наши репортеры и очевидцы из тестнета утверждают, что там он уже "пропал" 🫡🫡🫡

Крутая ироничная фраза.
@TheOpenDevBlog

🔥 Мы пообщались с @kyouma из Ton Tech, чтобы выяснить подробности грядущего обновления TON, связанного с новой системой распределения контрактов по шардам.

Главной проблемой, которую и решали мы в @bidask, было то, что система распределения контрактов по шардам была строго детерминированной — брался хэш от state init, получался адрес контракта, и после этого по первым битам адреса определялось, в каком шарде будет контракт. Из-за этого все операции в TON были заметно дольше — ведь транзакция пользователя постоянно "прыгала" по шардам даже там, где это совершенно не нужно.

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

На их основе даже был сделан DEX, позволяющий проводить обмены в рамках одного блока. Там не было использовано фишки со сплитом контрактов, просто были точки входа в DEX во всех шардах. Минусом такого подхода было деление ликвидности пар на все шарды и закономерное увеличение слипаджа. Немногие знают, но mainnet версия bidask, хоть и начала писаться до появления LUXNOX, во многом была вдохновлена именно этим решением. Мы следим за экосистемой 🤟

Как эту проблему решили?
Теперь в state init появился новый параметр — fixed_prefix_length. Он дает понять, какое количество бит в начале адреса при деплое можно перезаписать, чтобы контролировать, в какой шард пойдет контракт.

На счет обратной совместимости можно не переживать — на месте fixed_prefix_length раньше был другой, по сути бесполезный параметр, связанный с anycast, поэтому с точки зрения построения state init ничего глобально не изменилось.

При всей кажущейся простоте изменения это, конечно, открывает пространство для множества вещей. Первое, что приходит в голову — jetton, который создает jetton wallet всегда в 1 шарде с контрактом кошелька пользователя. Нам, как разработчикам, это еще вселяет надежду, что наконец кто-то займется обновлением стандарта jetton, который явно морально устарел.

Это сильно улучшит опыт взаимодействия с DeFi, ведь теперь протоколы могут контролировать ончейн, без брутфорса, что будут в 1 шарде. Не сразу, но это принесёт значимые плоды.

@TheOpenDevBlog

🔥 GM
Подкиньте — какой у кого есть тулинг под FunC?
Пойдет что угодно. Го обмениваться опытом

🔥 Мы ищем контакты с трейдинг командами.

@bidask есть что предложить: мы быстрее, мы эффективнее, мы дешевле.
Мы готовы помочь с интеграцией, стратегиями, с чем угодно, что у вас вызывает трудности при интеграции нового DEX.

Считайте этот пост публичной рефералкой, мы будем крайне благодарны, если по вашей рекомендации или репосту к нам придет будущий партнер.

🅱️ Кидаем скрины скорости свапов, поехали

LFG

https://app.bidask.finance/