Eon Key Distribution

The keypers infrequently generate eon keys. The eon keys need to be transmitted to two types of recipients:

• users, so that they can encrypt transactions
• decryptors, so that they can validate epoch secret keys, also generated by keypers

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:

1. Key broadcast contract
2. Shuttermint
3. P2P

Key broadcast contract

Keypers 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:

• no way to miss a key
• no way to publish keys for past epochs
• users and decryptors need to watch the chain anyways to get keyper identities and other configuration parameters

Cons:

• potentially costly on mainnet or rollups

Shuttermint

Keypers send signatures to the Shuttermint chain. Users and decryptors sync the chain and fetch key and signature from there.

Pros

• cheap
• no need for keypers to send another transaction
• signatures can be verified automatically

Cons

• users and decryptors need to sync another chain, which is problematic at least for users
• keypers might decide to switch to a different chain (e.g., in case keyper set transitioning is blocked), in which users and decryptors would need to find the new chain
• lots of overhead

P2P

Keypers 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

• cheap

Cons

• users and decryptors need to join the p2p network, which is problematic for users
• no hard guarantee that all keys are received (peers could withhold keys)

from rolling-shutter.

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

from rolling-shutter.