すべてのアトミックスワップが同じというわけではない

Zenith Network

すべてのアトミックスワップが同じというわけではない

Zenith はEVMアプリケーションがCanton ネイティブのアセットおよびアプリケーションとアトミックに連携することを可能にします。そのためにZenith が依拠するのは、真のコンセンサスベースの アトミック性です:Zenith EVMはCanton のコンセンサスメカニズムを使用して、トランザクションを単一の不可分な操作として調整・決済します。

対照的に、ハッシュタイムロックコントラクト(HTLC)は、多くのクロスチェーン「アトミック」スワップの背後にあるメカニズムであり、本質的に異なるものを提供します。HTLCは経済的 アトミック性をスマートコントラクト層で強制しますが、決済は依然として独立したコンセンサスメカニズムに依存しています。

この記事では、両者の違いを詳しく解説し、異なるコンテキストにおける「アトミック」の真の意味を明確にします。

「アトミック」の2つの意味

「アトミック」という用語はしばしば柔軟に使用され、異なるメカニズムを表し、最も重要な区別を曖昧にしています。

  • 経済的アトミック性はハッシュタイムロックコントラクトを使用して実装され、スマートコントラクト層で機能します。スワップが完全に完了するか、まったく完了しないかを保証しますが、トランザクションの両レッグはそれぞれのチェーン上で、独自のコンセンサスメカニズムを通じて、独自のファイナリティ時間で決済されます。

  • コンセンサスレベルのアトミック性はプロトコル層で機能します。トランザクションの両レッグは同一の単一コンセンサスメカニズム内で処理され、単一の不可分な操作としてコミット(または拒否)されます。結果を強制するためのタイムロックや暗号エスクローへの依存はありません。プロトコル自体がそれを保証します。

これは些細な意味論的区別ではありません。ファイナリティ、レイテンシ、セキュリティ、およびコンポーザビリティに重大な影響を与えます。

Article image

HTLCの仕組み

ハッシュタイムロックコントラクトは、多くのクロスチェーンアトミックスワップの基盤となるメカニズムです。このコンセプトは、ハッシュロックとタイムロックを条件付き支払いに組み合わせた初期のBitcoin開発者によって提案されました。これ以来広く採用されており、例えばChainlinkは 詳細な解説を提供し、独立したブロックチェーンネットワーク間でのピアツーピアのアセット交換を可能にする方法を説明しています。

典型的なHTLCベースのクロスチェーンスワップの仕組みは以下の通りです:

  1. Alice(チェーンA上)とBob(チェーンB上)はトークンのスワップに合意します。

  2. Aliceはシークレットを生成してその暗号ハッシュを計算し、チェーンA上にタイムロックスマートコントラクトをデプロイして自分のトークンをそこに預け入れます。コントラクトはそのハッシュでロックされており、元のシークレットを知っている者だけが資金を引き出せます。引き出されなかった場合、トークンは設定されたタイムアウト後にAliceへ返還されます。

  3. BobはAliceのハッシュを確認し(シークレットは見えません)、チェーンB上に対応するタイムロックコントラクトをデプロイして(Aliceのものより短いタイムロックで)自分のトークンを預け入れます。彼のコントラクトは同じハッシュを使用します。これにより両者はそれぞれのチェーン上のコントラクトに資産をロックした状態になります。

  4. Aliceはシークレットを公開することで、チェーンB上のBobのトークンを引き出します。この公開はオンチェーン上で可視状態になります。

  5. Bobは公開されたシークレットを使って、チェーンA上のコントラクトからAliceのトークンを引き出します。

  6. いずれかの当事者がそれぞれのタイムロック期間内に預け入れまたは引き出しを行わなかった場合、コントラクトはリバートされ、すべてのトークンは元の所有者に返還されます。

