以太坊智能合约的存续、存储及状态变更记录机制技术问询

Great questions—these are core concepts for anyone working with Ethereum smart contracts, so let’s break them down clearly:

1. How do smart contracts persist on Ethereum (store data and support state changes)? #

When you deploy a smart contract, Ethereum creates a special contract account (distinct from externally owned accounts controlled by private keys). This account has two non-negotiable components:

• The contract’s compiled EVM bytecode, which gets permanently stored in the account’s code field once deployment is confirmed.
• A dedicated storage space (think of it as a contract-specific key-value database) to hold all state variables—like token balances, user preferences, or governance settings.

Ethereum’s full nodes maintain a global state tree that tracks every account on the network. Every time a transaction interacts with a contract and modifies its state, this global tree updates. As long as the Ethereum network is operational and full nodes are running, the contract’s bytecode and state persist—they’re part of the immutable blockchain history, with all state changes validated and replicated across every node in the network.

2. What’s the specific storage format for smart contracts in blocks? #

Contract state and account data are organized using a Merkle Patricia Tree—a specialized structure that makes verifying data integrity fast and efficient. Here’s the breakdown:

• Each contract account has its own unique storage tree. This tree uses 256-bit keys (called storage slots) and 256-bit values.
  • For simple variables (like uint256 public totalSupply), the slot index is determined by the variable’s order in the contract code (starting at 0).
  • For dynamic types (like mappings or arrays), the slot index is calculated with the keccak256 hash of the variable’s base slot plus the key (e.g., keccak256(uint256(slot) | uint256(key)) for mappings).
• The contract’s bytecode isn’t stored in this tree—it lives directly in the contract account’s code field.
• Every block header includes a state root: a single hash that acts as the fingerprint of the entire global state tree at that block height. This root lets anyone quickly verify if any account (including contracts) has been tampered with.

3. How does the blockchain record state changes when interacting with a smart contract? #

When you send a transaction to modify a contract’s state (like updating a user’s balance), here’s the step-by-step process:

1. Your transaction is broadcast to the network, containing the contract address, function call data, gas limit, and other necessary details.
2. A miner picks up the transaction and runs it in the EVM. Executing the contract’s bytecode will modify the relevant storage slots in the contract’s storage tree.
3. After processing all transactions in the block, the miner generates a new global state tree with the updated contract state, computes the new state root, and adds this root to the block header.
4. The completed block is sent to all nodes. Each node re-runs the transactions to confirm the state changes are valid, then updates their local copy of the state tree to match the new state root.
5. While state changes live in the storage tree, you can track them via transaction receipts (which include logs emitted by the contract using emit statements) and the block’s state root—any change to the contract’s state will result in a different state root than the previous block.

内容的提问来源于stack exchange，提问作者Jeff Hu