Paglunsad ng Kritikal na Pag-aayos ng XRP Ledger
Ang mga developer ng XRP Ledger ay ipinagtanggol ang kanilang pambihirang desisyon sa seguridad matapos ilunsad ang isang kritikal na pag-aayos ng protocol nang hindi naghihintay sa karaniwang proseso ng pag-apruba ng validator na tumatagal ng dalawang linggo. Ang emergency update, na inilabas noong Setyembre 25, ay tumugon sa isang 11-taong gulang na kahinaan na maaaring nagbigay-daan sa mga umaatake na lumikha ng labis na XRP lampas sa itinakdang limitasyon ng suplay ng cryptocurrency.
Pag-aayos sa Kahinaan
Bagaman walang natagpuang ebidensya ng pagsasamantala, ang paraan na ginamit upang alisin ang banta ay nagpasimula ng debate kung paano dapat tumugon ang mga desentralisadong network sa mga emerhensya. Sa ilalim ng karaniwang balangkas ng pamamahala ng XRPL, ang mga pagbabago na nakakaapekto sa pagproseso ng transaksyon ay dapat makakuha ng suporta mula sa higit sa 80% ng mga pinagkakatiwalaang validator sa loob ng dalawang sunud-sunod na linggo bago ang aktibasyon.
Ang patch sa seguridad noong Setyembre ay sumunod sa ibang pamamaraan. Ayon sa opisyal na ulat ng kahinaan, ang pag-aayos ay naging epektibo kaagad sa bawat server matapos ang pag-upgrade sa xrpld 3.4.1, sa halip na sabay-sabay na ma-activate sa pamamagitan ng isang aprubadong pagbabago.
Mga Teknikal na Kahihinatnan
Sinabi ng mga developer na ang tindi ng kahinaan sa suplay ng XRP ay ginawang masyadong mapanganib ang karaniwang proseso. Ang pag-publish ng patch habang iniiwan ang depekto na maaring samantalahin sa isang mahabang panahon ng pagboto ay maaaring nagbigay sa mga umaatake ng sapat na impormasyon upang ulitin ang pagsasamantala.
Ang pangunahing problema ay may kinalaman sa integer overflow sa payment engine. Ang mga espesyal na nakabuo na transaksyon ay maaaring nagdulot sa sistema na mag-credit ng higit pang XRP kaysa sa aktwal na binayaran ng nagpadala, na posibleng lumikha ng mga bagong token.
“Sinubukan ng mga mananaliksik na hanapin ang kahina-hinang code mula pa noong 2015, bagaman wala silang natagpuang ebidensya na ito ay na-exploit sa isang pampublikong network.”
Debate sa Pamamahala at Seguridad
Ang desisyon ay hindi walang teknikal na mga kahihinatnan. Karaniwan, ang mga pagbabago ay sabay-sabay na na-activate sa mga katugmang server, na tinitiyak na ang mga validator ay nag-aaplay ng magkaparehong mga patakaran sa transaksyon. Sa halip, ang emergency update ay lumikha ng isang pansamantalang panahon kung saan ang mga upgraded na server ay tatanggihan ang ilang mapanlinlang na transaksyon habang ang mga mas lumang bersyon ay maaaring tumanggap pa rin sa mga ito.
Ang hindi pagkakaunawaan na iyon ay teoretikal na maaaring nakagambala sa pagpapatunay ng ledger kung ang mga umaatake ay nagtangkang samantalahin ang kahinaan bago sapat na mga validator ang nag-upgrade. Gayunpaman, ang mabilis na rollout ay nagbawas ng exposure na iyon. Higit sa 80% ng mga operator sa default Unique Node List ay nag-install ng bersyon 3.4.1 noong Setyembre 25, ayon sa pahayag ng development team.
Ang tugon ay naiiba mula sa hiwalay na Batch security fix, na sumunod sa karaniwang pamamaraan ng pagbabago at na-activate noong Oktubre 9. Ang insidente ay nagpasimula ng mga tanong tungkol sa kung gaano karaming kapangyarihan ang dapat ipatupad ng mga developer at mga operator ng validator sa panahon ng matinding emerhensya sa network.
“Ang mga kritisismo ay nakatuon sa pansamantalang pamamahagi ng software bago ang pampublikong paglabas ng source code na sensitibo sa seguridad.”
Mga Alalahanin ng mga May Hawak ng XRP
Para sa mga may hawak ng XRP, ang agarang alalahanin ay na-address na: ang kahinaan ay na-patch, at iniulat ng mga mananaliksik na walang kilalang pagsasamantala. Ang mas pangmatagalang tanong ay kung paano mapapanatili ng XRPL ang desentralisadong paggawa ng desisyon habang tumutugon nang sapat na mabilis sa mga hinaharap na kritikal na banta.
