Narzędzie do wykrywania metamorficznych inteligentnych kontraktów

Krytycznym założeniem bezpieczeństwa Ethereum jest to, że kod inteligentnej umowy jest niezmienny i dlatego nie można go zmienić po wdrożeniu w łańcuchu bloków. W praktyce niektóre inteligentne kontrakty mogą zmiany – nawet po ich wdrożeniu. Za pomocą kilku sprytnych sztuczek możesz tworzyć metamorficzne inteligentne kontrakty, które „przemieniać” w coś innego – a dzięki zrozumieniu, co je umożliwia, możesz je wykryć.

Inteligentne kontrakty metamorficzne są zmienne, co oznacza, że ​​programiści mogą zmieniać zawarty w nich kod. Te inteligentne kontrakty stanowią poważne zagrożenie dla użytkowników web3, którzy ufają kodowi, który spodziewają się działać z absolutną spójnością, zwłaszcza że źli aktorzy mogą wykorzystać tę zdolność do zmiany kształtu. Wyobraź sobie napastnika wykorzystującego technikę do „podważania” ludzi, którzy umieszczają tokeny w inteligentnym kontrakcie, z którego nie zdają sobie sprawy, że jest metamorficzny. Ataki oparte na tej i podobnych przesłankach mogą wyposażyć oszustów do żerowania na ludziach i ogólnie podważyć zaufanie do pełnej obietnicy zdecentralizowanych systemów.

Aby przeanalizować, czy inteligentny kontrakt zawiera właściwości metamorficzne, Zbudowałem prosty Metamorficzny detektor kontraktów (zainspirowany i oparty na oryginalnym dziele Jason rzeźbiarz, 0wiek, inni). Każdy może skorzystać z narzędzia, aby sprawdzić, czy dana umowa niesie ze sobą sygnały ostrzegawcze, które mogą wskazywać na potencjał metamorfizmu. Metoda nie jest niezawodna: tylko dlatego, że inteligentny kontrakt pokazuje flagę, nie oznacza, że ​​jest ona metamorficzna; i tylko dlatego, że tak nie jest, nie oznacza, że ​​jest bezpieczny. Kontroler oferuje jedynie szybką wstępną ocenę, że umowa może być metamorficznym w oparciu o możliwe wskaźniki. 

Użytkownicy Web3 powinni zapoznać się z zagrożeniami, jakie niosą ze sobą kontrakty metamorficzne, aby móc obserwować i unikać możliwych ataków. Portfele i indeksatory blockchain mogą pomóc, ostrzegając użytkowników przed interakcją z inteligentną umową, która może zawierać właściwości metamorficzne. To narzędzie ma pomóc zarówno w edukacji ludzi o tym potencjalnym zagrożeniu… jak i obronie przed nim.

Wykrywanie metamorficznych inteligentnych kontraktów

Połączenia Metamorficzny detektor kontraktów Zbudowałem analizy sześciu właściwości, które mogą wskazywać, czy smart kontrakt jest metamorficzny.

