Ang amiyendang Batch V1.1 ng XRP Ledger ay nalalapit na sa pagsisimula ng dalawang linggong proseso ng pag-activate nito, nang kailangan na lamang ng isang boto mula sa validator, matapos ayusin ng mga developer ang isa pang 11 isyu sa software na natuklasan sa panahon ng mga pagsusuri sa seguridad.
Sinabi ng RippleX nitong Lunes na ang pinakabagong pagsusuri ng Batch V1.1 ay nagtukoy ng mga problema na kinasasangkutan ng mga pirma ng transaksyon, pagsusuri sa awtorisasyon at pag-crash ng server, kung saan ang mga pag-aayos ay isinama sa bersyon na kasalukuyang isinasaalang-alang ng mga validator ng XRP Ledger.
Ang suporta ay umabot sa 27 sa 35 pinagkakatiwalaang validator nitong Martes, katumbas ng humigit-kumulang 77%, na iniiwan ang panukala na bahagyang mas mababa sa 80% na antas na kinakailangan upang makapasok sa panahon ng pag-activate ng network.
Ang Batch V1.1 ay magpapahintulot ng hanggang walong transaksyon na mapangkat sa isang operasyon, na may mga panuntunan sa pagpapatupad na maaaring mangailangan ng magkakaugnay na transaksyon na maging matagumpay nang magkasama.
Para sa isang pagpapalit ng token sa pagitan ng dalawang user, ang tampok ay maaaring gawing nakasalalay ang parehong paglilipat sa isa't isa. Kung ang isang panig ng palitan ay nabigo, ang isa pang transaksyon ay hindi makukumpleto nang hiwalay.
Maaaring gamitin ng mga wallet at pamilihan ang parehong istraktura upang iproseso ang isang bayad ng customer at isang bayad sa platform nang magkasama. Sinabi ng RippleX na ang mga komersyal na proyekto na gumagamit ng Batch ay nasa ilalim na ng kontrata o pagbuo, bagaman hindi pa pampublikong natukoy ng pangkat ng developer ang mga kumpanyang kasangkot.
Mabilis na tumaas ang suporta ng validator sa nakalipas na linggo. Noong Setyembre 8, ang Batch V1.1 ay may 24 na boto mula sa 35 validator sa default na Unique Node List, katumbas ng 68.57%, na naunang iniulat ng crypto.news. Tatlo pang validator ang sumuporta sa amiyenda mula noon.
Sa ilalim ng mga panuntunan sa pamamahala ng XRP Ledger, ang isang amiyenda ay dapat panatilihin ang hindi bababa sa 80% na suporta ng validator sa loob ng 14 na magkakasunod na araw bago ito ma-activate. Sa 35 pinagkakatiwalaang validator na kasalukuyang binibilang, ang isa pang sumusuportang boto ay magdadala sa Batch V1.1 sa itaas ng threshold at magsisimula sa panahong iyon.
Ang resulta ay hindi magiging nakasigurado kapag nagsimula na ang pagbilang. Maaaring baguhin ng mga validator ang kanilang posisyon, at ang pagbaba ng suporta sa ibaba ng 80% sa loob ng 14 na araw na bintana ay makagagambala sa proseso ng pag-activate.
Isang katulad na proseso ang naganap noong Hulyo nang ang amiyendang fixCleanup3_2_0 ay nakakuha ng 85.71% na suporta at pumasok sa panahon ng pag-activate nito. Ang package ay kalaunan ay na-activate noong Hulyo 29 matapos mapanatili ang sapat na suporta ng validator para sa kinakailangang panahon.
Ang kasalukuyang botohan ay sumunod sa pag-atras ng orihinal na disenyo ng Batch matapos makahanap ang mga mananaliksik ng isang kahinaan bago pa man umabot ang tampok sa mainnet ng XRP Ledger.
Sa ilalim ng ilang kundisyon, ang depekto ay maaaring nagpahintulot sa isang umaatake na maglagay ng mga transaksyon mula sa account ng isa pang user sa loob ng isang batch nang hindi nakukuha ang kinakailangang awtorisasyon. Walang pondo ng user ang nalagay sa peligro dahil ang apektadong amiyenda ay hindi kailanman na-activate.
Muling itinayo ng mga developer ang tampok matapos ang pagtuklas, kasama ang Batch V1.1 na kalaunan ay isinama sa xrpld 3.3.0, na inilabas noong Agosto 6.
Ang paglabas ng xrpld 3.3.0 ay nagpakilala ng tamang implementasyon ng Batch kasama ng ilang iba pang iminungkahing tampok ng protocol. Bawat amiyenda ay nangangailangan pa rin ng hiwalay na pag-apruba ng validator bago maging aktibo sa mainnet.
Sinabi ng RippleX software engineer na si Mayukha Vadari na ang orihinal na problema sa pirma ay natuklasan noong Pebrero bago ang pag-deploy sa mainnet. Kasama sa sumunod na trabaho ang isang root-cause fix, mga pagsusuri ng apat na senior engineer, isang Sherlock security contest at mga audit mula sa Halborn at Common Prefix.
"Matapos matuklasan ang v1.0 signature bug noong Pebrero (pre-Mainnet, walang pondo na nanganganib), muli namin itong itinayo," isinulat ni Vadari sa X noong Setyembre 14.
Ang proseso ng pagsusuri ay hindi natapos sa paunang kahinaan. Sinabi ng RippleX na isa pang 11 isyu ang natuklasan habang sinusuri ang kapalit na implementasyon.
Ang karagdagang natuklasan ay sumasaklaw sa paghawak ng pirma, pagsusuri sa awtorisasyon at mga kundisyon ng software na maaaring mag-crash ng mga server.
Ikinategorya ng Common Prefix ang isa sa mga kahinaan bilang kritikal. Ayon sa pagsusuri ng RippleX, ang isyu ay maaaring nagpahintulot sa isang umaatake na muling gamitin ang pahintulot na pinirmahan ng isang user at magsagawa ng mas maraming transaksyon kaysa sa orihinal na nilayon na pahintulutan ng user.
Kasama sa iba pang natuklasan ang paraan kung paano na-verify ng mga transaksyon ng Batch ang mga pahintulot at pinroseso ang mga pirma. Tinaos ng mga developer ang mga naiulat na problema bago umabot ang amiyenda sa kasalukuyan nitong yugto ng pagbobotohan ng validator.
Sinabi ng RippleX na apat na senior engineer ang sumuri sa implementasyon, habang ang Halborn at Common Prefix ay nagsagawa ng mga panlabas na audit. Dumaan ang code sa automated na pagsubok at isang pampublikong security contest na idinisenyo upang ilantad ang mga kahinaan bago ang pag-activate.
Ginamit ang security testing sa iba pang kamakailang panukala ng XRP Ledger. Isang pagsusuri sa seguridad ng Common Prefix noong Hunyo ang nagtukoy ng mga isyu sa bilang at pag-uugali sa mga bahagi ng XRPL, kung saan ang mga pag-aayos ay nai-deploy sa pamamagitan ng bersyon 3.2.0. Ang security firm ay kalaunan ay inatasang magsagawa ng pormal na pagpapatunay at pagsusuri ng iba pang bahagi ng network.
Ang isang hiwalay na Sherlock contest na sumasaklaw sa iminungkahing mga tampok ng XRP Ledger ay nakahanap ng dose-dosenang mga valid na kahinaan bago umabot sa mainnet ang mga apektadong amiyenda, kasama ang mga natuklasang kritikal at may mataas na kalubhaan.
Ang Batch ay isa sa ilang pagbabago sa protocol na ipinakilala sa pamamagitan ng 3.3.0 software cycle habang ang mga developer ng XRP Ledger ay nagtatrabaho sa pag-aayos ng transaksyon, privacy, mga pahintulot at mga tampok na pang-institusyon.
Bago ilabas ang software, binalangkas ng mga developer ang limang iminungkahing amiyenda ng XRPL na kinabibilangan ng mga transaksyon ng Batch, Confidential MPT, Sponsor, Dynamic MPT at Permission Delegation.
Ang Batch ay idinisenyo sa paligid ng atomic settlement, kung saan ang maraming magkakaugnay na operasyon ay maaaring hawakan bilang isang pinag-ugnay na transaksyon sa halip na isumite nang hiwalay.
Ang Permission Delegation ay magpapahintulot sa isang account na magbigay ng pinaghihigpitang awtoridad sa isa pang account nang hindi inililipat ang buong kontrol. Ang Confidential MPT ay idinisenyo upang itago ang mga balanse at halaga ng paglilipat para sa Multi-Purpose Tokens habang pinananatiling nakikita ang mga pagkakakilanlan ng account sa pampublikong ledger.
Wala sa mga tampok ang magiging aktibo dahil lamang sa ang code nito ay kasama sa xrpld. Ang mga validator ay hiwalay na nagpapasya kung susuportahan ang mga amiyenda, na iniiwan ang bawat panukala sa sarili nitong iskedyul ng pagbobotohan.
Nakita na ng network ang iba't ibang rate ng pag-aampon sa buong 3.3.0 na panukala. Bumoto ang Ripple noong Agosto para sa amiyendang PermissionDelegationV1_1 nang ito ay may suporta mula sa pito sa 35 pinagkakatiwalaang validator.
Mas lumapit na ang Batch sa threshold ng pag-activate. Ang kasalukuyang 27 na boto nito ay iniiwan ang amiyenda na isang sumusuportang validator na lang ang kulang mula sa pagsisimula ng 14 na araw na panahon, kung mananatili ang kasalukuyang mga boto.
Hindi pinangalanan ng RippleX ang mga komersyal na proyekto na sinabi nitong nasa ilalim ng kontrata o pagbuo upang gamitin ang Batch. Sinabi ng CoinDesk na tinanong nito ang pangkat ng developer kung aling mga kumpanya ang naghahanda na gamitin ang tampok at kung ang 11 pinakabagong pag-aayos ay nakatanggap ng independiyenteng pagsusuri laban sa bersyon na kasalukuyang isinasaalang-alang ng mga validator.
XRP