XRP Ledger (XRPL) infrastructure is back to normal operation after the manifest flood attack on its network occurred in July, as indicated in new data provided by XRPL engineer and Ripple CTO Emeritus David Schwartz.
Table of Contents
In his latest post, David Schwartz has released telemetry data from his personal XRPL node for August 25th to September 8th. He noted that the performance of his private node is “Rock Solid” and that the network infrastructure seems to have bounced back after the initial attack.
It is worth noting that the private node helps in connecting other nodes within the XRP Ledger network.
Also Read | Can the CLARITY Act Survive Its Sept. 15 Senate Vote?
XRP Ledger Survives July Manifest Storm Attack
This latest update follows an attack that occurred on July 31, when hackers attacked the XRP Ledger nodes using something referred to as a “manifest storm” by the developers.
These hackers attacked by sending thousands of counterfeit manifest certificates to the network infrastructure, which are supposed to be processed by validator nodes in the network.
There were various connection issues reported by the Schwartz’s hub at the time of the attack. The issues reported included “onReadMessage” issues, which were observed at the point when nodes were checking their ledger states.
The attack did not affect the consensus of the XRP Ledger since it was not possible to prevent the creation of consensus of new ledgers.
XRPL Deploys 3.2.1 Security Fix
In response to this attack, the XRP Ledger developers released the xrpld 3.2.1 hotfix that included changes to mitigate such attacks in the future.
The limits have been set on the manifest size, and the caching of data from unknown participants has been altered in such a way that no suspicious connections will be able to exploit computer and network power resources.
Over a month since the attack, the telemetry by Schwartz gives us a glimpse of the effectiveness of these changes under normal operating conditions.
XRPL Hub Maintains Hundreds of Network Connections
Schwartz’s statistics indicate that the private XRPL node operated about 400 concurrent connections from August 25 to September 8.
There were 423 connections in total, of which 135 were inbound, while 271 were outbound.
Latency of peers was quite low, with an average of 165 milliseconds. A brief jump made the peer latency around 1.49 seconds on September 6, although the jump did not disrupt the consensus mechanism of the network.
The number of connection losses was approximately 84.6 per five minutes, an amount considered to be regular background noise for the hub.
The most significant change was observed in the “Abuse” metric of the hub, which dropped to almost zero. It indicates that the new software filters out most of the undesirable traffic and doesn’t allow it to exert any significant load on the hub.
New Data Offers Early Test of XRPL Security Changes
The most recent telemetry provides a very early hint of how effective the xrpld 3.2.1 alterations have been in ensuring the security of XRPL nodes after the July attack.
Although the information is gathered from Schwartz’s personal hub and is not a reflection of all nodes running on the XRP Ledger, the consistent connection numbers, low latency, and zero abuse readings point to an enhanced readiness of the network in coping with such attacks in the future.
The most important thing about XRPL from this incident is that the disruption of July had no impact on ledger finality, and the software improvements made thereafter seem to have done the job well.
Also Read | Strategy Deploys $176M on STRC Buyback After Pausing Bitcoin Accumulation
This article contains market analysis and price predictions. These are not guarantees. Crypto markets are volatile. Always DYOR. Not financial advice.
