Általános tulajdonságtesztek ERC4626 tárolókhoz

Ahogy a DeFi növekszik és fejlődik, a méretezhető infrastruktúra és a kompozíció a fejlesztők szem előtt tartásával foglalkozik. Ethereum Requests for Comments (vagy ERC-k) – szabványos eszközkészletek Ethereum-alapú alkalmazások készítéséhez, például a széles körben használt token szabványhoz ERC20 — alapvető szerepe, hogy következetes iránymutatásokat adjon a fejlesztőknek az ökoszisztémához való hozzájáruláshoz anélkül, hogy a nulláról indulnának. Korábban ebben az évben, tokenizált boltozat szabvány ERC4626 azért jött létre, hogy elősegítse a hozamot hordozó tokenek közötti keresztkompatibilitást. A megvalósítás részleteinek szabványosítása a sürgető kompozíciós problémákat is megoldhatja, megkönnyítve a protokoll-integrációt, és végső soron kevésbé hibás.

Számos DeFi projekt már fogadott a szabványt, hogy növeljék a boltozatok összeállíthatóságát, és várhatóan szélesebb körben alkalmazzák az ökoszisztémában. A meglévő boltozatok adaptálása azonban növekedési fájdalmat okoz; kritikus szempontból bizonyos megvalósítási hibák új célpontokat tehetnek ki a támadásnak. Még az apró hibák is (olyan kicsik, mint a szabványos felület félreértelmezése) jelentős következményekkel járhatnak mind a biztonságra, mind a felhasználói élményre nézve, hangsúlyozva, hogy több biztonsági eszközre és intézkedésre van szükség, különösen egy összetettebb DeFi ökoszisztémán belül. 

Szerencsére az egyszerű hibáknak viszonylag egyszerű megoldásaik lehetnek, ha jóval a kihasználásuk előtt észlelik őket (de ideális esetben még a telepítés előtt). Ennek érdekében elengedtük ERC4626 tulajdonságtesztek a zavaros és szimbolikus végrehajtáshoz, hogy segítsen a tárolókészítőknek felderíteni a szabványsértéseket, amelyek megszakíthatják az integrációt, vagy sebezhetőséghez vezethetnek. Ebben a bejegyzésben elmagyarázzuk a motiváló problémát, végigjárjuk a megközelítésünket, és néhány gyakorlati tanáccsal zárjuk.

Először egy kis háttér az ERC4626 szabványról

márciusban véglegesítették, ERC4626 a tokenizált trezorok szabványa. A széles körben használt kiterjesztése érdekében vezették be ERC20 szabvány (jelenleg több száz tokenek alapja), ösztönzi a szabványosítást a hozamot hordozó tárolókban, és biztosítja a kompozíciót az alkalmazások és protokollok (pl. hozamaggregátorok) számára, amelyeknek interakcióba kell lépniük velük. Ez azt jelenti, hogy az ERC4626 tárolóra épített bármely alkalmazás könnyen kiterjeszthető bármely más ERC4626 tárolóval való együttműködésre. 

A tokenizált trezorok lehetővé teszik a felhasználók számára, hogy szabadon letétbe helyezzék vagyonukat a trezorrészvények verdésére, majd később beváltsák ezeket a részvényeket, hogy kivegyék a tőkét és a kamatot a trezorból. Ezek a trezorrészvények ERC20 tokenek, így könnyen kereskedhetnek velük, vagy fedezetként felhasználhatók más eszközök kölcsönzésére. Például a felhasználók elhelyezhetik eszközeiket Yearn trezorokban, hogy yVault tokeneket verhessenek, amelyeket aztán Uniswapban kereskedhetnek, további hozamért tétbe helyezhetik, vagy fedezetként használhatják fel hitelezési protokollokhoz.

A hozam generálására és elosztására (és a részvényárfolyam meghatározására) vonatkozó üzleti logika megvalósításonként eltérő lehet. Annak érdekében, hogy a lehető legtöbb tárolót lefedje (az interoperábilis vagy azonos céllal), az ERC4626 szabvány a felhasználói felület leírására összpontosít, és a megvalósítási részletek nagy részét meghatározatlanul hagyja. Ez lehetővé teszi az üzleti logika eltéréseit mindaddig, amíg a trezor megfelel a felület speciális követelményeinek, és ösztönzi sokféle alkalmazás és típusú ERC4626 tároló közötti interoperabilitás.

Ahogy egyre több trezor jön létre, várhatóan a kezdetektől fogva az ERC4626 szabvány szerint fogjuk megvalósítani őket; de jelenleg egy átmeneti szakaszban vagyunk, amikor a nagyobb kompozíció előnyeit kihasználni kívánó fejlesztőknek frissíteniük kell a meglévő trezorokat, alkalmazásokat és protokollokat, hogy megfeleljenek a szabványnak. A frissítés során pedig számos bonyolultsággal és kihívással kell megküzdeniük. 

