悪意あるコントラクトは、ユーザーに気づかれることなく、自分がシミュレーション環境で実行されているのか、それとも実際にオンチェーンで実行されているのかを事前にどう知ることができるのか？
鍵となるのは、ブロックチェーンの実行環境に「特殊変数」（special variables）と呼ばれる一連の環境情報が存在することだ。例えば現在のブロック高、タイムスタンプ、そして本記事で触れたブロック生成者のアドレス（COINBASE）などがそれにあたる。これらの変数は、各取引の実行時にコントラクトのコードが能動的に読み取り、それに基づいて異なる判断を下せる情報であり、もともとはコントラクトのロジックが自分が置かれているオンチェーンの状態を感知できるように設計されたものだ（例えばタイムスタンプに基づいてあるイベントがすでに終了しているかを判断するなど）。
問題はこうだ——実際のチェーン上では、これらの変数は常に具体的で意味のある値で埋められる。しかしシミュレーション環境では、実際にブロックがパッケージ化されることも、実際の生成者が存在することもないため、シミュレーションツールを開発するチーム自身が、これらのフィールドに何を入れるかを決めなければならない。ZenGoチームの研究では、一部の実装が最も手間のかからない方法を選び、ゼロ値やヌルアドレスをそのまま入れていたことが判明した。この一見無害に見える簡略化が、悪意あるコントラクトに「自分が今シミュレートされているかどうか」を明確に判別できる根拠を与えてしまった。これはコントラクトのコード内に「観客席に誰か見ている人がいるか」を確認できる窓を残しているのと同じことだ。
もしシミュレーションツールが、ブロック生成者アドレスなどの環境変数に、実際のチェーンと同じ具体的な値を単に入れるようにすれば、この問題は根本的に解決できるのではないか？
これは確かに業界が現在主に採用している修正の方向性だ。ZenGoチームもこの研究を開示した際、修正方法は比較的シンプルだと明確に指摘している——ゼロ値やヌルアドレスといった識別されやすい「近道」を使うのをやめ、実際のチェーンの状態から取得した意味のある具体的な値を代わりに入れることで、シミュレーション環境がオンチェーンの状態をできるだけ忠実に再現するようにするというものだ。開示通知を受け取ったベンダーの多くも、実際に短期間でこの種の修正を完了させた。
しかしこの解決策が実際に解決するのは、「COINBASEがゼロアドレスかどうか」という特定の判定方法だけであり、「コントラクトがシミュレーション環境と実際の環境を見分ける方法が何かあるのか」というより根本的な問題ではない。理論上は、シミュレーション環境と実際のオンチェーン環境の間に、コントラクトのロジックが検知できるわずかな違い——実行速度の微妙な差、一部の低レベルのシステムコールの挙動の違い、あるいはまだ公に研究されていない他の環境変数など——が少しでも残っている限り、周到に設計された悪意あるコントラクトは理論上、新たな判定根拠を見つけられる可能性がある。これこそが、ほとんどのセキュリティ研究者が次のような立場を取る理由だ——既知の手法にパッチを当てることは攻撃の敷居を大幅に引き上げるが、「シミュレーション環境が実際の環境と完全に区別不可能な状態を実現できるかどうか」は本質的に、継続的にリソースを投じ続けなければ優位を維持できない競争であり、一度きりで根本的に解決できる問題ではない。
この環境変数の差異を利用した検知手法以外に、悪意あるコントラクトが取引シミュレーションのチェックを回避できる方法は他にもあるのか？
ある。そして防御の観点から見れば、もう一つの手法がもたらす実際の影響はさらに深刻かもしれない。コントラクト自体にシミュレーション環境を検知させて回避させる代わりに、攻撃者はシミュレーション結果がユーザーに提示されるその段階に狙いを定めることもできる——つまり、シミュレーションツール自体は正しくシミュレーション結果を実行していても、その結果をユーザーが理解できる画面に変換するウォレットインターフェースの解析や表示のロジック自体に欠陥があれば、攻撃者は実際のシミュレーション結果と一致しない画面をユーザーに見せる機会を依然として持っている。例えば、ある取引が実際にはユーザーのウォレットの所有権を攻撃者が管理するコントラクトに移転する命令を含んでいるにもかかわらず、ウォレットインターフェースの解析ロジックがこの命令を正しく認識せず、「まもなく1 SOLを受け取ります」といった一見無害な部分だけを表示していれば、ユーザーは完全に知らないうちに、ウォレットの制御権を完全に手放す取引に署名してしまうことになる。
この種の「シミュレーション結果自体には問題がないが、ユーザーに提示される画面に問題がある」というリスクは、本サイトですでに紹介した盲目署名の核心的なロジックと密接に関連している——どちらも同じより根本的な原則を指し示している。ユーザーが実際に画面で目にする内容と、その裏で本当に起きている技術的な操作の間には、常に何らかのソフトウェアが翻訳を担う中間層が存在し、その翻訳層自体——シミュレーションエンジンであれウォレットインターフェースであれ——が攻撃されたり、設計が不十分だったりする可能性があるということだ。
取引シミュレーションツール自体すら回避されうるこの種のリスクに直面した際、一般ユーザーは実際に何ができるのか？どんなツールも本当には信頼できないように聞こえる。
その結論は早すぎる。この研究が明らかにしたのは、「取引シミュレーションは絶対的な保証ではない」という事実であって、「取引シミュレーションは役に立たない」ということではない——実際、この種の高度な回避手法を使わなければ突破できない攻撃の多くは、それ自体が攻撃者がかなりの技術的リソースと計画を投じたことを意味しており、この種の周到に設計された攻撃は通常、金額が小さく標的が不明確な取引には投じられない。日常的なほとんどの取引について、取引シミュレーションツールは依然として現時点で最も効果的で最も低コストな第一の防御線であり、それを使い続けることは、まったく使わないよりもはるかに安全であることに変わりはない。
より実践的な心構えは、取引シミュレーションツールを「リスクの確率を大幅に下げる必要な措置」として捉えることであり、「一度通過すればもう何も考えなくていい」という万能な保証として捉えないことだ。特にいくつかの特定の状況では追加の警戒を高める価値がある——取引が特に大きな金額を伴う場合、やり取りするコントラクトが最近デプロイされたばかりの場合、承認しようとする対象が知名度の高い主流プロトコルではない場合、あるいはシミュレーション結果が示す報酬が合理的とは思えないほど高い場合だ。こうした状況では、もう数分かけて第二の独立した情報源でコントラクトのロジックを確認したり、いっそのこと数日様子を見て他のユーザーが先に問題に遭遇するのを待ったりすることは、それほどコストをかけずに実質的に安全性のマージンを高める方法だ。セキュリティは決して単一のツールで完全に隙をなくすものではなく、複数の防御層を重ねることで、どの一層が破られても全体が丸ごと失われることのないようにするものなのだ。
本サイトの盲目署名のリスクを紹介した記事を読んだことがあれば、その中の具体的な提案の一つを覚えているかもしれない——取引に署名する前に、まず取引シミュレーションツールで一度実行してみて、その取引が実際に自分の資産にどんな変化をもたらすかを確認してから署名するかどうかを決める、というものだ。この提案自体は間違っていない。Coinbase Wallet、Rabby、Blowfishなど主流のウォレットや拡張機能にすでに内蔵されている取引シミュレーションツールは、確かに大量の悪意ある取引を食い止めることができる。しかし2023年にセキュリティ研究チームZenGoが開示したある手法は、この本来「防御線の一つ」と見なされていたツールに、それまであまり公に議論されてこなかった盲点があることを露呈させた——悪意あるコントラクトは、自分がシミュレートされていることを「察知」する方法を持っており、シミュレーション環境に対しては意図的に良好に振る舞い、取引が実際にオンチェーンに送信されて初めて本性を現すことができるのだ。
ZenGoチームはこの手法を「レッドピル攻撃」（red pill attack）と呼んでいる。その核心的な原理は、スマートコントラクトが実行時に読み取れる一部の「環境変数」を利用するものだ。例えばCOINBASE（現在のブロックを生成したマイナーまたはバリデーターのアドレスを表す）がその一例だ。これらの変数は実際のオンチェーン取引では常に具体的で非ゼロのアドレスで埋められる。しかしシミュレーション環境では、そもそも本物のブロックやマイナーが存在しないため、一部のシミュレーションツールの実装では、便宜上このフィールドを全ゼロのアドレスに設定してしまう。悪意あるコントラクトは、コード内に「もしCOINBASEがゼロアドレスなら、ユーザーに有利な偽の結果を返す。もしゼロアドレスでなければ、本当にやりたい悪意ある動作を実行する」というシンプルな判定ロジックを一行書くだけで、自分が現在シミュレーション環境で動いているのか、それとも実際にオンチェーンで実行されているのかを正確に見分けることができる。
ZenGoチームはこの攻撃がPolygonチェーン上でどう機能するかを実際に実演した。ある悪意あるコントラクトはユーザーにまず約0.1 MATIC（当時の価値で約0.1ドル）を送るよう求め、シミュレーション結果ではユーザーが見返りとして0.016 WETH（当時の価値で約30ドル）を受け取ると表示された——一見損をすることのない、非常に有利な取引に見え、ユーザーは安心して確認ボタンを押した。しかしこの取引が実際にオンチェーンに送信・実行される際には、その時点でCOINBASEフィールドにはすでに本物のブロック生成者のアドレスが埋められていたため、コントラクトは自分がシミュレーション環境にいないことを認識し、本来約束していた報酬をそのままスキップし、ユーザーが送ったMATICをすべて自分のものにしてしまった。この研究はその後調査範囲を拡大し、Coinbase Wallet、Rabby、Blowfish、Pocket Universeを含む合計6つの主流ウォレットとセキュリティ拡張機能に、この種の手法に対する防御上の抜け穴が存在していたことが判明した。ほとんどのベンダーは責任ある開示を受けた後、迅速に修正を完了させ、ZenGoもそれによって複数のバグ懸賞金を獲得した。
この研究が明らかにした核心的な教訓は、「取引シミュレーションツールは役に立たないから使うな」ということではない——実際、ほとんどの主流ツールは開示後にこの特定の、今では既知となった検知手法に対して修正を完了しており、シミュレーションは依然として、この種の高度な回避テクニックを伴わないほとんどの悪意ある取引を食い止め続けている。使い続ける方が、まったく使わないよりもはるかに安全だ。本当に見直すべき認識は次の点だ——取引シミュレーションが示す「安全」という結果は、確率的に極めて信頼性の高いシグナルであって、決して迂回不可能な絶対的な保証ではなかった。特に出所不明のコントラクト、稼働開始からまだ日が浅いコントラクト、あるいは著名なプロトコルと意図的に酷似したインターフェースを持つコントラクトに直面した際には、追加の慎重さが依然として必要だ。具体的に取れる対策としては、特に金額の大きな取引については、単一のシミュレーションツールの結果だけでなく、別の独立した情報源（ブロックチェーンエクスプローラーのコントラクトソースコード照会機能など）を使ってコントラクトのロジックを追加で確認すること。「損をすることのない」取引、合理的な範囲を明らかに超える報酬を謳う取引に対しては、普段よりも高い警戒を保つこと——これはまさに攻撃者がシミュレーション結果を偽装してユーザーに署名させる最も強い動機を持つ場面だからだ。そして継続的にリソースを投じて新しい回避手法に対抗する検知ロジックを更新し続けているシミュレーションサービス提供者を優先的に選ぶこと。「シミュレーションを行った」ことを、一度きりのチェックで安心できる終着点と見なさないことが大切だ。