Einführung

Die Roadmap von Ethereum beinhaltet eine Skalierungstechnologie namens Data Availability Sampling (DAS) 6. DAS führt neue<a href="https://notes.ethereum.org/ @djrtwo /das-requirements">Anforderungen ein 4 zum Netzwerk-Stack von Ethereum, was die Implementierung spezieller Netzwerkprotokolle erfordert 7 . Ein prominentes <a href="https://notes.ethereum.org/@dankrad /S-Kademlia-DAS"> Protokoll Vorschlag 4 verwendet eine Distributed Hash Table (DHT) basierend auf Kademlia 2 , um die Stichproben der Daten zu speichern und abzurufen.

Allerdings sind DHTs 4 anfällig für Sybil-Angriffe: Ein Angreifer, der eine große Anzahl von DHT-Knoten kontrolliert, kann dazu führen, dass DAS-Samples nicht mehr verfügbar sind. Um dieser Bedrohung entgegenzuwirken, kann eine hochvertrauenswürdige Netzwerkschicht eingerichtet werden, die ausschließlich aus Beacon-Chain-Validatoren besteht. Eine solche Sicherheitsmaßnahme erhöht die Barriere für Angreifer erheblich, da sie nun ihre eigene ETH einsetzen müssen, um das DHT anzugreifen.

In diesem Beitrag stellen wir ein Proof-of-Validator-Protokoll vor, das es DHT-Teilnehmern ermöglicht, ohne Wissen nachzuweisen, dass sie ein Ethereum-Validator sind.

Motivation: „Sample Hiding“-Angriff auf DAS

In diesem Abschnitt motivieren wir den Nachweis des Validatorprotokolls weiter, indem wir einen Sybil-Angriff gegen Data Availability Sampling beschreiben.

Beim DAS-Protokoll dreht sich alles um den Block Builder, der dafür sorgt, dass Blockdaten verfügbar gemacht werden, damit Clients sie abrufen können. Aktuelle Ansätze beinhalten die Partitionierung von Daten in Stichproben, und Netzwerkteilnehmer rufen nur Stichproben ab, die ihren Interessen entsprechen.

)

Stellen Sie sich ein Szenario vor, in dem ein Sybil-Angreifer verhindern möchte, dass Netzwerkteilnehmer Proben von einem Opferknoten abrufen, der für die Bereitstellung der Proben verantwortlich ist. Wie in der Abbildung oben dargestellt, generiert der Angreifer viele Knoten-IDs, die der Knoten-ID des Opfers nahe kommen. Indem der Angreifer den Knoten des Opfers mit seinen eigenen Knoten umgibt, verhindert er, dass Clients den Knoten des Opfers entdecken, da bösartige Knoten absichtlich Informationen über die Existenz des Opfers zurückhalten.

Weitere Informationen zu solchen Sybil-Angriffen finden Sie in diesem aktuellen Forschungspapier 2 zu DHT-Eclipse-Angriffen. Darüber hinaus<a href="https://notes.ethereum.org/ @dankrad /S-Kademlia-DAS#SKademlia-modifications">Dankrads Vorschlag 8 für das DAS-Netzwerkprotokoll beschreibt, wie das S/Kademlia-DHT-Protokoll unter solchen Angriffen leidet, und zeigt die Notwendigkeit eines Proof-of-Validator-Protokolls auf.

Nachweis des Validators

Der obige Angriff begründet die Notwendigkeit eines Proof-of-Validator-Protokolls: Wenn nur Validatoren dem DHT beitreten können, muss ein Angreifer, der einen Sybil-Angriff starten möchte, auch eine große Menge ETH einsetzen.

Mit unserem Proof-of-Validator-Protokoll stellen wir sicher, dass nur Beacon-Chain-Validatoren dem DHT beitreten können und dass jeder Validator eine eindeutige DHT-Identität erhält.

Darüber hinaus streben wir zur Gewährleistung der DoS-Resilienz der Validatoren auch danach, die Identität der Validatoren auf der Netzwerkebene zu verbergen. Das heißt, wir möchten nicht, dass Angreifer erkennen können, welcher DHT-Knoten welchem Validator entspricht.

Um diese Ziele zu erreichen, muss das Proof-of-Validator-Protokoll die folgenden Anforderungen erfüllen:

• Einzigartigkeit: Jeder Beacon-Kettenvalidator muss in der Lage sein, ein einzelnes, eindeutiges Schlüsselpaar abzuleiten. Diese Eigenschaft schränkt nicht nur die Anzahl der Knoten ein, die ein Sybil-Angreifer generieren kann, sondern ermöglicht es Netzwerkteilnehmern auch, sich schlecht verhaltende Knoten lokal zu bestrafen, indem sie ihr abgeleitetes Schlüsselpaar auf die Sperrliste setzen
• Datenschutz: Angreifer dürfen nicht in der Lage sein, herauszufinden, welcher Validator einem bestimmten abgeleiteten öffentlichen Schlüssel entspricht
• Verifizierungszeit: Der Verifizierungsprozess des Protokolls muss effizient sein und weniger als 200 ms pro Knoten dauern, sodass jeder Knoten mindestens fünf neue Knoten pro Sekunde lernen kann

Ein solches Proof-of-Validator-Protokoll würde Bob beim Verbindungsaufbau in der DHT-Schicht verwenden, damit Alice weiß, dass sie mit einem Validator spricht.

Proof of Validator-Protokoll

Unser Proof-of-Validator-Protokoll ist im Grunde ein einfaches anonymes Anmeldeinformationsschema. Sein Ziel besteht darin, Alice in die Lage zu versetzen, genau dann einen eindeutigen abgeleiteten Schlüssel mit der Bezeichnung D zu generieren, wenn sie eine Validatorin ist. Anschließend verwendet Alice diesen abgeleiteten Schlüssel D innerhalb der Netzwerkschicht.

Bei der Entwicklung dieses Protokolls bestand unser Ziel darin, eine Lösung zu schaffen, die sowohl einfach zu implementieren als auch zu analysieren ist und sicherstellt, dass sie die dargelegten Anforderungen auf effiziente Weise erfüllt.

Protokollübersicht

Das Protokoll verwendet ein Mitgliedschaftsnachweis-Unterprotokoll, bei dem Alice beweist, dass sie eine Validatorin ist, indem sie mithilfe von ZK-Beweisen die Kenntnis eines geheimen Hash-Vorbilds nachweist. Alice erstellt dann ein einzigartiges Schlüsselpaar, das aus diesem geheimen Hash-Vorbild abgeleitet wird.

Das Unterprotokoll zum Nachweis der Mitgliedschaft kann mit verschiedenen Methoden instanziiert werden. In diesem Beitrag zeigen wir ein Protokoll, das Merkle-Bäume verwendet, und ein zweites Protokoll, das Lookups verwendet.

Obwohl beide Ansätze eine akzeptable Effizienz aufweisen, weisen sie deutliche Kompromisse auf. Merkle-Bäume basieren auf SNARK-freundlichen Hash-Funktionen wie Poseidon (die als experimentell angesehen werden können). Andererseits basieren effiziente Suchprotokolle auf einem vertrauenswürdigen Potenzen-Tau-Setup, dessen Größe der Größe des Validatorsatzes entspricht (derzeit 700.000 Validatoren, aber es wächst).

Kommen wir nun zu den Protokollen:

Ansatz Nr. 1: Merkle Trees

Merkle-Bäume werden häufig für Mitgliedschaftsnachweise verwendet (z siehe Semaphor 3). Hier ist der Kompromissspielraum beim Entwerfen eines Mitgliedschaftsnachweises mithilfe von Merkle-Bäumen:

• Positiv: Kein vertrauenswürdiges Setup erforderlich
• Positiv: Einfach zu verstehen
• Negativ: Setzt auf SNARK-freundliche Hash-Funktionen wie Poseidon
• Negativ: Langsamere Proof-Erstellung

Nachfolgend beschreiben wir das Proof-of-Validator-Protokoll basierend auf Merkle-Bäumen:

Proof-of-Validator-Protokoll unter Verwendung von Merkle-Bäumen

)

Am Ende des Protokolls kann Alice D im DHT verwenden, um Nachrichten zu signieren und ihre eindeutige DHT-Knotenidentität abzuleiten.

Schauen wir uns nun eine etwas kompliziertere, aber wesentlich effizientere Lösung mit Suchvorgängen an.

Ansatz Nr. 2: Nachschlagen

Hier ist der Kompromissraum bei der Verwendung von Lookup-2- Protokollen wie Caulk 2:

• Positiv: Äußerst effiziente Proof-Erstellung (mittels Vorverarbeitungsphase)
• Positiv: Das Protokoll kann angepasst werden, um eine reguläre Hash-Funktion anstelle von Poseidon zu verwenden
• Negativ: Erfordert ein vertrauenswürdiges Setup von großer Größe (idealerweise gleich der Größe der Validatoren)

Nachfolgend beschreiben wir ein konkretes Proof-of-Validator-Protokoll:

Nachweis des Validatorprotokolls mithilfe von Lookups

Genau wie beim Merkle-Ansatz registriert jeder Validator i einen neuen Wert pi in der Blockchain, sodass:

Effizienz

Wir haben die Laufzeit unseres Mitgliedschaftsnachweisprotokolls (Link 6 zum Benchmark-Code 5) im Hinblick auf die Erstellung und Überprüfung von Nachweisen verglichen. Beachten Sie, dass der Mitgliedschaftsnachweis zwar nur ein Teil unseres Proof-of-Validator-Protokolls ist, wir jedoch davon ausgehen, dass er die Gesamtlaufzeit dominiert.

Nachfolgend stellen wir Benchmark-Ergebnisse für einen Merkle-Tree-Mitgliedschaftsnachweis bereit, bei dem das Halo2-Beweissystem mit IPA als Polynom-Verpflichtungsschema verwendet wird. IPA ist ein langsameres Schema als KZG, erfordert jedoch kein vertrauenswürdiges Setup, um die Vorteile des Merkle-Tree-Ansatzes zu maximieren.

Wir stellen fest, dass sowohl die Prüfer- als auch die Verifiziererzeiten gut mit unseren Effizienzanforderungen übereinstimmen. Aus diesem Grund haben wir uns gegen ein Benchmarking des Caulk-basierten Ansatzes entschieden, da dessen Leistung voraussichtlich in allen Kategorien (insbesondere Prüfzeit und Prüfgröße) deutlich besser sein wird.

Die Benchmarks wurden auf einem Laptop mit einem Intel i7-8550U (fünf Jahre alte CPU) erhoben.

Diskussion

Rotierende Identitäten

Die Eindeutigkeitseigenschaft des Proof-of-Validator-Protokolls stellt sicher, dass jeder Netzwerkteilnehmer über ein eindeutiges abgeleitetes Schlüsselpaar verfügt. Für bestimmte Netzwerkprotokolle kann es jedoch von Vorteil sein, Validatoren rotierende Identitäten zu ermöglichen, bei denen sich ihre abgeleiteten Schlüssel regelmäßig, möglicherweise täglich, ändern.

Wenn sich Eve in einem solchen Szenario an einem bestimmten Tag schlecht benimmt, kann Alice sie für diesen Tag auf die Sperrliste setzen. Am nächsten Tag kann Eve jedoch einen neuen abgeleiteten Schlüssel generieren, der nicht auf der Sperrliste steht. Wenn wir in der Lage sein wollten, Validatoren basierend auf ihrer rotierenden Identität dauerhaft auf die Blockliste zu setzen, bräuchten wir ein fortschrittlicheres Schema für anonyme Anmeldeinformationen wie SNARKBlock 1.

Warum nicht den öffentlichen Identitätsschlüssel BLS12-381 verwenden?

Ein alternativer (vielleicht einfacherer) Ansatz wäre, eine Verpflichtung aus allen BLS12-381-Schlüsseln der Validatoridentität aufzubauen und einen Mitgliedschaftsnachweis für diese Verpflichtung zu erstellen.

Dieser Ansatz würde jedoch erfordern, dass Prüfer ihren privaten Identitätsschlüssel in das ZK-Beweissystem einfügen, um einen gültigen Mitgliedschaftsnachweis zu erstellen und den eindeutigen abgeleiteten Schlüssel zu berechnen.

Wir haben uns entschieden, diesen Ansatz nicht zu wählen, da es keine gute Praxis ist, sensible Identitätsschlüssel in ein kompliziertes kryptografisches Protokoll einzufügen, und es außerdem für Prüfer schwieriger wäre, ihren Hauptidentitätsschlüssel offline zu halten.

Zukünftige Forschungsrichtungen

• Können wir SNARK-Schaltkreise vollständig vermeiden und den Zugehörigkeitsnachweis und die Schlüsselableitung auf rein algebraische Weise durchführen?
• Verwandt: Können wir ein effizientes Protokoll zum Nachweis der Mitgliedschaft haben, ohne eine vertrauenswürdige Einrichtung zu haben und ohne uns auf SNARK-freundliche Hash-Funktionen zu verlassen?

Danksagungen

Vielen Dank an Enrico Bottazzi, Cedoor, Vivian Plasencia und Wanseob für die Hilfe beim Navigieren im Netz der Codebasen für Mitgliedschaftsnachweise.

Haftungsausschluss:

1. Dieser Artikel wurde von [ethresear] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [George Kadianakis, Mary Maller, Andrija Novakovic, Suphanat Chunhapanya]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Th
   Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.