XRPL Batch V1.1 artėja prie aktyvavimo, institucijos

XRPL Batch V1.1 gali aktyvuotis rugsėjo 29 d., jei validatorių superdauguma išliks. Pataisa įveda atomas grupuotas transakcijas, didina DvP ir tokenizuotų atsiskaitymų galimybes, po išsamios saugumo peržiūros.

XRPL Batch V1.1 artėja prie aktyvavimo, institucijos

8 Minutės

Sekti „Google“

XRPL Batch V1.1 artėja prie aktyvavimo, institucijos kuria

XRP Ledger Batch V1.1 pataisa vis dar turi pakankamą palaikymą tarp validatorių, kad tęstų aktyvavimo atgalinį laikmatį, ir Ripple teigia, kad turto valdytojai bei komerciniai projektai rengia integracijas, kurios pasinaudos nauja transakcijų grupavimo funkcija, jei ji įsijungs vėliau šį mėnesį. Gyvi validatorių rodikliai rodo, kad pataisa išlaiko pakankamą palaikymą, kad potencialus aktyvavimo langas liktų atviras rugsėjo 29 d., o kūrėjai ir saugumo komandos atliko iteratyvią peržiūrą po to, kai ankstesnė versija buvo sustabdyta dėl kritinės spragos.

Aktyvavimo statusas ir kaip veikia validatorių balsavimas

Remiantis naujausia momentine nuotrauka, Batch V1.1 turėjo 30 iš 35 XRPLDashboard stebimų patikimų validatorių palaikymą — maždaug 85% pritarimą. XRP Ledger reikalauja bent 80% validatorių palaikymo, kad pataisa būtų palaikoma nenutrūkstamam 14 dienų periodui prieš aktyvavimą. Ši 80% superdauguma šiuo validatorių rinkiniu reiškia 28 balsus, ir laikmatis pradėjo veikti rugsėjo 15 d. 14:06:41 UTC. Jei palaikymas išliks pastovus per visą periodą, aktyvavimas gali įvykti netrukus po 14:06:41 UTC rugsėjo 29 d.

Svarbu prisiminti, kad XRPL pataisos neaktyvuojamos vien tik pasiekus 80% vieną kartą. Validatoriai turi išlaikyti superdaugumą be pertraukų visą 14 dienų laikotarpį. Balsai gali keistis laikui bėgant; jei palaikymas nukris žemiau ribos, aktyvavimo langas sustos ir reikės naujo nenutrūkstamo 14 dienų periodo, kad būtų pradėtas aktyvavimo procesas iš naujo.

Pastaroji balsavimo trajektorija

Batch V1.1 palaikymas per pastarąjį mėnesį pakilo gana greitai. Rudenį, pradžioje rugsėjo, pataisa turėjo tik 24 iš 35 validatorių balsų, todėl ji liko žemiau aktyvavimo ribos. Iki rugsėjo 15 d. palaikymas išaugo iki 27 balsų ir tada peržengė 28 balsų ribą, pradėdamas dabartinį atgalinį laikmatį. Naujausias paskelbtas skaičius rugsėjo 20 d. išliko 30 iš 35 stebimų validatorių palankiai.

Ką Batch V1.1 įveda į transakcijų sluoksnį

Apibrėžta XLS-56 specifikacijoje, Batch V1.1 leidžia vienai transakcijai supakuoti nuo dviejų iki aštuonių vidinių transakcijų. Šis grupavimas veikia keturiais apdorojimo režimais: Visi arba nieko, Tik vienas, Iki gedimo ir Nepriklausoma. Kiekvienas režimas keičia, kaip ledgeris apdoroja vidines transakcijas, kai viena ar kelios jų dalys nepavyksta arba pavyksta.

  • Visi arba nieko: arba visos vidinės transakcijos sėkmingos kartu, arba nė viena neturi poveikio. Tai atominis režimas, svarbus pristatymas-prieš-mokėjimą (DvP) srautams.
  • Tik vienas: reikalauja, kad tiksliai viena vidinė transakcija pavyktų; kitu atveju partija žlunga.
  • Iki gedimo: apdoroja vidines transakcijas tvarka tol, kol įvyksta klaida; po to likusios vidinės transakcijos nebandomos.
  • Nepriklausoma: vidinės transakcijos apdorojamos atskirai; vienos dalies sėkmė ar nesėkmė nekeičia kitų.

Batch V1.1 palaiko iki aštuonių vidinių transakcijų, įskaitant atominius swapus ir kitus daugialaipsnius susitarimus. Toks dizainas leidžia kurti sudėtingus atsiskaitymo srautus, pavyzdžiui, sujungiant turto perdavimą su mokėjimu vienoje atominėje operacijoje.

Pristatymas prieš mokėjimą ir atominis atsiskaitymas

Ripple pabrėžė pristatymas-prieš-mokėjimą (DvP) kaip komercinį naudojimo atvejį. Pagal DvP, turto atsiskaitymas ir atitinkamas mokėjimas gali būti dedami į tą patį atominį Batch, kad nesėkmingas mokėjimas užkirstų kelią susietam turto perdavimui. Tai sumažina atsiskaitymo riziką tokenizuotų aktyvų srautuose ir instituciniame prekyboje, kur atominių operacijų ir galutinumo garantijos yra itin svarbios.

Saugumo istorija: kodėl pataisa buvo pertvarkyta

Batch V1.1 yra perdirbta ankstesnės Batch pasiūlymo versijos pakaita, kuri buvo sustabdyta po to, kai saugumo tyrėjai vasarį atrado kritinę parašų tikrinimo spragą. Spragos ataskaitą parengė nepriklausomas tyrėjas ir patvirtino automatizuoti įrankiai; joje parodyta, kad tam tikromis sąlygomis originalioji Batch pasirašymo logika galėjo per anksti nustatyti parašų patikrinimo sėkmę susidūrus su naujai sukurtu paskyros įrašu. Blogiausiu atveju tai būtų leido užpuolikui įterpti vidinę transakciją, patvirtintą paskyros vardu, neturint teisėto privataus rakto.

Tas pirmasis Batch pasiūlymas niekada neįsijungė į mainnet; jis vis dar buvo balsavimo stadijoje, kai kūrėjams ir validatoriams patarta blokuoti aktyvavimą. rippled leidimas 3.1.1 (vasario 23 d.) padarė Batch ir fixBatchInnerSigs nepalaikomus, kad užtikrintų, jog jie negalėtų aktyvuotis spragai taisant.

Taisymas ir perdizainavimas

Kūrėjai pakeitė pasirašymo ir autorizacijos logiką rengdami Batch V1.1. Pataisymai pašalino per ankstyvą sėkmės sąlygą, sugriežtino parašų tikrinimo taisykles ir pridėjo papildomas autorizacijos apsaugas. Patobulinta pataisa buvo įtraukta į xrpld 3.3.0 leidimą, išleistą rugpjūčio 6 d., po papildomo vystymo ir saugumo peržiūrų.

Saugumo darbai tuo nesibaigė. Prieš dabartinį validatorių balsavimą prižiūrėtojai ištaisė dar vieną parašų, autorizacijos patikrinimų ir galimų serverio stabilumo problemų rinkinį. RippleX nurodė, kad peržiūros procesas apėmė vidaus priešininko testavimą, AI pagalbą analizėje, Sherlock saugumo konkursą ir vertinimus iš išorinių saugumo įmonių, tokių kaip Halborn ir Common Prefix. Šios pastangos buvo skirtos sumažinti atakos paviršių ir sustiprinti pasirašymo srautus keliems paskyrų modeliams bei kraštutinėms situacijoms.

Kūrėjų ir įrankių parengimas

