Introduction

La feuille de route d'Ethereum intègre une technologie de mise à l'échelle appelée Data Availability Sampling (DAS) 6. Le DAS introduit de nouvelles <a href="https://notes.ethereum.org/@djrtwo/das-requirements"> exigences 4 à la pile réseau d'Ethereum, ce qui nécessite la mise en œuvre de protocoles réseau spécialisés 7. L'un des principaux <a href="https://notes.ethereum.org/@dankrad/S-Kademlia-DAS"> protocoles proposition 4 utilise une table de hachage distribuée (DHT) basée sur Kademlia 2 pour stocker et récupérer les échantillons de données.

Cependant, les DHT 4 sont sensibles aux attaques de Sybil : Un attaquant qui contrôle un grand nombre de nœuds DHT peut rendre les échantillons DAS indisponibles. Pour contrer cette menace, il est possible d'établir une couche de réseau de haute confiance, composée uniquement de validateurs de chaînes de balises. Une telle mesure de sécurité augmente considérablement la barrière pour les attaquants, puisqu'ils doivent maintenant miser leur propre ETH pour attaquer le DHT.

Dans ce billet, nous présentons un protocole de preuve de validateur, qui permet aux participants de la DHT de démontrer, à zéro connaissance, qu'ils sont un validateur Ethereum.

Motivation : Attaque par "dissimulation d'échantillons" sur les DAS

Dans cette section, nous motivons davantage la preuve du protocole du validateur en décrivant une attaque de Sybil contre l'échantillonnage de la disponibilité des données.

Le protocole DAS s'articule autour du constructeur de blocs, qui veille à ce que les données des blocs soient mises à la disposition des clients pour qu'ils puissent les récupérer. Les approches actuelles consistent à diviser les données en échantillons, et les participants au réseau ne récupèrent que les échantillons qui les intéressent.

)

Considérons un scénario dans lequel un attaquant Sybil souhaite empêcher les participants au réseau de récupérer des échantillons auprès d'un nœud victime, qui est responsable de la fourniture de l'échantillon. Comme le montre la figure ci-dessus, l'attaquant génère de nombreux ID de nœuds qui sont proches de l'ID de nœuds de la victime. En entourant le nœud de la victime de ses propres nœuds, l'attaquant empêche les clients de découvrir le nœud de la victime, car les nœuds malveillants dissimuleront délibérément des informations sur l'existence de la victime.

Pour plus d'informations sur ces attaques Sybil, consultez ce récent document de recherche 2 sur les attaques DHT Eclipse. En outre, <a href="https://notes.ethereum.org/@dankrad/S-Kademlia-DAS#SKademlia-modifications"> Dankrad's Proposition de protocole de réseau DAS 8 décrit comment le protocole DHT S/Kademlia souffre de telles attaques et montre la nécessité d'un protocole de preuve de validation.

Preuve du validateur

L'attaque décrite ci-dessus justifie la nécessité d'un protocole de preuve de validité : Si seuls les validateurs peuvent rejoindre la DHT, un attaquant qui souhaite lancer une attaque Sybil doit également miser une grande quantité d'ETH.

Grâce à notre protocole de preuve de validation, nous garantissons que seuls les validateurs de la chaîne de balises peuvent rejoindre la DHT et que chaque validateur obtient une identité DHT unique.

En outre, pour la résistance aux attaques par déni de service des validateurs, nous cherchons également à dissimuler l'identité des validateurs sur la couche réseau. En d'autres termes, nous ne voulons pas que les attaquants soient en mesure de déterminer quel nœud de la DHT correspond à quel validateur.

Pour atteindre ces objectifs, le protocole de preuve de validité doit répondre aux exigences suivantes :

• Unicité : Chaque validateur de chaîne de balises doit être en mesure de dériver une paire de clés unique. Cette propriété limite non seulement le nombre de nœuds qu'un attaquant Sybil peut générer, mais permet également aux participants au réseau de punir localement les nœuds qui se comportent mal en bloquant leur paire de clés dérivée.
• Confidentialité : Les adversaires doivent être incapables de savoir quel validateur correspond à une clé publique dérivée particulière.
• Temps de vérification : le processus de vérification du protocole doit être efficace et prendre moins de 200 ms par nœud, ce qui permet à chaque nœud d'apprendre au moins cinq nouveaux nœuds par seconde.

Un tel protocole de preuve de validité serait utilisé par Bob lors de l'établissement de la connexion dans la couche DHT, de sorte qu'Alice sache qu'elle s'adresse à un validateur.

Preuve du protocole du validateur

Notre protocole de preuve de validité est en fait un simple système d'authentification anonyme. Son objectif est de permettre à Alice de générer une clé dérivée unique, dénommée D, si et seulement si elle est un validateur. Par la suite, Alice utilise cette clé dérivée D au sein de la couche réseau.

Lors de la conception de ce protocole, notre objectif était de créer une solution à la fois simple à mettre en œuvre et à analyser, en veillant à ce qu'elle réponde efficacement aux exigences énoncées.

Aperçu du protocole

Le protocole utilise un sous-protocole de preuve d'appartenance, dans lequel Alice prouve qu'elle est un validateur en démontrant qu'elle connaît une préimage de hachage secrète à l'aide de preuves ZK. Alice construit ensuite une paire de clés unique dérivée de ce préimage de hachage secret.

Le sous-protocole de preuve d'appartenance peut être instancié par différentes méthodes. Dans ce billet, nous présentons un protocole utilisant les arbres de Merkle et un second protocole utilisant les listes de recherche.

