XRP Ledger Upgrade Resolves Full History Node Failures with Rippled v2.2.3

Key Takeaways:

• The rippled version 2.2.3 upgrade resolves a critical SQLite page sizing issue that previously caused failures in Full History (FH) nodes.
• Validators are unaffected by the problem and can choose to update to version 2.2.3 or remain on version 2.2.2 as no additional amendments exist.
• The update ensures FH nodes can now function properly, though most public XRPL endpoints weren’t impacted due to redundancy measures.

The XRP Ledger (XRPL) is set to undergo an important upgrade aimed at resolving a long-standing issue affecting its Full History (FH) nodes. The core problem involved a SQLite restriction related to page sizing, which caused these nodes to fail. Vet, an XRP dUNL validator, shared that the fix has been integrated into the official rippled release, version 2.2.3, which is now available for installation. 

This version specifically addresses the SQLite page sizing issue for FH nodes that use a 4096-page size. Validators, however, are not impacted by this issue and can choose to remain on version 2.2.2 or update to 2.2.3, as no additional amendments have been introduced between the two versions.

Trade & Invite your friends to earn up to 20 $USDT worth of $HMSTR

1. New users on Bitrue will receive HMSTR tokens worth 10 USDT for their first trade of any spot pair. 
2. All users who invite three new users to register on Bitrue and complete any spot trade will receive HMSTR tokens worth 10 USDT.

Click here for more details

Full History Node Failures Escalate, But XRP Ledger Consensus Remains Unaffected

The issue, first highlighted by some validators weeks earlier, escalated over the weekend when several full history servers went down. Normally, FH nodes serve the full transaction history of the XRP Ledger, but the SQLite-related failure disrupted this process. Despite the significant impact on full history servers, XRP Cafe founder Xrpl Adam clarified in a post that the issue did not affect the network’s consensus or overall health. 

He further pointed out that most public XRPL endpoints use clio redundancy, meaning they do not require an actual full history server to return historical transaction results, mitigating the practical impact for users.

Attention all $DOGS holders! New Launchpool is live on Bitrue. Stake $DOGS to share 50,000 $HMSTR prize pool!

How can I participate in Launchpool to earn tokens? After completing the KYC verification, as long as your spot account has designated tokens and the balance reaches the minimum staking limited amount, you can participate, and you can redeem it at any time; Click here for more details.

Delayed Attention and Recent Fix: How Rippled v2.2.3 Resolves Long-Standing Full History Node Issues

While the problem has existed for several years, it only recently garnered more urgent attention after the widespread failure of FH nodes. Adam expressed disappointment that the issue wasn’t prioritized earlier, suggesting that timely promotion of the fix could have prevented the server failures. Nonetheless, the release of rippled version 2.2.3 offers a much-needed solution, ensuring full history servers can now function properly without being hindered by SQLite restrictions.

Register now! Secure your spot to enjoy up to 100% cashback! Invite new users to reserve and share a $10,000 USDT prize pool!

Click here for more details.

FAQ:

• What issue does the rippled version 2.2.3 update resolve? It addresses a SQLite page sizing issue that caused Full History (FH) nodes to fail.
• Are validators required to update to version 2.2.3? No, validators can choose to remain on version 2.2.2 since the update only affects FH nodes and introduces no new amendments.
• Did this issue impact the XRP Ledger’s overall health or consensus? No, the issue did not affect the network’s consensus or overall health, as most public endpoints use clio redundancy to provide transaction history.