Generaliserte egenskapstester for ERC4626 hvelv

Etter hvert som DeFi vokser og modnes, er skalerbar infrastruktur og komponerbarhet det viktigste for utviklere. Ethereum Requests for Comments (eller ERCs) – standardiserte verktøysett for å bygge Ethereum-baserte apper, for eksempel den mye brukte token-standarden ERC20 — tjene den essensielle rollen å gi konsistente retningslinjer for utviklere for å bidra til økosystemet uten å starte fra bunnen av. Tidligere i år, tokenisert hvelvstandard ERC4626 ble opprettet for å oppmuntre til krysskompatibilitet mellom avkastningsbærende tokens. Standardisering av implementeringsdetaljer kan også adressere presserende komposisjonsproblemer, noe som gjør protokollintegrering enklere og til slutt mindre utsatt for feil.

Flere DeFi-prosjekter har allerede vedtatt standarden, som ønsker å øke komposisjonen til hvelvene deres, og vi forventer bredere bruk i hele økosystemet. Tilpasning av eksisterende hvelv forårsaker imidlertid noen voksesmerter; kritisk kan visse implementeringsfeil avsløre nye mål for angrep. Selv små feil (så små som å feiltolke standardgrensesnittet) kan ha betydelige konsekvenser for både sikkerhet og brukeropplevelse, noe som understreker behovet for flere sikkerhetsverktøy og -tiltak, spesielt innenfor et mer sammensatt DeFi-økosystem. 

Heldigvis kan enkle feil ha relativt enkle løsninger hvis de oppdages i god tid før de blir utnyttet (og ideelt sett før de i det hele tatt blir distribuert). For det formål slapp vi ERC4626 egenskapstester for uklar og symbolsk utførelse for å hjelpe hvelvbyggere med å oppdage standardbrudd som kan bryte integrasjoner eller føre til sårbarheter i etterkant. I dette innlegget forklarer vi det motiverende problemet, går gjennom tilnærmingen vår og avslutter med noen praktiske råd.

Først litt bakgrunn om ERC4626-standarden

Avsluttes i mars, ERC4626 er standarden for tokeniserte hvelv. Det ble introdusert for å utvide det mye brukte ERC20 standard (for øyeblikket basen for hundrevis av tokens), oppmuntre til standardisering på tvers av avkastningsbærende hvelv, og sikre komposisjon for appene og protokollene (f.eks. avkastningsaggregatorer) som trenger å samhandle med dem. Dette betyr at enhver app bygget på et ERC4626-hvelv enkelt kan utvides til å fungere med et hvilket som helst annet ERC4626-hvelv. 

Tokeniserte hvelv lar brukere fritt sette inn eiendeler for å lage hvelvandeler, og senere løse inn disse aksjene for å trekke hovedstol og renter fra hvelvet. Disse hvelvandelene er ERC20-tokens, og kan dermed enkelt handles eller brukes som sikkerhet for å låne andre eiendeler. For eksempel kan brukere sette inn eiendelene sine i Yearn-hvelv for å lage yVault-tokens, som deretter kan handles på Uniswap, satses for ytterligere avkastning eller brukes som sikkerhet for utlånsprotokoller.

Forretningslogikken for å generere og distribuere avkastning (og bestemme aksjekursen) kan variere på tvers av implementeringer. For å dekke så mange hvelv som mulig (med mål om å gjøre dem interoperable kontra identiske), fokuserer ERC4626-standarden på å beskrive brukergrensesnittet, og lar det meste av implementeringsdetaljene være uspesifisert. Dette tillater variasjoner i forretningslogikk så lenge hvelvet oppfyller de spesifikke kravene til grensesnittet, og oppmuntrer interoperabilitet på tvers av mange forskjellige typer apper og typer ERC4626-hvelv.

Etter hvert som flere hvelv blir opprettet, forventer vi å se dem implementert i henhold til ERC4626-standarden fra starten av; men vi er for øyeblikket i en overgangsfase, der utviklere som ønsker å dra nytte av større komponerbarhet, må oppdatere eksisterende hvelv, apper og protokoller for å samsvare med standarden. Og mens de oppgraderer, sliter de med en rekke kompleksiteter og utfordringer. 

