Conseils de lecture

Avant de lire cet article, vous devez avoir une compréhension de base de MEV

· Être familier avec les transactions Ethereum et comprendre ce qu'une transaction contient et comment elle est finalement incluse dans le bloc

· Connaître l'arbre de Merkle et le rôle de la preuve de connaissance nulle

· cliquez pour lire : MEV (5): Un écosystème MEV plus juste (Partie 1)

L'article précédent a présenté (1) la conception du constructeur Flashbot SGX, qui augmente l'équité du constructeur de bloc grâce à un matériel de confiance, et (2) la conception du FSS Chainlink, qui empêche MEV en décentralisant les rôles de commande des transactions.

Cet article discutera (3) de la conception des Mempools cryptés, qui vise à réduire ou à éliminer MEV en offrant la confidentialité des transactions par des méthodes cryptographiques.

Mempools chiffrés

Deux objectifs : protection MEV et résistance à la censure

S'il existe un outil qui permet aux utilisateurs de crypter leurs transactions avant de les diffuser, et de les décrypter uniquement lorsqu'elles sont incluses dans le bloc, les utilisateurs n'auront pas à se soucier d'être affectés par MEV. Le chercheur MEV ne peut pas du tout voir le contenu de la transaction, et les utilisateurs n'ont pas besoin de se soucier du fait que leurs transactions soient refusées en raison d'être ciblées par les proposants ou de violer les sanctions gouvernementales. La pierre angulaire de la construction de cet outil est la cryptographie.

Les Mempools chiffrées utilisent la cryptographie pour (1) chiffrer le contenu de la transaction de l'utilisateur afin de protéger leur vie privée, et (2) vérifier la validité de la transaction lorsqu'elle est chiffrée, empêchant les attaquants de générer un tas de transactions chiffrées invalides. Cela les empêche de lancer une attaque par déni de service sur la chaîne, car le Proposer gaspillerait de l'espace de bloc en incluant un tas de transactions invalides qui ne sont découvertes qu'au dernier moment.

Conseil de lecture : La simple cryptographie ne peut pas garantir pleinement la résistance à la censure, car le Proposer qui souhaite censurer peut toujours refuser d'accepter toute transaction cryptée, ainsi la cryptographie ne fait qu'augmenter le coût de la censure (le Proposer renonce aux frais de traitement de toutes les transactions cryptées). Pour obtenir une meilleure protection contre la censure, vous devez utiliser une liste d'inclusion telle que PBS.

Assurez-vous que les transactions peuvent être déchiffrées (Déchiffrement garanti)

Après avoir chiffré la transaction, il est important de s'assurer qu'elle peut être déchiffrée. Ne pas le faire peut créer une vulnérabilité dans une attaque par déni de service (DoS). Dans une telle attaque, l'attaquant envoie de manière répétée des transactions chiffrées qui ne peuvent pas être déchiffrées. Par conséquent, le nœud doit conserver ces transactions jusqu'à leur expiration, ce qui entraîne une accumulation de ces transactions inutiles dans le pool de transactions du nœud.

Il existe quelques moyens de s'assurer que les transactions peuvent être déchiffrées :

1. Pure trust (En vol)

2. Matériel de confiance, Enclave

3. Chiffrement/Déchiffrement de seuil

4. Chiffrement/Déchiffrement de retard

5. Témoin de chiffrement/déchiffrement

△ Plusieurs façons de garantir que les transactions peuvent être décryptées et leurs exemples. La complexité augmente de gauche à droite, avec la confiance pure étant la plus simple et le décryptage des témoins étant le plus difficile.

Source de l'image :https://www.youtube.com/watch?v=XRM0CpGY3sw

Commit-reveal

Le mécanisme de commit-reveal peut-il également atteindre le même objectif? L'utilisateur commence par entrer le contenu de sa transaction dans une fonction de hachage pour obtenir une valeur de hachage, appelée engagement. Une fois que le demandeur garantit l'inclusion de l'engagement de transaction de l'utilisateur dans le bloc, l'utilisateur procède à la divulgation du contenu complet de la transaction.

Conseil de lecture : La manière d'engagement peut être semblable au Proposer dans PBS promettant qu'il sera inclus dans le bloc Builder par signature. C'est un engagement garanti. Si le Proposer viole la promesse, il sera puni.

△ Le proposant promet de recevoir l'engagement de la transaction d'Alice

Bien que Commit-reveal et le chiffrement puissent servir au même objectif de masquer le contenu des transactions des utilisateurs et de prévenir l'extraction et la censure de MEV, Commit-reveal ne peut pas garantir le déchiffrement puisque le pouvoir réside entre les mains de l'utilisateur. L'utilisateur a le choix de ne pas révéler le contenu, que ce soit intentionnellement ou non.

Exiger des utilisateurs de joindre un dépôt et de confisquer le dépôt s'ils se retrouvent sans révélation peut aggraver l'expérience utilisateur déjà médiocre du Commit-reveal.

△ Alice n'a pas besoin de révéler sa transaction

1. Confiance pure (En vol)

L'utilisateur crypte la transaction et l'envoie au rôle centralisé. Le rôle centralisé décrypte ensuite la transaction et s'assure qu'elle ne sera pas divulguée avant d'être incluse dans le bloc. Les utilisateurs font généralement confiance au rôle centralisé et considèrent les transactions comme cryptées jusqu'à ce qu'elles soient incluses dans le bloc, même si le rôle centralisé décrypte la transaction immédiatement après l'avoir reçue.

Conseil de lecture : Ce rôle centralisé serait, par exemple, le constructeur, le proposeur ou le séquenceur/opérateur de PBS, ou de l'agrégat de Rollup.

2. Matériel de confiance, Enclave

Il fonctionne de la même manière que la confiance pure, mais mieux que la confiance pure car les utilisateurs font confiance à un matériel de confiance et au code du programme qu'il exécute, plutôt que de faire confiance à une personne, une organisation ou une entreprise.

3. Chiffrement/Déchiffrement seuillé

Chainlink FSS utilise également le chiffrement et le déchiffrement par seuil, mais dans Chainlink FSS, les gestionnaires des clés de seuil sont les Oracles de Chainlink, tandis que dans les Mempools chiffrées, les gestionnaires (appelés Keypers) peuvent être des Validateurs de L1 ou L2 (en supposant que L2 ait également un Validator décentralisé).

Le chiffrement/déchiffrement seuillé présente plusieurs inconvénients :

• Hypothèse d'une majorité honnête forte : Il faut supposer que plus de la moitié des Keypers sont honnêtes. S'ils sont malhonnêtes, ils peuvent décrypter et voir les transactions des utilisateurs à leur guise, examiner les transactions, ou extraire le MEV des transactions.
• Manque de responsabilité : tant qu'un nombre suffisant de participants Keyper collaborent, ils peuvent décrypter les informations. Cependant, lorsque les participants Keyper complotent, nous ne savons pas lesquels sont impliqués dans le complot. Sans pouvoir identifier les acteurs malveillants, il est impossible de concevoir un mécanisme de punition pour Keyper. Par conséquent, nous devons nous appuyer sur l'hypothèse que la majorité des participants Keyper sont honnêtes.
• Affaiblissement de la vivacité : Un nombre excessif de Keyper hors ligne entraînera un nombre insuffisant de Keyper en ligne, ce qui empêchera le déchiffrement et la production de blocs. Cela entraînera l'arrêt de la chaîne. Cela entre en conflit avec le mécanisme PoS d'Ethereum, qui souligne que la chaîne continuera à produire des blocs même en cas de troisième guerre mondiale, et finira par atteindre la finalité. On peut en déduire que la probabilité d'Ethereum PoS utilisant le déchiffrement avec un seuil n'est pas élevée.

Parce que le chiffrement et le déchiffrement seuillés nécessitent beaucoup de changements, L2 est plus adapté à cette approche que L1.

Cet article propose la conception et les considérations pour la mise en œuvre en L1. Les projets qui testent cette conception peuvent se référer à Shutter Network. Pour plus d'informations, veuillez consulter :https://ethresear.ch/t/shutterized-beacon-chain/12249

4. Cryptage/Décryptage en différé

Le chiffrement différé garantit que le texte chiffré peut être automatiquement déchiffré après un certain temps. Cependant, le processus de décryptage n’est pas vraiment automatique et nécessite que quelqu’un agisse en tant que décrypteur et effectue des calculs continus. Après un certain laps de temps, déterminé par la difficulté du cryptage, les calculs peuvent être terminés et le décryptage peut être réalisé avec succès.

Le concept de chiffrement à retardement est similaire à la fonction de retard vérifiable (VDF), qui appartiennent tous deux à la famille de la cryptographie à libération temporelle.

VDF nous permet de vérifier rapidement F(x) : un résultat de "calcul séquentiel chronophage". Cela est similaire à la Preuve de Travail (PoW), mais le calcul de VDF est un processus séquentiel, contrairement à PoW, qui peut être accéléré grâce au calcul parallèle. Le déchiffreur de VDF ne peut effectuer que des calculs répétés étape par étape.

