Біла бумага Axelar v1

Мережа Axelar: Підключення додатків з Blockchain екосистемами

Чернетка 1.0

Січень 2021

Оригінал білої бумаги на англійській мові

https://axelar.network/wp-content/uploads/2021/07/axelar_whitepaper.pdf

Анотація

З’являється безліч екосистем блокчейн, які надають унікальні та відмінні функції, привабливі для користувачів і розробників додатків. Однак комунікація між екосистемами дуже розріджена і фрагментована. Щоб дозволити програмам безперешкодно спілкуватися між екосистемами блокчейну, ми пропонуємо Axelar. Стек Axelar надає децентралізовану мережу, протоколи, інструменти та API, які забезпечують просту міжланцюгову комунікацію. Набір протоколів Axelar складається з протоколів транскордонної маршрутизації та передачі. Децентралізована відкрита мережа валідаторів забезпечує мережу живленням; будь-хто може приєднатися, використати його та взяти участь. Візантійський консенсус, криптографія та механізми стимулювання розроблені для досягнення високих вимог безпеки та життєдіяльності, унікальних для міжланцюжкових запитів.

1. Вступ

Блокчейн-системи швидко набирають популярність і залучають нові варіанти використання для токенізації активів, децентралізованих фінансів та інших розподілених додатків. Кілька основних платформ, таких як Ethereum, Monero, EOS, Cardano, Terra, Cosmos, Avalanche, Algorand, Near, Celo і Polkadot, пропонують різні функції та середовища розробки, які роблять їх привабливими для різних додатків, варіантів використання та кінцевих користувачів [ 5, 11, 4, 21, 20, 23, 24, 19, 6, 14, 25]. Однак корисні функції кожної нової платформи наразі пропонуються менше ніж 1% користувачів екосистеми, а саме власникам рідного токена на цій платформі. Чи можемо ми дозволити розробникам платформ легко підключати свої блокчейни до інших екосистем? Чи можемо ми дозволити розробникам додатків створювати найкращу платформу для своїх потреб, при цьому спілкуючись у кількох екосистемах блокчейн? Чи можемо ми дозволити користувачам взаємодіяти з будь-яким додатком на будь-якому блокчейні безпосередньо зі своїх гаманців?

Щоб об’єднати блокчейн-екосистеми та дозволити програмам безперешкодно спілкуватися між ними, ми пропонуємо мережу Axelar. Валідатори спільно запускають візантійський консенсусний протокол і запускають протоколи, що полегшують міжланцюгові запити. Будь-хто може приєднатися до мережі, брати участь і використовувати її. Основна мережа оптимізована для високих вимог безпеки та працездатності, унікальних для крос-ланцюжкових запитів. Мережа Axelar також включає набір протоколів і API. Основні протоколи:

• Протокол міжланцюгового шлюзу (CGP). Цей протокол аналогічний протоколу Border Gateway Protocol в Інтернеті. Цей протокол використовується для підключення кількох автономних блокчейн-екосистем і відповідає за маршрутизацію між ними. Блокчейнам не потрібно «говорити будь-якою власною мовою», розробникам їх платформи не потрібно вносити будь-які користувацькі зміни в свої ланцюги, а їхні ланцюги можна легко підключити до глобальної мережі.

• Протокол міжланцюгової передачі (CTP). Цей протокол аналогічний протоколам програмного рівня File Transfer, Hypertext Transfer Protocols в Інтернеті. Це стек протоколів на рівні програми, який розташований поверх протоколів маршрутизації (наприклад, CGP та інших технологій маршрутизації). Розробники додатків можуть підключати свої програми dapp до будь-якого ланцюга для виконання запитів між ланцюжками. Користувачі можуть використовувати протокол CTP для взаємодії з програмами в будь-якому ланцюжку, використовуючи прості виклики API, аналогічні запитам HTTP GET/POST. Розробники можуть блокувати, розблоковувати та передавати активи між будь-якими двома адресами на будь-якій платформі блокчейну, виконувати тригери крос-ланцюгових додатків (наприклад, програмні програми в ланцюжку A, можуть оновлювати його стан, якщо якась інша програма в ланцюжку B задовольняє деяким критеріям пошуку (відсоткова ставка > X)), і виконувати загальні міжланцюгові запити між додатками в різних ланцюгах (розумний контракт у ланцюжку A може викликати для оновлення стану смарт-контракту на ланцюг В). Цей протокол дозволяє компонувати програми в екосистемах блокчейн.

Мережа Axelar пропонує наступні переваги:

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

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

1.1. Існуючі рішення для сумісності

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

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

Центри взаємодії. Такі проекти, як лабораторії Cosmos, Polkadot, Ava, спрямовані на взаємодію між бічними ланцюгами, що є рідними для їхніх екосистем, використовуючи спеціальні протоколи міжланцюгового зв’язку [23, 25, 24]. Наприклад, можна розкрутити сайдчейн (Cosmos Zone), який може спілкуватися з Cosmos Hub. Сайдчейн має ґрунтуватися на консенсусі Tendermint і говорити про протокол, зрозумілий Cosmos Hub. З’єднання з іншими блокчейнами та екосистемами, які розмовляють різними мовами, залишаються зовнішніми технологіями.

Парні мости. Загорнуті активи (наприклад, загорнуті біткойни) намагаються заповнити відсутній пробіл між ланцюжками взаємодії в екосистемі. Одним із прикладів є tBTC [9], який є користувацьким протоколом, де для захисту переказів використовується розумна комбінація смарт-контрактів і застави. Ці рішення вимагають значних інженерних зусиль для створення – для кожної пари ланцюжків розробники повинні створити новий розумний контракт у ланцюжку призначення, який аналізує докази стану з вихідного ланцюга (подібно до того, як кожен бічний ланцюг міг би, в принципі, аналізувати стан інших ланцюгів). За допомогою цього підходу було розгорнуто лише кілька мостів. Ці підходи не масштабуються, коли один із базових блокчейнів хоче оновити свої правила консенсусу або формат транзакції. Це тому, що всі розумні контракти, які залежать від стану цих ланцюжків, потрібно буде оновити. Необхідно також налаштувати валідатори та вимагати від них блокування різних активів, щоб забезпечити надмірне забезпечення будь-якої передачі активів, що обмежує економічну ефективність таких переказів.

