IntersectMBO / IntersectMBO/ouroboros-consensus
Design support for incrementally ticking the current ledger state as the wall clock advances
- Dominant language
- Haskell
- Stars
- 67
- Forks
- 43
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 43
Description
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?
Contributor guide
Assessment
This issue has not been assessed yet.