GetRulesExtra derived a Rules' Lux rules from a process-wide last context: the chain config and timestamp of whichever Rules any goroutine evaluated most recently. Rules are evaluated concurrently, by block processing, the miner, the tx pool and every eth_call, so a Rules could read another evaluation's upgrades: its IsDurango, its predicaters, its enabled precompiles, and the intrinsic gas that depends on them. The precompile overrider read the same global when the EVM asked it for a precompile, so which Lux precompiles a call reached could follow another goroutine's block. The context now travels with the Rules value. core's rules hook already put the chain config and timestamp in Rules.Payload for its precompile overrider; the overrider answers them, and GetRulesExtra reads them from the Rules it is given. The overrider decides its own enabled set from them too. RulesAt attaches them where no hook did. The global and SetRulesContext are gone. Every call site evaluates its Rules for the block it reads them for, so a caller that no other goroutine races sees the same rules as before. The blob pool's state checks passed a zero Rules and read the head's context the check before them had left; they now pass the head's Rules. TestRulesExtraIsTheRulesOwn evaluates two rule sets and reads the first; TestPrecompileOverrideIsTheRulesOwn asks each one's overrider for the tx allow list after the other was evaluated, in both orders; TestRulesExtraUnderConcurrentEvaluation reads four rule sets on four goroutines at once, across two times and two chains, including the intrinsic gas of a creation and the precompile a call reaches. TestActivePrecompiles, skipped for this bug, runs again. Co-authored-by: Hanzo Dev <[email protected]>
EVM Package
The EVM package implements the Luxd VM interface.
VM
The VM creates the Ethereum backend and provides basic block building, parsing, and retrieval logic to the consensus engine.
APIs
The VM creates APIs for the node through the function CreateHandlers(). CreateHandlers returns the Service struct to serve EVM specific APIs. Additionally, the Ethereum backend APIs are also returned at the /rpc extension.
Block Handling
The VM implements buildBlock, parseBlock, and getBlock and uses the chain package from Luxd to construct a metered state, which uses these functions to implement an efficient caching layer and maintain the required invariants for blocks that get returned to the consensus engine.
To do this, the VM uses a modified version of the Ethereum RLP block type here and uses the core package's BlockChain type here to handle the insertion and storage of blocks into the chain.
Block
The Block type implements the Luxd ChainVM Block interface. The key functions for this interface are Verify(), Accept(), Reject(), and Status().
The Block type wraps the stateless block type here and implements these functions to allow the consensus engine to verify blocks as valid, perform consensus, and mark them as accepted or rejected. See the documentation in Luxd for the more detailed VM invariants that are maintained here.