Intended Anatomy of Radix dApps
A decentralized application (dApp) is an application built to be deployed to a decentralized network and run by that network. Building a dApp typically involves creating both a web-based front-end user interface, and some smart contract logic that runs on a decentralized network. A web3 wallet (such as Metamask on Ethereum) typically connects a user’s account and assets to the dApp by taking responsibility for cryptographically signing transactions with the private key for the user’s account and submitting them to the decentralized network.
Radix follows this same model, with Radix’s smart contracts taking the form of Scrypto-based blueprints and components. A typical user interaction with a Radix dApp would work like this:
The user loads a dApp UI webapp, which is served on a traditional cloud host or other file hosting system. (This host might also manage off-ledger data like private data for users or images for NFTs.)
The dApp UI webapp connects to the Radix Network (via a Gateway node) to read the current state of any relevant components.
The user initiates an action in the webapp which formulates a transaction and passes it to the user’s web3 wallet application.
The wallet application signs the transaction (with the user’s approval) and submits it to the Radix Network (again via a Gateway node). The network computes and commits the results of the transaction to the state of components on the network.
The above describes the anticipated dApp architecture when Scrypto and Radix Engine v2 capability is implemented in the Radix Network protocol for its Babylon release. Until Babylon, the current Olympia release of the Radix Network has no Scrypto capability, and no web3 wallet, and so we have provided other ways for developers to get started today.
To allow developers to begin experimenting and developing with Scrypto right away in preparation for Babylon, the current early access release of Scrypto (Alexandria) provides a local simulator so that the Radix Network is not immediately needed. It works like this:
Blueprints are deployed, and instantiated into components, within the simulator environment running on the developer’s computer, using a RocksDB database as a simulated "ledger".
The Scrypto command line tools play the role of both dApp UI and wallet, letting the developer directly read the state of components, and submit transactions which require no signature and are automatically accepted by the simulator as valid and the results committed to the "ledger".
While this allows the developer to build complete Scrypto-based component functionality, it is not possible to directly connect dApp UI webapps. To do this, we currently offer the Public Test Environment and associated tools.
The Public Test Environment (PTE) is a simulated, centralized testing environment that allows developers to publish Scrypto blueprints and call instantiated components through transactions. PTE provides a minimum set of tools and APIs to enable experimentation with full-stack DApp development.
The PTE enables a very minimal form of the intended full-stack of a Radix dApp. It does not include a true, fully featured Radix web3 wallet, but the included browser extension fills the essential role of such a wallet for the sake of testing and demonstration. A fully-featured web3 Radix wallet is under development for the Babylon release; further details will come later.