Папа Віталінк I переосмислює L2

Оригінальний автор | Vitalik.eth

Компіляція | Odaily 0xAyA

! [Папа Віталінк I переосмислює L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)

Особлива подяка Карлу Фльоршу за відгук та огляд

Екосистема рівня 2 Ethereum швидко розширювалася протягом останнього року. Екосистема ZK-EVM Rollup, представлена StarkNet, Arbitrum, Optimism і Scroll, досягла великих успіхів у підвищенні безпеки, а сторінка L2beat надає хороший підсумок стану кожного проекту. Крім того, ми бачили, як деякі команди, які створюють сайдчейни, починали створювати Rollups (Polygon), деякі проєкти рівня 1 намагалися перейти на Validation (Celo) і докладали нових зусиль (Linea, Zeth тощо).

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

Деякі наразі автономні проєкти рівня 1 прагнуть наблизитися до екосистеми Ethereum і потенційно стати рівнем 2. **Ці проекти можуть вимагати поступового переходу. Перехід зараз призведе до зниження зручності використання, оскільки технологія не готова до того, щоб викласти все на згорток; Але занадто пізній перехід може коштувати імпульсу і занадто пізно, щоб мати будь-який сенс. Деякі централізовані проєкти хочуть надати користувачам більше гарантій безпеки та вивчають шляхи на основі блокчейну. У багатьох випадках ці проєкти можуть раніше досліджувати «дозволені ланцюжки консорціумів». Насправді їм може знадобитися лише «середній рівень» децентралізації. Крім того, вони часто мають дуже високу пропускну здатність, що робить їх непридатними навіть для роллапів, принаймні в короткостроковій перспективі. Нефінансові додатки, такі як ігри або соціальні мережі, хочуть бути децентралізованими, але потребують лише «середнього рівня» безпеки. Соціальні мережі, наприклад, насправді передбачають, що різні частини програми обробляються по-різному: низькочастотні, високоцінні дії, такі як реєстрація імені користувача та відновлення облікового запису, повинні виконуватися в Rollup; Високочастотні та малоцінні дії, такі як публікації та опитування, вимагають меншої безпеки. Якщо ваша публікація зникла через збій ланцюжка, це прийнятна ціна; Але якщо збій ланцюжка призводить до втрати облікового запису, це велика проблема.

Важливим питанням є те, що сплата меншої, але все ще видимої комісії за зведення є прийнятною для додатків та користувачів рівня 1 Ethereum на даний момент, але не для користувачів за межами світу блокчейну: якщо ви раніше платили 1 долар США, то платити 0,10 долара більш прийнятно; Але якщо раніше ви платили $0, то платити $0,10 неприпустимо. Це стосується як поточних централізованих додатків, так і невеликих проектів рівня 1, які часто мають дуже низькі комісії при невеликій базі користувачів.

Виникає питання: який із цих складних компромісів між ролапами, валідіумами та іншими системами є прийнятним для конкретного застосування?

Rollups、Validiums、Відключено

Перший вимір безпеки та масштабу, який ми розглянемо, можна описати так: якщо ви володієте активом, який був випущений на рівні 1, а потім депонував його на рівні 2, а потім переніс на свій рахунок, чи можете ви бути впевнені, що зможете повернути цей актив на рівень 1? **

У той же час виникає схоже питання: який вибір технологій веде до цієї гарантії, і які компроміси стоять за цим вибором технологій? **

Ми можемо просто описати проблему за допомогою таблиці:

! [Папа Віталінк I переосмислює L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)

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

• Між Rollup і Validium: тип валідіуму, який дозволяє будь-кому здійснювати ончейн-платежі для покриття комісій за транзакції, після чого оператор буде змушений надати деякі дані ланцюжку або втратити депозит.
• Між Плазмою та Валідіумом: Система Плазми надає гарантії безпеки, подібні до зведення, та доступність даних поза мережею (DA), але підтримує лише обмежену кількість програм. Система може надавати повний EVM і гарантії рівня Плазми користувачам, які не використовують складніші програми, і гарантії рівня валідіуму користувачам, які використовують ці програми.

Ці проміжні варіанти можна розглядати як спектр технологій між ролапами та валідіумами. Але що спонукає додаток вибрати ту чи іншу точку родоводу, а не крайню ліву чи крайню праву? Тут є два основних чинники:

Вартість доступності даних на самому Ethereum буде поступово знижуватися в міру вдосконалення технології. Наступний хардфорк Ethereum, Dencun, представив EIP-4844 (також відомий як «proto-danksharding»), який забезпечує ончейн DA близько 32 кБ/с. Очікується, що протягом наступних кількох років це число поступово збільшуватиметься з повним розгортанням danksharding, зрештою досягнувши цільового показника DA близько 1,3 МБ/с. У той же час, удосконалення стиснення даних дозволить нам робити більше з тим самим обсягом даних. Потреби самого додатку: Скільки втрачає користувач через високі комісії в порівнянні з проблемами з додатком? ** Фінансові додатки втрачають більше через збої в роботі додатків; Ігри та соціальні мережі передбачають велику кількість активності на одного користувача, а цінність активності відносно низька, тому компроміс між безпекою для них різний.

Цей компроміс виглядає приблизно так:

! [Папа Віталінк I переосмислює L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)

Ще однією частковою гарантією, про яку варто згадати, є попередні підтвердження. Попереднє підтвердження — це повідомлення, підписане деякими учасниками зведення або валідіуму, в якому говориться: «Ми довели, що ці транзакції включені в цей порядок, і що корінь після стану є таким». Ці учасники можуть підписати попереднє підтвердження, яке не відповідає фактичній ситуації, пізніше; Але якщо вони це роблять, то спалюють завдаток. Це корисно для додатків з низькою вартістю, таких як споживчі платежі, в той час як програми з високою вартістю, такі як багатомільйонні фінансові перекази, можуть чекати «звичайного» підтвердження від повної підтримки безпеки системи.

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

Читання Ethereum без дозволу

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

! [Папа Віталінк I переосмислює L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)

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

Найгірший сценарій, до якого це може призвести, полягає в наступному. Припустимо, перший блок верхнього ланцюга зчитує деякі дані з крайнього лівого блоку ланцюжка Ethereum. Наприклад, хтось вносить 100 ETH на Ethereum у верхній ланцюжок. Потім відбувається відкат з Ethereum. При цьому відкату верхнього ланцюга не відбувається. В результаті, майбутній блок верхнього ланцюга правильно слідував за новим блоком нового правильного ланцюжка Ethereum, але тепер результат неправильного старого ланцюга (тобто депозит у розмірі 100 ETH) все ще існує у верхньому ланцюжку. Ця вразливість може дозволити створити валюту, яка конвертує мостовий ETH у верхньому ланцюжку в частковий резерв.

Вирішити цю проблему можна двома способами:

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

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

Важливо відзначити, що в першому способі є особливий випадок (1). Якщо атака 51% створює два несумісні блоки на Ethereum, і обидва блоки здаються завершеними одночасно, то верхній ланцюг може вибрати неправильний блок (тобто блок, який консенсус спільноти Ethereum в кінцевому підсумку не підтримує) і його необхідно відкотити, щоб перейти до правильного блоку. Можна стверджувати, що немає необхідності писати код заздалегідь, щоб впоратися з цією ситуацією; Він може впоратися з цим, зробивши хардфорк верхнього ланцюга.

Можливість для ланцюжків зчитувати дані на Ethereum без дозволу є цінною з наступних причин:

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

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

Наявність моста робить ланцюг валідіумом?

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

! [Папа Віталінк I переосмислює L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)

Поки що ні! На це є дві причини:

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

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

Тепер давайте зробимо міст мостом валідації: він не тільки перевіряє консенсус, але і ZK-SNARK, який доводить, що стан будь-якого нового блоку обчислюється правильно.

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

Однак ми все ще не вирішили другу проблему: топ-чейн не може читати Ethereum.

Для цього нам потрібно зробити одну з двох речей:

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

! [Папа Віталінк I переосмислює L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)

Фіолетове посилання на діаграмі може бути як хеш-посиланням, так і мостовим контрактом, який підтверджує консенсус Ethereum.

Чи достатньо цього? Як з'ясувалося, цього виявилося недостатньо, адже були невеликі особливі випадки:

Що станеться, якщо Ethereum атакує 51%? ** Як впоратися з оновленням хардфорку Ethereum? ** Як боротися з хардфорком-апгрейдом верхнього ланцюга?**

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

Єдина життєздатна відповідь на запитання (3) полягає в тому, що наявність певної форми механізму управління на Ethereum змусить контракт на міст на Ethereum знати про оновлення хардфорку верхнього ланцюга.

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

Висновок

Існує два ключові виміри «підключення до Ethereum»:

Безпека виведення коштів на Ethereum Безпека зчитування даних Ethereum

Обидва виміри важливі і мають різні міркування. В обох випадках родовід існує:

! [Папа Віталінк I переосмислює L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)

Зверніть увагу, що кожен вимір вимірюється двома різними способами (тобто насправді існує чотири виміри?). ): Безпеку вилучення можна виміряти (i) рівнем безпеки та (ii) відсотком користувачів або варіантів використання, які виграють від найвищого рівня безпеки, тоді як безпеку зчитування можна виміряти (i) здатністю посилання швидко читати блоки Ethereum, зокрема різницею між завершеним блоком і будь-яким блоком, і (ii) силою соціальних зобов'язань посилання при роботі з периферійними випадками, такими як атаки 51% і хардфорки.

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