ハッシュタイムロックコントラクトを通じたスワップは「アトミック」であるのは経済的な意味においてのみです:プロトコルが誠実に遵守された場合、両者がトークンを受け取るか、どちらも受け取らないかのいずれかになります。これはアプリケーション層におけるオール・オア・ナッシングの結果です。

しかしこのスワップの決済はアトミックではありません。 Aliceの引き出しトランザクションはチェーンBのコンセンサスで決済されます。Bobの引き出しトランザクションはチェーンAのコンセンサスで決済されます。これらは完全に独立した2つのファイナライゼーションプロセスです。単一のコンセンサスメカニズムがオペレーションの両レッグを処理する瞬間は一切存在しません。「アトミック」な保証はスマートコントラクトロジックの特性であり、基盤となる決済の特性ではありません。

Article image

HTLCの欠点と攻撃ベクター

HTLCはクロスチェーン取引において有用な経済的保証を提供しますが、タイムロック・独立したコンセンサスメカニズム・ゲーム理論的な前提への依存に起因する重大な構造的弱点を抱えています。

Article image

ファイナリティは最も遅いチェーンに依存する

HTLCベースのスワップは、関与するネットワークの中で最も遅いものと同じ速度にしかなりません。両者はスワップが最終的なものと見なされる前に、両チェーン上で十分な承認数を待たなければなりません。一方のチェーンのブロック時間が遅い、混雑が激しい、あるいは(特定の条件下のEthereumのように)確率的ファイナリティを持つ場合、スワップ全体のファイナリティのタイムラインはそれに応じて延びます。これにより、厳密なタイミングや迅速な決済を必要とするあらゆるインタラクションにHTLCは不向きとなります。

タイムロックが非現実的なレイテンシを生む

タイムロックの期間は、ネットワーク遅延・ブロック時間のばらつき・十分な承認数の確保を考慮して保守的に設定しなければなりません。実際には、タイムロックの期間は数時間単位で設定されることが多くなります。取引・DeFiのインタラクション・応答性を必要とするあらゆるワークフローにおいて、このレイテンシはHTLCベースのスワップを事実上非現実的なものにします。スワップの開始から完了までの時間は、実行ではなく待機によって支配されます。

チェーンの再編成がファイナリティの前提を損なう

Ethereumを含む確率的ファイナリティを持つチェーンでは、ブロックの再編成によってトランザクション履歴が遡及的に変更される可能性があります。確認済みと見えた引き出しトランザクションが、相手方がスワップ完了を前提にすでに行動した後であっても、再編成によって巻き戻される可能性があります。HTLCにはこれを処理する組み込みのメカニズムがありません。タイムロックが期限切れになり、シークレットが公開された後でも、一方のチェーン上の決済が依然として覆される可能性があります。これにより、いかなるスマートコントラクトロジックも解消できない真の決済リスクの窓口が生まれます。

グリーフィング攻撃がコストなしに資本をロックする

HTLCに対して最もよく研究されている攻撃ベクターの一つがグリーフィング攻撃です。悪意ある当事者がスワップを開始し、相手方の資本をロックした上で、意図的に自分の側の完了を拒否します。誠実な当事者のトークンはタイムロックが期限切れになるまで凍結されたままになります。攻撃者は最初のトランザクションのガスコスト以外に何も支払いません。

サービス拒否攻撃によってタイムアウトが引き起こされる可能性がある

攻撃者がネットワークレベルのDDoSやRPCエンドポイントへのフラッディングによって、当事者がクレームトランザクションを送信できないようにした場合、タイムロックが期限切れとなりスワップは失敗する。誠実な当事者はトークンを失わない(リバートされるため)が、スワップ自体は妨害される。高額または時間的制約のある状況では、スワップの失敗自体も重大な損害をもたらす可能性がある。

フリーオプション問題

HTLCはシークレットを生成した当事者、この例ではAliceに有利な非対称性を本質的に生み出す。両当事者が資産をロックした後、Aliceはシークレットを公開してスワップを完了するかどうかを、Bobのタイムロックウィンドウの全期間にわたって決定できる。価格が不利な方向に動いた場合、Aliceは何もしないだけでよく、両方のタイムロックが期限切れとなり、両サイドがリバートされ、Aliceはそのまま立ち去ることができる。一方、すでにトークンをロックしているBobにはそのような選択肢がない。彼はデポジットした瞬間から拘束され、ただ待つことしかできない。ボラティリティの高い市場では、これは事実上BobのコストでAliceにフリーオプションを与えることになる。

Canton と Zenith EVM にまたがる真のアトミック性

Zenith は根本的に異なるアプローチを採用している。Zenith はEVM実行をCanton のコンセンサスの内部に組み込み、プロトコルレベルで真のアトミックコンポーザビリティを実現する。

external_call() プリミティブ

Zenith EVM と Canton 間のスワップや複数レッグのDeFiオペレーションを含むアトミックなインタラクションは、ZenithがDamlに実装したexternal_call()プリミティブによって実現される。この関数により、Damlコントラクトは同一のCantonトランザクション内で決定論的にEVM実行環境を呼び出すことができる。

クロス環境トランザクションのフローは以下の通りである:

  1. サブミッション:ユーザーは、対応するDaml操作とともにラップされたEVMトランザクションペイロードを含むネイティブCantonトランザクションを送信する。

  2. インボケーション:Damlコントラクトがトランザクションを処理し、external_call()を呼び出して、ローカルで稼働するRethベースのEVMランタイムにEVMペイロードを転送する。

  3. ネイティブEVM実行:Cantonパーティシパントはカノンノードおよびzenith EVMオペレーターとしての二重の役割で動作する。EVMトランザクションはEthereumと一貫したシーケンシャルなシングルスレッドセマンティクスでネイティブに実行され、新たなEVM状態ルートが生成される。

  4. 決定論的バリデーション:Zenith はCantonのネイティブな二段階バリデーションモデルに依存している。

    1. サブミッターはインタープリテーション中にexternal_call()を実行し、その結果をトランザクションビューに含める。

    2. ドメイン内の他のすべてのCantonバリデーターが独立して同一の呼び出しを再実行する。

    3. いずれかのバリデーターが異なる結果を得た場合、トランザクション全体が拒否される。

  5. アトミックセトルメント:Canton側のレッグとEVM側のレッグはどちらも同一のsameCanton トランザクションの実行ツリーの一部であるため、両方が成功するか、トランザクション全体が失敗するかのいずれかとなります。結合されたトランザクションが検証されると、ファイナリティがユーザーに確認されます。

Article image

実際に何を意味するか

external_call()プリミティブは Canton のネイティブ検証モデルに従っており、追加の信頼前提を導入しません。タイムロックはありません。一方のレッグが決済済みで他方がまだという状態になる窓口も存在しません。結果は両当事者が合理的かつ誠実に行動するかどうかに依存せず、プロトコル自体が両レッグを共にコミットするか、まったくコミットしないかを保証します。

EVM の実行が Canton トランザクション全体に加えるレイテンシはわずか数百ミリ秒であり、HTLC ベースのスワップが持つ潜在的に長いタイムロック期間と比較すれば無視できるオーバーヘッドです。

まとめ

違いは以下のように整理できます:

Article image

おわりに

これまで見てきたように、アトミックスワップはすべて同等ではありません。誰かが「アトミック」と言うとき、「どのレイヤーでアトミックなのか」と問うことが重要です。

その答えによって、あなたが得ているものが、設定されたタイムロック強制ルールの中で両当事者が合理的に行動することに依存する約束なのか、それともトランザクションが完全に実行されるかまったく実行されないかを保証する真のプロトコルレベルの保証なのかが決まります。

gradient bg

Ready to build on Canton?

Let’s design your EVM environment together.

Let’s get started
Zenith Logo

© 2026 Zenith. All rights reserved. Registered Canton Super Validator.

Privacy Policy