About alternatives

Modularization and clear interfaces are only enforced when there are alternatives. That is, alternative implementations of components or alternative compositions of components.

Large parts of the Cardano codebase created by IO are optimized for a single target use case: producing blocks for the public Cardano network. While this is certainly the main use case that requires special care and tuning of performance characteristics to meet the timing demands of the consensus protocols, it currently does not leave much room for experimentation and re-use outside of that use case.

In the past, one could use the cardano-node to create permissioned networks more suitable for enterprise deployments. This was basically done by setting up Ouroboros-BFT consensus networks (through a transitional protocol named TPraos, e.g. in Alonzo), but since Babbage the parameters allowing for operating in that mode had been removed (CIP-55) and in Praos this is not possible anymore. Making this alternative use case more prominent could have naturally ensured individual components are modular enough for being used in this alternative composition, demonstrated the flexibility, and consequently could have made setting up side chains (e.g. partner chains and midnight) using the cardano codebase more appealing.

A good example of an alternative composition that enforces a well defined interface on the cardano-ledger is the Hydra project. In this case, the exact same ledger rules are re-used in a completely different application (that allows for off-chain processing of cardano transactions) and any "corruption" of the applyTx interface used here would be detected from this separate usage.

Arguably, the ledger is easiest to re-use component in the Cardano stack as it is "only" a pure function from evolving LedgerState, roughly: applyTx :: LedgerState -> Tx -> LedgerState. However, it is quite directly used by the Consensus layer and it is not clear (at least from the outside) that alternative ledgers could be used? Intuitively this should be possible, but ledger eras are also defined in the consensus layer and would it be straight-forward or complicated to establish alternative eras with, for example, an account-based ledger? Such an alternative implementation of cardano-ledger would not only demonstrate the flexibility and re-usability of the hosting consensus layer, but also ensure that the ledger abstraction does not leak into the consensus.

In summary, for each component to be re-usable we should maintain and demonstrate alternatives. Note that we often do have such alternatives already in tests and more often than not this is just a discoverability or communication issue.