EIP-7762 і EIP-7691: створення Ethereum Blobs знову великим

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

Однак, як і очікувалося , використання blob-об’єктів було низьким — все ще недостатньо зведених чи децентралізованих програм (DApps), які використовують blob-об’єкти.

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

Деякі стверджують, що блоки дозволяють масштабувати Ethereum і що згодом у мережу буде перенесено більше зведених служб. Інші стверджують, що зведені пакети на даний момент практично не роблять внеску в Ethereum.

Крім цінових ефектів, дискусії виникли навколо більш широких наслідків блобів. Однією з основних тем є те, чи слід коригувати мінімальну базову комісію за blob, як це запропоновано в EIP-7762. Результат цієї пропозиції залишається невизначеним. Інша дискусія, зафіксована в EIP-7691, зосереджена навколо того, чи слід збільшувати кількість блоків, при цьому прихильники стверджують, що це не порушить безпеку консенсусу. Обидві пропозиції розглядаються для майбутнього хардфорка Pectra .

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

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

Давайте спочатку зануримося в точну концепцію доступності даних і пояснимо, як EIP-4844 покращує Ethereum як рівень DA.

Що таке доступність даних (DA)?

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

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

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

Також важливо зазначити, що DA не є двійковою властивістю — це не просто означає «доступний» або «недоступний». Натомість він існує в безперервному спектрі. Захищені та децентралізовані блокчейни, такі як Ethereum, забезпечують потужний DA, але варіації в ступені доступності можуть виникати залежно від таких факторів, як механізм консенсусу та рівень децентралізації.

Чому DA має значення для зведень?

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

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

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

Як EIP-4844 покращує функціональність DA Ethereum?

EIP-4844 представляє нову структуру даних під назвою blob, яка, на відміну від calldata , тимчасово зберігається на рівні консенсусу протягом приблизно 18 днів перед видаленням. Валідатори Ethereum виділяють близько 50 ГБ для тимчасового зберігання blob-об’єктів. Blobs відрізняються від calldata, оскільки вони недоступні для віртуальної машини Ethereum (EVM); доступні лише їхні блоб-обов’язки, що зменшує обсяг даних, забезпечуючи при цьому DA. Blobs пропонують ефективний DA, забезпечуючи лише основні функції, необхідні для зведення, сприяючи значному зниженню комісії за транзакції.

Кожна blob-об’єкт має приблизно 128 KiB, а блок може містити до 6 blob-об’єктів, що становить приблизно 0,784 MiB на блок. Blob-об’єкти додаються за допомогою нового типу транзакцій під назвою blob-транзакції, які, як і попередні транзакції, використовують принаймні 21 000 газів і можуть містити від 1 до 6 blob-об’єктів.

Яка зараз ціна blobs?

Ціна блобів визначається за допомогою нової одиниці, яка називається блоб-газ , де кожна блоб споживає 217 = 131 072 одиниць блоб-газу. Подібно до механізму збору за газ EIP-1559 Ethereum, ціни на блоб-газ динамічно коригуються залежно від перевантаження блобів в останніх блоках. Базова плата за газ Bblobgas,k+1 для наступного блоку k + 1 розраховується таким чином:

Коли блок заповнюється максимум 6 блобами, базова плата за блоб-газ може зрости приблизно на 12,5% у наступному блоці. Наразі мінімальна базова плата за блоб становить 1 вей, установлюючи мінімальну комісію за блоб у 131 072 вей. Кожна блоб-транзакція також включає стандартну комісію за виконання у розмірі 21 000 газу, помножену на ціну газу. Мінімальна базова комісія в 1 вей активно обговорюється, а EIP-7762 пропонує підвищення, щоб краще збалансувати витрати та потреби в доступності даних.

EIP-7762: Збільште мінімальну базову плату за blob

EIP-7762 пропонує збільшити базову плату за газ (забронюйте готель набагато ближче до центру), щоб швидше дізнаватися ціну. Він намагається змінити лише один параметр: MIN_BLOB_BASE_FEE . Він пропонує змінити його з 1 вей до 225 вей. Але яка аргументація стоїть за цією пропозицією?

Чи є проблематичною мінімальна базова комісія за блоб у розмірі 1 вей?

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

Під час цих сплесків поступове коригування базової комісії за газ від 1 вей може повільно узгоджуватися з фактичним попитом. Давайте нагадаємо гіпотетичний сценарій: уявіть, що ви відвідуєте ETH Bangkok 2024 , де ви вирішуєте зупинитися у віддаленому готелі з майже безкоштовними продуктами поблизу. Для повсякденних потреб це ідеальний варіант. Однак, коли вам потрібно відвідати захід у конференц-центрі, у звичайних умовах до нього потрібно дістатися за шість годин. Додайте трафік і відсутність прямих маршрутів, і подорож може розтягнутися на 14 годин.

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

Крім того, теоретичний мінімальний час для досягнення відповідної ціни може не витримати на практиці. Якщо валідатори або конструктори блоків пропускають блоб-транзакції з блоків, цей період виявлення може подовжитися ще далі. Наприклад (з допису dataalways ), під час скидання LayerZero 20 червня базова плата за blob зросла з 1 вей до 7471 гвей. Теоретично це мало зайняти приблизно 252 блоки або 51 хвилину (розраховується так):

log1.125 (7.471 x 1012) = 251.66

Однак фактичний час становив близько 6 годин — майже в 5–6 разів більше, ніж очікувалося. Подовжені періоди визначення ціни означають, що базова комісія не відображає точного попиту. Ця розбіжність може спонукати користувачів згортань і блоків до агресивних ставок через пріоритетні комісії, що призводить до непередбачуваного та висококонкурентного ринку комісій. Підсумовуючи, базова комісія, встановлена надто низькою, затримує відкриття ціни, не узгоджуючи комісії з попитом у реальному часі.

Те, що пропонує EIP-7762, схоже на проживання в готелі ближче до конференц-центру. Хоча ви можете заплатити більше за продукти поблизу, якщо ближче, то швидше та зручніше дістатися до конференц-центру, коли це необхідно.

Чи не вплине на зведені транзакції більша мінімальна базова комісія за blob?

Якщо мінімальна базова комісія за блоб-об’єкт зросте, зведені пакети справді стягуватимуть вищі комісії за подання транзакцій блоб-об’єкта. Однак підвищення мінімальної базової комісії blob з 1 wei до 225 wei не означає, що зведені пакети сплачують у 225 разів поточну комісію за транзакції blob. Це пов’язано з тим, що blob-транзакції сплачують не лише комісію за blob-газ, але й платять комісію за виконання blob-транзакцій. Так само, як і транзакції без blob, транзакції blob сплачують принаймні 21 000 газу. Якщо вони публікують дані виклику, плата за виконання зростає ще більше.

Якщо припустити, що базова плата за газ становить 5 Gwei, плата за виконання транзакцій blob становитиме (принаймні) приблизно 21,000 x 109 = 2.1 x 1013 wei. Для порівняння, мінімальна комісія за один blob становить 131,072 = 1.3 x 105 wei , що робить базову комісію blob тривіальною – приблизно в 1.6 x 108 = 160,000 разів дешевше, ніж комісія за виконання. Інтуїтивно зрозуміло, що помірне збільшення мінімальної базової комісії blob не вплине суттєво на загальну вартість транзакцій blob.

Наприклад, відповідно до запропонованої EIP-7762 мінімальної базової комісії blob у 225 вей, плата за блоб стає 225 x 1.3 x 105 = 4.3 x 1012 wei. Таким чином, загальна вартість (комісія за виконання + комісія Blob) стає 2.1 x 1013 + 4.3 x 1012 = 2.5 x 1013

Це приблизно на 20% більше порівняно з поточною мінімальною базовою комісією за блоб у розмірі 1 вей. У випадках, коли блок заповнено максимум 6 крапками, збільшення може досягати приблизно 120%.