Utfordringene med standardkonformitet (og fallgruvene ved å unnlate å overholde)

Det er ikke alltid like enkelt å følge en ny standard. Hvert ERC4626 hvelv må trofast (og nøyaktig) implementere standardens krav som beskrevet. Ellers blir integreringen av ERC4626-hvelv stadig mer kompleks for å ta hensyn til forskjellige variasjoner. Denne kompleksiteten gjør integrasjoner iboende feilutsatte; og fordi de ikke er tilstrekkelig fremtidssikret, kan de føre til sikkerhetssårbarheter over tid.

Ikke-standard ERC20-tokens (f.eks. Tether USD) krever at mange DeFi-systemer bruker et ekstra bibliotek (som SafeERC20) når de utfører tokenoverføringer for å håndtere divergerende atferd på en sikker måte (for eksempel å returnere ingenting når en overføring lykkes i stedet for å returnere true). Dette betyr at alle systemer som samhandler med disse tokenene kan bli sårbare hvis systemet ikke er designet for å håndtere tilfeller av "manglende returer". Disse scenariene kan potensielt introdusere en felles sikkerhetsfelle, og øke de totale utviklings- og vedlikeholdskostnadene (når man tar med den ekstra logikken og avhengighetene som trengs for å redusere problemer). Overholdelse av standarden er derfor kritisk ikke bare for individuelle implementeringer, men også for sikkerheten til hele økosystemet. Én sårbarhet i et enkelt system eller avhengighet kan forårsake omfattende problemer.

Ideelt sett vil standarder være formelt spesifisert uten tvetydighet (f.eks. formell spesifikasjon av ERC20), og hver implementering kan formelt verifiseres mot standardspesifikasjonen. I praksis er dette imidlertid ikke lett å oppnå på kort tid, på grunn av kostnadene og innsatsen som kreves fra samfunnet.

Vi introduserer kjørbare ERC4626-egenskaper for å identifisere samsvarsproblemer 

Mens vi jobber mot en ideell tilstand (hvert hvelv formelt bekreftet mot strenge formelle spesifikasjoner), har vi skrevet ERC4626-standarden egenskaper for å fange opp avvik i subtile detaljer som er enkle å gå glipp av i standardkravene.  

Vault-utviklere kan kjøre testene for å oppdage potensielle standardbrudd i deres implementeringer før distribusjon. Og hvelvintegratorer kan sjekke om de gitte hvelvene følger standarden før de integreres i systemet deres. Egenskapene kan også testes mot live-hvelvene som allerede er utplassert på mainnet, via mainnet gaffeltesting. Testing av levende hvelv kan være nyttig – spesielt når hvelvene har blitt distribuert eller oppgradert nylig – for å sikre at alle systemparametere er satt riktig. 

Vi valgte egenskapsbaserte tester – skrevet i Foundry og klare til å kjøres av fuzzeren – for å gjøre egenskapene kjørbare (og dermed testbare). I fremtiden kan de også kjøres av symbolsk utførelse eller modellkontrollverktøy for å formelt verifisere at det gitte hvelvet tilfredsstiller egenskapene for alle mulige innganger og forhold.

Vi skrev egenskapene til å være generelle nok til å brukes på et bredt spekter av hvelv som implementerer forskjellig forretningslogikk. Vi brukte bare offentlige grensesnittfunksjoner for å gjøre dem agnostiske for implementeringsdetaljer. (På grunn av denne begrensningen ble imidlertid visse standardkrav som refererer til implementeringsspesifikke interne data utelatt fra egenskapene.)

For eksempel tilsvarer følgende egenskap et av kravene til convertToShares() funksjon, "MÅ IKKE vise noen variasjoner avhengig av den som ringer." Gitt de to kontoadressene og beløpet, får den hver av kontoene til å ringe convertToShares() med samme beløp, og sikrer at de to returverdiene er like. Denne egenskapen er uavhengig av implementeringsdetaljene til convertToShares(), som varierer på tvers av hvelv og må tilfredsstilles av alle hvelv som implementerer ERC4626. Denne egenskapen kan utføres ved å gi spesifikke inngangsverdier (for enhetstesting), mange tilfeldige innganger (for fuzz-testing) eller symbolske verdier (for symbolsk utførelse og formell verifisering). Den kan også kjøres lokalt eller mot en nettgaffel (for integrasjonstesting).

Use case: egenskaper som tester for avrundingsfeil

Avrundingsfeil, for eksempel, er en viktig klasse av (tilsynelatende mindre) feil som kan ha noen serieimplikasjoner. Den underliggende regnskapslogikken til ERC4626, for eksempel beregning av antall aksjer som skal preges, eller mengden aktiva som skal trekkes ut, implementeres ved å bruke fastpunktsregning – avrundingsfeil er uunngåelige. Til sikkerhet, men standarden spesifiserer eksplisitt den foretrukne avrundingsretningen for hver grensesnittfunksjon, mens feilgrensene forblir uspesifiserte og implementeringsavhengige. Nærmere bestemt deposit() og redeem() funksjoner skal returnere en etter-tilnærming av den nøyaktige verdien, mens mint() og withdraw() funksjoner skal returnere en enn-tilnærming. For eksempel, hvis gjeldende aksjekurs (dvs. mengden aktiva per aksje) er 2, da deposit() med 3 wei av eiendeler bør bare prege opptil 1 wei av aksjer (dvs. floor(3/2)), samtidig som withdraw() med 3 wei av eiendeler bør brenne minst 2 wei av aksjer (dvs. ceil(3/2)).

Vi skrev de avrundingsrelaterte egenskapene til å være uavhengige av den underliggende regnskapslogikken ved å behandle den som en svart boks. Konkret formulerte vi dem som såkalte «tur-retur»-egenskaper, som beskriver forholdet mellom to motsatte funksjoner. For eksempel spesifiserer følgende egenskap at uttak av eiendeler som nettopp har blitt deponert ved å prege N aksjer, må brenne ikke mindre enn N aksjer. Med andre ord, ingen kan tjene en gratis fortjeneste ved å konvertere eiendeler og hvelvandeler frem og tilbake ved gjentatte preging og uttak.

Faktisk fant vi ut at flere ERC4626-hvelv på hovednettet ikke tilfredsstiller egenskapen ovenfor på grunn av avrundingsfeil. Dette betyr at hvem som helst kan tjene, for eksempel, et par satoshi BTC (1 satoshi ~= 0.02 cent i skrivende stund) ved ganske enkelt (og gjentatte ganger) å prege og trekke ut, sakte tømme hvelvet. Dette kan faktisk gi fortjeneste på kjeder som nyter godt av svært lave gassavgifter (f.eks. Fantom), eller hvis eiendelsprisen blir høy nok i fremtiden.

Tester ERC4626-standarden i naturen

Vi testet egenskapene våre mot ~100 ERC4626-hvelv på hovednettet, og fant mange hvelv som ikke fulgte standardkravene – mest på grunn av avrundingsfeil (f.eks. bruk av gulvavrunding der tak er ønsket, som vi beskrev). Spesielt klarte visse hvelv ikke å prege det nøyaktige antallet aksjer som ble bedt om av mint() funksjon, selv om standarden eksplisitt krever denne. Noen av dem ga også ut en inkonsekvent Deposit hendelse der de loggede dataene er forskjellig fra det som faktisk ble preget. Til vår overraskelse ble noen hvelv aldri preget på stedet i det hele tatt; i stedet setter de bare mynteforespørslene i en kø, og behandler dem senere i en batch som en separat transaksjon.

Selv om disse divergerende atferdene ikke kunne utnyttes i seg selv, kan de bli sårbare når de integreres i andre systemer som bare forventer standardatferd. Disse problemene vil gjøre hvelvintegrering mye vanskeligere, og potensielt nøytralisere den pågående innsatsen og drive motivasjonen bak standardisering.

Ved å bruke egenskapstestene våre og andre handlingsrettede skritt mot standardoverholdelse

Å følge standarden nøyaktig kan forhindre divergerende atferd (ideelt før de noen gang blir utplassert). Vi håper eiendommene våre hjelper, sammen med noen få ekstra handlingspunkter. For de som utvikler og/eller integrerer ERC4626-hvelv:

