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

Mithril Client fail to validate certificate chain if the previous certificate is more than one epoch older #377

Closed
Alenar opened this issue Jul 28, 2022 · 2 comments
Assignees

Comments

@Alenar
Copy link
Collaborator

Alenar commented Jul 28, 2022

Issue

The Certificate Chain breaks when one Epoch does not have any associated Certificate.
⚠ We need to talk with the research team to find out if it is a bug or not

@jpraynaud
Copy link
Member

jpraynaud commented Aug 4, 2022

Possible Recovery Solutions

  • Using a higher Epoch Offset and embedding in the signed message multiple Next AVKs. This solution could work, but would be cumbersome (as the Signers would have to wait more epochs before being able to sign, for example 3 instead of 2)
  • Use the Aggregator Beacon to orchestrate certificate creation for an epoch at a later epoch when the network is back up. This means that the Aggregator is in charge of broadcasting the epoch to be used by the Signers to individually sign, and is verifying if there is a gap. This solution is likely to be the most simple to deploy, but it might not cover all of the cases that would lead to an epoch gap in the chain (for example if the Signers were not able to gather Stake Distribution for previous Epochs on their end)
  • In a multiple Aggregator network, if an Aggregator misses an epoch (due to networking or operations trouble), it should be able to recover the chain by retrieving from any other up to date aggregator
  • A last option to recover from such an Epoch gap would be to re-genesis the chain (this will always work, but it will be hard to operate and should be reserved to emergency situations)

@jpraynaud
Copy link
Member

Next Steps

We will review the recovery strategies with the research team to validate if we should implement one of them (and which one)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants