Article de foobar/The Variable publié sur https://0xfoobar.substack.com/p/ethereum-proof-of-stake, traduit par Jean Zundel

Pour Ethereum, le passage au PoS ou preuve d’enjeu représente un changement majeur, tellement fondamental et aux implications tellement profondes qu’il a fallu 5 ans pour mettre en œuvre le Merge, la fusion entre la couche d’exécution d’ETH1 et la couche de consensus d’ETH2. Exit le consensus Nakamoto, c’est un lointain dérivé du consensus dit «classique» (depuis les premiers travaux de Leslie Lamport et al.) qui a été choisi en l’augmentant entre autres d’un roulement des validateurs actifs choisis aléatoirement parmi toute la population des stakers, des «miseurs». Cet article analyse le fonctionnement du consensus d’ETH 2.0 dans le contexte du PoS (stricto sensu, PoS, PoW et PoA sont en fait des mécanismes anti-Sybil) et les parades contre les attaques possibles, ainsi que la controverse que ce choix engendre.

Bienvenue ! Dans cet article, nous allons nous plonger dans les domaines suivants :

• Description détaillée du modèle de consensus et de la preuve d’enjeu d’Ethereum ;
• Récupération après attaques malveillantes de la part de la preuve d’enjeu d’Ethereum ;
• Réfutation des arguments courants des anti-PoS ;
• Aspects pratiques : la preuve d’enjeu liquide, la gestion de votre propre nœud

Mécanismes de consensus : PoS, PoW, PoA

Un mécanisme de consensus définit la manière dont un réseau distribué de nœuds décide de l’état courant du réseau, des blocs qui se trouvent dans la chaîne ainsi que de leur ordre. La production de blocs est un terme générique qui décrit l’action de chercher dans la mempool pour récupérer les transactions qui s’y trouvent en attente, les ordonner en blocs et attacher le nouveau bloc à la blockchain existante. Il existe trois catégories courantes de mécanismes de consensus : la preuve d’enjeu, la preuve de travail et la preuve d’autorité.

1. PoW (Bitcoin) : preuve de travail, donne le pouvoir de production de blocs à celui qui utilise la plus grande puissance de calcul. Le protocole définit une fonction de hachage unidirectionnelle lourde en termes de calcul, telle que SHA-256, puis les mineurs s’affrontent pour trouver une entrée qui donne un résultat comportant de nombreux zéros.
2. PoA (Binance Smart Chain) : preuve d’autorité, mécanisme de liste blanche qui donne le pouvoir de production de blocs à quelques nœuds. C’est une blockchain autorisée typique, et rien de plus.
3. PoS (Ethereum, bientôt) : preuve d’enjeu, donne le pouvoir de production de blocs à quiconque bloque ses jetons natifs, ceci en proportion du nombre de jetons misés.

Implémentation d’Ethereum

Le PoS a été annoncée pour Ethereum il y a bien des années déjà, mais avec la beacon chain ou chaîne phare fonctionnant depuis 18 mois d’affilée et des merges ou fusions réussies sur plusieurs réseaux de test, l’implémentation initiale est quasiment finalisée. Je me concentrerai sur les spécificités du fonctionnement de la chaîne PoS en régime de croisière plutôt que de me perdre dans les détails de l’implémentation de la fusion.

Il y a environ 400 000 validateurs sur la beacon chain et vous pouvez suivre en direct les statistiques et les blocs ici. Un validateur fait référence à un dépôt spécifique de 32 eth dans le contrat de dépôt de la beacon chain sur le mainnet ; un utilisateur peut gérer plusieurs validateurs. Les retraits de blocs ne sont pas activés aujourd’hui, ni au moment de la Fusion, mais seront activés lors du hard fork Shanghai qui suivra. Un slot se produit toutes les 12 secondes, et un validateur et un seul est choisi au hasard pour soumettre un bloc dans le slot. Une époque (epoch) est composée de 32 slots, soit 6,4 minutes. Si un validateur est hors ligne et ne propose pas de bloc dans son slot, ce slot est laissé vide. Ainsi, les temps de bloc Ethereum passeront d’une distribution de Poisson avec un temps de bloc moyen de 13 secondes, à exactement 12 secondes avec des slots vides occasionnels. Le premier bloc de chaque époque est traité comme le bloc de contrôle.

Si un seul validateur propose un bloc dans chaque slot, que font les autres en attendant leur tour ? Ils créent des attestations, qui sont des votes signés décrivant ce qu’ils pensent être head (tête) actuelle de la chaîne, et des liens vers un bloc de contrôle parent. Comme les attestations sont signées de manière cryptographique par un validateur spécifique, les validateurs peuvent devoir rendre des comptes s’ils sont équivoques, s’ils votent pour deux blocs à la même hauteur. Les frais de communication et de stockage pour 400 000 attestations sont extrêmement élevés, de sorte qu’à chaque époque, chaque validateur n’est affecté qu’à l’attestation d’un seul emplacement. Les validateurs de chaque créneau sont affectés à des comités, qui sont des regroupements supplémentaires d’au moins 128 validateurs. Les agrégateurs combinent ensuite les signatures de plusieurs validateurs à l’aide d’une agrégation BLS avant de ne stocker que les données de synthèse dans le bloc.

L’aléa est généré par la RANDAO, une balise d’accumulation d’aléas (dans ce contexte, une balise, beacon, est un service) où les proposants de blocs révèlent une signature BLS du numéro de l’époque actuelle signée par la clé privée de leur validateur. Cela signifie qu’il y a très peu de choix pour l’aléa généré ; les validateurs peuvent soit contribuer une valeur unique vérifiable, soit voir leur bloc complètement ignoré. La signature de hachage est mélangée à la RANDAO de la chaîne par XOR, qui offre une amélioration supplémentaire marginale de la sécurité grâce à sa commutativité. Ben Edgington fournit plus de détails sur cette spécification.

Une supermajorité (2/3) de validateurs est nécessaire pour finaliser un bloc. En cas de partage du réseau à 50-50, les blocs cessent d’être finalisés et les récompenses d’attestation s’arrêtent. Les validateurs non participants laissent lentement fuiter de l’enjeu du fait de leur inactivité jusqu’à ce que les validateurs en ligne obtiennent à nouveau une supermajorité. Il s’agit du mécanisme «d’auto-réparation» qui permet à la fois la sécurité et la vitalité (liveness).

Les époques sont des groupes de 32 slots, et elles passent par trois étapes : proposée, justifiée, finalisée. Une fois qu’une supermajorité, soit les deux tiers des validateurs actuels, atteste une époque, celle-ci peut progresser. Les attestations sont liées à des paires de blocs de contrôle, l’un d’une époque précédente et l’autre de l’époque actuelle. Nous les désignons par une paire constituée du bloc source et du bloc cible. Un bloc est proposé par un seul validateur, et lorsqu’une supermajorité d’attestations le marque comme head, il est considéré comme justifié. Lorsqu’une supermajorité d’attestations marque une époque justifiée comme l’époque précédente, elle est considérée comme finalisée. C’est ainsi que les blocs d’une époque sont généralement finalisés une époque plus tard, soit 15 minutes au total.

Les transactions sont finalisées lorsqu’elles ne peuvent pas être réorganisées sans brûler une quantité importante d’ETH. Comme les deux tiers des validateurs ont attesté du bloc finalisé, deux tiers des validateurs devraient également attester d’un bloc différent à la même hauteur pour créer une époque finalisée distincte à la même hauteur. Ainsi, au moins un tiers des validateurs aurait fait preuve d’équivoque, de double vote incompatible. L’équivoque est punie par le slashing, la suppression de la totalité de la mise du validateur, de sorte que l’attaquant doit s’engager à détruire au moins un tiers de tous les ETH mis en jeu. Le coût de la réorganisation d’un bloc finalisé est de plusieurs milliards de dollars, même aux prix plancher actuels.

Un acteur malveillant pourrait également empêcher la finalisation en retenant les attestations de sorte que la supermajorité ne soit jamais atteinte. Lorsque la chaîne ne parvient pas à finaliser pendant 4 époques ou plus, les validateurs inactifs sont pénalisés par une inactivity leak, une fuite d’inactivité. Il s’agit de brûler lentement les soldes de l’ensemble des validateurs hors ligne jusqu’à ce que les validateurs en ligne aient à nouveau une supermajorité et puissent rétablir la vitalité. La récompense d’attestation est suspendue jusqu’à ce que la chaîne recommence à finaliser, afin de rendre la censure et les attaques par DoS plus coûteuses.

La mise en jeu exige un effort actif

Nombreux sont ceux qui ont une impression déformée du staking, de la mise en jeu, en raison de l’utilisation généreuse de ce terme dans la DeFi et les NFT. Dans beaucoup de ces protocoles, le staking signifie le dépôt de jetons dans un contrat de séquestre, réduisant ainsi la liquidité du côté de la vente pendant que les jetons restent passifs. Il n’y a pas de risque de perte et pas de participation active, uniquement des rétributions pour les personnes ayant une faible préférence pour le temps. Voir le remarquable démontage de Cobie des raisons pour lesquelles ces structures sont finalement inutiles.

Pour être tout à fait clair, ces jeux n’ont rien à voir avec ce dont nous discutons. Un véritable enjeu au niveau du protocole implique un engagement avec des avantages et des inconvénients, qui nécessite une participation active et constante pour proposer de nouveaux blocs et attester les blocs créés par d’autres. Cela signifie que vous pouvez être récompensé pour une participation honnête avec un temps de fonctionnement élevé, ou que vous pouvez perdre de l’argent si vous vous déconnectez ou si vous soutenez un fork malveillant. Les règles ne sont pas appliquées de manière capricieuse par une entité centralisée ; elles sont clairement définies à l’avance et intégrées au cœur du protocole décentralisé lui-même.

Il existe deux règles clés d’équivoque qu’un validateur doit suivre, tirées de la spécification de Gasper :

1. Double vote – aucun validateur ne fait deux attestations distinctes pour le même bloc cible
2. Vote d’entourage – aucun validateur ne fait une attestation entourant ou entourée d’une attestation précédente.
3. Les clients honnêtes de la couche de consensus sont explicitement programmés pour ne jamais faire cela, de sorte qu’un utilisateur honnête normal ne devrait pas avoir à s’inquiéter du déclenchement de ces mécanismes. Pourtant, ils offrent une protection importante contre les validateurs malveillants et résolvent de manière élégante le problème du nothing-at-stake, du «rien à perdre» en raison de l’absence d’enjeu.

Si le slashing n’est appliqué qu’aux erreurs de commission, d’activité néfaste, il existe également des pénalités moins importantes appelées inactivity leaks, fuites d’inactivité, pour les erreurs d’omission. Les utilisateurs honnêtes doivent prêter une attention particulière au temps de fonctionnement de leur validateur, car un validateur hors ligne est pire que rien du tout. Si plus d’un tiers des validateurs sont hors ligne, les blocs ne peuvent pas être finalisés, et il devient plausible que ces nœuds hors ligne construisent en fait leur propre chaîne dans l’ombre en prétendant qu’une partition du réseau existe. Les pénalités de temps d’arrêt servent à éviter de telles situations.

Auto-guérison d’Ethereum contre les minorités perturbatrices

La combinaison de la réduction de l’équivoque, des fuites d’inactivité et des soft forks activés par les utilisateurs est très efficace. La réduction de l’équivoque traite les erreurs de sécurité, les fuites d’inactivité s’occupent des erreurs de vitalité, et les UASF (user activated soft forks) permettent même à une minorité honnête de se remettre d’une supermajorité malveillante.

On parle d’équivoque lorsqu’un validateur atteste deux blocs distincts à la même hauteur, ce qui a le potentiel de créer des fourches de chaînes parallèles et d’éventuels réorganisations. Il s’agit d’un élément clé du problème de l’absence d’enjeu (nothing-at-stake) qui consiste à construire sur toutes les bifurcations possibles parce que cela ne leur coûte rien. En recueillant des attestations signées, les chiens de garde du réseau peuvent en apporter la preuve quand cela se produit et détruire l’enjeu du responsable de l’équivoque.

On parle de fuite d’inactivité lorsqu’un validateur ne fournit pas d’attestation. On ne peut pas prouver qu’il s’agit d’un acte malveillant, car le validateur pourrait s’être accidentellement déconnecté, mais ce fait est dommageable pour le réseau.

On parle de soft forks activés par les utilisateurs lorsqu’un sous-ensemble de validateurs estime que la chaîne principale les ignore, eux et leurs transactions, et qu’ils se regroupent pour former leur propre fork (branche) de production de blocs.

Examinons quelques scénarios théoriques dans lesquels un sous-ensemble de validateurs malveillants souhaite censurer certaines transactions indésirables. Comment cela se passerait-il à divers niveaux de détention ?

Censure limitée des sous-minorités

Une baleine (whale ou gros détenteur) possédant 10% de l’éther mis en jeu veut censurer des transactions en refusant d’inclure celles provenant d’une liste noire dans les blocs qu’il propose. Ces transactions sont incluses dans les 90% restants des blocs. La baleine gagne un peu moins d’argent parce qu’elle laisse tomber certaines transactions de mempool très rémunératrices.

Censure agressive de la sous-minorité

Une baleine possédant 10 % de l’éther misé refuse d’inclure les transactions d’une liste noire dans ses propositions de blocs, et refuse également d’attester les autres blocs qui incluent ces transactions. Les blocs continuent à être finalisés parce qu’une supermajorité d’attestations soutient les blocs honnêtes. La baleine perd de l’argent à la fois sur les rétributions de transactions et les récompenses d’attestation manquées.

Censure limitée des minorités

Un cartel de baleines avec 40% de participation totale veut censurer les transactions, mais veut attester les blocs honnêtes proposés par les autres. Même chose que dans le cas de la censure limitée de la sous-minorité.

Censure agressive des minorités

Un cartel de baleines avec 40% de participation totale veut censurer les transactions, et refuse d’attester des blocs honnêtes. Les blocs cessent d’être finalisés car il n’y a plus de supermajorité honnête. La chaîne se divise en deux chaînes filles, comme s’il y avait eu une partition propre du réseau. Les validateurs honnêtes voient les deux bifurcations mais se basent sur la branche honnête car elle a plus de poids dans la règle de choix en cas de bifurcation de LMD-GHOST. Les validateurs censeurs verront également les deux branches mais passeront manuellement outre la règle de choix de la bifurcation de LMD-GHOST et choisiront de continuer sur la chaîne censurée, en prétendant qu’ils ne sont pas au courant de la chaîne honnête.

Sur la chaîne honnête, la fuite d’inactivité se déclencherait dès que les blocs cesseraient d’être finalisés. Cela signifie que tous les validateurs censeurs apparaîtraient comme hors ligne par leur refus d’attester les blocs honnêtes. Les validateurs censeurs verraient leur mise brûler lentement jusqu’à ce que leurs soldes tombent suffisamment bas pour qu’ils soient retirés de l’ensemble des validateurs. À ce moment-là, les validateurs honnêtes auraient maintenant une supermajorité et les blocs recommencent à être finalisés.

Notez que cela n’a pas nécessité un hard fork. Les pénalités et les fuites d’inactivité existantes éliminent progressivement les validateurs malveillants ou hors ligne de l’ensemble, et les autres peuvent retrouver une supermajorité sans que la chaîne ne s’arrête un instant.

Soft fork activé par les utilisateurs à partir d’une supermajorité malveillante

Nous avons vu que même si les validateurs honnêtes n’ont pas une supermajorité, en proposant des blocs honnêtes que les validateurs censeurs refusent d’attester, ces derniers seront évincés de l’ensemble des validateurs. Que se passe-t-il si les validateurs honnêtes ont une sous-majorité et les validateurs censeurs une supermajorité ?

Il est intéressant de noter que les mécanismes sont presque identiques ! La principale différence réside dans le fait que les validateurs honnêtes doivent se regrouper explicitement pour reconnaître leurs attestations respectives et passer outre la règle du choix de la branche, mais à part cela, ils peuvent former leur propre chaîne fille et la supermajorité malveillante élimine lentement les enjeux de l’ensemble des validateurs jusqu’à ce que la sous-minorité honnête retrouve une supermajorité.

Une fois de plus, il convient de noter qu’aucun changement explicite au niveau du protocole n’a été effectué pour détourner explicitement les jetons de certains utilisateurs, comme nous l’avons vu dans l’attaque de The DAO en 2016. C’est plutôt la combinaison de l’élimination des enjeux des validateurs équivoques, d’une part, et des fuites d’inactivité, d’autre part, qui fait que les validateurs qui ne construisent pas sur la même chaîne perdent progressivement leur mise. C’est un mécanisme assez élégant qui permet à une minorité honnête de se remettre d’une majorité malveillante.

Améliorations possibles d’Ethereum

Bien sûr, le PoS d’Ethereum peut encore être amélioré dans plusieurs domaines. Par exemple :

• La finalité en un seul slot consiste à réduire le temps de finalité de 2 époques (64 blocs) à 1 bloc ;
• La réduction du montant minimum nécessaire pour miser rendrait la participation en personne à l’enjeu plus viable pour les utilisateurs qui n’ont pas 32 ETH ;
• L’élection d’un leader secret unique minimiserait les potentielles attaques par DoS contre les proposants de blocs lorsque leur adresse est connue à l’avance ;
• La séparation des proposants et des constructeurs lors de la construction des blocs permettrait aux particuliers d’atteindre facilement le même rendement maximal que les grandes exploitations.

Principaux malentendus

PoS = Gouvernance onchain

Ethereum n’a pas de gouvernance onchain, intégrée au protocole de base, même si un sous-ensemble de protocoles PoS en a une. Tout comme les nœuds complets de Bitcoin font en sorte que les mineurs restent honnêtes pour produire des blocs valides conformes à la fonction de transition d’état, les nœuds complets d’Ethereum font en sorte que les validateurs restent honnêtes pour produire des blocs valides conformes à la fonction de transition d’état. Même une supermajorité de validateurs malveillants ne peut pas tromper un nœud complet honnête.

Les mécanismes de consensus permettent d’ajouter de nouvelles transactions à la chaîne, et n’ont pas le pouvoir de contraindre arbitrairement l’état de la blockchain. Les règles de transition d’état sont codées dans le protocole lui-même et restent inviolables à moins que la couche sociale ne crée elle-même un fork. L’un des invariants de transition d’état du Bitcoin est que la somme des sorties d’UTXO doit être égale aux entrées ; l’un des invariants de transition d’état d’Ethereum est qu’un compte ne peut déplacer que son propre Ether. Ni les mineurs ni les stakers (miseurs) ne peuvent enfreindre ces règles, même avec une supermajorité, tant que les non-validateurs font tourner leurs propres nœuds sur le réseau pour vérifier les transitions d’état honnêtes.

PoS = Banque centrale

Ce que les gens entendent par là n’est pas clair. Je pense qu’il s’agit d’une référence à la manipulation par la planification centrale de facteurs macroéconomiques tels que la masse monétaire et les taux d’intérêt. Comme on l’a mentionné ci-dessus, les validateurs n’ont pas la capacité de changer la fonction de transition d’état et les changements de mécanisme d’Ethereum sont longuement débattus en public des mois, voire des années à l’avance. La gouvernance est hors chaîne, au niveau de la couche sociale, et non sur la chaîne. Les validateurs n’ont aucun pouvoir ici.

PoS = Passage à l’échelle pour abaisser le prix du gaz

C’est faux. Les prix du gaz reflètent l’offre et la demande d’espace dans les blocs. La modification du mécanisme de consensus n’augmente pas l’offre d’espace de blocs, mais le sharding ou fragmentation pourrait le faire. La fragmentation était à l’origine une partie importante de la feuille de route d’Ethereum, mais a ensuite été reléguée au second plan et ne sera pas réalisée avant un certain temps après la fusion. Consultez les notes sur le proto-danksharding pour suivre l’état actuel des plans sur la disponibilité des données.

PoS = les riches deviennent plus riches, PoW = égalitaire

L’idée de CPU, de GPU et d’ASIC qui s’affrontent dans une compétition mathématique pour trouver le plus rapidement des préimages de hachage a une élégance égalitaire. Des individus souverains utilisant des ordinateurs personnels peuvent rivaliser avec des états-nations pour le droit de gagner 6,25 BTC fraîchement émis.

Malheureusement, les chaînes d’approvisionnement en ASIC sont facilement contrôlées par les réglementations en matière d’importation et d’exportation, sans parler de la dangereuse dépendance vis-à-vis de Taïwan. La nécessité d’une énergie abondante et bon marché est un autre point faible qui empêche les particuliers de mettre en place des installations minières discrètes. Et comme nous ne sommes pas encore entrés dans une utopie de post-pénurie, il faut un capital initial pour acheter des installations de minage. Pire encore, les progrès technologiques obligent les mineurs à mettre constamment à niveau leurs installations pour rester compétitifs, ce qui signifie que la dépendance à la chaîne d’approvisionnement est un point faible permanent si jamais les choses tournent mal.

Le PoW peut être considéré comme une instanciation spécifique du PoS, où les utilisateurs mettent du capital en jeu pour acheter des appareils de minage qui sont ensuite en concurrence pour les droits de proposition de blocs. Le capital mis en jeu peut être retiré à tout moment, mais sa valeur suit une courbe de décroissance correspondant à la valeur marchande actuelle des puces informatiques. La nécessité d’un capital initial est identique dans le PoW et le PoS, la principale différence étant que le capital est forcé de passer par une chaîne d’approvisionnement en puces informatiques dans le PoW, alors qu’il peut être purement misé dans le PoS.

PoS = Nothing-at-stake (absence d’enjeu)

Le PoS résout le problème de l’absence d’enjeu en pénalisant sévèrement les validateurs qui construisent sur deux blocs parents à la fois.

PoS = Pas de ventes forcées

On souligne souvent les faibles marges des mineurs de PoW en les comparant aux rendements élevés générés par les «miseurs». Cependant, les marchés sont efficaces et rien n’est gratuit dans la vie. Ce qui semble être de l’argent gratuit pour les stakers est en fait un coût d’opportunité important du capital, en choisissant de placer leur argent dans l’ETH plutôt que dans des milliers d’autres opportunités d’investissement, et un risque réel de dépréciation du capital. La même dynamique de marché qui conduit à de faibles marges par rapport à d’autres opportunités d’investissement avec l’extraction de BTC s’applique également aux faibles marges par rapport à d’autres opportunités d’investissement avec la mise en jeu d’ETH.

PoS = Les banques centrales achèteront tous les jetons.

Cela tend à venir de personnes qui n’ont jamais essayé de déplacer des carnets d’ordres de taille significative. Il est évident qu’on ne peut pas acheter toute l’offre au prix au comptant du moment, pas plus que l’on ne peut acheter tous les ASIC au prix au comptant du moment. Lorsque la demande augmente, le prix augmente de manière très convexe.

PoS = Faire confiance à un serveur centralisé pour obtenir la chaîne canonique

Recommandez la note de Vitalik sur la «faible subjectivité» et la description de l’EF. La première fois qu’un nœud se connecte, il doit avoir un certain cadre de référence pour savoir comment s’amorcer. Il ne s’agit pas d’un problème propre au PoS ; même un nœud complet de bitcoins doit savoir quel logiciel client est valide, à partir de quelles IP démarrer son historique, etc. Le PoS n’ajoute ici que des hypothèses de confiance supplémentaires mineures.

PoS = aucune consommation réelle de ressources

Il existe un fossé mental fascinant entre les personnes qui considèrent les liens avec le «monde réel» comme le seul attribut pouvant conférer une légitimité à un actif numérique, et les personnes qui considèrent les liens avec le «monde réel» comme des dépendances dangereuses à éviter lors de la construction de systèmes autosuffisants.

PoS = mauvaise complexité

La compréhension des implémentations actuelles représente clairement une véritable odyssée, avec un maëlstrom de mots nouveaux et de connaissances en matière de systèmes distribués à assimiler. Pourtant, après un examen en profondeur de tous les composants, rien ne semble inutile et un travail actif est en cours pour simplifier tout ce qui est possible. La société moderne est construite sur une série d’abstractions de plus en plus complexes ; les rejeter en raison de leur inaccessibilité initiale reviendrait à renoncer à une innovation massive.

Risques réels

Cartels de dépositaires d’enjeu liquide (et illiquide)

Alors qu’Ethereum n’a pas de PoS délégué au niveau de la couche du protocole, des remplacements au niveau de la couche application sont apparus. Lido a pris la tête des parts de mise en jeu, suivi par une poignée d’échanges centralisés. Plutôt que d’utiliser leurs propres validateurs, les utilisateurs envoient de l’ETH à ces fournisseurs de mise en jeu et reçoivent un dérivé d’enjeu sous forme de jeton, tel que stETH. Ces fournisseurs de mise en jeu ont alors généralement un contrôle total sur la façon dont les validateurs sont gérés. Les dépositaires ayant un contrôle de vote démesuré sont la voie la plus probable pour la capture réglementaire. Dernièrement du moins, ils ont fait exploser les fonds de leurs clients dans des manipulations à effet de levier, de sorte que les seules personnes qui auront de l’argent à la fin de tout cela seront les auto-dépositaires, pratiquant le self-custody.

La «tokénisation» des actifs du monde réel rend les forks difficiles

Lorsqu’un actif maintient son ancrage non pas grâce à des mécanismes onchain, mais grâce à la possibilité de rachat 1:1 hors chaîne auprès d’un émetteur centralisé, l’émetteur choisit une chaîne canonique pour honorer les rachats et les créations. Le meilleur exemple aujourd’hui est un stablecoin comme USDC ou USDT, mais d’autres actifs du monde réel tokenisés suivront sûrement dans les années à venir. MakerDAO est à la tête de nombreux efforts exploratoires.

La preuve d’une ressource quelle qu’elle soit est centralisatrice.

L’argent et les ressources ont tendance à s’accumuler entre les mains d’une poignée de personnes en l’absence de redistribution ou de révolution occasionnelle. L’effet de levier personnel implicite créé par des technologies de pointe exacerbe empiriquement la dynamique de la loi de puissance. Ainsi, bien que le PoS soit une abstraction plus propre que le PoW, ces deux mécanismes empêcheront une grande partie du monde de participer. Étant données les limites de notre horizon actuel, il est difficile d’imaginer que d’autres mécanismes de consensus pourraient apparaître avec une participation encore plus équitable, mais ce n’est pas à exclure.

Qu’est-ce que cela signifie pour moi ?

Une dernière section sur les aspects pratiques. Si vous êtes intéressé par la mise en jeu de vos propres ETH, les rendements annuels sont estimés entre 5 et 15 %, en fonction du nombre de participants et de l’importance des rétributions dues à la MEV. Il est possible d’effectuer une opération intéressante de «maintien jusqu’à l’échéance» en ce moment, car de nombreux dérivés liquides de mise en jeu se négocient en dessous de leur valeur de rachat éventuelle de 1 ETH. Pourquoi cela se produit-il ? Beaucoup de gens ont effectué une transaction stETH/ETH à effet de levier dans l’espoir d’augmenter leurs rendements, mais comme les retraits ne seront pas autorisés avant le hard fork Shanghai après la fusion, les besoins en liquidités sont apparus et il n’y a pas assez d’acheteurs. Il faut savoir que les produits dérivés liquides de mise en jeu ne sont en aucun cas arrimés à la valeur de l’ETH, si ce n’est qu’à l’échéance ils devraient être remboursables 1:1. Mais les acheteurs courageux qui sont prêts à prendre un risque inconnu sur la durée ont une possibilité d’être dûment récompensés.

Ce conseil peut paraître étrange car tout cet article incite à éviter les collusions malveillantes, et maintenant nous décrivons une manière de diriger de l’argent vers un dérivé d’un dépositaire. Mais il serait négligent de notre part de demander aux gens d’entrer dans un verrouillage à 1:1 sans savoir qu’ils peuvent être payés pour prendre le risque de la durée, de la gouvernance et des contrats autonomes pour ramasser les jetons bon marché des fonds surendettés.

Enfin, si vous êtes intéressé par l’exploitation de votre propre nœud de validation, voici un excellent guide pour la mise en jeu par soi-même.

Conclusion

De nombreux protocoles en PoS existent déjà, mais Ethereum établit une nouvelle norme de qualité. L’accent est mis sur la prise en charge d’un ensemble étendu de validateurs, sur des pénalités explicites, sur un compromis clair entre la vitalité et la sécurité, et sur le travail pénible au départ que représente la maintenance de plusieurs clients logiciels. Le système n’est pas parfait mais c’est l’une des innovations les plus élégantes dont nous disposons. Nous espérons que ce résumé explicatif vous aidera à comprendre comment tous les éléments s’assemblent .

Annexe

Définitions

LMD-GHOST : latest message driven – greediest heaviest observed subtree, la règle de choix de la branche déterminant quel bloc est considéré comme head de chaîne courante.

Casper FFG : le gadget de finalité utilisé dans le PoS d’Ethereum qui fait passer les blocs du stade «proposé» à «justifié» puis à «finalisé».

Gasper : le nom de l’implémentation PoS d’Ethereum, une combinaison de la règle de choix de la branche LMD-GHOST, du FFG Casper et du système spécifique de récompense/pénalité.

RANDAO : le mécanisme de génération de nombres aléatoires utilisé pour sélectionner les proposants des blocs, trier les validateurs en comités, etc.

BLS : le mécanisme de signature cryptographique utilisé pour les attestations des validateurs.

fuite d’inactivité : les validateurs qui ne soumettent pas d’attestations sont pénalisés si la chaîne cesse de se finaliser.

slashing : les validateurs qui proposent ou attestent malicieusement de plusieurs blocs à la même hauteur voient leur mise réduite.

proposer boost : une modification de LMD-GHOST donnant un poids supplémentaire aux blocs proposés plus tôt dans le créneau pour se défendre contre les attaques par avalanche, voir cette explication d’une réorganisation de 7 blocs dans la beacon chain alors que cette mise à jour était en cours de déploiement.

The post Le mécanisme de consensus d’Ethereum après la Fusion first appeared on Ethereum France.

Article de Vitalik Buterin publié sur https://vitalik.ca/general/2021/01/05/rollup.html, traduit par Jean Zundel.

