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

Extend validator guide with concrete validations a beacon node should perform for builder blocks #31

Open
ralexstokes opened this issue Jun 13, 2022 · 1 comment

Comments

@ralexstokes
Copy link
Member

A builder provides an ExecutionPayloadHeader when offering bids to a given proposer.

The proposer (and specifically the local beacon node the proposer is running) should check the header against their local execution state to ensure the header is not inaccurate or even malicious.

We should specify the set of validations that should be performed in the validator guide.

@staccDOTsol
Copy link

Absolutely, ensuring the integrity and accuracy of the ExecutionPayloadHeader is crucial for the security of the Ethereum network. Here are some concrete validations that a beacon node should perform when processing builder blocks:

  1. Signature Verification: The beacon node should verify the signature of the ExecutionPayloadHeader to ensure it was signed by the correct builder.

  2. Execution State Validation: The beacon node should compare the execution state referenced in the ExecutionPayloadHeader with its own local execution state. This includes checking the correctness of the execution environment, the account balances, and the contract code.

  3. Gas Limit Check: The beacon node should verify that the gas limit specified in the ExecutionPayloadHeader is within the acceptable range defined by the network protocol. This prevents excessive gas consumption and potential denial-of-service attacks.

  4. Timestamp Validation: The beacon node should check the timestamp in the ExecutionPayloadHeader to ensure it falls within an acceptable range. This prevents the inclusion of outdated or future-dated execution payloads.

  5. Nonce Verification: The beacon node should validate the nonce of the ExecutionPayloadHeader to ensure it is correctly incremented. This prevents replay attacks and ensures the freshness of the execution payload.

  6. Consensus Rules Compliance: The beacon node should enforce the consensus rules defined by the Ethereum protocol. This includes checking for any protocol-specific requirements or restrictions on the execution payload.

By performing these validations, a beacon node can ensure the integrity and correctness of the builder blocks it processes, contributing to the overall security and stability of the Ethereum network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@ralexstokes @staccDOTsol and others