Аннотация

ZetaChain: блокчейн со встроенной поддержкой кроссчейн смарт-контрактов

Данный технический документ (WhitePapper/Белая бумага) посвящён ZetaChain — блокчейн с поддержкой типовых омничейн смарт-контрактов.

С помощью данной технологии можно соединять как блокчейны с поддержкой смарт-контрактов, такие как Ethereum, роллапы второго уровня для Ethereum, Solana, Terra и Algorand. Так и блокчейны без поддержки смарт-контрактов, такие как Bitcoin, Dogecoin и другие.

ZetaChain — это Proof-of-Stake (PoS) блокчейн с наблюдателями и подписантами для внешних блокчейнов. Наблюдатели проверяют внешние сети на предмет соответствующих событий, транзакций и состояний в определенный момент времени, и по результатам наблюдения достигают консенсуса на ZetaChain блокчейне.

Все подписанты совместно владеют единым ключом схемы пороговой подписи (TSS), который позволяет отправлять аутентифицированные сообщения во внешние сети и хранить активы, как обычные аккаунты / адреса во внешних сетях.

Смарт-контракты на ZetaChain поддерживают произвольную логику, выполняемую условно по событиям внешней сети, и могут напрямую обновлять состояния внешней сети через свои TSS-подписанные транзакции.

Таким образом, ZetaChain позволяет создавать омничейн dApps, взаимодействующие с различными блокчейнами нативно и напрямую, без оборачивая и бриджинга каких-либо активов.

1. Вступление

Мультичейн будущее кажется неизбежным. Сложно представить, что одного блокчейна будет достаточно для всех сценариев использования. Тем не менее, мультичейн будущее без совместимости между блокчейнами можно сравнить с Интернетом до появления TCP/IP.

Современные блокчейны слишком фрагментированы и не являются совместимыми — это препятствует массовому принятию технологий. Например, децентрализованное приложение (dApp) зачастую привязано к определенному блокчейну. Если пользователь знакомится с криптоэкосистемой с помощью данного приложения, то подобная фрагментация создает для него огромные барьеры для быстрого освоения или использования приложения на другой сети.

В рамках решения проблемы функциональной совместимости было разработано несколько предложений и проектов, в которых особое внимание уделяется возможности взаимодействия.

Однако большинство из этих систем применимы только к конкретным блокчейнам, стандартизируют протоколы в рамках собственных систем, требуя от других блокчейнов принятия или сложных, ограниченных и/или менее безопасных мостов для подключения (см. рисунок 1).

Рисунок 1 - До и после ZetaChain

Рисунок слева: Нынешняя экосистема. Пользователи и разработчики изолированы в различных сетях, а существующие кроссчейн решения носят разрозненный характер, что приводит к серьезной и нарастающей фрагментации. Рисунок справа: Экосистема с ZetaChain. Пользователи, разработчики и приложения могут беспрепятственно взаимодействовать между сетями. Новая парадигма — Омничейн dApps.

В настоящем техническом документе мы представляем новый, публичный блокчейн первого уровня, который эффективно и агностически соединяет блокчейны и облегчает взаимодействие.

Кроме этого, мы представляем типовый блокчейн смарт-контракт, способный напрямую хранить и управлять активами на других блокчейнах, тем самым позволяя создавать смарт-контракты, способные хранить активы на других сетях. Это открывает безграничные возможности для кроссчейн приложений.

Блокчейны по своей сути являются закрытыми системами. Цель данного документа — разработать и определить практичную систему, универсальную по своим кроссчейн возможностям, не вынуждая существующие блокчейны принимать новые стандарты или разрабатывать новый блокчейн, на который потребуется перевести все активы. И цель состоит в том, чтобы сделать это децентрализованным, византийским отказоустойчивым способом.

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

Согласно нашему обширному исследованию, для решения этой проблемы наилучшим образом подходит децентрализованная нотариальная система на основе стимулируемого Proof-of-Stake, с репликацией конечного автомата (также известной как блокчейн), которую мы называем ZetaChain.

ZetaChain — это, прежде всего, публичный блокчейн с валидаторами Proof-of-Stake. Доверяется, что подавляющее большинство (>66% узлов) узлов-валидаторов честны и действуют в соответствии с требованиями протокола, и все они совместно выполняют роль нотариусов.

В дополнение к тому, что это блокчейн, интероперабельность также нуждается в наблюдении за работой других блокчейнов. Поэтому к каждой ноде валидатора ZetaChain прикреплен наблюдатель, который проверяет другие блокчейны на соответствие событиям (журнал событий, транзакция или состояние в определенное время). Наблюдатели передают ZetaChain информацию о соответствующих событиях и достигают консенсуса.

ZetaChain использует пользовательскую логику для обновления своего состояния в ответ на полученные от наблюдателей данные. С другой стороны, чтобы изменить состояние на других блокчейнах, каждый валидатор также связан с подписантом, владеющим долей ключа.

Все валидаторы владеют одной парой публичного/приватного ключа, посредством которого могут напрямую инициировать транзакции на других блокчейнах для изменения состояния. Принцип подписания может быть в виде пороговой схемы подписи, такой как GG18/GG20 ECDSA/EdDSA, или пороговой/агрегатной подписи BLS, в зависимости от криптографии на разных блокчейнах и их возможностей/затрат на разработку смарт-контрактов.

Единый публичный ключ и адрес в системе ZetaChain позволяет ZetaChain хранить активы на сторонних блокчейнах, которые могут не иметь функциональности смарт-контрактов, например, как Bitcoin. Эта возможность позволяет создавать мощные кроссчейн (или омничейн) приложения поверх нативных кроссчейн смарт-контрактов ZetaChain.

Такая реализация выглядит примерно так же, как в Ethereum, где смарт-контракту можно доверить управление активами в соответствии с заранее установленными правилами, но в ZetaChain смарт-контракт может использовать и управлять активами на любом подключенном блокчейне.

Резюмируя, можно сказать, что ZetaChain разработана как децентрализованная кроссчейн платформа смарт-контрактов.

Видение ZetaChain состоит в том, чтобы стать публичным компьютером на всех основных блокчейнах, поверх которого можно будет легко создавать децентрализованные кроссчейн приложения. в виде публичных, трастлесс и персистентных смарт-контрактов.

2. Общие предпосылки: Эволюция блокчейна

2.1. Биткоин: первая децентрализованная криптовалюта

Bitcoin — это первая децентрализованная и не требующая разрешения публичная информационная система, разработанная на основе криптографии. Основным механизмом является византийский отказоустойчивый распределенный консенсус, который Bitcoin решает с помощью комбинации методов из криптографии, экономических стимулов и информатики.

Ключевыми инновациями Bitcoin является использование алгоритма цифровой подписи на основе эллиптической кривой (ECDSA) для самостоятельного хранения средств, а также использование алгоритма Proof-of-Work для достижения распределенного консенсуса (упорядочивание постоянно растущего журнала транзакций) и обеспечения устойчивости к атакам сибилов. Bitcoin также стал первым крупным применением технологии блокчейн — криптовалютой p2p.

Сеть Bitcoin добилась большого успеха, несмотря на то, что она не выполнила своего главного обещания — стать средством электронного платежа. Скорее, Bitcoin стал самым безопасным, децентрализованным и надежным средством накопления капитала за счет своей технической простоты и отказоустойчивости, высокой степени децентрализации и низкого порога входа, а также предсказуемой и консервативной денежной политики.

Сеть Bitcoin состоит из нод, соединенных p2p-сетью. Участниками сети являются пользователи и майнеры. Сообща сеть Bitcoin ведет растущую регистрационную книгу, которая представляет собой последовательность пользовательских транзакций.

Пользовательская транзакция — это подписанное сообщение, в результате которого расходуется определенное количество монет, контролируемое пользователем.

Пользовательская транзакция включает одно или несколько UTXO в качестве входа и создает одно или несколько UTXO в качестве выхода, тем самым изменяя состояние (UTXO сет).

