WEB3-458: Update the Steel beacon block commit validation to always revert on invalid timestamps #605
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
changed the title
capossele
approved these changes
May 30, 2025
Co-authored-by: Angelo Capossele <[email protected]>
Co-authored-by: Angelo Capossele <[email protected]>
nategraf
added a commit
that referenced
this pull request
Jun 4, 2025
…evert on invalid timestamps (#605) On `main`, the `Beacon.parentBlockRoot(uint256 timestamp)` function returns zero bytes if the timestamp given is invalid. This allows the `Steel.validateCommitment` to return true if given a commitment suchas `Commitment { id: Encoding.encodeVersionID(block.timestamp - 1, 1), bytes32(0), configID }` where the digest is zero and the timestamp is within the last ~24 hours but does not correspond to a valid block. This violates the semantics of `validateCommitment` in that this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. As a result, leveraging this bug to compromise the soundness of a program using Steel would require a separate bug or misuse of the Steel API. As a fix for this issue, this PR checks whether the EIP-4788 contract call reverts, and reverts with `InvalidBlockTimestamp` if so. We choose this error message as this is the only case in which the EIP-4788 contract will revert when called from the `Beacon` contract. With this, this PR removes the explicit check that the timestamp is recent, as it is redundant. As a drive-by change, this PR also drops the explicit check for the block number being too old when using execution block commitments. Instead, this checks the return value of the `blockhash` opcode, which will return zeroes if the block number is too old. This should not result in any change of behavior on Ethereum. --------- Co-authored-by: Angelo Capossele <[email protected]> Co-authored-by: Wolfgang Welz <[email protected]>
nategraf
added a commit
that referenced
this pull request
Jun 7, 2025
…evert on invalid timestamps (#605) On `main`, the `Beacon.parentBlockRoot(uint256 timestamp)` function returns zero bytes if the timestamp given is invalid. This allows the `Steel.validateCommitment` to return true if given a commitment suchas `Commitment { id: Encoding.encodeVersionID(block.timestamp - 1, 1), bytes32(0), configID }` where the digest is zero and the timestamp is within the last ~24 hours but does not correspond to a valid block. This violates the semantics of `validateCommitment` in that this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. As a result, leveraging this bug to compromise the soundness of a program using Steel would require a separate bug or misuse of the Steel API. As a fix for this issue, this PR checks whether the EIP-4788 contract call reverts, and reverts with `InvalidBlockTimestamp` if so. We choose this error message as this is the only case in which the EIP-4788 contract will revert when called from the `Beacon` contract. With this, this PR removes the explicit check that the timestamp is recent, as it is redundant. As a drive-by change, this PR also drops the explicit check for the block number being too old when using execution block commitments. Instead, this checks the return value of the `blockhash` opcode, which will return zeroes if the block number is too old. This should not result in any change of behavior on Ethereum. --------- Co-authored-by: Angelo Capossele <[email protected]> Co-authored-by: Wolfgang Welz <[email protected]>
nategraf
added a commit
that referenced
this pull request
Jun 7, 2025
…evert on invalid timestamps (#605) On `main`, the `Beacon.parentBlockRoot(uint256 timestamp)` function returns zero bytes if the timestamp given is invalid. This allows the `Steel.validateCommitment` to return true if given a commitment suchas `Commitment { id: Encoding.encodeVersionID(block.timestamp - 1, 1), bytes32(0), configID }` where the digest is zero and the timestamp is within the last ~24 hours but does not correspond to a valid block. This violates the semantics of `validateCommitment` in that this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. As a result, leveraging this bug to compromise the soundness of a program using Steel would require a separate bug or misuse of the Steel API. As a fix for this issue, this PR checks whether the EIP-4788 contract call reverts, and reverts with `InvalidBlockTimestamp` if so. We choose this error message as this is the only case in which the EIP-4788 contract will revert when called from the `Beacon` contract. With this, this PR removes the explicit check that the timestamp is recent, as it is redundant. As a drive-by change, this PR also drops the explicit check for the block number being too old when using execution block commitments. Instead, this checks the return value of the `blockhash` opcode, which will return zeroes if the block number is too old. This should not result in any change of behavior on Ethereum. --------- Co-authored-by: Angelo Capossele <[email protected]> Co-authored-by: Wolfgang Welz <[email protected]>
nategraf
added a commit
that referenced
this pull request
Jun 7, 2025
…evert on invalid timestamps (#605) On `main`, the `Beacon.parentBlockRoot(uint256 timestamp)` function returns zero bytes if the timestamp given is invalid. This allows the `Steel.validateCommitment` to return true if given a commitment suchas `Commitment { id: Encoding.encodeVersionID(block.timestamp - 1, 1), bytes32(0), configID }` where the digest is zero and the timestamp is within the last ~24 hours but does not correspond to a valid block. This violates the semantics of `validateCommitment` in that this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. As a result, leveraging this bug to compromise the soundness of a program using Steel would require a separate bug or misuse of the Steel API. As a fix for this issue, this PR checks whether the EIP-4788 contract call reverts, and reverts with `InvalidBlockTimestamp` if so. We choose this error message as this is the only case in which the EIP-4788 contract will revert when called from the `Beacon` contract. With this, this PR removes the explicit check that the timestamp is recent, as it is redundant. As a drive-by change, this PR also drops the explicit check for the block number being too old when using execution block commitments. Instead, this checks the return value of the `blockhash` opcode, which will return zeroes if the block number is too old. This should not result in any change of behavior on Ethereum. --------- Co-authored-by: Angelo Capossele <[email protected]> Co-authored-by: Wolfgang Welz <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On
main, theBeacon.parentBlockRoot(uint256 timestamp)function returns zero bytes if the timestamp given is invalid. This allows theSteel.validateCommitmentto return true if given a commitment suchasCommitment { id: Encoding.encodeVersionID(block.timestamp - 1, 1), bytes32(0), configID }where the digest is zero and the timestamp is within the last ~24 hours but does not correspond to a valid block.This violates the semantics of
validateCommitmentin that this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. As a result, leveraging this bug to compromise the soundness of a program using Steel would require a separate bug or misuse of the Steel API.As a fix for this issue, this PR checks whether the EIP-4788 contract call reverts, and reverts with
InvalidBlockTimestampif so. We choose this error message as this is the only case in which the EIP-4788 contract will revert when called from theBeaconcontract. With this, this PR removes the explicit check that the timestamp is recent, as it is redundant.As a drive-by change, this PR also drops the explicit check for the block number being too old when using execution block commitments. Instead, this checks the return value of the
blockhashopcode, which will return zeroes if the block number is too old. This should not result in any change of behavior on Ethereum.