Ми живемо в мультичейн світі. Ідея про те, що всі децентралізовані програми використовуватимуть спільний блокчейн смарт-контрактів, на практиці мертва. Ethereum повертається до дорожньої карти, де програми мають власні rollup чейни, зростає популярність мультичейн екосистем, таких як Cosmos і Polkadot, а також альтернативних чейнів рівня 1, таких як Solana та Polygon. Сьогодні децентралізовані програми розкидані по різних блокчейнах.

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

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

Кросчейн комунікації вимагає компромісів щодо безпеки

Як показали Zamyatin et al., безпечне спілкування через блокчейни без довіреної третьої сторони або припущення про синхронізацію неможливе. Безпечний у цьому контексті означає атомарний. Наприклад, якщо Аліса переміщує 5 монет із чейна A до чейна B, то це передбачає дві транзакції: (1) віднімання балансу Аліси на 5 монет у чейні A та (2) збільшення його на 5 монет у чейні B. Для того щоб кросчейн комунікація була атомарною, або обидві, або жодна з цих транзакцій не має відбуватися. Якщо відбувається лише одна з цих транзакцій (наприклад, баланс Аліси віднімається в чейні A, але не збільшується в чейні B), вона не є атомарною.

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

Ми можемо вважати, що (неофіційно) існує два ключових компоненти для забезпечення атомарного кросчейн комунікації:

• Живучість ретрансляції: якщо відбувається транзакція, яка змінює стан чейну A таким чином, що впливає на стан чейну B, тоді певна транзакція повинна бути передана на чейн B (користувачем, ретранслятором або іншою стороною) для завершення операції. Наприклад, якщо Аліса заблокує кілька монет у чейні A, щоб перемістити їх у чейн B, має бути подана відповідна транзакція, щоб збільшити баланс Аліси в чейні B.
• Перевірка стану: коли чейн A і чейн B виконують дії на основі станів один одного, вони повинні бути впевнені, що інформація про стан, яку вони отримали, насправді відповідає узгодженому та дійсному стану чейна відповідно до правил дійсності транзакції чейна. Зауважте, що живучість вимагає перевірки стану. Щоб отримати більш детальну інформацію про перевірку кросчейн стану, див. Zamyatin et al.

Визначення «довіреної третьої сторони» є широким. Сам блокчейн є довіреною третьою стороною; він просто розподіляє довіру між більшістю учасників консенсусного протоколу (припущення чесної більшості). DAO також може бути надійною третьою стороною. Наприклад, у випадку моста між стандартним сайдчейном (або чейном рівня 1) і батьківським чейном консенсус сайдчейну може заблокувати або вкрасти кошти, розміщені в сайдчейні через батьківський чейн. Це пояснюється тим, що для перевірки стану батьківський чейн не перевіряє транзакції в самому сайдчейні. Натомість він вірить, що оператори сайдчейну (тобто консенсус) лише переміщують депоновані кошти в батьківському чейні відповідно до правил дійсності транзакцій сайдчейну. Такий міст є надійним мостом, оскільки він спирається на чесне припущення більшості, щоб запобігти крадіжці коштів операторами мосту, наприклад, мости Ethereum-Polygon і Ethereum-Solana.

Однак для rollup не потрібні припущення чесної більшості для перевірки стану, щоб гарантувати атомарність депозитів або зняття коштів, оскільки основний чейн опосередковано перевіряє дійсність транзакції rollup за допомогою таких методів, як докази ZK або докази фальсифікації. Однак вилучення коштів зі rollup через батьківський чейн вимагає довіреної третьої сторони у формі дуже слабкого припущення чесної меншості для живучості: принаймні один ретранслятор або агрегатор повинен опублікувати rollup блоки в батьківському чейні. У випадку rollup, де будь-яка сторона може бути ретранслятором або агрегатором і, таким чином, сам користувач може виконувати цю роль, це вимагає припущення синхронності (тобто існує синхронна мережа, так що коли користувач надсилає повідомлення, воно буде отримане в мережі протягом певного періоду часу).1

Кластери

Ми можемо розділити кросчейн комунікації на дві основні категорії:

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

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

Ми можемо визначити кластер як набір чейнів, які спілкуються один з одним (внутрішньокластерна комунікація) за допомогою кросчейн комунікації з мінімізованою довірою, включаючи використання перевірки стану з мінімізованою довірою, як-от докази фальсифікації, докази дійсності або пряму перевірку транзакцій. Кластер може бути, наприклад, набором rollup, підключених до батьківського чейну (як у випадку з rollup Ethereum), або автономних чейнів рівня 1, таких як Polygon або Solana.

Ключова властивість кластера полягає в тому, що кожен чейн у кластері може перевіряти кінцевий автомат кожного іншого чейну в кластері. Наприклад, усі rollup Ethereum сумісні з EVM, тож можна перевірити докази фальсифікації або ZK для rollup у EVM. Однак перевірити кінцевий автомат Solana в EVM практично неможливо, тому Solana не може спільно використовувати кластер з Ethereum.

Кластери також можуть спілкуватися з іншими кластерами (міжкластерна комінукація) за допомогою довіреної кросчейн комунікації, використовуючи методи перевірки стану, які не є мінімізованими до довіри, наприклад покладатися на комітет із 2/3 валідаторів для підписання блоків. Прикладом цього є міст Ethereum-Polygon.

Слід зазначити, що кластери є суверенними, тобто чейн у кластері A не може ввести чейн у кластері B у коло кластера A без хардфорку кластера A або B. Наприклад, неможливо створити rollup Ethereum, який створює мінімізований міст довіри між цим rollup і Polygon, без зміни Polygon, який буде реалізований як rollup (можна використати докази фальсифікації або ZK), щоб перенести його всередину кластера Ethereum. (Так само одна країна не може нав’язувати свої закони іншій країні без міжнародної угоди, якщо вона не вторгнеться в цю країну або не відбудеться революція.4)

Компроміс між безпечним компонуванням та масштабованістю

Вище ми встановили, що зв’язок між декількома чейнами завжди потребує компромісу щодо безпеки, порівняно з комунікацією через смарт-контракти в одному чейні.

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

Подібним чином існують також обмеження щодо того, наскільки великим може бути окремий кластер чейнів, включаючи набір rollup у головному чейні. Навіть із rollup прогнозується, що Ethereum 2.0 наразі оброблятиме близько 100,000 транзакцій в секунду.

Два важливі основні обмеження, які визначають розмір кластера:

• Вимога всіх чейнів у кластері розуміти середовище виконання один одного. Наприклад, якщо у вас є набір оптимістичних rollup на основі EVM, які взаємодіють між собою, вони повинні мати можливість зрозуміти EVM, щоб зрозуміти докази фальсифікації один одного. Подібно до ZK rollup, вони повинні розуміти системи підтвердження ZK один одного. Якщо ви хочете створити rollup за допомогою нового середовища виконання, вам потрібно створити власний кластер або хардфорк існуючого кластера.
• Ємність доступності даних кластера. Щоб підтримувати мінімізовану перевірку стану довіри між усіма чейнами в кластері, кожен чейн повинен перевіряти доступність даних блоків кожного іншого чейна в цьому кластері з мінімізованою довірою або шляхом безпосереднього завантаження даних, або за допомогою методів підтвердження наявності даних. Навіть із теоретично оптимальними підтвердженнями доступності даних існує обмеження розміру окремого кластера через обмеження ресурсів виробників блоків (тобто цільові вимоги до ресурсів для запуску валідатора).2

На практиці ми можемо спостерігати, що модель кластеризації вже є тим, як працює екосистема блокчейну в реальному світі – набір чейнів рівня 1 і rollup із внутрішньо- та міжкластерними мостами один з одним (див. схему вище). Однак міжкластерні мости мають серйозні компроміси щодо безпеки – ви повинні вірити, що набір валідаторів не вкраде ваші кошти. Таким чином, блокчейн-спільнота повинна забезпечити максимальну внутрішньокластерну масштабованість (наприклад, за допомогою rollup), щоб досягти межі кожного кластера, перш ніж створювати нові кластери, які покладаються на менш безпечну міжкластерну комунікацію.

Кластери в Celestia

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

Рівні блокчейн стеку. Celestia надає нижній рівень.

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

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

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

З цією метою важливим проектом, над яким ми працюємо, є optimint, додаткова заміна Tendermint, яка дозволяє розробникам створювати чейни на основі Cosmos як rollup, які можуть використовувати інші чейни, такі як Celestia, як рівень консенсусу та доступності даних. У майбутньому наша мета — зробити можливим для зон Cosmos на основі rollup формувати кластер одна з одною за допомогою протоколу Inter-Blockchain Communication (IBC).

Висновок

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

Дякуємо Юрі Стрікеру, Василю Шаповалову, Ніку Вайту, Ісмаїлу Хоффі, Олексію Замятіну, DeFi Frog, epolynya, Данкраду Фейсту, Патріку Маккоррі, Лейну, Арджуну Бхуптані та Хасу за коментарі до цієї публікації.

Нотатки

1. Слід зазначити, що батьківський чейн потребує припущення чесної більшості для того, щоб вилучення коштів із rollup було включено до чейну. Однак у цій моделі ми припускаємо, що обидва чейни мають наполегливість і живучість (див. визначення 1 і 2 у Zamyatin et al.), тому, якщо транзакція надсилається в чейн, вона зрештою буде включена в чейн.

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

3. Припущення чесної більшості для перевірки стану в протоколах атомарного обміну, таких як Nxtp, не обов’язково має значення, якщо два контрагенти є користувачами, які самі перевіряють чейни. Однак це має значення у випадку протоколів "lock-and-mint", коли активи вилучаються з одного чейна та передаються в інший, де контрагентами є два чейна.

4. Перегляньте цю статтю про DAO як рідні конституції Інтернету.

Українська спільнота

Приєднуйтесь до нашаго Telegram каналу, щоб читати всі новини та апдейти про Celestia українською. Ми будемо раді Вас бачити!