В новой работе Виталика: Что такое многомерное ценообразование газа?

Автор: Виталик Бутерин

Перевод: Карен, Foresight News

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

1. Сырые вычисления (например, ADD, MULTIPLY);

2. Чтение и запись в хранилище Ethereum (например, SSTORE, SLOAD, ETH-переводы);

3. Пропускная способность данных;

4. Стоимость генерации доказательств ZK-SNARK для блоков.

Например, транзакция, которую я отправил, потребила в общей сложности 47 085 Газа. В это число входит: (i) базовая стоимость 21 000 Газа, (ii) байты calldata, включенные в транзакцию, потребляющие 1556 Газа, (iii) чтение/запись в хранилище потребляющее 16 500 Газа, (iv) логирование потребляющее 2149 Газа, остальное используется для выполнения EVM. Комиссия за транзакцию, которую пользователи должны заплатить, прямо пропорциональна Газу, потребляемому транзакцией. Блок может содержать максимум 30 миллионов Газа, и цена Газа непрерывно корректируется через механизм целевого средства EIP-1559, чтобы обеспечить среднее значение 15 миллионов Газа на блок.

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

Однако этот подход также имеет неэффективности: он рассматривает различные ресурсы как взаимозаменяемые, когда фактические базовые ограничения различны. Чтобы понять эту проблему, можно сначала взглянуть на следующую диаграмму:

Лимиты Газа накладывают ограничение:

Фактические базовые ограничения безопасности обычно ближе к:

Это различие приводит к тому, что лимиты Газа либо несправедливо исключают блоки, которые фактически безопасны, либо принимают блоки, которые фактически небезопасны, или и то, и другое.

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

Блоб: Многомерный Газ в Dencun

В начале этого года средний размер блока составлял 150 кБ. Большая часть этого - данные Rollup: протоколы Layer2 хранят данные on-chain. Эти данные очень дорогие: хотя стоимость транзакций на Rollup всего лишь в 5-10 раз выше, чем соответствующие транзакции на Ethereum L1, эта стоимость все равно слишком высока для многих случаев использования.

Почему бы тогда не снизить стоимость calldata (в настоящее время 16 Газа за ненулевые байты, 4 Газа за нулевые байты), чтобы сделать Rollup дешевле? Мы делали это раньше, и можем сделать снова сейчас. Но ответ здесь таков: максимальный размер блока составляет 30 000 000/16=1 875 000 ненулевых байтов, и сеть едва или почти не может обрабатывать блоки такого размера. Снижение стоимости в 4 раза увеличило бы максимум до 7,5 МБ, что представляло бы огромный риск для безопасности.

Эта проблема в конечном итоге решается путем введения отдельного, дружественного к Rollup пространства данных (называемого блоб) в каждом блоке.

