Ознайомтеся з оновленням Dencun та потенційними можливостями Ethereum

Версія оновлення мережі Ethereum Dencun була запущена в тестовій мережі Goerli 17 січня 2024 року, а тестова мережа Sepolia була успішно запущена 30 січня. Модернізація Денкуна все ближче і ближче.

Після оновлення тестової мережі Holesky 7 лютого відбудеться оновлення основної мережі. Офіційно визначено дату запуску магістральної мережі після модернізації в Канкуні - 13 березня 2024 року.

Майже кожне оновлення Ethereum супроводжується значними ринковими тенденціями. Озираючись на останнє оновлення від 12 квітня 2023 року, відоме як Шанхайське оновлення, проекти, пов'язані з Proof-of-Stake (PoS), зазнали підвищеного попиту на ринку.

Якщо слідувати попередньому досвіду, то, ймовірно, з'являться можливості для стратегічного позиціонування напередодні майбутньої модернізації Dencun.

Однак, через технічну складність оновлення Денкуна, його не можна описати так само лаконічно, як оновлення Шанхаю, однією фразою на кшталт "перехід Ethereum від PoW до PoS". Ця складність ускладнює розуміння ключових моментів стратегічного позиціонування.

Тому ця стаття має на меті пояснити технічні деталі оновлення Dencun простою і зрозумілою мовою. Вона допоможе читачам розібратися в тонкощах цього оновлення, висвітливши його зв'язок з доступністю даних (DA), рішеннями рівня 2 та іншими важливими аспектами.

01. EIP 4484

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

Простіше кажучи, поточні рішення Ethereum Layer 2 вимагають відправки транзакцій, що відбуваються на Layer 2, в calldata основної мережі Ethereum. Ці дані виклику потім використовуються вузлами для перевірки дійсності блоків у мережі 2-го рівня.

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

EIP-4844 впроваджує економічно ефективне рішення, створюючи новий тип області зберігання під назвою Binary Large Object (BLOB). Він вводить новий тип транзакцій, відомий як "BLOB-Carrying Transaction", щоб замінити дані транзакцій, які до оновлення зберігалися в calldata. Цей інноваційний підхід допомагає екосистемі Ethereum Layer 2 досягти економії витрат на газ.

Чому сховище BLOB є економічно ефективним？

Як ми всі знаємо, економічна ефективність часто пов'язана з компромісом. Причина, по якій BLOB-дані коштують дешевше, ніж звичайні дані викликів Ethereum аналогічного розміру, полягає в тому, що рівень виконання Ethereum (EL) не має прямого доступу до самих BLOB-даних.

Замість цього, EL може отримати доступ тільки до посилань на дані BLOB, а самі дані BLOB можуть бути завантажені і збережені тільки рівнем консенсусу Ethereum (CL, також відомим як маякові вузли). Вимоги до пам'яті та обчислювальних ресурсів для зберігання BLOB-даних значно нижчі, ніж для звичайних даних викликів Ethereum.

Крім того, BLOB має відмінну особливість - він може зберігатися лише протягом обмеженого періоду (зазвичай близько 18 днів) і не може нескінченно збільшуватися, як розмір реєстру Ethereum.

Термін придатності зберігання BLOB

На відміну від постійного реєстру блокчейну, BLOB - це тимчасове сховище, доступне протягом 4096 епох, або приблизно 18 днів.

Після закінчення терміну дії більшість клієнтів консенсусу не зможуть отримати конкретні дані в BLOB. Однак докази його попереднього існування залишаться в мережі у вигляді зобов'язань KZG і будуть постійно зберігатися в мережі Ethereum.

Чому 18 днів? Це компроміс між вартістю зберігання та ефективністю.

Перш за все, ми повинні розглянути найбільш інтуїтивно зрозумілі бенефіціари цього оновлення - оптимістичні розгортки (такі як Arbitrum та Optimism), оскільки в оптимістичних розгортаннях є 7-денне вікно захисту від шахрайства. Дані про транзакції, що зберігаються в Blob, - це саме те, що потрібно Optimistic Rollups для запуску челенджу.

Таким чином, термін дії Блобу повинен забезпечувати доступ до Доказу шахрайства з оптимістичними роллами. Для простоти спільнота Ethereum вибрала 2 в степені 12 (4096 епох виходять з 2^12, а одна епоха становить приблизно 6,4 хвилини).

BLOB-транзакція та BLOB

Розуміння взаємозв'язку між ними є важливим для розуміння ролі BLOB у доступності даних (ДД).

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

Взаємозв'язок між ними можна зрозуміти так, що більша частина даних першого (дані транзакцій другого рівня) зберігається в другому. Решта даних, тобто зобов'язання BLOB-даних, буде збережено у calldata основної мережі. Іншими словами, обіцянки можуть бути прочитані EVM.

Зобов'язання можна уявити як побудову всіх транзакцій в BLOB в дереві Меркла, і тоді тільки корінь Меркла, який є зобов'язанням, може бути доступним для контракту.

