[IMPACT]
Market
dApp developers building browser-based applications.
Problem Space
As is well-appreciated, Cardano relies on the local environment inherent in a EUTXO to construct transactions capable of interacting with smart contracts running on-chain. This is in contrast to Ethereum, which relies on the global state of the blockchain towards the same end. While the Ethereum implementation is seemingly straightforward, the complications inherent in dealing with global state result in several undesirable side-effects: failing transactions, wasted resources, and so on.
The Cardano model sidesteps these issues by limiting the scope of smart contract transactions to their immediate environment as represented in the associated EUTXO. This design allows for resource determinism and atomic transactions. These assurances, however, are not without costs. Most notably, building transactions is burdensome upfront and the process includes querying the state of the chain and constructing the transaction using the Contract Monad or custom solutions.
The web3.js library on Ethereum is largely applauded for providing an easy and intuitive way for developers and users to plugin into key infrastructure as they interact with the blockchain. A key feature of web3.js is its abstraction over light wallets. This high-level approach removes a significant amount of complexity for dApp developers who would otherwise have to design around the intricacies of individual light wallets to perform even basic application functions.
Yet, owing to the design challenges and maturity of Cardano, a comparable suite of tools has yet to be developed. As the Cardano ecosystem comes online, high-level light client support of this kind is necessary to realize the integrated experiences users expect and to lessen the burden on development teams.
How does browser-based support for transactions help Cardano?
On Ethereum, web browser applications form a common interface for users to transact against the blockchain. Typically, in-browser wallets facilitate this process by injecting a Web3 provider object into the browser. This Web3 object links the user's wallet to publicly accessible nodes, allowing wallets like Metamask to sign transactions and manage private keys within the browser for seamless interaction with the network.
Tooling on Cardano has aimed to match this user experience, but progress remains to be made. Formerly, suggestions arose in support of an integrated backend product that would handle this interfacing in a generic manner for the majority of applications.
We believe, however, a series of transaction-building libraries will provide a clearer path forward. Using our Cardano-Transaction-Library (CTL), developers will be able to mix and match tools that, when configured appropriately, will help streamline transaction creation and maintenance in browser-based or javascript environments (e.g., mobile, server). More concretely, the CTL will perform the heavy lifting of building transactions to meet the requirements of a smart contract – typically non-trivial – while automating more generic effects such as balancing transactions.
Cardano-Serialization-Library vs Cardano-Transaction-Library
The Cardano-Serialization-Library (CSL) is a popular tool among dApp developers. As described in the documentation, it "is a library, written in Rust, for serialization & deserialization of data structures used in Cardano's Haskell implementation of Alonzo along with useful utility functions." Essentially, the library supports the serialization and deserialization of data structures included in Cardano transactions so that they can be submitted against the blockchain efficiently. It also provides various wallet utilities for generating keys and addresses, managing the minutiae of transaction creation, handling metadata, and so on.
That said, the CSL has limitations and pain points remain. The CTL seeks to address these and utilizes the CSL in so doing. The CTL, however, is in general a higher-level solution that automates transaction creation by querying the blockchain, via Ogmios, to gather the necessary information. It also abstracts over the wallet, meaning developers need only rely on declarative API function calls without worrying about the specifics of individual light clients. Overall, CTL relies on these tools as it aims to provide an all-encompassing solution for building/submitting transactions and interacting with wallets.
-Working with type differences across Plutus and the CSL. For instance, unifying the data expressions across Plutus, Purescript, and Rust to be uniform.
-Accounting for Javascript 'quirks' to produce reliable constructions for transactions.
-A large part of this effort also deals with representing staking at a high level. This is challenging due to the intricacies of Addresses on the Cardano Ledger which, for instance, may or may not include staking credentials. However, this functionality will pave the way to incorporating Stake Validators into the functionality of dApps. This has implications for DAO treasuries, ADA-backed stablecoins, and more.
-Reconciling differences in UTXO management across different wallets, especially with respect to balancing transactions.
(Note: we have already begun addressing these issues and have made some early progress).
[FEASIBILITY]
Our Proposal
We aim to deliver Cardano-Tx-Lib over an abbreviated period and iterate upon its functionality as we integrate browser-based wallets existing within the ecosystem. Largely, this involves building a PureScript SDK for processing queries through Ogmios, and we will establish a baseline of functionality first by working with Nami.
Developers will be able to use our library to:
-create responsive web3 applications
-query and process on-chain data through the browser
-efficiently build, balance, and sign transactions via browser wallets
-expedite their off-chain development
-easily convert PAB endpoint code to our SDK code
-support many major wallets
-build 'decentralized infrastructure' where SPOs are able to run a decentralized network of query and submit APIs
Funding:
Engineering hours: 888
Total: $71,000
Breakdown:
Feature Total Time
Initial Exploration and Building a Testing Framework …………………………………..40
PureScript bridge and Basic Query Types …………………………………………………80
Contract-style Interface and Effective Error Handling………………………………..100
Incorporating Full EUTXO (Datums, etc) into Transaction Builds………………….100
Integration with Other Browser-based Wallets……………………………………………160
Documentation and Training Materials………………………………………………………40
General Testing………………………………………………………………………………………..80
Audit Prep………………………………………………………………………………………………..80
Spec………………………………………………………………………………………………………..80
Subtotal…………………………………………………………………………………………………..760
Change Budget………………………………………………………………………………………..128
Total Time………………………………………………………………………………………………..888 hours
Total Cost $71,000
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. We employ over 80 developers and have helped build community projects such as:
-Liqwid
-SundaeSwap
-Ardana
-Optim
-Many others
Through our work with early-stage projects, we have one of the largest groups of PureScript / Haskell / Plutus developers in the community. Developers working on our Cardano-Tx-Lib will bring their collective experience to the project and ensure a successful launch.
Website: <https://mlabs.city/>
Core Team
Haskell and PureScript Developer
Vladimir Kalnitsky:
Vladimir is a software developer with a few contributions to the PureScript ecosystem and solid experience with Haskell. During his undergraduate years, Vladimir focused on functional programming and type theory. He is now studying for a Master's in BigData and Machine Learning. Vladimir is more of a 'hacker' than a scientist, but he still values formal reasoning about code and well-founded software development practices.
GitHub: <https://github.com/klntsky/>
Haskell, Plutus, and PureScript Developer
Viet Tran:
Viet has an undergraduate and master's degree in Mathematics alongside a Ph.D. in Theoretical Physics. He previously worked as a quant, writing Python/Cython code to model the outcome of sporting events through optimizers, Markov Chains, and various probability distributions. He acquired an interest in category theory, functional programming, and blockchain technology in recent years. He has 12 months of experience in Haskell, Plutus, and Purescript combined.
GitHub: <https://github.com/vvtran>
Delivery Manager
Rory Tyler Hayford:
Rory is a linguist-turned-developer and programming polyglot. His development career began with the web, and he has experience with both backend and frontend development. His initial forays into functional programming several years ago soon turned into a profound and lasting passion. He has a strong background in functional programming and reproducible build systems with a focus on Haskell, Nix, and Purescript. He is also the author of a handful of open-source Haskell libraries.
GitHub: <https://github.com/ngua>
[AUDITABILITY]
Intended Fund – Fund8: Developer Ecosystem
Challenge Statement: “How can we create a positive developer experience that helps the developer focus on building successful apps?”
Project Impact: High
-
Usability: our libraries will help developers create the browser-based applications and UX that blockchain users expect of web
-
Open Source Tooling: Cardano-Tx-Lib will be open source and freely available for developers to use
-
Cost-Effective Development: dApps running on Cardano require substantial off-chain infrastructure in order to function efficiently and reliably. The CTL will substantially reduce this burden
KPIs (Key Performance Indicators)
-Peer-to-peer transactions successfully executed
-Tx automatically balanced from wallet UTXOs
-Reduced off-chain development time
-Full EUTXO support
-Number of wallets supported
Auditability
-General GitHub activity (https://github.com/Plutonomicon/cardano-browser-tx)
-Pull requests and resolved issues
-Streamlined transaction building for smart contract interactions
-Number of browser wallets supported
-External projects incorporating our library
-JavaScript API and accompanying usage examples
-Perform fee and execution unit estimates
-Plutus contract parameter application on the frontend (this removes a piece of centralization)
3 Months: Establish a baseline of functionality using Nami. This includes parsing Ogmios JSON objects, p2p transactions, and so on.
6 Months: Serializing / deserializing datums, script lookups and incorporating script interactions, submitting transactions against basic smart contracts (e.g. escrows, vesting contracts, etc.)
12 Months: Integrations with other browser-based wallets (Gero, Yoroi, etc.), documentation and educational tutorials, implementing other nice-to-haves.
This is a new proposal
