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

1. Значення та випадки використання міжланцюгової сумісності

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

Наприклад:

(1) Депонування активів із ланцюга OP у GMX у ланцюзі ARB для збільшення глибини пулу ліквідності.

(2) Використання активів із ланцюга OP для запозичень під заставу на Compound у ланцюзі ARB.

(3) Досягнення міжланцюжкової передачі активів NFT.

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

2. Чотири типи міжланцюгових протоколів взаємодії

2.1 Перевірка на основі вузлів або сторонніх мереж (перший тип)

2.1 Перевірка на основі вузлів або сторонніх мереж (перший тип)

Найпростіші крос-ланцюгові протоколи використовують Multi-Party Computation (MPC) для перевірки транзакцій. Thorchain служить яскравим прикладом, перевіряючи транзакції через вузли, розгорнуті в блокчейні для встановлення стандартів безпеки. Як правило, такі протоколи залучають до мережі від 100 до 250 валідаторів вузлів. Однак недоліком цього підходу є вимога до кожного вузла перевіряти кожну транзакцію, що призводить до збільшення часу очікування для користувачів. Крім того, експлуатаційні витрати вузлів є значними для протоколу і в кінцевому підсумку перекладаються на користувачів.

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

Поради: атака на Thorchain була пов’язана з уразливістю коду (система сприйняла підроблені символи ETH за справжні) і не пов’язана з безпекою методу перевірки.

Таблиця 1: Порівняння продуктивності протоколів міжланцюгової взаємодії

2.1.2 Покращення

У відповідь на це явище Wormhole вибрала 19 валідаторів для перевірки автентичності транзакцій, включаючи добре відомі валідатори вузлів, такі як Jump Crypto. Ці валідатори також працюють в інших мережах, таких як ETH і OP. Однак такий підхід несе ризик бути надто централізованим. Автор вважає, що повна децентралізація не завжди може бути найкращим вибором, оскільки певний ступінь централізованого управління може зменшити витрати. Зрештою, метою будь-якого проекту є досягнення масового впровадження та максимізація економічних вигод. Важливо відзначити, що вразливість Wormhole до атак була пов’язана з дефектом контракту; зловмисник використовував зовнішній контракт для перевірки транзакцій і викрадення активів, що не було пов’язано з внутрішньою безпекою процесу перевірки.

На відміну від інших крос-чейн протоколів, Axelar є блокчейном на основі Proof of Stake (POS). Axelar пакує інформацію перевірки з інших мереж і надсилає її до своєї основної мережі для перевірки, перш ніж пересилати її в цільовий ланцюг. Варто зазначити, що існує зворотна залежність між витратами на валідацію та безпекою. Зі збільшенням обсягу перевірочної інформації для участі в перевірці та підтримки безпеки мережі потрібно більше вузлів. Теоретично не існує верхньої межі для кількості вузлів, і збільшення кількості вузлів може призвести до різкого зростання витрат на передачу. Axelar може зіткнутися з цією дилемою в майбутньому.

Малюнок 1: Механізм перевірки осі

2.2 Оптимістична перевірка (другий тип)

Успіх оптимістичної верифікації (OP) свідчить про її поточну безпеку, економічну ефективність і переваги в швидкості. Отже, міжланцюгові протоколи, такі як Synapse, прийняли цю модель перевірки. Проте Synapse використовує метод Lock/Mint для обміну активами, що несе ризики хакерських атак. Причини цієї вразливості будуть розглянуті в розділі 2.3.1. Крім того, оптимістична перевірка задовольняє лише поточні потреби; з часом будуть потрібні більш безпечні та надійні методи, зберігаючи при цьому переваги у швидкості та вартості. Тепер автор представить подвійну перевірку як заміну оптимістичної перевірки.

2.3 Подвійна перевірка (третій тип)

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

(1) LayerZero

Одним із нововведень LayerZero є розгортання надлегких вузлів у різних ланцюгах, які передають дані релеєрам і оракулам поза ланцюгом (наданих Chainlink) для перевірки. Це дозволяє уникнути важких обчислювальних завдань, пов’язаних з першим типом протоколу. Oracle генерує таку інформацію, як заголовки блоків, тоді як Relayer підтверджує автентичність транзакцій. Транзакції обробляються лише тоді, коли обидва компоненти функціонують правильно. Важливо відзначити, що вони працюють незалежно. Щоб викрасти активи, хакеру потрібно буде контролювати як Relayer, так і Oracle. Порівняно з оптимістичною перевіркою, це більш безпечно, оскільки перевіряється кожна транзакція.

Рисунок 2: Механізм верифікації LayerZero

Переваги за ціною та безпекою: автор проводив експерименти з використанням Stargate (на базі технології LayerZero)

1）Від OP до ARB потрібна 1 хвилина для завершення транзакції—-1,46 дол.

2）Від OP до BSC потрібна 1 хвилина для завершення транзакції—-0,77$

3）З OP до ETH потрібно 1 хвилина 30 секунд, щоб завершити транзакцію — $11,42

Виходячи з вищевикладеного, модель подвійної верифікації займає явну лідируючу позицію.

(2) Ланцюжок

Committing DON збирає дані транзакцій, а цільовий ланцюг ARM збирає інформацію з вихідного ланцюга ARM, щоб реконструювати дерево Merkle та порівняти його з деревом Merkle Committing DON. Після успішної «перевірки» певної кількості вузлів транзакція передається на виконання DON для виконання, і навпаки. Примітка: ARM є незалежною системою. Технологія Chainlink на 90% подібна до принципів LayerZero, обидві використовують модель «збір інформації + перевірка інформації (перевірка кожної транзакції)».

Малюнок 3: Механізм перевірки Chainlink

Наразі Chainlink підтримує такі проекти, як Synthetix (для міжланцюгової передачі sUSD) і Aave (для міжланцюгового голосування за управління). З точки зору безпеки, хоча ARM і Executing DON є двома системами, обидві контролюються Chainlink, що створює ризик внутрішньої крадіжки. Крім того, завдяки подібним технологіям Chainlink, швидше за все, залучить відомі проекти, які прагнуть до поглибленої співпраці, щоб скористатися її послугами, досягаючи ефекту об’єднання. Навпаки, LayerZero більш привабливий для розгортання нових проектів. Але з точки зору підтримуваних мереж і екосистем LayerZero має перевагу. Крім того, розробники проектів зазвичай вважають за краще розгортати свої продукти в популярних екосистемах.

Рисунок 4: Екосистема LayerZero

2.3.1 Трикутник неможливості Layerzero

Малюнок 5: Трикутник неможливості Layerzero

Безпека. Існує чотири методи передачі активів між мережами:

1）Lock/Mint: міжланцюгові протоколи розгортають пули ліквідності в різних мережах. Коли користувач бажає перенести ETH із ланцюга A до ланцюга B, він повинен заблокувати ETH у ланцюзі A, а потім еквівалентна кількість wETH буде викарбувана в ланцюзі B. Щоб перевести назад у ланцюг A, wETH спалюється, а заблокований ETH у ланцюжку A звільняється. Ризик тут полягає в тому, що безпека повністю залежить від міжланцюгового мосту — якщо заблокована сума є значною, вона стає прибутковою мішенню для хакерів для атаки на пули ліквідності.

2）Спалювання/монтаж: токени карбуються у формі Omnichain Fungible Tokens (OFT), що дозволяє записувати певну кількість токенів у вихідному ланцюжку та еквівалентну кількість карбувати в ланцюжку B. Цей метод дозволяє уникнути ризиків, пов’язаних із великими пули ліквідності та теоретично пропонує більшу безпеку. Модель OFT зазвичай вибирається під час випуску токенів, що полегшує циркуляцію між додатками. Хоча існуючі проекти можуть конвертувати свої токени в OFT, це складно через залучення інтересів багатьох зацікавлених сторін, наприклад, обробка нативних токенів в інших додатках після перетворення. Тому це більш життєздатний варіант для нових проектів. Таким чином, немає необхідності для існуючих проектів брати на себе такий ризик; вони можуть продовжувати розвиватися існуючим шляхом. Отже, вибір безпеки означає, що його не можна застосовувати до старих проектів.

