Обычно, все особенности и возможности блокченов доступны исключительно внутри него самого, что делает невозможным взаимодействие экосистем между собой. Разработчики, в свою очередь, обязаны делать выбор, какой блокчейн будет для них более подходящим.
Акселар помогает блокчейнам взаимодействовать друг с другом предоставляя для этого децентрализованную сеть. Проектам/блокчейнам не нужно делать никаких изменений со своей стороны.
Для обеспечения безопасности, Axelar использует независимых валидаторов.
Функциональная совместимость (также интероперабельность от англ. interoperability — способность к взаимодействию) — это способность продукта или системы, интерфейсы которых полностью открыты, взаимодействовать и функционировать с другими продуктами или системами без каких-либо ограничений доступа и реализации.
Существут проблема, что пользователи не могут взаимодействовать с любым приложением и блокчейном по своему выбору напрямую из своего кошелька.
Рассматриваемый нами Акселар решает эту проблему, являясь так называемым мостом между блокчейнами (не путать с обычными крипто-мостами, которые просто монетки переводят из одного блокчена на другой (но он и это может)). Это позволяет разработчикам делать сервисы, которые доступны на всех блокчейнах, увеличивая при этом гибкость, как для разрабов, так и для пользователей.
Рядовому пользователю нет дела, TRX, SOL или BSC использует приложение. Ему надо “чтобы работало”. Разрабам же не надо решать между эфиром, ниром (привет его разрабам), соланой и прочими сетями, подбирая преимущества и недостатки для себя и для юзеров. Ему же нужно выбрать то, что больше подходит для решения определенной задачи.
КОР Протокол состоит из протокола межсетевого шлюза (взаимодействия) (Cross-Chain Gateway) и межсетевого транспортного протокола (Cross-Chain Transfer protocol).
По большому счету первый отвечает за само взаимодействие между блокчейнами. Второй же - за передачу, блокировку/разблокировку средств между разными блокчейнами.
CGP (межсетевой шлюз, это первый), используется для соединения автономных блокчейн-экосистем друг с другом и обеспечивает маршрутизацию между сетями. Блокчейнам ненужно быть построеными на одном и том же языке программирования. Вместо написания кастомных решений (по факту - костылей), разработчикам нужно просто подключить свое творение к общей системе, которая берет на себя взаимодействие между экосистемами.
CTP (второй который, кроссчейн транспортный протокол), как уже говорил, отвечает за передачу, блокировку/разблокировку средств между разными блокчейнами. Но также он отвечат за триггеры. При “таком то событии” сделать “то-то” в другой сети. Это работает и со смарт контрактами. Считай это неким подобием http, либо протоколом уровня приложений. Пользователи могуть использовать простые апи запросы, аналогичные ГЕТ, ПОСТ.
Из особенностей я бы выделил:
- Подключи и используй. Тут все и так понятно. Минимальные усилия с получением желаемого результата
Поддержка Кросс чейн рутов. Считай это Протоколом маршрутизации в нашем вебе.
https://habr.com/ru/post/184350/
https://ru.wikipedia.org/wiki/Border_Gateway_Protocol
(если не интересно, то и не забивай голову) - Поддержка обновлений. При обновлении одного блокчейна, другой не пострадает. Просто и логично.
- Единый язык уровня приложений. Вспоминаем сравнение с http. Он по большому счету везде одинаков.
- Безопасность поддерживается DPOS (делегированным proof of stake) - пользователи дают свой стейк. В рамках консенсуса валидаторы запускают клиентское ПО других блокчейнов, чтопозволяет проверять их состояние. Валидаторы сообщают об этих состояниях в блокчейн Axelar, и как только их становится достаточно, состояние биткойнов, эфириума и других цепочек записывается в Axelar.
Сейчас будут сильно технические моменты, так что либо слушай внимательно, либо не слушай вообще.
Итак. Каждый валидатор имеет вес от 0 до 1, обозначающий силу голоса этого конкретного валидатора. Веса всех валидаторов в сумме составляют 1. Валидатор корректный, если запускает узел, который согласуется с правилами протокола Axelar. Для финализации блоков или подписания запросов между цепочками Axelar требуются правильные валидаторы с общим весом больше порога. Это число от 0.5 до 1.
Валидаторы запускают консенсус Byzantine Fault Tolerant (BFT) в каждом раунде i, чтобы завершить i-й блок. Как только i-й блок завершен, запускается новый консенсус BFT для завершения i + 1-го блока и так далее.
Различные блокчейны работают с разными сетевыми предположениями. Синхронная связь означает, что существует фиксированная верхняя граница времени доставки сообщения, где это время известно и может быть встроено в протокол. Асинхронная связь означает, что доставкаможет занять сколь угодно много времени, и известно, что протоколы консенсуса не могут быть созданы для асинхронных сетей даже при наличии только одного злонамеренного валидатора. Компромиссом между синхронностью и асинхронностью является предположение о частично синхронной коммуникации. Сеть может быть полностью асинхронной до некоторого неизвестного глобального времени стабилизации (GST), но после GST связь становится синхронной с известной верхней границей ∆.
Для синхронных сетей обычно устанавливается как ½ либо ⅔. Текущий порог по сути для всех поддерживаемых на данный момент установлен на 51-ом проценте, если судить по акселарскану. При коннекте экосистем через Axelar, соединение работать будет по самому высокому порогу. Пример. Биток - синхронность, космос - частичная синхронность. Значит, работам по полной.
Блокчейн Axelar работает в частично синхронном режиме и, следовательно, требует прогора 2/3, но можно улучшить пороговое требование, предполагая, что другие существующие блокчейны являются безопасными и используя их безопасность.
Криптографические предварительные сведения
Цифровые подписи. Схема цифровой подписи представляет из себя набор алгоритмов. Keygen выдает пару ключей (PK, SK). Только владелец одного может подписывать сообщения, но любой может проверить подписи с помощью другого открытого ключа.
Далее нужно будет понимание нескольких протоколов, так что углубляться сильнее не будем.
Cross-Chain Asset Transfer
Давай перейдем к чему-то более реальному. Мост между блокчейнами. Если не в курсе, то суть такая. Есть монетка в одной сети, тебе нужна монетка (такая же, либо другая) в другой сети
Вот как это работает
1. Пользователь (или приложение, действующее от имени пользователя) отправляет запрос, который впоследствии направляется в сеть Axelar.
2. Валидаторы Axelar используют пороговую криптографию для коллективного создания нового адреса депозита (dS) и публикуют его в блокчейне Axelar.3. Пользователь (или приложение) мониторит этот адрес на блокчейне Axelarа. Пользователь отправляет столько то таких-то токенов на этот адрес. Ничего экстраординарного, обычная транзакция в блокчейне изначальной сети.
4. Транзакция размещается на Акселаре. Валидаторы шлют запрос через API нашего изначального блокчейна на наличие такой-то транзакции, и, если ответ “да, есть такое”, то сообщают это и Axelarу.
5. Как только количество валидаторов, говорящих, что транзакция была (или не была) проведена становится больше порогового значения, то Axelar просит валидаторов подписать другую транзакцию, которая отправляет энное количество обернутых токенов с Акселара.
6. Валидаторы подписывают транзакцию. Подпись включается в блок так называемого раунда R+11.
7. Кто угодно берет подпись из этого блока R + 11 и отправляет всё в желанный нами блокчейн.
8. Запрос был обработан, как только появилась запись во втором (конечном) блокчейне.
А пока минимальное саммари:
Если прям ОЧЕНЬ коротко и не совсем корректно - один протокол и АПИшечка и твое невероятно важное приложение с добавлением небольшо количества магии, может работать со всеми экосистемами.
Поскольку тема достаточно сложная, тут мы прервемся. Если хочешь, чтобы мы погрузились еще глубже и поковырялись во внутренностях, о том, как реализовано проектирование открытой кросс-чейн сети, протоколы, которые мы поверхностно охватили сегодня и особенности реализации безопасности системы, то дай мне об этом знать.
Скоро увидимся.
https://habr.com/ru/post/184350/
https://ru.wikipedia.org/wiki/Border_Gateway_Protocol
https://axelar.network/wp-content/uploads/2021/07/axelar_whitepaper.pdf
Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony. https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf.
Chelsea Komlo and Ian Goldberg. Frost: Flexible round-optimized schnorr threshold signatures. Cryptology ePrint Archive, Report 2020/852, 2020. https://eprint.iacr.org/2020/852
Это был сценарий подкаста
https://link.chtbl.com/jun-ru