【ITニュース解説】When the Smart Contract Works, but the Payment Is Wrong: A Collusion Attack in MealForward (Part 1)

MealForwardは、ブロックチェーン技術を活用したコミュニティ食事券プロジェクトだ。このシステムでは、寄付者が資金をオンチェーンのエスクローコントラクトに預け入れ、承認された発行者が食事券を配布し、受け取った人々が提携レストランで一時的なQRコードを使って食事券を引き換える。レストランが食事の提供を確認すると、エスクローコントラクトから該当する金額がレストランに支払われる仕組みである。

スマートコントラクトのレビューを進める中で、「スマートコントラクトは設計通りに正しく実行されたのに、実際には提供されていない食事に対して誤った支払いがなされてしまうことはないか」という疑問が生じた。これはSolidityレベルの技術的な脆弱性にとどまらず、ビジネスロジックや信頼モデルに関わる、より広範な共謀攻撃の問題を指摘している。

MealForwardのエスクローコントラクトには、主にreport()とsettle()という二つの関数がある。report()関数は、オペレーターが食事の提供をコントラクトに報告するためのもので、settle()関数は、その報告に基づいて決済担当者がレストランへの支払いを実行するためのものだ。これらの関数にはアクセス制御が設けられており、オペレーターのみがreport()を実行でき、決済担当者のみがsettle()を実行できる。また、同じ食事券が複数回使われないような仕組みも含まれている。しかし、根本的な問題として、オペレーターは食事の提供が実際にあったことを証明することなく、有効な提供報告を提出できてしまう点がある。コントラクトは呼び出し元の権限や状態遷移が許可されているかは検証できるが、レストラン内部で実際に何が起こったかは直接知ることができないのだ。

この状況から、最初の攻撃シナリオとして「オペレーターとレストランの共謀」が想定された。もし攻撃者がオペレーターの秘密鍵を不正に入手し、さらに不正なレストランのオーナーと共謀した場合、攻撃者はreport()関数を使って、実際には食事が提供されていないにもかかわらず虚偽の提供報告を行うことができる。その後、共謀しているレストランがsettle()関数を実行すれば、スマートコントラクトはすべての条件が満たされていると判断し、レストランに資金を支払ってしまう。結果として、食事が提供されていないにもかかわらず、寄付者の資金が不正に流出することになる。これは、システムのビジネスロジックと信頼モデルの脆弱性であり、承認された参加者が共謀することで、経済的に誤った結果を引き起こす可能性があることを示している。

この共謀攻撃に対処するため、複数のアプローチが検討された。

第一のアプローチは「オンチェーンとオフチェーンの整合性確認（Reconciliation）」だ。これは、ブロックチェーン上のコントラクトの状態と、レストランの内部データベースのようなオフチェーンのビジネス記録との間に不整合がないかを監視する仕組みだ。例えば、オフチェーンでは食事が提供済みと記録されているのに、オンチェーンではまだ利用されていない状態であれば、システムは不整合を検知し、調査・回復を試みる。しかし、この方法にも限界がある。もしオペレーターとレストランが共謀して、オンチェーンとオフチェーンの両方の記録を偽造した場合、このシステムは異常を検知できない。データの一貫性があるからといって、それが現実の出来事の正確さを保証するものではないという点が重要だ。

第二のアプローチは「決済遅延（Delayed Settlement）」である。これは、report()関数による食事提供の報告から、実際にsettle()関数による支払いが実行されるまでの間に、一定の待機期間を設けるというものだ。例えば30分間の遅延期間を設けることで、この間に独立した監視サービスが不審な活動を検知し、必要であれば支払いを一時停止するなどの介入を行う時間的余裕が生まれる。この待機期間はスマートコントラクトによって強制される必要があり、監視や緊急介入はオペレーターの権限とは独立した主体が行うべきだ。しかし、このアプローチも、共謀者が一貫した偽の記録を作成した場合、監視システムがそれを正規のものと判断してしまう可能性があるため、物理的な食事の提供を証明するものではない。

第三のアプローチとして「受取人の食事券を承認プロセスに組み込む（Claim Permit with EIP-712）」が考案された。これまでのシステムではオペレーターの権限だけで食事券のロックが可能だったが、オペレーターの秘密鍵が侵害されるリスクを考慮し、オペレーターが食事券をロックする際に、単に自身の権限だけでなく、特定の食事券とレストランに対して発行された「クレーム許可証（Claim Permit）」も合わせて提出することを義務付けるというものだ。この許可証は、受取人が提示するQRコードなどを元に「償還権限者（Redemption Authority）」が署名し、EIP-712というイーサリアム標準を用いて安全に作成される。EIP-712は、構造化されたデータを安全に署名するための標準であり、署名がどのデータに対して行われ、どのコントラクトとチェーンに紐づいているかを明確にできる。この仕組みにより、オペレーターの秘密鍵が漏洩しても、償還権限者の署名がなければ不正な償還を行えなくなり、セキュリティモデルが強化される。

しかし、このクレーム許可証の導入も、「食事が実際に提供されたこと」を証明するものではない。例えば、不正なレストランが正規の受取人のQRコードをスキャンして有効なクレーム許可証を取得し、オペレーターがそれを使って手続きを進めたとしても、レストランが実際に食事を提供しないという共謀は依然として可能だ。クレーム許可証が証明するのは、特定のルールに基づいて償還が承認されたという事実であり、物理的なサービス提供を保証するものではないのだ。そのため、「クレーム許可証（償還の承認）」、「提供申告（食事提供の報告）」、「提供証拠（食事提供を裏付ける情報）」という三つの概念を区別することが極めて重要となる。受取人による確認のような追加の証拠導入も検討されるが、スマートフォンの有無やインターネットアクセスなど、アクセシビリティの観点から実用上の課題がある。

これらの議論を通して、スマートコントラクトが正しく機能することだけではDAppのセキュリティは完全ではないことが明らかになった。共謀攻撃のような問題に対処するためには、整合性確認、決済遅延、そしてEIP-712を利用したクレーム許可証といった、複数の対策を組み合わせてシステム全体のセキュリティを考える必要がある。それぞれの対策は異なる問題を解決するものであり、単独では十分とは言えない。これらのメカニズムは現在、MealForwardのセキュリティ設計の一環として検討されている段階であり、特定の前提（オペレーターの秘密鍵が侵害され、レストランと共謀する場合）の下で、不正な償還を大幅に減らすことを目指している。

この議論はさらに、「もしMealForwardプラットフォーム自体が悪意を持った場合、どうなるのか」という、より困難な問いへと続いている。オペレーター、償還権限者、監視システムがすべて同じプラットフォーム管理者によって制御されている場合、単にサーバーや秘密鍵を分けるだけで十分なセキュリティが提供できるのか、という根本的な疑問だ。これは、ユーザーがプラットフォーム自体を盲目的に信頼する必要のないDAppを設計するための、次なる検討課題となるだろう。