Generaliserade egenskapstester för ERC4626-valv

När DeFi växer och mognar är skalbar infrastruktur och komponerbarhet högst upp i sinnet för utvecklare. Ethereum Requests for Comments (eller ERC) — standardiserade verktygssatser för att bygga Ethereum-baserade appar, till exempel den allmänt använda tokenstandarden ERC20 — tjäna den väsentliga rollen att tillhandahålla konsekventa riktlinjer för utvecklare att bidra till ekosystemet utan att börja om från början. Tidigare i år, tokeniserad valvstandard ERC4626 skapades för att uppmuntra korskompatibilitet mellan avkastningsbärande tokens. Standardisering av implementeringsdetaljer kan också ta itu med pressande problem med sammansättning, vilket gör protokollintegrering enklare och i slutändan mindre felbenägen.

Flera DeFi-projekt har redan gjort det antagen standarden, som vill öka sammansättningsförmågan hos deras valv, och vi förväntar oss en bredare användning i hela ekosystemet. Att anpassa befintliga valv orsakar dock en del växtvärk; kritiskt, vissa implementeringsfel kan exponera nya mål för attack. Även små fel (så små som att feltolka standardgränssnittet) kan få betydande konsekvenser för både säkerhet och användarupplevelse, vilket understryker behovet av fler säkerhetsverktyg och -åtgärder, särskilt inom ett mer komponerbart DeFi-ekosystem. 

Lyckligtvis kan enkla fel ha relativt enkla lösningar om de upptäcks långt innan de utnyttjas (och helst innan de ens distribueras). För det ändamålet släppte vi ERC4626 egenskapstester för fuzzing och symbolisk utförande för att hjälpa valvbyggare att upptäcka standardöverträdelser som kan bryta integrationer eller leda till sårbarheter längre fram. I det här inlägget förklarar vi det motiverande problemet, går igenom vårt tillvägagångssätt och avslutar med några praktiska råd.

Först lite bakgrund om ERC4626-standarden

Slutfördes i mars, ERC4626 är standarden för tokeniserade valv. Det introducerades för att utöka det allmänt använda ERC20 standard (för närvarande basen för hundratals tokens), uppmuntra standardisering över avkastningsbärande valv och säkerställa komponerbarhet för appar och protokoll (t.ex. avkastningsaggregatorer) som behöver interagera med dem. Detta innebär att alla appar som är byggda på ett ERC4626-valv enkelt kan utökas för att fungera med alla andra ERC4626-valv. 

Tokeniserade valv tillåter användare att fritt sätta in tillgångar för att prägla valvaktier och senare lösa in dessa aktier för att dra ut kapital och ränta från valvet. Dessa valvaktier är ERC20-tokens och kan därför enkelt handlas eller användas som säkerhet för att låna andra tillgångar. Användare kan till exempel sätta in sina tillgångar i Yearn-valv för att skapa yVault-tokens, som sedan kan handlas på Uniswap, satsas för ytterligare avkastning eller användas som säkerhet för utlåningsprotokoll.

Affärslogiken för att generera och distribuera avkastning (och bestämma aktiekursen) kan variera mellan olika implementeringar. För att täcka så många valv som möjligt (med målet att göra dem interoperabla kontra identiska), fokuserar ERC4626-standarden på att beskriva användargränssnittet och lämnar de flesta av implementeringsdetaljerna ospecificerade. Detta möjliggör variationer i affärslogik så länge som valvet uppfyller de specifika kraven för gränssnittet, och uppmuntrar interoperabilitet mellan många olika typer av appar och typer av ERC4626-valv.

När fler valv skapas förväntar vi oss att se dem implementerade enligt ERC4626-standarden från början; men vi är för närvarande i en något övergångsfas, där utvecklare som vill dra fördel av större komponerbarhet kommer att behöva uppdatera befintliga valv, appar och protokoll för att överensstämma med standarden. Och när de uppgraderar, brottas de med ett antal komplexiteter och utmaningar. 

Utmaningarna med standardöverensstämmelse (och fallgroparna med att inte anpassa sig)

Att följa en ny standard är inte alltid lätt. Varje ERC4626-valv måste troget (och exakt) implementera standardens krav enligt beskrivningen. Annars blir integrationen av ERC4626-valv allt mer komplex för att ta hänsyn till olika variationer. Denna komplexitet gör integrationer i sig felbenägna; och eftersom de inte är tillräckligt framtidssäkra, kan de leda till säkerhetsbrister över tid.

Icke-standardiserade ERC20-tokens (t.ex. Tether USD) kräver att många DeFi-system använder ett extra bibliotek (som SafeERC20) när de utför tokenöverföringar för att säkert hantera olika beteenden (till exempel returnera ingenting när en överföring lyckas istället för att returnera true). Detta innebär att alla system som interagerar med dessa tokens kan bli sårbara om systemet inte är utformat för att korrekt hantera fall av "saknade returer". Dessa scenarier kan potentiellt introducera en gemensam säkerhetsfälla och öka de totala utvecklings- och underhållskostnaderna (när man tar hänsyn till den ytterligare logik och beroenden som behövs för att mildra problem). Att följa standarden är därför avgörande inte bara för enskilda implementeringar utan också för säkerheten för hela ekosystemet. En sårbarhet i ett enda system eller beroende kan orsaka omfattande problem.

Helst skulle standarder vara formellt specificerade utan tvetydighet (t.ex. formell specifikation av ERC20), och varje implementering kan formellt verifieras mot standardspecifikationen. I praktiken är detta dock inte lätt att uppnå på kort tid, på grund av de kostnader och ansträngningar som krävs från samhället.

Vi introducerar körbara ERC4626-egenskaper för att identifiera överensstämmelseproblem 

När vi arbetar mot ett idealiskt tillstånd (varje valv formellt verifierad mot rigorösa formella specifikationer), har vi skrivit ERC4626-standarden egenskaper för att fånga avvikelser i subtila detaljer som är lätta att missa i standardkraven.  

Vault-utvecklare kan köra testerna för att upptäcka potentiella standardöverträdelser i deras implementeringar före implementering. Och valvintegratörer kan kontrollera om de givna valven följer standarden innan de integreras i deras system. Egenskaperna kan också testas mot de levande valven som redan är utplacerade på huvudnätet, via mainnet-gaffeltestning. Att testa livevalv kan vara användbart - speciellt när valven har distribuerats eller uppgraderats nyligen - för att säkerställa att alla systemparametrar har ställts in korrekt. 

Vi valde egenskapsbaserade tester - skrivna i Foundry och redo att köras av dess fuzzer - för att göra egenskaperna körbara (och därmed testbara). I framtiden kan de också köras av symbolisk exekvering eller modellkontrollverktyg för att formellt verifiera att det givna valvet uppfyller egenskaperna för alla möjliga indata och villkor.

Vi skrev egenskaperna så att de var tillräckligt generella för att kunna tillämpas på ett brett utbud av valv som implementerar olika affärslogik. Vi använde endast offentliga gränssnittsfunktioner för att göra dem agnostiska mot implementeringsdetaljer. (På grund av denna begränsning uteslöts dock vissa standardkrav som hänvisar till implementeringsspecifika interna data från egenskaperna.)

Till exempel motsvarar följande egenskap ett av kraven i convertToShares() funktion, "FÅR INTE visa några variationer beroende på den som ringer.” Med tanke på de två kontoadresserna och beloppet gör det att vart och ett av kontona ringer convertToShares() med samma belopp och säkerställer att de två returvärdena är lika. Denna egenskap är oberoende av implementeringsdetaljerna för convertToShares(), som varierar mellan valv och måste uppfyllas av alla valv som implementerar ERC4626. Den här egenskapen kan exekveras genom att tillhandahålla specifika ingångsvärden (för enhetstestning), många slumpmässiga ingångar (för fuzz-testning) eller symboliska värden (för symbolisk exekvering och formell verifiering). Den kan också köras lokalt eller mot en mainnet-gaffel (för integrationstestning).

Användningsfall: egenskaper som testar för avrundningsfel

Avrundningsfel, till exempel, är en viktig klass av (till synes mindre) buggar som kan ha vissa serieimplikationer. Den underliggande redovisningslogiken i ERC4626, t.ex. beräkning av antalet aktier som ska präglas, eller mängden tillgångar som ska tas ut, implementeras med aritmetik med fast punkt – avrundningsfel är oundvikliga. För säkerhetstandarden specificerar emellertid uttryckligen den föredragna avrundningsriktningen för varje gränssnittsfunktion, samtidigt som felgränserna lämnas ospecificerade och implementeringsberoende. Närmare bestämt deposit() och redeem() funktioner ska returnera en under-approximation av det exakta värdet, medan mint() och withdraw() funktioner ska returnera en över-approximation. Till exempel, om den aktuella aktiekursen (dvs mängden tillgångar per aktie) är 2, då deposit() med 3 wei av tillgångar bör endast präglas upp till 1 wei av aktier (dvs. floor(3/2)), medan withdraw() med 3 wei av tillgångar bör bränna minst 2 wei av aktier (dvs. ceil(3/2)).

Vi skrev de avrundningsrelaterade egenskaperna för att vara oberoende av den underliggande redovisningslogiken genom att behandla den som en svart låda. Specifikt formulerade vi dem som så kallade "round-trip" egenskaper, som beskriver förhållandet mellan två motsatta funktioner. Till exempel anger följande egenskap att uttag av tillgångar som just har spärrats genom att prägla N-aktier måste förbrännas inte mindre än N-aktier. Med andra ord, ingen kan göra en gratis vinst genom att konvertera tillgångar och valvaktier fram och tillbaka genom att upprepade gånger prägla och ta ut dem.

Vi fann faktiskt att flera ERC4626-valv på huvudnätet misslyckas med att tillfredsställa ovanstående egenskap på grund av avrundningsfel. Det betyder att vem som helst kan tjäna, till exempel, ett par satoshi BTC (1 satoshi ~= 0.02 cent i skrivande stund) genom att helt enkelt (och upprepade gånger) prägla och dra ut, långsamt tömma valvet. Detta kan faktiskt ge en vinst på kedjor som åtnjuter mycket låga gasavgifter (t.ex. Fantom), eller om tillgångspriset blir tillräckligt högt i framtiden.

Testar ERC4626-standarden i naturen

Vi testade våra egenskaper mot ~100 ERC4626-valv på huvudnätet och hittade många valv som inte följde standardkraven - mestadels på grund av avrundningsfel (t.ex. att använda golvavrundning där tak önskas, som vi beskrev). Specifikt misslyckades vissa valv att prägla det exakta antalet aktier som begärts av mint() funktion, även om standarden uttryckligen kräver detta. Några av dem avgav också en inkonsekvent Deposit händelse där loggade data skiljer sig från vad som faktiskt skapades. Till vår förvåning präglade några valv aldrig på plats alls; istället lägger de bara myntförfrågningarna i en kö och behandlar dem senare i en batch som en separat transaktion.

Även om dessa divergerande beteenden inte var exploaterbara i sig, kan de bli sårbara när de integreras i andra system som bara förväntar sig standardbeteenden. Dessa problem kommer att göra valvintegreringen mycket svårare, vilket potentiellt neutraliserar de pågående ansträngningarna och driver motivationen bakom standardisering.

Använda våra fastighetstester och andra åtgärder mot standardöverensstämmelse

Att följa standarden exakt kan förhindra divergerande beteenden (helst innan de någonsin implementeras). Vi hoppas att våra fastigheter hjälper, tillsammans med några ytterligare åtgärder. För dem som utvecklar och/eller integrerar ERC4626-valv:

• Vi rekommenderar starkt att driva vår fastighet tester mot dina valv. De kommer snabbt att hitta problem om det finns några tydliga överträdelser av standarden.
• Vi föreslår också att du granskar vår egenskaper för att korskontrollera din förståelse av standardkraven och justera din implementering om det finns någon oavsiktlig avvikelse.
• Om ditt valv måste avvika från standarden rekommenderar vi att du tydligt dokumenterar de icke-standardiserade beteenden, så att andra korrekt kan hantera dessa avvikelser när de integreras med ditt valv. Observera att detta bör ses som en sista utväg.

***
ERC4626-valv har potential att bli en viktig byggsten för DeFi inom överskådlig framtid — och, för komponerbarhetens skull, är det viktigt för både nya och befintliga valv att följa standarden. Nya implementeringar kommer att dyka upp efter standarden, så det finns ingen bättre tid än nu för att standardisera befintliga valv. 

När vi arbetar mot ett idealiskt tillstånd (där olika valv är enhetligt sammansatta), kan ERC4626-egenskapstester köras för att lättare upptäcka standardöverträdelser i valvimplementeringar. Egenskapstesterna (med dokumentation och exempel) är alla offentligt tillgängliga i vår Github Repository. Vi välkomnar din feedback och bidrag!

***
De åsikter som uttrycks här är de från den individuella AH Capital Management, LLC (“a16z”) personal som citeras och är inte åsikterna från a16z eller dess dotterbolag. Viss information som finns här har erhållits från tredjepartskällor, inklusive från portföljbolag av fonder som förvaltas av a16z. Även om den är hämtad från källor som anses vara tillförlitliga, har a16z inte självständigt verifierat sådan information och gör inga utfästelser om den aktuella eller varaktiga riktigheten av informationen eller dess lämplighet för en given situation. Dessutom kan detta innehåll innehålla tredjepartsannonser; a16z har inte granskat sådana annonser och stöder inte något reklaminnehåll i dem.

Detta innehåll tillhandahålls endast i informationssyfte och bör inte litas på som juridisk rådgivning, affärs-, investerings- eller skatterådgivning. Du bör rådfråga dina egna rådgivare i dessa frågor. Hänvisningar till värdepapper eller digitala tillgångar är endast i illustrativt syfte och utgör inte en investeringsrekommendation eller erbjudande om att tillhandahålla investeringsrådgivningstjänster. Dessutom är detta innehåll inte riktat till eller avsett att användas av några investerare eller potentiella investerare, och får inte under några omständigheter lita på när man fattar ett beslut om att investera i någon fond som förvaltas av a16z. (Ett erbjudande om att investera i en a16z-fond kommer endast att göras av det privata emissionsmemorandumet, teckningsavtalet och annan relevant dokumentation för en sådan fond och bör läsas i sin helhet.) Alla investeringar eller portföljbolag som nämns, hänvisas till, eller beskrivna är inte representativa för alla investeringar i fordon som förvaltas av a16z, och det finns ingen garanti för att investeringarna kommer att vara lönsamma eller att andra investeringar som görs i framtiden kommer att ha liknande egenskaper eller resultat. En lista över investeringar gjorda av fonder som förvaltas av Andreessen Horowitz (exklusive investeringar för vilka emittenten inte har gett tillstånd för a16z att offentliggöra såväl som oanmälda investeringar i börsnoterade digitala tillgångar) finns tillgänglig på https://a16z.com/investments /.

Diagram och grafer som tillhandahålls i är endast i informationssyfte och bör inte litas på när man fattar investeringsbeslut. Tidigare resultat är inte en indikation på framtida resultat. Innehållet talar endast från det angivna datumet. Alla prognoser, uppskattningar, prognoser, mål, framtidsutsikter och/eller åsikter som uttrycks i detta material kan ändras utan föregående meddelande och kan skilja sig åt eller strida mot åsikter som uttrycks av andra. Se https://a16z.com/disclosures för ytterligare viktig information