Add block builder tee proofs #236
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
fnerdman
force-pushed
the
add-block-builder-tee-proofs
branch
from
182e53a to
ecebf4e
Compare
|
Does this one go on top of #232 ? |
|
let's close this for now imo @fnerdman , when @avalonche starts implementing we can add this in |
| // 1. The caller is a registered address from an attested TEE | ||
| // 2. The TEE is running an approved block builder workload (via policy) | ||
|
|
||
| // Additional validation can be performed on the blockContentHash |
There was a problem hiding this comment.
What validation would this be? I can't think of anything useful we can do with a nonstandard hash like the one we have here. Solidity doesn't have retrospection so we can't look at the previous transactions to validate the blockContentHash onchain; all we can do is rely on the TEE to correctly compute this hash.
If we can't think of anything, can we remove this comment so it's not ambiguous what we mean here? That would simplify things for implementers
|
|
||
| ```solidity | ||
| // Block builder verification contract | ||
| function verifyBlockBuilderProof(bytes32 blockContentHash) external { |
There was a problem hiding this comment.
I think we should add a uint8 version argument here, so we can easily communicate the version of flashtestations this verification is meant for. Without this for example, if we later decide that we want to we want to change how the blockContentHash is calculated, then we'll have no way to communicate to offchain verifiers how to recompute the blockContentHash offchain.
The downside of this is that it will slightly increase L1 gas cost because of the additional calldata. But it's just a single 8-bit value, so it's very little.
|
|
||
| // Additional validation can be performed on the blockContentHash | ||
|
|
||
| emit BlockBuilderProofVerified( |
There was a problem hiding this comment.
we should add version here (see above comment)
| For rollup systems, this proof mechanism: | ||
|
|
||
| 1. Can be included as the final transaction in each block | ||
| 2. Enables L1 contracts to verify that blocks were built by authorized TEEs |
There was a problem hiding this comment.
Is this possible? L1 contracts do not have access to the EIP-4844 blobs that (see this explainer on EIP-4844 specifically the wording "Blobs are persisted in beacon nodes, not in execution layer").
If we want to expose this data to L1's, we'd need some way to bridge this transaction call to the L1. Maybe we want to do that, but it'll increase the gas cost of this (which we want to keep as cheap as possible).
I think we should remove this line for now, as it's not clear it's possible.
Adds a section on how flashtestations will be used as block proofs. not sure if we should add. Pros: adds to the bigger picture, implementation is easy once we have flashtestations, so we could add it to the current cycle. Cons: somewhat diverts from the path of trying to present a spec that can universally and transparently track attestations and their TTL.
Don't merge for now, needs feedback.