Bitcoin поддерживает ограниченную форму скриптинга: при транзакции монеты могут быть отправлены в скрипт, и тот, кто может удовлетворить требованиям скрипта (т.е. предоставить данные, чтобы оценка равнялась 1), может потратить эти монеты.

Скриптовый язык намеренно прост и неполный по Тьюрингу — то есть не содержит структур ветвлений и циклов — но поддерживает довольно много простых, но принципиально полезных приложений, таких как мультисиг, атомарные свопы и т. д.

2.2. Ethereum: программируемый блокчейн со смарт-контрактами

Хотя концептуально Bitcoin — это простая бухгалтерская книга (упорядоченная последовательность транзакций) с базовыми скриптовыми функциями, которая послужила каноническим примером блокчейна, это не предел того, что может сделать блокчейн.

Например, из-за ограниченности верификации протокола Bitcoin в его сети невозможно выпустить новые монеты. Сеть Bitcoin не программируема в том смысле, что в ней может быть реализована произвольная функция перехода состояния.

Единственная функция перехода состояния, которую поддерживает Bitcoin — это жестко закодированное изменение сета UTXO. Таким образом, никакие приложения, помимо валюты BTC, не могут использовать сеть Bitcoin, наследуя ее консенсус, децентрализацию и безопасность.

Чтобы расширить сферу применения блокчейна для обеспечения программируемости, полной по Тьюрингу, был создан Ethereum. Ethereum заимствует Proof-of-Work из Bitcoin для консенсуса и внес несколько важных инноваций, сделавших его публичным программируемым блокчейном.

Во-первых, Ethereum использует виртуальную машину (EVM), обеспечивающую полную по Тьюрингу среду “песочницу” для определения произвольных функций перехода состояний (смарт-контрактов). Во-вторых, Ethereum отходит от модели UTXO в Bitcoin и использует учетную систему, в которой аккаунт хранит состояние.

Существует два вида аккаунтов: Учетные записи, принадлежащие внешним пользователям (EOA), управляемые приватным ключом. И учетные записи смарт-контрактов, которые работают автономно в соответствии со своей собственной логикой.

Наличие смарт-контрактов на Ethereum делает его одним из наиболее широко используемых dApp блокчейнов с тысячами развернутых приложений, таких как финансовые деривативы, биржи, НФТ, гемблинг и игры.

Смарт-контракты на Ethereum похожи на объекты в объектно-ориентированном языке программирования, где можно хранить состояние и вызывать функции для изменения состояния. Пользователи могут взаимодействовать со смарт-контрактами, отправляя им сообщения; и смарт-контракты могут также отправлять сообщения другим смарт-контрактам (вызывать), изменяя их состояния.

Смарт-контракты позволяют создавать очень интересные приложения и могут выполнять некоторые очень мощные вещи, такие как флэш-кредитование или флэш-свопы, которые не имеют аналогов в неблокчейновых приложениях. Это стало возможным благодаря мощной атомарности транзакции, вызывающей функции смарт-контракта: она либо завершается, либо полностью отменяется.

С годами появляется все больше и больше блокчейнов, таких как Polkadot, Solana, Avalanche и Cosmos, поддерживают близкие к полноте по Тьюрингу смарт-контракты.

2.3. Зарождение и мультичейн проблемы

Хотя некоторые предпочитают использовать одну сеть, но правда в том, что технология блокчейн и рынки развиваются с поразительной скоростью, и становится все более очевидно, что будущее экосистемы стоит за множеством блокчейнов.

Они будут служить своим целям и иметь свои собственные компромиссы в плане безопасности, децентрализации, масштабируемости, скорости, издержек, соблюдения норм и так далее.

Ключевое ограничение в этом мультичейн будущем заключается в том, что блокчейн спроектирован как закрытая система. Транзакции, совершаемые на блокчейне, могут полагаться лишь на состояние своего блокчейна и могут изменять только состояние собственного блокчейна. Внешняя информация не может быть достоверно передана в блокчейн без доверенной третьей стороны (оракула).

Транзакции, совершаемые с участием нескольких блокчейнов, должны проходить через доверенную сторону, например, централизованную биржу. Как результат, в настоящее время не существует децентрализованного, общедоступного и публичного сервиса, облегчающего проведение общих атомарных транзакций (не только атомарного обмена, но и произвольной логики) с участием нескольких блокчейнов.

К популярным кроссчейн или кросс-блокчейн стратегиям относятся сайдчейны, ретрансляторы, нотариальные системы, хэш-контракты с временной блокировкой и блокчейны блокчейнов.

Во-первых, сайдчейны/ретрансляторы — это популярные решения для реализации мостов, которые в основном позволяют переносить активы. В этих системах отдельные активы обладают собственной системой учета, которая является авторитетным источником информации об их принадлежности, но с помощью мостов можно переместить актив на другие блокчейны, будучи уверенным, что актив может вернуться на домашний блокчейн.

Ретранслятор — это один из непосредственных механизмов обеспечения совместимости, когда вместо того, чтобы полагаться на доверенного посредника для предоставления информации о сети А к сети Б, сеть Б реализует тонкий клиент сети А с помощью смарт-контрактов и может проверить, произошло ли определенное событие, транзакция или состояние в определенный момент времени на сети А.

Это часто называют трастлесс, потому что нет никаких дополнительных предположений о доверии, помимо доверия к двум участвующим цепочкам. Другими словами, не требуется никакого доверия к достоверности механизма передачи сообщений от цепи A к цепи B, кроме того, что сообщение будет доставлено и доставлено вовремя.

Примерами ретрансляторов являются BTCRelay в Ethereum (SPV-клиент Биткойна) и Rainbow bridge Эфириума на блокчейне NEAR. Ретрансляторы также являются популярными механизмами для сайдчейнов.

Во-вторых, нотариальные системы — это механизмы, в которых доверенному лицу (или их множеству) поручается нотариально заверять утверждения, например, что событие X произошло на блокчейне А. Наиболее очевидными нотариальными схемами являются централизованные биржи, которые являются доверенными лицами для облегчения межблокчейновых обменов монетами.

Нотариальные системы не обязательно должны быть централизованными; например, проект Interledger в его атомарном режиме может быть отнесен к категории децентрализованной, византийской отказоустойчивой нотариальной системы для облегчения межблокчейновых переводов.

Отметим, что нотариальные системы являются наиболее гибкими с точки зрения вариантов использования интероперабельности, поскольку они способны действовать с произвольной логикой в ответ на события на дискретных блокчейнах. Еще одной заметной децентрализованной нотариальной системой является THORChain, который реализует DEX для нативных монет в нескольких различных сетях, используя набор поощряемых валидаторов в качестве нотариусов.

В-третьих, хэш-контракты с временной блокировкой (HTLC) –- это конструкции смарт-контрактов, которые могут способствовать атомарному обмену между блокчейнами без дополнительного доверия со стороны участвующих двух блокчейнов.

Добавьте описание

Ключевыми словами являются “атомарный” и “трастлесс”.

Атомарный означает, что транзакции (с участием двух сторон) либо завершаются, либо реверсируются (как будто ничего не произошло). Термин trustless означает, что для атомарного свопа не нужно доверять третьей стороне.

Это работает примерно следующим образом: две стороны интерактивно развертывают и взаимодействуют со смарт-контрактами с обеих сторон.

Главная идея состоит в том, что стороной А задумывается секретный хэш, который используется обеими сторонами, и сторона А вынуждена раскрыть секрет при требовании монеты стороны Б, которая затем может быть использована стороной Б для требования монеты стороны А.

Примерами HTLC являются мост XClaim BTC/Ethereum или BTC/Polkadot, а также Lightning Network в Bitcoin.

В-четвертых, блокчейны блокчейнов (BoB) — это фреймворки, обеспечивающие данные, сеть, консенсус, стимулы и контрактные уровни для построения ориентированных на конкретные приложения блокчейны, взаимодействующих между собой.

