Chief Technology Officer of Ripple Inc. payments decacorn, David Schwartz, is working on a "major optimization" of XRP Ledger protocol. Today it shares the first results of system testing—and they look impressive.
"Incredibly encouraging": Ripple CTO on XRPL optimization
According to the latest Twitter thread by Mr. Schwartz, he merged different performance optimizations proposed by various software engineers. Then, he stress tested system performance by shutting down the server and restarting it after a 60-second pause.
Such a restart implies a code upgrade, so the system relaunches with new inputs. For Mr. Schwartz, three of them were the most important—namely memory consumption, data processing rates (number of nodes synchronized per second) and time required for synchronization.
While the existing version of XRP Ledger software ("rippled"), v1.7.0.-b5, takes 82 seconds to synchronize, consumes 5.2 GB of memory and can process up to 73,000 nodes per second, a new build by Mr. Schwarz witnesses far more amazing results in regard to all indicators.
Here's what David Schwartz has achieved in testnet:
- System gets synchronized in 37 seconds (54.8 percent faster);
- System restart consumes 2.2 GB of memory (57.6 percent less);
- System processes 327,000 nodes per second maximum (347.9 percent more powerful).
FLR delegation pool becomes XRPL validator
Despite impressive performance, Mr. Schwartz reiterates that the new code is not fully audited yet, so he welcomes all feedback, but he does not recommend trying to launch it with real XRP tokens.
Meanwhile, the XRP Ledger validator team has been joined by the pioneering Spark (FLR) delegation pool, Scandinodes. According to the official announcement by the Scandinodes team, it became an XRP Ledger validator on Dec. 16.
The new validator can be tracked in XRPlorer by its public key: nHDs4pq2rpjfCNHgw2iwg3MHoNXunf9v25LyLKf7Nnh6dHuHW98k.
As covered by CryptoComes previously, Scandinodes is the first start-up that offers Spark (FLR) token delegation services that eliminates the necessity for FLR holders to run their own hardware while approving Spark transactions.
