Pre-Execution Simulation

What is pre-execution simulation, and how does it relate to the agent execution loop discussed earlier in this series?

When this series broke down the agent execution loop earlier, it discussed potential latency problems in each of the perceive, decide, and act stages. Pre-execution simulation is an additional check inserted between the decide and act stages — after an agent decides to submit a transaction, rather than submitting it directly on-chain, it first "pretend-executes" that transaction in a simulated environment that can fully reproduce on-chain state, seeing what the actual outcome would be.

This extra step is fundamentally there to address a potential misjudgment in the decision stage — even if the decision logic itself looked reasonable, the actual execution outcome can still differ from what's expected due to the current on-chain state (a liquidity pool's real-time balance, or someone else's transaction that just happened to complete first, for example). Pre-execution simulation gives the agent a chance, before actually spending funds, to confirm whether something unexpected would happen if this transaction were genuinely submitted.

Why is pre-execution simulation necessary — isn't a correct judgment at the decision stage enough?

A decision-stage judgment is usually calculated based on the on-chain state the agent read at that instant, but between the decision being made and the transaction actually being packed into a block, on-chain state can keep changing — a concrete manifestation of the execution latency problem discussed earlier in this series. Without a pre-execution simulation check, an agent has no choice but to blindly submit the transaction, only discovering after it's actually confirmed on-chain that the real outcome differed significantly from expected (slippage exceeding tolerance, say, or the transaction failing entirely and wasting gas).

Pre-execution simulation lets the agent verify once more, at the last moment before submission, using on-chain state as close to real as possible, significantly reducing the odds of "looked reasonable at decision time, but something went wrong at execution." This mechanism matters especially because once a transaction genuinely fails on-chain or causes an unexpected loss, that cost is usually real and irreversible (especially the gas already spent, which isn't refunded even if the transaction fails), while pre-execution simulation's cost is relatively low — just extra computational resources, not real funds involved.

実行前シミュレーションは実際どのように機能し、技術的にどうオンチェーンの状態を再現するのですか？

一般的な技術実装は、ローカルまたはクラウドで実行される完全なオンチェーン状態のコピーを通じて行われる（メインネットをフォークすることで、現在の全てのオンチェーンデータを含むシミュレーション環境を構築するなど）。エージェントは送信予定の取引をこのシミュレーション環境に投入して実行し、環境はこの取引が実際に引き起こす状態変化を返す——実際の資産残高の変動額、消費されるガス量、そして取引が何らかの理由（設定されたスリッページを超える、残高不足、コントラクトロジックによる拒否など）で失敗するかどうかである。

より高度な実装では、本シリーズで前述したMEV関連の概念も組み合わせる——シミュレーション環境は現在mempool内にある他の未確認取引が引き起こし得る影響を再現しようと試み、シミュレーション結果を取引が実際にオンチェーンに反映される時の実際の状況により近づける。単に現在確認済みのオンチェーン状態に基づいてシミュレーションするだけではない。このようなより完全なシミュレーションは、市場が極めて短時間で変化することによってシミュレーション結果と実際の実行結果にギャップが生じる確率をさらに低減できる。

実行前シミュレーションは一般ユーザーにどのような実際の影響を与えますか？DeFAI製品の評価にどう応用すればいいですか？

利用しているDeFAIエージェントに実行前シミュレーション機構が組み込まれている場合、この製品はあなたの資金が実際にオンチェーンに送られる前に、明らかな誤りや想定外の結果につながる取引をフィルタリングできる安全網を追加で備えていることを意味する——これは市場の瞬間的な変化や、判断ロジックが境界的なケースを十分考慮していなかったことによる不必要な損失や無駄なガス代を効果的に減らせる。どのDeFAI製品を評価する際も、このエージェントが取引を送信する前にシミュレーション検証のステップを備えているか、そしてシミュレーション結果が失敗や想定外の損失を示した場合、エージェントがどんな対応措置を取るか（自動的に取引をキャンセルする、パラメータを調整して再シミュレーションする、あるいは全く処理せずそのまま送信するなど）を直接尋ねる価値がある。

ある製品が実行前シミュレーションについて全く言及していない場合、その製品が必ず安全でないことを意味するわけではないが、「判断」と「実際に資金を使う」の間に、比較的低コストでありながら実質的な保護を提供できるチェック機構が欠けていることを意味する。この場合、想定外の実行結果が発生する確率は理論上、シミュレーション機構を持つ製品よりも高く、ポジション計画において追加で考慮する価値がある。