Давно не писал, есть чем поделиться.

📟 Прилетело из @invmru

На таком грустном рынке тестирую другие направления. Одним из них, с некоторой полезностью, оказался эвристический анализ смарт-контрактов.

Алгоритм поиска - тема для отдельного поста.

Veil - аналог Tornado Cash на ZK-SNARKs. Проверка подписи была реализована некорректно - оказалось возможным забрать чужие депозиты, передав слабую подпись (подробнее тут).

Атака на пул "0.1 ETH": basescan

Остальные пулы через 10 минут засекьюрил Defimon - я ограничил доступ проверкой на owner, но они обошли её и закрыли уязвимость: defimon

Через пару дней Defimon засекьюрили foom.cash от схожего бага:
- alert
- разбор от ZK Security

Какие были варианты:
- Whitehat - искать выход на команду, сабмитить баг-баунти репорт, рассчитывать на вознаграждение (ориентир 5–10% от суммы под риском). Но не факт, что этим путём удалось бы вовремя засекьюрить foom.
- Grayhat - сам определил размер комиссии за находку, не проверил другие пулы.
- Blackhat - мог не возвращать ничего.

Упущенный потенциал:
У foom.cash есть treasury на баг-баунти в размере $500K, а Defimon засекьюрили $1.1M - потенциал на выплату $110K+. Плюс Veil могли обнести blackhat'ы подчистую,
повторив вектор.

Первый живой кейс. Действовал на адреналине, без чёткого плана. Позже вернул большую часть.

Ончейн-пруф с упоминанием этого канала (прочитать input data как UTF-8): basescan

📟 Прилетело из @invmru

gm! Виталик установил OpenClaw тоже принял AI

Как истинный шифропанк он установил локальную модель gpt-oss:20b, и в твите пофлексил тем, что за час переписал свою платформу для ведения блога. При этом, офк, он понимает, что нормальная модель справилась бы с этим за one shot.

Но тред не про вайбкодинг. Виталик написал тред про то, как AI должен использоваться в разработке Ethereum. И его позиция неочевидная.

the right way to use it, is to take half the gains from AI in speed, and half the gains in security: generate more test-cases, formally verify everything, make more multi-implementations of things

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

Формальная верификация — это когда корректность программы доказывается как теорема. Не "прогнали тесты, coverage 95%", а математическое доказательство, что при любых входных данных контракт ведёт себя правильно. До сих пор это стоило столько, что делали только там, где баг приводит к ужасным проблемам. На вскидку даже не нашел смарт-контракты с реализованной формальной верификацией сейчас из дефи топа. Верифицировать 20-строчный контракт стоило дороже, чем написать.

Один из контрибьюторов Lean Ethereum с помощью AI написал machine-verifiable proof для одной из самых сложных теорем, на которых стоит безопасность STARKs. Из людей, кто реально понимает всю эту цепочку до конца — может пара сотен в мире. И вот для этой математики теперь пишутся формальные доказательства с помощью AI.

bug-free code, long considered an idealistic delusion, will finally become first possible and then a basic expectation

Bug-free code — который всю жизнь считался бредом идеалистов — скоро станет сначала возможным, а потом базовым ожиданием. Виталик прямо это говорит. Для блокчейна, где весь смысл в том что ты не доверяешь никому, это необходимая часть пазла.

При этом без розовых очков — "there WILL be lots of wrestling with bugs and inconsistencies between implementations". Но эта борьба будет идти в 5x быстрее и 10x тщательнее.

В исходной цитате треда — чел, который за две недели один написал Ethereum-клиент на весь роадмап 2030+. 702K строк Go, синхронизируется с мейннетом. Виталик признаёт — там полно стабов и багов. Но полгода назад даже это было невозможно.

Но глядя на Виталика мне кажется, что до сингулярности ещё далеко.

https://x.com/VitalikButerin/status/2027781104288317837

📟 Прилетело из @insuline_eth

@gosunov_ch в комментах подсказал, что DAI – неплохой пример, чтобы разобраться, что это такое на примере смарт-контракта. Вот чем можно заменить думскроллинг новостей на сегодня🕊

https://github.com/sky-ecosystem/dss

📟 Прилетело из @insuline_eth

Алгоритмы. Алгоритм Дейкстры

Рассматривая этот алгоритм, я все никак не мог привыкнуть читать его как Дейкстры. Каждый раз в голове крутился образ персонажа из Ведьмака - шпиона Диикстры. При этом на английском языке они пишутся одинаково - Dijkstra. Но забудем об этом и вернемся к нашему алгоритму.

Представьте карту городов, соединённых дорогами. Каждый город можно представить как вершину графа, каждая дорога — как ребро, а расстояние между городами — как вес ребра. Например, рассмотрим такой граф:

    A ──1── B
    │       │
    4       2
    │       │
    C ──────D
        1

Если мы хотим добраться из A в D по кратчайшему пути, то на глаз ответ не всегда очевиден. Именно для решения таких задач и существует алгоритм Дейкстры, который находит кратчайшие пути от одной вершины до всех остальных во взвешенном графе с неотрицательными весами рёбер.

Прежде чем углубляться, стоит уточнить ключевые понятия. Граф — это набор точек (вершин), соединённых линиями (рёбрами). Вес ребра — это число, стоящее на ребре и обозначающее стоимость перехода (расстояние, время, цена и т.п.). Взвешенный граф — это граф, где у каждого ребра есть вес. Кратчайший путь — это маршрут с минимальной суммой весов рёбер. Алгоритм Дейкстры относится к классу жадных алгоритмов: на каждом шаге он выбирает локально лучший вариант, то есть вершину с наименьшим известным расстоянием от старта.

Идею алгоритма можно объяснить простыми словами: вы стоите в начальной точке и хотите узнать расстояния до всех остальных городов. Вы постепенно открываете для себя новые города, всегда переходя сначала в тот, до которого сейчас ближе всего. При этом, попадая в новый город, вы проверяете, не стали ли теперь известные пути до его соседей короче. Этот процесс повторяется, пока не будут обработаны все вершины. Иными словами, на каждом шаге мы идём в ближайший ещё не посещённый город и обновляем расстояния до его соседей.

Рассмотрим работу алгоритма на конкретном примере. Пусть дан граф:

    A ──1── B
    │     ╱ │
    4   2   5
    │ ╱     │
    C ──1── D

Рёбра и их веса:
- A–B: 1
- A–C: 4
- B–C: 2
- B–D: 5
- C–D: 1

Начальная вершина — A. В начальный момент мы знаем расстояние только до самой себя (ноль), а до всех остальных вершин расстояние полагаем бесконечным. Состояние можно описать так:

Расстояния:  A=0,  B=∞,  C=∞,  D=∞
Посещены:    {}
Очередь:     [(0, A)]

Извлекаем из очереди вершину A с расстоянием 0. Рассматриваем её соседей: до B можно добраться за 0+1=1, что меньше бесконечности, поэтому обновляем расстояние до B. До C можно добраться за 0+4=4, обновляем C. После этого состояния становятся такими:

Расстояния:  A=0,  B=1,  C=4,  D=∞
Посещены:    {A}
Очередь:     [(1, B), (4, C)]

Теперь из очереди выбираем вершину с наименьшим расстоянием — это B (расстояние 1). Из B можно пойти к A (но расстояние 1+1=2 больше уже известного 0, поэтому пропускаем), к C (1+2=3, что меньше текущего 4, обновляем C до 3) и к D (1+5=6, обновляем D с бесконечности до 6). После этого:

Расстояния:  A=0,  B=1,  C=3,  D=6
Посещены:    {A, B}
Очередь:     [(3, C), (4, C_old), (6, D)]

Обратите внимание: в очереди теперь есть два элемента для вершины C: (3, C) и (4, C_old). Это старая запись, которая будет проигнорирована позже.

Следующая ближайшая вершина — C с расстоянием 3. Проверяем соседей: до A (3+4=7 > 0), до B (3+2=5 > 1), до D (3+1=4 < 6) — обновляем D до 4. После обновления:

Расстояния:  A=0,  B=1,  C=3,  D=4
Посещены:    {A, B, C}
Очередь:     [(4, D), (4, C_old), (6, D_old)]

Наконец, извлекаем D с расстоянием 4. Её соседи уже посещены или не дают улучшений. Алгоритм завершается. Итоговые расстояния:

- A = 0
- B = 1
- C = 3
- D = 4

Кратчайшие пути из A:
- A → A : 0
- A → B : A → B (вес 1)
- A → C : A → B → C (1 + 2 = 3)
- A → D : A → B → C → D (1 + 2 + 1 = 4)

📟 Прилетело из @solidityset

Теперь разберём реализацию алгоритма на языке Python с использованием модуля heapq, который предоставляет приоритетную очередь. Приоритетная очередь отличается от обычной тем, что всегда возвращает элемент с наименьшим ключом (в нашем случае — расстоянием). Это как раз соответствует жадному выбору ближайшей вершины.

import heapq  # Модуль для приоритетной очереди (мин-куча)

