Вступ: після поступового занепаду Solana та випуску Token компанією OP, Layer2 і Rollup, здається, стали новим притулком для незліченних практиків Web3. Оскільки ведмежий ринок продовжує поширюватися, FTX виходить з гри, а Multicoin зазнає великих збитків, конкуренти Ethereum поступово вийшли зі стадії Web3, і вони постійно втрачають впевненість конкурувати з ETH. Все більше і більше людей стали вважати Rollup ядром нового раунду оповіді, і все більше і більше проектів виникали на L2, як гриби після дощу.
Але все це «фальшиве процвітання» чи «бульбашка, яка може лопнути будь-коли»? Чи дійсно Rollup і L2 такі хороші, як стверджує більшість людей? Чи справді це так безпечно, як думають люди? Не кажучи вже про те, що багато OP Rollups не мають доказів шахрайства, які ризики безпеці **Rollups? **
Натхненна «Можливістю оновлення Ethereum L2», нещодавно опублікованою L2BEAT, ця стаття зосереджена на ризиках мультипідпису та довіри комітетів, що лежать в основі оновлення Rollup (негайне оновлення контракту Rollup, забираючи ресурси користувача) і попередніх кліше про Rollup. Нагадуючи нещодавню Multichain, ми поговоримо про те, чому L2 не такий «красивий», як багато хто думає.
Короткий опис принципу Rollup
Короткий опис принципу роботи Rollup:
**Ethereum Rollup = набір контрактів на власних вузлах мережі Layer1 + Layer2. **
Групу мережевих вузлів рівня 2 можна розділити на кілька типів ролей, найважливішою з яких є секвенсор (Sequencer). Він отримує запити на транзакції, які відбуваються на Рівні 2, визначає порядок їх виконання, а потім пакує послідовність транзакцій у пакет (Batch), який надсилається до контракту проекту Rollup на Рівні 1 (надалі разом іменується контрактом Rollup).
Повний вузол Layer2 може безпосередньо отримати послідовність транзакцій із секвенсора або прочитати пакет транзакцій (Batch), надісланий секвенсором до Layer1, але останній має вищу остаточну надійність (незмінність), ніж перший. Зазвичай, коли секвенсор надсилає пакет транзакцій до рівня 1, порядок пакету транзакцій не можна змінити (поки в Ethereum немає відкату блоку, послідовність транзакцій Rollup не зміниться).
Оскільки виконання транзакції змінюватиме стан реєстру блокчейну, на додаток до порядку транзакцій повний вузол рівня 2 також повинен синхронізувати стан реєстру з секвенсором, щоб забезпечити узгодженість.
Таким чином, секвенсору потрібно не лише передавати пакети транзакцій до Layer1 Rollup contract, але також передавати результати оновлення стану (Stateroot/State diff) після виконання транзакції до Layer1.
Неважко помітити, що L1 (Ethereum) насправді діє як дошка оголошень для вузлів L2, яка є набагато більш децентралізованою, надійнішою та безпечнішою, ніж власна мережа L2. Для повних вузлів L2, якщо вони отримають послідовність транзакцій Rollup на L1 + початковий Stateroot, вони можуть відновити реєстр блокчейну L2 і обчислити останній Stateroot. Якщо корінь стану, обчислений самим повним вузлом L2, не узгоджується з коренем стану, опублікованим секвенсором для L1, це означає, що секвенсор має шахрайство.
Найбільш інтуїтивно зрозумілий гіпотетичний випадок: Секвенсор L2 може викрасти ресурси користувача. Наприклад, чи може він підробити деякі транзакції, які не повинні були відбуватися (ps: передайте деякі токени користувача L2 на адресу оператора секвенсора, а потім передайте ці токени на L1). Таке запитання можна звести до: що робити після того, як секвенсор опублікує неправильні дані транзакції або неправильний Stateroot? **
Для ризику шахрайства секвенсора різні типи Rollup мають різні контрзаходи. Optimistic Rollup (Optimistic Rollup) дозволяє повним вузлам L2 надавати докази шахрайства (Fraud Proof), доводячи, що дані, видані секвенсором на L1, містять помилки. Наприклад, Arbitrum створив білий список вузлів, що дозволяє вузлам L2 у білому списку видавати докази шахрайства.
Крім того, враховуючи, що більшість бірж і приватних учасників проекту крос-ланцюгового мосту запускатимуть повні вузли L2, помилки можна знайти негайно, а показник успіху більшості секвенсорів Rollup, які викрадають монети, в основному дорівнює 0 (оскільки врешті-решт їх потрібно перевести, це все ще потрібно завершити на біржі, або вкрадені монети можна перенести на L1 і потім знайти інший вихід).
(Агрегатор на зображенні насправді є секвенсором)
Але для Optimism без доказів шахрайства, секвенсер може красти монети через власний міжланцюговий мостовий контракт Rollup. Наприклад, оператор секвенсора може підробляти інструкції щодо транзакцій, переказувати активи інших людей у L2 на їх власну адресу, а потім передавати вкрадені монети в L1 через мостовий контракт, який постачається разом із Rollup. Оскільки доказів шахрайства немає, повний вузол OP не може оскаржити неправильну транзакцію, тому теоретично секвенсор OP може викрасти активи користувача в L2 (якщо він справді цього хоче).
Рішення такого роду проблеми полягає в «соціальному консенсусі» (під контролем громадської думки, наприклад членів спільноти та соціальних медіа), або **покладаючись на офіційну кредитну підтримку OP. **
Цікаво, що біржа нещодавно зменшила затримку для користувачів Arbitrum і Optimism для передачі монет на біржу (зі 100 блоків L2 до 1 блоку L2), що фактично означає віру в те, що секвенсори ARB і OP не зроблять зла** (за замовчуванням це централізовані сервери з офіційним схваленням)**.
На відміну від оптимістичного Rollup, на додачу до повних вузлів L2, ZK Rollup вирішує проблему шахрайства секвенсора через Validity Proof (часто плутають із ZK Proof). У мережі ZK Rollup є вузол під назвою Prover, який призначений для створення доказів дійсності для пакетів транзакцій, виданих секвенсором. У той же час існує контракт (зазвичай званий Verifier) на L1, який спеціально перевіряє сертифікат дійсності.Поки пакет транзакцій і сертифікат, що відповідає Stateroot/State diff, проходять перевірку контракту Verifier, він буде завершений (Finalized). Офіційний міст ZK Rollup випускатиме лише транзакції зняття коштів, підтверджені сертифікатом дійсності, який, очевидно, набагато надійніший за Optimism.
Теоретично безпека OP Rollup гарантується повними вузлами L2 (принаймні один чесний вузол, який може видавати докази шахрайства). Безпека ZK Rollup гарантується контрактом Verifier на L1 (транзакція остаточно підтверджується вузлом L1). На перший погляд, усі вони можуть «успадкувати безпеку L1» (за допомогою L1 для завершення остаточного підтвердження/розрахунку транзакції), а максималісти Ethereum навіть називають це «еквівалентом безпеки L1» (що відповідає остаточності результатів транзакцій L1), але насправді це не так, або навіть далеко від цього.
Ті "кліше" пункти
По-перше, ZK Rollup швидкість генерації підтвердження дійсності надзвичайно низька, секвенсор може виконати тисячі транзакцій за 1 секунду, але для створення підтвердження для цих тисяч транзакцій може знадобитися щонайбільше кілька годин. Але цю проблему також легко вирішити. Основний ZKR по суті розділяє завдання генерації доказів і надсилає їх на різні вузли Prover для паралельної обробки, щоб значно збільшити швидкість генерації доказів.
По-друге, необхідно враховувати затримку публікації даних вузлами L2 у L1. Тому що кожного разу, коли секвенсор або перевірка надсилає дані на L1, буде фіксована вартість (наприклад, для кожної відправки витрачається контейнер). Часта публікація даних на L1 є нерентабельною або навіть збитковою, тому секвенсор і перевірка мінімізують частоту публікації даних на L1, а потім пакують і випускають велику кількість даних за один раз.
Іншими словами, коли кількість користувачів недостатня, а кількість ініційованих транзакцій недостатня, секвенсор затримає передачу даних на L1. Наприклад, коли торік було мало користувачів, Optimism надсилав пакет транзакцій на L1 лише кожні півгодини. Зараз, оскільки кількість користувачів зросла, ця проблема була ефективно вирішена. На відміну від OP, Starknet застосував метод зменшення частоти випусків State diff, щоб зменшити витрати на дані, завдяки чому затримка остаточного підтвердження транзакції Starknet подовжується до 7-8 годин.
Крім того, більшість ZK Rollups часто «збирають багато доказів і надсилають їх на L1 одночасно», щоб ще більше зменшити витрати. Тобто Prover не надсилатиме L1 відразу після створення Proof, а чекатиме, доки буде згенеровано кілька Proofs, об’єднає їх разом, а потім надішле до контракту Verifier L1. (Насправді процес агрегування доказів полягає у використанні одного доказу для включення кроків обчислення, згенерованих перевіркою кількох доказів)
Наслідком цього є те, що частота випусків Proof ще більше зменшується, а затримка від ініціації транзакції до остаточного підтвердження ще більше подовжується.
За даними Block Explorer, **затримка підтвердження транзакції **Polygon ZKEVM становить приблизно 30-50 хвилин, а Starknet і Zksync Era – більше 7 годин. **Очевидно, що це лише «часткове успадкування безпеки L1», яка далека від «еквівалента безпеки L1», як кажуть прихильники Ethereum.
Звичайно, всі вищезазначені проблеми можуть бути вирішені завдяки технічному прогресу, і вони будуть реалізовані в найближчому майбутньому. Наприклад, багато учасників проекту розробляють високопродуктивне апаратне забезпечення, щоб скоротити час генерації доказів дійсності; Optimism також обіцяє незабаром випустити систему захисту від шахрайства; рішення Ethereum Danksharding зменшить вартість даних Rollup у десятки разів або навіть більше, що може ефективно вирішити проблеми, перелічені вище.
Важко розв'язати проблему "правління людини".
Подібно до таких проектів додатків, як Defi, робота мережі Rollup залежить від відповідних контрактів на L1, і ці контракти є «оновлюваними», що означає, що деякі коди можна замінити (більшість Rollups використовують проксі-контракти), і їх можна виконати негайно за авторизацією мультипідпису або комітету безпеки. Дозвольте мені спершу поговорити про висновок: **Зведення може швидко змінити код контракту на L1 за допомогою мультипідпису або комітету безпеки, який контролюється кількома людьми, а потім викрасти активи користувача. **
Перш за все, «чому контракт Rollup потрібно оновити» і «як це оновлюється». Код контракту на Ethereum не можна змінити після розгортання, але Rollup неминуче має різні помилки під час процесу розробки, які можуть призвести до неправильних результатів; у той же час Rollup також проходить часті ітерації продукту, і нові функції потрібно часто додавати; у більш екстремальних випадках можуть бути хакери, які атакують контракт Rollup, тому контракт Rollup потрібно оновлювати, що часто досягається за допомогою проксі-контрактів.
Проксі-контракт насправді є методом, який зазвичай використовується в розробці контрактів Ethereum, який полягає в тому, щоб відокремити дані контракту від бізнес-логіки та зберегти їх у різних контрактах. Дані (змінні стану) зберігаються в проксі-контрактах, а бізнес-логіка (функції) зберігається в логічних контрактах. Проксі-контракт (Proxy) довіряє процес виконання функції логічному контракту (Implementation) через delegatecall, а потім повертає кінцевий результат абоненту (Caller).
Щоб оновити контракт у режимі проксі, вам потрібно лише вказати проксі-контракт на новий логічний контракт (переписати адресу логічного контракту, що зберігається в проксі-контракті). **Більшість проектів Rollup прийняли цей метод оновлення контракту, який можна описати як простий і грубий. **
Неважко уявити, що Контракт Rollup може бути оновлений — це справді величезний грім: якщо оновлений контракт містить шкідливий код, наприклад зміна умов випуску зняття вбудованого мостового контракту Rollup або зміна умов контракту Verifier для визначення дійсності та підтвердження правильності, секвенсер може вкрасти монети (принцип згадувався раніше).
Але проблема в тому, що контракт Rollup не може бути оновлений. Причина дуже зрозуміла. Загалом, переважна більшість Rollup вирішить, чи оновлювати контракт Rollup за допомогою управління DAO, комітету з безпеки або авторизації за допомогою мультипідпису. Крім того, блокування часу Timelock використовуватиметься для встановлення періоду затримки для оновлення контракту.
Враховуючи, що більшість пропозицій DAO мають автоматизований процес виконання (реалізований через контракти в ланцюжку), навіть якщо контракт потрібно оновити, спочатку потрібно отримати достатню кількість голосів, а потім операція оновлення контракту буде виконана лише після затримки, визначеної блокуванням часу (часто багато днів). Якщо хтось хоче брати участь у зловмисному оновленні контракту, йому потрібно подолати керування DAO за допомогою атак на управління (наприклад, атак на управління, які відбулися на Tornado Cash), але вартість цього дуже висока, і вони повинні спочатку отримати достатню кількість токенів, що не вдасться за звичайних обставин. Навіть якщо атака управління буде успішною, завдяки блокуванню часу користувачі матимуть достатньо часу, щоб вивести активи з L2, а **офіцери Rollup матимуть достатньо часу, щоб вжити екстрених заходів. **
Схоже, блокування часу є чарівною зброєю проти зловмисного оновлення контракту. Але проблема полягає в тому, що так звані "надзвичайні заходи, які можуть вжити офіційні особи Rollup" фактично обходять керування DAO і блокування часу та негайно оновлюють контракт Rollup через мультипідпис або авторизацію комітету безпеки. З огляду на те, що поточний основний Rollup містить мільярди доларів у активах користувачів, «негайне оновлення контракту», дозволене комітетом із мультипідпису та безпеки, є крайнім надзвичайним заходом, але це також дамоклів меч, що висить над головами всіх користувачів.
Очевидно, це питання максимізації довіри: ви повинні вірити, що співробітники Rollup не матимуть думки про крадіжку ваших активів. Якщо розглядати це з точки зору Trustless (точка зору Ніка Сабо), **усі зведені пакети, які контролюються комітетами з мультипідпису та безпеки, небезпечні. **Емін Ган Сірер, засновник Avalanche, Анатолій, засновник Solana, і Джастін Бонс, відома сонячна пляма, усі наголошували на цій проблемі.
Якими зведеними пакетами маніпулюють мультипідписи/комітети?
Відповідно до звіту «Можливість оновлення Ethereum L2», опублікованого відомою науково-дослідною установою рівня L2 L2 BEAT і веб-сайтом візуалізації даних L2BEAT, **Arbitrum, Optimism, Loopring (Loopring), ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM та інші основні зведені пакети мають багатопідписні або авторизовані комітетом контракти на оновлення та можуть обійти час. обмеження блокування. **
Хоча dYdX має адресу EOA, яка може обійти договір про оновлення управління DAO, вона обмежена блокуванням часу (принаймні 2 дні затримки). Immutable X має 14-денну затримку оновлення контракту. Тому, згідно з L2BEAT, **dYdX і Immutable X є більш ненадійними, ніж інші основні зведені пакети, які запустили основну мережу. **
**Тож як зменшити ризик довіри, пов’язаний із мультипідписом і комітетом безпеки? **Відповідь насправді схожа на інцидент Multichain: її можна віднести до проблеми боротьби з відьмами. Необхідно переконатися, що multisigs/комітети контролюються декількома різними організаціями без високого ступеня збігу інтересів і низького ризику змови. Наразі здається, що немає іншого хорошого способу, окрім як підвищити зрілість децентралізованого управління DAO та запросити відомих і авторитетних знаменитостей або інституцій до участі в багатопідписному комітеті. Наведений вище сценарій, здається, був поширеним у реальних демократіях.
Звичайно, також можна обмежити поведінку оновлення контракту, керовану мультипідписом/комітетом, за допомогою блокування часу, але це потрібно зважити з багатьма факторами, оскільки мета мультипідпису/комітету полягає в швидкому вирішенні деяких надзвичайних ситуацій; водночас, якщо сторона проекту Rollup не має твердого рішення щодо питання надійності, цю проблему неможливо вирішити.
Тому, незважаючи на те, що різні проекти Rollup можуть гарантувати безпеку активів користувачів більшу частину часу завдяки складній конструкції механізму, ймовірність події «чорний лебідь» у Rollup не дорівнює нулю через існування кількох підписів і комітетів. Навіть якщо ймовірність змови між кількома підписами та членами комітету становить лише 1 на 10 000, враховуючи вартість активів, що перебувають на зберіганні L2 (передбачається, що це 10 мільярдів доларів США), ризик активів користувачів L2 все одно становить 1 мільйон доларів США на день. Нагадує інцидент із Multichain, це справді моторошно.
Тож я особисто вважаю, що, як раніше казав Поліня, більшість коштів в екосистемі Ethereum все одно матимуть тенденцію циркулювати та замикатися в L1, а не в L2, а екосистема Rollup не зможе охопити більшу частину вартості в екосистемі Ethereum у довгостроковій перспективі. Для великих інвесторів і китів основна мережа Ethereum, очевидно, є більш придатним і надійним місцем для отримання коштів, ніж L2. Тому багато людей розмірковували над тим, «чи призведе зростання L2 до дезертирства L1», насправді у них вже є відповідь.
Як сказав Кейго Хігасіно у своїй книзі, людське серце набагато невловиміше, важче зрозуміти, складніше та важче змінити, ніж математичні формули. Багато речей не можна вирішити суто технічними засобами, але будь-який фактор, пов’язаний із «людською природою», завжди буде найбільш неконтрольованою, непередбачуваною та найсерйознішою проблемою у світі. Згадаймо, будь ласка, класичне речення на надгробку Канта:
«Дві речі завжди оточують мою думку, і чим більше я думаю про них, тим більше подиву й благоговіння вони викликають у мене: моральний закон усередині та зоряне небо над головою».
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Найбільший ризик довіри Rollup: проблема «правління людини», яку не можна ігнорувати
Автор: Link, Geek Web3
Вступ: після поступового занепаду Solana та випуску Token компанією OP, Layer2 і Rollup, здається, стали новим притулком для незліченних практиків Web3. Оскільки ведмежий ринок продовжує поширюватися, FTX виходить з гри, а Multicoin зазнає великих збитків, конкуренти Ethereum поступово вийшли зі стадії Web3, і вони постійно втрачають впевненість конкурувати з ETH. Все більше і більше людей стали вважати Rollup ядром нового раунду оповіді, і все більше і більше проектів виникали на L2, як гриби після дощу.
Але все це «фальшиве процвітання» чи «бульбашка, яка може лопнути будь-коли»? Чи дійсно Rollup і L2 такі хороші, як стверджує більшість людей? Чи справді це так безпечно, як думають люди? Не кажучи вже про те, що багато OP Rollups не мають доказів шахрайства, які ризики безпеці **Rollups? **
Натхненна «Можливістю оновлення Ethereum L2», нещодавно опублікованою L2BEAT, ця стаття зосереджена на ризиках мультипідпису та довіри комітетів, що лежать в основі оновлення Rollup (негайне оновлення контракту Rollup, забираючи ресурси користувача) і попередніх кліше про Rollup. Нагадуючи нещодавню Multichain, ми поговоримо про те, чому L2 не такий «красивий», як багато хто думає.
Короткий опис принципу Rollup
Короткий опис принципу роботи Rollup:
**Ethereum Rollup = набір контрактів на власних вузлах мережі Layer1 + Layer2. **
Групу мережевих вузлів рівня 2 можна розділити на кілька типів ролей, найважливішою з яких є секвенсор (Sequencer). Він отримує запити на транзакції, які відбуваються на Рівні 2, визначає порядок їх виконання, а потім пакує послідовність транзакцій у пакет (Batch), який надсилається до контракту проекту Rollup на Рівні 1 (надалі разом іменується контрактом Rollup).
Повний вузол Layer2 може безпосередньо отримати послідовність транзакцій із секвенсора або прочитати пакет транзакцій (Batch), надісланий секвенсором до Layer1, але останній має вищу остаточну надійність (незмінність), ніж перший. Зазвичай, коли секвенсор надсилає пакет транзакцій до рівня 1, порядок пакету транзакцій не можна змінити (поки в Ethereum немає відкату блоку, послідовність транзакцій Rollup не зміниться).
Оскільки виконання транзакції змінюватиме стан реєстру блокчейну, на додаток до порядку транзакцій повний вузол рівня 2 також повинен синхронізувати стан реєстру з секвенсором, щоб забезпечити узгодженість.
Таким чином, секвенсору потрібно не лише передавати пакети транзакцій до Layer1 Rollup contract, але також передавати результати оновлення стану (Stateroot/State diff) після виконання транзакції до Layer1.
Неважко помітити, що L1 (Ethereum) насправді діє як дошка оголошень для вузлів L2, яка є набагато більш децентралізованою, надійнішою та безпечнішою, ніж власна мережа L2. Для повних вузлів L2, якщо вони отримають послідовність транзакцій Rollup на L1 + початковий Stateroot, вони можуть відновити реєстр блокчейну L2 і обчислити останній Stateroot. Якщо корінь стану, обчислений самим повним вузлом L2, не узгоджується з коренем стану, опублікованим секвенсором для L1, це означає, що секвенсор має шахрайство.
Найбільш інтуїтивно зрозумілий гіпотетичний випадок: Секвенсор L2 може викрасти ресурси користувача. Наприклад, чи може він підробити деякі транзакції, які не повинні були відбуватися (ps: передайте деякі токени користувача L2 на адресу оператора секвенсора, а потім передайте ці токени на L1). Таке запитання можна звести до: що робити після того, як секвенсор опублікує неправильні дані транзакції або неправильний Stateroot? **
Для ризику шахрайства секвенсора різні типи Rollup мають різні контрзаходи. Optimistic Rollup (Optimistic Rollup) дозволяє повним вузлам L2 надавати докази шахрайства (Fraud Proof), доводячи, що дані, видані секвенсором на L1, містять помилки. Наприклад, Arbitrum створив білий список вузлів, що дозволяє вузлам L2 у білому списку видавати докази шахрайства.
Крім того, враховуючи, що більшість бірж і приватних учасників проекту крос-ланцюгового мосту запускатимуть повні вузли L2, помилки можна знайти негайно, а показник успіху більшості секвенсорів Rollup, які викрадають монети, в основному дорівнює 0 (оскільки врешті-решт їх потрібно перевести, це все ще потрібно завершити на біржі, або вкрадені монети можна перенести на L1 і потім знайти інший вихід).
Але для Optimism без доказів шахрайства, секвенсер може красти монети через власний міжланцюговий мостовий контракт Rollup. Наприклад, оператор секвенсора може підробляти інструкції щодо транзакцій, переказувати активи інших людей у L2 на їх власну адресу, а потім передавати вкрадені монети в L1 через мостовий контракт, який постачається разом із Rollup. Оскільки доказів шахрайства немає, повний вузол OP не може оскаржити неправильну транзакцію, тому теоретично секвенсор OP може викрасти активи користувача в L2 (якщо він справді цього хоче).
Рішення такого роду проблеми полягає в «соціальному консенсусі» (під контролем громадської думки, наприклад членів спільноти та соціальних медіа), або **покладаючись на офіційну кредитну підтримку OP. **
Цікаво, що біржа нещодавно зменшила затримку для користувачів Arbitrum і Optimism для передачі монет на біржу (зі 100 блоків L2 до 1 блоку L2), що фактично означає віру в те, що секвенсори ARB і OP не зроблять зла** (за замовчуванням це централізовані сервери з офіційним схваленням)**.
На відміну від оптимістичного Rollup, на додачу до повних вузлів L2, ZK Rollup вирішує проблему шахрайства секвенсора через Validity Proof (часто плутають із ZK Proof). У мережі ZK Rollup є вузол під назвою Prover, який призначений для створення доказів дійсності для пакетів транзакцій, виданих секвенсором. У той же час існує контракт (зазвичай званий Verifier) на L1, який спеціально перевіряє сертифікат дійсності.Поки пакет транзакцій і сертифікат, що відповідає Stateroot/State diff, проходять перевірку контракту Verifier, він буде завершений (Finalized). Офіційний міст ZK Rollup випускатиме лише транзакції зняття коштів, підтверджені сертифікатом дійсності, який, очевидно, набагато надійніший за Optimism.
Теоретично безпека OP Rollup гарантується повними вузлами L2 (принаймні один чесний вузол, який може видавати докази шахрайства). Безпека ZK Rollup гарантується контрактом Verifier на L1 (транзакція остаточно підтверджується вузлом L1). На перший погляд, усі вони можуть «успадкувати безпеку L1» (за допомогою L1 для завершення остаточного підтвердження/розрахунку транзакції), а максималісти Ethereum навіть називають це «еквівалентом безпеки L1» (що відповідає остаточності результатів транзакцій L1), але насправді це не так, або навіть далеко від цього.
Ті "кліше" пункти
По-перше, ZK Rollup швидкість генерації підтвердження дійсності надзвичайно низька, секвенсор може виконати тисячі транзакцій за 1 секунду, але для створення підтвердження для цих тисяч транзакцій може знадобитися щонайбільше кілька годин. Але цю проблему також легко вирішити. Основний ZKR по суті розділяє завдання генерації доказів і надсилає їх на різні вузли Prover для паралельної обробки, щоб значно збільшити швидкість генерації доказів.
По-друге, необхідно враховувати затримку публікації даних вузлами L2 у L1. Тому що кожного разу, коли секвенсор або перевірка надсилає дані на L1, буде фіксована вартість (наприклад, для кожної відправки витрачається контейнер). Часта публікація даних на L1 є нерентабельною або навіть збитковою, тому секвенсор і перевірка мінімізують частоту публікації даних на L1, а потім пакують і випускають велику кількість даних за один раз.
Іншими словами, коли кількість користувачів недостатня, а кількість ініційованих транзакцій недостатня, секвенсор затримає передачу даних на L1. Наприклад, коли торік було мало користувачів, Optimism надсилав пакет транзакцій на L1 лише кожні півгодини. Зараз, оскільки кількість користувачів зросла, ця проблема була ефективно вирішена. На відміну від OP, Starknet застосував метод зменшення частоти випусків State diff, щоб зменшити витрати на дані, завдяки чому затримка остаточного підтвердження транзакції Starknet подовжується до 7-8 годин.
Крім того, більшість ZK Rollups часто «збирають багато доказів і надсилають їх на L1 одночасно», щоб ще більше зменшити витрати. Тобто Prover не надсилатиме L1 відразу після створення Proof, а чекатиме, доки буде згенеровано кілька Proofs, об’єднає їх разом, а потім надішле до контракту Verifier L1. (Насправді процес агрегування доказів полягає у використанні одного доказу для включення кроків обчислення, згенерованих перевіркою кількох доказів)
Наслідком цього є те, що частота випусків Proof ще більше зменшується, а затримка від ініціації транзакції до остаточного підтвердження ще більше подовжується.
За даними Block Explorer, **затримка підтвердження транзакції **Polygon ZKEVM становить приблизно 30-50 хвилин, а Starknet і Zksync Era – більше 7 годин. **Очевидно, що це лише «часткове успадкування безпеки L1», яка далека від «еквівалента безпеки L1», як кажуть прихильники Ethereum.
Звичайно, всі вищезазначені проблеми можуть бути вирішені завдяки технічному прогресу, і вони будуть реалізовані в найближчому майбутньому. Наприклад, багато учасників проекту розробляють високопродуктивне апаратне забезпечення, щоб скоротити час генерації доказів дійсності; Optimism також обіцяє незабаром випустити систему захисту від шахрайства; рішення Ethereum Danksharding зменшить вартість даних Rollup у десятки разів або навіть більше, що може ефективно вирішити проблеми, перелічені вище.
Важко розв'язати проблему "правління людини".
Подібно до таких проектів додатків, як Defi, робота мережі Rollup залежить від відповідних контрактів на L1, і ці контракти є «оновлюваними», що означає, що деякі коди можна замінити (більшість Rollups використовують проксі-контракти), і їх можна виконати негайно за авторизацією мультипідпису або комітету безпеки. Дозвольте мені спершу поговорити про висновок: **Зведення може швидко змінити код контракту на L1 за допомогою мультипідпису або комітету безпеки, який контролюється кількома людьми, а потім викрасти активи користувача. **
Перш за все, «чому контракт Rollup потрібно оновити» і «як це оновлюється». Код контракту на Ethereum не можна змінити після розгортання, але Rollup неминуче має різні помилки під час процесу розробки, які можуть призвести до неправильних результатів; у той же час Rollup також проходить часті ітерації продукту, і нові функції потрібно часто додавати; у більш екстремальних випадках можуть бути хакери, які атакують контракт Rollup, тому контракт Rollup потрібно оновлювати, що часто досягається за допомогою проксі-контрактів.
Проксі-контракт насправді є методом, який зазвичай використовується в розробці контрактів Ethereum, який полягає в тому, щоб відокремити дані контракту від бізнес-логіки та зберегти їх у різних контрактах. Дані (змінні стану) зберігаються в проксі-контрактах, а бізнес-логіка (функції) зберігається в логічних контрактах. Проксі-контракт (Proxy) довіряє процес виконання функції логічному контракту (Implementation) через delegatecall, а потім повертає кінцевий результат абоненту (Caller).
Щоб оновити контракт у режимі проксі, вам потрібно лише вказати проксі-контракт на новий логічний контракт (переписати адресу логічного контракту, що зберігається в проксі-контракті). **Більшість проектів Rollup прийняли цей метод оновлення контракту, який можна описати як простий і грубий. **
Неважко уявити, що Контракт Rollup може бути оновлений — це справді величезний грім: якщо оновлений контракт містить шкідливий код, наприклад зміна умов випуску зняття вбудованого мостового контракту Rollup або зміна умов контракту Verifier для визначення дійсності та підтвердження правильності, секвенсер може вкрасти монети (принцип згадувався раніше).
Але проблема в тому, що контракт Rollup не може бути оновлений. Причина дуже зрозуміла. Загалом, переважна більшість Rollup вирішить, чи оновлювати контракт Rollup за допомогою управління DAO, комітету з безпеки або авторизації за допомогою мультипідпису. Крім того, блокування часу Timelock використовуватиметься для встановлення періоду затримки для оновлення контракту.
Враховуючи, що більшість пропозицій DAO мають автоматизований процес виконання (реалізований через контракти в ланцюжку), навіть якщо контракт потрібно оновити, спочатку потрібно отримати достатню кількість голосів, а потім операція оновлення контракту буде виконана лише після затримки, визначеної блокуванням часу (часто багато днів). Якщо хтось хоче брати участь у зловмисному оновленні контракту, йому потрібно подолати керування DAO за допомогою атак на управління (наприклад, атак на управління, які відбулися на Tornado Cash), але вартість цього дуже висока, і вони повинні спочатку отримати достатню кількість токенів, що не вдасться за звичайних обставин. Навіть якщо атака управління буде успішною, завдяки блокуванню часу користувачі матимуть достатньо часу, щоб вивести активи з L2, а **офіцери Rollup матимуть достатньо часу, щоб вжити екстрених заходів. **
Схоже, блокування часу є чарівною зброєю проти зловмисного оновлення контракту. Але проблема полягає в тому, що так звані "надзвичайні заходи, які можуть вжити офіційні особи Rollup" фактично обходять керування DAO і блокування часу та негайно оновлюють контракт Rollup через мультипідпис або авторизацію комітету безпеки. З огляду на те, що поточний основний Rollup містить мільярди доларів у активах користувачів, «негайне оновлення контракту», дозволене комітетом із мультипідпису та безпеки, є крайнім надзвичайним заходом, але це також дамоклів меч, що висить над головами всіх користувачів.
Очевидно, це питання максимізації довіри: ви повинні вірити, що співробітники Rollup не матимуть думки про крадіжку ваших активів. Якщо розглядати це з точки зору Trustless (точка зору Ніка Сабо), **усі зведені пакети, які контролюються комітетами з мультипідпису та безпеки, небезпечні. **Емін Ган Сірер, засновник Avalanche, Анатолій, засновник Solana, і Джастін Бонс, відома сонячна пляма, усі наголошували на цій проблемі.
Якими зведеними пакетами маніпулюють мультипідписи/комітети?
Відповідно до звіту «Можливість оновлення Ethereum L2», опублікованого відомою науково-дослідною установою рівня L2 L2 BEAT і веб-сайтом візуалізації даних L2BEAT, **Arbitrum, Optimism, Loopring (Loopring), ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM та інші основні зведені пакети мають багатопідписні або авторизовані комітетом контракти на оновлення та можуть обійти час. обмеження блокування. **
Хоча dYdX має адресу EOA, яка може обійти договір про оновлення управління DAO, вона обмежена блокуванням часу (принаймні 2 дні затримки). Immutable X має 14-денну затримку оновлення контракту. Тому, згідно з L2BEAT, **dYdX і Immutable X є більш ненадійними, ніж інші основні зведені пакети, які запустили основну мережу. **
**Тож як зменшити ризик довіри, пов’язаний із мультипідписом і комітетом безпеки? **Відповідь насправді схожа на інцидент Multichain: її можна віднести до проблеми боротьби з відьмами. Необхідно переконатися, що multisigs/комітети контролюються декількома різними організаціями без високого ступеня збігу інтересів і низького ризику змови. Наразі здається, що немає іншого хорошого способу, окрім як підвищити зрілість децентралізованого управління DAO та запросити відомих і авторитетних знаменитостей або інституцій до участі в багатопідписному комітеті. Наведений вище сценарій, здається, був поширеним у реальних демократіях.
Звичайно, також можна обмежити поведінку оновлення контракту, керовану мультипідписом/комітетом, за допомогою блокування часу, але це потрібно зважити з багатьма факторами, оскільки мета мультипідпису/комітету полягає в швидкому вирішенні деяких надзвичайних ситуацій; водночас, якщо сторона проекту Rollup не має твердого рішення щодо питання надійності, цю проблему неможливо вирішити.
Тому, незважаючи на те, що різні проекти Rollup можуть гарантувати безпеку активів користувачів більшу частину часу завдяки складній конструкції механізму, ймовірність події «чорний лебідь» у Rollup не дорівнює нулю через існування кількох підписів і комітетів. Навіть якщо ймовірність змови між кількома підписами та членами комітету становить лише 1 на 10 000, враховуючи вартість активів, що перебувають на зберіганні L2 (передбачається, що це 10 мільярдів доларів США), ризик активів користувачів L2 все одно становить 1 мільйон доларів США на день. Нагадує інцидент із Multichain, це справді моторошно.
Тож я особисто вважаю, що, як раніше казав Поліня, більшість коштів в екосистемі Ethereum все одно матимуть тенденцію циркулювати та замикатися в L1, а не в L2, а екосистема Rollup не зможе охопити більшу частину вартості в екосистемі Ethereum у довгостроковій перспективі. Для великих інвесторів і китів основна мережа Ethereum, очевидно, є більш придатним і надійним місцем для отримання коштів, ніж L2. Тому багато людей розмірковували над тим, «чи призведе зростання L2 до дезертирства L1», насправді у них вже є відповідь.
Як сказав Кейго Хігасіно у своїй книзі, людське серце набагато невловиміше, важче зрозуміти, складніше та важче змінити, ніж математичні формули. Багато речей не можна вирішити суто технічними засобами, але будь-який фактор, пов’язаний із «людською природою», завжди буде найбільш неконтрольованою, непередбачуваною та найсерйознішою проблемою у світі. Згадаймо, будь ласка, класичне речення на надгробку Канта:
«Дві речі завжди оточують мою думку, і чим більше я думаю про них, тим більше подиву й благоговіння вони викликають у мене: моральний закон усередині та зоряне небо над головою».