When we put together our Cardano Proposals 2025, we knew that it was likely some of them would change over the course of the year as community priorities shifted, new research was developed, or technological challenges were encountered.

For History Expiry, that point came somewhat earlier than expected. Our initial plan for history expiry was partly motivated by the desire to drop a large amount of code and logic from the Haskell node, and partly to be able to periodically trim the chain. Shortly after submitting our proposals, however, a few of us gathered in Paris for the first Node Diversity Workshop. Amongst many other valuable topics, we discussed history expiry. Somewhat to our surprise, the general consensus amongst the attendees at that meeting was that having a node which could replay the chain from Genesis was a valuable—and often distinguishing—feature of Cardano compared to other chains, and that we would like to retain this, at least in the Haskell node.

However, the fact remains that the majority of new node implementations do not intend to implement previous eras, and many node operators would prefer not to have to carry the increasingly large full history of the chain. Some version of history expiry is obviously therefore still needed - but which version precisely?

A digression via Archive Nodes

If the intention is to remain able to sync from Genesis, then we need to keep the history of the chain available, not only as an archive for inspection but also as a source for chain synchronisation. The question then becomes one of how to incentivise people to keep and serve this chain. Since serving the archive has no direct on-chain visibility, it is hard to incentivise through on-chain mechanisms.

We consider that there are three possible approaches to this incentivisation problem:

• On-chain: Introduce mechanisms which make provision of archive nodes visible on chain.
• Construct or propose off-chain incentives to provide archival nodes.
• Obviation: Make serving the historical chain so cheap that incentives are not needed.

Initially we had started thinking about the first two approaches. However, we then thought about another proposal which we had put forward - the Genesis Sync Accelerator. The Genesis Sync Accelerator is a plan to speed up syncing nodes via Ouroboros Genesis, by using an http-served archive of the chain and leveraging Genesis’s capability to validate blocks served from one peer by polling other peers.

Originally the juxtaposition of these proposals presented something of a concern for us. As we mentioned in our previous post, we had expected these proposals to go through community review before full on-chain voting, and in their initial incarnations these proposals were somewhat contradictory.

If, however, we don’t want to entirely truncate the chain, the GSA offers a tantalising possibility to work as the archival node. Since the GSA uses http transport via CDNs to distribute the block database, costs are likely to be sufficiently low to effectively obviate the incentive issue. Nodes wishing to sycn the chain from Genesis may download the block database from a CDN, run a local GSA and use that to fetch blocks.

In order to support this, we require that other nodes are capable of verifying the blocks provided by the GSA. We can do this by requiring that all nodes keep the header chain, which is significantly smaller than the full block chain, and can be more sensibly distributed with Mithril snapshots. We have already discussed this requirement with the Amaru team, and we intend to reach out to other alternate node developers in the next few weeks.

How we now envision History Expiry

With this in mind, we can now discuss how we have re-envisioned the History Expiry project:

1. Our first objective remains the same: we need to support nodes that do not possess and cannot validate the historical block chain. This will involve some change to the mini-protocols to support communicating about prehistoric data (e.g. points where a node has only the header but not the blocks due to them being too old) and likely some changes to the existing node to alter disconnection logic when communicating with such nodes (e.g. removing any assumptions that a node claiming to be on a particular chain should be able to provide all the blocks on that chain.)
2. Defining a “reasonable horizon” for inclusion (of the full blockchain) in Mithril snapshots. This needs to be at least k blocks deep - we suggest something in the region of 5 epochs or so.
3. Updating the Haskell node to support starting from a block database not rooted at Genesis, since we envision this as the main method of operation.

Then, we propose to use the Genesis Sync Accelerator as the archival node. This should provide fast and safe syncing to anyone wishing to validate the full historical chain at low cost and high convenience to the wider network.

Most nodes would therefore sync the chain via a (much smaller) Mithril snapshot, downloading only the header chain, the last n epochs of the blockchain, and the ledger state. Those that wish to sync from Genesis would download the GSA, which will fetch an archive from a CDN and deliver blocks locally, while validating those against the full network of Cardano nodes.

We’re pretty happy about this plan, and we believe it represents the best way forward for history expiry given the desire to retain a Haskell node capable of processing from Genesis. We’ll shortly create and link to a CIP where we propose the changes to mini-protocols and the requirements on alternate nodes, so we look forward to your comments!