Эти два ресурса имеют разные цены и лимиты: после хардфорка Dencun в Ethereum блок может содержать (i) 30 миллионов Газа и (ii) 6 блобов, каждый из которых способен содержатьОколо 125 кБ каллдата. Эти два ресурса имеют разные цены и регулируются посредством механизма ценообразования, аналогичного EIP-1559, с целью среднего значения 15 миллионов газа и 3 блобов в блоке. В результате стоимость Rollup была снижена в 100 раз, объем транзакций на Rollup увеличился более чем в 3 раза, а теоретический максимальный размер блока слегка увеличился: с примерно 1,9 МБ до примерно 2,6 МБ. Примечание: комиссии за транзакции Rollup предоставлены Growthepie.xyz. Форк Dencun произошел 13 марта 2024 года, вводя многомерное ценообразование для блобов. Многомерный газ и безсостояний клиенты В ближайшем будущем доказательства хранения для безсостояний клиентов также столкнутся с аналогичными проблемами. Безсостояний клиенты - это новый тип клиентов, которые смогут проверять цепочку без необходимости хранить большое количество или какие-либо данные локально. Безсостояний клиенты достигают этого, принимая доказательства конкретных частей состояния Ethereum, к которым транзакции в этом блоке должны обратиться. Диаграмма показывает безсостояний клиент, получающий блок и доказательство текущих значений частей состояния, касающихся выполнения блока (например, балансы счетов, код, хранилище), что позволяет узлам проверять блок без какого-либо хранения. Чтение из хранилища стоит 2100-2600 газа, в зависимости от типа чтения, при этом запись в хранилище обходится дороже. В среднем блок будет выполнять около 1000 операций чтения/записи в хранилище (включая проверки баланса ETH, вызовы SSTORE и SLOAD, чтение кода контракта и другие операции). Однако теоретический максимум составляет 30 000 000/2 100 = 14 285 чтений. Нагрузка на пропускную способность безсостояний клиентов пропорциональна этому числу. Текущий план заключается в поддержке безсостояний клиентов путем перехода от дизайна деревьев Меркля Патриции к деревьям Веркле. Однако деревья Веркле не обладают постквантовой безопасностью и не являются оптимальным выбором для новых систем доказательств STARK. Поэтому многие заинтересованы в поддержке безсостояний клиентов через двоичные деревья Меркля и STARK, либо полностью пропуская Веркле, либо переходя к STARK после нескольких лет перехода к Веркле, когда STARK станут более зрелыми. Доказательства STARK на основе ветвей двоичного хэш-дерева имеют множество преимуществ, но их основной недостаток заключается в длительном времени, необходимом для генерации доказательств: деревья Веркле могут доказывать более 100 000 значений в секунду, в то время как хэш-основанные STARK обычно доказывают лишь несколько тысяч хэшей в секунду, и для доказательства каждого значения требуется много хэш-ветвей. Учитывая сегодняшние прогнозы от высокооптимизированных систем доказательств, таких как Binius и Plonky3, а также специализированных хэшей, таких как Vision-Mark-32, кажется, что доказательство 1000 значений в секунду выполнимо в течение некоторого времени, но доказательство 14 285 значений - нет. Средний блок будет в порядке, но потенциальные блоки худшего случая (выпущенные злоумышленниками) нарушили бы сеть. Нашим стандартным подходом к решению таких ситуаций является повторное ценообразование: увеличение стоимости чтения из хранилища для снижения максимального значения на блок до более безопасного уровня. Однако мы уже много раз это делали, и если сделать это снова, это сделает слишком дорогими слишком много приложений. Более эффективным подходом является многомерный газ: ограничение и оплата доступа к хранилищу отдельно, поддерживая среднее использование на уровне 1000 доступов к хранилищу на блок, но устанавливая верхний предел на блок, например, 2000 доступов. Универсальность многомерного газа Еще один ресурс, который стоит рассмотреть, - это рост размера состояния: операции, которые увеличивают размер состояния Ethereum, что впоследствии требует от полных узлов его хранения. Уникальность роста размера состояния заключается в том, что его ограничение полностью происходит от долгосрочного устойчивого использования, а не от пикового использования. Поэтому добавление отдельного измерения газа для операций, увеличивающих размер состояния (например, SSTORE от нуля к ненулевому, создание контракта), может быть ценным, но с другой целью: мы можем установить плава

Установка цены газа, ориентированная на конкретное среднее использование, без установки каких-либо ограничений на блок.

Это демонстрирует мощное свойство многомерного газа: это позволяет нам отдельно узнать для каждого ресурса: (i) каково идеальное среднее использование? (ii) каково безопасное максимальное использование на блок? В отличие от установки цен на газ на основе максимального значения на блок и последующего следования за средним использованием, у нас есть 2n степеней свободы для установки 2n параметров, корректируя каждый параметр на основе соображений безопасности сети.

В более сложных сценариях, например, когда соображения безопасности для двух ресурсов частично перекрываются, это можно решить, сделав опкод или ресурс потребляющим определенное количество газа различных типов (например, потребляя несколько типов газа для операции от нуля к ненулевому).

ERO SSTORE может потреблять 5000 газа для доказательства бесхозного клиента и 20000 газа для расширения хранилища).

Максимально на транзакцию (выбирая тот, который потребляет больше данных или вычислений)

Пусть 𝑥1 будет стоимостью газа данных, 𝑥2 - стоимостью газа вычислений, таким образом, в одномерной системе газа мы можем записать стоимость газа транзакции:

В этой схеме мы определяем стоимость газа транзакции как:

То есть транзакции оплачиваются не на основе данных плюс вычислений, а на основе того, из двух ресурсов, которого она потребляет больше. Это легко можно расширить, чтобы охватить больше измерений (например, 𝑚𝑎𝑥(...,𝑥3∗𝑠𝑡𝑜𝑟𝑎𝑔𝑒_𝑎𝑐𝑐𝑒𝑠𝑠)).

Должно быть легко увидеть, как это увеличивает пропускную способность, обеспечивая при этом безопасность. Теоретически максимальный объем данных в блоке все еще составляет GasLIMIT/𝑥1, что также справедливо для одномерной схемы газа. Аналогично, теоретический максимальный объем вычислений составляет GasLIMIT/𝑥2, также справедливо для одномерной схемы газа. Однако стоимость газа любой транзакции, потребляющей данные и вычисления, будет уменьшена.

