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).