Виправте вільні зауваження Віталіка щодо питань DA та стійких до цензури вилучень

Віталік пропустив «виклик доступності даних» Arbitrum і Redstone, яких можна назвати вбивцею Celestia.

Автор: Faust, geek web3

16 січня 2024 року під твітом, ініційованим Деніелом Вангом, засновником проекту Ethereum Layer 2 Taiko, і спілкуючись із Цзен Цзяцзюнем, засновником гаманця AA Soul Wallet, Віталік сказав: «Ключ до Rollup — це безумовна безпека: навіть якщо Ви націлені всіма, і Ви все одно можете забрати активи. Це неможливо зробити, якщо DA покладається на зовнішню систему (за межами Ethereum).»

Escape Pod: «Безпечне зняття коштів без умов» словами Вятліка

Оскільки Віталік розповів про свої погляди на Validium у другій половині цього твіту (Validium відноситься до другого рівня ZK, який не використовує Ethereum для реалізації даних DA), він привернув багато уваги (раніше ходили чутки, що Ethereum Фонд подумає, що Layer2 = Rollup).

(Потрібно підкреслити: **Концепція DA, яка обговорюється в спільноті Ethereum, стосується того, чи можна отримати нещодавно згенеровані дані з Рівня 2, а не того, чи можна отримати історичні дані давно. ** Якщо вони не опубліковані в Ethereum ланцюжок Нові дані, вузли рівня 2 можуть бути не в змозі успішно проаналізувати останній блок L2)

Проте «Дебати щодо визначення рівня 2 Ethereum» і «Війна DA» давно чули незліченна кількість людей. Ця стаття не має на меті обговорювати такі теми. Мета полягає в тому, щоб зосередити більше уваги на першій половині Виступ Віталіка, також Це слова, які згадуються на початку цієї статті.

Тут Віталік зазначив, що Rollup може досягти безнадійного вилучення, стійкого до цензури. Навіть якщо всі вузли Layer2 не співпрацюють з вами, ви все одно можете вилучити свої активи з Layer2; і** він зазначив, що лише зведення може досягти цієї " "Безумовної безпеки вилучення», тоді як рівень 2, який покладається на інші методи випуску даних DA, не може цього зробити. **

Але насправді сказане Віталіком не суворе. **

По-перше, лише активи, які перемикаються з Рівня 1 на Рівень 2, можуть бути перехрещені назад до ланцюжка ETH. Чисті рідні активи Рівня 2 не можуть бути перехрещені на Рівні 1 (якщо власні активи Рівня 2 не розгортають угоду про перехідний актив на Рівні 1).

**Якщо, як сказав Віталік, «усі націлені на вас», **ви можете вивести щонайбільше перемикаючі активи L1-L2, **але ви не можете вилучити свій «власний токен рівня 2», **наразі це не так Не має значення, використовуєте ви звичайний відхід, примусовий відхід чи аварійний люк.

По-друге, «**Безпечне зняття без умов» не обов’язково покладається на систему DA. **Раннє рішення Layer2 до Rollup, Plasma, яке реалізує випуск даних DA в ланцюжку Ethereum, коли система DA виходить з ладу (тобто відбувається приховування даних, окрім секвенсора/комітету, ніхто інший не може отримати нові дані транзакції/стан інформація про перехід), також дозволяє користувачам надсилати сертифікати активів через історичні дані та безпечно виходити з рівня 2.

Іншими словами, **безпечне вилучення Плазми не покладається на систему DA, а **вилучення антицензури не покладається на систему DA (але мають бути доступні історичні дані); крім того, **це твердження з Ethereum Dankrad з Фонду (творець Danksharding) сам сказав, що ** також загальновизнаний.

Зверніться до попередніх статей Geek Web3: «Вилучення даних і докази шахрайства: причини, чому Плазма не підтримує розумні контракти»

По-друге, не враховуючи Celestia та Blobstream, проблему збереження даних/збою DA можна вирішити навіть без використання ETH як рівня DA. Давайте просто поговоримо про «проблему доступності даних», яку реалізують команди Arbitrum і Redstone, дозволяючи секвенсору публікувати лише зобов’язання DA (насправді хеш даних) у ланцюжку, вказуючи, що дані було випущено з ланцюжка. Якщо хтось не може отримати щойно згенеровані дані поза ланцюжком, він може оскаржити зобов’язання DA в ланцюжку та вимагати від секвенсора розкрити дані ланцюжку.

