Disclaimer: The opinions expressed by our writers are their own and do not represent the views of U.Today. The financial and market information provided on U.Today is intended for informational purposes only. U.Today is not liable for any financial losses incurred while trading cryptocurrencies. Conduct your own research by contacting financial experts before making any investment decisions. We believe that all content is accurate as of the date of publication, but certain offers mentioned may no longer be available.
A few weeks ago, Ripple CTO David Schwartz revealed plans to launch a hub that will be used to understand XRP network behavior and performance based on data gathered from it.
Now that the hub is in operation, Schwartz observed his first "bit of weird data" from the hub as reported yesterday by U.Today. The Ripple CTO revealed corrective measures for the anomaly, which have achieved results.
According to the Ripple CTO, the past 24 hours of the hub's performance looked solid, although a tiny glitch was recorded at 12:58 a.m., which might be due to the monitoring system.
At the time of Schwartz's X post, the hub was handling 11,000 requests per second from 173 peers with a response time of about 0.006 seconds from the average request coming in to the reply going out.
Schwartz shared an image alongside his post that illustrated this. The X post caught the attention of the XRP community with XRP enthusiast WrathofKahneman inquiring about what the "abuse" category in the "disconnections" side of the image meant.
Schwartz stated that this referred to servers that had been disconnected from the hub due to the belief that they were placing excessive load on it. He suspects that 100% of these are false positives due to some defects in the XRPL code, and that working on this is one of the reasons he chose to run the hub.
Exciting network possibility for XRPL
Schwartz revisited one of his concepts for XRP Ledger, which he designed eight years ago: the peer link policing system aimed to protect users against malicious peers. While the design, cryptography and rules of XRPL effectively safeguard against malicious peers misleading users, it could impose load on them.
To handle this, a peer receives "charge" for messages it sends, and "credits" are also given over time. If a peer's "charges" exceed their "credits," they risk being disconnected.
Schwartz stated that the schedule of fees and credits he picked almost a decade ago worked, but because the network has grown much since then and the hardware has changed, he may need to revisit it.
Going forward, Schwartz noted he wants to further understand how well the charge/credit scheme is working on the live network and, if needed, make some adjustments to it. One possibility is to take latency into account, granting peers with low latency a higher credit limit, given that an attacker cannot forge low latency.
Dan Burgin
Vladislav Sopov
U.Today Editorial Team