Depuis longtemps, les couches de niveau 2 sont vues comme un moyen de passer à l’échelle, pour augmenter le nombre de transactions par seconde limitant naturellement une blockchain décentralisée comme Ethereum. Les rollups, dont le nom évoque les rouleaux de pièces que l’on peut commodément transporter et stocker, sont rapidement devenus la technologie la plus en vue. Après un bref survol des solutions développées auparavant, Plasma et les channels, Vitalik Buterin expose ici les principes fondamentaux des deux principaux types de rollups ainsi que les avantages et les inconvénients de chacun.

Les rollups font fureur dans la communauté Ethereum, et sont en passe de devenir la solution clé pour le scaling, le passage à l’échelle d’Ethereum dans un avenir proche. Mais qu’est-ce exactement que cette technologie, que peut-on en attendre et comment l’utiliser ? Cet article tentera de répondre à certaines de ces questions.

Contexte : qu’est-ce que le passage à l’échelle des couches 1 et 2 ?

Il existe deux manières de passer à l’échelle l’écosystème d’une blockchain. Premièrement, on peut faire en sorte que la blockchain elle-même ait une capacité de transactions plus élevée. Le principal inconvénient de cette technique est que les blockchains comportant de « plus grands blocs » sont intrinsèquement plus difficiles à vérifier et risquent de devenir plus centralisées. Pour éviter ce risque, les développeurs peuvent soit augmenter l’efficacité du logiciel client, soit, de manière plus durable, utiliser des techniques telles que le sharding pour permettre de répartir le travail de construction et de vérification de la chaîne sur de nombreux nœuds ; le projet connu sous le nom de « eth2 » est actuellement en train de mettre en œuvre cette solution pour Ethereum.

Deuxièmement, on peut changer la façon dont on utilise la blockchain. Au lieu de placer directement toute l’activité sur la blockchain, les utilisateurs effectuent la majeure partie de leur activité hors chaîne dans un protocole dit de « niveau 2 ». Il existe un smart contract ou contrat autonome sur la chaîne, qui n’a que deux tâches : traiter les dépôts et les retraits, et vérifier les preuves que tout ce qui se passe hors de la chaîne respecte les règles. Il existe plusieurs manières de faire ces preuves, mais elles ont toutes en commun le fait que la vérification des preuves sur la chaîne est beaucoup moins coûteuse que le calcul originel hors chaîne.

Comparaison : state channels, Plasma et rollups

Les trois principaux types de mise à l’échelle par une couche de niveau 2 sont les state channels ou canaux d’état, Plasma et les rollups. Il s’agit de trois paradigmes différents, avec des avantages et des inconvénients différents, et à ce stade, nous sommes assez confiants dans le fait que toutes les mises à l’échelle de la couche 2 entrent à peu près dans ces trois catégories (bien que des controverses de dénomination existent à la marge, voir par exemple «validium»).

Comment fonctionnent les channels ?

Voir aussi : https://www.jeffcoleman.ca/state-channels et statechannels.org

Imaginez qu’Alice offre une connexion Internet à Bob, en échange de quoi ce dernier lui verse 0,001 dollar par mégaoctet. Au lieu d’effectuer une transaction pour chaque paiement, Alice et Bob utilisent le système de niveau 2 suivant.

D’abord, Bob met 1$ (ou l’équivalent en ETH ou en monnaie stable) dans un contrat autonome. Pour effectuer son premier paiement à Alice, Bob signe un «ticket» (un message hors chaîne), qui dit simplement «0,001$», et l’envoie à Alice. Pour effectuer son deuxième paiement, Bob signe un autre ticket qui indique «0,002$» et l’envoie à Alice. Et ainsi de suite pour autant de paiements que nécessaire. Lorsque Alice et Bob ont terminé leurs transactions, Alice peut publier le ticket de plus grande valeur à la chaîne, enveloppé dans une autre signature de sa part. Le contrat vérifie les signatures d’Alice et de Bob, verse à Alice le montant indiqué sur le ticket de Bob et renvoie le reste à Bob. Si Alice ne veut pas fermer le channel (pour cause de malveillance ou de défaillance technique), Bob peut déclencher une période de retrait (par exemple, 7 jours) ; si Alice ne fournit pas de ticket dans ce délai, Bob est alors remboursé de tout son argent.

Cette technique est puissante : elle peut être ajustée pour gérer les paiements bidirectionnels, les relations par contrat autonome (par exemple, Alice et Bob passent un contrat financier à l’intérieur du canal) et la composition (si Alice et Bob ont un canal ouvert, tout comme Bob et Charlie, Alice peut interagir sans confiance avec Charlie). Mais les channels ont leurs limites. Les channels ne peuvent pas être utilisés pour envoyer des fonds hors chaîne à des personnes qui ne sont pas encore des participants. Les channels ne peuvent pas être utilisés pour représenter des objets qui n’ont pas de propriétaire logique clair (par exemple, Uniswap). Et les channels, surtout s’ils sont utilisés pour faire des choses plus complexes que de simples paiements récurrents, nécessitent de bloquer un capital important.

Comment Plasma fonctionne-t-il ?

Voir aussi l’article originel sur Plasma et Plasma Cash.

Pour déposer un actif, un utilisateur l’envoie au contrat autonome qui gère la chaîne Plasma. Elle lui attribue un nouvel identifiant unique (par exemple 537). Chaque chaîne Plasma a un opérateur (il peut s’agir d’un acteur centralisé, d’un multisig ou d’un élément plus complexe comme du PoS ou du DPoS). À chaque intervalle (15 secondes, ou une heure, ou entre les deux), l’opérateur génère un «lot» composé de toutes les transactions Plasma qu’il a reçues hors chaîne. Il génère un arbre de Merkle, où à chaque indice X de l’arbre, il y a une transaction transférant l’actif d’ID X s’il en existe une ; sinon cette feuille est à zéro. Ils publient la racine Merkle de cet arbre sur la chaîne. Ils envoient également la branche de Merkle de chaque index X au propriétaire actuel de cet actif. Pour retirer un actif, un utilisateur publie la branche de Merkle de la transaction la plus récente qui lui a envoyé l’actif. Le contrat déclenche une période de contestation, pendant laquelle chacun peut essayer d’utiliser d’autres branches de Merkle pour invalider la sortie en prouvant que (i) l’expéditeur ne possédait pas l’actif au moment où il l’a envoyé, ou (ii) qu’il a envoyé l’actif à quelqu’un d’autre à un moment ultérieur. Si personne ne prouve que la sortie est frauduleuse pendant (par exemple) 7 jours, l’utilisateur peut retirer le bien.

Plasma présente des propriétés plus puissantes que les canaux : vous pouvez envoyer des actifs à des participants qui n’ont jamais fait partie du système, et les exigences en matière de capital sont beaucoup plus faibles. Mais cela a un coût : les chaînes ne nécessitent aucune donnée pour tourner en «fonctionnement normal», mais Plasma exige que chaque chaîne publie une empreinte cryptographique à intervalles réguliers. De plus, les transferts Plasma ne sont pas instantanés : il faut attendre la fin de l’intervalle et la publication du bloc.

En outre, Plasma et les channels partagent une même faiblesse : la théorie des jeux sur laquelle se fonde leur sécurité repose sur l’idée que chaque objet contrôlé par les deux systèmes a un «propriétaire» logique. Si ce propriétaire ne se soucie pas de son bien, il peut en résulter un résultat «non valide» concernant cet actif. Cette situation est acceptable pour de nombreuses applications, mais elle est un facteur de rupture pour beaucoup d’autres (par exemple, Uniswap). Même les systèmes où l’état d’un objet peut être modifié sans le consentement du propriétaire (par exemple, les systèmes basés sur les comptes, où l’on peut augmenter le solde de quelqu’un sans son consentement) ne fonctionnent pas bien avec Plasma. Tout cela signifie qu’il faut beaucoup de «raisonnement spécifique à l’application» dans tout déploiement réaliste de Plasma ou de channels, et qu’il n’est pas possible de mettre en œuvre un système Plasma ou de channels qui se contente de simuler l’environnement complet d’Ethereum (ou «l’EVM»). Pour contourner ce problème, il faut… les rollups.

Rollups

Voir aussi : EthHub sur les optimistic rollups et les ZK rollups.

Plasma et les channels sont des représentations «complètes» de couche de niveau 2, en ce qu’ils tentent de déplacer les données et les calculs hors de la chaîne. Cependant, les questions fondamentales de la théorie des jeux concernant la disponibilité des données signifient qu’il est impossible de le faire en toute sécurité pour toutes les applications. Plasma et les channels contournent ce problème grâce à une notion explicite de propriétaire, mais cela les empêche d’être totalement généraux. Les rollups, en revanche, sont une représentation «hybride» de couche 2. Les rollups déplacent le calcul (et le stockage de l’état) hors chaîne, mais conservent certaines données par transaction sur la chaîne. Dans un souci d’efficacité, ils utilisent toute une série d’astuces de compression pour remplacer les données par du calcul chaque fois que cela est possible. Il en résulte un système dont l’évolutivité est toujours limitée par la bande passante de données de la blockchain sous-jacente, mais dans un rapport très favorable : alors qu’un transfert de jetons ERC20 de la couche de base d’Ethereum coûte environ 45000 gaz, un transfert de jetons ERC20 dans un rollup occupe 16 octets d’espace sur la chaîne et coûte moins de 300 gaz.

Le fait que les données résident sur la chaîne est essentiel (N.B.: le fait de mettre les données «sur IPFS» n’est pas suffisant car IPFS ne permet pas d’obtenir un consensus sur la disponibilité ou non d’une donnée ; les données doivent se trouver sur une blockchain). Le fait de mettre les données sur la chaîne et d’avoir un consensus à ce sujet permet à quiconque de traiter localement toutes les opérations du rollup s’il le souhaite, ce qui lui permet de détecter la fraude, d’initier des retraits ou de commencer personnellement à produire des lots de transactions. L’absence de problèmes de disponibilité des données signifie qu’un opérateur malveillant ou hors ligne peut faire encore moins de mal (par exemple, il ne peut pas causer un retard d’une semaine), ce qui ouvre un espace de conception beaucoup plus grand pour qui a le droit de publier des batches, des lots, et ce qui rend les rollups beaucoup plus faciles à raisonner. Et surtout, l’absence de problèmes de disponibilité des données signifie qu’il n’est plus nécessaire de faire correspondre les actifs aux propriétaires, ce qui explique pourquoi la communauté Ethereum est aussi enthousiaste à l’égard des rollups comparé aux formes précédentes de passage à l’échelle de niveau 2 : les rollups sont totalement génériques, et on peut même faire fonctionner une EVM à l’intérieur d’un rollup, ce qui permet aux applications Ethereum existantes de migrer vers des rollups pratiquement sans avoir à écrire de nouveau code.

