feat(evm): compile etherscan sources and use them on the debugger

[joshieDo]

Motivation

WIP

Debugging with sources coming from etherscan is nice.

Solution

1. When identifying addresses for traces, collect addresses & sources.
2. Compile each contract address [and downloads the solc version required)
3. Provide them to the TUI debugger. Here I changed the TUI initialization. @brockelmore wdyt ?

Missing:

• [ ] etherscan multi-file support
• [ ] cache
• [ ] cleanup

It's working now with some limitations:

• flattened sources only
• no vyper
• no v0.4.*
• --via-ir isn't provided by etherscan (i think...).

Working example:

cargo run --bin cast -- run 0xe6288cf5bb88281801302d558e434b8fced0dbaa8edc007ef2f5b0ffec694f88 --rpc-url https://api.avax.network/ext/bc/C/rpc --debug

If there are many contracts, be ready to wait a while...

[onbjerg]

I think there was talk of source maps being added to the Etherscan API (it's already present in the UI) - is this something we can get confirmed somewhere, and if so, are we willing to wait for that considering that this is sort of a workaround for that?

[mattsse]

it's not yet included in the getsourcecode api https://api.etherscan.io/api?module=contract&action=getsourcecode

[onbjerg]

it's not yet included in the getsourcecode api https://api.etherscan.io/api?module=contract&action=getsourcecode

Yeah, I meant that there was talks that it would be included soon-ish. I just don't know when, but if we can get a timeline and its not too far out we should maybe hold off and wait for that?

[joshieDo]

It will still take some time for etherscan to add it from my understanding. And when it does arrive, some of these changes will need to happen anyway.(eg. passing sourcemaps per external contracts to the debugger UI).

But even then, I feel like it could be added because:

• it's not clear all contracts will have a sourcemap. For example. USDT does not have a sourcemap in the UI.
• other chains' "etherscans" might not add this to their API or be slow to add it.

[onbjerg]

Alright, I was just saying that if it would be added soon there probably wouldn't be much of a point adding something we are going to delete, but if you feel strongly that it will take a long time/be incomplete then you're free to go ahead :)

[gakonst]

@joshieDo are we interested in picking this up again?

[mds1]

IMO yes, this would be a really great feature. Having a module for etherscan compilation would also be useful for things like https://github.com/foundry-rs/foundry/pull/2494#issuecomment-1198773042

[joshieDo]

i'd love to have this feature, but with all the refactors/conflicts (also the incoming TUI one), it's probably better to start from scratch. Maybe use this one as a potential reference.

[gakonst]

Agree that this should be started from scratch. Will see if I can find someone to take it over the finish line using this as a reference.

[omkarb]

Sorry for the delay on this team, I'll have a new draft PR building on the work that JoshieDo has done in the next couple days.

[gakonst]

Thanks boss

[gakonst]

superseded by https://github.com/foundry-rs/foundry/pull/3006