Ми також бачили кілька інших одноцільових мостів від розробників платформ, які переписують логіку переходу стану в смарт-контрактах для з’єднання з іншими екосистемами [1, 7]. Вони страждають від багатьох проблем масштабованості, не дозволяють екосистемі масштабуватися рівномірно, і вводять додаткові залежності для додатків. Наприклад, якщо зміниться одна платформа, усі смарт-контракти на всіх мостах потрібно буде оновити. Це в кінцевому підсумку поставить екосистему в тупик, де ніхто не зможе оновити. Нарешті, якщо один одноцільовий міст з’єднує платформи A і B, а другий одноцільовий міст з’єднує B і C, це не означає, що програми на A зможуть спілкуватися з програмами на C. Можливо, доведеться створити інший одноцільовий міст або логіка програми перепрограмування.

Інші спроби подолати сумісність включають федеративні оракули (наприклад, Ren [8]) та специфічні для додатків інтероперабельні блокчейни [10].

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

2. Пошуки масштабованого міжланцюгового зв'язку

По суті, кросланцюгове спілкування вимагає, щоб гетерогенні мережі знайшли здатність спілкуватися однією мовою. Щоб вирішити цю проблему, ми пояснюємо набір протоколів Axelar, описуємо його високорівневі властивості та пояснюємо, як ці властивості відповідають ядру масштабованого міжланцюгового зв’язку.

1. Інтеграція «Plug-and-Play». Розробники платформ блокчейн не повинні виконувати важку інженерну або інтеграційну роботу, щоб говорити якоюсь «користувацькою мовою» для підтримки крос-ланцюгів. Протокол крос-ланцюга повинен мати можливість підключати будь-який існуючий або новий блокчейн без тертя. Нові активи слід додавати з мінімальними зусиллями.
2. Міжланцюгова маршрутизація. Такі функції, як виявлення мережевих адрес, шляхів маршрутизації та мереж, є ядром Інтернету і забезпечуються BGP та іншими протоколами маршрутизації. Аналогічно, щоб полегшити спілкування в екосистемах блокчейну, нам потрібно підтримувати виявлення адрес між ними, додатками та маршрутизацією.
3. Підтримка оновлення. Якщо одна з екосистем блокчейну змінюється, це не повинно впливати на сумісність інших блокчейнів. Система повинна розпізнавати оновлення, і для їх підтримки потрібно докладати мінімальних зусиль (тобто не слід переписувати «логіку переходу стану», а програми не повинні зламати).
4. Єдина мова для додатків. Програмам потрібен простий протокол для блокування, розблокування, передачі та зв’язку з іншими програмами, незалежно від того, в якому ланцюжку вони знаходяться. Цей протокол повинен бути незалежним від ланцюга і підтримувати прості виклики, аналогічні протоколам HTTP/HTTPS, які дозволяють користувачам і браузерам спілкуватися з будь-яким веб-сервером. Оскільки до протоколів маршрутизації нижнього рівня приєднується все більше мереж і активів, програми повинні мати можливість використовувати їх для зв’язку, не переписуючи свої програмні стеки.

Далі ми підсумуємо вимоги безпеки, яким повинні відповідати ці протоколи.

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

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

3. Мережа Axelar

Мережа Axelar надає єдине рішення для міжланцюгового зв’язку, яке відповідає потребам як розробників платформи – від них не потрібна робота по інтеграції, так і розробників додатків – один простий протокол і API для доступу до глобальної ліквідності та зв’язку з усією екосистемою.

Мережа Axelar складається з децентралізованої мережі, яка об’єднує екосистеми блокчейну, які розмовляють різними мовами, і набір протоколів з API на вершині, що полегшує додаткам виконання крос-ланцюжкових запитів. Мережа з’єднує існуючі автономні блокчейни, такі як Bitcoin, Stellar, Terra, Algorand, і центри взаємодії, такі як Cosmos, Avalanche, Ethereum і Polkadot. Наша місія полягає в тому, щоб дозволити розробникам додатків створювати такі програми простіше, використовуючи універсальний протокол і API, не розгортаючи свої власні міжланцюгові протоколи або переписуючи програми в міру розробки нових мостів. Для цього ми розробили набір протоколів, який включає протокол міжланцюгового шлюзу (див. Розділ 6) і протокол міжланцюгової передачі (див. Розділ 7).

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

Блокчейн Axelar дотримується моделі Delegated Proof-of-Stake (DPoS), подібної до Cosmos Hub. Користувачі обирають валідаторів, які повинні об’єднати свою частку, щоб брати участь у консенсусі та підтримувати високу якість обслуговування. Модель DPoS дозволяє підтримувати великий набір децентралізованих валідаторів і надійні стимули, які гарантують, що валідатори відповідають за підтримку мостів і часток криптографічних порогових схем. Як частина консенсусу, валідатори запускають програмне забезпечення легкого клієнта інших блокчейнів, що дозволяє їм перевіряти стан інших блокчейнів. Валідатори повідомляють про ці стани в блокчейн Axelar, і як тільки їх достатньо, стан Bitcoin, Ethereum та інших ланцюгів записується на Axelar.

Згодом базовий рівень Axelar дізнається про стан зовнішніх блокчейнів у будь-який момент часу, створюючи «вхідні мости» з інших блокчейнів. Валідитори спільно підтримують порогові рахунки для підпису в інших блокчейнах (наприклад, 80% валідаторів повинні схвалювати та спільно підписувати будь-яку транзакцію з них), що дозволяє їм блокувати й розблоковувати активи та стан між ланцюжками та розміщувати стан на інших блокчейни, «вихідні мости». Загалом мережу Axelar можна розглядати як децентралізований міжланцюговий оракул читання/запису.

Решта документа описує попередники та будівельні блоки за мережею (секція 4), деякі технічні деталі мережі (розділ 5), протокол перехресного ланцюгового шлюзу (розділ 6) та протокол перенесення перенесення крос-ланцюгів (розділ 7 ).

