Öffentliche Zufälligkeit und Zufälligkeits-Beacons

Öffentlicher Zufall ist eine wesentliche Komponente vieler realer Sicherheitsprotokolle. Bei manchen Anwendungen, wie z. B. Glücksspielen und Multiplayer-Spielen, sorgt der Zufall für zusätzlichen Spaß. In anderen Anwendungen bietet die Zufälligkeit eine faire Möglichkeit, nicht teilbare Ressourcen zuzuweisen, die von Green Cards über die Zuweisung von Bezirksrichtern zu Fällen bis hin zur Aussaat bei Sportturnieren reichen. Es wird auch zum Zuordnen verwendet Negativ Ressourcen wie Steuerprüfungen oder sekundäre Sicherheitskontrollen am Flughafen.

Traditionell haben wir uns auf vertrauenswürdige Autoritäten verlassen, um Zufälligkeit für diese Protokolle zu erzeugen, aber in der Web3-Welt müssen wir es besser machen. In diesem Beitrag untersuchen wir Ansätze zum Erstellen öffentlich überprüfbarer Zufälligkeit via verteilte Randomness Beacons und diskutieren Sie dann einige On-Chain-Anwendungen. (Teil II, der demnächst erscheint, wird sich speziell auf die Wahl von Führern konzentrieren und gleichzeitig eine Bewertung alternativer Ansätze zur Wahl von Führern geben.) 

Gewünschte Eigenschaften

Das Generieren von Zufallszahlen ist eine notorisch subtile Aufgabe. Beispielsweise sind viele kryptografische Schlüssel geleakt worden, weil sie auf einen fehlerhaften Zufallszahlengenerator verlassen (wofür Cloudflares Wall of Lavalampen als kreative Milderung gedient hätte). Das ist einfach Private Zufälligkeit, wo es jedoch nur von einer Partei generiert und verwendet werden muss.

Im Gegensatz dazu ist die öffentliche Zufälligkeit ein Mehrparteienprozess, was die Schwierigkeit beträchtlich erhöht. Ein gutes Protokoll zum Erzeugen öffentlicher Zufälligkeit hat die folgenden Sicherheitseigenschaften:

• Unvoreingenommen: Kein Angreifer oder keine Angreiferkoalition sollte in der Lage sein, die Ausgabe zu beeinflussen. 
• Zuverlässig: Kein Angreifer sollte in der Lage sein, das Protokoll an der Ausgabe zu hindern.
• Überprüfbar: Jeder kann die Protokollausgabe leicht überprüfen und sollte die gleiche Ausgabe wie alle anderen sehen.
• Unberechenbar: Wenn das Protokoll zur Zeit eine Ausgabe erzeugt T₁, sollte niemand vor einiger Zeit etwas über die Ausgabe vorhersagen können T₀<T₁, am besten mit T₀ sehr nah an T₁.

Unvoreingenommenheit ist eine schwächere Eigenschaft als Unvorhersagbarkeit, da jedes unvorhersehbare Protokoll unvoreingenommen sein muss. Informatiker würden Unvoreingenommenheit sagen reduziert zur Unvorhersehbarkeit, denn wer voreingenommen ist, kann vorhersagen. Aber manchmal möchten wir getrennt darüber nachdenken, weil sie sich auf unterschiedliche Annahmen stützen können – zum Beispiel könnte eine unehrliche Mehrheit das Ergebnis vorhersagen, aber nicht beeinflussen.

Zusätzlich zu diesen Eigenschaften sollte das Protokoll effizient laufen und eine große Anzahl zufälliger Bits erzeugen. (In der Praxis reicht es für Anwendungen oft aus, 128 Zufallsbits zu erzeugen und sie zu verwenden, um einen Pseudozufallszahlengenerator [PNRG] zu impfen, um bei Bedarf mehr Bits auszugeben. Allerdings sollte die Unvorhersehbarkeit für jedes einzelne Bit der Ausgabe gelten, um dafür verwendbar zu sein Anwendungen wie Lotterien oder Ressourcenzuteilungen.) Das Protokoll sollte idealerweise auch hinsichtlich der Kommunikations- und Rechenkosten effizient sein.

Unterschiedliche Protokolle können diese Eigenschaften unter unterschiedlichen Bedingungen erzielen. Zum Beispiel könnten einige Protokolle von keiner Koalition von beeinflusst werden f₁ bösartige Knoten und unvorhersehbar durch jede Koalition von f₂<f₁ bösartige Knoten. Es gibt auch unterschiedliche Grade der Voreingenommenheit. Beispielsweise kann ein Teilnehmer in einigen Protokollen die Ausgabe um „ein Bit“ vorspannen – was bedeutet, dass er zwischen einer von zwei möglichen Ausgaben wählen kann. Andere Angriffe könnten es ihnen ermöglichen, die Ausgabe vollständig zu reparieren. Normalerweise wollen wir jedoch überhaupt keine Voreingenommenheit (oder Vorhersagbarkeit) tolerieren.

Das kryptographische Ideal: RUndomness-Leuchtfeuer

Kryptographen beginnen oft damit, über eine ideale Lösung für ihre Probleme nachzudenken. Im Fall öffentlicher Zufälligkeit a Zufälligkeit Leuchtfeuer ist ein idealisierter Dienst, der regelmäßig Zufallsausgaben produziert, die alle notwendigen Sicherheitsanforderungen erfüllen.

Ein solches idealisiertes Zufallssignal, ähnlich wie andere kryptografische Abstraktionen – wie zufällige Orakel oder das generische Gruppenmodell – existiert in der realen Welt nicht. Aber es ist ein nützliches Ziel, das man anstreben sollte, und ein nützliches Modell, um über Protokolle nachzudenken, die auf öffentlicher Zufälligkeit beruhen. 

Wir können einige Näherungen eines idealen Zufallssignals betrachten.

• Zentralisierte Baken: Der einfachste Ansatz, um eine gute Zufälligkeit zu erzeugen, ist über einen zentralisierten Drittanbieter mit Diensten wie NIST-Zufallssignal or Random.org, das Zufälligkeit aus atmosphärischem Rauschen generiert und für die Verwendung beim Glücksspiel akkreditiert ist. Diese Abhängigkeit von Dritten untergräbt die Philosophie der Dezentralisierung vollständig. Tatsächlich müssen wir im obigen Beispiel darauf vertrauen, dass die relevanten Organisationen die Zufälligkeit korrekt und ohne kryptografischen Beweis erzeugen.
• Physikalische Zufälligkeit wird angezeigt: Viele traditionelle Lotterien verlassen sich auf eine öffentliche Zurschaustellung, die zum Beispiel beinhalten kann, dass jemand in einen Behälter mit Tischtennisbällen mit unterschiedlichen Nummern greift. Leider sind diese oft leicht manipulierbar. Zum Beispiel, Bestimmte Bälle können in einen Gefrierschrank gelegt werden und Der Selektor kann angewiesen werden, die kalten auszuwählen.
• Natürliche Leuchtfeuer: Eine gängige Idee ist es, zufällige Naturphänomene wie Wetter oder kosmische Hintergrundstrahlung als Leuchtfeuer zu verwenden. Leider bieten alle vorgeschlagenen Quellen keinen starken Konsens. Verschiedene Beobachter werden leicht unterschiedliche Werte sehen, was die erneute Einführung einer vertrauenswürdigen Partei erfordert, um eine offizielle Messung durchzuführen, mit allen Nachteilen eines zentralisierten Beacons.
• Halbzentralisierte Beacons: Ein besserer Ansatz wäre, die Zufälligkeit von zu erhalten Bitcoin-Block-Header direkt oder von Schlusskurse der Aktien, die öffentlich leichter zu überprüfen und für eine Partei schwieriger vollständig zu kontrollieren ist. Dennoch gibt es immer noch subtile Angriffe auf beide Proof-of-Work-Blockchain-Zufälligkeit und Zufälligkeit von Aktienkursen. Mit Blockchain-Headern können Miner beispielsweise Blöcke zurückhalten, deren Header einen Beacon-Wert erzeugen, der ihnen nicht gefällt. Oder sie können sich entscheiden, Verbindungen zu brechen, wenn zwei kollidierende Blöcke basierend auf ihrer bevorzugten Beacon-Ausgabe gefunden werden.

Dezentrale Randomness Beacons (DRBs)

Ein natürlicher Ansatz für die Probleme zentralisierter Beacons besteht darin, ein dezentralisiertes kryptografisches Protokoll zum Erzeugen öffentlicher Zufälligkeit zu entwickeln. Dieses Problem ist ähnlich wie das Entwerfen dezentralisierter Konsensprotokolle, nur schwieriger. Alle Teilnehmer müssen sich nicht nur auf eine Ausgabe (die Zufälligkeit) einigen, sondern es sollte für einen böswilligen Teilnehmer des Protokolls unmöglich sein, die Ausgabe zu beeinflussen oder vorherzusagen.

Protokolle, die zum Simulieren eines Randomness Beacon entwickelt wurden, werden Distributed Randomness Beacons (DRBs) genannt. (Andere Namen sind „Distributed Coin Flipping“.) Das Problem wird seit Jahrzehnten mit untersucht berühmte Unmöglichkeitsergebnisse, die in den 1980er Jahren bewiesen wurden, aber das Interesse wurde in der Blockchain-Ära wieder entfacht. DRBs könnten verwendet werden, um On-Chain-Zufälligkeit bereitzustellen, was ein Schlüsselfaktor für faire, sichere und transparente On-Chain-Anwendungen wäre.

Der klassische Ansatz: Commit-Reveal-Protokolle

Für einen DRB im optimistischen Fall genügt ein sehr einfaches Zwei-Runden-Protokoll. In Runde 1 jeder Teilnehmer i generiert einen zufälligen Wert r_i und veröffentlicht ein kryptografisches Commitment c_i=Verpflichten(r_i). In dieser Anwendung kann die Verpflichtung einfach eine Hash-Funktion wie SHA-256 sein. Nachdem die Verpflichtung jedes Teilnehmers veröffentlicht wurde, sind sie an ihre Wahl gebunden r_i, aber die Zusagen geben keine Informationen über die Beiträge anderer Teilnehmer preis. In Runde 2 „eröffnet“ jeder Teilnehmer sein Engagement durch Veröffentlichung r_i. Alle Zufallswerte werden dann kombiniert, zum Beispiel durch XOR-Verknüpfung oder (vorzugsweise) Hashing ihrer Verkettung.

Dieses Protokoll ist einfach und erzeugt eine zufällige Beacon-Ausgabe, solange auch nur einer der Teilnehmer seine auswählt r_i nach dem Zufallsprinzip. Leider leidet es an einem klassischen Fehler: Wenn alle bis auf einen der Teilnehmer ihren Zufallswert preisgegeben haben, kann der letzte Teilnehmer die mutmaßliche Beacon-Ausgabe berechnen. Wenn es ihnen nicht gefällt, können sie sich weigern, ihren Wert zu veröffentlichen, und das Protokoll abbrechen. Das Ignorieren des Beitrags eines fehlerhaften Teilnehmers behebt das Problem nicht, da ein Angreifer immer noch die Wahl zwischen zwei Beacon-Ausgaben hat (einer mit seinem Beitrag berechnet und einer ohne).

Blockchains bieten eine natürliche Abhilfe für dieses Problem: Jeder Teilnehmer kann aufgefordert werden, einige Gelder auf einem Treuhandkonto zu hinterlegen, die beschlagnahmt werden, wenn er seinen zufälligen Beitrag nicht preisgibt. Genau diesen Ansatz verfolgte der Klassiker RANDAO Leuchtfeuer auf Ethereum. Der Nachteil dieses Ansatzes besteht darin, dass die Ausgabe immer noch voreingenommen sein kann, was sich für den Angreifer finanziell lohnen kann, wenn das hinterlegte Geld geringer ist als der Geldbetrag, der auf dem Ergebnis des Signals basiert. Eine bessere Sicherheit gegen voreingenommene Angriffe erfordert die Hinterlegung von mehr Coins auf einem Treuhandkonto.

Commit-Reveal-Recover-Protokolle

Anstatt zu versuchen, alle Parteien dazu zu zwingen, ihren zufälligen Beitrag offenzulegen, enthalten einige Protokolle einen Wiederherstellungsmechanismus, sodass der Rest das Protokoll vervollständigen kann, selbst wenn eine Minderheit der Teilnehmer aussteigt. Es ist wichtig, dass das Protokoll in beiden Fällen zum gleichen Ergebnis führt, damit die Parteien das Ergebnis nicht beeinflussen können, indem sie entscheiden, ob sie aussteigen oder nicht.

Ein Ansatz, um dies zu erreichen, besteht darin, dass jeder Teilnehmer den anderen Teile seines Geheimnisses zur Verfügung stellt, sodass eine Mehrheit von ihnen es rekonstruieren kann, z. Shamirs Geheimnisteilung. Eine wichtige Eigenschaft ist jedoch, dass die anderen überprüfen können, ob das festgeschriebene Geheimnis ordnungsgemäß geteilt wurde, was die Verwendung eines stärkeren Primitivs erfordert, das als öffentlich verifizierbares Teilen von Geheimnissen (PVSS) bezeichnet wird.

Mehrere andere Wiederherstellungsmechanismen sind möglich, aber alle haben die gleiche Einschränkung. Wenn es gibt N Teilnehmer, und wir wollen Resilienz, wenn eine Gruppe von bis zu f Knoten ausfällt, dann muss es sein, dass keine Gruppe aus Nf Die Teilnehmer können das Endergebnis berechnen. Das bedeutet aber auch eine böswillige Koalition Nf Die Teilnehmer können das Ergebnis im Voraus vorhersagen, indem sie den Wiederherstellungsmechanismus privat simulieren. Dies kann auch während der ersten Runde des Protokolls geschehen, in der eine solche Koalition ihre eigenen Zufallsentscheidungen ändern und das Ergebnis beeinflussen könnte. 

Anders ausgedrückt bedeutet dies jede Koalition von Nf Knoten müssen mindestens einen ehrlichen Knoten enthalten. Durch einfache Algebra, Nf > f, damit f < N/2, und diese Protokolle erfordern von Natur aus eine ehrliche Mehrheit. Dies ist ein signifikanter Unterschied zum ursprünglichen Sicherheitsmodell von Commit-Reveal, das nur erfordert f<N (mindestens ein ehrlicher Teilnehmer).

Diese Protokolle erfordern oft auch erhebliche Kommunikationskosten, um die zusätzlichen PVSS-Informationen zwischen allen Knoten in jedem Protokolllauf zu teilen. Die Forschungsgemeinschaft hat in den letzten Jahren beträchtliche Arbeit an diesem Problem geleistet, einschließlich Forschungsvorschlägen RandShare, Kratzen, SekRand, HERB, oder Albatros, aber keiner scheint den Einsatz in der realen Welt gesehen zu haben.

Verifizierbare zufällige funktionsbasierte Protokolle

Erkennen, dass eine Gruppe von Nf Teilnehmer können den zufälligen Beacon-Wert im obigen Protokoll berechnen, was zu einem etwas einfacheren Ansatz führt: Teilen Sie einen langfristigen geheimen Schlüssel zwischen sich N Parteien und lassen Sie sie es verwenden, um a überprüfbare Zufallsfunktion (VRF). Der geheime Schlüssel wird über a geteilt t-aus-N Schwellwertregelung, so dass evtl t Teilnehmer können die VRF berechnen (aber eine kleinere Koalition kann dies nicht). Zum t=Nf, dies bietet die gleiche Ausfallsicherheit für f bösartige Knoten wie die oben besprochenen Commit-Reveal-Recover-Protokolle.

DFINITY Pionier dieses Ansatzes als Teil ihres Konsensprotokolls unter Verwendung von Schwellen-BLS-Signaturen (die als VRF fungieren). Das Alleinstehende Drand Randomness Beacon verwendet im Wesentlichen den gleichen Ansatz, wobei eine Gruppe von Teilnehmern in jeder Runde einen Schwellenwert-BLS-Zähler signiert. Das Liga der Entropie ist eine Open-Source-Instanz von drand, die alle 30 Sekunden mit 16 teilnehmenden Knoten (Stand September 2022) Zufälligkeiten erzeugt und von einer Mischung aus Unternehmen und universitären Forschungsgruppen betrieben wird. 

Ein Nachteil dieser Ansätze besteht darin, dass das Initialisieren des Schwellenwertschlüssels relativ komplex ist, ebenso wie das Neukonfigurieren des Schlüssels, wenn Knoten hinzukommen oder gehen. Im Normalfall sind die Protokolle jedoch sehr effizient. 

Wie oben beschrieben, fügt das einfache Signieren eines Zählerwerts keine neue Zufälligkeit pro Runde hinzu. Wenn also eine ausreichende Anzahl von Schlüsseln der Teilnehmer kompromittiert wird, dann wird das Protokoll in jeder zukünftigen Runde vorhersehbar sein.

Kettenglied-VRF vereint Dieser Ansatz (unter Verwendung der NSEC5 VRF) mit einer externen Zufälligkeitsquelle, die von Parteien angegeben wird, die Zufälligkeit anfordern, in der Praxis typischerweise ein neuer Blockchain-Header. Diese Daten werden dann durch ein VRF geleitet, das entweder von einer Partei betrieben oder einer Gruppe zugeordnet wird.

Ethereums Leuchtfeuerkette verwendet derzeit BLS-basierte VRFs: Der Vorschlagende jeder Runde fügt der Mischung seinen VRF-Wert hinzu. Dies spart eine Kommunikationsrunde im Vergleich zum Commit-Reveal-Paradigma (vorausgesetzt, ein langfristiger öffentlicher BLS-Schlüssel wird einmal registriert), obwohl dieses Design einige Vorbehalte des Commit-Reveal-Ansatzes erbt, einschließlich der Möglichkeit, die Ausgabe des Beacons durch Zurückhalten der Ausgabe zu beeinflussen .

Verifizierbare verzögerungsfunktionsbasierte Protokolle

Schließlich ist eine vielversprechende neue Richtung die Verwendung zeitbasierter Kryptographie, insbesondere überprüfbarer Verzögerungsfunktionen (VDFs). Dieser Ansatz verspricht eine gute Kommunikationseffizienz und Robustheit mit Widerstandsfähigkeit gegenüber N-1 bösartige Knoten. 

Um auf das ursprüngliche Commit-Reveal-Protokoll zurückzukommen, können traditionelle Commitments durch ersetzt werden terminierte Verpflichtungen um das Problem der Teilnehmer zu beseitigen, die sich weigern, ihren zufälligen Beitrag preiszugeben. Zeitlich festgelegte Commitments können vom ursprünglichen Committer oder von jedem, der bereit ist, eine langsame Funktion (im Wesentlichen ein VDF) zu berechnen, effizient geöffnet werden. Wenn also ein Teilnehmer aus einem Commit-Reveal-Protokoll aussteigt, kann sein Commitment immer noch von anderen geöffnet werden. Es ist wichtig, dass die Mindestzeit zum Öffnen des Commitments lang genug ist, dass dies nicht während der ersten Runde (der Commit-Phase) des Protokolls erfolgen kann, da sonst böswillige Teilnehmer die Commitments anderer schnell genug öffnen könnten, um ihren eigenen Beitrag zu ändern und das Ergebnis zu beeinflussen .