Вероятно, это подход, принятый в предложенном EIP-7623 для уменьшения максимального размера блока при дальнейшем увеличении числа блобов. Точный механизм в EIP-7623 немного сложнее: он сохраняет текущую цену calldata на уровне 16 газа за байт, но добавляет минимальную цену в 48 газа за байт; транзакции оплачивают большее из (16 * байтов + execution_Gas) и (48 * байтов). Таким образом, EIP-7623 уменьшает теоретический максимальный объем транзакционных данных в блоке с примерно 1,9 МБ до примерно 0,6 МБ, сохраняя при этом стоимость для большинства приложений неизменной. Преимущество этого подхода заключается в том, что он меняет очень мало по сравнению с текущей одномерной схемой газа, что делает его очень легким в реализации.

Однако у этого подхода есть два недостатка:

1. Даже если все остальные транзакции в блоке используют очень мало этого ресурса, транзакции, которые сильно потребляют один ресурс, все равно будут необоснованно платить высокие комиссии;

2. Он стимулирует объединение данных-интенсивных и вычислительно-интенсивных транзакций вместе для экономии затрат.

Я считаю, что правила, подобные EIP-7623, будут приносить значительные выгоды, даже с этими недостатками.

Однако, если мы готовы вложить (значительно больше) усилий в разработку, появится более идеальный подход.

Многомерный EIP-1559: более сложная, но идеальная стратегия

Давайте сначала рассмотрим, как работает обычный EIP-1559. Мы сосредоточимся на версии, представленной в EIP-4844, ориентированной на блобы, так как она более математически элегантна.

Мы отслеживаем параметр excess_blobs. В течение каждого периода блока мы устанавливаем:

excess_blobs <-- max(excess_blobs + len(block.blobs) - TARGET, 0)

где TARGET = 3. Это означает, что если в блоке больше блобов, чем цель, excess_blobs увеличивается, а если в блоке меньше блобов, чем цель, excess_blobs уменьшается. Затем мы устанавливаем blob_basefee = exp(excess_blobs / 25.47), где exp - приблизительное значение экспоненты

Функция 𝑒𝑥𝑝(𝑥)=2.71828^𝑥.

Это означает, что когда excess_blobs увеличивается примерно на 25, базовая плата за blobs увеличивается примерно в 2.7 раза. Если blobs становятся слишком дорогими, среднее использование уменьшается, и excess_blobs начинает уменьшаться, автоматически снижая цену снова. Цена на blobs непрерывно корректируется, чтобы в среднем блоки были заполнены наполовину, что означает, что в каждом блоке в среднем содержится 3 blobs.

Если происходит кратковременный пик использования, существует ограничение: каждый блок может содержать максимум 6 blobs, в этом случае транзакции могут конкурировать, увеличивая приоритетную плату. Однако в обычных обстоятельствах каждому blob'у нужно всего лишь заплатить базовую плату за blob плюс небольшую дополнительную приоритетную плату, чтобы быть включенным в качестве стимула.

Такая ценовая политика Gas существует в Ethereum уже много лет: уже в 2020 году EIP-1559 ввела очень похожий механизм. Через EIP-4844 мы устанавливаем две независимые плавающие цены для Gas и Blobs.

Примечание: Базовые платы Gas в гвей в течение одного часа 8 мая 2024 года. Источник: ultrasound.money

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

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

Для строителей блоков оптимальная стратегия большую часть времени такая же, как и сегодня: включать любое допустимое содержимое. Большинство блоков не заполнены полностью — как в Gas, так и в Blobs. Сложная ситуация возникает, когда достаточно Gas или достаточно Blobs, чтобы превысить предел блока, и строителям потенциально нужно решить задачу многомерного задачи о рюкзаке, чтобы максимизировать свою прибыль. Однако даже с достаточно хорошими приближенными алгоритмами выгоды от оптимизации прибыли через собственные алгоритмы в этом сценарии намного меньше, чем от использования MEV для тех же операций.

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

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

Однако разработчики все равно могут достичь довольно хороших результатов, оптимизируясь на основе долгосрочных средних исторических цен.

Многомерная ценообразование, EVM и подвызовы

Одной из проблем, которая не возникает в blobs и не возникнет в полной многомерной реализации ценообразования, нацеленной на calldata, как EIP-7623 или даже для отдельного ценообразования доступа к состоянию или любому другому ресурсу, являются лимиты Gas в подвызовах.

