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

Prepare for switch to Birth Rounds #18244

Open
rbair23 opened this issue Mar 7, 2025 · 4 comments
Open

Prepare for switch to Birth Rounds #18244

rbair23 opened this issue Mar 7, 2025 · 4 comments

Comments

@rbair23
Copy link
Contributor

rbair23 commented Mar 7, 2025

Two things we should do to prepare for the migration to birth rounds. In a release prior to adopting birth rounds:

  1. Enable real birth rounds, such that even event when it is created uses the pending round as its birth round
  2. Increase the depth of the PCES to include all non-expired events

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.

@lpetrovic05
Copy link
Contributor

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.

@edward-swirldslabs
Copy link
Contributor

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?

@lpetrovic05
Copy link
Contributor

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 1 for all events, we could use that as an indicator instead of software version I think....
@timfn-hg do you see any problem with this?

@timfn-hg
Copy link
Contributor

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 DefaultBirthRoundMigrationShim#migrateEvent(PlatformEvent))

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

4 participants