XRP Ledger-utviklere forsvarer sikkerhetsbeslutning
XRP Ledger-utviklere har nylig implementert en kritisk protokollfiks uten å vente på nettverkets standard to ukers validatorgodkjenningsprosess. Den nødoppdateringen, som ble utgitt 25. september, adresserte en 11 år gammel sårbarhet som kunne ha tillatt angripere å opprette brukbar XRP utover kryptovalutaens tiltenkte forsyningsgrense. Selv om etterforskere ikke fant bevis for utnyttelse, har metoden som ble brukt for å eliminere trusselen skapt debatt om hvordan desentraliserte nettverk bør reagere på nødsituasjoner.
Normal prosedyre vs. nødoppdatering
Under den normale XRPL-governance-rammen må endringer som påvirker transaksjonsbehandling få støtte fra mer enn 80 % av de betrodde validatorene i to påfølgende uker før aktivering. Sikkerhetsoppdateringen i september fulgte en annen prosedyre. Ifølge den offisielle sårbarhetsrapporten ble fiksingen effektiv umiddelbart på hver server etter oppgradering til xrpld 3.4.1, i stedet for å bli aktivert samtidig gjennom et godkjent tillegg. Utviklerne sa at alvorlighetsgraden av XRP-forsyningssårbarheten gjorde den normale prosessen for farlig.
«Å publisere oppdateringen mens feilen fortsatt var utnyttbar i løpet av en langvarig avstemningsperiode kunne ha gitt angriperne nok informasjon til å gjenskape utnyttelsen.»
Den tekniske utfordringen
Det underliggende problemet involverte et heltallsoverskudd i betalingsmotoren. Spesielt konstruerte transaksjoner kunne ha fått systemet til å kreditere mer XRP enn avsenderen faktisk betalte, noe som potensielt kunne ha skapt nye tokens. Forskere sporet den sårbare koden tilbake til 2015, selv om de ikke fant bevis for at den hadde blitt utnyttet på et offentlig nettverk.
Beslutningen om nødoppdateringen var ikke uten tekniske konsekvenser. Normalt aktiveres tillegg samtidig på kompatible servere, noe som sikrer at validatorene bruker identiske transaksjonsregler. Nødoppdateringen skapte derimot en midlertidig periode der oppgraderte servere ville avvise visse ondsinnede transaksjoner, mens eldre versjoner fortsatt kunne akseptere dem. Den uenigheten kunne teoretisk ha forstyrret ledger-validering hvis angripere forsøkte å utnytte sårbarheten før tilstrekkelig mange validatorer oppgraderte.
Imidlertid reduserte den raske utrullingen den eksponeringen. Mer enn 80 % av operatørene på den standard Unike Node-listen hadde installert versjon 3.4.1 innen 25. september, ifølge utviklingsteamets avsløring.
Debatt om utviklernes myndighet
Responsen var forskjellig fra den separate Batch-sikkerhetsfiksingen, som fulgte den normale tilleggprosedyren og ble aktivert 9. oktober. Hendelsen har ført til spørsmål om hvor mye myndighet utviklere og validatoroperatører bør utøve under alvorlige nettverksnødsituasjoner. Kritikk har delvis fokusert på den midlertidige distribusjonen av programvare før den sikkerhetsfølsomme kildekoden ble offentliggjort.
«Støttespillere argumenterer for at umiddelbar koordinering var nødvendig for å forhindre at angripere utnyttet en offentliggjort svakhet.»
XRPL Foundation har avvist forslag om at operatører ble tvunget til å installere oppdateringen, og understreker at validatorene tok sine egne oppgraderingsbeslutninger. Debatten kommer også mens kommende XRPL-låneoppgraderinger fortsetter å bevege seg gjennom den ordinære avstemningsprosessen, noe som viser at rutinemessige protokollendringer fortsatt krever vedvarende validatorstøtte.
Fremtiden for XRPL
For XRP-innehavere har den umiddelbare bekymringen blitt adressert: sårbarheten ble fikset, og etterforskere rapporterte ingen kjente utnyttelser. Det langsiktige spørsmålet er hvordan XRPL kan opprettholde desentralisert beslutningstaking samtidig som de reagerer raskt nok på fremtidige kritiske trusler.
