Opside の NCRC Trustless ネイティブ プロトコルに注目

Opside はテストネット上で NCRC を実装することに成功しました。公式ウェブサイトhttps://pre-alpha-assetshub.opside.network/ で誰でも体験できるようになりました。

トラストレスな相互ロールアップ通信が必要なのはなぜですか?

ロールアップは、ブロックチェーンのスケーラビリティを強化し、トランザクション コストを削減し、全体的な効率を向上させる機能として大きな注目と採用を集めています。 Opside は Web3 アプリケーション向けの ZK-RaaS サービスを提供し、開発者が Opside Rollup Launchbase を通じて独自のロールアップを作成できるようにします。複数のロールアップが存在するこの時代では、さまざまなロールアップの共存が増加すると予想され、異なるレイヤ 2 ソリューション間のシームレスな相互運用性が重要になります。

現在、ロールアップ間のやり取りは比較的孤立したままであり、リアルタイムのクロスチェーン通信やアセットの相互運用性が欠けています。この分離により、状況が断片化され、アセットが特定のロールアップ内に限定され、異なるネットワーク間での自由なフローと使用が制限されます。

効率的なロールアップ間のコミュニケーションが存在しないと、個々のロールアップの可能性が制限されるだけでなく、全体的なユーザー エクスペリエンスにも影響します。資産を転送したり、ロールアップ間でクロスチェーントランザクションを実行しようとするユーザーは、煩雑で時間のかかるプロセスに直面します。この次善のエクスペリエンスは、ロールアップの魅力を弱め、レイヤー 2 スケーリング ソリューションの広範な採用をある程度妨げます。

既存のクロスロールアップブリッジングソリューションでは、多くの場合、ロールアップチェーン上に新しいセットのインターチェーンコントラクトを展開し、マルチチェーン流動性インセンティブを利用して資産クロスチェーン機能を実現します。ただし、これらのソリューションはメッセージベースのクロスチェーン相互作用に普遍的に適用できるわけではなく、集中化と信頼のリスクが伴います。

マルチ ロールアップ時代の可能性を最大限に引き出すには、トラストレスでユニバーサルなクロス ロールアップ通信プロトコルが緊急に必要です。

Opside のソリューション: ネイティブ クロス ロールアップ コミュニケーション

実際、各 ZK ロールアップには本質的に L1<>L2 ブリッジが付属しており、これをネイティブ ブリッジと呼びます。流動性ベースのスキームを利用するサードパーティのブリッジとは異なり、ネイティブ ブリッジは独自の「ミントバーン」クロスチェーン メカニズムとして動作します。トラストレス性を維持しながら、ゼロ知識証明を通じてセキュリティを確保します。ロールアップ上のすべての資産は、ネイティブ ブリッジを介した入金トランザクションから生成され、ネイティブ ブリッジから最終的なセキュリティの承認を受けています。

私たちはオッカムの剃刀の原則、「実体は必要以上に増殖させてはならない」を固く信じています。サードパーティのブリッジは、より安価で高速なクロスチェーン エクスペリエンスを提供する可能性がありますが、追加の信頼コストとセキュリティ リスクが発生します。最近のマルチチェーン事件がその好例です。したがって、最初から、Opside のロールアップ間通信に対するインスピレーションは単純なものでした。追加のサードパーティ ブリッジを導入するのではなく、ネイティブ ブリッジを直接活用してマルチロールアップの相互運用性を実現するというものでした。この概念により、NCRC (Native Cross Rollup Communication) プロトコルが誕生しました。

NCRC の前提条件

複数のロールアップ間で NCRC を有効にするには、次の 2 つの前提条件を満たす必要があります。

• これらのロールアップは、ZK ロールアップ タイプに属している必要があります。

• これらのロールアップは同じ L1 上に存在する必要があります。

  
  

これら 2 つの条件を満たすロールアップは、理論的には、基礎となる L1 と同じレベルのセキュリティを備えています。同様に、これらのロールアップ間のネイティブ ブリッジのセキュリティ レベルは同一であり、ロールアップ間で信頼を必要としません。すべての NCRC トランザクションは有効性証明によって検証され、NCRC のセキュリティ保証の基本的な情報源として機能します。

ロールアップ承認契約（RRC）

2023 年 8 月の時点で、Polygon zkEVM、zkSync時代、Linea など、いくつかの ZK ロールアップがメインネット上で稼働しています。ただし、これらの ZK ロールアップは独立していて関連性がないため、ユーザー資産の断片化につながります。この問題の根本的な理由は、L1 (イーサリアムメインネット) 上の契約が無関係であるという事実にあります。これらはお互いの存在を認識せず、ネイティブのロールアップ ブリッジを介して直接通信することはできません。

したがって、最初に実行する必要があるのは、ロールアップが相互に検出して認識できるようにするために、特殊なコントラクトを L1 に展開することです。これは RRC (ロールアップ承認契約) と呼ばれます。 RRC は、ロールアップの追加、一時停止、終了など、NCRC に参加しているすべての ZK ロールアップを管理する責任があります。 RRC 内の各ロールアップには専用のロールアップ ID が割り当てられますが、L1 の ID は 0 に固定されたままになります。

ロールアップのネイティブ ブリッジを介してクロスロールアップ トランザクションを開始する場合、アドレスはターゲット ロールアップ ID を指定できます。

• ロールアップ ID が 0 の場合は、メッセージが L1 に渡されること (撤回など) を意味します。
• ロールアップ ID が 0 でない場合は、メッセージが別のロールアップに送信されることを示します。

Opside は、すべての L1 層に RRC コントラクトを展開し、対応する ZK ロールアップが許可なく参加または終了できるようにします。この RRC コントラクトは、L1 上のブリッジ コントラクト アドレスを含む、各ロールアップ ID の情報を維持するために使用されます。 RRC 契約はデータ検索サービスのみを提供し、クロスチェーン資産と直接やり取りするものではないことに注意することが重要です。

ネイティブ ブリッジ スマート コントラクトおよびサービスとの互換性

一般に、Rollup のネイティブ ブリッジは、L1 のブリッジ コントラクト、L2 のブリッジ コントラクト、およびメッセージ リレーを担当するブリッジ サービスの 3 つのコンポーネントに分割されます。 NCRC プロトコルは、これらのコンポーネントを基礎となるレベルで活用し、より高いレベルのカプセル化を追加します。主な変更点は以下の通りです。

• L2 のブリッジ コントラクト: 元のメソッドを保持しながら、bridgeAsset という名前の新しいメソッドが追加されます。このメソッドを使用すると、ユーザーは destinationNetwork パラメータでターゲット ロールアップの ID を指定できます。

• L1 のブリッジ コントラクト: 新しい BridgeAsset メソッドのクロスチェーン メッセージを処理するために、新しいメソッドがカプセル化されます。ブリッジ コントラクトは、RRC コントラクトで見つかったロールアップ ID に基づいて、ターゲット ロールアップの情報を特定し、クロスチェーン アセットをターゲット ロールアップのブリッジ コントラクトに転送します。クロスチェーン資産は、ターゲットのロールアップにデポジットされます。

• ブリッジ サービス: メッセージ リレーを担当し、クロス ロールアップ トランザクションの料金をユーザーに請求します。

  
  

ロールアップが上記の NCRC 関連の互換性適応を完了すると、RRC に登録してネイティブのクロスロールアップ通信ネットワークに参加できます。

ネイティブクロスロールアップトランザクションのプロセス

ユーザーにとって、NCRC の動作は Rollup のネイティブ ブリッジの動作と完全に一致しています。 Rollup1 から Rollup2 へのクロスロールアップ トランザクションの開始は、次の手順を含む自動プロセスです。

1. Rollup1 上のイニシエーター User1 は、ネイティブ ブリッジの BridgeAsset メソッドを呼び出して、クロスチェーン トランザクションを開始します。このトランザクションの destinationNetwork パラメーターは、Rollup2 のロールアップ ID に設定されます。このロールアップ ID は、対応する L1 ブリッジ コントラクト アドレスを取得するために使用されます。ロールアップ ID が 0 の場合、ターゲット ネットワークは L1 であることを示します。

   
   

2. 続いて、このトランザクションは、Rollup1 の Sequencer1 によってパッケージ化されます。開始者である User1 はクロスロールアップトランザクションのコストを負担し、Rollup1 の Sequencer1 に支払います。次に、Rollup1 のブリッジ サービスは、クロスチェーン アセットを L1 上の Rollup1 ブリッジ コントラクトに転送します。この時点で、Rollup1 と L1 の両方がアセットの書き込みと解放の操作を完了します。

   
   

3. クロスロールアップ資産転送を完了するために、Rollup1 の Bridge サービスは RRC コントラクトにクエリを実行し、destinationNetwork パラメータに対応するターゲット Rollup2 に関する情報を取得します。この情報は、Rollup2 の L1 ブリッジ コントラクト アドレスを提供します。次に、Rollup2 のブリッジ コントラクトがこれらのアセットの制御を取得し、bridgeAsset メソッドを通じてそれらを Rollup2 にマップします。

   
   

4. 最後に、トランザクションが正常にパッケージ化され、プルーフが生成されると、Rollup2 の Bridge サービスはclaimAsset オペレーションを実行します。その結果、Rollup1 によって開始されたクロスチェーン アセットは、Rollup2 の指定されたアドレスに安全に到着します。

クロスチェーン プロセス全体を通じて、ユーザーの資産は次のパスを通過することに注意してください: Rollup1 -> Rollup1 の L1 ブリッジ コントラクト -> Rollup2 の L1 ブリッジ コントラクト -> Rollup2。言い換えれば、ユーザーの資産はサードパーティのプロトコルを経由しません。これらは Rollup のネイティブ ブリッジを利用します。プロセス全体は安全でトラストレスです。

ユーザーが Rollup1 でクロスチェーン操作を実行し、宛先として Rollup2 を選択すると、技術的なプロセスには実際には Rollup1、L1、Rollup2 の 3 つのエンティティが関係します。ただし、このプロセスにおいてユーザーは L1 の存在を意識する必要はありません。彼らの経験は、単に Rollup1 から Rollup2 への直接のクロスです。根底にある現実は、クロスチェーン資産が L1 上で 2 つのブリッジング操作を受け、ユーザーの認識上、Rollup1 から Rollup2 へのシームレスな接続が作成されるということです。このプロセス中、L1 上の操作は自動的に処理されるため、ユーザーは追加のアクションを実行する必要はありません。ユーザーの観点から見ると、現在のロールアップは、L1 と他のロールアップの両方に対してクロスチェーン操作を実行できます。この設計により、根底にある複雑さを隠しながら、ユーザー エクスペリエンスの流動性が向上します。

NCRC は Opside テストネット上で稼働中です。

Opside は、テストネット上でネイティブのクロスロールアップ通信を実装することに成功しました。公式サイトから誰でも体験できるようになりました。

https://pre-alpha-assetshub.opside.network/また、潜在的なバグやセキュリティ リスクを特定し、貴重な提案を提供してくれるユーザーや開発者も歓迎します。

私たちは、トラストレスなネイティブクロスロールアップ通信は、すべてのロールアップ間で流動性を安全に共有するだけでなく、堅牢なマルチロールアップの相互運用性を提供し、分散型アプリケーションとDeFiプロトコルの新たな可能性を開くと信じています。