Omnichain Smartcontract vs Messaging
Omnichainスマートコントラクトとメッセージングの比較
アイデアを練り始めると、「dAppをどのように構築すればいいのだろう」と考えるかもしれません。ここでは、アプリケーションのアーキテクチャを決定するのに役立ついくつかの考慮事項を紹介します：
アーキテクチャの決定
旧来のソリューションであるメッセージパッシングは、別のブロックチェーンにメッセージを転送するためのリレーとしてのみZetaChainを使用します（例：Ethereum→BSCなど）。dAppは、接続された各チェーン上に少なくとも1つのコントラクトを展開する。dAppのステートとロジックは、非同期メッセージで接続されたチェーン上のすべてのコントラクトに散らばっています。これは、一方向の非同期ロジック/エフェクトのみを必要とし、統一されたステートを必要としない、または恩恵を受けない特定のアプリケーションにとって理にかなっています。
OmnichainスマートコントラクトとZRC-20トークンを使用した新しいアーキテクチャは、非常に異なるトポロジーを持っています：dAppにはzEVM上の1つのコントラクトのみが必要で、外部チェーンにはdAppのコントラクトは必要ありません。zEVMはZRC-20コントラクトを介して外部チェーンのコインを管理します。
dAppは、以下の検討事項に基づいて、これらのソリューションのどれかを活用することができます：
dAppの複雑さ
より複雑なdAppは、ロジックと状態がより集中化されているため、Omnichain Smart Contractsを好むかもしれません。一方、メッセージングでは、異なるチェーン上の多くのコントラクト間でメッセージと状態の同期をブロードキャストする必要があり、これは実質的に攻撃対象やガス料金の高さにつながります（各メッセージには追加のガス料金を支払う必要があり、完全に状態の同期を保つために送信しなければならないメッセージ数はスケールします）。
既存のEVMコントラクトの上に構築する
Uniswap V2/V3、Curve、Aave、Compoundなど、Ethereum上で監査と実戦テストが行われた一般的なアプリケーションは、ZetaChainで簡単にデプロイできます。ZRC-20との互換性を追加することでこれらのアプリケーションを拡張することはできますが、それらの変更は最小限であり、ロジックの大部分は同じままである可能性があり、ユーザーはイーサリアム上で行うのと同様にシングルステップ取引でこれらのアプリケーションとやりとりすることができます。一方、メッセージングでは、多くの状況（特に複雑なもの）で、開発者は「車輪を作り直す」必要があります。つまり、まったく別の、非同期メッセージングと状態同期システムでロジックを作り直すのです。メッセージングでは、同じように既存のアプリケーションを活用できません。
スマートでないコントラクトチェーンのサポート
ZRC-20はBitcoin/Algorand/Cardano/XRPを簡単にサポートできますが、スワップや貸し出しなどのアプリケーションで汎用的なスマートコントラクトをサポートする能力や効率はありません。メッセージングには、接続されたチェーン上のスマートコントラクトが必要なため、これらのチェーンではメッセージングが機能しません。
外部ガスコスト
ZRC-20は、外部チェーンとのやり取りがFTに限定されているため、多くのユースケースでメッセージパッシングよりもガスコストが大幅に削減されます（ETH/BNB/MATICの標準価値移転には21kガス、ERC20トークンの移動には約60kガスかかります。）メッセージパッシングは本質的にソース/デスティネーションチェーンでメッセージデータを処理する必要があり、検証、検証、パージングなどのために追加のガスコストがかかります。
流動性の一元化
omnichainスマートコントラクトを使用すると、ネイティブアセットの流動性を直接ペアにして取引することができます。これにより、ネイティブアセットを取引するためのステップが最小限になり（1ステップ）、ブリッジやラッピングのステップや複雑なメッセージの送信は必要ありません。例えば、単一取引で統一プールを通じてイーサリアムETHをポリゴンUSDCと直接取引することができます。メッセージを使えば、既存のチェーン上のUniswapプールのような既存の流動性を活用し、ZetaChainを通じてZETAの燃焼/造幣を経由して取引することができます。このアプローチは、より複雑（より多くのトランザクションが関与し、より多くのガス）かもしれませんが、ZetaChainのエコシステム内の流動性に依存するものではありません。オムニチェーーンスマートコントラクトとメッセージングは、どちらも統一された流動性へのアプローチを提供しますが、開発者が自分のシステム要件に基づいて選択する次第です。
例外処理
ZRC-20/zEVMでは、トランザクションが処理されると同時に、外国のインタラクションが標準的なERC-20/契約インタラクション（成功）または契約インタラクションなし（失敗）のいずれかに限定されるので、例外/復帰処理ははるかに単純です。これに対し、メッセージングでは復帰をサポートしていますが、dApp（およびユーザー）は、非同期/イベント駆動の方法でエラーをやみくもに待ち、処理しなければなりません。