Integrate CaptureArbitrumStorageGet/Set into the prestate tracer #2602
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.
This PR implements
CaptureArbitrumStorage[Get]Set
methods forprestateTracer
capturing changes that ArbOS makes to storage outside EVM execution, these weren't picked up by theprestateTracer
before.Arbos
Storage
object callsRecordStorage[Get]Set
functions to capture tracing of reads and writes of key-value pairs, meaning the SLOAD/SSTORE opcodes tracing in these functions during scenarioTracingDuringEVM
has no impact at all as the caller address (scope.Contract) and the key being passed don't associate with each other, instead the key corresponds to types.ArbosStateAddress.To solve this issue, we currently call
CaptureArbitrumStorage[Get]Set
regardless of the tracing scenario and call opcode tracing additionally if the scenario isTracingDuringEVM
to preserve functionality of other tracers that haven't yet implementedCaptureArbitrumStorage...
methods. Notice that SLOAD/SSTORE opcode tracing has no effect on prestate tracer due to the above stated issue and callingCaptureArbitrumStorage...
methods first yields correct results.Pulls in geth- OffchainLabs/go-ethereum#352
Resolves NIT-2733