In our last post, we described how the Radix Engine, as part of the Radix technology stack, provides breakthrough buildability by taking an “asset-oriented” approach to DLT development, rather than today’s typical smart contracts. This approach is not just easier – but improves the quality of the result. An excellent example of this is in how Radix enables much better “composability” of DLT applications.

Composability is one of the most powerful concepts in software architecture, and has recently become a topic of debate in the DLT world. Some have begun to worry that Ethereum may not be as composable as many developers desire, and that sharding Ethereum to increase its throughput may make the problem even worse.

Poor smart contract composability may in fact be a critical factor in DLT’s failure to reach broad adoption in applications today. What exactly is composability and why does it matter?

Composability Created the Modern Web

Let’s start with a composability success story that arguably underpins much of the Internet’s usage today.

The Internet and the Web (the HTTP protocol) gave us a communications layer where users and companies could communicate freely. But for many years, “applications” on the Web were mostly islands of data: a user could request a webpage and interact with it in only very particular ways (via further requests). Communication between applications was rare because integrations required creating specialized interfaces. HTTP on its own was like an open bazaar where merchants could speak, but where a thousand languages were spoken, making communication between them difficult or practically impossible.

For the Web to reach its full potential, this barrier had to be broken down; developers needed more than just bare HTTP. They needed a simple lingua franca (a concise bridge language for a specific purpose) that speaks in simple terms about what HTTP is best for: sending and receiving messages. A new way of using HTTP called REST finally provided the right lingua franca for the task, making very different applications look simply like receivers and senders of messages using the same type of interface. Suddenly interoperability between applications became native, easy, intuitive. Innovation on the Web thrived as a result.

How did REST accomplish this? It established a simple set of message-oriented components. These components encouraged developers to think of their application’s functionality in terms of the simple messages that it can send and receive. Any application offering such a “RESTful API” is abstracted as a “service” (thus today’s common “software as a service” cloud offering). Any developer can rapidly make use of – and combine – RESTful services, no matter how complex the service is on the inside.

Composable development of message-oriented functionality using RESTful API endpointsThis makes RESTful services highly composable; a developer can create a new application that easily composes existing RESTful services together to create new systems and functionality that was never anticipated by the service providers. (This has become the primary business model of many enormously successful “solution integrator” companies today.)

This approach is useful not just on the open Web, but inside companies as well. The concept of “microservices” has captured much of backend systems development by taking a very similar approach to REST. Backend functionality is packaged up behind simple abstracted messaging APIs, enabling quick integration and the predictable addition of new and unplanned functionality in the future.

The Problem with Composable Smart Contracts

The common assumption in the blockchain and DLT world today is that DLT applications must be built using smart contracts, each representing a black box of functionality. Here “composability” takes the form of communication between smart contracts that accept and act on on-chain (or on-ledger) messages. This is remarkably similar to the composability model of REST for the Web – simply moved onto a blockchain or other DLT.

Typical DLT smart contracts encourage a message-oriented pattern of interoperability similar to the Web

‍This seems intuitive on the surface, but forcing the message-oriented model of composability onto a fundamentally different technology and set of needs presents difficulties for developers. Remember that the right lingua franca must be designed for the specific type of problem the developer is trying to solve with the technology. When composing web-based data services, the message-oriented model matches developer expectations – but when composing DLT-based transactions, it breaks down as we shall see.

Take, as a simplified example, the “train-and-hotel problem” often cited in discussions of composability in the Ethereum community today. In this example, a traveler wishes to buy both a train ticket and a hotel room at the destination – but wants to buy neither ticket nor room if either one isn’t available. In the smart contract model, train tickets, hotel reservations, and money are provided by independent smart contracts, each with messaging interfaces.

The messaging connections a developer must manage to perform a single “train-and-hotel” transaction

‍The developer would prefer to think of this as a single transaction. However using a message-oriented model, the transaction must be constructed in terms of a multi-step escrow process. “Debit” and “credit” messages create “receipt” messages that can be passed around, ensuring that the money isn’t committed in the separate train and hotel smart contracts until both train and hotel respond that they are willing to do the sale. This is the method of composability recommended for Ethereum.

