fix: pre-state tracer logging storage after call from precompile #64
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why this should be merged
Fixes tracing when a stateful precompile calls another contract that itself accesses storage.
How this works
The pre-state tracer from
eth/tracers/native
doesn't implementCaptureEnter()
(entry of a new context), instead relying onCaptureState()
(per-opcode tracing) to detect that a new contract has been entered. In doing so, it maintains an invariant that is expected whenCaptureState(vm.SLOAD, ...)
is called—breaking the invariant results in a panic due to a nil map.The fix involves (a) maintaining the invariant as part of
CaptureEnter()
(previously a no-op); and (b) calling said method insidevm.PrecompileEnvironment.Call()
. The latter has the added benefit of properly handling all tracing involving an outbound call from precompiles.How this was tested
New integration test demonstrates that the tracer can log the retrieved storage value.