Radix Engine: An Asset-Oriented Smart Contract Alternative
This is part 2 in my series on Radix technology (see parts 1 and 3). I’ve been working closely with Radix and am excited by the approach they are taking to solve many of the real-world DLT development problems I’ve written about in the past.
As we discussed in a previous post, Radix is made of two layers: the Radix Engine and the Radix Ledger. The Radix Engine is the application layer for Radix — the part that developers directly interact with. While similar in concept to the virtual machine provided by smart contract platforms like Ethereum or Hyperledger, the Radix Engine is a paradigm shift from traditional smart contract development.
The Radix Engine makes it possible to rapidly and confidently build applications and business systems that take advantage of the true benefits of DLT — but it requires a bit of a mental shift. This blog post explains a new method to build DLT-based applications with Radix, with far less complexity.
The Importance of Transactional Systems
At the heart of every business is a source of truth. For example, today that source of truth in a bank is often called the “general ledger”. In a manufacturing company, it might be something from SAP. Regardless of what form it takes, the most valuable source of truth answers questions like:
- “What are our customers’ current account balances?”
- “Where are our products located and who has them?”
- “Who authorized these transactions and when?”
An ideal source of truth provides answers that are always correct, and always available. It should provide those answers while handling hundreds, thousands, or millions of simultaneous assets, users, products, or accounts. This is no small ask.
Building a better source of truth means lower operational costs, better risk management, greater capital velocity, creation of interoperable platforms, or even avoiding disaster. These are substantial benefits to companies of almost any size, whether a Fortune 500 enterprise or a disruptive startup — or whether the industry is banking, logistics, medicine, insurance, retail, real estate, or media.
For a system to act as an authoritative source of truth, it cannot be simply a store of the state of the business. It must enforce the business process rules that govern the transactions that create the state of the business. Allow an invalid transaction to slip by and you’ll discover down the road that your “source of truth” is lying to you (an expensive mistake). Therefore a true source of truth must be a robust transactional system that operates the most sensitive parts of the business.
DLT could be used only as a record of the transactions handled in other systems, but this only leverages a small part of DLT’s capabilities. DLT is an inherently transactional technology that is capable, if used fully, of integrating business process enforcement and a store of state to become a complete transactional system. It is an excellent foundation for better sources of truth with all the advantages listed above.
The first DLT transactional system was Bitcoin and is simple: it enforces transactional rules of a “digital cash” source of truth. How do we give DLT developers the tools to build a world of other more complex transactional systems — to create better sources of truth for the world’s businesses and applications?
The Smart Contract Way
Enforcing the transactional rules of a DLT is the role of its application layer. The application layer sits above the ledger layer (such as blockchain) and defines how the DLT is configured and used by developers. It defines what transactions are valid, while the ledger layer resolves any conflicts between transactions and records the final authoritative result. The design of a DLT’s application layer defines what kinds of transactional systems can be built, and the difficulty in doing so.
In Bitcoin’s digital cash application layer, transactions are expressed as changes to “state machines” called UTXO. State machines are powerful because they describe a system in terms of what is allowed to happen, not what is disallowed . In short, rather than running “if-then” checks to doing the wrong thing, state machines simply aren’t capable of doing the wrong thing by their definition. This gives Bitcoin its inherent security as a digital cash source of truth.
Blockchain platforms after Bitcoin sought to generalize Bitcoin’s application layer model to enable application, not just digital cash. Ethereum offered application development via a virtual machine that runs specialized smart contract code, with each smart contract represented in whole as a single complex state machine. In this way, Ethereum creates a “world computer” where computation (‘Turing complete”) is performed as discrete updates to a single state. This same general smart contract model has been adopted by virtually every applications-oriented blockchain today, including private DLTs like Hyperledger.
The smart contract approach, however, introduced a subtle but important change to the security model. Bitcoin UTXO state machines are quite simple and model individual transactions of Bitcoins. But smart contract state machines are more like complex black boxes where we are guaranteed that the code inside the box will be run correctly, but there are no guarantees whatsoever that the code correctly models the behavior you want . We’re back to writing checks where bugs lead to “correct” updates to the state that may be errors just as readily as desired behavior.
While Ethereum-style smart contracts are theoretically powerful, but they place a tremendous burden on the developer. To create the rules for how transactions in an application should behave, the developer is forced to take on the responsibility of implementing and deploying highly-secure smart contract code. For a technology intended for transactional systems where trust and security are key, this is extremely unappealing. Building simple token functionality is workable, but even marginally more complex applications have ended in catastrophic results.
We need a new kind of DLT application layer where transactional systems can be easily defined with the inherent security of Bitcoin’s simple digital cash UTXO. We want to give developers the tools to directly express business-relevant transactional rules that are enforced automatically, rather than creating carefully-crafted smart contract code.
The Radix Engine Way
Bitcoin works as digital cash because its application layer directly models and enforces our expectations for how real-world cash behaves. The Radix Engine simply extends this philosophy and makes it much more customizable for developers.
Let’s revisit the kind of questions a good business source of truth should always be able to answer:
- “What are our customers’ current account balances?”
- “Where are our products located and who has them?”
- “Who authorized these transactions and when?”
For a transactional system to provide these answers, it should directly model the of the business and how they should behave in transactions. These assets could be money, products, authorizations, collectibles, loans, tickets, votes, packets of data, or even identities — whatever must be transacted and managed correctly.
The native language of development on top of the Radix Engine , and development on Radix starts not with smart contract code, but with defining the assets of the desired transactional system — in short, clearly defining the business need. By making the assets of the business the basic building blocks for development using the Radix Engine, Radix transactions become intuitive:
- Move money between customer accounts ( if sufficient balance is available)
- Manage a shipment of products between carriers ( if the chain of custody is followed)
- Process a transaction at the current time ( if the requester has the proper authorization)
The “if” constraints should be inherent in the definition of the assets: is an asset that is only movable if available; are assets that can only change custody to the correct next along a chain; certain transactions of a type may require specific and time-stamped approval by authorized users .
The Radix Engine allows developers to easily map business assets to pre-built Radix components. Radix provides (and continues to develop) a variety of customizable components to let developers define assets that match real-world transactional system needs. These building-block style components are packaged into the Radix Engine Library that runs within the Radix Engine on Radix network nodes.
The customization of the component defines its rules: who can create or destroy it, who (or what other system) can own or control it, what steps must it follow, or how it depends on other assets. We’ve found that a few well-designed components like these can model a near-universal set of transactional systems. We will discuss how to model the wide range of DLT use cases in a later post.
Once assets are configured and issued, Radix transactions using them look similar to intuitive business-relevant transaction requests, like those above. The Radix Engine automatically ensures that only valid transactions that follow the rules of all assets involved are accepted. Valid transactions are then handled by the Radix Ledger to resolve conflicts and commit the final update to the state of the source of truth.
Defining, issuing, managing, and transacting Radix Engine assets are all provided through the Radix API. Radix libraries in commonly-used languages like Java and Javascript make it as easy as possible to use the Radix API. No smart contract code is required.
The Radix Engine’s “asset-oriented” approach to DLT application development has multiple benefits.
Development is greatly simplified. Developers can focus on modeling the behavior of the business process that must be enforced, rather than building it from scratch in a general-purpose programming language.
The resulting transactional system is a more inherently secure source of truth. Correct enforcement of business process is built into in the definitions of native assets — not a function of careful checks in smart contract code. Only correct behavior of our assets is possible, and so the correctness of the source of truth is guaranteed by the DLT.
DLT applications are more composable. Because functionality is expressed in terms of assets that model things the business cares about, new functionality can intuitively be composed from these existing assets without modifying a smart contract black box. The ability to build unanticipated functionality with existing components is incredibly powerful and will be discussed further in a later post .
The result is an inherently simple and direct method of defining a transactional system that is an ironclad source of truth for the business. A traditional database system delivering this kind of functionality, for a business of any scale, is typically the subject of a team of professionals who build, maintain, debug, and audit it. The Radix Engine eliminates the great majority of the development and risk of achieving such a system, while its ledger allows the system to run securely with massive scale, redundancy, and concurrency without refactoring core application code.
How does the Radix Engine Work?
Beneath the Radix API, the Radix Engine expresses all of these assets and transactions as discrete state machines — all of which automatically and individually have the kind of guaranteed validity as Bitcoin’s UTXO state machine-based transactions. We call this the “atom model“, where “atoms” are requested transactions that contain multiple “particles” that will — if everything is valid and non-conflicting — individually update all of the state machines that represent the assets of the business. The asset-modeling components provided in the Radix Engine library are expressed, under the hood, through these particle state machines.
In most cases, Radix Engine Library components are sufficient to model the most common assets of a transactional system. However if greater customization is required by more advanced developers, new asset types can be built and deployed within the Radix Engine Library as custom particles and constraint machines (the rules that define valid particle state changes).
To learn more, see the Radix knowledge base where we describe how the Radix Engine uses constraint machines to achieve security, composability and scalability.
Originally published at https://www.radixdlt.com on November 22, 2019.
