Переслати оригінальний заголовок «Чи готові ми нарешті до збільшення ліміту газу?»

Возникла ростущая дискуссия о возможности увеличения пропускной способности газа 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 протягом останніх чотирьох років:

Вибачте за погану якість, але публікація, з якої я її взяв, була саме такою

Здається, що кожні два роки вартість 1 ГБ SSD зазвичай зменшується наполовину.

Якщо ми порівняємо це зі збільшенням потужності пам'яті та стану, різниця є незначною. Поточний приріст Ethereum є лінійним, тоді як вартість обладнання зазвичай зменшується експоненційно.

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

Ширина пропуску

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

Наразі максимальний розмір блоку становить 270 КБ, а поточний розмір блоку після Денеба становить 75 КБ. Якби ми подвоїли цей показник, зміна була б еквівалентна збільшенню на 0,5-2 блоба в порівнянні з історичним максимумом і поточним середнім значенням, що було б еквівалентно збільшенню пропускної здатності вузла (вхідної та вихідної) на ≈ 2-5%. Отже, що стосується середньостатистичного випадку, то це не суттєва зміна. Насправді, додаткові три краплі були б набагато гіршими.

Найгірший випадок з подвоєним обмеженням газу

Найгірший варіант був розрахований на 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. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.