Skip to content

Allow zero safeBlockHash and finalizedBlockHash after finalization #760

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.

Sign up for GitHub

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

Open
dapplion wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Allow zero safeBlockHash and finalizedBlockHash after finalization #760

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions src/engine/paris.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ This structure encapsulates the fork choice state. The fields are encoded as fol
- `safeBlockHash`: `DATA`, 32 Bytes - the "safe" block hash of the canonical chain under certain synchrony and honesty assumptions. This value **MUST** be either equal to or an ancestor of `headBlockHash`
- `finalizedBlockHash`: `DATA`, 32 Bytes - block hash of the most recent finalized block

*Note:* `safeBlockHash` and `finalizedBlockHash` fields are allowed to have `0x0000000000000000000000000000000000000000000000000000000000000000` value unless transition block is finalized.
*Note:* `safeBlockHash` and `finalizedBlockHash` fields are allowed to have `0x0000000000000000000000000000000000000000000000000000000000000000` value. When set to zero, the client **MUST** default to the latest known value for the corresponding field, or the genesis block hash if no value is known.
Copy link
Copy Markdown
Contributor

@mkalinin mkalinin Mar 6, 2026

Choose a reason for hiding this comment

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

The safeBlockHash with FCR implementation may point to an already unsafe block on the EL side. In this case EL should rather revert it to finalizedBlockHash

Copy link
Copy Markdown
Member Author

@dapplion dapplion Mar 9, 2026

Choose a reason for hiding this comment

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

How would you phrase that?

Copy link
Copy Markdown
Contributor

@mkalinin mkalinin Mar 9, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Suggested change
*Note:* `safeBlockHash` and `finalizedBlockHash` fields are allowed to have `0x0000000000000000000000000000000000000000000000000000000000000000` value. When set to zero, the client **MUST** default to the latest known value for the corresponding field, or the genesis block hash if no value is known.
*Note:* `safeBlockHash` and `finalizedBlockHash` fields are allowed to have `0x0000000000000000000000000000000000000000000000000000000000000000` value. When set to zero, the client **MUST** default both values to the latest known `finalizedBlockHash` value, or the genesis block hash if no `finalizedBlockHash` value is known.

Will the above work?

Copy link
Copy Markdown
Contributor

@mkalinin mkalinin Mar 9, 2026

Choose a reason for hiding this comment

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

I think we should make this an explicit statement in the fcU spec below to aid visibility.

Copy link
Copy Markdown
Member

@jochem-brouwer jochem-brouwer Apr 9, 2026

Choose a reason for hiding this comment

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

I think the zero case is especially important for the transition period, changing this now is possible since we have transitioned, but it does not feel very "clean" to "change" the behavior at the transition. I also realize that not being backwards compatible should not be a big problem (assume chains have already transitioned or new chains start in PoS mode) so not a super strong opinion here, but one suggestion:

How about adding this rule to forkchoiceUpdatedV2 and all FcUs after, instead of forkchoiceUpdatedV1? This would keep the "old" behavior and ship new behavior to a fork after the transition.

Copy link
Copy Markdown
Contributor

@mkalinin mkalinin Apr 20, 2026

Choose a reason for hiding this comment

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

I think that zero hash would work for both situations:

  • When transition block isn’t yet finalized, there is yet no known finalized block on EL side and it’s fine to mark genesis block as final
  • When there is already a finalized block, EL will stick with it unless a non-zero hash comes from the CL side


### PayloadAttributesV1

Expand Down Expand Up @@ -216,11 +216,11 @@ The payload build process is specified as follows:

4. Before updating the forkchoice state, client software **MUST** ensure the validity of the payload referenced by `forkchoiceState.headBlockHash`, and **MAY** validate the payload while processing the call. The validation process is specified in the [Payload validation](#payload-validation) section. If the validation process fails, client software **MUST NOT** update the forkchoice state and **MUST NOT** begin a payload build process.

5. Client software **MUST** update its forkchoice state if payloads referenced by `forkchoiceState.headBlockHash` and `forkchoiceState.finalizedBlockHash` are `VALID`. The update is specified as follows:
5. Client software **MUST** update its forkchoice state if payloads referenced by `forkchoiceState.headBlockHash` and `forkchoiceState.finalizedBlockHash` are `VALID`. If `forkchoiceState.finalizedBlockHash` is zero, the client **MUST** use the latest known finalized block hash for this update. The update is specified as follows:
* The values `(forkchoiceState.headBlockHash, forkchoiceState.finalizedBlockHash)` of this method call map on the `POS_FORKCHOICE_UPDATED` event of [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675#block-validity) and **MUST** be processed according to the specification defined in the EIP
* All updates to the forkchoice state resulting from this call **MUST** be made atomically.

6. Client software **MUST** return `-38002: Invalid forkchoice state` error if the payload referenced by `forkchoiceState.headBlockHash` is `VALID` and a payload referenced by either `forkchoiceState.finalizedBlockHash` or `forkchoiceState.safeBlockHash` does not belong to the chain defined by `forkchoiceState.headBlockHash`.
6. Client software **MUST** return `-38002: Invalid forkchoice state` error if the payload referenced by `forkchoiceState.headBlockHash` is `VALID` and a **non-zero** payload referenced by either `forkchoiceState.finalizedBlockHash` or `forkchoiceState.safeBlockHash` does not belong to the chain defined by `forkchoiceState.headBlockHash`.
Comment thread
mkalinin marked this conversation as resolved.

7. Client software **MUST** process provided `payloadAttributes` after successfully applying the `forkchoiceState` and only if the payload referenced by `forkchoiceState.headBlockHash` is `VALID`. The processing flow is as follows:

Expand Down
Loading