Оригінальний автор: @Web3 Маріо

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

На даний момент підтримуються моделі Ethereum Gas - EIP-1559 і EIP-4844

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

• Коливання за рівнем Комісія за транзакцію та консенсусною вартістю транзакцій: В активному Блокчейн існує достатній попит на упаковку транзакцій, а це означає, що блоки можна легко заповнити, але це часто також означає, що загальна комісія Коливання надзвичайно висока. Наприклад, коли середній ціна на газ становить 10 Gwei, гранична вартість мережі для прийняття ще однієї транзакції в блоці в 10 разів перевищує середню ціна на газ в 1 Gwei, що є неприйнятним.
• Непотрібні затримка для користувачів: Через жорсткий ліміт газу кожного блоку в поєднанні з природними коливаннями історичних об'єм, транзакції зазвичай чекають, поки кілька блоків будуть упаковані, але це неефективно для всієї мережі; Тобто не існує механізму «провисання», який дозволяє одному Блок бути більшим, а наступному Блок меншим, щоб задовольнити відмінності в потребах, які Блок в кожному конкретному випадку.
• Неефективне ціноутворення: Використання простого механізму аукціону призводить до неефективного визначення справедливої ціни, а це означає, що користувачам буде важко назвати розумну ціну, а це означає, що в дуже лонг випадках користувачі платять високі комісії.
• Без Нагорода за блок Блокчейн буде нестабільним: Коли Нагорода за блок, принесені Майнінг, видаляються і прийнята чиста модель комісії, це може призвести до дуже лонг нестабільності, наприклад, стимулювання майнінгу до крадіжки Комісія за транзакцію «сестринських блоків», відкриття більш потужних егоїстичний майнінг Вектор атаки тощо.

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

Можна побачити, що коли батьківський\газ_used більший за батьківський_газ_target, то базова плата поточного Блок буде порівнюватися з базовою платою попереднього Блок плюс значення зсуву, а значення зсуву приймається за батьківське_base_fee помножене на зсув загального використання попереднього Блок газ відносно газ цілі, і максимальне значення залишку 1 з газ метою та константою. Зворотна логіка аналогічна.

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

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

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

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

base_fee_per_blob_газ = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_газ / BLOB_BASE_FEE_UPDATE_FRACTION)

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

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

Слід додати, що поточні налаштування TARGET_BLOB_GAS_PER_BLOCK та MAX_BLOB_GAS_PER_BLOCK вводять обмеження в Основна мережа 3 blobs (0,375 МБ) на Блок і максимум 6 blobs (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 ] представляє цільове співвідношення класу операції Gas, LIMIT_TARGET_RATIOS[ 1 ] представляє цільове співвідношення класу даних Blob Gas, а LIMIT_TARGET_RATIOS [ 2 ] представляє calldata Цільове співвідношення класу Gas, цей вектор використовується для обчислення газ цільових значень, що відповідають трьом класам газ в батьківському Блок, а логіка розрахунку наступна, тобто ліміт газу ділиться на LIMIT_TARGET_RATIOS відповідно:

Логіка газ_limits така:

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

газ_limits[ 1 ] має дорівнювати MAX_BLOB_GAS_PER_BLOCK

газ_limits[ 2 ] має дорівнювати газ_limits[ 0 ] // CALLDATA_GAS_LIMIT_RATIO

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

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