Вступ: 13 травня 2024 року Віталік запропонував EIP-7706, який доповнює існуючу модель газу шляхом окремого видалення розрахунку газу для вхідних даних та налаштування базового механізму ціноутворення плати, схожого на газ Blob, подальше зменшення операційних витрат Layer 2. Пов'язані пропозиції також потрібно відслідковувати до EIP-4844, запропонованого у лютому 2022 року, що є дуже давнім. Тому перевіряючи пов'язані матеріали, ми сподіваємося надати огляд останнього механізму газу Ethereum для полегшення швидкого розуміння всіма.

Поточні підтримувані моделі газу Ethereum - EIP-1559 та EIP-4844

У початковому дизайні Ethereum використовував простий механізм аукціону для ціноутворення комісій за транзакції, вимагаючи від користувачів активно заявляти свої транзакції, тобто встановлювати ціни на газ. Зазвичай, оскільки комісії за транзакції, які платять користувачі, йдуть на рахунок майнерів, майнери вирішують порядок упакування транзакцій на основі принципу економічної оптимальності, згідно з ціною, ігноруючи ситуацію MEV. На думку основних розробників того часу, цей механізм стояв перед чотирма проблемами:

Флуктуація рівнів комісій за транзакції не відповідає консенсусним витратам на транзакції: Для блокчейнів у активному стані є достатньо попиту на упаковку транзакцій, що означає, що блоки можуть легко заповнитися, але це часто призводить до значних флуктуацій загальних комісій. Наприклад, коли середня ціна Gas становить 10 Гвей, маржинальні витрати, понесені мережею за прийняття наступної транзакції у блоку, в десять разів вищі, ніж коли середня ціна Gas становить 1 Гвей, що є неприйнятним.

Непотрібні затримки для користувачів: через жорсткий ліміт газу для кожного блоку, разом з природними коливаннями історичного обсягу транзакцій, транзакції часто мають чекати кілька блоків, щоб бути упакованими, що є неефективним для загальної мережі. Немає механізму «розслаблення», який дозволяв би одному блоку бути більшим, а наступному - меншим, щоб виправдати відмінності в попиті між блоками.

Неефективне ціноутворення: Використання простого механізму аукціону призвело до низької ефективності в визначенні справедливої ціни, що означає, що користувачам важко визначити розумну ціну, що призводить до багатьох випадків, коли користувачі платять занадто великі комісійні.

Блокчейн без блок-нагород буде нестабільним: При скасуванні блок-нагород, що виникають внаслідок майнінгу, і прийнятті чистої моделі комісій, це може призвести до багатьох нестабільностей, таких як стимулювання майнінгу "сестринських блоків" для крадіжки комісійних винагород, відкриття більш потужних векторів атак самозаймання тощо.

До пропозиції та впровадження EIP-1559 існувала перша ітерація моделі Gas. EIP-1559, запропонований Віталіком та іншими основними розробниками 13 квітня 2019 року, був прийнятий на озброєння в лондонській модернізації 5 серпня 2021 року. Цей механізм відмовляється від механізму аукціону і замість цього застосовує подвійну модель ціноутворення: базова комісія та пріоритетна комісія. Базова плата кількісно розраховується на основі співвідношення між споживанням газу в материнському блоці та плаваючою та рекурсивною цільовим показником газу за допомогою встановленої математичної моделі. Інтуїтивний ефект полягає в тому, що якщо споживання газу в попередньому блоці перевищує заздалегідь визначений цільовий показник газу, базова плата збільшується, а якщо вона нижча за цільовий показник газу, базова плата зменшується. Це може краще відображати попит і пропозицію та робити прогнози щодо розумного газу точнішими, запобігаючи непомірним цінам на газ через неправильну роботу, оскільки розрахунок базової плати безпосередньо визначається системою, а не вільно визначається користувачами. Конкретний код виглядає наступним чином:

Можна зробити висновок, що коли parent_gas_used більше, ніж parent_gas_target, базова плата поточного блоку порівнюватиметься з базовою платою попереднього блоку плюс значення зсуву. Щодо значення зсуву, воно розраховується шляхом множення parent_base_fee на зсув загального використання газу попереднього блоку відносно цілі газу та взяття залишку від цілі газу та константи, потім взяття максимального значення результату і 1. Логіка схожа у зворотному напрямку.

Крім того, Основна комісія більше не буде виділятися як винагорода для шахтарів, але буде безпосередньо спалюватися, тим самим ставлячи економічну модель Ethereum в дефляційний стан, що сприяє стабільності вартості. З іншого боку, Комісія пріоритету подібна до чайки, яку користувачі дають шахтарям і може бути вільно оцінена, що до певної міри дозволяє повторне використання алгоритму послідовності шахтарів.

З розвитком часу у 2021 році розвиток Rollups поступово досяг свого піку. Ми знаємо, що незалежно від того, чи це OP Rollups, чи ZK Rollups, це передбачає потребу завантаження певних доказів стислих даних L2 на ланцюг через calldata для досягнення Доступності Даних на ланцюзі або їх безпосередню перевірку на ланцюзі. Це накладає значні витрати газу на збереження остаточності L2, які в кінцевому рахунку передаються користувачам. Тому вартість використання більшості протоколів L2 не була настільки низькою, як уявлялася в той час.

У той же час Ethereum також зіткнувся з дилемою конкуренції блокового простору. Ми знаємо, що кожен блок має ліміт газу, що означає, що загальне споживання газу всіма транзакціями в поточному блоці не може перевищувати це значення. Розраховуючи на основі поточного ліміту газу в 30 000 000, теоретично існує обмеження в 1 875 000 байт, де 16 відноситься до газу, спожитого на один байт calldata, обробленого EVM. Це означає, що максимальний розмір даних, який можна розмістити в одному блоці, становить приблизно 1,79 Мб. Однак дані, пов'язані зі зведенням, згенеровані секвенсерами L2, зазвичай мають більший розмір даних, що конкурує з підтвердженням транзакцій іншими користувачами основного ланцюга, що призводить до зменшення кількості транзакцій, які можуть бути упаковані в один блок, тим самим впливаючи на TPS основного ланцюга.

Щоб вирішити цю дилему, основні розробники 5 лютого 2022 року запропонували EIP-4844, який був впроваджений після модернізації Dencun у другому кварталі 2024 року. Ця пропозиція вводить новий тип транзакції під назвою Blob Transaction. На відміну від традиційних типів транзакцій, основна ідея Blob Transaction доповнює новий тип даних, а саме дані Blob. На відміну від типів calldata, дані BLOB не можуть бути доступні безпосередньо EVM, а можуть отримати доступ лише до його хешу, також відомого як VersionedHash. Додатково вводяться два супутніх дизайну. По-перше, порівняно зі звичайними транзакціями, цикл транзакцій GC BLOB коротший, що гарантує, що дані блоку не стануть занадто роздутими. По-друге, дані BLOB мають власний механізм Gas. В цілому, представлений ефект схожий на EIP-1559, але математична модель вибирає природну експоненціальну функцію, яка краще працює в стабільності при коливаннях обсягу транзакцій. Це пов'язано з тим, що нахил природної експоненціальної функції також є природною експоненціальною функцією, що означає, що незалежно від стану обсягу транзакцій мережі, коли обсяг транзакцій швидко зростає, базова комісія газу-блобу відображає більш повно, ефективно стримуючи транзакційну активність. Крім того, ця функція має важливу характеристику, де значення функції дорівнює 1, коли абсциса дорівнює 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Де MIN_BASE_FEE_PER_BLOB_GAS та BLOB_BASE_FEE_UPDATE_FRACTION - дві константи, а excess_blob_gas визначається різницею між загальним споживанням газу кульки в батьківському блоку та константою TARGET_BLOB_GAS_PER_BLOCK. Коли загальне споживання газу кульки перевищує цільове значення, тобто різниця є позитивною, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) більше 1, і base_fee_per_blob_gas збільшується, в іншому випадку воно зменшується.

