Un élément technique important que j’ai oublié de mentionner est la proposition de passer de Casper FFG à Minimmit comme gadget de finalité. Pour résumer, Casper FFG offre une finalité en deux tours : il exige que chaque attesteur signe une première fois pour « justifier » le bloc, puis une deuxième fois pour le « finaliser ». Minimmit ne nécessite qu’un seul tour. En contrepartie, la tolérance aux pannes de Minimmit (dans notre paramétrisation) tombe à 17 %, contre 33 % pour Casper FFG. Dans les discussions sur le consensus d’Ethereum, j’ai toujours été le défenseur des hypothèses de sécurité : j’ai insisté pour atteindre la limite théorique de 49 % de tolérance aux pannes sous synchronie, poussé pour des gadgets de récupération après attaque de 51 %, et conçu DAS pour rendre les vérifications de disponibilité des données résistantes aux majorités malhonnêtes, etc. Mais je suis à l’aise avec les propriétés de Minimmit, voire enthousiaste à certains égards. Dans ce message, je vais expliquer pourquoi. Définissons exactement les propriétés de sécurité du 3SF (pas la chaîne de balise actuelle, qui est inutilement faible à bien des égards, mais le 3SF idéal) et de Minimmit. « Réseau synchronisé » signifie « latence du réseau inférieure à environ 1/4 de slot », « réseau asynchrone » signifie « latence potentiellement très élevée, certains nœuds pouvant être hors ligne pendant des heures ». Les pourcentages (« attaquant a <33 % ») font référence aux pourcentages d’ETH staké actif. ## Propriétés du 3SF Cas réseau synchronisé : * Attaquant a p < 33 % : rien de mauvais ne se produit * 33 % < p < 50 % : l’attaquant peut arrêter la finalité (au prix de pertes massives de fonds via l’inactivité leak), mais la chaîne continue de progresser normalement * 50 % < p 67 % : l’attaquant peut finaliser à sa guise, il devient beaucoup plus difficile pour les bons acteurs d’effectuer un minority soft fork Cas réseau asynchrone : * Attaquant a p 33 % : peut annuler la finalité, au prix de pertes massives de fonds via slashing ## Propriétés de Minimmit Cas réseau synchronisé : * Attaquant a p < 17 % : rien de mauvais ne se produit * 17 % < p < 50 % : l’attaquant peut arrêter la finalité (au prix de pertes massives de fonds via l’inactivité leak), mais la chaîne continue de progresser normalement * 50 % < p 83 % : l’attaquant peut finaliser à sa guise, il devient beaucoup plus difficile pour les bons acteurs d’effectuer un minority soft fork Cas réseau asynchrone : * Attaquant a p 17 % : peut annuler la finalité, au prix de pertes massives de fonds via slashing Je pense en fait que ce dernier équilibre est meilleur. Voici mon raisonnement : * La pire forme d’attaque n’est pas en réalité la réversion de finalité, mais la censure. La raison en est que la réversion de finalité crée des preuves massives et publiquement disponibles permettant de coûter immédiatement des millions d’ETH à l’attaquant (c’est-à-dire des milliards de dollars), alors que la censure exige une coordination sociale pour y faire face. * Dans les deux cas, une attaque de censure nécessite 50 %. * Une attaque de censure devient *beaucoup plus difficile* à contourner lorsque l’attaquant censeur peut finaliser unilatéralement (c’est-à-dire >67 % dans le 3SF, >83 % dans Minimmit). S’il ne peut pas, alors si les bons acteurs contre-coordonnent, on obtient deux chaînes non-finalisées en conflit pendant plusieurs jours, et les utilisateurs peuvent choisir. S’il peut, alors il n’existe aucun point de Schelling naturel pour coordonner un soft fork. * Dans le cas d’un bogue logiciel, le pire scénario est la finalisation d’un élément buggé. Dans le 3SF, il suffit que 67 % des clients partagent le bogue pour qu’il soit finalisé ; dans Minimmit, il faut 83 %. En somme, Minimmit maximise les situations où « il se produit deux chaînes en conflit », ce qui est en réalité un résultat bien plus sain et beaucoup plus réparable que « la mauvaise chose est finalisée ». Nous voulons que la finalité signifie définitif. Ainsi, dans les situations d’incertitude (qu’il s’agisse d’attaques ou de bogues logiciels), nous devrions être plus à l’aise avec des périodes d’heures ou de jours où la chaîne ne finalise pas, mais progresse plutôt selon la règle de choix du fork. Cela nous donne le temps de réfléchir et de déterminer quelle chaîne est correcte. En outre, je pense que le « 33 % slashé pour annuler la finalité » du 3SF est excessif. S’il y a même 15 millions d’ETH stakés, cela représente 5 millions ($10 milliards) slashés pour annuler une fois la chaîne. Si vous avez $10 milliards et que vous êtes prêt à commettre des actes de vandalisme violant les lois informatiques de nombreux pays, il existe des moyens BEAUCOUP MEILLEURS de dépenser cet argent que d’attaquer une chaîne. Même si votre objectif est de briser Ethereum, il existe bien d’autres vecteurs d’attaque bien plus efficaces. Ainsi, si nous avons la garantie fondamentale d’au moins 17 % slashés pour annuler la finalité (ce que Minimmit fournit), nous devrions juger les deux systèmes à partir de ce point en fonction de leurs autres propriétés — où, pour les raisons que j’ai décrites ci-dessus, je pense que Minimmit performe mieux.