Background

Today's hard fork combinator design handles transitions from one era to the next (eg Byron to Shelley, Alonzo to Babbage, etc) in a way that has so-far supported the needs of Cardano.

However, Issue #339 results from the current HFC design clashing with the current Conway design. (To be clear: the Conway design is not at fault, in my opinion.)

As part of our work on Issue 339, we've also been considering which assumptions of today's HFC design need to change. EG The draft PR #340 changes Edsko's original translate*-then-tick scheme (which made plenty of sense for Byron-to-Shelley!) to a new (tick-then-translate)*-then-tick scheme. We think the latter better matches the very reasonable intuition that the current (😞) Ledger and Consensus team members have about "when" era-to-era translations happen. However, we've finally also realized that this new scheme is still very specific to Cardano.

In these discussions around Issue 339, @dnadales early on suggested that the HFC should make even less assumptions. I've come around to that agree with him: the HFC should be as reasonably-general as possible---even beyond Cardano---and we should include helper combinators (eg (tick-then-translate)*-then-tick) for instantiating it conveniently for the Cardano use case.

Task

This Issue is to propose a new generalized interface about how the HFC handles era transitions. We don't necessarily need to implement it, but at least having "the general interface" semi-formalized will help us navigate these kinds of questions, both Issue 339 now and similar issues in the future.

Also, we should discuss that "idealized" interface with at least the Ledger Team, since they ultimately own any design decisions that are required in order to implement each concrete era transition.