Aller au contenu
Financial Context Wiki

résistance à la censure

La résistance à la censure est un concept important dans les concepts de base et les limites institutionnelles de la cryptomonnaie. Cet article explique sa définition, ses principes de fonctionnement, ses formules de base, ses cas réels, ses limites de risque et ses malentendus courants pour aider les utilisateurs à comprendre le mécanisme en chaîne au lieu de simplement mémoriser les termes.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

La résistance à la censure est la capacité d’un réseau à maintenir une transaction valide accessible et éligible à une éventuelle inclusion même lorsque des passerelles, des pairs, des constructeurs ou des producteurs de blocs particuliers la refusent. Il s’agit d’un certain degré de résilience, et non d’une promesse selon laquelle chaque transaction entre dans le bloc suivant ou que chaque fournisseur d’accès doit servir chaque utilisateur.

La revendication doit nommer la couche, l’acteur et la fenêtre temporelle. Une chaîne de base peut résister à une censure soutenue des transactions tandis qu’un portefeuille, une interface, un point de terminaison RPC, un échange ou un séquenceur de cumul bloque l’accès immédiatement. Une transaction peut également être retardée pour des raisons non censurées telles qu’une signature invalide, une mauvaise occasion, un solde insuffisant, des frais inférieurs à la politique de relais local ou une concurrence pour un espace de bloc limité.

Comment ça marche

Suivez une transaction signée à travers des étapes distinctes :

  1. Création et soumission. Le portefeuille construit et signe une transaction, puis l’envoie via un fournisseur RPC, une route privée ou le réseau peer-to-peer. Une passerelle peut le refuser sans changer le protocole de base.
  2. Admission et propagation. Les nœuds vérifient la validité du consensus et leur propre politique de pool de mémoire ou de relais. Une transaction peut être valide par consensus mais non relayée par un nœud particulier. Plusieurs pairs indépendants et chemins de soumission réduisent la dépendance à l’égard d’un seul contrôleur d’accès.
  3. Construction et proposition de blocs. Un mineur, un validateur, un séquenceur ou un constructeur externe choisit les transactions et leur ordre. Les producteurs tournants ne rendent temporaire le refus d’un acteur que si une part significative des producteurs ultérieurs peuvent voir et inclure la transaction.
  4. Validation et choix de fork. D’autres nœuds rejettent les blocs invalides et décident quelle branche valide est canonique. La validation indépendante empêche un producteur de valider une transaction invalide, mais elle ne l’oblige normalement pas à inclure une transaction valide particulière.
  5. Confirmation ou caractère définitif. L’inclusion n’est pas la même chose qu’un règlement durable. Les réorganisations peuvent supprimer une inclusion récente ; la règle de confirmation ou de finalité pertinente est spécifique à la chaîne.

Mesurez les résultats au lieu d’attribuer une étiquette binaire. Pour une transaction largement disponible pour la première fois chez t_seen et incluse chez t_included :

inclusion delay = t_included - t_seen

Comparez ce délai avec des transactions de même prix et de même complexité dans la même fenêtre de congestion. Une autre mesure utile est :

eligible inclusion rate = included eligible transactions / observed eligible transactions

« Éligible » doit indiquer les règles de validité, de nonce, de solde, de frais, de gaz ou de poids, de calendrier et de capacité. Dans le cas contraire, la sélection ordinaire des tarifs ou la congestion peuvent être confondues avec une censure sélective.

La résistance dépend de la diversité des domaines de défaillance : pairs, RPC, opérateurs autonomes, pools, clients, constructeurs, relais, séquenceurs, fournisseurs d’hébergement et juridictions. Le nombre brut de nœuds peut induire en erreur, car de nombreux nœuds ou clés de validation peuvent partager un même contrôleur. Les parcours d’inclusion forcée ou les listes d’inclusion peuvent renforcer les garanties, mais leur statut et leurs conditions de déploiement sont importants. EIP-7805, par exemple, est une proposition et ne constitue pas une garantie Ethereum actuellement déployée.

Exemple

Supposons qu’une transaction valide atteigne le réseau public à la hauteur de bloc 840,000. Il propose des frais compétitifs, s’inscrit dans chaque bloc suivant et reste valable. Trois producteurs l’omettent ; le quatrième l’inclut à la hauteur 840,004.

  • Le retard observé est de 4 blocks par rapport au point de départ indiqué.
  • Trois omissions ne prouvent pas à elles seules la coordination ; les commandes, la propagation et la politique des producteurs nécessitent une enquête.
  • L’inclusion d’un quatrième producteur indépendant montre que les premiers producteurs ne disposaient pas d’un droit de veto total.
  • Si les producteurs contrôlant les opportunités 90% appliquent le même filtre, un modèle simplifié à créneau indépendant donne la probabilité d’inclusion par créneau 1 - 0.90 = 10% et l’attente attendue 1 / 0.10 = 10 slots. Un contrôle corrélé et des règles de sélection réelles peuvent invalider ce modèle.

Pour documenter une censure présumée, préservez la transaction ou l’identifiant signé, les premières observations provenant de nœuds indépendants, les contrôles de frais et de validité, les politiques de pool de mémoire, le contenu du bloc, l’attribution du producteur et les transactions comparables. Une erreur RPC ou une entrée d’explorateur manquante ne suffit pas.

Risques

  • Faux positifs : une invalidité, un nom occasionnel périmé, des fonds insuffisants, une politique de frais, une capacité ou une mauvaise propagation peuvent ressembler à de la censure.
  • Ordre concentré : un pool, un constructeur, un relais ou un séquenceur dominant peut transformer le filtrage sélectif en longs délais.
  • Censure au niveau de l’accès : les domaines, les magasins d’applications, les frontends, les portefeuilles et les fournisseurs RPC peuvent bloquer l’accès pratique tandis que l’accès direct au protocole reste possible.
  • Infrastructure corrélée : des points de terminaison d’apparence distincte peuvent partager une exposition d’opérateur, de cloud, de client, de relais ou juridique.
  • Fuite de confidentialité : la rediffusion via de nombreux services peut améliorer la portée tout en exposant l’adresse IP, la synchronisation et les liens de transaction.
  • Faibles voies d’évacuation : l’inclusion forcée peut entraîner des frais, des cautions, des retards, des fenêtres, des exigences en matière de données ou des contrôles privilégiés.
  • Risque de réorganisation et de gouvernance : l’inclusion peut ne pas être définitive, et les mises à niveau ou les pouvoirs d’urgence peuvent modifier les hypothèses.

Utilisez des chemins véritablement indépendants lorsque cela est possible. Ne partagez jamais de phrases de départ ou de clés privées avec un service RPC, relais ou « anti-censure », et ne remplacez ou ne rediffusez pas une transaction sans comprendre les règles de nonce et de frais.

Idées fausses courantes

  • « Valide signifie inclusion garantie. » La validité crée l’éligibilité ; les producteurs sélectionnent toujours les transactions à moins qu’une règle plus stricte ne s’applique.
  • « Décentralisé signifie non censurable. » La concentration peut rester dans la production, les constructeurs, les relais, les RPC, les frontends ou la gouvernance.
  • « Un RPC bloqué prouve une censure en chaîne. » Cela prouve qu’un chemin d’accès a échoué ou a refusé la demande, et non un veto à l’échelle du réseau.
  • « Des frais élevés annulent tous les filtres. » Des frais compétitifs visent un ordre économique, et non un filtre explicite.
  • « Une éventuelle inclusion suffit. » L’inclusion après un délai opérationnel peut s’avérer inutile ; la fenêtre temporelle appartient à la réclamation.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...