Доповідь: РЕАЛЬНИЙ стан l2

Доповідь Бартека Кєпушевського (Bartek Kiepuszewski), засновника L2BEAT, на Devcon SEA, у якій розглядається поточний стан рішень рівня 2 (l2), розрив між обіцянками щодо безпеки ролапів та реальністю, нові категорії оцінювання, а також зобов'язання L2BEAT виділити значні ресурси на перевірку систем доведення протягом наступного року.

Ця стенограма є доступною копією оригінальної стенограми відео (opens in a new tab), опублікованої Фундацією Ethereum. Її було злегка відредаговано для зручності читання.

Вступ (0:00)

Будучи засновником L2BEAT, я маю унікальну можливість працювати практично з кожною командою l2, і ми співпрацюємо з ними від самого початку розвитку цієї сфери — тобто вже близько чотирьох років. Це неймовірно. Час летить дуже швидко. Ми працювали з першопрохідцями в технологіях з нульовим розголошенням (ZK), ми працювали з Plasma Group, яка перейменувалася на Optimism, ми працювали з Arbitrum. І з цієї сцени я хочу висловити подяку всім цим командам, адже без вашої підтримки ми б точно не були тут. Як L2BEAT, ми надзвичайно вдячні за всю підтримку, яку нам надає спільнота.

Тож давайте поглянемо на те, чого нам вдалося досягти. Перш за все, ми змогли запустити майже 50 ролапів та понад 50 інших l2. Це неймовірне досягнення — це велика кількість систем, і майже стільки ж ми маємо запустити найближчими місяцями. Ми також залучили багато коштів, велику загальну заблоковану вартість (TVL) у ці системи, і якщо ви подивитеся на графіки, вони всі йдуть тільки вгору.

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

Масштабування Етеріуму (2:10)

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

Однак є одне «але». Ви ж знаєте, друзі, завжди є якесь «але», чи не так? І я тут просто для того, щоб бути чесним з усіма вами. Я дійсно хочу, щоб ця сфера стала серйозною, і це моя можливість закликати вас до підтримки, щоб переконатися, що ми не зазнаємо невдачі — не підведемо очікування спільноти. Нам потрібно почати дуже серйозно ставитися до безпеки того, що ми створюємо.

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

Велике «але»: відсутність систем доведення (4:30)

Тож що це за велике «але»? Ну, по-перше, більшість l2 сьогодні не мають системи доведення, що досить дивно, адже першопрохідці, такі як StarkNet, zkSync, Aztec — чотири роки тому, коли вони запускали свої перші ролапи для конкретних застосунків, вони мали системи доведення. Тож так, сьогодні ви можете запустити l2 одним натисканням кнопки. Однак, чи дійсно це l2? Чи дійсно це ролап? Те, що ви робите, — це запуск чогось, що захищено мультипідписом. Я не думаю, що цього достатньо.

Стан екосистеми сьогодні виглядає приблизно так, як на цій діаграмі. Зліва ви можете бачити поточні l2 із системою доведення. Справа ви можете бачити поточні l2 без системи доведення. І я б побився об заклад, що переважна більшість майбутніх l2 не матимуть системи доведення. Це включатиме практично кожен ланцюг OP Stack, за винятком OP Mainnet та Base — і, до речі, хвала їм, вони як чемпіони. Однак кожен інший ланцюг OP Stack просто не має системи доведення.

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

Ради безпеки (6:00)

Наразі більшість l2 не використовують ради безпеки. Що ми маємо на увазі під радою безпеки? Рада безпеки — це, по суті, мультипідпис, який складається щонайменше з восьми учасників і вимагає порогу консенсусу в 75%. Тож ви можете думати про це як про великий мультипідпис, але справа не лише в розмірі — справа в тому, що ми хочемо, щоб учасники були географічно децентралізовані. Можливо, вчора ви чули чудову презентацію про необхідність географічної диверсифікації. Це те, чого ми хочемо від цих структур. І, по суті, найважливіше, ми хочемо, щоб учасники були з різних компаній та різних юрисдикцій. Це надзвичайно важливо, і я покажу вам кілька прикладів, чому саме.

Думайте про ради безпеки як про ці надпотужні мультипідписи. За ними стоїть дуже важливий соціальний рівень. Тож таким є поточний стан речей, і знову ж таки, він дуже поганий. Ми маємо ради безпеки лише в Arbitrum, Optimism, Polygon, zkSync — і я знаю, що StarkNet, Scroll та, що цікаво, Fuel запускаються з радою безпеки. Усі інші — це, по суті, дуже маленькі, внутрішні, часто приватні мультипідписи, і, відверто кажучи, надзвичайно важко знайти різницю між цими мультипідписами та звичайними EOA.

Припущення довіри щодо доступності даних (7:25)

Третя велика помилка, яку ми зробили, полягає в тому, що більшість l2, які не є ролапами, налаштовані з жахливими припущеннями довіри щодо доступності даних (DA). І я використовую слово «жахливими» — по-перше, тому що воно мені подобається, а по-друге, тому що це дійсно, дійсно погано.

Подивіться на ці приклади зліва — Arbitrum, StarkEx, Immutable X. Однак майже всі інші буквально публікують DA на свій сервер у підвалі чи ще десь. Ми не маємо жодного уявлення. Ми буквально не маємо жодного уявлення. Суть у тому, що вони дійсно погані, і, здається, їм байдуже. Тож, можливо, користувачам теж байдуже — ми не знаємо. Але нам потрібно дійсно подивитися на ці дані і сказати всім: гей, це не комітет з доступності даних.

Комітет з доступності даних був спочатку створений і підтриманий StarkWare для реалізацій StarkEx та Arbitrum. Але суть була не в тому, щоб ви могли сказати: «У мене є один сервер у підвалі, я можу назвати його комітетом з доступності даних». Це не було метою цієї ініціативи.

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

Чому системи доведення мають значення (8:40)

Чому ми повинні дбати про системи доведення? На нашу думку, є щонайменше три вагомі причини, чому ми всі повинні мати робочу систему доведення.

Перша полягає в тому, що це насправді дозволяє бездозвільний вихід у разі, якщо всі оператори не працюють — а вони можуть не працювати з будь-якої причини. Зовсім нещодавно у нас був випадок, коли dYdX припинив роботу. Вони попередили користувачів, але багато користувачів не вийшли. Однак, якщо у вас є система доведення, ви можете налаштувати систему так, щоб у бездозвільний спосіб хтось перебрав на себе управління, або ви можете створити механізм екстреного виведення, щоб користувачі могли забрати свої кошти. Це надзвичайно важливо. Без системи доведення ви просто не можете цього зробити — це неможливо.

Друга причина полягає в тому, що ви насправді можете покращити припущення довіри ради безпеки — за умови, звісно, що вона у вас є. І причина цього досить нюансована. Тепер ви можете зробити наступне: замість ситуації, коли зловмисний пропонувальник — а це діаграма, що показує стандартний оптимістичний ролап без системи доведення, який ви можете бачити в багатьох OP Stack сьогодні — є дуже сильний мультипідпис, який може перевизначити корінь стану, і є пропонувальник, який пропонує корені стану. Якщо ця пропозиція є зловмисною, все, що їм потрібно зробити, це підкупити меншість членів ради безпеки, щоб вони відвернулися — не робили нічого зловмисного, а просто нічого не робили, і в цьому випадку зловмисна пропозиція насправді пройде, і вони вкрадуть кошти.

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

Нарешті, системи доведення — якщо ви на Стадії 2 — дозволяють вам усунути будь-яких посередників взагалі. Вам не потрібна рада безпеки, або якщо вона у вас є, то лише для екстрених ситуацій. Тож це насправді може мати глибокі регуляторні наслідки. Ви можете захотіти запустити свій l2 як систему Стадії 2 від самого початку. Це можливо, але, звісно, вам потрібно мати систему доведення — в ідеалі ви можете захотіти мати більше однієї. Вже є деякі анонси систем, які це роблять, як-от нещодавній анонс від команди Незермайнд, яка створює ролап, що має бути на Стадії 2 під час запуску.

Чому ради безпеки, а не мультипідписи (11:29)

Це було про системи доведення. Тепер, чому ради безпеки, а не просто звичайні мультипідписи? Причина в тому: не вірте, що мультипідписи — це мультипідписи. Ось у чому причина — якщо тільки немає соціального рівня, який може дійсно переконати вас, що вони фундаментально диверсифіковані.

У нашій історії було кілька великих подій. У нас був Multichain, який стверджував, що вони дуже децентралізовані, і виявилося, що ні, це не так — і це твердження, яке ви не можете дійсно перевірити незалежно. Величезна атака, або внутрішня робота, або шахрайство (rug pull) — ми не впевнені.

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

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

Тож підсумовуючи: якщо у вас є ролап Стадії 0 без ради безпеки, по суті, зловмисний оператор може робити з вашими коштами все, що заманеться. Якщо ви є ролапом Стадії 0 з радою безпеки, то зловмиснику потрібно підкупити меншість ради безпеки — можливо, це важко зробити, але набагато легше, ніж підкупити більшість ради безпеки, що вам довелося б зробити, якби ваш ролап мав систему доведення. І нарешті, ніхто не зможе вкрасти ваші кошти, якщо ви на Стадії 2. Це обіцянка переходу до Стадії 2.

Запропонована перекласифікація (13:10)

Питання в тому: чи маємо ми правильні стимули для проєктів, щоб вони дійсно дбали про це? Проблема полягає в тому, що єдине, що ми можемо зробити — ми як L2BEAT і ми як спільнота Етеріуму — це застосовувати соціальний тиск. Віталік сказав, що починаючи з наступного року він планує публічно згадувати лише ті l2, які знаходяться на Стадії 1. Раніше він навіть казав, що не буде називати системи ролапами, якщо вони не на Стадії 1.

Тож ми думали, що ми можемо зробити. На даний момент у нас є стадії для ролапів. У нас немає стадій для валідіумів та оптиміумів. Ми довго думали — можливо, ми могли б запровадити «Стадію 0+» для систем, які мають системи доведення, але ще не є Стадією 1. Але після місяців обговорень ми вирішили: ні, настав час дорослішати.

Те, що ми пропонуємо спільноті — і це буде винесено на форум для отримання відгуків спільноти — полягає в наступному. По-перше, ми хочемо створити окрему категорію для систем. Головна відмінність полягає в тому, що вам доведеться мати систему доведення, щоб бути на Стадії 0. Тож, наприклад, StarkNet сьогодні буде на Стадії 0 за цією класифікацією. Усі ланцюги OP Stack, які не мають системи доведення — за винятком Base та Optimism — не потраплять до цієї категорії. І, звісно, ми дамо час системам на адаптацію. Це основна категорія, і вона має бути як суперліга систем.

Потім у вас є інша категорія систем, які не використовують DA Етеріуму. Вони використовують додаткові припущення довіри, які постачаються із зовнішньою DA. Ми називаємо їх «alt-DA», але вони включатимуть валідіуми, оптиміуми та будь-які гібридні конструкції, які ви можете створити. Однак вони повинні надавати вам розумні гарантії DA — це не може бути ваш підвал. Це має бути комітет з доступності даних розумного розміру, або якщо ви використовуєте Celestia чи Avail, вам потрібно використовувати міст.

Категорія «інші» та зобов'язання L2BEAT (16:05)

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

Інтерфейс користувача виглядатиме приблизно так: ви побачите цей розподіл — ролапи, валідіуми та оптиміуми, а також інші. І сортування за замовчуванням буде за безпекою, а не за загальною заблокованою вартістю (TVL). Давайте не будемо гнатися за TVL з поганою безпекою — це закінчиться дуже погано.

Ми будемо просувати проєкти Стадії 1 та Стадії 2. Ми будемо розглядати проєкти Стадії 0 як претендентів. Щодо «інших», ми раді додати їх до списку — ми будемо надзвичайно ліберальними. Вам просто потрібно бути по суті узгодженими з Етеріумом і, очевидно, мати міст, який дозволяє переміщувати кошти. Однак ми будемо дивитися на припущення довіри та мультипідписи, і ми сподіваємося, що повільно, але впевнено системи перейдуть від «інших» до валідіумів/оптиміумів або до ролапів.

Ось як, на нашу думку, виглядала б категорія «інші» — це реальні дані прямо зараз, реальні системи, які можуть потрапити до цієї категорії, якщо вони не запровадять систему доведення. Ви побачите точно, хто є пропонувальником, хто є оскаржувачем (challenger), і хто є оновлювачем (upgrader). Найсмішніше те, що ви можете побачити це сьогодні на L2BEAT — просто ця інформація настільки глибоко захована на сторінці деталей, що, б'юся об заклад, її перевіряють лише дослідники та ентузіасти. Усе це доступно сьогодні. Однак ми дійсно хочемо відкрити ці дані для кінцевих користувачів. Ми хочемо, щоб кінцеві користувачі були по-справжньому обізнані про те, що відбувається, щоб ми всі несли відповідальність за системи, які створюємо.

Чи достатньо просто сказати: «У мене є система доведення»? Ні. Наша обіцянка спільноті як L2BEAT полягає в тому, що наступного року ми виділимо значні ресурси на те, щоб дійсно дуже ретельно і глибоко вивчити ці системи доведення, щоб переконатися, що вони надійні та повні. Ми будемо аналізувати як ZK, так і оптимістичні. Ми заглибимося у вихідний код, ми подивимося, як ви створили своє довірене налаштування, ми подивимося на ваші схеми і побачимо, що саме перевіряється ончейн. Ми хочемо зробити все надзвичайно прозорим, щоб припущення довіри були чітко донесені — і, що більш важливо, ваша система доведення не може бути прихована за необґрунтовано малим білим списком.