Следует заметить, что BoB не решает современные проблемы совместимости напрямую. Вместо этого блокчейн позволяет создавать новые интероперабельные блокчейны. Для подключения к сетям необходимо использовать некий мост или другой механизм, показанный выше.

Яркими примерами BoB являются Polkadot и Cosmos, построенные на основе Substrate и Tendermint как механизма консенсуса, а также XCMP и IBC как протоколы кроссчейн коммуникации.

Любая из этих комплексных стратегий имеет свои сильные и слабые стороны, связанные с технической сложностью, предположениях о доверии, уровне функциональной совместимости и вариантах использования. Наше рассмотрение носит ограниченный и неполный характер, но все же мы можем условно классифицировать характеристики этих стратегий. Сравнение этих стратегий приведено в Таблице 1.

3. Смежные разработки функциональной совместимости/интероперабельности

В этом разделе мы приводим некоторые из последних и наиболее актуальных проектов, идей и тенденций, чтобы придать контекст данной статье и ZetaChain. Для более академических кросс-блокчейновых исследований, рекомендуем ознакомиться со всеобъемлющим исследованием [1].

3.1. Кроссчейн коммуникация

Базовым элементом любой кросс-блокчейновой функциональности является способность обмениваться данными и подтверждать в сети B, что определенная транзакция произошла на сети A.

BTCRelay [5], Rainbow Bridge [6]

Рассмотрим задачу создания одностороннего моста в Ethereum из Bitcoin. Если пользователь на Bitcoin отправляет 1 BTC на заданный кастодиальный адрес, на Ethereum выпускается один обернутый BTC.

Чтобы сделать это безопасным способом, смарт-контракт на Ethereum может верифицировать транзакцию на Bitcoin и выпустить соответствующую обернутую BTC монету на Ethereum. Примером может служить BTCRelay.

Для верификации транзакции на Bitcoin смарт-контрактом Ethereum, требуется, чтобы кто-нибудь (оффчейн сервис) предоставил транзакцию с доказательством Меркла транзакции. Смарт-контракт Ethereum верифицирует доказательство на основе цепочки заголовков блоков, хранящихся в смарт-контракте. Этот смарт-контракт по сути является легким клиентом Bitcoin.

Хотя сила доказательства немного ниже, чем у полноценной ноды (может быть уязвим для атак типа 51%), подобный вид моста является сильным и трастлесс/надежным, хотя и довольно дорогостоящим в плане эксплуатации, поскольку цепочка заголовков блоков должна постоянно обновляться в смарт-контракте.

Rainbow Bridge также является хорошим примером трастлесс-моста, между Ethereum и NEAR.

Wormhole [20]

Wormhole также является средством кроссчейн передачи сообщений, но он не трастлесс. Скорее, он полагается на группу узлов-валидаторов, которые подтверждают достоверность переданного сообщения.

Рассмотрим ту же задачу построения одностороннего моста на Ethereum из Solana.

Когда пользователь отправляет 1 SOL на конкретный кастодиальный адрес, на Ethereum выпускается один обернутый SOL. Смарт-контракт Ethereum не верифицирует транзакцию на Solana, чтобы выпустить обёрнутую монету; он полагается на то, что подавляющее большинство из всех валидаторов Wormhole честны и корректны.

Безопасность Wormhole основана на том, что подавляющее большинство валидаторов являются честными. Похоже, что Wormhole опирается на репутацию валидаторов для обеспечения доверия.

LayerZero [14]

LayerZero — это коммуникационный уровень для упрощения передачи сообщений между сетями. По сути, это более слабая реализация ретранслятора (см. введение о Relay).

Идея состоит в том, чтобы разрешить сети B подтверждать, что данная транзакция или событие произошло в сети A. Если сеть B поддерживает типовые смарт-контракты, в смарт-контракте может быть реализован легкий клиент сети A, позволяющий проверять информацию о сети A трастлесс методом.

Однако даже легкий клиент может быть дорогостоящим для запуска в смарт-контракте, как с точки зрения вычислений, так и с точки зрения хранения данных; например, BTCRelay на Ethereum, похоже, прекращена.

LayerZero сокращает эти расходы с помощью сверхлегкого клиента на смарт-контракте, который не сообщает и не хранит всю цепочку заголовков блоков (или значительную ее часть). Скорее, LayerZero полагается на доверие к заголовку блока без цепочки заголовков блоков, которая может быть отслежена до некоторого известного доверенного блока.

Ключевым допущением безопасности LayerZero является то, что две стороны — Релеер, который предоставляет доказательство транзакции, и Оракул, который предоставляет заголовок блока — не вступают в сговор.

В нашей терминологии и классификации LayerZero — не трастлесс, поскольку доверие необходимо для независимости двух сторон. Мы используем более строгое определение понятия “трастлесс”, где достоверность (необязательно жизнеспособность, устойчивость к цензуре) сообщений не зависит от доверия к чему-либо, кроме двух участвующих блокчейнов.

Если ретранслятор и оракул сговорятся, они могут обмануть LayerZero, составив недействительный заголовок блока (~2 ETH стоит вычисление PoW nonce, являющегося coinbase вознаграждением за каждый блок), и заставить сеть B поверить, что несуществующая транзакция произошла на сети A. LayerZero по существу передает вопрос безопасности стороннему ретранслятору и оракулу.

IBC [11]

Протокол IBC (Inter-Blockchain Communication) — это TCP/IP-подобный протокол для взаимодействия между суверенными блокчейнами.

IBC — это протокол сквозного шифрования, ориентированный на взаимодействие, протокол с хранением состояния между блокчейнами. На практике для IBC обычно требуются быстрые механизмы, такие как Tendermint, а блокчейн должен поддерживать IBC-протокол, например, созданные с помощью Cosmos SDK.

Что касается блокчейнов, поддерживающих IBC, они могут устанавливать связи, и через эти связи один блокчейн может проверить доказательства по отношению к состояниям консенсуса другого блокчейна. Каждый блокчейн, поддерживающий IBC, должен запустить легкий клиент, способный подтверждать доказательства на другом блокчейне, чтобы они могли соединиться.

Модуль IBC также должен управлять производством доказательств, а отдельный процесс (ретранслятор) должен передавать пакет и доказательство в цепочку контрагента.

Среди блокчейнов, поддерживающих IBC, можно установить очень тесное взаимодействие, например, перевод монет, атомарные свопы, кроссчейн децентрализованные биржи и даже кроссчейн смарт-контракты.

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

3.2. Кроссчейн передача активов

Hop [10]

Hop — это протокол для передачи монет между роллапами и блокчейнами первого уровня трастлесс методом.

По умолчанию роллапы являются изолированными системами, и передача активов между роллапами и блокчейном первого уровня может быть медленной и затратной.

Примером могут служить оптимистичные роллапы, которым обычно требуется неделя для вывода средств на L1; с другой стороны, zk-роллапы могут быстро подтвердить разрешение на вывод средств, но это требует проведения множества вычислений, которые дорого обходятся на L1.

Hop решает проблему перемещения монет между роллапами, создавая мосты и бридж-монеты, и использует AMM для обмена монетами без отправки монет напрямую. В частности, Hop создает бридж-монеты для каждого роллапа, и их можно передавать партиями, чтобы снизить стоимость.

Бридж-монета выступает в качестве промежуточного актива при переводе монет из роллапа А на роллап Б. Hop использует уже имеющиеся мосты роллапов для осуществления межроллапных транзакций, поэтому ему не нужен отдельный оффчейн-сервис.

Connext [4]

Connext — это решение для кроссчейн обмена активами с минимальным уровнем доверия.

Идея в некотором роде напоминает широко распространенные атомарные свопы, использующие Hash Time Locked Contracts (HTLC) для обеспечения атомарности транзакций.

Используется сеть оффчейн маршрутизаторов для создания рынка и механизма ценообразования типа AMM. Безопасность средств пользователей не зависит от третьих сторон, только от работоспособности системы.

