January 9, 2023

ZetaChain: блокчейн із нативною системою Крос-ланцюгових смарт-контрактів

20.02.2022, v0.3.1

ZetaChain
[email protected]

Анотація

У цій технічній документації пропонується ZetaChain, блокчейн із загальною підтримкою смарт контрактів omnichain, який об’єднує як блокчейни смарт-контрактів, такі як Ethereum, Ethereum L2 rollups, Solana, Terra та Algorand, так і навіть блокчейни без cмарт контрактів, такі як Bitcoin і Dogecoin. ZetaChain складається з блокчейну Proof-of-Stake, спостерігачів і підписантів для зовнішніх блокчейнів. Спостерігачі сканують зовнішні ланцюжки на наявність відповідних подій, транзакцій і станів у певний момент часу та досягають консенсусу щодо спостереження на блокчейні ZetaChains. Підписувачі спільно володіють єдиним ключем порогової схеми підпису (TSS), який може надсилати автентифіковані повідомлення до зовнішніх ланцюжків і зберігати активи, як звичайні облікові записи/адреси у зовнішніх ланцюгах. Смарт контракти на ZetaChain підтримують довільну логіку, яка виконується залежно від подій зовнішнього ланцюга, і може безпосередньо оновлювати зовнішні стани ланцюга через свої підписані транзакції TSS. Таким чином, ZetaChain дає змогу omnichain dApps, які взаємодіють із різними блокчейнами безпосередньо та безпосередньо, не обгортаючи та не з’єднуючи жодних активів.

1. Вступ

Важко уявити, що одного блокчейну буде достатньо для всіх випадків використання нашого суспільства. Багатоланцюгове майбутнє здається неминучим. Однак багатоланцюгове майбутнє без взаємодії між блокчейнами може бути аналогічно Інтернету до TCP/IP. Сучасні блокчейни занадто фрагментовані та за своєю природою не сумісні, що перешкоджає масовому впровадженню технологій. Наприклад, децентралізована програма (dApp) має бути одружена з певним блокчейном. Якщо користувач підключається до криптоекосистеми через певний dApp, ця фрагментація створює величезні перешкоди для користувача, щоб плавно прийняти або спробувати dApp в іншому ланцюжку. Для вирішення питань сумісності було зроблено кілька пропозицій і проектів, які спеціально підкреслюють здатність взаємодії. однак, блокчейни для прийняття або через складні, обмежені та/або менш безпечні мости для приєднання (див. Фігура 1). У цьому технічному документі ми пропонуємо новий загальнодоступний блокчейн L1, який активно та агностично з’єднує блокчейни та сприяє взаємодії. Крім того, ми пропонуємо загальний смартконтракт на блокчейні, який може утримувати та маніпулювати активами на зовнішніх блокчейнах безпосередньо, таким чином уможливлюючи загальні смарт-контракти, які можуть зберігати активи на зовнішніх ланцюгах. Це відкриває двері до безмежних міжланцюжкових dApps.

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

ZetaChain - це, перш за все, публічний блокчейн з валідаторами Proof-of-Stake. Передбачається, що переважна більшість (>66% вузлів) вузлів-валідаторів є чесними і діють відповідно до протоколу, а також колективно виконують функції нотаріусів. Крім того, що це блокчейн, інтероперабельність вимагає спостереження за іншими блокчейнами. Таким чином, до кожного вузла-валідатора ZetaChain приєднаний спостерігач, який сканує інші блокчейни на предмет відповідних подій (журнал подій, транзакції або стан в певний момент часу). Спостерігачі повідомляють про відповідні події в ZetaChain і досягають консенсусу. ZetaChain використовує власну логіку для оновлення свого стану у відповідь на отримані повідомлення. З іншого боку, для того, щоб змінити стан в інших блокчейнах, до кожного валідатора також приєднується підписувач, який володіє ключовою часткою. У сукупності всі валідатори володіють єдиною парою публічного/приватного ключа, яка може ініціювати транзакції в інших блокчейнах для безпосередньої зміни стану. Схема підпису може бути якоюсь схемою порогового підпису, наприклад, GG18/GG20 ECDSA/EdDSA, або пороговим/агрегованим підписом BLS, в залежності від криптографії різних ланцюжків та їх можливостей/вартості смарт-контрактів. Наявність єдиного публічного ключа та адреси в системі ZetaChain дозволяє ZetaChain зберігати активи на зовнішніх блокчейнах, які можуть не мати адекватних можливостей смарт-контрактів, таких як Bitcoin. Така можливість дозволяє створювати потужні крос-ланцюгові (або омніканальні) додатки на основі власних смарт-контрактів ZetaChain на основі крос-ланцюгових смарт-контрактів ZetaChain. Ця можливість виглядає дуже схожою на Ethereum, де смарт-контракту можна довіряти управління активами відповідно до заздалегідь визначених правил, за винятком того, що в ZetaChain смарт-контракт може використовувати і управляти активами в будь-якому підключеному блокчейні.Таким чином, ZetaChain розроблено як децентралізовану крос-блокчейн-платформу смартконтрактів. Бачення ZetaChain полягає в тому, щоб бути загальнодоступним комп’ютером у всіх важливих блокчейнах, на основі якого можна легко створювати кросблокчейнові децентралізовані додатки як загальнодоступні, надійні та постійні смарт контракти.

Малюнок 1. До і після ZetaChain. Підмалюнок (a) ліворуч: поточна екосистема. Користувачі та розробники розділені на відповідні ланцюжки, а поточні крос-ланцюгові рішення розрізняються, що призводить до значної, зростаючої фрагментації. Підмалюнок (b) справа: Екосистема з ZetaChain. Користувачі, розробники та програми можуть безперебійно працювати в мережах. Увімкнено нову парадигму Omnichain dApps.

2. Передумови: Еволюція блокчейнів

2.1. Bitcoin: оригінальна децентралізована криптовалюта

Blockchain, піонером якого став біткойн, є децентралізованою публічною книгою без дозволів, побудованою на основі криптографії. Основним механізмом є візантійський відмовостійкий розподілений консенсус, який біткойн розв’язав за допомогою комбінації методів криптографії, економічних стимулів і інформатики. Ключові інновації в біткойнах включають використання алгоритму цифрових підписів еліптичної кривої (ECDSA) для самостійного зберігання коштів, а також використання Proof-of-Work для досягнення розподіленого консенсусу (впорядкування постійно зростаючого журналу транзакцій) і підтримки стійкості до нападає сивіла. Біткойн також представляє перше велике застосування технології блокчейн — криптовалюту p2p. Мережа Bitcoin була дуже успішною, навіть якщо вона не виконала своєї обіцянки стати електронною готівкою. Швидше, біткойн став найбільш безпечним, децентралізованим,

