-
Notifications
You must be signed in to change notification settings - Fork 148
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
Prepare for switch to Birth Rounds #18244
Comments
This is not possible to implement this way, if an event is ancient, there is no guarantee that a node has ever received this event, because it could have become stale before being sent to anyone. If such an event were to not be ancient all of a sudden, the network could get stuck if no one has that event. Cody created a different strategy for this migration that we have finally gotten working. We mostly ready for this migration to proceed. |
Is the software version necessary in the event core? Or can we figure out the software version based on using real birth rounds and the freeze round? |
Before migration we use a BR of |
I think that would be OK since we really basing whether or not to override the event, as part of migration, on the generation. The version check is just a quick escape. But, I think the code will need to be updated to avoid overriding the birth round to 1 in the "ancient" case (see |
Two things we should do to prepare for the migration to birth rounds. In a release prior to adopting birth rounds:
On or after the upgrade to Birth Rounds, PCES could be reduced to ancient events, which should have some help on startup after upgrade. The essential thing is that we have all 500 rounds worth of events with real birth rounds at the time we switch to birth rounds so that we have enough events to make sure that any events that were ancient based on generation, and are no longer ancient based on birth rounds, are still known and find their way into the hashgraph.
The text was updated successfully, but these errors were encountered: