Коротка історія крос-ланцюга: пояснення дев’яти різних крос-ланцюгових рішень

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

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

Історію крос-ланцюгових механізмів необхідно викласти та порівняти, щоб зрозуміти крос-ланцюгові рішення та порівняти їх відмінності та атрибути.

Передача вручну

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

Напівавтоматична передача

Наступна ітерація покращується, коли користувач переносить активи в певний гаманець і/або смарт-контракт у ланцюжку A. Потім централізована програма відстежує адресу для переказів. Така програма автоматично відправляє активи в ланцюг B після перевірки. Плюсом залишається простота впровадження без зайвої складності чи кодування, а записи можна зберігати в мережі, а не локально. Недоліком є ​​те, що централізована програма може мати помилки або не працювати. На центральному кредитному рахунку також можуть закінчитися кошти. Гарантія безпеки також низька, децентралізації немає.

Централізований обмін

Коли прості крос-ланцюгові рішення не можна масштабувати, централізовані біржі процвітають на крос-чейн потребах. Вони працюють так, що користувачі передають активи на свою централізовану біржу, а потім, використовуючи «внутрішній» обмін біржі, перетворюють «активи X» у ланцюжку A на «активи Y» у ланцюжку B за допомогою обліку записів. Перевага очевидна – це найпростіше рішення у використанні – кодування не потрібне, а на біржах рівня 1 висока надійність. Але проблема виявляє протилежний недолік – централізований контроль того, коли доступний депозит/виведення. Централізована біржа забезпечує високу безпеку з недоліком найменшої децентралізації.

Централізований міст

Наступне вдосконалення покращує наявність окремої інфраструктури для передачі активів між ланцюгами – міст. Централізований міст працює так, що користувач передає активи, а потім, використовуючи функцію передачі мосту, ініціює передачу активів X у ланцюжку A в активи Y у ланцюжку B. Централізований ретранслятор (або набір) відповідає за процес:

Заблокуйте активи X у ланцюжку A
Перевірити
Монтувати активи Y у ланцюжку B
Перевагою цього моста є повністю автоматичний процес без будь-яких ручних перерв. А недоліком залишається централізований контроль того, коли доступний депозит/виведення. Крім того, міст може бути несправним або зламаним, що час від часу робить його нефункціональним. Тож захищеність середня, а децентралізації все одно немає.

Децентралізований міст з MPC

Наступною ітерацією буде децентралізація моделі перевірки замість централізованого мосту. Міст MPC (багатосторонніх обчислень) починається з того, що користувачі передають у нього активи. Використовуючи функцію передачі моста, він ініціює передачу активів X у ланцюжку A в активи Y у ланцюжку B. Зазвичай за процес відповідає децентралізований набір ретрансляторів:

Заблокуйте активи X у ланцюжку A за допомогою MPC
Перевірте за допомогою MPC
Монтуйте активи Y у ланцюжку B за допомогою MPC
Перевагою MPC є повністю автоматичний процес без переривання вручну, а вузли ретрансляції не потребують централізації. Недоліком є ​​висока вартість обчислення та зв’язку MPC. Крім того, вузли можуть бути скомпрометовані або змовлені. Безпека середня, децентралізація також середня.

Міст атомарного обміну з HTLC

Інший клас мостів виникає в залежності від технології атомарного обміну (Lightning Network). Він працює таким чином: користувач передає активи в атомарний міст обміну, а потім, використовуючи функцію передачі мосту, ініціює перенесення активів X у ланцюжку A в активи Y у ланцюжку B:

Створіть новий HTLC – Hash Lock Timed Contract
Внесіть активи X у контракт у ланцюжку A
Згенеруйте ключ блокування хешів + зашифруйте секрет для остаточного виведення протягом часу T у ланцюжку B
Представте зашифрований секрет для укладення контракту в ланцюжку B для виведення активів Y
АБО час T минув і відновіть активи X із контракту в ланцюжку A із зашифрованим секретом
Значною перевагою є те, що немає централізованого вузла/процесу, який контролює передачу мосту. І недолік є відносно поширеним – висока вартість розгортання HTLC і виконання викликів HTLC. Через ненадійність підтримувати високий рівень безпеки та контрольний слід складно. Безпека цього підходу є високою, і децентралізація також висока, враховуючи вищезазначені недоліки.

Межланцюгова сумісність із Light Client + Oracle

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

По-перше, користувач передає активи X у контракт міжланцюгового протоколу сумісності в ланцюжку A
Повідомлення про передачу встановлюється за контрактом і отримується децентралізованими вузлами ретранслятора
Вузли надсилають докази до контракту протоколу в ланцюжку B
Оновлення заголовка блоку (полегшеного клієнта) обробляються мережею Oracle для забезпечення доставки та дійсності
Користувач знімає активи Y з контракту протоколу в ланцюжку B після перевірки
Плюс цього підходу полягає в тому, що від передачі до завершення не потрібен проміжний маркер або ланцюжок. Після оновлення заголовків блоків можливе миттєве підтвердження. Мінуси: 1) ризики змови з боку Oracles, 2) через недовіру, підтримання високого рівня безпеки та контрольний слід є складним. Безпека цього підходу середня, а децентралізація висока.

Взаємодія крос-ланцюга з ланцюгом ретрансляції

З огляду на уроки підходу Oracle, також присутнє рішення чистого релейного ланцюга. Процес дещо інший:

Користувач передає активи X у контракт міжланцюгового протоколу сумісності в ланцюжку A
Повідомлення про передачу встановлюється за контрактом і отримується децентралізованими вузлами ретранслятора
Вузли надсилають докази контракту ланцюга ретрансляції
Базові валідатори ланцюга ретрансляції обробляють блокові оновлення, щоб забезпечити доставку та дійсність
Після перевірки вузли ретранслятора пересилають повідомлення про передачу до контракту протоколу в ланцюжку B
Користувач знімає активи Y з контракту протоколу в ланцюжку B
Перевага цього підходу перед простим рішенням Oracle полягає в дешевшій оплаті від ланцюжків ретрансляції, які споживають більшу частину витрат. Миттєве підтвердження можливе після оновлення блоків, що має вирішальне значення для вирішення тривалих затримок. Проблема полягає в тому, що сам протокол може не підтримувати повну екосистему. Безпека висока (в екосистемі), а децентралізація також висока.

Рівень міжланцюгової інфраструктури з легким клієнтом + ланцюгом ретрансляції

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

Користувач передає активи X у договір сумісності рівня міжланцюгової інфраструктури в ланцюжку A
Повідомлення про передачу встановлюється за контрактом і отримується децентралізованими вузлами ретранслятора
Вузли надсилають докази договору про сумісність ланцюга ретрансляції
Оновлення заголовка блоку (полегшеного клієнта) обробляються децентралізованими вузлами підтримки для забезпечення доставки та дійсності
Після перевірки вузли ретранслятора передають повідомлення до контракту взаємодії в ланцюжку B
Користувач вилучає активи Y з контракту на взаємодію в ланцюжку B
Це рішення забезпечує взаємодію з дуже низькою платою завдяки реалізації ланцюга ретрансляції. Він також надає миттєве підтвердження після оновлення заголовків блоків. Найбільшою проблемою є висока складність оптимізації легких клієнтів у ланцюзі ретрансляції. Завдяки проведенню достатньої кількості досліджень і розробок ці оптимізації повинні підтримувати переваги, які інші не можуть вирішити. Безпека дуже висока, а децентралізація висока.

Про протокол MAP

Серед крос-ланцюгових рішень ми ще не побачили жодного, яке вирішило б усі вищезазначені проблеми. До впровадження протоколу MAP. Після 3 років комплексних досліджень і розробок MAP Protocol нарешті безкомпромісно досягла рівня Omnichain із легкою технологією Client + relay chain. MAP реалізував принципи Omnichain із такими властивостями:

Готовий розробник
Покриття всіх мереж
Мінімальна вартість
Завершеність безпеки
Миттєве підтвердження

Протокол MAP — це рівень інфраструктури для підтримки побудови мостів, DEX, протоколів сумісності тощо. Він підтримує перевірку легкими клієнтами безпосередньо в ланцюзі ретрансляції MAP – для зменшення витрат. І він надає стимули, вбудовані в кожен компонент, щоб розробники dapp заробляли або представляли кінцевим користувачам. MAP підтримує ланцюги EVM і не-EVM – рівень протоколу ізоморфний усім ланцюгам.

У майбутньому MAP — це інфраструктура, що стоїть за всіма ланцюжками, яка стане новим базовим рівнем. Розробники більше не обмежені ланцюжком вибору й можуть зосередитися на самому продукті dapp. Майбутнє за Omnichain, і більша модульність і стимулювання – це шлях.