🔥 ЗАВТРА

ЛЕГЕНДАРНОЕ ВОЗВРАЩЕНИЕ

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

Недавно писал, что рассказывать про крипту нынче скучно. Фарм, мемкоины, prediction markets — всё одно и то же. Но необязательно быть трейдером и дегеном, чтобы "работать в криптовалютах" – можно действительно работать, имею ввиду фулл-тайм и за зарплату.
Раз в месяц на карту или Ledger.

В конце 2021 я выбрал это направление для себя и ушел из E-commerce. В 2022 написал статью о том, как фронтенд-разработчику перейти из web 2.0 в web 3.0. С неё, по сути, начался этот канал. Тогда ниша была крошечной — разработчиков не хватало, конкурировать легко, а зарплаты росли просто потому что некому было работать, а рынок пампился инвесторскими деньгами.

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

Сколько реально платят джуну в web3 прямо сейчас? Что учить в 2026 — Solidity, Rust, аналитику? Можно ли зайти в крипту как профессию, а не как рынок для лудки? Почему GPT опасен при работе со смарт-контрактами?

3 марта в 19:30 позвал в гости на эфир Guide DAO — расскажем про это. Основной спикер — Кирилл Степанченко, выпускник школы, который прошёл путь с нуля до работы в web3. Я добавлю свою историю и перспективу. Ссылку на эфир опубликую отдельным постом.

Записаться на эфир и посмотреть детали о школе → @GuideDAO_hallo_bot

Guide DAO — одна из немногих школ, которая учит не "войти в крипту", а работать в ней. Буткемпы, воркшопы, помощь с трудоустройством — я сам проходил их курс по дата-аналитике и рекомендовал здесь. Если думаете в эту сторону — промокод INSULINE даёт 20% скидку на любой курс и суммируется с остальными скидками. guidedao.xyz

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

Держите лонг и шорт на разных perp дексах, но бесит, что надо заходить часто и проверять?

Решение есть - Delta-neutral monitor бот с уведомлениями о ваших активных дельта-нейтральных стратегиях.

Бот следит за двумя позициями (leg A и leg B), сравнивает их по размеру и суммарному PnL.
В Telegram приходит уведомление только если появляется заметный перекос или одна из ног пропадает и позицию стоит сворачивать.
Если всё в порядке, бот молчит.

Поддерживаются: Hyperliquid, Extended, Ethereal, Nado, Pacifica, Paradex и StandX.

Бот не торгует и ничего не исполняет.
Приватные ключи не нужны — используются только read-only API токены или адреса кошельков (аккаунтов).
Это именно мониторинг состояния дельта-нейтралки, а не автоматизация стратегии.

Выбор дексов, активов и порогов настраивается прямо через Telegram, без правки конфигов и перезапусков. В начале было в файле, но мне это быстро надоело - решил сделать проще: и себе помог, и вам облегчил настройку 🙂.

Делал для себя под фарминг поинтов и funding, но решил выложить публично.

Код и README на GitHub:
denis-skripnik/delta-neutral-bot
Нужен node.js

Если есть баги или вопросы — пишите в @blind_dev_chat.
Используете ли вы дельта-нейтральную стратегию? Мониторите вручную или автоматизировали?

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

^^ у нас тут вкусная вакансия

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

Я 2 месяца активно вайд-кодю. Вот что понял

До этого около 2 лет использовал ChatGPT web для кода, прототипов и автоматизации. Но последние два месяца формат работы изменился.

Раньше я:

Давал задачу, получал код по файлам отдельно, скачивал и тестировал, отправлял ошибки или улучшения, опять скачивал...

В общем, долго и муторно!

Сейчас чаще делаю иначе:

1. продумываю архитектуру
2. Формулирую задачу целиком
3. правлю результат точечно через промпты и, если очень мелкие правки - вручную.

Скорость выросла заметно.

Например, своего delta-neutral monitor бота я собрал примерно за 3-5 часов. Вручную писал бы значительно дольше.

Поэтому решил упомянуть курс по вайдкодингу, который стартует 10 марта. Это живой курс с наставником, где за 1.5-2 месяца участники с нуля делают полноценный веб-проект: база данных, логин, деплой, автоматизация — весь цикл от идеи до работающего сервиса.

Что мне кажется важным:

1. фокус на практике
2. результатом становится реальный продукт
3. домашние задания проверяются
4. после прохождения дают доступ ко всему обучению и комьюнити

Я скептически отношусь к растянутым форматам, но 8 занятий с проверкой и самостоятельной работой между ними — это уже системный подход.

Сайт:
https://www.guidedao.xyz/ru

А вот LinkedIn спикера.

По промокоду blind действует скидка 20% + дополнительные 10% от цены на сайте.

Мне нравится, когда человек без опыта в разработке начинает делать для себя полезные инструменты. Ещё недавно это звучало как фантастика.

А вы уже используете вайд-кодинг для реальных задач или пока только экспериментируете?

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

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

🔥 365 ДНЕЙ В КРИПТО РАЗРАБОТКЕ

https://youtu.be/07GJrc_lKNs
https://youtu.be/07GJrc_lKNs
https://youtu.be/07GJrc_lKNs

Я ВЕРНУЛСЯ!

ПРИЯТНОГО ПРОСМОТРА!

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

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

📟 Прилетело из @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