Generaliserede egenskabstest for ERC4626 hvælvinger

Efterhånden som DeFi vokser og modnes, er skalerbar infrastruktur og sammensætning top of mind for udviklere. Ethereum Requests for Comments (eller ERC'er) — standardiserede værktøjssæt til at bygge Ethereum-baserede apps, såsom den meget brugte token-standard ERC20 — tjene den væsentlige rolle at give konsistente retningslinjer for udviklere, så de kan bidrage til økosystemet uden at starte fra bunden. Tidligere i år, tokeniseret hvælving standard ERC4626 blev oprettet for at fremme krydskompatibilitet mellem udbyttebærende tokens. Standardisering af implementeringsdetaljer kan også løse presserende problemer med sammensætning, hvilket gør protokolintegration lettere og i sidste ende mindre udsat for fejl.

Flere DeFi-projekter har allerede vedtaget standarden, der søger at øge sammensætningen af ​​deres hvælvinger, og vi forventer en bredere anvendelse i hele økosystemet. Tilpasning af eksisterende hvælvinger forårsager dog nogle voksesmerter; kritisk kan visse implementeringsfejl afsløre nye mål for angreb. Selv små fejl (så små som at fejlfortolke standardgrænsefladen) kan have betydelige konsekvenser for både sikkerhed og brugeroplevelse, hvilket understreger behovet for flere sikkerhedsværktøjer og -foranstaltninger, især inden for et mere sammensat DeFi-økosystem. 

Heldigvis kan simple fejl have relativt simple løsninger, hvis de opdages i god tid før de bliver udnyttet (og ideelt set før de overhovedet er implementeret). Til det formål frigav vi ERC4626 egenskabstest til fuzzing og symbolsk udførelse for at hjælpe hvælvingsbyggere med at opdage standardovertrædelser, der kan bryde integrationer eller føre til sårbarheder længere fremme. I dette indlæg forklarer vi det motiverende problem, gennemgår vores tilgang og afslutter med nogle konkrete råd.

Først lidt baggrund om ERC4626-standarden

Afsluttet i marts, ERC4626 er standarden for tokeniserede hvælvinger. Det blev introduceret for at udvide det meget brugte ERC20 standard (i øjeblikket grundlaget for hundredvis af tokens), tilskynd til standardisering på tværs af udbyttebærende hvælvinger og sikre komponerbarhed for de apps og protokoller (f.eks. udbytteaggregatorer), der skal interagere med dem. Dette betyder, at enhver app bygget på en ERC4626-boks nemt kan udvides til at fungere med enhver anden ERC4626-boks. 

Tokeniserede hvælvinger giver brugerne mulighed for frit at deponere aktiver til at præge hvælvingsandele og senere indløse disse aktier for at trække hovedstol og renter fra hvælvingen. Disse vault-aktier er ERC20-tokens og kan derfor nemt handles eller bruges som sikkerhed for at låne andre aktiver. For eksempel kan brugere deponere deres aktiver i Yearn-bokse for at præge yVault-tokens, som derefter kan handles på Uniswap, satses for yderligere afkast eller bruges som sikkerhed for udlånsprotokoller.

Forretningslogikken for generering og fordeling af afkast (og bestemmelse af aktiekursen) kan variere på tværs af implementeringer. For at dække så mange vaults som muligt (med det mål at gøre dem interoperable vs. identiske), fokuserer ERC4626-standarden på at beskrive brugergrænsefladen, hvilket efterlader de fleste af implementeringsdetaljerne uspecificerede. Dette giver mulighed for variationer i forretningslogik, så længe hvælvingen opfylder grænsefladens specifikke krav og tilskynder interoperabilitet på tværs af mange forskellige slags apps og typer af ERC4626-bokse.

Efterhånden som flere hvælvinger bliver skabt, forventer vi at se dem implementeret i henhold til ERC4626-standarden fra starten; men vi er i øjeblikket i en overgangsfase, hvor udviklere, der ønsker at drage fordel af større komponerbarhed, bliver nødt til at opdatere eksisterende vaults, apps og protokoller, så de er i overensstemmelse med standarden. Og efterhånden som de opgraderer, kæmper de med en række kompleksiteter og udfordringer. 

Udfordringerne ved standardoverensstemmelse (og faldgruberne ved ikke at overholde)

Det er ikke altid ligetil at følge en ny standard. Hver ERC4626-boks skal trofast (og nøjagtigt) implementere standardens krav som beskrevet. Ellers bliver integrationen af ​​ERC4626-hvælvinger mere og mere kompleks for at tage højde for forskellige variationer. Denne kompleksitet gør integrationer i sagens natur fejltilbøjelige; og fordi de ikke er tilstrækkeligt fremtidssikrede, kan de føre til sikkerhedssårbarheder over tid.

Ikke-standard ERC20-tokens (f.eks. Tether USD) kræver, at mange DeFi-systemer bruger et ekstra bibliotek (såsom SafeERC20), når de udfører token-overførsler for sikkert at håndtere divergerende adfærd (f.eks. returnerer intet, når en overførsel lykkes i stedet for at returnere true). Dette betyder, at alle systemer, der interagerer med disse tokens, kan blive sårbare, hvis systemet ikke er designet til korrekt at håndtere tilfælde af "manglende returneringer". Disse scenarier kan potentielt introducere en fælles sikkerhedsfælde og øge de samlede udviklings- og vedligeholdelsesomkostninger (når der tages højde for den yderligere logik og afhængigheder, der er nødvendige for at afbøde problemer). Overholdelse af standarden er derfor kritisk ikke kun for individuelle implementeringer, men også for sikkerheden i hele økosystemet. En sårbarhed i et enkelt system eller afhængighed kan forårsage udbredte problemer.

Ideelt set ville standarder være formelt specificeret uden tvetydighed (f.eks. formel specifikation af ERC20), og enhver implementering kunne formelt verificeres i forhold til standardspecifikationen. I praksis er dette dog ikke let at opnå på kort tid på grund af de omkostninger og den indsats, der kræves fra samfundet.

Introduktion af eksekverbare ERC4626-egenskaber for at identificere overensstemmelsesproblemer 

Mens vi arbejder hen imod en ideel tilstand (hver boks formelt bekræftet i forhold til strenge formelle specifikationer), har vi skrevet ERC4626-standarden egenskaber at fange uoverensstemmelser i subtile detaljer, der er nemme at gå glip af, i standardkravene.  

Vault-udviklere kan køre testene for at opdage potentielle standardovertrædelser i deres implementeringer før implementering. Og vault-integratorer kan kontrollere, om de givne vaults følger standarden, før de integreres i deres system. Egenskaberne kan også testes mod de levende hvælvinger, der allerede er installeret på mainnet, via mainnet gaffeltest. Det kan være nyttigt at teste live vaults - især når boksene er blevet installeret eller opgraderet for nylig - for at sikre, at alle systemparametre er indstillet korrekt. 

Vi valgte ejendomsbaserede tests - skrevet i Foundry og klar til at blive kørt af dens fuzzer - for at gøre egenskaberne eksekverbare (og dermed testbare). I fremtiden kan de også blive kørt af symbolsk udførelse eller modelkontrolværktøjer for formelt at verificere, at den givne hvælving opfylder egenskaberne for alle mulige input og betingelser.

Vi skrev egenskaberne til at være generelle nok til at blive anvendt på en bred vifte af hvælvinger, der implementerer forskellig forretningslogik. Vi brugte kun offentlige grænsefladefunktioner for at gøre dem agnostiske over for implementeringsdetaljer. (På grund af denne begrænsning blev visse standardkrav, der henviser til implementeringsspecifikke interne data, dog udeladt fra egenskaberne.)

For eksempel svarer følgende egenskab til et af kravene i convertToShares() funktion, "MÅ IKKE vise nogen variationer afhængigt af den, der ringer." I betragtning af de to kontoadresser og beløbet, får det hver af konti til at kalde convertToShares() med samme beløb, og sikrer, at de to returværdier er ens. Denne ejendom er uafhængig af implementeringsdetaljerne for convertToShares(), som varierer på tværs af hvælvinger og skal opfyldes af alle hvælvinger, der implementerer ERC4626. Denne egenskab kan udføres ved at angive specifikke inputværdier (til enhedstest), mange tilfældige input (til fuzz-test) eller symbolske værdier (til symbolsk udførelse og formel verifikation). Det kan også køres lokalt eller mod en mainnet-gaffel (til integrationstest).

Use case: egenskaber, der tester for afrundingsfejl

Afrundingsfejl er for eksempel en vigtig klasse af (tilsyneladende mindre) fejl, der kan have nogle serieimplikationer. Den underliggende regnskabslogik i ERC4626, f.eks. beregning af antallet af aktier, der skal præges, eller mængden af ​​aktiver, der skal trækkes ud, implementeres ved hjælp af fastpunktsregning - afrundingsfejl er uundgåelige. Til sikkerhedstandarden specificerer dog eksplicit den foretrukne afrundingsretning for hver grænsefladefunktion, mens fejlgrænserne efterlades uspecificerede og implementeringsafhængige. Specifikt deposit() , redeem() funktioner skal returnere en under-tilnærmelse af den nøjagtige værdi, mens den mint() , withdraw() funktioner skal returnere en i løbet af-tilnærmelse. For eksempel, hvis den aktuelle aktiekurs (dvs. mængden af ​​aktiver pr. aktie) er 2, så deposit() med 3 wei af aktiver bør kun præge op til 1 wei af aktier (dvs. floor(3/2)), mens withdraw() med 3 wei af aktiver bør brænde mindst 2 wei af aktier (dvs. ceil(3/2)).

Vi skrev de afrundingsrelaterede egenskaber til at være uafhængige af den underliggende regnskabslogik ved at behandle den som en sort boks. Helt konkret formulerede vi dem som såkaldte ”round-trip” egenskaber, som beskriver forholdet mellem to modsatte funktioner. For eksempel specificerer følgende egenskab, at tilbagetrækning af aktiver, der netop er blevet spærret ved udmøntning af N-aktier, skal forbrænde ikke mindre end N-aktier. Med andre ord, ingen kan få en gratis fortjeneste ved at konvertere aktiver og vault-aktier frem og tilbage ved gentagne gange at præge og trække dem ud.

Faktisk fandt vi ud af, at flere ERC4626-hvælvinger på mainnet ikke opfylder ovenstående egenskab på grund af afrundingsfejl. Det betyder, at enhver kan tjene, for eksempel, et par satoshi BTC (1 satoshi ~= 0.02 cent i skrivende stund) ved simpelthen (og gentagne gange) at præge og trække ud, langsomt tømme hvælvingen. Dette kan faktisk give en fortjeneste på kæder, der nyder godt af meget lave gasgebyrer (f.eks. Fantom), eller hvis aktivprisen bliver høj nok i fremtiden.

Test af ERC4626-standarden i naturen

Vi testede vores egenskaber mod ~100 ERC4626 hvælvinger på mainnet, og fandt mange hvælvinger, der ikke fulgte standardkravene - mest på grund af afrundingsfejlene (f.eks. ved at bruge gulvafrunding, hvor loft er ønsket, som vi beskrev). Specifikt kunne visse hvælvinger ikke præge det nøjagtige antal aktier, som blev anmodet om mint() funktion, selvom standarden eksplicit kræver denne. Nogle af dem udsendte også en inkonsistent Deposit hændelse, hvor de loggede data er forskellige fra det, der faktisk blev præget. Til vores overraskelse blev nogle hvælvinger aldrig præget på stedet overhovedet; i stedet sætter de bare mynteanmodningerne i en kø og behandler dem senere i en batch som en separat transaktion.

Selvom disse divergerende adfærd ikke kunne udnyttes i sig selv, kan de blive sårbare, når de integreres i andre systemer, der kun forventer standardadfærd. Disse problemer vil gøre vault-integration meget sværere, hvilket potentielt neutraliserer den igangværende indsats og driver motivationen bag standardisering.

Brug af vores ejendomstests og andre handlingsrettede skridt mod standardoverholdelse

At følge standarden præcist kan forhindre divergerende adfærd (ideelt set før de nogensinde bliver implementeret). Vi håber, at vores ejendomme hjælper, sammen med et par yderligere handlingspunkter. For dem, der udvikler og/eller integrerer ERC4626 vaults:

• Vi anbefaler stærkt at drive vores ejendom tests mod dine hvælvinger. De vil hurtigt finde problemer, hvis der er nogle klare overtrædelser af standarden.
• Vi foreslår også at gennemgå vores egenskaber at krydstjekke din forståelse af standardkravene og justere din implementering, hvis der er en utilsigtet uoverensstemmelse.
• Hvis din boks skal afvige fra standarden, anbefaler vi tydeligt at dokumentere den ikke-standardiserede adfærd, så andre korrekt kan håndtere disse afvigelser, når de integrerer med din boks. Bemærk venligst, at dette skal betragtes som en sidste udvej.

***
ERC4626-hvælvinger har potentialet til at blive en vigtig byggesten for DeFi i en overskuelig fremtid - og af hensyn til komponerbarheden er det vigtigt for både nye og eksisterende hvælvinger at følge standarden. Nye implementeringer vil dukke op efter standarden, så der er ikke noget bedre tidspunkt end nu til at standardisere eksisterende hvælvinger. 

Efterhånden som vi arbejder hen imod en ideel tilstand (hvor forskellige vaults er ensartet komponerbare), kan ERC4626-egenskabstests køres for lettere at opdage standardovertrædelser i vault-implementeringer. Ejendomstestene (med dokumentation og eksempler) er alle offentligt tilgængelige i vores Github Repository. Vi glæder os over din feedback og bidrag!

***
De synspunkter, der er udtrykt her, er dem fra det enkelte AH Capital Management, LLC ("a16z") personale, der er citeret, og er ikke synspunkter fra a16z eller dets tilknyttede selskaber. Visse oplysninger indeholdt heri er indhentet fra tredjepartskilder, herunder fra porteføljeselskaber af fonde forvaltet af a16z. Selvom det er taget fra kilder, der menes at være pålidelige, har a16z ikke uafhængigt verificeret sådanne oplysninger og fremsætter ingen repræsentationer om den aktuelle eller vedvarende nøjagtighed af oplysningerne eller dens passende for en given situation. Derudover kan dette indhold omfatte tredjepartsreklamer; a16z har ikke gennemgået sådanne annoncer og støtter ikke noget reklameindhold indeholdt deri.

Dette indhold er kun givet til informationsformål og bør ikke påberåbes som juridisk, forretningsmæssig, investerings- eller skatterådgivning. Du bør rådføre dig med dine egne rådgivere om disse spørgsmål. Henvisninger til værdipapirer eller digitale aktiver er kun til illustrationsformål og udgør ikke en investeringsanbefaling eller tilbud om at levere investeringsrådgivningstjenester. Ydermere er dette indhold ikke rettet mod eller beregnet til brug af nogen investorer eller potentielle investorer og kan under ingen omstændigheder stoles på, når der træffes en beslutning om at investere i en fond, der administreres af a16z. (Et tilbud om at investere i en a16z-fond vil kun blive givet af private placement-memorandummet, tegningsaftalen og anden relevant dokumentation for en sådan fond og bør læses i deres helhed.) Eventuelle investeringer eller porteføljeselskaber nævnt, refereret til eller beskrevne er ikke repræsentative for alle investeringer i køretøjer, der administreres af a16z, og der kan ikke gives sikkerhed for, at investeringerne vil være rentable, eller at andre investeringer foretaget i fremtiden vil have lignende karakteristika eller resultater. En liste over investeringer foretaget af fonde forvaltet af Andreessen Horowitz (undtagen investeringer, hvortil udstederen ikke har givet tilladelse til, at a16z offentliggør såvel som uanmeldte investeringer i offentligt handlede digitale aktiver) er tilgængelig på https://a16z.com/investments /.

Diagrammer og grafer, der er angivet i, er udelukkende til informationsformål og bør ikke stoles på, når der træffes nogen investeringsbeslutning. Tidligere resultater er ikke vejledende for fremtidige resultater. Indholdet taler kun fra den angivne dato. Alle fremskrivninger, estimater, prognoser, mål, udsigter og/eller meninger udtrykt i disse materialer kan ændres uden varsel og kan afvige fra eller være i modstrid med andres meninger. Se venligst https://a16z.com/disclosures for yderligere vigtige oplysninger