-
Notifications
You must be signed in to change notification settings - Fork 39
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
Protocol: attest against EnclaveID rather than HostID #1831
Changes from 4 commits
c72f0d3
8a48857
0a4f5d1
0e2435a
5547758
b81c6c0
f86989a
c83b11d
2325b7d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -128,8 +128,8 @@ func (b *BatchHeader) UnmarshalJSON(data []byte) error { | |
// RollupHeader is a public / plaintext struct that holds common properties of rollups. | ||
// All these fields are processed by the Management contract | ||
type RollupHeader struct { | ||
Coinbase common.Address | ||
CompressionL1Head L1BlockHash // the l1 block that the sequencer considers canonical at the time when this rollup is created | ||
EnclaveID common.Address // the enclave that signed the rollup | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do we need the enclaveId here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah agree this doesn't seem quite right. My understanding (or rather chatGPT's understanding 😅) is that having the R and S signature values and the original hash isn't enough to derive the public key. If we had the signature bytes (the format with a 'recoveryID' extra byte on the end) we would be able to recover it. Should we be including that in the header instead of just the R and S maybe? |
||
CompressionL1Head L1BlockHash // the l1 block that the sequencer considers canonical at the time when this rollup is created | ||
|
||
CrossChainMessages []MessageBus.StructsCrossChainMessage `json:"crossChainMessages"` | ||
|
||
|
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.
We have been storing the full attestation report in the contract state, but it's not read at the moment. The enclave gets the data from the transaction calldata currently.
Are there reasons it's a good idea to store these attestation reports on the L1?
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 it's a vestige from the time we were planning to perform the verification on-chain.
Can be removed