Philip DiSarro poroča o dveh kritičnih pomanjkljivostih v Aikenovi implementaciji CIP-113

Philip DiSarro, ustanovitelj in izvršni direktor Anastasia Labs ter avtor CIP-143, je 24. julija dejal, da je med pregledom Aikenove implementacije Cardanovega programabilnega žetonskega ogrodja CIP-113 odkril dve kritični ranljivosti. V isti niti je objavil posodobljene primerjalne teste, ki primerjajo kodo Aiken z izvirno implementacijo Plutarch, ki sta jo razvila DiSarro in ekipa Input Output. Razkritje prihaja, medtem ko je CIP-113 še vedno v fazi Last Check in njegova implementacija še naprej poteka skozi varnostni pregled.

Plutarch beleži nižje stroške v primerjalnih testih CIP-113

Objavljena datoteka s primerjalnimi meritvami primerja obe implementaciji v okviru Cardanovega največjega proračuna transakcije 10 milijard enot CPU in 14 milijonov enot pomnilnika. Tako Aiken kot Plutarch se na koncu prevedeta v Untyped Plutus Core, kodo, ki jo izvajajo vozlišča Cardano.

Plutarch je zabeležil nižjo skupno porabo CPU in pomnilnika v vsakem od petih izpostavljenih scenarijev.

V standardnem testu prenosa je Aiken porabil 1,19 krat več CPU in 1,17 krat več pomnilnika kot Plutarch. Največja razlika med prikazanimi scenariji se je pojavila v testu, ki je združeval zaseg, zunanji skript in 50 vhodov z javnimi ključi, kjer je Aiken porabil 3,23 krat več CPU in 2,36 krat več pomnilnika.

Obe implementaciji sta v testu 16-swap $NIGHT DEX ostali znotraj Cardanovih omejitev transakcij. Plutarch je porabil 6,66 % razpoložljivega proračuna CPU in 11,68 % proračuna pomnilnika, v primerjavi s 7,59 % in 15,25 % pri Aiken.

DiSarrojeva objava je vključevala tudi linearne projekcije o tem, koliko elementov bi lahko šlo v eno transakcijo. Ocenjena meja je postavila Plutarch na 658 vhodov v primerjavi s 162 pri Aiken, 472 izhodov v primerjavi s 334, 36.489 žetonov v primerjavi z 1.661 in 527 pravilnikov v primerjavi s 160. Ti podatki so projekcije zmogljivosti skript, izpeljane iz testiranih stroškov izvajanja, ne pa izmerjene prepustnosti glavnega omrežja.

Primerjava prevedenih skriptov je v šestih od sedmih kategorij ustvarila manjše skripte Plutarch. Skript directoryNodeSpending je meril 331 bajtov pri Plutarch in 1.698 bajtov pri Aiken. Izjema je bil programmableLogicGlobal, kjer je Aiken ustvaril skript velikosti 3.157 bajtov v primerjavi s 3.437 bajti pri Plutarch.

CIP-113 dodaja programabilna pravila nativnim sredstvom Cardano

CIP-113 predlaga ogrodje za dodajanje programabilnih pravil preverjanja nativnim sredstvom Cardano brez potrebe po spremembi glavne knjige ali hard forku. Izdajatelji bi lahko določili pogoje, ki se izvedejo med prenosi žetonov, kovanjem in uničevanjem.

Pravila lahko vključujejo allowliste, deny liste, omejitve prenosa, časovne zaklepe ter izbirne funkcije zamrznitve ali zasega. Ogrodje je namenjeno stablecoinom, tokeniziranim vrednostnim papirjem in sredstvom iz resničnega sveta, ki zahtevajo nadzor nad lastništvom in premikanjem.

V predlagani arhitekturi so programabilni žetoni shranjeni na skupnem naslovu pametne pogodbe, lastništvo pa je predstavljeno prek poverilnic za vložek. Verižni register povezuje vsako politiko žetona z njenimi pravili prenosa, logiko izdaje in morebitnimi pooblaščenimi nadzori tretjih strani.

