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

System upgrade handling #133

Open
Shadowfiend opened this issue May 30, 2018 · 0 comments
Open

System upgrade handling #133

Shadowfiend opened this issue May 30, 2018 · 0 comments
Labels
📝 yellowpaper Items or info to be captured in the yellowpaper.

Comments

@Shadowfiend
Copy link
Contributor

Some of the questions this issue can track (until we break it down further, if needed):

  • What conditions trigger a “hard fork”-style whole-system upgrade?
  • What does a whole-system upgrade consist of? e.g., what happens to the relay and its relay groups? [1] What happens to keeps?
  • What do softer upgrades look like (e.g., client upgrades)?

[1]- One concrete question for the relay is, say we want to change the curve on which we run BLS key generation and signing. How do we manage this? In particular, do we require all active relay groups to regenerate their keys post-upgrade? Do we support two curves in parallel? Do we drop all groups and restart the relay? Working out some of the implications of these decisions would be good. Several of them will likely apply to other places as well (e.g., Threshold ECDSA likely will have similar questions about crypto upgrades).

@Shadowfiend Shadowfiend added the 📝 yellowpaper Items or info to be captured in the yellowpaper. label May 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📝 yellowpaper Items or info to be captured in the yellowpaper.
Projects
None yet
Development

No branches or pull requests

1 participant