Actu-crypto

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterdayYour RSS feeds

The DeFi Collective : bientÎt une plateforme répertoriant les protocoles véritablement décentralisés ?

October 16th 2024 at 17:00

Il y a quelques jours, Vitalik Buterin, cofondateur d'Ethereum, a évoqué son souhait de trouver un bon équilibre entre décentralisation et coopération au sein de l'écosystÚme de la finance décentralisée. The DeFi Collective, association à but non lucratif soutenant les protocoles DeFi résilients, s'est emparée du sujet.

L’article The DeFi Collective : bientĂŽt une plateforme rĂ©pertoriant les protocoles vĂ©ritablement dĂ©centralisĂ©s ? est apparu en premier sur Cryptoast.

Une introduction à l’Abstraction du Compte

November 24th 2022 at 17:33

Cet article revoit les grands principes qui se cachent derriĂšre l’abstraction du compte (ou Account Abstraction) pour en comprendre ses enjeux. Il passe en revue les comptes Ethereum et leurs limitations, apporte une dĂ©finition simple de l’abstraction du compte, explique pourquoi nous en parlons tant aujourd’hui, ce que cela permet et donne un aperçu du futur de cette innovation.

InspirĂ© de l’excellente serie sur le sujet par Julien Niset d’Argent:  https://www.argent.xyz/blog/part-3-wtf-is-account-abstraction/.
Un grand merci Ă  Disiaque, spolrot et filtertron pour leur relecture.

1. Les comptes Ethereum

Un compte Ethereum permet d’utiliser la blockchain. Il existe deux types de comptes : les comptes contrats (ou contract account ou smart-contracts) et les EOAs (Externally Owned Accounts ou compte Ă  propriĂ©taire externe). 

Les comptes contrats sont dĂ©ployĂ©s sur Ethereum de maniĂšre immuable et permettent l’utilisation de la blockchain Ă  travers leurs fonctions programmables. Les EOAs permettent d’interagir avec Ethereum et ses smart contracts via des wallets (e.g. Metamask) qui agissent comme des interfaces avec la blockchain.
Nous nous concentrons ici sur les EOAs : les comptes utilisateurs.

Un EOA possÚde les caractéristiques suivantes :

  • Balance: montant d’actifs sur le compte
  • Nonce: paramĂštre incrĂ©mental permettant de vĂ©rifier que les transactions s’effectuent dans le bon ordre
  • Address: suite hexadĂ©cimale de 42 caractĂšres (0x
n) permettant l’identification du compte

À chaque EOA est assignĂ© un signataire (« signer »). C’est un objet cryptographique composĂ© d’une paire de clefs (ou « keypair ») publique et privĂ©e :

  • La clef publique permet l’identification du wallet. C’est Ă  partir de celle-ci que l’on dĂ©rive l’adresse publique du compte lors de sa crĂ©ation. (NB : les adresses Ethereum sont dĂ©rivĂ©s des 20 derniers octets du hash de la clef publique, en ajoutant ”0x” au dĂ©but) 
  • La clef privĂ©e permet de signer des messages numĂ©riques et prouver que l’on est le dĂ©tenteur du wallet i.e. prouver qu’on peut effectuer des transactions (par exemple envoyer de l’argent ou interagir  depuis ce compte.
  • NB : Il est possible de dĂ©river la clef publique Ă  partir de la clef privĂ©e suivant le modĂšle ECDSA, mais l’inverse est impossible.
C.f. Définition des comptes sur Ethereum-France (2017) https://www.ethereum-france.com/comptes-transactions-gaz-et-limites-de-gaz-par-bloc-sur-ethereum/ 

2. Limitations des comptes Ethereum

Aujourd’hui, sur Ethereum Mainnet, un EOA est indissociable du signataire et vice versa. Cela reprĂ©sente une limitation au niveau du protocole qui affecte l’expĂ©rience utilisateur et la sĂ©curitĂ© des comptes de plusieurs maniĂšres :

  • Il existe une seule clef privĂ©e par compte ; perdre sa clef privĂ©e revient Ă  perdre l’accĂšs Ă  son compte et tous ses actifs.
  • ProtĂ©ger sa clef privĂ©e, en dissimulant les 12 ou 24 mots composant la seed phrase, est aussi sensible que complexe, mĂȘme pour les utilisateurs avancĂ©s.
  • Le modĂšle de signature (ECDSA) est limitĂ© et non rĂ©sistant Ă  l’informatique quantique.
  • Ce mĂȘme modĂšle de signature est rigide : il ne peut pas ĂȘtre modifiĂ© Ă  la guise de l’utilisateur ou des applications.
  • Le compte doit payer du gas pour chaque transaction, dans le token natif (ETH). Cela limite l’expĂ©rience et la confidentialitĂ© des utilisateurs.

RĂ©soudre ces limitations semble urgent pour plusieurs raisons : tout d’abord car l’informatique quantique se dĂ©veloppe rapidement et pourrait remettre en cause la sĂ©curitĂ© des comptes Ethereum (en rendant obsolĂšte le modĂšle de signature ECDSA). Mais c’est aussi et surtout la pĂ©rennitĂ© de mauvaises pratiques depuis des annĂ©es qui freinent l’adoption de la technologie en effrayant les utilisateurs ou les poussent Ă  se tourner vers des solutions centralisĂ©es.

3. L’abstraction du compte

L’abstraction du compte est une alternative au modĂšle de comptes utilisateurs actuels permettant de faire face aux limitations Ă©voquĂ©es ci-dessus. 
En informatique, l’abstraction consiste Ă  enlever, sĂ©parer ou isoler des caractĂ©ristiques d’un Ă©lĂ©ment afin de le simplifier et/ou rĂ©duire Ă  l’essentiel. 

L’abstraction du compte consiste en une transformation de l’EOA en un smart-contract, permettant d’isoler le signataire des autres Ă©lĂ©ments du compte. Ce smart-contract permet d’imiter les fonctionnalitĂ©s principales d’un compte, c’est-Ă -dire valider et exĂ©cuter des transactions, et d’ajouter des capacitĂ©s de programmation et personnalisation.

La gestion de ce nouveau type de smart contracts se fait via des smart contract wallets (tels que Argent ou Safe). Depuis des annĂ©es, ils permettent d’émuler une forme d’abstraction de compte: c’est-Ă -dire qu’ils implĂ©mentent les caractĂ©ristiques de l’abstraction du compte sans changement du protocole Ethereum. Il y a toujours des EOA, mais une partie des complexitĂ©s est dissimulĂ©e.
Par exemple avec Argent, un pionnier des smart contract wallets, chaque utilisateur possÚde un EOA secret sur son téléphone, qui est le propriétaire du smart contract. La gestion de la clef privée est abstraite grùce à un modÚle de social recovery.

Cf. Vitalik Buterin via “Pourquoi avons-nous besoin de l’adoption massive du “social recovery” (permis grñce à l’abstraction du compte) https://vitalik.ca/general/2021/01/11/recovery.html 

Cependant les smart contract wallets sont considĂ©rĂ©s comme des citoyens de seconde zone car Ethereum a Ă©tĂ© conçu pour interagir avec les EOAs et non des smart contracts ; chaque application a besoin d’ĂȘtre personnalisĂ©e pour pouvoir interagir avec les smart contract wallets (cf. EIP-1271 et la fonction isValidSignature).

4. CapacitĂ©s et possibilitĂ©s de l’abstraction du compte

L’abstraction du compte permet de grandes amĂ©liorations de sĂ©curitĂ© et de facilitĂ© d’utilisation, et ouvre la porte Ă  une infinitĂ© de cas d’usages, notamment :

  • Social Recovery (recouvrement social) : permet de se passer de clefs privĂ©es en donnant l’autorisation de rĂ©initialiser un wallet Ă  partir d’autres entitĂ©s (comptes, hardware wallets, utilisateurs).
  • Multicall (multi-appel) : permet de grouper plusieurs opĂ©rations et les soumettre en une transaction (atomique) afin d’économiser du gas, rĂ©aliser plusieurs opĂ©rations d’une seule traite ou encore programmer des transactions sous conditions.
  • Fraud monitoring (surveillance de la fraude) : permet une validation Ă  facteur multiples (e.g. 2FA) avec plusieurs signatures pour interagir avec certains smart contracts ou rĂ©aliser certains types d’opĂ©rations. 
  • Session keys (clefs de session) : donne la possibilitĂ© d’autoriser un smart contract Ă  rĂ©aliser un ensemble d’actions pendant une pĂ©riode de temps donnĂ©.
  • Custom gas management (gestion personnalisĂ©e du gaz) : permet d’éviter aux utilisateurs d’avoir Ă  payer du gas pour chaque transaction. Permettrait Ă©galement aux utilisateurs ou applications de payer le gas dans n’importe quel token ou monnaie fiduciaire.


et bien d’autres encore. La grande force de l’abstraction du compte est qu’il rend possible de personnaliser les paramĂštres des comptes utilisateurs, et notamment le modĂšle de signature, ce qui dĂ©cuple le champ des possibilitĂ©s.

5. Pourquoi l’abstraction du compte, maintenant ? 

On parle d’abstraction du compte depuis les dĂ©buts d’Ethereum et Vitalik en est un fervent dĂ©fenseur. 
Historiquement, les EOAs ont Ă©tĂ© conçus avec comme prioritĂ© la possibilitĂ© de gĂ©rer soi-mĂȘme et sans intermĂ©diaire ses clefs privĂ©es afin de maximiser la dĂ©centralisation du rĂ©seau.

Plusieurs propositions de mises Ă  jour du protocole ont Ă©tĂ© imaginĂ©es pour implĂ©menter l’abstraction du compte sur Ethereum: les EIP-86, EIP-2938, EIP-3074,et le plus rĂ©cent EIP-4337.

L’EIP-4337 consiste Ă  rendre plus facile le dĂ©veloppement et la gestion des smart contract wallets en mutualisant l’infrastructure nĂ©cessaire Ă  leur fonctionnement. Avec l’EIP-4337, les utilisateurs n’envoient plus directement de transactions au rĂ©seau. À la place, ils soumettent des “intentions” de transaction Ă  une mempool, repris par des bundlers ou assembleurs qui vĂ©rifient, exĂ©cutent et soumettent les transactions Ă  l’EVM. Des paymasters ou trĂ©soriers-payeurs peuvent ĂȘtre dĂ©signĂ©s pour financer les frais de gaz.

Les spĂ©cifications de cet EIP ont Ă©tĂ© dĂ©finies et l’implĂ©mentation est en cours. 

+ c.f. Roadmap de l’implĂ©mentation de l’Account Abstraction https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap?utm_source=substack&utm_medium=email#Transaction-inclusion-lists 
+c.f. historique des EIPs sur l’abstraction du compte https://hackmd.io/@matt/r1neQ_B38?utm_source=substack&utm_medium=email

En plus de ces dĂ©veloppements sur le protocole Ethereum, la mise en production des solutions de scalabilitĂ© ou passage Ă  l’échelle reprĂ©sente aujourd’hui une aubaine pour l’abstraction du compte qui peut ĂȘtre implĂ©mentĂ©e nativement et Ă  grande Ă©chelle en ayant appris des erreurs commises dans le passĂ©.

6. Quelles pistes d’avenir pour l’abstraction du compte ?

Sur Ethereum, nous utilisons encore des EOAs ou des smart contract wallets qui imitent l’abstraction du compte. L’implĂ©menter sur Ethereum, comme toute modification du protocole, reprĂ©senterait des changements lourds et complexes. Mais comme l’a montrĂ© Vitalik dans la roadmap mise Ă  jour d’Ethereum, l’Account Abstraction Track a dĂ©jĂ  bien avancĂ©, et devrait s’accĂ©lĂ©rer dans les prochains mois.

Des solutions de scalabilitĂ© de type Layer2 (couches de niveau 2 ou L2) comme Starknet et Zksync v2 supportent l’abstraction du compte nativement. Il sera fascinant d’étudier les dĂ©veloppements de l’abstraction du compte sur ces derniĂšres et de parfaire le modĂšle proposĂ© par l’EIP-4337. Nous nous attendons Ă  ce que d’autres L2/blockchains suivent le pas.

Dans un monde oĂč 99% de l’activitĂ© d’Ethereum se passe sur les L2(cf. Rollup-centric roadmap) le besoin d’abstraction du compte sur mainnet pourrait se rĂ©duire. Mais si on se dirige vers un monde oĂč les chaĂźnes/rollups sont compatibles avec l’EVM et/ou Ă©quivalents, alors il sera tout de mĂȘme nĂ©cessaire d’implĂ©menter cette innovation sur le mainnet d’Ethereum. D’un autre cĂŽtĂ©, si Ethereum adopte l’abstraction du compte sur mainnet, la majoritĂ© des L2 devront suivre
 đŸ“đŸ„š

Pour finir avec une note d’actualitĂ©, la faillite de FTX souligne une fois de plus la nĂ©cessitĂ© des solutions de self custody (dĂ©tention personnelle) qui permettent de s’émanciper des solutions centralisĂ©es et sĂ©curiser nos actifs sans tiers parti. L’abstraction du compte, qui positionne les smart contracts wallets comme standard de la self custody, apparaĂźt comme la suite logique dans le dĂ©veloppement des comptes et wallets sur Ethereum ; mais pas seulement.


Pour suivre Ethereum-France ⬇

Des questions ou commentaires? N’hĂ©sitez pas Ă  me contacter via NathanSexer sur Twitter.

The post Une introduction à l’Abstraction du Compte first appeared on Ethereum France.

Ethereum a fusionnĂ© đŸŒ

September 15th 2022 at 09:16

Tout ce qu’il faut savoir sur le Merge, le PoS et les prochaines Ă©tapes.

Mainnet Merge Announcement
Image tirĂ©e de l’annonce officielle du Merge par la fondation, en hommage Ă  la mise Ă  jour du merge « Paris », nommĂ©e ainsi en rĂ©fĂ©rence Ă  EthCC.

English version available here.

TLDR; Ethereum a fusionnĂ© avec succĂšs. Une prouesse technique qui permet au rĂ©seau de fonctionner en Proof-Of-Stake et ainsi rĂ©duire de 99.95% sa consommation d’électricitĂ© et son Ă©mission d’ETH de 90%, tout en rendant le rĂ©seau plus sĂ©curisĂ© et dĂ©centralisĂ©. Nous revenons sur ce qu’est le Merge, son dĂ©roulement, ses bĂ©nĂ©fices et les prochaines Ă©tapes de la feuille de route d’Ethereum.

  • Qu’est-ce que le “Merge”?
  • Comment s’est dĂ©roulĂ© le Merge?
  • Qu’est-ce que le Proof Of Stake (PoS)?
  • Quels avantages du PoS vs PoW?
    • Tableau comparatif de PoW vs PoS
  • Quelles sont les prochaines grandes Ă©tapes d’Ethereum?
  • Appendix
    • EthPoS vs EthPoW
    • Structure de bloc sous PoS (cf thread)
    • Cycle de vie des attestations Ethereum sous PoS
  • FAQs
    • En tant qu’utilisateur, comment cela m’impacte t-il? Que dois-je faire?
    • Comment devenir validateur?
    • Est-ce que le Merge amĂ©liore la scalabilitĂ© d’Ethereum?
  • Ressources

Merci à Philippe Honigman, Bettina Boon Falleur, Jean Zundel, Jimmy Ragosa et Simon Polrot pour la révision.


Qu’est-ce que le “Merge”?

https://ethereum.org/en/upgrades/merge/

Le Merge correspond Ă  la fusion des chaĂźnes d’Ethereum qui s’est opĂ©rĂ©e le 15 septembre 2022.

La blockchain Ethereum comportait Ă  sa crĂ©ation une seule chaĂźne qui fonctionnait Ă  l’aide d’un mĂ©canisme de consensus associĂ© au Proof-of-Work (PoW ou Preuve de Travail). 

En dĂ©cembre 2020, en vue du passage au Proof-Of-Stake (PoS ou Preuve d’Enjeu) anticipĂ© depuis sa crĂ©ation, une autre chaĂźne Ă  Ă©tĂ© lancĂ©e: la “Beacon Chain” (chaine d’accroche, chaĂźne phare, chaĂźne balise) aussi appelĂ©e la « Consensus Layer ». 

Depuis le lancement de la Beacon Chain, deux chaĂźnes tournaient en parallĂšle :

  • La couche d’exĂ©cution (execution layer), oĂč Ă©taient exĂ©cutĂ©es les transactions et stockĂ© l’état historique d’Ethereum. Elle correspond Ă  la partie “⛏ Proof-of-work” sur le schĂ©ma ci-dessus, comprenant « Ethereum State: transactions, apps, contracts, balances »), c’était le mainnet Ethereum.
  • La couche de consensus (consensus layer) ou Beacon chain, Ă©tait la chaĂźne amorcĂ©e par des utilisateurs ayant dĂ©posĂ© leur ETH (sur mainnet) pour devenir validateur. Jusqu’au Merge, ils ne faisaient qu’écouter le mainnet et validaient uniquement l’état de leur propre chaĂźne.

