Lack of a language-agnostic mechanism to specify the types used in Cardano Dapps reduces cross-language interoperability and increases the time spent on connecting on-chain, off-chain, and analytics.
Configuration-based mechanism for specifying DApp data types and associated tooling for producing type libraries with common operations for popular language/PAB environments.
This is the total amount allocated to MLabs - Cardano DApp Schemas
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 PlutusTx or Plutarch 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).
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.
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.
Developers building Cardano DApps and extended tooling and infrastructure.
For the reader’s reference, the following standards and technologies have solved a similar problem in traditional software sectors:
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.
This project will generate code that integrates closely with target language/PAB environments, concretely Cardano Transaction Lib, Plutarch, Lucid and Postgres, 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 Purescript Bridge/CTL, we are confident in our ability to deliver such a project.
Hours involved: 1,440 hours
Precedent research: 60h
Language, API, Tooling design: 180h
Haskell, Purescript, Typescript, SQL Backends: 960h
Change Budget: 60h
Total Time: 1,440 hours
Total Cost: $115,200
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:
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 MLabs Haskell repo and Plutonomicon repo for more information on our contribution to open-source tooling on Cardano.
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.
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 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 Purescript Bridge and a regular contributor to Cardano Transaction Lib. Before joining MLabs in 2021, he was a software engineer in information security.
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.
We will measure:
We expect growth/positive results in these areas and are committed to meeting the milestones we have established throughout this proposal.
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 Purescript Bridge. 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.
This is a new proposal.
Cardano full-stack developers with first-hand experience of the problem while building large-scale Dapps. We previously developed Purescript Bridge (see below) as an interim solution for interoperability between Plutus/Plutarch on-chain and Purescript off-chain/frontend code.