Leader-Wahl von Randomness Beacons und anderen Strategien

Die Leader-Wahl in einer Blockchain-Umgebung zielt darauf ab, den Teilnehmer auszuwählen, der den nächsten Block bestimmt, der an die Blockchain angehängt werden soll. Typischerweise wird ein Validator pro Slot aus dem Satz von Validatoren ausgewählt und erhält das Recht, die Kette mit einem neuen Block in diesem Slot zu erweitern. (Wir gehen davon aus, dass Validierer die genaue Zeit einhalten und sich auf die aktuelle Slot-Nummer einigen.) In diesem Artikel untersuchen wir Strategien für Randomisierte Führerwahl in Konsensprotokollen. (Weitere Informationen zur Zufälligkeit im Allgemeinen finden Sie in unserem früheren Artikel Öffentliche Zufälligkeit und Zufälligkeits-Beacons, Wobei Wir haben uns eigenständige Protokolle angesehen, um öffentlich überprüfbare und unvorhersehbare Zufälligkeiten zu erzeugen.) 

Warum die Wahl des Anführers wichtig ist

Die Wahl ehrlicher und aktiver Führungskräfte ist entscheidend für das gesunde Wachstum der Kette. Böswillige Validatoren sollten nicht in der Lage sein, den Leader-Wahlprozess dahingehend zu beeinflussen, dass sie sich selbst häufiger zu Leadern machen. Andernfalls könnte die Produktion von Blöcken in die Hände von Parteien fallen, die Transaktionen zensieren oder die Blockchain ganz stoppen können. In Konsensprotokollen im Stil der längsten Kette könnte ein Leader, der einen ungültigen Block (oder überhaupt keinen Block) erzeugt, dazu führen, dass sich die Kette vorübergehend verzweigt. In Konsensprotokollen im BFT-Stil löst ein schlechter Anführer ein Ansichtsänderungs-Unterprotokoll aus, das einen Kommunikations-Overhead mit sich bringt. 

Alternative zur Ausschusswahl

Die Wahl des Ausschusses ist ein verwandtes Problem, bei dem das Ziel darin besteht, eine gleichmäßig zufällige Teilmenge der Prüfer mit einer bestimmten Größe auszuwählen k. Diese Funktionalität ist an sich schon nützlich, da in Blockchain-Einstellungen oft Unterkomitees benötigt werden, um die Größe des Validator-Sets zu reduzieren, damit der Konsens schneller läuft (unter vielen Beispielen sind Algorands Sortierung und Auswahl des Komitees von Ethereum). Aber die Komiteewahl ist auch für die Wahl des Anführers nützlich, da sie es den Validatoren ermöglicht, das erneute Ausführen eines Anführerwahlprotokolls zu vermeiden, wenn der gewählte Anführer nicht erscheint. Wird anstelle eines Vorsitzenden ein Komitee mit fester Reihenfolge gewählt, kann das zweite Komiteemitglied Vorsitzende werden, wenn das erste nicht verfügbar ist. 

Die Eigenschaften eines guten Wahlprotokolls

In einem Wahlprotokoll für Führer sollten die Führer unberechenbar sein. Wenn ein Angreifer erfährt, wer der nächste Anführer ist, kann er einen Denial-of-Service-Angriff (DoS) auf ihn starten, um ihn daran zu hindern, einen Block zu veröffentlichen. Der Angreifer könnte dann den nächsten Anführer ausschalten und so weiter, wodurch die Blockchain zum Erliegen kommt. Die Unvorhersehbarkeit könnte auch verstärkt werden, um sicherzustellen, dass der Validator selbst nicht lernt, wann er führen wird, was für die Verhinderung von Bestechung wichtig sein könnte.

Der Leader-Wahlprozess sollte die folgenden drei Eigenschaften haben:

• Fairness: jeder ehrliche Validierer hat eine Wahrscheinlichkeit von 1/N aus einer Menge zu wählen N Validatoren (eine entspannte Vorstellung von spieltheoretische Fairness erlaubt Bauführerwahl auch bei Vorliegen einer böswilligen Mehrheit, wenn auch mit nicht konstanter Untergrenze der Rundenzahl).
• Unvorhersehbarkeit: Der Gegner lernt erst irgendwann den nächsten Anführer T bevor der Leiter den nächsten Block ankündigt.
• Einzigartigkeit: In jedem Slot wird genau ein Anführer gewählt.

Geheime Führerwahl

