Переведите оригинальный заголовок «Наконец, готовы ли мы к увеличению лимита газа?»

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

Кроме того, появились 2 подхода к увеличению Лимита газа:

• EIP-7782: Сокращение времени блока в протоколе Ethereum
• EIP-7783: механизм на основе «постепенного увеличения», чтобы медленно увеличивать лимит газа со временем.

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

Резюме истории Ethereum с лимитом газа

Когда Ethereum был запущен в 2015 году, лимит газа был изначально установлен на5,000 Газ на блок. С течением времени этот лимит претерпел значительные изменения:

• 2016: Лимит газа впервые был увеличен до около 3 миллионов, а в том же году он был повышен еще раз до примерно 4,7 миллионов.

– В результате апгрейда Tangerine Whistle и, в частности, внедрения EIP-150, лимит газа был увеличен до 5,5 миллиона. Это изменение было внесено в рамках переоценки некоторых инструкций, связанных с операциями ввода-вывода, в ответ на атаки типа отказа в обслуживании (DoS).

– В июле 2017 года лимит газа был увеличен до 6,7 миллиона, и продолжал увеличиваться:

– Декабрь 2017: ~8 миллионов

– Сентябрь 2019: ~10 миллионов

– Август 2020 г.: 12,5 миллиона

– Апрель 2021: 15 миллионов

По EIP-1559 также существует максимальный (или «жесткий предел») лимит газа, который установлен в два раза больше цели. Это означает, что блок может включать транзакции с максимальным количеством газа до 30 миллионов.

И практически четыре года не было никакого увеличения лимита газа вообще.

Время ли наконец пересмотреть Лимит газа?

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

Хранение

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

Существует два типа "роста" в Ethereum:

• Рост государства

• Исторический рост

Рост государства

Состояние Ethereum - это совокупность всех балансов аккаунтов, кода умных контрактов и хранилища, которое продолжает расширяться по мере обработки большего количества транзакций и развертывания умных контрактов. С момента своего создания размер состояния значительно вырос, и это происходило в периоды ускоренного роста, вызванного сетевой перегрузкой, увеличением активности транзакций и ростом децентрализованных финансов (DeFi) и NFT. В настоящее время рост состояния составляет приблизительно 2,5 ГБ в месяц, или 30 ГБ в год.

Этот рост состояния может привести к следующим проблемам:

– Более медленное время доступа к диску

– Увеличены требования к оборудованию

Однако на момент написания этого сообщения ни одна из этих проблем не является особенно значительной. Фактически, разница во времени доступа между системами хранения, которые отличаются всего на несколько десятков гигабайт, является довольно незначительной из-за алгоритмической сложности запросов, которая обычно имеет логарифмическую зависимость. Требования к хранению также незначительны, поскольку стоимость нового оборудования снижается с темпом, который значительно превышает относительно небольшой рост размера состояния в 30 ГБ в год. Даже если это увеличит до 60 ГБ в год, разница, вероятно, не будет заметна и все равно будет превышена технологическим прогрессом в области оборудования.

История роста

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

Тем не менее, стоит отметить, что вскоре самостоятельным стейкерам понадобится более 2 ТБ памяти для запуска валидатора на Ethereum. Это фактически повысит требования до 4 ТБ памяти, так как большинство оборудования продается с учетом двоичных степеней. Парадоксально, это означает, что Ethereum может также использовать дополнительное хранилище, поскольку валидаторы уже должны будут инвестировать в более емкое оборудование, независимо от того, будет ли увеличен лимит газа или нет.

ПРИМЕЧАНИЕ: Нет среднего и худшего случаев анализа хранения, потому что постоянное манипулирование блоками в течение продолжительного времени (недели и месяцы) является безумно дорогостоящим предприятием.

Стоимость хранения со временем

Чтобы оправдать мои утверждения о том, что стоимость хранения данных снижается экспоненциальными темпами, мы можем взглянуть на колебания цен в долларах США на 1 ГБ SSD за последние четыре года:

Извините за плохое качество, но издание, откуда я взял это, было таким

Похоже, что каждые два года стоимость гигабайта SSD имеет тенденцию уменьшаться вдвое.

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

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

Пропускная способность

Средний случай для пропускной способности в Ethereum выглядит примерно как 2 МБ/с; однако большая часть этого числа приходится на CL gossiping blobs и aggreGates. Когда речь идет о увеличении лимита газа, единственное, на что следует обратить внимание, - это размер блока.

В настоящее время максимальный размер зарегистрированного блока составляет 270 КБ, а текущий размер блока после Deneb составляет 75 КБ. Если бы мы удвоили это значение, изменение было бы эквивалентно увеличению на 0,5–2 BLOB-объекта по сравнению с историческим максимумом и текущим средним значением, что было бы эквивалентно увеличению пропускной способности узла на ≈ 2–5 % (входящей и исходящей). Так что, что касается среднего случая, то это не существенное изменение. На самом деле, дополнительные три капли были бы намного хуже.

Худший сценарий с 2-кратным превышением лимита газа

Худший случай рассчитан на 1,7 МБ, что станет 3,4 МБ (+50% пропускной способности, необходимой для всплеска). Это не так много, но всё же значительно. Причина, по которой я считаю, что это не так много, заключается в том, что такая атака отказа в обслуживании (DoS) будет довольно дорогой, а всплеск составит +50% от текущих средних требований, что уже учтено. Как я уже говорил, заполнение блоков на 15 миллионов газа на протяжении нескольких последовательных блоков очень дорогостоящее занятие. Таким образом, хотя злоумышленник в теории может запустить DoS на несколько блоков, он должен потратить значительное количество денег на это. Кроме того, ему придется конкурировать с другими транзакциями, чтобы попасть в блок, что делает это еще более дорогостоящим.

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

Вычисление

Вычисления и время блока никогда не были проблемой, но вот мы идем.

Средний случай

Среднее время вычисления блока обычно составляет менее 1 секунды, даже на медленных машинах с плохими дисками. Здесь нечего обсуждать - в среднем это никогда не было узким местом.

Худший случай

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

Однако любые векторы DoS здесь можно устранить с помощью переоценки, и если увеличение лимита газа производится с помощью EIP-7783, то эти риски пренебрежимо малы.

Вывод

В целом, похоже, что рост СХД не является узким местом для увеличения лимита газа, поскольку аппаратное обеспечение, такое как СХД, легко модернизировать. Однако пропускная способность представляет большую угрозу, так как ее гораздо сложнее масштабировать. К счастью, EIP-7783 эффективно снижает риски, связанные с пропускной способностью и потенциальным увеличением объема вычислений. Тем не менее, было бы разумно переоценить стоимость calldata, чтобы обеспечить дополнительную безопасность (хотя, на мой взгляд, вряд ли в этом есть необходимость).

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

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

Отказ от ответственности:

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