Denarnice bi morale razreševati poverilnice za vložek, da bi pravilno prikazovale stanja. Decentralizirane menjalnice, indeksatorji, raziskovalci in druge aplikacije bi morale podpirati tudi dodaten postopek preverjanja, preden bi uporabniki lahko prek obstoječe infrastrukture Cardano delovali s programabilnimi žetoni.

Aiken in Plutarch ponujata različna razvojna pristopa, medtem ko se prevajata v enak format kode na verigi. Cardanova razvijalska dokumentacija predstavlja Aiken kot dostopno izhodišče z vgrajenim testiranjem in namensko zasnovano sintakso. Plutarch je v Haskell vdelan jezik, ki razvijalcem omogoča podrobnejši nadzor nad ustvarjeno kodo in stroški izvajanja.

DiSarro je avtor CIP-143, Interoperable Programmable Tokens, in je sodeloval z ekipo Input Output pri njeni izvirni referenčni implementaciji v Plutarch. Repozitorij Cardano Foundation navaja, da so bili trenutni validatori Aiken preseljeni iz te implementacije in prilagojeni širšemu ogrodju CIP-113.

Njegova neposredna vključenost v izvirno arhitekturo in kodo umešča novo primerjavo meritev v razvojno zgodovino projekta. CIP-143 je zdaj označen kot neaktiven, potem ko je bil vključen v kandidata CIP-113, ki ostaja v fazi pregleda CIP urednikov Last Check.

Dve prijavljeni ranljivosti čakata na tehnično razkritje

DiSarro je dejal, da je njegov pregled implementacije Aiken razkril dve kritični ranljivosti, ki sta bili med revizijskim postopkom spregledani. Njegova nit ni opredelila prizadete kode, možnih napadalnih poti, potencialnega vpliva ali stanja sanacije.

Repozitorij že vsebuje javne ugotovitve začetne revizije, vključno z dvema zaprtima težavama z oznako critical. Težava 56 je opisovala pot, po kateri bi lahko na novo kovani žetoni ušli programabilnemu skrbništvu med dejanjem tretje strani. Težava 64 se je ukvarjala z možno kontaminacijo nepovezanih UTxO prek iste administrativne funkcije.

Te ugotovitve so bile prijavljene med začetno revizijo in jih brez dodatnega tehničnega razkritja ni mogoče opredeliti kot dve ranljivosti, ki jih je DiSarro pozneje prijavil.

V razpravi o pregledu CIP-113 so bila izpostavljena tudi varnostna vprašanja. Sodelujoči je 20. julija dejal, da je bilo spregledanih več visoko resnih ranljivosti in da so nekatere predlagane spremembe uporabnosti prinesle dodatne varnostne težave. Med nadaljnjim pregledom CIP so se udeleženci strinjali, da bi moral naslednji korak vključevati obsežnejšo revizijo, medtem ko predlog ostaja v fazi Last Check.

Repozitorij Cardano Foundation navaja, da so bile ugotovitve začetne revizije in nadaljnje ponovne revizije odpravljene v glavni veji. Končno poročilo o reviziji pa ostaja neobjavljeno, repozitorij pa označuje implementacijo kot neprimerno za produkcijsko rabo z resničnimi sredstvi, dokler ne bodo dokončani poročilo, širše testiranje in nadaljnji strokovni pregled.

Preden lahko implementacija CIP-113 napreduje proti uvedbam za resnična sredstva, ostajajo tri konkretni izidi v teku: objava končnega revizijskega poročila, razkritje in odprava dveh ranljivosti, ki jih je prijavil DiSarro, ter dokončanje širšega varnostnega pregleda, zahtevanega med postopkom CIP. Ti izidi bodo določili, katere spremembe kode in specifikacij bodo vključene, preden bo predlog združen in bo implementacija obravnavana kot primerna za produkcijsko rabo.