Введение: 13 мая 2024 года Виталик предложил EIP-7706, который дополняет существующую модель газа путем отдельного удаления расчета газа для calldata и настройки механизма ценообразования базовой платы, аналогичного газу Blob, дополнительно снижая операционные расходы Layer 2. Связанные предложения также необходимо отнести к EIP-4844, предложенному в феврале 2022 года, что является длительным временем разделения. Поэтому, проверяя связанные материалы, мы надеемся предоставить сводку последнего механизма газа Ethereum, чтобы облегчить быстрое понимание каждого.

В настоящее время поддерживаемые модели газа Ethereum - EIP-1559 и EIP-4844

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

Флуктуация уровней комиссий за транзакции не соответствует консенсусной стоимости транзакций: Для блокчейнов в активном состоянии имеется достаточный спрос на упаковку транзакций, что означает, что блоки могут легко заполняться, но это часто приводит к значительным колебаниям общих сборов. Например, когда средняя цена за газ составляет 10 Гвей, предельные затраты, понесенные сетью при принятии еще одной транзакции в блоке, в десять раз выше, чем при средней цене за газ 1 Гвей, что неприемлемо.

Ненужные задержки для пользователей: из-за жесткого лимита газлимита для каждого блока, совместно с естественной флуктуацией исторических объемов транзакций, транзакции часто должны ждать несколько блоков для упаковки, что неэффективно для всей сети. Нет механизма «релаксации», который позволяет одному блоку быть больше, а следующему блоку быть меньше, чтобы удовлетворить различия в спросе между блоками.

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

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

До предложения и внедрения EIP-1559 существовала первая итерация газовой модели. EIP-1559, предложенный Виталиком и другими основными разработчиками 13 апреля 2019 года, был принят в обновлении в Лондоне 5 августа 2021 года. Этот механизм отказывается от аукционного механизма и вместо этого использует двойную модель ценообразования: базовую комиссию и приоритетную комиссию. Базовая плата рассчитывается количественно на основе соотношения между потреблением газа в родительском блоке и плавающей и рекурсивной целью газа с помощью установленной математической модели. Интуитивно понятный эффект заключается в том, что если потребление газа в предыдущем блоке превышает заданный целевой показатель газа, базовая плата увеличивается, а если она ниже целевого показателя, базовая плата уменьшается. Это может лучше отражать спрос и предложение и сделать прогнозы на разумный газ более точными, предотвращая непомерные цены на газ из-за неправильных операций, поскольку расчет базовой платы определяется непосредственно системой, а не свободно указывается пользователями. Конкретный код выглядит следующим образом:

Можно предположить, что когда parent_gas_used больше, чем parent_gas_target, базовая плата текущего блока будет сравниваться с базовой платой предыдущего блока плюс смещение. Что касается смещения, оно рассчитывается путем умножения parent_base_fee на смещение общего газового использования предыдущего блока относительно целевого газа и взятия модуля относительно целевого газа и постоянной, а затем взятия максимального значения результата и 1. Логика аналогична в обратном порядке.

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

По мере того, как время шло в 2021 году, развитие Rollups постепенно достигло своего пика. Мы знаем, что будь то OP Rollups или ZK Rollups, это подразумевает необходимость загрузки определенных доказательств сжатых данных L2 на цепочку через calldata для достижения доступности данных on-chain или для непосредственной проверки on-chain. Это накладывает значительные газовые издержки на поддержание окончательности L2, которые в конечном итоге переносятся на пользователей. Поэтому стоимость использования большинства протоколов L2 в то время не была такой низкой, как предполагалось.

В то же время Ethereum также столкнулся с дилеммой конкуренции за блочное пространство. Мы знаем, что у каждого блока есть предел газа, что означает, что общее потребление газа всех транзакций в текущем блоке не может превышать это значение. При расчете на основе текущего предела газа в 30 000 000, теоретический предел составляет 1 875 000 байтов, где 16 относится к газу, потребляемому на каждый байт calldata, обработанный EVM. Это означает, что максимальный размер данных, который может быть размещен в одном блоке, приблизительно составляет 1,79 МБ. Однако данные, связанные с Rollup, создаваемые L2-последователями, обычно имеют больший размер данных, что конкурирует с подтверждением транзакций другими пользователями основной цепи, что приводит к уменьшению количества транзакций, которые могут быть упакованы в один блок, тем самым влияя на TPS основной цепи.

Чтобы решить эту дилемму, 5 февраля 2022 года разработчики ядра предложили EIP-4844, который был реализован после обновления Dencun во втором квартале 2024 года. В этом предложении представлен новый тип транзакции под названием Blob Transaction. В отличие от традиционных типов транзакций, основная идея транзакции BLOB-объекта дополняет новый тип данных, а именно данные BLOB-объектов. В отличие от типов calldata, данные больших двоичных объектов не могут быть доступны непосредственно EVM, а могут получить доступ только к их хэшу, также известному как VersionedHash. Кроме того, представлены два сопутствующих дизайна. Во-первых, по сравнению с обычными транзакциями, цикл GC транзакций BLOB-объектов короче, что гарантирует, что данные блоков не станут слишком раздутыми. Во-вторых, данные BLOB-объектов имеют собственный механизм Gas. В целом, представленный эффект аналогичен EIP-1559, но математическая модель выбирает естественную экспоненциальную функцию, которая работает лучше в стабильности при работе с колебаниями объема транзакций. Это связано с тем, что наклон естественной экспоненциальной функции также является естественной экспоненциальной функцией, а это означает, что независимо от состояния объема транзакций в сети, когда объем транзакций быстро увеличивается, базовая плата за газ больших двоичных объектов отражается более полно, эффективно ограничивая транзакционную активность. Кроме того, эта функция имеет важную характеристику, где значение функции равно 1, когда абсцисса равна 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Где MIN_BASE_FEE_PER_BLOB_GAS и BLOB_BASE_FEE_UPDATE_FRACTION - две константы, а excess_blob_gas определяется разницей между общим потреблением газа блоба в родительском блоке и константой TARGET_BLOB_GAS_PER_BLOCK. Когда общее потребление газа блоба превышает целевое значение, т.е. разница положительна, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) больше 1, и base_fee_per_blob_gas увеличивается, в противном случае уменьшается.

Это позволяет осуществлять выполнение по низкой стоимости в сценариях, где требуется только возможность консенсуса Ethereum для хранения данных масштаба больших масштабов для обеспечения доступности, без монополизации емкости упаковки транзакций блока. Возьмем в качестве примера секвенсор Rollup, критическая информация L2 может быть инкапсулирована в блоб-данные через блоб-транзакции, а логика для верификации on-chain может быть реализована в EVM через сложные конструкции с использованием versionedHash.

Следует отметить, что текущая установка TARGET_BLOB_GAS_PER_BLOCK и MAX_BLOB_GAS_PER_BLOCK накладывает ограничение на mainnet, а именно цель обработки в среднем 3 блобов (0,375 МБ) на блок и максимальный предел 6 блобов (0,75 МБ) на блок. Эти начальные пределы направлены на минимизацию давления, которое EIP оказывает на сеть, и ожидается, что они будут увеличены в будущих обновлениях, поскольку сеть продемонстрирует надежность при работе с более крупными блоками.

Усовершенствование модели потребления газа для среды выполнения - EIP-7706

После уточнения текущей модели Gas Ethereum давайте взглянем на цели и детали реализации предложения EIP-7706. Это предложение было представлено Виталиком 13 мая 2024 года. Подобно данным Blob, это предложение отделяет модель Gas для другого специального поля данных, а именно calldata, и оптимизирует соответствующую логику реализации кода.

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

Следует отметить новый дизайн параметра, LIMIT_TARGET_RATIOS=[2,2,4], где LIMIT_TARGET_RATIOS[0] представляет целевое отношение газа для операций выполнения, LIMIT_TARGET_RATIOS[1] представляет целевое отношение газа для данных Blob, а LIMIT_TARGET_RATIOS[2] представляет целевое отношение газа для calldata. Этот вектор используется для вычисления целевых значений газа для трех типов газа в родительском блоке, используя LIMIT_TARGET_RATIOS для целочисленного деления на предельное значение газа следующим образом:

Логика установки для gas_limits следующая:

gas_limits[0] должны следовать существующей формуле корректировки.

gas_limits[1] должен быть равен MAX_BLOB_GAS_PER_BLOCK.

gas_limits[2] должны быть равны gas_limits[0] // CALLDATA_GAS_LIMIT_RATIO.

Мы знаем, что текущий gas_limits[0] составляет 30000000, а CALLDATA_GAS_LIMIT_RATIO установлен на 4. Это означает, что текущая цель по газу calldata примерно равна 30000000 // 4 // 4 = 1875000. Поскольку согласно текущей логике расчета газа calldata каждый ненулевой байт потребляет 16 Gas, а нулевые байты потребляют 4 Gas, предполагая, что распределение ненулевых и нулевых байтов в сегменте calldata составляет 50%, средняя обработка 1 байта calldata требует 10 Gas. Следовательно, текущая цель по газу calldata должна соответствовать данным calldata объемом 187500 байтов, примерно вдвое больше текущего среднего использования.

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

Отказ от ответственности:

1. Этот статья перепечатана из [TechFlow]. Все авторские права принадлежат оригинальному автору [Web3Mario]. Если есть возражения против этого переиздания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
2. Ответственность за отказ: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. За исключением упоминания, копирование, распространение или плагиат переведенных статей запрещены.