В Ethereum ресурсы до недавнего времени были ограничены и ценообразованы с использованием единственного ресурса, называемого "газом". Газ - это мера количества "вычислительных усилий", необходимых для обработки заданной транзакции или блока. Газ объединяет в себе несколько типов "усилий", прежде всего:
- Сырые вычисления (например, ADD, MULTIPLY)- Чтение и запись в хранилище Ethereum (например, SSTORE, SLOAD, ETH-переводы)- Пропускная способность данных- Стоимость генерацииZK-SNARK доказательствоблокНапример, эта транзакциячто я отправил, стоит в общей сложности 47 085 газа. Это разделено между (i) «базовая стоимость» в размере 21000 газа, (ii) 1556 газа за байты в вызываемых данных, включенных в транзакцию (iii) 16500 газа для чтения и записи в хранилище, (iv) газ 2149 за созданиежурнал, и остальное для выполнения EVM. Комиссия за транзакцию, которую пользователь должен заплатить, пропорциональна газу, который потребляет транзакция. Блок может содержать максимум 30 миллионов газа, и цены на газ постоянно корректируются через @vbuterin/eip-1559-faq">Механизм целевой настройки EIP-1559, обеспечивающий, что в среднем блоки содержат 15 миллионов Газ.
Этот подход имеет одно основное преимущество: поскольку все сливается в один виртуальный ресурс, это приводит к очень простому дизайну рынка. Оптимизация транзакции для минимизации издержек проста, оптимизация блока для сбора максимальных возможных сборов относительно легкая (не включаяMEV) и нет никаких странных стимулов, которые могли бы поощрять объединение некоторых транзакций с другими для экономии на комиссиях.
Но этот подход также имеет одну основную неэффективность: он рассматривает различные ресурсы как взаимозаменяемые, когда фактические ограничения того, что сеть может обработать, не соблюдаются. Один из способов понять эту проблему - посмотреть на эту диаграмму:
Лимит газа налагает ограничение
𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗компутация- Транзакции, которые сильно зависят от одного ресурса, все еще необоснованно облагаются большим количеством, даже если все остальные транзакции в блоке используют мало этого ресурса.- Он создает стимулы для слияния данных и транзакций с вычислениями в один пакет для экономии затрат.Я бы возражал, что правило в стиле EIP-7623, как для данных транзакции, так и для других ресурсов, может принести достаточно большие преимущества, чтобы оправдать это даже несмотря на эти недостатки. Однако, если и когда мы готовы приложить (значительно большие) усилия по разработке, есть более идеальный подход.
Многомерный EIP-1559: более сложная, но идеальная стратегияДавайте сначала кратко рассмотрим, как работает «обычный» EIP-1559. Мы сосредоточимся на версии, которая была представлена в EIP-4844 для блобов, потому что она математически более элегантна.
Мы отслеживаем параметр, excess_blobs. Во время каждого блока мы устанавливаем:
избыточные_блобы EIP-1559 вернулся в 2020 году. С EIP-4844 у нас теперь есть две отдельно фиксированные цены на газ и на блобы.
Базовая плата за газ за один час 2024-05-08 года, в гвей. Источник: ultrasound.money.
В принципе, мы могли бы добавить еще несколько отдельных плавающих сборов за чтение хранилища и другие виды операций, хотя с одним замечанием, о котором я подробнее расскажу в следующем разделе.
Для пользователей этот опыт удивительно похож на сегодняшний: вместо того, чтобы платить одну базовую комиссию, вы платите две базовые, но ваш кошелек может абстрагироваться от вас и просто показать вам ожидаемую комиссию и максимальную комиссию, которую вы можете ожидать заплатить.
Для строителей блоков, в большинстве случаев оптимальная стратегия такая же, как и сегодня: включить всё, что действительно. Большинство блоков не полные - ни в газенив каплях. Одним из сложных случаев является ситуация, когда достаточно газа или достаточно блобов, чтобы превысить лимит блока, и строителю потенциально придется решить Многомерная ранцевая задачадля максимизации своей прибыли. Однако даже там существуют довольно хорошие приближенные алгоритмы, и выгоды от создания собственных алгоритмов для оптимизации прибыли в этом случае намного меньше, чем выгоды от того же самого сделать с MEV.
Для разработчиков основной вызов заключается в необходимости переработки функций EVM и окружающей инфраструктуры, которые сегодня разработаны вокруг одной цены и одного лимита, в дизайн, который учитывает несколько цен и несколько лимитов. Одной из проблем для разработчиков приложений является то, что оптимизация становится немного сложнее: в некоторых случаях нельзя однозначно сказать, что A эффективнее B, потому что если A использует больше calldata, а B использует больше выполнения, то A может быть дешевле, когда calldata дешев, и дороже, когда calldata дорог. Однако разработчики всё равно смогут получить разумно хорошие результаты, оптимизируясь на основе длительного исторического среднего уровня цен.
Многомерное ценообразование, EVM и подвызовыЕсть одна проблема, которая не возникала с блобами и не возникнет с EIP-7623 или даже с «полной» многомерной реализацией ценообразования для calldata, но возникнет, если мы попытаемся отдельно ценообразовать доступ к состоянию или любой другой ресурс: газовые лимиты при подвызовах.
Лимиты газа в EVM существуют в двух местах. Во-первых, каждая транзакция устанавливает лимит газа, который ограничивает общее количество газа, которое может быть использовано в этой транзакции. Во-вторых, при вызове контракта другим контрактом вызывающий контракт может установить свой собственный лимит газа. Это позволяет контрактам вызывать другие контракты, которым они не доверяют, и все равно гарантировать, что после этого вызова у них останется газ для выполнения других вычислений.
След абстрактной транзакции учетной записи, где учетная запись вызывает другую учетную запись и передает вызываемому ограниченное количество газа, чтобы гарантировать, что внешний вызов может продолжаться даже если вызываемая сторона потребляет весь выделенный ей газ.
Изгиб заключается в том, что сделать газ многомерным между различными типами исполнения кажется так, будто это потребует подвызовов для установки множественных лимитов для каждого типа газа, что потребует действительно глубоких изменений в EVM и не будет совместимо с существующими приложениями.
Вот почему многомерные предложения по газу часто ограничиваются двумя измерениями: данными и выполнением. Данные (будь то данные вызова транзакции или блобы) назначаются только за пределами EVM, поэтому ничего внутри EVM не нужно изменять, чтобы установить отдельные цены на вызовы транзакций или блобы.
Мы можем подумать о решении в стиле "EIP-7623" для этой проблемы. Вот одна простая реализация: во время выполнения увеличьте стоимость операций с хранилищем в 4 раза; для упрощения анализа давайте скажем, что 10000 газа за операцию с хранилищем. По окончании транзакции вернуть min(7500 * операции_с_хранилищем, газ_выполнения). Результатом будет то, что после вычета возврата пользователю будет начислено:
execution_Газ + 10000 storage_operations - min(7500операции хранения, выполнение Газ)
Который равен:
max(execution_gas + 2500операции хранения, 10000storage_operations)
Это отражает структуру EIP-7623. Другой способ сделать это - отслеживать storage_operations и execution_gas в реальном времени и взимать плату в размере 2500 или 10000 в зависимости от того, сколько max(execution_gas + 2500Операции хранения, 10000Потребление газа (storage_operations) увеличивается в тот момент, когда вызывается опкод. Это позволяет избежать необходимости перераспределения газа в транзакциях, поскольку большая часть его будет возвращена через возвратные средства.
У нас нет тонкой настройки разрешений для подвызовов: подвызов может потреблять всю "квоту" транзакции для дешевых операций хранения. Но у нас есть достаточно хорошее решение, где контракт, делающий подвызов, может установить ограничение и гарантировать, что после завершения подвызова у основного вызова все еще будет достаточно газа для выполнения всех пост-обработок, которые ему нужны.
Самое простое «полное многомерное решение ценообразования», о котором я могу подумать, - это то, что мы рассматриваем пределы газа для подвызовов как пропорциональные. То есть, предположим, что есть
𝑘
различные типы исполнения, и каждая транзакция устанавливает многомерный предел
𝐿1…𝐿𝑘
Предположим, что на текущем этапе выполнения остался газ
𝑔1…𝑔𝑘
Предположим, что вызывается операция CALL, с лимитом газа для подвызова
𝑆
. Пусть
𝑠1=𝑆
, и затем
𝑠2=𝑠1𝑔1∗Газ2
,
𝑠3=𝑠1𝑔1∗𝑔3
, и так далее.
То есть мы рассматриваем первый тип газа (реалистично, выполнение VM) как своего рода привилегированный "единицу учета", а затем назначаем другие типы газа так, чтобы подвызов получал тот же процент доступного газа по каждому типу. Это несколько некрасиво, но это максимизирует обратную совместимость. Если мы хотим сделать схему более "нейтральной" между различными типами газа, за счет жертвы обратной совместимости, мы могли бы просто иметь параметр ограничения газа подвызова, представляющий собой дробь (например, [1...63] / 64) оставшегося газа в текущем контексте).
В любом случае, однако, стоит подчеркнуть, что как только вы начинаете вводить многомерный выполнение газа, врожденный уровень уродства увеличивается, и это кажется трудным избежать. Следовательно, наша задача состоит в том, чтобы сделать сложный компромисс: мы принимаем ли немного больше уродства на уровне EVM, чтобы безопасно разблокировать значительные приросты масштабируемости L1, и если да, то какое конкретное предложение лучше всего подходит для экономики протокола и разработчиков приложений? Довольно вероятно, что ни одно из упомянутых мной выше предложений не является лучшим вариантом, и всё ещё есть возможность придумать что-то более элегантное и лучшее.
Отказ от ответственности:- Эта статья перепечатана из [[Виталик Бутерин]], Все авторские права принадлежат оригинальному автору [Виталик Бутерин]. Если есть возражения к этому повторному изданию, пожалуйста, свяжитесь с [Gate Learn](https://www.Gate.com/questionnaire/3967команда, и они решат это незамедлительно.- Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.- Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.