• Vi anbefaler på det sterkeste å drive eiendommen vår tester mot hvelvene dine. De vil raskt finne problemer hvis det er noen klare brudd på standarden.
• Vi foreslår også å gjennomgå vår egenskaper for å krysssjekke din forståelse av standardkravene, og justere implementeringen hvis det er utilsiktet avvik.
• Hvis hvelvet ditt må avvike fra standarden, anbefaler vi at du tydelig dokumenterer ikke-standard atferd, slik at andre kan håndtere disse avvikene på riktig måte når de integreres med hvelvet ditt. Vær oppmerksom på at dette bør betraktes som en siste utvei.

***
ERC4626-hvelv har potensial til å bli en viktig byggestein for DeFi i overskuelig fremtid — og for komponerbarhetens skyld er det viktig for både nye og eksisterende hvelv å følge standarden. Nye implementeringer vil dukke opp etter standarden, så det er ingen bedre tid enn nå for å standardisere eksisterende hvelv. 

Ettersom vi jobber mot en ideell tilstand (der forskjellige hvelv er enhetlig komponerbare), kan ERC4626-egenskapstester kjøres for lettere å oppdage standardbrudd i hvelvimplementeringer. Eiendomstestene (med dokumentasjon og eksempler) er alle offentlig tilgjengelige i vår Github Repository. Vi tar gjerne imot tilbakemeldinger og bidrag!

***
Synspunktene som er uttrykt her, er de fra individuelle AH Capital Management, LLC (“a16z”) personell som er sitert og er ikke synspunktene til a16z eller dets tilknyttede selskaper. Visse opplysninger her er innhentet fra tredjepartskilder, inkludert fra porteføljeselskaper av fond forvaltet av a16z. Selv om a16z er hentet fra kilder som antas å være pålitelige, har ikke a16z uavhengig verifisert slik informasjon og gir ingen representasjoner om den nåværende eller varige nøyaktigheten til informasjonen eller dens hensiktsmessighet for en gitt situasjon. I tillegg kan dette innholdet inkludere tredjepartsannonser; aXNUMXz har ikke vurdert slike annonser og støtter ikke noe reklameinnhold som finnes deri.

Dette innholdet er kun gitt for informasjonsformål, og bør ikke stoles på som juridisk, forretningsmessig, investerings- eller skatterådgivning. Du bør rådføre deg med dine egne rådgivere om disse sakene. Referanser til verdipapirer eller digitale eiendeler er kun for illustrasjonsformål, og utgjør ikke en investeringsanbefaling eller tilbud om å tilby investeringsrådgivningstjenester. Videre er dette innholdet ikke rettet mot eller ment for bruk av noen investorer eller potensielle investorer, og kan ikke under noen omstendigheter stoles på når du tar en beslutning om å investere i et fond som forvaltes av a16z. (Et tilbud om å investere i et a16z-fond vil kun gis av det private emisjonsmemorandumet, tegningsavtalen og annen relevant dokumentasjon for et slikt fond og bør leses i sin helhet.) Eventuelle investeringer eller porteføljeselskaper nevnt, referert til, eller beskrevet er ikke representative for alle investeringer i kjøretøy forvaltet av a16z, og det kan ikke gis noen garanti for at investeringene vil være lønnsomme eller at andre investeringer som gjøres i fremtiden vil ha lignende egenskaper eller resultater. En liste over investeringer foretatt av fond forvaltet av Andreessen Horowitz (unntatt investeringer som utstederen ikke har gitt tillatelse til at a16z kan offentliggjøre så vel som uanmeldte investeringer i børsnoterte digitale eiendeler) er tilgjengelig på https://a16z.com/investments /.

Diagrammer og grafer gitt i er kun for informasjonsformål og bør ikke stoles på når du tar investeringsbeslutninger. Tidligere resultater er ikke en indikasjon på fremtidige resultater. Innholdet taler kun fra den angitte datoen. Eventuelle anslag, estimater, prognoser, mål, prospekter og/eller meninger uttrykt i dette materialet kan endres uten varsel og kan avvike eller være i strid med meninger uttrykt av andre. Se https://a16z.com/disclosures for ytterligere viktig informasjon