EIP-4844 Економіка: глибоке занурення в стратегії доступних даних Rollup

Автор: Джейсон, ETHconomics Research Space

Велика подяка Colin@colinlyguo за участь в обговоренні та надання коментарів до цієї статті, а також Qi Zhou@qc_qizhou за його відгук щодо цієї статті.

Пишіть попереду

У серії економічних досліджень EIP-4844 ми розділимо його на чотири частини, щоб описати вплив, який нова транзакція з перенесенням блок-об’єктів матиме на мережу. У попередній статті автор детально ознайомився з механізмом комісії за транзакції Blob, включаючи метод розрахунку комісії за транзакції Blob, характеристики транзакцій Blob та алгоритм оновлення базової комісії Blob. У цій статті автор далі досліджує, як нещодавно запроваджений ринок Blob EIP-4844 вплине на стратегію доступності даних його основного зведеного попиту на основі аналізу EIP-4844 Economics and Rollup Strategies.

EIP-4844 Економічна серія:

• Економіка EIP-4844 №1: докладний механізм збору EIP-4844
• EIP-4844 Economics #2: доступні стратегії поглибленого зведення даних (ця стаття)
• EIP-4844 Економіка №3: Поглиблене багатовимірне ціноутворення на ресурси
• EIP-4844 Економіка №4: Поглиблені стратегії упаковки торгівлі типу 3

Стратегія доступності зведених даних

EIP-4844 представляє простори даних Blob як краще рішення щодо доступності даних. Здається, для Rollup потрібно лише технічно оновити свій алгоритм криптографічного зобов’язання для підтримки Blobs. Однак, окрім оновлення базової технології, Rollup має вивчити, як використовувати Blobs, щоб максимально знизити вартість даних про доступність. Іншими словами, Rollup має розробити стратегію надання своїх даних на основі відповідної кривої витрат, а також кривої попиту.

Аналіз гіпотези моделі

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

Гіпотеза 1: Введення неявних витрат на затримку

Під час процесу моделювання, окрім плати за обробку, яка споживається методами доступності даних, ця стаття також вводить неявні витрати на затримку даних. Ціна затримки даних може бути інтуїтивно не зрозумілою для більшості людей. У крайньому прикладі, наприклад, TPS зведення становить 1 транзакцію на день. Очікування, поки ці транзакції заповнять Blob, перш ніж відправити його в L1, не виглядає чудовою стратегією.

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

1. Перевагою L2 є те, що транзакції на ньому можуть бути підтверджені L1. Хоча секвенсор може швидко повернути результати обробки транзакцій L2, якщо транзакція L2 не підтверджена L1, централізований секвенсор насправді менш безпечний, ніж L1, наприклад Polygon. Таким чином, цільові користувачі L2 повинні звернути увагу на дані доступності транзакцій L2, які надсилаються подіям L1, щоб визначити статус транзакції, і покладатися на цей статус для наступних операцій. Таким чином, чим більша затримка даних, тим довше користувачеві доведеться чекати і тим гірше буде працювати з користувачем.
2. Візьмемо для прикладу програми крос-L2. Кінцева безпека таких програм залежить від даних про доступність L2, надісланих до L1. Таким чином, деякі ключові функції таких програм повинні дочекатися завантаження даних про доступність відповідних транзакцій L2, перш ніж їх можна буде реалізувати.
3. Для zkrollup, коли дані про доступність і сертифікат дійсності транзакції L2 надсилаються на L1, транзакція L2 негайно підтверджується L1. Однак для оптимістичного зведення дані про доступність транзакцій L2 все ще повинні чекати періоду перевірки (наприклад, 7 днів) після надсилання в L1. У цьому випадку здається, що своєчасне надання даних про доступність для транзакцій L2 не так важливо. Насправді це не так, оскільки деякі програми (такі як Maker Bridge) безпосередньо виконають перевірку доступності даних рівня 2, надісланих до рівня 1, не чекаючи періоду виклику.

Припущення 2: вартість затримки даних пропорційна часу очікування транзакції

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

1. Експоненціальна функція (вартість затримки експоненціально зростає з часом)
2. Поштучна функція (вартість затримки вводиться лише тоді, коли вона перевищує певний поріг)

У порівнянні з більш детальною характеристикою, наведеною вище, лінійна функція має такі переваги:

1. Похідна є константою, зручною для моделювання та виведення.
2. Безперервно диференційована, похідна операція в процесі моделювання

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

Припущення 3: Споживання газу розумними контрактами, що обробляють дані про доступність, є постійним

У цій статті передбачається, що споживання газу для даних про доступність обробки смарт-контрактів є постійним і не залежить від обсягу транзакцій у пакеті транзакцій у доступній стратегії Blob і доступній стратегії між Calldata та Blob.

У фактичних сценаріях споживання газу для даних доступності обробки може бути лінійно пов’язане з обсягом транзакції. Наприклад, якщо пакет транзакцій складається з усіх операцій L2 → L1, тоді смарт-контракт може потребувати обробки цих операцій одну за одною, тому споживання газу для обробки даних доступності також буде лінійним.

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

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

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

cr:@donnoh_eth

2. Газ, спожитий для обробки даних доступності в Arbitrum, в основному позитивно корелює з розміром пакета транзакцій, що, здається, не відповідає припущенням цієї статті. Фіксована частина досягає 175 000 газів, а змінна частина досягає максимуму 90 000 газів, співвідношення приблизно 51,4%. Певною мірою це припущення все ж є обґрунтованим.

cr:@donnoh_eth

Припущення 4: вартість газу для обробки даних про доступність смарт-контрактів є незначною

У виведенні ціни рівноваги Blob, стратегії впорядкування Blob і розподілу вартості Blob ця стаття припускає, що споживання газу смарт-контрактами, що обробляють дані про доступність, є незначним, тобто воно набагато нижче за вартість завантаження даних про доступність.

