Amendamentul Batch V1.1 al Registrului XRP se află la un singur vot de validator de la începerea procesului său de activare de două săptămâni, după ce dezvoltatorii au remediat alte 11 probleme software descoperite în timpul reviziilor de securitate.
RippleX a declarat luni că cea mai recentă revizuire a Batch V1.1 a identificat probleme legate de semnăturile tranzacțiilor, verificările de autorizare și blocările de server, iar soluțiile au fost încorporate în versiunea aflată acum în considerare de validatorii Registrului XRP.
Marți, suportul era de 27 din cei 35 de validatori de încredere, echivalentul a aproximativ 77%, lăsând propunerea chiar sub nivelul de 80% necesar pentru a intra în perioada de activare a rețelei.
Batch V1.1 ar permite gruparea a până la opt tranzacții într-o singură operațiune, cu reguli de execuție care pot impune ca tranzacțiile legate să reușească împreună.
Pentru un schimb de tokenuri între doi utilizatori, funcția ar putea face ambele transferuri dependente unul de celălalt. Dacă una dintre părțile schimbului eșuează, cealaltă tranzacție nu ar fi finalizată independent.
Portofelele și piețele ar putea utiliza aceeași structură pentru a procesa o plată a clientului și o taxă de platformă împreună. RippleX a declarat că proiecte comerciale care utilizează Batch sunt deja sub contract sau în curs de dezvoltare, deși echipa de dezvoltatori nu a identificat public companiile implicate.
Suportul validatorilor a crescut rapid în ultima săptămână. Pe 8 septembrie, Batch V1.1 avea 24 de voturi din cei 35 de validatori din lista implicită de noduri unice (Unique Node List), egal cu 68,57%, a raportat anterior crypto.news. Încă trei validatori au susținut amendamentul de atunci.
Conform regulilor de guvernanță ale Registrului XRP, un amendament trebuie să mențină cel puțin 80% suport din partea validatorilor timp de 14 zile consecutive înainte de a se putea activa. Cu 35 de validatori de încredere numărați în prezent, un alt vot de susținere ar duce Batch V1.1 peste prag și ar începe acea perioadă.
Rezultatul nu ar fi blocat odată ce începe numărătoarea inversă. Validatorii își pot schimba pozițiile, iar dacă suportul scade sub 80% în timpul ferestrei de 14 zile, procesul de activare ar fi întrerupt.
Un proces similar a avut loc în iulie, când amendamentul fixCleanup3_2_0 a obținut 85,71% suport și a intrat în fereastra sa de activare. Pachetul s-a activat ulterior pe 29 iulie, după ce a menținut suficient sprijin din partea validatorilor pentru perioada necesară.
Votul actual urmează retragerii designului original Batch, după ce cercetătorii au găsit o vulnerabilitate înainte ca funcția să ajungă pe rețeaua principală (mainnet) a Registrului XRP.
În anumite condiții, eroarea ar fi putut permite unui atacator să plaseze tranzacții din contul altui utilizator într-un lot (batch) fără a obține autorizația necesară. Niciun fond al utilizatorilor nu a fost pus în pericol, deoarece amendamentul afectat nu a fost niciodată activat.
Dezvoltatorii au reconstruit funcția în urma descoperirii, Batch V1.1 fiind ulterior inclus în xrpld 3.3.0, lansat pe 6 august.
Lansarea xrpld 3.3.0 a introdus implementarea corectată a Batch alături de alte câteva funcții propuse pentru protocol. Fiecare amendament necesită încă o aprobare separată a validatorilor înainte de a deveni activ pe rețeaua principală (mainnet).
Mayukha Vadari, inginer software la RippleX, a declarat că problema originală a semnăturii a fost descoperită în februarie, înainte de implementarea pe mainnet. Munca ulterioară a inclus o soluție la cauza principală, revizii efectuate de patru ingineri seniori, un concurs de securitate Sherlock și audituri de la Halborn și Common Prefix.
„După ce bug-ul de semnătură v1.0 a fost descoperit în februarie (pre-Mainnet, fără fonduri în pericol), l-am reconstruit”, a scris Vadari pe X pe 14 septembrie.
Procesul de revizuire nu s-a încheiat cu vulnerabilitatea inițială. RippleX a declarat că au fost descoperite alte 11 probleme în timp ce implementarea de înlocuire era examinată.
Descoperirile suplimentare au vizat gestionarea semnăturilor, verificările de autorizare și condițiile software capabile să blocheze serverele.
Common Prefix a clasificat una dintre vulnerabilități ca fiind critică. Conform reviziei RippleX, problema ar fi putut permite unui atacator să refolosească o permisiune pe care un utilizator o semnase și să efectueze mai multe tranzacții decât intenționase inițial să autorizeze utilizatorul.
Alte descoperiri au implicat modul în care tranzacțiile Batch verificau permisiunile și procesau semnăturile. Dezvoltatorii au abordat problemele raportate înainte ca amendamentul să ajungă în stadiul actual de votare a validatorilor.
RippleX a declarat că patru ingineri seniori au revizuit implementarea, în timp ce Halborn și Common Prefix au efectuat audituri externe. Codul a trecut prin testare automată și un concurs public de securitate conceput pentru a expune punctele slabe înainte de activare.
Testarea de securitate a fost utilizată și în cazul altor propuneri recente pentru Registrul XRP. O revizuire de securitate Common Prefix din iunie a identificat probleme numerice și comportamentale în componentele XRPL, cu soluții implementate prin versiunea 3.2.0. Firma de securitate a fost ulterior însărcinată cu verificarea formală și analiza altor părți ale rețelei.
Un concurs Sherlock separat, care a acoperit funcții propuse pentru Registrul XRP, a găsit zeci de vulnerabilități valide înainte ca amendamentele afectate să ajungă pe mainnet, inclusiv descoperiri critice și de gravitate ridicată.
Batch este una dintre numeroasele modificări de protocol introduse prin ciclul software 3.3.0, pe măsură ce dezvoltatorii Registrului XRP lucrează la decontarea tranzacțiilor, confidențialitate, permisiuni și funcții instituționale.
Înainte de lansarea software-ului, dezvoltatorii au prezentat cinci amendamente XRPL propuse, care includeau tranzacții Batch, MPT Confidențial (Confidential MPT), Sponsor, MPT Dinamic (Dynamic MPT) și Delegație de Permisiuni (Permission Delegation).
Batch este conceput în jurul decontării atomice, unde mai multe operațiuni înrudite pot fi gestionate ca o tranzacție coordonată, în loc să fie trimise separat.
Delegația de Permisiuni (Permission Delegation) ar permite unui cont să acorde autoritate restricționată unui alt cont fără a-i ceda controlul total. MPT Confidențial (Confidential MPT) este conceput pentru a ascunde soldurile și sumele de transfer pentru Tokenurile Multifuncționale (Multi-Purpose Tokens), menținând în același timp identitățile conturilor vizibile în registrul public.
Niciuna dintre funcții nu devine activă pur și simplu pentru că codul său este inclus în xrpld. Validatorii decid separat dacă susțin amendamentele, lăsând fiecare propunere pe propriul său program de votare.
Rețeaua a înregistrat deja rate de adoptare diferite pentru propunerile 3.3.0. Ripple a votat în august pentru amendamentul PermissionDelegationV1_1 când acesta avea suportul a șapte din cei 35 de validatori de încredere.
Batch s-a apropiat de atunci mult mai mult de pragul de activare. Cele 27 de voturi actuale lasă amendamentul la un singur validator de susținere distanță de la începerea perioadei de 14 zile, cu condiția ca voturile existente să rămână pe loc.
RippleX nu a numit proiectele comerciale despre care a spus că sunt sub contract sau în curs de dezvoltare pentru a utiliza Batch. CoinDesk a declarat că a întrebat echipa de dezvoltatori care companii se pregătesc să utilizeze funcția și dacă cele 11 soluții recente au primit o revizuire independentă față de versiunea aflată în prezent în considerare de validatori.
XRP