-
Notifications
You must be signed in to change notification settings - Fork 7
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
Figure out how decryptors will get the eon key #51
Comments
Eon Key DistributionThe keypers infrequently generate eon keys. The eon keys need to be transmitted to two types of recipients:
Each eon key is valid in a range of epochs. The start of the range is explicitly specified by the keypers. The end of the range is given by the start of the following eon key. The latest generated eon key is valid indefinitely until a newer eon key is generated. Eon keys are signed by a threshold majority of the keyper set. This allows nodes to verify that a received eon key is valid, no matter via which channel they got it, as long as they know the current keyper set. However, they cannot cryptographically verify that they received all eon keys (i.e., they might use an eon key in an epoch for which a newer eon key is available). Therefore, the eon key distribution mechanism should ensure that recipients are able to fetch all keys. We have multiple options with pros and cons:
Key broadcast contractKeypers submit the eon key, including the signature, to a contract on a blockchain. Users and decryptors fetch the key from the contract. The contract may verify the signature directly or the caller can do so off-chain. Pros:
Cons:
ShuttermintKeypers send signatures to the Shuttermint chain. Users and decryptors sync the chain and fetch key and signature from there. Pros
Cons
P2PKeypers broadcast the eon keys with signatures on a gossip network. Every node on the network (keypers, decryptors, collator, potentially users) stores them in their db. Nodes that join ask some or all of their peers for keys the know. Pros
Cons
|
During discussion, a fourth option came up: In Rolling Shutter, the collator can provide the eon keys to users. Nevertheless, we decided to go with the key broadcast contract because it's the most practical and most secure. If necessary, it would also work with (newer versions of) On-chain Shutter (useful if we decide to unify the implementations at some point). |
The decryptors need to know the eon keys so that they can validate that the epoch keys. Figure out how they get them and how they make sure they're valid/produced by the keypers.
The text was updated successfully, but these errors were encountered: