EIP-7910 The eth_config JSON-RPC method (eth_config JSON-RPC Method)
Final · Networking & nodes · EIP status Final · created 2025-03-18
Adds the eth_config RPC method, through which a node reports as JSON the configuration values of the fork currently active, the next fork, and the last configured fork. This allows checking in advance whether client configuration is correct before a hard fork.
Why it is needed
In Ethereum's history there have been several incidents where clients were not configured correctly for an upcoming hard fork (an upgrade that changes network rules all at once) and fell out of consensus at the fork point. Most were minor incidents amounting to a single client's blocks being discarded, but the Pectra activation on the Holešky testnet was different. Four of the network's six clients had the deposit contract address misconfigured, and rather than the incorrect chain being discarded, it was justified, leaving side effects even after finalization. Yet before a fork actually occurs, there has been no standard way to externally check whether each node is holding the correct configuration. This EIP lets nodes self-report key configuration values before a fork, so operations teams can compare responses across nodes and catch configuration errors in advance.
What changes
Today
- Whether a fork's configuration is correct cannot be checked in a standard way until the fork actually occurs
- Configuration file formats differ across clients, making it hard to compare nodes
- Configuration errors only surface as consensus failures once the fork boundary is crossed
After EIP-7910
- A single eth_config call returns the current, next, and last fork configuration as standard JSON
- Comparing responses across multiple nodes catches mismatches before the fork
- Checks items down to chain ID, precompiles, system contract addresses, and the blob schedule
Who is affected
- Node operators and validator teams: Before a fork, an automated check script can compare nodes' eth_config output to confirm readiness.
- Client development teams: The method must be implemented, and it can also be used to debug configuration mismatches.
- Network monitoring tools: Can cross-check nodes' responses against the known fork specification or against other nodes to detect anomalies.
- Peer nodes on the consensus layer (CL) side: Can automatically check the fork readiness of a paired execution client.
In depth
Method definition and response structure
eth_config is called with no parameters, and the response has three members: current, next, and last. These are, respectively, the currently active configuration, the next configuration, and the last known configuration; next and last are null if no future fork is configured. If the next fork is also soon to be the last fork, the two members hold the same configuration. Clients MUST expose this method on the standard JSON-RPC port and MAY also expose it via the Engine API. The response MUST include all configuration parameters defined by this EIP and MUST reflect the latest values as of the most recently supplied block header. If configuration is cached, the cache MUST be cleared when a fork boundary is crossed. Configuration objects MAY be used for internal per-fork configuration management, but raw, unprocessed configuration data SHOULD NOT be returned as is.
Fields of the configuration object
Each configuration object MUST include the following members in alphabetical order. activationTime records the fork's activation time as a JSON number of Unix epoch seconds (UTC); current uses the actual activation time, while next and last use the scheduled time, and forks activated at genesis use 0. blobSchedule is an object holding three numbers: baseFeeUpdateFraction, max, and target. chainId is a lowercase hexadecimal string with a 0x prefix, with leading zeros stripped; chains with no chain ID or a chain ID of 0 are not supported. forkId is the FORK_HASH value from EIP-6122, a lowercase hexadecimal string left-padded to 4 bytes. This specification assumes a post-Merge network and does not cover proof-of-work related matters. Future forks that want to add, change, or remove members must define this in the relevant EIP or meta EIP.
Full enumeration of precompiles and system contracts
precompiles is an object listing the precompile contracts active at a fork by name and 20-byte address (lowercase, leading zeros preserved). If a precompile is replaced by an on-chain contract or removed, it drops from the list, which also accommodates future discussions of precompile removal. Cancun's names are ECREC, SHA256, RIPEMD160, ID, MODEXP, BN254_ADD, BN254_MUL, BN254_PAIRING, BLAKE2F, and KZG_POINT_EVALUATION; Prague adds BLS12_G1ADD, BLS12_G1MSM, BLS12_G2ADD, BLS12_G2MSM, BLS12_PAIRING_CHECK, BLS12_MAP_FP_TO_G1, and BLS12_MAP_FP2_TO_G2; Osaka adds P256VERIFY. systemContracts is an object of system contract names and addresses, omitted for forks before Cancun. Cancun has just BEACON_ROOTS_ADDRESS, and Prague has BEACON_ROOTS_ADDRESS, CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, DEPOSIT_CONTRACT_ADDRESS, HISTORY_STORAGE_ADDRESS, and WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS. Future forks must define their system contract list in a meta EIP.
Handling Blob Parameter Only (BPO) forks
A BPO (Blob Parameter Only) fork, which changes only blob parameters, is also treated as a new fork. The new fork's configuration is built on top of the parent fork's configuration (recursing further back if the parent is itself a BPO fork), updating only the relevant values in the blobSchedule object. Accordingly, a BPO fork also appears as a complete configuration object in current and next, and operators can check whether a blob schedule change is configured correctly the same way as for any other fork.
Why return the full configuration with no hash
The initial design considered having next carry only the changed portion, but analysis of past incidents showed that parameters causing consensus splits, such as the deposit contract address, were sometimes introduced in an earlier fork and only caused problems later when a different EIP in a subsequent fork depended on that configuration. A partial configuration couldn't catch errors like this, so the full configuration was chosen instead. A configuration hash that was present in the early draft was also removed, both because there was disagreement over what data format to hash with (plain JSON, RLP, or SSZ) and because sorting object keys alphabetically lets tools compare the JSON directly, making a hash unnecessary. JSON was chosen as the format for its ubiquity, its readability for both humans and machines, and the existence of RFC-8785 as a standard canonical form. YAML has no standard canonical form, and no Ethereum software uses XML.
Backwards compatibility and security considerations
This EIP does not change existing behavior. Configurations from pre-Cancun forks are non-standard, so clients supporting those forks MAY return partial or non-standard configurations, while full compliance is REQUIRED only for post-Cancun forks. On the security side, a misconfiguration could expose operational information, so operators are advised to restrict eth_config to trusted interfaces such as local access or authenticated endpoints. Since a node could report a false configuration, monitoring tools can cross-check it against known fork specifications or other nodes' responses. To prevent resource exhaustion, the configuration object can be cached internally and request frequency can be rate-limited, with a minimum response interval (e.g., 1 second). This EIP's specification is finalized in Final status.