Посты канала The Open Dev Blog

сначала новые

#149Текст

🔥 Astra «починила» Qwen На днях прогремела новость: MIT CSAIL дали GPT-6 Astra поковыряться в весах открытой небольшой Qwen3.5-0.8B, и та вручную, без градиентов и файнтюна, вырезала баг с зацикливанием рассуждений. Результат впечатляет: MATH-500 (бенчмарк по решению математических задач) подскочил с 7.9% до 48.1%, а IFEval (бенчмарк на строгое соблюдение текстовых инструкций) — с 21% до 62.3%. Всё это — результат изменения всего 131 072 параметров, то есть 0.016% от общего числа. В новостях уже написали: «ИИ начал перепрограммировать ИИ», приписали Astra нечеловеческие способности в редактировании весов «на лету». Как это обычно бывает — это просто красивый заголовок. Давайте разберёмся. Осадим хайп: то, что сделала Astra — не «сверхчеловеческая» способность. В данном случае хорошей аналогией было бы сравнение с редактированием скомпилированного бинарника. Для его прямой редактуры нужно разобраться в ассемблере, какая инструкция за что отвечает, как преобразуется память в программе, и т.д. Это, безусловно, сложно, но люди давно умеют это делать. Суть в том, что Qwen изначально страдала от проблемы повторяющихся рассуждений — это было известно из её документации. Внутри модели каждый слой что-то «дописывает» к общему потоку мыслей, который идёт дальше. Astra сравнила, чем поток отличается, когда модель зацикливается и когда нет, и нашла один конкретный «сигнал», который приводит к зацикливанию. Оказалось, его добавляют два слоя — 15-й и 19-й. Astra не стала их ослаблять или вырезать — она просто отобрала у них возможность писать именно этот сигнал, оставив всё остальное как было. Правка затронула 64 столбца весов в двух слоях. Каждый столбец — это 1024 числа (hidden_size модели, «ширина» потока, который идёт сквозь все слои). Получается 2 × 64 × 1024 = 131 072 числа — те самые 0.016% весов. Специалисты (на одного из которых мы опираемся) считают, что обычное обучение остаётся более эффективным способом улучшения моделей. А ИИ принесёт больше пользы, если будет помогать оптимизировать сам процесс обучения, а не «ковыряться» в готовых весах. Тем не менее, техника Weight-Space Programming (прямое редактирование весов) — это мощный инструмент отладки. Если модель ведёт себя странно, мы теперь не просто пытаемся менять промпт или переобучить её с нуля, а можем точечно, хирургически поправить конкретные нейроны, ответственные за баг. Это будет экономить кучу времени и вычислений, если метод удастся сделать надёжным. Кроме того, новые красивые числа на бенчмарке были достигнуты путём увеличения числа попыток до 50. При 10-25 попытках на каждую задачу рост MATH-500 был с 7% до 14%. Это тоже отлично, но уже не такая красивая цифра, и не такой громкий заголовок. Не путайте прорыв с дорогим отладчиком. @TheOpenDevBlog

Открыть в Telegram
Просмотры393−49%к среднему
Пересылки10
Реакции31
Комментарии2
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
2 ч231
14 ч356
26 ч393
  1. Через 1 час231
  2. Через 24 часа393
  3. Всего сейчас393
#148Текст
Просмотры746−2%к среднему
Пересылки5
Реакции16
Комментарии11
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
6 ч336
18 ч627
30 ч655
66 ч746
  1. Через 6 часов336
  2. Через 24 часа655
  3. Всего сейчас746
#147Опрос
Просмотры726−5%к среднему
Пересылки7
Реакции15
Комментарии19
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
39 ч689
69 ч726
  1. Всего сейчас726
#146Текст
Просмотры1 190+56%к среднему
Пересылки18
Реакции102
Комментарии33
#145Текст