Мережа Bitcoin складається з вузлів, з’єднаних мережею p2p. Серед учасників – користувачі та майнери. Мережа біткойн спільно підтримує зростаючу книгу, яка є послідовністю транзакцій користувачів. Транзакція користувача - це підписане повідомлення, яке витрачає певну кількість монет, контрольованих користувачем. Мережа Bitcoin явно не підтримує стан балансу кожного облікового запису; єдиним станом мережі є набір поточних UTXO — невитрачених виходів транзакцій. Баланс користувача BTC — це сума всіх UTXO, які може витратити користувач. Транзакція користувача включає один або кілька UTXO як вхідні дані та створює один або більше UTXO як вихідні дані, таким чином змінюючи стан (набір UTXO). Біткойн підтримує обмежену форму сценаріїв: транзакція може надсилати монети до сценарію, і будь-хто, хто може задовольнити сценарій (тобто надати дані, щоб зробити його оцінкою 1), може витратити монети. Мова сценаріїв є навмисне простою та неповною за Тьюрінгом — а саме без структур розгалужень і циклів — але підтримує чимало простих, але фундаментально корисних програм, таких як multi-sig, атомарні свопи тощо.

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

Хоча біткойн концептуально є простим обліковим записом (упорядкованою послідовністю транзакцій) із базовими функціями сценаріїв, який служив канонічним прикладом блокчейну, це не межа можливостей блокчейну. Наприклад, через обмежений обсяг функції перевірки протоколу Bitcoin неможливо випускати нові монети в мережі Bitcoin. Мережа Bitcoin не є програмованою в тому сенсі, що можна реалізувати довільну функцію переходу стану. Єдиною функцією переходу стану, яку підтримує біткойн, є жорстко закодована зміна набору UTXO. Таким чином, жодні інші додатки, окрім валюти BTC, не можуть використовувати мережу біткойн, успадковуючи її консенсус, децентралізацію та безпеку. Щоб розширити сферу застосування блокчейну для підтримки повного програмування за Тьюрингом, народився Ethereum. Ethereum запозичив Proof-of-Work у Bitcoin для свого консенсусу та зробив кілька важливих нововведень, які зробили його публічним програмованим блокчейном. По-перше, Ethereum визначає віртуальну машину (EVM), яка забезпечує повне пісочничне середовище Turing для визначення довільних функцій переходу стану (смарт контракти). По-друге, Ethereum відходить від моделі UTXO в біткойнах до системи на основі облікових записів, де зберігається стан облікових записів. Існує два типи облікових записів: зовнішні облікові записи (EOA), якими керує закритий ключ, і облікові записи смарт-контрактів, які працюють автономно відповідно до власної логіки. Доступність смарт-контрактів на Ethereum робить його одним із найпоширеніших блокчейнів dApp із тисячами розгорнутих додатків, таких як похідні фінансові інструменти, біржі, NFT, азартні ігри та ігри. Смарт контракти в Ethereum схожі на об’єкти в об’єктноорієнтованій мові програмування, де можна зберігати стан і викликати функції, щоб змінити його стан. Користувачі можуть взаємодіяти зі смарт-контрактами, надсилаючи їм повідомлення, а смарт-контракти також можуть надсилати повідомлення іншим смартконтрактам (викликаючи), щоб змінити свій стан. Смарт контракти можуть увімкнути дуже складні програми та деякі дуже потужні операції, такі як флеш-позики або флеш-свопи, які не мають аналогів у програмах, не пов’язаних з блокчейном. Це стало можливим завдяки потужній атомарності транзакції, яка викликає функції смарт-контракту: вона або завершується, або повністю повертається. З роками з’явилося все більше і більше блокчейнів, таких як Polkadot, Solana, Avalanche і Cosmos, які підтримують смарт-контракти, майже повні за Turing.

2.3. Виникнення та виклики мультиланцюгів

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

Популярні крос-ланцюгові або крос-блокчейн-стратегії включають сайд-чейни, реле, нотаріальні схеми, хешконтракти з блокуванням часу та блокчейни блокчейнів. По-перше, бічні ланцюги/ретранслятори є популярними рішеннями для реалізації мостів, які передусім забезпечують портативні активи. У них деякі активи мають домашню книгу, яка є авторитетною щодо їх власності, але через мости можна перемістити актив в інші блокчейни, будучи впевненим, що актив зможе повернутися до домашнього блокчейну. Ретрансляція є одним із прямих механізмів для сприяння взаємодії, де замість того, щоб покладатися на надійного посередника для надання інформації про ланцюжок A ланцюжку B, ланцюжок B реалізує тонкий клієнт ланцюжка A за допомогою смартконтрактів і може перевірити, чи конкретна подія , транзакція або стан у певний момент часу відбулися в ланцюжку A. Це часто називають безнадійним, оскільки немає додаткового припущення довіри, окрім довіри двом залученим ланцюгам. Іншими словами, довіри до дійсності механізму доставки повідомлень від ланцюга A до ланцюжка B не потрібно, окрім того, що повідомлення доставлено та доставлено вчасно. Приклади реле включають BTCRelay на Ethereum (SPV-клієнт Bitcoin) і міст Rainbow Ethereum на блокчейні NEAR. Реле також є популярними механізмами для бічних ланцюгів. Приклади реле включають BTCRelay на Ethereum (SPV-клієнт Bitcoin) і міст Rainbow Ethereum на блокчейні NEAR. Реле також є популярними механізмами для бічних ланцюгів. Приклади реле включають BTCRelay на Ethereum (SPV-клієнт Bitcoin) і міст Rainbow Ethereum на блокчейні NEAR. Реле також є популярними механізмами для бічних ланцюгів.

По-друге, нотаріальні схеми — це механізми, у яких довіреній особі (або групі) доручається нотаріально завіряти претензії, такі як подія X, що відбулася в блокчейні A. Найбільш очевидні нотаріальні схеми — це централізовані біржі, які є довіреними організаціями для полегшення кросблокчейн обміну монетами . Нотаріальні схеми не повинні бути централізованими; наприклад, проект Interledger у його атомарному режимі можна класифікувати як децентралізовану, візантійську відмовостійку нотаріальну схему для полегшення міжреєстраційних переказів. Зверніть увагу, що нотаріальні схеми є найбільш гнучкими з точки зору варіантів використання сумісності, оскільки вони здатні діяти з довільною логікою у відповідь на події в дискретних блокчейнах. Ще однією помітною децентралізованою нотаріальною схемою є THORChain, яка реалізує DEX для нативних монет у кількох різних мережах,

По-третє, хеш-контракти блокування часу (HTLC) — це конструкції смарт-контрактів, які можуть

Таблиця 1. Порівняння існуючих міжланцюжкових стратегій

cприяти атомарним свопам між ланцюжками блокчейнів без довіри без додаткової довіри за межами двох блокчейнів-учасників. Ключові слова атомарний і безнадійний. Атомарний означає, що транзакції (за участю двох сторін) або завершені, або скасовані (наче нічого не сталося). Trustless означає, що жодній третій стороні не потрібно довіряти для атомарного обміну. Це приблизно працює двома сторонами, які інтерактивно розгортають і взаємодіють з смарт контрактами з обох сторін. Основна ідея полягає в хеші секрету, який створюється стороною А і використовується обома сторонами, і сторона А змушена розкрити секрет, коли вимагає монету сторони Б, яку потім може використовувати сторона Б, щоб претендувати на монету сторони А. Приклади HTLC включають XClaim BTC/Ethereum або BTC/Polkadot bridge, а також Lightning Network на біткойнах.

По-четверте, блокчейни блокчейнів (BoB) — це фреймворки, які надають рівні даних, мережі, консенсусу, стимулів і контрактів для побудови блокчейнів для конкретної програми, які взаємодіють між собою. Зверніть увагу, що BoB не вирішує поточні проблеми сумісності безпосередньо. Скоріше це дозволяє створювати нові взаємосумісні блокчейни. Щоб під’єднатися до застарілих ланцюгів, необхідно використовувати якийсь міст або інший механізм, показаний вище. Важливими прикладами BoB є Polkadot і Cosmos, побудовані на основі Substrate і Tendermint як механізми консенсусу, а також XCMP і IBC як міжланцюгові протоколи зв’язку.

Кожна з цих широких стратегій має свої сильні та слабкі сторони в технічній складності, припущеннях довіри, рівні сумісності та варіантах використання. Наше обговорення тут є коротким і неповним, але все ж ми можемо дуже приблизно класифікувати характеристики цих стратегій; Дивитися Таблиця 1 для порівняння цих стратегій.

3. Робота, пов'язана з функціональною сумісністю

У цьому розділі ми вибираємо деякі з останніх і найбільш актуальних проектів, ідей і тенденцій, щоб забезпечити контекст для цієї статті та ZetaChain. Щоб дізнатися більше про наукові крос-блокчейн дослідження, зверніться до всебічного опитування [1].

3.1. Перехресний зв'язок

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

BTCRelay [5], Райдужний міст [6]: Розглянемо завдання побудови одностороннього мосту на Ethereum з Bitcoin. Коли користувач Bitcoin надсилає 1 BTC на вказану адресу зберігання, один загорнутий BTC видається на Ethereum. Щоб зробити це надійним способом, смартконтракт на Ethereum може перевірити транзакцію на Bitcoin та випустити відповідну загорнуту монету BTC на Ethereum. Таким прикладом є BTCRelay. Для смарт-контракту Ethereum для перевірки транзакції з біткойнами хтось (служба поза мережею) може надіслати транзакцію разом із підтвердженням транзакції Merkle. Смарт-контракт Ethereum перевіряє докази на основі ланцюжка заголовків блоків, що зберігаються в смарт-контракті. Цей смарт-контракт, по суті, є легким клієнтом Bitcoin. Незважаючи на те, що міцність доказу трохи нижча, ніж повний вузол (був би вразливий до певних атак 51%), цей тип мосту є міцним і надійним, хоча і досить дорогим в експлуатації, оскільки ланцюжок заголовків блоків потрібно постійно оновлювати в смарт-контракті. Rainbow Bridge також є хорошим прикладом надійного мосту між Ethereum і NEAR.

Wormhole [20]: Wormhole також є міжланцюговою службою доставки повідомлень, але вона не є надійною. Швидше, це залежить від набору вузлів перевірки, щоб засвідчити дійсність доставленого повідомлення. Розглянемо те саме завдання побудови одностороннього мосту на Ethereum від Solana. Коли користувач надсилає 1 SOL на певну адресу зберігання, один загорнутий SOL видається на Ethereum. Смарт контракт Ethereum не перевіряє транзакцію на Solana, щоб випустити загорнуту монету; він вірить, що супер більшість набору валідаторів Wormhole є чесними та правильними. Безпека Wormhole залежить від чесності більшості валідаторів. Схоже, що Wormhole покладається на репутацію валідаторів, щоб зміцнити довіру.

LayerZero [14]: LayerZero — це комунікаційний рівень для полегшення доставки повідомлень між мережами. По суті, це слабша форма Relay (див. вступ до Relay). Ідея полягає в тому, щоб дозволити ланцюжку B перевірити, чи певна транзакція чи подія сталася в ланцюжку A. Якщо ланцюжок B підтримує загальні смарт-контракти, легкий клієнт ланцюжка A може бути реалізований у смарт-контракті, щоб перевірити інформацію про ланцюг A. недовірливим способом. Однак навіть легкий клієнт може бути дорогим для роботи в розумному контракті як з точки зору обчислень, так і зберігання; наприклад, BTCRelay на Ethereum, здається, припинено. LayerZero зменшує ці витрати за допомогою надлегкого клієнта на смарт-контракті, який не звітує та не зберігає весь ланцюжок заголовків блоків (або значну його частину). швидше, LayerZero покладається на довіру до заголовка блоку без ланцюжка заголовків блоку, який може відстежити назад до деякого відомого надійного блоку. Ключове припущення безпеки LayerZero полягає в тому, що дві сторони — Relayer, яка надає підтвердження транзакції, та Oracle, яка надає заголовок блоку, — не змовляються між собою. Згідно з нашою термінологією та класифікацією, LayerZero не є безнадійним через довіру, необхідну для незалежності двох сторін. Ми використовуємо більш суворе визначення ненадійного, оскільки дійсність (не обов’язково живучість, стійкість до цензури) повідомлень не залежить від довіри до LayerZero не є безнадійним через довіру, необхідну для незалежності двох сторін. Ми використовуємо більш суворе визначення ненадійного, оскільки дійсність (не обов’язково живучість, стійкість до цензури) повідомлень не залежить від довіри до LayerZero не є безнадійним через довіру, необхідну для незалежності двох сторін. Ми використовуємо більш суворе визначення ненадійного, оскільки дійсність (не обов’язково живучість, стійкість до цензури) повідомлень не залежить від довіри до що-небудь, крім двох блокчейнів-учасників. Якщо ретранслятор і оракул вступають у змову, вони можуть обдурити LayerZero, створивши недійсний заголовок блоку (коштує близько 2 ефірів для обчислення PoW nonce, що є винагородою coinbase за кожен блок), і змусити ланцюг B повірити, що відбулася неіснуюча транзакція у ланцюжку A. LayerZero фактично передає свою безпеку стороннім ретрансляторам і оракулам.

IBC [11]: протокол Inter-Blockchain Communication (IBC) — це TCP/IP-подібний протокол для зв’язку між суверенними блокчейнами. IBC — це наскрізний, орієнтований на з’єднання протокол із збереженням стану між блокчейнами. На практиці для IBC зазвичай потрібні швидкі ланцюжки завершеності, такі як Tendermint, а блокчейн має підтримувати протокол IBC, наприклад ланцюжки, створені за допомогою Cosmos SDK. Для блокчейнів, які підтримують IBC, вони можуть встановлювати з’єднання, і через ці з’єднання один блокчейн може перевіряти докази проти консенсусних станів іншого блокчейну. Кожен блокчейн, який підтримує IBC, повинен запускати полегшений клієнт, здатний перевіряти докази в іншому блокчейні, щоб їх можна було підключити. Модуль IBC також повинен обробляти створення доказів, а окремий процес (ретранслятор) повинен передавати пакет і докази в ланцюжок контрагентів. Серед блокчейнів, які підтримують IBC, можна встановити дуже міцну взаємодію, таку як передача монет, атомарні свопи, міжланцюгові децентралізовані обміни та навіть міжланцюгові розумні контракти. Основним недоліком IBC є те, що він вимагає прийняття, що є великим запитом щодо інших блокчейнів, а також може бути неможливим для застарілих блокчейнів.

3.2. Передача активів між блоками

Hop [10]: Hop — це протокол для надсилання монет через зведення та їх базовий L1 без довіри. За замовчуванням зведені системи є ізольованими системами, і передача активів між зведеними пакетами та L1 може бути повільною та дорогою. Наприклад, для оптимістичного зведення зазвичай потрібен тиждень, щоб вийти на L1; з іншого боку, zk-rollups можуть миттєво підтвердити вихід, але це передбачає великі обчислення, які є дорогими на L1. Hop вирішує проблему переміщення монет через зведення, створюючи бриджі та бридж-койни, а також використовує ринки AMM для обміну монетами, а не надсилає монети напряму. Зокрема, Hop створює мостові монети для кожного зведення, і мостові монети можна переміщувати партіями, щоб зменшити вартість. Бридж-койн виступає в якості проміжного активу при передачі монети з зведення A на зведення B. Hop використовує існуючі мости згортання для виконання перехресних транзакцій, тому йому не потрібна окрема служба поза мережею.

Connext [4]: Connext — це мінімізоване рішення для міжланцюгового обміну активами. Ідея чимось нагадує узагальнений атомарний своп із використанням заблокованих контрактів (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 користувач блокує зовнішній актив (наприклад, біткойн), а система генерує загорнуту версію біткойна, що належить нещодавно згенерованому розповсюдженому закритому ключу TSS. Система генерує адресу в Bitcoin, і користувач переказує Bitcoin на цю адресу. Після завершення передачі вузол Fusion отримує підтвердження в мережі Bitcoin і видає загорнуту версію BTC користувачеві в мережі Fusion. Таким чином, блокування завершено. Процес блокування аналогічний, але навпаки. Схоже, що Multichain — це міст, який блокує монети на з’єднаних ланцюгах і обертає їх на блокчейні Fusion. Таким чином, мультичейн можна розглядати як централізований міст.

THORChain [16], Sifchain [19], Chainflip [17]: THORChain (разом із аналогічними конкурентами, такими як Sifchain і Chainflip) — це децентралізована мережа ліквідності, яка сприяє створенню нативних монет L1 у стилі AMM на різних блокчейнах, зокрема Bitcoin, Litecoin, Bitcoin Cash, Ethereum. Примітно, що THORChain не є, строго кажучи, мостом, оскільки він не блокує та не обертає монети та не здійснює транзакції з обгорнутими монетами. Швидше, THORChain — це спеціальний блокчейн програми, який підтримує пул, логіку та керування сховищами в різних ланцюгах для обміну. THORChain поширює ключ підпису за допомогою схеми GG20 TSS і має власну реалізацію на основі бібліотеки TSS Binance. ZetaChain частково натхненний дизайном THORChain, і її можна розглядати як простішу та більш узагальнену платформу, яка дозволяє не лише обмінюватися, але загальна платформа смарт-контрактів, яка дозволяє легко створювати довільні кросчейн-додатки. Наприклад, розробники можуть реалізувати аналогічну функціональність THORChain як смарт-контракт на ZetaChain.

Synapse [15]: Згідно з загальнодоступною інформацією, Synapse має бути зовнішньо перевіреною системою на основі набору валідаторів для міжланцюжкових обмінів. Він випускає смарт-контракти AMM на зовнішніх ланцюжках і деякі композитні стейблкойни як проміжний актив для кросчейну. Для переміщення посередницьких стейблкойнів між ланцюгами, здається, використовується стратегія спалювання та карбування. На момент написання цієї статті детальна публічна інформація про їх механізм перевірки недоступна.

3.3. Смарт-контракт крос-блокчейн

Quant Network [21]: З точки зору функціональності, мережа Quant і її Overledger [21] є найближчим до ZetaChain. Мережа Quant — це централізований сервіс, який забезпечує стандартизований доступ на основі веб-сервісу до підключених публічних або приватних блокчейнів, або регіональні застарілі книги баз даних. Він підтримує загальну можливість програмування, викликану подіями в цих блокчейнах (транзакція до/з заданої адреси, взаємодія смарт-контракту, події, зміни стану тощо), за допомогою популярних мов і фреймворків, таких як Javascript, Java, Python тощо. ZetaChain прагне досягти подібної загальної програмованості, але з стимульованим публічним блокчейном, із значно меншими припущеннями довіри, більшою прозорістю, повною перевіреністю та можливістю перевірки.

ICP/Chain-Key [2]: Інтернет-комп’ютерний протокол (ICP) пропонує забезпечити взаємодію з мережею біткойн за допомогою технології Chain-Key, яка схожа на схему розподіленого порогового підпису. За допомогою Chain Key ICP в принципі може зберігати кошти в мережі Bitcoin. Незрозуміло, як ICP спостерігає за мережею Bitcoin і як їх платформа смарт-контрактів взаємодіє із зовнішніми блокчейнами.

HyperService [12]: HyperService пропонує крос-ланцюгову платформу смарт-контрактів, яка не залежить від ланцюга. Він складається з двох компонентів: високорівневої мови HSL для опису крос-ланцюжкового dApp і рівня виконання, який забезпечує фінансові атомарні транзакції.

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

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

З іншого боку, в екосистемі 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, який є частково синхронним алгоритмом консенсусу Byzantine Fault Tolerant (BFT). Кожен вузол валідатора може голосувати за пропозиції щодо блоків із силою голосування, пропорційною об’єднаним стейкінгам (ZETA). Кожен валідатор ідентифікується його консенсусним відкритим ключем. Валідатори повинні постійно бути онлайн, готові брати участь у виробництві блоків, що постійно зростає. В обмін на свої послуги валідатори отримають винагороду за блоки та потенційно інші винагороди, такі як комісія за газ або комісія за обробку, пропорційно їхнім прикріпленим стейкінгам.

Спостерігачі: Ще одна група важливих учасників консенсусу ZetaChain — це спостерігачі, які досягають консенсусу щодо подій і станів зовнішнього ланцюга. Спостерігачі спостерігають за зовнішніми підключеними ланцюжками певні відповідні транзакції/події/стани на певних адресах через свої повні вузли зовнішніх ланцюжків. Спостерігачів можна додатково розділити на дві ролі: секвенсер і верифікатор. Секвенсор виявляє відповідні зовнішні транзакції/події/стани та звітує верифікаторам; верифікатори перевіряють і голосують на ZetaChain для досягнення консенсусу. Для системи потрібен принаймні один секвенсор і кілька верифікаторів. Секвенсору не потрібно довіряти, але для живості потрібен принаймні один чесний секвенсор.

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

На практиці всі вищезазначені ролі (окрім секвенсора) розташовані в одному комп’ютерному вузлі, спільно використовують програмне забезпечення та облікові дані, такі як ключі перевірки та пов’язані ставки, а також пов’язані винагороди/різання. ZetaChain планує з часом перейти від Proofof-Authority до повністю делегованої моделі Proof-of-Stake (DPoS), а також поступово делегувати управління блокчейном власникам монет ZETA за допомогою голосування в мережі.

малюнок 2. Архітектура високого рінвя Zetachain

4.2. Спостерігачі

Спостерігачам доручено стежити за зовнішніми мережами для відповідних транзакцій. Спостерігачі постійно сканують події зовнішнього ланцюга, відповідальні за запис і карбування нативної монети (ZETA), повідомлення та виклики смарт-контрактів, а також інші події, які dApps реєструють на ZetaChain. Кожен спостерігач незалежно спостерігає, використовуючи власний повний вузол зовнішніх ланцюжків, і всі спостереження повинні досягти консенсусу щодо ZetaChain, перш ніж вважатися завершеними. Після завершення подій автоматично запускається виконання логіки ZetaChain, яку можна визначити як спеціальний модуль Cosmos SDK або власний смарт-контракт ZetaChain.

Існує два режими спостереження: активний і пасивний. Активне спостереження постійно сканує зовнішні блокчейни на предмет відповідних транзакцій/подій/станів. Пасивний режим покладається на секвенсор (або його невеликий набір) для сканування та звітування про транзакції/події разом із доказом Merkle. Спостерігачі перевіряють докази та досягають консенсусу щодо перевірки в ланцюжку. Перевага активного режиму полягає в тому, що він завжди активний і стійкий до цензури завдяки децентралізації, але вартість кожного вузла висока, оскільки для сканування потрібні повні вузли (зовнішніх ланцюжків). Пасивний режим набагато дешевший, оскільки верифікацію можна проводити за допомогою легкого клієнта. Потрібен лише один або кілька секвенсорів доступ до повного вузла, який набагато дешевший і значно спрощує масштабування до кількох зовнішніх ланцюжків і більшої кількості вузлів перевірки. Недоліком пасивного режиму є те, що активність зовнішнього ланцюжкового вхідного спостереження залежить від секвенсора, а також піддається цензурі секвенсором. Це та сама ситуація, що й оптимістичне зведення, де живучість зведення залежить від секвенсора. Щоб пом’якшити це, кожен може бути секвенсером, якщо він цього захоче, і секвенсер може бути стимульований створенням конкурентного ринку. Зокрема, dApps мають особисту зацікавленість у запуску секвенсора. Ще одна перевага запуску пасивного режиму спостереження за допомогою секвенсора полягає в тому, що dApps контролюють порядок спостереження. З міркувань ефективності активний режим не передбачає впорядкування спостереження.

4.3. Багатостороння порогова схема підпису

ZetaChain потрібен обліковий запис у зовнішніх ланцюгах, щоб зберігати кошти в цьому ланцюзі (керувати пулом, сховищем тощо), а також виконувати привілейовані дії (спалювати, карбувати, переміщувати кошти зі сховища тощо). Це потрібно для крос-ланцюгових смартконтрактів загального призначення, оскільки основною особливістю смарт-контрактів є автономне управління активами. Наприклад, в Ethereum смарт-контракт має адресу та може містити будь-який актив, як-от зовнішня адреса (EOA, звичайний обліковий запис користувача). Ця можливість дає змогу використовувати багато потужних програм, таких як пули AMM, пули кредитування/позичання тощо, де користувачі об’єднують свої активи та дозволяють смарт-контрактам керувати ними відповідно до заздалегідь визначених правил смарт-контрактів. Щоб мати обліковий запис, ZetaChain повинен мати закритий ключ. Щоб уникнути єдиної точки відмови (єдине розташування закритого ключа.

Це також необхідно для підтримки ланцюжків без смарт-контрактів, таких як Bitcoin, Dogecoin або платформ смарт-контрактів, перевірка кількох підписів на яких є дорогою. Щоб уникнути будь-якої єдиної точки відмови, ZetaChain використовує найсучаснішу схему багатостороннього порогового підпису (TSS) [8,9] на основі реалізації від THORChain TSS [16] і Binance tsslib [13]. Для зовнішнього світу валідатори ZetaChain спільно володіють єдиним приватним ключем ECDSA/EdDSA, відкритим ключем і адресою, а підпис, підписаний ZetaChain, може бути ефективно перевірений за допомогою стандартної процедури перевірки ECDSA/EdDSA підключеними блокчейнами. Всередині приватний ключ генерується без дилера, і приватний ключ поширюється в усіх валідаторах. Жодного разу жодна сутність або меншість валідаторів не можуть зібрати приватний ключ і підписати повідомлення від імені всієї мережі. Генерація ключів і процедури підписання виконуються багатосторонніми обчисленнями (MPC), які не розкривають жодного секрету будьякого вузла-учасника. Оскільки ZetaChain може зберігати ключ і адресу TSS, ZetaChain може підтримувати смарт-контракти, які можуть керувати власними сховищами/пулами в підключених мережах, включаючи біткойни. Це фактично додає можливості смарт-контрактів до мережі біткойн і, можливо, до інших блокчейнів, які не є смарт-контрактами. TSS, який використовує ZetaChain, дає

малюнок 3. Leaderless TSS Keygen і Keysign

формування та зручність гарячого гаманця з рівнем безпеки холодного гаманця. Дивитися малюнок 3 для ілюстрації.

Щоб підписувати децентралізований спосіб, ZetaChain використовує багатосторонню систему , 𝑡, 𝑛-порогова схема ECDSA на основі [8]. Ця схема безлідерного порогового підпису (TSS) виконує генерацію ключів і підпис розподіленим способом. Тобто жоден валідатор або сторонній актор не має доступу доповний приватний ключ у будь-який момент часу, і жодна приватна інформація не витікає під час створення ключа або підписання. Для підвищення ефективності ZetaChain використовує пакетне підписання та паралельне підписання для покращення пропускної здатності підписувачів.

4.4. Смарт-контракт крос-ланцюга та віртуальна машина Zeta

Смарт-контракти ZetaChain розроблені, щоб мати можливість безпосередньо взаємодіяти з державами в зовнішніх мережах.

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

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

Друга – це модель програмування. Існує дві основні парадигми смарт-контрактів у блокчейні: на основі UTXO та на основі облікового запису. Bitcoin, Ergo та Cardano представляють перший, а Ethereum (EVM) — другий. Загалом, з точки зору виразності EVM вище, а UTXO-скрипти нижче. Однак смарт-контракти на основі UTXO зазвичай простіші, надійніші та мають меншу поверхню для атаки через обмеження UTXO. Наприклад, сценарії Bitcoin дуже рідко мають ненавмисні помилки безпеки, тоді як смарт-контракти Ethereum сумно відомі багатомільйонними експлойтами (атаки повторного входу тощо).

Критичною відмінністю між моделями смарт-контрактів на основі UTXO та моделей смартконтрактів на основі облікового запису є спільний глобальний стан. Смарт-контракти UTXO додаються до транзакцій, і вони не мають доступу до будь-якого глобального змінного спільного стану, тоді як модель на основі облікового запису залишає практично всі стани спільними та змінними. Це обмеження моделі UTXO ускладнює або робить неможливим вираження певних складних dApps (таких як AMM, ICO тощо), але це значно спрощує речі. Біткойн-скрипт не підтримує такі популярні dApps, як AMM DEX.

Тож постає питання: чи можемо ми розширити модель UTXO, щоб вона була достатньо виразною для підтримки популярних dApps, таких як AMM DEX у стилі Uniswap, залишаючись простою та безпечною? Ergo стала піонером розширеної моделі UTXO (eUTXO), і Cardano наслідував її приклад. У Cardano та інших платформах eUTXO AMM DEX можуть бути реалізовані певною мірою шляхом збереження стану пари AMM в UTXO. Однак у цьому підході є серйозна проблема: перевантаження UTXO, що означає, що лише одна транзакція може бути успішною за блоком, оскільки лише одна транзакція може витратити цей UTXO та створити новий у блоці. Таким чином, конкуруючі транзакції, які намагаються витратити той самий UTXO, зазнають невдачі й повинні чекати одного блоку та витратити новий UTXO. Це неоптимально.

У цій статті ми досліджуємо гібридний підхід UTXO та облікових записів, враховуючи сильні сторони кожного з них. По суті, ми використовуємо UTXO для представлення та відстеження зовнішніх транзакцій блокчейну, а також використовуємо смарт-контракти на основі облікових записів для логіки та керування спільними глобальними станами. Ми розглядаємо спостережувані зовнішні події як синтетичний UTXO. UTXO містить кількість монети ZETA (спалена), кількість іншої монети (необов’язково, наприклад, BTC у мережі біткойн, де неможливо випустити монету ZETA), а також повідомлення сценарію (приблизно еквівалентне повідомленню або виклику функції на Ethereum). Смарт контракт на ZetaChain запускає повідомлення та генерує подію, яка намагається витратити UTXO на ZetaChain. Потім подію підбирають підписанти ZetaClient, і вони підписують транзакцію до зовнішнього ланцюжка. Віртуальна машина ZetaChain і ZetaClient перевірятимуть певні інваріанти, одним із яких є те, що вихідний ZETA має дорівнювати вхідному ZETA в UTXO. Після підтвердження вихідної транзакції UTXO позначається як витрачений і видаляється з кінцевого автомата. Якщо вихідна транзакція не вдається (недостатньо газу тощо), UTXO позначається як повернення, а відшкодування ZETA та/або пов’язаних монет відшкодовується в ланцюжку джерела. Коли повернення коштів

Малюнок 4. Гібридний потік UTXO-рахунків.

підтверджується, тоді UTXO видаляється з кінцевого автомата. Дивитися малюнок 4 для ілюстрації.

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

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

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

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

1.                     Кожен UTXO може генерувати лише один вихідПодія.По суті, лише один зовнішній ланцюг може оновити свій стан у відповідь на UTXO. Оскільки вихідні транзакції на зовнішніх ланцюжках зазвичай не можна повернути (наприклад, надіслані токени не можна прийняти назад), багаторазовий вихідПодіяs унеможливить скасування всієї транзакції.

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

Деякі складніші смарт-контракти, які повинні мати кілька вихідних транзакцій (наприклад, повинні надсилати в кілька ланцюжків), найкраще писати як багатоетапні транзакції. Програма повинна обробляти атомарність багатоетапної транзакції сама; подивіться цей документ [3] для натхнення.

5. Токен ZETA

Токен ZetaChains ZETA використовується для сплати зборів за газ для розумного контакту ZetaChain і додатково використовується для захисту блокчейну PoS ZetaChain шляхом зв’язування/стейкинга/ слешингу. ZETA також лежить в основі міжланцюгової передачі, обміну, доставки повідомлень і безпеки ZetaChains. ZETA — це один із перших багатоланцюжкових токенів, який нативно випускається на кількох ланцюжках і рівнях.

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

Ми використовуємо власний токен ZETA для представлення перехресного ланцюжка вартості, оскільки:

•                      На відміну від більш поширеної двосторонньої прив’язки, немає обгортання і, отже, немає багаторазового представлення того самого базового активу.

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

•                      Користувачі можуть платити ZETA за міжланцюгову послугу, яку надає ZetaChain, і за газ у ланцюзі призначення за один крок/пакет.

6. Випадки використання та програми

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

6.1. Передача міжланцюжкового повідомлення зі значенням/даними

Можливість надійної та безпечної передачі повідомлень від одного ланцюга до іншого може створити потужні міжланцюгові додатки навіть без власних смарт контрактів ZetaChain. Функція передачі повідомлень складається з кінцевих точок зв’язку на всіх зовнішніх ланцюгах. Валідатори ZetaChain служать візантійським відмовостійким нотаріусом, який засвідчує дійсність подій/транзакцій у ланцюжку A до ланцюга B, а також як ретранслятор повідомлень. Смарт-контракту ланцюжка B потрібно лише внести в білий список адресу TSS ZetaChain, щоб бути впевненим у тому, що ZetaChain перевірив події в ланцюжку A. Це дозволяє умовне виконання контракту ланцюга B залежно від транзакцій/повідомлень від ланцюга A, що відкриває широкий спектр міжланцюгові dApps, такі як AMM DEX, NFT тощо (докладніше див. нижче). Важливою та зручною особливістю системи ZetaChain є те, що до повідомлень можна прикріпити значення у вигляді монети ZETA (нативно кросчейн), що значно спрощує dApps, які потребують переміщення значення кросланцюжка.

Служба обміну повідомленнями ZetaChain складається в основному з інтерфейсних контрактів на підключених ланцюгах. Щоб отримати доступ до служби передачі повідомлень, dApp має розгорнути смарт-контракт як у ланцюзі джерела, так і в ланцюзі призначення. У вихідному ланцюжку смарт-контракт-відправник може викликати функцію zeta.MessageSend із такою інформацією: адреса відправлення, ідентифікатор ланцюжка призначення, адреса контракту призначення, монета ZETA для передачі, ліміт газу в ланцюжку призначення, повідомлення контракту для транзакції призначення (двійковий або корисне навантаження в кодуванні JSON) та індекс транзакції. Контракт надсилання має реалізовувати функцію zetaMessageRevert, яка буде викликана ZetaChain, коли доставка повідомлення одержувача та обробка транзакції не вдається (наприклад, через відсутність газу, коштів, недійсне повідомлення тощо). У разі збою система ZetaChain поверне монету ZETA на адресу відправлення (без плати за газ) і викличе функцію zetaMessageRevert контракту dApp, яка має скасувати дії програми (наприклад, розблокування заблокованого NFT). У цільовому ланцюжку контракт dApp має реалізовувати функцію zetaMessageReceive, яка приймає ті самі параметри, що й відправник zeta.MessageSend, і може виконувати логіку програми (наприклад, карбувати NFT, заблокований у вихідному ланцюжку). Контракт призначення також отримає монету ZETA (за вирахуванням комісії за газ), яку можна використовувати як перехресний переказ вартості.

Передача повідомлень може увімкнути низку важливих програм, таких як міжланцюгові DEX, запозичення/позики, багатоланцюгові NFT тощо.

6.2. Зовнішні активи, керовані смарт-контрактами

Потужною особливістю смарт-контрактів є те, що смарт-контракти можуть містити будь-які активи, які може містити звичайний обліковий запис, і можуть отримувати та витрачати цей актив відповідно до запрограмованої логіки. Однак такі важливі блокчейни, як Bitcoin, Dogecoin, Monero тощо, не мають достатньо загальних можливостей смарт-контрактів для підтримки таких корисних програм, як обміни AMM, ринки запозичень/позик під заставу з пулами тощо. Наразі немає способу залучити нативний біткойн (без упаковки) до довільної логіки децентралізовано та без дозволу. Можливість смарт-контракту між ланцюгами ZetaChain може утримувати та використовувати активи в зовнішніх ланцюгах напряму, таким чином дозволяючи керувати смартконтрактами власний біткойн на ZetaChain, серед інших власних активів наприклад ETH, ERC20, Algorand ASA тощо. Крім того, за допомогою смарт-контрактів ZetaChain і з передачею повідомлень міжланцюгові dApps можна легко створювати за допомогою смартконтрактів у ланцюгах-учасниках, причому смарт-контракти ZetaChain керують рідними сховищами біткойнів.

Розглянемо приклад більш детально. Механізм смарт-контрактів ZetaChain для управління BTC на біткойнах виглядає наступним чином. Ініціалізація запитів смартконтракту KeyGenщоб створити ключ TSS, який діє як адреса сховища біткойнів. ZetaClient відстежуватиме адресу TSS і після ідентифікації вхідних транзакцій до сховища TSS аналізує дані з транзакції Bitcoin в OP_RETURN і викликаєzetaProcess функція з проаналізованими даними смарт-контракту. Смарт-контракт виконує відповідні дії (наприклад, кредитування певних рахунків, надсилання іншого активу відповідно до ціни AMM тощо). Щоб надіслати біткойни зі смарт-контракту, смартконтракт видає спеціальнийПодіящо ZetaClient підбере, підпише та транслюватиме в мережу Bitcoin. Смарт контракт також повинен реалізовувати функцію zetaExternalTxConfirmякий буде викликаний під час видобутку вихідної транзакції зовнішнього ланцюга.

6.3. Міжланцюгові біржі AMM

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 обліковий запис ZetaChain TSS містить усі рідні активи на зовнішніх ланцюгах, якими можна керувати безпосередньо за контрактами ZetaChain. Смарт-контракт ZetaChain реалізує логіку AMM, яка визначає ціни, свопи, постачальників ліквідності та комісії.

У підході передавання повідомлень стани та логіка dApp поширені по всіх зовнішніх ланцюгах; ZetaChain діє лише як верифікатор і ретранслятор повідомлень. Переваги цього підходу полягають у тому, що існуючу інфраструктуру можна повторно використовувати (наприклад, у ланцюгах EVM контракти Uniswap можна повторно використовувати для керування пулом X/ZETA), а dApp потрібно лише обробляти міжланцюгові передачі повідомлень, щоб реалізувати умовне виконання. З іншого боку, у рідному підході розумного контракту ZetaChain логіка та стан

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

dApp живе на ZetaChain, єдиній платформі з уніфікованим інтерфейсом для взаємодії із зовнішніми мережами. Переваги цього підходу полягають у легкості розробки dApp (мінімальні зусилля розробки для розміщення нових ланцюжків) і гнучкості (більше не обмежується ідіосинкразіями ланцюжків і взаємодією між ланцюжками передачі повідомлень). Додаткові переваги полягають у тому, що він мінімально покладається на смарт-контракти на зовнішніх ланцюгах, тому складна логіка може працювати не лише на ланцюжках смарт-контрактів, але й на ланцюжках UTXO, таких як біткойн.

6.4. Багатоланцюгові NFT

Незамінний токен (NFT) — це нова концепція, яка знайшла застосування в колекціях мистецтва, іграх, квитках на події та багатьох інших додатках. На відміну від взаємозамінних токенів, таких як токени ETH, BTC або ERC-20, кожен NFT є унікальним і не може бути взаємозамінним з іншим NFT у тій же колекції. Ця незамінність може бути важливою в таких програмах, як мистецтво, нерухомість тощо. Наприклад, на Ethereum найпоширенішими стандартами NFT є ERC-721 і ERC-1155. У ERC-721 NFT в основному є кортежем (contractAddress, tokenId).Смарт контракт, який випускає NFT, відстежує власників кожного NFT на картіowner=>tokenId.NFT можна передавати від одного власника до іншого, і кожному власнику NFT можна надсилати запити.

У багатоланцюжковому світі NFT, де одна й та сама колекція NFT випускається в кількох ланцюгах (таких як Ethereum, Flow, Solana), і один NFT може переходити в інший ланцюг, проблемою в моделі мосту є знання походження даний NFT – хто є власником даного NFT тепер, коли NFT може бути в одному з кількох ланцюжків

Малюнок 6. DEX, створений за допомогою смарт контрактів ZetaChain. Оскільки ZetaChain TSS може керувати зовнішніми пулами ланцюжків за допомогою своїх смарт-контрактів, DEX може навіть підтримувати ланцюжки й активи без смарт-контрактів, де транзакції є простими та одноетапними.
Малюнок 7. Багатоланцюгові NFT. Завдяки децентралізованому органу видачі (ZetaChain TSS) можна мати 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 multisig.

Щоб досягти балансу між децентралізацією та координацією, деякі аспекти 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 в мережах.

Ми пропонуємо комплексний захист від карбування без відповідного спалювання наступним чином:

Вузли ZetaChain перевірятимуть загальну пропозицію в ланцюжках перед початком карбування токена ZETA. Це захищає від програмних помилок або вразливостей у програмному забезпеченні вузла ZetaChain. Контракти токенів у ланцюжках (за винятком Ethereum, де роль блокувального контракту виконуватиметься) перевіряють загальну кількість ZETA у ланцюжках перед карбуванням. Загальний запас 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/зведеного рівня, з доступом до повної пропозиції власних активів у цих ланцюжках.

https://link3.to/zetachain

Список літератури:

[1]      Rafael Belchior, André Vasconcelos, Sérgio Guerreiro, and Miguel Correia. “A Survey on Blockchain Interoperability: Past, Present, and Future Trends.” ACM Computing Surveys (CSUR) 54 (8). ACM New York, NY: 141. 2021.

[2]      “Chain Key Cryptography: The Scientific Breakthrough Behind the Internet Computer.” https://medium.com/dfinity/chain-key-technology-one-public-key-for-theinternet-computer-6a3644901e28.

[3]      Alexander Chepurnoy, and Amitabh Saxena. “Multi-Stage Contracts in the UTXO Model.” In Data Privacy Management, Cryptocurrencies and Blockchain Technology, 244254. Springer. 2019.

[4]      “Connext Documentation.” https://docs.connext.network/.

[5]      “Ethereum/BTCRelay.” github.com/ethereum/btcrelay.

[6]      “ETH-NEAR Rainbow Bridge.” https://near.org/blog/eth-near-rainbow-bridge/.

[7]      “FUSION Whitepaper.” https://fusion.org/en.

[8]      Rosario Gennaro, and Steven Goldfeder. “Fast Multiparty Threshold ECDSA with Fast Trustless Setup.” In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 11791194. CCS 18. Association for Computing Machinery, New York, NY, USA. 2018. doi:10.1145/3243734.3243859.

[9]      Rosario Gennaro, and Steven Goldfeder. “One Round Threshold ECDSA with Identifiable Abort.” IACR Cryptol. ePrint Arch. 2020: 540. 2020.

[10]   “Hop: Send Tokens Across Rollups.” https://hop.exchange/whitepaper.pdf.

[11]   Jae Kwon, and Ethan Buchman. “Cosmos: A Network of Distributed Ledgers.” URL Https://cosmos.network/whitepaper. 2016.

[12]   Zhuotao Liu, Yangxi Xiang, Jian Shi, Peng Gao, Haoyu Wang, Xusheng Xiao, Bihan Wen, and Yih-Chun Hu. “Hyperservice: Interoperability and Programmability across Heterogeneous Blockchains.” In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 549566. 2019.

[13]   “Multi-Party Threshold Signature Scheme.” https://github.com/binance-chain/tsslib.

[14]   Caleb Banister Ryan Zarick Bryan Pellegrino. “LayerZero: Trustless Omnichain Interoperability Protocol.” URL https://coinweb.io/files/Coinweb-Whitepaper.pdf. 2021.

[15]   “Synapse Protocol Documentation.” https://docs.synapseprotocol.com/.

[16]   THORChain.org. “Decentralized Liquidity Network.” URL https://github.com/thorchain/Resources/blob/master/Whitepapers/THORChainWhitepaper-May2020.pdf. 2020.

[17]   URL Https://chainflip.io/. “Chainflip.” 2021.

[18]   URL Https://multichain.org/. “Multichain (previously Anyswap).” 2021.

[19]   URL Https://sifchain.finance/. “Sifchain.” 2021.

[20]   URL Https://wormholenetwork.com/en/about/. “Wormhole.” 2020.

[21]   URL Https://www.quant.network/. “Quant Network.” 2021.