Белая книга Akamon β v1
Akamon β: решение для обеспечения совместимости Cardano и Polygon
MELD Labs
Абстрактно
В этой статье представлено текущее состояние Akamon β, нативного моста между Cardano и Polygon. Цель состоит в том, чтобы использовать эффективную инфраструктуру обеих сетей для объединения и использования собственных активов между сетями.
Акамон стремится быть мостом, управляемым сообществом, открытым для всех, подчеркивая децентрализацию и надежную опеку. Тем не менее, во втором варианте мы должны начать где-то посередине и продолжать настаивать на децентрализации в более поздних версиях. Цель состоит в том, чтобы итеративно улучшать и собирать опыт на ходу. Например, ранняя полуцентрализованная версия testnet предлагает нам практический UX, инфраструктуру, экономику и операционные основы, чтобы больше сосредоточиться на децентрализации от γ.
1. Введение
Функциональная совместимость блокчейна[7][8][1][4] — относительно новая область, которая постоянно развивается.
Люди строят блокчейн мосты, чтобы обеспечить связь между различными сетями. Хотя большинство решений используют базовую функциональность переноса активов с одного конца на другой, их архитектура может существенно различаться.
С WBTC у нас есть многоучрежденческий дизайн с надежным хранением, KYC,
и AML. С другой стороны, такие проекты, как RenVM, нацелены на безнадежную опеку.
Акамон исследует различные архитектуры и методы, начиная с моста между реестром eUTXO[2] в Cardano и аккаунтом в Полигон[3]. Мы начинаем с полностью централизованного дизайна в α, а затем начинаем децентрализовать его с каждой новой итерацией дизайна, такой как β. Мы также изучаем возможности оптимизации для предотвращения перегрузки сети, улучшения децентрализации, управления структуры, время расчетов, эффективность капитала, интеграция dApp и многое другое.
Помимо переноса нативных активов между двумя цепочками, мы также планируем интегрировать DEX на обоих концах, чтобы поддерживать обмены между цепочками в эффективном режиме и в удобный способ. Дополнительные функции включают публикацию мультиподписанных данных Oracle от Полигона до Кардано и не только.
2 Akamon β
Akamon β — это вторая итерация дизайна среди многих, которые мы разрабатываем. Мы проектируем мост итеративно, чтобы сосредоточиться на новой фундаментальной концепции с каждой итерацией.
α сосредоточился на настройке UX, инфраструктуры и операционных основ для
более поздние версии, таких как β, чтобы начать децентрализацию.
Ключевой концепцией всех итераций является перенос активов между цепочками, например, круговой маршрут ADA можно увидеть ниже
Пользователи сначала отправляют ADA или mMATIC в скрипт в цепочке, чтобы инициировать запрос.
Отправка ADA — это минт mADA на Полигоне. Отправить mMATIC - это сжечь их
на Cardano, чтобы получить MATIC на Polygon. Затем подтверждение происходит, когда валидаторы подписывают, чтобы подтвердить запрос. Когда будет собрано достаточное количество подписей, пользователи получили токены на другом конце моста. Процесс подтверждения должен развиваться с каждой итерацией, от централизованного (одна подпись) до полностью децентрализованного
(узлы сообщества).
Мостовые узлы размещают заблокированные токены для получения дополнительных доходов. Эта структура позволит пользователям платить более низкие комиссии за транзакции на основе более значительных движений. Существуют также программы скидок для держателей NFT Akamon, для пользователей, которые оплатят комиссию за перевод в MELD и многое другое. Кроме того, мы разрешаем пользователям оплачивать комиссию в очень гибкие способы. Например, пользователи могут оплатить полную плату за мост в MELD,
не тратя при этом ни единого ADA.
Из-за итеративного характера процесса важно построить миграцию фреймворков для плавного перехода от одной итерации к другой. Этот процесс включает миграцию как данных, так и активов, что не так просто сделать правильно. β имеет миграцию, встроенную как в Cardano, так и в Polygon для дальнейших обновлений "β" и "γ" транзакциях.
2.1 Обернутые токены
В α мы развернули централизованные контракты для обернутых токенов, начиная с МАДА и мМАТИК. В β мы развертываем контракты с несколькими подписями, чтобы начать децентрализацию токенов. Мы также добавили больше встроенной поддержки токенов от обоих цепочек, такие как MELD от Cardano и WBTC от Polygon. Кроме того, мы будем поддерживать оплату сборов за мост в нативных токенах, таких как MELD (как частично, так и целиком) со скидкой от β.
В Мумбаи токен-контракт β mADA 0xCbdFD52b3314057990678D07DD6b04FF511C0b0c, который является прокси-контрактом для реализации ERC20. Любой может сжечь свои токены и тогда мост(бридж) контракт может создавать больше тех же токенов, когда будет собрано достаточное количество подписей узла.
Мы развертываем больше нативных токенов Cardano в Мумбаи для
МЭЛД, MAL и других. Мы также рассчитываем на сотрудничество с dApps на
Polygon для добавления в белый список и поддержки обернутых токенов. Например, для обмена mADA и mMELD с QUICK и LINK на QuickSwap.
В общедоступной тестовой сети Cardano (1097911063) идентификатор политики β упакованного токена 193db17d14543131f4c382b1a7c4c70e55dd47b44c6701727a817219.
Как и в случае со стороной Polygon, каждый может сжечь свои собственные завернутые токены и тогда бридж-контракт может минтить больше токенов после того, как было получено достаточное количество подписей узлов.
Главными приоритетами для перехода на Cardano на данный момент являются BTC, ETH, и стабильные монеты в долларах США. Цель состоит в том, чтобы принести массовую ликвидность новой волне децентрализованных приложений Cardano, которые поставляются с хардфорком Vasil. Мы в MELD Labs
проектируем несколько таких монет для эпохи Бэббиджа на Cardano с учетом этой ликвидности.
Мы также можем интегрировать Akamon с DEX, чтобы разрешить межсетевые свопы в эффективный и удобный для пользователя способ.
Помимо обернутых токенов, мы также рассматриваем обернутые мультиподписанные токены. Данные из Polygon в Cardano и наоборот. Например, мы могли бы написать данные Oracle ChainLink от Polygon к скрипту Cardano, который проверяет подписи валидатора. Когда Vasil попадает на эти UTxO данные он может ссылаться на несколько скриптов DeFi для расчета коэффициента обеспечения, принятия решения о том, кто выиграет ставку, и более.
2.2 Требования к децентрализованному приложению (dApp)
Мы определяем несколько требований для этой итерации моста.
• Запрос моста действителен, когда N из M узлов валидатора вошли в систему. Подписи должны быть проверены в сети.
• Плата за мост состоит из комиссии за объем, минимальной комиссии ADA на Cardano, и платы за базовую сеть. Плата за бридж оплачивается в нативном токене исходной цепи. Например, переход от Cardano к Polygon оплачивается в АДА. Перевод с Polygon на Cardano оплачивается в MATIC. Когда происходит обертывание собственных токенов Cardano, которые не являются ADA (например, MELD) - то пользователи должны заблокировать этот токен и некоторые ADA, чтобы покрыть значение min-ADA, узел валидатора покрывает это минимальное значение ADA для запросов от Polygon в тот момент как пользователи уже заплатили его в MATIC на Polygon.
• Плата за мост должна быть указана и подписана узлом валидатора и принята
пользователем перед завершением промежуточной транзакции и отправкой ее в
сеть. Собранные сборы хранятся в ончейн-контракте, чтобы быть позже распределенными между узлами валидатора.
• Пользователь не может отменить запрос моста.
• Мы не зависим от хардфорка Vasil на Cardano.
Другие предположения, которые следует учитывать:
• N из M узлов валидатора являются доверенными на каждый запрос моста.
• Нам нужна миграция для обновления списка узлов валидатора.
• Мы распределяем плату за мост в соответствии с заранее установленным соотношением между валидатором узла.
2.3 Архитектура
2.4 Скрипты валидатора Cardano
Мы внедряем скрипты валидатора Cardano в Plutus и строим транзакции
с нашей библиотекой cardano-tx-builder. Для тестирования мы используем EmulatorTrace для минимальных несчастливых случаев и стек анализа Hachi для проверки свойств с символьным выполнением.
2.5 Смарт-контракты Polygon
В основном мы используем библиотеку OpenZeppelin Contracts для написания смарт-контрактов, особенно обновляемый вариант. Мы используем Hardhat для запуска частной тестовой сети и Truffle для написания контрактных тестов для этой тестовой сети.
Все еще требуется много улучшений, и мы с нетерпением ждем заключения нескольких контрактов аудитов, когда мы попадем в тестовую сеть.
2.5.1 Жизненный цикл запроса моста
Сначала пользователь отправляет информацию о запросе в Akamon API, чтобы процитировать подписанную плату за мост.
• Если Polygon является исходной цепочкой, пользователь создает транзакцию, которая вызывает договор с подписанным гонораром и информацией о запросе в качестве параметров.
Затем подписанная плата проверяется в сети. Для упаковки токены
заблокированы в контракте журнала и сборах, и отправлены в FeeCollector
договор. Для распаковки токены сжигаются напрямую с отправкой комиссий к контракту FeeCollector.
• Если Polygon является цепочкой назначения, узел проверки сохраняет запрос.
(идентификатор транзакции, адрес назначения, токен запроса, сумма запроса) в договоре журнала. Другие валидаторы подписывают, чтобы подтвердить это в сети. Последняя требуемая подпись помечает запрос как выполненный, а затем чеканит или возвращает заблокированные токены пользователю.
Контракт журнала обрабатывает все действия валидаторов и пользователей.
• Для валидаторов этот контракт включает список запросов на перенос и распаковку от Кардано до Полигона. Валидатор может обновлять несколько запросов в транзакциях (создать, подписать и выполнить). Все запросы уникальны по своему id (закодировано и хешировано из информации запроса, включая идентификатор транзакции Cardano).
Чтобы уменьшить комиссию за газ, потраченную впустую при неудачных транзакциях валидатора, мы никогда не отменяем вызов транзакции валидатора, но игнорируем остаточную информацию насколько это возможно. Например, если валидатор создает существующий запрос, мы помечаем его как транзакцию подписи. Когда валидатор подписывает запрос с достаточным количеством подтверждений, запрос выполняется немедленно в той же транзакции.
• Пользователи могут переносить и распаковывать токены из Polygon в Cardano с помощью совершения звонков в журнал контракта.
Контракт FeeCollector собирает все сборы моста. Любой желающий может позвонить в контракт на распределении комиссии между узлами валидатора на основе заранее определенного соотношения.
Соотношение может быть обновлено только транзакцией, подписанной всеми узлами валидатора.
2.5.2 Листинг нового токена
Каждому токену на Polygon нужен собственный адрес смарт-контракта. Мост должен развернуть по одному адресу для каждого нового обернутого токена, который он хочет поддерживать. Валидаторы нод сначала договариваются вне сети о создании контракта, прежде чем обновлять свои ноды (и конфигурации соответственно). Хорошая часть заключается в том, что нам не нужно обновлять договор журнала. Узлы валидатора могут отклонять запросы, содержащие недопустимые обернутые токены.
2.5.3 Миграция контракта
Мост использует настройку прокси для обновления своей реализации контракта, в то время как сохраняет свое состояние адреса и баланса при необходимости. Такая миграция требует мультиподписей от узлов валидатора и полезна для работы в режиме реального времени патчев и оптимизации.
Кроме того, мы можем перенести весь мост на новый адрес контракта следуя этим шагам:
• Разверните новую версию контракта моста на новый адрес с соответствующим состоянием.
• Создайте запрос на миграцию в миграционном контракте, включая старый
адрес, новый адрес и список токенов, которые вам нужно перевести из
старого адреса на новый.
• После того, как запрос получит достаточное количество подтверждений, он может быть выполнен, и токены переводятся на новый адрес.
В текущем состоянии нам нужно сначала обновить бридж-контракт через прокси и разрешить перемещение активов из старого контракта.
2.6 Akamon DB
Служба Akamon DB в PostgreSQL является сердцевиной узла проверки.
Два индексатора, один для Cardano и один для Polygon, синхронизируют данные моста из соответствующей цепочки к базе данных Akamon. Затем узел валидатора может читать новые запросы и обрабатывать. Кроме того, сервер API Akamon может обслуживать данные из БД для рендеринга пользовательского интерфейса.
Наши цели для схемы БД состоят из трех частей:
• Все данные должны записываться и синхронизироваться с цепями. Это должно послужить тому что бы безопасно синхронизироваться в БД с нуля в любое время.
• Управление откатами цепочек должно быть простым и последовательным.
• Запрос данных должен быть простым и эффективным.
Мы ожидаем, что схема БД будет расширяться, поскольку мы стремимся к большему количеству особенностей моста со временем. Возможность безопасной повторной синхронизации с нуля очень важна.
2.7 Индексатор Akamon Cardano
Существующие решения для индексации на Cardano слишком ресурсоемкие, медленные и негибкие для наших нужд. Также непросто синхронизировать данные напрямую с узла Cardano для использования dApp. Поэтому мы создали собственный кардано-индекс фреймворк для различных вариантов использования, включая Akamon β.
Наш фреймворк cardano-index использует соединение Node-to-Client в
ChainSync от Ouroboros в качестве базового протокола. Связь постоянно
передает события нашему индексатору всякий раз, когда узел получает новые блоки или обнаруживает откат. Каждое из наших dApp затем записывает свои обработки событий в приложении уровней, чтобы указать, как извлекать и сохранять данные для каждой транзакции без опасение откатов. Все данные сохраняются в базе данных PostgreSQL в Akamon БД для Akamon Node и API для запросов.
Akamon — это первый продукт, для которого мы используем наш собственный кардано-индекс. Мы многому научились на практике и могли бы существенно улучшить структуру. Мы собираемся перенести наше ядро plutus-chain-index-core на основе службы meld-index в cardano-index для всех будущих потребностей протокола MELD.
2.8 Полигональный индексатор Akamon
Мы используем The Graph как стандартное отраслевое решение для индексации, похожее на EVM блокчейны. Помимо своего основного компонента Graph Node, The Graph использует две другие внешние услуги:
• Узел IPFS, на котором размещены объявления подграфа.
• База данных PostgreSQL в качестве базового решения для хранения.
Затем код нашего приложения указывает:
• Схема GraphQL формата данных, которые мы хотим сохранить в базе данных.
• Декларативная конфигурация контрактов, событий и типов данных, которые мы
хотим проиндексировать.
• Для каждого обработчика событий на языке AssemblyScript записывается сопоставление, определяющее как извлекать, загружать и сохранять данные.
График регулярно запрашивает узел многоугольника для обработки новых блоков и транзакций на основе этих спецификаций. Наш код сопоставления приложений делает не нужным беспокойства о реорганизациях, поскольку The Graph автоматически их обнаруживает. Пока Graph предоставляет интерфейс GraphQL, наше текущее решение предпочитает необработаную производительность и выразительность базовой базы данных PostgreSQL. Это говорит о том, что по-прежнему полезно иметь службы GraphQL для облегчения отладки, эксплуатации и потребности.
2.9 Akamon Node
Узел Akamon связывает основные компоненты в единую исполняемую службу, включая базу данных, конфигурации Cardano и Polygon также взаимодействие с ними, соответствующие службы, и время выполнения.
Центральный поток обработки должен читать проиндексированные пользовательские запросы из Akamon БД, решите что делать (создавать новые запросы в цепочке, подписывать, выполнять или отклонять
существующие запросы), создайте и опубликуйте для него транзакцию и повторите.
Другие действия узла включают слияние UTxO Locker на Cardano и распределение сборов на обоих сторонах.
Обратите внимание, что поток обработки на каждом из них относительно различен и разделен из-за различий между двумя цепями. Например, мы используем нашу собственную библиотеку cardano-tx-builder для построения транзакций на платформе Cardano.
Как и в случае с кардано-индексом, мы многому научились на практике когда запустили cardano-tx-builder. Мы продолжим использовать его в других проектах с открытым исходным кодом для всего сообщества, когда он будет готов. Инструмент на стороне многоугольника относительно надежен и удобен для нас, чтобы ничего не катить самостоятельно.
Одна интересная проблема запуска автономных решений для нескольких сетей заключается в следующем:
проблема слежения за живучестью. Ончейн одной сети — это офчейн другой,
поэтому некоторые гарантии не сохраняются при обработке транзакций между цепочками. Например, отстающий узел на стороне полигона может отклонить действительные пользовательские запросы в скрипте Cardano on-chan, потому что запросы еще не существуют из-за его рассинхронизированного представления. В настоящее время мы следим за тем, чтобы наши индексаторы
обновлялись перед выполнением действий с узлом.
Наконец, если мы правильно спроектируем базовые абстракции, модули узла должны оставаться очень маленькими, даже когда мы начнем поддержку новых сетей. Две потенциальные для нас на данный момент сети: Avalanche и Nervos.
2.10 Akamon API
Служба API Akamon обслуживает данные из базы данных Akamon для рендеринга пользовательского интерфейса с другими конечными точками для улучшения интеграции UX и MELDapp, в том числе промежуточную статистику, такую как средние сборы, ожидаемое время обработки, статус транзакции и
листинг.
По мере того, как мы со временем децентрализуем мост, члены сообщества должны иметь возможность для создания и эксплуатации собственного интерфейса Akamon поверх своего узла и API сервера. На данный момент MELDapp будет первым и единственным интерфейсом Akamon.
2.10.1 Оплата сборов Akamon в MELD
Мы успешно создали прототип системы комиссий, которая позволяет пользователям платить комиссию из стороны Cardano в нативных токенах, не тратя ни одного ADA. Технически, пользователям по-прежнему нужен ADA для хранения собственных токенов, но эти значения можно зарезервировать для
удерживания изменения транзакции. Пользователям не нужно пополнять запасы на ADA, и можно, скажем, время от времени снимать вознаграждения за ставки MELD для оплаты любых комиссий в рамках MELD и протокола Акамон со скидкой.
Механика проста, но мощна и гибка. Сначала пользователи отправляют запрос взаимодействия с их UTxO, установленным на конечную точку Akamon. Затем конечная точка создает и подписывает сбалансированную транзакцию, которая оплачивает нативную транзакцию пользователя, используя свои собственные ADA UTxO для покрытия остальных. Затем пользователь предварительно просматривает транзакцию в интерфейсе, подобном кошельку Nami. Если пользователи согласны с предложением моста - они могут войти в систему и отправить возвращенную транзакцию, эффективно выполняя взаимодействие моста, не тратя ни единого АДА.
Поскольку обобщенным случаем является совместно подписанное P2P-соглашение о сделке, эта система оплаты позволяет мостовым узлам проводить произвольные программы скидок, такие как: взимать меньшую плату для пользователей, у которых есть Akamon NFT и многое другое. Пользователи могут пропустить сделку и не подписывать сделку, если они считают, что предложение слишком дорогое или неудобное.
Единственным недостатком на данный момент является сложность управления UTxO.
Только одна транзакция может пройти, если один и тот же UTxO предлагается дважды для разных пользователей. Мы планируем создать множество UTxO для варианта использования и внедрить как стратегии выбора монет с сохранением состояния, так и без сохранения состояния.
3 Akamon γ
Как только β станет стабильной в основной сети, мы начнем работу над следующей версией в γ. Первая цель — более децентрализованная установка с, надеюсь, узлами сообщества.
Вторая цель — производительность. Например, γ сможет использовать
новые функции хардфорка Vasil на Cardano для снижения комиссий и улучшения
пропускной способности.
Потребности пользователей и то, как они взаимодействуют с мостом, должны оставаться неизменными независимо от его базовой архитектуры. Не следует жертвовать UX, чтобы быть немного больше децентрализованным, если это вообще поддается количественной оценке. Во всяком случае, мы должны поднажать для еще лучшего UX с каждой итерацией.
Мы планируем выпустить первую статью по Akamon γ к 2023 году. Запуск тестовой сети должен последовать вскоре после этого.
4 Связанная работа
4.1 WBTC
WBTC[5] — одно из первых в истории широко используемых решений по интероперабельности блокчейна. Он надежно связывает Биткойн с Эфириумом, но использует мультиинституциональный дизайн для распределения доверия и власти. Дизайн WBTC стал устаревший в настоящее время, с такими недостатками, как KYC и AML. Тем не менее, он привнес много правильных идей в пространство функциональной совместимости, включая, помимо прочего, акцент на безопасность, дизайн модели доверия, управление на основе DAO, сайдчейн для масштабируемости, атомарные свопы для обернутых токенов и регулирование.
4.2 RenVM
RenVM — это византийская отказоустойчивая сеть, обеспечивающая универсальное взаимодействие между блокчейнами. Сочетая консенсус со своими алгоритмами безопасных многосторонних вычислений (MPC[6]), RenVM может создать децентрализованный, не требующий разрешения и не требующий доверия хранитель, способный блокировать активы на одном сервере, цепочке и чеканить их привязанные представления один к одному в других цепочках.
Таким образом, пользователи могут взаимодействовать с несколькими приложениями, активами и цепочками только с одной транзакцией.
На первый взгляд, RenVM делает все правильно и должен быть образцом для подражания для ненадежных мостов. Единственным недостатком является сложная конструкция по сравнению с доверительным решением, нетривиальным требованием по количеству валидаторов, их обеспечение и узел с закрытым исходным кодом при написании.
Мы также планируем изучить возможность создания встроенной поддержки Cardano на RenVM.
4.3 Force Bridge
Force — это мост, соединяющий Nervos с другими блокчейн-системами. Nervos недавно запустил первую версию основной сети, которая поддерживает Ethereum.
В конечном итоге за ними должны последовать Cardano, Bitcoin и другие сети.
Мост будет поддерживать легкого клиента в нотариальной схеме с несколькими подписями на первом этапе. Комитет, состоящий из Фонда Нервос и
члены сообщества отправят заголовки легкому клиенту и свою подпись.
Мост заменит multi-sig-light-client на втором этапе на облегченный клиент на основе консенсуса. Он будет полностью децентрализован, где каждый
может отправлять заголовки. Контракт проверит заголовок с консенсусом
алгоритма цепочки.
Другие номинации включают WanChain и Nomad. Мы изучаем все эти
решения для потенциального вдохновения и сотрудничества.
5. Выводы
Мы сосредоточимся на высокоуровневых описаниях текущего состояния Акамон β в первые две версии официального документа. Мы рассчитываем охватить гораздо больше глубин, третья версия будет опубликована к концу июля 2022 года, когда β попадет в основную сеть.
Использованная литература
[1] Рафаэль Белхиор, Андре Васконселос, Серхио Геррейро и Мигель Коррейя.
Обзор функциональной совместимости блокчейна: прошлые, настоящие и будущие тенденции,
05 2020.
[2] М. Чакраварти, Джеймс Чепмен, К. Маккензи, Орестис Мелконян, М.П.
Джонс и П. Уодлер. Расширенная модель utxo. В финансовой криптографии
Семинары, 2020.
[3] Джайнти Канани, Сандип Найлвал и Анураг Арджун. матовая белая бумага,
2020.
[4] Паскаль Лафуркад и Мариус Ломбард-Плате. О совместимости блокчейна, 05 2020.
[5] Kyber Network, BitGo Inc и Repulic Protocol. Завернутые жетоны, 2019.
[6] Росс Пьюр и Цзянь-Лун Ван. Renvm безопасные многосторонние вычисления,
2020.
[7] Алексей Замятин, Мустафа Аль-Бассам, Дионисис Зиндрос, Элефтериос КокорисКогиас, Педро Морено-Санчес, Ангелос Киайяс и Уильям Дж. Ноттенбелт. Sok: Связь между распределенными реестрами. У Никиты Борисова.
и Клаудия Диас, редакторы, Financial Cryptography and Data Security, стр.
3–36, Берлин, Гейдельберг, 2021. Springer Berlin Heidelberg.
[8] Алексей Замятин, Доминик Харц, Джошуа Линд, Панайотис Панайоту,
Артур Жерве и Уильям Кноттенбельт. Xclaim: надежные, интероперабельные активы, обеспеченные криптовалютой. На симпозиуме IEEE по безопасности 2019 г.
и конфиденциальность (SP), страницы 193–210, 2019 г.