クロスチェーンアプリ(xApps)の構築 / dAppをxChainにアップグレード
Connextは、ビルダーがセキュアなxchain dApps（xapps）を作成できるように取り組んでいます。私たちのネットワークは、基盤となるブロックチェーンのセキュリティを保持したxAppsを構築する唯一の方法となるのです。
xAppsとは？
xApps（「ザップ」と発音）は、独立したチェーン/実行環境、EthereumとAvalanche、PolygonとPolkadot、さらにはOptimismとArbitrumなどの間で操作を行う分散型アプリケーションです。
マルチチェーンからxchainへの移行
マルチチェーンのデプロイは既に存在し、Aave、Yearn、Curve、どれも多くのチェーンで複数のインターフェイスを持っています。これらのアプリはすべて異なるチェーンで使用できますが、互いにサイロ化された別のアプリのように動作します：これらはマルチチェーンであり、xchainではありません。
では、どのようにxchainパラダイムで構築すればよいのでしょうか？
- インターフェイスの統一: 全てのチェーンのデータを集約し、ユーザーに1つの統合された体験を提供するインターフェイスを構築する
- ホームチェーンを抽象化: ユーザーがどこからやり取りを開始したかに関わらず、サポートされているすべてのチェーンからユーザーの残高とアクションを認識させる
- xCallでトランザクションを任意のチェーンにルーティング: Connextを使用して、ユーザがシングルステップで任意の受信チェーンのコントラクトコールを実行したり、コントラクト同士を直接接続したりする
理想的な結果としては、ユーザーがどのチェーンからも流動性やデータにアクセスできる単一のインターフェースを持つxappとなります。ユーザーが、今自分がどのチェーンにいるのかなど、気にする必要はないはずです。
では、何を作ることができるか？
いくつかのアイデアを紹介します：
- xChain zaps: LPアプリと同様に、あるチェーンの資産を保持している場合、それを別のチェーンのファームにザッピングし、LPに分割して直接入金することが可能になります
- xChainのガバナンス: 現状では、dAppのネイティブチェーンではないチェーンにブリッジされたガバナンストークンを保有している場合、投票することはできません
- チェーン間利回りの最適化:トークンを別のチェーンにブリッジし、利回りを収穫し、利益を持ち帰る
- Dexアービトラージ: Dexアービトラージャーがチェーン間で異なる市場価格を実行し、利益を得るための機会を提供
- xChain borrowing: チェーンAで担保を追加し、チェーンBで別の資産を借り入れ可能に
xchainで何ができるのかについては、まだ表面を削り始めた段階に過ぎません。
ConnextでxAppsを構築する
dAppsの構築は困難な作業を伴います。チェーンが増えると、コントラクトのデプロイ、デプロイ済みアドレスの管理、ステートの読み取りと書き込み、RPCプロバイダ/ノードの管理など、全てがビルダーとユーザーにとって指数関数的に複雑さを増すことになります。
Connextは、最高レベルのセキュリティを備えたクロスチェーンアプリケーションの構築経験を簡素化します:
- ネイティブxAppsのための統一されたスマートコントラクト・インターフェースは、Connextを使用することで、どのようなクロスチェーン処理を行うかを正確に選択でき、単一の統一インターフェースによって開発の複雑さを大幅に軽減します。
- インスタントな流動性ブリッジングとcalldataパッシングは、プロトコルが受信チェーン上の関数を呼び出すことによって、ユーザーからガスインターフェースを抽象化することができます
- メッセージパッシングに関しては、単方向および双方向のメッセージパッシングが可能となります
単方向のメッセージパッシングでは、あるチェーンから別のチェーンに信頼なくメッセージを渡すことができ、それが特定のソースから来たものであることを検証できることを意味します。あるチェーンから別のチェーンに投票したい場合、信頼できる方法でそれを行うことができます。
双方向では、あるチェーンにリクエストを送り（例えば、TWAPの価格を読む）その結果を元のチェーンに戻す必要がある場合が考えられます
xAppsはイノベーションの新しい波であり、あらゆるdAppの将来の標準となるものなのです。
では、どのようにxAppを構築するのでしょうか？
スマートコントラクトを書くにしても、Web/Node環境でConnextのSDKを使うにしても、クロスチェーン操作を行うためのxappを構築するには、クロスチェーンコール「xcalls」を送信するための標準パラメータのセットへの理解が最終的に必要となります。ここから先は、xcallに必要なパラメータについての簡単な入門書です。
xcall関数は、1つのXCallArgsの引数を取ります：
CallParamsに少し戻りますが、他のものから始めてみましょう。
- transactingAssetId:ブリッジされる資産のコントラクトアドレスを指し、ERC20に準拠したトークンも含まれます。xappは、アセットアドレスが引数として渡されるxcallをラップする上位の関数を保持しており、ユーザーがどのアセットで作業するかを指定できるようになっています。
- amount: 標準的なフォーマットで指定されたブリッジトークン量（例えば、¹⁰¹⁸の小数点を持つトークンである1 USDCを送るには、1000000000000と指定する必要があります）
- relayerFee:トランザクションを相手ドメインに中継するために中継者に支払われる手数料。Connext Amarok testnetでは、テストネット上の中継者は手数料を取らないため、この値は0に設定できます。しかし、メインネットでは、この値は中継者が取引を中継するためのコスト条件（ガス料金にインセンティブを上乗せしたもの）を満たすのに十分な高さである必要があります。この手数料はオリジンドメインのネイティブアセットで支払われ、オリジンドメインにロックされ、最終的にリレイヤーが請求する流れです。Connextのコントラクトは、relayerFeeが xcallのmsg.valueで送信されるものと一致することを保証します。何らかの理由で初期のrelayerFee が低く設定された場合、BridgeFacet.bumpTransfer をオリジンドメインで呼び出すことで、初期料金を中継者にとって十分な金額に引き上げることができます。
残りの引数はCallParamsです：
- to:これはデスティネーションチェーン上のアドレスを指すもので、ユーザーのウォレットアドレスか、他のコントラクトのアドレスかは、xcallの用途に依存します。xcallが単に資金のブリッジを意図している場合、ユーザーはこれを自分のウォレットまたはデスティネーションチェーン上の別のウォレットアドレスとして 指定できます。xcallがターゲットのコントラクトに任意のcalldataを送信することを意図している場合には、 アドレスはそのコントラクトのアドレスでなければなりません。
- callData:ブリッジングファンドのみの場合、これは空である必要があります。また、任意のcalldataを送信する場合、エンコードされたcalldataをここに渡す必要があります。
- originDomain / destinationDomain: NomadによってマッピングされるドメインIDを指すもので、これらのドメインIDは「チェーンID」と同等ではありません。
- recovery: 実行に失敗した場合に資金を送るための宛先側のリカバリーアドレスです。これによって、失敗したコールで送られた資金がまだアクセス可能であることが保証されます。
- callback: ICallbackインタフェースを実装したコントラクトのアドレスです。対象のコントラクトが何も返さない場合、このフィールドはZero Addressである必要があります。コールバックのインタラクションについては仕様を参照してください。
- callbackFee: relayerFeeに似ていますが、これはコールバック実行時に中継者に支払うためのものです。これもConnext Amarokのテストネットでは0に設定することができ、オリジンドメインからバンプ可能です。
- forceSlow:これをtrueに設定すると、ユーザーはxcallをNomadの低速パス（～30分）に強制的に通し、ルーターから課される0.05%のトランザクション手数料を節約できるようになります。スローパスのxcallは関係なくスローパスを通過するため、これはファーストパスの転送にのみ影響することに注意してください。速度を気にしないユーザーがコスト面で最適化するためのオプションとして機能します。
- receiveLocal:これをtrueに設定すると、ユーザーは宛先ドメインで採用されたアセットではなく、ローカルのNomad風味のアセットを受信することができます。
これらの知識を持って、ChainAからChainB上で実行されるcalldataを送信する簡単なスマートコントラクトのセットを書くことができます。また、ICallbackインターフェースを実装することで、ChainBからの実行結果をChainAで非同期的に反応させることも可能です。
上記の例では、Target.solコントラクトのdoSomething関数はパーミッション付きであることを意味しています。オリジンコントラクト（Source.sol）だけがターゲット関数を呼び出すことができるようにするためには、originSender()とorigin()のチェックは、この許可制を維持するために行われる必要があります。また、Source.solコントラクトでは、異なるドメインでの実行結果を非同期で処理できるコールバックの使用方法を示しています。
xcallを使用するには、チェーン間で許可されたcalldataを送信したり、単なる資金移動など、多岐にわたる方法があります。Connextは、エンドユーザーエクスペリエンスとセキュリティに重点を置きながら、クロスチェーンアプリケーションの構築を開発者にとってより身近なものにしています。
その他のリソース
- インターオペラビリティのトリレンマとOptimisticブリッジ
- モジュラー・インターオペラビリティ・スタック: Layneによるプレゼンの様子
- xAppsスターターキット (+ docs)
- 質問、お問い合わせはDiscordへ
- グラントの申請
今後のConnext Networkにご期待ください！