Цей механізм дуже простий за дизайном і йому не потрібно покладатися на сторонні DA, такі як Celestia, Avail або EigenDA. Для цього потрібно лише, щоб сторона проекту Layer2 налаштувала сам вузол DAC поза ланцюгом. можна назвати вбивцею Селестії. **

Далі автор має намір інтерпретувати «безпечний вихід без умов», згаданий Віталіком, і «проблему доступності даних», про яку він не згадував, і спробувати розповісти всім: **Чому сторонні проекти DA, такі як Celestia, Avail , і EigenDA не є обов’язковим варіантом для Рівня 2, який є DA поза мережею та переслідує безпеку? **

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

Насправді неважко зрозуміти, що сказав Віталік, він говорив про евакуаційну кабіну З.К.Роллапа. Escape Hatch, також відомий як Escape Hatch, — це режим виведення, який активується безпосередньо на Layer1. Після запуску цього режиму контракт Rollup перейде в заморожений стан, відхилить нові дані, надані секвенсором, і дозволить будь-кому показати Merkle Proof, щоб підтвердити баланс своїх активів на Рівні 2, і перенести власні активи з Передача офіційної адреси депозиту Layer2. **

Крім того, режим аварійного люка є «ненадійним механізмом вилучення», який може бути вручну запущений сторонами на рівні 1 після того, як транзакція користувача була відхилена секвенсором рівня 2 протягом тривалого часу. **

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

Оскільки всі вузли рівня 2 запускатимуть клієнт Ethereum geth і отримають блоки Ethereum, вони можуть відстежувати запуск події примусового вилучення

Якщо запит на примусове зняття коштів ігнорується протягом тривалого часу, користувач може активно активувати режим аварійного люку (період очікування за замовчуванням протоколу Loopring становить 15 днів, а плану StarkEx – 7 днів). Потім процес роботи такий, як описано на початку цієї статті.Користувач подає доказ Merkle, що відповідає його власним активам, щоб підтвердити свій статус активів на Рівні 2, а потім вилучає активи з контракту, пов’язаного зі зведенням.

**Але щоб побудувати Merkle Proof, вам потрібно спочатку знати повний статус L2, а також **вам потрібно знайти повний вузол L2 для запиту даних. Якщо виникне екстремальна ситуація, згадана Віталіком, і немає вузла рівня 2, який би з вами співпрацював, ** ви можете самостійно запустити повний вузол рівня 2 і отримати історичні дані, опубліковані сортувальником L2 в Ethereum через мережу Ethereum, ** з рівня 2. Блоки генезису починають синхронізуватися один за одним, доки не буде обчислено кінцевий стан і не створено доказ Merkle, після чого кошти можна буде безпечно вивести через аварійний люк.

**Очевидно, що «опір цензурі» на даний момент еквівалентний самому Ethereum/Layer1. **Поки повний вузол Ethereum надає вам історичні дані за дуже давно, це майже ненадійно.

**Однак після EIP-4844 усі вузли Ethereum автоматично втратять деякі історичні дані, тому історичні дані рівня 2 протягом більше ніж 18 днів більше не будуть створювати резервні копії всім вузлом ETH. У цей час опір цензурі вилучення аварійних люків більше не буде таким хорошим, як Today так близько до Trustless. **

Після 4844 ми маємо вірити, що відносно обмежена кількість вузлів Ethereum, які зберігають усі історичні дані, готова надати вам дані (власних вузлів рівня 2 часто дуже мало, тому ми не розглядатимемо їх на даний момент). До того часу припущення про довіру **історичні дані рівня 1 можна буде отримати/вилучення аварійного люка рівня 2 зміниться з сьогоднішнього Trustless або 0 на 1/N, тобто передбачається, що 1 з N вузлів може надати вам дані. **

Команда EthStorage, схоже, прагне розширити цей N, щоб заохотити більше вузлів зберігати давні дані. Якщо знаменник 1/N достатньо великий, оцінка все одно буде близькою до 0, що є близьким до введення припущення про відсутність довіри. Це може бути відповідним рішенням проблеми пошуку історичних даних після 4844 року.

Взаємозв’язок між евакуаційними капсулами та DA – атака програми-вимагача Validium

Тут ми ще раз підсумуємо це: **Аварійний люк дозволяє вам підтвердити статус активів рівня 2 через Merkle Proof і здійснювати надійні зняття коштів на рівні 1. **

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

Конкретний принцип такий: секвенсор може зберігати дані транзакцій і публікувати лише Merkle Root (Stateroot) у ланцюжку Ethereum, а потім через підтвердження дійсності спробувати змусити новий Stateroot пройти перевірку та стати поточним законним Stateroot.

