cip | title | author | discussions-to | status | type | category | created | license |
---|---|---|---|---|---|---|---|---|
59 |
Re-add header fields with values used in Ethereum 2.0 |
Karl Bartel (@karlb) |
Final |
Standards Track |
Ring 0 |
2023-03-22 |
Apache 2.0 |
Add the fields ommers
, ommersHash
, nonce
, difficulty
and mixHash
to Celo block headers with constant values.
Since Celo uses proof-of-stake, its block headers do not contain fields related to proof-of-work. When Ethereum switched from proof-of-work to proof-of-stake, it did not drop the related block header fields, but instead set them to constant values to preserve backwards compatibility (see EIP-3675).
Since Celo intends to keep a high level of Ethereum compatibility, these header fields should be added to Celo.
Reducing these differences to Ethereum helps in two ways:
- The more similar API (JSON-RPC) makes the life easier for application developers supporting both Ethereum and Celo
- The Celo-blockchain code can stay close to the Ethereum client’s implementation, thereby reducing maintenance work and allowing easier collaboration.
- Together with other CIPs, Celo's block header hash calculation can get mostly identical to Ethereum's, further increasing the compatibility
Add the following fields with constant values to the block header:
field name (https://eips.ethereum.org/EIPS/eip-3675#block-structure) | field name (geth/celo-blockchain) | JSON-RPC field | value |
---|---|---|---|
difficulty | Difficulty | difficulty | 0 |
nonce | Nonce | nonce | 0x0000000000000000 |
ommers | (only present in body) | uncles | [] |
ommersHash | UncleHash | sha3Uncles | 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 (Keccak256(RLP([]))) |
mixHash | MidDigest | mixHash | 0x0000000000000000000000000000000000000000000000000000000000000000 |
If GraphQL keys are added for these header fields, they must match the name used by upstream geth for the same field.
One additional field that is missing in Celo is the baseFee
, but in contrast to the fields above, it will not contain a constant value and deserves a more thorough discussion. Therefore, it will be handled in a separate CIP.
While the JSON-RPC fields are important for application compatibility, the case is less clear for the actual header fields in the blockchain implementation. Since the values are constant, we could return the values in the JSON-RPC without actually storing them in the block header.
The reason for including the values in the header is to reduce differences between the blockchain implementations between Ethereum and Celo.
Block header changes impact the consensus and require a hard fork.
Adding fields to the JSON-RPC should not break applications (unless they choke on new fields, which won’t be the case for well written applications).
The header changes can be inspected by querying the latest block header via JSON-RPC.
curl -X POST -H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest", true],"id":1}' \
$RPC_URL
- Add fields to
Header
struct - Copy new fields in
CopyHeader
- Set
UncleHash
field torlpHash([]*Header(nil))
- Return new field in JSON-RPC via
RPCMarshalHeader
See this PR.
No known security considerations.
This work is licensed under the Apache License, Version 2.0.