Please describe your proposed solution.

Problem

There are no language-agnostic mechanisms for specifying the types of information and values used in Cardano DApps, a detrimental fact to productivity and cross-language environment interoperability. A significant percentage of DApp development effort is spent on dealing with serialization/deserialization issues between on-chain code types, off-chain/frontend, and analytics/databases. This major source of delay in project timelines could be eliminated if types would be language agnostically defined once per DApp; with serialization/deserialization code for multiple targets generated automatically from the agnostic definition.

Currently, type definitions for a typical Cardano DApp must be specified in the Haskell programming language. Together with the <u>PlutusTx</u> or <u>Plutarch</u> libraries, Haskell is the de-facto main tool for writing Plutus programs.

The lack of language-agnostic tools for specifying Cardano DApps data types (e.g. datums, redeemers, etc.) has a negative effect on productivity. Furthermore, it constitutes a fundamental hurdle to cross-language environment interoperability and proliferation of generic tooling to enable rich interaction with DApps (e.g., database explorers).

The mentioned issue of language-tied typing has become more severe with the proliferation of different PAB platforms, each written in different languages. PAB platforms enable developers to build software that give users the ability to interact with Cardano DApps from a variety of platforms (e.g., server, desktop, browser, mobile etc.). Examples of such platforms include <u>Bot Plutus Interface</u> (Haskell), <u>Cardano Transaction Lib</u> (Purescript), and <u>Lucid</u> (Javascript).

To make Cardano DApps available across all the aforementioned platforms, structured information needs to be effectively shared in a language-agnostic manner and made available to different language/PAB environments. Furthermore, blockchain analytics applications, DApp aggregators, and DApp interoperability will require light DApp-type schemas that are decoupled from the DApp’s implementation code - it is not very practical to have to import a DApp’s codebase in order to interpret its datums, redeemers, and other on-chain data.

We want to consolidate the solution to this issue into a single project that takes type definitions out of a language-specific environment and into a configuration language that can be then fed to a reliable code generation tool that targets a number of different language/PAB environments.

The intent behind this project is to align the Cardano tech environment with modern best practices that facilitate building robust, technology stack agnostic Cardano DApps.

Solution

We propose a configuration language for specifying DApp schemas. The language makes use of code-generation tooling, which using the schemas produces ‘type libraries’ (aka. typelibs) for different language/PAB environments. Each typelib is generated alongside supporting libraries for handling encoding, serialization and other essential operations. All the mentioned processes are automated, maintaining correctness and compatibility between different language/PAB environments.

Cardano DApp Schemas serve as a language-neutral, extensible mechanism for specifying type definitions and code-generating different language environments library implementations.

Market

Developers building Cardano DApps and extended tooling and infrastructure.

Features

• Configuration language for specifying data types aligned with the Plutus data model.
• Support for sum, record/product and polymorphic types.
• Automated production of type libraries from configuration-based specifications.
• Integration with build systems associated with the target language/PAB environments (e.g., Cabal, Spago, Node, Nix etc.).
• Standardized data type associated operations, including JSON encodings, Plutus data encodings, Plutarch instances, Pretty printers, Arbitrary instances and more.

Related work

For the reader’s reference, the following standards and technologies have solved a similar problem in traditional software sectors:

1. <u>ASN.1</u> - adopted by widely used cryptographic standards (see X.509),
2. <u>Google Protobuf</u> - used by major tech companies as the foundation for RPC and microservice-based architectures,
3. <u>Apache Thrift</u> - used by major tech companies as the foundation for RPC and microservice-based architectures,
4. <u>Apache Avro</u> - configuration-based schema definition mechanism used across different Apache projects,
5. <u>CDDL</u> - used by Cardano itself at the network/transport level, fairly complicated standard with little supporting tooling available,
6. <u>XDR</u> - used for RPC in Linux-based enterprise networks,
7. <u>Microsoft IDL</u> - used by Microsoft DCE/MS-RPC protocols and a foundational technology for MS Windows-based enterprise networks,
8. ADL <u>https://github.com/timbod7/adl</u>
9. Data specification technology inspired by and built for functional programming language environments.

Please describe how your proposed solution will address the Challenge that you have submitted it in.

Typical Cardano DApp projects involve a very diverse team. For instance, a frontend team working with Javascript/Typescript, contract writers using Purescript and the <u>Cardano Transaction Lib</u>, an analytics team reporting on the DApp’s state and statistics with SQL/GraphQL using relational databases, and a Haskell team writing Plutus programs and building server/desktop automation using <u>Bot Plutus Interface</u>.

We hope this proposal will make such diverse teams work together more effectively by consolidating all data type definitions in a single place, and reusing them reliably across their respective technological environments.

The successful adoption of this project would radically increase developer productivity, while decreasing the amount of unnecessary, tedious, error-prone and boilerplate code that needs to be manually written and curated. Type definitions would serve as documentation for the project, as well, and could very well be foundational to proliferation of generic tools and infrastructure that can interact with schema-enabled Cardano DApp projects.

What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?

This project will generate code that integrates closely with target language/PAB environments, concretely <u>Cardano Transaction Lib</u>, <u>Plutarch</u>, <u>Lucid</u> and <u>Postgres</u>, to name a few. Given that some of these projects are currently under active development, we anticipate that API breakages will be a common occurrence and we intend to bring respective development teams into a common social circle in order to organize for mutual evolution and growth.

We don’t anticipate any significant technological hurdles. Encouraged by our experience successfully building and using <u>Purescript Bridge/CTL</u>, we are confident in our ability to deliver such a project.

Please provide a detailed plan, including timeline and key milestones for delivering your proposal.

1st month

• Study and document related and relevant technologies, assessing the potential for their direct application to our problem. Research existing schema definition systems, their data models, and feature-rich configuration languages/systems (like <u>Dhall</u>) that could be used to host and embed our data type and schema model.
• Determine and document the schema model and build a schema validation tool.
• Specify the entirety of <u>Plutus Ledger API</u> in the developed schema system.

2nd month

• Focus on code generation, tackling Haskell and Purescript language/PAB environments first. Aim to reach feature parity with existing tooling as quickly as possible.
• Determine and document the standard for code generation, enabling developers to understand how they can use the data types defined in our schema system (PlutusTx, Plutarch, Cardano Transaction Lib).

3rd month

• Refine all of the above and introduce tests assuring cross-language compatibility and correctness.
• Developer productivity tools and integrate with relevant build systems (Nix, Cabal, Spago).
• Incorporate this system in a Cardano DApp project that uses Plutarch and Cardano Transaction Lib to demonstrate the advertised gains of DApp schemas.

Please provide a detailed budget breakdown.

Hours involved: 1,440 hours

Total: $115,200

Breakdown

—

Precedent research: 60h

Language, API, Tooling design: 180h

Haskell, Purescript, Typescript, SQL Backends: 960h

Testing: 120h

Documentation: 60h

—

Subtotal: 1380h

—

Change Budget: 60h

—

Total Time: 1,440 hours

Total Cost: $115,200

Please provide details of the people who will work on the project.

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. Moreover, MLabs has the capacity to conceptualize and ship developer ecosystem tools like Cardano DApp schemas. Please visit the <u>MLabs Haskell</u> repo and <u>Plutonomicon</u> repo for more information on our contribution to open-source tooling on Cardano.

Core team

Cardano DApp full-stack developers with first-hand experience of the stated problem - in the course of building large-scale DApps. We have previously improved Purescript Bridge (as an interim solution), enabling interoperability between Haskell written Plutus/Plutarch on-chain code and Purescript written off-chain/frontend code.

• <u>https://github.com/mlabs-haskell/purescript-bridge</u>

Sean Hunter

Sean is a Haskell developer who has worked on Cardano DApps and infrastructure projects at MLabs. He is a maintainer of purescript-bridge and contributor to Cardano Transaction Lib, where he implemented the Plutus data schemata that facilitate translations between Haskell and PureScript. Before joining MLabs, he was a postgraduate philosophy student and instructor specializing in philosophy of language and logic.

Vlad Posmangiu Luchian

Vlad is a software engineer working with Haskell. At Mlabs, Vlad works on designing and delivering a diverse range of DApps including DEXs, Oracles, and NFT Marketplaces. In his spare time, he takes a keen interest in researching type and programming language theory.

Drazen Popovic

Drazen is a full-stack Cardano developer, working on several Cardano DApps that span Haskell, Purescript and Nix language environments. He’s also a maintainer of <u>Purescript Bridge</u> and a regular contributor to <u>Cardano Transaction Lib</u>. Before joining MLabs in 2021, he was a software engineer in information security.

If you are funded, will you return to Catalyst in a later round for further funding? Please explain why / why not.

At this time, we do not intend to return to Catalyst in a later round for further funding of this project. Our budget includes the full scope that we anticipate for the proposal, and our previous experience in developing Purescript Bridge and improvements to it gives us good assurance that our estimates are accurate.

Please describe what you will measure to track your project's progress, and how will you measure these?

We will measure:

• the number of features implemented,
• the number of issues discovered and resolved,
• the usability of Cardano DApp schemas to projects that have incorporated it,
• the number of contributors adding to the GitHub repo,
• the number of Cardano projects relying on Cardano DApp schemas,
• the general perception of the project in the Cardano developer community.

We expect growth/positive results in these areas and are committed to meeting the milestones we have established throughout this proposal.

What does success for this project look like?

In the short term, after this funding round, we expect a proof of concept end-to-end solution that has feature parity with the current state of the art which includes Haskell (Plutarch) and Purescript (Cardano Transaction Lib) interoperability with <u>Purescript Bridge</u>. Hopefully, this will be accompanied by a successful adoption in a small to medium-sized commercial Cardano DApp project.

Following that, in the medium term, we want to see increased adoption of the Cardano DApp schemas by several projects, hopefully making it the default choice for Cardano DApp developers. This will, of course, be contingent on the project stability and support prospects.

The end goal is expanding code generation to target and encompass all relevant language/PAB environments.

Please provide information on whether this proposal is a continuation of a previously funded project in Catalyst or an entirely new one.

This is a new proposal.