Vitalik: аналіз різних типів L2

L2 проекти ставатимуть дедалі більш гетерогенними.

Оригінальна назва: 《Different types of layer 2s》

Автор: Vitalik Buterin

Переклад: BlockBeats

Екосистема стрімко розширювалася протягом минулого року. Традиційно екосистему ZK-EVM rollup, представлену StarkNet, Arbitrum, Optimism та Scroll, характеризує швидкий прогрес і постійне підвищення безпеки; сторінка L2beat добре підсумовує стан кожного проекту.

Крім того, ми бачимо, що деякі команди будують сайдчейни, а також починають розробляти rollup-рішення (наприклад, Polygon), деякі L1-проекти намагаються рухатися у напрямку валідації ефективності (наприклад, Celo), а також з'являються абсолютно нові спроби (наприклад, Linea, Zeth…).

Одним із неминучих наслідків цього є те, що ми бачимо тенденцію до більшої гетерогенності L2-проектів (heterogeneous, тобто «гетерогенність». Примітка перекладача: у криптосфері «гетерогенність» означає співіснування або змішування різних типів чи сутностей. Це слово зазвичай використовується для опису різних блокчейнів, протоколів, технологій або активів, які мають різні характеристики, правила чи властивості). Я очікую, що ця тенденція збережеться з таких причин:

Наразі деякі незалежні L1-проекти прагнуть тісніше інтегруватися з екосистемою Ethereum і потенційно трансформуватися в L2-проекти. Ці проекти можуть захотіти здійснити поступовий перехід. Миттєвий повний перехід знизить доступність, оскільки технологія ще не готова до перенесення всього в rollup-рішення. А надто пізній повний перехід може призвести до втрати імпульсу та не мати практичного сенсу.

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

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

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

Важлива тема полягає в тому, що хоча нинішні додатки та користувачі на Ethereum L1 у короткостроковій перспективі готові платити невеликі, але помітні rollup-комісії, користувачі з не-блокчейн світу менш схильні це робити: якщо ви раніше платили 1 долар, то платити 0,10 долара легше прийняти, а якщо раніше платили 0 доларів — це вже складно прийняти.

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

Природне питання: для конкретного додатку, який вибір між rollup-рішенням, validium (валідація ефективності) та іншими системами є найбільш доцільним у цих складних компромісах?

Rollups vs Validiums vs Disconnected Systems

Перший вимір безпеки та масштабованості, який ми розглянемо, можна описати так: якщо у вас є актив, випущений на L1, потім ви депонуєте його на L2, а потім переводите на свій рахунок, то яку гарантію ви маєте, що зможете повернути актив на L1?

Також є пов'язане питання: які технічні рішення забезпечують цей рівень гарантії, і які компроміси вони мають?

Ми можемо описати це питання простою схемою:

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

Між rollup і validium: у validium будь-хто може здійснити платіж на ланцюгу для оплати комісії за транзакцію, і тоді оператор буде змушений надати певні дані на ланцюг, інакше втратить заставу.

Між plasma і validium: система Plasma забезпечує гарантії безпеки, подібні до rollup, з доступністю даних поза ланцюгом, але підтримує лише обмежену кількість додатків. Система може надавати повну EVM і для користувачів, які не використовують складні додатки, забезпечувати рівень гарантій Plasma, а для тих, хто використовує — рівень validium.

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

1. Вартість нативної доступності даних Ethereum, яка з часом знижуватиметься завдяки розвитку технологій. Наступний хардфорк Ethereum Dencun впроваджує EIP-4844 (також відомий як «proto-danksharding»), який забезпечує близько 32 кБ/сек доступності даних на ланцюгу.

Очікується, що протягом наступних років із впровадженням повного danksharding ця доступність даних поступово зростатиме, а кінцева мета — близько 1,3 МБ/сек. Одночасно вдосконалення стиснення даних дозволить робити більше з тією ж кількістю даних.

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

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

Ще один тип, який варто згадати, — це попередні підтвердження (pre-confirmations). Попереднє підтвердження — це повідомлення, підписане групою учасників у rollup або validium, яке засвідчує: «Ми підтверджуємо, що ці транзакції включені в такому порядку, і post-state root такий». Ці учасники можуть підписати попереднє підтвердження, яке не відповідає дійсності, але якщо так станеться, їхня застава буде знищена.

Це дуже корисно для додатків із низькою вартістю (наприклад, споживчі платежі), а для додатків із високою вартістю (наприклад, фінансові перекази на мільйони доларів) краще чекати «звичайного» підтвердження, яке підтримується повною безпекою системи.

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

Довірене читання Ethereum

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

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

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

Є два способи вирішення цієї проблеми:

1. Верхній ланцюг може читати лише фіналізовані блоки Ethereum, тому йому ніколи не потрібно відкотитися;

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

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

Здатність блокчейна читати Ethereum без довіри важлива з двох причин:

По-перше, це знижує ризики безпеки, пов'язані з бриджуванням токенів, випущених на Ethereum (або інших L2), у цей ланцюг;

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

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

Чи може наявність бриджера зробити ланцюг validium?

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

Додатки можуть будувати на цьому функціонал, наприклад, депозити та виведення токенів. Як тільки такий бридж створено, чи забезпечує він якісь гарантії безпеки активів, про які ми згадували раніше?

Поки що — ні! Є дві причини:

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

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

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

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

Однак ми досі не вирішили другу проблему: верхній ланцюг не може читати дані Ethereum. Щоб це реалізувати, потрібно зробити одне з двох:

1. Додати у верхній ланцюг бридж-контракт, який перевіряє фіналізовані блоки Ethereum;

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

Ці фіолетові зв'язки можуть бути як хеш-зв'язками, так і бридж-контрактами, що перевіряють консенсус Ethereum

Чи цього достатньо? Насправді, ні, бо є деякі дрібні крайові випадки:

1. Що станеться, якщо Ethereum зазнає 51% атаки?

2. Як обробляти хардфорк-апгрейди Ethereum?

3. Як обробляти хардфорк-апгрейди вашого ланцюга?

51% атака на Ethereum призведе до наслідків, подібних до 51% атаки на верхній ланцюг, але навпаки. Хардфорк Ethereum може зробити бридж у верхньому ланцюзі недійсним. Соціальне зобов'язання (social commitment), що у разі відкату фіналізованого блоку Ethereum або хардфорку Ethereum буде відповідний відкат або хардфорк у верхньому ланцюзі, — це найчистіше рішення.

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

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

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

Висновок

«Зв'язок із Ethereum» має два ключові виміри:

1. Безпека виведення в Ethereum;

2. Безпека читання Ethereum.

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

Зверніть увагу, що кожен вимір має два різних способи вимірювання (фактично чотири виміри): безпеку виведення можна вимірювати за (i) рівнем безпеки та (ii) тим, скільки користувачів або сценаріїв отримують вигоду від найвищого рівня безпеки;

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

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