Splošni testi lastnosti za trezorje ERC4626

Ko DeFi raste in dozoreva, sta razvijalcem na prvem mestu razširljiva infrastruktura in sestavljivost. Ethereum Requests for Comments (ali ERC-ji) – standardizirani kompleti orodij za izdelavo aplikacij, ki temeljijo na Ethereumu, kot je široko uporabljen standard žetonov ERC20 — služijo ključni vlogi zagotavljanja doslednih smernic za razvijalce, da prispevajo k ekosistemu, ne da bi začeli iz nič. Letos, tokenizirani standard trezorja ERC4626 je bil ustvarjen za spodbujanje navzkrižne združljivosti med žetoni, ki prinašajo donos. Standardiziranje podrobnosti implementacij lahko obravnava tudi pereča vprašanja sestavljivosti, zaradi česar je integracija protokola lažja in na koncu manj nagnjena k napakam.

Več projektov DeFi je že sprejet standard, s čimer želimo povečati sestavljivost njihovih trezorjev, in pričakujemo širšo uporabo v celotnem ekosistemu. Vendar prilagajanje obstoječih obokov povzroča nekaj težav pri rasti; kritično je, da lahko nekatere napake pri implementaciji izpostavijo nove tarče za napad. Celo majhne napake (tako majhne, ​​kot je napačna interpretacija standardnega vmesnika) imajo lahko pomembne posledice za varnost in uporabniško izkušnjo, kar poudarja potrebo po več varnostnih orodjih in ukrepih, zlasti v bolj sestavljivem ekosistemu DeFi. 

Na srečo imajo lahko enostavne napake razmeroma preproste rešitve, če jih odkrijemo precej preden jih izkoristimo (in v idealnem primeru še preden jih uporabimo). V ta namen smo izpustili Testi lastnosti ERC4626 za fuzzing in simbolično izvajanje za pomoč izdelovalcem trezorjev pri odkrivanju standardnih kršitev, ki lahko prekinejo integracije ali povzročijo ranljivosti v nadaljevanju. V tem prispevku razložimo motivacijski problem, predstavimo naš pristop in zaključimo z nekaj uporabnimi nasveti.

Najprej malo ozadja standarda ERC4626

Končano marca, ERC4626 je standard za tokenizirane trezorje. Uveden je bil, da bi razširil široko uporabo ERC20 standard (trenutno osnova za stotine žetonov), spodbujanje standardizacije v trezorjih, ki prinašajo donos, in zagotavljanje sestavljivosti za aplikacije in protokole (npr. zbiralnike donosov), ki morajo z njimi komunicirati. To pomeni, da je mogoče katero koli aplikacijo, zgrajeno na trezorju ERC4626, preprosto razširiti za delo s katerim koli drugim trezorjem ERC4626. 

Tokenizirani trezorji omogočajo uporabnikom, da prosto položijo sredstva za kovanje delnic trezorja in pozneje odkupijo te delnice za dvig glavnice in obresti iz trezorja. Te delnice trezorja so žetoni ERC20, zato je z njimi mogoče enostavno trgovati ali jih uporabiti kot zavarovanje za izposojo drugih sredstev. Uporabniki lahko na primer deponirajo svoja sredstva v trezorje Yearn za kovanje žetonov yVault, s katerimi je nato mogoče trgovati na Uniswap, vložiti za dodaten donos ali uporabiti kot zavarovanje za protokole posojanja.

Poslovna logika za ustvarjanje in distribucijo donosa (in določanje cene delnice) se lahko razlikuje glede na implementacijo. Da bi pokrili čim več trezorjev (s ciljem, da bi bili interoperabilni v primerjavi z identičnimi), se standard ERC4626 osredotoča na opis uporabniškega vmesnika, večina podrobnosti izvedbe pa ostane nedoločenih. To omogoča variacije v poslovni logiki, dokler trezor izpolnjuje posebne zahteve vmesnika in spodbuja interoperabilnost v številnih različnih vrstah aplikacij in vrstah trezorjev ERC4626.

Ko bo ustvarjenih več trezorjev, pričakujemo, da bodo že od začetka implementirani v skladu s standardom ERC4626; vendar smo trenutno v nekoliko prehodni fazi, kjer bodo morali razvijalci, ki želijo izkoristiti večjo sestavljivost, posodobiti obstoječe trezorje, aplikacije in protokole, da bodo v skladu s standardom. Ko se nadgrajujejo, se soočajo s številnimi zapletenostmi in izzivi. 

