Update Shutter spec (#50)

* Clarify keyper chain watching

* Trigger decryption key generation by new blocks

This also clarifies that decryption key for slot s is generated in slot
`s - 1`.

* Update decryption key shares message format

To improve compatibility with other Shutter implementations, the gnosis
specific message fields are moved to an optional field `extra`.

Field indices are a bit random for historical reasons. We might clean
this up in the future.

* Update decryption keys message format

To improve compatibility with other Shutter implementations, the gnosis
specific message fields are moved to an optional field `extra`.

* Fix compute_identity input argument

The sender is taken from the `TransactionSubmitted` event, not the keys
message.

* Remove decryption progress sharing via contract

This was meant to simplify recovery if many keypers go down at the same
time. However, it is very inefficient. In the current implementation,
this mechanism is not used in favor of a different recovery mechanism.
This mechanism will be added to the spec in the future.

* Add txIndex to TransactionSubmitted event

This may help the validator fetching specific events without syncing the
chain history.

* Choose transactions by index

Previously, the validator was expected to choose encrypted transactions
by their identity preimage. This is problematic for two reasons:

- the identity preimage is not necessarily unique
- the validator has to sync the full chain history in order to be able
  to do this

Now, the validator is supposed to fetch the events in a tx index range,
given by the keys' message tx pointer and the number of keys in that
message.

* Add dummy key

The dummy key ensures keypers generate at least one key per slot with
registered validator, even if there are no transactions scheduled. This
does not interfer with anything, but it allows monitoring key generation
works even if no one uses the system.

* Specify tx pointer recovery

The tx pointer records the current state of transaction execution or in
other words the next transaction the system is supposed to execute.
Ideally, this value would be tracked by the chain itself, but this would
require a chain fork. Instead, we have to rely on consensus among the
keypers.

In practice, under normal conditions, the keypers use the txPointer in
`DecryptionKeys` messages as canonical (note that in order to be valid,
these messages need to be signed off by at least a threshold of the
keypers). However, if no such message is received for a long time, key
generation must be failing. This might be due to keypers not agreeing on
the txPointer. In order to recover from this failure, the keypers reset
the txPointer to the number of encrypted transactions in the queue,
i.e., they jump to the end (because this is the easiest value to agree
on without communication).

Keypers should do this when key generation has been failing for some
time. What "some time" means is left to the keypers to decide. It is a
tradeoff between quick recovery and poor UX due to skipped transactions.

Note that this automatically contains a retry mechanism: If key
production is failing, no decryption keys messages will be received, so
they also will not update the tx pointer.

* Fix high level spec

* Define explicit key broadcaster

Previously, the keyper set contract had to broadcast the eon key. Now,
the keyper set contract defines a predicate that says if an account is
allowed to broadcast or not. This allows them to outsource key
broadcasting to a dedicated contract.

* Specify gossipsub topic names

shutter/high-level.md

@@ -28,7 +28,7 @@ Validators can opt into participating in the protocol by registering in the _val
 
 Instead of sending a transaction in plaintext, users may encrypt it. The encrypted blob has to be annotated with the transaction hash, the gas limit, and the current eon. The resulting tuple is wrapped in an envelope transaction that submits it to the _sequencer contract_. Users can also encrypt "bundles" of transactions all at once.
 
-The encryption function takes the eon key and an identity value as parameters. The identity value is derived from the transaction hash and the sender address of the envelope transaction. Note that the identity value can be reconstructed from the envelope transaction, but cannot be forged without control over the sender account.
+The encryption function takes the eon key and an identity value as parameters. The identity value is derived from a user defined random value and the sender address of the envelope transaction. Note that the identity value can be reconstructed from the envelope transaction, but cannot be forged without control over the sender account.
 
 The sequencer contract manages a set of transaction queues, one for each eon. Upon submission, encrypted transactions are appended to the end of the queue corresponding to the given eon. Submitting a transaction requires burning the specified amount of gas at the current base fee price.