[SOLUTION] Please describe your proposed solution.

Problem

Cardano-transaction-library (CTL) is a Swiss knife framework for Cardano offchain development created at MLabs. To appeal to a wider audience, a few shortcomings have to be addressed.

Wide dependency tree, use of WebAssembly

There are a number of WebAssembly dependencies we use that bloat CTL-produced front-end bundles for end users: it’s not possible to tree-shake WebAssembly binaries using JavaScript bundlers.

cardano-serialization-library (CSL) is a dependency of CTL. CSL’s code is partially autogenerated using https://github.com/dcSpark/cddl-codegen, which reads Cardano CDDL and emits rust code. Rust code then gets compiled to WebAssembly, and the build artefacts can be consumed as an NPM package: https://www.npmjs.com/package/@emurgo/cardano-serialization-lib-browser

At the moment of writing, the WASM binary in this package is 2.03 MB

cardano-message-signing (CMS) is a library that implements CIP-0008 message signing spec and is consumable from the browser as an NPM package:

<https://www.npmjs.com/package/@emurgo/cardano-message-signing-browser>

The WebAssembly blob is of 372KB in size.

cardano-message-signing is used for Cip30Mock implementation, that is only needed for testing.

uplc-apply-args (<https://github.com/mlabs-haskell/uplc-apply-args>) is a custom solution we use for applying PlutusData arguments to parameterized Plutus Scripts.

The WebAssembly blob is of 177KB in size.

Solution

Wide dependency tree, use of WebAssembly

We will re-implement parts of functionality in TypeScript or JavaScript and move the rest to optional dependencies.

cardano-serialization-library contains some functionality that we don’t actually need.

We use CSL for two purposes:

• Conversion between domain types and their CBOR representations
• Min-ada fee estimation using MinOutputAdaCalculator

We want to build a lightweight JS-only re-implementation of the part of CSL responsible for CBOR (de) serialisation of Cardano domain types. This part will have the same interface as CSL so that we can plug it into CTL without much refactoring.

There are ~130 semantically nontrivial CSL domain types we use.

Among them:

• 6 address-related types
• 3 numeric types: BigInt, Int, BigNum - we use arithmetic from CSL only for BigNum

We can allow ourselves to differ from CSL by lifting some requirements that are not relevant to us:

• We will only produce code for the latest era specification (no backwards compatibility is needed because we only deal with transactions from the current era)
• We will not guarantee that roundtrip property is preserved - serialize(deserialize(tx)) may differ from tx - again, because we don’t deal with deserialization a lot.

We have considered three approaches to implementing Cardano domain-type serialization:

• Code generation from CDDL to JS, similar to how <https://github.com/dcSpark/cddl-codegen> does that - requires writing a code generator from CDDL to JS / TS
• pros: automatic deriving of code from specification is a principled approach to software development. High correctness guarantees.
• cons: We have a limited set of data types and there is no potential for reuse
• cons: New versions of CDDL specs are proposed rarely and are always announced in advance
• cons: we estimate the development time to be >3 months (longest)
• cons: Even cddl-codegen does not allow to generate 100% of the code: https://github.com/dcSpark/cddl-codegen/blob/master/GENERATING_SERIALIZATION_LIB.md - because address data layout is not specified in CDDL, and there are a few technical limitations. High risks
• Manual implementation means writing the encoders/decoders by hand
• pros: straightforward approach that does not involve many risks
• cons: will require manual changes in the future
• cons: we estimate the development time to be slightly less than 3 months
• Adapting serialization code from cardano-js-sdk:
• pros: the (en/de)coder code is already there, no need to write it
• pros: lowest development cost
• cons: a fork is required, because serialization-related types are tightly coupled with the rest of the library

We decided to adapt serialization code from @cardano-sdk/core by stripping the unneeded parts and maintaining it as a separate project (proposed name “cardano-data-lite”, may be changed in the future).

MinOutputAdaCalculator is another CSL API we will have to re-implement. It is just a piece of arithmetics code that is trivial to rewrite:

<https://github.com/Emurgo/cardano-serialization-lib/blob/5c58e5ee75b0d6262840287ba06c9f9d1caf1037/rust/src/utils.rs#L1403>

cardano-message-signing (CMS)

We believe that, since most users would not need the CMS library in the browser context, it is possible to re-organize the CTL structure to make it an optional dependency for clients’ projects.

uplc-apply-args

We have evaluated the feasibility of implementing it in pure JavaScript, and, unfortunately, the scope of the functionality is too wide for us to fit it into a single Catalyst proposal. We will move it to a separate package for now, and free most of the users who do not need this functionality from having to deal with WebAssembly.

Market

Our target audience is Cardano dApp developers who use or may use CTL in the future, including current clients of MLabs.

Features

• New reusable library with a CSL-like interface that implements cardano domain types serialization and deserialization in pure JavaScript
• Dependency footprint reduction of CTL

Related work

Previous Catalyst proposals for Cardano Transaction Library development:

• Catalyst Fund8: <https://cardano.ideascale.com/c/idea/396607>

• Catalyst Fund9: <https://cardano.ideascale.com/c/idea/64398>

• Catalyst Fund10: <https://cardano.ideascale.com/c/idea/101478>

  [IMPACT] Please define the positive impact your project will have on the wider Cardano community.

The main value propositions of this work are:

• Dependency footprint reduction of CTL will result in more optimal bundles, and will improve UX of CTL-based dApps by making them more accessible to users with slow network connectivity, which is extremely important for mobile users and consumers from developing countries.
• Creation of a new reusable library that replicates parts of cardano-serialization-lib interface. It can be considered a viable drop-in replacement for cardano-serialization-lib for some dApp developers, that does not require WebAssembly

We can measure success using two observable metrics:

• CTL total bundle size reduction in KB (before, after)
• Usage stats of a newly created CSL replacement package on NPM

We will promote the outputs of our work on the company's social media and/or in technical communities.

[CAPABILITY & FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

Our capabilities to deliver the project have been demonstrated by prior work on Cardano Transaction Library, funded by:

• Catalyst Fund8: <https://cardano.ideascale.com/c/idea/396607>
• Catalyst Fund9: <https://cardano.ideascale.com/c/idea/64398>
• Catalyst Fund10: <https://cardano.ideascale.com/c/idea/101478>
• IOG
• MLabs and its clients

Our ability to manage funds responsibly is evidenced by our successful completion and closure of all our funded projects from Fund7, Fund8, and Fund9. We have consistently upheld the utmost care with our compliance, maintaining complete transparency with the Catalyst team and broader community members. Furthermore, our extensive project management experience across a diverse range of client projects has honed our skills in budgeting, meeting milestones, and adhering to roadmaps.

[Project Milestones] What are the key milestones you need to achieve in order to complete your project successfully?

cardano-data-lite implementation

Outputs:

• cardano-data-lite (CDL) library implementation
• CI setup
• Documentation for CDL

Acceptance Criteria:

• CDL has been adapted from @cardanosdk/core, and the library is completed including the serialization code adapted to our use case.
• A CDL interface that is similar to CSL in data conversion and type naming has been added
• A CI has been integrated.
• Basic documentation is present

Evidence:

• Link to GitHub and relevant commit(s)
• Instructions for running tests are provided

Estimate: 29% of budget

>Use cardano-data-lite in CTL

Outputs:

• Use of CDL in CTL instead of CSL
• Implementation of MinOutputAdaCalculator alternative in CTL
• Unit tests of CDL

Acceptance Criteria:

• Cardano-transaction-library no longer uses cardano-serialization-library
• Serialization of the domain types is done via cardano-data-lite
• Mentions of CSL are removed from CTL documentation (except of the changelog)
• Unit tests are present in the repo

Evidence:

• Link to GitHub repo and relevant commit(s).

Estimate: 28%

>Move library for application of Plutus script parameters out of CTL core

Outputs:

• A PureScript package with implementation of applyArgs (wrapper over uplc-apply-args)

Acceptance Criteria:

• PureScript package created for applyArgs

Evidence:

• Link to GitHub repo and relevant commit(s).

Estimate: 10%

>Move message signing library dependency out of CTL core

Outputs:

• Cip30Mock functionality available in a separate PureScript package outside of CTL

Acceptance Criteria:

• PureScript package compatible with CTL is created for Cip30Mock functionality

Evidence:

• Link to GitHub repo and relevant commit(s)

Estimate: 10%

>Cardano-Transaction-Library without WebAssembly

Outputs:

• CTL version that does not require using WebAssembly for bundling

Acceptan Criteria:

• The evidence demonstrates that CTL-based projects can be bundled without WebAssembly, if they only use “core” CTL - that is, without the packages moved out into separate projects

Evidence:

• Video demonstration/explanation
• Link to GitHub repo and relevant commit(s)

Estimate: 23%

[RESOURCES] Who is in the project team and what are their roles?

MLabs

MLabs has quickly become one of the premier development firms in the Cardano Ecosystem. We are an IOG Plutus Partner and work regularly with IOG to develop the Cardano blockchain and ecosystem. Our team is composed of talented developers who have helped build community projects such as:

• Liqwid
• SundaeSwap
• Minswap
• Optim
• Many others

Through our work with early-stage projects, we have one of the largest groups of Haskell/Plutus developers in the community.

Website: <https://mlabs.city/>

Core Team

Vladimir Kalnitsky - Tech Leadership

Vladimir is a software developer with a number of contributions to the PureScript ecosystem and solid experience with Haskell. During his undergraduate years, Vladimir focused on functional programming and type theory. Vladimir is more of a 'hacker' than a scientist, but he still values formal reasoning about code and well-founded software development practices.

Dzmitry Shuiski - Haskell and PureScript Development

Dzmitry is an experienced software engineer, currently developing solutions using functional programming techniques, mostly using PureScript and Haskell. Coming from a background in iOS App Development, he is well-versed in various aspects of developing robust and user-centric systems. Dzmitry has made considerable contributions to CTL in the past and is now primarily focused on Cardano dApp development. He is currently pursuing a degree in Software Engineering and Management at the Graz University of Technology to deepen his knowledge in more fundamental disciplines.

[BUDGET & COSTS] Please provide a cost breakdown of the proposed work and resources.

M1: cardano-data-lite implementation - 111 hours total

• Fork cardano-sdk/core (10h)
• Remove parts irrelevant to serialization (38h)
• Provide an interface similar to CSL (40h)
• Set up CI (12h)
• Set up basic docs (7h)
• Reporting (4h)

M2: Use cardano-data-lite in CTL - 104 hours total

• Replace CSL with CDL in CTL (19h)
• Update docs (7h)
• Add unit tests + bug fixes (22h)
• Implement MinOutputAdaCalculator in CTL (40h)
• Reporting (16h)

M3 move library for application of plutus script parameters out of CTL core - 38 hours total

• A separate PureScript package with applyArgs implementation (30h)
• Reporting (8h)

M4 move message signing library dependency out of CTL core - 38 hours total

• Move Cip30Mock out of core library (30h)
• Reporting (8h)

M5 CTL without WebAssembly - 87 hours total

• Reorganizing bundling machinery (webpack) (22h)
• Reorganizing bundling machinery (esbuild) (24h)
• Reorganizing bundling machinery (nix) (28h)
• Reporting (13h)

Subtotal: 378 hours

Total hours with contingency (15%) and management (12%) overheads: 480 hours

Total USD cost (@100 USD/hour) = 48,000 USD

Total ADA cost (@ 6-month-low rate $0.24 USD / ADA): 200,000 ADA

**In the interest of full transparency, please note we have applied a conservative USD/ADA exchange rate in pricing this proposal. This is to ensure our operations remain stable regardless of market conditions. Although we firmly believe the future of Cardano is bright, we recognize the price of ADA and all cryptocurrencies is inherently volatile. Our financial obligations are denominated in fiat. Most importantly, this includes the salary of our engineers whose hard work makes projects like this possible.

In the unlikely scenario of severe negative price movement beyond our forecasted rate, it is possible that MLabs may need to temporarily suspend work on this proposal until the market recovers. Rest assured, this decision would be made solely to protect our business's long-term viability and never taken lightly.

We appreciate your understanding and support, and we are excited to see what we can achieve together.

[VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

Making dApp developers more productive by removing the need to deal with WebAssembly bundling would save costs for the teams and therefore may positively affect the number of successful Cardano projects. Improving UX for the end users is also a major benefit.