4. Попередники 4.1. Позначення та припущення

Нехай V в степені r позначає набір валідаторів Axelar у раунді R. Кожен валідатор має вагу, число в (0, 1], що позначає силу голосу цього конкретного валідатора. Вагові ваги всіх валідаторів становлять 1. Валідатор правильний якщо вона запускає вузол, який відповідає правилам протоколу Axelar. Щоб завершити блокування або підписувати міжланцюгові запити, Axelar потрібні правильні валідатори загальної ваги > F. Ми називаємо параметр F ∈ [0.5, 1] протокольний поріг.

Axelar може бути заснований на миттєвому блокчейні Delegated-Proof-of-Stake. У кожному раунді i валідатори виконують консенсус візантійської відмовостійкості (BFT), щоб завершити i-ий блок. Після завершення i-го блоку запускається новий консенсус BFT для завершення блоку i + 1, і так далі. Валідатори обираються шляхом делегування кола. Користувач із певною ставкою може вибрати запуск вузла валідатора або делегувати свої права голосу (ставку) існуючому валідатору, який потім голосує від їхнього імені. Набір валідаторів можна оновлювати, валідатори приєднуються до набору або залишають його, а користувачі делегують/скасовують право голосу.

Різні блокчейни працюють за різними мережевими припущеннями. Синхронний зв’язок означає, що існує фіксована верхня межа ∆ для часу доставки повідомлень, де ∆ відомий і може бути вбудований в протокол. Асинхронний зв’язок означає, що доставка повідомлень може займати як завгодно багато часу, і відомо, що протоколи BFT не можуть бути створені для асинхронних мереж навіть за наявності лише одного шкідливого валідатора. Реалістичним компромісом між синхронністю та асинхронністю є припущення про частково синхронну комунікацію. Мережа може бути повністю асинхронною до невідомого глобального часу стабілізації (GST), але після того, як GST зв'язок стає синхронною з відомою верхньою межею ∆ [17].

Типові блокчейни працюють за умови > F правильних валідаторів. Для синхронних мереж зазвичай встановлюється F = 1/2, але для слабшого припущення частково синхронної мережі F = 2/3. Біткойн, його форки та поточна версія Ethereum для підтвердження роботи працюють лише за умови синхронізації. Інші, такі як Algorand і Cosmos, вимагають лише часткової синхронії. При з’єднанні ланцюжків через Axelar з’єднання працює, припускаючи найсильніші мережеві припущення з цих ланцюжків, що є синхронністю у випадку з’єднання Bitcoin і Cosmos, наприклад. Сам блокчейн Axelar працює в частково синхронному режимі і, таким чином, вимагає F = 2/3, але можна покращити вимогу до порогового значення, припустивши, що інші існуючі блокчейни безпечні та використовують їхню безпеку.

4.2. Криптографічні попередні

Цифрові підписи. Схема цифрового підпису — це набір алгоритмів (Keygen, Sign, Verify). Keygen виводить пару ключів (PK, SK). Тільки власник SK може підписувати повідомлення, але будь-хто може перевіряти підписи за допомогою відкритого ключа PK. Більшість систем блокчейну сьогодні використовують одну зі стандартних схем підпису, наприклад ECDSA, Ed25519, або кілька їх варіантів [2, 3].

Порогові підписи. Порогова схема підпису дозволяє групі з n сторін розділити секретний ключ для схеми підпису таким чином, що будь-яка підмножина з t + 1 або більше сторін може співпрацювати для створення підпису, але жодна підмножина з t або менше сторін не може створити підпис. підпис або навіть дізнатися будь-яку інформацію про секретний ключ. Підписи, створені пороговими протоколами для ECDSA і EdDSA, виглядають ідентичними підписам, створеним автономними алгоритмами.

Порогова схема підпису замінює алгоритми Keygen і Sign для звичайної схеми підпису розподіленими n-сторонніми протоколами T.Keygen, T.Sign. Ці протоколи зазвичай вимагають як загальнодоступного каналу мовлення, так і приватних парних каналів між сторонами, і вони зазвичай передбачають кілька раундів зв’язку. Після успішного завершення T.Keygen кожен користувач володіє часткою si секретного ключа SK і відповідного відкритого ключа PK. Протокол T.Sign дозволяє цим сторонам створювати підпис для даного повідомлення, який є дійсним під відкритим ключем PK. Цей підпис може бути перевірений будь-ким за допомогою алгоритму Verify оригінальної схеми підпису.

4.3. Властивості порогових підписів

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

Захист від нечесної більшості. Деякі порогові схеми мають обмеження, що вони безпечні лише тоді, коли більшість n сторін чесні. Таким чином, пороговий параметр t має бути меншим за n/2 [15]. Це обмеження зазвичай супроводжується тим фактом, що для підписання необхідно 2t + 1 чесних сторін, навіть якщо тільки t + 1 пошкоджені сторони можуть вступити в змову, щоб повернути секретний ключ. Схеми, які не підпадають під це обмеження, вважаються захищеними від нечесної більшості.

Як обговорювалося пізніше в Розділі 5.2, крос-ланцюгові платформи повинні максимізувати безпеку своїх мереж і мати можливість терпіти якомога більше корумпованих сторін. Таким чином, необхідні схеми, які можуть терпіти нечесну більшість.

Попередні підписи, неінтерактивне онлайн підписання. Прагнучи зменшити тягар комунікації для сторін під час підписання повідомлення, кілька останніх протоколів визначили значну частину роботи щодо підпису, яку можна виконати «в автономному режимі», до того, як повідомлення для підпису стане відомим [18, 13]. ]. Вихід цієї автономної фази називається попереднім підписом. Виготовлення попередніх підписів розглядається як окремий протокол T.Presign, відмінний від T.Keygen і T.Sign. Вихідні дані протоколу попереднього підписання повинні залишатися приватними сторонами, поки вони не використають їх на етапі підписання. Пізніше, коли повідомлення, яке потрібно підписати, стане відомим, залишиться лише невелика кількість додаткової «онлайнової» роботи в T.Sign, щоб завершити підпис.

