Ang mga developer ng RippleX ay naglalapat ng pormal na beripikasyon sa binalak na native lending system ng XRP Ledger bago ang pag-activate ng Mainnet. Saklaw nito ang XLS-66 Lending Protocol at XLS-65 Single Asset Vaults.
Ang validator ng XRPL Foundation na si Vet ay binigyang-pansin ang pagsusuri matapos ibahagi ng Ripple engineer na si Vito Tumas ang ikalawang bahagi ng serye ng beripikasyon ng RippleX. Nilalayon nitong makahanap ng mga depekto na maaaring hindi matukoy ng normal na pagsubok.
“Hindi sapat ang tradisyonal na pagsubok kapag bumubuo ka ng DeFi nang direkta sa Layer-1,” sabi ni Tumas. Sinusuri ng mga karaniwang pagsubok ang mga sitwasyong inaasahan ng mga developer. Gumagamit ang pormal na beripikasyon ng mga mathematical model upang suriin kung ang isang sistema ay maaaring pumasok sa mga invalid na estado.
Nakikipagtulungan ang Ripple sa protocol research firm na Common Prefix. Gumagawa ang mga koponan ng abstract model ng nilalayong pag-uugali at gumagamit ng mga machine-checkable na pamamaraan upang subukan ang mga panuntunan sa seguridad bago suriin ang mga resulta laban sa implementasyon ng xrpld.
Inilarawan ni Vet ang gawain bilang bahagi ng pagbuo ng “Fortress XRP.” Aniya, ang lending protocol ay sumasailalim sa pagsusuri batay sa mga pamamaraang ginagamit para sa high-risk na software. Ang label ay kanyang pagtatasa, hindi isang sertipikasyon.
Plano ng XRPL na ilagay ang mga function ng pagpapautang sa loob ng base protocol nito sa halip na umasa sa hiwalay na mga smart contract. Ang disenyong iyon ay maaaring pasimplehin ang pag-access, ngunit ang isang depekto sa core code ay maaaring makaapekto sa bawat aplikasyon na gumagamit ng feature.
Ang mga iskedyul ng pautang, kalkulasyon ng interes, defaults, vault shares, freezing rules, at clawbacks ay lumilikha ng maraming posibleng interaksyon. Ang maliliit na error sa accounting o pag-round ay maaaring lumaki sa mga paulit-ulit na transaksyon, na nagiging mahalaga ang mga bihirang edge case sa panahon ng pagsusuri.
Nauna nang sinabi ng RippleX na ang mga pormal na pamamaraan ay maaaring patunayan ang kawalan ng mga tinukoy na klase ng bug, sa halip na ipakita lamang na gumana ang mga nasubok na kaso. Hindi mapapatunayan ng proseso na walang kahinaan ang software dahil ang bawat patunay ay nakasalalay sa napiling modelo at mga katangian.
Ang pagsusuri ay sumusunod sa isang naunang kaso ng seguridad ng XRPL na kinasasangkutan ng mga Batch transaction. Inalis ng Bersyon 3.1.1 ang suporta sa Batch matapos makahanap sina Pranamya Keshkamat at Cantina AI ng depekto sa iminungkahing amendment.
Pahihintulutan ng XLS-66 ang fixed-term, uncollateralized loans na pinondohan sa pamamagitan ng Single Asset Vaults. Ang mga loan broker ay magtatakda ng mga tuntunin at mamamahala ng panganib, habang ang off-chain underwriting ay susuri sa mga borrower bago lumipat ang mga pondo on-chain.
Kasama sa disenyo ang opsyonal na first-loss capital upang sumipsip ng bahagi ng default bago magtamo ng pagkalugi ang mga depositor ng vault. Sinusuportahan din nito ang XRP at issued assets, habang ang mga compliance control ay maaaring mag-freeze o mag-claw back ng mga karapat-dapat na token.
Idinagdag ng bersyon 3.1.0 ng XRPL ang suporta para sa mga lending at vault amendment noong Enero. Ang mga feature ay nananatiling sakop ng proseso ng amendment at hindi maaaring mag-activate maliban kung panatilihin ng mga validator ang kinakailangang suporta.
Gaya ng naunang naiulat ng crypto.news, ang XRP Ledger 3.2.0 ay nagta-target ng paglabas sa Hunyo 15 at babaguhin ang pangalan ng core server software ng network mula rippled patungong xrpld. Sinusundan ng upgrade ang bersyon 3.1.3, na nagdagdag ng accounting at invariant fixes para sa mga vault at lending tool.
Ang pormal na beripikasyon ay nagdaragdag ngayon ng isa pang layer ng seguridad habang inihahanda ng mga developer ang native lending protocol para sa posibleng pag-activate ng Mainnet.
