…mp create-steel-app (#584)

- create-steel-app bumped to `release-2.1` branch
- minor changes to crates/steel/README.md

---------

Co-authored-by: Victor Graf <victor@risczero.com>

Co-authored-by: morgangibbs87 <133707571+morgangibbs87@users.noreply.github.com>

…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 <angelocapossele@gmail.com>
Co-authored-by: Wolfgang Welz <welzwo@gmail.com>

#604)

- **add contracts/script/verify-set-verifier.sh**
- **add set verifier 0.7 to deployment.toml**

Co-authored-by: Angelo Capossele <angelocapossele@gmail.com>