Specify cross-era ticking/forecasting for Cardano

[amesgen]

Right now, the semantics of cross-era ticking/forecasting is purely implementation-defined, driven by whatever does not cause any concrete issues, rather than principled considerations.

• See here for forecasting.
• See

  ouroboros-consensus/ouroboros-consensus-cardano/src/ouroboros-consensus-cardano/Ouroboros/Consensus/Cardano/CanHardFork.hs

  Lines 708 to 723 in 106ce89

  	-- HACK to make sure protocol parameters get properly updated on the
  	-- era transition from Babbage to Conway. This will be replaced by a
  	-- more principled refactoring in the future.
  	--
  	-- Pre-Conway, protocol parameters (like the ledger protocol
  	-- version) were updated by the UPEC rule, which is executed while
  	-- ticking across an epoch boundary. If sufficiently many Genesis
  	-- keys submitted the same update proposal, it will update the
  	-- governance state accordingly.
  	--
  	-- Conway has a completely different governance scheme (CIP-1694),
  	-- and thus has no representation for pre-Conway update proposals,
  	-- which are hence discarded by 'SL.translateEra'' below. Therefore,
  	-- we monkey-patch the governance state by ticking across the
  	-- era/epoch boundary using Babbage logic, and set the governance
  	-- state to the updated one /before/ translating.

  and Change implementation of ticking in the HFC to tick-then-translate-then-tick #339 for an explanation why the current approach to ledger state ticking (translate-then-tick, ie first translate, then tick across the era/epoch boundary using the logic of the new era) is at the very least surprising in this case.
• Chain-dep state ticking is also underspecified (eg on the transition from TPraos to Praos, should the extra entropy nonce have been used if non-neutral?).

We should try to improve the situation here, and should be in a decent position for this as we now have a sizeable sample of era transitions whose requirements/particularities can guide our judgement. This requires input from the Ledger team, but the Consensus team can start by drafting a proposal. Possible outcomes are:

• Decide on how responsibility for the cross-era logic should be distributed across Consensus and Ledger. (Right now, it is a mix between the Ledger-provided TranslateEra instances, and how/when Consensus invokes them. At the very least, it should be clarified what the exact requirements/guarantees here are.)
  • Very concrete example question: The ledger events of which era should be emitted when ticking across an era boundary?
• Enriching the existing specifications with cross-era behavior (eg in the existing Ledger specs PDFs, or in the formal ledger specifications).

Crucially, any semantics we decide on has to be compatible with mainnet.

[dnadales]

@amesgen I marked this issue as needing help for the time being. Perhaps we could create a separate issue where we describe what we need from the ledger team, and mark that one as help needed.