feat: restrict parallel precompile state access - #120
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
close https://github.com/Galxe/gravity-audit/issues/1089
Summary
This PR implements the Grevm side of Galxe/gravity-audit#1089 by replacing unrestricted parallel custom precompiles with a capability-restricted API.
ParallelPrecompileandDynParallelPrecompileas the registration boundary for custom precompiles used by the parallel scheduler.ParallelPrecompileInputwithout exposing AlloyPrecompileInput, rawEvmInternals, ordb_mut().ParallelPrecompileState:balance,sload,set_balance, andsstore.Schedulerand worker EVM construction to accept the restricted type and perform the Alloy adapter conversion internally.Motivation
Alloy
PrecompileInputexposes the full mutable EVM internals. A custom precompile could therefore read or write throughdb_mut()and bypass the revm journal.In parallel execution, bypassing the journal can break:
The new API makes journal-aware access the only way for a scheduler-registered custom precompile to interact with EVM state.
Design
Restricted precompile interface
ParallelPrecompileInputprovides:The state facade deliberately does not expose the raw database, mutable journal accounts, code mutation, checkpoints, logs, transient storage, or a conversion back to
EvmInternals.All state operations go through revm journal APIs. Storage access preserves normal account-first semantics, including beneficiary-history coordination. The lower-level database storage path remains independent of beneficiary reward history as a correctness fallback.
Error and execution semantics
STATICCALLare recorded as sticky halts, even if an implementation ignores the returned error and reports success.RevertandHaltresults follow normal call-frame rollback semantics.Precompile implementations remain responsible for gas validation and complete
PrecompileOutputaccounting. They must also remain safe to call concurrently and more than once because speculative executions may be discarded and retried.Integration impact
This is an intentional API change for custom precompile users:
becomes:
Integrations should implement
ParallelPrecompiledirectly or construct aDynParallelPrecompilefrom a restricted closure. Built-in precompiles and scheduler users that do not register custom precompiles are unaffected.Testing
Coverage includes:
sload/sstore;Revert,Halt, and fatal-error atomicity;Basicwrite.Related