公链や Layer2 チェーンの数が増えるにつれて、資産や Dapp のクロスチェーン需要も増加し、クロスチェーンブリッジは一般的な解決策の一つとなっていますが、Zetachain を代表とする Omnichain は全く異なる道を歩んでいます。本稿では Zetachain を例に取り、Omnichain がどのようにクロスチェーンルールをスマートコントラクトに書き込むことで、クロスチェーン相互運用性を実現しているのかを説明します。
いくつかのクロスチェーン技術方案#
クロスチェーン（Cross-Chain）技術の核心的な目標は、異なるブロックチェーン間の相互運用性（Interoperability）を実現することです。相互運用性とは、異なるブロックチェーンシステムが互いに理解し、他方の資産（トークン、暗号通貨など）やデータを使用できること、または異なるブロックチェーンプラットフォーム上で動作するアプリケーションが相互にやり取りし、協力できることを指します。この目標の実現は、ブロックチェーンエコシステムの柔軟性と拡張性を大幅に向上させ、異なるブロックチェーンプラットフォーム間の孤立効果を打破し、より広範なアプリケーションと発展を促進します。
クロスチェーンメッセージの処理方法や対応する資産の署名承認方法の違いに基づいて、以下のいくつかの技術方案に分類できます。
- クロスチェーンブリッジ（Cross-Chain Bridges）：
クロスチェーンブリッジは、資産をあるブロックチェーンから別のブロックチェーンに移転することを可能にする技術です。これは、ソースチェーン上の資産をロックし、ターゲットチェーン上に対応する代表的な資産（または同等の資産）を発行することで実現されます。この方法は、資産のクロスチェーン移転と使用をサポートしますが、資産のロックと解放のプロセスが安全で信頼できることを保証する必要があります。2 つの独立したチェーンがブリッジ方式で相互運用性を持つ場合、私たちはそのうちの 1 つのチェーンを他のチェーンのメインチェーンのサイドチェーンと呼びます。
2. 公証（Notary）：
公証方案は、一群の信頼できるノード（または機関）に依存して、クロスチェーン取引の有効性を検証します。これらの公証ノードは、あるチェーン上で発生するイベントを監視し、別のチェーン上でそれに対応するトランザクションを作成して、これらのイベントを検証および記録します。この方法はクロスチェーン相互運用性を実現できますが、その安全性と分散化の程度は、公証ノードの信頼性に大きく依存します。
3. ハッシュタイムロック契約（Hash Timelock Contracts, HTLCs）：
HTLCs は、時間ロックに基づくスマートコントラクト技術であり、2 つの参加者が第三者なしで安全にクロスチェーン交換を行うことを可能にします。これは、正しいパスワードを提供することで資金を解放する必要がある契約を作成することで実現されます。参加者の両方が契約の要件を満たした場合にのみ、資金は解放され、相手に渡されます。この方法は分散型の資産交換をサポートしますが、参加者の協力に一定の要件があります。
4. BoB（Blockchain on Blockchain、例えば Cosmos の IBC）：
この技術方案は、既存のブロックチェーン上に新しいブロックチェーン（またはレイヤー）を作成することでクロスチェーン相互運用性を実現します。例えば、Cosmos ネットワークの IBC（Inter-Blockchain Communication）プロトコルです。IBC は、異なるブロックチェーンが独立したガバナンス構造を維持しながら、資産とデータの安全な伝送を実現することを可能にします。この方法は、各チェーンが自由に情報と価値を交換できる分散型のブロックチェーンインターネットを構築することを目指しています。
これらの技術方案にはそれぞれ利点と欠点があり、異なるシナリオやニーズに適しています。クロスチェーン技術の選択と実装は、対象ブロックチェーンの特性、安全性の要件、分散化の程度、および実現の複雑性などの要因を考慮する必要があります。
クロスチェーンメッセージ伝達#
クロスチェーンメッセージ伝達（Cross-Chain Message Passing, CCMP）は、クロスチェーン相互運用性を実現するための核心技術であり、クロスチェーン相互作用のプロセスが安全かつ効果的に行われることを保証します。その基本的な目的は、異なるブロックチェーン間でメッセージを伝達し、検証することで、資産とデータのクロスチェーン相互作用を実現することです。その作業原理は主に以下のいくつかの重要な段階を含みます。
1. メッセージの生成と送信：
- メッセージには通常、資産移転に関するすべての必要な情報が含まれています。例えば、資産の数量、ソースアドレス、目的アドレスなどです。
- メッセージが生成された後、ソースチェーンのスマートコントラクトを通じて発信され、この契約は取引の詳細を記録し、資産のロックをトリガーします。
2. メッセージの伝達：
- 伝達方法には通常 2 つのタイプがあります：直接伝達と中継伝達。
- 直接伝達は、ソースチェーンとターゲットチェーンの間に直接の通信経路があることを意味しますが、これは実際には非常に稀です。なぜなら、ほとんどのブロックチェーンは独立して運用されているからです。
- 中継伝達は、中継者（中央集権的なサービスプロバイダーまたは分散型のノードネットワーク）を含み、これらはソースチェーン上の特定のイベントを監視し、関連情報をキャッチしてターゲットチェーンに伝達します。
3. メッセージの検証：
- ターゲットチェーン上で受信したメッセージは、その合法性と完全性を確認するために検証される必要があります。
- 検証プロセスには通常、ソースチェーンのデータ証明（Merkle 証明など）が必要であり、これによりメッセージが実際にソースチェーンから来たものであり、改ざんされていないことが確認されます。
- 検証が通過すると、ターゲットチェーン上のスマートコントラクトはメッセージの内容に基づいて、トークンの鋳造や状態の更新などの対応する操作を実行します。
4. 処理と応答：
- 検証が完了すると、ターゲットチェーンは資産の解放や新しいトークンインスタンスの作成など、必要な操作を処理します。
- このステップが完了すると、クロスチェーン相互作用は基本的に完了し、ユーザーはターゲットチェーン上で資産を使用または管理できます。
したがって、本質的には、前述のいくつかのクロスチェーン技術方案は、それぞれ異なるメッセージ伝達方法を採用しているために生じています。
1. クロスチェーンブリッジ
クロスチェーンブリッジは、異なるブロックチェーン間で資産と情報の移転を促進するために中介層を作成します。この中介層は次のようになります：
- 中央集権的なサーバーで、信頼できるエンティティが制御し、一つのチェーン上のイベントを監視し、別のチェーン上でこれらのイベントを複製する役割を担います。
- 分散型ネットワークで、複数の独立して運営されるノードで構成され、これらのノードはコンセンサスメカニズムを通じてメッセージを検証し、転送します。
クロスチェーンブリッジでは、通常、ソースチェーン上の資産のロックとターゲットチェーン上の同等の資産の鋳造が関与します。このプロセスでは、メッセージが検証および実行される前に改ざんされないことを保証する必要があります。
2. 公証人
公証方案は通常、事前に選定された公証人（個人、組織、または自動化されたノード）に依存し、これらの公証人は一つのチェーン上のイベントを監視し、別のチェーン上でこれらのイベントを検証および確認します。公証人は、中央集権的または半中央集権的な検証メカニズムを提供し、このメカニズムの安全性と信頼度は公証人の信頼性に大きく依存します。
3. ハッシュタイムロック契約（HTLC）
HTLC は、2 つのチェーン間の条件付き資産交換に使用される暗号技術に依存した契約です。これは、暗号ハッシュ関数と時間ロックを使用して資産の解放条件を制御します：
- 暗号ハッシュ：受取人が正しいプレイメージ（ハッシュの元データに対応）を提供した場合にのみ、資産が契約から解放されます。
- 時間ロック：指定された時間内に正しいプレイメージが提供されない場合、資産は元の保有者に戻ります。
この方法は中央集権的な検証に依存せず、契約自体によって資産の安全な交換を保証します。
4. BoB
この技術は、クロスチェーン通信プロトコルの基盤の上に新しいチェーンまたはサブチェーンを作成することによって実現されます。例えば、Cosmos は IBC プロトコルを通じて異なるブロックチェーン間の直接通信を実現し、各チェーンがその自治性を維持しながら、安全にメッセージと資産を交換できるようにします。IBC と XCMP の本質は実際にはクロスチェーン通信プロトコルです。
同時に CCMP 技術は、いくつかの主要な課題にも直面しています：
** 安全性：** 中継ノードまたはネットワークは信頼できるものでなければならず、そうでなければメッセージが改ざんされるリスクがあります。また、ソースチェーンとターゲットチェーンのスマートコントラクトも、潜在的な脆弱性を防ぐために十分に安全に設計される必要があります。
** 効率と遅延：** クロスチェーン操作は通常、複数のブロック確認を伴い、顕著な時間遅延を引き起こす可能性があります。
** 分散化と信頼の問題：** 中継ノードや第三者サービスに依存することは、ブロックチェーンの分散化の精神に反する可能性があるため、分散化されていて安全な CCMP メカニズムを設計することは技術的な課題です。
これらの技術的および安全上の課題により、CCMP の実現と最適化はクロスチェーン技術の研究と発展の活発な分野となっています。さまざまな解決策が、分散化、安全性、効率の間で最適なバランスを見つけようとしています。
クロスチェーン資産の署名と承認#
クロスチェーン技術とクロスチェーン相互運用性は、クロスチェーンメッセージ伝達（CCMP）に依存するだけでなく、ソースチェーンとターゲットチェーン上で資産の安全な処理と取引の合法性を確保するために、効果的な署名と承認を行う方法にも関係しています。異なるクロスチェーン技術方案は、異なる署名と承認メカニズムを採用しており、これらのメカニズムの核心は、取引の合法性を検証し、実行する方法、そして資産の安全な移転を確保することにあります。以下は、一般的なクロスチェーン技術方案における署名承認の実装に関するいくつかの例です。
1. クロスチェーンブリッジ
クロスチェーンブリッジは、多署名（Multisignature）または代理署名（Proxy Signature）の方法を採用して、署名と承認を処理することがあります。この方案では、資産を移転する操作は、一定数の検証ノードまたは特定の代理サービスの承認を得る必要があり、これらのノードまたはサービスは取引要求の検証を担当し、取引に署名します。この方法は安全性を高めることができますが、信頼の問題も引き起こします。なぜなら、これは中央集権的または半中央集権的なエンティティに依存しているからです。
2. 公証人
公証人システムでは、公証人または公証ノードの集合が通常、クロスチェーン取引要求を監視し、検証し、ターゲットチェーン上で対応する操作を実行します。公証人はターゲットチェーン上で操作に署名承認を行い、ソースチェーン上の取引が許可されていることを証明します。この方法は公証人の信頼度と安全性に依存します。
3. ハッシュタイムロック契約（HTLC）
HTLC では、署名承認は外部の検証者や中介に依存しません。むしろ、取引の合法性と実行は契約のロジックと参加者間の直接的な相互作用に依存します。参加者は正しいプレイメージ（つまり、鍵）を提供して契約を解放する方法として、これ自体が一種の承認となります。さらに、契約自体には時間ロックメカニズムが備わっており、特定の時間ウィンドウ内に正しいプレイメージが提供される場合にのみ取引が完了することを保証します。
4. BoB
例えば、Cosmos の IBC プロトコルでは、署名承認プロセスはチェーン間プロトコルとローカル契約の実行を通じて行われます。各チェーンは独自に自らの安全性と承認メカニズムを管理しながら、プロトコルを通じてクロスチェーンメッセージの安全性と有効性を確保します。この方案は分散化と自治を強調し、単一のエンティティへの依存を減らします。
要するに、署名承認メカニズムは、異なるクロスチェーン技術方案においてその構造と安全要件に応じて異なります。これらのメカニズムの選択と設計は、安全性、信頼、分散化、効率のバランスを取ることが重要です。クロスチェーン技術を実装する際には、すべての参加チェーンの合法性と安全性を確保することが不可欠です。
Zetachain のアーキテクチャ#
もし DeFi が金融ルールをスマートコントラクトに書き込むことであり、オンチェーンゲームがゲームルールをスマートコントラクトに書き込むことであるなら、Omnichain は実際にはクロスチェーンルールをスマートコントラクトに書き込むことです。これには、クロスチェーンメッセージ伝送ルールと資産の署名承認ルールが含まれます。Zetachain がどのようにそれを実現しているのか、詳細を見ていきましょう。
ZetaChain は、Cosmos SDK と Tendermint PBFT コンセンサスエンジンに基づいて構築された PoS ブロックチェーンです。Tendermint PBFT コンセンサスエンジンを使用することで、ZetaChain は約 5 秒の迅速なブロック生成時間と即時の最終確定性（ブロック確認なし、再編成を許可しない）を実現できます。理想的なネットワーク条件下では、その取引スループットは毎秒 4000 以上の取引に達する可能性がありますが、クロスチェーン取引のスループットは外部チェーンの遅延やさまざまな他の要因（外部ノード RPC の速度など）によってこのレベルに達しない可能性があります。
ZetaChain のアーキテクチャは、ノードで構成された分散ネットワークを含んでおり、これらのノードは通常、バリデーター（validators）と呼ばれます。ZetaChain の各バリデーターは内部に ZetaCore と ZetaClient を含んでいます。ZetaCore はブロックチェーンを生成し、複製された状態機械を維持する役割を果たし、ZetaClient は外部チェーン上のイベントを監視し、取引を署名して外部に送信します。ZetaCore と ZetaClient は一緒にパッケージ化され、ノードオペレーターによって運営されます。誰でも十分な ZETA トークンをステークすることでノードオペレーターになり、検証作業に参加できます。
したがって、ZetaChain のバリデーターが ZetaCore コンポーネントのみを実行する場合、それはシーケンサー（sequencer）になり、ZetaClient コンポーネントのみを実行し、外部チェーン上のイベントを監視するだけの場合、それはオブザーバー（observers）になります。同様に、ZetaClient コンポーネントのみを実行し、取引を署名して外部に送信する場合、それはサイナー（signers）になります。
ZetaChain はまた、外部チェーンとの認証インタラクションに使用される標準の ECDSA/EdDSA キーを集団で保持しています。これらのキーは複数のサイナー（signers）に分散されており、スーパーメジャーサイナーのみが ZetaChain を代表して外部に署名できます。ZetaChain は、バインドされたステーキングと正 / 負のインセンティブメカニズムを使用して経済的安全性を確保しています。
Zetachain の 2 つのクロスチェーン相互運用メカニズム#
Zetachain は 2 つのクロスチェーン相互運用メカニズムをサポートしています。一つは従来のクロスチェーンブリッジメカニズムであり、もう一つは Omnichain スマートコントラクトメカニズムです。
クロスチェーンブリッジメカニズム#
まず、クロスチェーンブリッジメカニズムの作業フローを見てみましょう。全体のプロセスは主に以下のいくつかのステップを含みます。
**1. ユーザーと契約の相互作用：** ユーザーはチェーン A の契約 C1 上で操作を行い、ユーザーが指定した [chainID, contractAddress, message] を含むイベントまたは取引メモを残します。このメッセージはバイナリ形式でエンコードされたアプリケーションデータです。
**2. オブザーバーがイベントをキャッチ：**ZetaChain のオブザーバー（zetaclient 内）はこのイベントまたはメモをキャッチし、zetacore に報告します。zetacore は入ってくる取引を検証する役割を担います。
**3. アウトバウンド取引の構築：**zetacore は CCTX（クロスチェーン取引）状態変数および OutboundTxParams を修正し、TSS サイナー（zetaclient 内）に指示して、外部取引を構築、署名、ブロードキャストします。
**4. 署名とブロードキャスト：**zetaclient の TSS サイナーは CCTX 内の OutboundTxParams に基づいてアウトバウンド取引を構築し、TSS キー署名儀式を行い、その後署名された取引を外部ブロックチェーンにブロードキャストします。
**5. 状態の更新と追跡：**CCTX 構造は、クロスチェーン取引の各段階 / 状態を追跡します。
**6. 取引確認：** 一旦ブロードキャストされた取引があるブロックチェーンに含まれると（つまり「マイニング」または「確認」されると）、zetaclient はこの確認状況を zetacore に報告し、その後 CCTX 状態を更新します。
7. 成功と失敗の処理：
- 外部取引が成功した場合、CCTX 状態は OutboundMined に変わり、CCTX 処理が完了し、終端状態に入ります。
- 外部取引が失敗した場合（例えば、イーサリアムチェーン上で取り消された場合）、CCTX 状態は PendingRevert（可能な場合）または Aborted（取り消しが不可能な場合）に更新されます。Aborted 状態に入ると、CCTX 処理が完了します。
8. 取り消しの処理：
- 新しい状態が「PendingRevert」の場合、CCTX にはすでに 2 番目の OutboundTxParams が含まれている必要があり、zetaclients に入ってくるチェーンと契約への「Revert」アウトバウンド取引を作成するよう指示します。これにより、入ってくる契約がアプリケーションレベルの取り消し機能を実現し、契約状態をクリーンアップできます。
- zetaclients は取り消し取引を構築し、TSS キー署名儀式を行い、その後取引を入ってくるブロックチェーン（この例ではチェーン A）にブロードキャストします。
9. 取り消し確認：
- 取り消し取引がチェーン A で「確認」されると、zetaclients は取引状態を zetacore に報告します。
- 取り消し取引が成功した場合、CCTX 状態は Reverted に変わり、処理が完了します。
- 取り消し取引が失敗した場合、CCTX 状態は Aborted に変わり、処理が完了します。
上記のステップを通じて、クロスチェーンメッセージの伝達は主に ZetaCore と ZetaClient の内部通信によって完了し、やや中央集権的な方法で行われます。また、Zetachain 自体のスマートコントラクトは使用されず、ターゲットチェーンのスマートコントラクトのみが使用されます。この場合、ターゲットチェーンがイーサリアムのようなスマートコントラクトプラットフォームである必要があり、各チェーンはクロスチェーン相互運用性を実現するために少なくとも 1 つの契約をデプロイする必要があります。ビットコインのような非スマートコントラクトプラットフォームでは使用できません。もう一つ、アプリケーションの状態とロジックは、これらのアプリケーション契約のすべてに分散して存在します。異なるチェーン間で状態を同期し、通信することは高価で遅く、ロールバック処理が複雑になります。これらの問題を解決するために、Zetachain は Omnichain スマートコントラクトメカニズムを導入しました。
Omnichain スマートコントラクトメカニズム#
Omnichain スマートコントラクトは、ZetaChain が提案するクロスチェーン相互運用性処理を簡素化する方法です。これは主に以下のステップを通じてクロスチェーンメッセージを処理し、クロスチェーン相互運用を実現します。
**1. 資産の受信：** ユーザーはローカル資産（ERC20 トークンなど）をチェーン A の TSS アドレスに送信し、同時に [zEVMContractAddress, message] を指定するメッセージを添付します。ここでの TSS アドレスは、ERC20 トークンをホスティングするために特別に設けられた契約である可能性があります。
**2. 監視と報告：**ZetaChain のオブザーバー（zetaclients）は、このクロスチェーン呼び出しが行われることを監視し、zetacore に報告します。
**3. 呼び出しと実行：**zetacore は SystemContract のdepositAndCall()関数を呼び出し、この関数は指定された zEVMContractAddress のonCrossChainCall()関数を呼び出します。この呼び出しの過程で：
- zrc20パラメータは、ユーザーが最初のステップで送信した外部トークンの ZRC20 契約アドレスで埋められます。
- amountパラメータは、ユーザーが送信したトークンの数量で埋められます。
- messageパラメータは、ユーザーが取引メモで送信したメッセージになります。
**4. 契約ロジックの実行：**omnichain スマートコントラクトは、zContract(zEVMContractAddress).onCrossChainCall(zrc20, amount, message)の方法で呼び出されます。アプリケーション契約はonCrossChainCall()関数内でそのビジネスロジックを実装する必要があります。
5. 契約実行結果の処理：
- 契約実行が成功し、外部資産の出力がない場合、この omnichain スマートコントラクトの相互作用は完了します。
- zEVM 契約の実行が失敗した場合（ロールバックが発生した場合）、CCTX が作成され、入ってくる取引を取り消し、同じ数量の外部トークンがユーザーに返されます（可能な手数料を差し引いて）。
- onCrossChainCall()に出力がある場合（例えば、いくつかの ZRC20 の引き出し操作をトリガーした場合）、外部資産を外部チェーン上のユーザー指定のアドレスに転送するための別の CCTX が作成されます。これらの引き出しは通常、単純なトークン移転です。
Omnichain スマートコントラクトの顕著な特徴は：
-
それは zEVM 上にのみデプロイされ、すべてのロジックと状態が一箇所に集中しているため、アプリケーションの開発と保守がより簡単になります。
-
外部チェーン上にアプリケーションスマートコントラクトをデプロイする必要がないため、ビットコインのような非スマートコントラクトチェーンをサポートできます。
-
すべての取り消し操作が ZetaChain プロトコルによって処理されるため、アプリケーション契約は取り消しロジックを処理する必要がありません。
一言で言えば、ZetaCore と ZetaClient 間の内部通信に必要な少数の情報を除いて、他のクロスチェーン情報の処理ルールは Zetachain 自体のスマートコントラクトに書き込まれています。ユーザーがターゲットチェーンの指定アドレスに追加メッセージを伴う送金を行うだけで、Zetachain 自体のスマートコントラクト内のクロスチェーン操作がトリガーされます。
より複雑な dApp は、ロジックと状態が一箇所に集中しているため、Omnichain スマートコントラクトを好むかもしれません。一方、従来のメッセージ伝達では、異なるチェーン上でメッセージと状態をブロードキャストする必要があり、これがより多くの攻撃面と追加のガス費用を引き起こす可能性があります（各メッセージには追加のガスを支払う必要があり、完全な状態同期を維持するために送信するメッセージの数が増加します）。言い換えれば、開発者にとって、Omnichain スマートコントラクトの動作は、すべての資産が一つのチェーン上にあるかのように見えます（下図参照）。
Zetachain の署名承認メカニズム#
ZetaChain の署名承認メカニズムは、先進的なマルチパーティー閾値署名方案（Threshold Signature Scheme, TSS）に依存しており、この方案は単一障害点の問題を効果的に解決し、システム全体の安全性を強化します。
**1. 閾値署名方案：**ZetaChain は、マルチパーティ計算（Multi-Party Computation, MPC）に基づく TSS を使用しており、この方案は複数のバリデーター（validators）が単一の ECDSA/EdDSA 秘密鍵を共同管理できるようにしますが、いかなる単一のエンティティや少数のバリデーターも完全に秘密鍵を掌握することはありません。この方法はホットウォレットの利便性とコールドウォレットレベルの安全性を提供します。
**2. 鍵生成と配布：**ZetaChain では、秘密鍵は信頼できる仲介者なしで生成され、すべてのバリデーター間で配布されます。これは、どの単一のバリデーターや外部の行為者も、いつでも完全な秘密鍵にアクセスできないことを意味し、システムの安全性を確保します。
**3. 署名プロセス：**ZetaChain が採用する TSS はリーダーレスであり、分散方式で鍵生成と署名を行います。これにより、鍵生成や署名プロセス中に秘密情報が漏洩することはありません。効率を高めるために、ZetaChain はバッチ署名と並列署名技術を採用し、署名者のスループットを向上させています。
**4. スマートコントラクトと資産管理：**TSS 鍵とアドレスを持つことで、ZetaChain は接続されたチェーン上でローカルの金庫 / 資金プールを管理でき、ビットコインなどの非スマートコントラクトチェーンも含まれます。これは実際にはビットコインネットワークなどにスマートコントラクト機能を追加し、ユーザーが資産を集約し、スマートコントラクトが事前に設定されたルールに基づいてこれらの資産を管理できるようにします。例えば、自動化市場作成者（AMM）プールや貸出プールなどです。
**5. 非スマートコントラクトチェーンのサポート：**TSS により、ZetaChain はビットコインやドージコインのような非スマートコントラクトチェーンをサポートし、マルチ署名のコストが高いスマートコントラクトプラットフォームを検証できます。
この署名承認メカニズムを通じて、ZetaChain は強力なクロスチェーン機能を提供するだけでなく、取引の安全性と検証の分散化を確保し、広範なデジタル資産管理と操作をサポートする強力なプラットフォームとなっています。