XRPL fixes critical pre-메인넷 flaw, but client apps remain at risk
The repaired amendment closes the disclosed XRPL signer gap, but nodes, clients, wallets and explorers now face the production test.
XRP Ledger (XRPL) validators have put BatchV1_1 on a conditional path to activate at 14: 06: 41 UTC on Sept. 29, turning a security near-miss into a live test of the network's amendment process and its surrounding software.
On Sept. 22, xrpldashboard showed30 of 35 trusted validators supporting the amendment, above its displayed 28-vote threshold. The majority first appeared on-ledger on Sept. 15.
UnderXRPL's amendment rules, support must remain above 80% for two weeks. A fall to 80% or less ends the majority period, so the activation date remains conditional.
Sept. 29 is the first production test of whether XRPL's validator process, reference implementation, and client ecosystem converted a dangerous pre-메인넷 flaw into usable atomic transaction infrastructure.
The original Batch amendment never activated on theXRP Ledger 메인넷. In February, researchers found a critical authorization flaw while the amendment was still in its voting phase, and validators were advised to vote it down.
XRPL Labs'official vulnerability disclosurestates that no funds were at risk.
The flaw sat in the loop that checked the accounts authorizing a batch. If the code encountered a signer for a newly created account whose key matched that account, it returned success immediately instead of continuing through the remaining signers.
An attacker could place that valid signer first, then add a forged entry purporting to authorize a victim account. If the amendment had gone live, the unchecked victim transaction could have executed without the victim's keys.
XRPL's response came in two stages. Version 3. 1. 1 marked the original Batch and fix Batch Inner Sigs amendments unsupported, blocking their activation. BatchV1_1 later replaced them with a rewritten authorization path and additional defenses.
The episode was a failure caught at the boundary between software release and protocol activation.
The XRPL Foundation's finalXLS-56 specificationnow requires a multi-account batch to contain the exact, complete set of Batch Signers whose authorization the inner transactions would ordinarily need, apart from the account whose normal signature authorizes the outer transaction.
출처: CryptoSlate