crytic / medusa

Parallelized, coverage-guided, mutational Solidity smart contract fuzzing, powered by go-ethereum
https://secure-contracts.com/program-analysis/medusa/docs/src/
GNU Affero General Public License v3.0
301 stars 40 forks source link

Add hevm/foundry cheatcodes #36

Closed montyly closed 1 year ago

montyly commented 2 years ago

prank, vm, etc...

Supporting hevm/foundry cheatcodes is going to be important for medusa's success. This might require us to keep a fork of geth.

bsamuels453 commented 1 year ago

is it possible to just use anvil as the vm engine instead of geth? there's a lot of foundry contributors and it might be hard to keep up with implementing new cheatcodes

Xenomega commented 1 year ago

Anvil is written in Rust and this is Go, so unless there is a well maintained go interface or we maintain one ourselves (which would probably be less desirable than just rewriting everything in Rust at that point depending on how much access we'll want to expose for testing), then I don't see that being the case.

But yeah, you do have a point about that Ethereum implementation being more flexible than go-ethereum for cheat codes given they already maintain a lot, and have a nice framework beyond their Ethereum implementation. I was told our goal here was to make a go-ethereum based fuzzer here though.. so if we changed our mind, maybe we should have another discussion?

montyly commented 1 year ago

Under the hood anvil use revm: https://github.com/bluealloy/revm. However foundry is actually building their own node (https://twitter.com/gakonst/status/1595648232226291712), so it's unclear if anvil will become part of reth or not.

I don't think we need to use the same VM as foundry. We want to be driving our development, not following another one. Implementing the cheatcodes might be tricky with geth, but once we know how to do it, it should not take too much ressources. It's not like they are going to change all their cheatcode every month, and they should become stable.