Technical Debt

[CarlosLopezDeLara]

WHAT

Resolve top tech debt items

PI 3.5

• deprecate the intermediate cli tx body format --> Deprecate intermediate tx body cli format #4277
• Deprecate intermediate txbody format #4303
• separate transaction body construction and validation --> separate transaction body construction and validation #4495
• 🚫 BLOCKED Cardano node uses a for of optparse-applicative. We need to bring our changes to the upstream library so that we don't have to maintain it, (M) --> blocked Merge changes on optparse-applicative to upstream library #4520
• 🚫 BLOCKED Move from ansi-wl-pprint to prettyprinter (M) --> Blocked Merge changes on optparse-applicative to upstream library #4520

Spill over to PI 5

• Add key serialization to API --> needs clarification (John Ky)
• Condense the cardano-cli genesis command into a single command --> would this break cardano-testnet and QA tests?
• Decision: ability to keep creating byron addresses
• d parameter Remove the decentralization parameter field in the Babbage #4054

Dependencies

• Keep an eye on optparse-applicative library
• Decision on d parameter. It is likely not possible. Figure out if we can enable OBFT nodes through other means/modes.

Risks

optparse-applicative / Move from ansi-wl-pprint to prettyprinter) (Risk if our changes are not merged)

• For us, the prettyprinter library has more intuitive and predictable control over text output and we already use it in other projects. Modifying optparse-applicative to use this library will mean we can use a single library for pretty printing everywhere and not have to deal with two different incompatible libraries that do the same thing. We will not be able to fix the fork of optparse-applicative problem.
• Relying on a fork long term is untenable because optparse-applicative may release new versions. If that happens we would have to patch our fork to keep up with those. We will end up having to maintain our own fork which will itself cost us effort in the future. We don't want to get into a situation where our code bases uses two incompatible versions of this library and have to stop work to fix builds

d parameter (Risk of full removal)

• d parameter has been removed from babbage onwards --> it can still be cleaned up (A cosmetic not a functional change)

This conflicts with a request from commercial:

• Private instances might want to leverage Babbage features while running on OBFT mode --> Maintaining a fork to bring d parameter back is a costly option.**

genesis command (Risk to be mitigated)

• Condensation might break cardano-testnet and QA tests. Evaluate if it's worth the pain.

Decision: ability to keep creating byron addresses (Risk to be mitigated)

• Many exchanges still rely on their ability to create byron addresses, we need clearance from exchanges first.