Лимиты Gas в EVM существуют на двух уровнях. Во-первых, каждая транзакция устанавливает лимит Gas, ограничивая общее количество Gas, которое может быть использовано в этой транзакции. Во-вторых, когда контракт вызывает другой контракт, этот вызов может установить свой собственный лимит Gas. Это позволяет контрактам вызывать другие контракты, которым они не доверяют, и все равно гарантировать, что у них остается Gas для выполнения других вычислений после вызова.

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

Проблема заключается в том, что достижение многомерного Gas между различными вызовами

Различные типы выполнения, кажется, требуют подвызовов для установки нескольких лимитов для каждого типа Gas, что потребует очень глубоких изменений в EVM и будет несовместимо с существующими приложениями. Это одна из причин, почему многомерные предложения по Gas обычно ограничиваются двумя измерениями: данные и выполнение. Данные (будь то данные вызова транзакции или блоб) выделяются внешне для EVM, поэтому внутренние изменения в EVM для ценообразования данных вызова транзакции или блоба не требуются. Мы можем предложить "решение в стиле EIP-7623" для решения этой проблемы. Это простая реализация: взимать плату в 4 раза больше за операции хранения во время выполнения; для упрощения анализа. Предположим, что каждая операция хранения стоит 10 000 газов. По окончании транзакции возвращается сумма min(7500 * операции_хранения, Gas_выполнения). Следовательно, после вычета возврата пользователю нужно заплатить следующие сборы: Gas_выполнения + 10 000 * операции_хранения - min(7500 * операции_хранения, Gas_выполнения) Это равно: max(Gas_выполнения + 2 500 * операции_хранения, 10 000 * операции_хранения) Это отражает структуру EIP-7623. Другой подход - отслеживать операции_хранения и Gas_выполнения в реальном времени и взимать плату в размере 2 500 или 10 000 в зависимости от того, насколько увеличивается max(Gas_выполнения + 2 500 * операции_хранения, 10 000 * операции_хранения) в момент вызова опкода. Это позволяет избежать избыточного выделения газа для транзакций, которое в основном компенсируется через возвраты. У нас нет детализированного разрешения для подвызовов: подвызовы могут потреблять всю выделенную транзакции квоту на дешевые операции хранения. Однако у нас есть нечто довольно хорошее, а именно то, что контракт, совершающий подвызов, может установить лимит и гарантировать, что по завершении подвызова у основного вызова все еще будет достаточно газа для необходимой постобработки. Самое простое "полное многомерное решение ценообразования", которое я могу предложить, - это: мы рассматриваем лимит газа для подвызовов как пропорциональный. То есть, предполагая, что существует 𝑘 различных типов выполнения, и каждая транзакция устанавливает многомерные лимиты 𝐿1...𝐿𝑘. Предполагая, что на текущем этапе выполнения остается газ 𝑔1...𝑔𝑘. При вызове опкода CALL и использовании лимита газа для подвызова 𝑆, пусть 𝑠1=𝑆, тогда 𝑠2=𝑠1/𝑔1*𝑔2, 𝑠3=𝑠1/𝑔1*𝑔3 и так далее. Другими словами, мы рассматриваем газ для первого типа (фактически выполнение VM) как особый "счетный блок", а затем выделяем газ для других типов так, чтобы подвызовы получали тот же процент доступного газа в каждом типе. Этот метод может показаться немного некрасивым, но максимизирует обратную совместимость. Если мы хотим сделать это решение более "нейтральным" между различными типами газа, не жертвуя обратной совместимостью, мы можем просто представить параметр лимита газа для подвызовов как часть оставшегося газа в текущем контексте (например, [1...63]/64). Тем не менее, в любом случае стоит подчеркнуть, что с внедрением многомерного выполнения газа встроенная сложность увеличится, что, кажется, трудно избежать. Поэтому наша задача - найти сложный компромисс: готовы ли мы принять увеличение уровня сложности (некрасивость) на уровне EVM, чтобы безопасно разблокировать значительные преимущества масштабируемости L1, и если да, какое конкретное предложение наиболее эффективно для экономики протокола и разработчиков приложений? Очень вероятно, что ни один из двух вышеупомянутых подходов не является лучшим, но есть еще место для предложения более элегантных и лучших решений. Отдельное спасибо Ansgar Dietrichs, Barnabe Monnot и Davide Crapis за их обратную связь и рецензии.