Цього можна досягти розумним шляхом: хоча EVM не може знати конкретний зміст BLOB, контракт EVM може перевірити достовірність даних транзакції, знаючи Зобов'язання.

02. Взаємозв'язок між BLOB та рівнем 2

Технологія Rollup забезпечує доступність даних (DA) шляхом завантаження даних в мережу Ethereum, але вона не призначена для того, щоб смарт-контракти L1 могли безпосередньо зчитувати або перевіряти ці завантажені дані.

Метою завантаження даних про транзакції в L1 є просто надання можливості всім учасникам переглядати ці дані.

До оновлення Dencun, як зазначалося вище, Optimistic Rollups публікуватиме дані про транзакції в Ethereum як calldata. Тому будь-хто може використовувати цю інформацію про транзакції для відтворення стану і перевірки коректності роботи мережі 2-го рівня.

Неважко помітити, що дані про транзакції повинні бути дешевими, відкритими та прозорими. Calldata - не найкраще місце для зберігання даних транзакцій спеціально для Layer 2, а BLOB-Carrying Transaction створено спеціально для Rollup.

На цьому етапі ви можете задатися питанням про важливість даних про транзакції.

Насправді дані про транзакції використовуються лише в певних сценаріях:

• Для оптимістичного згортання, заснованого на припущенні про довіру, існує ймовірність нечесності. У таких випадках корисними стають записи транзакцій, завантажені за допомогою роллапсу, що дозволяє користувачам ініціювати докази шахрайства.
• Для ZK Rollup доведення з нульовим знанням довело, що оновлення стану є коректним. Дані завантажуються лише для того, щоб користувачі могли самостійно розрахувати повний стан. Коли вузол 2-го рівня не може працювати коректно, вмикається механізм аварійного виходу, який вимагає повного дерева станів L2. Про це ми поговоримо в останньому розділі цієї статті.

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

Розміщуючи дані про транзакції в BLOB, хоча вони і недоступні для контрактів, контракт в основній мережі може зберігати зобов'язання BLOB.

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

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

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

Слід зазначити, що в реальній роботі Dencun для генерації зобов'язань не використовується дерево Меркла, подібне до Celestia, а використовується алгоритм KZG (Kate-Zaverucha-Goldberg, Polynomial Commitment).

Порівняно з доведенням за деревом Меркла, процес генерації KZG-доведеності є відносно складним, але його обсяг перевірки менший, а кроки перевірки простіші. Однак недоліком є те, що він вимагає надійних налаштувань (ceremony.ethereum.org, який вже закінчився) і не має можливості запобігати атакам квантових обчислень (Dencun використовує метод Version Hash, а інші методи перевірки можуть бути замінені за необхідності).

Для популярного зараз проекту DA Celestia використовується варіант дерева Меркла. На відміну від KZG, він певною мірою покладається на цілісність вузлів, але допомагає знизити поріг обчислювальних ресурсів між вузлами, зберігаючи децентралізовану природу мережі.

03. Можливості в Денчуні

Хоча EIP-4844 знижує витрати і підвищує ефективність на рівні 2, він також підвищує ризики для безпеки, що також відкриває нові можливості.

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

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

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

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

Це те, що Віталік часто називає атакою на приховування даних.

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

Цей повноцінний вузол може отримувати всі історичні дані, опубліковані секвенсором 2-го рівня в основній мережі Ethereum, через основну мережу Ethereum. Користувачі можуть створити необхідний доказ Merkle і надіслати його до контракту в основній мережі, щоб безпечно завершити виведення активів L2.

Після EIP-4844 дані 2-го рівня існують тільки в BLOB повних вузлів Ethereum, а історичні дані до 18 днів будуть автоматично видалені.

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

Після введення в дію EIP-4844 користувачам буде дуже складно отримати повне дерево статусів рівня 2 у спосіб, що заслуговує на повну довіру.

Без стабільного способу отримання дерева станів 2-го рівня користувачі не можуть виконувати операції примусового виведення коштів в екстремальних умовах. Тому EIP-4844 певною мірою став недоліком безпеки для рівня 2.

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

Ethstorage може вирішити проблему недовіри і отримав два раунди фінансування від Ethereum Foundation.

Насправді, ця концепція може по-справжньому задовольнити потенціал, який принесла з собою модернізація Dencun, і вона заслуговує на нашу увагу.

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

Крім того, більшість існуючих рішень L2 в основному зосереджені на масштабуванні обчислювальної потужності Ethereum, тобто збільшенні TPS. Однак попит на безпечне зберігання великих обсягів даних в мережі Ethereum різко зріс, особливо через популярність додатків, таких як NFT і DeFi.

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

Нарешті, Ethstorage також може вирішувати зовнішні потреби децентралізованих додатків. Наразі існуючі рішення в основному розміщуються на централізованих серверах (з DNS). Таке налаштування робить веб-сайти вразливими до цензури та інших проблем, таких як перехоплення DNS, злом веб-сайтів або збої в роботі серверів, про що свідчать такі інциденти, як Tornado Cash.

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

Відмова від відповідальності:.

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