Feed

Часть 2: Газовая модель - «Защита блока»

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

Газ-лимит — это инвариант: «В блоке не больше X работы и не больше Y байт». Но сейчас это можно легко обойти тремя способами, и Glamsterdam закрывает их своими EIPs.

TLDR

EIP-7976 описывает главную проблему блока, который может быть раздут данными, а не только вычислениями. Решает проблему повышением стоимости calldata в блоке.

EIP-7981 повышает стоимость за данные, передаваемые через Access List (это список адресов Ethereum и конкретных слотов их storage, к которым транзакция потенциально будет обращаться при выполнении транзакции).

EIP-7778 отменяет применение рефанда газа к лимиту блока (количество газа минусуется при выполнении, когда sstore обнуляет слот).

Зачем это все?

Ключевая проблема в том, что важны не только вычисления в блоке, но и сами данные блока.

Планируется, что газ-лимит блока будет расти, а вместе с ним будет увеличиваться влияние проблемы: блок можно раздуть данными через calldata, access lists или выполнить больше вычислений за счет рефанда газа, обходя газ-лимит.

В плане увеличивать газ-лимит блока до 200 млн, что однозначно усугубит описанные проблемы.

Glamsterdam закрывает все три уже сейчас, до того, как лимит поднимут.

1️⃣ EIP-7976

Это предложение затрагивает те данные транзакции, которые можно отправить через calldata.

Посыл тот же, что и раньше: большим данным место в blobs, а не в calldata.

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

До обновления Pectra было все просто: 4 единицы газа за нулевой байт, 16 — за ненулевой.

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

Каждая транзакция считается двумя способами, и платит она по максимальному тарифу:

1. Обычный расчет — 4/16 газа за байт + исполнение;
2. Минимальная планка — 10/40 газа за байт (в Pectra).

Ниже расценки и пример с учетом Glamsterdam, который поднимает минимальную планку.


Обычная цена | 4 | 16
Floor в EIP-7623 (Pectra) | 10 | 40
Floor в EIP-7976 (Glamsterdam) | 64 | 64

Пример

Если речь об обычном трансфере ERC-20, его calldata - это плюс/минус 68 байт.

По обычной цене будет посчитано, как 68 * 16 = 1_088 (для простоты считаем, что там все 68 байт ненулевые) + газ за исполнение.

По Glamsterdam нижняя граница будет посчитана, как 68 * 64 = 4_352. Это меньше, чем обычный расчет + исполнение. Поэтому транзакция платит по большему из двух: в нашем случае дешевая calldata + исполнение.

P.S. А вот транзакция, которая почти ничего не вычисляет, но несёт 100 КБ данных, заплатит не меньше 100_000 × 64 = 6,4M газа.

Подобное повышение позволяет уменьшить количество данных в блоке. Считаем легко: газ-лимит блока / 64 газа за байт (это минимальная стоимость за байт информации).

При газ-лимите 200M это ~3,1 МБ вместо ~5 МБ при Pectra, что безусловно снижает объем данных.

2️⃣ EIP-7981

Помимо calldata другой тип данных, который может раздуть блок - Access List. Это наследие EIP-2930 (Berlin). До сих пор - это необязательное поле транзакции.

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


• адрес — 2 400 газа;
• слот — 1 900 газа.


Взамен эти адреса и слоты становятся тёплыми с самого начала транзакции, и обращение к ним стоит 100 газа вместо холодных 2_600 / 2_100. Задумка прекрасная, как способ немного сэкономить.

Вам напоминает это чем-то фаворита Glamsterdam обновления BAL, где мы прокидываем адреса, состояния в слотах, которые транзакция планирует менять?😅

Проблема с Access List

Можно разбавить в транзакции calldata при помощи access list так, чтобы повышенная минималка (EIP-7976) перестала действовать.

И вуаля! Calldata снова стоит дёшево, 16 газа за байт, а в блок влезает больше байт, чем позволяет минималка. Блок снова раздут данными.

Решение

Бахнуть надбавку в те же 64 газа за байт, что и для calldata.



| Байт | Было (EIP-2930) | Стало
Адрес | 20 | 2_400 | 2_400 + 20 * 64 = 3 680
Ключ слота | 32 | 1_900 | 1_900 + 32 * 64 = 3 948

