Cardano Smart Contract Composability Challenges
Last updated
Last updated
Composability in the context of decentralized applications (dApps) refers to the ability of different dApps to interact and build upon one another, facilitating the creation of complex, interconnected systems. This feature is central to the success of decentralized ecosystems, enabling innovation and the development of highly integrated solutions.
Ethereum’s EVM (Ethereum Virtual Machine) boasts high composability, allowing developers to reuse code and functionality from existing dApps to create new ones. This fosters a collaborative and interconnected ecosystem. Here’s how it works:
Smart Contract Interaction: Any smart contract on an EVM-compatible blockchain can call any other contract, enabling dApps to share data and functionality effortlessly.
Token Interoperability: Tokens and other blockchain assets can move freely between different dApps, facilitating seamless interactions and value transfers.
Building Blocks: dApps can be constructed from smaller, reusable components, promoting modularity and efficiency.
Benefits of Composability:
Innovation: Composability enables rapid development by allowing developers to build on existing solutions, driving innovation.
Interoperability: It fosters interoperability between dApps and blockchains, creating a more unified Web3 landscape.
Efficiency: Developers can save time and resources by reusing existing code and functionality, avoiding the need to reinvent the wheel.
Examples:
DeFi protocols leverage composability to create complex financial products and services.
dApps can integrate with each other to offer users a more comprehensive and seamless experience.
Open-source code from one project can be reused to develop new dApps, and token interoperability allows for cross-platform interaction.
Despite the growing number of decentralized applications on Cardano, composability remains a significant challenge. This is not an inherent flaw of the Cardano platform but a consequence of its dapps technical design.
Cardano uses the eUTxO (Extended Unspent Transaction Output) model, which, while enhancing security and scalability, presents challenges for dApp interoperability. Unlike Ethereum’s account-based model, where smart contracts can easily interact with one another, Cardano’s EUTxO model tightly couples transaction outputs with specific contracts. This design creates a more complex environment for integrating various dApps.
Furthermore, there are currently limited cross-protocol interoperability standards, such as oracles, that facilitate seamless interactions between Cardano-based dApps. Different projects, like Indigo, Liqwid, and Djed, use their own proprietary oracles with varying standards, while others, such as Orcfax and Charli3, employ their own systems as well. When supporting multiple Oracles, Danogo smart contracts
The Challenge of Batchers in Transaction Processing
When batchers are used to bundle multiple transactions together, they can introduce problems. Each transaction in a batch might depend on others for inputs or outputs, and if one transaction fails, the entire batch fails. This compromises the atomicity that is essential for composability, as dApps may expect operations (such as lending and borrowing in DeFi) to be executed together or not at all.
For example, in a swap transaction that uses a batcher, the transaction is not completed until two batch transactions are finalized. This adds complexity, making it significantly harder for one smart contract to interact with another.
Issues with Payment Key-Based Identification
Another key challenge is the use of payment keys to identify users. Since smart contracts typically rely on a user’s payment key to interact with the contract, this can make it difficult for multiple smart contracts to communicate on behalf of the user.
If one smart contract uses the payment key to identify a user, it may not be able to access or "see" the payment key used by another contract. Cardano smart contracts are generally isolated from each other, and unless they are explicitly designed to interact using common references (such as shared data or tokens), they cannot communicate effectively.
For example, if Liqwid (a lending platform) and Indigo (a synthetic asset platform) both use payment keys for user identification, neither contract can automatically call or interact with the other on behalf of the same user unless the user explicitly authorizes each transaction. This creates friction in composing actions across multiple dApps.
When the payment key is the sole method of user identification, it establishes a direct relationship between the user and the contract, limiting flexibility. Other smart contracts cannot act on behalf of the user unless the user provides explicit consent for each transaction (via a signature). This lack of abstraction between user identity and smart contract logic further hinders composability, especially in DeFi applications, where users expect seamless interactions between lending, borrowing, staking, and other protocols.
Danogo aims to solve several composability issues within Cardano’s ecosystem by implementing a set of innovative strategies:
Open-Source Smart Contracts: Danogo provides fully open-source smart contracts, complete with detailed documentation and guides on Datum. This makes it easier for other smart contracts to interact with Danogo’s ecosystem, fostering interoperability across Cardano-based dApps. If Dapps choose not to opensource, they should at least publish documentation on datum design & documentations.
Standardized Oracles: Danogo will publish the oracle standards used by Djed, Indigo, Liqwid, as well as Orcfax and Charli3. By pushing for the standardization of oracles across the Cardano ecosystem, Danogo aims to simplify the interaction between dApps and ensure smooth, permissionless communication across Cardano ecosystem.
Avoiding Batchers: Danogo’s smart contracts avoid the use of batchers, which can cause UTxO contention. Instead, Danogo employs transaction chaining and queries the mempool directly. This approach minimizes the complexity and potential failure points that arise with batch transactions. With the advent of Layer 2 solutions like Midgards, this issue will become less significant.
Alternative User Identification: Rather than relying on the payment key for user identification, Danogo utilizes fungible tokens (FTs) or non-fungible tokens (NFTs) as a method of receipt for user identification. This allows users to transfer their wallets without disrupting their ability to interact with Danogo’s smart contracts. It also enables any other smart contract to interact directly with Danogo’s ecosystem, without needing user-specific payment key access or explicit permission at every step. (We learnt this design from @zygomev from Optim Labs)
Cardano’s unique EUTxO model provides significant security and scalability benefits but presents challenges for dApp composability. The reliance on payment keys, use of batchers, and lack of interoperability standards make it difficult for Cardano-based dApps to interact with one another seamlessly.
However, Danogo is addressing these issues by creating open-source smart contracts, promoting oracle standardization, avoiding the use of batchers, and introducing flexible user identification methods. These efforts are designed to enhance composability, enabling Cardano’s ecosystem to unlock the potential for more integrated and dynamic dApp interactions, making Cardano a more competitive player in the decentralized space.