def dijkstra(graph, start):
    # 1. Инициализация: все расстояния = бесконечность
    distances = {node: float("infinity") for node in graph}
    distances[start] = 0  # До стартовой вершины — 0

    # 2. Приоритетная очередь: (расстояние, вершина)
    # heapq всегда отдаёт элемент с МИНИМАЛЬНЫМ расстоянием первым
    priority_queue = [(0, start)]

    while priority_queue:
        # 3. Извлекаем вершину с наименьшим расстоянием
        current_distance, current_node = heapq.heappop(priority_queue)

        # 4. Устаревшая запись? Пропускаем
        # (в очереди могут быть старые версии с большим расстоянием)
        if current_distance > distances[current_node]:
            continue

        # 5. Обходим соседей
        for neighbor, weight in graph[current_node].items():
            distance = current_distance + weight

            # 6. Нашли более короткий путь? Обновляем!
            if distance < distances[neighbor]:
                distances[neighbor] = distance
                heapq.heappush(priority_queue, (distance, neighbor))

    return distances

Поясним некоторые детали реализации. Строка if current_distance > distances[current_node]: continue необходима для отбрасывания устаревших записей в очереди. Когда мы обновляем расстояние до вершины (например, C с 4 на 3), старая запись (4, C) остаётся в куче. Когда она позже извлекается, мы проверяем, что её расстояние больше текущего известного, и просто пропускаем её. Это экономит время и корректирует работу алгоритма.

Важно понимать, почему используется именно приоритетная очередь. Если бы мы каждый раз искали минимум простым перебором, сложность стала бы квадратичной. Благодаря этому мы получаем эффективность: каждая операция извлечения минимума и вставки стоит O(log V), где V — число вершин.

Сложность алгоритма Дейкстры с приоритетной очередью составляет O((V + E) log V), где V — количество вершин, E — количество рёбер. Для большинства реальных задач, таких как прокладка маршрутов на карте или в сетях, это приемлемо быстро.

Однако у алгоритма Дейкстры есть важное ограничение: он работает только с неотрицательными весами рёбер. Почему это так? Дело в том, что алгоритм основан на гарантии: когда вершина извлекается из очереди с минимальным расстоянием, это расстояние уже окончательное и не может быть улучшено позже. Если бы существовали отрицательные рёбра, то путь через другую вершину, ещё не обработанную, мог бы дать меньшее расстояние, даже если текущая вершина уже «закрыта». Рассмотрим простой пример:

A ──2── B ──(−5)── C
A ─────────4───── C

Дейкстра из A сначала установит расстояния: B=2, C=4. Затем извлечёт B (расстояние 2) и пометит его как финальное. При обработке B он обновит C: 2 + (−5) = −3, и это станет новым расстоянием до C. Однако теперь уже поздно пересматривать пути через другие вершины, потому что B уже обработан. В этом конкретном случае мы всё же получим правильный ответ, но в более сложных графах с отрицательными весами могут возникнуть ситуации, когда оптимальный путь требует пересмотра уже обработанных вершин, что невозможно в рамках алгоритма Дейкстры. Более того, отрицательные веса могут создавать циклы с отрицательной суммой, которые делают понятие кратчайшего пути вообще неопределённым (можно бесконечно уменьшать стоимость, обходя цикл).

Если в графе присутствуют отрицательные веса, следует использовать алгоритм Беллмана–Форда. Он не полагается на жадный выбор и не делает предположений о финальности расстояний. Вместо этого алгоритм выполняет V−1 проходов по всем рёбрам, каждый раз пытаясь улучшить расстояния. Вот его простая реализация:

📟 Прилетело из @solidityset

def bellman_ford(graph, start):
    distances = {node: float("infinity") for node in graph}
    distances[start] = 0

    for _ in range(len(graph) - 1):  # V-1 итераций
        for node in graph:
            for neighbor, weight in graph[node].items():
                if distances[node] + weight < distances[neighbor]:
                    distances[neighbor] = distances[node] + weight

    return distances

Сложность Беллмана–Форда выше — O(V·E), но он способен обнаруживать отрицательные циклы и, соответственно, определять, что задача не имеет решения. Сравним два подхода:

- Дейкстра: работает только с неотрицательными весами, быстрее (O((V+E) log V)).
- Беллман–Форд: работает с любыми весами, медленнее (O(V·E)), может обнаруживать отрицательные циклы.

В реальной жизни алгоритм Дейкстра широко применяется. Например, в GPS-навигаторах (Google Maps, Яндекс.Карты) города или перекрёстки — это вершины, дороги — рёбра, а весом может быть время в пути. Алгоритм находит маршрут с минимальным временем. В интернете протоколы маршрутизации, такие как OSPF, используют алгоритм Дейкстры для определения кратчайшего пути передачи пакетов данных (вершины — роутеры, рёбра — каналы связи, вес — задержка или пропускная способность). В игровых движках NPC (неигровые персонажи) находят путь по карте с препятствиями. В системах поиска авиабилетов вершинами выступают аэропорты, рёбрами — рейсы, а весом — стоимость или время, что позволяет находить самые дешёвые или быстрые маршруты с пересадками.

#algorithm

📟 Прилетело из @solidityset

Порадуемся за них, от чистого сердца

📟 Прилетело из @invmru

Detailed report from Foom.cash

