Execution
Inside the EVM state transition: pre-checks, gas accounting, opcodes, precompiles, and receipts.
Third-party documentation. This is independently authored analysis of the public Go Ethereum (Geth) codebase — not the official docs, and not reviewed or endorsed by the Go Ethereum (Geth) team.
Execution
The heart of Geth is deterministic transaction execution: given a block and a starting state, every honest client must reach the identical ending state root. The code that guarantees this lives in the state processor and the EVM packages.
Pre-execution checks
Before any opcode runs, each transaction is validated structurally (signature recovery, nonce vs. account, chain id) and economically: the sender must cover gasLimit × gasFeeCap, plus value. EIP-1559 ordering rules are enforced here — base fee burns, priority tips flow to the proposer within caps.
The state transition loop
Transactions apply in block order against a working state copy. For each one: buy gas upfront, increment sender nonce, then execute calldata through the EVM interpreter — contract creation if to is empty, message call otherwise. Refund unused gas at the end; revert restores the working state but still charges consumed gas.
Opcodes and precompiles
The interpreter dispatches ~150 opcodes across environment reads, arithmetic, memory/stack ops, calls/creates, and logging. Fixed-function precompiles (ecrecover, sha256, modexp, pairing checks, and later the point-evaluation precompile) live at reserved addresses and implement heavy crypto in native Go.
Receipts and logs
Every executed transaction produces a receipt: status, cumulative gas, bloom filter over its logs, and the log entries themselves (address, topics, data). Receipts never affect consensus state directly — they exist for light verification and for the log queries dApps depend on.