Виталик: новая быстрая статья о многомерном ценообразовании газа
Виталик говорит о многомерной цене газа в Ethereum, как следует балансировать и выбирать?
Автор: Виталик Бутерин
Перевод: Карен, Foresight News
В Ethereum ресурсы до недавнего времени были ограничены и ценообразование осуществлялось с использованием единицы измерения под названием "Газ". Газ - это единица измерения "вычислительных усилий", необходимых для обработки конкретных транзакций или блоков. Газ объединяет различные типы "вычислительных усилий", причем наиболее важные из них:
1. Сырые вычисления (например, СЛОЖЕНИЕ, УМНОЖЕНИЕ);
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 чтений. Нагрузка на пропускную способность бесхозяйственных клиентов пропорциональна этому числу.
Текущий план заключается в поддержке бесхозяйственных клиентов путем перехода от деревьев Меркла Патриции к деревьям Веркле в конструкции состояния Ethereum. Однако деревья Веркле не обладают постквантовой безопасностью и не являются оптимальным выбором для новых систем доказательств STARK. Поэтому многие заинтересованы в поддержке бесхозяйственных клиентов через бинарные деревья Меркла и STARK, либо полностью пропуская Веркле, либо переходя к нему после нескольких лет переходного периода, когда системы STARK станут более зрелыми.
Доказательства STARK на основе бинарных ветвей хэш-деревьев имеют множество преимуществ, но их основной недостаток заключается в длительном времени, необходимом для генерации доказательств: деревья Веркле могут доказывать более 100 000 значений в секунду, в то время как хэш-основанные STARK обычно доказывают только несколько тысяч хэшей в секунду, и для доказательства каждого значения требуется включение множества хэш-ветвей.
Учитывая сегодняшние прогнозы от высокооптимизированных систем доказательств, таких как Binius и Plonky3, а также специализированных хэшей, таких как Vision-Mark-32, кажется, что доказательство 1000 значений в секунду выполнимо в течение некоторого времени, но доказательство 14 285 значений - нет. Средние блоки будут в порядке, но потенциальные крайние случаи блоков (выпущенные злоумышленниками) нарушили бы сеть.
Стандартный подход, который мы принимаем для решения таких ситуаций, - переоценка: увеличение стоимости чтения из хранилища для снижения максимального значения на блок до безопасного уровня. Однако мы уже делали это много раз, и повторное увеличение сделало бы слишком дорогими слишком много приложений. Более эффективный подход - многомерный газ: ограничение и оплата доступа к хранилищу отдельно для поддержания среднего использования на уровне 1000 доступов к хранилищу на блок, но установка верхнего предела на блок, например, 2000 доступов.
Универсальность многомерного газа
Еще один ресурс, который стоит рассмотреть, - это рост размера состояния: операции, которые увеличивают размер состояния Ethereum, что впоследствии требует от полных узлов его хранения. Уникальность роста размера состояния заключается в том, что причины его ограничения приходят вместе с ростом
Изменение цены газа в зависимости от длительного устойчивого использования, а не от пиковых значений.Поэтому добавление отдельного измерения Gas для увеличения операций размера состояния (например, от нуля к ненулевому SSTORE, создание контракта) может быть ценным, но с другой целью: мы можем установить плавающую цену, нацеливаясь на конкретное среднее использование, но не устанавливать лимит для каждого блока.
Это демонстрирует мощное свойство многомерного Gas: это позволяет нам отдельно узнать для каждого ресурса (i) каково идеальное среднее использование? (ii) каково безопасное максимальное использование на блок? Устанавливая цены на Gas на основе максимального значения на блок и позволяя среднему использованию варьироваться, у нас есть 2n степеней свободы для установки 2n параметров, корректируя каждый параметр с учетом соображений безопасности сети.
В более сложных сценариях, например, когда соображения безопасности для двух ресурсов частично перекрываются, это можно сделать, имея опкод или ресурс, потребляющий несколько типов Gas в определенных количествах (например, от нуля к ненулевому SSTORE может потреблять 5000 Gas для доказательства отсутствия состояния клиента и 20000 Gas для расширения хранилища).
Максимально на транзакцию (выберите тот, который имеет более высокую стоимость данных или вычислений)
Пусть 𝑥1 будет стоимостью Gas для данных, 𝑥2 - стоимостью Gas для вычислений, таким образом, в одномерной системе Gas мы можем записать стоимость Gas транзакции как:
В этой схеме мы определяем стоимость Gas транзакции как:
То есть транзакции оплачиваются в зависимости от того, какой из двух ресурсов они потребляют больше, а не суммы данных и вычислений. Это легко можно расширить на более многомерные случаи (например, 𝑚𝑎𝑥(...,𝑥3∗𝑠𝑡𝑜𝑟𝑎𝑔𝑒_𝑎𝑐𝑐𝑒𝑠𝑠)).
Легко увидеть, как это повышает пропускную способность, обеспечивая при этом безопасность. Теоретически максимальный объем данных в блоке все еще равен Gas LIMIT /𝑥1, так же как в одномерной схеме Gas. Аналогично, теоретический максимум вычислений равен Gas LIMIT /𝑥2, также как в одномерной схеме Gas. Однако стоимость Gas для любой транзакции, потребляющей данные и вычисления, будет уменьшена.
Скорее всего, такой подход принят в предложенном EIP-7623 для уменьшения максимального размера блока при дальнейшем увеличении количества блобов. Точный механизм в EIP-7623 немного сложнее: он сохраняет текущую цену calldata на уровне 16 Gas за байт, но вводит минимальную цену в 48 Gas за байт; транзакции оплачивают большее из (16 * байтов + Gas выполнения) и (48 * байтов). Таким образом, EIP-7623 уменьшает теоретический максимум данных вызова транзакции в блоке с примерно 1,9 МБ до примерно 0,6 МБ, сохраняя при этом стоимость для большинства приложений неизменной. Преимущество такого подхода заключается в том, что он меняет очень мало по сравнению с текущей одномерной схемой Gas, что делает его очень легким в реализации.
Однако у этого подхода есть два недостатка:
1. Даже если все остальные транзакции в блоке используют очень мало этого ресурса, транзакции, которые сильно потребляют один ресурс, все равно будут необоснованно облагаться большой платой;
2. Он стимулирует объединение данных-интенсивных и вычислительно-интенсивных транзакций вместе для экономии затрат.
Я считаю, что правила, подобные тем, которые предложены в EIP-7623, будут приносить значительные выгоды, даже с учетом этих недостатков.
Однако, если мы готовы вложить (значительно больше) усилий в разработку, появится более идеальный подход.
Многомерный EIP-1559: более сложная, но идеальная стратегия
Давайте сначала рассмотрим, как работает стандарт EIP-1559. Мы сосредоточимся на версии, представленной для блобов в EIP-4844, так как она более математически элегантна.
Мы отслеживаем параметр excess _ blobs. В течение каждого периода блока мы устанавливаем:
excess _ blobs <-- max (excess _ blobs + len(block.blobs) - TARGET, 0)
где TARGET = 3. Это означает, что если
Блок содержит больше блобов, чем цель, избыточные _ блобы увеличиваются, и если блок содержит меньше блобов, чем цель, избыточные _ блобы уменьшаются. Затем мы устанавливаем базовую плату за блоб = exp(избыточные _ блобы / 25.47), где exp - это приближение экспоненциальной функции 𝑒𝑥𝑝(𝑥)=2.71828^𝑥.
Это означает, что каждый раз, когда избыточные _ блобы увеличиваются примерно на 25, базовая плата за блобы увеличивается примерно в 2.7 раза. Если блобы становятся слишком дорогими, среднее использование уменьшается, и избыточные _ блобы начинают уменьшаться, автоматически снижая цену снова. Цена на блобы непрерывно корректируется, чтобы в среднем блоки были заполнены наполовину, что означает, что в каждом блоке в среднем содержится 3 блоба.
Если происходит кратковременный пик использования, существует ограничение: каждый блок может содержать максимум 6 блобов, в этом случае транзакции могут конкурировать, увеличивая приоритетную плату. Однако в обычных обстоятельствах каждый блоб должен оплатить только базовую плату за блоб плюс небольшую дополнительную приоритетную плату, чтобы быть включенным в качестве стимула.
Такая ценообразование на газ была в Ethereum уже много лет: уже в 2020 году EIP-1559 ввела очень похожий механизм. Через EIP-4844 мы устанавливаем две независимые плавающие цены на газ и блобы.
Примечание: Базовая плата за газ в гвей на один час 8 мая 2024 года. Источник: ultrasound.money
В принципе, мы можем добавить еще несколько независимых плавающих сборов за чтение хранилища и другие типы операций, но я подробно опишу проблему, на которую нужно обратить внимание, в следующем разделе.
Для пользователей эта ситуация очень похожа на сегодняшнюю: вам больше не нужно платить базовую плату (basefee), а две базовые платы, которые ваш кошелек может абстрагировать от вас, показывая только ожидаемую плату и максимальную плату, которую вы можете ожидать заплатить.
Для строителей блоков оптимальная стратегия в основном такая же, как и сегодня: включать любое допустимое содержимое. Большинство блоков не заполнены - как в случае с газом, так и с блобами. Сложная ситуация возникает, когда достаточно газа или достаточно блобов, чтобы превысить предел блока, требуя от строителей потенциально решить многомерную задачу о рюкзаке для максимизации своей прибыли. Однако даже с довольно хорошими приближенными алгоритмами выгоды от оптимизации прибыли через собственные алгоритмы в этом сценарии намного меньше, чем от использования MEV для тех же операций.
Для разработчиков основной вызов заключается в необходимости переработать функциональность EVM и связанной с ним инфраструктуры, которая в настоящее время разработана на основе одной цены и лимита и теперь должна быть переработана для учета нескольких цен и лимитов.
Одной из проблем, с которой сталкиваются разработчики приложений, является то, что оптимизация становится немного сложнее: в некоторых случаях вы уже не можете явно сказать, что A эффективнее B, потому что если A использует больше calldata, а B использует больше выполнения, A может быть дешевле, когда calldata дешев, и дороже, когда calldata дорог.
Однако разработчики все равно могут достичь довольно хороших результатов, оптимизируясь на основе долгосрочных средних цен.
Многомерное ценообразование, EVM и подвызовы
Одной из проблем, которая не возникает в блобах и не возникнет в EIP-7623 или даже в полной реализации многомерного ценообразования для calldata, но возникнет, если мы попытаемся индивидуально ценить доступ к состоянию или любой другой ресурс, является лимит газа в подвызовах.
Лимиты газа в EVM существуют в двух местах. Во-первых, каждая транзакция устанавливает лимит газа, ограничивая общее количество газа, которое может быть использовано в этой транзакции. Во-вторых, когда контракт вызывает другой контракт, этот вызов может установить свой собственный лимит газа. Это позволяет контрактам вызывать другие контракты, которым они не доверяют, и все равно гарантировать, что у них есть лимит после совершения вызова.
Остается доступным газ для выполнения других вычислений.
<img src="https://img.bitgetimg.com/multiLang/image/ec5474dbb2a7f1806abef925ed20134b171525709</p><p>Примечание: След абстрактных транзакций включает в себя один аккаунт, вызывающий другой аккаунт и предоставляющий ограниченное количество газа вызываемому, чтобы даже если вызываемый исчерпает все выделенное ему газа, внешний вызов может продолжить работу.</p> <p>Проблема заключается в достижении многомерного газа между различными типами выполнения, что, кажется, требует множественных ограничений для каждого типа газа для подвызовов, что требует очень глубоких изменений в EVM и несовместимо с существующими приложениями.</p> <p>Это одна из причин, почему многомерные предложения по газу обычно остаются в двух измерениях: данные и выполнение. Данные (будь то данные вызова транзакции или блоб) выделяются внешне для EVM, поэтому внутренние изменения в EVM для ценообразования данных вызова транзакции или блоба не требуются.</p> <p>Мы можем предложить " решение в стиле EIP-7623" для решения этой проблемы. Вот простая реализация: взимать плату 4 раза больше за операции хранения во время выполнения; упрощения анализа предположим, что каждая операция стоит 10000 газа. По окончании транзакции возврат минимума(7500 * операции_хранения, газ_выполнения). В результате после вычета возврата пользователю нужно заплатить следующие сборы:
газ_выполнения + 10000 * операции_хранения - минимум(7500 * операции_хранения, газ_выполнения)
Это равно:
максимум(газ_выполнения + 2500 * операции_хранения, 10000 * операции_хранения)
Это отражает структуру EIP-7623. Другой подход - отслеживать операции_хранения и газ_выполнения в реальном времени и взимать плату 2500 или 10000 в зависимости от того, насколько увеличилось максимум(газ_выполнения + 2500 * операции_хранения, 10000 * операции_хранения) в момент вызова операции. Это позволяет избежать необходимости избыточного выделения газа для транзакций, которое в основном возвращается через возвраты.
Мы не получили детализированного разрешения для подвызовов: подвызовы могут потреблять всю выделенную транзакции квоту на дешевые операции хранения.
Но мы получили нечто довольно хорошее, а именно, контракт, выполняющий подвызов, может установить ограничение и гарантировать, что по завершении подвызова у основного вызова все еще будет достаточно газа для необходимой последующей обработки.
Самое простое "полное многомерное решение ценообразования", которое я могу предложить, заключается в том, что мы считаем лимит газа для подвызовов пропорциональным. То есть, предположим, что существует 𝑘 различных типов выполнения, и каждая транзакция устанавливает многомерные лимиты 𝐿1...𝐿𝑘. Предположим, что на текущем этапе выполнения осталось газа 𝑔1...𝑔𝑘. Предположим, что вызывается операция CALL, используя лимит газа подвызова 𝑆. Пусть 𝑠1=𝑆, тогда 𝑠2=𝑠1/𝑔1*𝑔2, 𝑠3=𝑠1/𝑔1*𝑔3 и так далее.
Другими словами, мы рассматриваем газ для первого типа (фактически выполнение VM) как особенную "единицу учета", а затем выделяем газ для других типов так, чтобы подвызовы получали одинаковый процент доступного газа в каждом типе. Этот подход может выглядеть немного некрасиво, но он максимизирует обратную совместимость.
Если мы хотим сделать это решение более "нейтральным" между различными типами газа, не жертвуя обратной совместимостью, мы можем просто представить параметр лимита газа для подвызовов как часть оставшегося газа в текущем контексте (например, [1...63]/64).
Тем не менее, независимо от случая, стоит подчеркнуть, что после внедрения многомерного выполнения газа встроенная сложность увеличится, что, кажется, трудно избежать.
Таким образом, наша задача - найти сложный компромисс: готовы ли мы принять определенную степень увеличения сложности (некрасивость) на уровне EVM, чтобы безопасно разблокировать значительные преимущества масштабируемости L1, и если да, какое конкретное предложение наиболее эффективно для экономики протокола и разработчиков приложений? Очень вероятно, что ни одно из двух упомянутых мной решений не является лучшим, но есть еще место для предложения более элегантных и лучших решений.
Особая благодарность Ansgar Dietrichs, Barnabe Monnot и Davide Crapis за их обратную связь и рецензирование.
Дисклеймер: содержание этой статьи отражает исключительно мнение автора и не представляет платформу в каком-либо качестве. Данная статья не должна являться ориентиром при принятии инвестиционных решений.
Вам также может понравиться
Поставка сосредоточена, стоимость L1 недооценена, ожидается, что TON станет следующим крупным событием в криптовалюте
В долгосрочной перспективе сравнивать TON с BNB, имеющим рыночную стоимость 9 миллиардов долларов США, является разумной и реалистичной целью.
Восстановление 1155 биткоинов, потерянных и найденных в сети: жертвой может быть обладатель NFT "скучающей обезьяны", раскрыта личность хакера.
9 мая хакеры начали возвращать ETH пострадавшим, в конечном итоге вернув все ETH. Был ли хакер вынужден сделать этот шаг под давлением, или он сделал это по чувству совести? PANews выяснил некоторые причины на основе онлайн-коммуникаций.
Мем-монета: держите название коротким, избегайте повествования "Мы - не просто мем".
Выберите токен Meme, который соответствует вашим ценностям, и наслаждайтесь увлекательным опытом инвестирования.
Как вы относитесь к поддержке Виталиком EIP-7702: не пожертвует ли это неограниченным потенциалом рынка вызывающих EIP-3074?
ERC-4337 и EIP-3074 - два независимых параллельных свободных рынка. Было бы демонстративным ошибкой отказаться от широких возможностей EIP-3074 ради поддержания легитимности ERC-4337.