До EIP-4844 це припущення було однозначно вірним на основі статистики:

cr:@donnoh_eth

cr:@donnoh_eth

Однак у перші дні виходу EIP-4844 в Інтернет вартість Blob здавалась незначною, дивіться пакетну транзакцію від Optimism. Протягом цього періоду пропозиція Blobs значно перевищує попит, а ціна газу даних становить 1 вей.

cr:beaconcha.in

Хоча це не узгоджується з поточною ситуацією, ця гіпотеза все ще має значення для дослідження трьох вищезазначених тем.

• Рівноважна ціна Blob досліджує сценарій, коли Blob досягає балансу між попитом і пропозицією в майбутньому
• Стратегія впорядкування Blob і розподіл вартості Blob обговорюють сценарій, коли витрати Blob надто високі, і впорядкування потрібно виконати

💡 Поточний (2024.3.31) Blob закріпив ціль і ближче до гіпотези моделювання:

cr: @0xRob

Припущення 5: ціна газу та ціна газу даних є значеннями статичної рівноваги

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

Доступні стратегії для Blob

У EIP-4844 Blob приймає модель зарядки контейнера. Тому для Rollup є компроміси:

Коли blob повністю використовується, амортизована вартість завантаження даних доступності є найнижчою

Витрати на затримку даних є найвищими, коли blob повністю використовується (найдовше очікування для відправки на перший рівень мережі)

Вартість плану доступних даних Blob

Доступні стратегії між Calldata і Blob

Як рішення щодо доступності даних, Blob не повністю перевершує Calldata:

• Амортизована вартість використання Calldata для завантаження даних про доступність залишається незмінною. Немає необхідності чекати, поки дані досягнуть певного рівня, наприклад Blob, щоб зменшити витрати. Тому їх можна швидко опублікувати, що призведе до менших витрат на затримку даних.
• Можна очікувати, що Rollup з меншим обсягом транзакцій буде більш схильний використовувати Calldata. Ці зведені пакети вимагають великих витрат на затримку даних, щоб повністю заповнити Blob.

Вартість тарифного плану доступних даних Calldata

Однак з технічної точки зору Віталік вважає за краще обмежити використання Calldata і дозволити Rollup використовувати Blobs:

• Для Rollup вартість підтримки двох комплектів механізмів є занадто високою.
• Calldata сам по собі не призначений для надання даних.

Також було запропоновано EIP-7623 (проект) щодо підвищення вартості Calldata як рішення доступності даних. Основна ідея проста:

1. Якщо частка Calldata у споживанні газу для транзакцій становить >~ 76%, вартість Calldata становить 68 газу/байт
2. Якщо частка Calldata у споживанні газу транзакції становить < 76%, вартість Calldata становить 16 газ/байт

Цей EIP передбачає припущення, що якщо частка Calldata становить >~ 76%, тоді транзакція вважається використаною для доступності даних. Це значення зважено за історичною статистикою:

1. Спостерігайте за пропорцією Calldata доступних транзакцій і намагайтеся досягти мети якомога більше
2. Слідкуйте за часткою Calldata транзакцій, які не мають доступу до даних, і намагайтеся випадково не пошкодити його.

Блоб-рівноважна ціна

Стратегія порядку блоків

Спільний випуск Blobs, схоже, здатний вирішити проблему надмірних витрат на затримку даних Blob.Подібно до реальних контейнерів, вони не обмежуються перевезенням товарів лише від однієї компанії.

У цьому розділі оцінюються зміни рівноважної ціни Blob, спричинені комбінованою стратегією замовлення в наступних трьох сценаріях, і аналізується, чи є комбінована стратегія замовлення кращою стратегією, ніж опублікування окремо.

1. І Rollup i, і Rollup j використовують Blob як доступне рішення для даних.
2. Rollup i використовує Blob як рішення доступності даних, тоді як Rollup j використовує Calldata як рішення доступності даних.
3. І Rollup i, і Rollup j використовують Calldata як доступне рішення для даних.

Сценарій 1: як Rollup i, так і Rollup j використовують Blob як доступне рішення

Рівноважна ціна Blobs у Сценарії 1 знизиться приблизно наполовину

У сценарії 1 комбінована стратегія замовлення є кращою, ніж опублікована окремо.

Сценарій 2: Rollup i використовує Blob як рішення доступності даних, тоді як Rollup j використовує Calldata як рішення доступності даних

У сценарії 2 рівноважна ціна Blob зросте до 2 разів порівняно з початковою ціною.

У сценарії 2 стратегія об’єднання замовлень не обов’язково є кращою стратегією, ніж публікація окремо.

Сценарій 3: і Rollup i, і Rollup j використовують Calldata як доступне рішення

У сценарії 3 стратегія розподілу замовлень не обов’язково є кращою стратегією, ніж опублікування.

Розподіл вартості Blob

Властивість 1: повинен існувати оптимальний план вирівнювання витрат

Характеристика 2: великі зведені пакети повинні сплачувати комісію Blob, нижчу за коефіцієнт транзакцій

Характеристика 3: Великий зведений пакет повинен сплатити більше половини комісії Blob

Властивість 4: Small Rollup має кращу оптимізацію вартості однієї транзакції

Постскриптум

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

У майбутньому ще багато відкритого простору для досліджень, наприклад, що станеться зі стратегією доступності зведених даних після завершення EIP, що обмежує Calldata. Ласкаво просимо приєднатися до дослідницького простору ETHconomics для обговорення досліджень.

Відповідна інформація

EIP 4844: що це означає для користувачів L2?

EIP-4844 Економіка та зведені стратегії

Економіка EIP-4844 №1: Детальний механізм зборів EIP-4844