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.
Project will be fully open source.
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. However, we want to facilitate expansion to other languages getting traction in this space, specifically Aiken for on-chain Plutus scripts.
The lack of language-agnostic tools for specifying Cardano DApps data types (e.g. datums, redeemers, etc.) hurts productivity. Furthermore, it constitutes a fundamental hurdle to cross-language environment interoperability and the 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 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 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.
The project implements a configuration language for specifying DApp types/schemas. The language makes use of code-generation tooling, which using the schemas produces ‘type libraries’ (aka. typelibs) for different language 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 environments.
LambdaBuffers 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:
Intended Challenge – Fund10: Developer Ecosystem - The Evolution
Challenge Statement – “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?
How does increased throughput on Cardano help developers?
Typical Cardano DApp projects involve a very diverse team. For instance, Plutus scripts are written in Plutarch, PlutusTx and Aiken.
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 the proliferation of generic tools and infrastructure that can interact with schema-enabled Cardano DApp projects.
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 spirit of complete transparency with the Cardano community, the outputs of our proposal will be widely available. Foremost, as an open-source project, the GitHub repo at https://github.com/mlabs-haskell/lambda-buffers will be the obvious resource for updates, documentation, and educational resources. This repo will be updated as the project progresses - a primary deliverable of this proposal.
MLabs has a noteworthy social media presence. We'll make active use of these channels to share regular updates with less technical community members. Finally, we'll actively share progress reports through the typical, publically-available Catalyst channels. MLabs has a strong compliance record, and this will not change throughout the progress of this proposal.
LambdaBuffers project is nearing its completion in terms of its Fund9 deliverables, and with that, the overall research, design and implementation has already been done. Adding new language backends comes with little uncertainty as the framework was designed with such additions in mind.
1st month - Rust support
3rd month - Aiken support
1) Rust support
3) Aiken support
Subtotal: 576 hours @95/hour = $54,720 USD
Total (@ rate $0.21 USD / ADA): 260571
**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.
In a survey ran by the LambdaBuffers team and made available at https://github.com/mlabs-haskell/lambda-buffers/blob/main/docs/feedback/questionnaire-results.pdf it was determined that 10-20% of a DApp project time is spent on managing PlutusData encodings of DApp types. The goal of this project is to eliminate this cost in its entirety.
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.
Full-stack Cardano distributed application (dApp) developer and auditor, working on several Cardano dApps that span Haskell, Purescript, Rust and Nix language environments. Worked on decentralized protocols based on the Cardano blockchain including decentralized exchange, synthetic assets, oracle protocols and programmable money. In particular, he was the technical lead on the Cardano Open Oracle Protocol and was responsible for design and implementation.
Technical lead on the LambdaBuffers project, which is a novel toolkit for sharing types between different languages. Led the design and implementation which included common compiler topics such as type checking, type class resolution and code generation into various languages.
Less notable, but mention worthy, a maintainer of a Purescript Bridge fork (now deprecated in favor of LambdaBuffers) and a contributor to Cardano Transaction Lib Purescript library which is one of the foundational tools in the Cardano ecosystem.