There is a growing demand for permissionless programmability on the XRP Ledger. This kind of programmability will give developers the flexibility to securely implement complex scenarios in on-chain, user-deployed code, without needing permission from anyone (such as a UNL quorum).
To this end, the Programmability team at RippleX has been hard at work over the last few months researching different smart contract systems that exist in the broader crypto ecosystem. This blog post outlines our preliminary findings and also details what we believe to be the best VM solution for the future of XRPL programmability.
Overview
We started by researching possible solutions to the programmability question, to determine what was even remotely worth considering, and which designs seemed to match our goals at a first look. We called this “Phase 1”.
We then narrowed down the list of VMs to the most promising three options, and created some simple proofs-of-concept integrating those into rippled (the software that the XRPL runs on), to determine what was most feasible from a more technical perspective (“Phase 2”).
This post will provide an update on both Phases 1 and 2.
Note: this blog post only addresses the applicability of different VMs to XRPL programmability, and does not handle other design considerations, such as gas and storage mechanisms. We'll share our thoughts on those topics in a follow-up post.
Overall Design Objectives
The main goals we have for programmability on the XRPL are:
- Permissionless by design (i.e. no need for UNL approval for the network to execute user code)
- Meshes well with the XRPL, both design- and implementation-wise
- Easy access to native features/primitives, to build on the XRPL’s powerful building blocks
- Easy for new developers to learn (e.g. familiar design paradigms)
- Minimal impact to existing XRPL users/use-cases, especially with regard to payments, performance, and security
- Minimal impact to node/validator costs
Phase 1: Discovery Research
As part of our discovery process, we considered the following technologies (including possibly modifying them to meet the needs of the XRPL). We also spoke extensively with developers from many of these communities to gather their input.
- Hooks
- Stellar (Soroban)
- EVM
- Solana
- Aptos/Sui (Move)
- TON
- NEAR
- BitVM
- RISC-V
- L2s/Sidechains
Phase 1 Evaluation Criteria
In this first phase, we only considered a subset of the design objectives listed above (namely, those that were easier to investigate without needing to build a proof-of-concept):
- Permissionless
- Meshes well with the XRPL, design-wise (especially its account-based model)
- Easy integration with native features
- Easy learning for new developers
- Use familiar development models
- Ecosystem adoption (looking at the broader crypto ecosystem) - as a partial proxy for ease of learning
1. Hooks
Hooks are small pieces of code that are installed on an account. They are triggered by incoming and outgoing transactions and can:
- Block an incoming or outgoing transaction
- Modify an outgoing transaction
- Create and send a new, additional transaction
Why This Was Investigated
Hooks was originally designed for the XRPL, and already exists in one form on Xahau, where it has been in production for more than a year.
Evaluation Results
| Requirement | Satisfies? | Notes |
|---|---|---|
| Permissionless |  |
|
| Native Feature Access | |
Via transaction emission. |
| Ease of Learning |  |
Yes, with some modifications, such as JSHooks. |
| Design Meshes Well with XRPL | |
|
| Ease of rippled Integration | |
|
| Ecosystem Adoption |  |
Xahau is the only chain that supports Hooks, and it is still very new. |
We decided to move Hooks onto the next step. Since Hooks was designed for the XRPL, it easily passed many of the criteria that we were evaluating at this step. The main two sticking points were ease of learning for new developers (due to needing to know the C programming language) and low ecosystem adoption, but these factors were not enough of a concern to stop it from moving onto the next stage of evaluation.
2. Stellar (Soroban)
Soroban is the smart contracts platform on the Stellar network. Soroban Contracts are small programs written in the Rust programming language and compiled as WebAssembly (WASM) for deployment.
Why This Was Investigated
Stellar and the XRPL are very similar in their overall architecture - for example, both are account-based and use trustlines. As a result, it may be easy enough to port Soroban to the XRPL.
Notes
There does not appear to be a way to interact with Stellar-native features from a Soroban smart contract. For example, in order to get assets to work with a smart contract, you need a Stellar Asset Contract (SAC) that pairs with it and stores the smart contract asset balances. These are deployed like normal smart contracts. In addition, there is no way to access ledger object data unless it’s the data stored in the contract (with the exception of the SAC, which can access trustline balances), and no way to integrate with a Stellar-native AMM without something off-chain or special wrapper logic.
Evaluation Results
| Requirement | Satisfies? | Notes |
|---|---|---|
| Permissionless | |
|
| Native Feature Access | |
Yes, with some modifications, such as adding additional APIs (known as “host functions” in WASM). |
| Ease of Learning | |
Soroban contracts are somewhat difficult to read for someone who is new to the ecosystem. |
| Design Meshes Well with XRPL | |
Stellar and the XRPL are very similar in architecture. |
| Ease of rippled Integration | |
While Soroban was designed to be used by other blockchains as well, the 10 years of divergence between Stellar and the XRPL will likely still make integration somewhat difficult. |
| Ecosystem Adoption | |
Electric Capital’s Developer Report doesn’t show many Stellar developers. |
We decided not to proceed with Soroban. Soroban fails our criteria in two key places: Ecosystem Adoption and Native Feature Access. The lack of native feature access essentially counteracts the benefits of Stellar’s similarities to the XRPL.
3. EVM
The Ethereum Virtual Machine is a smart contract VM used on many different chains, but started on the Ethereum network. Contracts are written in Solidity, which was developed specifically for the EVM.
Why This Was Investigated
The EVM is by far the most popular development stack in the crypto ecosystem.
Evaluation Results
| Requirement | Satisfies? | Notes |
|---|---|---|
| Permissionless | |
|
| Native Feature Access | |
Yes, with some modifications, such as adding precompiles. |
| Ease of Learning | |
Solidity is the most popular smart contract language. |
| Design Meshes Well with XRPL | |
The EVM idea of unique contract addresses is roughly analogous to the XRPL’s pseudo-accounts. |
| Ease of rippled Integration | |
The VM is a standalone module, but was never designed to be integrated with something as different as the XRPL, so there will likely be difficulties. |
| Ecosystem Adoption | |
Electric Capital’s Developer Report shows it as by far the most popular development stack |
We decided to move the EVM onto the next step. Given its popularity and ease of use, the EVM easily passes this round of evaluation. The biggest questions are about whether you would be able to access native features, and how well the code would integrate with rippled.
4. Solana
On Solana, contracts (which are called “programs”) are written in the Rust programming language. Solana’s on-chain programs are compiled via the LLVM compiler infrastructure to an Executable and Linkable Format (ELF) containing a variation of the Berkeley Packet Filter (BPF) bytecode.
Why This Was Investigated
Solana is the second most popular smart contract stack for crypto developers.
Evaluation Results
| Requirement | Satisfies? | Notes |
|---|---|---|
| Permissionless | |
|
| Native Feature Access | |
Yes, with some modifications, such as adding native programs. |
| Ease of Learning | |
The tooling ecosystem is relatively mature, and Rust is a fairly popular programming language. |
| Design Meshes Well with XRPL | |
The contract data is stored in a separate account from the executable, which doesn’t mesh very well with the way the XRPL uses accounts (accounts store their own data, or data is stored in other ledger objects). |
| Ease of rippled Integration | |
The VM isn’t a standalone module, so it would have to be extracted from the Solana codebase before it could be added to rippled. |
| Ecosystem Adoption | |
Electric Capital’s Developer Report shows it as the second-most popular development stack. |
We decided not to proceed with SolVM. This is mainly because they have a very different system of transactions, and making the conversion would likely be too difficult. In addition, the Solana VM is embedded into their server code, and would be difficult to extract.
5. Aptos/Sui (Move)
Move is a very high-performance, memory-safe, parallel-execution capable VM that currently powers smart contracts on the Aptos & Sui chains.
This evaluation focused on the Aptos version of Move.
Why This Was Investigated
Move smart contracts are gaining in popularity. In addition, its ability to handle parallel execution of transactions is intriguing and could potentially benefit the XRPL performance-wise in the future if the XRPL were to adopt it.
Aptos’s version of Move was chosen instead of Sui’s because Aptos has an account-based model (like the XRPL), which would likely be easier to port to the XRPL.
Evaluation Results
| Requirement | Satisfies? | Notes |
|---|---|---|
| Permissionless | |
|
| Native Feature Access | |
Yes, with some modifications, such as adding host functions. |
| Ease of Learning | |
It has a very steep learning curve, but is nice to work with once that is overcome. |
| Design Meshes Well with XRPL | |
It is also an account-based system with a reserve-like method of storage rent. Interestingly, they have a unique method of contract data storage, where the user holds their data, instead of the contract account. |
| Ease of rippled Integration | |
The VM isn’t a standalone module, so it would have to be extracted from the Aptos codebase before it could be added to rippled. |
| Ecosystem Adoption | |
Electric Capital’s Developer Report shows that it has a solid developer base, but not near the top. |
We decided to move Move onto the next step. The memory-safe and parallel execution nature of the Move VM make it very intriguing when thinking about how the XRPL can improve in the future.
6. TON
The TON blockchain has its own custom smart contract implementation, written in the FunC programming language and using the TON Virtual Machine (TVM).
Why This Was Investigated
The TON VM is intended to handle large numbers of smaller transactions, which may mesh with the XRPL’s method of processing via independent transactions, rather than larger smart contract functions.
Evaluation Results
| Requirement | Satisfies? | Notes |
|---|---|---|
| Permissionless | |
|
| Native Feature Access | |
Yes, with some modifications, such as adding additional APIs. |
| Ease of Learning | |
FunC is difficult to learn, but they have a higher-level language, Tact, that’s easier to use. |
| Design Meshes Well with XRPL | |
It emphasizes small, modular contracts, but uses TON types all the way down. |
| Ease of rippled Integration | |
The TVM uses TON types all the way down - for example, integers are signed 257 bits in TON, so each XRPL integer would need to be converted to that format. |
| Ecosystem Adoption | |
Electric Capital’s Developer Report doesn’t show many TON developers. |
We decided not to proceed with TON. This is mainly due to the fact that the TON VM uses TON types all the way down, and this would likely be difficult to work with.
7. NEAR
The NEAR blockchain/platform (launched in October 2020) supports smart contracts written in Rust and TypeScript which are compiled to WebAssembly (WASM) for deployment. NEAR uses proof-of-stake consensus.
Why This Was Investigated
NEAR is another blockchain that uses WASM, and is also account-based. It also has claims of a unique sharding mechanism (Nightshade) intended to support 1000+ TPS, which could be useful for the XRPL’s performance in the future.
Evaluation Results
| Requirement | Satisfies? | Notes |
|---|---|---|
| Permissionless | |
|
| Native Feature Access | |
Yes, with some modifications, such as adding additional APIs (known as “host functions” in WASM). |
| Ease of Learning | |
Rust and TypeScript are fairly easy to learn, but the smart contracts use some unusual decorators. |
| Design Meshes Well with XRPL | |
NEAR also uses an account-based model for asset holdings. |
| Ease of rippled Integration | |
NEAR uses different data types. |
| Ecosystem Adoption | |
Electric Capital’s Developer Report shows that it has a solid developer base, but not near the top |
We decided to move NEAR onto the next step, since we already had WASM on the list.
8. BitVM
BitVM is a conceptual framework that leverages Bitcoin’s limited scripting language to enable Turing-complete Bitcoin contracts without modifying the network's consensus rules. The main idea is to compile a program into a Boolean circuit and commit it in a Taproot address.
Why This Was Investigated
Neither Bitcoin nor the XRPL support Turing-complete smart contracts. As a result, BitVM is an interesting area of exploration because it offers the promise of programmability (with minimal changes to the XRPL), by using off-chain Turing-complete computation that can be verified by a much simpler computation layer on the main blockchain.
Notes
- Representing a general-purpose computation on the XRPL is challenging. The XRPL does not have the capability to represent a computation as a NAND gate circuit, for example.
- BitVM is stateless, and therefore uses the Lamport signature scheme to commit Boolean circuits for state transition. The XRPL does not currently support this.
- Further fraud-proof and dispute-resolution mechanisms are required if a BitVM solution is selected.
Evaluation Results
| Requirement | Satisfies? | Notes |
|---|---|---|
| Permissionless | |
|
| Native Feature Access | |
Yes, with some heavy modifications, as new machine instructions would need to be added and a fraud-proof mechanism would be required. |
| Ease of Learning | |
Developers have to do everything at the machine instruction level - there is no higher-level language. |
| Design Meshes Well with XRPL | |
It is designed for a UTXO blockchain, which the XRPL is not. |
| Ease of rippled Integration | |
BitVM has dependents that make integration difficult, such as the Lamport signature scheme. |
| Ecosystem Adoption | |
It is only used on Bitcoin, but Bitcoin is a very popular chain. |
We decided not to proceed with BitVM, since our research showed that it didn’t mesh well from a design or implementation perspective.
9. RISC-V
RISC-V is an emerging CPU instruction-set architecture that can be used to execute blockchain computation.
Why This Was Investigated
- RISC-V is register-based rather than stack-based as in WASM, which makes RISC-V more efficient.
- RISC-V only contains ~40-50 instructions, while WASM has more than 200 instructions.
- RISC-V is hardware-friendly and more suitable for resource-constrained devices.
- RISC-V has built-in crypto support, which makes ZK proof generation and verification more efficient.
Evaluation Results
| Requirement | Satisfies? | Notes |
|---|---|---|
| Permissionless | |
|
| Native Feature Access | |
Yes, with some modifications, such as adding additional APIs. |
| Ease of Learning | |
It is still a very nascent VM. |
| Design Meshes Well with XRPL | |
Since RISC-V is its own independent VM, it should be easy enough to customize it. |
| Ease of rippled Integration | |
It would be a similar level of integration as WASM. |
| Ecosystem Adoption | |
It is still very nascent, and projects are only starting to use it. |
We decided not to proceed with RISC-V, mainly due to its current maturity level. We plan to monitor RISC-V VM development in the blockchain ecosystem and will consider it as an alternative/additional solution for XRPL programmability in the future. For example, Nervos, Polkadot, and Ethereum are all in the process of developing RISC-V based projects.
10. Layer 2s and Sidechains
The two main examples considered here were rollups and sidechains.
Why This Was Investigated
L2 roll-ups provide parallel scalability and can be customized to fit a diverse set of application needs. Their safety comes from the mainnet (L1), and the safety of the mechanism connecting each roll-up to its L1 is guaranteed by each roll-up protocol.
Roll-Ups
L2 roll-ups provide parallel scalability and can be customized to fit a diverse set of application needs. Their safety comes from the Layer-1 (L1) mainnet, and the safety of the bridges between the roll-ups and their L1s is guaranteed by each roll-up protocol.
We investigated both Optimistic and ZK roll-ups.
Evaluation Results
There are several practical issues impeding the addition of roll-ups as a native primitive to the current XRPL:
- The XRPL would need to add ~10 new transactors, for bridging between the mainnet and any roll-up, and additional native support beyond this would be required to verify ZK proofs.
- XRPL does not have the appropriate logic and/or libraries to verify ZK proofs yet. Adding these would require significant testing and integration before being safely added to the XRPL.
- The zkVM libraries and several other projects we investigated are not yet production-ready. For example, they are in various stages of development (alpha, beta, or even still just a prototype).
- Proving a ZK roll-up is very computationally expensive, so more research is needed to enable this to work in the confines of the current consensus model.
Note: Full permissionless programmability on the XRPL would make roll-ups a more practical solution because the infrastructure required to support them on-chain could be implemented in smart contracts, instead of transactors.
Other Networks (e.g. Sidechains)
We discounted the concept of XRPL sidechains (or other networks connected to XRPL via a bridge) as a solution because bridges are too inefficient for any effective native programmability solution. As an example, it is very difficult to interact with XRPL-native features from inside a smart contract on a different chain.
Despite our choice above, sidechains still very much have their place in the XRPL ecosystem. For example, the XRPL EVM Sidechain provides EVM support for those who need a completely EVM-based solution, which would never be possible on the XRPL, due to the XRPL having a very different implementation and structure from any EVM chain.
Phase 1 Conclusions
To summarize: we advanced WASM, MoveVM, and EVM to the next phase.
Phase 2: A Deeper Dive
Phase 2 focused on VMs rather than ecosystems or smart contract designs. This is because choosing a specific VM is independent from what the eventual smart contract design on the XRPL might look like.
For every VM studied in Phase 2, we attempted to integrate it into rippled and build a very simple proof-of-concept of what that might look like. The options that passed the initial Phase 1 round of review and made it to the final cut were:
- WASM (e.g. Hooks, NEAR)
- Move (Aptos-style)
- EVM
The considerations in the deeper dive were:
- Compatibility with the rippled codebase
- Ease of embedding into the rippled codebase
- Ability to read and write from XRPL ledger state
- Performance impact
WebAssembly (WASM)
Similar to Solidity/EVM, WASM-based smart contract runtimes are deterministic, secure, and portable. In addition, WASM promises better performance, and supports many general-purpose programming languages (in other words, a Web2 developer may not have to learn a new language). With those benefits, WASM is the most popular smart contract language choice of many of the newer blockchain projects, such as Polkadot, Cosmos, Near, and most recently Soroban on Stellar.
We built a simple prototype with limited functionality. The prototype can store the smart contract Wasm code as part of a ledger object. The smart contract functions can be invoked by transactions. Once invoked, our POC processes the transaction and the ledger object, and stores data to a small storage attached to the smart contract.
Compared to Solidity/EVM, which was purposely built for smart contracts, WASM is general purpose and targets web2 developers. This provides more flexibility when integrating into a blockchain, but it also requires additional work to add or modify components, such as the storage interface and gas measurement mechanism. Fortunately, there are enough other blockchain projects that have already implemented WASM-based programmability solutions that we can look to for possible solutions on how to solve those problems.
Move
It took some time to learn Move and the associated tooling, but the experience of developing in Move was pleasant. However, we decided not to advocate for integrating it into the XRPL mainnet due to some practical concerns:
- The standalone MoveVM is easily extracted into rippled, but the VM alone is not useful without additional library support. In the Aptos case, these extended Move libraries are not well isolated from the Aptos codebase itself, making it difficult to incorporate the overall VM into rippled.
- To understand the effort in integrating Aptos’ MoveVM, we tried to build a prototype that simulates the interaction of rippled with the MoveVM. Unfortunately, the Aptos code base was not stable, likely due to the introduction of Move 2, which inhibits our ability to fully consider this as a viable option in the short-term.
- The prototype imported too much code from Aptos code base. The imported code was “internal” to another project, it was not easy to understand and was hard to tell which was by design that less likely to change and which was implementation detail.
- The XRPL’s rich set of native objects would need to be translated into objects that can be understood by the MoveVM, but this effort would be non-trivial.
EVM
EVM is the world’s first blockchain smart contract VM. Its programming language, Solidity, is still the most popular smart contract language. We created a prototype that hosted an EVM. The host prototype interacts with the EVM by providing storage for storing code and data, and by publishing smart contract bytecode to the EVM and later invoking the contract. The library we used, revm, was very easy to work with, and we had a similarly positive experience with associated tooling, reflecting the mature state of the EVM ecosystem.
However, we decided not to advocate for integrating it into the XRPL mainnet for the following reasons:
- We wouldn't be able to support many Ethereum RPCs because tooling (for code development, or wallets for example) would need to be changed, resulting in both rippled development work, tooling work, and a steeper smart contract developer learning curve, which would likely delay overall adoption.
- The changes we’d have to make to the EVM to enable it to work in the XRPL would remove many of the great benefits of the EVM (e.g. tooling, copy-paste-ability of contracts, etc.)
- Hypothesis: The ostensible benefit of choosing EVM is easy copy-pasting of existing Solidity code. However, existing Solidity code doesn’t know anything about the XRPL (addresses, signatures, objects, etc.). So, to allow this sort of copy-pasting into the rippled version of EVM, we would have to abandon many XRPL primitives, which we see as a core strength of the XRPL.
- Likewise, this approach would not be beneficial to EVM developers as they would have to rewrite their smart contracts to use XRPL primitives.
- The XRPL ecosystem already has a planned sidechain with EVM capabilities (the XRPL EVM Sidechain). That will be a more optimal option for Solidity developers, since it will be a standard EVM environment to build in.
Phase 2 Conclusions
Given our findings in Phase 2 (outlined in the table below), we propose that the VM choice for XRPL programmability is based on WASM.
Next Steps
Stay tuned for a second blog post outlining our proposed vision for programmability on the XRPL, as well as a couple of XLS specs!
Top comments (0)