Онлайн-фаза T.Sign не вимагає спілкування між сторонами. Кожна сторона просто виконує локальне обчислення для повідомлення та попереднього підпису, а потім оголошує свою частку в підписі. (Після загального доступу ці спільні підписи s1,..., st+1 будь-хто легко комбінує, щоб розкрити фактичний підпис s.) Ця властивість називається неінтерактивним онлайн-підписанням.

Міцність. Порогові схеми гарантують лише те, що підмножина зловмисників не зможе підписати повідомлення або дізнатися секретний ключ. Ця гарантія, однак, не виключає можливості того, що погані суб’єкти можуть заблокувати всім іншим доступ до ключів або підписів. У деяких схемах шкідлива поведінка навіть однієї сторони може призвести до припинення T.Keygen або T.Sign без корисного виведення. Єдиний вихід — перезапустити протокол, можливо, з різними сторонами.

Натомість, для децентралізованих мереж ми хочемо, щоб T.Keygen і T.Sign досягли успіху, якщо принаймні t + 1 зі сторін є чесними, навіть якщо деякі зловмисники надсилають неправильні повідомлення або залишають повідомлення в протоколах. Ця властивість називається міцністю.

Атрибуція помилок. Здатність ідентифікувати поганих акторів у T.Keygen або T.Sign називається атрибуцією помилок. Без приписування провини важко надійно виключити або покарати поганих акторів, і в цьому випадку витрати, пов’язані з поганими акторами, повинні нести кожен. Ця властивість також важлива для децентралізованих мереж, де зловмисна поведінка повинна бути ідентифікована та економічно демотивована за допомогою правил скорочення.

Безпека в одночасних налаштуваннях. Схема підпису має бути захищеною в умовах одночасного використання, де можна паралельно задіяти декілька екземплярів ключового генератора та алгоритмів підпису. (Дрійверс та ін. [16], наприклад, продемонстрували атаку на схеми багатопідпису Шнорра в цих налаштуваннях). Існують версії як схем ECDSA, так і схем Шнорра, які задовольняють цим властивостям [13, 22].

ECDSA і EdDSA — це, безумовно, найбільш поширені схеми підпису в просторі блокчейну. Таким чином, порогові версії обох схем були в центрі уваги нещодавнього відродження досліджень і розробок. Читачі, які цікавляться найсучаснішими новинами, можуть звернутися до [22, 13, 18] та нещодавнього опитування [12].

5. Мережа Axelar
5.1. Проектування відкритої міжланцюгової мережі

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

• Відкрите членство. Будь-який користувач повинен мати можливість стати валідатором (дотримуючись правил мережі).
• Оновлення членства. Коли валідатор чесно залишає систему, його ключ потрібно відповідним чином відкликати.
• Заохочення та різання. Шкідливі валідатори повинні бути ідентифіковані, а їхні дії повинні бути ідентифіковані та врегульовані протоколом.
• Консенсус. Порогові схеми самі по собі визначаються як самостійні протоколи. Для поширення повідомлень між вузлами нам потрібні як широкомовні, так і приватні канали «точка-точка». Крім того, валідатори повинні узгодити останній стан кожного виклику порогових схем, оскільки вони часто мають кілька раундів взаємодій.
• Керування ключами. Так само, як звичайні валідатори в будь-якій системі PoS повинні ретельно охороняти свої ключі, так само валідатори Axelar також повинні охороняти свої порогові частки. Клавіші потрібно обертати, розділяти між онлайн- та офлайновими частинами тощо.

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

• Порогове генерування ключа. Існуючі алгоритми генерації порогових ключів для стандартних схем підпису блокчейну (ECDSA, Ed25519) є інтерактивними протоколами між кількома учасниками (див. Розділ 4). Спеціальна транзакція в мережі Axelar інструктує валідаторів розпочати виконання цього протоколу з визначенням стану. Кожен валідатор запускає процес порогового демона, який відповідає за безпечне збереження секретного стану. Для кожної фази протоколу:
1. Валідатор зберігає стан протоколу в локальній пам'яті.
2. Він викликає секретний демон для створення повідомлень відповідно до опису протоколу для інших валідаторів.
3. Він поширює повідомлення або через трансляцію, або через приватні канали до інших валідаторів.
4. Кожен валідатор виконує функції переходу стану, щоб оновити свій стан, перейти до наступного етапу протоколу та повторити вищезазначені кроки.

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

• Порогове підписання. Запити на підписання в мережі Axelar обробляються аналогічно запитам на генерацію ключів. Вони викликаються, наприклад, коли користувач хоче вилучити актив з одного з ланцюжків. Це інтерактивні протоколи, і перехід стану між раундами запускається як функція повідомлень, що поширюються через блокчейн Axelar і локальну пам’ять кожного валідатора.
• Обробка змін у складі валідатора. Набір валідаторів потрібно періодично змінювати, щоб нові зацікавлені сторони могли приєднатися до набору. Після оновлення набору валідатора нам потрібно оновити пороговий ключ, який буде спільним для нового набору. Таким чином, якщо ми дозволимо комусь приєднатися в будь-який час, нам доведеться дуже часто оновлювати пороговий ключ. Щоб запобігти цьому, ми чергуємо валідатори кожні T-блоки. В інтервалах T раундів фіксується набір V R і пороговий ключ. У кожному раунді, який є цілим кратним параметру T , ми оновлюємо набір валідатора таким чином:

1. У будь-якому раунді R стан Axelar відстежує поточний набір валідаторів V R. V R+1 = V R, якщо R + 1 кратний T .
2. Під час раундів ((i − 1)T, iT ] користувачі публікують повідомлення про зв’язування/роз’єднання.
3. Наприкінці раунду iT ці повідомлення застосовуються до V iT −1, щоб отримати V iT .