Kintanti pasirašymo architektūra reikalavo atnaujinimų visoje XRPL kūrėjų ekosistemoje. Pavyzdžiui, xrpl.js biblioteka turėjo keistis, nes peržiūrėtas Batch formatas pririša papildomą paskyros ir sekos informaciją prie parašų. JavaScript binary-codec pridėjo Batch pasirašymo palaikymą versijoje 2.9.0 rugpjūčio mėnesį. Serverių operatoriams patarta pereiti prie xrpld 3.4.0, išleisto rugsėjo 16 d., kad būtų užtikrintas nuoseklumas; tas leidimas įtraukė atskiras paskolinimo ir išvalymo pataisas, tačiau nepakeitė Batch V1.1, kuri vis dar yra savo balsavimo procese.

Integracijos reikalavimai gamybiniam naudojimui

Programėlės, piniginės ir prekyvietės, norinčios priimti Batch, turės atnaujinti pasirašymo logiką, raktų valdymą ir transakcijų konstravimą. Kadangi vienas Batch gali apimti vidines transakcijas iš skirtingų paskyrų, įgyvendinimai turi valdyti daugpaskyrų autorizacijas, nonce ir sekos koordinavimą bei mokesčių apskaitą. XRPL transakcijų mokesčiai išlieka aktualūs Batch operacijoms, net jei perkeliami turto legai yra tokenizuotos atstovybės, o ne pats XRP.

Galimi naudojimo atvejai: tokenizacija, mokesčiai, mainai ir greitos paskolos

XLS-56 nurodo keletą potencialių taikymų, be paprastų sugrupuotų mokėjimų. Tai apima be pasitikėjimo pagrįstus daugpaskyrų mainus, platformos mokesčius, supakuotus su klientų mokėjimais, ir struktūras, panašias į flash loan. Pavyzdžiui, prekyvietė galėtų supakuoti kliento mokėjimą kartu su paslaugos mokeščiu į vieną atominį Batch vietoj dviejų atskirų transakcijų. Skirtingos paskyros gali autorizuoti atskiras tos pačios Batch dalis, leidžiant globos, prekyvietės ir institucinėms darbo eigos situacijoms, kai kelios šalys pasirašo konkrečias dalis.

Svarbu, kad Batch nereikalauja naudoti XRP kaip perkeliamos valiutos. Funkcija veikia transakcijų sluoksnyje ir gali supakuoti XRPL palaikomas turto perlaidas, tokenizuotus instrumentus ir pasirinktines žetonų struktūras kartu su XRP arba vietoj jo. XRP lieka aktualus mokesčiams mokėti, tačiau pagrindinis atsiskaitymas gali apimti kitus žetonus ar išleistas valiutas XRPL.

Institucinis susidomėjimas ir tokenizuotų atsiskaitymų eksperimentai

Ripple viešas komentaras apie Batch sutampa su augančiu finansų institucijų ir turto valdytojų susidomėjimu XRPL tokenizuotiems aktyvams ir instituciniams atsiskaitymams. Pastaraisiais mėnesiais pastebimi reikšmingi instituciniai testai ir pilotai, įskaitant tokenizuotų JAV iždo išpirkimo eksperimentus, kuriuose dalyvavo JPMorgan, Mastercard, Ondo Finance ir Ripple. Liepos mėnesį Aviva Investors paleido tokenizuotą fondo akcijų klasę XRPL, o Ripple suabejojo RLUSD — savo institucinio stable token koncepcija — kaip galimu grynųjų sąlygų legu atominiam DvP atsiskaitymui.

Grandinėje fiksuoti tokenizacijos rodikliai taip pat rodo augimą: vienas RWA duomenų agregatorius pranešė apie maždaug 2,6 mlrd. USD tokenizuoto realaus pasaulio turto vertės, pridėtos prie XRPL per šešių mėnesių laikotarpį, neįskaitant stablecoin. Stebėtojai įspėja, kad atstovaujama turto vertė ir aktyviai paskirstytas turtas yra skirtingi matavimai, tačiau tendencija rodo didėjantį aktyvumą aplink tokenizuotus instrumentus.

