о важном: как на самом деле создаётся блок в Ethereum (E. - далее)? 

когда нажимаем Swap, переводим ETH или взаимодействуем со смарт-контрактом иначе, за несколько сек за кулисами происходит целая цепочка действий: о ней много раз рассказывал, но сегодня хочу раскрыть подробности в 1-ом посте… 

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

№02. мемпул - кандидаты: узлы (ноды) E. получают ожидающие транзы: из этого потока могут формироваться будущие блоки. но! публичный мемпул - не единственный возможный путь: существуют приватные транзы, бандлы и др. способы доставки, связанные в том числе с MEV. ethereum.org отмечает существование приватных mev-пулов. 

№03. searchers - MEV: тут начинается НЕ обязательная часть, но это MEV-инфраструктура, поэтому: сёчеры анализируют доступные транзы и чейн, пытаясь найти MEV - дополнительную ценность, которую можно получить благодаря включению, исключению или определённому порядку транз. Это могут быть арбитраж и ликвидации; к негативным проявлениям MEV относятся некоторые формы фронтраннинг и сэндвич-атаки. searchers могут создавать собственные транзакции и бандлы и отправлять их дальше в инфраструктуру построения блока. 

№04. билдер - сборка блок: в современной PBS/MEV-boost архитектуре спец. билдер собирает транзакции и бандлы и пытается сформировать экономически выгодную полезную нагрузку. ethereum.org описывает модель так: билдеры специализируются на упорядочивании транзакций и создании блоков, после чего конкурируют за право передать свой вариант предложения. и схема в итоге: transactions + bundles → ordering → block candidate → bid. 

№05. релей - посредник между билдером и инициатором (по англ. proposer): в MEV-Boost появляется ещё один участник (relay): билдеры отправляют ему свои предложения. relay же выступает посредником между билдерами и валидаторами/инициаторами и помогает проверять и передавать предложения дальше. это тоже не самостоятельная роль базового PoS-консенсуса, а часть внешней архитектуры. ethereum.org приводит MEV-Boost как пример реализации Builder API. 

№06. инициатор  - предлагает блок: уже фундаментальная часть E. PoS. время E. разделено на слоты (ок. 12 сек). на каждый слот выбирается 1 валидатор, кот. получает роль: block proposer (BP) - он должен предложить новый блок сети. при использовании MEV-Boost proposer может получить предложения от внешних билдеров и выбрать подходящую нагрузку; без этой инфраструктуры валидатор может строить блок локально. поэтому схема: Searcher → Builder → Relay → Proposer - распространённый путь, но не обязательное правило E.

№07. аттестаторы → проверяют и голосуют: остальные валидаторы не просто доверяют BP: получив блок, узлы проверяют данные, а клиенты повторно исполняют содержащиеся в нагрузке исполнения (execution payload) транзы, чтобы проверить корректность изменения состояния E. Валидаторы создают подписанные аттестации - голоса о своём представлении корректной головы цепочки и чекпоинтах. 

№08. блок становится частью E. - затем получает финализацию: включение блока в канонический чейн ≠ финализация - финализация возникает позже. E. использует чекпоинты именно поэтому: когда соответствующие чекпоинты получают голоса, представляющие как минимум 2/3 застейканного ETH, они могут пройти стадии (из стадии одобренных в стадию финализированных). после финализации отмена такого блока потребовала бы уничтожения огромного объёма стека. 

и ещё одна важная деталь: валидатор - не 1 программа: E. разделён уровень исполнения и консенсуса: исполнение транзакций и состоянием E. - 1-я ч.; 2-я - участие в PoS-консенсусе (поэтому клиент валидатора выполняет его обязанности). отсюда - настройка включает: execution client, consensus client & validator client.