Introduction
A blockchain oracle serves as a crucial intermediary, connecting blockchain networks to external data sources. This connection enables decentralized applications (dApps) on the blockchain to access off-chain data, enriching the blockchain's utility and applications.
Testing Objective
The primary objectives of this testing were twofold:
- To evaluate the response time of the get_aggregate_price API for a maximum of 200 oracle objects, focusing on objects with the least recent update times under a realistic payment load.
- To assess whether a reasonable transaction per second (TPS) rate for oracleset transactions, under medium payment load conditions, would result in increased fee levels or cause consensus validation times to exceed the 5-second threshold.
Testing Environment
The testing environment mirrored the XRPL MainNet infrastructure to ensure the validity of our results. This environment comprised:
- A network of 9 rippled nodes, including 5 validators and 4 client p2p nodes.
- Nodes operated on AWS EC2 z1d.2xlarge instances, located in the same LAN and AWS region.
- Transactions were distributed across the network by 1 to 4 load servers targeting the 4 p2p nodes.
Data Setup
To simulate a realistic network, approximately 100,000 accounts were created, each pre-populated with 10 Oracle objects with 10 data entries. These oracles were arranged from the oldest to the most recent update times, to challenge the get_aggregate_price function under worst-case conditions.
Test Scenarios
The performance testing network aims to test the performance of get_aggregate_price and oracle_set under some payment load
Scenario 1 get_aggregate_price
During a 1-hour test period, the get_aggregate_price API was evaluated using 200 oracle objects, with a particular focus on token pairs that had the oldest update times. This approach was chosen to simulate the most demanding scenarios. Response times were meticulously measured and compared against those of standard payment submission operations. The frequency of get_aggregate_price requests was set at a rate of 7 per minute.
Response time for get_aggregate_price
The response time between get_aggregate_price and payment submit is compared below
In contrast, another RPC call ledger during the payment load, takes an average of 25.24 ms with the median of 24ms.
Scenario 2 oracleset
Another 1-hour test assessed the performance of the oracleset transaction at a rate of 15 TPS, alongside a background payment load of around 100 TPS. The goal was to monitor for any ledger validation delays or fee escalations.We did not observe any fee escalation nor did the ledger take longer than 5 seconds to validate.
The response time between oracleset and payment submit is compared below
Performance Server Related Metrics
get_aggregate_price
oracle_set
Conclusion
The Price Oracle feature testing on XRPL confirmed its strong performance and reliability under simulated MainNet conditions. The get_aggregate_price API efficiently processed queries on token pairs with the oldest updates among 200 oracle objects, averaging a response time of 6.24 ms under medium payment loads. Additionally, running oracleset transactions at around 15 per second, with a concurrent payment load of around 100 TPS, showed no significant ledger validation delays or fee escalations, with average response time of 5.71ms
