[Review] Re-add header fields with values used in Ethereum 2.0

[karlb]

Simple Summary

Add the fields ommers, ommersHash, nonce,difficulty and mixHash to Celo block headers with constant values.

Abstract

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.

Motivation

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

Specification

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.

Rationale

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.

Backwards Compatibility

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).

Test Cases

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

Implementation

• Add fields to Header struct
• Copy new fields in CopyHeader
• Set UncleHash field to rlpHash([]*Header(nil))
• Return new field in JSON-RPC via RPCMarshalHeader

Implementation suggestion at https://github.com/celo-org/celo-blockchain/compare/karlb/add-eth-header-fields?expand=1.

Security Considerations

No known security considerations.

License

This work is licensed under the Apache License, Version 2.0.