1. 1. Czy do wdrożenia kontraktu użyto kodu metamorficznego? Jeśli znany metamorficzny kod bajtowy – kod niższego poziomu, czytelny dla maszyny wirtualnej, w który inteligentne kontrakty Ethereum, zazwyczaj napisane w Solidity, stają się po skompilowaniu – pojawia się w transakcji dla wdrożenia danej inteligentnej umowy, jest to główna czerwona flaga. W kolejnych sekcjach omówimy jeden z takich przykładów metamorficznego kodu bajtowego opracowanego przez 0age. Ważne zastrzeżenie: istnieje potencjalnie niezliczona ilość odmian metamorficznego kodu bajtowego, co utrudnia wykrycie wszystkich odmian. Jednak skanując dobrze znane instancje, wykrywacz eliminuje nisko wiszące owoce dla napastników, którzy jedynie kopiują i wklejają istniejące przykłady.
   2. Czy kod inteligentnej umowy może ulec samozniszczeniu? Aby zastąpić kod w umowie – kluczowy krok w tworzeniu umowy metamorficznej – programista musi najpierw usunąć istniejący kod. Jedynym sposobem, aby to zrobić, jest użycie Kod operacji SELFDESTRUCT, polecenie, które robi dokładnie to, na co wygląda – usuwa cały kod i pamięć pod danym adresem kontraktu. Obecność w kontrakcie kodu autodestrukcyjnego nie dowodzi, że jest on metamorficzny; jednak daje wskazówkę, że umowa może bądź metamorficzny, a mimo to warto wiedzieć, czy kontrakty, na których polegasz, mogą same się wysadzić.
   3. Czy inteligentny kontrakt wywołuje kod z innego miejsca? Jeśli dany inteligentny kontrakt nie może bezpośrednio ulec samozniszczeniu, nadal może być w stanie wymazać się za pomocą Kod operacji DELEGATECALL. Ten kod operacyjny umożliwia inteligentnemu kontraktowi dynamiczne ładowanie i wykonywanie kodu, który znajduje się w innym inteligentnym kontrakcie. Nawet jeśli inteligentna umowa nie zawiera kodu operacji SELFDESTRUCT, może użyć DELEGATECALL do załadowania samozniszczającego się kodu z innego miejsca. Chociaż funkcja DELEGATECALL nie wskazuje bezpośrednio, czy inteligentna umowa jest metamorficzna, jest to możliwa wskazówka – i potencjalny problem z bezpieczeństwem – na który warto zwrócić uwagę. Ostrzegamy, że ten wskaźnik może potencjalnie wywołać wiele fałszywych alarmów. 
   4. Czy inna umowa wdrożyła tę umowę? Kontrakty metamorficzne mogą być wdrażane tylko przez inne inteligentne kontrakty. Dzieje się tak, ponieważ kontrakty metamorficzne są włączane przez inny kod operacyjny, z którego mogą korzystać tylko inne inteligentne kontrakty, zwane CREATE2. (Omówimy CREATE2 – jak to działa i dlaczego ma to znaczenie – więcej w dalszej części.) Ta cecha jest jednym z najmniej widocznych wskaźników możliwego metamorfizmu; jest to warunek konieczny, ale niewystarczający. Skanowanie w poszukiwaniu tej cechy może wywołać wiele fałszywych alarmów – ale jest to cenna informacja, ponieważ może wzbudzić podejrzenia i stanowić powód do dalszej analizy umowy, zwłaszcza jeśli inteligentna umowa zawiera opisany dalej kod.
   5. Czy umowa wdrożeniowa zawiera kod operacji CREATE2? Jak wspomniano powyżej, wdrożenie za pośrednictwem CREATE2 jest niezbędnym warunkiem wstępnym metamorfizmu. Jeśli kontrakt wdrożeniowy zawiera kod operacji CREATE2, może to wskazywać, że użyto CREATE2 do wdrożenia danego kontraktu. Jeśli wdrażający rzeczywiście użył CREATE2 do wdrożenia wspomnianej umowy, chociaż nie oznacza to, że umowa jest koniecznie metamorficzna, oznacza to, że może być metamorficznym i rozsądnie jest postępować ostrożnie i dalej badać. Ponownie, uważaj na fałszywe alarmy: UTWÓRZ2 ma dużo legalne zastosowania, w tym wzmocnienia Rozwiązania do skalowania „warstwy 2” i ułatwienie tworzenia inteligentnych portfeli kontraktowych, które mogą ulepszyć web3 dołączanie użytkowników i kluczowe opcje odzyskiwania.
   6. Czy kod się zmienił? To najbardziej oczywiste stwierdzenie, ale pojawi się dopiero po przekształceniu kontraktu metamorficznego. Jeśli skrót kodu inteligentnej umowy — unikalny identyfikator kryptograficzny — jest inny niż w momencie początkowego wdrożenia umowy, prawdopodobnie kod został usunięty, zastąpiony lub zmieniony. Jeśli skróty już się nie zgadzają, oznacza to, że coś się zmieniło w kodzie i umowa może być metamorficzna. Ta flaga jest najpewniejszym wskaźnikiem metamorfizmu, ale nie pomoże przewidzieć ani zapobiec morfingowi, ponieważ sprawdza tylko, czy już się wydarzyło.

Oprócz zbudowania prostego narzędzia wiersza poleceń dla Metamorphic Contract Detector, zbudowałem kilka przykładowych inteligentnych kontraktów, które demonstrują scenariusz stakowania kontraktów metamorficznych oszustwa, który opiszę w następnej sekcji. Cały kod jest w tym dostępny Repozytorium GitHub. 

Jak złośliwy aktor może wykorzystać kontrakty metamorficzne do kradzieży pieniędzy?

Oto, jak ktoś może wykorzystać metamorficzną inteligentną umowę w ramach oszustwa. 

Pierwsza to faza przygotowania. Atakujący wdraża inteligentną umowę pod konkretnym adresem w łańcuchu bloków za pomocą dwóch narzędzi: metamorficznego kodu bajtowego i kodu operacyjnego CREATE2. (Później rozwiniemy obie te koncepcje.) Metamorficzny kod bajtowy robi to, co sugeruje jego nazwa i „przekształca”. Tutaj zmienia się w umowa o obstawianie gdzie użytkownicy mogą postawić tokeny ERC-20. (Ponownie omówimy szczegóły tej sztuczki morfingu później. Obietnica!)

Następnie przychodzi przynęta i przełącznik. Niczego niepodejrzewający użytkownicy umieszczają swoje tokeny w tej umowie, zwabieni możliwością zarobienia zysku lub innej korzyści. Atakujący usuwa następnie cały kod do stakowania i „stan” – pamięć lub pamięć blockchain – pod tym adresem inteligentnej umowy za pomocą Kod operacji SELFDESTRUCT omówione w poprzedniej sekcji. (Należy zauważyć, że tokeny – które istnieją jako część oddzielnej umowy ERC-20 – pozostają niezmienione przez samozniszczoną umowę.)

Wreszcie ciągnięcie dywanu. Atakujący ponownie wykorzystuje ten sam metamorficzny kod bajtowy, który był używany w fazie konfiguracji, aby „ponownie wdrożyć” nowy kontrakt. Ten nowy kontrakt jest wdrażany pod ten sam adres, który został ostatnio opuszczony przez kontrakt samozniszczenia. Tym razem jednak kod bajtowy „przekształca się” (znowu wyjaśnimy to później) w złośliwy kontrakt, który może ukraść wszystkie tokeny umieszczone pod adresem kontraktu. Oszustwo zakończone. 

Ryzyko, jakie niosą ze sobą metamorficzne inteligentne kontrakty, jest już wyraźnie widoczne. Ale nadal możesz się zastanawiać, jak właściwie działa ta sztuczka metamorfizmu? Aby to zrozumieć, musisz zbadać głębiej, do poziomu kodu bajtowego. 

Jak CREATE2 otwiera możliwość metamorfizmu 

UTWÓRZ2 jest uaktualnieniem kodu operacyjnego, wprowadzony do Ethereum w lutym 2019 r., który oferuje nowy sposób wdrażania inteligentnych kontraktów. 

CREATE2 daje programistom większą kontrolę nad wdrażaniem inteligentnych kontraktów niż wcześniej. Oryginalny kod operacji CREATE utrudnia programistom kontrolowanie adresu docelowego dla inteligentnego kontraktu, który ma zostać wdrożony. Dzięki CREATE2 ludzie mogą kontrolować i znać adres konkretnej inteligentnej umowy z wyprzedzeniem, zanim faktycznie wdrożą ją w blockchain. Ta uprzednia wiedza – plus kilka sprytnych sztuczek – umożliwia ludziom tworzenie metamorficznych inteligentnych kontraktów. 

Jak CREATE2 może przewidzieć przyszłość? Obliczanie opcode'u jest deterministyczne: dopóki nie zmienią się wejścia, adres określony przez CREATE2 nie ulegnie zmianie. (Nawet najmniejsza zmiana spowoduje, że wdrożenie nastąpi gdzie indziej).

Bardziej szczegółowo, CREATE2 to funkcja, która łączy i haszuje kilka elementów. Po pierwsze, zawiera adres wdrażającego (lub nadawcy): inicjujący inteligentny kontrakt, który działa jako nadrzędny dla tego, który ma zostać utworzony. Następnie dodaje dowolny numer podany przez nadawcę (lub „sól”), co pozwala programiście na wdrożenie tego samego kodu na różne adresy (poprzez zmianę soli) i zapobiega nadpisywaniu istniejących, identycznych umów. Na koniec używa skrótu keccak256 jakiegoś kodu bajtowego inicjalizacji inteligentnego kontraktu („init”), który jest ziarnem, które zamienia się w nowy inteligentny kontrakt. Ta zaszyfrowana kombinacja określa adres Ethereum, a następnie wdraża podany kod bajtowy na ten adres. Tak długo jak kod bajtowy pozostaje dokładnie taki sam, CREATE2 zawsze wdroży dany kod bajtowy pod tym samym adresem w łańcuchu bloków.

Oto jak wygląda formuła CREATE2. (Uwaga: w poniższym przykładzie zauważysz inny element, „0xFF”. To tylko stała, której używa CREATE2 do zapobiegać kolizjom z poprzednim kodem operacji CREATE).

Teraz, gdy mamy sposób na wdrożenie kodu pod deterministyczny adres, jak to możliwe? zmiana kod pod tym samym adresem? Na początku może się to wydawać niemożliwe. Jeśli chcesz wdrożyć nowy kod za pomocą CREATE2, kod bajtowy musi się zmienić, a zatem CREATE2 zostanie wdrożony pod innym adresem. Ale co by było, gdyby programista skonstruował kod bajtowy w taki sposób, że mógłby „przekształcić się” w inny kod, gdy CREATE2 wdroży inteligentną umowę?

Jak właściwie działa kontrakt metamorficzny

Przepis na przekształcenie inteligentnego kontraktu w kontrakt metamorficzny wymaga w sumie trzech inteligentnych kontraktów, z których każdy odgrywa wyjątkową rolę.

Jednym z tych niezbędnych elementów jest Fabryka Kontraktów Metamorficznych, mózg operacji. Ta „Fabryka” jest odpowiedzialna za wdrożenie Kontraktu Metamorficznego, a także innej inteligentnej umowy zwanej Kontraktem Wdrożeniowym, nazwanej tak, ponieważ jej kod ostatecznie zostaje zaimplementowany wewnątrz Kontraktu Metamorficznego. Subtelna choreografia pomiędzy tymi trzema kontraktami skutkuje metamorfizmem, co obrazuje poniższy diagram.

Omówmy szczegółowo każdy krok 1-7, aby naświetlić operacje w pracy.

Krok 1: Deweloper wprawia wszystko w ruch

Programista projektuje kod inteligentnego kontraktu – kod bajtowy kontraktu implementacyjnego – który ostatecznie trafi do kontraktu metamorficznego. Deweloper wysyła ten kod do Metamorphic Contract Factory, inteligentnego kontraktu, którego głównym celem jest wdrażanie innych inteligentnych kontraktów. Ta akcja wprawia w ruch cały proces tworzenia kontraktu metamorficznego.

Wszystko, co następuje, jest wynikiem tego początkowego kroku. Rzeczywiście, Kroki od 1 do 6 mają miejsce w jednej transakcji atomowej w łańcuchu bloków, co oznacza prawie wszystkie naraz. Te kroki mogą być powtarzane w nieskończoność, w celu zastąpienia kodu w kontrakcie metamorficznym i utrzymania go w ciągłym morfingu.

Krok 2: Fabryka wdraża umowę wdrożeniową

Pierwszą umową wdrażaną przez Fabrykę jest Umowa wdrożeniowa, która zawiera kod wdrożeniowy. (Kreatywny, wiemy.) Pomyśl o Kontrakcie Implementacyjnym jak o doku załadunkowym lub punkcie orientacyjnym, który przechowuje kod przed wysłaniem do miejsca docelowego, które w tym przypadku będzie w kontrakcie metamorficznym. 

Krok 3: Sklep fabryczny Adres umowy wdrożeniowej

Po wdrożeniu w łańcuchu bloków umowa wdrożeniowa z konieczności będzie istniała pod jakimś adresem łańcucha bloków. Fabryka przechowuje ten adres kontraktu we własnej pamięci (do wykorzystania później, w kroku 5). 

Krok 4: Fabryka wdraża kontrakt metamorficzny

Fabryka wdraża kontrakt metamorficzny za pomocą CREATE2 i metamorficznego kodu bajtowego. Możesz znaleźć techniczny, dogłębny przewodnik po tym, jak działa metamorficzny kod bajtowy tutaj, ale wystarczy powiedzieć, że gdy metamorficzny kod bajtowy jest wykonywany, kopiuje kod z innej lokalizacji w łańcuchu – w tym przypadku z umowy implementacyjnej – do umowy metamorficznej. Jak wspomnieliśmy w poprzedniej sekcji, ponieważ CREATE2 jest deterministyczny – o ile używany jest ten sam nadawca, sól i kod bajtowy – adres kontraktu metamorficznego pozostaje taki sam bez względu na to, ile razy te kroki są powtarzane.

Poniżej znajduje się przykład tego, jak wygląda metamorficzny kod bajtowy, od repozytorium metamorficzne do 0. roku życia. To tylko jeden przykład metamorficznego kodu bajtowego — istnieje potencjalnie niezliczona ilość odmian, które znacznie komplikują wykrywanie kontraktów metamorficznych.

Krok 5: Zapytania o metamorficzny kod bajtowy Factory dla adresu kontraktu implementacyjnego

Metamorficzny kod bajtowy prosi fabrykę o adres kontraktu implementacyjnego (przechowywany w kroku 3). Nie ma znaczenia, jeśli adres umowy implementacji zmienia się, o ile metamorficzny kod bajtowy, który prosi o adres, pozostaje taki sam. Rzeczywiście, jeśli deweloper później wdroży nową umowę wdrożeniową – taką jak złośliwa, zaprojektowana do kradzieży tokenów – z konieczności zostanie ona wdrożona pod innym adresem łańcucha bloków, zgodnie z krokiem 2. Nie ma to wpływu na tworzenie umowy metamorficznej.

Krok 6: Kod kontraktu wdrożeniowego zostaje skopiowany do kontraktu metamorficznego

Korzystając z adresu łańcucha bloków poznanego w kroku 5, metamorficzny kod bajtowy lokalizuje kod w kontrakcie implementacyjnym i kopiuje ten kod do lokalnego magazynu kontraktu metamorficznego. W ten sposób zmienia się kształt kontraktu metamorficznego: kopiując kod z kontraktu implementacyjnego. 

Krok 7: Opłucz i powtórz

Deweloper może w kółko powtarzać kroki od 1 do 6 i zastępować kod w kontrakcie metamorficznym dowolnym innym za pomocą nowego kontraktu implementacyjnego. Wszystko, co jest potrzebne, to użycie kodu operacji SELFDESTRUCT – lub, bardziej przebiegle, kodów operacji DELEGATECALL, które ostatecznie skutkują SELFDESTRUCT – aby usunąć wcześniej istniejący kod w kontrakcie metamorficznym. Powtarzając cykl z nowym kodem bajtowym kontraktu implementacyjnego, kontrakt metamorficzny, jak magia, przekształcenie!

