Simulation-Execution Gap

What is the simulation-execution gap, and how does it differ from the pre-execution simulation discussed earlier in this series?

The pre-execution simulation discussed earlier in this series introduces this mechanism's own value — predicting the outcome before a transaction is formally submitted, avoiding sending a transaction that's obviously going to fail or cause a loss. The simulation-execution gap addresses this mechanism's limitation: no matter how precise the simulation result is, it's only a prediction based on the on-chain state at the moment of simulation, and between when the simulation completes and when the transaction actually gets packed into a block, on-chain state could have already changed, causing the actual execution result to not fully match the simulation's prediction.

This means pre-execution simulation is this mechanism exists and is usually effective, while the simulation-execution gap is even though this mechanism exists, you can't assume it's 100% accurate — understanding this gap helps you more accurately assess this protective measure's actual level of protection, rather than mistakenly believing having a simulation equals foolproof.

Why does a gap exist between simulation and actual execution, and how does this gap arise?

The first cause of this gap is a time lag — a simulation calculates its result based on the on-chain state at the moment of simulation, but between when the simulation completes and when the transaction actually gets packed and confirmed, several seconds or even longer could pass. If on-chain state changes during this window (a price swing, or another transaction executing first and changing contract state, say), the actual execution result could differ from the simulation's prediction — a structural cause similar, along the time-gap dimension, to the oracle latency arbitrage discussed earlier in this series.

The second cause of this gap is the simulation engine's own technical limitation — most simulation environments, in order to return a result within a reasonable time, simplify the genuine on-chain environment to some degree. This simplification causes no problem in most cases, but under certain complex edge scenarios (a complex transaction involving multiple protocols interacting in sequence, say), the subtle difference between the simplified simulation and the real execution environment can cause the simulation result and actual result to diverge.

シミュレーションと実際の実行のギャップは実際どのように現れ、それを説明する具体的なシナリオはありますか？

典型的なシナリオは次の通りである：市場が激しく変動している瞬間に、エージェントがまず取引に対して実行前シミュレーションを実行し、シミュレーション結果はこの取引が許容できるスリッページの範囲内で成功裏に実行できることを示しているため、エージェントはこの取引を送信することを決定する——しかし市場が激しく変動しているため、シミュレーションが完了してから取引が実際に組み込まれるまでのわずか数秒の間に、価格がさらに変動している可能性があり、実際の実行時のスリッページがシミュレーション時に予測された範囲をはるかに超え、本シリーズで前述したサンドイッチ攻撃をトリガーする可能性さえあり、実際の実行結果とシミュレーションの予測との間に大きなギャップが生じる。

このシナリオは、このギャップが増幅される瞬間は、しばしば市場の変動が最も激しく、状態の変化が最も速い時であることを思い出させてくれる——そしてその瞬間はまさに、ユーザーが実行前シミュレーションに正確に保護効果を発揮してほしいと最も必要とする時でもある。この「それを正確であってほしいと最も必要とする時ほど、逆に不正確になりやすい」という特性は、このメカニズムを評価する際に特に注意すべき環節である。

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

評価しているDeFAI製品が「実行前シミュレーションがある」ことを主な安全性のセールスポイントとして扱っている場合、このチームにさらに尋ねる価値がある：システムはシミュレーション結果と実際の結果の間に存在し得るギャップに対して、追加の保護メカニズムを設計しているか——取引を送信する際にシミュレーション結果よりも保守的なスリッページ許容範囲を追加で設定する、あるいはシミュレーション完了後に市場が激しく変化したことを検知した際に、古いシミュレーション結果をそのまま使って取引を送信するのではなく、もう一度シミュレーションを実行して再確認するなど。

実際に応用する際、これも本シリーズで繰り返し強調してきた原則の再現である——単一の保護メカニズムにはそれぞれ限界がある。実行前シミュレーションは確かにほとんどの明らかに問題のある取引をフィルタリングできるが、絶対的な保証として扱うべきではない。「シミュレーション検証」能力を謳うどのDeFAI製品を評価する際も、この機能が「宣伝されているかどうか」だけを見るのではなく、市場が激しく変動する極端な状況下でこのメカニズムが実際どれだけ信頼できるかを優先的に尋ねる価値がある。