Mit modernen VDFs ist ein noch eleganteres Ein-Runden-Protokoll möglich: Lassen Sie die Verpflichtung vollständig fallen. Jeder Teilnehmer kann einfach seinen zufälligen Beitrag veröffentlichen r_i, und das Endergebnis ist eine Kombination aus den Beiträgen jedes Teilnehmers, die über ein VDF laufen. Die Zeitverzögerung bei der Berechnung des VDF stellt sicher, dass niemand sein Engagement so wählen kann, dass die endgültige Ausgabe verfälscht wird. Dieser Ansatz wurde als vorgeschlagen EINHORN von Arjen Lenstra und Benjamin Wesolowski im Jahr 2015 und war in der Tat eine der wichtigsten motivierenden Anwendungen in der Entwicklung von VDFs.

Dieser Ansatz hat einige praktische Anwendung gesehen. Chia implementiert eine Version davon als Teil seines Konsensprotokolls unter Verwendung von VDFs mit wiederholter Quadratur in Klassengruppen. Starkware implementiert a Proof-of-Concept VDF-basiertes Beacon mit SNARK-basierten VDFs. Ethereum plant auch benutzen dieser Ansatz, Erstellen eines dedizierten ASIC zum Berechnen von VDFs, um Zufälligkeit auf der Konsensebene zu erzeugen.

***

Öffentliche Zufälligkeit ist ein wesentlicher Bestandteil vieler Protokolle, aber uns fehlt immer noch ein Standard-DRB, der hohe Sicherheit bietet. Der Designraum ist groß und viele Hybride und Kombinationen der oben genannten Ansätze sind möglich. Beispielsweise ist es möglich, ein VRF-basiertes Protokoll mit einem VDF-basierten Protokoll zu kombinieren, das beispielsweise frische Entropie hinzufügt, wie von vorgeschlagen RandRunner. Die Beacon Chain von Ethereum verwendet derzeit VRFs, obwohl sie in Zukunft möglicherweise VDFs hinzufügen wird, um die Möglichkeit einer Verzerrung durch Block-Withholding-Angriffe auszuschließen.

Es ist auch eine offene Frage, wann Protokolle mit ehrlicher Mehrheit akzeptabel sind. Für eine relativ kleine, geprüfte Gruppe von Teilnehmern – wie die League of Entropy – ist eine ehrliche Mehrheitsannahme vernünftig. Andererseits haben Protokolle, die nur einen einzigen ehrlichen Teilnehmer erfordern, einen inhärenten Vorteil – mehr Teilnehmer können die Sicherheit nur verbessern. Dies bedeutet, dass diese Protokolle möglicherweise mit offener, erlaubnisfreier Teilnahme bereitgestellt werden können.

In Teil II werden wir die spezifische Anwendung der randomisierten Leader-Wahl in Konsensprotokollen erörtern, die leicht unterschiedliche Designziele haben und daher noch mehr Protokolle und Ansätze vorgeschlagen haben.

***

Josef Boneau ist Forschungspartner bei a16z crypto. Seine Forschung konzentriert sich auf angewandte Kryptographie und Blockchain-Sicherheit. Er hat Kryptowährungskurse an der University of Melbourne, NYU, Stanford und Princeton unterrichtet und einen PhD in Informatik von der University of Cambridge sowie einen BS/MS-Abschluss von Stanford erhalten.

Valeria Nikolaenko ist Forschungspartner bei a16z crypto. Ihre Forschung konzentriert sich auf Kryptographie und Blockchain-Sicherheit. Sie hat auch an Themen wie Langstreckenangriffen in PoS-Konsensprotokollen, Signaturschemata, Post-Quantum-Sicherheit und Mehrparteienberechnung gearbeitet. Sie promovierte in Kryptographie an der Stanford University unter der Leitung von Professor Dan Boneh und arbeitete als Teil des Kernforschungsteams an der Diem-Blockchain.

***

Editor: Tim Sullivan

***

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.