Це дозволяє здійснювати виконання за низькою ціною в сценаріях, де бажано лише можливість узгодження Ethereum для зберігання даних великого масштабу для забезпечення доступності, не монополізуючи ємність упаковки транзакцій блоку. На прикладі Rollup-послідовника критична інформація L2 може бути укладена в блоб-дані через блоб-транзакції, а логіка для верифікації on-chain може бути реалізована в EVM через складні конструкції, використовуючи versionedHash.

Слід зауважити, що поточне значення TARGET_BLOB_GAS_PER_BLOCK та MAX_BLOB_GAS_PER_BLOCK накладає обмеження на мейннет, а саме ціль оброблення в середньому 3 блобів (0,375 МБ) на блок та максимальний ліміт 6 блобів (0,75 МБ) на блок. Ці початкові обмеження спрямовані на мінімізацію тиску, який EIP створює на мережу, і очікується, що вони будуть збільшені у майбутніх оновленнях, коли мережа продемонструє надійність під час обробки більших блоків.

Удосконалення моделі споживання газу для середовища виконання - EIP-7706

Після уточнення поточної моделі газу Ethereum давайте розглянемо цілі та деталі впровадження пропозиції EIP-7706. Ця пропозиція була запропонована Віталіком 13 травня 2024 року. Подібно до даних Blob, ця пропозиція відокремлює модель газу для іншого спеціального поля даних, а саме calldata, та оптимізує відповідну логіку реалізації коду.

У принципі, логіка обчислення базової комісії для calldata така ж, як базова комісія для blob-даних в EIP-4844, обидві використовують експоненційну функцію для обчислення масштабного коефіцієнта для поточної базової комісії на основі відхилення між фактичним значенням споживання газу в батьківському блоку та цільовим значенням.

Варто зазначити новий дизайн параметра, LIMIT_TARGET_RATIOS=[2,2,4], де LIMIT_TARGET_RATIOS[0] представляє цільове співвідношення газу для виконавчих операцій, LIMIT_TARGET_RATIOS[1] представляє цільове співвідношення газу для даних Blob, а LIMIT_TARGET_RATIOS[2] представляє цільове співвідношення газу для calldata. Цей вектор використовується для обчислення цільових значень газу для трьох типів газу в батьківському блоку, використовуючи LIMIT_TARGET_RATIOS для цілочисельного ділення на обмеження газу наступним чином:

Логіка налаштування для обмежень газу така:

gas_limits[0] має слідувати існуючій формулі коригування.

ліміти газу[1] повинні бути рівні MAX_BLOB_GAS_PER_BLOCK.

gas_limits[2] повинні бути рівні gas_limits[0] // CALLDATA_GAS_LIMIT_RATIO.

Ми знаємо, що поточний gas_limits[0] становить 30000000, а CALLDATA_GAS_LIMIT_RATIO встановлено на 4. Це означає, що поточна цільова кількість газу для calldata становить приблизно 30000000 // 4 // 4 = 1875000. Оскільки, згідно з поточною логікою розрахунку газу для calldata, кожен ненульовий байт споживає 16 Gas, а нульові байти споживають 4 Gas, припускаючи, що розподіл ненульових і нульових байтів в сегменті calldata становить 50%, середня обробка 1 байта calldata потребує 10 Gas. Тому поточна цільова кількість газу для calldata повинна відповідати calldata даним у розмірі 187500 байтів, приблизно вдвічі більше поточного середнього використання.

Перевага цього підходу полягає в значному зменшенні ймовірності досягнення обмеження газу calldata, підтримці використання calldata на відносно стабільному рівні через економічну модель і запобіганні зловживанням calldata. Причина цього дизайну полягає в тому, щоб відкрити шлях для розвитку L2, поєднуючи його з даними blob, для подальшого зниження вартості послідовника.

Disclaimer：

1. Ця стаття була перепублікована з [ TechFlow]. Усі авторські права належать оригінальному авторові [Web3Mario]. Якщо є зауваження до цього перепублікування, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіат статей, перекладених статей, заборонені.