- Ripple completes performance tests for XRPL’s Batch Transactions without slowing the network.
- Bundling up to eight transactions boosts processing power for complex tasks.
- XRPL keeps its five-second consensus time even under heavy load.
Ripple has concluded a performance testing round for a new feature on XRP Ledger (XRPL) known as Batch Transactions. This release allows clients to package up to eight single transactions in a single package, which increases the muscle of the ledger to process intensive operations without compromising its speed edge.
Here’s how it works: instead of initiating several individual transactions, you can send them all as a single collective transaction. This is especially handy when you want to perform actions like atomic swaps, conditional token mintage, and setting your transaction fees all at once. Ripple implemented this functionality in a way that each transaction within the collection needs to be successful as a group, without any partial outcomes that would create errors or anomalies.
Ripple’s performance team was interested in determining if the network would be capable of sustaining its high level of performance despite dealing with larger, more intensive bundles. The objective was unequivocal: the XRPL needed to hold its consensus time of five seconds, even if it was stressed to its limits.
Also Read: XRP Builds Strength with 2,260% Tokenization Growth on XRPL
Testing Under MainNet-Level Conditions
For the trials, RippleX built a private network that mirrored XRPL’s real-world MainNet setup. It had nine nodes, with five acting as validators and four as client gateways. The systems ran on Amazon’s EC2 z1d.2xlarge machines, each equipped with eight CPU cores, 64 GB of memory, and fast NVMe storage. All nodes were in the same region and connected through a shared network for consistent performance.
The team loaded the system with 250,000 synthetic accounts, based on a live snapshot from August 22, 2024. They tested four batch modes: “All or Nothing,” “Only One,” “Until Failure,” and “Independent.” Each batch carried eight transactions, covering everything from direct XRP payments to automated market maker (AMM) orders of varying complexity.
To really test the system’s reliability, they intentionally created failures in the last transaction of each batch. This was designed to trigger a full rollback and prove that the atomic processing rule worked as expected.
Batch Success Lifts XRPL Capacity, Failures Force Full Reverts
Performance results indicated XRPL was capable of dealing with batch processing without sacrificing overall throughput. For scenarios wherein all transactions were successful, the capacity of the ledger increased significantly. But transaction failures incurred a cost; throughput was decreased because an entire batch needed to be reversed.
Ripple observed that although there is room to increase emergency throughput, this would threaten to miss the target time of publishing the ledger. Nonetheless, throughout these tests, the network remained largely stable at its five-second consensus target.
Also Read: Ripple to Buy Rail in $200M Deal to Expand Stablecoin Services
