Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ulope
Copy link
Contributor

@ulope ulope commented Apr 1, 2022

No description provided.

Copy link
Contributor

@jannikluhn jannikluhn left a 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)
Copy link
Contributor

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?

Copy link
Contributor Author

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.
Copy link
Contributor

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.

@ezdac ezdac mentioned this pull request May 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants