Closed d-xo closed 1 year ago
Actually for the first case we don't even need an Expr -> EVM compiler, we can just generate random bytecode, produce an Expr from it, and then compare both against some concrete value.
Notes to self:
Fuzz input generators: https://github.com/MariusVanDerWijden/tx-fuzz https://github.com/MariusVanDerWijden/FuzzyVM
Runners: https://github.com/holiman/goevmlab
Branch: fuzz-msoos2
Check accuracy through geth:
--dev
mode and use geth attach
JSON RPC: https://ethereum.org/en/developers/docs/apis/json-rpc/eth.call
method of geth in JSON-RPC mode (https://www.quicknode.com/docs/ethereum/eth_call) can set state (including injecting a contract), execute code, and get the return value. It does NOT persist state, which is good. Then we can check it against what HEVM did.Catch errors with:
Fuzzing tools:
Tracing:
This has been implemented in Tracing.hs
, closing.
Just noting some ideas that @msooseth and I discussed for nice fuzzing pipelines that we could write if had an Expr -> EVM compiler.
Compiling an Expr End into EVM bytecode should be fairly simple, especially if we produce yul instead of bytecode directly. Each ITE can be an if-then-else block, and translating return / revert leaves into return / revert statements in yul shouldn't be too hard.
Concrete Evaulation vs Geth
This would test our smt encoding to make sure that it matches the concrete semantics (we could use the concrete semantics from hevm or from geth).
Symbolic Exec vs Equivalence Checker
This would test the symbolic execution engine (and Expr -> EVM compiler) against the equivalence checker.