По сравнению с Hop, Connext использует оффчейн сервисы и поэтому может подключать не только роллапы в рамках одного L1; по сравнению с другими решениями, Connext ориентирован на конкретные приложения, а не на широкое применение. Например, его нельзя адаптировать для отправки произвольных сообщений или вызовов кроссчейн контрактов.

Multichain [18]

Multichain (ранее Anyswap) — это кроссчейн мост и сеть кроссчейн маршрутизаторов.

Сеть состоит из смарт-контрактов подключенных сетей и сети Fusion. Ключевой технологией является распределенный ключ TSS между узлами MPC, а также DCRM (Distributed Control Rights Management) [7].

Схема ключа TSS, используемая в Multichain — GG20 [9], такая же, как в THORChain и ZetaChain. Многостороннее взаимодействие и хранение DCRM — это децентрализованная методика хранения.

DCRM состоит из двух важных функций: Lock-In и Lock-Out. При Lock-In пользователь блокирует внешний актив (например, Bitcoin), а система генерирует обернутую версию Bitcoin, принадлежащую только что сгенерированному распределенному приватному ключу TSS.

Система генерирует адрес Биткойна, и пользователь переводит Биткойн на этот адрес. Когда перевод завершается, узел Fusion получает подтверждение в сети Bitcoin и выдает пользователю обернутую версию BTC в сети Fusion. Таким образом, процесс Lock-In финализируется.

Процесс Lock-Out аналогичен, но происходит в обратном порядке. Получается, что Multichain — это мост, который блокирует монеты на подключенных сетях и оборачивает их на блокчейне Fusion. Поэтому Multichain можно рассматривать как централизованный мост.

THORChain [16], Sifchain [19], Chainflip [17]

THORChain (наряду с аналогичными конкурентами, такими как Sifchain и Chainflip) — это децентрализованная сеть ликвидности, которая облегчает выпуск нативных монет блокчейна первого уровня в стиле AMM на различных блокчейнах, включая Bitcoin, Litecoin, Bitcoin Cash, Ethereum.

Примечательно, что THORChain, строго говоря, не является мостом, поскольку он не блокирует и не оборачивает монеты и не совершает транзакции по оборачиваемым монетам. Скорее, THORChain — это блокчейн для конкретных приложений, который поддерживает пул, логику и управление хранилищами на разных сетях для обмена.

THORChain распространяет ключ подписи с использованием схемы GG20 TSS и имеет собственную реализацию, основанную на библиотеке Binance TSS.

ZetaChain отчасти вдохновлен дизайном THORChain, и его можно рассматривать как более простую и обобщенную платформу, которая позволяет не только совершать своппинг, но и создавать типовые смарт-контракты, обеспечивающие простоту разработки произвольных кроссчейн приложений. Например, разработчики могут реализовать функциональность, аналогичную THORChain, в виде смарт-контракта на ZetaChain.

Synapse [15]

Согласно открытым источникам информации, предполагается, что Synapse — это система кроссчейн свопов, основанная на внешнем верифицированном наборе валидаторов.

Synapse выпускает смарт-контракты AMM на внешних сетях, а также некоторые композитные стейблкоины в качестве промежуточного актива для кроссчейна. Для перемещения промежуточных стейблкоинов между сетями, используется стратегия сжигания и чеканки.

Подробная информация о функционировании механизма валидатора на момент написания данного документа недоступна.

3.3. Кроссчейн смарт-контракт

Сеть Quant [21]

По функциональности сеть Quant и ее продукт Overledger [21] наиболее близки к ZetaChain.

Сеть Quant представляет собой централизованную службу, которая обеспечивает стандартизированный доступ к подключенным публичным или частным блокчейнам на основе веб-сервиса, или региональным существующим базам данных.

Поддерживается общая программируемость, инициируемая событиями на этих блокчейнах (транзакция на/от определенного адреса, смарт-контракт взаимодействие, события, изменения состояния и т.д.), с помощью популярных языков и фреймворков, таких как Javascript, Java, Python и т.д. ZetaChain стремится достичь аналогичной общей программируемости, но с помощью стимулируемого публичного блокчейна, с гораздо меньшими предположениями о доверии, большей прозрачностью, полной проверяемостью и возможностью аудита.

ICP/Chain-Key [2]

Протокол Интернет-компьютера (ICP) предлагает обеспечить совместимость с сетью Биткойн с помощью своей технологии Chain-Key, которая похожа на схему распределенной пороговой подписи.

С помощью Chain Key протокол ICP в принципе может хранить средства в сети Биткойн. Неясно, как ICP осуществляет наблюдение за сетью Биткойн и как их платформа смарт-контрактов взаимодействует с внешними блокчейнами.

HyperService [12]

HyperService — это кроссчейн платформа смарт-контрактов, независимая от сетей. Она состоит из двух компонентов: языка высокого уровня HSL для создания кроссчейн dApp и уровня исполнения, который обеспечивает финансово-атомарные транзакции.

3.4. Блокчейн блокчейнов (BoB)

Наиболее известными BoB являются Cosmos и Polkadot. BoB — это, как правило, фреймворки, которые нацелены на тесное взаимодействие блокчейнов, разработанных для конкретных приложений.

Polkadot, например, предусматривает рэлейчейн, управляющий всем консенсусом, и парачейны, которые могут быть различными блокчейнами с различными функциями перехода состояния. Парачейны тесно взаимосвязаны и могут легко взаимодействовать друг с другом через ретрансляционную сеть.

Cosmos экосистема, напротив, не имеет совместного консенсуса, поэтому взаимодействие между сетями Cosmos менее тесное.

Каждая сеть Cosmos суверенна и имеет свой собственный выбор консенсуса (как правило, основанный на Tendermint). Экосистема Cosmos полагается на протокол IBC (см. раздел 3.1) и особые блокчейны, называемые хабами, для облегчения кроссчейн передачи активов и даже кроссчейн смарт-контрактов.

Для обеспечения взаимодействия в Cosmos или Polkadot, блокчейны обычно должны быть построены на некотором едином фундаменте. Устаревшие блокчейны или новые блокчейны с собственным консенсусом, не могут быть частью BoB.

4. Архитектура блокчейна ZetaChain

4.1. Аннотация

На самом высоком уровне ZetaChain — это Proof of Stake (PoS) блокчейн, который построен на основе Cosmos SDK и механизма консенсуса Tendermint PBFT.

В результате ZetaChain обладает быстрым периодом обработки блока (~5 с) и мгновенной завершенностью (не требуется подтверждение, не допускается реорганизация).

Механизм консенсуса Tendermint PBFT демонстрирует масштабирование до ~300 рабочих нод, а с будущими модернизациями с пороговыми сигнатурами BLS их число может возрасти до 1000+. Пропускная способность транзакций на ZetaChain потенциально может достигать 100 TPS благодаря эффективности использования протокола консенсуса Tendermint.

Архитектура ZetaChain состоит из распределенной сети нод, часто называемых валидаторами. Валидаторы выступают в роли децентрализованных наблюдателей, которые могут достичь консенсуса по соответствующим внешним состояниям и событиям, а также могут обновлять внешнее состояние сети посредством подписи распределенного ключа.

ZetaChain осуществляет эти функции децентрализованно (без единой точки отказа, трастлесс, общедоступно), прозрачно и эффективно. Каждый валидатор содержит ZetaCore и ZetaClient.

ZetaCore отвечает за производство блокчейна и поддержание реплицируемого конечного автомата.

ZetaClient отвечает за наблюдение за событиями во внешних сетях и подписывает исходящие транзакции.

ZetaCore и ZetaClient объединены вместе и управляются операторами узлов. Каждый желающий может стать оператором узла для участия в процедуре валидации при условии, что заложено достаточное количество активов в стейкинге. См. Рисунок 2 для наглядной демонстрации.

Добавьте описание

Валидаторы

ZetaChain использует протокол консенсуса Tendermint, который представляет собой частично синхронный византийский алгоритм консенсуса с отказоустойчивостью (BFT).

Каждый узел-валидатор может проголосовать за предложения блока с правом голоса, пропорциональным количеству заложенных монет (ZETA). Каждый валидатор определяется своим публичным ключом консенсуса.

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

Наблюдатели

Еще одним важным участником консенсуса ZetaChain являются наблюдатели, которые достигают консенсуса по внешним событиям и состояниям сети. Наблюдатели следят за подключенными сетями на предмет определенных соответствующих транзакций/событий/состояний по определенным адресам через свои полные узлы внешних сетей.

Наблюдатели могут быть разделены на две роли: секвенсор и верификатор (контролер).

Секвенсор выявляет соответствующие внешние транзакции/события/состояния и отчитывается перед верификаторами; верификаторы проверяют и голосуют на ZetaChain для достижения консенсуса.

Системе требуется как минимум один секвенсор и несколько верификаторов. Секвенсор не обязательно должен быть заслуживающим доверия, но по крайней мере один честный секвенсор необходим для обеспечения устойчивости системы.

Подписанты (Сингеры)

ZetaChain совместно хранит стандартные ключи ECDSA/EdDSA для аутентифицированного взаимодействия с внешними сетями. Ключи распределяются между несколькими подписантами таким образом, чтобы только подавляющее большинство из них могло подписывать от имени ZetaChain.

Важно убедиться, что в любой момент времени ни один субъект или малая группа нод не сможет подписывать сообщения от имени ZetaChain на внешних цепочках. Система ZetaChain использует облигационные ставки и положительные/отрицательные стимулы для обеспечения экономической безопасности.

На практике все вышеперечисленные роли (кроме секвенсора) сосредоточены в одной компьютерной ноде, совместно использующей программное обеспечение и учетные данные, такие как ключи валидатора и облигационные ставки, а также связанные с ними вознаграждения/слэшинг.

Планируется, что со временем ZetaChain перейдет от модели Proof-of-Authority к полностью делегированной модели Proof-of-Stake (DPoS) и постепенно передаст управление блокчейном держателям монет ZETA посредством ончейн голосования.

4.2. Наблюдатели

Наблюдателям поручено мониторить внешние сети на предмет соответствующих транзакций.

Наблюдатели постоянно проверяют события внешней сети, отвечающие за сжигание и чеканку нативной монеты (ZETA), сообщения и вызовы смарт-контрактов, а также другие события, которые регистрируются приложениями на ZetaChain.

Каждый наблюдатель ведет собственное независимое наблюдение, используя свой полноценный узел внешних сетей, и прежде чем финализироваться, все наблюдения должны достичь консенсуса на ZetaChain.

Как только события финализируются, автоматически запускается выполнение логики ZetaChain, которая может быть определена как собственный модуль Cosmos SDK или собственный смарт-контракт ZetaChain.

Существует два режима наблюдения: Активный и Пассивный режим.

Активный режим наблюдения предусматривает постоянное сканирование внешних блокчейнов на предмет соответствующих транзакций/событий/состояний.

Пассивный режим полагается на секвенсор (или их небольшой набор), который сканирует и сообщает о транзакциях/событиях вместе с доказательством Меркла. Наблюдатели проверяют доказательство и достигают консенсуса по ончейн верификации.

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

Использование пассивного режима гораздо менее затратно, так как проверка может быть выполнена с помощью легкого клиента. Только одному или нескольким секвенсорам нужен доступ к полной ноде, что намного дешевле и делает масштабирование на множество внешних сетей и увеличение количества нод намного проще.

Недостатком пассивного режима является то, что актуальность входящих наблюдений внешней цепочки зависит, а также подвергается цензуре со стороны секвенсора. Это та же ситуация, что и в оптимистичных роллапах, где живучесть роллапа зависит от секвенсора.

Для смягчения этой ситуации каждый может стать секвенсором, если захочет, а секвенсор может быть простимулирован за счет создания конкурентного рынка. В частности, dApps заинтересованы в работе секвенсора.

Еще одно преимущество пассивного режима наблюдения с секвенсором заключается в том, что dApps контролируют порядок наблюдения.

По соображениям эффективности активный режим не обеспечивает упорядочивание наблюдений. Но если порядок наблюдений важен для dApp, он может запустить свой собственный секвенсор в режиме синхронного наблюдения (т.е. ждать, пока каждое наблюдение будет завершено ZetaChain, прежде чем переходить к следующему).

4.3. Многосторонняя система пороговой подписи

ZetaChain должен владеть счетом на внешних сетях, чтобы хранить средства на этой сети (управлять пулом, хранилищем и т.д.) и выполнять привилегированные действия (сжигать, минтить, перемещать средства из хранилища и т.д.).

Это необходимо для кроссчейн смарт-контрактов общего назначения, поскольку основной особенностью смарт-контрактов является автономное управление активами. Например, в Ethereum смарт-контракт имеет адрес и может хранить любой актив, как Внешний Адрес Владельца (EOA, обычная учетная запись пользователя).

Благодаря этой возможности можно создавать множество мощных приложений, таких как AMM пулы, пулы кредитования/займов и т.д., где пользователи хранят свои активы и позволяют смарт-контрактам управлять ими в соответствии с заранее установленными смарт-контрактами правилами.

Для того чтобы иметь счет, ZetaChain требуется приватный ключ. Чтобы избежать единой точки отказа (единое место хранения приватного ключа, единый дилер при генерации ключа), ZetaChain необходима система распределенной пороговой подписи.

Это также необходимо для поддержки сетей без смарт-контрактов, таких как Bitcoin, Dogecoin, или платформы смарт-контрактов, для которых требуется дорогостоящее верифицирование мультиподписи. Чтобы избежать единой точки отказа, ZetaChain использует современную многостороннюю систему пороговой подписи (TSS) [8, 9], основанную на реализации THORChain TSS [16] и Binance tsslib [13].

По отношению к внешнему миру валидаторы ZetaChain коллективно обладают единым приватным ключом ECDSA/EdDSA, публичным ключом и адресом, и сигнатурой, подписанной ZetaChain, которую можно легко и эффективно проверить с помощью стандартной процедуры проверки ECDSA/EdDSA подключенными блокчейнами.

Внутренне, приватный ключ генерируется без дилера, и приватный ключ распространяется среди всех валидаторов. Ни в коем случае нельзя допустить, чтобы один или небольшое число валидаторов не смогли бы использовать приватный ключ и подписывать сообщения от имени всей сети.

Генерация ключей и процедуры подписания выполняются с помощью многосторонних вычислений (MPC), которые не разглашают секрет ни одного участвующего узла.

Поскольку ZetaChain может хранить TSS ключ и адрес, ZetaChain может поддерживать смарт-контракты, которые могут управлять собственными хранилищами/пулами на подключенных сетях, включая Bitcoin. Это существенно расширяет возможности смарт-контрактов в сети Bitcoin и, возможно, в других блокчейнах, не использующих смарт-контракты.

TSS, используемая ZetaChain, обеспечивает производительность и удобство горячего кошелька с уровнем безопасности холодного кошелька. Иллюстрацию см. на рисунке 3.

Добавьте описание

Для децентрализованной подписи ZetaChain использует многостороннюю 𝑡, 𝑛-пороговую систему ECDSA, основанную на [8].

Эта система пороговой подписи без лидера (TSS) выполняет генерацию ключей и подписание распределенным образом. То есть ни один проверяющий или сторонний субъект не имеет доступа к полному закрытому ключу в любой момент времени, и при генерации или подписании ключа не происходит утечки закрытой информации.

Для повышения эффективности ZetaChain использует пакетное и параллельное подписание для оптимизации производительности подписывающих лиц.

4.4. Кроссчейн смарт-контракт и Zeta Виртуальная Машина (ZVM)

Смарт-контракты ZetaChain разработаны таким образом, чтобы была возможность напрямую взаимодействовать с состояниями на внешних сетях.

Существует две ключевые проблемы при разработке платформы кроссчейн смарт-контрактов общего назначения: асинхронность и модель программирования.

Первая проблема заключается в том, что связь между сетями обязательно осуществляется посредством передачи сообщений и по своей природе является асинхронной между разнородными сетями.

Это означает, что в отличие от смарт-контрактов на одной цепи (например, EVM), запрос или изменение состояния другой цепи является асинхронным. Это исключает обычные удобные синхронные вызовы функций из кроссчейн смарт-контрактов.

Таким образом, модель программирования кроссчейн смарт-контракта лучше всего рассматривать как автомат конечных состояний, где изменение состояния запускается сообщениями (наблюдениями) от внешних сетей.

Вторая — это модель программирования. Существует две основные парадигмы смарт-контрактов на блокчейне: на основе UTXO и на основе счета. Биткойн, Ergo и Cardano представляют первую, а Ethereum (EVM) — вторую.

В целом, с точки зрения выраженности, EVM — на более высоком уровне, а скрипты на основе UTXO — на более низком. Однако смарт-контракты на базе UTXO обычно проще, надежнее и имеют меньшую поверхность атаки из-за ограничений UTXO.

Например, в скриптах Bitcoin очень редко возникают непредусмотренные ошибки безопасности, в то время как смарт-контракты Ethereum печально известны многомиллионными эксплойтами (атаки re-entrancy и т.д.).

Важнейшим отличием моделей смарт-контрактов на основе UTXO от моделей смарт-контрактов на основе счетов является наличие общего глобального состояния.

Смарт-контракты UTXO привязаны к транзакциям, и они не имеют доступа к глобальному, изменяемому общему состоянию, в то время как модель на основе счетов оставляет практически все состояния общими и изменяемыми. Это ограничение модели UTXO затрудняет или делает невозможным использование некоторых комплексных dApps (таких как AMM, ICO и т.д.), но значительно упрощает вещи.

Скрипт Bitcoin не может поддерживать популярные dApps, такие как AMM DEX. Поэтому возникает вопрос: возможно ли усовершенствовать модель UTXO так, чтобы она была достаточно гибкой для поддержки популярных dApp, например, AMM DEX таких как Uniswap, оставаясь при этом простой и безопасной?

Ergo стала новатором расширенной модели UTXO (eUTXO), а Cardano последовала ее примеру. В Cardano и других платформах eUTXO DEXs AMM могут быть реализованы в определенной степени путем хранения состояния AMM-пары в UTXO.

Однако в этом подходе есть серьезная проблема: Перегрузка UTXO, в результате которой только одна транзакция может стать преемником блока, поскольку только одна транзакция может потратить этот UTXO и создать новый в блоке. Конкурирующие транзакции, пытающиеся потратить один и тот же UTXO, потерпят неудачу и будут вынуждены ждать один блок и тратить новый UTXO. Это неоптимально.

В этой работе мы исследуем гибридный подход, основанный на UTXO и аккаунтах, используя сильные стороны каждого из них. По сути, мы используем UTXO для репрезентации и отслеживания внешних транзакций блокчейна, а смарт-контракты на основе учетных записей — для логики и управления общими глобальными состояниями.

Мы рассматриваем наблюдаемые внешние события как синтетический UTXO. UTXO содержит информацию о количестве монет ZETA (сжигаемых), количестве других монет (необязательно, например, BTC в сети Bitcoin, в которой выпуск монеты ZETA невозможен) и скрипт msg (примерный эквивалент сообщения или вызова функции в Ethereum).

Смарт-контракт на ZetaChain запускает msg и генерирует Event, с помощью которого пытается расходовать UTXO на ZetaChain. Затем это событие подхватывается ZetaClient подписантами, и они подписывают транзакцию на внешней сети.

Виртуальная машина ZetaChain и ZetaClient будут проверять определенные инварианты, один из которых заключается в том, что ZETA на выходе должна быть равна ZETA на входе в UTXO.

После подтверждения и наблюдения исходящей транзакции, UTXO помечается как истраченный и исключается из автомата состояний. Если исходящая транзакция не удалась (недостаточно газа и т.д.), UTXO помечается как возврат, и возврат ZETA и/или соответствующие монеты возвращаются на исходную сеть. Когда возврат подтвержден, UTXO исключается из машины состояний. Для наглядности смотрите Рисунок 4.

Добавьте описание

Мы используем синтетическую модель UTXO из-за ее подотчетности, простоты и масштабируемости, обходя при этом ключевое ограничение UTXO, заключающееся в сложности написания скриптов, и неуклюжести в некоторых важных приложениях (один TX за блок в AMM).

4.5. Транзакция, Субтранзакция, Атомарность

При применении модели UTXO приложение должно обеспечить атомарность транзакции, поскольку транзакция UTXO не может изменить глобальное состояние и отсутствует возможность частичного выполнения.

При использовании модели на основе счета виртуальная машина должна обеспечивать атомарность транзакций.

В кросс-блокчейновом контексте изменение состояния на внешних блокчейнах является асинхронным; кроме того, как правило, трудно возвратить частично выполненную транзакцию, если она регистрируется во внешнем блокчейне.

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

Ключевыми ограничениями являются:

1. Каждый UTXO может генерировать только одно событие выхода. По сути, только одна внешняя цепочка может обновить свое состояние в ответ на UTXO. Поскольку исходящие транзакции во внешних цепочках обычно необратимы (например, отправленные токены не подлежат возврату), несколько выходных Событий сделают нецелесообразным возврат всей транзакции.
2. Все кроссчейн переводы ценностей должны осуществляться в ZETA, поскольку только токен ZETA находится под контролем системы ZetaChain и может быть реверсирован (возвращен), если кроссчейн транзакция не удалась.

Некоторые сложнейшие смарт-контракты, которые имеют несколько выходных операций (например, должны отправляться в несколько сетей), лучше всего писать как многоэтапные транзакции.

Приложение должно самостоятельно обрабатывать атомарность многоэтапной транзакции; см. эту статью [3] для получения дополнительной информации.

5. Токен ZETA

Токен ZETA используется для оплаты газа на смарт-контактах ZetaChain и применяется для обеспечения защиты PoS блокчейна технологии ZetaChain посредством бондинга/стейкинга/слэшинга.

ZETA также служит основой кроссчейн переводов, свопов, передачи сообщений и безопасности ZetaChain. ZETA — один из первых мультичейн токенов, выпускаемый в нескольких сетях и уровнях.

Пользователи могут напрямую перемещать токен ZETA из любой сети A на сеть B. Механизм представляет собой одностороннюю привязку (т.е. сжигание X количества на сети A, а затем минтинг X количества на сети B).

Мы используем наш собственный токен ZETA для обозначения кроссчейн стоимости, так как:

• В отличие от более распространенной двусторонней привязки, здесь нет “обертывания” и, следовательно, нет многократного воспроизведения одного и того же базового актива.
• Единственная (нативная) ценность, которая может передаваться через кроссчейн, — это токен ZETA, что существенно сокращает вектор атак, в результате чего аудит становится более прозрачным и, как следствие, более безопасным. Например, мы можем проверить общий объем предложения на контракте минт сайта.
• Пользователи могут оплачивать токеном ZETA кроссчейн услуги, предоставляемые ZetaChain, и газ на принимающей сети за единый шаг/платеж.

6. Примеры использования и области применения

В этом разделе мы обсудим некоторые примеры применения ZetaChain.

Данные примеры не являются исчерпывающими, поскольку смарт-контракты общего назначения и функциональные возможности ZetaChain предоставляют основу для практически безграничного поиска творческих решений в отношении создания омничейн-приложений.

6.1. Кроссчейн передача сообщений со стоимостью/данными

Возможность надежно и безопасно передавать сообщения от одной сети к другой позволяет создавать мощные кроссчейн приложения, даже без использования нативных смарт-контрактов ZetaChain. Передача сообщений состоит эндпоинтов коммуникации на всех внешних сетях.

