Understanding the Composability of Applications on Cardano

Cardano supports composability for its applications, by the two-layer architecture but mainly by the modular approach to smart contracts. Come read more about it. In the article, you will also learn more about scalability and parallelism. In conclusion, we will do a quick comparison of Cardano with Ethereum with regard to composability.

What is Composability

Composability is a term that refers to the ability of different applications or components to work together and build on each other, creating new and more complex functionalities. Composability is often considered a desirable feature for decentralized applications (DApps), especially in the field of decentralized finance (DeFi), where users can combine different protocols or services to create new financial products or markets.

Composability enables third-party developers to connect their applications and bring new solutions to market. Combining two (or more) applications together can allow users to interact with all services through a single interface. A single application interface will allow access to all services of all composed applications.

For example, a DEX and a lending platform can be composed. Or you can compose two DEXs together.

Users can thus have access to more pools, more tokens, more liquidity, etc. DEXes can share orders and the market value of tokens (Oracles), etc. This increases efficiency, profitability, and users’ satisfaction.

In the image below you can see that the teams of two DEXes agreed to cooperate and composed their applications together. The user has access to the liquidity pools of both DEXes through a single interface of any DEX.

Composability also has disadvantages. By composing applications, mutual dependence is created.

Composability introduces complexity, as it requires more coordination and synchronization between different applications or components, which may have different interfaces, data types, or protocols.

Composability might reduce security, as it exposes applications or components to more risks or threats from each other, such as conflicts, failures, attacks, or vulnerabilities. If one app gets hacked, it can cause problems for the other app.

It must be noted that DeFi services are economically interconnected. For example, lending platforms can use stablecoins issued by other applications. If stablecoins are de-pegged for some reason, users of the lending platform will be affected.

Despite the risks, composability is a desirable feature because it improves the user experience and supports innovations.

Cardano enables composability for its DApps by allowing them to:

• Sharing data and value across different smart contracts or chains, without creating conflicts or failures.
• Running (executing) multiple smart contracts in parallel, without affecting or being affected by each other.
• Connecting and interoperating with other platforms or protocols, such as Ethereum or Bitcoin.

Cardano supports composability for its DApps (or just applications) at the ledger level, namely by an extended UTXO model that allows for parallel execution of smart contracts. Cardano is designed to have a two-layer architecture, where the settlement layer handles the transfer of value, and the computation layer handles the execution of smart contracts. Further, the functionality of smart contracts can be split into on-chain and off-chain logic.

The Two-Layer Architecture of Cardano

In order to properly understand composability, it is important to understand the Cardano two-layer architecture and the way in which the result of the action of the smart contract is stored in the ledger.

There is a connection between the execution of the smart contract (regardless of where it is executed) and the permanent storage of the result in the ledger. Almost every single component of a blockchain platform affects the overall quality of composability (but also scalability, security, etc.).

Cardano aims to provide more scalability, security, and sustainability than other platforms, by using a novel design that separates the core functions of the platform into two distinct layers: the Cardano Settlement Layer (CSL) and the Cardano Computation Layer (CCL). This design has a certain impact on composability.

The CSL is responsible for handling the transfer of value, such as ADA or other native tokens, between users or smart contracts. The CSL is based on an extended UTXO model, which ensures that transactions are deterministic and predictable. Importantly, it allows for parallel execution of smart contracts.

An Ouroboros Proof-of-Stake consensus is implemented in CSL.

The CCL is responsible for handling the execution of smart contracts, such as Plutus or Marlowe scripts (validator scripts, minting policies, etc.), that define the logic and rules of the applications. The CCL is based on a functional programming language, called Plutus Core, which runs on the Cardano Virtual Machine (CVM).

The CCL supports multiple programming languages, such as Plutus, Marlowe, Glow, Aiken, etc., which can be compiled into Plutus Core and run on the CVM.

The two-layer architecture of Cardano has several advantages over other platforms that use a single-layer architecture, such as Ethereum.

The two-layer architecture allows for more flexibility and innovation, as each layer can be updated and modified independently, without affecting the other layer. For example, the CSL can change its consensus protocol or token model, without affecting the CCL. Similarly, the CCL can change (or upgrade) its smart contract language or execution environment without affecting the CSL.

On the other hand, this architecture brings complexity and reduces usability as it requires more coordination and synchronization between different layers. For example, the CSL and the CCL have to maintain a consistent view of the ledger state and ensure that transactions are valid and compatible across both layers. Reduced usability requires more steps and tools for users or developers to access or interact with different layers.

The two-layer architecture improves the scalability of the platform, as it reduces the load on the blockchain and allows for parallel execution of smart contracts. For example, the CSL only has to validate transactions that involve the transfer of value, not the execution of smart contracts. Similarly, the CCL can run multiple smart contracts in parallel, for example on different sidechains, without interfering with each other.

The two-layer architecture of Cardano enables the composability of smart contracts by allowing them to interact and cooperate with each other on the blockchain.

Imagine token A minted by smart contract (minting policy) As and token B minted through Bs. Another smart contract that implements a swap can use both A and B tokens. In this case, smart contracts do not directly interact with each other (they are not composed), but tokens are shared between different smart contracts. We can talk about composability at the level of assets.

Cardano allows composability primarily through the modular approach to smart contracts. That is, through the division of the smart contract into on-chain and off-chain logic. We will talk about this in more detail later.

Plutus scripts (validators) are executed by the Cardano Virtual Machine in the CCL. The CCL interacts with the CSL, which is the layer that only handles the transfer of value, such as ADA or other native tokens, between users or smart contracts. The CSL validates and stores the transactions that involve the transfer of value on the blockchain.

CSL works only with the output of smart contracts (boolean value True or False). Assets can only be spent (unlocked) from an address (script address) if the return value is True. The CSL does not execute or validate the smart contracts themselves but only checks whether they have been executed and validated by the CCL and the return value. CSL accepts or rejects the transaction based on the boolean value.

In the picture below you can see CSL and CCL. Furthermore, a smart contract that is divided into on-chain and off-chain logic. On-chain logic is executed by CVM while off-chain logic can be executed on the server or the user's local computer. If the return value of the validator script is True, the transaction is written to the ledger in CSL.

Many applications (Plutus scripts) can use the CSL in parallel. UTXO model ensures that transactions are deterministic and predictable, and do not depend on the global state of the ledger or other transactions. Therefore, different transactions or smart contracts can be executed in parallel without interfering with each other, as long as they do not spend the same UTXOs.

Parallelism of the UTxO model helps composability because it allows smart contracts to interact and cooperate with each other on the blockchain, without creating conflicts or failures. For example, a smart contract that implements a token can be used by another smart contract that implements a swap, a lending platform, or an auction. The UTxO model can process these transactions in parallel, without creating conflicts or failures.

Modular Approach to Smart Contracts

Cardano uses a modular approach, where smart contracts consist of two components: on-chain code and off-chain code. Cardano allows the composability of applications through both on-chain and off-chain parts of smart contracts. If you want to learn more about how smart contracts work on Cardano, read our article on this topic. You can skip the chapter about Bitcoin and Ethereum.

On-chain code is a script that runs on the blockchain (CCL) to validate transactions that involve the smart contract. It is usually a simple code that unlocks funds on the script address.

Off-chain code might be a complex application that runs on the user’s machine or server to generate transactions (both the transactions with scripts and spending transactions) that conform to the smart contract logic. This brings enormous flexibility, but higher complexity poses risks. This stems, for example, from the fact that to execute the logic of the smart contract, it is necessary to use multiple execution environments, for example, the Java Virtual Machine (on the server) and the Cardano Virtual Machine on the blockchain (in the CCL).

The modular approach allows for more efficiency and scalability, as most of the smart contract logic is executed off-chain, reducing the load and cost on the blockchain. Composability on the Plutus script (validator) level is possible, but not as straightforward as composability on the off-chain logic level.

Composability on the Plutus script level means that different on-chain parts of smart contracts can interact and cooperate with each other on the blockchain (in CCL), creating new and more complex functionalities. This approach is usually avoided by developers as it presents a challenge. Different smart contracts may have different interfaces, data types, or protocols, which may make them incompatible or inconsistent with each other. Standardization and unification of approaches could help developers to achieve composability.

