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

Design support for incrementally ticking the current ledger state as the wall clock advances #1255

Open
nfrisby opened this issue Sep 17, 2024 · 0 comments
Assignees

Comments

@nfrisby
Copy link
Contributor

nfrisby commented Sep 17, 2024

A few eras now have each added a non-trivial amount of per-epoch work that the ledger rules must do.

The main mechanism for this has been "pulsers" in the ledger state, which explicitly schedule the work according to slot number. Whenever Consensus ticks the current ledger state up to the slot of the newly-arrived block, the pulser does some portion of the work schedule for that era.

As the pulsers have become more expensive overall (notably Conway's governance logic), it no longer makes sense to wait until the next block arrives to do the ticking. Instead of waiting for eg 35 slots until the next block arrives, and then doing 35 slots of pulser work all at once (which delays the validation and therefore selection and therefore potential extension of that block), we could have spread that pulser work across the 35 seconds.

So, ultimately, this tasks is to make the uniformly-scheduled pulser work actually execute on that schedule, instead of disrupting that schedule by cramming all of the work scheduled to happen "between" two blocks into the moment the second blocks arrives.


This may require a non-trivial refactor. In particular, the Ticked data family has been used within the Consensus type signatures for a few years now in order to require that the evolution of a ledger state follows the alternating tick -> apply -> tick -> apply schema. We're going to have to insert optional "incremental ticks" into that schema. Perhaps something like tick -> incrtick* -> apply -> tick -> incrtick* -> apply. Or perhaps it should instead be incrtick* -> tick -> apply -> incrtick* -> tick -> apply. It requires consideration and analysis.


Also: how should this affect the forecasting logic in the ChainSync client and the leadership check? Does forecasting need to start from a ledger state that has been incrementally ticked? Or perhaps the costs of the forecast (which is limited to 3k/f slots) is independent of whether the source ledger state has been ticked?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

1 participant