Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add missing blockHeaderSchema properties #6243

Merged
merged 9 commits into from
Jul 19, 2023
7 changes: 6 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -1699,11 +1699,16 @@ If there are any bugs, improvements, optimizations or any new feature proposal f

## [Unreleased]

### Fixed

#### web3-utils

- BigInts pass validation within the method `numberToHex` (#6206)

#### web3-rpc-methods

- Rpc method `getPastLogs` accept blockHash as a parameter https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getlogs (#6181)
- Rpc method `getPastLogs` accept blockHash as a parameter https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getlogs (#6181)

#### web3-eth

- Missing `blockHeaderSchema` properties causing some properties to not appear in response of `newHeads` subscription (#6243)
4 changes: 4 additions & 0 deletions packages/web3-eth/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -156,3 +156,7 @@ Documentation:
- Dependencies updated

## [Unreleased]

### Fixed

- Missing `blockHeaderSchema` properties causing some properties to not appear in response of `newHeads` subscription (#6243)
62 changes: 61 additions & 1 deletion packages/web3-eth/src/schemas.ts
Original file line number Diff line number Diff line change
Expand Up @@ -321,13 +321,37 @@ export const blockSchema = {
},
};

export const withdrawalsSchema = {
type: 'object',
properties: {
index: {
format: 'uint',
},
validatorIndex: {
format: 'uint',
},
address: {
format: 'bytes32',
},
amount: {
format: 'uint',
},
},
};

export const blockHeaderSchema = {
type: 'object',
properties: {
author: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some of these fields are not aligned with EL specs, there can be possibilities:

  • EL specs not updated
  • geth specific fields

so could you add an integration test , so when we add more EL clients we can catch issue earlier.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jdevcs What EL spec are you looking at? I've been using this one and don't even see eth_subscribe listed

Regardless, these added fields don't exist on Geth's response, but are instead from Nethermind's. It's okay and actually necessary to have these fields in the blockHeaderSchema, because it's used to format responses. Meaning as is, any fields not mentioned in this schema will be dropped from the response before it's returned to the user. No error is caused if the fields are not present. This does, however, beg the question of how do we declare the BlockHeaderOutput type - do we include these properties as optional since they could be there if the connected RPC client uses them? Or do we only include the common ones as the type is declared now?

The extra fields included by Nethermind that don't seem to be available using Geth:

  • author
  • totalDifficulty
  • size
  • excessDataGas
  • mixHash
  • transactions
  • uncles
  • withdrawals

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasnt able to find author field in EL Specs https://github.com/ethereum/execution-apis/blob/4da6a02f094d9d8c826272f6ceac2d751866f132/src/schemas/block.yaml#L22 in block schema at first place, and later there is no eth_subscribe in EL specs ( as you found as well in specs doc).

If we include integration tests ( we will need to have a check for Nethermind in tests and expect that these additional fields are present), if its breaking in future for Nethermind we will be able to detect. Currently we dnt have NM, so it can be skipped.

This does, however, beg the question of how do we declare the BlockHeaderOutput type - do we include these properties as optional since they could be there if the connected RPC client uses them? Or do we only include the common ones as the type is declared now?

I'll suggest lets have additional types as optional and add doc comments that these are specific for NM.

format: 'bytes32',
},
hash: {
format: 'bytes32',
},
parentHash: {
format: 'bytes32',
},
receiptRoot: {
receiptsRoot: {
format: 'bytes32',
},
miner: {
Expand All @@ -339,12 +363,18 @@ export const blockHeaderSchema = {
transactionsRoot: {
format: 'bytes32',
},
withdrawalsRoot: {
format: 'bytes32',
},
logsBloom: {
format: 'bytes256',
},
difficulty: {
format: 'uint',
},
totalDifficulty: {
format: 'uint',
},
number: {
format: 'uint',
},
Expand All @@ -366,6 +396,36 @@ export const blockHeaderSchema = {
sha3Uncles: {
format: 'bytes32',
},
size: {
format: 'uint',
},
baseFeePerGas: {
format: 'uint',
},
excessDataGas: {
format: 'uint',
},
mixHash: {
format: 'bytes32',
},
transactions: {
type: 'array',
items: {
format: 'bytes32',
},
},
uncles: {
type: 'array',
items: {
format: 'bytes32',
},
},
withdrawals: {
type: 'array',
items: {
...withdrawalsSchema,
},
},
},
};

Expand Down