3）Атомарний своп: протокол створює пули ліквідності в обох ланцюжках, зберігаючи певну кількість токенів. Коли користувачі здійснюють передачу між ланцюжками, вони вносять активи в пул ліквідності в ланцюзі A, а відповідна кількість токенів вилучається з пулу ланцюга B і надсилається користувачеві. По суті, це одночасне збільшення та зменшення кількості токенів, що забезпечує високий рівень безпеки.

4）Проміжний токен: як описано в 2.1, Thorchain може спричинити виснаження та передбачає тривалий час очікування.

Наразі метод Atomic Swap є найпоширенішим методом, але в майбутньому, ймовірно, буде тенденція до моделі Burn/Mint, що дозволить досягти справжнього нульового виснаження під час міжланцюжкових переказів із збереженням безпеки. Іншою проблемою для старих проектів, які розглядають можливість використання Layerzero, є маніпуляція цінами Oracle. Було багато атак на оракули, і оскільки технологія ще не повністю зріла, більшість протоколів займають обережну позицію.

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

2.4 Модульний міжланцюговий протокол (перевірка AMB, тип чотири)

Connext функціонує як модульний міжланцюговий протокол сумісності, структурований у вигляді концентратора та спиці. Він делегує перевірку між ланцюгом A та ланцюгом B їхнім відповідним мостам довільних повідомлень (AMB) — зі зв’язком — це ланцюги A та B. Згенеровані докази дерева Merkle зберігаються в основній мережі Ethereum, яка діє як концентратор.

Рисунок 6: Механізм перевірки підключення

Цей протокол пропонує найвищий рівень безпеки, оскільки ми довіряємо безпеці мережі Ethereum, застосовуючи принцип спільної безпеки. Якщо використовується технологія Layerzero, ми насправді довіряємо самій команді проекту, що теоретично безпечніше, ніж так звана подвійна перевірка. У довгостроковій перспективі деякі крос-ланцюгові протоколи OP можуть мати проблеми з безпекою, і майбутня тенденція, ймовірно, зміниться на ZKP (докази з нульовим знанням) або моделі подвійної перевірки. З іншого боку, для безпечної перевірки власних токенів у ланцюгах кожен ланцюг використовує власний модуль AMB для перевірки, і ці перевірки можуть мати непослідовний час передачі. Офіційний AMB зазвичай вимагає більшого часу перевірки, і іноді користувачам може знадобитися чекати до чотирьох годин або навіть довше, щоб завершити перевірку. Це потенційно може обмежити масштабованість протоколу Connext з точки зору загальної економічної ефективності та загального використання.

3.Межланцюговий протокол на основі ZKP

Конкуренція між існуючими міжланцюжковими протоколами вже є жорстокою, і багато команд проектів націлилися на підтвердження з нульовим знанням (ZKP), сподіваючись йти в ногу з концепцією зведення ZK. Вони використовують такі технології, як ZK-релейери та ZK-кінцеві точки освітлення, підкреслюючи найвищу безпеку. Однак я вважаю, що ще занадто рано для застосування ZKP у міжланцюжному домені протягом наступних 5-10 років, і йому важко конкурувати з існуючими крос-ланцюжковими протоколами з наступних причин:

(1) Час і вартість створення доказів занадто високі. Докази з нульовим знанням поділяються на ZK STARK і ZK SNARK, причому перші мають більші докази, але коротший час генерації, а другі мають менші докази, але довший час (чим більше доказ, тим вища вартість). Більшість крос-ланцюгових рішень ZKP оберуть ZK SNARK, тому що якщо ціна крос-ланцюга занадто висока, жоден користувач не вибере рішення. Отже, як вирішити проблему тривалого необхідного часу? Деякі протоколи можуть додавати «швидкий шлях», подібний до Optimistic rollups (OP), де вони спочатку обробляють транзакцію, а потім перевіряють її. Однак це не суто ZKP і більше схоже на версію OP Plus.

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

