Documentation

How the re-matched transactions must be applied at the ledger tip era.

Either we translate all and need to use ApplyTxs or we don't translate and we can use ReapplyTxs.

Re-match a batch of already-validated transactions against a HardForkState whose era might have changed, without translating the transactions across eras.

The ledger state lives in a single era: the tip of the telescope. Walking the telescope era by era, each transaction that belongs to an era we pass (a Z at that point) is serialised to CBOR with that era's toCBOR (after forgetting its validation evidence — we can only encode a GenTx). Once we reach the tip, those bytes are decoded with the tip era's fromCBOR, as a GenTx:

• a transaction already in the tip era is kept as-is (ReapplyTxs);
• a past-era transaction whose bytes decode in the tip era is upgraded (ApplyTxs); it must be fully applied since it lost its evidence;
• a past-era transaction whose bytes do not decode is untranslatable and is reported back as a MismatchEraInfo;
• a transaction from a later era than the tip (the ledger tip retracted) is downgraded to the era of the tip.

Reports are built with matchNS from the transaction's original era and the ledger tip era, which is why each transaction carries its original era (NS SingleEraInfo) alongside its serialised bytes.