Впровадження Біткоїн-безпеки в тисячах рол-апів

BTC – актив з найбільшою ринковою капіталізацією, але більша його частина незадіяна. Нещодавно команда Babylon запропонувала ідею стейкінгу BTC, яка дозволяє власникам вкладати свої незадіяні BTC, щоб підвищити безпеку ланцюжків PoS. Команда AltLayer співпрацює з командою Babylon над створенням інфраструктури та сервісів, орієнтованих на rollup, які захищені мережею Біткоїн.

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

Чому саме децентралізована верифікація?

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

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

Щоб зрозуміти необхідність побудови децентралізованої мережі верифікації, давайте глибше розглянемо Optimistic роллапи. Optimistic ролапи є безпечними за умови, що існує хоча б одна “чесна” сторона, яка перевіряє, що стан, зафіксований операторами ролапів в Ефіріумі, дійсно відповідає правильному виконанню функції переходу стану на множині транзакцій і попередньо підтвердженому стану.

Для популярних універсальних ролапів з добре розвиненою екосистемою, таких як Arbitrum One і Optimism Mainnet, може не бути явної потреби у виділених нодах-верифікаторах, оскільки деякі учасники екосистеми, такі як постачальники кінцевих точок RPC, індексатори, експлорери, біржі та інші, мають неявний стимул стежити за ролапом, оскільки їхні продукти і сервіси значною мірою залежать від належного функціонування цих ролапів.

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

Більше того, з’являється нова категорія використання шаблону optimism в смарт-контрактах Ethereum L1 – коли хтось бере на себе зобов’язання щодо результату обчислень – і тоді шахрайство може бути доведено. Іншим прикладом можуть бути ефемерні роллапи, запроваджені AltLayer, де секвенсори роллапів передають стан роллапу в Ethereum під час розрахунків, де цей стан являє собою результат позаланцюгових обчислень в роллапі для певного додатку, наприклад, Dark Forest. У таких технологіях, що працюють на вимогу, наявність децентралізованої мережі верифікаторів, які можуть виявляти і оскаржувати стан роллів, стає надзвичайно важливою.

Огляд стейкінгу BTC через протокол Babylon

Babylon – це протокол, який дозволяє користувачам стейкати свої BTC в мережі Біткоїн. Цей стейкінг BTC можна використовувати для захисту зовнішніх мереж, таких як ланцюжок PoS.

Такий стейкінг не потребує довіри і не є кастодіальним, що означає, що користувачам не потрібно переносити свої біткоїни, що б вимагало довіри до біткоїн-адрес третіх сторін.

Замість цього, користувачі віддалено вкладають свої BTC в “контракт” Taproot в блокчейні Bitcoin, самостійно контролюючи їхнє зберігання. Цей стейк може бути віддалено знищений, якщо буде виявлено будь-яку зловмисну поведінку. Процес стейкінгу BTC в Babylon дещо схожий на стейкінг ETH + рестейкінг Eigenlayer, але з BTC.

Через відсутність смарт-контрактів у ланцюжку Біткоїна не можна надсилати будь-які довільні докази порушення безпеки і покладатися на те, що Біткоїн обробить такі докази так, як це роблять роллапи Ethereum, використовуючи мостовий контракт роллапу як валідаційний міст для виявлення шахрайства або доказів дійсності. Натомість протокол дозволяє надсилати докази, які можуть безпосередньо призвести до слешингу: приватний ключ стейкера, який блокує біткоїни, що перебувають у стейкхолдері. Це робиться за допомогою використання видобувних одноразових підписів (EOTS). EOTS – це примітив підпису, де два повідомлення, підписані одним і тим же приватним ключем, дозволяють будь-кому витягти приватний ключ з двох підписів.

Простіше кажучи, зловмисна поведінка призведе до витоку приватного ключа стейкера, який потім може бути використаний для відправки BTC на burn-адресу, ефективно досягаючи слешингу.

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

Побудова децентралізованої мережі верифікаторів з використанням Bitcoin

Restaked rollups – це, по суті, набір з трьох вертикально інтегрованих активно валідованих сервісів (Active Validated Services, AVS), що створюються на вимогу для певного роллапу, який працює з будь-яким базовим стеком роллапів. У поєднанні ці AVS надають три ключові послуги для роллапів:

✨ Перевірка правильності стану ролапів

✨ Швидша фіналізація

✨ Децентралізоване секвенування

Ось докладніша публікація, яка більш детально представляє restaked rollups.

Зараз ми розширюємо фреймворк restaked rollup за допомогою стейкінгу BTC, спираючись на Bitcoin. Існує два основних підходи до побудови цього фреймворку, які ми представляємо нижче.

Побудова верифікатора на Babylon

Перший підхід полягає у створенні внутрішньоланцюгового верифікатора на ланцюжку Babylon. Верифікатор – це контракт CosmWasm, який перевіряє докази правильного виконання ролапу, щоб переконатися, що секвенсор ролапу фіксує валідні блоки. Докази правильності надаються у вигляді доказу валідності на вимогу, який генерується секвенсором при виникненні проблеми. На відміну від повного ZK-ролапу, де оператор повинен генерувати ZK-доказ для кожного окремого переходу стану, модель на вимогу вимагає ZK-доказ лише тоді, коли виникає виклик.

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

Ця архітектура захисту від шахрайства ZK може бути узагальнена та реалізована в широкому спектрі optimistic rollup SDK.

Ми реалізували контракт верифікатора в CosmWasm, який перевіряє докази валідності, згенеровані для виконання EVM, з доказами, згенерованими за допомогою RISC Zero zkVM, що дозволяє створювати докази ZK на широкому спектрі мов загального призначення, таких як Rust, WASM та RISC-V. Крім того, генерація доказів добре розпаралелюється завдяки продовженням і Bonsai, що дозволяє системі ZK досягти найкращої в галузі продуктивності та функціональності.

Побудова верифікатора як автономної мережі

Оскільки протокол Babylon дозволяє захистити будь-який ланцюжок PoS за допомогою стейкінгу BTC, замість того, щоб будувати верифікатор на ланцюжку Babylon, можна також побудувати спеціальну автономну мережу верифікаторів, яка базується на протоколі Babylon, а не на ланцюжку Babylon. Створення виділеної мережі дасть гнучкість, зокрема, в роботі з режимами виконання, для яких немає ефективних верифікаторів. У цьому режимі ланцюжок PoS може бути мережею верифікаторів, які ефективно діють як мережа повноцінних нод і перевіряють кожен стан ролапу, просто повторно виконуючи транзакції і порівнюючи отриманий стан із зафіксованим оператором ролапу. Після виконання вони досягають консенсусу щодо остаточного стану ролапу, щоб забезпечити згоду по всій мережі щодо остаточного стану.

Оригінал статті тут.