Korzystając z tej techniki tworzenia kontraktów metamorficznych, sprytny programista może nieustannie przesuwać grunt pod stopy użytkowników web3. Rozważmy na przykład ponownie scenariusz oszustwa. Deweloper może najpierw wdrożyć umowę wdrożeniową z kodem do stakingu tokenów, który poprzez okrężną ścieżkę przedstawioną na grafice i opracowaną w powyższych krokach, kończy się w umowie metamorficznej. Oszust może później samodzielnie zniszczyć ten kod i zastąpić go, wdrażając nowy kontrakt wdrożeniowy zawierający token-kradzież kod. 

Cokolwiek zostanie wdrożone w umowie wdrożeniowej, ostatecznie trafi do umowy metamorficznej. To jest istota sztuczki. 

***

Metamorficzne inteligentne kontrakty łamią niejawną umowę społeczną web3, że dostajesz to, co widzisz. Podobnie jak w przypadku gry z powłoką, która wykorzystuje trzy ruchome kubki do ukrycia piłki, wzajemne oddziaływanie trzech kontraktów w tworzeniu kontraktu metamorficznego utrudnia śledzenie prawdziwej funkcji kontraktu. Gra typu shell jest szczególnie trafnym porównaniem, ponieważ oszuści z pewnością siebie często używają sztuczek i wprowadzania w błąd, aby zapewnić sobie zwycięstwo. W wersji web3 twórcy kontraktów metamorficznych mogą podobnie sprawić, że „piłka” – kod implementacyjny, czyli – zniknie (czytaj: samozniszczenie) i mogą ją zastąpić, co im się podoba.

Istnienie umów metamorficznych oznacza, że ​​użytkownicy web3 mogą zawierać umowy, które mogą się dowolnie zmieniać – dlatego tak ważne jest zrozumienie tego zagrożenia i obrona przed nim. Mój metamorficzny wykrywacz umów oferuje zaledwie pierwszy krok w kierunku identyfikacji kontraktów metamorficznych za pomocą sztuczki, którą stosują. Istnieje kilka sposobów na ulepszenie wykrywacza w przyszłości. Na przykład, sprawdzając rekurencyjnie Fabrykę (lub umowę wdrożeniową), która utworzyła Kontrakt metamorficzny, można zobaczyć, czy sama Fabryka jest metamorficzna. Ta funkcja byłaby przydatnym dodatkiem do ulepszonej wersji 2 Detektora.

Warto jeszcze raz powtórzyć: to narzędzie wykrywacza nie jest niezawodne. Flagi, które łapie, nie wszystkie są charakterystycznymi oznakami potencjału metamorficznego, ale oferują wskazówki. Zidentyfikowanie tych flag to dopiero początek dokładniejszego dochodzenia. Dlatego rozszerzyliśmy wykrywacz, aby wyszukiwał flagi, które mogą łatwo generować fałszywe alarmy, takie jak obecność kodów operacji CREATE2 lub DELEGATECALL. Jeśli masz sugestie dotyczące ulepszenia narzędzia lub chcesz wykorzystać lub uzupełnić tę początkową pracę, skontaktuj się ze mną pod adresem .

Analizuj inteligentne kontrakty pod kątem cech metamorficznych za pomocą narzędzia Detektor i odwiedzić GitHub repo więcej

Redaktor: Robert Hackett @rhhackett

***

Podziękowania: Chcę przekazać OGROMNE podziękowania i podziękować Robertowi Hackettowi, Eddy'emu Lazzarinowi, Samowi Ragsdale'owi, Riyazowi Faizullabhoy'owi, Noah Citron, Mason Hall i Daejun Park za cenne uwagi i rady dotyczące ożywienia tego posta i narzędzia. 

***

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ż pochodzi ze źródeł uważanych za wiarygodne, a16z nie zweryfikowała niezależnie takich informacji i nie składa żadnych oświadczeń dotyczących 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.