Ця публікація є перекладом від одного з амбасадорів Oasis.
Ми проводимо суворі перевірки для збереження точності перекладу, однак в текстах все ж можуть зустрічатися помилки та невідповідності. Oasis не несе відповідальності за точність або надійність перекладу. З оригінальною статтею можна ознайомитись за посиланням.
Єдиний блокчейн із вбудованою підтримкою Rollups на рівні консенсусу.
Layer-2 рішення для масштабування еволюціонували від “sidechains” до “commitchains”, “rollups” і мостів-валідаторів. «Rollup» означає запуск віртуальної машини зі смарт-контрактами (VM), в якій стан віртуальної машини періодично перевіряється та фіксується в базовому ланцюжку блоків. Це робиться задля того щоб забезпечити функціональність смарт-контракту з меншими витратами та вищою пропускною здатністю на відміну від запуску смарт -контрактів безпосередньо на базовому блокчейні. Перевірка, що виконується в базовому ланцюжку блоків, забезпечує надійність переходів між станами, а обчислення поза блокчейном дозволяють масштабувати виконання смарт-контрактів.
Ми не називали їх rollup’ами, але саме так працює ParaTimes, або як його ще називають, обчислювальний рівень Oasis Network.
З самого свого заснування Oasis Network відокремлювала обчислення від консенсусу в якості модульного принципу проектування. Цей поділ означає, що об’єкти рівня ParaTime обробляють лише виконання смарт-контрактів, а об’єкти рівня консенсусу обробляють лише консенсус. Перше та друге значно полегшує роботу. Такий поділ має багато переваг, зокрема: простота аудиту, ізоляція помилок та зменшення реплікації обчислень без шкоди для безпеки. Поділ, тобто виконання обчислень у (rollup) віртуальній машині, а також перевірка результатів і збереження логів в блокчейні — це і є основна суть rollup’ів.
Oasis Network — це не просто мережа, що підтримує rollups з самого свого початку. Справа у тому, що архітектура проекту оптимізована для rollups і тільки rollups: вона не рекомендує проводити загальні обчислення на рівні консенсусу і дозволяє виконувати там тільки вбудовані контракти. Ці вбудовані контракти є validating bridge контрактами мовою rollups. У той час як цілі проектування архітектури Oasis полягали в модульному підході для Layer-1 блокчейну, який підтримує смарт-контракти, можна стверджувати, що результатом модульності стало те, що рівень консенсусу Oasis став блокчейном з подтримкою тільки rollups. Якщо дивитися через призму rollups, то всі ParaTimes є віртуальними машинами Layer-2.
Зокрема, перевірочний міст Oasis на рівні консенсусу використовує метод захисту від шахрайства, який називається «виявленням невідповідності». Цей метод необхідний для того щоб підтвердити результати з рівня обчислень. Ця техніка, що виникла в результаті виявлення шахрайства та спільного проектування архітектури системи, використовує “bare metal proofs”, які є простими і, таким чином, більш надійними, оскільки мало що тут може піти не так. Як ми побачимо, простота “bare metal proofs” перевірок дає розробникам ParaTime більше простору. Наприклад, стає можливою реалізація середовища виконання смарт-контрактів, у якій смарт-контракти містять рідний код із «пісочницями». А це дає системі запас підвищеннямииимс продуктивності порівняно з паралельним виконанням ParaTime.
Можна також сказати, що Oasis Network— це перша мережа, що підтримує rollups з самого початку. І що номенкулатура “Layer 1”/“Layer 2” недостатньо точна для відображення повного змісту понять.
Назвіть це конвергентним дизайном. Давайте розглянемо, що це означає, і розглянемо деякі деталі.
Властивості rollups
Rollups були розроблені в основному для прискорення обробки смарт-контрактів на базі Ethereum. Точніше, вони були розроблені для виконання смарт-контрактів Ethereum, але в окремій, незалежній віртуальній машині, відмінній від Ethereum Layer-1 “base chain”. Зроблено це було щоб зменшити робоче навантаження у Layer-1. Все реальне виконання контракту здійснюється на Layer-2 rollup virtual machine. Єдина робота, яку виконує базовий блокчейн— це валідація роботи rollup virtual machine за допомогою смарт-контракту “validating bridge”. Зазвичай rollup virtual machine також є екземпляром EVM. А в деяких проектах, як от Arbitrum, rollup virtual machine налаштована таким чином, щоб спростити валідацію в базовому чейні. Поки валідація на Layer-1 дешевша, ніж запуск зведених смарт-контрактів безпосередньо на Layer-1, ми маємо приріст ефективності, оскільки виконання Layer-2 рішень має бути дешевшим. Це суть того, як за допомогою rollups відбуваеться масштабування пропускної здатності транзакцій.
Зауважте, що поверх Layer-1 блокчейну може бути багато віртуальних машин Layer-2. Немає жодних архітектурних обмежень, крім пропускної здатності Layer-1 в плані валідації . Чим ефективніший validating bridge contract та чим менше навантаження на виконання non-bridge смарт-контрактів на Layer-1, тим більше rollups може підтримуватися. Очевидно, у rollup’і також може бути перевіряючий bridge-type контракт, але для такої рекурсії є обмеження, які ми тут не будемо розглядати.
Більшість rollup’ів спочатку передають дані транзакції в базовий чейн, а потім фіксують результуючий стан rollup virtual machine в наступній транзакції. Це забезпечує остаточність замовлення транзакції і певним чином вирішує проблему доступності даних, оскільки стан rollup virtual machine може бути відновлено з даних транзакції за ціною повторного виконання всіх транзакцій з моменту дефолтного стану rollup virtual machine. Валідаційні мости можуть бути більш загальними, із off-chain сховищем стану, яке можна перевірити за допомогою доказів Merkle. Тому можливе окреме рішення щодо доступності даних, наприклад, дані транзакції можна криптографічно підсумувати так само, як стан віртуальної машини, зменшуючи витрати на зберігання Layer-1, відокремлюючи доступність даних від достовірності за допомогою off-chain сховища даних. Тут ми бачимо деякий компроміс по валідації адже тимчасова проблема пропускної здатності (оскільки доступ до необхідних для верифікації вхідних даних може бути повільним ) може затримати валідацію.
Спосіб, яким rollup’и виконують перевірку віртуальної машини, має дві форми:
- Optimistic rollups там, де заявлений результат виконання публічно публікується та потенційно оскаржується.
- zk rollups там, де SNARK використовуються для побудови proof of correctness.
Ключова відмінність полягає в тому, що Optimistic rollups використовують «fraud proofs», коли претенденти збирають докази щоб довести, що заявлений результат виконання є неправильним або шахрайським. А zk rollups використовують «validity proof», який виконавці публікують разом із станом rollup virtual machine, після чого validating bridge смарт-контракт перевіряє правильність доказу. В обох випадках потрібен час:
- Щоб дозволити іншим учасникам побачити новий стан і або виявити, що стан неправильний і створити докази шахрайства у випадку з optimistic rollups.
- або, у випадку з zk rollups, виконати proof verification алгоритм щоб відхилити доказ, якщо він неправильний.
Хоча це може здатися незначною відмінністю, в обох випадках потрібно попрацювати щоб створити доказ шахрайства або перевірити, чи є доказ достовірності правильним. Різниця полягає в тому, що зазвичай докази шахрайства передбачають повторне виконання транзакцій, тоді як перевірка достовірності має бути дешевшою за рахунок використання криптографічних методів (probabilistically checkable proofs; SNARKs). На практиці криптографічні методи включають значні накладні витрати і (поки що) не узагальнюються на довільне виконання смарт-контракту.
Зауважте, що загалом rollup virtual machine не обов’язково повинна бути сумісна з Ethereum, а також механізм перевірки не повинен працювати поверх Ethereum. Підійде будь-який децентралізований обчислювальний субстрат, розширивши його безпеку до rollup virtual machine. Звичайно, якщо rollup virtual machine сумісна з Ethereum, це робить перенесення існуючого EVM коду досить тривіальною задачею.
Особливості Fraud Proofs
Щоб зрозуміти, чому виявлення шахрайства в мережі Oasis і спільне проектування архітектури системи привели до більш ефективної, більш загальної схеми, спочатку потрібно обговорити різні види доказів шахрайства.
Simulation Proofs
Принцип роботиoptimistic rollups, таких як Arbitrum і Optimism, полягає в тому, що претенденти, які стверджують, що обчислення неправильні, повинні надати докази шахрайства. Доказ шахрайства має показати, що обчислення, які привели до неправильного підсумкового стану, відрізнялися від правильного виконання віртуальної машини в одній інструкції VM. Це можна «легко» перевірити за допомогою симулятора rollup virtual machine, що працює на базовому чейні.
Це непросто. Це навіть надзвичайно складно. Це тісно поєднує набір інструкцій rollup virtual machine з реалізацією validating bridge контракту. Ключ до можливості перевірити виконання полягає в тому, щоб не моделювати повне виконання rollup virtual machine, оскільки це було б надзвичайно дорого в плані плати за газ. Замість цього претендент повинен надати незаперечні докази того, що виконавець стверджує про стан вихідної rollup virtual machine, вказуючи на точну інструкцію VM, яка не була виконана належним чином, використовуючи розділення навпіл, порівнюючи стани виконання та Merkle proofs. Побудову підтвердження можна виконати в автономному режимі і лише перевірку потрібно виконати в режимі онлайн, шляхом перевірки мостового контракту шляхом валыдації, чи справді виконання вказаної інструкції VM не відповідає семантиці VM.
Щоб це спрацювало, validating bridge контракт повинен мати можливість імітувати будь-яку інструкцію rollup virtual machine. Забезпечити правильність симулятора та його семантичну еквівалентність фактичній rollup virtual machine є технічно складним завданням. Хоча складність симулятора залежить від складності набору інструкцій virtual machine, для створення точного і надійного симулятора, ймовірно, знадобиться багато часу, як у випадку з Arbitrum і Optimism.
Очікується, що претендент, який стверджує про шахрайство, надасть докази шахрайства разом із новою заявою щодо правильного стану результату. Якщо шахрайська транзакція F відхиляється від правильнго шляху виконання в якийсь момент t_0, претендент може побудувати шлях виконання C, який розходиться з правильним шляхом на деякому наступному етапі часу t_1> t_0, і надати доказ шахрайства, який успішно скасовує F, але сам по собі є шахрайським результатом. Таким чином, підтвердження шахрайства проти F не доводить, що C є правильним, і успішний виклик з іншим результатом повинен скинути годинник подання виклику, щоб C можна було оскаржити. Успішний виклик не є переконливим доказом того, що результат, пов’язаний із C, є правильним без додаткової перевірки іншими верифікаторами.
Bare Metal Proofs
Схема «bare metal proofs» полягає у наступному:
- Доказ повинен бути міцним. Докази можуть мати імовірнісний характер (наприклад, ZKPs) з можливістю вибору параметрів безпеки, щоб ймовірність помилки була настільки близькою до нуля, наскільки це необхідно.
- Доказ повинен працювати з будь-якою (детермінованою) віртуальною машиною без специфічних для машини адаптацій, включаючи віртуальні машини, які є простими розширеннями звичайних архітектур набору інструкцій, таких як x86–64. Схема повинна дозволяти запускати двійкові файли нативного коду в пісочниці (з обмеженнями, щоб уникнути недетермінованої поведінки) на повній, «bare metal», швидкості з розширеннями інструкцій блокчейна в якості запитів функцій.
Ці вимоги означають, що система, заснована на доказах шахрайства, буде набагато простішою, ніж система, заснована на доказах моделювання. Validating bridge контракт не потребує доступу до стану rollup virtual machine оскільки перевірка стану вимагає знання типу структур даних Merklised, які використовуються та способів їх перевірки, що залежить від rollup virtual machine. Це призведе до необхідності інтерфейсів/механізми, які дозволяють базовому блокчейну мати доступ до стану rollup’а та зробить інтерфейси модулів більш складними. Крім того, не потрібне моделювання на рівні інструкцій, специфічне для virtual machine. Уникнення (непотрібної) складності є важливою безпековою метою, оскільки складність породжує помилки.
Вимагаючи, щоб схема захисту від шахрайства була більш загальною, ми послаблюємо обмеження на дизайн rollup virtual machine. Хоча ми можемо продовжувати писати смарт-контракти мовою, яка компілюється в байт-код і використовує інтерпретатори байт-коду як віртуальну машину (що полегшує виконання одного кроку та збирання трасування виконання Merklised), ми більше не обмежені цим підходом. Можна застосувати більш просунуті та ефективні методи, щоб отримати величезний запас для підвищення ефективності смарт-контрактів. Наприклад, інструкції/байт-коди віртуальної машини можуть бути скомпільовані в машинний код для запуску в програмному середовищі ізольування помилок програмного забезпечення (SFI) (наприклад, RLBox), досягаючи майже рідної продуктивності коду.
Oasis ParaTimes
У випадку з Oasis, відокремлення виконання смарт-контрактів від консенсусу означало, що ми зупинилися на rollup-style дизайні. Існує EVM-сумісний ParaTime, Emerald ParaTime, серед інших, які запускають смарт-контракти на основі Rust, усі з яких використовують єдиний, вбудований, об’єктно-орієнтований смарт-контракт для перевірки. Жодні інші блокчейни не обмежують базовий чейн запуском лише зведених контрактів на перевірку.
Discrepancy Detection Fraud Proofs
Раніше ми вже згадували, що Oasis виконує лише вбудовані контракти перевірки на рівні консенсусу. На даний момент це «bare metal» fraud-proof style validating bridge, де ми використовуємо техніку під назвою «discrepancy detection» для виявлення шахрайства і, якщо воно виявлено, «discrepancy resolution» для його усунення. Ключова ідея «discrepancy detection» полягає в тому, що ми можемо бути більш ефективними у виявленні шахрайства, ніж у виправленні шахрайства, подібно до того, як додаткові надлишкові біти в теорії кодування можуть бути використані для виявлення більшої кількості помилок, ніж вони можуть виправити. Якщо вони демонструють незалежність від збоїв, супротивник, який скомпрометує один вузол виконання, не допомагає їм скомпрометувати інші, наприклад, підкупляючи оперативний персонал, вгадуючи їхні паролі тощо, ми можемо використовувати менші обчислювальні комітети, де ми вимагаємо, щоб усі прийшли до одного результат виконання смарт-контракту.
Практична безпека цієї конструкції легше зрозуміти. Дизайн на основі комітетів забезпечує загальновідомий параметр безпеки, розмір комітету, який виконує контракти напівсинхронізовано, так що користувачі знають кількість перехресних перевірок, а також знають, коли перехресні перевірки будуть завершені. Члени комітету мають SLA і можуть бути скорочені через недоступність. Це контрастує з optimistic rollups, коли користувач фіксовану кількість часу чекає на невідому кількість потенційних претендентів або самостійно перевіряє обчислення. Зауважте, що дизайн не перешкоджає подавати докази шахрайства членам, які не є членами комітету, і навіть «пізні» докази шахрайства від не членів комітету можна обробляти (дивіться розділ Checkpointing у цій статті нижче) адже перевірка не закрита.
Коли виникає розбіжність, виконується етап вирішення/відновлення невідповідності. Для напівсинхронних результатів комітету ми негайно запускаємо більший комітет, щоб з’ясувати, який результат правильний. Розмір цього комітету з питань резолюції набагато більший. Наприклад, рішенням може керувати весь консенсусний комітет — тож у цьому результаті можна бути впевненим. Хоча це дорожче з точки зору повторюваних обчислень і комунікацій, це не проблема. Це має відбуватися вкрай рідко і вартість в переважній більшості випадків амортизується за рахунок більш простих транзакцій.
Підвищення ефективності пояснюється застосуванням оптимізації швидкого/повільного шляху в проектуванні систем. Ймовірний випадок відсутності шахрайства/відсутності розбіжностей обробляється ефективно, а малоймовірний випадок невідповідності з двох чи більше невідповідних результатів може бути повільнішим. Подробиці про параметри безпеки дивіться тут.
Рівень консенсусу Oasis Network не запускає загальні смарт-контракти. Замість цього ми використовуємо функціональні validating bridge, які в іншому випадку реалізуються як смарт-контракт у rollup’і на основі Ethereum. Ми використовуємо виявлення розбіжностей для перевірки результатів із вузлів обчислювального (ParaTime) рівня, оскільки це є більш ефективним.
Щоб зрозуміти, чому виявлення розбіжностей ефективніше, давайте розглянемо очікувану кількість часу, яка необхідна для того, щоб випадковий вибір членів обчислювального комітету дозволив супротивнику скомпрометувати обчислення. Якщо із загальної кількості 100 кандидатів 33 є скомпрометованими, і ми випадковим чином обрали 20 для роботи в якості обчислювального комітету, навіть якщо нові композиції будуть відібрані зі швидкістю 100 000 на годину, супротивник, який контролює ці 33 скомпрометовані вузли, повинен був би зачекати 1066 років, перш ніж буде обраний повністю скомпрометований комітет, який може бути використаний для атаки на систему. Звичайна схема відмовостійкості може використовувати 100-сторонню реплікацію для досягнення консенсусу, тут ми повторюємо обчислення лише 20 разів.
Деталі технічного аналізу для розрахунків і чому виявлення розбіжностей є ефективнішим можна знайти в додатку до нашої технічної документації.
Оскільки виявлення розбіжностей порівнює лише результати обчислень, воно є більш загальним, ніж будь-яка схема, яка вимагає порівняння проміжних станів за допомогою одноетапного виконання. Підхід, який використовується в більшості optimistic rollups. Робота, яку необхідно виконати discrepancy detection validating bridge контракту, це виявлення розбіжностей на рівні консенсусу. Вона невелика, що дозволяє легко масштабувати систему, запускаючи кілька ParaTimes одночасно для паралельного виконання.
Розширюваність на інші схеми підтвердження шахрайства/дійсності
Зауважте, що в той час як рівень консенсусу Oasis Network використовує виявлення невідповідностей, його архітектурна може бути розширеною. Це може дозволити реалізувати інші методи перевірки виконання rollup’ів. Але ми поки що не бачимо в цьому потреби.
Якщо/коли схеми підтвердження zk-rollup достатньо виростуть для загальних обчислень, перевірка zkSNARK буде чудовим доповненням. Оскільки вбудовані validating bridges реалізовані на Go, вони також повинні працювати набагато швидше, ніж смарт-контракти Solidity.
Є значно більше варіацій/вимірів у просторі захисту від шахрайства, які ми тут не розглянули. Додаткову інформацію про дизайн систем протидії шахрайству можна отримати за посиланням.
Checkpointing
Виявлення невідповідностей дозволяє нам встановити параметр розміру комітету, щоб бути впевненим, що ймовірність того, що весь комітет буде скомпрометовано, є незначною. Залишаються два питання:
- Discrepancy Detection — якщо це зроблено лише для обчислювального комітету, воно не є повністю відкритим, оскільки для кваліфікації як кандидата на обчислювальний вузол необхідні обмеження у вигляді застейканих текенів, щоб запобігти атакам типу Sybil.
- Common-Mode Failures, такі як помилки в коді Oasis Network або ядрі Linux, можуть дозволити зловмиснику використовувати компроміс нульового дня, щоб скомпрометувати всі ноди обчисленнь та консенсусу.
Зауважте, що занепокоєння щодо багів у коді існує стосовно будь-якої мережі і аж ніяк не є унікальним для Oasis. Ми вважаємо, що якість коду Oasis і процеси перевірки є одними з найкращих у своєму класі.
Впоратися з zero-day вразливостями важко. Дійсно, як і всі програмні системи, жоден блокчейн не має простого рішення, крім можливого хардфорка. У Oasis ми вирішуємо катастрофічні збої як то надзвичайно малоймовірні сценарії, такі як компрометація у всіх комітетах, використання вразливостей нульового дня / збої в звичайному режимі тощо — шляхом розрізнення визначення замовлення транзакції та визначення результату транзакції та дозволяючи будь-кому оскаржити результати транзакції.
Що це значить? Ми додаємо безпечне ведення журналу періодичних хешів контрольних точок стану та упорядкування транзакцій. Ці дані дозволяють легко відтворювати транзакції з завідомо справної контрольної точки після того, як катастрофічний збій буде виявлено за допомогою виклику та усунено.
Створення логів повинне бути монотонною роботою / мати остаточність, оскільки ми включаємо атаки на великі відстані / втрату контролю над криптографічними ключами як потенційні режими збою. Цієї властивості можна досягти шляхом запису логу в розподілені реєстри лише для додавання, такі як інший блокчейн, наприклад, Ethereum; шляхом запису на фізачний носій:
- на принтер безперервної подачі,
- шляхом запису на носій для одноразового запису (CD-R/DVD-R),
- шляхом запису на носій, який періодично копіюється в автономні служби резервного копіювання
Запис в Ethereum використовуватиме остаточність Ethereum для позначки часу створення запису журналу, тоді як запис в інші механізми потребуватиме перевірки. Це можна зробити шляхом порівняння незалежних копій щоб переконатися, що носій не є новою, а зміненою копією легітимного логу. Перегляньте документ під назвою «Shades of Finality» (невдовзі буде опубліковано) для більш детального розуміння остаточності замовлення транзакції та остаточності значення стану.
Коли це буде завершено, будь-хто може оскаржити результати обчислювального рівня. Навіть після того, як виявлення розбіжностей прийме результати. Це означає, що якщо вчасно виявити катастрофічні збої, такі як повністю скомпрометований комітет або вразливість нульового дня, їх можна швидко виправити. Поки існує дійсна контрольна точка стану, яка передувала катастрофічному збою, ми маємо відомий стан, який можна використовувати як основу для відновлення.
Рекомендована політика для обробки катастрофічних збоїв — виконувати замовлення транзакції. Це означає, що якщо претендент покаже, що відбувся неправильний перехід стану, ми можемо відтворити зареєстровані транзакції, надіслані після відомого справного стану, щоб обчислити правильний поточний стан, використовуючи стільки реплікації/перевірки, скільки для цього необхідно. Подібно до виявлення розбіжностей, що забезпечує ефективний швидкий шлях для випадку відсутності розбіжностей у порівнянні з більш дорогою схемою для рідкісного випадку, коли виявляється розбіжність, контрольна точка та повтор для відновлення після катастрофічних збоїв можуть бути дорогими, оскільки очікується, що такі катастрофічні збої будуть надзвичайно малоймовірними.
Висновки
Архітектура Oasis Network стала результатом злитя підходів по виявленню шахрайства та архітектурою системи. Існує модульне розділення обов’язків між обчислювальним і консенсусним рівнями, а інтерфейс між ними складається з простої та ефективної схеми захисту від шахрайства.
Переваги дизайну Oasis:
- Чиста, модульна архітектура, що робить дизайн легшим для розуміння, ніж монолітні дизайни. Модульність також перетворюється на більш чисті сценарії використання, що полегшує аудит безпеки.
- Ефективне виявлення шахрайства з явними параметрами безпеки, які дозволяють розробникам ParaTime вибирати відповідні параметри для потрібних їм сценаріїв використання.
- Докази шахрайства дають змогу в майбутньому розробляти високопродуктивні середовища виконання смарт-контрактів, такі як власний код із пісочницею, що робить можливим створення обчислювальних та високонавантажених смарт-контрактів в майбутньому.
- Користувачі знають нижню межу кількості незалежної перевірки, а не сподіваються, що валідатори були доступні/працювали протягом періоду виклику, як у випадку з optimistic rollups.
В результаті Oasis Network — це rollup-style блокчейн, де рівень консенсусу виконує лише перевірку bridge-контрактів. Кілька ParaTimes, незалежних rollup virtual machines, були успішно розгорнуті поверх рівня консенсусу Oasis. Наразі Emerald ParaTime забезпечує виконання EVM-сумісних смарт-контрактів, а Cipher ParaTime надасть конфіденційне середовище виконання смарт-контрактів, після виходу в першому кварталі 2022 року.