Омничейн решения были самой обсуждаемой темой за последний год. С развитием инфраструктуры публичных сетей возник огромный интерес к тому, как различные сети общаются и взаимодействуют друг с другом. Решения были предложены и реализованы, но без радикальных компромиссов ни одно из них на самом деле не решает фундаментальных проблем. Теперь мы рассмотрим различные омничейн подходы и расскажем, почему и как они будут определять будущее омничейн инфраструктуры.
Во-первых, давайте обсудим, что такое омничейн технология и зачем она нужна. Причина использования: цепочки неоднородны и требуют от разработчиков значительного времени для отслеживания различий и проблем при перемещении активов между ними.
Что такое Omnichain технология?
Во-первых, давайте обсудим, что такое Omnichain технология и зачем она нужна. Причина использования: цепочки неоднородны и требуют от разработчиков значительного времени для отслеживания различий и проблем при перемещении активов между ними.
Омничейн мосты менее безопасны и им нельзя доверять на 100%, потому что они обычно принадлежат командам блокчейн-проектов и сильно централизованы (беспорядочно, без координации со стороны каждой команды). Целью блокчейна уровня 1 является стандартизация, но сегментация цепочек уровня 1 приводит к необходимости создания межцепочечного инфраструктурного уровня, который находится даже под уровнями уровня 1.
Как работают омничейн цепи?
Чтобы понять омничейн решения и сравнить их различия и характеристики, необходимо изложить и сравнить историю омничейн механизмов.
1-е поколение омничейн решения: Ручная передача
Самое первое омничейн решение - это ручная передача активов. Процесс начинается с того, что пользователь переводит активы на определенный кошелек в цепочке A, а централизованная организация отслеживает переводы в кошельке и записывает их в Excel. Затем, через определенный промежуток времени (обычно для целей мониторинга), организация зачисляет активы в цепочку B после проверки. Преимуществом этого подхода является простота реализации, но он подвержен человеческим ошибкам и имеет очень низкую гарантию безопасности. В этом подходе также отсутствует децентрализация.
Полуавтоматическая передача
Следующая итерация улучшается за счет того, что пользователь переводит активы на определенный кошелек и / или смарт-контракт в цепочке A. Затем централизованная программа отслеживает адрес для переводов. Такая программа настроена на автоматическую отправку активов в цепочку B после проверки. Плюсом по-прежнему является простота реализации без излишней сложности или кодирования, а записи можно хранить в цепочке, а не локально. Недостатком является то, что централизованная программа может глючить или работать со сбоями. На центральном кредитном счете также могут закончиться средства. Гарантия безопасности также невелика, и децентрализация отсутствует.
Централизованная биржа (CEX)
Когда простые омничейн решения просто не масштабируются, централизованные биржи процветают благодаря омничейн потребностям. Они работают, заставляя пользователей переводить активы на их централизованную биржу, а затем, используя “внутренний” обмен биржи, превращать “активы 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является высокая стоимость вычислений и связи. Кроме того, узлы могут быть скомпрометированы или вступили в сговор. Безопасность средняя, в то время как децентрализация также средняя.
Atomic Swap мост с HTLC
Возникает еще один класс мостов, зависящий от технологии atomic swap(Lightning Network). Это работает следующим образом: пользователь передает активы в мост атомной подкачки, а затем, используя функцию передачи моста, инициирует передачу активов Xв цепочке Aв активы Yв цепочке B:
- Создать новый Контракт с временной блокировкой HTLC - Хэша
- Внести активы X в контракт по цепочке A
- Сгенерировать хэш-ключ блокировки + зашифровать секрет для окончательного вывода в течение времени T по цепочке B
- Предоставить зашифрованный секрет для заключения контракта по цепочке Bдля вывода активов Y
- ИЛИ прошло время T, и восстановите активы X из контракта в цепочке A с зашифрованным секретом
Основное преимущество заключается в том, что нет централизованного узла /процесса, управляющего передачей моста. И недостаток довольно распространен - высокая стоимость развертывания HTLC и запуска HTLC-вызовов. Из-за отсутствия доверия поддержание высокого уровня безопасности и контрольного журнала также является сложной задачей. Безопасность такого подхода высока, а децентрализация также высока, учитывая вышеупомянутые недостатки.
Омничейн решение с Light клиентом / Oracle / Relay chain
Омничейн совместимость с Light Client + Oracle
После того, как появился дорогостоящий мост, появилось больше реализаций, направленных на снижение этой стоимости. Технология Light clientстала новейшей нормой для упрощения межцепочечных проверок. Процесс заключается в следующем:
- Первый пользователь передает активы X в контракт протокола межцепочечной интероперабельности в цепочке A
- Сообщение о передаче устанавливается в контракте и принимается децентрализованными узлами ретранслятора
- Узлы отправляют доказательства в контракт протокола по цепочке B
- Обновления заголовка блока (light клиент) обрабатываются Oracle network для обеспечения доставки и достоверности
- Пользователь выводит активы Y из контракта протокола в цепочке B после проверки
Плюсом этого подхода является то, что для завершения передачи не требуется никакого промежуточного токена или цепочки. Мгновенное подтверждение возможно после обновления заголовков блоков. Минусы: 1) риски сговора со стороны оракулов, 2) из-за ненадежности поддержание высокой безопасности и контрольного журнала является сложной задачей. Безопасность этого подхода является средней, в то время как децентрализация является высокой.
Омничейн совместимость с Relay Chain
На уроках подхода Oracle также присутствует чистое решение с цепочкой ретрансляции. Процесс немного отличается:
- Пользователь передает активы X в контракт протокола межцепочечной интероперабельности в цепочке A
- Сообщение о передаче устанавливается в контракте и принимается децентрализованными узлами ретранслятора
- Узлы отправляют доказательства в контракт ретрансляционной цепи
- Обновления блоков обрабатываются базовыми валидаторами цепочки ретрансляции для обеспечения доставки и достоверности
- После проверки узлы ретранслятора пересылают сообщение о передаче в контракт протокола по цепочке B
- Пользователь выводит активы Y из контракта протокола в цепочке B
Преимуществом этого подхода по сравнению с простым решением Oracleявляется более дешевая плата за ретрансляционные цепочки, которая потребляет большую часть затрат. Мгновенное подтверждение возможно после обновления блоков, что имеет решающее значение для решения более длительных задержек. Проблема заключается в том, что сам протокол может не поддерживать экосистему всей цепочки. Безопасность высока (внутри экосистемы), а децентрализация также высока.
Омничейн инфраструктурный уровень с Light Клиентом + Relay Chain
Решение следующего поколения ориентировано на омничейн инфраструктурный уровень, решающий все вышеперечисленные фундаментальные проблемы. Он сочетает в себе технологию light client с relay chain для объединения всех цепей:
- Пользователь передает активы X в контракт на взаимодействие уровня омничейн инфраструктуры в цепочке A
- Сообщение о передаче устанавливается в контракте и принимается децентрализованными узлами ретранслятора
- Узлы отправляют доказательства в контракт на интероперабельность ретрансляционной цепи
- Обновления заголовка блока (легкий клиент) обрабатываются децентрализованными узлами сопровождения для обеспечения доставки и достоверности
- После проверки узлы ретранслятора пересылают сообщение о передаче в контракт на взаимодействие по цепочке B
- Пользователь выводит активы Y из контракта на взаимодействие в цепочке B
Это решение обеспечивает совместимость с очень дешевыми тарифами благодаря реализации цепочки ретрансляции. И это дает мгновенное подтверждение после обновления заголовков блоков. Самой большой проблемой является высокая сложность оптимизации клиентов light в цепочке ретрансляции. Уделяя достаточно внимания исследованиям и разработкам, эти оптимизации должны обеспечить поддержку преимуществ, которые другие не могут решить. Безопасность очень высока, а децентрализация, очевидно, высока.
Следующее поколение Омничейн: Протокол MAP
Из омничейн решений мы еще не видели ни одного, которое решало бы все вышеперечисленные проблемы. До тех пор, пока не будет реализован протокол MAP. После 3 лет напряженных исследований и разработок MAP Protocol наконец-то достиг уровня омничейн инфраструктуры с технологией light Client + relay chain без компромиссов. В MAP реализованы омничейн принципы со следующими свойствами:
- Приложение Готово
- Охват всей цепочки поставок
- Экономичный
- Окончательность обеспечения безопасности
- Мгновенное подтверждение
Протокол MAP - это инфраструктурный уровень для поддержки построения мостов, дексов, протоколов взаимодействия и многого другого. Он поддерживает проверку light клиентами непосредственно в цепочке ретрансляции КАРТ - для снижения затрат. И это обеспечивает встроенные в каждый компонент стимулы для разработчиков dapp, которые они могут заработать или представить конечным пользователям. КАРТА поддерживает цепочки EVM и не-EVM - уровень протокола изоморфен всем цепочкам.
В будущем MAP - это инфраструктура, лежащая в основе всех цепочек, которая станет новым базовым уровнем. Разработчики больше не ограничены своей цепочкой выбора и могут сосредоточиться на самом продукте dapp.
