On Monday, Ripple Chief Technology Officer Emeritus David Schwartz acknowledged that the XRP Ledger has had more "technical hard forks" than most established public blockchains.
The ledger is currently in the process of adopting the new 3.1.3 software version, which has prompted some criticism pertaining to the network's consensus.
The looming deadline
As stated by XRPL dUNL validator Vet, the 3.1.3 update contains a "fix amendment" that will activate in nine days.
Any node that has not updated to version 3.1.3 by the deadline will no longer be able to communicate with the network.
As of May 18, only 40% of the network had successfully updated.
Some critics have questioned the mechanics of the XRPL's consensus model (given that the 60% majority of nodes could actually be forked off for running older software).
Frequent hard forks
Schwartz is not on board with the idea of a simple "one node one vote" system determining the mainnet.
He pointed out that bad actors could easily game such a scheme by spinning up dozens of fake nodes, which is known as a Sybil attack.
Schwartz confirmed that the XRP Ledger's fundamental design requires these types of upgrades to function as hard forks.
"It is true that XRPL has more events that are technically hard forks than most other established public ledgers," Schwartz explained. "That's mostly due to the somewhat unique place XRPL sits due to its use of smart transactors."
He has noted that Stellar operates similarly and frequently cycles through major protocol upgrades to implement new features and fixes.
A contentious split
As explained by Schartz, A raw percentage split among validators does not automatically dictate the outcome. Instead, the survival of a forked chain relies entirely on the Unique Node List (UNL). "The validator split doesn't matter," Schwartz stated. "All that's necessary is that each side have enough validators to create a functional UNL containing validators who agree to produce a ledger stream according to their preferred rules."
Schwartz noted the network would neatly cleave in two if there is a fracture within the community. "Most likely, if you had two competing ledger streams, you'd also have two competing UNLs and two competing code distributions."
Dan Burgin
