-
Notifications
You must be signed in to change notification settings - Fork 23
Description
Feature Overview
When signatures are being aggregated to perform an action on the bridge, the notary engine will emit the signature bundle as soon as it has received the threshold number of signatures. Say there are 9 validators and the threshold is 666 then the signauture bundle will contain 6 signature, which is sufficient.
This is a nice optimisation when the validator set is relatively static, but is a bit annoying if the validator set is changing a lot. For example during the sunsetting of Vega mainnet the validator set reduced quite quickly and we were in a position where we have 15 validaors on the contract, and 10 seen as validators in core.
What this meant is that any signature bundle would contain only 7 signature, but given there are 15 keys on the multisig this is under the threshold. If the notary engine instead created a bundle with all 10 signatures it would be above the threshold.
We should change the notary engine so that either (or both, or something else):
- calculate the threshold number of signatures based on the number of validators on the multisig, and emit a bundle only then
- if we have already submitted a bundle with the threshold number of signature, and another signature arrives, emit that too, it can't hurt.
Specs
- Link to spec or section within a spec
Tasks
A checklist of the tasks that are needed to develop the feature and meet the acceptance criteria and feature test scenarios.
- [ ]
- [ ]
Feature test scenarios
Detailed scenarios that can be executed as feature tests to verify that the feature has been implemented as expected.
GIVEN (setup/context)
WHEN (action)
THEN (assertion) For example...
See here for more format information and examples.
Additional Details (optional)
Any additional information that provides context or gives information that will help us develop the feature.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status