Actu-crypto

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterdayEthereum France

Le mĂ©canisme de consensus d’Ethereum aprĂšs la Fusion

September 8th 2022 at 07:47

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
https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F2cc1f113-acd4-47e8-81ef-70f04887d5c5_1600x924.png
L’état actuel de la chaĂźne phare. Blocs produits exactement toutes les 12 secondes. Voir les donnĂ©es en direct sur https://beaconcha.in

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.

https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fd54b77f3-6079-4f75-8693-f9b2d5e2ca67_804x550.png
Encore un triangle de compromis fameux. Choisissez-en deux, ou vous vous retrouverez quelque part au milieu.

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).

https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fc6ef9139-4c79-41f5-892a-5152aebae0a3_962x621.png
Un survol technique de la maniÚre dont les attestations des validateurs sont agrégées et finalement intégrées aux blocs.

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.
https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fdee9dcbf-b824-4d6c-a7ad-6b542895c83e_1108x522.png
Conditions du slashing selon les spécifications de Gasper

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 ?

https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F7bd964c8-dbcd-4cbf-a8ec-04596b505563_1024x1024.png
Collusion malveillante d’un cartel de baleines. Image gĂ©nĂ©rĂ©e par DALLE⋅2.

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 :

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.

https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F0f993b88-9a40-44a3-9ffb-8b58dd15c2fc_1410x938.jpeg
Source des dépÎts sur la beacon chain

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.

https://substackcdn.com/image/fetch/w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F01913607-2c45-40b5-ba9a-2d8b54a556d0_1524x1382.png
Volatilité de stETH/ETH ces trois derniers mois

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.

Un guide incomplet des rollups

February 2nd 2021 at 11:24

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 rollupsZK 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Ă©rieurInfĂ©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ĂštreEthereumRollup
Nonce~3   0
Prix du gaz~80-0.5
Gaz30-0.5
Destinataire214
Valeur~9~3
Signature~68 (2+33+33)~0.5
Depuis0 (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 :

ApplicationOctets dans le rollupCoût du gaz sur la couche 1Gain maximal   
Transfert d’ETH           1221 000105x
Transfert ERC20           16 (4 octets supplémentaires pour préciser quel jeton)~50 000187x
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 00077x
Retrait avec confidentialitĂ© (ZK rollup)40 (4 octets d’index de la racine + 32 octets d’annulateur + 4 octets de destinataire)           ~380 000           570x
Le gain maximal de passage Ă  l’échelle est calculĂ© comme suit : (coĂ»t du gaz L1) / (octets dans le rollup * 16) * 12 millions / 12,5 millions.

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 EIP 1559

December 7th 2020 at 15:09

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 (109 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.
❌