Note des auteurs :init4est un collectif de recherche travaillant sur les outils Ethereum de prochaine génération. Il s'agit d'une note de recherche, pas d'un document de divulgation. Bien que nous discuterons des nuances et des lacunes dans les modèles de sécurité des systèmes déployés et proposés, il serait hyperbolique de décrire ceux-ci comme des "vulnérabilités" ou comme "précédemment inconnus".

La résistance à la censure reste une valeur fondamentale des cryptomonnaies en général, et Ethereum en particulier. Nous croyons que les avantages des transactions sur chaîne doivent être accessibles à tous, et que les règles de la chaîne doivent s'appliquer à tous les utilisateurs de manière équitable. Les valeurs font avancer cet espace. L'ingénierie est le processus de mise à l'épreuve de nos valeurs face à la réalité pour déterminer où et comment elles se brisent.

Les dominos se suivent aussi :) Photo parTom WilsonsurUnsplash

Définition de la résistance à la censure

Nous avons tendance à modéliser la censure comme empêchant intentionnellement les transactions d'apparaître dans l'ordre canonique (c'est-à-dire l'exclusion de transactions). Nous considérons que les ordres sont équitables ou neutres lorsqu'ils dépendent entièrement du résultat économique pour le système de commande, et injustes ou censurés lorsqu'ils dépendent d'autres informations. Par exemple, lors de la création d'un bloc, il est acceptable de refuser d'inclure une transaction à faible frais, mais inacceptable de refuser d'inclure une transaction parce qu'elle a été envoyée par une personne spécifique. Par conséquent, nous disons qu'une transaction est censurée si son inclusion dépend d'informations non économiques. Si la transaction crée plus de profit observable pour le système de commande que toute autre transaction incluse, mais n'est pas elle-même incluse, elle est considérée comme censurée. Cette définition motive le travail sur les mécanismes d'inclusion forcée pour la résistance à la censure. Si un utilisateur peut forcer l'inclusion de sa transaction, alors elle ne peut être censurée selon cette définition.

Mécanismes d’inclusion forcée

Un objectif de sécurité fondamental des chaînes OP Stack est que le Séquenceur ne doit pas pouvoir empêcher les utilisateurs de soumettre des transactions à la chaîne L2.

• Optimisme

Les rollups modernes ont tendance à avoir un séquençage centralisé. Cela signifie que la censure par le séquenceur est trivial, car il peut simplement choisir de ne pas inclure une transaction utilisateur donnée. Pour résister à cela, plusieurs rollups - y compris OptimismeetArbitrum - disposent de mécanismes d'inclusion forcée. Ces mécanismes permettent à un utilisateur de s'assurer que sa transaction sera exécutée par le rollup après un certain délai, indépendamment du comportement du séquenceur. L'inclusion est forcée via un contrat déployé sur L1. Par conséquent, les transactions d'inclusion forcée ont (théoriquement) la même résistance à la censure que les autres transactions Ethereum.

L'inclusion forcée spécifie une sous-plage qui doit être conservée dans tout ordre valide.

Un mécanisme d'inclusion forcée a également été proposé pour Ethereum via EIP-7547. Les listes d'inclusion permettraient aux propositions de blocs de spécifier partiellement le contenu du bloc suivant. Sous l'hypothèse que les proposants de blocs ont moins d'incitations à censurer que les constructeurs de blocs, cela fournirait une atténuation efficace de la censure.

En général, les mécanismes d'inclusion forcée créent de nouvelles contraintes sur les ordonnancements valides. Ils rendent invalides de larges classes d'ordonnancements selon les règles du protocole¹. L'inclusion forcée doit être considérée comme permettant à l'utilisateur de spécifier un sous-ensemble de l'ordonnancement futur. Tous les ordonnancements valides doivent se développer à partir du sous-ensemble forcé.

Élargir notre modèle de résistance à la censure

Malheureusement, la confirmation de la transaction est le moyen, pas la fin. Notre modèle de résistance à la censure est incomplet!

La censure doit être définie en termes d'objectifs. Les utilisateurs veulent envoyer des jetons, acheter des NFT, emprunter des fonds, etc. La confirmation de la transaction est accessoire à cet objectif². Les censeurs, de même, ont des objectifs spécifiques. Cet objectif peut être d'empêcher une transaction de piratage de réussir, de se conformer à une loi ou d'interférer avec les affaires d'un concurrent. En respectant l'intention des deux parties, nous devons redéfinir la censure.

Dans cette optique, nous devrions élargir notre définition de la censure en disant : une transaction est censurée si un tiers peut l'empêcher d'atteindre son objectif. Autrement dit, le censeur n'a pas besoin d'empêcher la confirmation de la transaction ; il lui suffit de faire avorter l'exécution du contrat intelligent. Faire avorter une transaction EVM équivaut à censurer cette transaction, malgré le fait que cette transaction fasse partie de la chaîne canonique. Les modèles de menace qui sont aveugles au contenu d'une transaction ne modélisent pas correctement la censure et ne peuvent donc pas protéger efficacement les utilisateurs contre elle.

De manière semi-formelle, nous dirions que pour n'importe quelle interaction donnée avec la chaîne, il existe un prédicat de notation f qui évalue l'ordre résultant et produit 0 (objectif non atteint) ou 1 (objectif atteint). Dans ce modèle, la fonction de notation du censeur est simplement la négation : f’ = !f. Le censeur atteint son objectif lorsque l'utilisateur ne le fait pas.³

Bien que l'objectif de l'utilisateur puisse être caché, la transaction elle-même contient presque toujours suffisamment d'informations pour l'inférer. Les échanges Uniswap ont des objectifs évidents. En outre, parce que les blockchains sont déterministes, le censeur peut parfaitement prédire quelles ordonnances satisferont le prédicat du censeur. En conséquence, les utilisateurs ne peuvent pas compter sur des informations cachées pour les protéger de la censure dans le modèle EVM. Les détails de la transaction doivent être publics, ce qui signifie que des informations sur l'objectif de l'utilisateur sont publiques.

Pour simplifier, supposons que nous travaillons dans le modèle de séquenceur run-ahead standard⁴Nous traiterons ultérieurement de l'inclusion forcée sous la rotation du séquenceur. Dans ce modèle, le séquenceur a un contrôle total sur la séquence et peut simuler parfaitement n'importe quel résultat. Autrement dit, il est libre de choisir parmi l'ensemble de toutes les combinaisons possibles. Notre question semi-formelle sur la censure devient alors "existe-t-il un ordre valide sur lequel f évalue à 0" ? Si un tel ordre existe, alors le séquenceur peut le choisir.

À partir de là, nous pouvons étendre notre modèle pour tenir compte de l'inclusion forcée. « Existe-t-il un ordre valide, qui inclut le sous-ordre de l'utilisateur, pour lequel f évalue à 0 ? » Si un tel ordre existe, le séquenceur peut le sélectionner. L'inclusion forcée n'empêche pas le séquenceur d'exercer un contrôle sur l'ordre, elle ne fait que contraindre leur comportement. Malheureusement, l'inclusion forcée présente des problèmes fondamentaux qui l'empêchent d'être un mécanisme de résistance à la censure efficace pour de nombreuses transactions.

Le problème de la transmission

Les mécanismes d'inclusion forcée signifient que la commande se fait selon l'un des deux modes : non forcé ou forcé. Il existe un point défini à partir duquel la transition se fait du non forcé au forcé (et vice versa). Ce point est le transfert. Le transfert pose un problème épineux pour la conception des mécanismes d'inclusion forcée.

Il doit y avoir un passage de l'inclusion non forcée à l'inclusion forcée.

La transaction forcée s'exécute sur l'état lors de la remise. Donc encore une fois, la résistance de l'état⁵montre sa vilaine tête. Lorsque le transfert a lieu au sein d'un lot de transactions (comme un bloc), le créateur du lot peut exercer un contrôle sur l'état au moment du transfert. Si la transaction d'inclusion forcée lit un état public, alors le créateur du lot peut réécrire cet état avant et après l'exécution de la transaction forcée. La contention est suffisante pour la censure.

Parce que le créateur du lot peut exercer un contrôle sur l'état lors de la remise, il peut donc influencer le résultat de la transaction forcée. S'il peut influencer le résultat, il peut potentiellement affecter le résultat du prédicat de notation. Par exemple, considérons une interaction AMM simple. L'utilisateur définit un prix minimum acceptable, cependant, le créateur du lot peut s'assurer qu'au point de remise, le prix du marché est inférieur au prix minimum acceptable. Cela provoque l'annulation de la transaction de l'utilisateur, censurant ainsi effectivement l'utilisateur.⁶⁷

Curieusement, la censure par le biais de la contestation étatique est plus efficace que la censure par l'exclusion. Une transaction exclue peut être incluse dans des blocs futurs. Une transaction censurée par la contestation est définitivement invalidée. Elle a été incluse dans la chaîne et ne peut jamais être incluse à nouveau. Cette transaction ne peut jamais atteindre l'objectif de l'utilisateur. Pour réessayer, l'utilisateur doit recréer et soumettre à nouveau la transaction (qui peut alors être éventuellement censurée à nouveau).

Dans les systèmes pratiques

[A]ny user can bypass the Sequencer entirely to submit any Arbitrum transaction (including one that, say, initiates an L2 to L1 message to withdraw funds) directly from layer 1. Thus [sic] mechanism thereby preserves résistance à la censure even if the Sequencer is being completely unresponsive or even malicious.

• Arbitrum

Dans le modèle de séquençage de run-ahead, le séquenceur a un contrôle quasi parfait sur l'emplacement de la remise dans la séquence et paie des frais réduits (car il n'a pas besoin de donner un pourboire et peut exercer un certain contrôle sur le basefee EIP-1559). En conséquence, le séquenceur est dans une position privilégiée pour utiliser la contention d'état afin de censurer les actions des utilisateurs. C'est trivial. Le problème de remise assure que le séquenceur peut censurer de grandes classes de transactions.

Pour l'EIP-7547, les constructeurs choisissent l'endroit où les transferts de main ont lieu dans le bloc.⁸En conséquence, le constructeur est capable de choisir l'emplacement de la remise dans le bloc. Cela signifie qu'il peut sélectionner un préfixe et un postfixe à volonté,⁹tant qu'ils respectent les règles de gaz de bloc. Le préfixe peut mettre la chaîne dans un état sur lequel la transaction va revenir, tandis que le postfixe restaurera la chaîne à un état normal. Les listes d'inclusion EIP-7547 ne sont pas suffisantes pour empêcher la censure pour toute transaction accédant à un état controversé. Le problème du transfert empêche les IL d'assurer l'exécution de la transaction dans la plupart des cas.

L'inclusion forcée est inefficace pour protéger les utilisateurs de la censure pour la plupart des utilisations non triviales de la blockchain. Le problème de la remise en main propre garantit que le censeur a une discrétion suffisante sur l'état même s'il n'a pas suffisamment de discrétion sur l'ordre. Ce problème affecte les AMM, les marchés de prêt, les enchères et la plupart des autres actions DeFi. De nombreuses actions importantes sont censurables même si vous pouvez garantir l'inclusion de la transaction. La contention de l'état crée des limites strictes sur l'efficacité de l'inclusion forcée en tant que mécanisme de résistance à la censure.

Étude de cas

Pour voir les effets de cette situation, prenons l’exemple d’un utilisateur qui prête des USDC sur un marché de prêt sur Optimism. Lorsque l’utilisateur souhaite retirer des USDC du marché, il soumet une transaction Optimism, que le séquenceur censure. Ils utilisent ensuite le mécanisme officiel d’inclusion forcée pour mettre en file d’attente leur transaction sur Ethereum, en contournant le séquenceur.

Le séquenceur peut voir cette transaction dans la file d'attente et peut choisir de la bloquer. Pour censurer la transaction, le séquenceur emprunte tout le USDC disponible sur le marché juste avant la transaction forcée. Étant donné que le marché n'a plus de liquidité, la transaction forcée est annulée. Le séquenceur peut ensuite rembourser immédiatement le USDC.

Le séquenceur ou le constructeur peut manipuler l'état lors de la remise.

Cela nécessite que le séquenceur dispose d'un collatéral suffisant pour emprunter l'USDC, mais cela n'impose qu'un coût d'emprunt extrêmement faible.¹⁰De plus, le collatéral est réutilisable pour toute censure, car l'emprunt n'est jamais maintenu ouvert. Par conséquent, un utilisateur d'AAVE ou Compound sur Optimism (ou Arbitrum ou tout autre rollup séquentiel centralisé) n'a aucune garantie qu'il pourra jamais retirer le collatéral. Le séquenceur peut censurer tout retrait de n'importe quel marché de prêt à tout moment. L'inclusion forcée n'est tout simplement pas suffisante pour protéger les utilisateurs contre la censure.

Travail de suivi

Nous avons quelques domaines de recherche à suivre.

Tout d'abord, l'EIP-7547 peut être amélioré de manière anodine en exigeant que les transactions IL soient traitées à la fin du bloc suivant. Dans le contexte de l'enchère PBS, la censure est le MEV. Le constructeur tire une certaine valeur non économique, à laquelle il doit attribuer une valeur subjective exprimée en ETH. La censure par le constructeur entraîne donc une augmentation de l'offre de bloc du constructeur.¹¹Cela s'étend aux chercheurs, qui peuvent créer des groupes de censure. Une partie de la valeur économique de la censure est alors capturée par le proposant, ce qui crée une incitation à tolérer la censure même lorsque l'on n'y participe pas directement. Placer les transactions d'inclusion forcée à la fin du bloc supprime la capacité du constructeur de bloc à facilement insérer les transactions IL, et augmente le coût économique de la censure conflictuelle. Par exemple, censurer une interaction AMM via une contention d'état pourrait nécessiter de renoncer à certaines opportunités d'arbitrage AMM ou à un coût élevé pour pousser le marché hors de portée, ce qui ne peut être récupéré en fermant le sandwich. De plus, cela limiterait les groupes de censure produits par les chercheurs (plutôt que les constructeurs) à un par bloc.¹²Nous recommandons une exécution de haut de bloc, car le préfixe est plus significatif que le suffixe, cependant cela augmenterait considérablement le coût d'une transaction IL, car cela permettrait l'extraction de MEV de haut de bloc via l'inclusion forcée.¹³Supprimer le droit du censeur de postfixe atomiquement les transactions IL est une petite amélioration.

Deuxièmement, le problème de remise existe car le censeur peut regarder en avant via la simulation de transaction et exercer un contrôle sur l'état d'entrée. De nombreux mécanismes de résistance aux MEV introduisent des informations cachées pour supprimer la capacité du censeur à déduire des informations sur les objectifs des utilisateurs et à simuler des résultats. Ce sont généralement des schémas de commit-reveal, où certaines informations de transaction sont privées jusqu'après l'ordonnancement. La séparation ordonnancement-exécution et l'information cachée semblent prometteuses, mais sont largement incompatibles avec la chaîne d'approvisionnement MEV, les processus de consensus Ethereum et le modèle rollup séquencé. Une façon de neGate la capacité de simuler des transactions résoudrait la censure et de grandes classes de MEV, mais serait extrêmement invasive pour le protocole, les opérateurs du protocole, les applications et l'utilisateur final.

Troisièmement, il existe une classe intéressante de fonctions de notation « indépendantes de l’ordre ». Ce sont des objectifs qui ne peuvent pas être censurés par la contention de l’État, soit parce qu’ils n’accèdent pas à l’État litigieux, soit parce que l’État litigieux auquel ils accèdent a suffisamment de contraintes pour le rendre « fiable » dans un certain sens. Les actions indépendantes de l’ordre incluent l’envoi d’ETH à un EOA, la plupart des envois ERC-20,¹⁴et certaines interactions DeFi comme l'ajout de garantie à un marché. Ces actions sont protégées contre la censure par le biais de la contention. Cette classe d'objectifs a également des correspondances intéressantes dans la communication sécurisée entre chaînes et la résistance aux MEV, et mérite une étude plus approfondie. Dans certains cas, des applications et des protocoles peuvent être conçus pour n'inclure que des actions indépendantes de l'ordre, mais des études supplémentaires sont nécessaires.

Conclusion

L’état riche permet aux acteurs malveillants de censurer les transactions tout en les incluant. Le problème du transfert est fondamental pour les mécanismes d’inclusion forcée et ne peut qu’être atténué. Dans les cumuls séquencés de manière centralisée, aucune atténuation n’est possible. L’inclusion forcée ne peut pas résoudre la censure en présence d’un État litigieux. De grandes catégories de transactions économiquement importantes peuvent être censurées, même si elles sont incluses par la force. Le problème du transfert est endémique dans les rollups modernes et présent dans les EIP de résistance à la censure d’Ethereum. En conséquence, l’inclusion forcée, bien que bénéfique, n’est jamais suffisante pour fournir une résistance à la censure pour les chaînes des États riches. Les rollups n’héritent pas des propriétés de sécurité d’Ethereum et il est stupide de suggérer qu’ils le font. Lorsque vous cessez d’être obsédé par l’inclusion, il devient évident que la résistance à la censure est un cas particulier de résistance MEV.

Nous tenons à remercier Mike Neuder, Tarun Chitra, et Brandon Curtispour examen et commentaires.

1

Comme d'habitude, pour les L1, cela est accompli en rejetant les blocs invalides, tandis que dans les rollups, cela est accompli en coercitant les séquences invalides en séquences valides via une fonction de filtrage.

2

Ce n’est pas un article sur les intentions, le monde n’en a pas besoin de plus à ce stade.