Izzivi standardne skladnosti (in pasti neskladnosti)

Sledenje novemu standardu ni vedno preprosto. Vsak trezor ERC4626 mora zvesto (in natančno) izvajati zahteve standarda, kot je opisano. V nasprotnem primeru postane integracija trezorjev ERC4626 vse bolj zapletena zaradi upoštevanja različnih različic. Zaradi te kompleksnosti so integracije same po sebi nagnjene k napakam; in ker niso dovolj odporni na prihodnost, lahko sčasoma povzročijo varnostne ranljivosti.

Nestandardni žetoni ERC20 (npr. Tether USD) zahtevajo, da številni sistemi DeFi pri izvajanju prenosov žetonov uporabljajo dodatno knjižnico (kot je SafeERC20), da se varno spoprimejo z različnim vedenjem (na primer vrnitev ničesar, ko je prenos uspešen, namesto vrnitve true). To pomeni, da lahko vsi sistemi, ki komunicirajo s temi žetoni, postanejo ranljivi, če sistem ni zasnovan tako, da pravilno obravnava primere "manjkajočih vračil". Ti scenariji lahko povzročijo skupno varnostno past in povečajo splošne stroške razvoja in vzdrževanja (če upoštevamo dodatno logiko in odvisnosti, potrebne za ublažitev težav). Skladnost s standardom je zato kritična ne le za posamezne izvedbe, ampak tudi za varnost celotnega ekosistema. Ena ranljivost v posameznem sistemu ali odvisnosti lahko povzroči zelo razširjene težave.

Idealno bi bilo, če bi bili standardi uradno določeni brez dvoumnosti (npr. uradna specifikacija ERC20), vsako implementacijo pa je mogoče uradno preveriti glede na standardno specifikacijo. V praksi pa tega ni lahko doseči v kratkem času zaradi stroškov in truda, ki jih zahteva skupnost.

Predstavljamo izvedljive lastnosti ERC4626 za prepoznavanje težav s skladnostjo 

Medtem ko si prizadevamo za idealno stanje (vsak trezor je uradno preverjen glede na stroge formalne specifikacije), smo napisali standard ERC4626 Lastnosti ujeti neskladja v subtilnih podrobnostih standardnih zahtev, ki jih je enostavno zgrešiti.  

Razvijalci trezorja lahko izvedejo teste, da odkrijejo morebitne kršitve standardov v svojih implementacijah pred uvedbo. In integratorji trezorjev lahko preverijo, ali dani trezorji sledijo standardu, preden jih integrirajo v svoj sistem. Lastnosti je mogoče preizkusiti tudi glede na trezorje v živo, ki so že razporejeni v glavnem omrežju, prek testiranja vilic glavnega omrežja. Preizkušanje trezorjev v živo je lahko koristno – še posebej, če so bili trezorji nedavno uvedeni ali nadgrajeni – da zagotovimo, da so vsi sistemski parametri pravilno nastavljeni. 

Izbrali smo teste, ki temeljijo na lastnostih – napisani v Foundryju in pripravljeni za izvajanje s pomočjo njegovega fuzzerja – da bi lastnosti naredili izvedljive (in s tem preizkušljive). V prihodnosti jih lahko izvajajo tudi orodja za simbolično izvajanje ali preverjanje modela, da se formalno preveri, ali dani trezor izpolnjuje lastnosti za vse možne vnose in pogoje.

Lastnosti smo zapisali tako, da so dovolj splošne, da jih lahko uporabimo za širok nabor trezorjev, ki izvajajo drugačno poslovno logiko. Uporabili smo samo funkcije javnega vmesnika, da bi bile neodvisne od podrobnosti izvedbe. (Zaradi te omejitve pa so bile iz lastnosti izpuščene nekatere standardne zahteve, ki se nanašajo na notranje podatke, specifične za izvedbo.)

Na primer, naslednja lastnost ustreza eni od zahtev convertToShares() funkcija, "NE SME prikazati nobenih razlik glede na klicatelja.” Glede na dva naslova računa in znesek kliče vsakega od računov convertToShares() z enakim zneskom in zagotovi, da sta povratni vrednosti enaki. Ta lastnost je neodvisna od podrobnosti izvedbe convertToShares(), ki se razlikuje med trezorji in ga morajo izpolnjevati vsi trezorji, ki izvajajo ERC4626. To lastnost je mogoče izvesti z zagotavljanjem specifičnih vhodnih vrednosti (za testiranje enot), številnih naključnih vnosov (za testiranje fuzzov) ali simbolnih vrednosti (za simbolično izvajanje in formalno preverjanje). Zažene se lahko tudi lokalno ali proti glavni mreži (za testiranje integracije).

