{"items":[{"id":20042,"channel":{"id":180,"username":"metalampru","title":"MetaLamp | CIS","kind":"channel","private":false},"message_id":718,"url":"https://t.me/metalampru/718","date":"2026-11-05T10:57:00+00:00","edited_at":"2026-11-05T11:37:36+00:00","text":"Часть 2: Газовая модель - «Защита блока» \n\nВ предыдущей части мы обсудили только то, что касается изменений в области расчета газа и газ-лимита.\n\nГаз-лимит — это инвариант: «В блоке не больше X работы и не больше Y байт». Но сейчас это можно легко обойти тремя способами, и Glamsterdam закрывает их своими EIPs.\n \nTLDR\n\nEIP-7976 описывает главную проблему блока, который может быть раздут данными, а не только вычислениями. Решает проблему повышением стоимости calldata в блоке. \n\nEIP-7981 повышает стоимость за данные, передаваемые через Access List (это список адресов Ethereum и конкретных слотов их storage, к которым транзакция потенциально будет обращаться при выполнении транзакции).\n\nEIP-7778 отменяет применение рефанда газа к лимиту блока (количество газа минусуется при выполнении, когда sstore обнуляет слот).\n\nЗачем это все?\n\nКлючевая проблема в том, что важны не только вычисления в блоке, но и сами данные блока.\n\nПланируется, что газ-лимит блока будет расти, а вместе с ним будет увеличиваться влияние проблемы: блок можно раздуть данными через calldata, access lists или выполнить больше вычислений за счет рефанда газа, обходя газ-лимит.\n\nВ плане увеличивать газ-лимит блока до 200 млн, что однозначно усугубит описанные проблемы.\n\nGlamsterdam закрывает все три уже сейчас, до того, как лимит поднимут.\n\n1️⃣ EIP-7976\n\nЭто предложение затрагивает те данные транзакции, которые можно отправить через calldata.\n\nПосыл тот же, что и раньше: большим данным место в blobs, а не в calldata.\n\nИсторически, calldata — это входные данные транзакции: какую функцию смарт-контракта вызвать и с какими аргументами. Все это в байтах и лежит прямо в блоке, а значит вместе с ним и распространяется по сети.\n\nДо обновления Pectra было все просто: 4 единицы газа за нулевой байт, 16 — за ненулевой. \n\nПотом подкрутили это так, чтобы экономически было невыгодно в calldata класть много данных, так как уже для этого вовсю можно было использовать blob объекты.\n\nКаждая транзакция считается двумя способами, и платит она по максимальному тарифу: \n\n1. Обычный расчет — 4/16 газа за байт + исполнение; \n2. Минимальная планка — 10/40 газа за байт (в Pectra). \n\nНиже расценки и пример с учетом Glamsterdam, который поднимает минимальную планку.\n\n\nОбычная цена | 4 | 16\nFloor в EIP-7623 (Pectra) | 10 | 40\nFloor в EIP-7976 (Glamsterdam) | 64 | 64\n\nПример\n\nЕсли речь об обычном трансфере ERC-20, его calldata - это плюс/минус 68 байт. \n\nПо обычной цене будет посчитано, как 68 * 16 = 1_088 (для простоты считаем, что там все 68 байт ненулевые) + газ за исполнение.\n\nПо Glamsterdam нижняя граница будет посчитана, как 68 * 64 = 4_352. Это меньше, чем обычный расчет + исполнение. Поэтому транзакция платит по большему из двух: в нашем случае дешевая calldata + исполнение.\n\nP.S. А вот транзакция, которая почти ничего не вычисляет, но несёт 100 КБ данных, заплатит не меньше 100_000 × 64 = 6,4M газа. \n\nПодобное повышение позволяет уменьшить количество данных в блоке. Считаем легко: газ-лимит блока / 64 газа за байт (это минимальная стоимость за байт информации). \n\nПри газ-лимите 200M это ~3,1 МБ вместо ~5 МБ при Pectra, что безусловно снижает объем данных. \n \n2️⃣ EIP-7981\n\nПомимо calldata другой тип данных, который может раздуть блок - Access List. Это наследие EIP-2930 (Berlin). До сих пор - это необязательное поле транзакции. \n\nВ нём транзакция заранее перечисляет адреса и слоты хранилища, к которым собирается обращаться. За каждый элемент она платит при входе:\n\n\n• адрес — 2 400 газа;\n• слот — 1 900 газа.\n\n\nВзамен эти адреса и слоты становятся тёплыми с самого начала транзакции, и обращение к ним стоит 100 газа вместо холодных 2_600 / 2_100. Задумка прекрасная, как способ немного сэкономить. \n\nВам напоминает это чем-то фаворита Glamsterdam обновления BAL, где мы прокидываем адреса, состояния в слотах, которые транзакция планирует менять?😅\n\nПроблема с Access List\n\nМожно разбавить в транзакции calldata при помощи access list так, чтобы повышенная минималка (EIP-7976) перестала действовать.  \n\nИ вуаля! Calldata снова стоит дёшево, 16 газа за байт, а в блок влезает больше байт, чем позволяет минималка. Блок снова раздут данными.\n\nРешение\n\nБахнуть надбавку в те же 64 газа за байт, что и для calldata.\n\n\n\n | Байт | Было (EIP-2930) | Стало\nАдрес | 20 | 2_400 | 2_400 + 20 * 64 = 3 680\nКлюч слота | 32 | 1_900 | 1_900 + 32 * 64 = 3 948\n\nТолько в отличие от calldata, здесь надбавка действует на любой Access List. Заранее «нагреть» слот теперь сильно дороже, чем просто прочитать его холодным. \n\nВот теперь считайте сами выгодно ли вам в вашем случае прогревать слоты или проще обращаться к холодному слоту?\n\n❗️По моим расчетам прогревать больше нет смысла.\n\n3️⃣ EIP-7778\n\nРефанд - это возврат части газа за то, что транзакция очистила состояние. Обычно SSTORE обнуляет слот, который до этого был ненулевым. \n\n🔥 Немного истории\n\nПомните про такую модную штуку, как газовые токены? Такие токены занимали слоты при дешёвом газе, а при дорогом очищали их и получали возврат. \n\nПолучается в момент дорогого газа ты вместе со своей транзой сжигал часть данных и получал рефанд, что делало твою целевую транзакцию как бы дешевле. \n\nКогда-то это был крутой концепт, пока его не прикрыли в обновлении London, ограничив refund газа до 20% от потраченного. \n\nВ чем проблема сейчас?\n\nРефанд не просто делает возврат, он уменьшает газ, который засчитывается в лимит блока. \n\nТак как рефанд ограничен 20% от всего потраченного газа, то засчитанный блоку газ - это 80% реальной работы.\n\nПри газ-лимите 200 млн реальная работа = 200 / 0,8 = 250 млн. А это уже много для окна 6-9 секунд, которые даются на проверку блока. \n\nРешение\n\nУбрать рефанд из газ-лимита блока, но оставить его для уменьшения платы за транзакцию. \n\nПолучается, что для пользователя ничего не меняется, его рефанд сохранен, а в блок не влезет больше работы сверх газ-лимита.\n\nОбщий вывод\n\nЧтобы безопасно поднимать газ-лимит блока, сначала нужно сделать его честным. Исключить возможность обойти лимит или раздуть за счет данных. Три предложения (7976, 7981, 7778) направлены именно на это. \n\nРаздуть блок через calldata, access list будет экономически невыгодно. Рефанд перестанет влиять на газ-лимит блока.\n\nВишенка этой группы предложений: заранее «нагреть» слот теперь почти вдвое дороже, чем прочитать его холодным. Поэтому как способ сэкономить газ access list (EIP-2930) после Glamsterdam перестаёт работать, и всем, кто это использует, стоит отказаться от него.\n\n#павел_найданов\n\n🤟 Сайт | ТГ-канал | Наш чат","html":"<strong>Часть 2: Газовая модель - «Защита блока» </strong><br><br>В предыдущей части мы обсудили только то, что касается изменений в области расчета газа и газ-лимита.<br><br>Газ-лимит — это инвариант: «В блоке не больше X работы и не больше Y байт». Но сейчас это можно легко обойти тремя способами, и Glamsterdam закрывает их своими EIPs.<br> <br><strong>TLDR</strong><br><br><a href=\"https://eips.ethereum.org/EIPS/eip-7976\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><em>EIP-7976</em></a> <em>описывает главную проблему блока, который может быть раздут данными, а не только вычислениями. Решает проблему повышением стоимости calldata в блоке. </em><br><br><a href=\"https://eips.ethereum.org/EIPS/eip-7981\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><em>EIP-7981</em></a> <em>повышает стоимость за данные, передаваемые через Access List (это список адресов Ethereum и конкретных слотов их storage, к которым транзакция потенциально будет обращаться при выполнении транзакции).</em><br><br><a href=\"https://eips.ethereum.org/EIPS/eip-7778\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-7778</a> <em>отменяет применение рефанда газа к лимиту блока (количество газа минусуется при выполнении, когда sstore обнуляет слот)</em>.<br><br><strong>Зачем это все?</strong><br><br>Ключевая проблема в том, что важны не только вычисления в блоке, но и сами данные блока.<br><br>Планируется, что газ-лимит блока будет расти, а вместе с ним будет увеличиваться влияние проблемы: блок можно раздуть данными через calldata, access lists или выполнить больше вычислений за счет рефанда газа, обходя газ-лимит.<br><br>В плане увеличивать газ-лимит блока до 200 млн, что однозначно усугубит описанные проблемы.<br><br>Glamsterdam закрывает все три уже сейчас, до того, как лимит поднимут.<br><br>1️⃣ <strong>EIP-7976</strong><br><br>Это предложение затрагивает те данные транзакции, которые можно отправить через <strong>calldata</strong>.<br><br><blockquote>Посыл тот же, что и раньше: большим данным место в blobs, а не в calldata.</blockquote><br><br>Исторически, calldata — это входные данные транзакции: какую функцию смарт-контракта вызвать и с какими аргументами. Все это в байтах и лежит прямо в блоке, а значит вместе с ним и распространяется по сети.<br><br>До обновления Pectra было все просто: 4 единицы газа за нулевой байт, 16 — за ненулевой. <br><br>Потом подкрутили это так, чтобы экономически было невыгодно в calldata класть много данных, так как уже для этого вовсю можно было использовать blob объекты.<br><br>Каждая транзакция считается двумя способами, и платит она по максимальному тарифу: <br><br>1. Обычный расчет — 4/16 газа за байт + исполнение; <br>2. Минимальная планка — 10/40 газа за байт (в Pectra). <br><br>Ниже расценки и пример с учетом Glamsterdam, который поднимает минимальную планку.<br><br><br>Обычная цена | 4 | 16<br>Floor в EIP-7623 (Pectra) | 10 | 40<br>Floor в EIP-7976 (Glamsterdam) | <strong>64</strong> | <strong>64</strong><br><br><strong>Пример<br><br>Если</strong> речь об обычном трансфере ERC-20, его calldata - это плюс/минус 68 байт. <br><br>По обычной цене будет посчитано, как 68 * 16 = 1_088 (для простоты считаем, что там все 68 байт ненулевые) + <strong>газ за исполнение</strong>.<br><br>По Glamsterdam нижняя граница будет посчитана, как 68 * 64 = 4_352. Это меньше, чем обычный расчет + исполнение. Поэтому транзакция платит по большему из двух: в нашем случае дешевая calldata + исполнение.<br><br>P.S. А вот транзакция, которая почти ничего не вычисляет, но несёт 100 КБ данных, заплатит не меньше 100_000 × 64 = 6,4M газа. <br><br>Подобное повышение позволяет уменьшить количество данных в блоке. Считаем легко: газ-лимит блока / 64 газа за байт (это минимальная стоимость за байт информации). <br><br>При газ-лимите 200M это ~3,1 МБ вместо ~5 МБ при Pectra, что безусловно снижает объем данных. <br> <br>2️⃣ <strong>EIP-7981</strong><br><br>Помимо calldata другой тип данных, который может раздуть блок - Access List. Это наследие <a href=\"https://eips.ethereum.org/EIPS/eip-2930\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-2930</a> (Berlin). До сих пор - это необязательное поле транзакции. <br><br>В нём транзакция заранее перечисляет адреса и слоты хранилища, к которым собирается обращаться. За каждый элемент она платит при входе:<br><br><br>• адрес — 2 400 газа;<br>• слот — 1 900 газа.<br><br><br>Взамен эти адреса и слоты становятся тёплыми с самого начала транзакции, и обращение к ним стоит 100 газа вместо холодных 2_600 / 2_100. Задумка прекрасная, как способ немного сэкономить. <br><br>Вам напоминает это чем-то фаворита Glamsterdam обновления BAL, где мы прокидываем адреса, состояния в слотах, которые транзакция планирует менять?😅<br><br><strong>Проблема с Access List</strong><br><br>Можно разбавить в транзакции calldata при помощи access list так, чтобы повышенная минималка (EIP-7976) перестала действовать.  <br><br>И вуаля! Calldata снова стоит дёшево, 16 газа за байт, а в блок влезает больше байт, чем позволяет минималка. Блок снова раздут данными.<br><br><strong>Решение</strong><br><br>Бахнуть надбавку в те же 64 газа за байт, что и для calldata.<br><br><br><br> | Байт | Было (EIP-2930) | Стало<br>Адрес | 20 | 2_400 | 2_400 + 20 * 64 = 3 680<br>Ключ слота | 32 | 1_900 | 1_900 + 32 * 64 = 3 948<br><br>Только в отличие от calldata, здесь надбавка действует на любой Access List. Заранее «нагреть» слот теперь сильно дороже, чем просто прочитать его холодным. <br><br>Вот теперь считайте сами выгодно ли вам в вашем случае прогревать слоты или проще обращаться к холодному слоту?<br><br>❗️<strong>По моим расчетам прогревать больше нет смысла</strong>.<br><br>3️⃣ <strong>EIP-7778</strong><br><br>Рефанд - это возврат части газа за то, что транзакция очистила состояние. Обычно <code>SSTORE</code> обнуляет слот, который до этого был ненулевым. <br><br>🔥 <strong>Немного истории</strong><br><br>Помните про такую модную штуку, как газовые токены? Такие токены занимали слоты при дешёвом газе, а при дорогом очищали их и получали возврат. <br><br>Получается в момент дорогого газа ты вместе со своей транзой сжигал часть данных и получал рефанд, что делало твою целевую транзакцию как бы дешевле. <br><br>Когда-то это был крутой концепт, пока его не прикрыли в обновлении London, ограничив refund газа до 20% от потраченного. <br><br><strong>В чем проблема сейчас?</strong><br><br>Рефанд не просто делает возврат, он уменьшает газ, который засчитывается в лимит блока. <br><br>Так как рефанд ограничен 20% от <em>всего потраченного</em> газа, то засчитанный блоку газ - это 80% реальной работы.<br><br>При газ-лимите 200 млн реальная работа = 200 / 0,8 = 250 млн. А это уже много для окна 6-9 секунд, которые даются на проверку блока. <br><br><strong>Решение</strong><br><br>Убрать рефанд из газ-лимита блока, но оставить его для уменьшения платы за транзакцию. <br><br>Получается, что для пользователя ничего не меняется, его рефанд сохранен, а в блок не влезет больше работы сверх газ-лимита.<br><br><strong>Общий вывод</strong><br><br>Чтобы безопасно поднимать газ-лимит блока, сначала нужно сделать его честным. Исключить возможность обойти лимит или раздуть за счет данных. Три предложения (7976, 7981, 7778) направлены именно на это. <br><br>Раздуть блок через calldata, access list будет экономически невыгодно. Рефанд перестанет влиять на газ-лимит блока.<br><br>Вишенка этой группы предложений: заранее «нагреть» слот теперь почти вдвое дороже, чем прочитать его холодным. Поэтому как способ сэкономить газ access list (<a href=\"https://eips.ethereum.org/EIPS/eip-2930\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-2930</a>) после Glamsterdam перестаёт работать, и всем, кто это использует, стоит отказаться от него.<br><br>#павел_найданов<br><br>🤟 <a href=\"https://metalamp.ru/\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Сайт</strong></a> | <a href=\"https://t.me/metalampru\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>ТГ-канал</strong></a> | <a href=\"https://t.me/+L_tFSdgfNcwxNjEy\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Наш чат</strong></a>","language":"ru","class":"approved","duplicate_of":null,"secondary_of":null,"in_aggregator":true,"aggregator_url":"https://t.me/WEB3_AGGREGATOR/426299","deleted":false,"deleted_at":null,"views":273,"forwards":6,"sender_id":null,"cashtags":[],"hashtags":["павел_найданов"],"addresses":[],"domains":["eips.ethereum.org","ethereum.org","metalamp.ru","t.me"],"media":[{"type":"photo","url":"https://media.web3aggregator.io/files/pbiJrG5qEaEs","duration":null,"width":1312,"height":1199,"preview":false}],"link_preview":null,"album":null,"topic":"research"},{"id":19364,"channel":{"id":180,"username":"metalampru","title":"MetaLamp | CIS","kind":"channel","private":false},"message_id":717,"url":"https://t.me/metalampru/717","date":"2026-11-02T10:54:00+00:00","edited_at":"2026-11-02T12:53:11+00:00","text":"Часть 1: Газовая модель - \"Состояние блокчейна\"\n\nВ этот раз работы по газу было проделано много, первые три нововведения рассмотрим в этом посте.\n\n1. EIP-8037: State Creation Gas Cost Increase\n2. EIP-8038: State-access gas cost update\n3. EIP-2780: Resource-based intrinsic transaction gas\n\nTLDR\n\nEIP-8037 пересматривает стоимость добавления новых данных в состояние в блокчейна, когда буквально надо выделить новый слот, создать аккаунт или записать код контракта. \n\nEIP-8038 пересматривает стоимость доступа к уже существующим данным. \n\nEIP-2780 разбивает фиксированную базовую стоимость транзакции (21_000 газа) на составные части.\n\nЗачем это все?\n\nАбсолютно точно то, что газовая модель фундаментально пересматривается в Glamsterdam. Причина этого, как ни странно, масштабируемость. Увеличение газ-лимита блока до 60 млн. в Fusaka привело к тройному увеличению скорости прироста всего состояния блокчейна. Речь о том, что ежегодно нода будет хранить данных больше на ~116 ГиБ. \n\nПри продолжении увеличения газ-лимита до 200 млн. нода будет получать прирост в ~387 ГиБ в год и больше. В будущем это приведет к падению производительности. \n\nЕдинственный выход сдержать скорость прироста состояния блокчейна — это изменить газовую модель. Простыми словами: нужно сделать работу с данными дороже, чтобы разработчики дважды думали пихать или не пихать свой нос данные в блокчейн.😅\n\n1️⃣ EIP-8037\n\nЭто первое предложение, которое вводит новый расчет при добавлении новых данных в состояние блокчейна. \n\nОно включает в себя:\n- создание контракта через create, create2\n- перевод ETH на адрес, которого еще не было, что инициирует создание аккаунта  \n- первую запись в слот (изменение значения с нуля на что-то) с использованием опкода sstore\n- некоторые другие операции, связанные с call, selfdestruct, делегированием вызова для EOA.\n\nМатематику изменений можно посмотреть в таблице и коде любого клиента ноды, но основная суть в том, что вводится \"магическая переменная\" CPSB (cost per state byte), которая равняется 1530 газа. \n\nТеперь цена операции = [сколько байт она добавляет в состояние] × CPSB:\n\nОперация | Байт | Было | Стало\nНовый слот | 64 | 20_000 | 97 920 (~5×)\nНовый аккаунт | 120 | 25_000 | 183 600 (~7×)\nБайт кода при деплое | 1 | 200 | 1 530 (~7,6×)\nКонтракт 24 КБ целиком | — | ~4,9M | ~37,8M (~8×)\n\nP.S. CPBS взята не с бухты барахты, а рассчитана так, чтобы остановить скорость прироста состояния.\n\nMultidimensional metering\n\nЕсли вы думаете, что это все, то вы ошибаетесь. Помимо изменения базовых параметров стоимости вводится структурное разделение газа на: execution-gas и state-gas.\n\nДля операций по работе с состоянием используется state-gas, а исполнение (прогнать список опкодов вашего кода) - execution-gas.\n\nНа уровне транзакции пользователь платит как за execution-gas, так и за state-gas. Общая стоимость газа для транзакции равна сумме обоих измерений.\n\nТолько есть нюанс: лимит газа на одну транзакцию (~16,7M, EIP-7825) теперь применяется только к execution-gas.\n\nКак же теперь считается лимит газа на уровне блока?\n\nЛимит считается отдельно по сумме execution и state gas для всех транзакций, но учитывается максимальное значение из них. \n\n```js\nblock_gas = max(execution_gas_used, state_gas_used) ≤ gas_limit\n```\n\n2️⃣ EIP-8038\n\nПродолжает изменения газовой модели EIP-8038. Он подключается там, где нужно работать с уже существующим состоянием блокчейна: увеличивает стоимость холодного доступа к аккаунту и изменение уже существующих данных.\n\nКоличество газа за доступ к данным не менялось с 2021 года (Berlin), а состояние блокчейна с тех пор сильно выросло, и чтение с диска стало медленнее.\n\nНапомню, холодным доступом называется первое обращение к слоту или аккаунту в рамках транзакции, а теплым - повторное.\n\nТеплое обращение дешевле по газу, потому что после холодного доступа данные не требуется читать с диска, они уже в быстром доступе.\n\nОперация | Было | Стало\nХолодный доступ к аккаунту | 2_600 | 3_000\nХолодный доступ к стораджу  | 2_100 | 2_100\nТеплый доступ | 100 | 100\nЗапись в структуру аккаунта (nonce, balance, code hash) | ~6_700 | 9_000\nИзменение существующего слота | ~2_800 | 10_000\n\nПри этом холодный доступ к стораджу и теплый доступ остаются без изменения.\n\nЕсли слот имеет нулевое значение, то к нему еще будет добавлен газ из EIP-8037, за создание состояния.\n\nНа самом деле изменений в ценовой политике здесь много, в пост не поместится, при необходимости читать EIP. \n\nПомимо этого интересно здесь то, что все клиенты Ethereum (Geth, Nethermind, Besu, Erigon, Reth и др.) написаны при помощи разных языков (Go, C#, Java, Rust) и используют разные базы данных, оптимизации. Хоть все клиенты и посчитают газ за операцию одинаково, но сделают они это с разной скоростью.\n\nПоэтому было принято, что газ за операции задаёт самый медленный клиент - так сеть защищена от блоков, которые клиенты не успевают проверить.\n\n3️⃣ EIP-2780 \n\nСейчас любая транзакция платит фиксированные 21_000 газа, независимо от того, что она реально делает. Перевод без ETH существующему адресу и перевод, который создаёт новый аккаунт, стоят одинаково, хотя второй навсегда увеличивает состояние блокчейна.\n\nПоэтому предлагается разбить 21_000 на составные части:\n\n• 12_000 - это базовая стоимость, которая взимается за проверку подписи, аккаунт отправителя, включение в блок\n• 3_000 - взимается за холодный доступ к получателю (как описано в EIP-8038);\n• 6_000 - взимается за перевод ETH, который включает в себя запись баланса получателя в структуру аккаунта и лог перевода (это еще один EIP-7708, который пока за рамками нашего поста).\n\n\nЧто же тогда меняется?\n\n\n• обычный перевод ETH на существующий адрес - 21_000, как раньше\n• транзакция без перевода ETH (например, вызов контракта, такой как трансфер ERC-20) - 15_000 + газ за исполнение\n• перевод самому себе (так отменяют зависшую транзакцию: новая с тем же nonce и большей комиссией вытесняет старую) - 12_000;\n• перевод ETH на новый адрес: 21_000 + 183_600 газа состояния (из EIP-8037);\n• деплой контракта: 12 000 (база транзакции) + 12 000 (вычисление и проверка адреса контракта, EIP-8038) + 183_600 за новый аккаунт + 1_530 за каждый байт кода.\n\nИзменение в EIP-2780 было необходимо, потому что без него новый аккаунт можно было бы создать за обычные 21_000 газа и обойти подорожание, описанное в EIP-8037.\n\nВывод\n\n\nGlamsterdam фундаментально меняет то, за что мы платим газом.\n\nРаньше газ был усреднённой ценой «за работу», теперь он оплачивает конкретные ресурсы ноды:\n\n• создание нового состояния, которое навсегда ложится на диск каждой ноды (EIP-8037)\n• доступ к существующим данным и их изменение (EIP-8038)\n• базовую стоимость транзакции, которая теперь зависит от того, что транзакция реально делает (EIP-2780)\n\nНа первый взгляд может показаться, что вычисления дорожают, но отдельный анализ (EIP-7904) показал, что после оптимизаций клиентов под BAL опкоды и прекомпайлы и так укладываются в целевую скорость. Дорожает только то, что ложится на диск.\n\nЛогика простая: чтобы ноды не утонули в данных, создавать новое состояние - дорого, а менять существующее чуть-чуть дорого. 😂\n \n\nЭто грандиозная переделка и при этом обратно несовместимое изменение, которое требует планового обновления сети. \n\nЧто стоит проверить разработчикам:\n\n• eth_estimateGas - обновите ноду или убедитесь, что ваш RPC-провайдер поддерживает новую газовую модель, иначе транзакции будут падать от недооценки газа\n• если вы закладываете ровно 21_000 на любой перевод ETH, сервис сломается на переводе на новый адрес\n• захардкоженные лимиты газа в контрактах и скриптах могут перестать покрывать исполнение, транзакции будут фейлиться\n• замеры газа через разницу gasleft() до и после вызова могут дать отрицательный результат (EIP-8037).\n\n#павел_найданов\n\n🤟 Сайт | ТГ-канал | Наш чат","html":"<strong>Часть 1: Газовая модель - \"Состояние</strong> <strong>блокчейна\"</strong><br><br>В этот раз работы по газу было проделано много, первые три нововведения рассмотрим в этом посте.<br><br>1. <a href=\"https://eips.ethereum.org/EIPS/eip-8037\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-8037: State Creation Gas Cost Increase</a><br>2. <a href=\"https://eips.ethereum.org/EIPS/eip-8038\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-8038: State-access gas cost update</a><br>3. <a href=\"https://eips.ethereum.org/EIPS/eip-2780\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-2780: Resource-based intrinsic transaction gas</a><br><br><strong>TLDR</strong><br><br><a href=\"https://eips.ethereum.org/EIPS/eip-8037\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-8037</a><em> пересматривает стоимость добавления новых данных в состояние в блокчейна, когда буквально надо выделить новый слот, создать аккаунт или записать код контракта. <br><br></em><a href=\"https://eips.ethereum.org/EIPS/eip-8038\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-8038</a><em> пересматривает стоимость доступа к уже существующим данным. <br><br></em><a href=\"https://eips.ethereum.org/EIPS/eip-2780\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-2780</a><em> разбивает фиксированную базовую стоимость транзакции (21_000 газа) на составные части.</em><br><br><strong>Зачем это все?</strong><br><br>Абсолютно точно то, что газовая модель фундаментально пересматривается в Glamsterdam. Причина этого, как ни странно, масштабируемость. Увеличение газ-лимита блока до 60 млн. в Fusaka привело<strong> к тройному увеличению скорости прироста всего состояния блокчейна.</strong> Речь о том, что ежегодно нода будет хранить данных больше на ~116 ГиБ. <br><br>При продолжении увеличения газ-лимита до 200 млн. нода будет получать прирост в ~387 ГиБ в год и больше. В будущем это приведет к падению производительности. <br><br>Единственный выход сдержать скорость прироста состояния блокчейна — это изменить газовую модель. Простыми словами: нужно сделать работу с данными дороже, чтобы разработчики дважды думали пихать или не пихать <del>свой нос</del> данные в блокчейн.😅<br><br>1️⃣ <strong>EIP-8037</strong><br><br>Это первое предложение, которое вводит новый расчет при добавлении новых данных в состояние блокчейна. <br><br>Оно включает в себя:<br>- создание контракта через <code>create</code>, <code>create2</code><br>- перевод ETH на адрес, которого еще не было, что инициирует создание аккаунта  <br>- первую запись в слот (изменение значения с нуля на что-то) с использованием опкода <code>sstore</code><br>- некоторые другие операции, связанные с <code>call</code>, <code>selfdestruct</code>, делегированием вызова для EOA.<br><br>Математику изменений можно посмотреть в <a href=\"https://eips.ethereum.org/EIPS/eip-8037\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">таблице</a> и коде любого клиента ноды, но основная суть в том, что вводится \"магическая переменная\" <strong>CPSB</strong> (cost per state byte), которая равняется 1530 газа. <br><br>Теперь цена операции = [сколько байт она добавляет в состояние] × CPSB:<br><br>Операция | Байт | Было | Стало<br>Новый слот | 64 | 20_000 | 97 920 (~5×)<br>Новый аккаунт | 120 | 25_000 | 183 600 (~7×)<br>Байт кода при деплое | 1 | 200 | 1 530 (~7,6×)<br>Контракт 24 КБ целиком | — | ~4,9M | ~37,8M (~8×)<br><br>P.S. CPBS взята не с бухты барахты, а рассчитана так, чтобы остановить скорость прироста состояния.<br><strong><br>Multidimensional metering</strong><br><br>Если вы думаете, что это все, то вы ошибаетесь. Помимо изменения базовых параметров стоимости вводится структурное разделение газа на: <strong>execution-gas</strong> и <strong>state-gas</strong>.<br><br>Для операций по работе с состоянием используется state-gas, а исполнение (прогнать список опкодов вашего кода) - execution-gas.<br><br>На уровне транзакции пользователь платит как за execution-gas, так и за state-gas. Общая стоимость газа для транзакции равна сумме обоих измерений.<br><br>Только есть нюанс: лимит газа на одну транзакцию (~16,7M, <a href=\"https://eips.ethereum.org/EIPS/eip-7825\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-7825</a>) теперь применяется только к execution-gas.<br><br><strong>Как же теперь считается лимит газа на уровне блока?</strong><br><br>Лимит считается отдельно по сумме execution и state gas для всех транзакций, но учитывается максимальное значение из них. <br><br>```js<br>block_gas = max(execution_gas_used, state_gas_used) ≤ gas_limit<br>```<br><br>2️⃣ <strong>EIP-8038</strong><br><br>Продолжает изменения газовой модели EIP-8038. Он подключается там, где нужно работать с уже существующим состоянием блокчейна: увеличивает стоимость холодного доступа к аккаунту и изменение уже существующих данных.<br><br><em>Количество газа за доступ к данным не менялось с 2021 года (Berlin), а состояние блокчейна с тех пор сильно выросло, и чтение с диска стало медленнее.</em><br><br>Напомню, холодным доступом называется первое обращение к слоту или аккаунту в рамках транзакции, а теплым - повторное.<br><br>Теплое обращение дешевле по газу, потому что после холодного доступа данные не требуется читать с диска, они уже в быстром доступе.<br><br>Операция | Было | Стало<br>Холодный доступ к аккаунту | 2_600 | 3_000<br>Холодный доступ к стораджу  | 2_100 | 2_100<br>Теплый доступ | 100 | 100<br>Запись в структуру аккаунта (nonce, balance, code hash) | ~6_700 | 9_000<br>Изменение существующего слота | ~2_800 | 10_000<br><br>При этом холодный доступ к стораджу и теплый доступ остаются без изменения.<br><br><em>Если слот имеет нулевое значение, то к нему еще будет добавлен газ из EIP-8037, за создание состояния.</em><br><br>На самом деле изменений в ценовой политике здесь много, в пост не поместится, при необходимости читать <a href=\"https://eips.ethereum.org/EIPS/eip-8038\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP</a>. <br><br>Помимо этого интересно здесь то, что все клиенты Ethereum (Geth, Nethermind, Besu, Erigon, Reth и др.) написаны при помощи разных языков (Go, C#, Java, Rust) и используют разные базы данных, оптимизации. Хоть все клиенты и посчитают газ за операцию одинаково, но сделают они это с разной скоростью.<br><br>Поэтому было принято, что газ за операции задаёт самый медленный клиент - так сеть защищена от блоков, которые клиенты не успевают проверить.<br><br>3️⃣ <strong>EIP-2780 </strong><br><br>Сейчас любая транзакция платит фиксированные 21_000 газа, независимо от того, что она реально делает. Перевод без ETH существующему адресу и перевод, который создаёт новый аккаунт, стоят одинаково, хотя второй навсегда увеличивает состояние блокчейна.<br><br>Поэтому предлагается разбить 21_000 на составные части:<br><br>• 12_000 - это базовая стоимость, которая взимается за проверку подписи, аккаунт отправителя, включение в блок<br>• 3_000 - взимается за холодный доступ к получателю (как описано в EIP-8038);<br>• 6_000 - взимается за перевод ETH, который включает в себя запись баланса получателя в структуру аккаунта и лог перевода (это еще один <a href=\"https://eips.ethereum.org/EIPS/eip-7708\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-7708</a>, который пока за рамками нашего поста).<br><br><br><strong>Что же тогда меняется?</strong><br><br><br>• обычный перевод ETH на существующий адрес - 21_000, как раньше<br>• транзакция без перевода ETH (например, вызов контракта, такой как трансфер ERC-20) - 15_000 + газ за исполнение<br>• перевод самому себе (так отменяют зависшую транзакцию: новая с тем же nonce и большей комиссией вытесняет старую) - 12_000;<br>• перевод ETH на новый адрес: 21_000 + 183_600 газа состояния (из EIP-8037);<br>• деплой контракта: 12 000 (база транзакции) + 12 000 (вычисление и проверка адреса контракта, EIP-8038) + 183_600 за новый аккаунт + 1_530 за каждый байт кода.<br><br>Изменение в EIP-2780 было необходимо, потому что без него новый аккаунт можно было бы создать за обычные 21_000 газа и обойти подорожание, описанное в EIP-8037.<br><br><strong>Вывод</strong><br><br><br>Glamsterdam фундаментально меняет то, за что мы платим газом.<br><br>Раньше газ был усреднённой ценой «за работу», теперь он оплачивает конкретные ресурсы ноды:<br><br>• создание нового состояния, которое навсегда ложится на диск каждой ноды (EIP-8037)<br>• доступ к существующим данным и их изменение (EIP-8038)<br>• базовую стоимость транзакции, которая теперь зависит от того, что транзакция реально делает (EIP-2780)<br><br>На первый взгляд может показаться, что вычисления дорожают, но отдельный анализ (<a href=\"https://eips.ethereum.org/EIPS/eip-7904\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-7904</a>) показал, что после оптимизаций клиентов под BAL опкоды и прекомпайлы и так укладываются в целевую скорость. Дорожает только то, что ложится на диск.<br><br>Логика простая: чтобы ноды не утонули в данных, создавать новое состояние - дорого, а менять существующее чуть-чуть дорого. 😂<br> <br><br>Это грандиозная переделка и при этом обратно несовместимое изменение, которое требует планового обновления сети. <br><br>Что стоит проверить разработчикам:<br><br>• <code>eth_estimateGas</code> - обновите ноду или убедитесь, что ваш RPC-провайдер поддерживает новую газовую модель, иначе транзакции будут падать от недооценки газа<br>• если вы закладываете ровно 21_000 на любой перевод ETH, сервис сломается на переводе на новый адрес<br>• захардкоженные лимиты газа в контрактах и скриптах могут перестать покрывать исполнение, транзакции будут фейлиться<br>• замеры газа через разницу <code>gasleft()</code> до и после вызова могут дать отрицательный результат (EIP-8037).<br><br>#павел_найданов<br><br>🤟 <a href=\"https://metalamp.ru/\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Сайт</strong></a> | <a href=\"https://t.me/metalampru\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>ТГ-канал</strong></a> | <a href=\"https://t.me/+L_tFSdgfNcwxNjEy\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Наш чат</strong></a>","language":"ru","class":"approved","duplicate_of":null,"secondary_of":null,"in_aggregator":true,"aggregator_url":"https://t.me/WEB3_AGGREGATOR/426136","deleted":false,"deleted_at":null,"views":320,"forwards":6,"sender_id":null,"cashtags":[],"hashtags":["павел_найданов"],"addresses":[],"domains":["eips.ethereum.org","ethereum.org","metalamp.ru","t.me"],"media":[{"type":"photo","url":"https://media.web3aggregator.io/files/pqSFrGwKOgEo","duration":null,"width":1024,"height":654,"preview":false}],"link_preview":null,"album":null,"topic":"research"},{"id":18090,"channel":{"id":180,"username":"metalampru","title":"MetaLamp | CIS","kind":"channel","private":false},"message_id":716,"url":"https://t.me/metalampru/716","date":"2026-10-28T08:50:53+00:00","edited_at":null,"text":"СКУЧАЛИ? \n\nНадеемся, что да, а то мы тут немного пропали из виду.\n\nНо возвращаемся с новым выпуском подкаста! И не абы с кем, а с Михаилом из Sherlock 🕵️‍♂️\n\nСнова говорим про безопасность, но на этот раз больше с бизнесовой стороны 💰\n\nНам было интересно разобраться, как вообще устроен рынок аудитов, на чём зарабатывают security-компании, как конкурируют за клиентов и что сейчас происходит в индустрии.\n\nНу и как же, конечно не обошлось без разговоров про AI, миллионные взломы и будущее аудиторов.\n\nВ общем, получился вроде интересный разговор на тему Web3 Security с другой стороны — не глазами разработчиков, а глазами тех, кто продаёт безопасность крупнейшим криптопроектам.\n\nДетали в подкасте, вперёд слушать!\n\n📺 YouTube\n🎵 Яндекс-музыка\n🎵 Apple-подкасты\n💬 Слушать в Telegram\n\n🤟 Сайт | ТГ-канал | Наш чат","html":"<strong>СКУЧАЛИ?</strong> <br><br>Надеемся, что да, а то мы тут немного пропали из виду.<br><br>Но возвращаемся с новым выпуском подкаста! И не абы с кем, а с Михаилом из <strong>Sherlock</strong> 🕵️‍♂️<br><br>Снова говорим про безопасность, но на этот раз больше с бизнесовой стороны 💰<br><br>Нам было интересно разобраться,<strong> как вообще устроен рынок аудитов, на чём зарабатывают security-компании, как конкурируют за клиентов и что сейчас происходит в индустрии.</strong><br><br>Ну и как же, конечно не обошлось без разговоров про AI, миллионные взломы и будущее аудиторов.<br><br>В общем, получился вроде интересный разговор на тему Web3 Security с другой стороны — не глазами разработчиков, а глазами тех, кто продаёт безопасность крупнейшим криптопроектам.<br><br>Детали в подкасте, вперёд слушать!<br><br><strong>📺</strong><strong> </strong><a href=\"https://youtu.be/2fPuCp1Fen0?si=6fTYKOzDtctMPmIp\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>YouTube</strong></a><strong><br></strong><strong>🎵</strong><strong> </strong><a href=\"https://music.yandex.ru/album/36320292\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Яндекс-музыка</strong></a><strong><br></strong><strong>🎵</strong><strong> </strong><a href=\"https://podcasts.apple.com/us/podcast/metalamp-%D0%BE-web3/id1837845390\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Apple-подкасты</strong></a><strong><br></strong><strong>💬</strong><strong> </strong><a href=\"https://t.me/mavestreambot/app?startapp=metalamp\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Слушать в Telegram</strong></a><br><br>🤟 <a href=\"https://metalamp.ru/\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Сайт</strong></a><strong> | </strong><a href=\"https://t.me/metalampru\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>ТГ-канал</strong></a><strong> | </strong><a href=\"https://t.me/+L_tFSdgfNcwxNjEy\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Наш чат</strong></a>","language":"ru","class":"approved","duplicate_of":null,"secondary_of":null,"in_aggregator":true,"aggregator_url":"https://t.me/WEB3_AGGREGATOR/425855","deleted":false,"deleted_at":null,"views":110,"forwards":3,"sender_id":null,"cashtags":[],"hashtags":[],"addresses":[],"domains":["youtu.be","music.yandex.ru","yandex.ru","podcasts.apple.com","apple.com","t.me","metalamp.ru"],"media":[{"type":"photo","url":"https://media.web3aggregator.io/files/pASlrG9iyCEs","duration":null,"width":1280,"height":723,"preview":false}],"link_preview":null,"album":null,"topic":"media"},{"id":17169,"channel":{"id":180,"username":"metalampru","title":"MetaLamp | CIS","kind":"channel","private":false},"message_id":715,"url":"https://t.me/metalampru/715","date":"2026-10-23T10:31:01+00:00","edited_at":"2026-10-27T15:45:54+00:00","text":"Block-Level Access Lists (BAL)\n\nСледующий в Glamsterdam по важности: EIP-7928: Block-Level Access Lists. \n\nВместе ePBS и BAL создают основу для масштабирования производительности Ethereum.\n\nКаким образом масштабируемся?\n\nСейчас валидатор для проверки транзакций в блоке может их исполнить только последовательно или применив собственные оптимизации, т.к. неизвестно, как транзакции будут менять состояние блокчейна и важен порядок выполнения.\n\nРазработчики решили, что нужно исполнять транзакции параллельно, благодаря чему, блок проверяется быстрее и можно поднять лимит газа на блок. А это значит, можно запихать в него больше транзакций.\n\nКак сделать параллельное исполнение?\n\nНужно, чтобы вместе с блоком заранее приходил результат его выполнения: какие слоты меняются и какими они станут после каждой транзакции.\n \nДля этого разработали специальную структуру (BAL), чтобы хранить информацию о том, какие транзакции => какие слоты памяти будут изменять. \n\nТаким образом, можно исполнять транзакции параллельно и изолированно друг от друга, потому что будет известно начальное и конечное состояние стейта блокчейна на момент запуска.\n\nВ BAL все транзакции пронумерованы от 1 до n. Если до n-й транзакции слот в блоке никто не менял, значение читается с диска ноды. Если менял, берётся последнее значение из BAL.\n\nЧто лежит в BAL?\n\nBAL — это список адресов контрактов и акаунтов. Для каждого такого акаунта передается:\nstorage_changes — какие слоты изменились и на какое значение после какой транзакции;\nstorage_reads — слоты, которые только читали;\nbalance_changes, nonce_changes, code_changes — новые значения после каждой транзакции.\n\nКак передается BAL? \n\nВ каждый заголовок блока добавляется поле block_access_list_hash. который хранит хэш BAL. \n\nСам BAL лежит не в теле блока, а в ExecutionPayload и передаётся между CL и EL через Engine API.\nХранить его клиенты должны достаточно долго, не меньше 3533 эпох (это около 16 дней).\n\nКто формирует BAL и можно ли ему доверять?\n\nBAL собирает билдер вместе с payload. Напихать туда он может что угодно, поэтому нода доверять этому не может и должна формировать свой BAL, проверяя его с переданным от билдера.\n\nПолучается, что BAL выступает, как подсказка для выполнения, а не замена полноценному исполнению блока. При этом, если что-то не сходится, то блок считается невалидным. \n\nПример\n\nДано: Алиса, Боб и USDC.\n\nДо блока у Алисы 100 USDC, у Боба 0. \n\nВ блоке две транзакции: Алиса отправляет Бобу 30, а Боб отправляет Алисе 10. Вторая транзакция зависит от первой: без неё Бобу просто нечего отправлять. \n\nБез BAL валидатор обязан исполнить их строго по очереди. С BAL он уже знает, какими станут балансы после каждой транзакции: после tx1 — 70 и 30, после tx2 — 80 и 20.\n\n[\n  [ 0x...,                                  # адрес контракта USDC\n    [                                       # storage_changes\n      [ баланс_Алисы, [[1, 70], [2, 80]] ], # слот: [[номер tx, значение после tx]]\n      [ баланс_Боба,  [[1, 30], [2, 20]] ],\n    ],\n    [],                                     # storage_reads\n    [],                                     # balance_changes (ETH)\n    [],                                     # nonce_changes\n    []                                      # code_changes\n  ]\n]\n\nПоэтому валидатор запускает обе транзакции одновременно. tx1 берёт балансы с диска (100 и 0, так как до tx1 эти слоты в блоке никто не менял), а tx2 берет балансы из BAL (70 и 30), не дожидаясь tx1. \n\nВ конце валидатор сверяет: совпали ли результаты с тем, что записано в BAL? Если да, блок валиден. Если билдер где-то соврал, проверка не сойдётся, и блок невалиден.\n\nВывод\n\nПолучается, что ePBS дает время, расширяя окно распространения данных блока до 6-9 секунд, а BAL позволяет эффективнее использовать это время для проверки транзакций за счет параллельного исполнения. \n\nИз неочевидного, это то, что BAL дает не только возможность исполнить транзакции параллельно. \n\nТакже добавляется:\n1. Параллельное чтение значений слотов из диска, потому что BAL перечисляет все слоты, которые будут прочитаны или изменены в рамках блока. И это даже более круто по производительности, чем исполнение.\n2. Для билдера построение BAL обязательно, но код клиента ноды может исполнить блок и по старинке последовательно, а потом просто сравнить.\n\n#павел_найданов\n\n\n\n\n\n🤟 Сайт | ТГ-канал | Наш чат","html":"<strong>Block-Level Access Lists</strong> <strong>(BAL)</strong><br><br>Следующий в Glamsterdam по важности: <a href=\"https://eips.ethereum.org/EIPS/eip-7928\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-7928: Block-Level Access Lists</a>. <br><br><em>Вместе ePBS и BAL создают основу для масштабирования производительности</em> Ethereum.<br><br><strong>Каким образом масштабируемся?<br><br></strong>Сейчас валидатор для проверки транзакций в блоке может их исполнить только последовательно или применив собственные оптимизации, т.к. неизвестно, как транзакции будут менять состояние блокчейна и важен порядок выполнения.<br><br>Разработчики решили, что нужно исполнять транзакции параллельно, благодаря чему, блок проверяется быстрее и можно поднять лимит газа на блок. А это значит, можно запихать в него больше транзакций.<br><br><strong>Как сделать параллельное исполнение?</strong><br><br>Нужно, чтобы вместе с блоком заранее приходил результат его выполнения: какие слоты меняются и какими они станут после каждой транзакции.<br> <br>Для этого разработали специальную структуру (BAL), чтобы хранить информацию о том, какие транзакции =&gt; какие слоты памяти будут изменять. <br><br>Таким образом, можно исполнять транзакции параллельно и изолированно друг от друга, потому что будет известно начальное и конечное состояние стейта блокчейна на момент запуска.<br><br>В BAL все транзакции пронумерованы от 1 до <strong>n</strong>. Если до <strong>n</strong>-й транзакции слот в блоке никто не менял, значение читается с диска ноды. Если менял, берётся последнее значение из BAL.<br><br><strong>Что лежит в BAL?</strong><br><br>BAL — это список адресов контрактов и акаунтов. Для каждого такого акаунта передается:<br><code>storage_changes</code> — какие слоты изменились и на какое значение после какой транзакции;<br><code>storage_reads</code> — слоты, которые только читали;<br><code>balance_changes</code>, <code>nonce_changes</code>, <code>code_changes</code> — новые значения после каждой транзакции.<br><br><strong>Как передается BAL? </strong><br><br>В каждый заголовок блока добавляется поле <code>block_access_list_hash</code>. который хранит хэш BAL. <br><br>Сам BAL лежит не в теле блока, а в <code>ExecutionPayload</code> и передаётся между CL и EL через Engine API.<br>Хранить его клиенты должны достаточно долго, не меньше 3533 эпох (это около 16 дней).<br><br><strong>Кто формирует BAL и можно ли ему доверять?</strong><br><br>BAL собирает билдер вместе с payload. Напихать туда он может что угодно, поэтому нода доверять этому не может и должна формировать свой BAL, проверяя его с переданным от билдера.<br><br>Получается, что BAL выступает, как подсказка для выполнения, а не замена полноценному исполнению блока. При этом, если что-то не сходится, то блок считается невалидным. <br><br><strong>Пример</strong><br><br><strong>Дано: </strong>Алиса, Боб и USDC.<br><br>До блока у Алисы 100 USDC, у Боба 0. <br><br>В блоке две транзакции: Алиса отправляет Бобу 30, а Боб отправляет Алисе 10. Вторая транзакция зависит от первой: без неё Бобу просто нечего отправлять. <br><br>Без BAL валидатор обязан исполнить их строго по очереди. С BAL он уже знает, какими станут балансы после каждой транзакции: после tx1 — 70 и 30, после tx2 — 80 и 20.<br><br><pre><code>[<br>  [ 0x...,                                  # адрес контракта USDC<br>    [                                       # storage_changes<br>      [ баланс_Алисы, [[1, 70], [2, 80]] ], # слот: [[номер tx, значение после tx]]<br>      [ баланс_Боба,  [[1, 30], [2, 20]] ],<br>    ],<br>    [],                                     # storage_reads<br>    [],                                     # balance_changes (ETH)<br>    [],                                     # nonce_changes<br>    []                                      # code_changes<br>  ]<br>]</code></pre><br><br>Поэтому валидатор запускает обе транзакции одновременно. tx1 берёт балансы с диска (100 и 0, так как до tx1 эти слоты в блоке никто не менял), а tx2 берет балансы из BAL (70 и 30), не дожидаясь tx1. <br><br>В конце валидатор сверяет: совпали ли результаты с тем, что записано в BAL? Если да, блок валиден. Если билдер где-то соврал, проверка не сойдётся, и блок невалиден.<br><br><strong>Вывод</strong><br><br>Получается, что ePBS дает время, расширяя окно распространения данных блока до 6-9 секунд, а BAL позволяет эффективнее использовать это время для проверки транзакций за счет параллельного исполнения. <br><br>Из неочевидного, это то, что BAL дает не только возможность исполнить транзакции параллельно. <br><br>Также добавляется:<br>1. Параллельное чтение значений слотов из диска, потому что BAL перечисляет все слоты, которые будут прочитаны или изменены в рамках блока. И это даже более круто по производительности, чем исполнение.<br>2. Для билдера построение BAL обязательно, но код клиента ноды может исполнить блок и по старинке последовательно, а потом просто сравнить.<br><br>#павел_найданов<br><br><br><br><br><br>🤟 <a href=\"https://metalamp.ru/\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Сайт</strong></a> | <a href=\"https://t.me/metalampru\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>ТГ-канал</strong></a> | <a href=\"https://t.me/+L_tFSdgfNcwxNjEy\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Наш чат</strong></a>","language":"ru","class":"approved","duplicate_of":null,"secondary_of":null,"in_aggregator":true,"aggregator_url":"https://t.me/WEB3_AGGREGATOR/425621","deleted":false,"deleted_at":null,"views":817,"forwards":12,"sender_id":null,"cashtags":[],"hashtags":["павел_найданов"],"addresses":[],"domains":["eips.ethereum.org","ethereum.org","metalamp.ru","t.me"],"media":[{"type":"photo","url":"https://media.web3aggregator.io/files/pOh5rGwKOcEo","duration":null,"width":2560,"height":1706,"preview":false}],"link_preview":null,"album":null,"topic":"research"},{"id":14708,"channel":{"id":180,"username":"metalampru","title":"MetaLamp | CIS","kind":"channel","private":false},"message_id":713,"url":"https://t.me/metalampru/713","date":"2026-10-14T12:35:10+00:00","edited_at":"2026-10-14T12:43:24+00:00","text":"Enshrined Proposer-Builder Separation\n\n\nНу что, начинаем погружение в Glamsterdam с фаворита: EIP-7732: Enshrined Proposer-Builder Separation.\n\n1. Разделяет блок на части консенсуса и исполнения\n2. Пропоузер напрямую выбирает билдера блока\n3. Вводится новая сущность builder, а у валидаторов появляется новая обязанность: голосовать за своевременность payload\n\nКак транзакция живет сейчас?\n\n1️⃣ Пользователь и транзакции\n\nПользователь подписывает транзакцию своим приватным ключом и отправляет ее через RPC. Дальше у нее два пути. \n\nПервый — публичный мемпул, где её видят все ноды и все MEV-боты. \nВторой — приватный канал (Flashbots Protect или MEV Blocker). В этом случае транзакция уходит напрямую нескольким билдерам и защищена от сэндвичей. Сейчас заметная доля транзакций идёт именно приватно.\n\n2️⃣ Searcher => Builder\n\nСерчеры ищут MEV среди транзакций: арбитраж, ликвидации, фронтраны. Найденное они упаковывают в бандлы (упорядоченная группа транзакций) и отправляют билдерам.\n\nБилдер в течение всего слота непрерывно пересобирает лучший блок из мемпула, бандлов. \n\nБилдер готовит ставку (по сути — взятка за место в блоке) пропозеру, чтобы его блок был принят и прокинут дальше к валидаторам. Обычно вставляет взятку последней транзакцией. Выглядит, как перевод на  fee_recipient пропозера. \n\n4️⃣ Relay\n\nЭто доверенный посредник между билдерами и пропозерами. Он получает от билдеров полные блоки и симулирует их: проверяет валидность.\n\nРелей отдаёт пропозеру только заголовок с его взяткой. Сам payload (список транзакций) держит у себя, чтобы пропозер не мог украсть MEV билдера.\n\n4️⃣ Proposer (MEV boost)\n\nПропоузер  - это первая, официальная часть самого блокчейна Ethereum. Это не сторонняя надстройка, а ключевая роль внутри консенсуса Proof-of-Stake (PoS). \n\nПо сути — это валидатор, который в данный момент выбран для предложения блока. Расписание того, кто будет пропозером видно как минимум на эпоху вперёд. \n\nЧерез платформу MEV boost пропоузер ждет от релееров заголовки блоков без payload (без транзакций). \n\nОн мог бы по старинке собрать блок из мемпула, но ему нужно извлечь как можно больше MEV. Поэтому он ждет заголовки и взятки от релееров, а затем выбирает самый вкусный блок.\n\n5️⃣ Проверка и аттестация\n\nПропозер подписывает «слепой» блок (только заголовок) и отдаёт его релею. Релей подставляет транзакции и публикует полный блок. Дальше валидаторы из комитета слота проверяют его и голосуют (аттестуют).\n\n6️⃣ Финализация\n \nЕсли все ок, то пропоузер, в момент исполнения блока получает свою награду (priority fees + ту самую жирную взятку от билдера, которой с ним поделились серчеры).\n\nПосле того, как ⅔ стейка проголосовало со следующим чекпоинтом блок считается финализированным.\n\nЧто здесь может быть не так?\n\nНапример централизация: активных билдеров порядка 5-10, совсем недавно 80-85% всех блоков собиралось двумя билдерами — BeaverBuild и Titan Builder. Картина  динамичная, но ситуация все равно печальная. Самую свежую ситуацию можно посмотреть на relayscan.io.\n\nА релееров у нас порядка 6-8. Из них четыре игрока контролируют почти все. Ultra Sound, Titan, bloXroute (две версии) и Agnostic Relay. Кто-то из них может опускаться, подниматься, но суть такая же, как и с билдерами.\n\nСамое интересное, что они сейчас ничего не зарабатывают. Это благотворительность от больших игроков. Они вынуждены быть прослойкой, которой могут доверять и пропоузеры и билдеры, чтобы все работало. \n\nБолее того, у титана и билдер, и релеер, доверяет сам себе или все доверяют титану?😅\n\nИ это интересно понимать, на фоне, когда ругают другие чейны за их централизацию валидаторов. В Ethereum с валидаторами проблем нет — их сотни тысяч, но проблему я обозначил.\n\nКак транзакция будет жить после Glamsterdam?\n\nСхема, описанная выше, меняется фундаментально. Билдер теперь не внешний сервис, а сущность внутри BeaconState в реестре builders. А релееры перестают быть обязательной прослойкой между билдером и пропоузером.\n\nБилдер вносит депозит, минимум — 1 ETH. После этого он становится частью Ethereum. Для него нет очереди входа и выхода, как у валидаторов.\n\nСтейк билдера не голосует, он работает как залог: из него протокол списывает оплату пропозеру. Отсюда простое правило: билдер не может предложить взятку пропоузеру больше своего баланса.\nВ Glamsterdam у транзакции будет совсем другая жизнь.\n\n1️⃣ Пользователь и транзакции\n\nНа этом уровне все по-прежнему: пользователь подписывает транзакцию и отправляет ее в сеть.\n\n2️⃣ Proposer\n\nЗаранее известный пропоузер, который назначен королем танцпола, публикует данные о себе для билдеров. Так же, как раньше он делал это для релееров. Газ-лимит на блок и свой адрес для получения комиссии.\n\n3️⃣ Builder\n\nБилдеры собирают блоки из бандлов и доступных транзакций из мемпула, формируют заголовок блока и фиксируют взятку пропозеру. После этого отправляют пропозеру: взятку, block_hash будущего payload и коммитменты блобов. Сами транзакции и блобы остаются у билдера.\n\n4️⃣ Proposer публикует блок в beacon chain\n\nПропоузер выбирает самую выгодную взятку и кладёт её в свой beacon block. Этот блок максимально легкий, потому что в нем нет транзакций и блобов. В момент обработки этого блока сумма взятки списывается с баланса билдера. Если пропозер хочет строить сам, он ставит BUILDER_INDEX_SELF_BUILD с нулевой суммой.\n\n5️⃣ Аттестация\n\nВалидаторы голосуют за beacon block, проверив только консенсусную часть. Исполнять транзакции на этом шаге не нужно, поэтому это выполняется быстро.\n\n6️⃣ Builder раскрывает payload\n\nБилдер видит, что его блок прошел аттестацию и раскрывает payload вместе с блобами. \n\nРаскрывать стоит именно после аттестаций: если блок пропозера опоздал или его реорганизовали, билдер может ничего не раскрывать и не платит.\n\n7️⃣ PTC голосует (512 валидаторов)\n\nPTC (Payload Timeliness Committee) — это 512 валидаторов, которые голосуют за раскрытый payload. Причем у них нет задачи его прогонять, они только проверяют своевременность его прихода на проверку и что hash совпадает с тем, что был отправлен на проверку в консенсусе. Также проверяется доступность блобов.\n\nЕсли payload принят, списанная сумма с билдера передается пропозеру. Если payload не раскрыт билдером, но beacon block набрал достаточно веса аттестаций, пропозеру всё равно отправят взятку. \n\nПолучается двойная страховка и билдер не платит только если блок не принят вообще.\n\nТакже важно, что дальше процесс финализации не меняется, меняется только процесс постройки и проверки блока внутри слота.\n\nВопрос: а кто же проверяет payload?\n\nПосле того, как payload раскрывается PTC не проверяет payload, поэтому это делает следующий пропоузер и у него есть на это 6 сек. Также payload проверяют и валидаторы нового слота до момента, пока новые блоки формируются и не наступит время их аттестации. Это 9 сек.\n\nВывод\n\nePBS решает сразу две задачи, которые на первый взгляд не связаны.\n\nПервая — доверие и централизация. Сегодня блоки строятся катастрофически малым количеством внешних билдеров. А честность обмена блоками между билдерами и пропозером гарантирует горстка релеев, которые не имеют экономического стимула от слова совсем.\n\nПосле Glamsterdam билдер становится участником протокола со стейком, а честность и прозрачность обеспечивают правила консенсуса и комитет PTC: пропозер получает оплату, даже если билдер подвёл, а своевременно раскрытый payload честного билдера гарантированно попадает в цепочку.\n\n\n\nВторая — масштабирование. Блок делится на консенсусную часть и исполнительную, при этом тяжёлая проверка транзакций переезжает из узкого окна в 4 секунды в окно 6–9 секунд. Именно это, вместе с block-level access lists (EIP-7928), позволяет перейти к более высоким лимитам на газ.\n\nP.S. Насколько ситуация с билдерами улучшится — мне пока не понятно. Те же самые два билдера продолжат работу по постройке блока, да, теперь им надо стейкать ETH, но у них есть законный механизм по придержанию раскрытия payload. Что может привести к появлению большого количества пустых слотов, что для обывателя выльется в увеличенное время ожидания исполнения его транзакции.\n\n#павел_найданов\n\n🤟 Сайт | ТГ-канал | Наш чат","html":"<strong>Enshrined Proposer-Builder Separation</strong><br><br><br>Ну что, начинаем погружение в Glamsterdam с фаворита: <a href=\"https://eips.ethereum.org/EIPS/eip-7732\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">EIP-7732: Enshrined Proposer-Builder Separation</a>.<br><br><em>1. Разделяет блок на части консенсуса и исполнения<br>2. Пропоузер</em> напрямую выбирает билдера блока<br>3. <em>Вводится новая сущность </em><code>builder</code><em>, а у валидаторов появляется новая обязанность: голосовать за своевременность </em><code>payload</code><br><br><strong>Как транзакция живет сейчас?</strong><br><br>1️⃣<strong> Пользователь и транзакции</strong><br><br>Пользователь подписывает транзакцию своим приватным ключом и отправляет ее через RPC. Дальше у нее два пути. <br><br>Первый — публичный мемпул, где её видят все ноды и все MEV-боты. <br>Второй — приватный канал (Flashbots Protect или MEV Blocker). В этом случае транзакция уходит напрямую нескольким билдерам и защищена от сэндвичей. Сейчас заметная доля транзакций идёт именно приватно.<br><br>2️⃣ <strong>Searcher =&gt; Builder</strong><br><br>Серчеры ищут MEV среди транзакций: арбитраж, ликвидации, фронтраны. Найденное они упаковывают в бандлы (упорядоченная группа транзакций) и отправляют билдерам.<br><br>Билдер в течение всего слота непрерывно пересобирает лучший блок из мемпула, бандлов. <br><br>Билдер готовит ставку (по сути — взятка за место в блоке) пропозеру, чтобы его блок был принят и прокинут дальше к валидаторам. Обычно вставляет взятку последней транзакцией. Выглядит, как перевод на  <code>fee_recipient</code> пропозера. <br><br>4️⃣ <strong>Relay</strong><br><br>Это доверенный посредник между билдерами и пропозерами. Он получает от билдеров полные блоки и симулирует их: проверяет валидность.<br><br>Релей отдаёт пропозеру только заголовок с его взяткой. Сам payload (список транзакций) держит у себя, чтобы пропозер не мог украсть MEV билдера.<br><br>4️⃣ <strong>Proposer (MEV boost)</strong><br><br>Пропоузер  - это первая, официальная часть самого блокчейна Ethereum. Это не сторонняя надстройка, а ключевая роль внутри консенсуса Proof-of-Stake (PoS). <br><br>По сути — это валидатор, который в данный момент выбран для предложения блока. Расписание того, кто будет пропозером видно как минимум на эпоху вперёд. <br><br>Через платформу MEV boost пропоузер ждет от релееров заголовки блоков без payload (без транзакций). <br><br>Он мог бы по старинке собрать блок из мемпула, но ему нужно извлечь как можно больше MEV. Поэтому он ждет заголовки и взятки от релееров, а затем выбирает самый вкусный блок.<br><br>5️⃣ <strong>Проверка и аттестация</strong><br><br>Пропозер подписывает «слепой» блок (только заголовок) и отдаёт его релею. Релей подставляет транзакции и публикует полный блок. Дальше валидаторы из комитета слота проверяют его и голосуют (аттестуют).<br><br>6️⃣ <strong>Финализация</strong><br> <br>Если все ок, то пропоузер, в момент исполнения блока получает свою награду (priority fees + ту самую жирную взятку от билдера, которой с ним поделились серчеры).<br><br>После того, как ⅔ стейка проголосовало со следующим чекпоинтом блок считается финализированным.<br><br><strong>Что здесь может быть не так?</strong><br><br>Например централизация: активных билдеров порядка 5-10, совсем недавно 80-85% всех блоков собиралось <u>двумя билдерами</u> — <em>BeaverBuild</em> и <em>Titan Builder</em>. Картина  динамичная, но ситуация все равно печальная. Самую свежую ситуацию можно посмотреть на <a href=\"https://relayscan.io/overview?t=1h\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">relayscan.io</a>.<br><br>А релееров у нас порядка 6-8. Из них четыре игрока контролируют почти все. Ultra Sound, <u>Titan</u>, bloXroute<em> (две версии) </em>и Agnostic Relay. Кто-то из них может опускаться, подниматься, но суть такая же, как и с билдерами.<br><br>Самое интересное, что они сейчас ничего не зарабатывают. Это благотворительность от больших игроков. Они вынуждены быть прослойкой, которой могут доверять и пропоузеры и билдеры, чтобы все работало. <br><br>Более того, у титана и билдер, и релеер, доверяет сам себе или все доверяют титану?😅<br><br>И это интересно понимать, на фоне, когда ругают другие чейны за их централизацию валидаторов. В Ethereum с валидаторами проблем нет — их сотни тысяч, но проблему я обозначил.<br><br><strong>Как транзакция будет жить после Glamsterdam?</strong><br><br>Схема, описанная выше, меняется фундаментально. Билдер теперь не внешний сервис, а сущность внутри <code>BeaconState</code> в реестре <code>builders</code>. А релееры перестают быть обязательной прослойкой между билдером и пропоузером.<br><br>Билдер вносит депозит, минимум — 1 ETH. После этого он становится частью Ethereum. Для него нет очереди входа и выхода, как у валидаторов.<br><br>Стейк билдера не голосует, он работает как залог: из него протокол списывает оплату пропозеру. Отсюда простое правило: билдер не может предложить взятку пропоузеру больше своего баланса.<br>В Glamsterdam у транзакции будет совсем другая жизнь.<br><br>1️⃣ <strong>Пользователь и транзакции</strong><br><br>На этом уровне все по-прежнему: пользователь подписывает транзакцию и отправляет ее в сеть.<br><br>2️⃣ <strong>Proposer</strong><br><br>Заранее известный пропоузер, который назначен королем танцпола, публикует данные о себе для билдеров. Так же, как раньше он делал это для релееров. Газ-лимит на блок и свой адрес для получения комиссии.<br><br>3️⃣ <strong>Builder</strong><br><br>Билдеры собирают блоки из бандлов и доступных транзакций из мемпула, формируют заголовок блока и фиксируют взятку пропозеру. После этого отправляют пропозеру: взятку, <code>block_hash</code> будущего payload и коммитменты блобов. Сами транзакции и блобы остаются у билдера.<br><br>4️⃣ <strong>Proposer публикует блок в beacon chain</strong><br><br>Пропоузер выбирает самую выгодную взятку и кладёт её в свой beacon block. Этот блок максимально легкий, потому что в нем нет транзакций и блобов. В момент обработки этого блока сумма взятки списывается с баланса билдера. Если пропозер хочет строить сам, он ставит <code>BUILDER_INDEX_SELF_BUILD</code> с нулевой суммой.<br><br>5️⃣ <strong>Аттестация</strong><br><br>Валидаторы голосуют за beacon block, проверив только консенсусную часть. Исполнять транзакции на этом шаге не нужно, поэтому это выполняется быстро.<br><br>6️⃣ <strong>Builder раскрывает payload</strong><br><br>Билдер видит, что его блок прошел аттестацию и раскрывает payload вместе с блобами. <br><br>Раскрывать стоит именно после аттестаций: если блок пропозера опоздал или его реорганизовали, билдер может ничего не раскрывать и не платит.<br><br>7️⃣ <strong>PTC голосует (512 валидаторов)</strong><br><br>PTC (Payload Timeliness Committee) — это 512 валидаторов, которые голосуют за раскрытый payload. Причем у них нет задачи его прогонять, они только проверяют своевременность его прихода на проверку и что hash совпадает с тем, что был отправлен на проверку в консенсусе. Также проверяется доступность блобов.<br><br>Если payload принят, списанная сумма с билдера передается пропозеру. Если payload не раскрыт билдером, но beacon block набрал достаточно веса аттестаций, пропозеру всё равно отправят взятку. <br><br>Получается двойная страховка и билдер не платит только если блок не принят вообще.<br><br>Также важно, что дальше процесс финализации не меняется, меняется только процесс постройки и проверки блока внутри слота.<br><br><strong>Вопрос: а кто же проверяет payload?</strong><br><br>После того, как payload раскрывается PTC не проверяет payload, поэтому это делает следующий пропоузер и у него есть на это 6 сек. Также payload проверяют и валидаторы нового слота до момента, пока новые блоки формируются и не наступит время их аттестации. Это 9 сек.<br><br><strong>Вывод</strong><br><br>ePBS решает сразу две задачи, которые на первый взгляд не связаны.<br><br><strong>Первая</strong> — доверие и централизация. Сегодня блоки строятся катастрофически малым количеством внешних билдеров. А честность обмена блоками между билдерами и пропозером гарантирует горстка релеев, которые не имеют экономического стимула от слова совсем.<br><br>После Glamsterdam билдер становится участником протокола со стейком, а честность и прозрачность обеспечивают правила консенсуса и комитет PTC: пропозер получает оплату, даже если билдер подвёл, а своевременно раскрытый payload честного билдера гарантированно попадает в цепочку.<br><br><br><br><strong>Вторая</strong> — масштабирование. Блок делится на консенсусную часть и исполнительную, при этом тяжёлая проверка транзакций переезжает из узкого окна в 4 секунды в окно 6–9 секунд. Именно это, вместе с block-level access lists (EIP-7928), позволяет перейти к более высоким лимитам на газ.<br><br>P.S. Насколько ситуация с билдерами улучшится — мне пока не понятно. Те же самые два билдера продолжат работу по постройке блока, да, теперь им надо стейкать ETH, но у них есть законный механизм по придержанию раскрытия payload. Что может привести к появлению большого количества пустых слотов, что для обывателя выльется в увеличенное время ожидания исполнения его транзакции.<br><br>#павел_найданов<br><br>🤟 <a href=\"https://metalamp.ru/\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Сайт</strong></a> | <a href=\"https://t.me/metalampru\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\">ТГ-канал</a> | <a href=\"https://t.me/+L_tFSdgfNcwxNjEy\" target=\"_blank\" rel=\"noopener noreferrer nofollow ugc\"><strong>Наш чат</strong></a>","language":"ru","class":"approved","duplicate_of":null,"secondary_of":null,"in_aggregator":true,"aggregator_url":"https://t.me/WEB3_AGGREGATOR/425168","deleted":false,"deleted_at":null,"views":383,"forwards":7,"sender_id":null,"cashtags":[],"hashtags":["павел_найданов"],"addresses":[],"domains":["relayscan.io","eips.ethereum.org","ethereum.org","metalamp.ru","t.me"],"media":[{"type":"photo","url":"https://media.web3aggregator.io/files/p0CNrG7exQUo","duration":null,"width":746,"height":1208,"preview":false}],"link_preview":null,"album":null,"topic":"research"}],"next_cursor":null}