Le Merge marque la fusion de ces deux chaĂźnes et le changement de mĂ©canisme de consensus d’Ethereum avec la fin du PoW et le passage au PoS. Cette fusion entraĂźne plusieurs amĂ©liorations telles que la rĂ©duction de consommation d’énergie de 99.95%, et prĂ©pare le terrain pour les mises Ă  jour Ă  venir de scalabilitĂ© qui deviendront plus faciles Ă  implĂ©menter.

Comment s’est dĂ©roulĂ© le Merge?

La TTD (Terminal Total Difficulty, qui reprĂ©sente schĂ©matiquement la puissance de calcul globale dĂ©ployĂ©e par les mineurs depuis la crĂ©ation d’Ethereum – plus de dĂ©tails dans cet article), dĂ©terminĂ© par les Core Devs le 18 AoĂ»t 2022, a permis d’estimer la chronologie du Merge prĂ©vu entre le 10 et le 20 septembre 2022.

Nous suivions les prévisions du TTD via https://bordel.wtf (en référence à la communauté de hackers tchÚques du Paralelni Polis), mais un grand nombre de trackers étaient disponibles (cf. liste).

Le TTD à finalement été atteint le 15 septembre 2022 à 8h42:59 au block #15537394

  • Nous avons suivi la “Ethereum Mainnet Merge Viewing Party”  organisĂ© par la fondation Ethereum avec  Bankless, EthStaker, Ethereum Cat Herders, The Daily Gwei et des invitĂ©s comme Superphiz.eth, Pooja Rajan, Tim Beiko, Anthony Sassano, Justin Drake et Vitalik Buterin qui ont rĂ©pondu Ă  des questions rĂ©currentes : pourquoi le Merge, comment se dĂ©roule la fusion, comment amĂ©liorer la diversitĂ© des clients, comment maintenir la dĂ©centralisation etc.
  • Comme Ă  son habitude Jonathan Mann, nous a chantĂ© une chanson Ă©crit pour l’occasion: « Pandas Are Not Known For Running‘
  • Danny Ryan nous a dĂ©taillĂ© les Ă©tapes du merge: un premier block et les attestations qui arrivent, ≈ 32 blocks dans la 1Ăšre epoch, avec 2/3 de participation des validateurs nĂ©cessaires Ă  sa justification. AprĂšs la 2e epoch, les premiers blocks en PoS ont Ă©tĂ© finalisĂ©s et la chaĂźne Ethereum est officiellement passĂ© en PoS.

Si ces termes vous sont Ă©trangers, pas d’inquiĂ©tude, nous les dĂ©taillons dans la suite de l’article.

  • Le premier block en Proof-of-Stake est celui-ci: https://etherscan.io/block/15537394, nous le voyons Ă  la difficultĂ© du bloc qui Ă©quivaut 0, signifiant que le bloc n’a pas Ă©tĂ© minĂ©

Deux mises à jour critiques ont précédé le Merge :

  • La mise Ă  jour « Bellatrix » a prĂ©parĂ© la couche de consensus pour le Merge (en vert sur le schĂ©ma). Elle a notamment permis la mise Ă  jour de la structure des blocs qui a  instaurĂ© les slots de 12 secondes par bloc (post-merge).
    Toute personne faisant tourner un nƓud et/ou un validateur Ethereum a dĂ» mettre Ă  jour son client Ethereum avant le 6 Septembre 2022.
  • “Paris” qui implĂ©mente deux EIPs (Ethereum Improvements Proposals) : 
    • EIP-4399 = introduit un changement de sĂ©mantique de l’opcode DIFFICULTY (qui devient obsolĂšte) Ă  PREVRANDAO. L’utilisation reste la mĂȘme.
    • EIP-3675 = aussi appelĂ© “Merge EIP”: la mise Ă  jour du Merge qui met officiellement fin au PoW 
https://blog.ethereum.org/2022/08/24/mainnet-merge-announcement

Qu’est-ce que le Proof Of Stake (PoS)?

Passons en revue quelques éléments primordiaux du PoS :

Le PoS ou le PoW, le mĂ©canisme anti-Sybil associĂ© au consensus des blockchains, est central Ă  leur fonctionnement : c’est ce qui permet de dĂ©terminer leur Ă©tat, c’est-Ă -dire d’organiser la blockchain en produisant ses blocs, qui contiennent des transactions.

Contrairement au PoW qui fonctionne avec des mineurs, le PoS fait appel Ă  des validateurs pour dĂ©terminer l’état de la blockchain.

Chaque bloc (regroupement de transactions d’utilisateurs) de la blockchain Ethereum est soumis Ă  un groupe de validateurs choisis alĂ©atoirement, qui vĂ©rifient les transactions en les rĂ©-exĂ©cutant, vĂ©rifient leur signature et soumettent au rĂ©seau leur vote (sous forme d’attestations) afin de proposer la validation des blocs. Le temps de validation des blocs sur Ethereum sous PoW Ă©tait de 13/14 secondes. Maintenant, le temps par bloc est dĂ©terminĂ© par « slots » fixes de 12s, 1 bloc par slot, validĂ© par un validateur choisi alĂ©atoirement. Plusieurs slots forment une epoch, une Ă©poque. 2 epochs sont nĂ©cessaires afin que les blocs soient considĂ©rĂ©s comme finaux et irrĂ©versibles.

Les validateurs sont rémunérés pour plusieurs éléments : 
‱ Lorsqu’ils sont choisis alĂ©atoirement pour proposer des blocs
‱ Lorsqu’ils Ă©mettent des attestations, correspondant Ă  un vote du validateur sur ce que reprĂ©sente l’état de la chaĂźne
‱ Via les tips (pourboires) ou frais supplĂ©mentaires payĂ©s par les utilisateurs (instaurĂ©s grĂące Ă  l’EIP-1559)

Le PoS engendre un changement pour les mineurs/validateurs. Il n’y a pas de changement majeur pour les utilisateurs ni pour les dĂ©veloppeurs d’applications, ni mĂȘme d’interruption du rĂ©seau.

Pour en savoir plus sur le mĂ©canisme de consensus de PoS, nous l’avons expliquĂ© en dĂ©tail ici : https://www.ethereum-france.com/le-mecanisme-de-consensus-dethereum-apres-la-fusion/ 

Quels avantages du PoS vs PoW ?

  • 99.95% de consommation d’énergie en moins par rapport au fonctionnement en PoW selon la fondation Ethereum + vĂ©rification par JĂ©rĂŽme de Tychey avec la slide ci dessous:
Slide de Jerome de Tychey sur la consommation d’énergie de Ethereum post-Merge

Plus d’informations via le site de la fondation.

  • Plus dĂ©centralisĂ©: les barriĂšres Ă  l’entrĂ©e pour devenir validateur sont plus faibles. Moins de matĂ©riel informatique est nĂ©cessaire et il n’y a pas d’économie d’échelle Ă  rĂ©aliser sur PoS: les revenus des validateurs sont linĂ©aires (vs Ă©conomies d’échelle des mineurs sur PoW). 

