feat(`verify`): ability to verify external code

[sakulstra]

Component

Forge

Describe the feature you would like

When deploying a script that interacts with an external factory, foundry does not verify the created contracts.
E.g. here we call a proxy factory that creates on oz proxy - foundry did not verify the proxy(it's verified because i did it manually).

By my understanding, the reason for that is that foundry does not have the local bytecode of that contract in that case (given the factory was deployed from another repo potentially with other compiler settings).

---

Now, as i understand foundry scripts, for tracing all touched addresses are downloaded from explorers already - so in fact found should have the code, even if it's not part of the repo. While this is a bit of an edge case, over the last couple years we faced this shortcoming quite a few times.

Additional context

#4522 probably slightly related, as i guess one would need to be able to compile different contracts with potentially different settings without pruning existing ones.

[grandizzy]

@sakulstra in the sample you posted the factory is not verified https://sepolia.basescan.org/address/0x914d7fec6aac8cd542e72bca78b30650d45643d7 can you verify and retry? Thank you

[sakulstra]

@grandizzy this is the verified factory: https://sepolia.basescan.org/address/0x95f99d1695c866feb16657cca8e91437a50d2a5e
I think what you shared is the create2 factory used under the hood: https://github.com/safe-global/safe-singleton-factory

[grandizzy]

@klkvr would be great to have your input if that's feasible to implement. thank you!

[klkvr]

Now, as i understand foundry scripts, for tracing all touched addresses are downloaded from explorers already - so in fact found should have the code, even if it's not part of the repo. While this is a bit of an edge case, over the last couple years we faced this shortcoming quite a few times.

This is right, however, we are only downloading ABIs. To obtain code, we'd need to compile the downloaded contracts which might take a while and is not something that can be done by default (you could try running cast run <some big tx> --debug to try it yourself)

We could add this as an opt-in though. Generally I think it'd be nice to collect more context from downloaded contracts. I could also see forge test --debug rendering sources of etherscan contracts