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.

Sign up for GitHub

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
Open

SEP: Split epoch id into fields and support independent key input #239

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions docs/SEP/sep-001-split-epoch-id-into-fields-and-support-independent-key-input.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# Shutter Enhancement Proposal: Split epoch id into fields and support independent key input

## Current state

Currently, the epoch id is a single field of size uint64 consisting of:
- 4 bytes (uint32): activation block number
- 4 bytes (uint32): epoch sequence number

This value is used both as an identifier as well as the input to generate the epoch keys.

## 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).


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.


## Rationale

During implementation of the Snapshot integration it became apparent that we need to support much larger ids (256 bit).
The current scheme of merging block and sequence number into a single field make it cumbersome to work with and also will not easily scale to large id values.

The current epoch id also is used as the key input as is.
This will not work with the snapshot use case since they don't know about activation block numbers and only use their id as the key input.
Therefore it is necessary to provide a separate field that will be used as the key input.
In traditional rolling shutter it will simply contain the same value as the current epoch id.
For snapshot it will only consist of the provided external id.