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.

THE MEME STUDIO | Web3 Marketing Agency

Page Sponsor: The Meme Studio: Web3 Marketing Agency

Radix Founder Demonstrates Cross-Shard Atomic Composability

Radix Founder Demonstrates Cross-Shard Atomic Composability

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:

1. 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.
2. 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:

1. Support an almost infinite number of shards for maximum parallelism.
2. Develop a consensus protocol capable of dynamically handling atomic transactions across necessary shards without causing network delays.
3. 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: