Создание кроссчейн-приложений (xApps).

Обновите свое dApp до xChain

Connext позволяет разработчикам создавать безопасные xchain dApps (xApps). Connext— единственный способ создавать xApps, которые сохраняют безопасность базовых блокчейнов.

Что такое xApps?

xApps (произносится как «zaps») — это децентрализованные приложения, которые выполняют операции между независимыми сетями/средами выполнения, например Ethereum и Avalanche, Polygon и Polkadot, а также Optimism и Arbitrum.

Переход от мультичейн к xchain

Мультичейн уже здесь. Aave, Yearn, Curve — все они имеют несколько интерфейсов, во многих сетях. Хотя вы можете использовать все эти приложения в разных сетях, они действуют как разные приложения, изолированные друг от друга: они являются мульти сетевыми, а не xchain.

Как же построить парадигму xchain?

• Унифицируйте интерфейс: создайте единый интерфейс, который объединяет данные из всех сетей и дает пользователям единый, консолидированный опыт.
• Абстрагируйте «родную» сеть: распознавайте балансы и действия пользователей из любой поддерживаемой сети, независимо от того, откуда пользователь инициирует свое взаимодействие.
• xCall для маршрутизации транзакций в любую сеть: используйте Connext, чтобы позволить пользователям вызывать любой контракт принимающей сети, за один шаг или даже напрямую связывать ваши контракты друг с другом.

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

Что вы можете создать?

Вот несколько идей:

1. xChain zaps: аналогично приложениям LP, у вас есть актив в одной сети, вы загружаете его в фарминг, в другой сети, где вы можете разделить его на LP, а затем вносить напрямую, все это абстрагировано от пользователя.
2. Управление xChain: если у вас есть токены управления, которые были подключены к сети, которая не является родной для dApp, вы не можете голосовать. Голосование xChain станет стандартом для протоколов управления и DAO.
3. Оптимизация доходности по сетям. Перенесите токены в другую сеть, соберите награды, верните прибыль.
4. Арбитраж Dex: возможность для арбитражеров Dex работать и получать прибыль от разных рыночных цен в разных сетях.
5. Заем xChain: добавьте залог в сети A, займите любой актив в сети B.

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

Создавайте xApps с помощью Connext

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

Connext упрощает процесс создания межсетевых приложений с высочайшим уровнем безопасности:

1. Унифицированный интерфейс смарт-контрактов для нативных xApps. Вы можете использовать Connext, чтобы точно выбрать, какие операции с перекрестными сетями вы хотите выполнить; единый унифицированный интерфейс для снижения сложности разработки.
2. Мгновенный доступ к ликвидности и передача данных о запросах. Это позволяет абстрагировать газовый интерфейс от пользователя, позволяя протоколу вызывать функцию в принимающей сети.
3. Передача сообщений: однонаправленная и двунаправленная передача сообщений.

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

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

xApps — это новая волна инноваций и будущий стандарт для любого децентрализованного приложения.

Как создать xApp?

Независимо от того, пишете ли вы смарт-контракты или используете SDK Connext в среде Web/Node, создание xApp, для выполнения операций между сетями, в конечном итоге сводится к пониманию набора стандартных параметров, для отправки вызовов между блокчейнами («xCalls»). Ниже, краткое руководство по созданию необходимых параметров для xcall.

Функция xcall принимает один аргумент XCallArgs:

Через некоторое время мы вернемся к CallParams — давайте начнем с остальных.