Bien que les deux approches soient d'une efficacité acceptable, elles présentent des compromis distincts. Les arbres de Merkle reposent sur des fonctions de hachage compatibles avec SNARK, comme Poseidon (qui peut être considéré comme expérimental). D'autre part, les protocoles de recherche efficaces reposent sur une configuration de confiance de puissance de Tau dont la taille est égale à celle de l'ensemble des validateurs (actuellement 700 000 validateurs, mais ce nombre ne cesse de croître).

Entrons à présent dans les protocoles :

Approche n° 1 : arbres de Merkle

Les arbres de Merkle ont été largement utilisés pour les preuves d'appartenance (par ex. voir Sémaphore 3). Voici l'espace de compromis lors de la conception d'une preuve d'appartenance à l'aide d'arbres de Merkle :

• Positif : Pas besoin d'une configuration de confiance
• Positif : Simple à comprendre
• Négatif : S'appuie sur des fonctions de hachage compatibles avec SNARK comme Poseidon
• Négatif : Création de preuves plus lente

Nous décrivons ci-dessous la preuve du protocole de validation basé sur les arbres de Merkle :

Protocole de preuve de validation utilisant les arbres de Merkle

)

À la fin du protocole, Alice peut utiliser D dans la DHT pour signer les messages et en déduire son identité unique de nœud de la DHT.

Examinons maintenant une solution un peu plus compliquée, mais beaucoup plus efficace, qui fait appel à des listes de référence.

Approche n°2 : consultations

Voici l'espace de compromis de l'utilisation de protocoles de recherche 2 comme Caulk 2:

• Positif : Création de preuves extrêmement efficace (à l'aide d'une phase de prétraitement)
• Positif : Le protocole peut être adapté pour utiliser une fonction de hachage ordinaire au lieu de Poséidon.
• Négatif : Nécessite une installation de confiance de grande taille (idéalement égale à la taille des validateurs).

Nous décrivons ci-dessous une preuve concrète du protocole du validateur :

Preuve du protocole du validateur à l'aide de listes de contrôle

Exactement comme dans l'approche Merkle, chaque validateur i enregistre une nouvelle valeur pi sur la blockchain de telle sorte que :

Efficacité

Nous avons évalué la durée d'exécution de notre protocole de preuve d'appartenance(lien 6 vers le code de référence 5) en termes de création et de vérification de preuves. Notez que, bien que la preuve d'appartenance ne soit qu'une partie de notre protocole de preuve du validateur, nous nous attendons à ce qu'elle domine le temps d'exécution global.

Nous présentons ci-dessous des résultats de référence pour une preuve d'appartenance à un arbre de Merkle utilisant le système de preuve Halo2 avec l'IPA comme schéma d'engagement polynomial. L'IPA est plus lent que le KZG, mais il ne nécessite pas de configuration de confiance, ce qui maximise les avantages de l'approche de l'arbre de Merkle.

Nous observons que les temps du prouveur et du vérificateur s'alignent bien sur nos exigences d'efficacité. Pour cette raison, nous avons décidé de ne pas comparer l'approche basée sur Caulk, car ses performances devraient être nettement supérieures dans toutes les catégories (en particulier le temps de démonstration et la taille de la preuve).

Les tests ont été effectués sur un ordinateur portable équipé d'un processeur Intel i7-8550U (vieux de cinq ans).

Discussion

Identités tournantes

La propriété d'unicité du protocole de preuve de validation garantit que chaque participant au réseau possède une paire de clés dérivée distincte. Toutefois, pour certains protocoles de réseau, il peut être avantageux de permettre aux validateurs d'avoir des identités tournantes, où leurs clés dérivées changent périodiquement, voire quotidiennement.

Dans un tel scénario, si Eve se comporte mal un jour donné, Alice peut la mettre sur liste d'exclusion pour ce jour-là. Toutefois, le lendemain, Eve peut générer une nouvelle clé dérivée, qui n'est pas inscrite sur la liste de blocage. Si nous voulions être en mesure de bloquer de façon permanente les validateurs sur la base de leur identité rotative, nous aurions besoin d'un système d'identification anonyme plus avancé comme SNARKBlock 1.

Pourquoi ne pas utiliser la clé publique d'identité BLS12-381 ?

Une autre approche (peut-être plus simple) consisterait à créer un engagement à partir de toutes les clés BLS12-381 d'identité du validateur et à effectuer une preuve d'appartenance sur cet engagement.

Toutefois, cette approche nécessiterait que les validateurs insèrent leur clé privée d'identité dans le système de preuve ZK afin de créer une preuve d'appartenance valide et de calculer la clé dérivée unique.

Nous avons décidé de ne pas adopter cette approche parce que ce n'est pas une bonne pratique d'insérer des clés d'identité sensibles dans un protocole cryptographique compliqué, et que cela rendrait plus difficile pour les validateurs de garder leur clé d'identité principale hors ligne.

Orientations futures de la recherche

• Est-il possible d'éviter complètement les circuits SNARK et d'effectuer la preuve d'appartenance et la dérivation de la clé de manière purement algébrique ?
• En rapport : Est-il possible d'avoir un protocole de preuve d'appartenance efficace sans configuration de confiance et sans s'appuyer sur des fonctions de hachage compatibles avec SNARK ?

Remerciements

Merci à Enrico Bottazzi, Cedoor, Vivian Plasencia et Wanseob pour leur aide dans la navigation sur la toile des bases de code de preuve d'appartenance.

Clause de non-responsabilité：

1. Cet article est repris de[ethresear]. Tous les droits d'auteur appartiennent à l'auteur original[George Kadianakis , Mary Maller, Andrija Novakovic, Suphanat Chunhapanya]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les
   es points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.