The Open Dev Blog

The Open Dev Blog

Contact: @rends_east, @therealmaloleg or @bazrov

Username
@theopendevblog
Category
Cryptocurrencies
Country
RussiaRussia
Created
, 2 years
Subscribers1,346−9 in 4 days
Avg views per post, 7d579−51.3% vs prev 7d
ERR43.02%last 7 days

Subscribers, 30 days

Oct 31 – Nov 4−9 (−0.7%)

Show as table
DateSubscribers
Oct 31, 20261,355
Nov 1, 20261,353
Nov 2, 20261,352
Nov 3, 20261,353
Nov 4, 20261,346

Average views per post by day

By publication day

Show as table
DateAvg views per post
Oct 25, 20261,190
Oct 29, 2026726
Nov 1, 2026655
Nov 3, 2026356

Most viewed this month

  1. 01
    Views1.19K
    Forwards18
    Reactions102
    Comments33
  2. 02
    Views726
    Forwards7
    Reactions15
    Comments19
  3. 03
    Views655
    Forwards5
    Reactions15
    Comments11
  4. 04

    🔥 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

    Text
    Views356
    Forwards9
    Reactions31
    Comments2

Latest posts

#149Text

🔥 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

Open in Telegram
Views356−51%vs avg
Forwards9
Reactions31
Comments2
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
2 h231
14 h356
  1. After 1 hour231
  2. Total to date356
#148Text
Views655−10%vs avg
Forwards5
Reactions15
Comments11
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
6 h336
18 h627
30 h655
  1. After 6 hours336
  2. After 24 hours655
  3. Total to date655
#147Poll
Views726−1%vs avg
Forwards7
Reactions15
Comments19
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
39 h689
69 h726
  1. Total to date726
#146Text
Views1,190+63%vs avg
Forwards18
Reactions102
Comments33
#145Text

🔥 Что же случилось с сетью? Повысим прозрачность. Недавно выживших в 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

Open in Telegram
Views5,676+676%vs avg
Forwards28
Reactions77
Comments7
#144Text

🔥 Инфляция 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

Open in Telegram
Views4,264+483%vs avg
Forwards23
Reactions68
Comments8
#142Textedited
Views4,212+476%vs avg
Forwards62
Reactions62
Comments23
#139Text

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

Open in Telegram
Views2,086+185%vs avg
Forwards7
Reactions57
Comments13
#136Textedited

🔥 Почему 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

Open in Telegram
Views11,005×15vs avg
Forwards64
Reactions142
Comments19

All posts

Connections