私はOmniston、STON.fiのクロスチェーン、そして一般的にSTON.fiについて、多くの記事を書いてきました。


私が最も頻繁に使ってきた用語の一つがRFQです。


もう一つがHTLCです。


Omnistonがクロスチェーン・スワップをどのように扱うかを議論する中で、何度もそれを説明してきましたが、ひとつ問題があります。裏側で何が起きているのかをすでに理解していないと、RFQとHTLCは、複雑な暗号系の略語が2つ並んでいるだけに聞こえてしまうのです。


そうではありません。


簡単に言うと、RFQはクロスチェーン・スワップをどのように実行すべきかを決めるのに役立ちます。一方、HTLCは、2つの別々のブロックチェーン間での交換を調整するための仕組みを提供します。


でも、具体的にどのように一緒に働くのでしょうか?


では、あなたがスワップをクリックした瞬間から、資産が別のブロックチェーンに到着するまでに何が起きるのでしょうか?


分解してみましょう。


❑ なぜクロスチェーンのスワップには“スワップボタン以上のもの”が必要なのか


通常のトークンスワップは、両方の資産が同じブロックチェーン上に存在するなら比較的シンプルです。


ユーザーが1つの資産を用意し、流動性ソースが別の資産を用意し、トランザクションは同じネットワーク内で決済できます。


クロスチェーンのスワップには、もう1つの問題が入ってきます。


仮に、TONをEthereum上の資産と交換したいとします。TONとEthereumは独立したブロックチェーンです。ネイティブのトランザクション状態を共有していないため、TON上のトランザクションが「何かが起きた」とEthereumに単純に伝えることはできず、Ethereumがそれを同じ取引の一部として扱うことも期待できません。


したがって、システムは2つの別々の問題を解決する必要があります。


まず、到達先チェーン上で資産を提供できる相手を見つける必要があります。


次に、何かが起きて失敗した場合に、一方の側だけが不完全な取引を抱えたままにならないよう、交換を協調する必要があります。


ここで2つの概念が重要になります:


実行オファーを見つけるためのRFQ

条件付き決済のためのHTLC。


彼らは同じ問題の別々の部分を解決します。


❑ RFQ:市場に、あなたのスワップを実行できるのは誰か尋ねる


RFQはRequest for Quoteの略です。


一番簡単に理解するには、大量の通貨を交換したいと想像するとよいです。


1人のディーラーに行って、提示されたどんな価格でも受け入れる代わりに、複数のディーラーに聞くこともできます:


「この数量を交換したい。あなたは何を提示できますか?」


それが、RFQシステムの背後にある考え方そのものです。


スワップリクエストには、関係する資産、数量、要求する出力、タイミング要件、決済情報などの情報を含めることができます。


その後、流動性提供者は、実行したい内容を説明するクォートで応答できます。


Omnistonでは、これらの流動性提供者をリゾルバと呼びます。


重要なのは、RFQはスワップを決済する仕組みではないという点です。


主に、実行可能なオファーを見つけることです。


基本の流れは:


1. ユーザーがスワップリクエストを送信します。

2. リゾルバはリクエストを受け取ります。

3. リゾルバは実行可能なクォートを返します。

4. 適切な引用(クォート)が選択されます。

5. 取引は決済と実行のフェーズに進みます。


つまり、クロスチェーンのスワップ説明で「RFQ」を見かけたら、こう考えてください:


「誰がこの取引を実行できるの? それはどんな条件で?」


❑ リゾルバ:クォートの裏側にいる相手


リゾルバを理解すると、RFQモデルがかなり理解しやすくなります。


リゾルバは、為替レートを提示し、取引の実行にも関わるサービスです。クロスチェーンのルートでは、リゾルバは到達先ブロックチェーン上で必要となる流動性も提供できます。


それは従来のブリッジとは違います。


ブリッジは一般に、ネットワーク間で資産を移動または表現することに焦点を当てます。RFQベースのスワップシステムにおけるリゾルバは、特定の取引を埋められるプロのマーケットメイカー、あるいは流動性提供者のような役割を担っています。


こう考えてください:


RFQ:実行可能なオファーを出せるディーラーに複数問い合わせる

リゾルバ:注文を埋めることができるディーラー

クォート:取引に提示された条件 


複数のリゾルバが応答する場合、システムは利用可能なクォートを評価して適切なものを選択できます。


しかし、リゾルバを見つけるのは問題の半分にすぎません。


それでも取引を決済する必要があります。


❑ RFQがディールを見つける。でもどうやって決済するの?


あなたがクロスチェーン取引に合意したところを想像してください。


あなたは送信元チェーンでTONを提供します。


リゾルバはEthereumでETHを提供すると約束します。


では、あなたが最初にTONを送ったのに、リゾルバがETHを決して届けなかったらどうなるでしょうか。