(3) Невизначеність у технологічній еволюції. В існуючих крос-ланцюжкових протоколах методи, що включають подвійну перевірку, вже пропонують достатньо високий рівень безпеки для задоволення поточних потреб. Хоча може здатися, що ЗКП зараз не потрібні, майбутні технологічні ітерації можуть змінити цю ситуацію. Як і двадцять років тому, незалежно від того, чи потрібно містам третього рівня будувати шляхопроводи, у короткостроковій перспективі може не виникнути негайної потреби, але в довгостроковій перспективі ЗКП можуть стати наріжним каменем розвитку міжланцюгових доменів. Тому, незважаючи на те, що ще не настав час для ZKP, командам важливо продовжувати свої дослідження та розвідку, а також бути в курсі, оскільки темпи технологічного розвитку непередбачувані.

4.Висновок і рефлексія

Протоколи сумісності крос-ланцюгів є важливими для розробки блокчейну. Серед різноманітних крос-чейн протоколів механізм подвійної перевірки виділяється з точки зору безпеки, вартості та швидкості, особливо з такими лідерами галузі, як Layerzero та Chainlink. Хоча їх технічні реалізації фундаментально подібні, Layerzero може похвалитися багатшою екосистемою, що надає їй конкурентну перевагу на даний момент. Однак прогрес Layerzero у розвитку екосистеми був повільнішим через його механізми безпеки та аудиту, але вважається, що в майбутньому буде більше можливостей для розвитку. Що стосується крос-ланцюжкових рішень на основі Zero-Knowledge Proof (ZKP), хоча їх застосування все ще є далекою перспективою, траєкторія їхнього розвитку є перспективною, і вони вимагають постійної уваги.

Автор залишається оптимістичним щодо Layerzero та міжланцюжкового домену, але також висвітлює деякі потенційні проблеми. Більшість існуючих крос-ланцюгових протоколів знаходяться на рівні L0 (транспортний рівень) і в основному використовуються для передачі активів і розповсюдження повідомлень (соціальних, управлінських тощо). З точки зору передачі активів, існуючі крос-ланцюгові мости є псевдо-крос-ланцюгами. Автор вважає, що справжній крос-ланцюг стосується активу, який справді переходить до іншого ланцюга (Burn/Mint), а не Lock/Mint або Atomic Swap. Однак, щоб досягти цього, існуючі проекти повинні бути повністю переглянуті, щоб нові зайняли їхнє місце, з випуском токенів у моделі OFT. Але це дуже складно і вимагає значного перехідного періоду.

Ми все ще живемо у світі, який покладається на «третіх сторін», а блокчейни залишаються ізольованими. Що стосується передачі повідомлень, ланцюги можуть покладатися на транспортний рівень для передачі повідомлень, але поточний попит незначний. Наприклад, для обміну повідомленнями в соціальних мережах потрібен міжланцюговий зв’язок між Lens і Cyber, але масштаби розвитку соціальної сфери невизначені. Крім того, якщо більшість програмних додатків розгорнуто в екосистемі Lens і можуть вільно спілкуватися, не буде потреби в крос-чейні. Кросс-ланцюг стає необхідним лише у висококонкурентному середовищі.

Це спонукає до обговорення нових загроз від суперланцюжків рівня 2, таких як успіх суперланцюга OP, який може спонукати більше рішень рівня 2 використовувати подібні технології для бездоганної інтеграції (активи). Успіх блокчейну в майбутньому та нездатність OP та інших зведених програм обробляти надмірну кількість користувачів і транзакцій може призвести до появи нових рішень Layer2. Суть безшовної інтеграції полягає у використанні спільного розрахункового шару. Таким чином, для передачі активів не потрібна третя сторона, натомість дані про транзакції отримуються з того самого рівня розрахунків і перевіряються у відповідних ланцюгах. Подібним чином найбільше сподіваються побачити крос-ланцюгові протоколи – це конкуренція між OP, ARB, ZKsync і Starnet без чіткої ієрархії, оскільки це полегшить передачу між цими екосистемами. В іншому випадку, якщо один Layer2 домінує на 80% частки ринку, крос-ланцюг стане непотрібним. Однак майбутнє містить багато невизначеностей, і це лише деякі з побоювань автора, які слід вважати доцільними.

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

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

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