Только в отличие от calldata, здесь надбавка действует на любой Access List. Заранее «нагреть» слот теперь сильно дороже, чем просто прочитать его холодным.

Вот теперь считайте сами выгодно ли вам в вашем случае прогревать слоты или проще обращаться к холодному слоту?

❗️По моим расчетам прогревать больше нет смысла.

3️⃣ EIP-7778

Рефанд - это возврат части газа за то, что транзакция очистила состояние. Обычно SSTORE обнуляет слот, который до этого был ненулевым.

🔥 Немного истории

Помните про такую модную штуку, как газовые токены? Такие токены занимали слоты при дешёвом газе, а при дорогом очищали их и получали возврат.

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

Когда-то это был крутой концепт, пока его не прикрыли в обновлении London, ограничив refund газа до 20% от потраченного.

В чем проблема сейчас?

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

Так как рефанд ограничен 20% от всего потраченного газа, то засчитанный блоку газ - это 80% реальной работы.

При газ-лимите 200 млн реальная работа = 200 / 0,8 = 250 млн. А это уже много для окна 6-9 секунд, которые даются на проверку блока.

Решение

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

Получается, что для пользователя ничего не меняется, его рефанд сохранен, а в блок не влезет больше работы сверх газ-лимита.

Общий вывод

Чтобы безопасно поднимать газ-лимит блока, сначала нужно сделать его честным. Исключить возможность обойти лимит или раздуть за счет данных. Три предложения (7976, 7981, 7778) направлены именно на это.

Раздуть блок через calldata, access list будет экономически невыгодно. Рефанд перестанет влиять на газ-лимит блока.

Вишенка этой группы предложений: заранее «нагреть» слот теперь почти вдвое дороже, чем прочитать его холодным. Поэтому как способ сэкономить газ access list (EIP-2930) после Glamsterdam перестаёт работать, и всем, кто это использует, стоит отказаться от него.

#павел_найданов

🤟 Сайт | ТГ-канал | Наш чат

Часть 1: Газовая модель - "Состояние блокчейна"

В этот раз работы по газу было проделано много, первые три нововведения рассмотрим в этом посте.

1. EIP-8037: State Creation Gas Cost Increase
2. EIP-8038: State-access gas cost update
3. EIP-2780: Resource-based intrinsic transaction gas

TLDR

EIP-8037 пересматривает стоимость добавления новых данных в состояние в блокчейна, когда буквально надо выделить новый слот, создать аккаунт или записать код контракта.

EIP-8038 пересматривает стоимость доступа к уже существующим данным.

EIP-2780 разбивает фиксированную базовую стоимость транзакции (21_000 газа) на составные части.

Зачем это все?

Абсолютно точно то, что газовая модель фундаментально пересматривается в Glamsterdam. Причина этого, как ни странно, масштабируемость. Увеличение газ-лимита блока до 60 млн. в Fusaka привело к тройному увеличению скорости прироста всего состояния блокчейна. Речь о том, что ежегодно нода будет хранить данных больше на ~116 ГиБ.

При продолжении увеличения газ-лимита до 200 млн. нода будет получать прирост в ~387 ГиБ в год и больше. В будущем это приведет к падению производительности.

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

1️⃣ EIP-8037

Это первое предложение, которое вводит новый расчет при добавлении новых данных в состояние блокчейна.

Оно включает в себя:
- создание контракта через create, create2
- перевод ETH на адрес, которого еще не было, что инициирует создание аккаунта
- первую запись в слот (изменение значения с нуля на что-то) с использованием опкода sstore
- некоторые другие операции, связанные с call, selfdestruct, делегированием вызова для EOA.

Математику изменений можно посмотреть в таблице и коде любого клиента ноды, но основная суть в том, что вводится "магическая переменная" CPSB (cost per state byte), которая равняется 1530 газа.

Теперь цена операции = [сколько байт она добавляет в состояние] × CPSB:

Операция | Байт | Было | Стало
Новый слот | 64 | 20_000 | 97 920 (~5×)
Новый аккаунт | 120 | 25_000 | 183 600 (~7×)
Байт кода при деплое | 1 | 200 | 1 530 (~7,6×)
Контракт 24 КБ целиком | — | ~4,9M | ~37,8M (~8×)

P.S. CPBS взята не с бухты барахты, а рассчитана так, чтобы остановить скорость прироста состояния.

Multidimensional metering

Если вы думаете, что это все, то вы ошибаетесь. Помимо изменения базовых параметров стоимости вводится структурное разделение газа на: execution-gas и state-gas.

Для операций по работе с состоянием используется state-gas, а исполнение (прогнать список опкодов вашего кода) - execution-gas.

На уровне транзакции пользователь платит как за execution-gas, так и за state-gas. Общая стоимость газа для транзакции равна сумме обоих измерений.

Только есть нюанс: лимит газа на одну транзакцию (~16,7M, EIP-7825) теперь применяется только к execution-gas.

Как же теперь считается лимит газа на уровне блока?

Лимит считается отдельно по сумме execution и state gas для всех транзакций, но учитывается максимальное значение из них.

```js
block_gas = max(execution_gas_used, state_gas_used) ≤ gas_limit
```

2️⃣ EIP-8038

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

Количество газа за доступ к данным не менялось с 2021 года (Berlin), а состояние блокчейна с тех пор сильно выросло, и чтение с диска стало медленнее.

Напомню, холодным доступом называется первое обращение к слоту или аккаунту в рамках транзакции, а теплым - повторное.

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

Операция | Было | Стало
Холодный доступ к аккаунту | 2_600 | 3_000
Холодный доступ к стораджу | 2_100 | 2_100
Теплый доступ | 100 | 100
Запись в структуру аккаунта (nonce, balance, code hash) | ~6_700 | 9_000
Изменение существующего слота | ~2_800 | 10_000

При этом холодный доступ к стораджу и теплый доступ остаются без изменения.

Если слот имеет нулевое значение, то к нему еще будет добавлен газ из EIP-8037, за создание состояния.

На самом деле изменений в ценовой политике здесь много, в пост не поместится, при необходимости читать EIP.

