revm
revm copied to clipboard
feat: Structured Logging
Right now, Revm has no logging. It might make sense to integrate https://docs.rs/tracing in most places, so we have better visibility in its internals?
Arent the inspector and traces good enought for inspecting internals?
Arent the inspector and traces good enought for inspecting internals?
It's mostly for when we debug unexpected behavior etc in the Foundry executor, then we lack insight into what is going on in REVM, even outside of the inspectors
@onbjerg but, let me ask it like this, where would you put additional traces that are not covered by inspector?
In anything between inspector calls, or outside of the reach of inspectors, e.g. the precondition checks in transact:
https://github.com/bluealloy/revm/blob/71372fa9a2c2206c21448be0ec4b6dbece9ab281/crates/revm/src/evm_impl.rs#L43
Or the post checks in finalize:
https://github.com/bluealloy/revm/blob/71372fa9a2c2206c21448be0ec4b6dbece9ab281/crates/revm/src/evm_impl.rs#L193
Maybe some of the functions in SubRoutine to figure out what is being returned from things like load_account and so on.
Basically, sometimes you want to know what lead to the state you end up with in an inspector
@onbjerg precondition checks return an error if there is some check that doesnt pass, while finalize just aggregates changes and returns output, both can be traced outside of EVM. Figuring out what subroutine does is more on the level of debugging of EVM and not a contract, i dont usually expect this to happen, and when there was a need for debugging i usually just used EVM traces and output changes and compare them with geth EVM, I dont feel like traces there would help me a lot and they are would usually be turned off by default, it would just make noise. What is the main idea behind adding this other that we can add them (as a feature)?
This is now probably not a path revm is going to take. We can reopen it if you think there is a need.