Bon, mais comment fonctionne un rollup exactement ?

Il existe un contrat autonome sur la chaîne qui maintient une racine d’état : la racine Merkle de l’état du rollup (c’est-à-dire les soldes des comptes, le code du contrat, etc. qui sont «à l’intérieur» du rollup).

Tout le monde peut publier un lot, un ensemble de transactions fortement compressé avec la racine d’état précédente et la nouvelle racine d’état (la racine Merkle après le traitement des transactions). Le contrat vérifie que la racine d’état précédente du lot correspond à sa racine d’état actuelle ; si c’est le cas, la nouvelle racine d’état devient l’actuelle.

Pour faciliter les dépôts et les retraits, nous ajoutons la possibilité d’avoir des transactions dont l’entrée ou la sortie est «en dehors» de l’état du rollup. Si un lot comporte des entrées provenant de l’extérieur, la transaction qui soumet le lot doit également transférer ces actifs au contrat de rollup. Si un lot a des sorties vers l’extérieur, alors, lors du traitement du lot, le contrat autonome initie ces retraits.

Et c’est tout ! Sauf un détail majeur : comment savoir si les racines post-état des lots sont correctes ? Si quelqu’un peut soumettre un lot avec n’importe quelle racine post-état sans conséquences, il pourrait simplement se transférer toutes les pièces à l’intérieur du rollup. Cette question est essentielle car il existe deux familles de solutions très différentes au problème, et ces deux familles de solutions mènent aux deux saveurs de rouleaux.

Optimistic rollups contre ZK rollups

Les deux types de rollups sont :

1. Les Optimistic rollups, qui utilisent des preuves de fraude : le contrat de rollup conserve une trace de tout son historique des racines de l’état et l’empreinte cryptographique de chaque batch. Si quelqu’un découvre qu’un batch avait une racine post-état incorrecte, il peut publier une preuve sur la chaîne, prouvant que le lot a été mal calculé. Le contrat vérifie la preuve et renvoie ce lot ainsi que tous les lots     suivants. 
2. Les ZK rollups, qui utilisent des preuves de validité : chaque lot comprend une preuve cryptographique appelée ZK-SNARK (par exemple en utilisant le protocole PLONK), qui prouve que la racine post-état est le résultat correct de l’exécution du lot. Quelle que soit l’ampleur du calcul, la preuve peut être très rapidement vérifiée sur la chaîne. 

Les compromis entre les deux types de rollups sont complexes :

Propriété	Optimistic rollups	ZK rollups
Coût fixe du gaz par batch	~40 000 (une transaction légère qui ne fait que changer la valeur de la racine de l’État)	~500 000 (la vérification d’un ZK-SNARK est un travail de calcul assez intensif)
Délai de rétractation	~1 semaine (les retraits doivent être retardés pour donner le temps à quelqu’un de publier une preuve de fraude et d’annuler le retrait s’il est frauduleux)	Très rapide (il suffit d’attendre le prochain lot)
Complexité de la technologie	Faible	Élevée (les ZK-SNARK sont une technologie très nouvelle et mathématiquement complexe)
Possibilité de généralisation	Plus facile (les rollups EVM à usage général sont déjà proches du réseau principal)	Plus difficile (prouver des ZK-SNARK avec une EVM générique est beaucoup plus difficile que de prouver des calculs simples, bien qu’il y ait des efforts (par exemple Cairo) pour améliorer cela)
Coût du gaz par transaction sur la chaîne	Supérieur	Inférieur (si les données d’une transaction ne sont utilisées que pour vérifier, et non pour provoquer des changements d’état, alors ces données peuvent être omises, alors que dans un Optimistic rollup, elles devraient être publiées afin de pouvoir les vérifier lors d’une preuve de fraude)
Coûts de calcul hors chaîne	Inférieurs (bien qu’il soit plus nécessaire de refaire le calcul pour de nombreux nœuds complets)	Supérieurs (un ZK-SNARK s’avère particulièrement coûteux, potentiellement des milliers de fois plus cher que le calcul direct)

D’une manière générale, mon avis est qu’à court terme, les optimistic rollups devraient l’emporter pour le calcul générique sur l’EVM et les ZK rollups sont susceptibles de l’emporter pour les paiements simples, les échanges et d’autres cas d’usage spécifiques aux applications ; mais à moyen et long terme, les ZK rollups l’emporteront dans tous les cas d’usage à mesure que la technologie des ZK-SNARK s’améliorera.

Anatomie d’une preuve de fraude

La sécurité d’un Optimistic rollup repose sur l’idée que si quelqu’un publie un lot non valable dans le rollup, qui que ce soit d’autre qui suit la chaîne et a détecté la fraude peut publier une preuve de fraude, prouvant au contrat que ce lot est non valable et doit être annulé.

Une preuve de fraude prétendant qu’un lot est invalide contiendrait les données en vert : le lot lui-même (qui pourrait être vérifié par rapport à un hachage stocké sur la chaîne) et les parties de l’arbre de Merkle devaient prouver uniquement les comptes spécifiques qui ont été lus et/ou modifiés par le lot. Les nœuds de l’arbre en jaune peuvent être reconstruits à partir des nœuds en vert et n’ont donc pas besoin d’être fournis. Ces données sont suffisantes pour exécuter le lot et calculer la racine post-état (notez que les clients sans état vérifient les blocs individuels exactement de la même manière). Si la racine post-état calculée et la racine post-état fournie dans le lot ne sont pas les mêmes, le lot est frauduleux.

On a la garantie que si un lot a été mal assemblé, et que tous les lots précédents ont été assemblés correctement, il est possible de créer une preuve de fraude montrant que le lot a été assemblé de manière incorrecte. Notez la déclaration concernant les lots précédents : si plusieurs lots non valides ont été publiés dans le rollup, il est préférable d’essayer de prouver que le premier est non valide. Bien entendu, on a également la garantie que si un lot a été assemblé correctement, il n’est jamais possible de créer une preuve de fraude montrant que le lot est invalide.

Comment fonctionne la compression ?

Une simple transaction Ethereum (pour envoyer de l’ETH) prend ~110 octets. Un transfert ETH sur un rollup, en revanche, ne prend que ~12 octets :

Paramètre	Ethereum	Rollup
Nonce	~3	0
Prix du gaz	~8	0-0.5
Gaz	3	0-0.5
Destinataire	21	4
Valeur	~9	~3
Signature	~68 (2+33+33)	~0.5
Depuis	0 (récupéré de sig)	4
Total	~112	~12

Cela provient pour partie d’un meilleur encodage : la RLP d’Ethereum gaspille 1 octet par valeur sur la longueur de chaque valeur. Mais il y a aussi des astuces de compression très bien trouvées qui entrent en jeu :

• Nonce : le but de ce paramètre est d’empêcher les rediffusions. Si le nonce courant d’un compte est de 5, la prochaine opération de ce compte doit avoir un nonce 5, mais une fois l’opération traitée, le nonce du compte sera incrémenté à 6, de sorte que l’opération     ne pourra pas être traitée à nouveau. Dans le rollup, nous pouvons omettre complètement le nonce, car nous nous contentons de récupérer le nonce de l’état antérieur ; si quelqu’un essaie de rejouer une transaction avec un nonce antérieur, la signature ne sera pas vérifiée, car la signature sera comparée aux données qui contiennent le nouveau nonce supérieur.
• Prix du gaz : nous pouvons permettre aux utilisateurs de payer dans une de prix du gaz, par exemple un choix de 16 puissances consécutives de deux. Une autre possibilité serait de fixer un niveau de prix fixe pour chaque lot, ou même d’exclure entièrement le paiement du gaz du protocole de rollup et de faire payer les créateurs de lots par les participants aux transactions pour inclusion par un channel.
• Le gaz : nous pourrions tout aussi bien utiliser la totalité du gaz pour choisir entre des puissances consécutives de 2. On pourrait aussi se contenter d’une limite de gaz uniquement au niveau du lot.    
• To : nous pouvons remplacer l’adresse de 20 octets par un index (par exemple, si une adresse est la 4527e adresse ajoutée à l’arbre, nous utilisons simplement l’index 4527 pour y faire référence. Nous ajoutons un sous-arbre à l’état pour stocker la correspondance des index aux adresses). 
• Valeur : nous pouvons stocker la valeur en notation scientifique. Dans la plupart des cas, les transferts ne nécessitent que 1 à 3 chiffres significatifs.    
• Signature : nous pouvons utiliser les signatures agrégées BLS, qui permettent d’agréger de nombreuses signatures en une seule de ~32-96 octets (selon le protocole). Cette signature peut ensuite être vérifiée par rapport à l’ensemble des messages et des expéditeurs d’un même lot en une seule fois. Le ~0,5 du tableau représente le fait qu’il y a une limite au nombre de signatures pouvant être combinées dans un agrégat qui peuvent être vérifiées dans un seul bloc, et donc de grands lots auraient besoin d’une signature pour ~100 transactions.

Une astuce de compression importante, spécifique aux ZK rollups, est que si une partie d’une transaction est uniquement utilisée pour la vérification et n’est pas pertinente pour le calcul de la mise à jour de l’état, alors cette partie peut être laissée hors chaîne. Cela ne peut pas être fait dans un optimistic rollup car ces données devraient toujours être incluses dans la chaîne au cas où elles devraient être vérifiées ultérieurement dans une preuve de fraude, alors que dans un ZK rollup, le SNARK prouvant l’exactitude du lot prouve déjà que toutes les données nécessaires à la vérification ont été fournies. Un exemple important est celui des rollups de protection de la vie privée : dans un optimistic rollup, le ZK-SNARK d’environ 500 octets utilisé pour la confidentialité dans chaque transaction doit être intégré à la chaîne, tandis que dans un ZK rollup, le ZK-SNARK couvrant l’ensemble du lot ne laisse déjà aucun doute sur la validité des ZK-SNARK «internes».

Ces astuces de compression sont la clé de l’extensibilité des rollups ; sans elles, les rollups ne représenteraient peut-être qu’une amélioration d’un facteur ~10 par rapport à l’extensibilité de la chaîne de base (bien qu’il existe certaines applications spécifiques gourmandes en calculs où même les simples rollups sont puissants), alors qu’avec ces astuces de compression, le facteur d’échelle peut dépasser 100 fois pour presque toutes les applications.

Qui peut soumettre un lot ?

Il existe plusieurs écoles pour déterminer qui peut soumettre un lot dans un optimistic ou un ZK rollup. En général, tout le monde s’accorde à dire que, pour pouvoir soumettre un lot, un utilisateur doit verser un dépôt important ; si cet utilisateur soumet un jour un lot frauduleux (par exemple avec une racine d’état invalide), ce dépôt sera en partie brûlé et en partie donné comme récompense à celui qui a prouvé la fraude. Mais au-delà de cela, il existe de nombreuses possibilités :

• Anarchie totale : tout le monde peut soumettre un lot à tout moment. C’est l’approche la plus simple, mais elle présente des inconvénients importants. En particulier, il existe un risque que plusieurs participants génèrent et tentent de soumettre des lots en parallèle, et qu’un seul de ces lots puisse être inclus avec succès. Cela entraîne un gaspillage important d’efforts pour produire des épreuves et/ou un gaspillage de gaz pour publier les lots à enchaîner.        
• Séquenceur centralisé : un seul acteur, le séquenceur, peut soumettre des lots (à l’exception des retraits : la technique habituelle est qu’un utilisateur peut d’abord soumettre une demande de retrait, puis si le séquenceur ne traite pas ce retrait dans le lot suivant, l’utilisateur peut alors soumettre lui-même un lot à opération unique). C’est la plus «efficiente», mais elle dépend d’un acteur central à vie.
• Vente aux enchères du séquenceur : une vente aux enchères est organisée (par exemple tous les jours) afin de déterminer qui a le droit d’être le séquenceur pour le jour suivant. Cette technique présente l’avantage de permettre de lever des fonds qui pourraient être distribués par une DAO contrôlée par le rollup (voir : enchères MEV)    
• Sélection aléatoire à partir de l’ensemble du PoS : n’importe qui peut déposer de l’ETH (ou peut-être le jeton de protocole propre au rollup) dans le contrat de rollup, et     le séquenceur de chaque lot est choisi au hasard parmi l’un des déposants, la probabilité d’être sélectionné étant proportionnelle au montant déposé. Le principal inconvénient de cette technique est qu’elle conduit à l’immobilisation inutile d’un capital important. 
• Vote DPoS : un seul séquenceur est sélectionné lors d’une enchère, mais s’il n’est pas performant, les détenteurs de jetons peuvent voter pour le jeter dehors et organiser une nouvelle enchère pour le remplacer.    

Fractionnement des lots et fourniture de racines par l’État

Certains des rollups actuellement en cours de développement utilisent un paradigme de «split batch» ou lot éclaté, où l’action de soumettre un lot de transactions de couche 2 et celle de soumettre une racine d’état sont effectuées séparément. Cela présente certains avantages clés :

1. On peut permettre à plusieurs séquenceurs en parallèle de publier des lots afin d’améliorer la résistance à la censure, sans craindre que certains lots soient invalides parce qu’un autre lot a été inclus en premier.    
2. Si une racine d’état est frauduleuse, il n’est pas nécessaire de rétablir l’ensemble du lot     ; on peut rétablir uniquement la racine d’état et attendre que quelqu’un fournisse une nouvelle racine d’état pour le même lot. Cela donne aux expéditeurs de transactions une meilleure garantie que leurs transactions ne seront pas inversées.

Il existe donc un attirail assez complexe de techniques qui tentent de trouver un équilibre entre des compromis compliqués impliquant efficacité, simplicité, résistance à la censure, entre autres objectifs. Il est encore trop tôt pour dire quelle combinaison de ces idées fonctionne le mieux ; le temps nous le dira.

Quelle est l’ampleur du passage à l’échelle apporté par les rollups ?

Sur la chaîne Ethereum existante, la limite de gaz est de 12,5 millions, et chaque octet de données dans une transaction coûte 16 gaz. Cela signifie que si un bloc ne contient qu’un seul lot (nous dirons qu’un ZK rollup est utilisé, dépensant 500k de gaz pour la vérification des preuves), ce lot peut avoir (12 millions / 16) = 750000 octets de données. Comme indiqué ci-dessus, un rollup pour les transferts ETH ne nécessite que 12 octets par opération utilisateur, ce qui signifie que le lot peut contenir jusqu’à 62500 transactions. Avec un temps de bloc moyen de 13 secondes, cela se traduit par ~4807 TPS (contre 12,5 millions / 21000 / 13 ~= 45 TPS pour les transferts d’ETH sur Ethereum lui-même).

Voici un tableau pour d’autres exemples de cas d’utilisation :

Application	Octets dans le rollup	Coût du gaz sur la couche 1	Gain maximal
Transfert d’ETH	12	21 000	105x
Transfert ERC20	16 (4 octets supplémentaires pour préciser quel jeton)	~50 000	187x
Trade Uniswap	~14 (4 octets expéditeur + 4 octets destinataire + 3 octets valeur + 1 octet prix maxi + 1 octet divers)	~100000	428x
Retrait avec confidentialité (Optimistic rollup)	296 (4 octets d’index de la racine + 32 octets d’annulateur + 4 octets de destinataire + 256 octets de preuve ZK-SNARK)	~380 000	77x
Retrait avec confidentialité (ZK rollup)	40 (4 octets d’index de la racine + 32 octets d’annulateur + 4 octets de destinataire)	~380 000	570x

Il convient maintenant de garder à l’esprit que ces chiffres sont trop optimistes. Avant tout, un bloc ne contiendra presque toujours plus d’un seul lot, à tout le moins parce qu’il y a et qu’il y aura plusieurs rollups. Deuxièmement, les dépôts et les retraits continueront d’exister. Troisièmement, à court terme, l’utilisation sera faible, et les coûts fixes domineront donc. Mais même en tenant compte de ces facteurs, des gains d’extensibilité de plus de 100 devraient être la norme.

Maintenant, que faire si nous voulons aller au-delà de ~1000-4000 TPS (selon le cas d’utilisation spécifique) ? C’est ici qu’intervient le sharding d’eth2. La proposition sur le sharding, ou fragmentation, ouvre un espace de 16 Mo toutes les 12 secondes qui peut être rempli avec n’importe quelles données, et le système garantit un consensus sur la disponibilité de ces données. Cet espace de données peut être utilisé par des rollups. Cette capacité de ~1398k octets par seconde est une amélioration de 23x par rapport aux ~60 kB/sec de la chaîne Ethereum existante, et à plus long terme, la capacité en données devrait encore augmenter. Par conséquent, les rollups qui utilisent des données eth2 fragmentées peuvent traiter collectivement jusqu’à ~100k TPS, et même plus à l’avenir.

Quels sont les problèmes non encore résolus dans les rollups ?

Bien que le concept de base d’un rollup soit maintenant bien compris, que nous soyons tout à fait certains qu’il est fondamentalement faisable et sûr, et que de multiples rollups aient déjà été déployés sur le réseau principal, il reste encore de nombreuses zones d’ombre quant à leur conception, ainsi qu’un certain nombre de défis à relever pour amener de grandes parties de l’écosystème Ethereum sur des rollups afin de profiter du passage à l’échelle qu’ils offrent. Voici quelques-uns des principaux défis en question :

• Intégration des utilisateurs et de l’écosystème – peu d’applications utilisent des rollups, ils sont peu connus des utilisateurs et peu de portefeuilles ont commencé à les intégrer. Les commerçants et les associations ne les acceptent pas encore pour les paiements. 
• Transactions croisées – transfert efficace des actifs et des données (par exemple, les résultats d’oracles) d’un rollup à l’autre sans avoir à passer par la couche de base. 
• Audit des incitations – comment maximiser les chances qu’au moins un nœud honnête vérifie effectivement un optimistic rollup afin de pouvoir publier une preuve de fraude si quelque chose tourne mal ? Pour les rollups à petite échelle (jusqu’à quelques centaines de TPS), ce n’est pas     un problème important et on peut simplement compter sur l’altruisme, mais pour les rollups à plus grande échelle, une réflexion plus comlète est nécessaire sur ce sujet.    
• Exploration     de l’espace de conception entre le plasma et les rollups – existe-t-il des techniques permettant de mettre sur la chaîne certaines données pertinentes pour la mise à jour de l’état, mais pas toutes, et y a-t-il quelque chose d’utile qui pourrait en résulter ?     
• Maximiser la sécurité des pré-confirmations – de nombreux rollups fournissent une notion de «pré-confirmation» pour des UX plus rapides, où le séquenceur fournit immédiatement une promesse qu’une transaction sera incluse dans le lot suivant, et le dépôt du séquenceur est détruit s’ils manquent à leur parole. Mais la sécurité économique de ce système est limitée en raison de la possibilité de faire de nombreuses promesses à de très nombreux acteurs en même temps. Ce mécanisme peut-il être amélioré ?
• Améliorer la vitesse de réponse aux séquenceurs absents – si le séquenceur d’un rollup se met soudainement hors ligne, il serait utile de revenir à la normale rapidement et à moindre coût, soit en sortant en masse rapidement et à moindre coût vers un autre rollup, soit en remplaçant le séquenceur.     
• ZK-VM efficiente – génération d’une preuve ZK-SNARK selon laquelle le code de l’EVM générique (ou une autre VM sur laquelle les contrats existants peuvent être compilés) a été exécuté correctement et a donné un certain résultat. 

Conclusion

Les rollups constituent un nouveau paradigme puissant de passage à l’échelle de la couche de niveau 2 et devraient devenir une pierre angulaire du passage à l’échelle d’Ethereum à court et moyen terme (et peut-être aussi à long terme). La communauté Ethereum s’est montrée très enthousiaste car, contrairement aux tentatives précédentes de passage à l’échelle en couche 2, elle peut prendre en charge le code EVM générique, ce qui permet aux applications existantes de migrer facilement. Pour ce faire, ils ont fait un compromis essentiel : ils n’ont pas essayé de se retirer complètement de la chaîne, mais ont laissé une petite quantité de données par transaction sur la chaîne.

Il existe de nombreux types de rollups, et de nombreux choix dans l’espace de conception : on peut employer un optimistic rollup en utilisant des preuves de fraude, ou un ZK rollup en utilisant des preuves de validité (c.à.d. ZK-SNARK). Le séquenceur (l’utilisateur qui peut publier des lots de transactions à enchaîner) peut être un acteur centralisé, ou tout le monde et n’importe qui, ou encore un choix intermédiaire entre ces deux extrêmes. Les rollups sont une technologie encore très jeune et leur développement se poursuit rapidement, mais ils fonctionnent et certains (notamment Loopring, ZKSync et DeversiFi) fonctionnent déjà depuis des mois. On peut s’attendre à ce que des travaux passionnants dans ce domaine émergent dans les années à venir.

The post Un guide incomplet des rollups first appeared on Ethereum France.

FAQ publiée par Vitalik Buterin sur https://notes.ethereum.org/@vbuterin/BkSQmQTS8, traduite par Jean Zundel.

Bien sûr, le lancement réussi d’Eth2 a occupé tous les esprits ces dernières semaines, mais les travaux se poursuivent sur tous les fronts. L’EIP 1559, en discussion depuis plusieurs mois, représente une évolution majeure en changeant fondamentalement le fonctionnement des fees, les frais de transaction.

Qu’est-ce que l’EIP 1559 ?

L’EIP 1559 est une proposition visant à réformer le marché des frais d’Ethereum, avec les changements clés suivants :

• La limite actuelle de 10 millions de gaz est remplacée par deux valeurs : un «objectif moyen à long terme» (10 millions), et un «plafond ferme par bloc» (20 millions) ;
• Il existe un BASEFEE (qui est brûlé) que les transactions doivent payer, qui est ajusté bloc par bloc dans le but de cibler une valeur telle que la consommation moyenne de gaz du bloc reste autour de 10 millions.

En substance, alors que toute la volatilité à court terme de la demande d’espace de transaction à l’intérieur d’un bloc se traduit actuellement par une volatilité des frais de transaction, une partie se traduirait alors par une volatilité de la taille des blocs.

En quoi l’EIP 1559 est-elle bénéfique ?

Pour citer un ancien article :

Le statu quo des marchés des frais de transaction pose trois problèmes majeurs :

• Inadéquation entre volatilité des niveaux de frais de transaction et coût social des transactions : les frais de transaction sur les chaînes de blocs publiques établies, dont l’utilisation est suffisante pour que les blocs soient pleins, tendent à être extrêmement volatils. Sur Ethereum, les frais minimums tournent généralement autour de 2 gwei (10⁹ gwei = 1 ETH), mais ils peuvent parfois monter jusqu’à 20 à 50 gwei, voire 200 gwei en une occasion : https://etherscan.io/chart/gasprice. Il est clair que cela engendre une certaine inefficacité car il est absurde de supposer que le coût supporté par le réseau pour accepter une transaction supplémentaire dans un bloc soit 100 fois plus élevé lorsque le prix du gaz est de 200 gwei que lorsqu’il est de 2 gwei ; dans les deux cas, il s’agit d’une différence entre 8 millions de gaz et 8,02 millions de gaz ;
• Inefficacités des enchères de premier prix : voir https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410 pour un compte rendu détaillé. En bref, dans l’approche actuelle, les émetteurs publient une transaction avec une redevance, les mineurs choisissent les transactions les plus rémunératrices et chacun paie ce qu’il offre. Cette approche est bien connue dans la littérature sur les mécanismes d’incitation pour être très inefficace, nécessitant des algorithmes complexes d’estimation des frais ; ces algorithmes finissent souvent par ne pas très bien fonctionner, ce qui entraîne fréquemment des frais excessifs. Voir également https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72, la description par un core développeur Bitcoin des défis entraînés par le statu quo de l’estimation des frais ;
• Instabilité des chaînes de blocs sans récompense en bloc : à long terme, les chaînes de blocs où il n’y aura pas d’émission (y compris Bitcoin et Zcash) ont actuellement l’intention de récompenser les mineurs par les frais des transactions. Toutefois, des résultats connus montrent que cela risque d’entraîner une grande instabilité, en incitant à miner des «blocs frères» pour voler les frais de transaction, ouvrant ainsi des vecteurs d’attaque par minage égoïste beaucoup plus puissants, etc. Il n’existe actuellement aucune mesure efficace d’atténuation de ce phénomène.

L’EIP 1559 présente ces avantages :

• Il atténue les inefficacités économiques dues à l’inadéquation des coûts sociaux en raison de la volatilité des frais. L’argument économique est assez nuancé ; voir en particulier les pages 16 à 20 du document dont le lien figure sur https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838 (bien que je recommande de lire l’ensemble du document) pour une argumentation détaillée sur les raisons de cette situation. Intuitivement, le mécanisme d’ajustement des frais fonctionne comme un frais fixe à court terme et un plafond à long terme, et il s’avère qu’en raison des arguments avancés dans cet l’article de Martin Weitzman (en 1974), des frais fixes sont probablement préférables à un plafond dans les conditions où, fondamentalement, toutes les blockchains publiques sont aujourd’hui en place.
• Il remplace la vente aux enchères par une vente à prix fixe (sauf pendant de courtes périodes où les blocs se remplissent complètement jusqu’à ce que les frais rattrapent leur retard), ce qui élimine les inefficacités de la vente aux enchères au premier prix et rend l’estimation des frais extrêmement simple : calculez les frais f pour le bloc suivant, si vous pouvez vous le permettre, payez-les, sinon ne le faites pas.
• Il crée un mécanisme similaire à une récompense permanente par bloc (le 1/N provenant du pot), ce qui atténue bon nombre des problèmes d’instabilité liés aux chaînes de blocs fonctionnant uniquement sur les frais sans nécessiter de véritable émission permanente.

Un autre avantage sous-estimé de l’EIP 1559 est qu’il permet de mesurer les prix du gaz de manière sûre. Aujourd’hui, le simple fait de regarder les prix du gaz sur la chaîne et de les utiliser comme indice est exploitable, car les mineurs peuvent inclure des transactions fictives à très faible ou très forte redevance, où la redevance se ferait à eux-mêmes. Mais en vertu de l’EIP 1559, le BASEFEE ne peut être manipulé qu’à un coût élevé, car les transactions fictives exigeraient même du mineur qu’il paie des frais (qui sont brûlés).

Les marchés actuels des frais sont-ils vraiment si inefficaces ?

Oui, la différence entre le prix moyen du gaz et le dixième centile du prix du gaz dans un bloc normal est d’environ 3 fois pour la médiane et de 5 à 8 fois pour la moyenne. Les gens paient trop, en masse, inutilement.

Toute personne qui ne paie pas trop subit un retard de 1 à 2 minutes, voire plus, et ce retard ne profite en fait à personne ; la charge totale de la chaîne est la même, qu’une unité de charge donnée atteigne la chaîne au temps N ou au temps N + 60. Il n’y a aucun avantage social réel à favoriser des participants «exprimant une préférence pour la rapidité» dans le mécanisme du marché des frais, du moins dans des conditions normales ; il s’agit d’une perte parfaitement inutile. Il vaudrait mieux pour nous tous que davantage de transactions soient incluses immédiatement, ce que permet l’EIP 1559.

Pourquoi ne pas simplement utiliser la deuxième enchère (ou une k-ième enchère) pour résoudre les inefficacités de la meilleure enchère ?

Les enchères au k-ième prix (où chacun paie un prix de gaz égal au prix le plus bas qui était inclus dans le bloc) sont effectivement «efficaces» dans une analyse économique traditionnelle*, mais elles ont le défaut d’être vulnérables à la collusion.

* Oui, bien sûr, techniquement, il faut utiliser le prix du gaz le plus élevé qui n’est pas inclus dans le bloc ; mais en pratique, étant donné que la plupart des blocs Ethereum comportent des centaines de transactions, la différence serait négligeable.

L’EIP 1559 pourrait-elle faire courir le risque de surcharger les nœuds et les mineurs pendant les périodes de forte utilisation ?

EIP 1559 peut tout au plus multiplier par 2 la taille des blocs, même à court terme. Chaque «bloc complet» (c’est-à-dire un bloc dont le gaz est 2x la TARGET) augmente le BASEFEE de 1,125x, donc une série de blocs complets constants augmentera le prix du gaz par un facteur 10 tous les ~20 blocs (~4,3 min en moyenne). Par conséquent, les périodes de forte charge sur la chaîne ne dureront pas plus de 5 minutes.

Notez qu’actuellement, les périodes de doublement de la charge durant 5 minutes se produisent déjà aléatoirement environ une fois tous les ~63888 blocs (~10 jours) en raison de la variance du taux de production des blocs. L’introduction de l’EIP 1559 n’entraînerait donc pas un niveau de charge sans précédent dans le système.

En outre, la limite de gaz de 10 millions, pas plus, est justifiée dans une large mesure non par des limites strictes du réseau (les taux d’oncles sont proches des plus bas niveaux historiques, bien que les risques pour les nœuds non-mineurs tels que les nœuds de bootstrap puissent être plus élevés), mais par des préoccupations fondamentalement long terme :

• Risque de centralisation par des taux d’oncles un peu plus élevés : si les taux d’oncles grimpaient jusqu’à 20%, cela profiterait de manière disproportionnée aux grands bassins bien connectés ;
• Limites en taille de l’état ;
• Difficulté de synchronisation après une courte période hors ligne.

Dans ces trois cas, ce qui importe n’est pas la limite supérieure de la capacité dans une fenêtre de temps très courte, mais plutôt la capacité moyenne à long terme. Le fait que les taux d’oncles soient de 2% pendant les heures impaires et de 18% pendant les heures paires aurait le même effet sur les trois cas précités, car les taux d’oncle sont toujours de 10%. Étant donné que l’EIP 1559 limite toujours la consommation de gaz à long terme à une moyenne d’environ 10 millions par bloc, il n’affecte pas la moyenne à long terme.

À quoi ressemblerait un pic de consommation élevée avec l’EIP 1559 par rapport au statu quo ?

Considérons un «pic mathématiquement idéal» (par exemple, cela pourrait se produire dans la vie réelle en raison d’un événement soudain sur le marché conduisant à de nombreuses possibilités d’arbitrage sur les DEX, à des offres sur les CDP liquidés, etc.), où N * 10 millions de transactions de gaz, chacune avec un prix du gaz très très élevé, sont toutes diffusées.

Actuellement, cela conduirait à la situation suivante :

• Les prochains blocs N seraient exclusivement remplis de nouvelles transactions à prix élevés ;
• Ensuite, les autres transactions, ainsi que celles que les gens enverraient après le pic, seraient incluses dans l’ordre décroissant du prix du gaz.

Un «utilisateur normal» moyen devrait attendre plus de N blocs.

Examinons maintenant la situation avec l’EIP 1559 :

• Les blocs N/2 suivants seraient remplis exclusivement de nouvelles transactions «d’heure de pointe», chacune avec une quantité de gaz deux fois plus importante que la normale ;
• Si toutes les autres transactions sont envoyées avec un plafond de prix du gaz égal à l’ancien prix du gaz, les blocs N/2 suivants seraient vides, et après cela les choses reviendraient à la normale. Mais de manière réaliste, les transactions prioritaires fixeraient des plafonds de prix du gaz plus élevés et seraient incluses en premier, et les autres transactions plus tard.

Un «utilisateur normal» moyen devrait attendre quelque part entre N/2 et plus de N blocs.

Par conséquent, même en incluant la «période de récupération» après la période de pointe pendant laquelle la capacité des blocs serait inférieure à la normale, la plupart des transactions seraient incluses plus tôt.

Voici une simulation très grossière (il y a beaucoup d’hypothèses étranges ici, mais il est difficile de modéliser un système complet qui couvre à la fois les courbes de l’offre et de la demande et les temps d’attente) ; le tableau source est ici.

Statu quo :

EIP 1559 :

Que ferait l’EIP 1559 en cas de pics plus importants et plus prolongés (p. ex. pics d’une journée) ?

Pas beaucoup. Le BASEFEE augmenterait et il y aurait une courte période au début où quelques transactions seraient plus rapides, mais après cela, le marché des frais fonctionnerait comme dans des conditions «ordinaires», à un niveau de frais plus élevé. Le principal avantage de l’EIP 1559 en matière de pics est que les dommages causés par l’inefficacité des marchés de frais ordinaires sont amplifiés lorsque les frais sont élevés, de sorte qu’il devient plus important d’avoir un marché des frais qui fonctionne.

Pourquoi limit = cible * 2 ? Pourquoi pas 4 ? Ou 8 ?

Plus le rapport limite / cible est élevé, plus les avantages de l’EIP 1559 en termes d’efficacité du marché des frais sont importants. Cela dépend de l’amplitude des pics à court terme que nous sommes prêts à accepter ; 2x est assez prudent. Nous pourrions même lancer l’EIP 1559 avec un rapport limite / objectif de 2 pour commencer, et l’augmenter au fil du temps si nous voyons que le réseau fonctionne bien même en cas de pics à court terme.

Pourquoi les mineurs incluraient-ils des transactions ?

L’EIP comprend un «pourboire» que les émetteurs de transactions peuvent inclure pour le mineur. Ce pourboire sert à deux choses : premièrement, s’il y a subitement beaucoup plus de transactions que prévu, les mineurs incluront d’abord les transactions avec un pourboire plus élevé, de sorte que le mécanisme de priorisation basé sur les frais reste finalement actif. Deuxièmement, il compense le risque d’oncles pour les mineurs (le risque accru que leur bloc ne soit pas inclus dans la chaîne principale parce que l’ajout d’une transaction supplémentaire le ralentira).

Le calcul du niveau de pourboire qui compense le risque d’oncle donne environ 0,8 gwei (les blocs oncles obtiennent en moyenne une récompense de 1,67 ETH au lieu de la base de 2 ETH, ce qui représente une perte de ~0,33 ETH = 330m gwei, 10 millions de blocs de gaz ajoutent ~0,025 au taux d’oncles par rapport aux blocs vides, donc le coût prévu du gaz est = 330m / 10m * 0,025 = 0,825 gwei) et les mineurs se fixent effectivement cette valeur lorsque la chaîne est vide.

Ce niveau de pourboire est indépendant du BASEFEE, de sorte que les clients peuvent en toute confiance fixer 1-1,5 gwei et s’attendre à ce que leurs transactions soient acceptées.

Comment les portefeuilles peuvent-ils choisir les pourboires ? Y a-t-il un risque de guerre des enchères pour les pourboires ?

Les portefeuilles pourront simplement choisir les pourboires en examinant quels pourboires ont été acceptés dans le passé sur la chaîne et en augmentant leur pourboire s’ils constatent qu’une transaction qu’ils envoient n’a pas été acceptée immédiatement. Notez que dans des «conditions normales», il n’y a aucune raison de fixer un pourboire supérieur au strict minimum.

En cas de congestion soudaine, les pourboires se transforment en guerre d’enchères ; les portefeuilles peuvent détecter la congestion et, dans ce cas, ils peuvent offrir aux utilisateurs la possibilité de fixer une priorité faible ou élevée pour leur transaction.

Qu’est-ce que le mécanisme d’escalator ? Comment peut-il être combiné avec le PEI 1559 ?

Le mécanisme d’escalator est une proposition de réforme différente des frais de transaction dans laquelle, au lieu de spécifier des frais uniques, les utilisateurs spécifient leurs frais comme une fonction, généralement avec un début, une augmentation par bloc et un maximum, par exemple «5 gwei si cette transaction est incluse dans le bloc 10123456, ajouter 1 gwei pour chaque bloc suivant (par exemple 8 gwei si inclus dans le bloc 10123459), jusqu’à un maximum de 100 gwei».

Il s’agirait de quatre paramètres : frais de début, bloc de début, incrément par bloc, frais maximum.

L’objectif est d’être «plus sécurisé» envers les erreurs d’estimation des frais, car si les frais s’avèrent trop bas, ils augmenteront naturellement au fil du temps jusqu’à ce que la transaction soit incluse. Dans le contexte de l’EIP 1559, cela pourrait être utilisé pour fixer le pourboire. Le fait que le pourboire se situerait généralement dans une fourchette constante signifie que même un portefeuille n’utilisant que des paramètres fixes pour l’escalator donnerait des résultats assez corrects aux utilisateurs.

Les mineurs ne seront-ils pas incités à s’associer pour faire baisser le BASEFEE en limitant le remplissage de leurs blocs à moins de la moitié ?

En général, l’efficacité ce genre de stratégies est limitée, car à moins que presque tout le monde ne soit de connivence, une transaction non incluse dans un bloc sera incluse dans le bloc suivant ; l’effet de cette action sur le BASEFEE à long terme sera donc négligeable.

Toutefois, les mineurs peuvent mettre en place une sorte de «tarification monopolistique». Supposons que les émetteurs de transactions soient prêts à payer des frais supplémentaires pour éviter d’être retardés d’un bloc. Les mineurs peuvent refuser d’inclure les transactions qui ne comportent pas un pourboire minimum T ; ils perdent une partie de leurs revenus, mais gagnent à ce que les émetteurs augmentent leurs frais s’ils évaluent la probabilité supplémentaire que vous soyez le prochain mineur et qu’ils incluent leur transaction de manière suffisamment élevée. Cette stratégie est fortement défavorable au mineur : il subit le coût total de la perte de revenus, mais ne gagne qu’une petite partie de l’augmentation des frais de transaction que d’autres envoient.

Notez que même si un mineur réussit avec cette stratégie, il augmentera les revenus des autres mineurs plus qu’il n’augmentera ses propres revenus (car les autres mineurs profitent des pourboires plus élevés en raison de vos actions), et il ne s’agit donc pas d’un vecteur de centralisation.

Cela ne ramènera pas le BASEFEE à zéro, mais permettra d’atteindre un équilibre où le BASEFEE constituera toujours la majeure partie des frais et les pourboires le complétant. En effet, à moins que les mineurs ne soient tous de connivence (auquel cas nous avons des problèmes plus importants), les mineurs subissent la totalité des coûts, hors transactions, mais ne bénéficient que partiellement des avantages liés à l’augmentation des pourboires.

Si le risque que les mineurs déploient une telle stratégie reste inacceptable, nous pouvons affecter une partie (par exemple 50%) des recettes de l’EIP 1559 à un fonds commun dont un petit pourcentage est prélevé sur chaque bloc pour être ajouté à la récompense de bloc des mineurs ; cela garantit que les mineurs bénéficient d’un BASEFEE élevé, ce qui réduit encore les gains d’une telle attaque.

Voici, schématisée, une proposition de modification de l’EIP allant dans ce sens :

• Définir le compte 0x35 comme FEE_SMOOTHING_BUFFER, et définir FEE_SMOOTHING_CONSTANT = 8192 ;
• Ajouter un terme supplémentaire à la récompense en bloc (ajouté en même temps que la récompense en bloc de base et les récompenses oncle+neveu). Soit smoothing_reward = FEE_SMOOTHING_BUFFER.balance // FEE_SMOOTHING_CONSTANT. Transférer smoothing_reward wei de FEE_SMOOTHING_BUFFER vers block.coinbase ;
• Après l’application des récompenses du bloc, la moitié des frais EIP-1559 de ce bloc (arrondis à l’inférieur) est ajoutée au solde de FEE_SMOOTHING_BUFFER. Le reste (c’est-à-dire la moitié arrondie à l’unité supérieure) est brûlé.

Notez que dans un contexte de preuve d’enjeu, il serait souhaitable de mettre en place des élections à bulletins secrets des dirigeants ainsi que des sanctions en cas de révélation prématurée, afin d’empêcher les validateurs d’acquérir la réputation de n’accepter que des pourboires élevés et d’en tirer eux-mêmes tout le bénéfice, car les émetteurs de transactions sauraient quels validateurs vont bientôt créer des blocs.

Autres ressources

Le document original : https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410

Thread de ethresear.ch sur les simulations de Barnabe : https://ethresear.ch/t/eip-1559-simulations/7280

The post FAQ EIP 1559 first appeared on Ethereum France.