rolling-shutter icon indicating copy to clipboard operation
rolling-shutter copied to clipboard

Let the collator trigger a `EonPublicKey` resend

Open ezdac opened this issue 2 years ago • 0 comments

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.

ezdac avatar Jan 10 '23 14:01 ezdac