Whenever a keyper set is finalized and added to the KeyperSetManager listening clients want to use the information of the keyper set (member addresses, threshold, activation block number) to schedule the activation of a new keyper set and use a different eon public key.

Currently the event only emits information that links to the keyper-set contract.
However upon receiving this event, clients have to read multiple fields of that contract in order to acquire the needed information. This results in multiple eth_call JSON-RPC calls before all information has been gathered.

@fredo Is it possible and would it make sense to add the following information from the KeyperSet and the KeyperSetManager contract?

• Members
• Threshold
• result of KeyperSetIndexByBlock(activationBlock)

The sequencer system address which is able to pause shutter is predefined by the shutter code base.
We can pass this address in the constructor to automatically set the pauser and sequencer role.

The inbox contract will receive encrypted transactions by the users. From this place the reveal tx type will pick up txs encrypted for the current block, decrypt and execute them and clear the storage.

The contract has the following interface

interface IInbox {
    function submitEncryptedTransaction(
        uint64 eon,
        uint64 blockNumber,
        bytes memory encryptedTransaction,
        uint256 gasLimit
    ) external payable;

   
    // PSEUDO
    function getTransactions(uint64 blockNumber) external view;

    function clear() external;

    function withdraw() external;

When scheduling a new keyper set, the only condition for the activation slot is to be greater or equal than the latest keyper set.
However, this allows activation slots to be in the past.

From a logical perspective this doesn't make sense, cause we are scheduling a keyper set for blocks which are already finalized. Furthermore, the state of the contracts and the chain will look weird, cause the contract state which set should have been used and the actual eon key used for a given block might differ.
In order to unwind this, one would have to know when the latest keyper set was scheduled and that it was scheduled to past blocks.
I don't see that the liveness would be attacked in this scenario, but I also really don't see a benefit of allowing such a behavior. Effectively, what would happen is, that the keyper set would be active from the next block on (because past blocks are already created), which would be the same if we would just schedule it for the next block.

The default AdminRole should be set by the constructor. Affected contracts are Inbox and KeyperSetManager