Zetachainを例に、Omnichainがどのようにチェーン抽象を実現するかを解説する
TechFlow厳選深潮セレクト
Zetachainを例に、Omnichainがどのようにチェーン抽象を実現するかを解説する
クロスチェーンブリッジは比較的一般的なソリューションだが、Omnichain はまったく異なる道を歩んでいる。
Web3業界の深掘り報道に専念し潮流を洞察著者：CaptainZ、元Injectiveリサーチャー
チェーン抽象Omnichainとは、クロスチェーンのルールをスマートコントラクトに書き込むことである。
パブリックチェーンおよびLayer2チェーンの数が増えるにつれ、アセットやDappのクロスチェーン需要も高まりつつある。クロスチェーンブリッジは比較的よく見られる解決策だが、Zetachainを代表とするOmnichainはまったく異なる道を歩んでいる。
本稿ではZetachainを例に取り、Omnichainがどのようにしてクロスチェーンルールをスマートコントラクトに記述し、クロスチェーン相互運用性の分散化を実現しているかを解説する。
A. いくつかのクロスチェーン技術方式
クロスチェーン（Cross-Chain）技術の核となる目的は、異なるブロックチェーン間での相互運用性（Interoperability）を実現することにある。相互運用性とは、異なるブロックチェーンシステムが互いのアセット（トークン、暗号資産など）やデータを理解・利用できること、あるいは異なるブロックチェーンプラットフォーム上で動作するアプリケーション同士が相互に連携・協働できることを意味する。この目標の達成により、ブロックチェーンエコシステムの柔軟性と拡張性が大きく向上し、各プラットフォーム間の孤島状態を打破し、より広範な応用と発展を促進できる。
クロスチェーンメッセージの処理方式および対応するアセットの署名認可方式の違いにより、以下の技術方式に分類できる：
1. クロスチェーンブリッジ（Cross-Chain Bridges）：
クロスチェーンブリッジとは、アセットをあるブロックチェーンから別のブロックチェーンへ移転させる技術である。ソースチェーン上のアセットをロックし、ターゲットチェーン上でそれに対応する代表的アセット（または等価アセット）を発行することでこれを実現する。この方式はアセットのクロスチェーン移転と利用を支援するが、アセットのロックと解放プロセスが安全かつ信頼できるように保証される必要がある。二つの独立したチェーンがブリッジ方式で相互運用性を持つ場合、一方のチェーンをもう一方のメインチェーンのサイドチェーンと呼ぶ。
2. 公証（Notary）：
公証方式は、信頼された一組のノード（または機関）に依存して、クロスチェーン取引の有効性を検証するものである。これらの公証ノードは一つのチェーン上で発生したイベントを監視し、別のチェーン上で対応するトランザクションを作成してそのイベントを検証・記録する。この方法でもクロスチェーン相互運用性を実現できるが、その安全性と分散化レベルは公証ノードの信頼性に大きく左右される。
3. ハッシュタイムロック契約（Hash Timelock Contracts, HTLCs）：
HTLCは、時間ロックに基づくスマートコントラクト技術であり、第三者なしに二人の当事者が安全にクロスチェーン交換を行うことを可能にする。これは、正しいパスワードを提供しないと資金を解放できないコントラクトを作成することで実現される。両当事者がともに契約条件を満たしたときのみ、資金が解放され相手方に支払われる。この方式は分散型のアセット交換を支援するが、当事者間の協力が必要である。
4. BoB（Blockchain on Blockchain、例えばCosmosのIBC）：
この技術方式は、既存のブロックチェーン上に新しいブロックチェーン（またはレイヤー）を作成することでクロスチェーン相互運用性を実現するもので、CosmosネットワークにおけるIBC（Inter-Blockchain Communication）プロトコルなどが該当する。IBCは異なるブロックチェーンが独立したガバナンス構造を維持しつつ、アセットとデータを安全に転送できるようにする。この方式は、各チェーンが自由に情報を交換できる分散型ブロックチェーンインターネットの構築を目指している。
これらの技術方式にはそれぞれ長所と短所があり、異なるシナリオやニーズに適用される。クロスチェーン技術の選定と実装には、対象となるブロックチェーンの特性、セキュリティ要件、分散化レベル、実装の複雑さなどを考慮する必要がある。
B. クロスチェーンメッセージ伝達
クロスチェーンメッセージ伝達（Cross-Chain Message Passing, CCMP）は、クロスチェーン相互運用性を実現するための中核技術であり、クロスチェーンインタラクションのプロセスが安全かつ効果的に進行することを保証する。その基本的な目的は、異なるブロックチェーン間でメッセージを伝達・検証し、アセットとデータのクロスチェーンインタラクションを実現することにある。その動作原理は主に以下の重要な段階からなる：
1. メッセージの生成と送信：
- メッセージには通常、アセット移転に関するすべての必要な情報（アセット数量、送信元アドレス、宛先アドレスなど）が含まれる。
- メッセージが生成されると、ソースチェーンのスマートコントラクトを通じて送信される。このコントラクトは取引詳細を記録し、アセットのロックをトリガーする。
2. メッセージの伝達：
- 伝達方法は一般的に二種類ある：直接伝達と中継伝達。
- 直接伝達とは、ソースチェーンとターゲットチェーン間に直接通信経路があることを意味するが、実際にはほとんど見られない。なぜなら、ほとんどのブロックチェーンは独立して動作しているためである。
- 中継伝達では、中継者（中央集権的なサービスプロバイダーまたは非中央集権的なノードネットワーク）が関与する。これらの中継者はソースチェーン上の特定のイベントを監視し、関連情報を取得してターゲットチェーンに伝達する。
3. メッセージの検証：
- ターゲットチェーンでは、受信したメッセージが合法性と完全性を持っているかを検証する必要がある。
- 検証プロセスには通常、ソースチェーンのデータ証明（Merkle証明など）が必要であり、これによりメッセージが確かにソースチェーンから来ており、改ざんされていないことが証明される。
- 検証が通れば、ターゲットチェーンのスマートコントラクトはメッセージ内容に基づいて対応する操作（トークンの鋳造やステータス更新など）を実行する。
4. 処理と応答：
- 検証完了後、ターゲットチェーンは必要な操作（アセットの解放や新たなトークンインスタンスの作成など）を実行する。
- このステップが終了すれば、クロスチェーンインタラクションは基本的に完了し、ユーザーはターゲットチェーン上でアセットを利用・管理できるようになる。したがって本質的に言えば、前述したいくつかのクロスチェーン技術方式は、異なるメッセージ伝達方式を採用していることに起因している。
1. クロスチェーンブリッジ
クロスチェーンブリッジは、中間層を構築することで異なるブロックチェーン間でのアセットおよび情報の移転を促進する。この中間層は以下のような形態を取り得る： - 中央集権的なサーバー。信頼できる実体が制御し、一方のチェーン上のイベントを監視し、他方のチェーン上でそのイベントを複製する。
- 非中央集権ネットワーク。複数の独立運営ノードから構成され、コンセンサスメカニズムを通じてメッセージの検証と転送を行う。
クロスチェーンブリッジでは、通常、ソースチェーンでのアセットロックとターゲットチェーンでの同等アセットの鋳造が行われる。このプロセスでは、メッセージが検証・実行される前に改ざんされないよう保証する必要がある。
2. 公証人
公証方式は、あらかじめ選ばれた一組の公証人（個人、組織、自動化されたノードなど）に依存しており、これら公証人が一方のチェーン上のイベントを監視し、他方のチェーン上でそのイベントを検証・確認する役割を担う。公証人は中央集権または半中央集権的な検証メカニズムを提供するが、その安全性と信頼度は公証人の信頼性に強く依存する。
3. ハッシュタイムロック契約（HTLC）
HTLCは、暗号技術に依存する契約であり、二つのチェーン間の条件付きアセット交換に使用される。これは、暗号学的ハッシュ関数とタイムロックを使ってアセットの解放条件を制御する：
- パスワードハッシュ：受取人が正しいプリイメージ（ハッシュに対応する元データ）を提供した場合にのみ、資金が契約から解放される。
- タイムロック：規定時間内に正しいプリイメージが提供されなかった場合、資金は元の所有者に返却される。
この方式は中央集権的な検証に依存せず、契約自体によってアセットの安全な交換が保証される。
4. BoB
この技術は、クロスチェーン通信プロトコルの上に新しいチェーンまたはサブチェーンを作成するものである。例えば、CosmosはIBCプロトコルを通じて異なるブロックチェーン間の直接通信を実現しており、各チェーンは自律性を保ちながら、安全にメッセージとアセットを交換できる。IBCやXCMPの本質はクロスチェーン通信プロトコルである。
同時にCCMP技術はいくつかの主要な課題にも直面している：
セキュリティ：リレーノードまたはネットワークは信頼できるものでなければならない。そうでなければ、メッセージが改ざんされるリスクがある。また、ソースチェーンとターゲットチェーンのスマートコントラクトも十分に安全に設計され、潜在的な脆弱性を防ぐ必要がある。
効率性と遅延：クロスチェーン操作は通常、複数のブロック確認を伴うため、顕著な時間遅延が生じる可能性がある。
分散化と信頼問題：リレーノードまたは第三者サービスに依存することは、ブロックチェーンの分散化精神に反する可能性があるため、分散化かつ安全なCCMPメカニズムの設計は技術的課題である。
これらの技術的・セキュリティ上の課題ゆえに、CCMPの実装と最適化はクロスチェーン技術の研究・開発において活発な分野となっている。さまざまな解決策が、分散化、安全性、効率性の間で最適なバランスを見つけることを試みている。
C. クロスチェーンアセットの署名と認可
クロスチェーン技術および相互運用性は、クロスチェーンメッセージ伝達（CCMP）に依存するだけでなく、ソースチェーンとターゲットチェーン上で効果的な署名と認可を行う方法にも依存しており、アセットの安全な処理と取引の正当性を確保する。異なるクロスチェーン技術方式は異なる署名・認可メカニズムを採用しており、その核は取引の正当性を検証・実行する方法と、アセットの安全な移転を保証することにある。以下は、一般的なクロスチェーン技術方式における署名認可の実装例である：
1. クロスチェーンブリッジ
クロスチェーンブリッジは、マルチシグネチャ（Multisignature）またはプロキシ署名（Proxy Signature）方式を採用することがある。この方式では、アセット移転操作に対して一定数の検証ノードまたは特定のプロキシサービスによる認可が必要となり、これらのノードまたはサービスが取引要求の検証と署名を担当する。この方式はセキュリティを高めるが、認可された中央集権または半中央集権的実体に依存するため、信頼性の問題も生じる。
2. 公証人
公証人方式では、公証人または公証ノード群が通常、クロスチェーン取引要求を監視・検証し、ターゲットチェーン上で対応する操作を実行する。公証人はターゲットチェーン上で操作に対する署名認可を行い、ソースチェーン上の取引が許可されていることを証明する。この方式は公証人の信頼度とセキュリティに依存する。
3. ハッシュタイムロック契約（HTLC）
HTLCでは、署名認可は外部の検証者や仲介者に依存しない。代わりに、取引の正当性と実行は契約ロジックと参加者間の直接的なやり取りに依存する。参加者が正しいプリイメージ（つまり鍵）を提供することで契約のロックを解除するが、これが一種の認可となる。さらに、契約自体がタイムロック機構を持ち、特定の時間枠内で正しいプリイメージが提供された場合にのみ取引が成立する。
4. BoB
例えば、CosmosのIBCプロトコルでは、署名認可プロセスはチェーン間プロトコルとローカルコントラクトの実行によって行われる。各チェーンは独自のセキュリティと認可メカニズムを管理し、プロトコルを通じてクロスチェーンメッセージの安全性と有効性を保証する。この方式は分散化と自律性を重視し、単一の実体への依存を減らす。
結局のところ、異なるクロスチェーン技術方式における署名認可メカニズムは、その構造とセキュリティ要件に応じて異なる。これらのメカニズムの選択と設計の鍵は、セキュリティ、信頼性、分散化、効率性のバランスをどう取るかにある。クロスチェーン技術を実施する際には、すべての参加チェーンの正当性とセキュリティを確保することが不可欠である。
D. 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コンポーネントのみを実行し外部チェーン上のイベントを監視する場合はobserver（観測者）となり、ZetaClientコンポーネントのみを実行して外部送信トランザクションに署名するだけの場合はsigner（署名者）となる。
ZetaChainはまた、標準的なECDSA/EdDSA鍵を共同で保持しており、外部チェーンとの認証インタラクションに使用される。これらの鍵は複数のsignerに分散されており、スーパーマジョリティのsignerのみがZetaChainを代表して外部に署名できる。ZetaChainはバインドされたステーキングと正・負のインセンティブメカニズムを使用して経済的安全性を確保する。
E. Zetachainの二種類のクロスチェーン相互運用メカニズム
Zetachainは二種類のクロスチェーン相互運用メカニズムをサポートしており、一つは従来のクロスチェーンブリッジ方式、もう一つはOmnichainスマートコントラクト方式である。
E.1 クロスチェーンブリッジ方式
まずクロスチェーンブリッジ方式の動作プロセスを見てみよう。全体のプロセスは主に以下のステップからなる：
1. ユーザーとコントラクトのインタラクション：ユーザーがチェーンAのコントラクトC1上で操作を行い、[chainID, contractAddress, message]を指定したイベントまたは取引メモを残す。このメッセージはバイナリ形式で符号化されたアプリケーションデータである。
2. 観測者がイベントをキャッチ：ZetaChainのobserver（zetaclient内）がこのイベントまたはメモを検出し、zetacoreに報告する。zetacoreは入力取引の検証を担当する。
3. 出力取引の構築：zetacoreはCCTX（クロスチェーン取引）の状態変数およびOutboundTxParamsを変更し、TSS signer（zetaclient内）が外部取引を構築・署名・ブロードキャストするよう指示する。
4. 署名とブロードキャスト：zetaclientのTSS signerはCCTX内のOutboundTxParamsに基づき出力取引を構築し、TSS鍵署名式典を実行した後、署名済み取引を外部ブロックチェーンにブロードキャストする。
5. 状態の更新と追跡：CCTX構造はまた、クロスチェーン取引の各段階／状態も追跡する。
6. 取引の確認：一旦ブロードキャストされた取引が何らかのブロックチェーンに含まれれば（「マイニング」または「確認」）、zetaclientはこの確認状況をzetacoreに報告し、その後CCTX状態を更新する。
7. 成功と失敗の処理：
- 外部取引が成功した場合、CCTX状態はOutboundMinedとなり、CCTX処理は完了し、最終状態に入る。
- 外部取引が失敗した場合（例：イーサリアムチェーン上で取り消された）、CCTX状態はPendingRevert（可能な場合）またはAborted（取り消しが不可能な場合）に更新される。Aborted状態になれば、CCTX処理は完了する。
8. 取り消し処理：
- 新しい状態が「PendingRevert」の場合、CCTX内にはすでに第二のOutboundTxParamsが含まれており、zetaclientsが入力チェーンおよびコントラクトに戻す「Revert」出力取引を作成するよう指示する。これにより、入力コントラクトはアプリケーションレベルでの取り消し機能を実装し、コントラクト状態をクリーンアップできる。
- zetaclientsは取り消し取引を構築し、TSS鍵署名式典を実行し、取引を入力ブロックチェーン（この例ではチェーンA）にブロードキャストする。
9. 取り消し確認：
- 一度取り消し取引がチェーンA上で「確認」されれば、zetaclientsは取引状態をzetacoreに報告する。
- 取り消し取引が成功すれば、CCTX状態はRevertedとなり、処理が完了する。
- 取り消し取引が失敗すれば、CCTX状態はAbortedとなり、処理が完了する。
上記のステップを通じて、クロスチェーンメッセージの伝達は主にZetaCoreとZetaClientの内部通信によって完遂されており、やや中央集権的な方式であり、Zetachain自身のスマートコントラクトは使用されていない。ターゲットチェーンのスマートコントラクトのみが使用されており、この場合、ターゲットチェーンがイーサリアムのようなスマートコントラクトプラットフォームである必要がある。ビットコインのような非スマートコントラクトプラットフォームでは使用できない。また、アプリケーションの状態とロジックはすべてのこれらのアプリケーションコントラクトに分散して存在する。異なるチェーン間での状態同期と通信は高コストで遅く、ロールバック処理も複雑化する。これらの問題を解決するために、ZetachainはOmnichainスマートコントラクト方式を導入した。
E.2 Omnichainスマートコントラクト方式
Omnichainスマートコントラクトは、ZetaChainが提案したクロスチェーン相互運用性処理を簡素化する方法である。主に以下のステップでクロスチェーンメッセージを処理し、クロスチェーン相互運用を実現する：
1. アセットの受領：ユーザーがローカルアセット（ERC20トークンなど）をチェーンAのTSSアドレスに送信し、同時に[zEVMContractAddress, message]を指定したメッセージを付加する。ここでいうTSSアドレスは、ERC20トークンをホストするために特別に設けられたコントラクトかもしれない。
2. 観測と報告：ZetaChainのobserver（zetaclients）がこのクロスチェーン呼び出しを検知し、zetacoreに報告する。
3. 呼び出しと実行：zetacoreはSystemContractの`depositAndCall()`関数を呼び出し、この関数がさらに指定されたzEVMContractAddressの`onCrossChainCall()`関数を呼び出す。この呼び出しプロセスでは：
- `zrc20`パラメータには、ユーザーが最初のステップで送った外部トークンを管理するZRC20コントラクトアドレスが設定される。
- `amount`パラメータには、ユーザーが送ったトークン数量が設定される。
- `message`パラメータには、ユーザーが取引メモに送ったメッセージが設定される。
4. コントラクトロジックの実行：`zContract(zEVMContractAddress).onCrossChainCall(zrc20, amount, message)`という形式でomnichainスマートコントラクトが呼び出される。アプリケーションコントラクトは`onCrossChainCall()`関数内でビジネスロジックを実装すべきである。
5. コントラクト実行結果の処理：
- コントラクト実行が成功し、外部アセット出力がない場合、このomnichainスマートコントラクトのインタラクションは完了する。
- zEVMコントラクトの実行が失敗した場合（ロールバック発生）、入力取引を取り消すためにCCTXが作成され、同じ数量の外部トークンがユーザーに返還される（可能な手数料を差し引いた上で）。
- `onCrossChainCall()`に出力がある場合（例：ZRC20の引き出し操作をトリガーした）、CCTXが新たに作成され、外部チェーン上のユーザー指定アドレスへ外部アセットを移転するよう指導・追跡する。これらの引き出しは通常、シンプルなトークン移転である。
Omnichainスマートコントラクトの顕著な特徴は以下の通りである：
- zEVM上にのみデプロイされ、すべてのロジックと状態が一点に集中するため、アプリケーションの開発とメンテナンスが容易になる。
- 外部チェーン上にアプリケーションスマートコントラクトをデプロイする必要がないため、ビットコインのような非スマートコントラクトチェーンもサポートできる。
- すべての取り消し操作はZetaChainプロトコルが処理するため、アプリケーションコントラクトは取り消しロジックを実装する必要がない。
一言で言えば、ZetaCoreとZetaClient間の内部通信に必要な少量の情報を除き、他のすべてのクロスチェーン情報処理ルールがZetachain自身のスマートコントラクトに書き込まれている。ユーザーがターゲットチェーンの指定アドレスに、付加メッセージ付きの送金を行うだけで、Zetachain自身のスマートコントラクト内のクロスチェーン操作がトリガーされる。
より複雑なdAppは、ロジックと状態が一点に集中しているため、Omnichainスマートコントラクトを好む傾向がある。一方、従来のメッセージ伝達では、異なるチェーン上でメッセージと状態をブロードキャスト・同期する必要があり、攻撃面が増えたり、ガス代が高くなったり（各メッセージに追加ガスが発生し、完全な状態同期を維持するためのメッセージ数が増える）する可能性がある。言い換えれば、開発者にとってOmnichainスマートコントラクトは、あたかもすべてのアセットが一つのチェーン上にあるかのように振る舞う（下図参照）。
F. 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は強力なクロスチェーン機能を提供するだけでなく、取引の安全性と検証の分散化も確保し、幅広いデジタルアセットの管理・操作を支援する強力なプラットフォームとなる。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@hiCaptainZ