Валидаторы ZetaChain служат в качестве византийского отказоустойчивого нотариата, подтверждающего достоверность событий/транзакций в сети A для сети B, а также служат ретранслятором сообщений.

Смарт-контракт сети B должен только внести в белый список TSS-адрес ZetaChain, чтобы подтвердить, что ZetaChain проверила события в сети A. Это позволяет условно использовать контракты на сети B в зависимости от транзакций/сообщений из сети A, что открывает широкий спектр кроссчейн приложений, таких как AMM DEXs, NFT и т.д. (см. подробнее ниже).

Важной и удобной особенностью системы ZetaChain является то, что к сообщениям может быть привязана ценность в виде монеты ZETA (встроенный кроссчейн), что существенно облегчает реализацию приложений, требующих кроссчейн перемещения ценностей.

Сервис передачи сообщений ZetaChain состоит в основном из интерфейсных контрактов на подключенных сетях. Для получения доступа к службе передачи сообщений приложению необходимо развернуть смарт-контракт на исходной сети и сети получения.

В исходной сети отправляющий смарт-контракт может вызвать функцию zeta.MessageSend со следующей информацию: адрес отправителя, идентификатор сети назначения, адрес контракта назначения, монета ZETA для трансфера, лимит газа на сети получения, сообщение контракта для целевой транзакции (двоичная или JSON закодированная информация) и индекс транзакции.

Отправляющий контракт должен имплементировать функцию zetaMessageRevert, вызываемую ZetaChain, в случае неудачи при отправке сообщения получателю и обработке транзакции (например, из-за отсутствия газа, отсутствия средств, недействительного сообщения и т.д.).

При неудаче система ZetaChain произведет возврат ZETA монет отправителю (за вычетом платы за газ) и вызовет функцию zetaMessageRevert в контракте dApp, которая предназначена для реверса действий приложения (например, разблокировки заблокированного НФТ).

На целевой сети контракт dApp должен реализовать функцию zetaMessageReceive, которая принимает те же параметры, что и отправляющая zeta.MessageSend, и может выполнить логику приложения (например, чеканить NFT, который был заблокирован на исходной сети). Контракт получателя также примет ZETA токены (за вычетом платы за газ), которые могут быть использованы в качестве кроссчейн трансфера ценностей.

Передача сообщений позволяет реализовать множество различных важнейших приложений, таких как кроссчейн DEX, заимствование/кредитование, мультичейн NFT и т.д.

6.2. Внешние активы, управляемые смарт-контрактом

Мощной особенностью смарт-контрактов является возможность хранить любые активы, которые может хранить обычный счет, и получать и тратить эти активы в соответствии с запрограммированной логикой.

Тем не менее, такие важнейшие блокчейны, как Bitcoin, Dogecoin, Monero и т.д., не обладают достаточной способностью смарт-контрактов для поддержки таких полезнейших приложений, как биржи AMM, рынки обеспеченных заимствований / кредитования с пулами и т.п.

В настоящее время не существует способа децентрализованно и без разрешения задействовать нативный Bitcoin (необорачиваемый) в произвольной логике. Кроссчейн смарт-контракты ZetaChain могут непосредственно удерживать и использовать активы внешних сетей, что позволяет управлять биткоином на ZetaChain с помощью смарт-контрактов, а также другими активами, такими как ETH, ERC20, Algorand ASAs и т. д.

Помимо этого, благодаря смарт-контрактам ZetaChain и передаче сообщений, кроссчейн dApps могут легко компоноваться со смарт-контрактами на различных сетях, при этом смарт-контракты ZetaChain управляют нативными Bitcoin-хранилищами.

Давайте более подробно рассмотрим на примере. Механизм использования смарт-контрактов ZetaChain для управления BTC в Bitcoin заключается в следующем:

1) При инициализации смарт-контракт запрашивает KeyGen для генерации ключа TSS, который выступает в качестве адреса хранилища Bitcoin.

2) ZetaClient отслеживает адрес TSS и при обнаружении входящих транзакций в хранилище TSS парсит данные транзакции Bitcoin в параметре OP_RETURN и вызывает функцию zetaProcess с парсированными данными на смарт-контракте.

3) Смарт-контракт выполняет соответствующие действия (например, зачисление средств на определенные счета, отправка другого актива в соответствии с ценами AMM и т.д.).

4) Для отправки Bitcoin из смарт-контракта смарт-контракт эмитирует определенное событие, которое ZetaClient подхватывает, подписывает и передает в сеть Bitcoin.

5) Смарт-контракт также должен поддерживать функцию zetaExternalTxConfirm, которая будет задействована при добыче исходящей внешней сетевой транзакции.

6.3. Кроссчейн АММ биржи

ZetaChain позволяет реализовать настоящие кроссчейн децентрализованные биржи AMM, построенные поверх смарт-контрактов. Существует два способа конструирования AMM DEX на ZetaChain: передача сообщений и встроенные смарт-контракты ZetaChain.

Ключевое различие заключается в том, управляется ли пул внешним смарт-контрактом или собственным смарт-контрактом ZetaChain. При передаче сообщений пул активов управляется смарт-контрактами на внешних сетях; при подходе, основанном на использовании смарт-контрактов ZetaChain, пул управляется смарт-контрактами ZetaChain с помощью учетной записи TSS.

Если выражаться более конкретно, то при передаче сообщений управление активами осуществляется смарт-контрактами на внешних сетях в паре с монетой ZETA.

Для обмена актива X на сети A на актив Y на сети B можно выполнить следующие действия:

1) обмен валюты X на ZETA на сети A с помощью управляемого пула смарт-контрактов и AMM;

2) передача сообщения вместе с монетой ZETA из сети A в сеть B;

3) сеть B с помощью управляемого пула смарт-контрактов (Y/ZETA) обменивает монету ZETA на Y.

При использовании встроенных смарт-контрактов ZetaChain на TSS-счете хранятся все основные активы внешних сетей, которыми могут управлять непосредственно контракты ZetaChain. Смарт-контракт ZetaChain реализует логику AMM, которая определяет ценообразование, своп, поставщиков ликвидности и комиссионные сборы.

При использовании метода передачи сообщений состояние и логика dApp распределяются между всеми внешними сетями; ZetaChain выступает только в качестве верификатора и ретранслятора сообщений.

Преимущества такого подхода состоит в том, что существующая инфраструктура может быть использована повторно (например, в EVM-сетях контракты Uniswap могут повторно использоваться для управления пулом X/ZETA), а dApp необходимо только управлять кроссчейн передачей сообщений для осуществления условно-последовательного выполнения.

С другой стороны, при применении “нативного” подхода ZetaChain смарт-контракт, логика и состояние dApp функционируют на ZetaChain, единой платформе с унифицированным интерфейсом для взаимодействия с внешними сетями.

Преимущества данного подхода — простота разработки dApp (минимальные усилия при внедрении новых сетей), и гибкость (больше не ограничены идиосинкразией сети и передачей сообщений при кроссчейн взаимодействии). Дополнительные преимущества — минимальная зависимость от смарт-контрактов на внешних сетях, поэтому усложненная логика может работать не только на сетях смарт-контрактов, но и на сетях UTXO, таких как Биткойн.

Добавьте описание

6.4. Мультичейн NFT

Non-fungible Token (NFT) — это зарождающаяся концепция, нашедшая применение в коллекционировании произведений искусства, играх, билетах на мероприятия и многих других областях. В отличие от взаимозаменяемых токенов, таких как ETH, BTC или токены ERC-20, каждый NFT уникален и неповторим.

Эта невзаимозаменяемость может быть очень важна в таких областях применения, как искусство, недвижимость и т.д.

В Ethereum, например, самыми распространенными стандартами NFT являются ERC-721 и ERC-1155. В ERC-721 NFT представляет собой кортеж (contractAddress, tokenId).

Смарт-контракт, который выпускает NFT, ведёт учёт обладателей каждого NFT в карте owner=>tokenId. NFT может быть передан от одного владельца другому, и к каждому владельцу NFT можно обратиться с запросом.

В мире мультичейн NFT, где одна и та же коллекция выпускается на нескольких сетях (таких как Ethereum, Flow, Solana), и NFT можно перевести на другие сети, то проблемой в модели моста является определение происхождения данной NFT.

Кто является собственником данной NFT в настоящее время, поскольку NFT может находиться на одной из множества сетей, и где находятся записи о транзакциях по переводам?

Добавьте описание

Эту проблему можно решить с помощью смарт-контрактов ZetaChain, которые облегчают кроссчейн передачу прав собственности на NFT.

Это может работать следующим образом. В каждой сети будет создан смарт-контракт эскроу, управляемый ключом ZetaChain. Чтобы перевести NFT на другую сеть, нужно перевести NFT в эскроу, заплатить комиссию за транзакцию в монетах ZETA, и ZetaChain отчеканит NFT на сети получателя. Смарт-контракт на ZetaChain отслеживает владельца и блокчейн, где находится NFT в любой момент времени.

До сих пор существовали экспериментальные кроссчейн мосты NFT, но наличие децентрализованного эмиссионного центра позволяет NFT быть исконно кроссчейн, что упрощает и делает целесообразным процесс создания, верификации и обмена NFT кроссчейн.

7. Безопасность

7.1. Децентрализация

ZetaChain разработана так, чтобы не иметь единой точки отказа, в первую очередь за счет децентрализации. ZetaChain — децентрализованная архитектурно и инфраструктурно.

Децентрализация — это эффективный способ обеспечения отказоустойчивости, противодействия атакам и сговорам.

Узлы ZetaChain управляются отдельными лицами или организациями без разрешения. Отсутствие единой точки отказа в узле ZetaChain (ZetaCore, ZetaClient) не влияет на работу системы.

В то же время для внесения изменений во внешних сетях ZetaChain должна действовать как единый механизм для подписания сообщений, поэтому возникает вопрос о централизованном ключе подписи.

ZetaChain использует схему пороговой подписи без лидера GG20 (TSS), которая выполняет генерацию ключей и подписание ключей распределенным, децентрализованным способом. Ни один узел ZetaChain или иной отдельный участник сети не имеет доступа к децентрализованному распределению. Ни один узел ZetaChain или другой человек никогда не получает доступ к полному приватному ключу в какой-либо момент времени.

По сути, узел ZetaChain (в частности, подписант в ZetaClient) обладает равным “голосом” при подписании исходящих транзакций, как в m/n мультисиге.

Чтобы обеспечить баланс между децентрализацией и координацией, некоторые аспекты ZetaChain не полностью децентрализованы или разработаны так, чтобы развиваться в сторону большей децентрализации постепенно. Например, программное обеспечение на данный момент разрабатывается централизованно, что означает, что система подвержена программным ошибкам из единого источника.

Для защиты от ошибок ZetaChain использует многоуровневую защиту, которая будет более подробно рассмотрена ниже.

7.2. Защита входящих и исходящих транзакций

ZetaCore принимает события от наблюдателей в ZetaClients.

ZetaClients отслеживает события внешних сетей через различные источники, таких провайдеров услуг, как Infura, их (оператора валидатора) собственный экземпляр полного узла, или полный узел под управлением разработчиков и партнеров. Наблюдаемое событие (как входящая транзакция в ZetaChain) должна достичь консенсуса в ZetaCore, чтобы вызвать изменения состояния в ZetaCore.

Изменение состояния в ZetaCore заставляет подписантов ZetaClient подготавливать, подписывать и транслировать транзакции во внешние сети. Механизм консенсуса ZetaChain гарантирует, что что транзакция согласована; ключ TSS гарантирует, что только подавляющее большинство ZetaClient могут подписывать транзакции.

Все входящие/исходящие транзакции и принятые решения (через изменение состояния) регистрируются в блоках ZetaChain, которые доступны, неизменяемы, проверяемы и полностью прозрачны.

7.3. Всесторонняя защита от произвольной чеканки монет

Поскольку единственной собственной ценностью, которая может перемещаться между сетями через ZetaChain, является токен ZETA, а ZetaChain эффективно управляет только передачей токена ZETA из сети A в сеть B, можно предложить всестороннюю защиту от единственного способа кражи ценности из Zetachain: недействительная чеканка, которая завышает общее предложение ZETA по всем сетям.

Мы предлагаем всестороннюю защиту от чеканки без соответствующего сжигания следующим образом:

1) Перед началом чеканки токена ZETA ноды ZetaChain проверяют общее предложение по всем сетям. Это защищает от программных ошибок или уязвимостей в ПО узла ZetaChain.

2) Контракты токенов на сетях (за исключением Ethereum, на котором роль блокирующего контракта будет выполнять контракт) проверяют общее предложение ZETA по всем сетям перед чеканкой.

3) Общий объем предложения ZETA определяется Chainlink и публикуется на каждой подключенной сети.

Такая защита гарантирует, что никто не сможет произвольно чеканить и общее предложение ZETA останется фиксированным во всех сетях.

Следует отметить, что указанные два варианта всесторонней защиты, хотя и обеспечивают надежную защиту от ошибок в программном обеспечении и воровства из ZetaChain (включая каждого владельца токена ZETA), тем не менее, они не устраняют эксплойты. Например, если злоумышленник получит контроль над 2/3 валидаторов, или злоумышленник сможет использовать ошибку в программном обеспечении, он сможет перенаправить легитимный минт от другого пользователя на свой кошелек. Однако в самом наихудшем сценарии последствия, скорее всего, будут незначительными, поскольку злоумышленник может украсть средства только у действующих пользователей в это конкретное время, и система будет быстро остановлена, как только пользователи заметят это.

Итого: средства, подверженные риску в наихудшем сценарии, — это только та сумма ZETA, которая перемещается кроссчейн в момент эксплойта. Остальные средства никогда не подвергаются риску

7.4. Что произойдет, если внешние сети будут атакованы

Если подключенные с помощью ZetaChain внешние сети подвергаются атаке (например, атака 51%), это может привести к следующим неисправностям:

1) Двойное расходование, приводящее к избыточному предложению токена ZETA;

2) Цензурирование;

3) Реверс, ведущий к потере атомарности кроссчейн транзакции, поскольку исходная составляющая может больше не существовать;

4) Хард форк, разделение цепи; и многое другое.

Дизайн ZetaChain может смягчить некоторые из этих случаев или минимизировать ущерб от неограниченного распространения. К примеру, внешняя сеть, вызывающая неограниченный минт (путем многократного возврата и оплаты), невозможна из-за проверки общего предложения на ZetaChain.

В свою очередь, dApps, использующие монету ZETA для кроссчейн передачи стоимости, также защищены от неограниченной инфляции.

Для других внешних сетей, которые эксплуатируются, ZetaChain должна перейти в режим аварийного отключения для оценки ситуации. Восстановление будет осуществляться под координацией заинтересованных сторон и механизмов управления.

8. Заключение

В данном техническом документе мы рассмотрели перспективы межсетевого взаимодействия.

В то время как бриджинг является основным решением на сегодняшний день и находится в центре внимания множества появляющихся проектов, ZetaChain исследует более амбициозный и универсальный подход: встроенные кроссчейн смарт-контракты которые напрямую взаимодействуют практически с любым внешним блокчейном.

Не требуется оборачивать активы для кроссчейн передачи ценностей и не нужны мосты для каждой пары блокчейнов. Смарт-контракт ZetaChain может хранить активы непосредственно на внешних сетях и управлять активами в соответствии с заранее заданной произвольной логикой.

Каждое взаимодействие с внешней сетью осуществляется непосредственно на внешних сетях.

Таким образом, ZetaChain представляет собой платформу для децентрализованных кроссчейн приложений с подключением практически к любому существующему или будущему блокчейну и/или L2/роллапу, с доступом к полному набору активов в этих сетях.