Example of composable smart contract messaging, from the Ethereum wikiThe train-and-hotel problem is extremely simple, but is already unwieldy to the developer who just wants a single transaction. Imagine trying to compose complex transactions between, say, multiple financial service providers – each having to build safe debit/credit/receipt support into their smart contracts – where real money is at stake.

The more smart contract services a developer wishes to compose together, the more messages must be orchestrated, and the more burden to the developer. This is clearly not particularly composable functionality.Recently, there has been an additional debate in the Ethereum community around composability. Developers would prefer that the required request/receipt messages are all passed quickly and synchronously, functioning effectively as a single system. However, Eth2 proposed state sharding would force smart contracts to live on different shards and therefore messages passed between them would be asynchronous.

While the message-oriented composability model would still function, sharding would add further developer burden and increase transactional latencies.Overall, the assumed smart contract method attempts to unnaturally force DLT into the mold of a different technology. Unlocking the full potential of DLT requires a new pattern that encourages developers to think of their DLT-based application in terms of components that suit the technology.

Asset-Oriented Composability for DLT

As the REST example shows us, to make DLT truly composable, we need a native lingua franca that uses simple components to encourage developers “speak” in direct terms about what DLT is best suited for. The Web is a technology of communication that needed a language of messages. DLT is a technology of transactions that requires a new language of assets to make interoperability between DLT applications native, easy, and intuitive.

Whether we’re talking about cryptocurrencies or bonds issuance, CryptoKitties or real-time supply chains, DeFi or IoT, self-sovereign identity or national elections – all of these applications intuitively break down into transactions of assets like coins, bonds, collectibles, products, loans, data packets, identities, or votes. The DLT’s job should be to conduct transactions according to each asset’s unique rules that model developers’ expectations for how they should behave.

To use the train-and-hotel example, truly composable DLT applications would let a developer compose a single transaction across businesses that simply says: “buy a train ticket and this hotel room, using my money.” The language shouldn’t be messages, it should tickets, rooms, and money. Businesses and their applications then become issuers, specifying the rules that their assets must follow, such as “train tickets are non-transferable assets that are made available when purchasable and have an associated price in a given currency”.

With self-enforcing assets issued on DLT, composing new functionality across businesses, like our train-and-hotel purchase, is simple and direct. A developer may request a single, intuitive, “atomic” transaction that includes both the ticket and room, using the appropriate currency for each, even though the assets are defined and controlled by different issuers. The DLT can then correctly accept or reject the entire requested transaction at once, as the developer desires, without any special developer effort.

Performing the “train-and-hotel” transaction across businesses in a single, intuitive stepWe can imagine much more complex composed functionality. Perhaps an application wishes to use dozens of assets spread across many issuers, mixing and building on top of interoperable representations of their userbases and products. Perhaps these assets may sometimes be controlled by complex “off-ledger” functionality in business back-end systems. The composable interface is still just the assets, and each transaction requested by the developer is just as simple.

As with REST, this approach is useful not just for transactional systems on public or consortium DLT platforms, but for private deployments as well. This is because composability of assets allows integration of not just multiple businesses – but enables multiple systems within a complex business to share a single “source of truth”, and build new functionality on top of it. For example, a business could rapidly build an internal cross-department accounting system, and could later expand that into a customer payments platform without refactoring their entire back-end. True composability makes DLT a powerful next-generation integration technology.

The Movement to Natively Composable DLT

As with the Web, reaching DLT’s full potential requires rethinking the DLT application development paradigm from developer’s perspective where composability is key. Some DLT platforms are starting to recognize this need and taking an asset-oriented approach. Stellar focuses on issuance and management of fiat-backed assets by financial service providers. NEM provides simple token and multi-sig account features that can model many types of assets. Algorand’s latest update offers a native, flexible “Standard Assets” layer. Even Libra’s Move smart contract language is based on the creation of “resources” that model basic asset behavior.

As we described in our last post, Radix and its Radix Engine is designed from the start around a powerful, natively asset-oriented approach. It provides built-in components that enable the developer to express their application needs in terms of business-relevant assets that are handled as first-class citizens by Radix. We believe this makes Radix the most natural platform for practical, secure, and natively composable DLT applications for real-world use cases. And the hand-in-glove design of Radix Engine and Ledger allows the resulting solutions to scale to the throughputs we expect highly-composable DLT usage will demand.