△ Avec VDF, vous pouvez vérifier le résultat d'un calcul qui m'a pris 10 secondes à effectuer, disons, en 0,01 seconde, et je n'avais aucun moyen de paralléliser mon calcul. Source de l'image :https://techtelegraph.co.uk/fonctions-de-retard-vérifiables-sur-bitcoin

Le chiffrement et le déchiffrement différés sont également des calculs continus comme VDF et ne peuvent pas être accélérés par des opérations parallèles. Cependant, il faut considérer que quelqu'un accélérera le processus de déchiffrement grâce à une optimisation matérielle. Par conséquent, si vous souhaitez adopter cette technologie et l'appliquer dans un environnement public réel, vous devez vous assurer que personne n'a un énorme écart matériel et ne peut achever le déchiffrement à l'avance (et le déchiffrement est effectué en privé, il est donc difficile à détecter).

Actuellement, la Fondation Ethereum et Protocol Labs collaborent déjà sur la recherche de puces ASIC VDF, dans l'espoir d'exporter le matériel informatique le plus avancé sur le marché, de sorte que personne ne puisse avoir d'avantages matériels disparates et décrypter secrètement à l'avance. Pour en savoir plus, veuillez consulter :https://filecoin.io/blog/posts/collaboration-with-the-ethereum-foundation-on-vdfs/

Conseil de lecture : VDF peut également être utilisé pour augmenter l'impossibilité de manipulation des nombres aléatoires d'Ethereum.

L'avantage du chiffrement et du déchiffrement différés par rapport au chiffrement et au déchiffrement seuil est qu'il n'a pas besoin de faire confiance ou de compter sur le fonctionnement normal d'un groupe de gardiens de clés, et il se déchiffrera automatiquement lorsque le temps sera écoulé. Cependant, ce temps de déchiffrement imposé est également un inconvénient du déchiffrement différé : les transactions chiffrées doivent prendre un certain temps pour être déchiffrées, ce qui signifie qu'il y a un délai fixe pour que les transactions des utilisateurs soient téléchargées sur la chaîne. De plus, la concurrence matérielle est également un risque qui ne peut être ignoré dans cette méthode. Il est difficile de savoir si quelqu'un a développé une puce plus rapide pour déchiffrer.

5. Témoin de chiffrement/déchiffrement

Imaginez qu'un texte chiffré ne soit pas déchiffré par une clé ou un calcul séquentiel, mais ne puisse être déchiffré que lorsqu'une certaine "condition" est remplie, telle que "lorsque cette équation est résolue" ou "lorsque cette équation est résolue" Une fois que le texte chiffré est inclus dans le bloc, le texte chiffré peut être déchiffré, et ainsi de suite.

Conseil de lecture : "Connaître la clé pour décrypter un texte chiffré" ou "connaître les résultats de calculs continus" est en fait une condition.

Grâce au chiffrement des témoins, nous pouvons non seulement obtenir les effets du chiffrement seuil et du chiffrement différé, mais nous pouvons également combiner ces deux méthodes de déchiffrement. Par exemple, nous pouvons définir les conditions comme suit : "Condition 1 : 'Un groupe de Keypers accepte de déchiffrer ce texte chiffré' ou Condition 2 : 'Après cinq minutes'" : Si tous les Keypers sont en ligne, nous pouvons rapidement satisfaire la Condition 1 pour déchiffrer le texte chiffré. Cependant, s'il n'y a pas suffisamment de Keypers en ligne, nous pouvons au moins nous assurer que nous pouvons satisfaire la Condition 2 et déchiffrer en prouvant grâce au VDF que 'cinq minutes se sont écoulées'.

△ Assez de Keypers peuvent être déchiffrés en ligne (ci-dessus) ou après un certain temps (ci-dessous)

Tant que les conditions sont prouvées être remplies, le décryptage peut être réalisé. La preuve peut être faite à travers des méthodes telles que les preuves de connaissance nulle, qui peuvent vérifier efficacement des calculs complexes (en supposant que les opérations requises pour prouver les conditions sont complexes) ou cacher des informations (en supposant que le prouveur ne veut pas révéler certaines informations pendant le processus de preuve). Cependant, bien que le chiffrement de témoin soit très puissant, la technologie actuelle n'est pas suffisante pour fournir une utilisation pratique.

