fix: script simulation with default sender

[klkvr]

Motivation

Closes #8960

Right now, when simulating a script without providing a --sender arg, we will use the default sender both for script contract deployment and setUp/run. This will result in sender nonce being higher than an actual on-chain nonce. For certain scripts, this might result in mismatched addresses and failure during on-chain simulation, if incorrect addresses end up in calldata.

Solution

Fix contains 2 parts:

1. Follow-up for fix: nonce correction logic #7907 which enables nonce correction even when sender is default foundry sender. Unsure why this case was excluded earlier
2. Hack during script execution — if we're simulating with default sender, we'd set it's nonce to a hardcoded high value for script contract CREATE transaction. This allows us to reset nonce back to on-chain value when simulating the script, and ensure matching contract addresses during on-chain sumlation

[grandizzy]

Possibly fixing #2002 too

[klkvr]

Possibly fixing #2002 too

I don't think so. This sounds like an issue with gas estimation on optimism? looks like people are getting around it by using --with-gas-multiplier

it could be addressed by enforcing --slow for optimism by default, like we do for arbitrum:

foundry/crates/cli/src/utils/cmd.rs

Line 163 in 8905af3

pub fn has_different_gas_calc(chain_id: u64) -> bool {

though this might affect UX

cc @mds1, assume you're running scripts on OP networks quite often and know about hacks that are required

[mds1]

cc @mds1, assume you're running scripts on OP networks quite often and know about hacks that are required

Most scripts I run these days are actually on L1, so I don't have much insight unfortunately. I will see if someone else has more insight than I do here

[grandizzy]

makes sense, lgtm!

[grandizzy]

@zerosnacks @yash-atreya mind to check before merging? thank you!

[zerosnacks]

Fix LGTM

Initially thought that setting the nonce to a constant u64::MAX / 2 might result in duplicate nonces / replacement transactions but considering the state is committed directly and synchronously this should not be an issue