Этапы Транзакции Ethereum

Часть 2

Предыдущая часть

Реелеры, валидаторы и процесс добавления блока в блокчейн

5. Реелер

Между блок-билдером и валидатором стоит ещё один важный участник - релеер.

Он получает блок-пропозалы от разных билдров, складывает их в очередь и делает две ключевые вещи:

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

сравнивает, какой блок приносит валидатору максимальную прибыль

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

Чтобы валидатор не мог украсть идею блока и вручную заменить порядок транзакций, релеер отправляет ему не полный блок, а слепый блок: в нём скрыто содержимое транзакций, но виден заголовок и обещанная награда.

Так релеер защищает и билдеров, и валидаторов.

6. Задача Валидатора

Валидатор - участник, который держит залоченный ETH и отвечает за финальное "да" или "нет" для блока.

Получив слепый блок от релеера, валидатор:

проверяет заголовок: слот, ссылку на предыдущий блок, корни данных

убеждается, что блок относится к текущему слоту и не ломает цепочку

оценивает, какую награду он получит за подпись именно этого блока

Если всё корректно и блок выгоден, валидатор подписывает его своим валидаторским ключом. После этого блок перестаёт быть просто предложением и становится настоящим блоком Ethereum, готовым к публикации в сеть.

Подпись валидатора - момент, когда сеть официально признаёт этот блок кандидатом для включения в историю.

7. Блок распространяется по сети и становится частью цепочки

Подписанный блок валидатор отправляет в сеть. Узлы начинают принимать его по p2p-протоколу:

проверяют подпись

сверяют заголовок и корни

убеждаются, что блок логично продолжает текущую цепочку

Если всё сходится, узел добавляет блок к своей локальной копии цепи и пересылает дальше соседям. За короткое время блок расходится по всей сети: тысячи узлов включают его в свою историю.

С этого момента транзакции внутри блока:

окончательно меняют состояние аккаунтов и контрактов

становятся частью истории Ethereum

могут использоваться как основа для следующих транзакций

Через несколько эпох блок дополнительно закрепляется алгоритмом консенсуса и получает финальный, необратимый статус. После этого переписать его без катастрофы для сети уже нельзя.

Упростим до одной строки:

1. нажал Send
2. кошелёк собрал и подписал транзакцию
3. RPC проверил и передал её в мемпул
4. блок-билдеры выбрали её для блока
5. релеер проверил и выбрал лучший блок
6. валидатор подписал
7. блок разошёлся по сети и лёг в цепочку.

Смотреть видео - youtu.be/UIK2wXx_Ovg

VARTCALL

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

Что тут будет происходить?

– Почему AI?
Сравним двух программистов: один из них использует AI, а другой — нет, — и посмотрим на их результаты и эффективность. Думаю, вывод очевиден. А с учётом того, сколько денег вкладывается в развитие AI, страшно представить, что будет через 5–10 лет. В любом случае не хочется, чтобы технология прошла мимо.

– Что тут будет выкладываться?
Когда я погружаюсь в новую тему, я делаю кучу конспектов (которые, как правило, потом даже не открываю). Раньше это были письменные записи, теперь — заметки в Notion (или на какой-либо другой платформе).
Так как это просто конспекты, которые я пишу для себя во время изучения новой темы, они не претендуют на гениальность и идеальность. Это просто структурированная информация для удобного использования.

– Чему будем учиться?
На данный момент нет чёткого плана, так как не хватает насмотренности, поэтому действуем в режиме максимального расфокуса и пробуем всё понемногу. Но цель этого мероприятия — заработать деньги на AI.
И да, постараемся не скатываться в сверхпростые темы, которые каждый может освоить за 1–2 дня — просто потому, что там слишком высокая конкуренция.

– Будет ли платный продукт?
Пока сам с этого не заработаю, курса, подписки или какой-либо иной монетизации не будет.

SemolinaCode | Chat | YouTube | HowToCode | Prop

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

Погружение в Core Solidity. Часть 1

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

Если кратко: я закончил писать проект своего ассистента для аудита смарт контрактов, и теперь нужно добавить общий mcp сервер и систему автоматизации добавлений в базу данных, что поможет всегда держать ее актуальной. Кстати, это будут первые проекты на вайб кодинге. После тестов и настройки, я покажу их вам.

А пока, давайте поговорим об обновлении языка Solidity - Core Solidity, о котором я писал не так давно. Разработчики выкатили небольшое описание функций системы, которые мы рассмотрим на этой неделе.