Turto valdytojai ir neatskleisti partneriai

RippleX inžinerijos vadovas Ayo Akinyele žiniasklaidai sakė, kad bendradarbiavimo su turto valdytojais darbai ruošiami Batch V1.1 kontekste, tačiau įmonė viešai neatskleidė konkrečių partnerių ar paleidimo grafikų. Tai palieka dabartinę naratyvą kaip komercinių integracijų vystymo lygmenį, o ne kaip oficialius partnerystės paskelbimus. Ripple nurodė, kad daugiau detalių bus pateikta po to, kai projektai užbaigs savo gamybines plano gaires ir pataisa bus aktyvi.

Ką rinkos dalyviai turėtų stebėti toliau

Du artimo laikotarpio įvykiai nulems, ar Batch V1.1 pereis į gamybinį naudojimą. Pirma, validatorių superdauguma turi būti palaikoma be pertraukų visą 14 dienų atgalinį laikmatį. Jei reikšminga validatorių grupė pašalins palaikymą, vykstantis laikotarpis sustos ir reikės naujo nenutrūkstamo periodo. Antra, serverių operatoriai ir tarpinės programinės įrangos teikėjai turi užbaigti programinės įrangos atnaujinimus ir pasirašymo įrankių atnaujinimus, kad palaikytų galutinį Batch pasirašymo formatą.

Jei aktyvavimas įvyks, tikėtinas atsargus, etapinis priėmimas globėjų, piniginių ir institucinių klientų. Projektai, kurie rengėsi Batch, greičiausiai išleis integracijos pastabas ir partnerystės pranešimus, kuriuose paaiškins, kaip jie ketina panaudoti atominį atsiskaitymą, DvP ir mokesčių bundlingo srautus operacijų sudėtingumui ir atsiskaitymo rizikai sumažinti.

Rizikos ir atitikties aspektai

Pereiti į gamybinį naudojimą reikės griežtų operacinių kontrolės priemonių: raktų saugojimo praktikų, parašų koordinavimo tarp paskyrų, neteisingai suformuotų Batch stebėjimo ir konservatyvaus srautų ribojimo, kad būtų išvengta atsitiktinių masinių gedimų. Reguliuotojai ir institucijų atitikties komandos taip pat įvertins, kaip atominės daugialaipsnės transakcijos dera su esamais atsiskaitymo, derinimo ir audito rėmais. Tokenizuoti aktyvai patys savaime kelia saugojimo, teisines ir reguliavimo pasekmes, kurios išeina už techninių Batch galimybių ribų.

Išvada: pasirengimas ir atsargus optimizmas

Batch V1.1 yra reikšmingas patobulinimas XRPL transakcijų modeliui, leidžiantis atominėms daugialaipsnėms darbo eigoms, svarbioms tokenizuoto turto atsiskaitymui, DvP ir prekyviečių mokėjimams. Pataisa atsigavo po ankstesnio saugumo incidento ir praėjo intensyvų peržiūros ciklą, o jos dabartinis validatorių palaikymas palaiko atvirą rugsėjo 29 d. aktyvavimo langą, jei palaikymas išliks pastovus.

Rinkos dalyviams ateinančios savaitės bus pasirengimo periodas: galutiniai programinės įrangos atnaujinimai, pasirašymo įrankių atnaujinimai ir galimi komerciniai diegimai iš turto valdytojų bei institucinių projektų, kai funkcija taps prieinama. Jei Batch aktyvuosis, jis gali žymiai supaprastinti daugialaipsnius atsiskaitymus XRPL ir pagreitinti institucinių tokenizacijos atvejų plėtrą, kuriems būtinas atominiškumas ir deterministiniai atsiskaitymo rezultatai.

Palikti komentarą

Komentarai

Komentarų dar nėra. Būkite pirmas.