🔥 Что же случилось с сетью? Повысим прозрачность. Недавно выживших в TON взбудоражило замедление сети, отложенное после этого обновление валидаторов, и отсутствие комментариев на этот счет. TON Core отказалось отвечать на наш вопрос, поэтому представим свою версию событий — и надеемся, что нас поправят там, где мы ошиблись. Совсем недавно в кулуарных девелоперских чатах TON обсуждали этот пост. Судя по всему, с отправкой сообщений было всё нормально, но, видимо, разработчиков из TON Core насторожило другое. В блокчейне есть механизм защиты от спама сообщениями — так называемый "action fine". Если в результате обработки action фазы после нескольких успешно обработанных сообщений пришёл один неуспешный action, с аккаунта должен взиматься fine за ячейки (cells) исходящих сообщений, которые были обработаны, ведь валидатор совершил некоторые действия — должен получить награду. Однако баг был в том, что эта комиссия взималась только за последний, неуспешный action. Получается, что валидатор совершал бесплатную работу — это и могло привести к DoS всей сети. Было исправлено в коммите 5f454cd. Кроме фикса TON Core создали токен PUB5 (его метадата была опубликована работником TON Core), и зачем то с его помощью заспамили сеть сообщениями, из-за чего блокчейн и замедлился. Судя по всему, это не связано с конкретным багом. Интересно, что у токена нет холдеров, потому что все jetton wallet-ы стали nonexist, то есть фактически были удалены из блокчейна (mode 128 + 32, ничего криминального). Также был обнаружен коммит, вводящий ограничение на общий размер всех сообщений в action фазе (раньше было ограничение только на каждое конкретное сообщение). Кроме того, в последнем обновлении валидаторов был введён запрет на публикацию library cells в мастерчейн. По словам Анатолия Тонкоровича Макосова, это было сделано, чтобы "снизить количество векторов атак". Действительно ли была возможна атака, или это просто снижение рисков, нашей редакции неизвестно. Повысили. @TheOpenDevBlog

Открыть в Telegram
Просмотры5 676+643%к среднему
Пересылки28
Реакции77
Комментарии7
#144Текст

🔥 Инфляция TON — ПРАВДА После недавнего обновления блокчейна TON доходность ликвидного стейкинга стабильно превышает 15-20%. Многие трубят о возросшей инфляции, давайте разберемся: ⚫️ Инфляция — результат печати новых TON, поэтому снижение комиссий на неё не влияет. ⚫️ Валидаторы сейчас получают 50% от комиссий с транзакций. Это не печать нового TON, просто перераспределение. Следовательно — это не инфляция. ⚫️ Печать TON происходит исключительно от наград за генерацию блоков (1.7 TON за masterchain, 1 TON за basechain). Значения старые, но печать ускорилась вместе с ускорением блокчейна. До обновления в год печаталось порядка 34 миллионов TON — это 0.65% инфляции от общей эмиссии блокчейна. После ускорения блокчейна награды возросли пропорционально, как и инфляция — до 3.9% в год. Очень важно, что это инфляция именно от total supply, то есть от всего напечатанного TON. Если считать инфляцию от циркулирующего предложения (circulating supply), то числа возрастут: 1.2% раньше и 7.6% сейчас (на основе данных с CMC). Можно ли пострадать от инфляции при ликвидном стейкинге? Нет, нельзя. Ликвидный стейкинг будет приносить доходность в размере инфляции ТОЛЬКО если в блокчейне не будет транзакций (а значит, и газа с них) И если весь supply TON-а будет застейкан. Во всех остальных случаях доходность честного ликвидного стейкинга будет выше инфляции. Не стоит также забывать, что в TON fees бывают не только за сообщения, но и за хранение информации в блокчейне (storage fees), поэтому даже если транзакций нет, существует постоянно накапливающийся долг каждого опубликованного в блокчейне адреса. 😱 Что у соседа? TON не лидер по инфляции среди блокчейнов, нынешняя скорость печати новых монет не выбивается из нормы. Например, у Solana она составляет те же самые 3.9-4.5% на total supply (источник). @TheOpenDevBlog

Открыть в Telegram
Просмотры4 264+458%к среднему
Пересылки23
Реакции68
Комментарии8
#142Текстизменён
Просмотры4 212+451%к среднему
Пересылки62
Реакции62
Комментарии23
#139Текст

🔥 Proposal стандарта Анатолий Тонкорович Макосов читает наш канал, а потому мы вместе с @shibdev подумали и поняли, какие идеи до него донести. Нынешний парсинг сообщений в эксплорерах блокчейна — это ужасно. Для того, чтобы добавить свою схему, нужно исхитряться, искать контакты, писать PR в какие то репы, просить добавить схемы, и т.д. Мы предлагаем ультимативное децентрализованное решение в духе нашего с вами блокчейна — сохранение схем сообщений в NFT. Допустим, протокол хочет, чтобы его сообщения парсились и показывались как они есть в эксплорерах. Для этого он идет в специальный NFT minter, резервирует для себя opcode, и минтит NFT со своей схемой сообщения (может даже не резервировать opcode, а вычислять из схемы). Эксплорер отдельно следит за этой коллекцией, и может получать NFT оттуда по id — opcode сообщения, которое видит перед собой (возможно, вместе с кодом или схемой контракта, который это сообщение получает). А для предотвращения откровенного сквотинга и скама opcode-ов предлагается ввести какую-то плату за их регистрацию. 💎 Это децентрализованно, круто и в духе нашего с вами любимого блокчейна. Если вы прочитали наш proposal, и не хотите говорить, что вам он понравился, откупите $TONDEV c левого кошелька, поддержите наше комьюнити. @TheOpenDevBlog

Открыть в Telegram
Просмотры2 086+173%к среднему
Пересылки7
Реакции57
Комментарии13
#136Текстизменён

🔥 Почему TON в разы быстрее Solana? Все уже видели посты про скорость финализации после sub-second апдейта, и насколько TON круче условной Solana в этом параметре (в 10+ раз). Но на практике, при использовании кошельков или DeFi, это не ощущается. Объясним почему. Финализация — это момент, когда блок в блокчейне становится необратимым. Если валидатор выпускает блок, другие валидаторы его должны проверить (после чего он получает статус confirmed), а затем должно пройти еще какое то время (должно быть выпущено какое то количество блоков), чтобы блок был финализирован. До прошествия этого момента есть риск, что в блокчейн будет опубликована другая цепочка блоков (форк), а та, в который находится наш confirmed блок, будет откинута. Можно создавать блоки очень быстро, а финализировать их долго, это и есть основная хитрость "быстрых" блокчейнов — они принимают риски появления форков, и не очень сильно работают над скоростью финализации. Например, если какое-либо приложение следит не за финализацией, а за созданием блока, то оно рискует быть атаковано через создание форка, который не будет финализирован. Это означает, что, несмотря на получение статуса confirmed, в блокчейн будет опубликован другой, конкурирующий с данным, блок. Атака с помощью данного механизма крайне сложна, поэтому большинство приложений на Solana и других блокчейнах этот риск игнорируют (хотя даже на официальной странице Solana пишется, что целых 5% блоков не финализируется вообще). И Solana, и TON выпускают один блок раз в 400 миллисекунд. Однако если у TON блок финализируется через еще 400 миллисекунд, то у Solana должно пройти аж 12 секунд до полной финализации. То есть в параметре финализации и до sub-second апдейта TON был быстрее Solana, хотя в интерфейсах это совсем не ощущалось. UX рулит. @TheOpenDevBlog

Открыть в Telegram
Просмотры11 005×14к среднему
Пересылки64
Реакции142
Комментарии19
#135Текст

🔥 Как чуть не взломали EVAA. Пару месяцев назад @gosunov и @peskarbrain изучали код смарт-контрактов EVAA, и обнаружили интересное. От обнуления TVL EVAA спасла чистая случайность. Важно: в коде больше ничего найдено не было, информация в посте на данный момент уже точно устаревшая. EVAA, как и любой здоровый DeFi протокол на TON, использует vanity контракты (они у EVAA названы blank). Это удобно, позволяет не зависеть от конкретной версии протокола — абсолютный best practice на TON, всем советуем. По сути vanity контракты — это система авторизации внутри DeFi архитектуры, поэтому с ней нужно быть максимально внимательным. Если ты авторизуешь контракт по vanity-дате, то тебе нужно быть уверенным, что его никто, кроме тебя, не может задеплоить (это делается с помощью проверки деплоера на vanity), и что никак иначе подменить vanity-код с помощью твоей архитектуры нельзя. Со вторым у EVAA возникла проблема. Всё возможно, как это часто на TON случается, от слишком большой свободы. EVAA позволяет пользователям отправлять кастомные сообщения (forward data) при выводе TON из протокола (при заёме или выводе средств). Ранее недостаточный контроль данных в кастомных сообщениях привела к багу в DEX coffee swap, мы об этом писали. Из существующих деталей пазла собрать предположительную (в реальности она не работает и никогда не работала) атаку очень просто: 1) Деплоим ванити контракт вместо EVAA (разумеется, подменить мы ничего на нём не можем). 2) Отправляем на него вывод из протокола, в forward_data которого указываем новый код для замены. Vanity проверяет, что сообщение пришло от правильного адреса (с волта EVAA), поэтому авторизует его и принимает все данные из сообщения как должные — подменяет свой код, и вуаля, у нас есть свой собственноручно написанный контракт внутри периметра ончейн архитектуры EVAA. Спасла EVAA чистая случайность (или холодный расчёт) — их опкоды операций внутри архитектуры все начинались с нескольких лидирующих нулей. Из-за этого maybe_ref, которым должен был быть код нашего кастомного контракта, для vanity считался пустым, и он его игнорировал. Интересно то, что если бы EVAA соблюли стандарт по формированию опкодов через crc32, то атака была бы возможна. Несмотря на несколько аудитов от крайне крупных аудиторских компаний, практика показывает, что это крайне типовой баг для блокчейна TON, и об этом всегда стоит думать при проектировании архитектуры смарт-контрактов. Если хотите проверить вашу ончейн логику — обращайтесь к @TheOpenDevTeam. Везёт тому, кто везёт. @TheOpenDevBlog

