Daniel "CEO of the XRPL" Keller@daniel_wwf
What is the XRPL Cluster, and how does it work in layman's terms?
When we talk about the XRPL, many think about validators as the main backbone of the network that keeps everything working. However, the picture is way more complex than most people would imagine. With the recent announcement of the overhaul of the cluster, I want to shed some light on what the XRPL Cluster is, how it works, and why it plays such a crucial role for the XRPL.
Whenever you open @XummWallet, use a service, deposit or withdraw XRP or @CasinoCoin from rnr.poker, an exchange or marketplace, there is a high chance that your requests or submissions are sent to the cluster. The cluster offers a single access point via a WebSocket connection to interact with the XRP Ledger.
The cluster is a popular alternative to running your own infrastructure, allowing you to get data in and out of the ledger. While it is highly recommended to use your own infrastructure, it is only viable for some to do so.
How does it work?
The cluster is a sophisticated guide for navigating information requests and submissions through a vast, globally dispersed network of servers, ensuring your data takes the most efficient and available path possible. It also ensures that requests are evenly spread throughout the network of nodes, ensuring maximum efficiency. The potential failure of single nodes is mitigated because multiple nodes are available for specific requests.
When a user initiates a query or a data submission, their request first travels through Cloudflare, a prominent web infrastructure and website security company. Here, rather than employing standard load balancing via Cloudflare – a technique for distributing workloads uniformly across servers to prevent any single server from becoming a bottleneck – , it utilises the geographical proximity of the user, directing the request to the nearest edge server from among seven potential edge nodes.
Once a request reaches the closest edge node, it encounters NGINX – a highly efficient HTTP server and proxy. Subsequently, the query dives into a specialised custom-coded middleware developed by @XRPLLabs. The middleware embeds a routing logic, an intelligent set of rules and pathways specifically engineered for routing traffic. It ensures that the data is routed astutely based on the query type and the available nodes within the network.
The middleware discerns the nature and requirement of the query, leading it through the most logical and available path to the relevant "rippled" node – specialised servers that manage and sustain the XRP Ledger.
The network, thus, adapts dynamically, directing different query types and data submissions to various node types, such as Full History (FH) nodes or others, based on current availability and specific requirements. For instance, different node types will handle pathfinding and ledger submission tasks to optimise network performance and reliability.
Intriguingly, the system also incorporates intricate layers of security and traffic management to navigate through myriad challenges, such as distributed denial-of-service (DDoS) attacks, spam, and other forms of network abuse, substantially elevating the complexity of its operation.
What about security and availability?
Between Cloudflare and the backend proxies, primarily through NGINX, several logging and detection layers are seamlessly integrated, diligently monitoring, logging, and analysing the traffic that transits through the network. These layers are perpetually in dialogue with Cloudflare and the edge nodes, making informed, real-time decisions regarding the traffic. By employing advanced algorithms and heuristics, they discern legitimate user traffic from potentially malicious activities, determining whether specific traffic should be allowed, throttled, or outright blocked.
This vigilant approach ensures that all nodes remain available and optimally functioning, preserving the integrity and fluidity of user transactions and interactions within the network. Consequently, this enhances the overall stability and reliability of the system amidst the chaotic ocean of digital disturbances constantly bombarding the infrastructure.
How much is the cluster being used?
To give you an idea of the amount of data the cluster is handling, here are some stats from September:
2.95mln unique IPs requested or submitted data, which amounted to a total of 286.27mln requests translating into over 20 Terrabytes of data being served.
The top five geo locations for requests are (requests per seven days):
- USA 🇺🇸 ~16mln requests
- Germany 🇩🇪~12mln requests
- The Netherlands 🇳🇱 ~6mln requests
- Belgium 🇧🇪 ~5mln requests
- Japan 🇯🇵 ~4mln requests
Based on these figures, the cluster dealt with ~110 requests/submissions per second during that time frame.
Conclusion
Now that you understand what the XRPL Cluster is, how it operates, and how much workload it is handling, you might understand why it became a core component of the XRP Ledger.
Remember that dozens of people outside of @Ripple and @RippleXDev commit their time 24 hours a day, seven days a week, to ensure you will never notice even the slightest hiccup when interacting with the ledger. Even if you notice some minor issues occasionally, be assured that these people will do whatever needs to be done to find a solution.