https://x.com/Foomclub_/status/2028231845788188747

📟 Прилетело из @invmru

Выбирайте Deepseek, если подписок нет, а интересно глянуть результат

(у них оказывается подписки то и нет, только платный api)

📟 Прилетело из @insuline_eth

Мой AI-сетап FW2026

Claude Code за $100. Планирование и agentic таски: перс ассистент, сетап VDS, всё что требует контекст и рассуждение. Планирование через superpowers

Codex за $200. Чисто code execution. Все матёрые OG разрабы пишут на нём. Плох в планировании и вайб-кодинге, когда не знаешь чего хочешь. Но если знаешь — улетает.

Ещё один трюк — cross-review. Задачу оформляю в Claude Code через брейншторминг, собираем план и финал скидываю кодексу на проверку. Кодекс доточенный к деталям: хорошо ловит ситуации когда хотим реализовать функцию, но забыли поддержку в другом месте или тест не написали. Клод чаще соглашается. Кодекс ищет.

IDEшка Zed, но в 90% случаев хватает Ghostty. Ещё понравился Codex App: удобный интерфейс для ревью изменённых файлов, работает быстро. Жду T3Code от Theo.

Был бы broke – оставил только кодекс. Токенов в разы больше, модели с контекстом работают лучше. Клод даже за один небольшой промпт у меня 30-40к контекста съедает при отсутствии system prompts и mcp. При этом работаю часто в 2-3 потока одновременно и на кодексе до 50% лимита ни разу не добирался, а клод периодически отлетает.

Antigravity не пробовал, как и курсор. Не очень понимаю как посредники работают с моделями.

Gemini пока не тестировал, но хочу скоро потестить с Pi agent. Модель вроде до сих пор плохо работает с tool calling.

📟 Прилетело из @insuline_eth

Привет я Killian и я:
> Заплатил за эту рекламу чтобы привлечь именно тебя!
> Веду и монетизирую свой Twitter уже 3 года.
> Рассказываю аудитории как зарабатывать на ретродропах, ролях и media fluence.
> Зарабатываю на абузах крипто проектов и фарме дропов.

Интересно? Подписывайся

чем больше вас подпишется тем больше вероятность, что у инфлюенсера которого вы читаете повторно купят рекламу, думайте🫡

📟 Прилетело из @in_crypto_info

Почему люди переоценивают аудиты? Избавляемся от ложного чувства безопасности.

Мы смотрим отчёты сами, читаем их у других. И, когда видим, что все проблемы исправлены, думаем: "Можно вкладываться". Как будто сам факт аудита автоматически снижает риск.

Но это не гарантия надёжности.
Аудит - это проверка конкретной версии кода в конкретный момент времени.

Я в своей аналитике тоже всегда упоминаю про аудиты в "Код" и даже повышаю оценку проекту в случае их наличия с исправленными проблемами.

Но последнее время стал обращать внимание на следующее:

1. Когда проходил аудит?
Из последнего: Edgex аудит был в 2024-2025 годах, а они периодически обновляются. Сейчас 2026!
Это уже нельзя считать актуально проверенным кодом.

2. Иногда пишут про аудиты, но на самом деле это не основные компоненты. Обычные люди не поймут. Поэтому важно скармливать файлы ИИ и спрашивать, основные компоненты проекта или нет.
Опять же, в Edgex был Starkex и мультисиг/роутер ввода-вывода.
Но сам код движка dex либо не аудировался, либо не публиковали об этом инфу.

А это критично.

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

Изучающие же аудит не обратят на это внимание, и для них будет полной неожиданностью такая дестабилизация.

3. ИИ ускоряет поиск уязвимостей.
Для справедливости скажу, что и пытаются найти их для исправления тоже. Тот же Виталик Бутерин об этом писал.
Но факт в том, что развитие ускоряется, и старые проекты с медленными обновлениями оказываются в зоне риска.

В 2025 году ИИ-инструмент помог обнаружить критическую уязвимость в действующем блокчейн-протоколе с потенциальным ущербом в несколько миллионов долларов — при том, что проект уже проходил аудит.
Также был случай с Balancer, но об этом уже 2 раза писал в разных постах.

4. Важна также репутация аудиторов: возможно они сами по себе делают некачественный анализ кода - это уже дополнительный глубокий анализ.


И важно, что ИИ может написать выжимку по аудитом. Но они не могут сказать вам про репутацию, соответствие текущей версии (особенно если нет Github) и насколько профессиональны аудиторы / проводились ли ИИ-аудиты кода.
Поэтому не стоит сильно полагаться на то, есть ли аудиты у проекта и сколько их: всегда важно соблюдать риск-менеджмент.

А вы изучаете код / аудиты проектов при выборе, куда инвестировать? Или для вас наличие аудита уже достаточный аргумент?

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev