Uogólnione testy właściwości dla skarbców ERC4626

Ponieważ DeFi rośnie i dojrzewa, skalowalna infrastruktura i możliwość komponowania są priorytetem dla programistów. Ethereum Requests for Comments (lub ERC) — ustandaryzowane zestawy narzędzi do tworzenia aplikacji opartych na Ethereum, takie jak powszechnie używany standard tokenów ERC20 — odgrywają zasadniczą rolę w dostarczaniu spójnych wytycznych dla programistów, aby mogli wnosić wkład do ekosystemu bez zaczynania od zera. Wcześniej w tym roku, standard skarbca tokenizowanego ERC4626 został stworzony, aby zachęcić do wzajemnej kompatybilności między tokenami przynoszącymi dochód. Standaryzacja szczegółów implementacji może również rozwiązać palące problemy z komponowaniem, dzięki czemu integracja protokołu jest łatwiejsza i ostatecznie mniej podatna na błędy.

Kilka projektów DeFi już tego dokonało przyjęty standard, starając się zwiększyć możliwości komponowania swoich skarbców, i przewidujemy szersze zastosowanie w całym ekosystemie. Adaptacja istniejących skarbców powoduje jednak pewne bóle wzrostu; co krytyczne, pewne błędy implementacji mogą narazić nowe cele na atak. Nawet małe błędy (tak małe jak błędna interpretacja standardowego interfejsu) mogą mieć znaczące konsekwencje zarówno dla bezpieczeństwa, jak i doświadczenia użytkownika, podkreślając potrzebę większej liczby narzędzi i środków bezpieczeństwa, szczególnie w bardziej komponowanym ekosystemie DeFi. 

Na szczęście proste błędy mogą mieć stosunkowo proste rozwiązania, jeśli zostaną wykryte na długo przed ich wykorzystaniem (a najlepiej, zanim zostaną wdrożone). W tym celu wydaliśmy Testy właściwości ERC4626 do fuzzingu i symbolicznego wykonania, aby pomóc konstruktorom skarbców wykrywać naruszenia standardów, które mogą zepsuć integrację lub doprowadzić do powstania luk w zabezpieczeniach. W tym poście wyjaśniamy motywujący problem, omawiamy nasze podejście i kończymy kilkoma praktycznymi radami.

Najpierw krótkie wprowadzenie do standardu ERC4626

Sfinalizowany w marcu, ERC4626 jest standardem dla skarbców tokenizowanych. Został wprowadzony w celu rozszerzenia szeroko stosowanego ERC20 standard (obecnie baza dla setek tokenów), zachęcanie do standaryzacji w skarbcach przynoszących zysk oraz zapewnianie możliwości komponowania dla aplikacji i protokołów (np. agregatorów zysku), które muszą z nimi współdziałać. Oznacza to, że każdą aplikację zbudowaną na skarbcu ERC4626 można łatwo rozszerzyć do pracy z dowolnym innym skarbcem ERC4626. 

Skarbce tokenizowane umożliwiają użytkownikom swobodne deponowanie aktywów w celu wybicia udziałów skarbca, a następnie wykupienie tych udziałów w celu pobrania kapitału i odsetek ze skarbca. Te akcje skarbca są tokenami ERC20, a zatem można nimi łatwo handlować lub wykorzystywać jako zabezpieczenie do pożyczania innych aktywów. Na przykład, użytkownicy mogą zdeponować swoje aktywa w skarbcach Yearn, aby wybić tokeny yVault, którymi można następnie handlować na Uniswap, obstawiać w celu uzyskania dodatkowego zysku lub wykorzystać jako zabezpieczenie protokołów pożyczkowych.

Logika biznesowa generowania i dystrybucji zysku (oraz określania ceny akcji) może się różnić w zależności od implementacji. Aby objąć jak najwięcej skarbców (w celu uczynienia ich interoperacyjnymi, a nie identycznymi), standard ERC4626 koncentruje się na opisie interfejsu użytkownika, pozostawiając większość szczegółów implementacji nieokreślonych. Pozwala to na wprowadzanie zmian w logice biznesowej, o ile skarbiec spełnia określone wymagania interfejsu i zachęca do: interoperacyjność w wielu różnych rodzajach aplikacji i typach skarbców ERC4626.

Ponieważ tworzonych jest więcej skarbców, spodziewamy się, że od samego początku zostaną one wdrożone zgodnie ze standardem ERC4626; ale obecnie znajdujemy się w nieco przejściowej fazie, w której programiści, którzy chcą skorzystać z większej możliwości komponowania, będą musieli zaktualizować istniejące skarbce, aplikacje i protokoły, aby były zgodne ze standardem. A w miarę ich aktualizacji borykają się z wieloma zawiłościami i wyzwaniami. 

Wyzwania związane ze zgodnością ze standardami (i pułapki związane z brakiem zgodności)

Podążanie za nowym standardem nie zawsze jest proste. Każdy skarbiec ERC4626 musi wiernie (i dokładnie) realizować opisane w normie wymagania. W przeciwnym razie integracja skarbców ERC4626 staje się coraz bardziej złożona, aby uwzględnić różne odmiany. Ta złożoność sprawia, że ​​integracje są z natury podatne na błędy; a ponieważ nie są wystarczająco odporne na przyszłość, mogą z czasem prowadzić do luk w zabezpieczeniach.

Niestandardowe tokeny ERC20 (np. Tether USD) wymagają, aby wiele systemów DeFi korzystało z dodatkowej biblioteki (takiej jak SafeERC20) podczas wykonywania transferów tokenów, aby bezpiecznie radzić sobie z rozbieżnymi zachowaniami (na przykład nie zwracać niczego, gdy transfer się powiedzie, zamiast zwracać true). Oznacza to, że wszelkie systemy wchodzące w interakcję z tymi tokenami mogą stać się podatne na ataki, jeśli system nie jest zaprojektowany do prawidłowej obsługi przypadków „brakujących zwrotów”. Scenariusze te mogą potencjalnie wprowadzić wspólną pułapkę bezpieczeństwa i zwiększyć ogólne koszty rozwoju i konserwacji (przy uwzględnieniu dodatkowej logiki i zależności potrzebnych do złagodzenia problemów). Zgodność ze standardem ma zatem kluczowe znaczenie nie tylko dla poszczególnych wdrożeń, ale także dla bezpieczeństwa całego ekosystemu. Jedna luka w pojedynczym systemie lub zależności może powodować powszechne problemy.

Idealnie, standardy byłyby formalnie określone bez dwuznaczności (np. formalna specyfikacja ERC20), a każde wdrożenie można formalnie zweryfikować pod kątem zgodności ze standardową specyfikacją. W praktyce jednak nie jest to łatwe do osiągnięcia w krótkim czasie ze względu na koszty i wysiłek społeczności.

Przedstawiamy wykonywalne właściwości ERC4626 w celu identyfikacji problemów ze zgodnością 

Pracując w kierunku idealnego stanu (każdy skarbiec formalnie zweryfikowany pod kątem rygorystycznych specyfikacji formalnych), napisaliśmy standard ERC4626 niska zabudowa aby wychwycić rozbieżności w subtelnych, łatwych do przeoczenia szczegółach wymagań standardowych.  

Deweloperzy Vault mogą przeprowadzać testy, aby wykryć potencjalne naruszenia standardów w ich implementacjach przed wdrożeniem. Integratorzy skarbców mogą sprawdzić, czy dane skarbce są zgodne ze standardem, zanim zintegrują je ze swoim systemem. Właściwości można również przetestować pod kątem aktywnych skarbców już wdrożonych w sieci głównej, za pomocą testów rozwidlenia sieci głównej. Testowanie skarbców na żywo może być przydatne — zwłaszcza gdy skarbce zostały niedawno wdrożone lub uaktualnione — aby upewnić się, że wszystkie parametry systemu zostały ustawione poprawnie. 

Wybraliśmy testy oparte na właściwościach — napisane w Foundry i gotowe do uruchomienia przez jego fuzzer — aby właściwości były wykonywalne (a tym samym testowalne). W przyszłości mogą być również uruchamiane przez symboliczne wykonanie lub narzędzia sprawdzające model, aby formalnie zweryfikować, czy dany skarbiec spełnia właściwości dla wszystkich możliwych danych wejściowych i warunków.

Napisaliśmy właściwości tak, aby były wystarczająco ogólne, aby można je było zastosować do szerokiej gamy repozytoriów, które implementują inną logikę biznesową. Użyliśmy tylko funkcji interfejsu publicznego, aby uczynić je niezależnymi od szczegółów implementacji. (Ze względu jednak na to ograniczenie niektóre standardowe wymagania, które odnoszą się do danych wewnętrznych specyficznych dla implementacji, zostały pominięte we właściwościach).

Na przykład następująca właściwość odpowiada jednemu z wymagań convertToShares() funkcja, „NIE MOŻE pokazywać żadnych zmian w zależności od dzwoniącego”. Biorąc pod uwagę dwa adresy kont i kwotę, powoduje to wywołanie każdego z kont convertToShares() o tej samej kwocie i zapewnia, że ​​obie wartości zwrotu są równe. Ta właściwość jest niezależna od szczegółów implementacji convertToShares(), która różni się w zależności od repozytoriów i musi być spełniona przez wszystkie repozytoria implementujące ERC4626. Ta właściwość może być wykonana poprzez podanie określonych wartości wejściowych (dla testów jednostkowych), wielu losowych wejść (dla testów rozmytych) lub wartości symbolicznych (dla wykonania symbolicznego i weryfikacji formalnej). Może być również uruchamiany lokalnie lub z rozwidleniem sieci głównej (do testowania integracji).

Przypadek użycia: właściwości, które testują błędy zaokrąglania

Na przykład błędy zaokrąglania są ważną klasą (pozornie drobnych) błędów, które mogą mieć pewne konsekwencje dla serii. Podstawowa logika księgowa ERC4626, np. obliczanie liczby akcji do wybicia lub kwoty aktywów do wycofania, jest wdrażana przy użyciu arytmetyki stałoprzecinkowej — błędy zaokrągleń są nieuniknione. Do bezpieczeństwo, jednak standard wyraźnie określa preferowany kierunek zaokrąglania dla każdej funkcji interfejsu, pozostawiając granice błędu nieokreślone i zależne od implementacji. W szczególności deposit() i redeem() funkcje powinny zwracać an dla-przybliżenie dokładnej wartości, natomiast mint() i withdraw() funkcje powinny zwracać an koniec-przybliżenie. Na przykład, jeśli aktualna cena akcji (tj. ilość aktywów na akcję) wynosi 2, wtedy deposit() przy 3 wei aktywów powinien wybić tylko do 1 wei akcji (tj. floor(3/2)), podczas withdraw() z 3 wei aktywów powinien spalić co najmniej 2 wei akcji (tj. ceil(3/2)).

Napisaliśmy właściwości związane z zaokrąglaniem, aby były niezależne od podstawowej logiki rachunkowości, traktując ją jako czarną skrzynkę. W szczególności sformułowaliśmy je jako tak zwane właściwości „w obie strony”, które opisują związek między dwiema przeciwstawnymi funkcjami. Na przykład poniższa właściwość określa, że ​​wycofywanie aktywów, które właśnie zostały zdeponowane przez wybicie N akcji, musi spalić nie mniej niż N akcji. Innymi słowy, nikt nie może zarabiać na zamianie aktywów i udziałów skarbca w tę iz powrotem poprzez wielokrotne bicie i wycofywanie.

Rzeczywiście stwierdziliśmy, że kilka skarbców ERC4626 w sieci mainnet nie spełnia powyższej właściwości z powodu błędów zaokrąglania. Oznacza to, że każdy może zarobić na przykład kilka satoshi BTC (1 satoshi ~= 0.02 centa w momencie pisania tego tekstu) po prostu (i wielokrotnie) wybijając i wycofując, powoli opróżniając skarbiec. Może to faktycznie przynieść zysk sieciom, które korzystają z bardzo niskich opłat za gaz (np. Fantom) lub jeśli cena aktywów stanie się wystarczająco wysoka w przyszłości.

Testowanie standardu ERC4626 na wolności

Przetestowaliśmy nasze właściwości na ~100 skarbcach ERC4626 w sieci mainnet i znaleźliśmy wiele skarbców, które nie spełniały standardowych wymagań — głównie z powodu błędów zaokrąglania (np. użycie zaokrąglania podłogi tam, gdzie pożądany jest sufit, jak opisaliśmy). W szczególności, w niektórych skarbcach nie udało się wybić dokładnej liczby akcji żądanych przez mint() funkcja, chociaż norma wyraźnie wymaga to. Niektóre z nich również emitowały niespójne Deposit zdarzenie, w którym zarejestrowane dane różnią się od faktycznie wybitych. Ku naszemu zdziwieniu, niektóre krypty nigdy nie zostały wybite na miejscu; zamiast tego po prostu umieszczają żądania mięty w kolejce i przetwarzają je później w partii jako oddzielną transakcję.

Chociaż te rozbieżne zachowania nie były możliwe do wykorzystania per se, mogą stać się podatne na ataki, gdy zostaną zintegrowane z innymi systemami, które oczekują jedynie standardowych zachowań. Te problemy znacznie utrudnią integrację skarbca, potencjalnie neutralizując trwające wysiłki i motywując do standaryzacji.

Korzystanie z naszych testów właściwości i innych praktycznych kroków w kierunku zgodności ze standardami

Precyzyjne przestrzeganie standardu może zapobiec rozbieżnym zachowaniom (najlepiej, zanim zostaną one wdrożone). Mamy nadzieję, że nasze właściwości pomogą, wraz z kilkoma dodatkowymi działaniami. Dla tych, którzy opracowują i/lub integrują skarbce ERC4626:

• Gorąco polecamy prowadzenie naszej nieruchomości Testy przeciwko twoim skarbcom. Szybko znajdą problemy w przypadku wyraźnych naruszeń normy.
• Proponujemy również przejrzenie naszych niska zabudowa w celu krzyżowego sprawdzenia zrozumienia standardowych wymagań i dostosowania implementacji w przypadku niezamierzonych rozbieżności.
• Jeśli Twój skarbiec musi odbiegać od standardu, zalecamy wyraźne udokumentowanie niestandardowych zachowań, aby inni mogli prawidłowo poradzić sobie z tymi odchyleniami podczas integracji ze skarbcem. Należy pamiętać, że należy to traktować jako ostateczność.

***
Skarbce ERC4626 mają potencjał, aby stać się ważnym elementem konstrukcyjnym dla DeFi w dającej się przewidzieć przyszłości — i ze względu na możliwość komponowania ważne jest, aby zarówno nowe, jak i istniejące skarbce były zgodne ze standardem. Nowe implementacje pojawią się zgodnie ze standardem, więc nie ma lepszego czasu niż obecnie, aby ujednolicić istniejące skarbce. 

W miarę zbliżania się do stanu idealnego (gdzie różne skarbce można jednolicie komponować), testy właściwości ERC4626 mogą być uruchamiane w celu łatwiejszego wykrywania naruszeń standardów w implementacjach skarbców. Testy właściwości (z dokumentacją i przykładami) są publicznie dostępne na naszym Github składnica. Czekamy na Twoją opinię i wkład!

***
Wyrażone tutaj poglądy są poglądami poszczególnych cytowanych pracowników AH Capital Management, LLC („a16z”) i nie są poglądami a16z ani jej podmiotów stowarzyszonych. Niektóre informacje w nim zawarte zostały pozyskane ze źródeł zewnętrznych, w tym od spółek portfelowych funduszy zarządzanych przez a16z. Chociaż pochodzą ze źródeł uważanych za wiarygodne, a16z nie zweryfikowało niezależnie takich informacji i nie składa żadnych oświadczeń dotyczących aktualnej lub trwałej dokładności informacji lub ich adekwatności w danej sytuacji. Ponadto treści te mogą zawierać reklamy osób trzecich; a16z nie przeglądał takich reklam i nie popiera żadnych zawartych w nich treści reklamowych.

Te treści są udostępniane wyłącznie w celach informacyjnych i nie należy ich traktować jako porady prawnej, biznesowej, inwestycyjnej lub podatkowej. Powinieneś skonsultować się w tych sprawach z własnymi doradcami. Odniesienia do jakichkolwiek papierów wartościowych lub aktywów cyfrowych służą wyłącznie celom ilustracyjnym i nie stanowią rekomendacji inwestycyjnej ani oferty świadczenia usług doradztwa inwestycyjnego. Ponadto treść ta nie jest skierowana ani przeznaczona do użytku przez jakichkolwiek inwestorów lub potencjalnych inwestorów iw żadnym wypadku nie można na nich polegać przy podejmowaniu decyzji o zainwestowaniu w jakikolwiek fundusz zarządzany przez a16z. (Oferta inwestycji w fundusz a16z zostanie złożona wyłącznie na podstawie memorandum dotyczącego oferty prywatnej, umowy subskrypcyjnej i innej odpowiedniej dokumentacji takiego funduszu i należy ją przeczytać w całości.) Wszelkie inwestycje lub spółki portfelowe wymienione, wymienione lub opisane nie są reprezentatywne dla wszystkich inwestycji w pojazdy zarządzane przez a16z i nie można zapewnić, że inwestycje będą opłacalne lub że inne inwestycje dokonane w przyszłości będą miały podobne cechy lub wyniki. Lista inwestycji dokonanych przez fundusze zarządzane przez Andreessena Horowitza (z wyłączeniem inwestycji, w przypadku których emitent nie wyraził zgody na publiczne ujawnienie przez a16z oraz niezapowiedzianych inwestycji w aktywa cyfrowe będące w obrocie publicznym) jest dostępna pod adresem https://a16z.com/investments /.

Wykresy i wykresy zamieszczone w niniejszym dokumencie służą wyłącznie celom informacyjnym i nie należy na nich polegać przy podejmowaniu jakichkolwiek decyzji inwestycyjnych. Wyniki osiągnięte w przeszłości nie wskazują na przyszłe wyniki. Treść mówi dopiero od wskazanej daty. Wszelkie prognozy, szacunki, prognozy, cele, perspektywy i/lub opinie wyrażone w tych materiałach mogą ulec zmianie bez powiadomienia i mogą się różnić lub być sprzeczne z opiniami wyrażanymi przez innych. Dodatkowe ważne informacje można znaleźć na stronie https://a16z.com/disclosures