• Порогове генерування та підписання ключа за наявності змінних валідаторів. Блокчейн Axelar може надіслати запит на новий ключ або пороговий підпис на раунді R. Процес підписання триває довше, ніж один раунд, і ми не хочемо сповільнювати консенсус, тому ми просимо, щоб підпис було створено до раунду R + 10 стартів. Зокрема, валідатори починають раунд R + 10 тільки після того, як побачать сертифікат для раунду R + 9 і підпис для кожного запиту ключа/підпису, виданого під час раунду R. Результати всіх запитів раунду R повинні бути включені в блок R + 11. У іншими словами, пропозиція блоку раунду R, яка не містить результатів раунду R 11, вважається недійсною, і валідатори не голосують за неї. Щоб забезпечити підписання всіх порогових повідомлень перед оновленням набору валідатора, Axelar не видає жодних запитів на порогове значення під час раунду, який дорівнює −1, −2, . . . , −9 за модулем T .

5.2. Безпека мережі

Безпека блокчейн-систем покладається на різні криптографічні та теоретичні протоколи ігор, а також на децентралізацію мережі. Наприклад, у блокчейнах proof-of-stake без належних стимулів валідитори можуть вступати в змову та переписувати історію, викрадаючи кошти інших користувачів у процесі. У мережах proof-of-work без достатньої децентралізації досить легко створити довгі форки та подвійні витрати, як довели численні атаки на Bitcoin Gold та Ethereum Classic.

Більшість досліджень безпеки блокчейну зосереджені на суверенних мережах. Але як тільки ланцюги взаємодіють, потрібно розглянути нові вектори атаки. Наприклад, припустимо, що Ethereum спілкується з невеликим блокчейном X через прямий міст, який керується двома смарт-контрактами, одним на Ethereum і одним на X. Окрім інженерних проблем, які ми підсумували в Розділі 1.1, потрібно вирішити, що станеться, коли довіра припускає: ції X порушуються. У цьому випадку, якщо ETH перейшов на X, валідатори X можуть вступити в змову, щоб підробити історію X, де вони тримають усі ETH, опублікують підроблені докази консенсусу в Ethereum та вкрасть ETH. Ситуація ще гірша, коли X пов’язаний з кількома іншими ланцюгами через прямі мости, а якщо X розгалужується, ефекти поширюються через кожен міст. Налаштування рекомендацій щодо керування відновленням для кожного парного мосту є надзвичайним завданням для будь-якого окремого проекту.

Мережа Axelar вирішує проблеми безпеки, використовуючи такі механізми:

• Максимальна безпека. Axelar встановлює поріг безпеки на 90%, що означає, що майже всім валідаторам доведеться вступити в змову, щоб вилучити будь-які кошти, заблоковані його мережею, або підробити підтвердження стану1. На практиці було помічено, що валідатори PoS мають дуже високий час роботи (близько до 100%), за умови, що вони належним чином стимулюються. Отже, мережа Axelar вироблятиме блоки навіть незважаючи на цей високий поріг. Однак у рідкісних випадках, коли щось піде не так і мережа зупиняється, мережа потребує надійних резервних механізмів для перезавантаження системи, описаної далі.
• Максимальна децентралізація. Оскільки мережа використовує порогові схеми підпису, кількість валідаторів може бути якомога більшою. Мережа не обмежена кількістю валідаторів, які ми можемо підтримувати, лімітами транзакцій або комісіями, які виникли б, наприклад, при використанні кількох підписів у різних ланцюгах, де складність (і плата) зростають лінійно з кількістю валідаторів.2
• Надійні резервні механізми. Перше питання, яке необхідно вирішувати в мережі з високими порогами безпеки, як зазначено вище, це що відбувається, коли сама мережа зупиняється. Припустимо, сама мережа Axelar зупиняється. Чи можемо ми створити резервний механізм, який дозволить користувачам повернути свої кошти? Щоб усунути будь-яку потенційну зупинку самої мережі Axelar, кожен обліковий запис порогового мосту в блокчейні X, яким спільно керують валідатори Axelar, має «ключ екстреного розблокування». Цим ключем можуть користуватися тисячі сторін і навіть може бути користувацьким ключем для блокчейна X, який використовується спільнотою цієї мережі. Таким чином, якщо мережа Axelar зупиниться, цей ключ буде діяти як резервний засіб і дозволить відновити активи (докладніше див. нижче).

1. Останній параметр, який буде вибрано для розгортання мережі, можна змінити. 2. Для деяких блокчейнів мультипідписи пропонують розумну альтернативу, коли плата за газ є невеликою, а підтримувані формати повідомлень є доречними. Але вони не масштабуються для двох найбільших платформ, таких як Bitcoin та Ethereum.

• Максимальна децентралізація зворотних механізмів. Цей резервний механізм включає вторинний набір користувачів для відновлення, у якому кожен може брати участь без будь-яких витрат. Цим користувачам не потрібно бути онлайн, запускати вузли або координувати дії один з одним. Вони «викликаються на чергування», лише якщо мережа Axelar зупиняється і не може відновитися. Безпека мережі підвищується завдяки дуже високому пороговому значенню для первинного набору валідаторів і максимально децентралізованого вторинного набору відновлення.
• Спільне управління. Загальний протокол керує мережею Axelar. У сукупності користувачі можуть голосувати за те, який ланцюг має підтримуватися через його мережу. Мережа також виділить пул коштів, які можна буде використати для відшкодування витрат користувачам у разі несподіваних надзвичайних ситуацій, які також контролюються за допомогою протоколів управління.
Різні механізми безпеки обговорюються нижче.

Відступні механізми. Коли Axelar зупиняється через високий поріг, «ключ екстреного розблокування» бере контроль над мережею. Існує кілька способів створити екземпляр цього ключа розблокування, і певні ланцюги/програми можуть вибрати інший варіант для «набору відновлення» або повністю відмовитися: [3]

• Варіант а. Поділіться ключем між фондами блокчейн-проектів і авторитетними людьми в спільноті.

• Варіант b. Діліться між партіями, обраними за допомогою делегованого механізму PoS.

• Варіант c. Для облікових записів, які керують активами та інформацією для ланцюга/програми X, надайте власний ключ зацікавленим сторонам/валідаторам X. Припускаючи, що X має механізми управління, ті самі механізми керування можна застосувати для визначення курсу дій, якщо Axelar зупиниться.

[3] Останнє розгортання в мережі Axelar буде завершено ближче до запуску мережі.

Тепер, враховуючи ідентифікаційні дані користувачів відновлення та їхні відкриті ключі, простий протокол генерує частки ключа відновлення, про які ніхто не знає. Більше того, користувачам набору відновлення не потрібно перебувати в мережі, доки не буде викликано відновлення через механізми управління. Відповідно до стандартних розподілених протоколів генерації ключів, кожен валідатор Axelar має випадкове значення. Секретний ключ відновлення створюється шляхом підсумовування цих значень. Замість того, щоб робити підсумки в чистому вигляді, усі спільні ресурси шифруються під відкритими ключами користувачів відновлення, а потім додаються гомоморфно (це передбачає адитивне гомоморфне шифрування та додатковий рівень нульової інформації, обидва з яких легко отримати). Результатом цього протоколу є відкритий ключ відновлення RPK і потенційно тисячі шифрувань (під відкритими ключами користувачів відновлення) часток відповідного секретного ключа Enci(si), які розповсюджуються їх власникам (наприклад, розміщені в ланцюжку). ). Контракти Axelar bridge включають опцію повернення коштів за допомогою RPK за певних умов. Нарешті, також можна оновити цей ключ відновлення і навіть змінити набір користувачів, які володіють його акціями, не вимагаючи роботи від акціонерів-учасників.

Якщо ланцюг X, підключений до Axelar, розривається, є кілька варіантів:

• Встановити обмеження на вартість активів у доларах США, які можна перемістити/вивезти з X в будь-який день. Таким чином, шкідливий ланцюжок X може вкрасти лише невелику частину всіх активів, які підключені до нього, перш ніж валідатори Axelar виявлять це, і механізми управління з наступних куль запрацюють.
• Модуль управління Axelar можна використовувати для голосування за те, що відбувається в цих ситуаціях. Наприклад, якщо є доброякісна помилка і спільнота перезапускає X, керівництво Axelar може вирішити перезапустити з’єднання з того місця, де воно зупинилося.
• Якщо ETH був переміщений до X, спеціальний ключ відновлення Ethereum може визначити, що станеться з активами ETH.

6. Протокол міжланцюгового шлюзу (CGP)

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

Синхронізація стану (Розділ 6.2). Розмістити інформацію про стан вихідного блокчейна S в стан блокчейна D призначення.

(Наприклад, опублікуйте заголовок блоку Bitcoin в блокчейні Ethereum.)

Передача активів (Розділ 6.3). Перенесіть цифровий актив із S в D і назад.

(Наприклад, перенесіть біткойни з блокчейну Bitcoin в блокчейн Ethereum, а потім назад у блокчейн Bitcoin.)

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

6.1. Рахунки в інших мережах

Щоб об’єднати різні ланцюжки, у кожному ланцюжку створюються порогові рахунки, які контролюють потік цінностей та інформації через них. Для ланцюга Chain позначте рахунок ChainAxelar.

Bitcoin рахунок. Для Bitcoin та інших ланцюжків нерозумних контрактів валідатори Axelar створюють пороговий ключ ECDSA відповідно до розділу 5.1. Цей ключ керує обліковим записом ECDSA у біткойнах і є адресою призначення, куди користувачі надсилають депозити. Персоналізовані порогові ключі можуть бути створені за запитом користувача. Ключ можна періодично оновлювати, а останні ключі та персоналізовані ключі можна знайти, зробивши запит до вузла Axelar.

Обліковий запис порогового мосту на ланцюгах зі смарт-контрактами. Позначимо ланцюжок SC. валідатори створюють пороговий ключ ECDSA або ED25519 відповідно до розділу 5.1, залежно від типу ключа, який підтримує ланцюжок. Ми позначаємо цей ключ PKAxelar, коли немає двозначності щодо того, який ланцюг ми ​​маємо на увазі. Цей ключ керує обліковим записом смарт-контракту на SC, позначеним SCAxelar, і будь-яка програма на SC може запитати SCAxelar, щоб дізнатися PK-адресу цього ключа. Таким чином, будь-яка програма SC може розпізнавати повідомлення, підписані SKAxelar. Протокол також повинен враховувати змінні значення PKAxelar. Це відбувається наступним чином:

1. Ініціалізуйте SCAxelar на SC. Він зберігає PKAxelar як частину свого стану, який ініціалізується як значення генезису на Axelar. SCAxelar також включає правила оновлення ПК.
2. Щоб оновити PKAxelar, потрібно надіслати транзакцію формату (оновлення, PKnew) із підписом поточного SKAxelar. Тоді контракт встановлює PKAxelar = PKnew.
3. Щоразу, коли валідатори оновлюють пороговий ключ для SC з PK i на PK i+1, Axelar запитує, щоб валідатори використовували SK i для підпису (оновлення, PK i+1). Згодом цей підпис публікується в SCAxelar, який оновлює PKAxelar.

6.2. Синхронізація стану

Нехай qS позначає довільне питання про стан ланцюга S. Прикладами таких запитань є:
• «У якому раунді блоку, якщо такий був, з’явилася транзакція tx?» • «Яке значення має певне поле даних?» • «Що таке кореневий хеш Меркла для всього стану S на етапі блоку 314159?»

Нехай aS позначає правильну відповідь на qS і припустимо, що кінцевий користувач або програма вимагає, щоб aS був розміщений у ланцюжку D. Мережа Axelar відповідає цій вимогі наступним чином:

1. Користувач розміщує запит qS на одному з облікових записів мосту (які згодом підбираються валідаторами) або безпосередньо в блокчейн Axelar.
2. Як частина консенсусу Axelar, кожен валідатор повинен запустити програмне забезпечення вузлів для ланцюжків S, D. Валідитори Axelar запитують API свого програмного забезпечення вузла S ланцюга для відповіді aS і повідомляють відповідь ланцюжку Axelar.
3. Коли > F зважені валідатори повідомляють ту саму відповідь у раунді R, Axelar просить валідаторів підписати aS.
4. За допомогою порогової криптографії валідатори підписують як S. Підпис входить в блок R + 11.
5. Будь-хто може взяти підписане значення aS з блоку R + 11 і опублікувати його в D.
6. Запит обслужено. Будь-яка програма на D тепер може приймати підписане значення aS, запитувати у DAxelar останній PKAxelar і перевіряти, що підпис aS відповідає PKAxelar. Валідитори також розміщують AS до облікового запису мосту в ланцюжку D, який програми можуть отримати.

