🔥 Пока в 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/

🔥 Вчера Павел Дуров сделал сенсационное заявление — TON стал №1 блокчейном по объему трейдинга NFT, если считать off-chain сделки.

Многие посмеялись, посчитали это забавным предложением, но знаете ли вы, что существует стандарт токена (а соответственно, и NFT), который можно передать off-chain?

Это — ERC-965, стандарт токена для EVM сетей (есть более известный аналог — ERC20Permit). Вкратце суть такая — своим приватным ключом вы подписываете некоторую информацию, передаете получившееся как угодно (хоть сообщением в телеграме) другому юзеру, а он со своего Ethereum кошелька может предъявить в смарт контракт этот "чек" и забрать токены. А может не забирать, подождать (хотя вроде это небезопасно).
Этот стандарт нужен для того, чтобы пользователь, передающий токены, не платил за газ (что-то знакомое 🤔)

По сути, это аналог выписывания чека, чтобы получатель должен был самостоятельно зайти в банк и его обналичить. Забавно, что функция в proposal так и называется — sendByCheque.

С переносом данного стандарта в TON есть некоторая проблема. Дело в том, что в Ethereum сущности смарт-контракта и кошелька пользователя (External Owned Account — EOA) разделены. Таким образом, если у вас есть приватный ключ, вы точно знаете, какой кошелек (адрес) в EVM сети ему соответствует. При предъявлении чека токен использует функцию ECRECOVER, восстанавливает кошелек (адрес) отправителя, и переводит его токены владельцу чека.
В TON всё является смарт-контрактом, поэтому однозначно восстановить по подписи адрес затруднительно. Однако всегда можно что то придумать, если будет нужно.

😐 Так что, наверное, Ethereum является топ-1 блокчейном мира по off-chain передаче токенов. Пока.
@TheOpenDevBlog

🔥 Наш блог меняет TON.

Уже довольно давно мы писали обзор на (на наш взгляд) устаревший стандарт жетона, и спустя некоторое время выяснилось, что наш разбор приняла во внимание команда TON Studio!
Они выпустили стандарт «богатого на фичи» жетона (так и называется), в который имплементировали возможность:

⚫️ Деплоя контракта через трансфер жетона
⚫️ Отправки всех жетонов (shut up and take my money)
⚫️ Отказа от деплоя jetton wallet получателя

Реализовано это через заранее предусмотренное поле custom_payload (которое почти не использовалось) у любых жетонов. Отправляешь нужный mode (первые 32 бита custom_payload), и jetton wallet формирует сообщение в соответствии с заданным модом. Минтлесс жетон в такой ситуации остается out-of-scope, планов совмещать эти два стандарта пока нет (да и надо ли?)

Контракты, разумеется, написаны на tact, репа тут, берегитесь комментов под постом.

Кстати, по соседству находится шард оптимизированный жетон (jetton wallet всегда находится в 1 шарде с владельцем), который, видимо, станет новым основным стандартом жетона в самом скором времени (не обязательно имплементация на tact).

Мы в @bidask недавно воспользовались контрактами NFT на tact, и остались довольны. Будем сотрудничать и поддерживать Ton Studio и дальше — они делают крутую работу.

Богатейте фичами, а не мемами
@TheOpenDevBlog

🔥 Денис Васин в недавнем своем опусе написал, что рекомендация засовывать целые протоколы в один шард — это "похороны изначальной идеи масштабирования".

Хоть мы в @bidask и не занимаемся подобным, у нас только каждый отдельный пул в одном шарде, но нам эта мысль не кажется очевидной. Что думаете?