Different smart contracts may have different states, dependencies, or constraints, which may make them difficult or impossible to coordinate or synchronize with each other. To achieve composability on the validator script level, smart contracts have to use some mechanisms or techniques to communicate and align their states, dependencies, or constraints. However, this would very likely require the cooperation of teams at the very beginning of application development or later re-implementation of the validators.

Fortunately, it is not necessary for applications (smart contracts) to interact at the level of validators (on-chain logic). It's much simpler at the off-chain logic level.

When designing off-chain logic, developers are only minimally limited by the requirements of on-chain logic. They can essentially design functionality with composability in mind.

Developers can use any programming language, framework, or existing standards to create the off-chain part of the smart contract. The only thing they have to ensure is the interaction with the Cardano node API.

Different off-chain applications can freely interact with each other without affecting other off-chain applications. Connecting apps at this level is very easy and not a big challenge for the average developer.

The result of the interaction of the off-chain parts of the application will be reflected in the on-chain parts. In the end, the result must be recorded in the ledger through validators. In other words, the off-chain interaction between applications must result in the construction of a spending transaction that unlocks the funds that are locked by the validator.

It can be said that the scalability and computational complexity of applications are almost unlimited at the level of off-chain parts of smart contracts. The bottleneck is the block size.

CSL enables parallel processing of transactions (UTxO model). CCL enables parallel execution of smart contracts. Parallel execution of smart contracts means that different smart contracts can be executed in parallel without affecting or being affected by each other, as long as they do not interact with the same UTxOs. If the output of the on-chain part of the smart contract is True, it is necessary to store the transaction in the blockchain, i.e. get it into the next block.

In the image below you can see how two off-chain parts of smart contracts communicate with each other (green arrow). The off-chain part of the applications is deliberately larger in the picture, which indicates that more complex logic is implemented there. On-chain parts of smart contracts can also communicate with each other (red arrow). The picture also shows how the result of the interaction between smart contracts results in the creation of two spending transactions that are written into the ledger (blue arrows). Spending transactions unlocked funds on the script addresses (transactions with scripts have been already stored in the ledger).

DeFi builders can create composable applications on Cardano. However, there are also some challenges and limitations that need to be addressed to achieve full composability.

• The compatibility and standardization of smart contract languages and interfaces.
• The usability and accessibility of applications. Users might need to have multiple wallets or accounts to access different applications.

Conclusion

A monolithic approach to smart contracts that Ethereum employs has advantages in terms of security and simplicity, but disadvantages in terms of scalability and flexibility. Cardano employs a modular approach to smart contracts. It has advantages in terms of scalability and flexibility, but disadvantages in terms of security and complexity.

A monolithic approach can lead to high fees and congestion, which can hamper the performance and usability of the smart contracts. The functionality of all contracts consumes the computational resources of the distributed network. It is not possible to perform part of the functionality off-chain. Applications are less flexible because they are limited by what the platform offers. On the other hand, this can also be an advantage, as the applications are (relatively) simple. All functionality of smart contracts is written in Solidity (or Vyper). This is also advantageous from a security point of view, as all the transactions and smart contracts are validated by the same consensus mechanism and executed by the same virtual machine.

From my point of view, the biggest disadvantage of Ethereum is the need to execute smart contracts sequentially. This limitation stems from the use of an account-based model.

A modular approach can achieve higher scalability, as different modules or layers can handle different tasks in parallel or asynchronously. This can reduce network load and users can pay lower fees as less distributed computational resources are consumed. The modular approach enables the creation of more complex and diverse smart contracts. However, it can introduce security risks, as different modules or layers may have different levels of trust and verification. Higher flexibility and unlimited options for developers can lead to complexity that can result in vulnerabilities and inconsistencies in the data and logic on the blockchain.

The biggest disadvantage of Cardano is probably low standardization and unification. There are currently several CIPs relating to the implementation of standards. This is partly due to the fact that Cardano is still a young platform.

In the next article, we will compare the composability of applications on Cardano with Ethereum in more detail.