Автор оригинала: @Web3 Mario

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

Поддерживаемые в настоящее время модели Ethereum Gas - EIP-1559 и EIP-4844

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

• Колебания уровня Комиссии за транзакцию и консенсусной стоимости транзакций: В активном блокчейне существует достаточный спрос на упаковку транзакций, что означает, что блоки могут быть легко заполнены, но это часто также означает, что общие колебания комиссии чрезвычайно высоки. Например, когда средняя цена на газ составляет 10 Gwei, предельные затраты сети на принятие еще одной транзакции в блоке в 10 раз превышают среднюю цену на газ в 1 Gwei, что неприемлемо.
• Ненужная задержка для пользователей: из-за жесткого лимита газа каждого блока в сочетании с естественным колебанием исторического объема транзакции обычно ожидают упаковки нескольких блоков, но это неэффективно для всей сети; То есть, не существует механизма «провисания», который позволяет одному блоку быть больше, а следующему блоку меньше, чтобы удовлетворить различия в потребностях, которые являются блоком в каждом конкретном случае.
• Неэффективное ценообразование: Использование простого механизма аукциона приводит к неэффективному обнаружению справедливой цены, что означает, что пользователям будет трудно дать разумную цену, а это означает, что в очень лонг случаях пользователи платят высокие комиссии. • Свободные от Награда за блок Блокчейн будут нестабильными: Когда Награда за блок, приносимые Майнинг, удаляются и принимается модель чистой комиссии, это может привести к очень лонг нестабильности, такой как стимулирование майнинга к краже Комиссия за транзакцию «сестринских блоков», открытие более мощных эгоистичный майнинг Вектор атаки и т. д.

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

Видно, что когда parent\Газ_used больше, чем parent_Газ_target, то базовая плата текущего Блок будет сравниваться с базовой комиссией предыдущего Блок плюс значение смещения, а значение смещения принимается как parent_base_fee умножается на смещение общего использования предыдущего Блок Газ относительно Газ цели, а максимальное значение остатка от 1 с Газ целью и константой. Обратная логика аналогична.

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

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

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

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

base_fee_per_blob_Газ = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_Газ / BLOB_BASE_FEE_UPDATE_FRACTION)

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

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

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

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

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

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

Стоит отметить новую структуру параметров, LIMIT_TARGET_RATIOS=[ 2, 2, 4 ], где LIMIT_TARGET_RATIOS[ 0 ] представляет целевой коэффициент класса операций Gas, LIMIT_TARGET_RATIOS[ 1 ] представляет целевое соотношение класса данных Blob Gas, а LIMIT_TARGET_RATIOS [ 2 ] представляет данные вызова Целевой коэффициент класса Gas, этот вектор используется для вычисления Газ целевых значений, соответствующих трем классам Газ в родительском Блок, а логика расчета следующая, то есть Лимит газа делится на LIMIT_TARGET_RATIOS соответственно:

Логика Газ_limits следующая:

Газ_limits[ 0 ] должен соответствовать существующей формуле корректировки

Газ_limits[ 1 ] должно быть равно MAX_BLOB_GAS_PER_BLOCK

Газ_limits[ 2 ] должно быть равно Газ_limits[ 0 ] // CALLDATA_GAS_LIMIT_RATIO

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

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