-
Notifications
You must be signed in to change notification settings - Fork 7
Contract changes for Stateless Batch Poster design #46
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
base: celestia-feat-stateless-batcher
Are you sure you want to change the base?
Contract changes for Stateless Batch Poster design #46
Conversation
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 think its good that we have the layer of abstraction between the verifier contracts for individual tees and the interface that the nodes/SequencerInbox interact with! I do have a couple questions though.
@param signature The signature of the user data | ||
@param userDataHash The hash of the user data | ||
*/ | ||
function verify(bytes memory signature, bytes32 userDataHash) external view { |
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.
How are we planning to extend this for future tee types?
I think this function might want to match on a teeType
argument to determine which verifier to check like the registerSigner function.
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.
ECDSA signature will be same across all Tee
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.
Yes but this contract will be responsible for checking multiple different potential sub contracts that could have the signer as a verified party correct? Like an instance EspressoTEEVerifier
should be capable of verifying with a EspressoSGXTEEVerifier
and a hypothetical EspressoNitroTEEVerifier
right?
…Systems/nitro-contracts into stateless-batcher-contract-changes
No description provided.