あるいは、リゾルバがETHをロックするが、あなたが自分の側を決済しないといったことも起こり得ます。


価格クォートだけでは、その問題は解決できません。


システムは、トランザクションの2つの側面を同じ出来事に条件付ける方法を必要としています。


ここでHTLCが登場します。


❑ HTLC:秘密と締切のあるロック


HTLCはHash Time-Locked Contractの略です。


名前は難しそうに聞こえますが、実際には2つの単純な仕組みを表しています。


1つ目はハッシュロックです。


秘密が生成され、その秘密の暗号学的ハッシュが条件の一部として使われます。元の秘密を知っている人(プリエイメージ)であれば、そのハッシュ条件を満たして解決できます。


2つ目はタイムロックです。


コントラクトには時間に基づく条件も含まれています。必要な行動が該当期間内に起きない場合、返金経路が利用可能になります。


たとえとしては、開けるのに特定のパスワードが必要な金庫があり、さらに有効期限の条件もある、といった感じです。


こう捉えられます:


Hashlock = 「正しい秘密が必要です。」

Timelock = 「一定の時間だけだよ。」


それらによって、条件付きのロックが作られます。


❑ なぜ2つのHTLCが必要なのか


クロスチェーンのアトミックスワップでは、1つのHTLCだけでは不十分です。


取引の両側で連動した条件が必要です。


たとえば、あるユーザーが送信元チェーン上のTONを、Ethereum上の資産と交換すると想像してください。


1つのHTLCがユーザーの送信側資産を保持し、別のHTLCがリゾルバの到達側資産を保持します。


双方が同じハッシュロックを使います。


重要な関係はこれです:


送信側HTLC ↔ 到達側HTLC


同じ秘密が2つをつなぎます。


秘密が適切な請求プロセスを通じて明かされると、それをもう一方の側の対応する条件を満たすために使えます。


必要な決済が行われない場合、該当するTimelockによって、最終的に返金(リファンド)への経路が利用可能になります。


これは、HTLCベースのアトミックスワップで使われる“オールオアリファンド”設計の基盤です。


❑ 「スワップ」をクリックしたときに実際に何が起きるの?


では、すべてをまとめましょう。


あなたがTON上の資産を、別の対応ブロックチェーン上の資産と交換するところを想像してください。


1. スワップリクエストを送信します


アプリケーションは、あなたが行いたい取引内容を説明するRFQを作成します。


そこには、関連する資産、数量、実行要件が含まれています。


2. リゾルバは応答します


リゾルバはリクエストを受け取り、実行可能なクォートを提供します。


それぞれのクォートは、そのリゾルバが実行する準備ができている内容を示しています。


3. クォートが選択される


システムは、利用可能な実行条件に応じて関連するクォートを選択します。


この時点で、RFQは主要な役目を果たしました。


システムは実行オファーを見つけました。


4. クロスチェーンの注文が開始される


取引は決済フェーズへ移行します。


送信側の資産は適切な決済プロセスに入り、リゾルバは到達側の流動性を用意します。


5. 両側が条件付きで結び付けられる


HTLCベースのクロスチェーンフローでは、同じハッシュロックを通じて送信側と到達側がつながります。


リゾルバは、取引に必要な到達側の流動性を提供します。


6. 秘密が明かされる


関連する決済条件が満たされると、秘密を開示できます。


その秘密によって、適切な当事者が自分のためにロックされた資産を請求できます。


7. 両側が決済する


ユーザーは到達先の資産を受け取ります。


リゾルバは送信側の資産を受け取ります。


つまり、単なる「相手が取引を完了してくれる」という約束に頼るのではなく、双方は同じ暗号学的条件を通じて結び付けられます。


8. 取引が完了しない場合


必要な決済条件が該当するタイムアウトの前に満たされない場合、決済ルールに従って返金経路が利用可能になります。


これは重要な違いです。


システムは「すべてのスワップが必ず成功しなければならない」と言っているわけではありません。


設計されたタイムアウトと返金メカニズムによって資産を回復できるなら、失敗したスワップは正当な結果になり得ます。


❑ RFQとHTLCは競合ではない


これは、すべてを覚えるのにおそらく一番簡単な方法です。


RFQ - 実行可能な流動性と取引条件を見つける

リゾルバ | 流動性を提供し、ルートを実行する

HTLC - 条件付きクロスチェーン決済を調整する

Omniston - これらのコンポーネントをクロスチェーン実行システムにつなぐ


つまり、RFQかHTLCのどちらが「より良い」のかを尋ねても、あまり意味がありません。


それらは異なるレイヤーで動作します。


RFQは、実行発見(execution discovery)の問題を解決します。

HTLCは条件付き決済の問題を解決します。


その両方を理解して、アーキテクチャを理解する必要があります。


❑ Omnistonはこの中でどこに当てはまる?


ここで、概念が実装につながっていきます。


OmnistonはTON上での流動性集約システムとして始まり、より広いクロスチェーン実行モデルへと進化しました。


そのアーキテクチャは、見積り(クォート)を依頼するプロセスと、実際の取引の決済を分離しています。


クロスチェーンルートでは、RFQ、リゾルバ、クォート選択、そしてクロスチェーン決済というモデルになります。


HTLCベースのモデルでは、送信側と到達側の区間は、ペアになったHTLCを通じて協調されます。


つまりOmnistonは、単に「1つのHTLC」ではありません。


それは、スワップを成立させるために必要な異なるコンポーネントをつなぐ、より広い実行レイヤーです。


アーキテクチャを簡潔に見ると、こうです:


ユーザー → RFQ → リゾルバ → クォート → 選択された実行 → クロスチェーン決済 → 到達先の資産


HTLCベースのクロスチェーン経路では、その後の決済段階で、共有されたハッシュロックとそれぞれのタイムアウト条件を通じて送信側と到達側がつながります。


この違いは重要です。なぜならRFQとHTLCはOmnistonの中で競合する2つの技術ではありません。実行プロセスの異なる段階で動作します。


❑ 何かがうまくいかなかったときはどうなる?


失敗の理解は、成功の理解と同じくらい重要です。


適切な実行可能なクォートを提供できるリゾルバがいなければ、取引を進める必要はありません。


実行が始まったとしても、必要な決済条件が満たされない場合、該当するタイムアウトの仕組みによって、最終的に返金経路が利用可能になります。


そして、すべてが意図どおりに機能するなら、秘密が双方をつなぎ、各参加者が自分の資産を請求します。


だからこそ、「アトミック」を「絶対に何も問題は起きない」という意味だと解釈しないことが重要なのです。


アトミックな決済とは、双方が条件付きで結び付けられる仕組みを指します。


全体のシステムは、ブロックチェーンの利用可能性、正しいコントラクトのロジック、適切なタイムアウト設定、トランザクションの実行、そして流動性の可用性といったものにも依存し続けます。


この仕組みの強みは、失敗した実行でも、単に双方を永久に相互依存させたままにするのではなく、定義された復旧(リカバリ)経路を持てる点です。


❑ それは、単に資産をブリッジするのと何が違うのか


クロスチェーンのスワップを、従来のブリッジモデルと区別することが役立ちます。


従来のブリッジでは、あるネットワークで資産をロックし、別のネットワークで資産を作成/表現することが関わる場合があります。


アトミックなクロスチェーンのスワップでは、別々のチェーン上の資産同士の交換を調整します。



Omnistonのクロスチェーンアーキテクチャは、リゾルバを使って到達側の流動性を提供し、クロスチェーン決済の仕組みでトランザクションを調整します。


それは、リゾルバを理解することがHTLCを理解するのと同じくらい重要である理由です。


❑ 必ずしも適切に単純化されがちな部分


HTLCは強力ですが、魔法ではありません。


「クロスチェーンのスワップが“アトミック”である」と言っても、試みたすべての取引が必ず成功するという意味でも、起こり得るすべてのリスクが消えるという意味でもありません。


仕組みはそれでも、基盤となるブロックチェーン、スマートコントラクト、タイムアウト設定、トランザクションの実行、そして参加する流動性提供者の可用性に依存します。


また、自動的な成功と復旧可能性(リカバリ)の間にも重要な違いがあります。


取引に必要な条件が満たされない場合、Timelockが返金経路を利用可能にできます。実装や決済の段階によって、その回復には適切なオンチェーン請求、または返金トランザクションが必要になることがあります。


役に立つ頭の中のモデルは、次のようなものではありません:


「HTLCなら何も問題は起きない。」


それは:


「HTLCは、2つの側面をつなぐ条件付き決済ルールを作り、必要な条件が満たされない場合にはタイムアウトに基づく復旧経路を提供します。」


技術を理解するうえで、はるかに正確な捉え方です。


❑ 2つの略語、2つの異なる仕事


RFQとHTLCを理解すれば、クロスチェーンのスワップはずっと考えやすくなります。


いくつかの異なる問題が、同時に解決されています。


RFQが実行オファーを見つけます。

リゾルバは流動性を提供し、ルートを実行します。

HTLCは独立したチェーン間での条件付き決済を提供します。


そしてOmnistonは、これらの要素をつなぎ合わせて、クロスチェーンの実行フローにします。


クロスチェーンのスワップ説明でRFQとHTLCが出てきた次回は、それらを暗記すべき“もう一つの暗号略語”として扱う必要はありません。


覚えておくべきことはこれだけ:


RFQがディールを見つけます。

リゾルバが流動性を提供します。

HTLCが決済条件をつなぎます。


そして、それがスワップボタンの裏側で起きることです。