3

Il s'agit clairement d'un modèle incomplet, car il ne tient pas compte des valeurs subjectives des résultats. Par exemple, le censeur peut perdre n'importe quelle somme d'argent si la censure échoue (par exemple, s'ils risquent d'être arrêtés par la police française s'ils ne censurent pas certains comportements). D'autre part, l'utilisateur peut gagner/perdre n'importe quelle somme d'argent si son objectif n'est pas atteint dans un délai précis (par exemple, s'ils ont pris plus de 100 millions de dollars de prêts contre leur propre jeton et doivent re-collatéraliser la position avant d'être liquidés).

4

Contrairement à un modèle de séquenceur “basé”. Dans la plupart des rollups modernes, le séquenceur “avance” Ethereum en fournissant des attestations d'inclusion et d'exécution pour une transaction avant que la transaction ne soit confirmée sur Ethereum. Dans ce modèle, le séquenceur a un contrôle total sur la séquence, et le résultat de la transaction doit être indépendant des réorganisations d'Ethereum.

5

Lorsque plusieurs utilisateurs veulent accéder au même contrat, au même actif ou au même état, leurs transactions sont « en concurrence » les unes avec les autres et peuvent interférer avec les résultats des autres. La controverse peut survenir par coïncidence ou délibérément. Il s’agit d’un problème insoluble de l’état riche dans les systèmes blockchain. L’accès du public à l’État partagé est à l’origine de la MEV, des problèmes d’évolutivité et du déclin de la civilité dans la société moderne.

6

En général, vous devriez considérer la résistance à la censure via l'état comme un cas spécial de MEV. Étant donné que la valeur extraite est hors chaîne, non observable et potentiellement très importante, il peut être difficile de prédire quand la résistance à la censure via l'état se produira.

7

Nous avons spécifiquement couvert l'utilisation de la contention d'état pour annuler les transactions dans notre article de 2017 «Les mineurs ne sont pas vos amis”. À l'époque, le terme « MEV » n'était pas encore utilisé.

8

Il est bien connu que PBS complique considérablement la résistance à la censure. Voir VB’s@vbuterin/pbs_censorship_resistance">note de recherche.

9

Le préfixe et le postfixe d’une transaction sont communément appelés « sandwich » et sont bien compris comme une méthode d’utilisation de la contention d’état pour extraire le MEV.

10

L'emprunt ne dure que quelques secondes, voire moins. Les séquenceurs Rollup peuvent parfois conserver des horodatages ou des limites de bloc pour rendre le temps d'emprunt effectif à 0.

11

Le constructeur sera prêt à payer jusqu’à sa valeur subjective de censure, poussant potentiellement l’enchère au-dessus de la valeur extractible objectivement observable du bloc. Dans les cas extrêmes, cela peut entraîner des cas où le censeur a une variation négative du solde d’ETH (c’est-à-dire qu’il paie plus d’ETH pour produire le bloc qu’il n’en reçoit en frais et récompenses).

12

Notez que cela repose sur les règles d'enchères de MEV empêchant l'intercalation de transactions provenant de différents bundles et ne permettant pas les transactions "doivent être annulées". Si ces règles étaient assouplies pour permettre l'intercalation des transactions de bundle, et/ou si les constructeurs commençaient à prendre en charge les blocs "doivent être annulés" dans les bundles, la protection disparaîtrait. Cette dynamique se produit parce que si les transactions IL doivent être à la fin du bloc, aucune transaction non forcée ne peut être intercalée, et donc au plus un bundle de censure de chercheur pourrait se produire.

13

Permettant efficacement au constructeur de créer des bundles inter-blocs limités. Les systèmes de pré-consensus comme FOCIL (en anglais seulement)pourrait atténuer cela.

14

Pour un jeton ERC-20 standard, l'appel de transfert n'est généralement pas soumis à la censure par le biais de la contention, car les tiers ne peuvent pas diminuer le solde de l'utilisateur. Cependant, prenez en compte un appel transferFrom. Si le transféreur approuvé est un contrat qui permet la contention sur son propre état, alors l'action peut être soumise à la censure via cette contention (consommant l'approbation requise pour le transferFrom d'une manière non intentionnelle).

Démenti:

1. Cet article est repris de [ la technologie], Tous les droits d'auteur appartiennent à l'auteur original [init4]. Si vous avez des objections à cette réimpression, veuillez contacter le Gate Learnl'équipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent pas de conseils 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, de distribuer ou de plagier les articles traduits.