Primer uporabe: lastnosti, ki testirajo napake pri zaokroževanju

Napake pri zaokroževanju so na primer pomemben razred (navidezno manjših) napak, ki imajo lahko nekatere posledice za serijo. Osnovna računovodska logika ERC4626, npr. izračun števila delnic, ki bodo kovane, ali zneska sredstev, ki bodo umaknjeni, se izvaja z uporabo aritmetike s fiksno vejico – napake pri zaokroževanju so neizogibne. Za varnostvendar pa standard izrecno določa prednostno smer zaokroževanja za vsako funkcijo vmesnika, medtem ko pušča meje napak nedoločene in odvisne od izvedbe. Natančneje, deposit() in redeem() funkcije bi morale vrniti an pod-približek točne vrednosti, medtem ko je mint() in withdraw() funkcije bi morale vrniti an več- približek. Na primer, če je trenutna cena delnice (tj. znesek sredstev na delnico) 2, potem deposit() s 3 wei sredstev bi moral kovati le do 1 wei delnic (tj. floor(3/2)), medtem withdraw() s 3 wei sredstev bi moral zažgati vsaj 2 wei delnic (tj. ceil(3/2)).

Lastnosti, povezane z zaokroževanjem, smo zapisali tako, da so neodvisne od osnovne računovodske logike, tako da jih obravnavamo kot črno škatlo. Natančneje, formulirali smo jih kot tako imenovane lastnosti »round-trip«, ki opisujejo odnos med dvema nasprotnima funkcijama. Naslednja lastnost na primer določa, da mora dvig sredstev, ki so bila pravkar deponirana s kovanjem N delnic, porabiti najmanj N delnic. Z drugimi besedami, nihče ne more ustvariti brezplačnega dobička s pretvarjanjem sredstev in delnic trezorja naprej in nazaj z večkratnim kovanjem in dvigovanjem.

Dejansko smo ugotovili, da več trezorjev ERC4626 v glavnem omrežju ne izpolnjuje zgornje lastnosti zaradi napak pri zaokroževanju. To pomeni, da bi lahko vsakdo zaslužil na primer nekaj satošijev BTC (1 satoši ~= 0.02 centa v času pisanja) s preprostim (in večkratnim) kovanjem in dvigovanjem ter počasnim praznjenjem trezorja. To lahko dejansko prinese dobiček verigam, ki uživajo zelo nizke pristojbine za plin (npr. Fantom), ali če bo cena sredstva v prihodnosti dovolj visoka.

Testiranje standarda ERC4626 v naravi

Naše lastnosti smo preizkusili glede na ~100 trezorjev ERC4626 v glavnem omrežju in našli veliko trezorjev, ki niso sledili standardnim zahtevam — večinoma zaradi napak pri zaokroževanju (npr. uporaba zaokroževanja tal, kjer je zaželena zgornja meja, kot smo opisali). Natančneje, nekateri trezorji niso uspeli skovati točnega števila delnic, ki jih je zahteval mint() funkcijo, čeprav standard izrecno zahteva ta. Nekateri med njimi so oddajali tudi nedosledno Deposit dogodek, pri katerem se zabeleženi podatki razlikujejo od tistih, ki so bili dejansko skovani. Na naše presenečenje nekateri trezorji sploh niso bili skovani na kraju samem; namesto tega preprosto postavijo zahteve za kovnico v čakalno vrsto in jih pozneje obdelajo v paketu kot ločeno transakcijo.

Čeprav ta različna vedenja sama po sebi niso bila izkoriščena, lahko postanejo ranljiva, ko so vključena v druge sisteme, ki pričakujejo le standardna vedenja. Zaradi teh težav bo integracija trezorja veliko težja, kar bo morda nevtraliziralo stalna prizadevanja in spodbujalo motivacijo za standardizacijo.

Z uporabo naših testov lastnosti in drugih učinkovitih korakov v smeri standardne skladnosti

Natančno upoštevanje standarda lahko prepreči različna vedenja (v najboljšem primeru, preden se sploh uvedejo). Upamo, da bodo naše lastnosti pomagale, skupaj z nekaj dodatnimi dejanji. Za tiste, ki razvijajo in/ali integrirajo trezorje ERC4626:

