You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 alternatingtick -> apply -> tick -> apply
schema. We're going to have to insert optional "incremental ticks" into that schema. Perhaps something liketick -> incrtick* -> apply -> tick -> incrtick* -> apply
. Or perhaps it should instead beincrtick* -> 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?The text was updated successfully, but these errors were encountered: