Знакомство

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

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

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

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

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

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

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

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

Расчет базовой платы и последствия: Если потребление газа в предыдущем блоке превышает целевой уровень газа, базовая плата увеличивается; если он не достигает целевого показателя по газу, базовая плата уменьшается. Эта корректировка хорошо отражает динамику спроса и предложения и повышает точность обоснованных прогнозов на газ, позволяя избежать непомерных цен на газ из-за неправильной эксплуатации, поскольку расчет базовой платы определяется системой, а не пользователем. Конкретный код для расчета выглядит следующим образом:

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

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

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

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

Для решения этой проблемы 5 февраля 2022 года разработчики ядра предложили EIP-4844, который был реализован после обновления Dencun в начале 2 квартала 2024 года. В этом предложении появился новый тип транзакции под названием Blob Transaction. В отличие от традиционных транзакций, транзакция BLOB-объекта включает в себя новый тип данных, данные BLOB-объектов, к которым, в отличие от calldata, EVM не может получить прямой доступ, а только через его хэш, также известный как VersionedHash. Кроме того, транзакции BLOB-объектов имеют более короткий цикл GC по сравнению с обычными транзакциями, что предотвращает чрезмерное раздувание данных блока. Данные BLOB-объектов также имеют встроенный газовый механизм, аналогичный 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 определяется разницей между общим потреблением газа blob в родительском блоке и постоянной TARGET_BLOB_GAS_PER_BLOCK. Когда общее потребление газа blob превышает целевое значение, что делает разницу положительной, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) больше 1, что приводит к увеличению base_fee_per_blob_gas, и наоборот.

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

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

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

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

Основные понятия

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

Примечательным аспектом этого предложения является введение нового дизайна параметров LIMIT_TARGET_RATIOS = [2, 2, 4]. Вот разбивка:

LIMIT_TARGET_RATIOS[0]: Целевой коэффициент для газа операции выполнения.

LIMIT_TARGET_RATIOS[1]: Целевое соотношение для газа данных BLOB-объектов.

LIMIT_TARGET_RATIOS[2]: Целевое соотношение для газа calldata.

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

Лимиты газа устанавливаются следующим образом:

• gas_limits[0] следует существующей формуле корректировки.

• gas_limits[1]MAX_BLOB_GAS_PER_BLOCKравно .

• gas_limits[2]gas_limits[0] / CALLDATA_GAS_LIMIT_RATIOравно .

Учитывая, что ток gas_limits[0] составляет 30 000 000, а CALLDATA_GAS_LIMIT_RATIO предустановлено значение 4, это означает, что текущая calldata цель по газу приблизительно:

[ \frac{30 000 000}{4 \times 4} = 1 875 000 ]

Согласно текущей calldata логике расчета газа:

• Каждый ненулевой байт потребляет 16 газов.

• Каждый нулевой байт потребляет 4 газа.

Предполагая равномерное распределение ненулевых и нулевых байтов в сегменте calldata, среднее потребление газа на байт составляет 10 Gas. Таким образом, текущий calldata целевой показатель газа соответствует примерно 187 500 байтам calldata, что примерно в два раза превышает текущее среднее потребление.

Преимущества предложения

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

В заключение, EIP-7706 не только уточняет модель calldata Gas, но и стратегически позиционирует Ethereum для эффективного масштабирования решений уровня 2 за счет контроля и оптимизации потребления газа, связанного с данными.

Отказ:

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