-
Notifications
You must be signed in to change notification settings - Fork 29
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
WEB3-213: add SteelVerifier
to verify Steel commitments in the guest
#319
base: main
Are you sure you want to change the base?
Conversation
Verifier
to verify Steel commitments in the guestVerifier
to verify Steel commitments in the guest
Verifier
to verify Steel commitments in the guestSteelVerifier
to verify Steel commitments in the guest
Need to clean-up the way preflight is factored on the host |
Extend the token-stats example to use two sample points with only a single commitment.
This reverts commit 157a96d.
/// Implement [BlockHeaderCommit] for the unit type. | ||
/// This makes it possible to treat an `HostEvmEnv<D, H, ()>`, which is used for the [BlockInput] | ||
/// in the same way as any other `HostEvmEnv<D, H, BlockHeaderCommit>`. | ||
impl<H: EvmBlockHeader> BlockHeaderCommit<H> for () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels very strange to implement a trait for an empty tuple, but here it could actually be kind of intuitive...
|
||
impl<D, H: EvmBlockHeader, C: Clone + BlockHeaderCommit<H>> HostEvmEnv<D, H, C> { | ||
/// Returns the [Commitment] used to validate the environment. | ||
pub fn commitment(&self) -> Commitment { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like that the corresponding commitment(&self)
method on a GuestEvmEnv
returns &Commitment, but I don't know how to fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I think this is alright. In most cases, I don't think devs will even notice.
/// Implement [BlockHeaderCommit] for the unit type. | ||
/// This makes it possible to treat an `HostEvmEnv<D, H, ()>`, which is used for the [BlockInput] | ||
/// in the same way as any other `HostEvmEnv<D, H, BlockHeaderCommit>`. | ||
impl<H: EvmBlockHeader> BlockHeaderCommit<H> for () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could use the following empty-type instead of unit-type. This is more clear and explicit, but I think implementing it on ()
also makes sense. Up to you.
/// Implement [BlockHeaderCommit] for the unit type. | |
/// This makes it possible to treat an `HostEvmEnv<D, H, ()>`, which is used for the [BlockInput] | |
/// in the same way as any other `HostEvmEnv<D, H, BlockHeaderCommit>`. | |
impl<H: EvmBlockHeader> BlockHeaderCommit<H> for () { | |
struct DirectCommit; | |
/// Implement [BlockHeaderCommit] for the unit type. | |
/// This makes it possible to treat an `HostEvmEnv<D, H, DirectCommit>`, which is used for the [BlockInput] | |
/// in the same way as any other `HostEvmEnv<D, H, BlockHeaderCommit>`. | |
impl<H: EvmBlockHeader> BlockHeaderCommit<H> for DirectCommit { |
|
||
impl<D, H: EvmBlockHeader, C: Clone + BlockHeaderCommit<H>> HostEvmEnv<D, H, C> { | ||
/// Returns the [Commitment] used to validate the environment. | ||
pub fn commitment(&self) -> Commitment { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I think this is alright. In most cases, I don't think devs will even notice.
let block_number: u64 = block_number.saturating_to(); | ||
let diff = header.number().saturating_sub(block_number); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this should be try_into
and checked_sub
. I suppose these cases would be caught be the subsequent checks (e.g. there is no block hash in the DB for a future block number) but it seems prudent to exist early here IMO.
let block_number: u64 = block_number.saturating_to(); | |
let diff = header.number().saturating_sub(block_number); | |
let block_number: u64 = block_number.try_into().context("invalid block number >= 2^64")?; | |
let diff = header.number().checked_sub(block_number).context("block number is greater than header block number")?; |
Co-authored-by: Victor Snyder-Graf <[email protected]>
This PR introduces the
SteelVerifier
, which acts as a built-in SteelContract
to verify Steel commitments. It is used like any otherContract
, during the preflight step and in the guest. This functionality is currently marked unstable and must be enabled using theunstable-verifier
feature.The `TokenStats' example has been updated to use the verifier to sample the stats over two datapoints at different times.