Особлива подяка Карлу Флершу за відгук і рецензію

Екосистема рівня 2 Ethereum стрімко розширювалася протягом останнього року. Зведена екосистема EVM, яка традиційно включає Arbitrum, Optimism і Scroll, а нещодавно Kakarot і Taiko, швидко розвивається, досягаючи значних успіхів у покращенні своєї безпеки; сторінка L2beat добре підсумовує стан кожного проекту. Крім того, ми бачили, як команди, які створюють сайдчейни, також починають створювати зведені проекти (Polygon), проекти рівня 1, які прагнуть стати валідіумами (Celo), і абсолютно нові зусилля (Linea, Zeth…). Нарешті, існує не просто екосистема EVM: «майже-EVM», як-от Zksync, розширення, як-от Arbitrum Stylus, і ширші зусилля, як-от екосистема Starknet, Fuel та інші.

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

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

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

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

Зведення проти валідіумів та відключених систем

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

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

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

https://s3.ap-northeast-1.amazonaws.com/gimg.gateimg.com/learn/b05ca283dcc74f262ac7a71f340dc85fb3a13b11.png

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

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

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

1. Вартість доступності нативних даних Ethereum, яка з часом зменшуватиметься в міру вдосконалення технології. Наступний хардфорк Ethereum, Dencun, представляє EIP-4844 (він же «proto-danksharding»), який забезпечує доступність даних у мережі ~32 КБ/с. Очікується, що протягом наступних кількох років це буде збільшуватися поетапно, оскільки <a href="https://hackmd.io/@vbuterin /sharding_proposal">розгортатиметься повне розгортання данкшардінгу, зрештою цільовим показником буде близько ~1,3 МБ/с доступності даних . Водночас удосконалення стиснення даних дозволить нам робити більше з тим самим обсягом даних.
2. Власні потреби програми: наскільки користувачі постраждають від високих комісій, а не від того, що щось у програмі піде не так? Фінансові програми втратили б більше через помилки програм; Ігри та соціальні медіа передбачають велику кількість активності на користувача та відносно малоцінну діяльність, тому для них має сенс інший компроміс безпеки.

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

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

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

Недовірливо читає Ethereum

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

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

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

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

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

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

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

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

Чи робить вас наявність мосту валідіумом?

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

Поки що ні! З двох причин:

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

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

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

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

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

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

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

Чи достатньо цього? Як виявилося, все ще ні, через кілька невеликих крайніх випадків:

1. Що станеться, якщо Ethereum отримає 51% атаки?
2. Як ви обробляєте оновлення хардфорку Ethereum?
3. Як ви справляєтеся з модернізацією жорсткої вилки вашого ланцюга?

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

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

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

Висновки

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

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

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

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

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

Відмова від відповідальності:

1. Ця стаття передрукована з [Віталік Бутерін]. Усі авторські права належать оригінальному автору [Віталік Бутерін]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.