Please describe your proposed solution.
Problem
This proposal aims to deal with multiple CTL-related tasks at once.
1) The user-facing constraints interface that is used in CTL as a way to define transactions is not very consistent, due to the fact that it hasn’t been planned out beforehand. We started with a close copy of Plutus interface and were adding features on request from the users - as a result we ended up with an interface that is unnecessarily complicated and is based on design decisions that only make sense for Plutus, but not CTL as offchain library.
https://github.com/Plutonomicon/cardano-transaction-lib/issues/1482
2) We don’t need “plutus domain” types in the core library. Historically, we decided to provide Cardano domain types and Plutus domain types separately, just like it is done in the Haskell ecosystem, to make it easier to adapt code from Haskell to PureScript. It looks like we don’t need Plutus domain types most of the time – they are only useful for interop with Plutus language via PlutusData encoders/decoders.
3) The codebase is a monolith. Some parts could be replaced with new libraries that were written after CTL has been established, and some others could be moved to new standalone repositories.
4) Internal developer surveys have shown us that library error messages are hard to read and reason about, and functionality for working with time on Cardano (validity intervals) is not convenient to use.
Solution
1) Re-write the constraints interface. Notable needed changes include:
- Removing the lookups interface – it does not make sense in the offchain context
- Joining the balancer constraints (that let us control the balancing process) with transaction constraints to simplify UX
- Making constraint naming more consistent
- Moving away from credential-based addressing to use of Address type (no need to separately take care of payment and stake keys most of the time)
2) Moving plutus domain types either to another package or to a set of modules that stand aside and are not used in the main APIs of the library. Cardano domain types should be used for core APIs.
3) The following parts can be moved to external packages, because they can provide value on their own.
- Cardano domain types
- Plutus domain types
The following libraries could be added to CTL as dependencies:
-
PureScript wrapper for cardano-serialization-lib (https://github.com/mlabs-haskell/purescript-cardano-serialization-lib) – to be used instead of our own wrapper. The advantage of the library is that it’s auto-generated from cardano-serialization-lib (https://github.com/Emurgo/cardano-serialization-lib/) code.
-
PureScript wrapper for CIP-30 browser-based wallet interface (https://github.com/mlabs-haskell/purescript-cip30) – it is reusable by other projects and is abstracted from particular wallets, unlike CTL itself.
4)
- Error messages could be improved by giving them human-readable descriptions and formatting properly, as well as introducing more fine-grained module-level error types when needed.
- Time-related APIs could be reworked (one of the possible solutions we would like to adapt: https://github.com/Plutonomicon/cardano-transaction-lib/issues/1517)
Market
This proposal will affect existing Cardano projects that use CTL, including, but not limited to:
- Liqwid
- Indigo Protocol
- Optim
- PlayerMint
- Atrium
How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?
Intended Fund – Fund10: Developer Ecosystem – The Evolution
How do we equip and support developers with tools and working infrastructure? How do we make Cardano their first choice when it comes to building dApps, innovating and collaborating?
What does this proposal entail?
This proposal directly addresses some problems CTL currently has, resolving these problems would attract more developers by providing more confidence in the tech stack.
How do you intend to measure the success of your project?
Success can be measured by the willingness of library users to update to a newer version. The inability of the users to update can be considered a failure.
Please describe your plans to share the outputs and results of your project?
MLabs maintains a social presence on Twitter and in Plutonomicon Discord, where updates could be posted.