• Toplo priporočamo vodenje naše lastnine testi proti vašim trezorjem. Hitro bodo našli težave, če pride do očitnih kršitev standarda.
• Predlagamo tudi, da pregledate naše Lastnosti da navzkrižno preverite svoje razumevanje standardnih zahtev in prilagodite svojo implementacijo, če pride do kakršnega koli nenamernega odstopanja.
• Če mora vaš trezor odstopati od standarda, priporočamo, da jasno dokumentirate nestandardno vedenje, tako da lahko drugi pravilno obravnavajo ta odstopanja pri integraciji z vašim trezorjem. Upoštevajte, da je treba to obravnavati kot zadnjo možnost.

***
Trezorji ERC4626 imajo potencial, da postanejo pomemben gradnik za DeFi v bližnji prihodnosti — in zaradi sestavljivosti je pomembno, da tako novi kot obstoječi trezorji sledijo standardu. Nove izvedbe se bodo pojavile po standardu, zato ni boljšega časa od sedanjega za standardizacijo obstoječih trezorjev. 

Ko si prizadevamo za idealno stanje (kjer so različni trezorji enotno sestavljeni), je mogoče izvajati teste lastnosti ERC4626 za lažje odkrivanje standardnih kršitev v implementacijah trezorjev. Preizkusi lastnosti (z dokumentacijo in primeri) so vsi javno dostopni v našem Githubu Skladišče. Veseli bomo vaših povratnih informacij in prispevkov!

***
Tukaj izražena stališča so stališča posameznega citiranega osebja družbe AH Capital Management, LLC (»a16z«) in niso stališča družbe a16z ali njenih podružnic. Nekatere informacije, vsebovane tukaj, so bile pridobljene iz virov tretjih oseb, vključno s portfeljskimi družbami skladov, ki jih upravlja a16z. Čeprav so vzeti iz virov, za katere menijo, da so zanesljivi, a16z ni neodvisno preveril takšnih informacij in ne daje nobenih zagotovil o trenutni ali trajni točnosti informacij ali njihovi ustreznosti za dano situacijo. Poleg tega lahko ta vsebina vključuje oglase tretjih oseb; a16z ni pregledal takšnih oglasov in ne podpira nobene oglaševalske vsebine v njih.

Ta vsebina je na voljo samo v informativne namene in se je ne smete zanašati kot pravni, poslovni, naložbeni ali davčni nasvet. Glede teh zadev se morate posvetovati s svojimi svetovalci. Sklici na katere koli vrednostne papirje ali digitalna sredstva so samo v ilustrativne namene in ne predstavljajo naložbenega priporočila ali ponudbe za zagotavljanje investicijskih svetovalnih storitev. Poleg tega ta vsebina ni namenjena nobenim vlagateljem ali bodočim vlagateljem niti ji ni namenjena in se nanjo v nobenem primeru ne smete zanašati, ko se odločate za vlaganje v kateri koli sklad, ki ga upravlja a16z. (Ponudba za vlaganje v sklad a16z bo podana le z memorandumom o zasebni plasiranju, pogodbo o vpisu in drugo ustrezno dokumentacijo katerega koli takega sklada in jo je treba prebrati v celoti.) Vse naložbe ali portfeljske družbe, omenjene, navedene ali opisane niso reprezentativne za vse naložbe v vozila, ki jih upravlja a16z, in ni nobenega zagotovila, da bodo naložbe donosne ali da bodo imele druge naložbe v prihodnosti podobne značilnosti ali rezultate. Seznam naložb skladov, ki jih upravlja Andreessen Horowitz (razen naložb, za katere izdajatelj ni dal dovoljenja a16z za javno razkritje, ter nenapovedanih naložb v digitalna sredstva, s katerimi se javno trguje), je na voljo na https://a16z.com/investments /.

Grafi in grafi, ki so navedeni znotraj, so izključno informativne narave in se nanje ne bi smeli zanašati pri sprejemanju kakršnih koli investicijskih odločitev. Pretekla uspešnost ni pokazatelj prihodnjih rezultatov. Vsebina govori samo od navedenega datuma. Vse projekcije, ocene, napovedi, cilji, obeti in/ali mnenja, izražena v tem gradivu, se lahko spremenijo brez predhodnega obvestila in se lahko razlikujejo ali so v nasprotju z mnenji, ki so jih izrazili drugi. Za dodatne pomembne informacije obiščite https://a16z.com/disclosures