rolling-shutter
rolling-shutter copied to clipboard
Let the collator trigger a `EonPublicKey` resend
Introduction
Currently the EonPublicKeyBroadcast
contract is not in use and we don't seem to have agreed upon who should be the owner of that contract or how the public-keys should be transmitted to the contract.
Our sole communication-channel of eon public keys is the EonPublicKey
P2P message, that we decided was needed for
cheaply relaying eon public keys in a verifiable way to the users for encrypting transactions.
At the moment this is also the only mechanism for the collator to learn about new Eon Public keys.
Problem
The collator uses the eon public key among other things to verify incoming DecryptionKey
messages -
if there is no eon public key in the DB that corresponds to a received DecryptionKey
message, the message will be ignored and dropped:
https://github.com/shutter-network/rolling-shutter/blob/68ab6a0d51a6a0781831263a0217543b56eeb081/rolling-shutter/collator/epochhandling.go#L60-L63
This means that when the collator misses the one-time broadcast of the eon public key, it will never accept any decryption keys for that eon and thus stalls the whole system.
Solution
Introduce a EonPublicKeyRequest
message for the P2P network that allows the current collator
to trigger a re-broadcast of the most recent EonPublicKey
by the keypers.
message RequestEonPublicKey {
uint64 instanceID = 1;
uint64 activationBlock = 2;
uint64 keyperConfigIndex = 3;
uint64 eon = 4;
bytes signature = 5;
}
To prevent amplified spam attacks, the keypers should have a global throttling timeout that limits the frequency of resent messages.