6.3. Міжланцюгова передача активів

Мережа забезпечує міжланцюгову передачу цифрових активів, розширюючи робочий процес синхронізації стану, зазначений у розділі 6.2.
Після ініціалізації DAxelar друкує і контролює достатній запас маркерів прив’язаного-S. Припустимо, що користувач вимагає обміняти x кількість маркерів у вихідному ланцюзі S на x кількість прив’язаних S маркерів у ланцюгу призначення D, які будуть депоновані на D-адресу wD за вибором користувача. Ми представляємо повністю загальний робочий процес, який підтримує довільні ланцюжки джерел S—навіть ланцюги, такі як біткойн, які не підтримують розумні контракти:

1. Користувач (або програма, що діє від імені користувача) надсилає запит на передачу (x, wD) до облікового запису порогового мосту, який згодом перенаправляється в мережу Axelar.

2. Валідатори Axelar використовують порогову криптографію для колективного створення нової адреси депозиту dS для S. Вони надсилають dS в блокчейн Axelar.

3. Користувач (або програма, що діє від імені користувача) вивчає dS, відстежуючи блокчейн Axelar. Користувач надсилає x кількість S-токенів на адресу dS через звичайну S-транзакцію txS, використовуючи своє улюблене програмне забезпечення для ланцюга S.
(Через порогову властивість dS токени не можна витрачати з dS, якщо для цього не координується порогове число валідаторів.)

4. txS розміщено на Axelar. Валідатори запитують API свого програмного забезпечення S-вузла ланцюга на наявність txS і, якщо відповідь «правда», повідомте відповідь ланцюжку Axelar.

5. Коли > F зважені валідатори повідомляють «істинно» для tx S на раунді R, Axelar просить валідаторів підписати транзакцію aD, яка надсилає x кількість прив’язаних токенів S від DAxelar до wD.

6. За допомогою порогової криптографії валідатори підписують aD. Підпис входить в блок R + 11.

7. Будь-хто може взяти підписане значення aD з блоку R + 11 і опублікувати його в D.

8. Запит обслуговується, після того, як оголошення D розміщено на D, передача обробляється.

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

1. Користувач ініціює запит на передачу (xt, wS), депонуючи xt кількість загорнутих-S токенів у cD за допомогою звичайної D-транзакції за допомогою свого улюбленого програмного забезпечення для ланцюга D.

2. (xt, wS) розміщено на Axelar. Валідатори запитують API свого програмного забезпечення вузла D ланцюга на наявність (xt, wS) і, якщо відповідь «правда», повідомляють відповідь ланцюжку Axelar.

3. Один раз > F зважені валідатори повідомляють «істинно» для (xt, wS) під час раунду R, Axelar просить валідаторів підписати транзакцію aS, яка надсилає xt кількість токенів S від SAxelar до wS.

4. За допомогою порогової криптографії валідатори підписують як S. Підпис входить в блок R + 11.

5. Будь-хто може взяти підписане значення aS з блоку R + 11 і опублікувати його в S.

6. Запит обслуговується, після того як aS розміщено на S, передача обробляється.

Додаткові запити, які підтримує рівень маршрутизації CGP, включають блокування, розблокування або передачу активів між ланцюжками.

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

7. Протокол міжланцюгової передачі (CTP)

CTP — це протокол на рівні програми, який спрощує використання функцій крос-ланцюга. Ми пояснюємо інтеграцію, зосереджуючись на функціях передачі активів (наприклад, використовуються в DeFi). Ці програми зазвичай складаються з трьох основних компонентів: інтерфейсного графічного інтерфейсу, смарт-контрактів в одному ланцюжку та проміжного вузла, який розміщує транзакції між інтерфейсом і смарт-контрактами. Інтерфейс взаємодіє з гаманцями користувача, щоб приймати депозити, обробляти зняття коштів тощо. Програми можуть використовувати функції крос-ланцюга, викликаючи запити CTP, аналогічні методам HTTP/HTTPS GET/POST. Ці запити згодом підбираються рівнем CGP для виконання, а результати повертаються назад користувачам.

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

– Зареєструйте блокчейн, з яким він хоче спілкуватися.
– Зареєструйте активи на цьому блокчейні, які він хотів би використовувати.
– Виконуйте операції над активами, такі як прийом депозитів, обробка зняття коштів та інші функції (подібні, скажімо, виклику контрактів ERC-20).

Припустимо, відомий додаток DeFi, MapleSwap, який ізначально знаходиться в регістрах ланцюга A з пороговим мостовим обліковим записом. Валідатори Axelar спільно керують самим контрактом у відповідному ланцюжку. Припустимо, що користувач хоче внести депозит у торгову пару між активами X і Y, які знаходяться в двох ланцюгах відповідно. Потім, коли користувач подає такий запит, він направляється через обліковий запис порогового мосту в мережу Axelar для обробки. У формі там виконуються такі дії:

1. Мережа Axelar розуміє, що ця програма зареєстрована для підтримки крос-ланцюга для активів. Він генерує ключ депозитів, використовуючи порогову криптографію та консенсус для користувача у відповідних ланцюгах A і B.

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

3. Коли депозити підтверджені, Axelar оновлює свій міжланцюжковий каталог, щоб записати, що користувач у відповідних ланцюгах вніс ці активи на депозит.

4. Валідатори Axelar виконують багатосторонні протоколи для створення порогового підпису, який дозволяє оновлювати обліковий запис порогового моста в ланцюжку A, де знаходиться програма.

5. Потім запит CTP повертається до смарт-контрактів програми DeFi, які можуть оновлювати свій стан, оновлювати формули прибутку, обмінні курси або виконувати інші умови, пов’язані зі станом програми.

Протягом цього процесу мережа Axelar на високому рівні діє як децентралізований міжланцюжковий оракул читання/запису, CGP є рівнем маршрутизації між ланцюгами, а CTP є протоколом програми.

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

• Виконувати послуги імен відкритих ключів (PKNS). Це універсальний каталог для відображення відкритих ключів до телефонних номерів/твіттерів (кілька проектів, наприклад Celo, надають ці функції на своїх платформах).

• Тригери крос-ланцюгових додатків. Програма в ланцюжку A може оновити свій стан, якщо інша програма в ланцюжку B задовольняє критеріям пошуку (відсоткова ставка < X).

• Компонування смарт-контрактів. Смарт-контракт у ланцюжку A може оновлювати свій стан на основі стану контрактів у ланцюжку B або запускати дію для оновлення смарт-контракту в ланцюгу B.

На високому рівні ці запити можна обробляти, оскільки разом протоколи CTP, CGP і мережа Axelar можуть передавати та записувати довільну інформацію про стан через блокчейни.

8. Підсумок

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

Посилання

[1] Althea peggy. https://github.com/cosmos/peggy. [Цитується на сторінці 2.]

[2] Детермінізоване використання алгоритму цифрового підпису (dsa) та алгоритму цифрового підпису еліптичної кривої (ecdsa). https://tools.ietf.org/html/rfc6979. [Процитовано на сторінці 5.]

[3] Алгоритм цифрового підпису кривої Едвардса (eddsa). https://tools.ietf.org/html/rfc8032. [Процитовано на сторінці 5.]

[4] Технічний документ Eos.io v2. https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md. [Цитується на сторінці 1.]

[5] Ethereum: безпечна децентралізована узагальнена книга транзакцій.
https://ethereum.github.io/yellowpaper/paper.pdf. [Цитується на сторінці 1.]

[6] Майже білий папір. https://near.org/papers/the-official-near-white-paper/. [Цитується на сторінці 1.]

[7] Веселковий міст. https://github.com/near/rainbow-bridge. [Цитується на сторінці 2.]

[8] Ren: віртуальна машина, що зберігає конфіденційність, що забезпечує фінансові програми з нульовим знанням. https://whitepaper.io/document/419/ren-litepaper. [Цитується на сторінці 3.]

[9] tbtc: децентралізований токен erc-20 з підтримкою btc. https://docs.keep.network/tbtc/index. pdf. [Цитується на сторінці 2.]

[10] Thorchain: децентралізована мережа ліквідності. https://thorchain.org/. [Цитується на сторінці 3.]

[11] Курт М. Алонсо. Від нуля до монеро. https://www.getmonero.org/library/Zero-to-Monero-1-0-0. pdf. [Цитується на сторінці 1.]

[12] Жан-Філіп Омассон, Адріан Хамелінк та Омер Шломовіц. Огляд порогового підписання ecdsa. Cryptology ePrint Archive, Report 2020/1390, 2020. https://eprint.iacr.org/2020/1390. [Цитується на сторінка 6.]

[13] Ран Канетті, Ніколаос Макріянніс та Уді Пелед. Uc неінтерактивний, активний, пороговий ecdsa. Cryptology ePrint Archive, Report 2020/492, 2020. https://eprint.iacr.org/2020/492. [Цитується на сторінка 6.]

[14] Документи cLabs. https://celo.org/papers. [Цитується на сторінці 1.]

[15] Іван Дамгард, Томас Пелле Якобсен, Єспер Буус Нільсен, Якоб Іллеборг Пагтер та Майкл Бексванг Остерґард. Швидкий поріг ECDSA з чесною більшістю. У SCN, том 12238 Конспектів лекцій з інформатики, сторінки 382–400. Springer, 2020. [Процитовано на сторінці 6.]

[16] Ману Дрійверс, Касра Едалатнеджад, Браян Форд, Ейке Кільц, Джуліан Лосс, Грегорі Невен та Ігор Степанов. Про охорону двораундних мультипідписів. У IEEE Symposium on Security and Privacy, сторінки 1084–1101. IEEE, 2019. [Процитовано на сторінці 6.]

[17] Синтія Дворк, Ненсі Лінч і Ларрі Стокмайер. Консенсус за наявності часткової синхронії. https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf. [Процитовано на сторінці 5.]

[18] Розаріо Дженнаро і Стівен Голдфедер. Один круглий поріг ecdsa з ідентифікованим перериванням. Cryptology ePrint Archive, Report 2020/540, 2020. https://eprint.iacr.org/2020/540. [Процитовано на сторінці 6.]

[19] Йоссі Гілад, Ротем Хемо, Сільвіо Мікалі, Георгіос Влахос та Микола Зельдович. Алгоранд: Масштабування візантійські угоди щодо криптовалют. Матеріали 26-го симпозіуму з принципів операційних систем, 2017. https://dl.acm.org/doi/pdf/10.1145/3132747.3132757. [Цитується на сторінці 1.]

[20] Еван Кереякес, До Квон, Марко Ді Маджо та Ніколас Платіас. Terra money: стабільність і усиновлення. https://terra.money/Terra_White_paper.pdf. [Цитується на сторінці 1.]

[21] Агелос Кіяяс, Олександр Рассел, Бернардо Давід та Роман Олійников. Ouroboros: доказово безпечний блокчейн-протокол для підтвердження участі. https://eprint.iacr.org/2016/889.pdf. [Цитується на сторінці 1.]

[22] Челсі Комло та Ян Голдберг. Frost: гнучкі, оптимізовані порогові сигнатури Шнорра. Cryptology ePrint Archive, Report 2020/852, 2020. https://eprint.iacr.org/2020/852. [Цитується на сторінці 6.]

[23] Дже Квон та Ітан Бучман. Космос: мережа розподілених реєстрів.
https://cosmos.network/resources/whitepaper. [Цитується на сторінках 1 і 2.]

[24] Команда Avalanche. Платформа Avalanche.
https://www.avalabs.org/whitepapers. [Цитується на сторінках 1 і 2.]

[25] Гевін Вуд. Polkadot: Бачення гетерогенної багатоланцюгової структури.
https://polkadot.network/PolkaDotPaper.pdf. [Цитується на сторінках 1 і 2.]