Die Wahl des geheimen Führers ist eine unvorhersehbare Wahl mit T = 0. In diesem Prozess ist der Leader niemandem bekannt, bis er den Block veröffentlicht. Dadurch wird das Fenster für einen DoS-Angriff vollständig eliminiert: Bevor sich der Anführer offenbart, weiß der Angreifer nicht, wen er angreifen soll, und macht seine beste Strategie zu einer zufälligen Vermutung. Und nachdem der Leader seinen Block veröffentlicht hat, ist es für einen Angriff zu spät, weil der Leader seine Verantwortung gegenüber dem Protokoll bereits erfüllt hat. 

Der Begriff „nachdem der Leader seinen Block veröffentlicht hat“ ist jedoch eigentlich eine Vereinfachung, da wir in der realen Welt keine sofortige Übertragung haben. Ein Angreifer mit einer starken Netzwerkposition könnte einen Leader bemerken, der zuerst einen Block sendet, und in der Lage sein, den Leader schnell zu korrumpieren, einen anderen Block zu erstellen und die ursprüngliche Sendung voranzutreiben. 

Obwohl dies ein sehr starkes Angreifermodell ist, wurden Abwehrmaßnahmen dagegen vorgeschlagen. Algorand schlug die vor Löschmodell, in dem der Leader tatsächlich in der Lage ist, den Schlüssel zu löschen, der zum Signieren des Blocks in seinem Slot erforderlich ist Bevor es auszustrahlen, also ist es wirklich zu spät für einen Angriff, wenn der Anführer öffentlich etwas unternimmt. Thaddeus Dryja, Quanquan C. Liu und Neha Narula, drei Forscher des MIT Media Lab, vorgeschlage dass der Leader vor dem Senden ein VDF auf seinem Block berechnet, um sicherzustellen, dass ein adaptiver Angreifer nicht rechtzeitig einen alternativen gültigen Block konstruieren kann, damit er für den gewünschten Slot akzeptiert wird.

Andere Wahlverfahren 

Der einfachste Wahlprozess für Führer ist Round-Robin, wo Führer in deterministischer Reihenfolge gewählt werden. Obwohl dieser Ansatz vorhersehbar und damit anfällig für DoS-Angriffe ist, eignet er sich für zugelassene Systeme, bei denen die Validatoren einen guten DoS-Schutz haben.

Ein Anführer kann auch unter Verwendung eines Ausgangs eines externen gewählt werden Zufälligkeit Leuchtfeuer, wenn einer verfügbar und vertrauenswürdig ist. Leider ist es für die Konsensteilnehmer schwierig, selbst ein Distributed Randomness Beacon (DRB)-Protokoll auszuführen, da diese typischerweise von einer Vorstellung von zuverlässiger Übertragung oder Konsens ausgehen, was wiederum eine Führerwahl erfordert, wodurch eine zirkuläre Abhängigkeit eingeführt wird.

Strom Führerwahl in Ethereum ist eine gute Fallstudie. Jeder neue Leader berechnet eine VRF-Ausgabe (Verifiable Randomness Function) (eine BLS-Signatur auf der Epochennummer) und verknüpft den Wert per XOR mit dem Mix. Der Wert der Mischung am Ende der Epoche i definiert die Führer und die Unterausschüsse für die Dauer der Epoche i+2. Anführer und ihr Zeitplan sind eine Epoche im Voraus vorhersagbar (derzeit ~6.4 min). Das Protokoll ist anfällig für Fairness-Angriffe, da der letzte Anführer seinen Beitrag zum Mix veröffentlichen oder zurückhalten und so das Ergebnis der nächsten Wahlen ein wenig beeinflussen kann. Wenn das letzte  k Führer konspirieren, sie können einführen k  Voreingenommenheit und machen die Wahl von böswilligen Benutzern wahrscheinlicher. Die Ethereum Foundation arbeitet aktiv an fortgeschritteneren Techniken für die Wahl von Führern, die wir unten besprechen.

VRF-basierte Führerwahl

Ein weiterer Ansatz, entwickelt von Algorand, Ist ein VRF-basierte Führerwahl, bei der jeder Validator privat eine VRF-Ausgabe berechnet und prüft, ob die Ausgabe unter einen Schwellenwert fällt. Dieses Verfahren filtert bereits die meisten Validatoren heraus, da die Schwelle so gewählt ist, dass ein Unterschreiten unwahrscheinlich ist. Die wenigen verbleibenden Validierer geben ihre VRF-Ausgaben preis, und derjenige mit dem niedrigsten VRF-Wert wird ausgewählt. Dieser Ansatz erreicht eine perfekte Unvorhersagbarkeit (oder Geheimhaltung), garantiert jedoch keine Einzigartigkeit. Einige der Validatoren erhalten möglicherweise keine Nachrichten von allen potenziellen Führern und gehen davon aus, dass der falsche Führer die Wahl gewonnen hat, was dazu führt, dass diese Validatoren von der Hauptkette abzweigen. 

Die VRF-Evaluierung wird regelmäßig mit der Ausgabe eines Zufallssignals gesät, um es für die Validatoren selbst weniger vorhersehbar zu machen, um zu sehen, welche Slots sie führen werden. Diese Eigenschaft verhindert, dass ein Angreifer, der den Validator stillschweigend kompromittiert, den Slot lernt, wenn der Validator ein Anführer werden würde, und einen Angriff startet, wenn der Validator im Begriff ist, eine Sperre anzukündigen. Dieser Ansatz trägt auch dazu bei, Bestechungsangriffe zu verhindern, bei denen ein Prüfer gegenüber externen Parteien beweist, dass er in einem bestimmten Slot führend sein wird, und Bestechungsgelder einheimst, wenn er eine Aufgabe als Führungskraft erledigt (z. B. eine Transaktion blockiert).

Solche Ansätze, bei denen die Zahl der gewählten Führer eine Zufallsvariable ist, werden genannt Probabilistische Führerwahl (PLE). PLE kann dazu führen, dass für einen bestimmten Slot keine Leader gewählt werden. Dies ist gleichbedeutend mit der Wahl eines Anführers, der böswillig oder offline ist, da der Slot letztendlich übersprungen wird, was die Effizienz des Konsensprotokolls verringert.

Aber der größte Vorbehalt bei PLE ist, dass mehrere Führer gewählt werden können, was eine Art bahnbrechendes Verfahren erfordert. Unentschieden stellen ein Risiko für den Konsens dar, da ein Validator mit einem erfolgreichen Input dies möglicherweise nur der Hälfte des Netzwerks meldet, was möglicherweise zu Meinungsverschiedenheiten beim gewählten Leader führt. Darüber hinaus können Prozesse zur Lösung von Bindungen zusätzliche Zeit und Kommunikation erfordern, was die Effizienz beeinträchtigt. Dfinity, ausführlicher besprochen in der erste Beitrag dieser Serie verwendet ein VRF-basiertes Zufallssignal, um einen einzelnen Anführer zu wählen; jedoch opfert es die Unvorhersehbarkeit, um dies zu tun. Im Idealfall sollte jeder Prozess zur Auswahl eines Anführers Bindungen vollständig vermeiden und dennoch unvorhersehbar sein, was uns zum heiligen Gral dieses Forschungsgebiets führt – der Wahl eines einzelnen geheimen Anführers.

Single Secret Leader Wahl 

Das Ziel Single Secret Leader Wahl (SSLE) besteht darin, einen eindeutigen Anführer aus einer Reihe von Validatoren auszuwählen und dabei Fairness und Unvorhersehbarkeit zu wahren. Protocol Labs präsentierte den Begriff als a Forschungsproblem, und Dan Boneh, der Stanford-Informatiker und a16z-Krypto-Forschungsberater, mit Saba Eskandarian, Lucjan Hanzlik und Nicola Greco, später angeboten eine formale Definition von SSLE. Diese Eindeutigkeitseigenschaft vermeidet die Konsensrisiken und Effizienzkosten, die sich aus unentschiedenen Verfahren ergeben. Konkret, Sarah Azouvi von Protocol Labs und Danielle Cappelletti vom Politecnico di Torino, erklären dass, wenn SSLE im Vergleich zu PLE in einem längsten Kettenprotokoll verwendet wird, Blöcke deutlich schneller finalisiert werden können (25 Prozent schneller, wenn ein Gegner ein Drittel des Einsatzes kontrolliert). Daher ist die Entwicklung eines praktischen SSLE-Protokolls ein wichtiges Problem.

In der gebräuchlichsten Vorgehensweise, die wir nennen werden Shuffle-basiert (wird sowohl im Original-SSLE-Papier als auch im ein SSLE-Vorschlag von Ethereum), registriert jeder Validierer a Nuntius das sieht zufällig aus, und doch können sie beweisen, dass es ihnen gehört. Die Nonces werden dann in einer Liste zusammengestellt. Die Liste wird so gemischt, dass die Verknüpfung der Nonces mit den Prüfern, die sie eingereicht haben, aufgehoben wird; Das heißt, angesichts der gemischten Liste kann kein Gegner sagen, welcher Validator welche Nonce eingereicht hat. Ein Listenindex wird dann gemäß einem Publikum ausgewählt Zufälligkeit Leuchtfeuer, und der Anführer offenbart sich, indem er beweist, dass die Nonce an diesem Index der gemischten Liste ihnen gehört. 

Da nur ein Index gewählt wird, gibt das Shuffle-basierte Protokoll immer a aus einzigartiges Führer. Da das zufällige Beacon so aufgebaut ist, dass es gleichmäßig zufällige Werte ausgibt, ist es das Protokoll auch Messe: Jeder Validator hat die gleiche Chance, gewählt zu werden. Wenn das Mischen richtig durchgeführt wird (dh gleichmäßig zufällig) und die Nonces nicht mehr mit den Identitäten der Prüfer verknüpft werden können, ist dieses Protokoll außerdem erfolgreich unvorhersehbarkeit.

Das Mischen ist notwendig, da die einfache Auswahl eines Index aus der nicht gemischten Liste auf der Grundlage eines zufälligen Beacons bereits Eindeutigkeit und Fairness bieten würde, Unvorhersehbarkeit jedoch schwerer zu erreichen ist: Wenn ein Gegner weiß, welcher Validator welche Nonce eingereicht hat, weiß er, wer die Nonce bei der Auserwählten eingereicht hat Index und kann den Anführer identifizieren. 

Diese beiden folgenden Ansätze mischen die Liste auf unterschiedliche Weise. Umso einfacher ist die Ethereum SSLE-Vorschlag, in welchem n Validatoren übermitteln ihre Nonces über Tor, um die Identität der Validatoren von ihren Nonces zu trennen. Sobald sich alle Prüfer registriert haben, wird die Liste unter Verwendung eines öffentlichen Zufallssignals gemischt, und die Prüfer werden in der Reihenfolge der gemischten Liste führend. Obwohl dieses Schema praktisch ist – die Wahl muss nur einmal pro durchgeführt werden n Slots – diese Abhängigkeit von Tor kann unerwünscht sein (wie es der Fall ist, wenn man sich auf die Sicherheit eines externen Protokolls verlässt). Außerdem ist es nicht vollkommen unvorhersehbar: nach dem ersten n-1 Führer offenbaren sich, das Finale nth Führer ist bekannt.

Anstatt Tor zu verwenden, hat das ursprüngliche SSLE-Papier jeden Validator zur Wahl registrieren lassen, indem er seine Nonce an die Liste anhängt, die Liste mischt und neu randomisieren die Nocken. Diese erneute Randomisierung bedeutet, dass jede Nonce einer neuen, nicht verknüpfbaren Zeichenfolge zugeordnet wird, sodass der Prüfer, dem sie gehört, immer noch den Besitz der neu randomisierten Nonce nachweisen kann. Die Re-Randomisierung sorgt dafür, dass ein Gegner nicht erkennen kann, in welcher Position eine bestimmte Nonce nach dem Mischen gelandet ist, vorausgesetzt, mindestens ein Mischer ist ehrlich.

Während dieser sequenzielle Shuffling-Ansatz aus dem ursprünglichen SSLE-Papier die Abhängigkeit von Tor vermeidet und die formalen Eigenschaften von SSLE erreicht, ist er teuer: Immer wenn sich ein neuer Validator registriert, muss er die gesamte gemischte Liste in die Blockchain posten, alle Nonces neu randomisieren und einen Nachweis erbringen, dass sie dies ehrlich getan haben, was zu einer linearen Menge an Kommunikation pro Validierer führt. Bei einem unveränderlichen Satz von Validatoren muss dies einmal pro Wahl durchgeführt (amortisiert) werden, da sich der Anführer erneut registriert, sobald er den Beweis für die Nonce offenbart hat. Das Papier bietet einen abstimmbaren Kompromiss zwischen Effizienz und Vorhersagbarkeit: Wir können stattdessen nur eine kleinere Teilmenge der Liste mischen, wodurch die Kosten gesenkt werden, wenn wir bereit sind, ein kleines Maß an Vorhersagbarkeit zuzulassen. Das Erreichen eines guten Gleichgewichts zwischen Effizienz und Sicherheit ist eine Herausforderung, weshalb SSLE-Protokolle in der Praxis noch nicht weit verbreitet sind. 

Praktischerweise kann dieser sequentielle Shuffling-Ansatz auch verwendet werden, um das Komitee-Wahlproblem zu lösen, indem das Zufallssignal verwendet wird, um k verschiedene Indizes aus der Liste als Komitee-Mitglieder auszuwählen. Dies ist eine schöne Leistung, da das Problem nicht trivial durch VRF-basierte Ansätze gelöst wird, da ein probabilistisches VRF-basiertes Protokoll ausgeführt wird k Zeiten können je nach Zufälligkeit eine unterschiedliche Ausschussgröße wählen. 

Andere Ansätze für SSLE

Ein weiterer Shuffle-basierter Ansatz ist Adaptive Secure SSLE von DDH. Diese Konstruktion ist etwas komplizierter, erreicht aber ein stärkeres Sicherheitsgefühl und schützt vor einem adaptiver Gegner in Algorands Löschmodell. Dieser Gegner ist insofern anpassungsfähig, als er auswählen kann, welche Prüfer während des Protokolls beschädigt werden sollen, im Gegensatz zu vor Beginn des Protokolls. 

Eine weitere Herausforderung bei SSLE besteht darin, jeden Validator mit einer Wahrscheinlichkeit auszuwählen, die proportional zu seinem Einsatz ist, und nicht einheitlich nach dem Zufallsprinzip. Shuffling-basierte Protokolle können dies naiv erreichen, indem sie jedem Validierer erlauben, mehrere Nonces zu registrieren: eine Nonce für jede Einsatzeinheit, die er hält. Die Kosten für das Mischen steigen jedoch linear mit der Anzahl der Einsatzeinheiten S, was selbst bei realistischen Einsatzverteilungen sehr teuer wird. Ein elegantes MPC-basiertes SSLE Der Ansatz hat eine Komplexität, die nur mit log zunimmt S, und es vermeidet auch die Notwendigkeit einer vertrauenswürdigen Einrichtung oder eines Zufallssignals. Im Vergleich zu Shuffling-basierten Ansätzen sind jedoch mehr Kommunikationsrunden (logarithmisch in der Anzahl der Teilnehmer) pro gewähltem Führer erforderlich

***

Wir haben unsere Analyse in dieser praktischen Tabelle zusammengefasst.

	Fairness	Unberechenbarkeit/ Geheimhaltung*	Einzigartigkeit
Round-Robin	✓	✗	✓
Idealer Zufalls-Beacon	✓	✗	✓
Anführerwahl von Ethereum (aktuell)	✗	✗	✓
VRF-basierte Führerwahl (Algorand)	✓	✓	✗
SSLE	✓	✓	✓

* Das Round-Robin-Beacon ist vollständig vorhersehbar, aber im Rest der Beacons ✗ bedeutet, dass der Begriff bis zu einem bestimmten begrenzten Grad erreicht wird: Ideal-Randomness Beacon ist unvorhersehbar, aber der Gegner lernt die Ausgabe zur gleichen Zeit wie der gewählte Anführer, daher kann der gewählte Anführer angegriffen werden, bevor er einen Block ankündigt; Das Leuchtfeuer von Etherum ist bis zu ~6 Minuten unvorhersehbar und kann leicht voreingenommen sein, um die Fairness zu verletzen; Algorand wählt mit geringer Wahrscheinlichkeit mehrere Anführer.

SSLE ist eine vielversprechende Richtung, die Fairness, Unvorhersehbarkeit und Einzigartigkeit erreicht. Zwei herausragende Herausforderungen bei der Einführung sind die Effizienz und die Fähigkeit, uneinheitliche Anteilsverteilungen zu berücksichtigen. Darüber hinaus gehen die von uns hervorgehobenen Shuffle-basierten SSLE-Ansätze von der Existenz eines unvoreingenommenen zufälligen Beacons aus, was in der Praxis nicht einfach zu erreichen ist. Da SSLE erst kürzlich offiziell definiert wurde, werden wir wahrscheinlich in naher Zukunft verbesserte Protokolle sehen, die seine Herausforderungen angehen. 

***

Miranda Christus ist Doktorandin in Informatik an der Columbia University, wo sie Mitglied der Theory Group und Presidential Fellow ist. Sie ist auch Forschungspraktikantin bei a16z crypto.

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.