Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Emit signatures for all validators not just enough for the threshold #11717

Open
wwestgarth opened this issue Sep 27, 2024 · 0 comments
Assignees
Labels
bridges feature new feature to be developed validators selection Validators joining and leaving by stake

Comments

@wwestgarth
Copy link
Contributor

wwestgarth commented Sep 27, 2024

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.

@wwestgarth wwestgarth added feature new feature to be developed validators selection Validators joining and leaving by stake bridges labels Sep 27, 2024
@wwestgarth wwestgarth self-assigned this Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bridges feature new feature to be developed validators selection Validators joining and leaving by stake
Projects
Status: No status
Development

No branches or pull requests

1 participant