【ITニュース解説】How Do I Verify a Manta Bridge Deposit in My dApp?

ブロックチェーンの世界では、異なるブロックチェーン間で資金を移動させる「ブリッジ」という仕組みがよく使われる。今回取り上げるManta Bridgeもその一つで、イーサリアム（L1）とManta Pacific（L2）の間で資産を移動させるためのものだ。システムエンジニアとして、このようなブリッジを使ったアプリケーションを開発する際、ユーザーが資金を預け入れたことをどのように確認し、アプリケーションに反映させるべきか、その具体的な方法と注意点を解説する。

まず重要なのは、ユーザーがイーサリアム上で預金取引を行ったことを示す「イーサリアムのレシート（領収書）」が確認されたとしても、それだけで資金がManta Pacific上で「利用可能になった」とは限らない、という点である。イーサリアム上での取引は、あくまで資金がブリッジに預け入れられたことを証明するに過ぎず、Manta Pacificという別のブロックチェーン上に資金が反映され、使えるようになるまでには、さらなるプロセスが必要となる。

Manta Pacificは「OP Stack」という技術に基づいたL1からL2へのメッセージフローを採用している。これは、イーサリアム（L1）側で預金が記録されると、その情報がメッセージとしてManta Pacific（L2）に送信され、L2側で対応するETHやトークンがユーザーのアカウントにクレジットされる、という流れである。このプロセスは「非同期」で実行される。つまり、イーサリアム上で預金取引が完了した時点と、Manta Pacific上で実際に資金が利用可能になる時点との間には時間差があるため、これらを別々の状態として扱う必要がある。

アプリケーションでユーザーの預金を「完了」と判断し、利用可能な残高として計上するためには、Manta Pacific側で資金が確実にクレジットされたことを証明する「目的地側の証拠」を用いるべきだ。具体的には、Manta Pacific上でのトランザクションが成功し、ユーザーの残高が意図通りに増加したことを確認するか、ブリッジの最終処理を示すイベント（特定のログ情報）をデコードし、資産の種類と金額が一致することを確認する必要がある。イーサリアムのレシートだけでは、資金がManta Pacific上で自由に使える状態になったという信号にはならないのだ。

特に、ERC-20のようなトークンを預け入れる際には、L1（イーサリアム）のトークンと、Manta Pacific上で対応するトークンを正確に照合することが非常に重要だ。単に表示されている「シンボル」だけを頼りにするのではなく、そのトークンの「コントラクトアドレス」を確認するようにしよう。異なるブリッジを経由して同じシンボルのトークンがManta Pacificに届いた場合、それらのコントラクトアドレスは異なる可能性があるため、混同を避ける必要がある。Mantaの公式トークンリストを参照し、正規のブリッジ資産と、外部からブリッジされたトークンを区別するためのコントラクトマッピングを利用することが望ましい。

アプリケーションの内部で預金処理の進行状況を管理する際には、「ステートマシン」という考え方を取り入れると良い。これは、預金が「提出済み（ユーザーのウォレットがL1ハッシュを返した時点）」「ソース確認済み（L1のレシートが成功した時点）」「完了（Manta Pacific側でのL2クレジットが確認された時点）」といった具体的な状態を遷移していく形で管理する。そして、データベースには、イーサリアム側とManta Pacific側の両方のトランザクションハッシュを一緒に保存しておくことを推奨する。これにより、万が一問題が発生した場合でも、ユーザーやシステム運用者が転送の両側面を簡単に追跡し、調査できるようになる。

もし、イーサリアム側で預金が確認されたにもかかわらず、Manta Pacific側で対応するクレジットが見つからないという状況が発生した場合は、すぐにユーザーに「もう一度送金してください」と促すのは避けよう。まずは預金を「保留中」のステータスにして、その原因を詳しく調査することが重要だ。このような症状は、メッセージがL2に中継されるのが遅れている「遅延リレー」、ブロックチェーンのデータを読み取る「RPCインデクサー」の遅延、Manta Pacific上での取引実行が失敗して元に戻ってしまった「宛先実行のロールバック」、あるいは送金先のウォレットアドレスが間違っていた「受信者不一致」など、様々な原因によって引き起こされる可能性がある。それぞれの場合で必要な対処方法が異なるため、適切な調査が不可欠となる。

具体的な回復手順としては、まず、預金を行ったイーサリアムのトランザクションハッシュを保存し、そのイーサリアムのレシートが単に「提出された」だけでなく「成功した」ことを確認する。次に、ブリッジのトランザクションデータやそこから出力されるログ情報をデコードし、送金者、送金先のアドレス、資産のコントラクトアドレス、そして金額といった預金の詳細を正確に記録する。その後、Manta Pacific側の情報を独立して照会する。この際、もし普段使っているRPCエンドポイント（ブロックチェーンの情報を取得するためのサーバー）が遅延している可能性があるなら、別のRPCやブロックチェーンエクスプローラーを使って、送金先のトランザクション、受信者の残高、関連するブリッジイベントなどを確認すると良い。

これらの調査を行った上で、再試行する前に状況を「調整」することが大切だ。もしManta Pacific側でクレジットが確認できれば、チェーンの状態に基づいてアプリケーションを更新し、預金を完了済みにする。しかし、もし実行が失敗していたり、依然としてクレジットが見つからない場合は、重複した預金を再度送信するのではなく、最初のソースハッシュを調査のために保持し続けるべきだ。

実践的な運用ルールとして、ユーザーインターフェース上では「ソース確認済み（イーサリアム側で確認済み）」と「Manta Pacificで利用可能」という二つの異なるステータスを明確に区別して表示することが推奨される。また、Manta Pacific側のトランザクションハッシュは、それが実際に存在し、確認できてからユーザーに表示するようにすると良い。このように慎重な確認と透明性のある状態管理を行うことで、ブリッジを介した預金処理におけるユーザーの混乱を避け、アプリケーションの信頼性を高めることができるだろう。