Помимо этого интересно здесь то, что все клиенты Ethereum (Geth, Nethermind, Besu, Erigon, Reth и др.) написаны при помощи разных языков (Go, C#, Java, Rust) и используют разные базы данных, оптимизации. Хоть все клиенты и посчитают газ за операцию одинаково, но сделают они это с разной скоростью.

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

3️⃣ EIP-2780

Сейчас любая транзакция платит фиксированные 21_000 газа, независимо от того, что она реально делает. Перевод без ETH существующему адресу и перевод, который создаёт новый аккаунт, стоят одинаково, хотя второй навсегда увеличивает состояние блокчейна.

Поэтому предлагается разбить 21_000 на составные части:

• 12_000 - это базовая стоимость, которая взимается за проверку подписи, аккаунт отправителя, включение в блок
• 3_000 - взимается за холодный доступ к получателю (как описано в EIP-8038);
• 6_000 - взимается за перевод ETH, который включает в себя запись баланса получателя в структуру аккаунта и лог перевода (это еще один EIP-7708, который пока за рамками нашего поста).


Что же тогда меняется?


• обычный перевод ETH на существующий адрес - 21_000, как раньше
• транзакция без перевода ETH (например, вызов контракта, такой как трансфер ERC-20) - 15_000 + газ за исполнение
• перевод самому себе (так отменяют зависшую транзакцию: новая с тем же nonce и большей комиссией вытесняет старую) - 12_000;
• перевод ETH на новый адрес: 21_000 + 183_600 газа состояния (из EIP-8037);
• деплой контракта: 12 000 (база транзакции) + 12 000 (вычисление и проверка адреса контракта, EIP-8038) + 183_600 за новый аккаунт + 1_530 за каждый байт кода.

Изменение в EIP-2780 было необходимо, потому что без него новый аккаунт можно было бы создать за обычные 21_000 газа и обойти подорожание, описанное в EIP-8037.

Вывод


Glamsterdam фундаментально меняет то, за что мы платим газом.

Раньше газ был усреднённой ценой «за работу», теперь он оплачивает конкретные ресурсы ноды:

• создание нового состояния, которое навсегда ложится на диск каждой ноды (EIP-8037)
• доступ к существующим данным и их изменение (EIP-8038)
• базовую стоимость транзакции, которая теперь зависит от того, что транзакция реально делает (EIP-2780)

На первый взгляд может показаться, что вычисления дорожают, но отдельный анализ (EIP-7904) показал, что после оптимизаций клиентов под BAL опкоды и прекомпайлы и так укладываются в целевую скорость. Дорожает только то, что ложится на диск.

Логика простая: чтобы ноды не утонули в данных, создавать новое состояние - дорого, а менять существующее чуть-чуть дорого. 😂


Это грандиозная переделка и при этом обратно несовместимое изменение, которое требует планового обновления сети.

Что стоит проверить разработчикам:

• eth_estimateGas - обновите ноду или убедитесь, что ваш RPC-провайдер поддерживает новую газовую модель, иначе транзакции будут падать от недооценки газа
• если вы закладываете ровно 21_000 на любой перевод ETH, сервис сломается на переводе на новый адрес
• захардкоженные лимиты газа в контрактах и скриптах могут перестать покрывать исполнение, транзакции будут фейлиться
• замеры газа через разницу gasleft() до и после вызова могут дать отрицательный результат (EIP-8037).

#павел_найданов

🤟 Сайт | ТГ-канал | Наш чат

СКУЧАЛИ?

Надеемся, что да, а то мы тут немного пропали из виду.

Но возвращаемся с новым выпуском подкаста! И не абы с кем, а с Михаилом из Sherlock 🕵️‍♂️

Снова говорим про безопасность, но на этот раз больше с бизнесовой стороны 💰

Нам было интересно разобраться, как вообще устроен рынок аудитов, на чём зарабатывают security-компании, как конкурируют за клиентов и что сейчас происходит в индустрии.

Ну и как же, конечно не обошлось без разговоров про AI, миллионные взломы и будущее аудиторов.

В общем, получился вроде интересный разговор на тему Web3 Security с другой стороны — не глазами разработчиков, а глазами тех, кто продаёт безопасность крупнейшим криптопроектам.

Детали в подкасте, вперёд слушать!

📺 YouTube
🎵 Яндекс-музыка
🎵 Apple-подкасты
💬 Слушать в Telegram

🤟 Сайт | ТГ-канал | Наш чат

Block-Level Access Lists (BAL)

Следующий в Glamsterdam по важности: EIP-7928: Block-Level Access Lists.

Вместе ePBS и BAL создают основу для масштабирования производительности Ethereum.

Каким образом масштабируемся?

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

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

Как сделать параллельное исполнение?

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

Для этого разработали специальную структуру (BAL), чтобы хранить информацию о том, какие транзакции => какие слоты памяти будут изменять.

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

В BAL все транзакции пронумерованы от 1 до n. Если до n-й транзакции слот в блоке никто не менял, значение читается с диска ноды. Если менял, берётся последнее значение из BAL.

Что лежит в BAL?

BAL — это список адресов контрактов и акаунтов. Для каждого такого акаунта передается:
storage_changes — какие слоты изменились и на какое значение после какой транзакции;
storage_reads — слоты, которые только читали;
balance_changes, nonce_changes, code_changes — новые значения после каждой транзакции.

Как передается BAL?

В каждый заголовок блока добавляется поле block_access_list_hash. который хранит хэш BAL.

Сам BAL лежит не в теле блока, а в ExecutionPayload и передаётся между CL и EL через Engine API.
Хранить его клиенты должны достаточно долго, не меньше 3533 эпох (это около 16 дней).

Кто формирует BAL и можно ли ему доверять?

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

Получается, что BAL выступает, как подсказка для выполнения, а не замена полноценному исполнению блока. При этом, если что-то не сходится, то блок считается невалидным.

Пример

Дано: Алиса, Боб и USDC.

До блока у Алисы 100 USDC, у Боба 0.

В блоке две транзакции: Алиса отправляет Бобу 30, а Боб отправляет Алисе 10. Вторая транзакция зависит от первой: без неё Бобу просто нечего отправлять.

Без BAL валидатор обязан исполнить их строго по очереди. С BAL он уже знает, какими станут балансы после каждой транзакции: после tx1 — 70 и 30, после tx2 — 80 и 20.

[
  [ 0x...,                                  # адрес контракта USDC
    [                                       # storage_changes
      [ баланс_Алисы, [[1, 70], [2, 80]] ], # слот: [[номер tx, значение после tx]]
      [ баланс_Боба,  [[1, 30], [2, 20]] ],
    ],
    [],                                     # storage_reads
    [],                                     # balance_changes (ETH)
    [],                                     # nonce_changes
    []                                      # code_changes
  ]
]

Поэтому валидатор запускает обе транзакции одновременно. tx1 берёт балансы с диска (100 и 0, так как до tx1 эти слоты в блоке никто не менял), а tx2 берет балансы из BAL (70 и 30), не дожидаясь tx1.

В конце валидатор сверяет: совпали ли результаты с тем, что записано в BAL? Если да, блок валиден. Если билдер где-то соврал, проверка не сойдётся, и блок невалиден.

Вывод

Получается, что ePBS дает время, расширяя окно распространения данных блока до 6-9 секунд, а BAL позволяет эффективнее использовать это время для проверки транзакций за счет параллельного исполнения.

Из неочевидного, это то, что BAL дает не только возможность исполнить транзакции параллельно.

Также добавляется:
1. Параллельное чтение значений слотов из диска, потому что BAL перечисляет все слоты, которые будут прочитаны или изменены в рамках блока. И это даже более круто по производительности, чем исполнение.
2. Для билдера построение BAL обязательно, но код клиента ноды может исполнить блок и по старинке последовательно, а потом просто сравнить.

#павел_найданов





🤟 Сайт | ТГ-канал | Наш чат

Enshrined Proposer-Builder Separation


Ну что, начинаем погружение в Glamsterdam с фаворита: EIP-7732: Enshrined Proposer-Builder Separation.

1. Разделяет блок на части консенсуса и исполнения
2. Пропоузер напрямую выбирает билдера блока
3. Вводится новая сущность builder, а у валидаторов появляется новая обязанность: голосовать за своевременность payload

Как транзакция живет сейчас?

1️⃣ Пользователь и транзакции

Пользователь подписывает транзакцию своим приватным ключом и отправляет ее через RPC. Дальше у нее два пути.

Первый — публичный мемпул, где её видят все ноды и все MEV-боты.
Второй — приватный канал (Flashbots Protect или MEV Blocker). В этом случае транзакция уходит напрямую нескольким билдерам и защищена от сэндвичей. Сейчас заметная доля транзакций идёт именно приватно.

2️⃣ Searcher => Builder

Серчеры ищут MEV среди транзакций: арбитраж, ликвидации, фронтраны. Найденное они упаковывают в бандлы (упорядоченная группа транзакций) и отправляют билдерам.

Билдер в течение всего слота непрерывно пересобирает лучший блок из мемпула, бандлов.

Билдер готовит ставку (по сути — взятка за место в блоке) пропозеру, чтобы его блок был принят и прокинут дальше к валидаторам. Обычно вставляет взятку последней транзакцией. Выглядит, как перевод на fee_recipient пропозера.

4️⃣ Relay

Это доверенный посредник между билдерами и пропозерами. Он получает от билдеров полные блоки и симулирует их: проверяет валидность.

Релей отдаёт пропозеру только заголовок с его взяткой. Сам payload (список транзакций) держит у себя, чтобы пропозер не мог украсть MEV билдера.

4️⃣ Proposer (MEV boost)

Пропоузер - это первая, официальная часть самого блокчейна Ethereum. Это не сторонняя надстройка, а ключевая роль внутри консенсуса Proof-of-Stake (PoS).

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

Через платформу MEV boost пропоузер ждет от релееров заголовки блоков без payload (без транзакций).

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

5️⃣ Проверка и аттестация

Пропозер подписывает «слепой» блок (только заголовок) и отдаёт его релею. Релей подставляет транзакции и публикует полный блок. Дальше валидаторы из комитета слота проверяют его и голосуют (аттестуют).

6️⃣ Финализация

Если все ок, то пропоузер, в момент исполнения блока получает свою награду (priority fees + ту самую жирную взятку от билдера, которой с ним поделились серчеры).

После того, как ⅔ стейка проголосовало со следующим чекпоинтом блок считается финализированным.

Что здесь может быть не так?

Например централизация: активных билдеров порядка 5-10, совсем недавно 80-85% всех блоков собиралось двумя билдерами — BeaverBuild и Titan Builder. Картина динамичная, но ситуация все равно печальная. Самую свежую ситуацию можно посмотреть на relayscan.io.

А релееров у нас порядка 6-8. Из них четыре игрока контролируют почти все. Ultra Sound, Titan, bloXroute (две версии) и Agnostic Relay. Кто-то из них может опускаться, подниматься, но суть такая же, как и с билдерами.

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

Более того, у титана и билдер, и релеер, доверяет сам себе или все доверяют титану?😅

И это интересно понимать, на фоне, когда ругают другие чейны за их централизацию валидаторов. В Ethereum с валидаторами проблем нет — их сотни тысяч, но проблему я обозначил.

Как транзакция будет жить после Glamsterdam?

Схема, описанная выше, меняется фундаментально. Билдер теперь не внешний сервис, а сущность внутри BeaconState в реестре builders. А релееры перестают быть обязательной прослойкой между билдером и пропоузером.

Билдер вносит депозит, минимум — 1 ETH. После этого он становится частью Ethereum. Для него нет очереди входа и выхода, как у валидаторов.

Стейк билдера не голосует, он работает как залог: из него протокол списывает оплату пропозеру. Отсюда простое правило: билдер не может предложить взятку пропоузеру больше своего баланса.
В Glamsterdam у транзакции будет совсем другая жизнь.

1️⃣ Пользователь и транзакции

На этом уровне все по-прежнему: пользователь подписывает транзакцию и отправляет ее в сеть.

2️⃣ Proposer

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

3️⃣ Builder

Билдеры собирают блоки из бандлов и доступных транзакций из мемпула, формируют заголовок блока и фиксируют взятку пропозеру. После этого отправляют пропозеру: взятку, block_hash будущего payload и коммитменты блобов. Сами транзакции и блобы остаются у билдера.

4️⃣ Proposer публикует блок в beacon chain

Пропоузер выбирает самую выгодную взятку и кладёт её в свой beacon block. Этот блок максимально легкий, потому что в нем нет транзакций и блобов. В момент обработки этого блока сумма взятки списывается с баланса билдера. Если пропозер хочет строить сам, он ставит BUILDER_INDEX_SELF_BUILD с нулевой суммой.

5️⃣ Аттестация

Валидаторы голосуют за beacon block, проверив только консенсусную часть. Исполнять транзакции на этом шаге не нужно, поэтому это выполняется быстро.

6️⃣ Builder раскрывает payload

Билдер видит, что его блок прошел аттестацию и раскрывает payload вместе с блобами.

Раскрывать стоит именно после аттестаций: если блок пропозера опоздал или его реорганизовали, билдер может ничего не раскрывать и не платит.

7️⃣ PTC голосует (512 валидаторов)

PTC (Payload Timeliness Committee) — это 512 валидаторов, которые голосуют за раскрытый payload. Причем у них нет задачи его прогонять, они только проверяют своевременность его прихода на проверку и что hash совпадает с тем, что был отправлен на проверку в консенсусе. Также проверяется доступность блобов.

Если payload принят, списанная сумма с билдера передается пропозеру. Если payload не раскрыт билдером, но beacon block набрал достаточно веса аттестаций, пропозеру всё равно отправят взятку.

Получается двойная страховка и билдер не платит только если блок не принят вообще.

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

Вопрос: а кто же проверяет payload?

После того, как payload раскрывается PTC не проверяет payload, поэтому это делает следующий пропоузер и у него есть на это 6 сек. Также payload проверяют и валидаторы нового слота до момента, пока новые блоки формируются и не наступит время их аттестации. Это 9 сек.

Вывод

ePBS решает сразу две задачи, которые на первый взгляд не связаны.

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

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



Вторая — масштабирование. Блок делится на консенсусную часть и исполнительную, при этом тяжёлая проверка транзакций переезжает из узкого окна в 4 секунды в окно 6–9 секунд. Именно это, вместе с block-level access lists (EIP-7928), позволяет перейти к более высоким лимитам на газ.

P.S. Насколько ситуация с билдерами улучшится — мне пока не понятно. Те же самые два билдера продолжат работу по постройке блока, да, теперь им надо стейкать ETH, но у них есть законный механизм по придержанию раскрытия payload. Что может привести к появлению большого количества пустых слотов, что для обывателя выльется в увеличенное время ожидания исполнения его транзакции.

#павел_найданов

🤟 Сайт | ТГ-канал | Наш чат