Фактичне збільшення вартості з EIP-7762 також залежить від стратегії транзакцій кожного зведення. Зведені блоби відрізняються за стратегіями подання блобів: вони використовують різну кількість блобів на транзакцію, публікують різну кількість даних викликів і, отже, стягують різні комісії за виконання. Зведені пакети, які публікують складніші докази в calldata, сплачуватимуть вищу комісію за виконання, тобто пропоноване збільшення базової комісії за блоб менш суттєво вплине на їхні загальні транзакційні витрати.

Дані історичних симуляцій, проведених dataalways, показують, що для зведень на основі OP Stack, як-от Base, Optimism і Blast, витрати можуть зрости до 16% із базовою комісією blob у 225 вей. Однак інші зведені показники показали зростання менше ніж на 2%, що свідчить про мінімальний вплив на загальні витрати на транзакції blob.

Уникнення раптового стрибка базової комісії

На додаток до коригування MIN_BLOB_BASE_FEE , було внесено невеликі зміни до способу розрахунку надлишкового газу . Раніше розрахунок excess_blob_gas потенційно міг призвести до небажаного стрибка базової комісії за blob. Щоб запобігти цьому, EIP вводить модифікацію, яка скидає надлишок газу на висоті вилки. Це налаштування забезпечує більш плавні переходи навколо події розгалуження.

Аналізуючи наслідки EIP-7762

Після пропозиції EIP-7762 це викликало значне обговорення . Хоча дослідники в основному погоджуються з мотивацією цієї пропозиції та необхідністю вирішення проблем у відкритті ціни, деякі проблеми залишаються. Однією з основних проблем є потенційний вплив частих коригувань протоколу на стабільність Ethereum. Регулярне тонке налаштування може спричинити непередбачені ускладнення та ризики.

Інша проблема полягає у визначенні відповідної мінімальної базової комісії за blob. Довільному вибору 225 вей бракує сильної емпіричної основи, що спонукає до подальших досліджень, щоб переконатися, що це значення підтримує довгострокові цілі протоколу. Для уникнення потенційної нестабільності або ненавмисних спотворень ринку вкрай важливо встановити надійне обґрунтування цієї базової комісії.

EIP-7691: збільшення пропускної здатності blob

EIP-7691 пропонує пряму зміну: збільшення максимальної кількості блоків на блок. Наразі обмеження становить 6 блоків на блок із цільовим значенням 3. EIP-7691 припускає, що, підвищивши це обмеження (наразі немає точної кількості), зведені пакети можуть досягти більшої масштабованості без шкоди для консенсусної стабільності Ethereum.

Які проблеми виникають у зв’язку зі збільшенням кількості крапель?

Збільшення кількості блоків на блок може збільшити загальний розмір даних, що передаються через однорангову мережу Ethereum (p2p), що потенційно може призвести до затримок у досягненні консенсусу. Кожен блоб містить 128 КБ даних, тому 6 блобів у сумі становлять 784 КБ. З максимальним розміром блоку Ethereum близько 2 МБ, загальна кількість даних, що передаються на слот, включаючи блоби, може досягати приблизно 2,78 МБ .

Зі збільшенням кількості blob-об’єктів збільшується і розмір даних, що збільшує час, необхідний для розповсюдження блоків і blob-об’єктів між вузлами. Ця затримка може поставити під сумнів процес консенсусу Ethereum, особливо тому, що валідатори повинні надати атестації протягом 4-секундного вікна до завершення кожного слоту. Таким чином, забезпечення консенсусної стабільності вимагає ретельного керування часом розповсюдження.

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

Емпіричний аналіз після EIP-4844 (див. публікацію 1 , публікацію 2 ) показує, що частота розгалуження зросла після впровадження та зростає зі збільшенням кількості блоків на блок. На наведеній нижче діаграмі показано показники реорганізації за кількістю блоків з 6 квітня по 6 червня 2024 року. Блоки, що містять максимум 6 блоків, демонструють значно вищу швидкість реорганізації, ніж блоки з меншою кількістю блоків, що викликає занепокоєння щодо впливу EIP-4844 на консенсусну безпеку Ethereum. .

Чи безпечно збільшувати кількість крапель?

Хоча повторні організації можуть виникати з кількох причин, більші навантаження на дані в мережі p2p є лише одним із факторів. Неоптимальні клієнтські реалізації також можуть сприяти частоті реорганізації. Мій початковий аналіз припускає, що час доступності даних (DA), тривалість, протягом якої вузли очікують надходження останнього блоку, є мінімальним — у середньому менше 20 мс, з різницею менше 5 мс між блоками, що містять 0 блоків, і блоками з 6 краплі. Враховуючи, що вузли чекають приблизно 4000 мс, перш ніж подати атестації, ця затримка здається незначною та навряд чи критично вплине на консенсус. На діаграмі нижче показано оцінений час DA для блоків, що містять різну кількість крапель.

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

Як EIP-7623 підтримує EIP-7691

Нещодавно Віталік запропонував: «Я думаю, що нам слід переглянути EIP-7623 і невелике збільшення кількості крапель (наприклад, ціль 3 -> 4, максимум 6 -> 8) для PectraA». Щоб зрозуміти, як EIP-7623 може сприяти цьому збільшенню, давайте спочатку розглянемо його основну пропозицію. (Докладне пояснення EIP-7623 див. тут )

Що таке EIP-7623?

EIP-7623 пропонує скоригувати вартість газу для даних викликів спеціально для транзакцій, які в основному служать цілям доступності даних (DA). По суті, транзакції з низьким газом виконання щодо їхнього розміру даних виклику призведуть до вищих витрат на газ — потенційно до 3 разів більше — для використання даних викликів. Таким чином, транзакції, які містять великі дані викликів, але виконують мінімальне виконання EVM, будуть мати вищі витрати, заохочуючи використання BLOB-файлів замість даних викликів для функцій, пов’язаних з DA.

Обґрунтування цього коригування полягає в тому, щоб мінімізувати вплив на щоденні транзакції користувачів, які не є DA, одночасно оптимізуючи структуру DA. Збільшуючи витрати на дані викликів для транзакцій, пов’язаних із DA, EIP-7623 заохочує операції з великим об’ємом даних переходити від даних викликів до блоків, оптимізуючи сховище мережі та ефективність DA. Крім того, ця пропозиція має на меті зменшити розмір блоку в найгіршому випадку з 2,78 МБ до приблизно 1,2 МБ, усуваючи поточну прогалину, коли середній розмір блоку Ethereum у 125 КБ потенційно може досягти набагато більшої межі.

EIP-7623 і EIP-7691

Якщо EIP-7623 ефективно зменшує максимальний розмір блоку, це створює простір для більшої кількості блоків, підтримуючи цілі EIP-7691. Навіть зі збільшенням кількості блоків загальний розмір даних залишається керованим у найгірших умовах завдяки зменшеній залежності від даних викликів для DA. Таке узгодження між EIP-7623 і EIP-7691 забезпечує більшу пропускну здатність blob-об’єктів без збільшення максимального розміру блоку за допустимі межі.

Висновок

У цій статті представлено нещодавні EIP, спрямовані на покращення функціональності блобів Ethereum. EIP-7762 пропонує підвищити мінімальну базову комісію за блоб-об’єкт, щоб забезпечити швидке визначення ціни під час різкого зростання попиту, мінімізуючи при цьому вплив на загальні витрати на транзакції блоб-об’єктів. EIP-7691 прагне збільшити кількість блоків на блок для подальшого масштабування рівня доступності даних (DA) Ethereum. З більшою кількістю блоків базова плата за блоки буде більш контрольовано зростати під час піків попиту, що дозволить плавніше коригувати ціну.

Навколо цих запропонованих змін точаться детальні дискусії . Наприклад, дебати включають встановлення цільового числа блоків на 4 і максимальної кількості блоків на 6, а також визначення того, чи має бути правило оновлення базової комісії симетричним чи асиметричним. Додаткові міркування передбачають нормалізацію надлишку блоб-газу та коригування частки оновлення бази блоб-комісії .

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