Наразі всі не знають повного статусу, що відповідає законному Stateroot, і не можуть створити відповідний доказ Merkle, щоб ініціювати вилучення аварійного люка. **Ви не можете зняти гроші, якщо сортувальник не бажає надати вам дані. Технічний директор Arbitrum яскраво назвав це «проблемою викупу» (особисто я вважаю за краще називати це атакою з викупом). **

**Але причина, чому DA схильна до «атак з викупом» у Validium поза ланцюгом, полягає в тому, що його власний дизайн механізму недостатньо досконалий.**Якщо запроваджено механізм перевірки, пов’язаний із поведінкою вилучення, або запроваджено проблему доступності даних , теоретично може вирішити проблему атак програм-вимагачів.

До речі, як згадувалося раніше, Плазма, яка дозволяє користувачам виводити гроші за допомогою давніх даних, не матиме «атак з викупом», як Validium, і Плазма також є DA поза ланцюгом (поза ланцюгом DA + перевірка в ланцюзі доказ шахрайства).

*Довідка: *Вилучення даних і докази шахрайства: чому Plasma не підтримує смарт-контракти

**Отже, стійкі до цензури вилучення/аварійні люки не обов’язково залежать від DA, все залежить від конструкції механізму процесу вилучення. **Причина, чому Віталік вважає, що стійкі до цензури зняття пов’язані з DA, полягає в тому, що він почав із існуючих рішень, таких як Validium і Smart Contract Rollup, і вже мав у своєму розумі фіксоване мислення.

**Але це не означає, що весь Рівень 2 офчейну DA у світі стикається з тими ж проблемами, що й Validium.**Це не означає, що зведений тип смарт-контракту є кінцем усього. Інновації можуть відбутися будь-коли (наприклад, проблеми з доступністю даних, згадані пізніше).

З іншого боку, якщо ваше рішення рівня 2 не враховує такі конструкції, як аварійні люки та антицензурні відкликання з самого початку, ваш рівень 2 точно не буде надійним/безпечним. **Іншими словами, хороший DA та система перевірки є достатніми умовами для досягнення стійкого до цензури вилучення, але вони не є необхідною умовою.

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

*Довідковий матеріал: *«Використання теорії бареля для демонтажу моделі безпеки рівня 2 біткойн/ефіріуму та індикаторів ризику»

Celestia Killer: проблеми з доступністю даних для Arbitrum і Redstone

Після розмови про зв’язок між евакуаційним люком і DA, давайте поглянемо на саму DA: рівень 2 не повинен публікувати дані DA в Ethereum, щоб уникнути «приховування даних» секвенсором.

Redstone, Arbitrum, Metis тощо розробляють механізм «перевірки доступності даних», який дозволяє секвенсеру публікувати лише DA Commitment (datahash) + Stateroot у ланцюжку, заявляючи, що параметри переходу стану (дані транзакції) були опубліковані поза мережею. **Якщо хтось не може отримати щойно згенеровані дані поза ланцюгом, він може оскаржити зобов’язання DA щодо ланцюжка та вимагати від секвенсора розкрити дані ланцюжку. **

Якщо секвенсор не зможе вчасно опублікувати дані в ланцюжку ETH після виклику, хеш даних/зобов’язання, яке він опублікував раніше, вважатиметься недійсним, і пов’язаний корінь стану також буде недійсним. **Очевидно, що це напряму вирішує проблему утримання даних (вивільняється лише root root, а відповідні дані транзакції не оприлюднюються). **

Очевидно, що це створює додаткову «проблему доступності даних» порівняно з рівнем 2 оффчейнів DA, таких як Validium і Optimium. **Але такого простого дизайну достатньо, щоб створити сильну конкуренцію Celestia, Avail, EigenDA тощо. **Самостійно налаштуйте DAC і встановіть проблеми з доступністю даних, щоб вам більше не потрібно було покладатися на Celestia.

Але, навпаки, **проблеми з доступністю даних також мають економічні проблеми, які необхідно вирішити. **Засновник ZkSync зазначив під час битви з технічним директором Arbitrum, що **проблеми з доступністю даних теоретично вразливі до атак DoS. **Наприклад, секвенсор швидко звільняє тисячі зобов’язань DA у ланцюжку, а потім приховує відповідні повні дані, не випускаючи їх. Таким чином він може виснажити всі кошти претендента, а потім випустити недійсний блок, викравши активи користувача.

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

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