• transactingAssetId: это относится к адресу контракта актива, который предназначен для моста. Это включает в себя любой токен, совместимый с ERC20. Обычно xApp будет иметь функцию более высокого уровня, обертывающую xCall, в которой адрес актива будет передаваться в качестве аргумента, чтобы пользователь мог указать, с каким активом он хочет работать.
• amount: количество токенов для моста, указанное в стандартном формате (т.е. для отправки 1 USDC, токена с 1⁰¹⁸ десятичными знаками, вы должны указать сумму как 10000000000000000000).
• relayerFee: это плата, выплачиваемая ретрансляторам, за трансляцию транзакции на другой домен. В тестовой сети Connext Amarok для этого параметра можно установить значение 0, поскольку ретрансляторы в тестовой сети, не берут никакой платы. Однако в основной сети это значение должно быть достаточно высоким, чтобы удовлетворять условиям затрат ретрансляторов на трансляцию транзакции, которые включают в себя плату за газ, плюс немного сверху, в качестве поощрения. Комиссия оплачивается в собственном активе исходного домена — она заблокирована в исходном домене, и в конечном итоге, запрашивается ретранслятором. Контракты Connext будут утверждать, что relayerFee соответствует тому, что отправлено в msg.value для xCall. Если по какой-либо причине начальная плата relayerFee установлена ​​слишком низкой, BridgeFacet.bumpTransfer можно вызвать в исходном домене, чтобы увеличить начальную плату, пока она не станет достаточной для ретрансляторов.

Оставшийся аргумент — CallParams.

• to: Это относится к адресу в сети назначения. Будь то адрес кошелька пользователя или адрес другого контракта, зависит от желаемого использования xCall. Если xCall предназначен для простого перевода средств, пользователь должен иметь возможность указать его как свой собственный кошелек или, возможно, адрес другого кошелька в сети назначения. Если xCall предназначен для отправки произвольных данных вызова целевому контракту, то этот адрес должен быть адресом этого контракта.
• callData: только в случае промежуточных средств, это поле должно быть пустым. Если должны быть отправлены произвольные данные вызова, то здесь должны быть переданы закодированные данные вызова.
• originDomain / destinationDomain: относятся к идентификаторам доменов, которые сопоставляются Nomad. Эти идентификаторы доменов не эквивалентны «идентификаторам сети».
• recovery: адрес восстановления, на стороне назначения, для отправки средств, в случае сбоя выполнения. Это гарантирует, что средства, отправленные с неудачными вызовами, по-прежнему доступны.
• callback: адрес контракта, реализующегоинтерфейс ICallback. Если целевой контракт ничего не возвращает, это поле должно быть нулевым адресом. Подробная спецификация обратного вызова.
• callbackFee: Аналогично relayerFee, за исключением того, что это плата за ретрансляторы, при выполнении обратного вызова. Опять же, может быть установлен на 0, в тестовой сети Connext Amarok. Эта плата тоже увеличивается с исходного домена!
• forceSlow: установка этого параметра в значение true, позволяет пользователям форсировать xCall, через медленный путь Nomad (~ 30 минут) и экономить на комиссии за транзакцию в размере 0,05%, взимаемой маршрутизаторами. Обратите внимание, что это влияет только на передачу по быстрому пути, поскольку вызовы xCall по медленному, пути будут проходить по медленному пути, в любом случае. Это вариант для пользователей, чтобы оптимизировать затраты, которым не важна скорость.
• receiveLocal: установказначения true позволяет пользователям получать локальный ресурс Nomad, вместо принятого ресурса в целевом домене.

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

Source.sol

Target.sol

В приведенном выше примере функция doSomething контракта Target.sol предназначена для разрешений. Другими словами, мы хотим, чтобы исходный контракт (Source.sol), мог вызывать целевую функцию. Вот почему должны выполняться проверки originSender() и origin() — для соблюдения этого требования разрешений. Контракт Source.sol, также демонстрирует использование обратных вызовов, когда результаты выполнения в разных доменах, могут обрабатываться асинхронно.

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

Дополнительные ресурсы

• Трилемма интероперабельности и оптимистичные мосты, наша модель безопасности.
• Что такое модульный стек функциональной совместимости? Посмотрите презентацию Лейна.
• Стартовый комплект для xApps + документы.
• Работаете над крутой идеей? Подайте заявку на грант!

О Connext

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

Ресурсы Connext: [Website] [Twitter] [Discord] [Docs] [Github] [Blog]