XRDBTC
XRD / Bitcoin
crypto

Radix is a layer-1 focused on building the infrastructure to take DeFi mainsteam. Radix uses a proprietary programming language called Scrypto which claims through asset-oriented programming, to eliminate the possibility of hacks and exploits while reducing the development time needed. Radix utilizes Cerberus consensus to maintain cross-shard DeFi composability. The Radix Network primarily relies on three key technological features, specifically the Scrypto programming language, the Cerberus consensus algorithm and the Radix Engine. Scrypto Scrypto is Radix's custom-built asset-oriented programming language for DeFi that aims to make developing DeFi intuitive. Scrypto is used to develop on-ledger smart contract "blueprints", which can be thought of as generic templates for common functionality, for example a "token" blueprint provides the basic functionality of a token. Those blueprints can then be instantiated on-ledger into smart contract "components", for example taking the token blueprint and instantiating a token component that has specific properties, such as max supply, etc. There will also be a Blueprint Catalog that developers can add to and browse, allowing them to extend existing blueprints, or insatiate components out of them. Cerberus Consensus Algorithm Cerberus is Radix's consensus algorithm that takes a different approach to sharding (a scaling solution for blockchains based on parallel computation). Cerberus combines three core insights to provide a theoretically infinitely scalable and atomically composable consensus protocol: It uses partial transaction ordering over the commonly used global ordering. In the latter, all transactions must be placed on the same timeline. Cerberus presumes that each transaction can specify precisely which shards are relevant (and thus must be ordered) for a specific transaction. This requires a specialized application layer that can specify how shards are used and relate to each other. The ability to identify only relevant shards enables Cerberus to employ a new form of BFT (Byzantine Fault Tolerant) style consensus, which Radix calls "braiding." Typical BFT-style consensus mechanisms use two or three phases of signed commitments between nodes to finalize a transaction. Cerberus' braided consensus runs a single three-phase BFT instance (called a "3-chain") within each shard, but braids these instances together with commitments provided by the leaders of the other related shards. This approach allows all relevant shards to atomically commit to a transaction that might pass through multiple shards. Cerberus allows its "3-chain" or "3-braid" consensus processes to run in parallel. Each shard can reach consensus independently as needed for a given transaction. Radix Engine v2 The Radix Engine is the network's development environment that allows for the creation of smart contract logic and decentralized applications. This engine is a form of programmability based on Finite State Machines (FSMs), a class of solutions that is common in systems where predictable correctness is a top priority. To make clear the difference from traditional Ethereum-style smart contracts, Radix gives Radix Engine smart contracts a name more suggestive of their function: Components. Components attempt to more closely model real-world expectations for finance. They are built from finite state machine logic, and define their behavior by "Actions" that directly translate a discrete existing input (or "before") state to an output (or "after") state. More concretely, this means that Components are defined by what it is possible for that Component to do via its Actions. By defining Components by their Actions in this way, Components potentially gain two important attributes when trying to avoid bad results: First, Components can behave more like finance building-block "primitives", rather than as black boxes, a precursor for application composability. Second, the use of Components allows creators to directly set their own definitions of what should be possible for that transaction, creating explicit guard rails on what can and cannot happen in creating the final output state. Components are executed within the Radix VM, which provides the partial ordering that Cerberus requires to braid consensus on a per-transaction basis. It does this by defining transactions as a related set of changes to state that are encoded across shards. For example, the ownership of two different tokens (two pieces of state) may be located on two different shards, and so an atomic transaction that transfers the ownership of both of those tokens must correctly "partially order" that transaction relative to other transactions on those two specific shards, at that moment. Developer Royalties Developers may set a royalty fee on their blueprints and components, such that whenever another developer or user makes use of those components and blueprints, a royalty is paid automatically.