Ми наймаємо дослідників. Ми виконаємо всю цю роботу. Це наша обіцянка на наступний рік. Я сподіваюся, що наступний рік стане роком l2 та ролапів — однак справа не в запуску ролапу одним натисканням кнопки. Суть у тому, що ви хочете мати можливість запустити систему з хорошою безпекою. В ідеалі ви хочете успадкувати якомога більше безпеки від Етеріуму. Нам усім потрібно багато працювати, щоб досягти цього. Але якщо ми цього не зробимо, то все, що ми робимо, — це, по суті, створення тисяч небезпечних сайдчейнів. Я думаю, що ми як спільнота цього не хочемо.

Питання та відповіді (18:45)

Ведучий: Перейдемо до питань та відповідей. Чи важливо, щоб ролапи мали децентралізований секвенсор, чи достатньо інших механізмів безпеки?

Бартек Кєпушевський: Це дуже гарне і важливе питання. Я думаю, що ми побачимо різні дизайни. Я не думаю, що децентралізація секвенсора є надзвичайно важливою для безпеки коштів користувачів, але вона може бути важливою для стійкості до цензури в реальному часі в певних ситуаціях. Віталік сказав під час своєї вступної доповіді, що майбутнє може полягати в тому, що ми побачимо ролапи, які стають «based» (базовими) — використовуючи інфраструктуру Етеріуму для боротьби з цензурою в реальному часі — тоді як інші, як-от, скажімо, MegaETH, можуть насправді мати дуже централізований секвенсор і покладатися лише на механізм екстреного виведення. Ми можемо побачити гібридні конструкції. Я думаю, що простір для дизайну величезний, і прямо зараз в L2BEAT ми дійсно хочемо побачити, що станеться і як це буде розвиватися.

Ведучий: Чи будуть системи доведення на основі TEE вважатися Стадією 2, навіть якщо вони передбачають довіру до виробника обладнання?

Бартек Кєпушевський: Коротка відповідь — ні, тому що з конструкціями, які ми бачимо сьогодні, якщо ви використовуєте SGX, Intel може надати доведення, і вони потенційно можуть заблокувати, вкрасти або заморозити все, що захочуть, і ніхто цього дійсно не помітить — і Етеріум цього не помітить. Однак, з усією роботою, яка проводиться для створення бездовірчих, бездозвільних TEE — мені кажуть, що це насправді надзвичайно захоплююча робота. Але коротка відповідь: сьогодні — ні.

Ведучий: Чому Optimism класифікується як Стадія 1? Виходячи з оцінки, це не так — Фундація повністю контролює процес пропозиції.

Бартек Кєпушевський: Вони по суті відповідають усім критеріям. Справа не стільки в процесі пропозиції — справа в тому, хто контролює кошти. У вас може бути централізований пропонувальник, однак є резервний варіант. Якщо вони припиняють роботу, то вся система стає більш бездозвільною. Я думаю, важливо визнати, якою є роль ради безпеки. Ми хочемо, щоб системи Стадії 1 дозволяли вам вийти, якщо централізований пропонувальник зупиниться. Наприклад, з dYdX пропозиція була суперцентралізованою, однак коли вони зупинилися, люди змогли вийти. Тож справа не в тому, централізовані ви чи децентралізовані — справа в тому, чи можете ви насправді вийти у бездозвільний спосіб.

Вони відповідали всім критеріям. До речі, ми вдосконалювали їх — критерії не є чимось висіченим у камені, оскільки всі ці системи розвиваються, тому нам потрібно розвиватися разом із цими системами. Критерії можуть трохи змінюватися, і ми дуже уважно стежимо як за Optimism, так і за Arbitrum, оскільки вони явно є двома лідерами. Є багато нюансів, у які я не маю часу заглиблюватися. Але це не означає, що ви отримуєте призначення стадії назавжди — якщо з'явиться нова інформація або щось, що ми могли пропустити чи не помітити, цілком можливо, що ви можете втратити це призначення.

Ведучий: Які основні причини того, що проєкти не будуються в напрямку Стадії 1?

Бартек Кєпушевський: Складність, час, вартість, таланти. Це напрочуд дорого. Як я вже казав, першопрохідці чотири роки тому по суті будували — dYdX був буквально одним із перших, якщо не першим, ZK-ролапом. Він був специфічним для застосунку, але все ж таки був першим. І якби не дрібні нюанси, це була б Стадія 2 — насправді, це процес управління, який ми вимагаємо для Стадії 2, дає збій. Але в усіх сенсах це система Стадії 2. Вона була побудована чотири роки тому, тож це не означає, що це неможливо.

Я думаю, що те, що робить це надзвичайно складним сьогодні для всіх ролапів, відверто кажучи, полягає в тому, що більшість ролапів не створюються командами — вони запускаються провайдерами «ролап як послуга» (rollup-as-a-service), і нам потрібно стимулювати їх працювати краще. І це важко. Ніхто не казав, що це буде легко.