Update Shutter spec #50
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This also clarifies that decryption key for slot s is generated in slot `s - 1`.
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.
To improve compatibility with other Shutter implementations, the gnosis specific message fields are moved to an optional field `extra`.
The sender is taken from the `TransactionSubmitted` event, not the keys message.
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.
This may help the validator fetching specific events without syncing the chain history.
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.
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.
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.
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.
dapplion
reviewed
Aug 26, 2024
dapplion
approved these changes
Aug 28, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current version of the spec is outdated relative to what's live on the network right now. This PR aligns the two versions. See the commit messages for descriptions of the individual changes.