Améliorer les délais via la détection de censure - Censorship.wtf

Les délais des protocoles (1:20)

Ethereum présente une certaine résistance à la censure, mais possède toujours des délais de censure non idéaux dans les pires scénarios

La détection de censure peut améliorer le délai même si la prévention de la censure n'est pas parfaite. Être capable de détecter la censure on-chain permet aux protocoles d'échéance d'être plus efficaces.

Le délai implique que les parties prenantes doivent avoir assez de temps pour agir, sinon elles sont désavantagées. Des exemples sont les enchères on-chain, les protocoles interactifs avec des valeurs par défaut en l'absence d'action, les preuves de fraude et les rollups optimistes, ainsi que les mécanismes de veto dans les sidechains

Si les parties honnêtes ne peuvent pas respecter un délai à cause de la censure, le système fonctionne moins bien.

La détection de censure permet aux protocoles d'échéance de tenir compte d'une censure potentielle plutôt que de supposer que les parties peuvent toujours respecter les délais.

Modèle de menace (2:45)

Le modèle de menace implique un adversaire ciblant un protocole d'échéance spécifique pour censurer certaines transactions.

L'adversaire vise à compromettre les proposeurs/constructeurs de blocs Ethereum en prenant leur place, en les payant ou en les attaquant.

Le but est de contrôler une fraction de l'activité de proposition/construction, et le motif est un gain financier en corrompant le fonctionnement du protocole d'échéance.

Exemples : Dans une enchère, faire une faible offre et censurer les offres plus élevées. Dans un rollup optimiste, faire une fausse réclamation et censurer les désaccords.

Principales hypothèses :

• L'adversaire cible un protocole de délai spécifique
• Il tente de compromettre/contrôler les proposeurs/constructeurs de blocs Ethereum
• Il cherche à obtenir un gain financier en censurant des transactions pour corrompre le protocole de délai

Réponses courantes (4:30)

Dans les protocoles à faible enjeu, nous pouvons ignorer le problème de censure ou allonger les délais. Cela peut être rationnel si une attaque est improbable ou si l'arbitrage favorise la réactivité.

Dans les protocoles à enjeux élevés, il ne suffit plus de faire des délais plus longs ou d'ignorer le problème.

L'approche habituelle consiste à rendre le délai plus long que le pire délai de censure supposé.

Sur Arbitrum, la challenge period (délai au cours duquel on peut soumettre une preuve de fraude) est de 7 jours, car c'est le pire délai de censure supposé sur Ethereum qui ne déclencherait pas de réponse sociale.

7 jours est un délai trop long, mais nécessaire dans le cas d'Arbitrum où des milliards pourraient être volés via une attaque de censure.

L'objectif est d'améliorer les protocoles à fort enjeu en détectant la censure, plutôt que de simplement supposer le pire cas de censure et avoir des délais très longs.

Idée clé (6:40)

L'idée principale est de concevoir un test de censure sur la chaîne Ethereum avec une erreur à sens unique.

Le test peut dire "pas de censure significative" ou "peut-être une censure". Il est conçu pour avoir une confiance statistique lorsqu'il déclare qu'il n'y a pas de censure.

Dans un protocole de délai, le délai peut être raccourci si le test ne détecte pas de censure. Par exemple, un délai normal de 7 jours pourrait devenir 3 heures si le test ne montre aucune censure pendant 3 heures.

Il n'est pas possible de détecter définitivement la censure, mais il est possible de détecter une absence de censure. Cela permet aux protocoles de raccourcir dynamiquement les délais lorsqu'aucune censure n'est détectée.

Attaques de censure sur Ethereum (8:30)

Il existe deux niveaux d'attaques de censure sur Ethereum :

1. Censure faible - Les proposeurs de blocs refusent d'inclure les transactions ciblées
2. Censure forte - Les blocs avec les transactions ciblées sont rejetés ou réorganisés

La censure faible peut être vaincue tant que certains proposeurs sont honnêtes. La censure forte peut soutenir les attaques si l'attaquant contrôle suffisamment de pouvoir de proposition/construction.

Vaincre la censure faible (9:55)

Supposons :

• Une fraction f des proposeurs est honnête et inclura une transaction cible
• x = nombre de slots honnêtes sur n slots au total
• La probabilité que x ≤ k suit une distribution binomiale basée sur f

Cela le modélise comme un tirage à pile ou face pondéré avec une probabilité f d'être honnête.

Ainsi, avec suffisamment de proposeurs honnêtes, la censure faible peut être statistiquement vaincue, mais la censure forte est plus difficile à surmonter si l'attaquant a beaucoup de contrôle.

Censure forte (11:25)

La censure forte implique la suppression de blocs produits honnêtement, en supposant que l'adversaire contrôle suffisamment de pouvoir en tant que proposeur.

Pour une attaque réussie, l'adversaire doit transformer chaque slot honnête en slot vide dans la chaîne canonique. Par conséquent, si une attaque a réussi, le nombre de slots honnêtes ≤ nombre de slots vides.

Nous pouvons mesurer les slots vides sur la chaîne en regardant les avancées des horodatages et le nombre de blocs ajoutés :

• Soit x = slots honnêtes
• y = slots vides sur n slots au total.
• Si une attaque s'est produite, P(y < k) ≤ P(x ≤ k) sur la base de la fraction f de proposeurs honnêtes.

Cela permet un test statistique on-chain pour savoir si une censure forte s'est produite en comparant les slots vides à la distribution binomiale.

Si le nombre de slots vides est statistiquement bien inférieur à celui attendu sans attaque, nous pouvons conclure qu'aucune attaque forte ne s'est produite récemment.

En pratique (14:30)

Si nous pouvons rejeter l'hypothèse d'attaque avec une confiance extrêmement élevée (par exemple p < 10^-6), le test peut conclure à l'absence de censure.

Étant donné k slots vides sur n slots au total, et une fraction f supposée de proposeurs honnêtes, nous pouvons vérifier si l'inégalité est respectée.

Pour la mise en œuvre :

• Choisir les paramètres f, k, n à l'avance
• Précalculer la somme binomiale hors ligne
• Construire un test simple on-chain pour vérifier si k et n satisfont l'inégalité

Exemple avec 10% de proposeurs honnêtes : Pas de censure si ≤ 34 slots vides sur 688 slots au total (2h 18min), ou si ≤ 4 slots vides sur 225 slots au total (45 min)

En testant sur l'ensemble des blocs d'Ethereum créés depuis le Merge, ces tests auraient toujours été validés.

Quelques problèmes ennuyeux (16:15)

Problème 1 : L'adversaire peut connaître les 64 prochains proposeurs et ainsi attendre pour attaquer

Atténuation : Ajouter 64 slots vides au début de la période de test, en supposant que l'adversaire ne peut pas arranger l'absence de slots vides dans les 64 premiers.

Problème 2 : Si le test échoue, on peut le refaire sur les n blocs suivants

Atténuation : Définir le niveau de confiance pour chaque test à epsilon/r en faisant jusqu'à r répétitions, ou définir un budget epsilon total et le dépenser sur les répétitions.

Le but de cette atténuation est d'arrêter les tests en boucle, car les boucles compromettent la validité statistique du modèle.

Pour les rollups optimistes ou les side-chains, décider quelle valeur de f (fraction des validateurs Ethereum qui ne censurent pas) est sûre à supposer.

Déployer le contrat "oracle de censure" avec certaines valeurs câblées de n, k, f.

Mettre à jour le délai d'attente pour qu'il soit adaptatif, en fonction du résultat de l'oracle de censure.