P.S. Далее будет идти перевод статьи от имени разработчиков.

Solidity — это самый широко используемый язык для написания смарт-контрактов. Он надёжен, заслуживает доверия и сегодня обеспечивает сохранность активов на сумму в сотни миллиардов долларов. Мы гордимся этим успехом и безупречной репутацией генерации безопасного кода. Однако пользователи Solidity прекрасно осознают некоторые его ограничения. Система типов зачастую недостаточно выразительна: она не позволяет создавать многократно используемый код библиотек или гарантировать ключевые свойства безопасности. Язык почти не поддерживает вычисления на этапе компиляции. Многие функции реализованы несогласованно или не всегда работают так, как ожидается.

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

Core Solidity — наше решение этой проблемы. Это полная переработка системы типов и фронтенд/мидл-энд компилятора Solidity, которая позволит:

- внедрить мощные новые возможности,
- заложить прочную основу для корректности компилятора при дальнейшем расширении языка,
- дать возможность авторам библиотек активно участвовать и поддержать сообществом управляемый процесс развития языка,
- расширить возможности инструментов верификации и анализа.

Помимо расширения и развития языка, мы также собираемся убрать или переработать некоторые существующие функции. Уже точно решено, что мы полностью уберём наследование. Другие изменения пока менее определены, но мы рассматриваем возможность замены или переработки таких механизмов, как try/catch, библиотеки, указатели на функции, преобразование типов и указание мест хранения данных.

Тем не менее, Core Solidity в сравнении с классическим Solidity — это не новый язык, а по большей части его расширение. Он сохранит знакомый внешний вид и архитектуру, и большинство концепций классического Solidity в нём останутся без изменений.

На данный момент у нас уже есть рабочий прототип Core Solidity. Большинство примеров из этого поста успешно проходят проверку типов и могут генерировать исполняемый код. Некоторые примеры используют ещё не реализованный синтаксис и будут компилироваться в будущем. Основы теории типов уже стабильны, но перед тем, как мы сочтём систему типов завершённой, мы хотим добавить как минимум поддержку вычислений во время компиляции и модули. Впереди ещё много работы по созданию стандартной библиотеки и достижению функциональной эквивалентности с классическим Solidity.

Хотя прототип уже работает, он пока не оптимизирован для удобства пользователей. Мы активно продолжаем работу над прототипом, и новые функции будут постепенно появляться в репозитории проекта для обратной связи и экспериментов. Мы с нетерпением ждём ваших комментариев!

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

Примечание о синтаксисе

Большая часть проделанной на сегодняшний день работы была сосредоточена на проектировании и реализации системы типов и связанного с ней конвейера генерации кода вплоть до Yul. Чтобы не увязнуть в бесконечных спорах о деталях синтаксиса и как можно скорее проверить наши ключевые идеи на рабочей реализации, мы решили использовать временный (провизорный) синтаксис. До релиза можно ожидать значительных изменений. В настоящее время мы стремимся в итоге максимально приблизить синтаксис Core Solidity к синтаксису классического Solidity. Что касается нового синтаксиса, то окончательная его версия, скорее всего, будет ближе к таким языкам, как TypeScript или Rust.

Новые языковые возможности

Core Solidity заимствует идеи из чистых функциональных языков программирования (например, Haskell, Lean), а также из современных системных языков (например, Rust, Zig). Мы расширяем Solidity следующими новыми возможностями:

- Алгебраические типы данных (известные также как суммы и произведения типов) и сопоставление с образцом (pattern matching)
- Обобщения (generics) / параметрический полиморфизм
- Трейты (traits) / классы типов (type classes)
- Вывод типов (type inference)
- Функции высшего порядка и анонимные функции
- Вычисления на этапе компиляции

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

Мы продолжим поддерживать низкоуровневый доступ к EVM, который часто необходим в промышленных реализациях: встроенная ассемблерная вставка (assembly) останется базовой языковой конструкцией, и мы расширим блоки ассемблера возможностью напрямую вызывать функции, определённые на высокоуровневом языке. Пользователи смогут отключать встроенные абстракции (например, автоматическую генерацию диспетчеризации контрактов, декодирование ABI, генерацию стандартной схемы хранения данных), следуя философии «плати только за то, чем пользуешься», характерной для таких языков, как Rust и C++.

Далее поговорим подробнее и с примерами.