Aussi, l’accĂšs aux ressources nĂ©cessaires Ă  la validation (ETH) est accessible Ă  tous, de la mĂȘme maniĂšre, contrairement au matĂ©riel informatique et Ă©lectricitĂ© du PoW.

  • RĂ©duction de l’émission d’ETH de 90% post merge.
    Certains parlent de “Triple Halvening” (en rĂ©fĂ©rence aux Halvings de Bitcoin) car 3 Ă©lĂ©ments entrent dorĂ©navant en jeu :
    • L’émission d’ETH sur le marchĂ© passera de ≈4.5% Ă  ≈0.5%/an, voire moins en fonction de la demande sur le rĂ©seau.
    • EIP-1559 brĂ»le de l’ETH Ă  chaque transaction (depuis le 05 AoĂ»t 2021 / block 12965000), pouvant dĂ©clencher des pĂ©riodes dĂ©flationnistes pour ETH lorsque le rĂ©seau est congestionnĂ©, c’est-Ă -dire lorsqu’il y a plus d’ETH brĂ»lĂ©s qu’émis.
    • Beaucoup d’ETH sont bloquĂ©s pour la validation (≈ 13 650 700 ETH soit ≈ $22 Milliards Ă  ce jour selon https://beaconcha.in/)
https://www.attestant.io/posts/charting-ethereum-issuance/ annoté par Jimmy Ragosa
  • Moins de pression Ă  la vente sur ETH : en plus des ETH stakĂ©s, les validateurs n’ont pas besoin de vendre leur ETH pour faire fonctionner leur(s) validateur(s), contrairement aux mineurs qui vendaient leur ETH pour payer leurs factures d’électricitĂ©.
  • Plus de sĂ©curitĂ© : une attaque pour prendre le contrĂŽle complet du rĂ©seau nĂ©cessiterait de dĂ©tenir plus de 66% de tous les ETH en collatĂ©ral (vs 51% du hashpower sur PoW). Cette attaque devient de plus en plus coĂ»teuse avec le prix de l’ETH. DĂ©tenir des ETH que l’on peut perdre et/ou qui perdraient leur valeur suite Ă  une attaque fournit une double incitation.

Tableau comparatif de PoW vs PoS (Ethereum)

ModĂšles de ConsensusPOW (Pre-merge)POS (Post-merge)
ActeursMineursValidateurs
HardwareMining rigsOrdinateur
RessourceElectricitéETH
RevenusExponentiels (Économie d’échelle)LinĂ©aires
(Incrémental)
Finalité*Probabilistique
≈6min
Explicite
>12.8min
Temps de validation
des blocs
≈13s=12s
ContrĂŽle complet**51% (>Âœ)>66% (>⅔)
Tableau comparatif de PoW vs PoS (Ethereum) par Nathan Sexer

*https://hackmd.io/@prysmaticlabs/finality
**https://medium.com/@Beosin_com/ethereum-pos-and-pow-security-fd52a6153b1e

Quelles sont les prochaines grandes Ă©tapes d’Ethereum ?

La scalabilitĂ© d’Ethereum est au centre des discussions depuis sa crĂ©ation et le prochain challenge des core devs.

Le Merge a d’ailleurs pu ĂȘtre priorisĂ© grĂące Ă  l’émergence des solutions de scaling telles que les Rollups qui ont dĂ©sengorgĂ© la L1 d’Ethereum et permis au Merge d’émerger ( đŸ€­) en prioritĂ©. C’est autour des Rollups que se construit la feuille de route d’Ethereum depuis des annĂ©es ; Vitalik parlait en 2020 de “rollup-centric ethereum roadmap”.  Plus d’informations sur les rollups : https://www.ethereum-france.com/un-guide-incomplet-des-rollups/.

Le Merge reprĂ©sentait une Ă©tape majeure. Par la suite, les core devs vont pouvoir s’attaquer aux prochaines grandes Ă©tapes de la roadmap d’Ethereum, Ă  savoir :

  • The Surge : AmĂ©liore significativement les performances et l’utilisabilitĂ© des rollups grĂące au trĂšs attendu sharding, avec le danksharding qui gagne en traction dans la communautĂ©.
    Attendu pour 2023.
  • The Verge : «Statelessness» grĂące aux Verkle Trees, ce qui permettrait aux noeuds de ne plus stocker l’état en permanence grĂące Ă  des «tĂ©moins».
  • The Purge : Élimine des donnĂ©es historiques et de la dette technique, pour notamment dispenser les nƓuds de stocker l’historique.
  • The Splurge : Apporte beaucoup de fonctionnalitĂ©s Ă  Ethereum, comme l’account abstraction, et bien d’autres.
https://twitter.com/VitalikButerin/status/1466411377107558402?s=20&t=muXSMLsxecRhFqydYowOow

Comme le montre ce schéma (publié par Vitalik en Décembre 2021, pas à jour), le développement des grandes étapes de la roadmap a avancé en parallÚle.
Nous nous attendons à une cadence de mise à jour soutenue dans les mois et années à venir.
Nous suivrons cela de prÚs. 

FAQs

En tant qu’utilisateur, comment cela m’impacte t-il ? Que dois-je faire ?

Rien ! Les applications s’en chargent pour vous. 

Vous aurez les mĂȘmes donnĂ©es, tokens etc. au mĂȘme endroit.
Le modĂšle de pricing de gas reste Ă©galement le mĂȘme, c’est-Ă -dire celui de l’EIP-1559.

Est-ce que le Merge amĂ©liore la scalabilitĂ© d’Ethereum?

Pas immĂ©diatement (mĂȘme si les blocs se valident 1 seconde plus rapidement en moyenne). Le merge apporte cependant des changements critiques aux futures mises Ă  jour de scalabilitĂ© d’Ethereum, notamment le sharding. Les frais de gas et la capacitĂ© d’exĂ©cution des transactions restent les mĂȘmes.

Comment devenir validateur ?

Il existe 3 maniĂšres de participer Ă  la validation d’Ethereum sous PoS, chacun reprĂ©sentant un compromis. La fondation a fait de trĂšs bons guides que nous vous invitons Ă  suivre.

Si l’investissement initial du solo staking de 32 ETH est consĂ©quent, cela reste le moyen le plus trustless et sĂ©curisĂ© pour staker ses ETH.
A noter : ces ETH sont bloquĂ©s jusqu’à ce qu’une nouvelle mise Ă  jour permette de les dĂ©bloquer (la Shanghai upgrade). Les validateurs reçoivent quand mĂȘme une partie de leurs rĂ©compenses sur une adresse mainnet dĂšs maintenant.

Quel avenir pour EthPoW/ETHW?

  • ETHPoW (ou ETHW) est la branche d’Ethereum restĂ©e en PoW.
  • Les acteurs majeurs de l’écosystĂšme dont les stablecoins (USDT ou USDC), protocoles de DeFi/lending (Aave), oracles (Chainlink) et bien d’autres supportent le passage au PoS.
  • La majoritĂ© des services et applications ne supporteront pas ETHPoW : c’est la grande majoritĂ© de ce qui marche aujourd’hui sur Ethereum qui s’écroule du jour au lendemain, Ă  commencer par toute la DeFi. Resteront les donnĂ©es historiques de la blockchain Ethereum et une couche applicative inutilisable.
  • A ceux qui souhaitent profiter de ETHPoW: la meilleure stratĂ©gie est de bien prendre ses prĂ©cautions et probablement de ne rien faire. La majoritĂ© des bĂ©nĂ©fices sera tirĂ©e par des traders, experts en MEV et arbitrage qui travaillent sur le sujet depuis des mois/annĂ©es, dans les blocs suivant le fork. 
  • Si les actifs sont rĂ©pliquĂ©s, ce ne sera pas le cas de leur valeur : on estimait avant le Merge que les tokens ETH de la chaine ETHPoW valaient seulement ≈2% de la valeur des ETH (cf. coinmarketcap). 
  • Rappelons qu’il est probable que la chaĂźne ne perdure pas sur le long terme et qu’elle reste un no mans land rĂ©servĂ©e aux spĂ©culateurs.
  • Selon Tarun Chitra (ici), les supporters de ETHPoW n’auraient pas encore rĂ©ussi Ă  synchroniser de noeud avec leurs changements; qui impliquent entre autres de remplacer les frais de gas brĂ»lĂ©s (cf. EIP-1559) pour se les distribuer Ă  la place, se distribuer les ETH appartenant Ă  la Fondation Ethereum etc.
  • Maintenir ETHPoW actif impliquerait qu’un Ă©cosystĂšme mature de mineurs, de dĂ©veloppeurs d’applications, de clients, d’investisseurs et d’utilisateurs restent actifs sur le rĂ©seau. Ils devront probablement forker Ă  nouveau pour mettre fin Ă  la Difficulty Bomb rendant obsolĂšte le PoW sur Ethereum


Appendice

Structure de bloc sous PoS (cf.  thread)

  • Sous PoS, les blocs Ethereum sont constituĂ©s de 3 parties (cf. ce thread):
  • Administration, contient les informations du bloc: 
    • slot : le numĂ©ro du bloc
    • proposer_index : le validateur qui le propose
    • parent_root : le hash du prĂ©cĂ©dent bloc
    • state_root : le hash d’un Merkle Root qui stocke l’état de la BeaconChain (BeaconState)
    • randao_reveal : un nombre gĂ©nĂ©rĂ© de maniĂšre alĂ©atoire au niveau du protocole, proposĂ© grĂące Ă  plusieurs proposants de bloc d’une Ă©poque.
    • graffiti: du texte de 32-byte (optionnel) soumis par les proposeurs de bloc
    • signature : la signature du validateur qui propose le bloc, qui permet de le responsabiliser : le rĂ©munĂšre s’il se comporte bien, le punit le cas inverse.
  • Consensus: contient les informations nĂ©cessaires pour coordonner et vĂ©rifier le consensus de la blockchain, et implĂ©menter le PoS
  • ExĂ©cution: contient la charge du bloc Ethereum,c’est-Ă -dire toutes les donnĂ©es des transactions contenues dans le bloc. TrĂšs similaire Ă  la structure des blocs Ethereum sous PoW, notamment pour des raisons de compatibilitĂ©. Voyons les quelques changements ci-dessous:
  • difficulty : passe Ă  0, le PoS ne nĂ©cessite pas ce paramĂštre qui correspondait Ă  la puissance de hachage nĂ©cessaire aux mineurs afin de miner le bloc.
  • sha3Uncles et uncles : disparaissent car le PoS ne produit pas naturellement de uncle blocks, ces blocs minĂ©s mais dĂ©passĂ©s par une autre branche.

Cycle de vie des attestations Ethereum sous PoS 

via https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/attestations 

Ressources


Pour suivre Ethereum-France ⬇

The post Ethereum a fusionnĂ© đŸŒ first appeared on Ethereum 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.

Ethereum 2.0: Ropsten PoS, la fusion est en cours đŸŒ

June 9th 2022 at 17:46

Le réseau de test Ropsten vient de fusionner : il fonctionne dorénavant en Proof-of-Stake (PoS)

C’est une Ă©tape clef de la transition d’Ethereum, dont le mainnet fonctionne actuellement en Proof of Work (PoW), vers le Proof of Stake (PoS).

Un point rapide sur l’état actuel d’Ethereum, le merge Ropsten et les Ă©tapes restantes pour le passage d’Ethereum en PoS 👇

NB: nous ne devons plus parler d’Ethereum 2.0 depuis « le grand renommage« . Il n’y a et n’y aura qu’un seul Ethereum et qu’un seul token ETH. Afin de maximiser la clartĂ©, nous devrions parler uniquement de fusion des couches d’execution (actuellement eth1) et de consensus (actuellement eth2).
Ce terme persiste malgré tout pour des raisons historiques de vulgarisation.

État actuel d’Ethereum

  • Ethereum fonctionne actuellement en PoW. Ethereum aujourd’hui, c’est une couche d’exĂ©cution (aussi appelĂ©e EL pour « Execution layer ») + l’état historique de la blockchain. 
  • SĂ©paration de la couche consensus: (CL pour « Consensus Layer ») en Proof of Stake, avec la Beacon chain. En fonctionnement depuis fin 2020. ✅
  • La « Shadow fork » mainnet dĂ©but avril et les tests clients ont Ă©tĂ© effectuĂ©s avec succĂšs. ✅
  • Passage des Testnets en Proof of Stake:
    • Tests des implĂ©mentations clients rĂ©ussis sur des « shadow forks » de testnets (souvent des forks de Goerli) limitĂ©s dans le temps avec par exemple la fork « Kiln ». Chaque fork est accompagnĂ© de sa propre beacon chain, vouĂ©e Ă  disparaĂźtre.
    • La « Beacon chain » Ropsten a Ă©tĂ© lancĂ©e le 30 Mai.
    • La couche de consensus doit se mettre Ă  jour pour suivre les nouvelles rĂšgles d’Ethereum 2.0 : la mise Ă  jour Bellatrix sur Ropsten a Ă©tĂ© effectuĂ©e le 2 Juin 2022.
    • La couche d’exĂ©cution doit Ă©galement se mettre Ă  jour. La “Terminal Total Difficulty” (TTD) est dĂ©terminĂ©e dans cette Ă©tape.
    • Ropsten a fusionnĂ© ✅ (lire le rĂ©sumĂ©)

A Venir: la fusion

  • Passage des Testnets en Proof of Stake:
    • Testnet Goerli ⏳
    • Testnet Sepolia ⏳
  • DĂ©termination du “slotheight” pour la mise Ă  jour Bellatrix de la Beacon Chain (CL)
  • DĂ©termination de la TTD (via le “All Core Dev Call”) pour la transition mainnet
    • Les core devs dĂ©terminent ici un TTD afin de dĂ©clencher la transition Ă  un moment donnĂ©.
    • On choisit un TTD plutĂŽt qu’un numĂ©ro de Block afin de limiter le potentiel d’attaque. Lors de la fusion des chaĂźnes, le hashrate rĂ©duira significativement ce qui pourrait permettre Ă  un acteur mal intentionnĂ© de forker la chain PoW et produire des blocs en amont du premier bloc en PoS ce qui affecterait le timing et la sĂ©curitĂ© de la fusion (source: https://eips.ethereum.org/EIPS/eip-3675#terminal-total-difficulty-vs-block-number)
    • Pour rappel: la difficultĂ© influence le «hashrate » nĂ©cessaire afin que les mineurs trouvent les blocs
  • Mises Ă  jour des clients qui rendra le merge possible
    • Bellatrix (CL)
    • Paris (EL)
  • PrĂ©-activation des clients CL & EL 
  • Compte a rebours des TTD
  • FinalitĂ© atteinte aprĂšs 2 epochs (≈12.8min)

On estime que la fusion d’Ethereum mainnet et son passage en PoS aura lieu d’ici la fin de l’étĂ©, courant Juillet-AoĂ»t. On estime aussi qu’Ethereum en PoS consommera 99.5% moins d’énergie qu’en PoW.

D’ici la fin de l’annĂ©e, les testnets Kiln, Rinkeby et Ropsten s’arrĂȘteront.
Post-merge, seuls les testnets Goerli et Sepolia seront maintenus.


Rejoignez Ethereum-France ⬇

The post Ethereum 2.0: Ropsten PoS, la fusion est en cours đŸŒ first appeared on Ethereum France.

Et voici EIP-1559 !

July 30th 2021 at 11:07
By: PhilH

Cet article est le 300Ăšme publiĂ© par Anthony Sassano dans le cadre de sa newsletter The Daily Gwei ! Comme beaucoup d’autres, il a Ă©tĂ© re-publiĂ© en français par nos amis de The Daily Gwei FR, crĂ©Ă©e par Jon Otherbright. Nous sommes heureux de publier Ă  notre tour sur Ethereum-France cette synthĂšse d’EIP-1559. Pour ceux qui veulent creuser le sujet, nous recommandons la FAQ EIP-1559 de Vitalik Buterin, traduite par Jean Zundel.

Aujourd’hui est un jour spĂ©cial car nous cĂ©lĂ©brons la 300Ăšme Ă©dition de la newsletter The Daily Gwei ! Pour marquer l’évĂ©nement, j’ai fait Ă©quipe avec mon ami Nader afin de proposer un article explicatif d’EIP-1559. C’est la premiĂšre fois que je co-Ă©cris un article pour la newsletter et je suis particuliĂšrement heureux de le faire Ă  propos de l’un des upgrades les plus importants de l’histoire d’Ethereum. Nader et moi souhaitons aussi remercier Tim Beiko et Trent Van Epps pour leur relecture et leurs retours sur cet article.


On a beaucoup parlĂ© d’EIP-1559 dans la communautĂ© Ethereum depuis qu’il a Ă©tĂ© proposĂ© en Avril 2019. Alors qu’EIP-1559 est sur le point d’ĂȘtre dĂ©ployĂ© en production Ă  l’occasion de l’upgrade London, Nader et moi avons Ă©crit cet article afin de vous proposer un tour d’horizon d’EIP-1559 et des bĂ©nĂ©fices attendus, au-delĂ  de la destruction d’une partie du montant des frais.

Source: MetaMask

Bénéfices essentiels de EIP-1559

  1. Meilleure estimation des frais de transaction
  2. Relation symbiotique entre ETH, le réseau Ethereum et ses utilisateurs
  3. Plus grande fiabilitĂ© de l’inclusion des transactions

Ce que EIP-1559 ne fait pas

  1. Ne réduit pas le prix du gas sur le long terme
  2. Ne rend pas l’ETH dĂ©flationniste par dĂ©faut

Avant de plonger dans EIP-1559, il est important de clarifier quelques aspects souvent mal compris. Tout d’abord, EIP-1559 ne conduit pas en soi Ă  des transactions moins coĂ»teuses Ă  long terme. Les prix du gas fluctuent en fonction de la demande d’émission de transactions relativement Ă  l’espace disponible dans chaque bloc. Cette EIP contribue Ă  lisser les prix du gas en permettant une augmentation modeste de la taille des blocs pendant les pics de demande. Elle n’amĂ©liore pas fondamentalement la scalabilitĂ© de la chaine, et n’est donc pas la solution finale pour rĂ©duire le prix du gas.

D’autre part, mĂȘme si une certaine quantitĂ© d’ETH est brĂ»lĂ©e lors de chaque transaction, on ne peut en conclure que cette diminution va compenser ou mĂȘme excĂ©der le taux d’émission du protocole. Pour que cela se produise, un taux de base de ~150 gwei est nĂ©cessaire pour compenser l’émission sur eth1 (Proof of Work) et un taux de base de ~20 gwei pour celle d’eth2 (Proof of Stake).

MĂ©canisme actuel des enchĂšres pour le prix du gas

Actuellement, Ethereum utilise une systĂšme d’enchĂšres pour dĂ©finir le prix des transactions, ce qui signifie que les utilisateurs proposant les prix les plus hauts sont ceux qui ont le plus de chance d’avoir leurs transactions incluses en premier. Le problĂšme majeur avec ce mĂ©canisme, c’est que les prix peuvent fluctuer de façon trĂšs brutale en fonction des pics soudains de demande pour l’espace libre limitĂ© des blocs d’Ethereum. Les utilisateurs sont toujours dans l’incertitude quant au bon niveau de prix quand ils soumettent une transaction et doivent souvent sur-payer pour ĂȘtre sĂ»rs que celle-ci sera incluse dans le prochain bloc. De façon gĂ©nĂ©rale, EIP-1559 cherche Ă  offrir une meilleure expĂ©rience utilisateur en modifiant le mode d’estimation des frais de transaction et la façon dont le rĂ©seau traite les pics d’utilisation.

Modifications importantes apportées par EIP-1559

  1. Frais de base (Base Fee), Frais de priorité (Priority Fee), et frais maximum (Max Fee)
  2. Taille de bloc variable
  3. Destruction du montant des frais de base

Frais de Base, Frais de Priorité et frais Maximum

  • Frais de Base (Base Fee) – Le prix de gas minimum requis pour qu’une transaction soit incluse dans un bloc. Cette valeur est fixĂ©e par le protocole. Elle est variable, fait partie de l’entĂȘte du bloc, et correspond Ă  la partie des frais de transaction qui est dĂ©truite.
  • Frais de PrioritĂ© (Priority Fee) – Le prix du gas que l’utilisateur est prĂȘt Ă  payer au mineur pour qu’il traite la transaction. Il est dĂ©fini par l’utilisateur, fait partie de la transaction et est payĂ© au mineur (il est attendu que ce fee sera par dĂ©faut de 2 gwei).
  • Frais Maximum (Max Fee) – Le prix du gas le plus Ă©levĂ© que l’utilisateur est prĂȘt Ă  payer pour sa transaction. Il est dĂ©fini par l’utilisateur et fait partie de la transaction.

Une fois EIP-1559 mise en oeuvre, une transaction sera valide seulement si Max Fee est supĂ©rieur Ă  Base Fee plus Priority Fee. Tout excĂ©dent sera remboursĂ© Ă  l’utilisateur.

Refund = Max Fee - (Base Fee + Priority Fee)

Le rĂ©sultat est que les utilisateurs seront beaucoup plus confiants en soumettant une transaction, car ils auront uniquement besoin de provisionner assez pour les frais de base et des frais de prioritĂ© modestes pour s’assurer de l’inclusion de leur transaction dans un bloc. L’utilisateur n’a plus Ă  se soucier de surenchĂ©rir sur les prix de gas parce que l’excĂ©dent lui est retournĂ© plutĂŽt que d’ĂȘtre payĂ© au mineur (ou au validateur).

Avec la crĂ©ation du nouveau type de transaction 1559, les wallets et autres fournisseurs de service et d’infrastructure devront upgrader leurs offres pour ĂȘtre compatible. Le format de transaction actuel continuera cependant Ă  ĂȘtre traitĂ©. Le rĂ©seau interprĂ©tera les frais de prioritĂ© comme Ă©tant la diffĂ©rence entre le prix du gas aujourd’hui dĂ©fini par l’utilisateur et les frais de base du bloc courant. Le seul inconvĂ©nient est que ces transactions ne donneront pas lieu Ă  un remboursement de l’utilisateur s’il y a un excĂ©dent.

Priority Fee = Legacy Gas Price - Base Fee


Un exemple de deux transactions incluse dans le mĂȘme bloc avec des frais de base Ă  15 gwei

Taille de bloc variable

Actuellement, Ethereum a une limite inflexible de 15 millions de gas par bloc. Vous pouvez vous reprĂ©senter la limite du gas comme la taille du bloc qui limite le nombre de transactions qui peuvent ĂȘtre incluses dans un seul bloc. Lorsqu’il y a un pic de demande, les prix du gas montent en flĂšche car les blocs sont pleins et aucun dĂ©passement n’est possible.

EIP-1559 autorise une augmentation temporaire de la taille de bloc afin de traiter un afflux soudain de transactions. Ceci est rendu possible au moyen de deux paramĂštres de bloc : la limite et la cible. La cible correspond Ă  50% de la limite, ce qui signifie que si la cible est de 15 millions de gas, la limite est de 30 millions. IdĂ©alement, la taille de chaque bloc devrait ĂȘtre proche de la cible (50% de la capacitĂ© maximum). Pour s’assurer que les blocs restent proches de la cible, Ethereum rĂ©duira les frais de base lorsque les blocs sont plus petits que la cible, et les augmentera quand ils dĂ©passeront la cible. Il convient aussi de noter que dans ce scĂ©nario, les frais de base augmentent trĂšs vite : 12.5% pour chaque bloc plein. Ce nombre peut ne pas paraĂźtre Ă©levĂ©, mais il signifie que les frais de base dĂ©cupleront en ~20 blocs (~260 secondes), seront multipliĂ©s par 100 en 40 blocs (~520 secondes), et auraient thĂ©oriquement consommĂ© tous les ETH existant aprĂšs ~170 blocs (~2210 secondes). Vous pouvez vous amuser avec cette feuille de calcul de Trent Van Epps pour vous faire une meilleure idĂ©e du fonctionnement de ce systĂšme.

Pour rĂ©sumer : les tailles de bloc variables lissent les prix du gas en permettant une augmentation temporaire de l’espace des blocs. Il en rĂ©sulte Ă  court terme une modĂ©ration de l’augmentation des prix du gas entre les blocs.

Destruction des frais de base

Comme indiquĂ© prĂ©cĂ©demment, les frais de prioritĂ© sont envoyĂ©s au mineur, mais les frais de base sont dĂ©truits et retirĂ©s de la circulation de façon permanente. La raison premiĂšre de ce mĂ©canisme est que si ces frais Ă©taient payĂ©s aux mineurs, ceux-ci seraient incitĂ©s Ă  les maintenir Ă  un niveau Ă©levĂ© afin de maximiser leur profit (et ils pourraient mĂȘme encombrer le rĂ©seau avec des frais de transaction Ă©levĂ©s, dont ils seraient remboursĂ©s en minant un bloc). La destruction des frais de base garantit que leur niveau est indiffĂ©rent aux mineurs

La destruction des frais de base fait de l’ETH une partie inhĂ©rente au protocole Ethereum. Aujourd’hui, tout crypto-actif ou mĂȘme une monnaie fiat pourrait techniquement ĂȘtre utilisĂ© pour payer le coĂ»t de traitement d’une transaction sur Ethereum. Un utilisateur peut soumettre une transaction sans frais et faire affaire avec un mineur en dehors du protocole (c’est ce que permettent les Flashbots). Avec EIP-1559, il devient nĂ©cessaire d’inclure un petit montant en ETH en tant que frais de base pour que le rĂ©seau accepte la transaction comme valide, ce qui assainit la relation entre le crypto-actif ETH et le rĂ©seau Ethereum.

Conclusion

Comme vous pouvez le voir, EIP-1559 va grandement amĂ©liorer l’expĂ©rience utilisateur en matiĂšre de traitement des transactions sur Ethereum. Bien sĂ»r, la plupart des gens se concentrent sur le mĂ©canisme de destruction des frais de base (et nous n’y Ă©chappons pas), mais les bĂ©nĂ©fices globaux d’EIP-1559 vont bien au-delĂ  et auront un impact positif sur les utilisateurs finaux. Si vous souhaitez Ă©tudier plus en profondeur EIP-1559, vous pouvez consulter cette compilation de ressources de Tim Beiko.

Passez une excellente soirée et à demain,
Anthony Sassano


Traduction par PhilH, relecture par Charles 53300 et Noé Curtz, édition sur The Daily Gwei par CookingCryptos.

The post Et voici EIP-1559 ! 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.

Qu’est-ce qui sĂ©curise Bitcoin ?

November 14th 2020 at 10:30

Bitcoin est un concept de monnaie numĂ©rique fonctionnant sur Internet qui a Ă©tĂ© crĂ©Ă© en 2008 par Satoshi Nakamoto. Mis en application Ă  partir du 3 janvier 2009, il a parcouru un long chemin qui l’a menĂ© Ă  devenir ce qu’il est aujourd’hui, Ă  la fois d’un point de vue technique, Ă©conomique et social. NĂ©anmoins, il existe toujours des incomprĂ©hensions Ă  son Ă©gard, y compris chez ceux qui pensent avoir saisi ses principes de base. C’est en particulier le cas de son modĂšle de sĂ©curitĂ© qui reste flou pour beaucoup de personens.

Dans Bitcoin, une foule de notions interviennent. Le systĂšme est fondĂ© sur un rĂ©seau public et dĂ©centralisĂ© de nƓuds qui font tourner un logiciel open source. Ces nƓuds vĂ©rifient des opĂ©rations cryptographiques et entretiennent un registre distribuĂ© et horodatĂ© appelĂ© la chaĂźne de blocs, registre oĂč sont enregistrĂ©es toutes les transactions d’une unitĂ© de compte, le bitcoin. Au sein de ce rĂ©seau, un certain nombre d’acteurs, appelĂ©s des mineurs, utilisent la puissance de calcul de leurs machines afin de valider les transactions effectuĂ©es par le rĂ©seau, et reçoivent en Ă©change une rĂ©munĂ©ration en bitcoins. Tout cela forme un tout harmonique qui permet Ă  Bitcoin d’exister depuis quasiment douze ans.

Cependant, ce qui sĂ©curise Bitcoin, ce n’est pas la cryptographie, la chaĂźne de blocs, le logiciel libre, la dĂ©centralisation ou la puissance de calcul. Ce qui sĂ©curise Bitcoin, c’est l’action combinĂ©e d’individus, de personnes de chair et d’os mues par leurs intĂ©rĂȘts, de gens qui prennent des dĂ©cisions et qui s’exposent Ă  des risques personnels. Bitcoin est en effet un systĂšme Ă©conomique et, en tant que tel, base sa sĂ©curitĂ© sur le comportement intĂ©ressĂ© des ĂȘtres humains1.

 

Qu’est-ce qui prĂ©serve la qualitĂ© de l’infrastructure logicielle ?

Bitcoin est un protocole de communication qui permet l’existence et la circulation d’une unitĂ© de compte numĂ©rique, le bitcoin. Ce protocole est un ensemble de rĂšgles et ne peut donc pas directement ĂȘtre utilisĂ© par un individu : il faut pour cela qu’il existe une implĂ©mentation logicielle, Ă  savoir un programme qui respecte et vĂ©rifie ces rĂšgles.

L’écosystĂšme autour de Bitcoin repose donc sur ces implĂ©mentations logicielles, qui peuvent ĂȘtre complĂštes (nƓuds du rĂ©seau) ou partielles (portefeuilles lĂ©gers). Bien Ă©videmment, les implĂ©mentations complĂštes sont les plus essentielles Ă  la sĂ©curitĂ© de Bitcoin, puisque ce sont elles qui servent Ă  valider les transactions et Ă  miner les blocs. En particulier, Bitcoin Core, l’implĂ©mentation de rĂ©fĂ©rence de Bitcoin (BTC), joue un rĂŽle central dans l’infrastructure du rĂ©seau.

Comme tous les programmes informatiques complexes, Bitcoin Core n’est pas exempt de faiblesses, ce qui au cours de son histoire s’est matĂ©rialisĂ© par deux incidents majeurs :

  • En aoĂ»t 2010, une faille dans le systĂšme des transactions (value overflow) avait permis Ă  une personne de crĂ©er plus de 184 milliards de bitcoins Ă  partir de rien ! Cet incident avait heureusement pu ĂȘtre corrigĂ© dans les heures qui avaient suivi grĂące Ă  la mobilisation des mineurs qui avaient appliquĂ© un patch correctif. À l’époque, cela n’avait pas Ă©tĂ© dommageable pour Bitcoin, qui ne gĂ©rait que peu de valeur.
  • En mars 2013, un dĂ©faut contenu dans la mise Ă  jour du code avait provoquĂ© la sĂ©paration accidentelle du rĂ©seau pendant plusieurs heures. Bitcoin Ă©tait alors beaucoup plus utilisĂ© et cette sĂ©paration momentanĂ©e avait notamment entraĂźnĂ© la rĂ©alisation d’une double dĂ©pense par un utilisateur.

C’est pour cela qu’il est crucial que le logiciel derriĂšre Bitcoin soit bien maintenu, optimisĂ©, amĂ©liorĂ©. Bitcoin reprĂ©sente aujourd’hui prĂšs de 300 milliards de dollars et dĂ©place des dizaines de milliards de dollars chaque jour, et par consĂ©quent il serait dĂ©sastreux qu’un dysfonctionnement majeur survienne.

Pour assurer la sĂ©curitĂ© du logiciel, il existe donc des dizaines de personnes, identifiĂ©es ou anonymes, qui s’attellent Ă  scruter et Ă  perfectionner le code, Ă  temps plein ou Ă  temps partiel. Puisque Bitcoin Core est un logiciel libre disponible en source ouverte sur Internet, n’importe qui peut consulter le code, vĂ©rifier qu’il est conforme au rĂ©sultat attendu ou mĂȘme proposer de le modifier pour l’amĂ©liorer ! Tel que l’expliquait Satoshi Nakamoto en dĂ©cembre 2009 :

Être accessible en source ouverte signifie que n’importe qui peut examiner le code de maniĂšre indĂ©pendante. S’il s’agissait d’une source fermĂ©e, personne ne pourrait vĂ©rifier la sĂ©curitĂ©. Je pense qu’il est essentiel pour un programme de cette nature d’ĂȘtre open source.

Cette ouverture, couplĂ©e Ă  une dette technique limitĂ©e, donne Ă  Bitcoin une sĂ»retĂ© plus grande que de nombreux systĂšmes informatiques. En effet, au vu des sommes en jeu, la rĂ©compense pour l’exploitation rĂ©ussie d’une faille dans le code serait Ă©norme, ce qui renforce la confiance qu’on peut avoir dans le logiciel au cours du temps (effet Lindy).

De plus, les failles dans le code sont, outre leur raretĂ©, le plus souvent trĂšs subtiles, ce qui fait que ce sont les dĂ©veloppeurs bienveillants qui les dĂ©couvrent et qui les rapportent. On peut par exemple citer le bogue d’inflation trouvĂ© et rĂ©vĂ©lĂ© en septembre 2018 par Awemany, dĂ©veloppeur pour Bitcoin Unlimited, ou la faille permettant des attaques par dĂ©ni de service rapportĂ©e en juin 2018 par Braydon Fuller, dĂ©veloppeur pour Bcoin, et rĂ©vĂ©lĂ©e publiquement plus deux ans plus tard, en septembre 2020.

Enfin, il faut spĂ©cifier que l’infrastructure logicielle n’est pas maintenue gratuitement et qu’elle est soutenue financiĂšrement par les organisations et les individus dont l’activitĂ© dĂ©pend de la qualitĂ© du fonctionnement du rĂ©seau. C’est ainsi que des entreprises impliquĂ©es dans Bitcoin acceptent de rĂ©munĂ©rer les principaux dĂ©veloppeurs de Bitcoin Core, pas par charitĂ©, mais parce qu’elles ont quelque chose Ă  gagner.

Tout ceci fait que la sĂ©cuitĂ© du logiciel s’amĂ©liore au cours du temps, que les vulnĂ©rabilitĂ©s sont dĂ©tectĂ©es et maĂźtrisĂ©es et que, en presque douze ans d’existence, seules deux d’entre elles ont provoquĂ© un incident majeur. Bitcoin ne repose donc pas sur des logiciels magiques qui fonctionneraient parfaitement bien, mais sur l’action des dĂ©veloppeurs qui maintiennent des implĂ©mentations faillibles et sur l’aide des mĂ©cĂšnes qui financent ce dĂ©veloppement.

 

Qu’est-ce qui assure le bon traitement des transactions ?

Bitcoin permet Ă  quiconque d’envoyer des fonds Ă  n’importe qui d’autre, quel que soit le moment, oĂč que se trouve le destinataire dans le monde pourvu qu’il dispose d’un accĂšs Ă  Internet. Il est ainsi rĂ©sistant Ă  la censure, c’est-Ă -dire qu’il est trĂšs difficile pour une entitĂ© d’empĂȘcher arbitrairement une transaction d’ĂȘtre rĂ©alisĂ©e.

La rĂ©sistance Ă  la censure est trĂšs importante car si Bitcoin n’avait pas cette propriĂ©tĂ©, il ne pourrait tout simplement pas survivre. Il deviendrait en effet un systĂšme bancaire comme un autre, soumis aux rĂ©glementations invasives des États : il devrait s’adapter Ă  l’instar de PayPal, ou mourir sous les coups des interventions Ă©tatiques, destin funeste qu’ont connu e-gold ou Liberty Reserve en leur temps.

Le bon traitement des transactions dans Bitcoin implique donc deux garanties qui le distinguent des systĂšmes bancaires traditionnels :

  • Toute transaction qui paie un montant correct de frais ne peut pas ĂȘtre dĂ©laissĂ©e (sĂ©curitĂ© a priori) ;
  • Toute transaction qui a Ă©tĂ© confirmĂ©e doit demeurer dans le registre et ne peut pas faire l’objet d’une double dĂ©pense (sĂ©curitĂ© a posteriori).

Ce bon traitement est assurĂ© par ce qu’on appelle le minage. Les mineurs, qui font partie du rĂ©seau, reçoivent les transactions des utilisateurs et les incluent dans des blocs. Ils rattachent ces blocs Ă  la chaĂźne par la rĂ©solution d’un problĂšme mathĂ©matique nĂ©cessitant une dĂ©pense d’énergie Ă©lectrique (preuve de travail) et sont en Ă©change rĂ©compensĂ©s par les bitcoins nouvellement crĂ©Ă©s (6,25 bitcoins par bloc actuellement) et par les frais payĂ©s par les transactions. Pour dĂ©terminer la chaĂźne valide les nƓuds suivent le principe de la chaĂźne la plus longue, c’est-Ă -dire qu’ils considĂšrent que la chaĂźne contenant le plus de preuve de travail (grosso modo celle avec le plus de blocs) est la chaĂźne valide. Cela permet au rĂ©seau d’arriver Ă  un consensus sur l’état du systĂšme.

Bitcoin repose donc sur la dĂ©pense d’énergie pour fonctionner, car c’est elle qui dĂ©termine le caractĂšre infalsifiable de la chaĂźne et des bitcoins crĂ©Ă©s. Le taux de hachage, qui dĂ©signe le nombre de calculs par seconde rĂ©alisĂ©s par le rĂ©seau, atteint aujourd’hui les 130 EH/s, Ă  savoir 130 milliards de milliards de calculs par seconde. Cette considĂ©rable force de calcul consomme aujourd’hui, selon certaines estimations, plus de 82 TWh par an, soit une dĂ©pense Ă©nergĂ©tique Ă©galant la consommation d’électricitĂ© de pays comme la Belgique ou la Finlande.

 

Taux de hachage Bitcoin BTC 2010 2020
Évolution du taux de hachage de Bitcoin entre 2010 et 2020 (Bitcoin.com Charts)

 

NĂ©anmoins, en dĂ©pit de son rĂŽle central, ce n’est pas sur cette Ă©nergie que se fonde la sĂ©curitĂ© du minage. En effet, la sĂ©curitĂ© vient de la concurrence entre les mineurs, et pas de l’énergie totale dĂ©pensĂ©e. Comme l’écrivait Satoshi Nakamoto dans le livre blanc de Bitcoin en 2008 :

Le systĂšme est sĂ©curisĂ© tant que les nƓuds honnĂȘtes contrĂŽlent collectivement plus de puissance de calcul qu’un groupe de nƓuds qui coopĂ©reraient pour rĂ©aliser une attaque.

L’important ce n’est pas que le taux de hachage de Bitcoin soit le plus haut possible, c’est que les mineurs disposant d’une puissance de calcul non nĂ©gligeable soient « honnĂȘtes », c’est-Ă -dire qui soient prĂȘts Ă  miner systĂ©matiquement toutes les transactions payant un montant correct de frais (pas de censure a priori) et Ă  toujours construire leurs blocs Ă  partir de la plus longue chaĂźne (pas de rĂ©organisation de chaĂźne).

Imaginons (cas pessimiste) que les États membres de l’ONU se mettent d’accord sur la dangerositĂ© de Bitcoin et dĂ©crĂštent l’interdiction de certaines transactions sur Bitcoin, les transactions de mĂ©lange de piĂšces au nom de la lutte contre le blanchiment d’argent par exemple. Dans ce cas, les mineurs pourraient ĂȘtre soumis Ă  de fortes pressions de la part de leurs autoritĂ©s respectives, et devraient faire le choix de continuer Ă  ĂȘtre honnĂȘtes en se dĂ©plaçant dans un pays non concernĂ© ou en minant illĂ©galement, ce qui constitue dans les deux cas un risque, ou de devenir des attaquants en suivant la loi. Cette rĂ©glementation des mineurs par les États permettrait, si leur matĂ©riel reprĂ©sentaient plus de la moitiĂ© de la puissance de calcul du rĂ©seau, d’empĂȘcher toute confirmation d’une transaction illĂ©gale par le biais d’une attaque des 51 % mondiale.

La solution au problĂšme proviendrait des individus et des groupes d’individus qui seraient prĂȘts Ă  miner des transactions dĂ©clarĂ©es comme illĂ©gales, et qui resteraient donc honnĂȘtes du point de vue de Bitcoin. Le risque pris par ces mineurs pourrait alors ĂȘtre compensĂ© par les frais des transactions censurĂ©es, qui pourraient s’avĂ©rer ĂȘtre trĂšs Ă©levĂ©s, surtout si des montants astronomiques Ă©taient en jeu.

C’est pour cela que la bon fonctionnement des transactions vient du comportement des mineurs, pas uniquement de la puissance de calcul du rĂ©seau. Pour que Bitcoin soit correctement sĂ©curisĂ©, il faut donc que les mineurs soient nombreux (partage du risque) et se trouvent Ă  des endroits diffĂ©rents du monde (dĂ©centralisation).

 

Carte de localisation des mineurs avril 2020
Répartition géographique des mineurs utilisant les coopératives BTC.com, Poolin et ViaBTC en avril 2020 (Cambridge Center for Alternative Finance)

 

 

Qu’est-ce qui garantit la limite des 21 millions de bitcoins ?

Lorsqu’on entend parler du bitcoin, il ne faut pas attendre longtemps avant que sa politique monĂ©taire singuliĂšre soit Ă©voquĂ©e. Le bitcoin suit en effet un processus d’émission trĂšs prĂ©cis qui limite sa quantitĂ© d’unitĂ©s en circulation Ă  21 000 000 : les fameux 21 millions de bitcoins.

Bien que le principe soit briĂšvement dĂ©crit dans le livre blanc, cette politique monĂ©taire n’a Ă©tĂ© dĂ©finie rigoureusement par Satoshi Nakamoto que le 8 janvier 2009 dans son annonce du lancement de Bitcoin :

La circulation totale sera de 21 000 000 de piĂšces. Elle sera distribuĂ© aux nƓuds du rĂ©seau lorsqu’ils crĂ©eront des blocs, le montant Ă©tant divisĂ© par deux tous les 4 ans.

les 4 premiÚres années : 10 500 000 piÚces
les 4 années suivantes : 5 250 000 piÚces
les 4 années suivantes : 2 625 000 piÚces
les 4 années suivantes : 1 312 500 piÚces
etc


Cela fait du bitcoin une monnaie dure Ă  produire Ă  l’inverse des monnaies fiat imposĂ©es par les États, comme l’euro ou le dollar, dont la gestion de la masse monĂ©taire est dĂ©lĂ©guĂ©e Ă  des banques centrales. Bitcoin donne ainsi aux individus la possibilitĂ© d’épargner une monnaie qui ne perd pas en valeur au cours du temps, et qui empĂȘche au passage les acteurs financiers proches du pouvoir de profiter de l’effet Cantillon.

La politique monĂ©taire du bitcoin constitue donc une propriĂ©tĂ© rĂ©volutionnaire qui n’a mĂȘme pas Ă©tĂ© appliquĂ©e par le passĂ© et beaucoup la mettent en valeur comme une propriĂ©tĂ© gravĂ©e dans le marbre qui ne pourrait absolument pas ĂȘtre modifiĂ©e. NĂ©anmoins ce n’est pas le cas, et cette « rĂ©sistance Ă  l’inflation » doit ĂȘtre, tout comme la rĂ©sistance Ă  la censure, sĂ©curisĂ©e par des individus qui agissent en ce sens.

Bitcoin est un protocole de communication, un ensemble de rĂšgles qui permettent Ă  des gens de transfĂ©rer de la valeur entre eux, et en cela il peut Ă©voluer. Les rĂšgles de consensus qui dĂ©finissent Bitcoin ne sont en effet pas figĂ©es et peuvent faire l’objet de changements, comme l’ont montrĂ© les diffĂ©rentes amĂ©liorations qui ont jalonnĂ© l’existence de Bitcoin telles que P2SH, les verrous temporels ou SegWit.

De plus, l’évolution du protocole peut se faire dans un sens non prĂ©vu originellement, ce qui a eu lieu Ă  de multiples reprises dans l’histoire des cryptomonnaies.

En juin 2016, Ethereum a ainsi violĂ© l’immuabilitĂ© de sa propre chaĂźne en annulant le piratage d’un contrat autonome (TheDAO) oĂč 3,6 millions d’éthers, qui reprĂ©sentaient plus de 45 millions d’euros. Cette somme dĂ©robĂ©e reprĂ©sentait 4,4 % de la quantitĂ© totale d’éthers en circulation, et une majoritĂ© Ă©conomique (Ă  commencer par Vitalik Buterin) a donc dĂ©cidĂ© de revenir sur ce transfert le 20 juin. Un groupe dissident a refusĂ©, ce qui a crĂ©Ă© une autre chaĂźne oĂč le piratage Ă©tait toujours prĂ©sent, qui s’appelle aujourd’hui Ethereum Classic.

De mĂȘme, Bitcoin a changĂ© depuis ses dĂ©buts et n’est plus le mĂȘme qu’en 2011. Le principal changement n’est pas un modification du protocole en soi, mais un changement de vision : les visions d’une monnaie d’échange et d’un moyen de transfert anonyme, qui Ă©taient prĂ©dominantes aux dĂ©buts de Bitcoin, se sont estompĂ©es au profit de la vision d’un or numĂ©rique qui servirait de monnaie de rĂ©serve. MĂȘme si les premiĂšres visions subsistent au travers du projet Lightning et des logiciels dĂ©diĂ©s Ă  la confidentialitĂ© (Wasabi, Samourai, JoinMarket), elles sont devenues nĂ©anmoins minoritaires dans la communautĂ© de Bitcoin. En effet, les gens s’enthousiasment plus aujourd’hui pour les investissements de grandes entreprises comme MicroStrategy et Square, ou pour l’intĂ©gration 100 % custodiale du bitcoin dans PayPal, que pour l’échange commercial ou pour l’usage rĂ©alisĂ© sur le dark web.

 

Visions de Bitcoin Nic Carter Hasu
Visions de Bitcoin (Nic Carter et Hasu).

 

Ce changement de narration s’est accompagnĂ© d’un maintien conservateur du protocole, notamment par le biais d’une restriction de sa capacitĂ© transactionnelle. Cette restriction a pour effet de prĂ©server la dĂ©centralisation du minage donc la sĂ©curitĂ© de la chaĂźne, mais aussi d’accroĂźtre considĂ©rablement les frais de transaction payĂ©s par les utilisateurs, qui peuvent actuellement ĂȘtre de plusieurs euros en moyenne pour un traitement rapide par le rĂ©seau2.

Face Ă  ces changements, nous sommes donc en droit de nous demander quelle est la force qui empĂȘche la politique monĂ©taire de Bitcoin d’ĂȘtre modifiĂ©e, ce qui nous amĂšne naturellement Ă  la question plus gĂ©nĂ©rale de la gouvernance de Bitcoin, c’est-Ă -dire la maniĂšre dont il est dirigĂ©. Qui dĂ©cide de l’avenir du protocole ?

D’une part, certains pensent que la gouvernance est la prĂ©rogative des dĂ©veloppeurs du protocole, que ceux-ci sont en charge de ce qui doit ou non ĂȘtre intĂ©grĂ©. Pour Bitcoin, ce serait le cas de l’implĂ©mentation de rĂ©fĂ©rence, Bitcoin Core, et de son mainteneur principal, Wladimir van der Laan, qui possĂšdent les droits sur le dĂ©pĂŽt GitHub. Il est en effet vrai que les dĂ©veloppeurs ont une certaine influence sur le protocole en acceptant ou en refusant d’inclure une modification : par effet d’inertie, ils ont un poids dans les choix qui vont ĂȘtre faits, car tout changement non consenti par eux devrait ĂȘtre implĂ©mentĂ© par une nouvelle Ă©quipe peut-ĂȘtre moins expĂ©rimentĂ©e et moins bien financĂ©e. NĂ©anmoins, si un changement majeur et controversĂ© en venait Ă  ĂȘtre proposĂ© (comme le serait probablement une violation de la politique monĂ©taire du bitcoin), les dĂ©veloppeurs n’auraient aucune chance de voir leur modification ĂȘtre acceptĂ©e. C’est notamment ce qui s’est passĂ© pour Bitcoin ABC, l’implĂ©mentation principale du protocole Bitcoin Cash, qui se voit aujourd’hui ĂȘtre exclue pour avoir tentĂ© de rediriger 8 % de la rĂ©compense de bloc Ă  ses fins.

D’autre part, une opinion assez rĂ©pandue suppose que ce sont les mineurs qui doivent dĂ©cider de l’évolution du protocole, notamment par le biais de votes proportionnĂ©s Ă  leur puissance de calcul. Ces mineurs sont en effet garants de l’intĂ©gritĂ© de la chaĂźne de blocs et possĂšdent un rĂŽle majeur dans Bitcoin. Il est donc Ă©vident qu’une version de Bitcoin privilĂ©giĂ©e par les mineurs a plus de chances de prospĂ©rer qu’une version concurrente qui serait plus sensible Ă  la censure. Cependant, ce ne sont pas les mineurs qui possĂšdent le rĂ©el pouvoir sur le protocole, pour la simple et bonne raison que ce ne sont pas eux qui contribuent Ă  valoriser l’unitĂ© de compte. En raisonnant par l’absurde, on pourrait dire que si les mineurs Ă©taient rĂ©ellement en charge du protocole, le systĂšme Ă©conomique de Bitcoin serait vouĂ© Ă  l’échec : ils seraient en effet incitĂ©s Ă  augmenter leurs revenus par la crĂ©ation monĂ©taire Ă  l’instar des banques centrales.

Tout ceci nous amĂšne Ă  la troisiĂšme catĂ©gorie d’acteurs impliquĂ©s dans Bitcoin : les utilisateurs, ou plutĂŽt les marchands, c’est-Ă -dire les personnes qui acceptent le bitcoin comme moyen de paiement pour un bien ou un service. Cette catĂ©gorie des marchands est Ă  prendre au sens large et inclut, outre les commerçants classiques, les Ă©pargnants et les spĂ©culateurs qui Ă©changent de l’euro contre du bitcoin. Le fait est que ce sont ces utilisateurs qui, par l’usage direct ou indirect d’un nƓud complet, dĂ©cident rĂ©ellement de la direction dans laquelle Bitcoin doit aller, car ce sont eux qui apportent de la valeur au bitcoin.

Lorsqu’en novembre 2017 il a Ă©tĂ© question de doubler la capacitĂ© transactionnelle de Bitcoin par le biais d’une mise Ă  niveau appelĂ©e SegWit2X, les utilisateurs ont refusĂ©. Cette proposition, soutenue par la majoritĂ© des mineurs et par une grande part des entreprises du milieu, a Ă©tĂ© annulĂ©e avant son activation au vu de l’impopularitĂ© de celle-ci. Ainsi, c’est le sectarisme des utilisateurs et des dĂ©tenteurs de bitcoins, attisĂ© par un certain nombre d’influenceurs, qui a prĂ©valu dans l’affaire, chose que pressentait Satoshi Nakamoto dĂšs dĂ©cembre 2010 :

Les utilisateurs de Bitcoin pourraient devenir de plus en plus sectaires à propos de la limitation de la taille de la chaüne pour que son accùs reste facile pour beaucoup d’utilisateurs et pour les petits appareils.

Le modĂšle Ă©conomique de Bitcoin est ainsi protĂ©gĂ© par ces marchands qui, par le biais d’une conservation plus ou moins longue, sont incitĂ©s Ă  faire en sorte que la valeur du bitcoin ne baisse pas, et mĂȘme qu’elle augmente. Il est donc dans leur intĂ©rĂȘt de ne pas modifier la politique monĂ©taire dĂ©flationniste du bitcoin. De plus, la limite des 21 millions de bitcoins est un point de Schelling fort qui dĂ©vantagerait toute tentative de changement.

NĂ©anmoins, ce modĂšle n’est pas magique et, tout comme le minage, repose essentiellement sur la rĂ©sistance individuelle des marchands aux pressions, qu’elles soient intĂ©rieures (la proposition d’une Ă©mission monĂ©taire pour protĂ©ger la chaĂźne par exemple) ou extĂ©rieures.

Le cas d’une pression extĂ©rieure est le plus parlant. De maniĂšre pessimiste, on pourrait imaginer qu’un dĂ©cret appliquĂ© par les États membres de l’ONU impose par la loi une crĂ©ation monĂ©taire qui reviendrait Ă  une banque centrale mondiale, et qui rendrait illĂ©gale la version dĂ©flationniste de Bitcoin. Dans ce dernier cas, le destin de Bitcoin serait entre les mains aux marchands, qui devraient faire preuve de courage en refusant ce dĂ©cret et en acceptant le bitcoin interdit, soit en toute illĂ©galitĂ© dans leur pays, soit dans un pays non concernĂ©.

Ainsi, Ă  l’instar du bon traitement des transactions qui est garanti par les mineurs et renforcĂ© par la dĂ©centralisation du minage, la dĂ©fense de la politique monĂ©taire est assurĂ©e par les marchands et affermie grĂące Ă  leur degrĂ© d’indĂ©pendance : moins il y a de marchands capables de continuer leur activitĂ© dans l’illĂ©galitĂ© ou depuis des lieux non rĂ©glementĂ©s, notamment par la gestion de leur propre nƓud complet, moins le bitcoin est rĂ©sistant Ă  l’inflation.

 

Conclusion

Bitcoin est un systĂšme Ă©conomique basĂ© sur l’action d’individus libres. Sa sĂ©curitĂ© ne provient donc pas des concepts sous-jacents Ă  son fonctionnement comme la cryptographie, la chaĂźne de blocs, le logiciel libre, la dĂ©centralisation ou la puissance de calcul, mais de la volontĂ© humaine des personnes qui Ɠuvrent chaque jour Ă  sa survie. Bitcoin ne serait pas lĂ  sans ses dĂ©veloppeurs bienveillants, ses mineurs soucieux de la rĂ©sistance de la chaĂźne et ses marchands prĂȘts Ă  tout pour conserver un protocole sain.

Bitcoin peut ainsi ĂȘtre dĂ©nigrĂ©, rĂ©glementĂ©, interdit, attaquĂ©, combattu, mais il ne pourra pas ĂȘtre dĂ©truit dans son principe tant qu’il y aura des gens derriĂšre lui. C’est pourquoi sa communautĂ© est si cruciale : mĂȘme dans les pires moments de doute, il y aura toujours des personnes prĂȘtes Ă  programmer, Ă  miner et Ă  valoriser le bitcoin. Ainsi, malgrĂ© les restrictions imposĂ©es par les États et les efforts des banques centrales pour le singer, Bitcoin est lĂ  pour rester. Et c’est tant mieux.

 


Notes

1. ↑ Je tire cette rĂ©flexion de la thĂ©orie d’Eric Voskuil et en particulier de son texte sur le principe du partage du risque dans lequel il observe que le risque individuel d’accepter ou de miner le bitcoin dĂ©pend du nombre de gens qui le prennent.

2. ↑ Ces deux changements, relatifs Ă  Bitcoin et Ă  Ethereum, ne sont pas forcĂ©ment de mauvaises Ă©volutions : le monde a probablement besoin d’une rĂ©serve de valeur Ă  hauts frais trĂšs sĂ©curisĂ©e et trĂšs stable (surtout lorsqu’on constate les derniers agissements des États et des banques centrales) et d’une plateforme de contrats autonomes qui puisse ĂȘtre modifiĂ©e socialement dans le cas oĂč 5 % des fonds sont concernĂ©s. NĂ©anmoins, ces changements indiquent que certains principes peuvent s’éroder et que les protocoles peuvent effectivement Ă©voluer dans un sens non prĂ©vu originellement.

Ethereum France Live: se préparer à Ethereum 2 avec Mamy Ratsimbazafy

November 13th 2020 at 22:38

Mercredi 18 Novembre, Ethereum France reçoit Mamy Ratsimbazafy pour une prĂ©sentation de l’Ethereum 2 Ă  l’heure du dĂ©jeuner sur Youtube.

L’Architecture par Charles AndrĂ© van Loo (1705–1765)

L’avĂšnement d’Ethereum 2 est proche, c’est une question de semaines depuis que le contrat de dĂ©pĂŽt pour participer Ă  la preuve d’enjeu (Proof of Stake) d’Ethereum a Ă©tĂ© dĂ©ployĂ© le 4 novembre. La crĂ©ation du premier bloc de la beacon-chain, qui servira de coordinateur du rĂ©seau Ethereum 2, est prĂ©vue au plus tĂŽt pour le mercredi 2 dĂ©cembre 2020. 

Mamy avait déjà accordé une interview à Ethereum France que vous pouvez retrouver ici.

Pour vous prĂ©senter tout ce que vous devez savoir sur cette Ă©volution et rĂ©pondre Ă  vos questions, Ethereum France recevra l’un de ses core dev: le français Mamy Ratsimbazafy qui dĂ©veloppe le client Ethereum 2 Nimbus chez Status.

Rendez-vous Ă  12h30 mercredi 18 novembre sur notre chaĂźne Youtube

The post Ethereum France Live: se préparer à Ethereum 2 avec Mamy Ratsimbazafy first appeared on Ethereum France.
❌