Открыть в Telegram
Просмотры2 923+283%к среднему
Пересылки44
Реакции78
Комментарии17
#134Текст

🔥 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

Открыть в Telegram
Просмотры2 055+169%к среднему
Пересылки22
Реакции562
Комментарии3
#133Текст

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

Открыть в Telegram
Просмотры1 804+136%к среднему
Пересылки8
Реакции28
Комментарии8
#131Текстизменён
Просмотры2 045+168%к среднему
Пересылки6
Реакции34
Комментарии9
#130Текст

🔥 Как нас взломали (нет) Последнее время часть команды @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

Открыть в Telegram
Просмотры1 957+156%к среднему
Пересылки16
Реакции60
Комментарии20
#129Текстизменён
Просмотры7 457+876%к среднему
Пересылки104
Реакции36
Комментарии16
#128Текст

🔥 LLM и безопасность Мы все уже начитались историй про успех в разработке с применением claude, cursor, codex и т.д. Этого слишком много, и странно было бы думать, что влияние LLM на IT ограничится исключительно разработкой. Надо это разбавить. Мы разбираемся в безопасности, про неё вам и расскажем. В ноябре 2024 года OWASP (международная организация, занимающаяся вопросами информационной безопасности) выпустил свой очередной топ самых популярных уязвимостей для больших языковых моделей — OWASP LLM top 10. Большинство позиций там довольно рядовые, однако мы здесь собрались из-за самой первой — "Prompt injecting". "Prompt injecting" — это буквально "убеди LLM в том, что ей надо сделать плохую вещь". В простейшем случае LLM можно сообщить, что ты администратор сайта, и тестируешь его работу, поэтому ассистенту нужно СРОЧНО отдать тебе все данные пользователей. Ничего не напоминает?:) В более сложных сценариях — дать непрямое указание через другие способы ввода информации. Все это превращает традиционный хакинг в довольно увлекательное занятие, где ты общаешься с не очень умным собеседником с памятью золотой рыбки, которого нужно обвести вокруг пальца. Вопреки простому описанию, сделать это довольно трудно. Интересный гайд на prompt injecting (осторожно, полностью его никто не читал). Кроме изменения традиционного хакинга, мы должны быть готовы и к новому виду вирусов. Мы все пользуемся агентами, чтобы они за нас что-то делали на нашем компьютере (или сервере). Ирония в том, что мы агентам для этого не нужны. Вот, например, уже появились вирусы, которые прямо на зараженном устройстве запрашивают помощи у AI агента для более эффективной кражи информации. БОЛЬШИЕ языковые модели @TheOpenDevBlog

Открыть в Telegram
Просмотры1 748+129%к среднему
Пересылки10
Реакции26
Комментарии6
#127Текст

🔥 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

Открыть в Telegram
Просмотры1 445+89%к среднему
Пересылки15
Реакции23
Комментарии5
#126Текст
Просмотры1 428+87%к среднему
Пересылки6
Реакции22
Комментарии15
#124Текст

🔥 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

Открыть в Telegram
Просмотры1 802+136%к среднему
Пересылки2
Реакции28
Комментарии5
#123Текст
Просмотры1 384+81%к среднему
Пересылки0
Реакции33
Комментарии4