#core

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

Друзья, у меня очень паршивое подключение к интернету сегодня (вероятно, из-за погодных условий). Я сделаю запись этого урока по Hardhat 3 и просто выложу сегодня вечером буквально через полтора часа. Прошу прощения.

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

1inch запускает Aqua — леер унифицированной ликвидности🏌

Перед тем как выложу обещанную (да-да, очень скоро) статью про стейблы — давайте глянем, что там интересного у 1inch.

1inch выкатывают Aqua — штуку, которая по сути унифицирует ликвидность между разными yield-инструментами, то есть теперь одна и та же ликвидность может работать сразу в нескольких yield стратегиях, повышая эффективность единицы капитала (ровно про это я уже писал в одной из прошлых моих статей)

Чтобы всё это не осталось просто идеей, они собрали:
— тулкит для билдеров (логично — кто-то же должен будет строить yield-инструменты внутри Aqua)
— инцентив программу с приятными бонусами в долларах, если сделать что-то реально годное

Пока остаются открытыми вопросы каскадов, пермишенов на ликвидность внутри каждой стратегии и тд, но скоро всё узнаем — уверен, что у 1inch всё продумано, буду следить за развитием и давать вам апдейты

А пока, вот тут все ссылки для ознакомления
https://1inch.com/aqua
https://x.com/1inch/status/1990389518797557845?s=20

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

gm! В продолжение прошлой темы давайте ретроспективно посмотрим, что вообще происходит в текущей DeFi-мете

С одной стороны — синтетические стейблы с доходностью и непрозрачным коллатералом.

С другой — волты, которые гонят APR за счёт лупинга и заливки ликвы в те самые high risk стейблы.

Кураторы при этом одни и те же, и рассчитывать на «справедливое» разруливание вроде кейса Re7 x MEV Capital, как мы уже увидели, особо не приходится.

При этом главная метрика DeFi-проектов до сих пор — TVL.
Но полноценно использовать этот TVL получается далеко не всегда: в отчётах Ethena хорошо видно, какая часть долларов реально задействована в стратегиях, а какая просто лежит idle. Тем же страдают и AMM-протоколы.

---

Кажется, 1inch решили предложить новую метрику — Total Unlocked Value.
В DeFi-конструкторе появляется новый слой shared liquidity: управляющие капиталом используют его атомарно для исполнения стратегий, а в остальное время средства остаются у пользователей под общим ончейн-учётом.

Ключевая идея Аквы достаточно простая: капитал остаётся в кошельках LP/мейкеров, а не в пуле.
Протокол ведёт виртуальные балансы maker → app → strategy → token, один и тот же капитал может одновременно бэкапить несколько стратегий.

То есть Aqua смещает фокус с «где выше APR и больше TVL» на вопрос «какие стратегии эффективнее используют один и тот же капитал по времени».

Из последнего интервью cp0x с Никитой Овчинниковым мы узнали, что солверы начинают захватывать рынок DEX-ов: у них банально лучше capital efficiency. Сейчас у каждого солвера свой оффчейн-слой управления балансами, и основная прибыль остаётся у них (пользователь видит только чуть более выгодный своп).

Aqua предлагает вынести этот shared-liquidity-слой ончейн и открыть к нему доступ внешним пользователям и LP. Для солверов и маркетмейкеров это потенциальный общий стандарт управления балансами, для девов — новый базовый слой, поверх которого можно строить волты, AMM/PMM и свои RFQ-решения.

---

Будет очень интересно посмотреть, как это поедет, но ощущение такое, что это как раз тот кусок паззла, которого не хватало последние полтора года: новые примитивы в DeFi. Тот же вайб я чувствую от yieldbasis, несмотря на плохой перфоманс rn

Кому интересно покопаться глубже — тут деврелиз и ссылки на SDK / WhitePaper / App Release (1инч, если вы читаете мой канал, вы забыли опубликовать репозиторий, хотя ссылка на него приведена в доке):

https://1inch.com/aqua

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

Запись главных моментов урока - всё про переход на новую версию и написание тестов на Hardhat 3 https://www.youtube.com/watch?v=0BNeWYQk8F0

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

RUG RAG

Первой практической штукой, которую мы сделаем, будет RAG система

RAG (Retrieval-Augmented Generation) – это подход, при котором искусственный интеллект сначала находит нужную информацию в базе данных или документах (retrieval), а затем использует её для генерации ответа (generation).

Простыми словами, это способ “научить” модель отвечать с опорой на реальные данные, а не только на то, что она запомнила при обучении.

RAG-системы применяются в чат-ботах, справочных ассистентах и корпоративных поисках — чтобы AI давал точные, актуальные и обоснованные ответы, цитируя источник, а не "выдумывал" их.

Чтобы перейти к практике, нам в любом случае придётся разобраться с тем что такое: AI модель, в чем разница между AI моделью и нейросетью и понять понять какие вообще бывают модели. Всё это я расписал в конспекте, который прикрепляю снизу

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

Читать: AI модели для чайников


SemolinaCode | Chat | YouTube | HowToCode | Prop

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

Прототип дизайна страницы падения Cloudflare

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

Погружение в Core Solidity. Часть 2

Алгебраические типы данных и сопоставление с образцом

Алгебраические типы данных (ADT, Algebraic Data Types) предоставляют принципиальную основу для моделирования данных за счёт комбинирования суммарных (sum) и произведённых (product) типов. Суммарные типы являются расширением перечислений (enums) из классического Solidity. Они представляют исключающие друг друга варианты: значение принадлежит ровно одному из возможных вариантов. Произведённые типы объединяют несколько значений в структурированные кортежи. На основе этих двух примитивов можно конструировать точные типы, делающие недопустимые состояния полностью невозможными для представления, что позволяет системе типов обеспечивать соблюдение инвариантов полностью на этапе компиляции.

Начнём с очень простого типа:

data Bool = True | False

Левая часть приведённого выше выражения определяет имя нового типа (Bool), а правая часть задаёт множество значений, составляющих тип Bool (True или False).

С помощью ADT также можно реализовать те же самые паттерны, что и пользовательские типы-значения (User Defined Value Types) в классическом Solidity. Например, значение с фиксированной точкой и 18 знаками после запятой («wad») можно представить следующим образом:

data wad = wad(uint256)

Тип wad (слева) имеет единственный конструктор значений wad (справа), который хранит значение типа uint256 в качестве своего внутреннего представления. Имена типов и конструкторы значений находятся в отдельных пространствах имён, поэтому могут совпадать. Простые обёрточные типы подобного рода будут полностью удалены компилятором при трансляции в Yul, то есть тип wad будет иметь точно такое же представление во время выполнения, как и uint256.

Теперь можно определить процедуру умножения чисел с фиксированной точкой с проверкой типов. Для этого потребуется извлечь внутреннее значение uint256, произвести над ним необходимые операции и обернуть результат в новый конструктор wad. Для распаковки воспользуемся сопоставлением с образцом (pattern matching). Сопоставление с образцом — это механизм управления потоком выполнения, позволяющий деконструировать и анализировать данные по их структуре. Вместо громоздких цепочек if-else можно писать декларативные выражения, полностью перебирающие все возможные значения проверяемого типа.

let WAD = 10 ** 18;

function wmul(lhs : wad, rhs : wad) -> wad {
    match (lhs, rhs) {
    | (wad(l), wad(r)) => return wad((l * r) / WAD);
    }
}

Тип AuctionState, ниже, имеет четыре альтернативных конструктора значений:

- NotStarted указывает, что аукцион ещё не начался, и хранит резервную цену;
- Active означает, что аукцион идёт, и хранит текущую максимальную ставку и адрес того, кто её сделал;
- Ended представляет успешно завершившийся аукцион с максимальной ставкой и адресом победителя;
- Cancelled описывает отменённый аукцион и хранит максимальную ставку и адрес предполагаемого победителя на момент отмены.

Теперь можно определить функцию processAuction, которая изменяет состояние аукциона в зависимости от текущего состояния и значения msg.value. Выражение match позволяет выполнить исчерпывающий разбор всех возможных состояний. Случай _ в конце конструкции match является обработчиком по умолчанию для всех оставшихся состояний, которые явно не были перечислены. Компилятор гарантирует полноту такого разбора, требуя, чтобы каждое возможное состояние обрабатывалось ровно один раз.

function processAuction(state: AuctionState) -> AuctionState {
    match state {
    | NotStarted(reserve) =>
        require(msg.value >= reserve);
        return Active(msg.value, msg.sender);
    | Active(currentBid, bidder) =>
        require(msg.value > currentBid);
        transferFunds(bidder, currentBid);
        return Active(msg.value, msg.sender);
    | _ => return state;
    }
}

#core

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