A szabványmegfelelés kihívásai (és a megfelelés elmulasztásának buktatói)

Egy új szabvány követése nem mindig egyszerű. Minden ERC4626 tárolónak hűen (és pontosan) meg kell felelnie a szabvány követelményeinek a leírtak szerint. Ellenkező esetben az ERC4626 tárolók integrációja egyre bonyolultabbá válik a különböző változatok figyelembevétele érdekében. Ez a bonyolultság az integrációkat eredendően hibaveszélyessé teszi; és mivel nem eléggé jövőbiztosak, idővel biztonsági résekhez vezethetnek.

A nem szabványos ERC20 tokenek (pl. Tether USD) számos DeFi rendszernek megkövetelik, hogy további könyvtárat (például SafeERC20) használjon a tokenátvitel során, hogy biztonságosan kezelje az eltérő viselkedéseket (például a visszaadás helyett nem ad vissza semmit, ha egy átvitel sikeres true). Ez azt jelenti, hogy az ezekkel a tokenekkel kölcsönhatásba lépő rendszerek sebezhetővé válhatnak, ha a rendszert nem úgy tervezték, hogy megfelelően kezelje a „hiányzó visszaküldések” eseteit. Ezek a forgatókönyvek potenciálisan általános biztonsági buktatót okozhatnak, és növelhetik az általános fejlesztési és karbantartási költségeket (ha figyelembe veszik a problémák enyhítéséhez szükséges további logikát és függőségeket). A szabványnak való megfelelés ezért nemcsak az egyes megvalósítások, hanem az egész ökoszisztéma biztonsága szempontjából is kritikus. Egyetlen rendszer vagy függőség egyetlen sebezhetősége széles körben elterjedt problémákat okozhat.

Ideális esetben a szabványokat formálisan, kétértelműség nélkül határoznák meg (pl. az ERC20 formális specifikációja), és minden megvalósítás formálisan ellenőrizhető a szabványos specifikációval összhangban. A gyakorlatban azonban ezt nem könnyű elérni rövid időn belül, a közösség költsége és erőfeszítése miatt.

A végrehajtható ERC4626 tulajdonságok bemutatása a megfelelőségi problémák azonosításához 

Miközben az ideális állapot elérésén dolgozunk (minden trezort formálisan ellenőriznek a szigorú formális előírások szerint), megírtuk az ERC4626 szabványt. ingatlanait a szabványkövetelmények finom, könnyen észrevehető részleteiben tapasztalható eltérések észlelésére.  

A Vault fejlesztői futtathatják a teszteket, hogy a telepítés előtt észleljék a lehetséges szabványsértéseket a megvalósításukban. A trezorintegrátorok pedig ellenőrizhetik, hogy az adott trezorok követik-e a szabványt, mielőtt integrálnák őket a rendszerükbe. A tulajdonságok a főhálózaton már telepített élő tárolókkal szemben is tesztelhetők, a mainnet fork teszteléssel. Az élő tárolók tesztelése hasznos lehet – különösen akkor, ha a tárolókat a közelmúltban telepítették vagy frissítették – annak biztosítása érdekében, hogy az összes rendszerparaméter megfelelően be legyen állítva. 

Tulajdonság-alapú teszteket választottunk – amelyeket Foundry-ban írtak, és készen állnak a fuzzer általi futtatásra – annak érdekében, hogy a tulajdonságokat végrehajthatóvá (és így tesztelhetővé) tegyük. A jövőben szimbolikus végrehajtási vagy modellellenőrző eszközökkel is futtathatók, hogy formálisan ellenőrizzék, hogy az adott tároló minden lehetséges bemenetre és feltételre vonatkozóan megfelel-e a tulajdonságoknak.

A tulajdonságokat úgy írtuk le, hogy azok elég általánosak legyenek ahhoz, hogy az eltérő üzleti logikát megvalósító tárolók széles skálájára lehessen alkalmazni. Csak nyilvános interfész-funkciókat használtunk, hogy agnosztikussá tegyük őket a megvalósítás részleteivel szemben. (E korlátozás miatt azonban bizonyos szabványos követelmények, amelyek az implementáció-specifikus belső adatokra vonatkoznak, kimaradtak a tulajdonságokból.)

Például a következő tulajdonság megfelel az egyik követelménynek convertToShares() funkció, "NEM SZABAD mutatni semmilyen eltérést a hívó féltől függően.” Tekintettel a két számlacímre és az összegre, mindegyik számlát lehívja convertToShares() azonos összeggel, és biztosítja, hogy a két visszatérési érték egyenlő legyen. Ez a tulajdonság független a megvalósítás részleteitől convertToShares(), amely a tárolókonként változik, és minden olyan tárolónak meg kell felelnie, amely megvalósítja az ERC4626-ot. Ez a tulajdonság végrehajtható meghatározott bemeneti értékek megadásával (egységteszthez), sok véletlenszerű bemenettel (fuzz teszteléshez) vagy szimbolikus értékekkel (szimbolikus végrehajtáshoz és formális ellenőrzéshez). Futtatható helyben vagy hálózati villával szemben is (integrációs teszteléshez).

Használati eset: olyan tulajdonságok, amelyek a kerekítési hibákat tesztelik

A kerekítési hibák például a (látszólag kisebb) hibák fontos osztályát képezik, amelyeknek sorozatos következményei lehetnek. Az ERC4626 mögöttes elszámolási logikája, pl. a verendő részvények számának vagy a kivonandó eszközök mennyiségének kiszámítása fixpontos aritmetikával valósul meg – a kerekítési hibák elkerülhetetlenek. Mert biztonságazonban a szabvány kifejezetten meghatározza az előnyben részesített kerekítési irányt minden egyes interfészfüggvényhez, miközben a hibahatárokat meghatározatlan és megvalósításfüggő hagyja. Konkrétan a deposit() és a redeem() függvényeknek vissza kell adniuk an alatt-a pontos érték közelítése, míg a mint() és a withdraw() függvényeknek vissza kell adniuk an felett-közelítés. Például, ha a részvény aktuális árfolyama (vagyis az egy részvényre jutó eszközök összege) 2, akkor deposit() 3 wei vagyonnal legfeljebb 1 wei részvényt szabad verni (pl. floor(3/2)), míg withdraw() 3 wei vagyonnal legalább 2 wei részvényt kell elégetnie (pl. ceil(3/2)).

A kerekítéssel kapcsolatos tulajdonságokat úgy írtuk le, hogy függetlenek legyenek a mögöttes elszámolási logikától, fekete dobozként kezelve. Konkrétan úgynevezett „oda-vissza” tulajdonságokként fogalmaztuk meg őket, amelyek két ellentétes függvény kapcsolatát írják le. Például a következő tulajdonság meghatározza, hogy az N részvény verésével éppen letétbe helyezett eszközök kivonása legalább N részvénynek kell legyen elégetnie. Más szóval, senki sem tud ingyen profitot szerezni az eszközök és a trezorrészvények oda-vissza konvertálásával ismételt pénzveréssel és kivonásokkal.

Valójában azt találtuk, hogy a mainnet számos ERC4626 tárolója nem felel meg a fenti tulajdonságnak kerekítési hibák miatt. Ez azt jelenti, hogy bárki kereshet például pár satoshi BTC-t (1 satoshi ~= 0.02 cent a cikk írásakor), ha egyszerűen (és ismételten) ver és kiveszi, lassan kiürítve a trezort. Ez ténylegesen profitot termelhet a nagyon alacsony gázdíjat élvező láncoknál (pl. Fantom), vagy ha az eszköz ára a jövőben elég magas lesz.

Az ERC4626 szabvány tesztelése vadon

Tulajdonságainkat ~100 ERC4626 tárolóval teszteltük a főhálózaton, és sok olyan boltozatot találtunk, amelyek nem feleltek meg a szabványos követelményeknek – főként a kerekítési hibák miatt (pl. padlókerekítés alkalmazása ott, ahol a mennyezet kívánatos, ahogy azt leírtuk). Konkrétan, bizonyos trezorok nem tudtak pontosan annyi részvényt verni, amennyit a kért mint() funkciót, bár a szabvány kifejezetten megköveteli ezt. Némelyikük következetlent is bocsátott ki Deposit esemény, amikor a naplózott adatok eltérnek a ténylegesen vert adatoktól. Meglepetésünkre néhány boltozatot egyáltalán nem vertek a helyszínen; ehelyett csak egy sorba teszik a mintakérelmeket, és később egy kötegben, külön tranzakcióként dolgozzák fel őket.

Bár ezek az eltérő viselkedések önmagukban nem voltak kihasználhatók, sebezhetővé válhatnak, ha olyan más rendszerekbe integrálják őket, amelyek csak a szokásos viselkedést várják el. Ezek a problémák jelentősen megnehezítik az értéktár integrációját, potenciálisan semlegesítve a folyamatban lévő erőfeszítéseket, és ösztönözve a szabványosítás mögötti motivációt.

Tulajdonsági tesztjeink és más, a szabványos megfelelés érdekében végrehajtható lépéseink használata

A szabvány pontos betartása megakadályozhatja az eltérő viselkedéseket (ideális esetben még a telepítés előtt). Reméljük, hogy tulajdonságaink segítenek néhány további műveleti elemmel együtt. Azok számára, akik ERC4626 tárolókat fejlesztenek és/vagy integrálnak:

• Javasoljuk ingatlanunk üzemeltetését tesztek a páncélszekrényei ellen. Gyorsan megtalálják a problémákat, ha egyértelműen megsértik a szabványt.
• Javasoljuk továbbá, hogy tekintse át a mi ingatlanait ellenőrizni, hogy megértette-e a szabványos követelményeket, és módosítani kell a megvalósítást, ha nem szándékos eltérés van.
• Ha a tárolónak el kell térnie a szabványtól, javasoljuk, hogy egyértelműen dokumentálja a nem szabványos viselkedéseket, hogy mások megfelelően kezelhessék ezeket az eltéréseket a trezorral való integráció során. Kérjük, vegye figyelembe, hogy ezt végső megoldásnak kell tekinteni.

***
Az ERC4626 páncélszekrények a belátható jövőben a DeFi fontos építőkövévé válhatnak – és az összeállíthatóság érdekében fontos, hogy mind az új, mind a meglévő trezorok kövessék a szabványt. Az új megvalósítások a szabványt követve jelennek meg, így nincs jobb idő a jelenleginél a meglévő trezorok szabványosítására. 

Miközben egy ideális állapot felé dolgozunk (ahol a különböző tárolók egységesen összeállíthatók), az ERC4626 tulajdonságtesztek futtathatók a tárolómegvalósítások szabványsértéseinek könnyebb észlelése érdekében. A tulajdonságtesztek (dokumentációval és példákkal) mind nyilvánosan elérhetők a Githubon raktár. Szívesen fogadjuk visszajelzéseiket és hozzászólásaikat!

***
Az itt kifejtett nézetek az AH Capital Management, LLC („a16z”) egyes alkalmazottainak nézetei, és nem az a16z vagy leányvállalatai nézetei. Az itt található bizonyos információk harmadik féltől származnak, többek között az a16z által kezelt alapok portfólióvállalataitól. Noha megbízhatónak vélt forrásokból származnak, az a16z nem ellenőrizte önállóan ezeket az információkat, és nem tesz kijelentést az információk aktuális vagy tartós pontosságáról, illetve annak egy adott helyzetre való megfelelőségéről. Ezenkívül ez a tartalom harmadik féltől származó hirdetéseket is tartalmazhat; az a16z nem vizsgálta át az ilyen hirdetéseket, és nem támogatja az abban található reklámtartalmat.

Ez a tartalom csak tájékoztatási célokat szolgál, és nem támaszkodhat rá jogi, üzleti, befektetési vagy adótanácsadásként. Ezekkel a kérdésekkel kapcsolatban konzultáljon saját tanácsadójával. Bármely értékpapírra vagy digitális eszközre történő hivatkozások csak illusztrációs célt szolgálnak, és nem minősülnek befektetési ajánlásnak vagy ajánlatnak befektetési tanácsadási szolgáltatások nyújtására. Ezen túlmenően ez a tartalom nem befektetőknek vagy leendő befektetőknek szól, és nem is szánható felhasználásra, és semmilyen körülmények között nem támaszkodhat rá az a16z által kezelt alapokba történő befektetésről szóló döntés meghozatalakor. (A16z alapba történő befektetésre vonatkozó ajánlatot csak az ilyen alap zártkörű kibocsátási memoranduma, jegyzési szerződése és egyéb vonatkozó dokumentációja tesz, és azokat teljes egészében el kell olvasni.) Minden említett, hivatkozott befektetés vagy portfóliótársaság, ill. A leírtak nem reprezentatívak az a16z által kezelt járművekbe történő összes befektetésre, és nem garantálható, hogy a befektetések nyereségesek lesznek, vagy a jövőben végrehajtott egyéb beruházások hasonló tulajdonságokkal vagy eredménnyel járnak. Az Andreessen Horowitz által kezelt alapok befektetéseinek listája (kivéve azokat a befektetéseket, amelyek esetében a kibocsátó nem adott engedélyt az a16z számára a nyilvánosságra hozatalra, valamint a nyilvánosan forgalmazott digitális eszközökbe történő be nem jelentett befektetéseket) a https://a16z.com/investments oldalon érhető el. /.

A benne található diagramok és grafikonok kizárólag tájékoztató jellegűek, és nem szabad rájuk hagyatkozni befektetési döntések meghozatalakor. A múltbeli teljesítmény nem jelzi a jövőbeli eredményeket. A tartalom csak a feltüntetett dátum szerint beszél. Az ezekben az anyagokban megfogalmazott előrejelzések, becslések, előrejelzések, célok, kilátások és/vagy vélemények előzetes értesítés nélkül változhatnak, és eltérhetnek mások véleményétől, vagy ellentétesek lehetnek azokkal. További fontos információkért látogasson el a https://a16z.com/disclosures oldalra