You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I expect the documentation, go-ethereum, and core-geth to align in their
description and implementation of eth_getBlockByNumber("pending", [true|false]).
Currently I believe there is no complete agreement (neither between docs nor clients).
I will attempt to describe the divergences.
nonce
Should be null. This value depends on the PoW solution, which is obviously not yet available.
Docs: Should be NULL.
core-geth: Is omitted. Incorrect.
go-ethereum: Is null. OK.
mixHash
Should be null or zero-value. This value depends on the PoW solution, which is obviously not yet available.
Docs: Missing entirely.
core-geth: Zero-value. OK.
go-ethereum: Filled. Incorrect.
number
Should not be null. Should be "latest" + 1.
Docs: Should be NULL. Incorrect.
core-geth: Is filled. OK.
go-ethereum: Is filled. OK.
hash
Should be null. Block cannot be hashed until all other fields are finalized.
Docs: Should be NULL. OK.
core-geth: Is omitted. Incorrect.
go-ethereum: Is null. OK.
miner
Should be null. Miner is not yet known.
Docs: Should be filled. Incorrect.
core-geth: Is omitted. Incorrect.
go-ethereum: Is null. OK.
totalDifficulty
Should not be null. Total difficulty is the inclusive cumulative sum of difficulty values where the difficulty for block n+1 is defined by block n.EDIT: Although the value can always be calculated for all RPC-possible blocks, at ethereum/go-ethereum it is filled when returning Header methods and non-Uncle methods (that is, blocks with transactions).
The API logic here fills this value only when inclTxs=true, which is false for Uncle methods.
Docs: Should be filled. OK, but inaccurate (does not describe pending case).
core-geth: Is null.
go-ethereum: Is null.
logsBloom
Should not be null. If the receiptsRoot is available, then logsBloom should be provided by the same assumptions.
System information
OS & Version: Linux
Commit hash : a7e6418
Expected behaviour
I expect the documentation, go-ethereum, and core-geth to align in their
description and implementation of
eth_getBlockByNumber("pending", [true|false])
.The ETH docs I'm looking at (and citing) are here: https://eth.wiki/json-rpc/API.
CoreGeth docs are here: https://etclabscore.github.io/core-geth/JSON-RPC-API/modules/eth/#eth_getblockbynumber.
Rel #332
Actual behaviour
Currently I believe there is no complete agreement (neither between docs nor clients).
I will attempt to describe the divergences.
nonce
null
. This value depends on the PoW solution, which is obviously not yet available.NULL
.null
. OK.mixHash
null
or zero-value. This value depends on the PoW solution, which is obviously not yet available.number
null
. Should be "latest" + 1.NULL
. Incorrect.hash
null
. Block cannot be hashed until all other fields are finalized.NULL
. OK.null
. OK.miner
null
. Miner is not yet known.null
. OK.totalDifficulty
Should not beEDIT: Although the value can always be calculated for all RPC-possible blocks, at ethereum/go-ethereum it is filled when returningnull
. Total difficulty is the inclusive cumulative sum ofdifficulty
values where thedifficulty
for block n+1 is defined by block n.Header
methods and non-Uncle
methods (that is, blocks with transactions).null
.null
.logsBloom
null
. If thereceiptsRoot
is available, thenlogsBloom
should be provided by the same assumptions.null
. Incorrect.0x0000...
. OK.0xd8a54...
. OK.Backtrace
core-geth example response.
go-ethereum example response.
The text was updated successfully, but these errors were encountered: