Введення

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

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

У своєму початковому дизайні Ethereum застосував простий механізм аукціону для встановлення ціни комісій за транзакції, вимагаючи від користувачів активно робити ставки за свої транзакції, встановлюючи ціну на газ. Як правило, оскільки комісії за транзакції, які сплачують користувачі, надходять майнерам, майнери віддають пріоритет транзакціям на основі найвищих ставок, не враховуючи майнерську цінність (MEV). Розробники ядра виділили чотири основні проблеми з цим механізмом:

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

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

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

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

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

Розрахунок базової комісії та наслідки: Якщо використання газу в попередньому блоці перевищує цільовий показник газу, базова плата збільшується; якщо він не дотягує до цільового показника газу, базовий збір зменшується. Це коригування добре відображає динаміку попиту та пропозиції та підвищує точність обґрунтованих прогнозів щодо газу, уникаючи непомірних цін на газ через неправильну роботу, оскільки розрахунок базової плати визначається системою, а не користувачем. Конкретний код для розрахунку виглядає наступним чином:

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

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

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

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

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

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS е*(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 можуть використовувати транзакції Blob для інкапсуляції ключової інформації L2 у дані BLOB і досягнення ончейн-верифікації за допомогою VersionedHash у EVM.

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

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

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

Основні поняття

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

Примітним аспектом цієї пропозиції є введення нового дизайну параметрів, LIMIT_TARGET_RATIOS = [2, 2, 4]. Ось розбивка:

LIMIT_TARGET_RATIOS[0]: Цільове співвідношення для газу виконання операції.

LIMIT_TARGET_RATIOS[1]: Цільове співвідношення для газу даних BLOB.

LIMIT_TARGET_RATIOS[2]: Цільове співвідношення для calldata gas.

Ці коефіцієнти використовуються для обчислення цільових значень газу для трьох типів газу в материнському блоці шляхом ділення ліміту газу на відповідні коефіцієнти.

Ліміти газу встановлюються наступним чином:

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

• gas_limits[1] дорівнює MAX_BLOB_GAS_PER_BLOCK.

• gas_limits[2] дорівнює gas_limits[0] / CALLDATA_GAS_LIMIT_RATIO.

Враховуючи, що струм gas_limits[0] становить 30 000 000, а встановлено CALLDATA_GAS_LIMIT_RATIO значення 4, це означає, що поточна calldata цільова мета газу становить приблизно:

[ \frac{30,000,000}{4 \times 4} = 1,875,000 ]

Згідно з поточною calldata логікою розрахунку газу:

• Кожен ненульовий байт споживає 16 Gas.

• Кожен нульовий байт споживає 4 Газ.

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

Переваги пропозиції

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

Підсумовуючи, EIP-7706 не тільки вдосконалює модель Gas для calldata , але й стратегічно позиціонує Ethereum для ефективного масштабування рішень рівня 2, контролюючи та оптимізуючи споживання газу, пов'язаного з даними.

Застереження:

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