Atomic Composability [ /əˈtɑmɪk kəmˌpoʊzəˈbɪlɪti/ ], sometimes called Synchronous Composability, is the ability to execute multiple operations across separate applications in a single transaction, without the risk of a partial failure, such that complex, multi-party transactions are either executed successfully or rolled back to their original state without data loss or inconsistency.
- Composability
- Atomicity
- Importance in Decentralized Systems
- Atomic Composability in Radix
- Challenges and Criticisms
Composability
Composability is the ability to recombine components within a system into larger structures and for the output of one to be the input of another. It is a sub-class of interoperability but confined to components within a system rather than between systems.
The concept of composability can be divided into high level ‘syntactic composability’ and low level ‘morphological composability’.
- Syntactic Composability can be likened to the grammar of a system and is the design principle that enables Lego pieces to fit together, or smart contracts on a decentralized ledger to permissionlessly call each other’s methods.
- Morphological Composability ensures that the internal structures of components within a system, such as functions and interfaces are compatible with those of other components. An example of this is the ERC20 token standard on Ethereum, which ensures that tokens are formatted in the same way across smart contracts.
Distinctions
- Modularity is a prerequisite for composability but is a distinct concept. Modularity is the design principle that divides a system into smaller parts or modules, but it does not prescribe the relationships between them.
- Integration is the process of orchestrating multiple components into a cohesive entity that is greater than the sum of its parts. An example would be combining words into a novel or separate business functions into a corporation.
Atomicity
Atomicity is one of the four ‘ACID’ attributes of reliable database transactions, along with Consistency, Isolation and Durability. In this context, atomicity means that all transactions are treated as a single, indivisible unit, regardless of how many operations they encompass. This implies two things:
- All or Nothing: If all operations in a transaction complete successfully, the transaction is considered committed. If any of the operations fail, the entire transaction is rolled back to its previous state, ensuring that the database remains unchanged.
- Undivisible Operations: Once a transaction is committed, it appears as a single operation, meaning there's no way to identify the sequence of operations that took place during that transaction from the perspective of other concurrent transactions.
Atomicity in this context relates to both syntactic and morphological qualities of the term.
Importance in Decentralized Systems
Atomic composability is deemed crucial to decentralized finance (DeFi) because it allows for operations such as flash loans, where an asset is borrowed, invested, and paid back within a single transaction.
Research by RDX Works has found that 69% of all Ethereum transactions utilize some degree of atomic composability.
In the context of decentralized systems, atomic composability is important for the following reasons:
- Consistency: Ensures that the decentralized system maintains a consistent state, especially when dealing with complex, interrelated transactions.
- Trust: Users of the system can be confident that their transactions will either complete in their entirety or fail without partial effects.
- Efficiency: Reduces the need for manual intervention or complicated recovery mechanisms to handle partial failures.
Atomic Composability in Radix
Radix has prioritized atomic composability by embracing three principles:
- Support an almost infinite number of shards for maximum parallelism.
- Develop a consensus protocol capable of dynamically handling atomic transactions across necessary shards without causing network delays.
- Design an application layer efficient enough to make use of this enormous shard space and consensus mechanism.
These design choices have been implemented in the following ways:
Pre-Sharded State Model
Radix’s consensus protocol, Cerberus, is designed around the concept of "pre-sharding." It differs from conventional sharding methods by beginning with the partitioning of the ledger into an extensive "shard space." The algorithm allows for a flexible consensus across any number of shards.
Partial Ordering
Traditional DLTs operate on global ordering, placing all transactions on one timeline. Cerberus enhances this concept by letting each transaction specify which shards are relevant to it.
Braiding BFT-Style Consensus
Radix employs a new form of consensus called “braiding”. This method involves intertwining various instances (shards) in a transaction. This combination creates a synchronized, reliable multi-shard transaction.
dApps and Smart Contracts Scaling
For optimal scalability, understanding the relationship between the consensus layer and the application layer is essential. The application layer sets the network's capabilities. Radix Engine determines the substates and relevant substates in a given transaction.
Radix Engine Design Choices
- Global Object Tokens: Radix considers tokens as global objects at the platform level, optimizing the movement of assets.
- Intent-Based Transactions: Transactions on Radix specify intentions rather than explicit actions. For example, rather than specifying particular tokens for a trade, the intention of exchanging a quantity is indicated.
- Single Shard Smart Contracts: Each smart contract (or “component”) on Radix is allocated to a single shard. This ensures optimized, uninterrupted functioning.
Unlimited dApp Throughput
Radix's design aims to offer unlimited throughput for an ecosystem of DeFi dApps. Its system contrasts with Ethereum's, where dApps have limited throughput due to a slow global consensus process. Conversely, Radix's combination of the Radix Engine and Cerberus achieves high parallelism, ensuring optimized transactions and maximum efficiency.
Challenges and Criticisms
Atomic composability, while powerful, is not without challenges:
- Performance Overhead: Ensuring atomicity, especially in a distributed setting, can introduce performance overhead due to the need for synchronization mechanisms.
- Complexity: Implementing atomic composability might complicate system design or make certain transaction types more challenging to execute.
- Scalability Concerns: As systems scale, maintaining atomic composability across a growing number of nodes or transactions can pose scalability challenges.
Critics have also pointed out that while atomic composability is a valuable feature, it may not always be necessary for all types of transactions, especially simpler ones. Balancing the needs for atomicity with system performance and simplicity is a key consideration.