-
Notifications
You must be signed in to change notification settings - Fork 9
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
SEP: Split epoch id into fields and support independent key input #239
base: main
Are you sure you want to change the base?
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.
Regarding the format, I'm not sure if we should start a "SEP" process for now. The protocol is still very much in flux anyways, so documents that simply describe the current state make more sense IMO.
## Proposal | ||
|
||
- Split activation block and sequence id into separate fields. | ||
- Add a key source field (name TBD) |
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 suggest to stick with calling it epoch id
or decryption key id
.
What size should it be?
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 suggest to stick with calling it epoch id or decryption key id.
Jannik and I discussed this in person and for now settled on encryption key id
.
What size should it be?
For the protobuf messages it doesn't matter since bytes
fields aren't size limited.
But since we need to store this in the DB as well 32 Byte should be good for now (basically so it fits any 265 Bit hash).
This needs confirmation with Snapshot since they also have legacy Ids that are IPFS content ids (which don't have a specific fixed length).
- Split activation block and sequence id into separate fields. | ||
- Add a key source field (name TBD) | ||
|
||
The collator needs to ensure that the key source field never accepts duplicate values. |
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 should write something about message validity and/or slashing conditions for rolling shutter. I.e., messages are only valid if the epoch id is correctly derived from sequence number and activation block number. Collators can be slashed if they don't match.
No description provided.