Ein Tool zur Erkennung von metamorphen Smart Contracts

Eine wichtige Sicherheitsannahme von Ethereum ist, dass Smart Contract Code unveränderlich ist und daher nicht geändert werden kann, sobald er in der Blockchain bereitgestellt wird. In der Praxis einige Smart Contracts kann ändern – auch nach dem Einsatz. Mit ein paar cleveren Tricks können Sie metamorphe Smart Contracts erstellen, die „Metamorphose“ in etwas anderes – und indem Sie verstehen, was sie möglich macht, können Sie sie erkennen.

Metamorphe Smart Contracts sind änderbar, was bedeutet, dass Entwickler den darin enthaltenen Code ändern können. Diese intelligenten Verträge stellen ein ernsthaftes Risiko für Web3-Benutzer dar, die auf Code vertrauen, von dem sie erwarten, dass er mit absoluter Konsistenz ausgeführt wird, zumal schlechte Akteure diese Gestaltwandlungsfähigkeit ausnutzen können. Stellen Sie sich einen Angreifer vor, der die Technik verwendet, um Personen, die Token in einen intelligenten Vertrag einsetzen, „über den Tisch zu ziehen“, von dem sie nicht wissen, dass er metamorph ist. Angriffe auf der Grundlage dieser und ähnlicher Prämissen könnten Betrüger in die Lage versetzen, Menschen auszubeuten, und im Allgemeinen das Vertrauen in das volle Potenzial dezentraler Systeme untergraben.

Um zu analysieren, ob ein Smart Contract metamorphe Eigenschaften enthält, Ich habe eine einfache gebaut Metamorphischer Kontraktdetektor (inspiriert von und aufbauend auf der Originalarbeit von Jason Schnitzer, 0alter und Extras). Jeder kann das Tool nutzen, um zu überprüfen, ob ein bestimmter Vertrag rote Fahnen aufweist, die auf das Potenzial für eine Metamorphose hinweisen könnten. Die Methode ist nicht narrensicher: Nur weil ein Smart Contract eine Flagge zeigt, bedeutet das nicht, dass er notwendigerweise metamorph ist; und nur weil es das nicht tut, heißt das nicht, dass es sicher ist. Der Checker bietet lediglich eine schnelle Ersteinschätzung für einen Vertrag könnte auf der Grundlage möglicher Indikatoren metamorph sein. 

Web3-Benutzer sollten sich mit den Bedrohungen vertraut machen, die von metamorphen Verträgen ausgehen, damit sie nach möglichen Angriffen Ausschau halten und diese vermeiden können. Wallets und Blockchain-Indexer können helfen, indem sie Benutzer warnen, bevor sie mit einem Smart Contract interagieren, der möglicherweise metamorphe Eigenschaften enthält. Dieses Tool soll sowohl dabei helfen, Menschen über diese potenzielle Bedrohung aufzuklären … als auch sich dagegen zu verteidigen.

Metamorphische Smart Contracts erkennen

Das Metamorphischer Kontraktdetektor Ich habe sechs Eigenschaften analysiert, die anzeigen können, ob ein Smart Contract metamorph ist.

1. 1. Wurde bekannter metamorpher Code verwendet, um den Vertrag bereitzustellen? Wenn bekannter metamorpher Bytecode – der untergeordnete, von virtuellen Maschinen lesbare Code, in den Ethereum Smart Contracts, typischerweise in Solidity geschrieben, nach der Kompilierung umgewandelt werden – in einer Transaktion für die Bereitstellung eines bestimmten Smart Contracts auftaucht, ist das ein großes Warnsignal. In den folgenden Abschnitten besprechen wir ein solches Beispiel für metamorphen Bytecode, der von 0age entwickelt wurde. Ein wichtiger Vorbehalt: Es gibt potenziell unzählige Variationen des metamorphen Bytecodes, was das Erkennen aller Varianten erschwert. Durch das Scannen nach bekannten Instanzen eliminiert der Detektor jedoch niedrig hängende Früchte für Angreifer, die lediglich vorhandene Beispiele kopieren und einfügen.
   2. Kann sich der Smart Contract Code selbst zerstören? Um den Code in einem Vertrag zu ersetzen – ein wichtiger Schritt bei der Erstellung eines metamorphen Vertrags – muss ein Entwickler zunächst den bereits vorhandenen Code löschen. Der einzige Weg, dies zu tun, ist die Verwendung von SELFDESTRUCT-Opcode, ein Befehl, der genau das tut, wonach er sich anhört – er löscht den gesamten Code und die Speicherung an einer bestimmten Vertragsadresse. Das Vorhandensein von selbstzerstörendem Code in einem Vertrag beweist nicht, dass er metamorph ist; Es bietet jedoch einen Hinweis darauf, dass der Vertrag könnte metamorph sein und es ist sowieso wissenswert, ob Verträge, auf die Sie sich verlassen, sich selbst atomisieren können.
   3. Ruft der Smart Contract Code von woanders auf? Wenn sich der betreffende Smart Contract nicht direkt selbst zerstören kann, kann er sich möglicherweise immer noch selbst löschen, indem er verwendet DELEGATECALL-Opcode. Dieser Opcode ermöglicht einem Smart Contract das dynamische Laden und Ausführen von Code, der sich in einem anderen Smart Contract befindet. Selbst wenn der Smart Contract den SELFDESTRUCT-Opcode nicht enthält, kann er DELEGATECALL verwenden, um selbstzerstörenden Code von woanders zu laden. Während die DELEGATECALL-Funktionalität nicht direkt anzeigt, ob ein Smart Contract metamorph ist, ist es ein möglicher Hinweis – und ein potenzielles Sicherheitsproblem – das erwähnenswert ist. Seien Sie gewarnt, dass dieser Indikator viele Fehlalarme hervorrufen kann. 
   4. Wurde dieser Vertrag von einem anderen Vertrag bereitgestellt? Metamorphische Verträge können eingesetzt werden einzige durch andere Smart Contracts. Dies liegt daran, dass metamorphe Verträge durch einen anderen Opcode aktiviert werden, der nur von anderen intelligenten Verträgen namens CREATE2 verwendet werden kann. (Wir werden CREATE2 – wie es funktioniert und warum es wichtig ist – in einem späteren Abschnitt näher besprechen.) Dieses Merkmal ist einer der am wenigsten auffälligen Indikatoren für eine mögliche Metamorphose; es ist eine notwendige, aber unzureichende Voraussetzung. Das Scannen nach diesem Merkmal wird wahrscheinlich viele Fehlalarme hervorrufen – aber es ist eine wertvolle Information zu wissen, da es Verdacht erregen und einen Grund liefern kann, einen Vertrag weiter zu prüfen, insbesondere wenn der Smart Contract den als nächstes beschriebenen Opcode enthält.
   5. Enthält der Deployer-Vertrag den CREATE2-Opcode? Wie oben erwähnt, ist das Deployment über CREATE2 eine wesentliche Voraussetzung für die Metamorphose. Wenn ein Deployer-Vertrag den CREATE2-Opcode enthält, kann dies darauf hindeuten, dass er CREATE2 verwendet hat, um den betreffenden Vertrag bereitzustellen. Wenn der Deployer tatsächlich CREATE2 verwendet hat, um diesen Vertrag bereitzustellen, bedeutet dies zwar nicht, dass der Vertrag notwendigerweise metamorph ist, aber es bedeutet, dass er es ist könnte metamorph sein und es kann ratsam sein, mit Vorsicht vorzugehen und weiter zu untersuchen. Auch hier Vorsicht vor Fehlalarmen: ERSTELLEN2 hat viel davon legitime Verwendungen, einschließlich Stärkung „Layer 2“-Skalierungslösungen und es einfacher zu machen, Smart Contract Wallets zu erstellen, die web3 verbessern können Benutzer-Onboarding und Schlüsselwiederherstellungsoptionen.
   6. Hat sich der Code geändert? Dies ist der offensichtlichste Tell, aber er wird erst angezeigt, nachdem sich ein metamorphischer Vertrag bereits gemorpht hat. Wenn der Code-Hash des Smart Contracts – eine eindeutige, kryptografische Kennung – anders ist als bei der ursprünglichen Bereitstellung des Vertrags, wurde der Code wahrscheinlich entfernt, ersetzt oder geändert. Wenn die Hashes nicht mehr übereinstimmen, hat sich etwas am Code geändert und der Vertrag ist möglicherweise metamorph. Dieses Flag ist der sicherste Indikator für Metamorphose, aber es hilft nicht, Morphing vorherzusagen oder zu verhindern, da es nur überprüft, ob es bereits stattgefunden hat.

Zusätzlich zum Erstellen eines einfachen Befehlszeilentools für den Metamorphic Contract Detector habe ich einige Beispiel-Smart-Contracts erstellt, die ein Betrugs-Staking-Szenario für metamorphe Verträge demonstrieren, das ich im nächsten Abschnitt beschreibe. Der gesamte Code ist darin verfügbar GitHub-Repository. 

Wie ein böswilliger Akteur metamorphe Verträge verwenden kann, um die Gelder von Menschen zu stehlen

So könnte jemand einen metamorphen Smart Contract als Teil eines Betrugs verwenden. 

An erster Stelle steht die Einrichtungsphase. Der Angreifer setzt einen Smart Contract an einer bestimmten Adresse in der Blockchain mit zwei Tools ein: metamorpher Bytecode und der CREATE2-Opcode. (Wir werden diese beiden Konzepte später weiter ausführen.) Der metamorphe Bytecode tut dann, was sein Name andeutet, und „morpht“. Hier ändert es sich in a Absteckvertrag wo Benutzer ERC-20-Token einsetzen können. (Auch hier werden wir die Details dieses Morphing-Tricks später besprechen. Versprochen!)

Als nächstes kommt der Köder und Schalter. Ahnungslose Benutzer setzen ihre Token in diesen Vertrag ein, angelockt von der Möglichkeit, eine Rendite oder einen anderen Vorteil zu erzielen. Der Angreifer löscht dann den gesamten Staking-Code und „Zustand“ – Blockchain-Speicher oder Speicher – an dieser Smart-Contract-Adresse mit der SELFDESTRUCT-Opcode im vorherigen Abschnitt besprochen. (Es sollte beachtet werden, dass die Token – die als Teil eines separaten ERC-20-Vertrags existieren – bestehen bleiben, unbeeinflusst von dem selbstzerstörten Vertrag.)

Zum Schluss der Teppichzug. Der Angreifer verwendet denselben metamorphen Bytecode, der in der Setup-Phase verwendet wurde, um einen neuen Vertrag „neu bereitzustellen“. Dieser neue Vertrag wird an derselben Adresse bereitgestellt, die kürzlich durch den selbstzerstörenden Vertrag geräumt wurde. Dieses Mal jedoch „verwandelt“ sich der Bytecode (erneut, wir erklären später, wie) in einen böswilligen Vertrag, der alle Token stehlen kann, die an der Vertragsadresse gestaket sind. Betrug abgeschlossen. 

Die Risiken, die von metamorphen Smart Contracts ausgehen, sind mittlerweile klar ersichtlich. Aber Sie fragen sich vielleicht immer noch, wie funktioniert dieser Metamorphose-Trick eigentlich? Um das zu verstehen, müssen Sie tiefer gehen, auf die Bytecode-Ebene. 

Wie CREATE2 die Möglichkeit der Metamorphose eröffnet 

ERSTELLEN2 ist ein Opcode-Upgrade, in Ethereum eingeführt im Februar 2019, das eine neue Möglichkeit bietet, Smart Contracts einzusetzen. 

CREATE2 gibt Entwicklern mehr Kontrolle über die Bereitstellung ihrer Smart Contracts als zuvor. Der ursprüngliche CREATE-Opcode macht es Entwicklern schwer, die Zieladresse für einen bereitzustellenden Smart Contract zu kontrollieren. Mit CREATE2 können Menschen die Adresse eines bestimmten Smart Contracts im Voraus kontrollieren und kennen, bevor sie ihn tatsächlich in der Blockchain bereitstellen. Dieses Vorwissen – plus einige clevere Tricks – ermöglicht es Menschen, metamorphe Smart Contracts zu erstellen. 

Wie kann CREATE2 die Zukunft vorhersagen? Die Berechnung des Opcodes ist deterministisch: Solange sich die Eingänge nicht ändern, ändert sich die von CREATE2 bestimmte Adresse nicht. (Selbst die kleinste Änderung führt dazu, dass die Bereitstellung woanders stattfindet.)

Genauer gesagt ist CREATE2 eine Funktion, die einige Elemente kombiniert und hasht. Erstens enthält es die Adresse des Deployers (oder Absenders): des initiierenden Smart Contract, der als übergeordneter Vertrag für den zu erstellenden fungiert. Als nächstes fügt es eine beliebige Zahl hinzu, die vom Absender (oder „Salz“) bereitgestellt wird, was es dem Entwickler ermöglicht, den gleichen Code für verschiedene Adressen bereitzustellen (indem er das Salz ändert) und verhindert, dass vorhandene, identische Verträge überschrieben werden. Schließlich verwendet es den keccak256-Hash eines Smart-Contract-Initialisierungs-Bytecodes („init“), der der Seed ist, der sich in einen neuen Smart-Contract verwandelt. Diese gehashte Kombination bestimmt eine Ethereum-Adresse und stellt dann den angegebenen Bytecode für diese Adresse bereit. So lange wie der Bytecode bleibt genau gleich, CREATE2 stellt den angegebenen Bytecode immer an derselben Adresse in der Blockchain bereit.

So sieht die CREATE2-Formel aus. (Hinweis: Sie werden im folgenden Beispiel ein weiteres Element bemerken, ein „0xFF“. Dies ist nur eine Konstante, die CREATE2 verwendet Kollisionen verhindern mit dem vorhergehenden CREATE-Opcode.)

Nun, da wir eine Möglichkeit haben, Code an einer deterministischen Adresse bereitzustellen, wie ist das möglich? Übernehmen den Code an derselben Adresse? Das mag zunächst unmöglich erscheinen. Wenn Sie neuen Code mit CREATE2 bereitstellen möchten, muss sich der Bytecode ändern, und daher wird CREATE2 an einer anderen Adresse bereitgestellt. Aber was wäre, wenn ein Entwickler den Bytecode so konstruiert, dass er sich in einen anderen Code „verwandeln“ könnte, wenn CREATE2 einen Smart Contract bereitstellt?

Wie ein metamorphischer Vertrag tatsächlich funktioniert

Das Rezept, um einen Smart Contract in einen metamorphen Vertrag umzuwandeln, erfordert insgesamt drei Smart Contracts, von denen jeder eine einzigartige Rolle spielt.

Eine dieser notwendigen Komponenten ist die Metamorphic Contract Factory, das Gehirn der Operation. Diese „Fabrik“ ist verantwortlich für die Bereitstellung des Metamorphic Contract sowie eines anderen Smart Contract namens Implementation Contract, der so genannt wird, weil sein Code schließlich im Metamorphic Contract implementiert wird. Eine subtile Choreografie zwischen diesen drei Kontrakten führt zu einer Metamorphose, wie im Diagramm unten dargestellt.

Lassen Sie uns jeden Schritt 1-7 im Detail besprechen, um die Vorgänge bei der Arbeit zu beleuchten.

Schritt 1: Ein Entwickler setzt alles in Bewegung

Ein Programmierer entwirft einen intelligenten Vertragscode – den Implementierungsvertrags-Bytecode – der schließlich im Metamorphic Contract endet. Der Entwickler sendet diesen Code an die Metamorphic Contract Factory, einen Smart Contract, dessen Hauptzweck darin besteht, andere Smart Contracts bereitzustellen. Diese Aktion setzt den gesamten Metamorphic Contract-Erstellungsprozess in Gang.

Alles, was folgt, ist ein Ergebnis dieses ersten Schrittes. In der Tat, Die Schritte 1 bis 6 finden in einer atomaren Transaktion auf der Blockchain statt, d. h. fast alle auf einmal. Diese Schritte können unendlich oft wiederholt werden, um den Code innerhalb des Metamorphic Contract zu ersetzen und ihn kontinuierlich zu verändern.

Schritt 2: Factory stellt den Implementierungsvertrag bereit

Der erste Vertrag, den die Factory bereitstellt, ist der Implementierungsvertrag, der den Implementierungscode enthält. (Kreativ, wir wissen.) Stellen Sie sich den Implementierungsvertrag als eine Laderampe oder einen Wegpunkt vor, der einen Code enthält, bevor er an seinen endgültigen Bestimmungsort geliefert wird, der in diesem Fall innerhalb des Metamorphic Contract sein wird. 

Schritt 3: Fabrik speichert die Adresse des Implementierungsvertrags

Nach seiner Bereitstellung in der Blockchain wird der Implementierungsvertrag notwendigerweise an einer Blockchain-Adresse existieren. Die Fabrik speichert diese Vertragsadresse in ihrem eigenen Speicher (zur späteren Verwendung in Schritt 5). 

Schritt 4: Factory setzt Metamorphic Contract ein

Die Factory stellt den Metamorphic Contract unter Verwendung von CREATE2 und metamorphic Bytecode bereit. Hier finden Sie eine technische, ausführliche Anleitung zur Funktionsweise von metamorphem Bytecode hier, aber es genügt zu sagen, dass bei der Ausführung des metamorphen Bytecodes Code von einem anderen Ort in der Kette – in diesem Fall aus dem Implementierungsvertrag – in den metamorphen Vertrag kopiert wird. Wie wir im letzten Abschnitt besprochen haben, bleibt die Metamorphic Contract-Adresse gleich, egal wie oft diese Schritte wiederholt werden, da CREATE2 deterministisch ist – solange derselbe Absender, Salt und Bytecode verwendet werden.

Unten ist ein Beispiel dafür, wie metamorpher Bytecode aussieht, aus der metamorphes Repo von 0age. Dies ist nur ein Beispiel für metamorphen Bytecode – es existieren potenziell unzählige Variationen, die die Erkennung metamorpher Verträge erheblich erschweren.

Schritt 5: Der metamorphe Bytecode fragt die Fabrik nach der Adresse des Implementierungsvertrags ab

Der metamorphe Bytecode fragt die Fabrik nach der Implementierungsvertragsadresse (wie in Schritt 3 gespeichert). Es spielt keine Rolle, ob sich die Adresse des Implementierungsvertrags ändert, solange der metamorphe Bytecode, der nach der Adresse fragt, gleich bleibt. Wenn der Entwickler später einen neuen Implementierungsvertrag bereitstellt – beispielsweise einen böswilligen, der darauf ausgelegt ist, Token zu stehlen – wird dieser gemäß Schritt 2 zwangsläufig an einer anderen Blockchain-Adresse bereitgestellt. Dies hat keine Auswirkungen auf die Erstellung des Metamorphic Contract.

Schritt 6: Der Implementierungsvertragscode wird in den Metamorphic Contract kopiert

Unter Verwendung der in Schritt 5 erlernten Blockchain-Adresse lokalisiert der metamorphe Bytecode den Code im Implementierungsvertrag und kopiert diesen Code in den lokalen Speicher des metamorphen Vertrags. So verändert sich der Metamorphische Vertrag: durch Kopieren des Codes aus dem Implementierungsvertrag. 

Schritt 7: Spülen und wiederholen

Ein Entwickler kann die Schritte 1 bis 6 immer wieder wiederholen und den Code im Metamorphic Contract durch einen neuen Implementierungsvertrag beliebig ersetzen. Alles, was benötigt wird, ist die Verwendung des SELFDESTRUCT-Opcodes – oder, umständlicher, der DELEGATECALL-Opcodes, die letztendlich zu einem SELFDESTRUCT führen –, um den bereits vorhandenen Code im Metamorphic Contract zu entfernen. Durch Wiederholen des Zyklus mit neuem Implementierungsvertrags-Bytecode wird der Metamorphische Vertrag wie durch Zauberei verwandeln!

Mit dieser Technik zur Erstellung metamorpher Verträge kann ein cleverer Entwickler ständig den Boden unter den Füßen der web3-Benutzer verschieben. Betrachten Sie zum Beispiel noch einmal das Betrugsszenario. Ein Entwickler könnte zuerst den Implementierungsvertrag mit Token-Staking-Code bereitstellen, der über den in der Grafik dargestellten und in den obigen Schritten ausgearbeiteten Umweg im Metamorphic Contract endet. Der Betrüger könnte diesen Code später selbst zerstören und durch die Bereitstellung eines neuen Implementierungsvertrags mit Token ersetzen.Stehlen Code. 

Was auch immer im Implementierungsvertrag eingesetzt wird, wird letztendlich im Metamorphic Contract landen. Das ist die Essenz des Tricks. 

***

Metamorphische Smart Contracts brechen den impliziten Web3-Sozialvertrag, dass das, was Sie sehen, das ist, was Sie bekommen. Ähnlich wie das Hütchenspiel drei sich bewegende Schalen verwendet, um einen Ball zu verstecken, erschwert das Zusammenspiel der drei Verträge bei der Erstellung eines metamorphischen Vertrags die Verfolgung der wahren Funktion des Vertrags. Das Hütchenspiel ist ein besonders passender Vergleich, da Vertrauensbetrüger oft Taschenspielertricks und Irreführungen anwenden, um sicherzustellen, dass sie gewinnen. In der web3-Version können metamorphische Vertragsschreiber den „Ball“ – also den Implementierungscode – auf ähnliche Weise verschwinden lassen (sprich: Selbstzerstörung) und ihn durch etwas ersetzen, was sie wollen.

Die Existenz metamorpher Verträge bedeutet, dass es für Web3-Benutzer möglich ist, Verträge einzugehen, die sich nach Belieben ändern können – deshalb ist es so wichtig, diese Bedrohung zu verstehen und sich dagegen zu wehren. Mein metamorphischer Kontraktdetektor bietet nur einen ersten Schritt zur Identifizierung metamorpher Verträge durch die Fingerfertigkeit, die sie anwenden. Es gibt mehrere Möglichkeiten, wie der Detektor in der Zukunft verbessert werden könnte. Durch rekursives Überprüfen der Fabrik (oder des Betreibervertrags), die den Metamorphic-Vertrag erstellt hat, könnte man beispielsweise sehen, ob die Fabrik selbst metamorph ist. Diese Funktion wäre eine nützliche Ergänzung zu einer aktualisierten Version 2 des Detektors.

Es lohnt sich, es noch einmal zu wiederholen: Dieses Detector-Tool ist nicht narrensicher. Die Flaggen, die es fängt, sind nicht alle verräterische Anzeichen für metamorphes Potenzial, aber sie bieten Hinweise. Die Identifizierung dieser Flags ist nur der Anfang für eine gründlichere Untersuchung. Aus diesem Grund haben wir den Detector erweitert, um nach Flags zu suchen, die leicht falsch positive Ergebnisse erzeugen könnten, wie das Vorhandensein von CREATE2- oder DELEGATECALL-Opcodes. Wenn Sie Vorschläge zur Verbesserung des Tools haben oder auf dieser anfänglichen Arbeit aufbauen oder sie ergänzen möchten, kontaktieren Sie mich unter .

Analysieren Sie Smart Contracts auf metamorphe Merkmale mit dem Detektor-Tool und besuchen Sie die GitHub Repo Für weitere

Herausgeber: Robert Hackett @rhhackett

***

Danksagungen: Ich möchte Robert Hackett, Eddy Lazzarin, Sam Ragsdale, Riyaz Faizullabhoy, Noah Citron, Mason Hall und Daejun Park ein RIESIGES Lob aussprechen und mich für ihr wertvolles Feedback und ihre Ratschläge bedanken, um diesen Beitrag und dieses Tool zum Leben zu erwecken. 

***

Die hier geäußerten Ansichten sind die der einzelnen zitierten Mitarbeiter von AH Capital Management, LLC („a16z“) und nicht die Ansichten von a16z oder seinen verbundenen Unternehmen. Bestimmte hierin enthaltene Informationen stammen aus Drittquellen, einschließlich von Portfoliounternehmen von Fonds, die von a16z verwaltet werden. Obwohl sie aus als zuverlässig erachteten Quellen stammen, hat a16z solche Informationen nicht unabhängig überprüft und gibt keine Zusicherungen über die dauerhafte Genauigkeit der Informationen oder ihre Angemessenheit für eine bestimmte Situation. Darüber hinaus kann dieser Inhalt Werbung von Drittanbietern enthalten; a16z hat solche Anzeigen nicht überprüft und unterstützt keine darin enthaltenen Werbeinhalte.

Dieser Inhalt wird nur zu Informationszwecken bereitgestellt und sollte nicht als Rechts-, Geschäfts-, Anlage- oder Steuerberatung angesehen werden. Sie sollten diesbezüglich Ihre eigenen Berater konsultieren. Verweise auf Wertpapiere oder digitale Vermögenswerte dienen nur der Veranschaulichung und stellen keine Anlageempfehlung oder ein Angebot zur Erbringung von Anlageberatungsdiensten dar. Darüber hinaus richtet sich dieser Inhalt nicht an Anleger oder potenzielle Anleger und ist nicht für die Verwendung durch diese bestimmt, und es darf unter keinen Umständen darauf vertraut werden, wenn eine Entscheidung getroffen wird, in einen von a16z verwalteten Fonds zu investieren. (Ein Angebot zur Investition in einen a16z-Fonds wird nur durch das Privatplatzierungsmemorandum, den Zeichnungsvertrag und andere relevante Unterlagen eines solchen Fonds abgegeben und sollte vollständig gelesen werden.) Alle erwähnten, erwähnten oder erwähnten Investitionen oder Portfoliounternehmen oder Portfoliounternehmen Die beschriebenen Investitionen sind nicht repräsentativ für alle Investitionen in von a16z verwaltete Vehikel, und es kann nicht garantiert werden, dass die Investitionen rentabel sind oder dass andere Investitionen in der Zukunft ähnliche Merkmale oder Ergebnisse aufweisen werden. Eine Liste der Investitionen von Fonds, die von Andreessen Horowitz verwaltet werden (mit Ausnahme von Investitionen, für die der Emittent a16z keine Genehmigung zur öffentlichen Offenlegung erteilt hat, sowie unangekündigte Investitionen in öffentlich gehandelte digitale Vermögenswerte) ist unter https://a16z.com/investments verfügbar /.

Die darin bereitgestellten Diagramme und Grafiken dienen ausschließlich zu Informationszwecken und sollten bei Anlageentscheidungen nicht als verlässlich angesehen werden. Die Wertentwicklung in der Vergangenheit ist kein Hinweis auf zukünftige Ergebnisse. Der Inhalt spricht nur zum angegebenen Datum. Alle Prognosen, Schätzungen, Prognosen, Ziele, Aussichten und/oder Meinungen, die in diesen Materialien geäußert werden, können ohne Vorankündigung geändert werden und können von den Meinungen anderer abweichen oder ihnen widersprechen. Weitere wichtige Informationen finden Sie unter https://a16z.com/disclosures.