Skip to content

Conversation

@nategraf
Copy link
Contributor

@nategraf nategraf commented Jun 4, 2025

@nategraf nategraf requested a review from a team as a code owner June 4, 2025 19:32
@nategraf
Copy link
Contributor Author

nategraf commented Jun 4, 2025

Note that this PR should be added to the release branch with the rebase action to preserve commit history

@nategraf nategraf force-pushed the victor/release-2.1-cherry-pick branch from e6f2325 to 5a13374 Compare June 7, 2025 00:48
nategraf and others added 8 commits June 6, 2025 17:55
…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]>
#604)

- **add contracts/script/verify-set-verifier.sh**
- **add set verifier 0.7 to deployment.toml**
@nategraf nategraf force-pushed the victor/release-2.1-cherry-pick branch from 5a13374 to ce54885 Compare June 7, 2025 00:57
@nategraf nategraf mentioned this pull request Jun 7, 2025
@nategraf nategraf enabled auto-merge (rebase) June 7, 2025 01:00
@nategraf nategraf merged commit ea13061 into release-2.1 Jun 7, 2025
8 of 10 checks passed
@nategraf nategraf deleted the victor/release-2.1-cherry-pick branch June 7, 2025 01:03
@nategraf nategraf changed the title Cherry-pick changes from main to rlease 2.1 branch for 2.1.1 release Cherry-pick changes from main to release 2.1 branch for 2.1.1 release Jun 9, 2025
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

Successfully merging this pull request may close these issues.

4 participants