相互運用性のトリレンマ
イーサリアムのドメイン間ブリッジが困難な理由
数日前、私たちはEthereum互換ドメイン（ドメイン＝チェーンとL2）間でトラストレス転送とコントラクトコールを可能にするためのプロトコルであるNXTPをリリースしました。
この記事では、なぜイーサリアムドメイン間の相互運用が難しいのかを説明し、なぜNXTPがエコシステムのための真の長期的ソリューションになると考えるのかを紹介します。
イーサリアムのトラストレスな相互運用性の必要性
マルチチェーン/L2イーサリアムの勢いは留まるところを知りません。多くのプロジェクトがDeFiでこの機能を実現するために取り組んでおり、何十もの新しいブリッジや相互運用性プロトコルの構築が進んでいます。
そして、これは多くのハッキングと詐欺をもたらしました：
このような例が後を立たないにもかかわらず、世の中の全てのブリッジングシステムは、高い信頼性を有する安全な分散型システムであると自らを売り込んでいます。つまり、開発者とユーザーにとっての大きな課題は、「どのブリッジングシステムが実際に安全なのかをどうやって見極めるか？」ということです。
暗号経済学における「トラストレス」の意味とは？
リサーチコミュニティにおいて、暗号経済のセキュリティとトラストレスの特性について話すとき、このような質問が投げかけられます：
システムを検証しているのは誰なのか、その検証を妨害するためにどれだけのコストがかかるのか？
私たちの目標が真に分散化された公共財を構築することである場合、私たちのシステムは、ならず者国家、巨大企業、悪の天才集団のような信じられないほど強力な敵によって攻撃されうることを考慮しなければなりません。
もしあなたが考える脅威モデルに、ジェフ・ベゾスがそれらの行為を行う可能性のある対象に含まれていないなら、それはNGです。
セキュリティを最大化するということは、システム内の検証者（バリデータ、マイナーなど）の数と多様性を最大化するということであり、これは通常、イーサリアムのバリデータセットによってすべて検証されるシステムを持つよう最善を尽くすことを意味します。これがL2やイーサリアムのスケーラビリティに対するアプローチの核となる考え方です。
ほとんどの人が気づいていませんが、スケーラビリティの研究は相互運用性の研究なのです。複数のドメインに移行することでスケールすることは昔から理解されていましたが、問題はそれらのドメインとの通信をいかに信頼性を持って行えるようにするかということでした。John AdlerによるOptimisticロールアップに関する論文のタイトルが「Trustless Two-Way Bridges With Sidechains By Halting」なのは、そのためです。
ドメイン間に新たな検証を追加するとどうなるか？
以上、暗号経済のセキュリティについて学んだことを、ブリッジに応用してみましょう。
Arbitrumに資金を預けているシナリオを考えてみましょう。このドメインはロールアップの代表として選択しました。このメカニズムにおいては、あなたの資金がイーサリアムの基礎となる検証システムによって安全が保たれていることを意味します。言い換えれば、あなたの資金は、ブロックチェーンエコシステムにおいて、暗号経済的に可能な限り安全であるということです。
ここで、ブリッジを使用して、資金を安価かつ迅速にOptimismに移動させるとします。Optimismもトラストレスなので、Arbitrumと同じレベルのセキュリティ（Ethereumのセキュリティ）を共有できると知っていれば、安心して資金を預けることができるでしょう。
しかし、実際にはあなたが使用するブリッジプロトコルは、それ自身の外部検証者を利用していることになります。言い変えれば、イーサリアムによって保護されているのではなく、ブリッジの検証者によって保護されているということです：
- ロック/ミントブリッジでラップアセットを作成している場合、ブリッジの検証者が一方的に結託してあなたの資金をすべて盗むことができるます
- 流動性プールを利用したブリッジの場合、ブリッジの検証者は同様に結託してLPからプール資金を盗むことができます
安全で信頼できるL2を待ち臨んだにもかかわらず、あなたの状況は、既存のサイドチェーンやL1を使った場合と同じになっているのです😨
重要なことは、暗号経済システムの安全性は、その中の最も弱いリンクと同レベルでしかないということです。安全でないブリッジを使用した場合、チェーンやL2がどれだけ安全であるかは関係なくなります。そして、L1やL2のセキュリティと同様に、全ては「誰がシステムを検証しているのか」という1つの疑問に集約されます。
相互運用性プロトコルの分類法
全ての相互運用性プロトコルは、誰が検証するかによって3つのタイプに分類することができます：
ネイティブ検証型（Natively verified）
ネイティブ検証プロトコルは、チェーン間で受け渡しされるデータを、チェーン自身の検証者が検証するものです。一般的に、これはあるチェーンのライトクライアントを別のチェーンのVMで実行したり、その逆を行うことで行われます。
例としてCosmos IBC、Near RainbowBridgeなどがあり、ロールアップの出入口もこの亜種です。
利点：
- 基礎となる検証者が直接ブリッジングに責任を持つため、最も信頼性の高い相互運用性を有する
- ドメイン間のメッセージパッシングを完全に一般化できる
不利な点：
イーサリアムのエコシステムは非常に異質であり、zk/Optimisticロールアップからサイドチェーン、多様なコンセンサスアルゴリズムを実行するベースチェーンまで、あらゆるドメインが存在します。ETH-PoW、Nakamoto-PoW、Tendermint-PoS、Snowball-PoS、PoAなどです。これらのドメインは、ネイティブに検証された相互運用システムを実装するためのそれぞれ独自の戦略を必要とします。
外部検証型（Externally verified）
外部検証型プロトコルは、チェーン間のデータ中継に外部の検証者のセットを使用するものです。これは通常、MPCシステム、オラクルネットワーク、閾値マルチシグ（全て事実上同じ）として表現されます。
例としてThorchain、Anyswap、Biconomy、Celer、Synapse、PolyNetwork、EvoDeFiなどが含まれます。
利点：
不利な点：
- ユーザーやLPは、資金やデータについて外部の検証機関を完全に信頼しなければならないため、基本的に基礎となるドメインよりも暗号経済的に安全でないことを意味します（Arbitrum to Optimismの例と同様）
場合によっては、プロジェクトは追加のステーキングまたはボンディングのメカニズムを使用して、ユーザーのセキュリティを強化しようとしますが、これは一般的にあまり意味を持ちません。システムをトラストレスにするためには、ユーザは保証可能な最大量まで保険をかけなければならず、その保険は検証者自身からかけなければならないからです。
これは、システムに必要な資本を大幅に増加させるだけでなく、そもそもミントされた資産や流動性プールを持つ目的そのものを打ち消してしまうことになるからです。
ローカル検証型（Locally verified）
ローカル検証型プロトコルは、あるクロスドメインの相互作用に関与する当事者のみがその相互作用を検証するものです。ローカル検証型プロトコルは、複雑なn当事者検証問題を、各当事者が自分の相手方のみを検証し、より単純な2当事者間相互作用の集合に変えてしまう手法を取ります。このモデルは、両者が経済的に敵対的である限り、つまり両者が結託してより広いチェーンから資金を奪う方法をとらない限り有効です。
例として、ConnextやHopなどのシンプルなアトミック・スワップシステムが挙げられます。
利点：
- ローカル検証型システムはトラストレスであり、そのセキュリティは、ロールアップによって共有される合理的な保証（例えば、チェーンはX日間以上検閲されない）を与えられたベースチェーンによってバックアップされています
- 他のドメインに拡張することが非常に簡単です
注意：すべてのローカル検証されたシステムがトラストレスというわけではない。UXの向上や機能の追加のために、トラストのトレードオフを行うものもあります。
例えば、Hopは、高速の任意メッセージングブリッジ(AMB)を必要とするシステムで、信頼性の仮定を追加しています：プロトコルは、ロールアップを終了するときに7日間待つのではなく、1日で流動性をアンロックします。また、あるドメインにAMBが存在しない場合、プロトコルは外部で検証されたブリッジに依存する必要があります。
不利な点：
- ローカル検証型システムは、チェーン間の一般化されたデータの受け渡しをサポートすることができません
ローカル検証型システムでドメイン間のコントラクト呼び出しを可能にすることは可能ですが、呼び出される関数に何らかの論理的な所有者がいる場合に限られます。例えば、スワップ関数はスワップ可能なトークンを持っている人なら誰でも呼び出すことができるので、チェーン間でUniswapスワップ関数を信頼なく呼び出すことが可能となります。これは、デスティネーションチェーン上のmint機能の所有者がソースチェーン上のlockコントラクトでなければならず、ローカルに検証されたシステムでこれを表現することは不可能であるためです。
相互運用性のトリレンマ
さて、この記事のテーマである、ブリッジの選択に関するユーザと開発者の決断を促すべきメンタルモデルについて説明します。
スケーラビリティトリレンマと同様に、イーサリアムのエコシステムには相互運用性のトリレンマが存在します。Interopプロトコルは、以下の3つの特性のうち2つしか持つことができません：
ConnextとNXTPの位置づけは？
3つの相互運用性を実現する簡単な方法はありません。しかし、この「相互運用性のトリレンマ」を解決するには、イーサリアムが「スケーラビリティトリレンマ」を解決するのと同じアプローチを取ればよいのです。
イーサリアムL1は、スケーラビリティを犠牲にして、セキュリティと分散化を最適化します。その根拠は、ブロックチェーンの持続性と実用性にとって、これらの特性が最も重要であるからです。イーサリアムは、既存の安全かつ分散化されたバックボーン上にレイヤーとして、L2/シャーディングによってスケーラビリティを追加しています。
Connextは、イーサリアムのエコシステムにおいて最も持続的で実用的、かつ採用率の高い相互運用システム、最大限の信頼性と拡張性を備えたものになると信じています。このため、NXTPはローカル検証型システムであり、基盤となるドメインと同様に安全でありながら、どのドメインでも使用できるように設計されています。
では、一般化可能性についてはどうでしょうか。イーサリアムエコシステムのスケーラビリティと同様、NXTPの上にネイティブ検証型プロトコルをプラグインすることで（相互運用ネットワークの「レイヤー2」として）、一般化可能性を追加することができます。そうすることで、ユーザーや開発者はあらゆるドメインで一貫したインターフェースを得ることができ、その機能が利用できる場合には接続を「アップグレード」して汎用化することができます。
以上が、NXTPを相互運用性ネットワークのベースプロトコルとする理由です。完全なネットワークは、NXTPを含むプロトコルのスタック、ドメインのペアに固有の一般化されたクロスチェーンブリッジ、それらを1つのシームレスなシステムに接続するためのプロトコルから構成されています。
Connextの活動に参加するには？
- TrConnextをhttps://xpollinate.ioでお試しください。
- チームへの参加に興味がある場合は求人情報をチェックしてください。
- Discordには超アクティブなコミュニティがありますので、ぜひご参加ください。
- プロジェクトの一部としてConnextを使いたい場合は、ドキュメントをチェックするか、Discordで私たちに連絡を取ってください。
- Connext は完全なオープンソースなので、コミュニティのメンバーは常にプロトコルへの貢献を歓迎します。
そして最後に、もしあなたがConnextの取り組みを面白いと感じたら、周りの暗号/ブロックチェーン好きな友人と共有してください。私たちは、ウォレット、ブラウザ、アプリケーションにおいて、イーサリアム上での即座に低コストな取引を実現させていきます。
これまでも、これからもご支援ありがとうございます。
Team Connext
