Introduction
Multi-Purpose Tokens (MPTs) are a flexible token standard proposed for the XRPL that enable various use cases, including payments, securities, and NFTs, all through a single unified framework. MPTs support a range of operations such as token issuance, authorization, clawback, and destruction, allowing for enhanced functionality in managing and interacting with digital assets. This versatile token structure facilitates the creation, transfer, and control of assets on the XRPL, contributing to improved scalability and efficiency for decentralized financial applications.
To ensure the seamless integration of MPTs into the XRPL, the RippleX performance team conducted extensive testing to evaluate the impact of MPT transactions on the network's consensus performance and overall health. This report outlines our testing methodology, findings, and conclusions, demonstrating that the activation of the MPT amendment will not adversely affect the network's performance or its ability to process other transactions.
For more details, please refer to the official documentation here.
Testing Objectives
The primary objective of this testing was to assess the performance of MPT transactions and their impact on consensus processing, particularly under high-load conditions. Specifically, we aimed to:
- Evaluate the capacity limits of the XRPL when processing MPT transactions alongside existing payment transactions.
- Identify potential bottlenecks or performance degradation caused by MPT-related operations.
- Ensure that the network maintains a 5-second consensus latency threshold, even under the most demanding scenarios.
Testing Methodology
Capacity Planning
To measure the maximum performance impact of integrating MPT transactions, we used the 5-second consensus latency limit as the benchmark for network capacity. This threshold ensures that the network remains in optimal condition while processing a mix of MPT and standard payment transactions. During testing, we monitored both ledger and consensus performance to determine whether the network load exceeded this latency criterion. Instances where the network surpassed this limit are referred to as “overvalidation” in the results below.
Test Environment
Our testing infrastructure simulated a private XRPL environment with 9 nodes, matching Ripple's MainNet in terms of hardware specifications. The key features of this environment are the following:
-
Network Setup
- 5 function as validator nodes
- 4 serve as client P2P nodes, interfacing with load generators
Uniform System Specifications: Each system mirrors the hardware specifications found in Ripple’s MainNet rippled infrastructure. Specifically, they are hosted on AWS's EC2 instance type, z1d.2xlarge, boasting 8 CPU cores, 64GB RAM, and 300GB NVMe SSD storage, dedicated to the rippled database.
Network Configuration: All nodes operate within the same AWS region and are interconnected through a shared LAN.
Load Submission: Between 1 and 4 load servers are actively engaged in transmitting transactions to the 4 P2P nodes.
Account Setup: A total of 100K synthetic accounts were established, built atop a public ledger synchronized from the MainNet as of July 3rd, 2023. Provisions were made in the simulation logic to ensure the uniqueness of source and destination accounts for every consensus cycle.
Configuration Continuity: The rippled configuration file was sourced directly from a Ripple MainNet validator. While the core configurations remained unchanged, requisite modifications were made to align with the specific needs of our environment.
Test Data Setup
To test Multi-Purpose Token (MPT) transactions, we prepared the following:
-
Accounts:
- Added 50,000 new accounts to the existing 100,000 payment accounts.
- Designated 15 accounts as MPT Token issuers to create and distribute tokens.
-
Token Issuances:
- Created 100,000 token issuances for MPT destroy transactions.
- Added 280 issuances for MPT operations like authorization, clawback, and issuance updates.
Load Modeling
#1 Payment Baseline
A mixed load of standard payment transactions involving both the AMM-based and LOB-based decentralized exchanges (DEX). This scenario establishes a baseline for network performance under typical MainNet conditions.
#2 Payment + MPT Transaction (3-7)
Payment + MPT Payments
- A mixed load of standard payment transactions and MPT payments.
- Replacing 20% of the payment transactions load that the current release can support with MPT p2p direct payments transactions.
- This scenario evaluates the performance impact of introducing MPT payments into the existing transaction mix.
#3 MPT Only Capacity
- A load consisting exclusively of MPT transactions, including MPTokenAuthorize, MPT payments, MPTokenIssuanceCreate, MPTokenIssuanceSet, Clawback, and MPTokenIssuanceDestroy.
- This scenario assesses the network's capacity to handle a high volume of MPT-related operations.
Transaction Execution Realistic Percentage:
- 30% MPTokenAuthorize
- 50% MPT Payment between testing accounts
- 25% Payment from MPTokenIssuer to MPTokenHolder
- 25% Payment from MPTokenHolder to MPTokenHolder
- 10% MPTokenIssuanceCreate
- 5% MPTokenIssuanceSet
- 3% Clawback
- 2% MPTokenIssuanceDestroy
Conclusion
Based on our comprehensive testing and evaluation, the introduction of Multi-Purpose Tokens (MPT) does not impose a significant load on the XRPL. Performance metrics—including ledger throughput, CPU usage, submission latency, and memory consumption—remained consistent across standard payments, mixed MPT and payment transactions, and fully MPT transactions. Moreover, we determined that MPT transactions can sustain throughput of up to 432 TPS under projected usage scenarios.
These results provide confidence that integrating MPT into rippled will pose no immediate risks to the network. Our commitment to ongoing research and development ensures that we will continue to enhance the performance and resilience of the XRP Ledger, enabling it to support a wide range of innovative use cases.
A security audit was also recently completed. Here is a link to the full report.
Top comments (0)