Блоки мертві. Хай живуть блоби: дослідники Ethereum вивчають оновлення для зменшення навантаження на дані валідаторів

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

У нещодавньому дослідницькому пості під назвою "Blocks Are Dead. Long Live Blobs", написаному Тоні Вайрштеттером і іншими учасниками Ethereum, автори окреслюють EIP-8142, або “Block-in-Blobs” — проект пропозиції, вперше представлений раніше цього року.

Дизайн дозволяє кодувати дані транзакцій безпосередньо в blob-и — формат даних, запроваджений оновленням EIP-4844 у Ethereum — замість того, щоб вимагати від валідаторів завантажувати та повторно виконувати повні навантаження виконання.

Ідея спрямована на усунення вузького місця в архітектурі Ethereum, за словами дослідників.

Розширення розмірів блоків разом із більшими межами gas означає, що валідатори повинні завантажувати та перевіряти більший об’єм даних. Це підвищує навантаження на пропускну здатність і обмежує масштабованість.

У березні 2024 року blob-и були впроваджені як частина дорожньої карти доступності даних Ethereum під час оновлення Dencun.

Реалізовані через EIP-4844, відомий також як proto-danksharding, blob-и розроблені для того, щоб переносити великі обсяги даних ефективніше, ніж стандартна transaction calldata.

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

Block-in-Blobs

EIP-8142 доповнює цю ідею.

Замість того, щоб розглядати blob-и як додатковий шар даних, пропозиція переміщає основні дані виконання-пейлоаду — вже закодовані в стандартному форматі RLP Ethereum — у самі blob-и.

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

Зміни стають особливо актуальними в майбутньому, де виконання перевіряють системи zkEVM.

Zero-knowledge proofs можуть підтверджувати, що транзакції були оброблені правильно, усуваючи потребу валідаторам повторно виконувати кожну транзакцію.

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

Block-in-Blobs створений для усунення цієї прогалини, стверджується у пропозиції.

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

Також існують ширші наслідки для того, як Ethereum враховує дані.

Сьогодні Ethereum все ще розділяє gas виконання та використання blob-даних. За новою моделлю обидва можуть бути об’єднані в єдину систему "data gas". Якщо реалізація буде успішною, дослідники кажуть, це узгодить витрати для всіх форм доступності даних і допоможе уникнути накладання обмежень.

Biconomy’s ERC-8211

Окремо ведуться зусилля щодо покращення структури і виконання самих транзакцій.

Biconomy у співпраці із UX треком Ethereum Foundation запропонувала ERC-8211 — стандарт, який перетворює транзакції на програмовані workflow.

Замість фіксованих параметрів при підписанні, ERC-8211 дозволяє транзакціям отримувати актуальні дані з chain, перевіряти умови та виконувати кілька кроків послідовно з одним підписом. Мета — зменшити кількість невдалих транзакцій і забезпечити складніші взаємодії на основі агентів серед DeFi протоколів, як пояснено у треді Biconomy на X.

Обидва нововведення відбуваються в рамках ширшої хвилі експериментів у екосистемі Ethereum. Дослідники окреслили багаторічні шляхи оновлень до кінця десятиліття після минулорічного подвійного запуску hard-fork.