△ La maturité des différentes technologies de cryptage et de décryptage. Le cryptage et le décryptage des témoins (Witness) ne sont pas encore suffisamment matures. Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

Manipuler et effectuer des opérations sur le texte chiffré grâce au chiffrement homomorphe

Les paragraphes précédents ont introduit différentes façons de garantir que les transactions peuvent être déchiffrées, mais quand les transactions peuvent-elles être déchiffrées? La réponse est: après que la transaction a été incluse dans le bloc et l'ordre est déterminé. Mais comment le constructeur de bloc assemble-t-il un bloc à partir d'un tas de charabia, ou même assemble-t-il efficacement un bloc très rentable? La réponse est: Cryptage homomorphique (HE).

△ Exemple de chiffrement homomorphique utilisé pour le vote: Le contenu du vote a été chiffré, mais le texte chiffré peut toujours être additionné et déchiffré après que le résultat soit calculé. Source de l'image :https://twitter.com/khushii_w/status/1660278622291210242

Conseil de lecture : Si le chiffrement et le déchiffrement sont effectués via une confiance pure (en vol) ou un matériel de confiance, il n'attend en réalité pas que la transaction soit incluse dans le bloc et que l'ordre soit déterminé avant le déchiffrement. Après tout, tout le monde fait confiance à l'autre partie, il déchiffrera et triera la transaction immédiatement après l'avoir reçue. Cela peut accélérer la formation des blocs et ne nécessite pas de ressources supplémentaires pour effectuer des opérations de chiffrement homomorphique.

Grâce au cryptage homomorphique, nous pouvons effectuer des opérations sur le texte chiffré sans le décrypter. Nous pouvons appliquer le processus d'opération de disposition des transactions et de formation d'un bloc légal à ces transactions chiffrées sans les décrypter, et obtenir un bloc de transaction chiffré. Lorsque le bloc est décrypté, nous obtiendrons un bloc complet et légal, dans lequel les transactions sont décryptées et triées dans l'ordre avant le cryptage.

△ Grâce au chiffrement homomorphe, Block Builder peut assembler un bloc complet et légal à partir de transactions chiffrées

Conseil de lecture : Il existe des niveaux de cryptage homomorphe, tels que le cryptage partiellement homomorphe (Partiellement HE) et le cryptage entièrement homomorphe (Entièrement HE). Le cryptage partiellement homomorphe ne peut ajouter ou multiplier que des textes chiffrés, tandis que le cryptage entièrement homomorphe peut ajouter et multiplier des textes chiffrés (essentiellement, toute opération peut être effectuée).

△ Le troisième colonne : La maturité des différentes technologies de chiffrement et de déchiffrement supportant le FHE. À l'exception du chiffrement en vol et de l'enclave, qui ne nécessitent pas de HE et sont donc considérés comme pris en charge, les autres ne sont pas encore disponibles. Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

Ce qui précède présente différents mécanismes pour chiffrer et déchiffrer les transactions. Chacun d'eux a des avantages et des inconvénients différents, mais en fin de compte, tout ce qu'ils peuvent faire est de cacher le contenu de la transaction et de s'assurer qu'il peut être déchiffré lorsque les conditions sont remplies. Une fois le contenu de la transaction caché, il peut éviter d'être déchiffré. Extraction de MEV et risque de censure.

Mais les données de transaction elles-mêmes comporteront des métadonnées pertinentes, telles que l'initiateur de la transaction, les frais de transaction ou la signature, qui sont utilisés pour vérifier la validité de la transaction. De plus, l'adresse IP de l'initiateur est également une forme de métadonnées, et même la taille des données de la transaction. Toutes ces métadonnées ont le potentiel de compromettre la vie privée de l'utilisateur, nous devons donc également protéger ces métadonnées.

Veiller à ce que les métadonnées ne divulguent pas la vie privée

Les listes suivantes les diverses métadonnées des transactions chiffrées et les mesures de protection correspondantes, qui nécessiteront des techniques cryptographiques telles que le chiffrement homomorphique et les preuves de connaissance nulle.

1. Adresse IP

2. Signature de transaction

3. Frais de transaction

4. Initiateur de transaction et sa valeur de nonce

5. Taille de la transaction

△ Les métadonnées différentes des transactions peuvent compromettre la vie privée des utilisateurs. Source de l'image:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

adresse IP

Le réseau auquel un utilisateur se connecte pour envoyer des transactions cryptées peut révéler l'identité de l'utilisateur en fonction de l'adresse IP de l'utilisateur et peut être censuré. La protection de la vie privée au niveau du réseau repose sur des technologies telles que Tor.

Signature de transaction, frais de traitement, initiateur de transaction et sa valeur de Nonce

Ces métadonnées sont utilisées pour prouver la validité de la transaction, mais elles révéleront l'identité de l'utilisateur, elles doivent donc être chiffrées. Une fois chiffrées, nous devons utiliser d'autres outils pour prouver la validité des transactions sans révéler ces informations. Sinon, le réseau pourrait être attaqué par DoS et être rempli d'une multitude de transactions invalides qui ne sont découvertes qu'après le déchiffrement.

Lorsqu'un nœud reçoit une transaction chiffrée, il doit (1) d'abord confirmer que l'initiateur de la transaction a réellement initié la transaction, c'est-à-dire vérifier la signature de la transaction, puis (2) confirmer que l'initiateur a suffisamment d'ETH pour payer la transaction (solde de l'utilisateur ≥ prix du gaz * limite de gaz), et (3) vérifier la valeur du nonce de l'expéditeur pour éviter les attaques de rejeu de transaction.

Preuve de connaissance nulle

Nous pouvons utiliser des preuves de connaissance nulle pour prouver que les transactions passent ces vérifications sans révéler ces informations. Une preuve de connaissance nulle se compose d'informations publiques (Entrée Publique), d'informations privées (Témoin Privé) et de l'énoncé que la preuve souhaite prouver (Énoncé).

△ Par exemple, les informations publiques (entrée publique) sont une transaction chiffrée (texte chiffré tx), les informations privées (témoin privé) sont une transaction non chiffrée (texte chiffré tx), et l'énoncé (énoncé zk) à prouver par cette preuve de connaissance nulle est "cette "Les transactions chiffrées sont légales" (tx texte chiffré valide). Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

Par exemple, si Alice veut prouver à Bob qu'elle a plus de 10 ETH, mais ne veut pas révéler son adresse, elle peut utiliser une preuve de connaissance nulle pour prouver à Bob que son adresse a réellement un solde de plus de 10 ETH.

"Prouver que l'adresse d'Alice a un solde de plus de 10 ETH" est l'énoncé (énoncé zk) à prouver par cette preuve de connaissance nulle. Afin de générer cette preuve, Alice doit fournir son adresse et prouver qu'elle détient la clé privée de l'adresse (par exemple, en utilisant la clé privée pour générer une signature), et elle doit également fournir le solde en ETH de cette adresse, par exemple, en utilisant une preuve de Merkle pour prouver combien d'ETH cette adresse détient dans le 1001e bloc.

L’adresse, la signature et la preuve Merkle ne peuvent pas être divulguées et sont des informations privées (témoin privé).

Lorsque cette preuve est produite, Bob peut vérifier cette preuve avec la racine de Merkle (appelée racine d'état) de l'arbre d'état du bloc 1001. Tout le monde connaît la racine d'état de chaque bloc, qui est une information publique (entrée publique).

La seule information que Bob connaît est l'information publique de State Root et les résultats de vérification. Il ne saura rien des informations privées d'Alice.

△ Alice fournit deux inputs privés : Preuve de Merkle et signature ; Bob fournit l'input public de la racine d'état. L'énoncé zk peut vérifier qu'Alice a une adresse et que le solde de l'adresse est > 10 ETH

(1) Vérifier la signature de la transaction

La vérification de la signature de la transaction se compose de deux parties : (a) l'initiateur de la transaction est légitime et (b) la signature de la transaction est signée par l'initiateur de la transaction.

(a) Principalement pour vérifier que l'adresse Ethereum de l'initiateur de la transaction est une adresse légale et non un nombre aléatoire. Cela sera prouvé grâce à une Preuve de Merkle que l'adresse existe dans l'arbre d'état Ethereum.

(b) Vérifie que la signature de la transaction est signée par la clé privée de l'initiateur de la transaction.

△ Cette preuve vérifie (a) l'adresse de l'initiateur de la transaction (via la preuve de Merkle de la clé publique de l'expéditeur) et (b) la légitimité de la signature dans la transaction (la signature sera incluse dans le texte brut de la tx). Le texte brut de la tx est la donnée brute non chiffrée de la transaction, qui est l'information privée fournie par l'initiateur de la transaction.

Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

Conseil de lecture : Le texte en rouge dans l'image ci-dessus fait référence à ce que signifie ce certificat après avoir passé la vérification (c'est-à-dire « la signature de la transaction est légale »). Il ne fait pas partie de l'énoncé zk. La partie bleue contient des informations relatives à la transaction elle-même, y compris des données de transaction chiffrées (publiques) et des données de transaction non chiffrées (privées). La partie verte est constituée des données supplémentaires nécessaires pour compléter la preuve, à la fois publiques et privées.

△ Prouvez que l'adresse de l'initiateur de la transaction existe dans l'arbre d'état d'Ethereum et que l'initiateur de la transaction a vraiment la clé privée de l'endroit

(2) Confirmer que l'initiateur de la transaction a suffisamment d'ETH pour payer les frais de traitement

Tout comme dans l'exemple précédent d'Alice et Bob prouvant que le solde est > 10 ETH, l'initiateur de la transaction doit fournir la preuve de Merkle du solde de sa propre adresse, et l'énoncé à prouver est "le solde de l'adresse ≥ les frais de transaction." Les frais de transaction sont égaux au prix du gaz multiplié par la limite de gaz. Les informations sur le prix du gaz et la limite de gaz sont incluses dans les données de transaction non chiffrées d'origine (tx en clair). tx en clair est une information privée fournie par l'initiateur de la transaction.

△ Cette preuve vérifie que le solde de l'adresse de l'initiateur de la transaction (via la preuve de Merkle de solde de l'expéditeur) est supérieur ou égal aux frais de transaction (les informations sur les frais de transaction sont incluses dans le texte en clair de la transaction). Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ Prouver l'équilibre de l'adresse de l'initiateur de la transaction > prix du gaz

(3) Vérifiez la valeur de Nonce de l'initiateur de la transaction

Parce que le Nonce est également enregistré dans l'état Ethereum, la Preuve de Merkle est également utilisée pour prouver la valeur de Nonce actuelle de l'initiateur de la transaction, puis la comparer avec la valeur de Nonce spécifiée dans la transaction pour confirmer que la transaction n'a pas été rejouée.

△ Cette preuve compare la valeur de Nonce de l'adresse de l'initiateur de la transaction (à travers la preuve de Merkle de Nonce) et la valeur de Nonce spécifiée par la transaction (la valeur de Nonce spécifiée par la transaction est incluse dans le texte de la transaction). Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ Prouver le nonce de l'adresse de l'initiateur de la transaction = nonce de la tx

Cependant, cette vérification ne peut pas empêcher les attaquants malveillants de générer plusieurs transactions avec la même valeur de nonce (ces transactions peuvent toutes passer la vérification de la valeur de nonce) pour mener des attaques de type DoS, nous devons donc ajouter des vérifications supplémentaires.

Nous demandons à l'initiateur de la transaction de fournir un autre tag de rejeu pour garantir qu'il n'y aura qu'une seule transaction avec la même valeur de nonce. Le tag de rejeu est la valeur de hachage de la valeur de nonce et de la clé privée de l'initiateur de la transaction : tag de rejeu = H (nonce, clé privée), donc différentes valeurs de nonce du même initiateur de transaction correspondront chacune à un tag de rejeu unique.

Par conséquent, les nœuds peuvent utiliser l'étiquette de rejeu pour identifier si un initiateur de transaction a lancé plusieurs transactions avec la même valeur de nonce (les étiquettes de rejeu de ces transactions seront les mêmes) et rejeter la deuxième transaction avec la même étiquette de rejeu.

△ Cette preuve calculera l'étiquette de rejeu et la comparera avec l'étiquette de rejeu transmise par l'entrée publique. La valeur de Nonce de la transaction est contenue dans le texte brut de la tx, et la clé privée est contenue dans le témoin privé.

Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ Prouver le nonce de l'adresse de l'initiateur de la transaction = nonce de la transaction et balise de rejeu = H(nonce, clé)

Ou si nous considérons que l'initiateur de la transaction peut vouloir remplacer la transaction avec la même valeur de Nonce par une autre transaction, peut-être parce qu'il ne souhaite pas exécuter la transaction originale, ou qu'il souhaite augmenter le prix du gaz afin que la transaction puisse être collectée plus rapidement.

À ce stade, nous pouvons introduire la valeur de Slot de PoS dans le calcul de Replay Tag : replay tag = H(nonce, clé privée, slot). Par exemple, Bob a envoyé une transaction avec un nonce de 5 dans le Slot 1001 mais elle n'a pas encore été reçue, il a donc décidé de doubler le prix du gaz de la transaction tout en laissant les autres champs inchangés, et a envoyé la transaction mise à jour dans le Slot 1005. En raison du changement de Slot, le Replay Tag est différent, et cette nouvelle transaction ne sera pas rejetée car la valeur de nonce est la même.

△ Les entrées publiques transmettront des valeurs de créneau supplémentaires pour le calcul de l'étiquette de rejeu. Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5. Taille de la transaction

Certains méthodes de chiffrement feront en sorte que la taille des données de transaction chiffrées soit identique à celle avant le chiffrement. Cependant, il existe encore une chance de déduire certaines informations à travers la taille. Par exemple, les données de transaction d'une transaction effectuée sur Uniswap doivent être plus grandes que les données de transaction d'un simple transfert d'ETH. Ainsi, la taille de la transaction est la même que celle des métadonnées qui pourraient compromettre la confidentialité.

Une approche intuitive consiste à effectuer une action de remplissage sur les données de transaction avant de les chiffrer, comme remplir avec une série de zéros jusqu'à ce que la taille de la transaction devienne une puissance de deux, voire la remplir entièrement jusqu'à ce qu'elle atteigne une taille fixe. Cela réduit la chance pour un observateur d'identifier une transaction par sa taille. Block Builder combinera les transactions remplies dans un bloc.

△ Le blanc est le rembourrage. Les offres bleues et oranges sont de la même taille, il n'y a donc aucun moyen de les distinguer en fonction de leur taille. Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

Cependant, les inconvénients de cette approche sont que (1) elle est inefficace car beaucoup d'espace dans le bloc sera gaspillé en remplissage, et (2) elle peut ne pas offrir une protection de la vie privée suffisante. Par exemple, la taille de la transaction en rouge sur l'image ci-dessus (quatre carrés) peut être rare, donc elle peut encore être découverte. Si toutes les transactions sont remplies à une taille fixe (comme 64 blocs), la vie privée sera améliorée, mais cela deviendra relativement un gaspillage d'espace de bloc.

△ L'inconvénient est l'inefficacité et une protection de la vie privée limitée. Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

Une meilleure approche consiste d'abord à rembourrer les transactions à une taille fixe, mais le chiffrement homomorphique peut être utilisé pour supprimer le rembourrage.

Parce que les transactions sont toutes rembourrées à une taille fixe, toutes les transactions vues par les observateurs auront la même taille. Le constructeur de blocs peut combiner les transactions chiffrées grâce à une fonction et supprimer le rembourrage en même temps.

△ Utilisez le cryptage homomorphique pour supprimer le rembourrage tout en combinant des transactions chiffrées. Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

Conseil de lecture : Block Builder avec une confiance pure ou un matériel de confiance peut obtenir le même effet sans chiffrement homomorphe (après tout, tout le monde lui fait confiance).

Comment Block Builder construit des blocs efficaces

Bien que nous puissions combiner efficacement les transactions chiffrées dans un bloc grâce au chiffrement homomorphique, il reste encore certains problèmes à résoudre, tels que (1) différentes transactions peuvent lire et écrire le même état (par exemple, elles échangent toutes sur Uniswap), ce qui peut entraîner une probabilité plus élevée d'échec pour les transactions de rang inférieur, et (2) le Constructeur de Blocs ne peut pas collecter les transactions en fonction du niveau des frais de traitement.

La solution idéale est d’exécuter l’EVM en chiffrement homomorphe, tout comme si l’on mettait un EVM dans une boîte noire pour l’exécution, afin que le Block Builder puisse simuler l’exécution des transactions via l’EVM pour former le bloc le plus efficace et le plus rentable. Cependant, la complexité technique de cette technologie est trop élevée, et il faudra beaucoup de temps pour la réaliser.

L'alternative consiste à attacher des frais de traitement cryptés et une liste d'accès cryptée à la transaction (la liste d'accès est utilisée pour indiquer quels états la transaction lira et écrira), et à utiliser le cryptage homomorphique pour vérifier la validité. De cette manière, le constructeur de blocs peut déterminer l'ordre des revenus des transactions grâce aux frais de traitement, et utiliser la liste d'accès pour empêcher les transactions de s'affecter mutuellement et d'entraîner une efficacité d'exécution de transaction réduite.

△ Il est déterminé par les frais de traitement et la liste d'accès quelles transactions doivent être collectées et dans quel ordre elles doivent être collectées. Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

Le moment où la transaction se produit

Si nous craignons que l'heure à laquelle les transactions chiffrées sont envoyées au réseau p2p puisse compromettre la confidentialité (par exemple, Alice effectue des transactions à UTC+8 00:00–04:00), nous pouvons demander aux validateurs d'envoyer régulièrement un tas de transactions factices chiffrées pour embrouiller l'observateur.

La transaction factice devra être accompagnée d'une preuve de connaissance nulle pour prouver qu'elle a été envoyée par le validateur et limiter la fréquence pour éviter que le réseau ne soit rempli de transactions factices (les observateurs ne sauront pas qu'il s'agit d'une transaction factice, seulement qu'elle est "légale et valide").

La transaction fictive sera identifiée et rejetée lors de l'opération de chiffrement homomorphe du bloc de groupe.

△ Les validateurs envoient régulièrement des Transactions Factices (grises) pour tromper les observateurs, mais cela augmentera la charge sur le réseau et les nœuds. Source de l'image :https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

Pools de mémoire chiffrée contre FSS

L'article précédent a également introduit que FSS va chiffrer les transactions d'abord et ensuite les remettre à Chainlink Oracle pour le tri. Le processus de chiffrement des transactions par FSS et de vérification de la validité des transactions chiffrées est en fait le même que les Encrypted Mempools, sauf :

• Le cryptage des transactions de FSS ne mentionne pas la protection des métadonnées, tandis que les Mempools chiffrés cachent les métadonnées et utilisent la preuve de zéro connaissance pour prouver la validité de la transaction.
• FSS utilise actuellement le chiffrement/déchiffrement par seuil et est déchiffré conjointement par Chainlink Oracle, ce qui signifie que vous devez faire confiance à Chainlink Oracle. Les Mempools cryptés ne précisent pas comment trier, mais se concentrent uniquement sur le chiffrement des transactions et la preuve de leur validité avec des preuves de connaissance nulle.
• Comparé à FSS qui met uniquement l'accent sur la "justesse", Encrypted Mempools met davantage l'accent sur "comment assembler efficacement le contenu du bloc et comment permettre au Proposer d'assembler le bloc le plus bénéfique au lieu de simplement décider aléatoirement de l'ordre des transactions."

À l'avenir, le FSS pourrait également utiliser la technologie des Mempools cryptés pour améliorer ou remplacer ses transactions de chiffrement et de déchiffrement.

S'attaquer à MEV avec la cryptographie

Cette conférence porte sur les pools de mémoire chiffrés, où l'auteur partage comment les techniques cryptographiques et les améliorations dans la couche de consensus d'Ethereum peuvent aider à lutter contre les problèmes causés par MEV. Pour plus de détails, veuillez vérifier :https://www.youtube.com/watch?v=mpRq-WFihz8

Résumé et points saillants

1. Le but des Mempools cryptés est de se protéger contre MEV et la censure en cryptant les transactions. Les autres ne peuvent savoir que vos transactions sont valides, mais ils ne peuvent pas savoir quelles actions vous effectuez dans vos transactions.

2. Cependant, pour vraiment atteindre une résistance efficace à la censure, un mécanisme tel que la Liste d'Inclusion PBS doit être utilisé. Sinon, le Builder peut toujours exercer la censure en refusant de recevoir des transactions chiffrées.

3. Il n'est pas facile de prouver qu'une transaction chiffrée est valide. Vous avez besoin de plusieurs preuves de connaissance nulle pour prouver la signature de la transaction, la valeur de Nonce de l'initiateur de la transaction, des frais de traitement suffisants, etc.

4. De plus, il est nécessaire d'éviter que des métadonnées telles que l'IP, la taille des données de transaction ou l'heure d'envoi de la transaction ne compromettent la confidentialité de la transaction.

5. Enfin, le plus important est de s’assurer que les transactions peuvent être décryptées —— Cryptage garanti. Il existe cinq méthodes différentes : Confiance pure (à la volée), Enclave matérielle approuvée, Chiffrement/déchiffrement de seuil, Chiffrement/déchiffrement différé et Chiffrement/déchiffrement des témoins. Chaque méthode a ses propres avantages et inconvénients.

Données de référence et lectures recommandées

Mempools chiffrés

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• Comment la cryptographie aide à résoudre les problèmes causés par MEV de la couche d'application et de la couche de consensus :https://youtu.be/jLHf6yw7b5Y?t=4139

Un grand merci à Steven Wu, Kimi Wu, Kevin Mai-Hsuan Chia et Anton Cheng pour avoir examiné et amélioré ce post.

Avertissement：

1. Cet article est repris de [ techflowpost]. Tous les droits d'auteur appartiennent à l'auteur original [Will 阿望; Diane Cheung]. Si des objections sont faites à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont exclusivement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdite.