MIP - Hard Fork Automation #32
Conversation
|
|
||
| ### Core Mechanism | ||
|
|
||
| The solution introduces a `--hardfork-handling` flag for the daemon to control how it behaves before and during a planned hard fork: |
There was a problem hiding this comment.
Can this be a true/false flag, or do we plan to add more switches to it in the future?
|
MIP Editors and O1 have agreed that we don't need this improvement to be a formal MIP that needs to be voted on, as it does not require a protocol change, other than adjusting some configuration values related to the hardfork moment. However, it is very important to have an early alignment with the community on how the hardfork is going to proceed. A promise of this hardfork is that for the vast majority of node operators, the actual switch from Berkeley to Mesa will happen automatically. Still, every node operator has a slightly different setup, and it makes sense to share details of the procedure in a detailed form. We aim for a consensus of block producers. Please follow and contribute to the discussion here. |
3 participants
This MIP proposes an automated hard fork mechanism for the Mina daemon, improving decentralization and security, and eliminating the need for precisely timed manual intervention during a hard fork