Actu-crypto

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

Les Ă©vĂšnements Ethereum de 2023

December 6th 2022 at 19:13

Depuis la DevCon, la communauté Ethereum est à la recherche des prochaines occasions pour se retrouver.
Nous sommes donc ravis de partager cette liste d’évĂšnements Ethereum pour l’annĂ©e 2023.

Compiled the Ethereum events list for 2023

Missing any? Ping me📍

Source & Links ➡https://t.co/5OFweLwgUK pic.twitter.com/i4WcDPkgw8

— Nathan Sexer | nethan.eth (@NathanSexer) December 6, 2022
Liste d’évĂšnements Ethereum

En 2022, nous avions listé pas moins de 70 évÚnements se déroulant dans une trentaine de pays.
Nous incluons dans cette liste de 2023 les confĂ©rences, Ă©vĂšnements et hackathons — online et offline — que nous jugeons de qualitĂ©, en lien avec Ethereum au sens large.

Nous attendons encore l’annonce de nombreux Ă©vĂšnements dont la liste des cĂ©lĂšbres hackathons d’ETHGlobal, qui devraient alimenter cette liste avec des dates pour les hackers dans le monde entier. Il manque Ă©galement la date dĂ©finitive d’EthCC (qui devrait se dĂ©rouler en Juillet) ou encore le lieu de la prochaine DevCon (dĂ©battu dans ce forum. Ont Ă©tĂ© proposĂ©s: Ireland, Nigeria, Taiwan, Italie, Serbie, Peru, Bulgaria, Inde, Israel, Portugal, GrĂšce, Vietnam, UAE, Singapour, Turquie). A suivre!

Ces Ă©vĂšnements jouent un rĂŽle primordial dans la communautĂ© Ethereum. Ce sont des occasions de rencontrer les acteurs du monde entier, dĂ©couvrir les derniĂšres avancĂ©es technologiques et ressentir l’effervescence de cet Ă©cosystĂšme. À ne pas manquer donc.

Si des Ă©vĂšnements manquent ou des informations venaient Ă  changer, n’hĂ©sitez pas Ă  rĂ©pondre au thread public ci-dessus ou contacter @NathanSexer sur Twitter, nous tĂącherons de maintenir cette liste Ă  jour.

Pour accĂ©der au calendrier, c’est par ici: « 2023 Ethereum Events« .


Pour suivre Ethereum-France ⬇

The post Les Ă©vĂšnements Ethereum de 2023 first appeared on Ethereum France.

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.

RĂ©capitulatif de la DevCon VI

October 27th 2022 at 18:35

L’équipe d’Ethereum-France Ă©tait prĂ©sente Ă  la sixiĂšme Ă©dition de la Devcon organisĂ©e par la Fondation Ethereum qui s’est tenue du 11 au 14 Octobre 2022 Ă  Bogota, en Colombie. On vous raconte.

Un grand merci Ă  SolĂšne, contributrice principale de cet article, ainsi qu’à Ugo, RĂ©mi, Hazelstar et Nathan pour leur participation.

AprĂšs un report de la DevCon sur trois annĂ©es consĂ©cutives suite au contexte sanitaire, la confĂ©rence a fait son retour avec un franc succĂšs Ă  Bogota oĂč plus de 6000 visiteurs provenant de 113 pays Ă©taient au rendez-vous ! Bogota Ă©tait au centre de toute attention dans l’écosystĂšme crypto et en particulier au sein de la communautĂ© Ethereum. En effet, la DevCon est un Ă©vĂ©nement consacrĂ© aux dĂ©veloppeurs Ethereum oĂč 80% du contenu proposĂ© est technique.

LA PROGRAMMATION

Durant 4 jours ce sont 444 intervenants, de plus de 20 nationalitĂ©s dont 37% parlant espagnol, qui ont animĂ© 200h de programmation sur 9 scĂšnes diffĂ©rentes. Parmi ces scĂšnes, certaines Ă©taient orientĂ©es vers la thĂ©orie et d’autres consacrĂ©es Ă  la mise en pratique de cette thĂ©orie. Un large choix de tracks Ă©tait proposĂ©:

  • Cryptoeconomics
  • Developer infrastructure
  • Governance & coordination
  • Layer 1 Protocol
  • Layer 2S
  • Opportunity & Global Impact
  • Security
  • Staking & Validator Experience
  • UX & Design
  • ZKPS: Privacy, Identity, Infrastructure

L’édition DevCon s’est dĂ©roulĂ©e un mois aprĂšs “The Merge” et ce sujet n’est pas passĂ© inaperçu puisque plusieurs confĂ©rences ont Ă©tĂ© consacrĂ©es Ă  la vision future d’Ethereum aprĂšs cette premiĂšre mise Ă  jour importante. Pour rappel, “The Merge” signifie la transition du mĂ©canisme de consensus du rĂ©seau Ethereum allant du proof-of-work vers le proof-of-stake. (Plus d’information dans cet article publiĂ© pour l’occasion)

Lors de la cĂ©rĂ©monie d’ouverture, Vitalik Buterin a rappelĂ© dans son talk classique “Ethereum in 30min”, les quatre prochaines Ă©tapes vers Ethereum 2.0 aprĂšs celle de The Merge : The Surge, The Verge, The Purge et The Splurge.

  • The Surge : amĂ©lioration de la scalabilitĂ© grĂące aux rollups, au danksharding et aux ZK-SNARKs
  • The Verge : remplacer les Merkle trees par des structures de donnĂ©es plus efficaces qui permettent aux nƓuds Ethereum d’ĂȘtre beaucoup plus lĂ©gers
  • The Purge : Ă©liminer les anciennes donnĂ©es et la dette technique
  • The Splurge : abstraction de compte, amĂ©liorations EVM, PBS

LES SUJETS PHARES DE CETTE 6EME ÉDITION
  1. Les MEVs 

Un des sujets phares de cette Ă©dition, et de cryptotwitter durant celle-ci, fut la MEV (Miner/Maximum Extractable Value) et la part grandissante de Flashbots dans l’écosystĂšme Ethereum, notamment autour de leur programme de validation de blocs qui exclut les transactions de Tornado Cash suite aux sanctions de l’OFAC (voir plus ici).

Pendant DevCon, Flashbots a fait une annonce sur la scĂšne principale concernant le dĂ©veloppement d’une nouvelle version de sa technologie consistant Ă  recueillir le maximum de valeur pouvant ĂȘtre extrait de la production de blocs d’Ethereum. 

Le projet se nomme SUAVE, un nom de code signifiant « Single Unifying Auctions for Value Expression« . Il s’agit d’une solution rĂ©pondant aux problĂšmes de censure existants sur Ethereum. Le logiciel serait un constructeur de blocs entiĂšrement dĂ©centralisĂ©, open-source et compatible avec l’EVM, puis pris en charge par plusieurs chaĂźnes. L’équipe de Flashbots a expliquĂ© que le projet Ă©tait “à 100 % contre la censure”.

Répertoire de talks intéressants à ce sujet :

  1.  Les Zero Knowledge

Les organisateurs de la DevCon ont consacrĂ© une salle aux Zero Knowledge (Zk-Proofs, Zk-Rollups, Zk-EVMs). C’est un sujet encore complexe mais les ZKPs sont d’une importance capitale pour les annĂ©es Ă  venir dans l’écosystĂšme. Ils reprĂ©sentent une solution d’avenir pour assurer la scalabilitĂ© et la confidentialitĂ© du rĂ©seau Ethereum. 

Zoom sur un talk de Ian Miers par Hazelstar

Hazelstar a rapportĂ© un talk marquant de Ian Miers concernant l’évolutivitĂ© est ennuyeuse, la confidentialitĂ© est morte : les preuves ZK, Ă  quoi servent-elles ?

Ian Miers part du constat qu’aujourd’hui les technologies des Zk-VMs et Zk Rollups ne sont pas totalement zero-knowledge, et qu’il est important de se demander quelle combinaison les ZKPs et la blockchain peuvent donner, qui ne soit pas juste “des feuilles de calculs plus rapides sur la blockchain”. Ian propose de nous donner sa dĂ©finition des ZKPs: “confidentialitĂ© (cache des donnĂ©es dans une finalitĂ© de paiements privĂ©s), compression (pour les Zk-SNARKs, c’est comme ça que l’on obtient l’évolutivitĂ© et que l’on Ă©conomise le gas) et crĂ©dibilitĂ© (d’un point de vue cryptographique, c’est sensĂ© et garanti)”. Et insiste sur la crĂ©dibilitĂ© dans des contextes divers tels que la rĂ©sistance Ă  la censure aux niveaux de rollups, contrer le blanchiment d’argent, et la crĂ©dibilitĂ© de l’identitĂ© en ligne.

  1. L’account abstraction

L’account abstraction est une promesse pour l’adoption des cryptos grĂące Ă  une amĂ©lioration de l’expĂ©rience utilisateur et de la sĂ©curitĂ© afin de conduire Ă  de nouvelles expĂ©riences. Vitalik affirme que le Layer 2 est un terrain naturel pour tester cette abstraction.

 Zoom sur « Why Account Abstraction is a Game-Changer for Dapps » (Julien Niset, co-fondateur d’Argent)

Dans ce talk, Julien Niser, co-fondateur et CSO d’Argent (smart contract wallet) rĂ©capitule l’historique de l’account abstraction, en discussion depuis les dĂ©buts d’Ethereum, Ă  travers les diffĂ©rents EIPs. Julien redĂ©finit ce concept consistant Ă  changer le modĂšle des EOAs en transformant les comptes Ethereum en smart-contract.

Sont notamment passĂ©s en revue les 5 changements que les dĂ©veloppeurs doivent garder en tĂȘte avec l’account abstraction:

  • Les comptes sont des smart-contracts: ils doivent ĂȘtre dĂ©ployĂ©s (pris en charge par le wallet)
  • Les adresses des comptes doivent ĂȘtre pris en charge comme des smart-contracts et non dĂ©rivĂ©s du signer
  • Les transactions peuvent avoir plusieurs signatures
  • On remplace la mĂ©thode de verification de signatures ECRecover par isValidSignature (EIP-1271)
  • On peut utiliser des multicalls (groupements de transactions)

On nous parle d’ArgentX, Argent pour Starknet et des fonctionnalitĂ©s permises par l’account abstraction telles que les multicalls, social recovery, fraud monitoring, session keys etc.

Répertoire de talks intéressants à ce sujet :

  1. La sécurité

La sécurité représente un sujet prédominant au sein de notre écosystÚme et plusieurs talks ont mis en perspective les moyens pour se protéger. 

Zoom sur l’avenir des audits de sĂ©curitĂ© des smart contracts par Hazelstar

Hazelstar a Ă©galement eu l’occasion de participer Ă  un panel au sujet de « L’avenir des audits de sĂ©curitĂ© des smarts contracts : WAGMI ou REKT ?”

Sur les changements de ces 3 derniĂšres annĂ©es, on retient surtout que la qualitĂ© des projets a augmentĂ© autant que leur complexitĂ© a explosĂ©. Il faut rappeler que le terme “auditer” qualifie mal le travail rĂ©alisĂ©, mais qu’il faut plutĂŽt parler d’évaluation de sĂ©curitĂ© par blocs de temps qui n’est pas Ă  l’épreuve des balles. S’il est difficile de dĂ©finir un standard, il nous faut reconaĂźtre qu’un langage commun est important et qu’il faut avant tout apprendre Ă  connaĂźtre les auditeurs et leur expĂ©rience car leur travail est trĂšs public. Tous s’accordent Ă  dire que “la sĂ©curitĂ© est primordiale, parfois plus que la vitesse” et enjoignent les projets et leurs developeurs Ă  “[se] concentrer sur la sĂ©curisation de leur propre code, et ensuite le donner aux auditeurs pour obtenir un avis, mais pas pour sĂ©curiser le code Ă  leur place.”

Zoom sur l’intervention de Jonathan Alexander, CTO d’Open Zeppelin et Co-Fondateur de Forta Network

L’intervention de Jonathan Alexander sur le sujet “Decentralized Threat Detection Bots“ Ă©tait trĂšs abordable. Il a prĂ©sentĂ© un nouveau domaine de recherche et dĂ©veloppement pour continuer Ă  protĂ©ger notre Ă©cosystĂšme: l’utilisation des bots. Dans un premier temps, il est revenu sur les diffĂ©rentes Ă©tapes d’une attaque d’un smart contract (financement, prĂ©paration, exploitation, blanchiment) pour en venir aux modĂšles de dĂ©tection des bots. Il a prĂ©sentĂ© 4 types de modĂšles d’utilisation des bots :

  • La simulation heuristique
  • La simulation de sĂ©ries chronologiques
  • La simulation multi blocs
  • La simulation TX

Aujourd’hui, son Ă©quipe explore Ă©galement d’autres domaines de recherche : les bots privĂ©s (pools d’analyse privĂ©s de confiance), l’analyse TX avant soumission et les alertes sur la blockchain.

Répertoire de talks intéressants à ce sujet :

DEVCON TALKS 
Zoom sur un talk de Matt Deible par RĂ©mi Foult

« Un talk que j’ai trouvĂ© trĂšs intĂ©ressant sur les DEX et les diffĂ©rentes fonctions de prix qu’ils utilisent fut celui de Matt Deible de la sociĂ©tĂ© Semiotic, nommĂ© «An overview of AMM mechanisms.

Les AMM de base:

  • CPMM : constant product market maker , uniswap V1 et V2, balancer V1
  • CSMM : constant sum market maker, Maker PSM, synthetics swap

Les AMM hybrides:

  • StableSwap : curve V1
  • Solidly stable pair : comme curve avec A=2
  • Dodo proactive market maker : switch entre CPMM et CSMM en fonction d’un paramĂštre k qui utilise un oracle de prix externe
  • Crypto swap : curve V2

Virtual reserves 

  • Kyber DMM : rĂ©plique une liquiditĂ© 5x plus profonde 
  • Uniswap V3 : le cĂ©lĂšbre AMM avec des market maker dĂ©diĂ©s

Semiotic dĂ©veloppe un aggrĂ©gateur de DEX odos.xyz similaire Ă  paraswap ou 1inch mais avec la possibilitĂ© d’avoir plusieurs tokens en input. Cela peut ĂȘtre intĂ©ressant notamment pour les farmers qui veulent vendre tout un tas de token de gouvernance contre de l’USD ou de l’ETH. De plus, odos n’a pas encore lancĂ© de tokens, du coup il est probable que si vous l’utilisez vous augmentez vos chances d’obtenir un airdrop  »

Zoom sur un talk de Stani Kulechov nommĂ© « La couche sociale du Web3 – Web3 social : la prochaine vague d’innovation » par Hazelstar

« Avec fraĂźcheur, Stani nous rapelle que la vitesse d’innovation d’internet et de son adoption s’est accĂ©lĂ©rĂ©e ces derniĂšres dĂ©cennies, et mĂȘme si aujourd’hui cette adoption n’est pas optimale dans toutes les parties du globe, demain, il se peut que tout soit diffĂ©rent. Pour Stani, les rĂ©seaux ouverts vont accĂ©lĂ©rer encore plus cette innovation et ajouter l’accĂ©ssibilitĂ© et la culture (= communautĂ©). Et dans le Web3, plus que la DeFi, ce sont les rĂ©seaux sociaux qui seront les applications de demain. Les besoins d’échanger et de crĂ©er nous motivent Ă  nous connecter, en tĂȘte-Ă -tĂȘte ou en groupe, nous sommes en mesure d’apprendre directement les uns des autres, et nous avons un sentiment d’appartenance lorsque nous crĂ©ons des communautĂ©s. 

Le Web2 social est un jeu Ă  somme nulle pour ses utilisateurs: nous donnons notre prĂ©cieux capital social aux GAFAM, et leur intĂ©rĂȘts ne sont pas alignĂ©s avec les nĂŽtres. Alors que le Web3 social crĂ©e une valeur Ă  somme positive. Stani conclut en rappelant les ingrĂ©dients du Web3 social: des rĂ©seaux ouverts, une architecture rĂ©ellement dĂ©centralisĂ©e. Et c’est Ă  nous de le construire ! »

Zoom sur un talk de Wouter Kampmann nommé « The history of dencentralization of MakerDAO » 

Talk sur l’histoire de la dĂ©centralisation de MakerDAO et du fonctionnement de leur organisation, qui est un des meilleurs exemples d’une organisation dĂ©centralisĂ©e aujourd’hui. 

Leur dĂ©centralisation a dĂ©butĂ© avec la dissolution de la Maker foundation ayant pour objectif de dĂ©centraliser leurs opĂ©rations i.e. accomplir des choses de maniĂšre transparente et dĂ©centralisĂ©e. Une DAO doit gouverner, mais Ă©galement exĂ©cuter. Pour cela, se mettent d’accord les dĂ©tenteurs de MKR, Ă  travers des dĂ©lĂ©guĂ©s, afin de voter des MIPs (Maker Improvment Proposals). La structure de MakerDAO est composĂ©e de Core Units d’une vingtaine Ă©quipes, et d’une centaine de membres plein temps, rĂ©munĂ©rĂ©s par la DAO. 

Wouter a passé en revue quelques uns de leur gros challenges et solutions apportés par la DAO:

  • Challenge: alignement des parties prenantes et blocages politiques. Solution: Des comitĂ©s de votes dĂ©centralisĂ©s, groupĂ©s par « opinion », votĂ©s par Ă©lĂ©ctions liquides/dĂ©mocratiques.
  • Challenge: transparence et confiance. Solution: une platforme d’opĂ©rations dĂ©centralisĂ©es.
  • Challenge: coordination des core units. Solution: des budgets, votĂ©s, par projet.
  • Challenge: acquisition de talents, onboarding & rĂ©munĂ©rations. Solution: une plateforme Ă©ducative makerdao.academy pour Ă©duquer et onboarder les nouveaux arrivants.
AUTRES TALKS À VOIR

Tous les talks sont disponibles sur https://archive.devcon.org/.

Mention spéciale pour ces talks auxquels nous avons également pu assister:

LE SHOW DE CLÔTURE

La DevCon s’est clĂŽturĂ©e aux couleurs de l’AmĂ©rique Latine avec un magnifique show surprise sur la main stage ! Ce sont des dizaines d’artistes du continent qui ont dĂ©filĂ© chacun leur tour : danseurs, comĂ©diens, artistes de cirque et d’autres artistes atypiques. Par la suite, le dĂ©filĂ© s’est transformĂ© en une grande parade dans l’enceinte de la DevCon. C’était un moment inoubliable pour les visiteurs. Ils ont eu l’occassion de danser et d’ĂȘtre plongĂ©s dans la culture latino-amĂ©ricaine durant cette clĂŽture d’évĂ©nement !

L’EXPÉRIENCE DEVCON
Les endroits insolites

La DevCon Ă©tait un lieu de vie avec quelques endroits insolites proposĂ©s pour vivre pleinement l’évĂ©nement ! Il y en avait pour tous les goĂ»ts. Voici nos prĂ©fĂ©rĂ©s :

L’hacker basement: lieu de rassemblement des hackers et d’exposition d’art

L’Ethereum Jungle: lieu de repos original avec de la musique relaxante

Les Community Hubs

Il y avait plusieurs hubs, reprĂ©sentĂ©s sous forme d’espace distincts, oĂč les communautĂ©s se retrouvaient pour Ă©changer. Chaque communautĂ© avait sa propre programmation chaque jour avec comme but principal l’échange et le renforcement du sentiment d’appartenance. Voici quelques exemples de communautĂ© prĂ©sentent lors de la DevCon : Regen,  Cryptoeconomics & Governance, Women Leaders in Web3, Anonymous, ZK et Design.

Chiva Chillout: lieu de divertissement latino-américain

Flashback sur les side events

La DevCon était également un lieu de rassemblement pendant 1 semaine, et ce partout au sein de Bogota ! Il y avait des dizaines de side events dont certains trÚs plébiscités tels que :

  • La rAAVE organisĂ©e par AAVE
  • La DAIvinity organisĂ©e par MakerDAO
  • Polygon Connect Bogota
  • Consensys Connect Bogota

Pour suivre Ethereum-France ⬇

The post RĂ©capitulatif de la DevCon VI 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.

L’EthCCweek 2022 vient d’ĂȘtre annoncĂ©e đŸ‡«đŸ‡·

June 28th 2022 at 12:18

Ethereum-France est heureux de faciliter l’EthCCweek pour la quatriĂšme annĂ©e consĂ©cutive.

L’EthCCweek 2022 est une semaine d’évĂ©nements, de hackathons, d’apĂ©ros, de meetups, de confĂ©rences et de fĂȘtes autour d’EthCC[5], organisĂ©e par les membres de la communautĂ© Ethereum au sens large.

EthCCweek 2022 aura lieu du 18 au 24 juillet 2022 Ă  Paris đŸ’™đŸ€â€

Announcing: the EthCCweek 2022 đŸ‡«đŸ‡·@EthCCweek is a community-led week of events around @EthCC, happening on July, 18–24th 2022 https://t.co/A6Rz6hvAaM

— Nathan Sexer | nethan.eth (@NathanSexer) June 28, 2022


EthCCweek 2022

Aprùs la Community Blockchain Week (2019), la France Blockchain Week (2020) et l’EthCC Week 2021, Ethereum-France donne à nouveau le coup d’envoi de cette initiative communautaire : EthCCweek 2022.

Tout le monde est invitĂ© Ă  postuler et Ă  accueillir des Ă©vĂ©nements autour de l’EthCC
➡https://ethccweek.fr/

đŸ’™đŸ€â€

Rappel : bien que nous ayons doublĂ© notre capacitĂ© d’accueil depuis l’annĂ©e derniĂšre, EthCC[5] affiche complet
 mais toutes les confĂ©rences EthCC seront diffusĂ©es en livestreaming (sur le site ethcc.io ainsi que sur notre chaine Youtube) !

Plus d’informations pratiques sur EthCC dans ce blogpost.

EthCCweek donnera la possibilitĂ© Ă  tout le monde d’accueillir et de participer Ă  de nombreux Ă©vĂ©nements autour d’EthCC et rencontrer tous ceux qui viennent pour l’occasion.

Inscrivez votre Ă©vĂ©nement ✍

Tout le monde peut organiser un Ă©vĂ©nement pendant l’EthCCweek.

Pour figurer sur le site de l’EthCCweek, remplissez ce formulaire : https://docs.google.com/forms/d/e/1FAIpQLSeNg-Y_F0UxQV80RkUxRGlCEXMbz54yBguWyzBTB7Szt0ppqQ/viewform .

ÉvĂ©nements de l’EthCCweek

Plus de 30 Ă©vĂ©nements ont dĂ©jĂ  Ă©tĂ© enregistrĂ©s sur le site de l’EthCCweek !

OrganisĂ©s par des Ă©quipes telles que Ledger, Starknet, Celo, Maker, Aave, Rekt, DeversiFi et les Ă©quipes de l’Avenir de la France Stake Capital, Aleph.im, Atlendis, Morpho, Paladin, ADAN, Angle, APWine, Jarvis, Mangrove, ParaSwap, Sismo, Synaps
 đŸ‡«đŸ‡·

Restrictions du COVID

Nous vous invitons Ă  suivre les mesures officielles du gouvernement français, qui varient selon le pays d’oĂč vous venez : https://www.diplomatie.gouv.fr/en/coming-to-france/coronavirus-advice-for-foreign-nationals-in-france/.

Les conditions se sont améliorées et les voyages ont été facilités pour les voyageurs entiÚrement vaccinés.
Veillez à suivre les protocoles et à adopter un comportement adapté.


Assurez-vous de vous inscrire à tous ces événements et rejoignez-nous sur Twitter et Telegram pour rester informés !

On se voit Ă  Paris

đŸ’™đŸ€â€

The post L’EthCCweek 2022 vient d’ĂȘtre annoncĂ©e đŸ‡«đŸ‡· 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.

EvĂ©nement: ApĂ©ro et Retour sur EthCC – Jeudi 7 Octobre [Paris]

September 29th 2021 at 17:02

L’évolution du contexte sanitaire nous permet enfin de reprendre les rassemblements de la communautĂ© Ethereum France. C’est avec grand plaisir que nous vous donnons rendez-vous jeudi 7 octobre dĂšs 18h au bar le Truskel (12 Rue Feydeau, 75002 Paris) pour discuter de l’actualitĂ© d’Ethereum d’un verre et surtout pour vous prĂ©senter le bilan de la confĂ©rence EthCC qui a eu lieu en juillet.

Ethereum France reprend du service avec le grand retour de nos meetups 🐓

Venez rencontrer la communauté Ethereum française, discuter blockchain et revivre les meilleurs moments d'@EthCC 2021

Le Jeudi 7 Octobre Ă  18h au @truskelclub https://t.co/fFjdomIPIk

— Ethereum France (@Ethereum_France) September 23, 2021

Pour vous inscrire à cet événement, rendez-vous sur le lien Meetup:

https://www.meetup.com/fr-FR/ASSETH/events/280963138/

A bientĂŽt!

The post EvĂ©nement: ApĂ©ro et Retour sur EthCC – Jeudi 7 Octobre [Paris] 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.

Les tokens stables – Partie 2 : MNBC et stablecoins algorithmiques

March 5th 2021 at 12:18

Cet article est la traduction d’un chapitre du livre Token Economy, de Shermin Voshmgir, publiĂ©e en avant-premiĂšre sur le site d’Ethereum France. Le livre est sous licence CC-NC-BY-SA. Si vous souhaitez participer Ă  sa traduction, contactez-nous !


AprĂšs avoir traitĂ© des tokens stables collatĂ©ralisĂ©s dans l’article prĂ©cĂ©dent, cette seconde partie aborde deux autres formes de tokens stables ou « stablecoins » : les monnaies numĂ©riques de banque centrale et les tokens stables algorithmiques.

Les monnaies numériques de banque centrale

Photo by Mika Baumeister on Unsplash

Alors que la communautĂ© crypto expĂ©rimente diffĂ©rentes formes de tokens stables, les banques centrales envisagent Ă©galement des moyens de tokeniser leurs propres monnaies, disposant dĂ©jĂ  de mĂ©canismes de stabilisation. Un token de banque centrale, parfois appelĂ© « monnaie fiduciaire numĂ©rique » ou « monnaie de base numĂ©rique », et abrĂ©gĂ© sous la forme « MNBC », constitue une reprĂ©sentation tokenisĂ©e de la monnaie souveraine d’un État. Les mĂ©canismes de stabilitĂ© sont mis en Ɠuvre par les banques centrales, de façon indĂ©pendante ou en accord avec les politiques fiscales et monĂ©taires des gouvernements. Des tokens de ce type s’intĂ©greraient donc Ă  la masse monĂ©taire de base au mĂȘme titre que d’autres formes de monnaie : les piĂšces et billets ainsi que les dĂ©pĂŽts Ă  vue (M0 et M1), les dĂ©pĂŽts Ă  court terme (M2) et les dĂ©pĂŽts Ă  long terme (M3). La MNBC pourrait ĂȘtre utilisĂ©e par les smart contracts en tant qu’instrument de rĂšglement, puisque sa reprĂ©sentation sous forme de token repose sur le registre dĂ©centralisĂ© associĂ©. 

Certains Ă©conomistes pensent que la MNBC pourrait concurrencer les dĂ©pĂŽts dans les banques commerciales et rĂ©duire le coĂ»t des systĂšmes de paiement locaux et internationaux. Le coĂ»t de crĂ©ation et de gestion des espĂšces et les frais de transactions internationales sont trĂšs Ă©levĂ©s. À long terme, la MNBC pourrait rendre obsolĂštes les comptes bancaires classiques en les remplaçant par des portefeuilles crypto, et favoriser l’inclusion financiĂšre des personnes ne disposant pas d’accĂšs aux services bancaires.

Cependant, cette désintermédiation des banques commerciales et des paiements internationaux pourrait aussi déstabiliser les systÚmes de crédit et les marchés des changes, au moins dans un premier temps. La MNBC pourrait également remettre en cause le systÚme de réserves fractionnaires1 qui est à la base de la création monétaire.

L’émission de monnaie par les banques centrales Ă  destination directe du public pourrait aussi constituer une nouvelle approche de mise en Ɠuvre des politiques monĂ©taires. Elle permettrait un contrĂŽle direct de la masse monĂ©taire et pourrait complĂ©ter ou se substituer Ă  d’autres instruments comme les taux d’intĂ©rĂȘts et l’assouplissement quantitatif2 (quantitative easing ou QE). Certains Ă©conomistes estiment mĂȘme que la MNBC pourrait conduire Ă  un systĂšme de « monnaie pleine3 », c’est-Ă -dire Ă  un transfert total de la crĂ©ation monĂ©taire depuis les banques privĂ©es vers les banques centrales.

Selon une Ă©tude de la Banque des rĂšglements internationaux, de nombreux gouvernements et banques centrales envisagent de tokeniser  leur monnaie ou ont mĂȘme amorcĂ© des expĂ©rimentations. C’est le cas notamment de la Banque d’Angleterre, des banques centrales de SuĂšde, d’Uruguay, des Ăźles Marshall, de Chine, d’Iran, de Suisse et de l’Union europĂ©enne. Il est donc probable que de nombreuses monnaies souveraines seront dotĂ©es d’une reprĂ©sentation tokenisĂ©e dans les annĂ©es qui viennent.

Les MNBC « synthĂ©tiques » (sMNBC) sont basĂ©es sur un concept voisin consistant Ă  autoriser des institutions privĂ©es Ă  Ă©mettre des tokens totalement garantis par les rĂ©serves de banque centrale. Qu’il s’agisse de MNBC ou de sMNBC, la question est de savoir si ce type de monnaie tokenisĂ©e contrĂŽlĂ©e par une banque centrale est appelĂ© Ă  remplacer les autres formes de tokens stables, ou si elle deviendra l’une des nouvelles variantes au sein d’une Ă©conomie Ă  base de tokens d’une infinie diversitĂ©. 

Les tokens stables algorithmiques

Tokens stable algorithmiques, à la recherche de l’auto-stabilisation

Les mĂ©thodes de stabilisation des cours Ă©voquĂ©es prĂ©cĂ©demment, telles que la collatĂ©ralisation Ă  base d’actifs financiers classiques, peuvent sembler naturelles de prime abord, mais on peut regretter qu’elles dĂ©rogent aux principes de dĂ©centralisation et d’autonomie des technologies blockchain.

La rĂ©gulation manuelle des cours, par exemple en changeant le ratio de collatĂ©ralisation, peut ĂȘtre comparĂ©e Ă  la façon dont Yahoo et d’autres moteurs de recherche des annĂ©es 1990 ont essayĂ© de rendre accessible le contenu du web en crĂ©ant des catalogues de sites, comme on catalogue des livres et des magazines dans une bibliothĂšque. Ces moteurs de recherche Ă©taient populaires et leur utilisation Ă©tait intuitive, mais il Ă©tait trĂšs difficile de les maintenir Ă  jour compte tenu de l’accroissement exponentiel des contenus. Finalement, la recherche algorithmique apportĂ©e notamment par Google a remplacĂ© la curation et le classement manuels. De la mĂȘme maniĂšre, la stabilisation par collatĂ©ralisation des tokens peut sembler a priori sĂ©duisante, mais de nombreuses solutions algorithmiques apparaissent aujourd’hui qui exploitent davantage les possibilitĂ©s des smart contracts.

Des mĂ©canismes peuvent ĂȘtre mis en place afin de rendre la masse monĂ©taire Ă©lastique, en stimulant sa contraction ou son expansion en fonction des besoins, Ă  l’instar des mesures prises par les banques centrales pour contrĂŽler la quantitĂ© de monnaie fiduciaire en circulation. Si la demande pour le token stable augmente ou dĂ©cline, l’algorithme procĂšde automatiquement Ă  des ajustements afin de maintenir la stabilitĂ© du cours. Si le cours est trop haut, de nouveaux tokens sont crĂ©Ă©s. S’il est trop bas, des tokens doivent ĂȘtre retirĂ©s de la circulation, d’une façon ou d’une autre. Il est difficile de rĂ©duire et augmenter dynamiquement la masse monĂ©taire d’une façon rĂ©sistante Ă  toutes sortes d’attaques ; le dĂ©bat reste ouvert en ce qui concerne les meilleures mĂ©thodes pour y parvenir.

Par exemple, si un token stable indexĂ© sur l’euro s’acquiert sur les marchĂ©s Ă  un cours supĂ©rieur Ă  1 EUR, cela indique que la demande est supĂ©rieure Ă  l’offre. La quantitĂ© de tokens disponible doit ĂȘtre augmentĂ©e afin de faire revenir le cours Ă  1 EUR. Le smart contract est programmĂ© pour Ă©mettre de nouveaux tokens et les vendre sur les marchĂ©s, augmentant ainsi l’offre jusqu’à ce que le prix revienne au cours souhaitĂ©. Lorsque le cours est infĂ©rieur Ă  1 EUR, la quantitĂ© de tokens doit Ă  l’inverse ĂȘtre rĂ©duite. Mais cette contraction de la masse monĂ©taire est beaucoup plus difficile Ă  obtenir que son expansion


L’approche la plus simple consiste Ă  programmer directement dans le smart contract du token les mĂ©canismes de contraction et d’expansion, de façon Ă  ce que la volatilitĂ© du cours soit remplacĂ©e par la volatilitĂ© du nombre de tokens. C’est l’option proposĂ©e par Ampleforth, qui rĂ©ajuste chaque jour le nombre de total de tokens AMPL en fonction de son cours. Chaque dĂ©tenteur conserve la mĂȘme participation par rapport au nombre total d’AMPL en circulation, mais le nombre d’AMPL dans son portefeuille peut changer de jour en jour. En consĂ©quence, le cours du token est stable, mais ni la valeur de l’actif dans le portefeuille du dĂ©tenteur, si son pouvoir d’achat ne le sont. Difficile de parler de token stable dans ces conditions. Le vĂ©ritable objectif du projet est de crĂ©er un crypto-actif dont l’évolution du cours n’est pas corrĂ©lĂ©e Ă  celles des autres crypto-actifs sur les marchĂ©s.

Les « parts de seigneuriage4 » (seigniorage shares) ont Ă©tĂ© conceptualisĂ©es par Roberty Sams en 2014, dans le but d’utiliser des smart contracts pour crĂ©er des incitations Ă©conomiques Ă  la stabilisation du cours d’un token. Cette approche, notamment empruntĂ©e par Basis Cash, Empty Set Dollar et Dynamic Set Dollar, consiste Ă  inciter les dĂ©tenteurs Ă  dĂ©truire une partie de leurs tokens en cas de dĂ©crochage par rapport Ă  la valeur de rĂ©fĂ©rence, en offrant en Ă©change la part de seigneuriage sous la forme d’une obligation Ă  coupon, c’est-Ă -dire la possibilitĂ© d’acheter de nouveaux tokens lors de la prochaine phase d’expansion Ă  un prix infĂ©rieur au cours stable visĂ©.

Le point faible de cette approche est qu’elle dĂ©pend d’un mĂ©canisme fonciĂšrement spĂ©culatif basĂ© sur la thĂ©orie des jeux. Pour jouer le jeu de la part de seigneuriage, il faut parier sur l’apprĂ©ciation future du token, dont la valeur ne repose sur rien d’autre que le comportement des autres participants et participantes partageant le mĂȘme optimisme sur le retour Ă  la valeur de rĂ©fĂ©rence. Si, pour une raison quelconque, le pessimisme l’emporte, alors une « spirale de la mort » peut survenir, rien ne venant freiner le dĂ©crochage du cours : il n’est dans l’intĂ©rĂȘt de personne d’acheter une part de seigneuriage lorsque les perspectives de crĂ©ation monĂ©taire s’éloignent ou disparaissent. Certains ont critiquĂ© le principe mĂȘme d’un token stable basĂ© sur un mĂ©canisme spĂ©culatif de ce type, le qualifiant de pyramide de Ponzi.

D’autres approches cherchent Ă  rĂ©soudre cette difficultĂ© en combinant les parts de seigneuriage avec une forme de collatĂ©ralisation. A la diffĂ©rence des tokens stables garantis par des crypto-actifs, ces systĂšmes ne nĂ©cessitent pas de sĂ»retĂ© excĂ©dentaire et sont donc plus efficaces en termes de rendement du capital. Avec Frax, le principal token utilisant aujourd’hui cette approche, les rĂ©serves accumulĂ©es via la collatĂ©ralisation sont Ă  la fois des crypto-actifs ayant une valeur de marchĂ© indĂ©pendantes du systĂšme (au dĂ©part, USDC et USDT) et des tokens/parts de seigneuriage dĂ©nommĂ©s FXS. La proportion de crypto-actifs tiers et FXS varie de façon dĂ©terministe en fonction de la demande et du prix du token stable. Le protocole Fei a Ă©tĂ© conçu selon une logique voisine. Un mĂ©canisme spĂ©culatif initial (levĂ©e de fonds en ETH basĂ©e sur une bonding curve) permet d’atteindre une taille critique (250 millions de FEI), aprĂšs quoi la trĂ©sorerie est utilisĂ©e de façon autonome par le protocole pour stabiliser le cours du FEI, au moyen d’interventions sur les marchĂ©s AMM et de pĂ©nalisation directe des dĂ©tenteurs vendant sous le cours cible.

Le projet Reflexer, lancĂ© en fĂ©vrier 2021, a pour but de constituer un crypto-actif stable indĂ©pendant, le RAI, non indexĂ© sur le dollar ou une autre devise fiduciaire. Sa raison d’ĂȘtre est d’offrir une alternative aux systĂšmes monĂ©taires traditionnels, dont l’équilibre est menacĂ© par l’émission massive de monnaie de ces derniĂšres annĂ©es. Le RAI, comme la premiĂšre version du DAI, est crĂ©Ă© en plaçant en garantie de l’ETH. Reflexer intĂšgre des mĂ©canismes de stabilitĂ© dans son protocole, sous la forme d’un taux d’intĂ©rĂȘt Ă©voluant en fonction de l’écart entre le prix de marchĂ© et le prix cible du RAI. Ce dernier a Ă©tĂ© initialisĂ© avec une valeur arbitraire au lancement, mais Ă©volue lentement en fonction de la demande de fond pour le token, au lieu de rester arrimĂ© Ă  une devise traditionnelle faillible.

L’idĂ©e d’utiliser des smart contracts pour copier certaines opĂ©rations des banques centrales est intĂ©ressante, mais il faut garder Ă  l’esprit que ces mĂ©canismes reposent sur des hypothĂšses Ă©conomiques peu vĂ©rifiĂ©es et des politiques monĂ©taires peu testĂ©es, en particulier en ce qui concerne les incitations Ă  la contraction de la masse monĂ©taire. De plus, leur fonctionnement dĂ©pend de la fiabilitĂ© des oracles de prix, dont la dĂ©centralisation et la fiabilitĂ© font toujours dĂ©bat aujourd’hui. De nombreux Ă©conomistes estiment que les tokens stables algorithmiques basĂ©s uniquement sur les parts de seigneuriage ne peuvent pas fonctionner car ils reposent sur des mĂ©canismes spĂ©culatifs conduisant Ă  un accroissement illimitĂ© du systĂšme. Les nouvelles approches que nous venons d’évoquer montrent Ă  quel point ce domaine est en pleine expansion et que des modĂšles plus efficaces sont possibles.

DĂ©fis et perspectives d’avenir

De nombreux projets visent Ă  crĂ©er des tokens stables, mais il n’existe pas de bonnes pratiques en la matiĂšre qui se soient imposĂ©es (si l’on exclut les MNBC qui bĂ©nĂ©ficieront des mĂ©canismes traditionnels de stabilitĂ© des monnaies nationales). L’émergence des tokens stables est un phĂ©nomĂšne rĂ©cent et de nombreuses propositions en la matiĂšre en sont encore au stade du white paper ou des premiĂšres expĂ©rimentations, en particulier la crypto-collatĂ©ralisation et les tokens stables algorithmiques. Bon nombre de ces projets sont sujets Ă  une forte volatilitĂ©, ce qui explique que les tokens garantis par des monnaies fiduciaires ou d’autres actifs traditionnels, comme Tether, sont dominants en termes de capitalisation. Le DAI (MakerDAO) et d’autres tokens crypto-collatĂ©ralisĂ©s constituent des alternatives prometteuses, mais ils comportent de nombreux inconvĂ©nients et inconnues, notamment concernant leur robustesse en cas d’effondrement des marchĂ©s.

A l’exception du RAI, tous les tokens stables, mĂȘme les plus dĂ©centralisĂ©s, sont associĂ©s Ă  un actif sous-jacent avec un ratio de 1 Ă  1. Selon la dynamique des marchĂ©s, le maintien de ce ratio peut ĂȘtre mis en cause. Si des activitĂ©s Ă©conomiques se dĂ©veloppent autour d’un token stable et que des effets de rĂ©seau s’enclenchent, le maintien du ratio pourrait perdre de l’importance. Cela pourrait par exemple ĂȘtre le cas si un token stable s’impose comme intermĂ©diaire des Ă©changes et est utilisĂ© comme moyen de paiement par un grand nombre d’entreprises.

Toute implĂ©mentation d’un token stable dĂ©centralisĂ© doit affronter le problĂšme des oracles. Si le token est supposĂ© maintenir son cours par rapport Ă  un autre actif de rĂ©fĂ©rence, il doit avoir accĂšs Ă  l’information sur le maintien ou la divergence des cours. Pour le moment, aucune solution complĂštement dĂ©centralisĂ©e et totalement fiable n’est disponible. De nouveau, le RAI fait exception ici puisqu’il est auto-rĂ©fĂ©rentiel.

Comme les monnaies conventionnelles, les tokens stables doivent satisfaire trois exigences incompatibles : 1) politique monĂ©taire indĂ©pendante, 2) stabilitĂ© des taux de change et 3) mobilitĂ© des capitaux. Étant donnĂ© que la mobilitĂ© des capitaux est un fondement de l’économie des tokens cryptographiques et que la stabilitĂ© des taux de change est l’objectif affichĂ© des tokens stables, il est impossible de mettre en place une politique monĂ©taire indĂ©pendante. De nombreux Ă©conomistes estiment donc que les tokens dont les rĂšgles d’émission sont autonomes, comme le bitcoin, ne pourront jamais maintenir un cours indexĂ© sur celui des monnaies conventionnelles. On peut toutefois nuancer ce point de vue si l’on considĂšre les tokens non comme les concurrents des monnaies conventionnelles, mais plutĂŽt comme des actifs nouveaux et alternatifs. L’idĂ©e que des actifs conventionnels comme des actions devraient avoir une valeur stable ou que leur volatilitĂ© devrait ĂȘtre un obstacle Ă  leur utilisation serait saugrenue.

Il est important de souligner que les tokens stables ne sont pas la seule solution au problĂšme de la volatilitĂ© des prix. Les assurances ou les produits dĂ©rivĂ©s financiers sont des approches alternatives ou complĂ©mentaires pour se protĂ©ger de la volatilitĂ© des prix. Les instruments de couverture financiĂšre peuvent ĂȘtre utilisĂ©s pour rĂ©duire les risques en Ă©quilibrant les positions prises sur les marchĂ©s. Les applications de la DeFi (finance dĂ©centralisĂ©e) peuvent ĂȘtre utilisĂ©es pour crĂ©er de tels instruments .

Enfin, il faut noter le risque rĂ©glementaire qui pĂšse sur les tokens stables, tout au moins ceux qui ne fonctionnent pas de façon totalement autonome sur une blockchain. En parallĂšle des recherches et des premiĂšres expĂ©rimentations de monnaie numĂ©rique de base, on perçoit depuis l’annonce du projet Libra de Facebook des signes de raidissement de la part de nombreux Etats Ă  l’encontre des tokens stables alignĂ©s sur les monnaies nationales et qui pourraient menacer leur souverainetĂ©. C’est notamment le cas des Etats-Unis avec le Stable Act proposĂ© en dĂ©cembre 2020. Plusieurs pays europĂ©ens, dont la France, ont appelĂ© la Commission europĂ©enne Ă  mettre en place une rĂ©glementation visant Ă  protĂ©ger la souverainetĂ© des Etats en matiĂšre de politique monĂ©taire.

Si elles aboutissent, les solutions de tokens stables permettront aux tokens de jouer le rĂŽle d’unitĂ© de compte et de servir de moyen d’échange au quotidien. Elles tiendront alors un rĂŽle clĂ© dans le dĂ©veloppement d’une Ă©conomie dynamique des tokens et des applications dĂ©centralisĂ©es. Cependant, la stabilitĂ© n’est qu’un des multiples dĂ©fis Ă  relever pour faire des tokens un moyen d’échange courant. La protection des donnĂ©es personnelles, la capacitĂ© Ă  dĂ©multiplier le volume des transactions et l’amĂ©lioration de l’expĂ©rience utilisateur sont tout autant nĂ©cessaires Ă  l’adoption la plus large de cette nouvelle technologie.


Cet article a Ă©tĂ© traduit et complĂ©tĂ© par PhilH et rĂ©visĂ© par Sophie Portulan et Aline Detrez. En complĂ©ment de cette introduction aux tokens stables, nous vous conseillons la lecture en français de deux billets de TokenBrice : « l’état et le futur des stablecoins » et « L’histoire de deux modĂšles de seigneuriage : Basis contre ESD« .

Notes

1Le systĂšme de rĂ©serves fractionnaires dĂ©signe le droit dont peut faire usage une banque commerciale de prĂȘter de l’argent qu’elle n’a pas et sur lequel elle touchera des intĂ©rĂȘts. Il s’agit Ă©galement d’un mĂ©canisme de crĂ©ation monĂ©taire encadrĂ© par la banque centrale qui fixe le taux de rĂ©serves obligatoires, c’est-Ă -dire le pourcentage de fonds que les banques doivent effectivement possĂ©der par rapport Ă  ceux qu’elles prĂȘtent.

2L’assouplissement monĂ©taire, ou quantitative easing, est une politique monĂ©taire active reposant sur des achats de titres financiers effectuĂ©s sur les marchĂ©s par une banque centrale afin de fournir des liquiditĂ©s aux banques, de favoriser l’investissement et d’accroĂźtre la masse monĂ©taire avec de nouvelles rĂ©serves bancaires. Il s’agit d’une mĂ©thode non conventionnelle utilisĂ©e lorsque les taux d’intĂ©rĂȘt avoisinent dĂ©jĂ  zĂ©ro pourcent.

3La monnaie pleine (full-reserve banking) est un systĂšme alternatif Ă  celui des rĂ©serves fractionnaires, oĂč la crĂ©ation monĂ©taire est effectuĂ©e uniquement par la banque centrale et oĂč les banques commerciales ne peuvent consentir des crĂ©dits qu’à hauteur des fonds qu’elles dĂ©tiennent.

4 Le seignieuriage est le revenu dĂ©rivĂ© de la diffĂ©rence entre le coĂ»t de production et de distribution d’une monnaie, et sa valeur.

The post Les tokens stables – Partie 2 : MNBC et stablecoins algorithmiques first appeared on Ethereum France.

Un guide incomplet des rollups

February 2nd 2021 at 11:24

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

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

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

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

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

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

Comparaison : state channels, Plasma et rollups

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

Comment fonctionnent les channels ?

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

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

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

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

Comment Plasma fonctionne-t-il ?

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

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

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

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

Rollups

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

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

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

Bon, mais comment fonctionne un rollup exactement ?

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

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

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

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

Optimistic rollups contre ZK rollups

Les deux types de rollups sont :

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

Les compromis entre les deux types de rollups sont complexes :

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

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

Anatomie d’une preuve de fraude

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

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

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

Comment fonctionne la compression ?

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

ParamĂštreEthereumRollup
Nonce~3   0
Prix du gaz~80-0.5
Gaz30-0.5
Destinataire214
Valeur~9~3
Signature~68 (2+33+33)~0.5
Depuis0 (récupéré de sig)4
Total~112~12

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

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

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

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

Qui peut soumettre un lot ?

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

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

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

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

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

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

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

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

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

ApplicationOctets dans le rollupCoût du gaz sur la couche 1Gain maximal   
Transfert d’ETH           1221 000105x
Transfert ERC20           16 (4 octets supplémentaires pour préciser quel jeton)~50 000187x
Trade Uniswap~14 (4 octets expéditeur + 4 octets destinataire + 3 octets valeur + 1 octet prix maxi + 1 octet divers)           ~100000   428x
Retrait avec confidentialitĂ© (Optimistic rollup)296 (4 octets d’index de la racine + 32 octets d’annulateur + 4 octets de destinataire + 256 octets de preuve ZK-SNARK)~380 00077x
Retrait avec confidentialitĂ© (ZK rollup)40 (4 octets d’index de la racine + 32 octets d’annulateur + 4 octets de destinataire)           ~380 000           570x
Le gain maximal de passage Ă  l’échelle est calculĂ© comme suit : (coĂ»t du gaz L1) / (octets dans le rollup * 16) * 12 millions / 12,5 millions.

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

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

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

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

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

Conclusion

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

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

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

Live: Retour sur le lancement d’Ethereum 2 et vers son futur avec Justin Drake

December 7th 2020 at 23:40

Jeudi 10 DĂ©cembre, Ethereum France a le plaisir de recevoir Justin Drake, chercheur de la Fondation Ethereum et l’un des architectes d’Ethereum 2.


Venez nombreux Ă  l’heure du dĂ©jeuner sur Youtube pour dĂ©couvrir les coulisses du lancement du 1er dĂ©cembre dernier et en apprendre plus sur les Ă©volutions Ă  venir. Le chat sera ouvert pour toutes vos questions.

File:Willem van der Vliet - Philosopher and Pupils - WGA25281.jpg
Philosopher and Pupils – Artist Willem van der Vliet (1626)

AprĂšs avoir accueilli Mehdi Zerouali de Sigma Prime Ă  quelques jours du premier bloc d’Ethereum 2, c’est au tour de Justin Drake de venir vous parler en français des efforts qui ont permis la rĂ©ussite de la semaine derniĂšre et ce Ă  quoi vous devez vous attendre pour les mois Ă  venir. Justin a dĂ©jĂ  eu l’occasion de venir plusieurs fois Ă  EthCC et notamment en 2019 pour prĂ©senter la phase 0 d’Ethereum 2. Justin a Ă©tudiĂ© les mathĂ©matiques Ă  Cambridge et fait de l’entrepreneuriat autour de Bitcoin de 2014 Ă  2017 avant de se tourner vers la recherche sur Ethereum 2.0.

Justin Drake : CogX

Rendez-vous à 12h30 jeudi 10 décembre sur notre chaßne Youtube

The post Live: Retour sur le lancement d’Ethereum 2 et vers son futur avec Justin Drake 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.

Guide pour débutants : staker sur Ethereum 2 !

November 24th 2020 at 12:43

Guide dĂ©taillĂ© de A Ă  Z de mise en place d’un validateur sur Ethereum 2.

Table Of Contents
  1. Prérequis et implications
  2. Mise en place de la machine
  3. Louer un serveur
  4. Connexion Ă  la machine
  5. CrĂ©ation d’un utilisateur
  6. SĂ©curisation de la machine
  7. Créer les clés de validateurs
  8. Mise en place des logiciels
  9. Monitoring
  10. Aller plus loin
  11. Appendice

Prérequis et implications

Devenir un validateur sur Ethereum 2 n’est pas quelque chose Ă  prendre Ă  la lĂ©gĂšre. Vous allez devoir bloquer 32 ETH (ou plus), sans pouvoir les retirer pendant un certain moment, et devoir vous assurer que votre validateur continue Ă  ĂȘtre actif sur toute cette pĂ©riode, sans quoi vous perdrez une partie de vos ETH placĂ©s.

De grands pouvoirs impliquent de grandes responsabilités

Avant de vous jeter Ă  l’eau, assurez-vous de pouvoir rĂ©pondre Ă  l’affirmatif Ă  ces questions:

  • Avez-vous 32 ETH ou plus Ă  sĂ©questrer pendant 3 ans ?
  • Pourrez-vous accorder du temps Ă  vos validateurs pendant 3 ans (mettre Ă  jour les logiciels, s’assurer que le validateur fonctionne etc
)
  • Avez-vous un minimum de connaissances en anglais (pour les mises Ă  jour, les dĂ©bats etc
)
  • Avez-vous accĂšs Ă  un interpreteur de commande (parfois appelĂ© Terminal, ou Console de commande)
  • Avez-vous lu notre poste d’introduction Ă  la preuve d’enjeu ?

Moins de 32 ETH ? Pas de panique !

Si vous n’avez pas 32 ETH, ou que vous ne vous sentez pas de devenir validateurs, vous pourrez toujours rejoindre des « staking pool« .

Prenez cependant le soin de vous renseigner sur les staking pool avant d’y sĂ©questrer vos ETH ! Il y a beaucoup d’arnaques

Mise en place de la machine

PremiĂšre Ă©tape : mettre en place une machine qui servira de validateur.

Deux options s’offrent Ă  vous: vous pouvez utiliser une machine chez vous, ou bien un serveur hĂ©bergĂ© ailleurs. Les deux ont leurs avantages et inconvĂ©nients : facilitĂ© d’accĂšs, stabilitĂ© de la connexion Ă  internet, taille du disque dur, confiance en l’hĂ©bergeur
 je vous laisse faire votre choix. Dans ce guide, je vais utiliser un hĂ©bergeur (aucun lien d’affiliation, c’est juste celui que j’utilise personellement), afin de montrer cette Ă©tape aussi. Si vous avez dĂ©jĂ  un ordinateur chez vous (ou votre serveur est dĂ©jĂ  mis en place), vous pouvez procĂ©der Ă  l’étape « Mise en place des logiciels » directement !

Je peux perdre mes ETH ?!

Vous vous apprĂȘtez Ă  sĂ©questrer au moins 32 ETH. Mais ĂȘtes-vous sĂ»r de connaĂźtre les risques et les pĂ©nalitĂ©s ? Plus de dĂ©tail dans l’appendice en bas de la page.

Cette partie va vous montrer comment:

  • Louer un serveur chez un hĂ©bergeur (ici netcup.eu)
  • Configurer le pare-feu
  • Configurer les clĂ©s d’accĂšs (ssh) et s’y connecter

Louer un serveur

Allez c’est parti ! Rendons-nous chez netcup.eu (ce guide n’est en aucun cas affiliĂ© ! C’est simplement l’option que j’utilise personellement).

SĂ©lectionnez « Server », et cherchez l’option VPS 6000 G9.

Quelle offre choisir ?

Ce qui importe, c’est d’ĂȘtre sĂ»r que le serveur tiendra la route en cas de perturbation sur le rĂ©seau. Aujourd’hui, il est recommandĂ© d’avoir au moins 4 CƓurs, 16 GB de RAM, 256Gb de SSD, juste pour faire tourner le Beacon Node (plus d’info sur ce terme plus tard dans le tutoriel) et les validateurs.

Cependant, Ă  ça il faut ajouter l’instance d’ETH1, qui nĂ©cessite elle-mĂȘme 16Gb de RAM et 500 GB de SSD. Et si vous voulez, vous pouvez aussi lancer un slasher, ce qui prend des ressources supplĂ©mentaires.

L’option VPS 6000 est une option avec laquelle vous n’aurez pas de problĂšmes dans les annĂ©es Ă  venir. Elle a largement de quoi faire, et tiendra la route mĂȘme en cas de conditions etrĂȘmes sur le rĂ©seau. L’option VPS 4000 est correcte et devrait ĂȘtre suffisante. L’option VPS 3000 fera pile l’affaire pour le moment, mais il faudra s’attendre Ă  devoir changer de plan d’ici 1 an ou deux. Enfin, si vous ne comptez pas lancer d’instance eth1 (si vous utilisez Infura par exemple), l’option VPS 2000 sera suffisante.

Si pour vous les termes eth1, Infura, beacon node et validateurs sont du charabia, vous pouvez allez lire le « Petit récapitulatif » dan « Mise en place des logiciels ».

Une fois votre offre sĂ©lectionnĂ©e, vous devrez procĂ©der Ă  la crĂ©ation de compte. Retenez bien les informations que vous entrez : une fois la demande effectuĂ©e, vous recevrez un appel de netcup.eu en anglais (ils sont allemands) et ils vous demanderont de bien confirmer : votre nom / prĂ©nom, votre adresse, votre code postale. C’est tout Ă  fait normal (bien que dĂ©routant je vous le concĂšde !).

Une fois ces informations confirmĂ©es par tĂ©lĂ©phone, ils vous enverront vos identifiants de connexion par e-mail : les e-mails sont en allemand et en anglais, donc il faudra scroller jusqu’en bas pour trouver la version anglaise !

Connectons-nous d’abord Ă  notre espace client. Comme Ă©crit dans le mail, le lien est celui-lĂ  : https://www.customercontrolpanel.de . Vos identifiants figurent aussi dans le mail (en orange sur la photo).

La premiĂšre Ă©tape Ă  suivre est de sĂ©curiser notre compte client mettant en place le 2FA : un mĂ©chanisme de sĂ©curitĂ© qui vous demandera d’entrer un code fournit par votre tĂ©lĂ©phone lors de vos prochaines connexions. Pour ce faire, cliquez sur Master Data en bas Ă  gauche.

Là vous pouvez cliquer sur le bouton « Enable two factor authentication ».

N’oubliez pas de sauvegarder votre clĂ© au cas oĂč vous seriez amenĂ© Ă  perder votre tĂ©lĂ©phone

Bien maintenant que votre compte est sĂ©curisĂ©, vous pouvez procĂ©der au rĂšglement. La facture devrait ĂȘtre Ă  peu prĂšs Ă©gale Ă  trois fois le montant mensuel : pas de panique, cela suit une pĂ©riode de facturation trimestrielle.

Une fois le rÚglement effectué, vous devriez recevoir de nouvelles informations par e-mail : un e-mail intitulé « Access data for SCP » et un autre intitulé « Ihr vServer bei netcup ist bereit gestellt.

Access data for SCP

D’abord par mesure de sĂ©curitĂ©, rendez-vous sur le servercontrolpanel (https://www.servercontrolpanel.de/SCP), connectez-vous avec les identifiants contenus dans le mail, et changez votre mot de passe (menu dĂ©roulant en haut Ă  droite, puis Option).

Sur ce paneau de contrĂŽle, vous avez accĂšs Ă  vos machines, et si vous cliquez sur l’une de vos machines, vous aurez un dĂ©tail de l’utilisation de celle-ci.

Les curieux remarqueront que j’ai pris l’option VPS 4000
 c’est pour le testnet !

Vous pouvez maintenant vous connecter Ă  la machine !

Connexion Ă  la machine

Fini la rigolade ! On passe aux choses sérieuses ! Pour ce faire, nous allons utiliser ssh ! ssh est un programme qui permet de se connecter de façon sécurisée à un serveur.

Pour l’utiliser, rien de plus simple : depuis le terminal de votre machine, tapez ceci (en remplaçant « adresseip » par l’adresse IP de votre propre machine, qui vous a Ă©tĂ© communiquĂ©e dans le deuxiĂšme e-mail)

ssh root@adresseip

Le mot de passe demandĂ© est celui qui apparaĂźt dans l’email que netcup vous a envoyĂ©. Ensuite, vous devriez avoir un message vous signalant que l’authenticitĂ© de la machine ne peut pas ĂȘtre prouvĂ©e
 c’est normal, tapez « yes » !

Si vous avez une erreur ici, c’est probablement que vous n’avez pas bien copiĂ© la clĂ© grĂące Ă  ssh-copy-id. J’ai utilisĂ© une clĂ© ECDSA et non ed25519, c’est pourquoi votre message d’erreur ne sera pas exactement le mĂȘme


PremiÚre étape
. changer de mot de passe ! Et oui, sécurité, sécurité, sécurité !

Entrez simplement :

passwd

Et choisissez un mot de passe solide (différent des autres mot de passe que vous utilisez habituellement !)

CrĂ©ation d’un utilisateur

Nous sommes actuellement connectĂ© en tant que l’utilisateur « root« . C’est en quelque sorte le superman de votre ordinateur : il a tous les droits. C’est une trĂšs mauvaise habitude, et un grand risque de sĂ©curitĂ© d’ĂȘtre connectĂ© en tant que root, c’est pourquoi nous allons crĂ©er un utilisateur !

La commande a entrer est celle-ci (en changeant utilisateur pour le nom d’utilisateur que vous dĂ©sirez crĂ©er).

adduser utilisateur

Suivez les instructions du terminal (soyez sĂ»rs de choisir un mot de passe solide !). Puis, ajoutez cet utilisateur Ă  la liste des « sudoers » : c’est la liste des utilisateurs qui sont autorisĂ©s Ă  effectuer des actions en tant qu’administrateur (parfois). Tapez la commande ci-dessous (en remplaçant utilisateur par votre nom d’utilisateur choisi, Ă©videmment).

usermod -aG sudo utilisateur

Pour ĂȘtre sĂ»r que cela fonctionne correctement, dĂ©connectez-vous de la machine en tappant :

exit

Puis connectez-vous cette fois-ci en utilisant votre nom d’utilisateur :

ssh utilisateur@adresseip

SĂ©curisation de la machine

La sĂ©curitĂ©, c’est important ! C’est pourquoi nous allons procĂ©der Ă  la mise en place de trois mesures de sĂ©curitĂ© : l’authentification par clĂ©, le changement de port SSH, et l’installation d’un pare-feu.

Je vais tenter d’expliquer simplement à quoi servent ces deux mesures.

  1. L’authentification par clĂ© : pour vous connecter Ă  votre machine vous avez utilisĂ© un mot de passe. Mais si votre mot de passe se fait hack, ou bien si vous avez choisi un mot de passe trop fragile, un hacker pourra facilement se connecter Ă  votre machine. C’est pourquoi nous allons utiliser l’authentification par clĂ© : vous allez crĂ©er une clĂ© SSH sur votre ordinateur, et c’est grĂące Ă  la prĂ©sence de cette clĂ© (et non le mot de passe) que vous serez autorisĂ© Ă  vous connecter.
  2. Changer le port SSH : Le port par dĂ©faut pour se connecter en SSH sur n’importe quelle machine est le 22. Cela veut dire qu’un hacker essaiera par dĂ©faut de vous attaquer par le port 22. En le changeant Ă  un autre port, il sera obligĂ© de deviner quel port vous avez choisi pour essayer de s’y connecter. Cela complique nettement la tĂąche !
  3. Installer un pare-feu : Par dĂ©faut, tous vos ports sont ouverts. Un attaquant peut donc essayer de vous attaquer sur beaucoup de ports diffĂ©rents. Un pare-feu rĂ©soud ce problĂšme : il rĂ©duits les ports ouverts, et donc rend la surface d’attaque beaucoup plus petite.

Authentification par clé

Nous allons créer votre clé SSH qui vous servira à vous connecter au serveur. Commencez par vous déconnecter de votre serveur (exit). Ensuite, tappez cette commande :

ssh-keygen -t ed25519

Ensuite suivez les instructions sur votre console. Une fois terminé, il vous faudra ajouter cette clé à la liste des clés autorisées par votre serveur :

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisatur@adresseip

Et voilĂ  le travail ! Votre clĂ© apparaĂźt dĂ©sormais parmi les clĂ©s autorisĂ©es sur votre serveur. Cependant, le serveur autorise toujours Ă  se connecter en fournissant le mot de passe de l’utilisateur : nous allons modifierons cela quand nous effectuerons le changement de port SSH.

Changer de port SSH

Commençons par mettre Ă  jour notre systĂšme.. Je ne vais pas dĂ©tailler ces commandes mais en gros, elles mettent Ă  jour le systĂšme, retirent les logiciels dont on ne se sert pas et installent UFW 🙂

Sudo et privilùges d’administrateur

Nous avons crĂ©Ă© un utilisateur qui n’est pas root car c’est risquĂ© de lancer toutes les commandes en tant qu’administrateur. Cependant, de temps en temps nous avons besoin de lancer des commandes en tant qu’administrateur. La solution : ajouter « sudo » au dĂ©but de la commande que nous lançons. Il se peut que lancer sudo vous demande votre mot de passe : c’est tout Ă  fait normal !

sudo apt update && sudo apt upgrade
 sudo apt dist-upgrade && sudo apt autoremove
 sudo apt install -y ufw

Maintenant nous pouvons changer le port SSH. Vous n’avez qu’à choisir un numĂ©ro de port entre 1024 et 49151, et vous assurez qu’il ne sort pas en rouge lorsque vous tapez cette commande (en remplaçant numerodeport par le numĂ©ro de port que vous avez choisi) :

sudo ss -tulpn | grep numerodeport

S’il sort en rouge, c’est qu’il est dĂ©jĂ  utilisĂ© par votre ordinateur. Choisissez en un nouveau et recommencez !

Ensuite, mettez à jour votre fichier de configuration SSH. Lancez l’editeur de nexte nano:

sudo nano /etc/ssh/sshd_config

Ici vous aurez 4 lignes Ă  modifier :

  • Remplacer la ligne « Port 22 » par « Port NUMERODEPORT » en remplaçant NUMERODEPORT par le numĂ©ro que vous avez choisi (spĂ©cifie le port utilisĂ© pour SSH).
  • Enlever le « # » devant la ligne « #PubkeyAuthentication yes » (spĂ©cifie que nous acceptons la conneixon par clĂ©).
  • Remplacer la ligne « PasswordAuthentication yes » par « Password authentication no » (spĂ©cifie que nous voulons dĂ©sactiver la connexion par mot de passe).
  • Remplacer la ligne « PermitRootLogin yes » par « PermitRootLogin no » (spĂ©cifie que nous voulons interdire de se connecter en tant que root).

Appuyez ensuite sur CTRL+o (la touche contrĂŽle et la touche o en mĂȘme temps), puis Entrer, puis CTRL+x (la touche contrĂŽle et la touche x en mĂȘme temps). C’est la suite Ă  tapper si l’on veut enregistrer un fichier et le fermer avec Nano.

Voici un GIF du dĂ©roulĂ© de l’opĂ©ration (avec comme exemple de port 39889).

Maintenant, nous pouvons redĂ©marrer le service SSH. Il suffit d’entrer cette commande :

sudo systemctl restart ssh

Attention, à compter de maintenant, pour vous connecter au serveur, la commande ne sera plus « ssh utilisateur@ip » mais « ssh -p NUMERODEPORT utilisateur @ip ».

Se connecter via l’interface Netcup.eu

Si vous vous retrouvez dans un cas ou vous ne parvenez plus à vous connecter à la machine en SSH, sachez que vous pouvez toujours vous reconnecter en passant par l’interface de de netcup.eu .

Plus d’information en bas de la page dans l’appendice.

Pour vous déconnecter, tapez:

exit

Puis reconnectez-vous :

ssh -p numerodeport utilisateur@adresseip

Installation du pare-feu

Maintenant faisons en sorte de rejeter les connexions par défaut :

sudo ufw default deny incoming

Acceptons les connections sur notre port SSH choisi :

sudo ufw allow numerodeportssh/tcp

Puisque nous allons utiliser Geth et Lighthouse, nous allons ouvrir les ports 30303 et 9000 (respectivement)

sudo ufw allow 30303
 sudo ufw allow 9000

Mettons maintenant en marche ces pare-feu :

sudo ufw enable

Maintenant, en tapant « sudo ufw status verbose« , vous devriez avoir un rendu similaire (mon port choisi pour SSH est le 38998) :

Et voilà ! Votre machine est désormais installée et sécurisée. Nous pouvons passer à la prochaine étape : créer les clés des validateurs.

Créer les clés de validateurs

Mainnet vs Testnet

Ce guide dĂ©tail les Ă©tapes nĂ©cessaires pour la mise en place d’un validateur sur le « mainnet », c’est-Ă -dire le rĂ©sau officiel Ethereum 2. Il existe cependant des « testnet », c’est-Ă -dire des rĂ©seaux qui permettent de tester, sans mettre en jeu des « vrais » ETH. Je vous recommande d’abord d’essayer d’installer et de lancer correctement un validateur sur un testnet. Pour ce faire, il suffit de remplacer « mainnet » par le nom du testnet (au moment de l’écriture, « pyrmont »).

Une fois le validateur ayant été correctement lancé sur le testnet, vous pourrez passer au mainnet !

Rendez-visite à ce site : https://github.com/ethereum/eth2.0-deposit-cli/releases/ et trouvez la version du logiciel pour linux : elle devrait se terminer par « linux-amd64.tar.gz« .

Voici à quoi elle ressemble au jour de création de ce guide :

Ensuite copiez-en le lien :

Maintenant, reprenez le terminal et tapez ces commandes (en remplaçant le lien « https:// » par le contenu de votre presse-papier (le lien que vous avez copiĂ© lors de l’étape prĂ©cĂ©dente)).

cd ~
 sudo apt install -y curl
 curl -LO https://github.com/ethereum/eth2.0-deposit-cli/releases/download/v1.1.0/eth2deposit-cli-ed5a6d3-linux-amd64.tar.gz

Vous venez de télécharger la version compressée du logiciel qui va vous servir à créer les clés de vos validateurs. Pour le décompresser, il vous suffit de taper :

tar xvf eth2deposit-cli-ed5a6d3-linux-amd64.tar.gz
 rm -rf eth2deposit-cli-ed5a6d3-linux-amd64.tar.gz
 cd eth2deposit-cli-ed5a6d3-linux-amd64

Les noms des fichiers pourraient diffĂ©rer sur votre machine : ici c’est eth2deposit-cli-ed5q6d3 car c’est la version actuelle, mais elle pourrait changer dans le futur. Pour l’afficher, lancez simplement la commande ls.

Vous pouvez maintenant créer vos clés ! Entrez cette commande (en changeant nombredevalidateurs par le nombre de validateurs que vous comptez lancer) :

./deposit new-mnemonic --num_validators nombredevalidateurs --mnemonic_language=english --chain mainnet

Prenez votre temps ! Gardez vos secrets au chaud


Prenez le temps de bien vérifier la commande que vous venez de taper. Avez-vous bien remplacé le NOMBREDEVALIDATEURS par le nombre de validateurs que vous comptez lancer ? Avez vous bien bien écrit « mainnet » ?

Dans cette commande, vous allez devoir noter vos mots de passe. Je vous recommande de les Ă©crire sur un bout de papier, d’en faire une deuxiĂšme copie et garder les deux copies dans deux endroits diffĂ©rents.

Personne ne pourra vous sauver si vous oubliez vos mot de passe ou vos mnemonics : c’est donc d’une importance capitale pour vous de vous appliquer pendant cette opĂ©ration.

PremiÚre étape : créer un mot de passe. Choisissez-en un (de préférence au hasard), de bonne qualité, et notez le sur le bout de papier. Ensuite lisez le bout de papier, et tapez-le ici. Soyez sûrs que ça correspond à ce que vous avez noté sur le bout de papier !

Ensuite vous verrez apparaĂźtre une liste de mots : c’est ce que l’on appelle votre mnemonic. Notez-le prĂ©cieusement, en faisant bien attention Ă  l’orthographe des mots (ils sont en anglais, attention aux faux amis!).

J’ai bien Ă©videmment pris le soin d’utiliser un autre mnnemonic que celui-ci


Vous devrez ensuite entrer, dans l’ordre, le mnemonic (suite de mots) que vous venez de noter. Soyez sĂ»rs de taper ce que vous avez Ă©crit sur votre papier !

Si vous tapez la commande ls, vous devriez avoir le mĂȘme rendu :

Dans le dossier validator_keys se trouvent plusieurs fichier : un fichier deposit_data
json, et autant de keystore-m
json que vous avez entré de numéro de validateurs. Le fichier deposit_data est un fichier unique qui contient des informations nécessaires pour pouvoir déposer des ETH pour staker : les fichier keystore-m sont des fichiers représentants vos clés de validateur. Ils seront utilisés par la suite !

Vous avez crĂ©Ă© vos clĂ© de validateur (ainsi que le fichier de deposit associĂ©, nous y reviendrons plus tard). Maintenant il est temps d’installer les logiciels !

Mise en place des logiciels

TroisiÚme étape: mettre en place les logiciels nécessaires au staking.
Ces instructions sont Ă©crites pour Ubuntu (Linux). Si vous utilisez une autre machine, il faudra probablement adapter quelques commandes !

Petit récapitulatif

Il y a trois logiciels principaux qui vont ĂȘtre exĂ©cutĂ©s par votre machine:

  • Le client Ethereum 1 : Oui, cela peut paraĂźtre Ă©tonnant mais la chaĂźne Ethereum 2 a besoin de connaĂźtre l’état de la chaĂźne Ethereum 1 afin de fonctionner correctement.
  • Le Beacon Node (BN) : C’est le logiciel qui s’occupe de communiquer avec les autres nƓuds du rĂ©seau, de la gestion de la base de donnĂ©e de la chaĂźne: bref c’est lui qui fait le gros du travail.
  • Le Validator Client (VC) : C’est le fameux « validateur » qui revient Ă  toutes les sauces. C’est un logiciel relativement simple, qui ne s’occupe de faire qu’une seule chose: signer des transactions. PĂ©riodiquement, il doit signer des transactions, grĂące Ă  sa clĂ© privĂ©e (clĂ© qui doit rester secrĂšte, bien cachĂ©e sur l’ordinateur). Il demande au BN quels messages il doit signer, s’assure que les informations renvoyĂ©es par le BN sont correctes, puis signe le message et le transmet au BN, qui lui le transmettra aux autres nƓuds du rĂ©seau.

Ce qui est intĂ©ressant, c’est que plusieurs VC peuvent se connecter au mĂȘme BN: en effet, on peut faire tourner des centaines de validateurs, qui se connectent tous au mĂȘme BN. Un VC ne consomme pas beaucoup (rappelez-vous, c’est le BN qui fait la majoritĂ© du travail), en lancer plusieurs sur la mĂȘme machine permet donc d’augmenter un peu la rentabilitĂ©.

Une question devrait vous traverser l’esprit : est-il possible de connecter son VC a un BN sur une autre machine ? La rĂ©ponse est oui ! Vous pourriez trĂšs bien connecter vos VCs au BN d’un ami, ou d’une entreprise, si vous leur faites confiance. Vous n’ĂȘtes donc pas OBLIGE de faire tourner un BN, si vous faites confiance Ă  un autre BN. Attention cependant : si le BN dans lequel vous avez confiance se met Ă  mal agir (se dĂ©connecter, ĂȘtre piraté ), vous pourriez en faire les frais ! C’est pourquoi il est recommandĂ© de faire tourner son propre BN.

Le paragraphe prĂ©cĂ©dent s’applique tout aussi bien au nƓud Ethereum 1 que vous devez lancer: vous pouvez dĂ©cider de ne pas en lancer, et de vous remettre Ă  un ami / une entreprise (par exemple Infura). Cependant, comme pour le BN, c’est dĂ©conseillĂ©, car on n’est jamais mieux servi que par soi-mĂȘme !

Machine peu performante

Si votre machine est peu performante, une solution pourrait ĂȘtre de ne pas lancer geth et d’utiliser un autre accĂšs Ă  la chaĂźne Eth 1.

Un des services les plus connus est Infura. Un tutoriel est disponible dans l’appendix afin d’en savoir plus. Cependant, comme Ă©crit just au-dessus, il est FORTEMENT recommandĂ© de lancer son propre client Ethereum 1 🙂

Les clients

Il y a plusieurs implĂ©mentations de clients pour Ethereum 2 : les plus connus sont Lighthouse, Prysm, Teku, et Nimbus. Chaque client a ses spĂ©cificitĂ©s (que ce soit l’équipe derriĂšre, l’histoire, les buts recherchĂ©s, le langage utilisĂ©, les caractĂ©ristiques techniques, la communautĂ© etc
). Dans cet article, nous allons utiliser l’implĂ©mentation Lighthouse, de l’équipe Sigma Prime.

Client Ethereum 1

De la mĂȘme maniĂšre que diffĂ©rent clients Ethereum 2 existent, il existe aussi plusieurs implĂ©mentations de client Ethereum 1. Les plus connus sont geth et openethereum (anciennement parity-ethereum). Dans ce tutoriel, j’utiliserai geth et parlerai de geth mais ce qu’il faut comprendre c’est « client Ethereum 1 ».

Nous avons deux possibilités pour lancer notre client :

  1. Classique : Nous téléchargeons les code source des clients, nous les compilons (ou téléchargeons directement le binaire), puis nous lançons les logiciels un par un (geth, BN et VC). Cette technique est standarde, fonctionne correctement et permet de personnaliser des paramÚtres.
  2. Docker-compose : C’est une technique qui repose sur l’utilisation d’un logiciel (docker-compose) qui fera tout ça Ă  notre place. Voyez-ça comme un logiciel qui gĂšre les autres logiciels : nous lui disons simplement « lance-moi une instance de geth, un BN, un VC, et connecte-les ensemble), et tada, le tour est jouĂ© !

J’ai personellement optĂ© pour l’utilisation de docker-compose : ça rend la tĂąche trĂšs simple Ă  utiliser, installer, et mettre Ă  jour.

Docker et Docker-Compose

Afin de nous faciliter la tĂąche, nous allons utiliser un logiciel qui s’occupera de lancer les autres logiciels Ă  notre place. Je vous prĂ©sente : Docker !

Pour installer Docker sur Ubuntu, c’est tout simple :

sudo apt install -y docker.io

Assurons-nous que Docker a bien été installé en lançant cette commande en la comparant au screenshot en-dessous.

sudo docker run hello-world

Si cette commande ne fonctionne pas, c’est probablement que docker n’a pas Ă©tĂ© correctement installĂ©. Dans ce cas, veuillez suivre les instructions d’installations officielles.

Profitons-en pour aussi installer Docker-Compose

sudo apt install -y docker-compose

Maintenant que nous avons installĂ© le logiciel docker-compose, il ne nous reste plus qu’à lui dire ce que nous voulons lui faire faire (lancer geth, un BN et un VC). Ca tombe bien : l’équipe de lighthouse a un dossier avec tout de dĂ©jĂ  prĂ©parĂ© !

Assurons-nous d’abord d’ĂȘtre dans le bon rĂ©pertoire :

cd ~

Puis téléchargeons le dossier de configuration

git clone https://github.com/sigp/lighthouse-docker/

La commande ls (qui liste les fichier du répertoire) devrait ressembler à cela maintenant :

Allez maintenant éditer le fichier de configuration. Déplacez-vous dans le bon répertoire :

cd lighthouse-docker

Faites une copie du fichier de configuration :

cp default.env .env

Et allez Ă©diter le fichier de configuration : (n’oubliez pas, pour quitter c’est CTRL+O, Enter, CTRL+X)

nano .env

Voici la liste des paramĂštres Ă  Ă©diter. Si le paramĂštre n’apparaĂźt pas dans cette liste, c’est qu’il doit ĂȘtre laissĂ© Ă  sa valeur par dĂ©faut. Attention, si vous voulez vous mettre sur le rĂ©seau de test, alors le paramĂštre NETWORK ne sera pas mainnet mais le nom du testnet (par exemple pyrmont).

NETWORK=mainnet
 START_VALIDATOR=YES
 VALIDATOR_COUNT=2
 START_GETH=YES
 ENABLE_METRICS=YES

Bien entendu je vous laisse Ă©diter VALIDATOR_COUNT pour ĂȘtre Ă©gal au nombre de validateurs que vous avez choisi de crĂ©er.

Si vous avez une machine puissante, vous pouvez aussi mettre SLASHER=YES afin de mettre en route un slasher.

Maintenant notre fichier de configuraiton prĂȘt, nous devons importer les validateurs. Pour ce faire, copiez d’abord les clĂ©s de validateurs dans le fichier courant.

cp -r ../eth2deposit-cli-ed5a6d3-linux-amd64/validator_keys/ .

Bien entendu il se peut que le nom de votre dossier varie : comme précisé au-dessus le mien est eth2deposit-cli-ed5a6d3-linux-amd64 mais je vous laisse adapter la commande à votre machine.

Puis initialisez les clés grùce à cette commande :

sudo docker run -it -v $(pwd)/lighthouse-data:/root/.lighthouse -v $(pwd)/validator_keys:/root/validator_keys sigp/lighthouse lighthouse --network mainnet account validator import --directory /root/validator_keys

Nous sommes fin prĂȘts ! Nous allons ouvrir un gestionnaire de fenĂȘtre, afin de conserver notre fenĂȘtre ouverte (plus d’info dans l’encart juste en-dessous).
D’abord installons tmux :

sudo apt install -y tmux

Puis lançons-le !

tmux

Et maintenant, la commande finale :

sudo docker-compose up

Et voilĂ  ! Vous devriez voir plein de messages fuser dans tous les sens. Ces messages sont des « logs », c’est-Ă -dire des messages qui dĂ©crivent le statut des diffĂ©rents logiciels (rappelez-vous, geth, BN et VC) qui tournent.

En bleu les messages Ă©mis par le BN, en jaune les messages de geth, et ne vert les messages des VC.

Si ces logs ne vous conviennent pas et vous voulez isoler seulement les logs du BN ou du VC, tappez :

sudo docker container ls --format '{{.Names}}'

Vous devriez avoir cela en sorite (peut-ĂȘtre deux lignes en plus si vous avez dĂ©jĂ  lancĂ© grafana / prometheus).

Pour suivre seulement les logs du validateurs par exemple :

sudo docker logs lighthouse-docker_validator_client_1 --follow

Et pour suivre le BN :

sudo docker logs lighthouse-docker_beacon_node_1

Ces commandes est lançable mĂȘme si vous n’ĂȘtes pas dans tmux, et vous pouvez les quitter Ă  tout moment en appuyant sur CTRL+c .

tmux

Nous avons lancĂ© les logiciels Ă  l’aide d’un gestionnaire de fenĂȘtre (appelĂ© tmux). Il permet aux logiciels de continuer Ă  tourner en tĂąche de fond. Pour vous dĂ©tacher de cette fenĂȘtre et la laisser tourner en tĂąche de fond, il vous suffit d’appuyer sur CTRL+b puis la lettre d.

A chaque fois que vous voudrez retrouver vos logiciels (pour les arrĂȘter, ou les mettre Ă  jour etc), il suffira de tapper tmux a. Vous pourrez donc faire des aller-retours jusqu’à vos logiciels grĂące Ă  ce gestionnaire de fenĂȘtre.

Vous pouvez quitter cet Ă©cran en appuyant sur CTRL+b puis d. Cela « dĂ©tache » l’écran tmux et vous renvoie vers l’écran de dĂ©part. Les logiciels continuer donc de tourner en tĂąche de fond. Pour retourner sur l’écran de tmux, tappez :

tmux a

Si vous voulez arrĂȘter complĂštement les logiciels : appuyez sur CTRL+c, puis entrez :

sudo docker-compose down

Mettre Ă  jour

En tant que validateur sur le rĂ©seau, vous avez comme devoir de tenir vos logiciels Ă  jour. Un tutoriel sur comment le faire est disponible dans l’appendix, en bas de la page 🙂

Maintenant que nous avons nos logiciels qui tournent, il ne nous reste plus qu’une Ă©tape : effectuer le(s) dĂ©pĂŽt(s) d’ETH sur le rĂ©seau ! Rendez-vous sur le site officiel : https://launchpad.ethereum.org/overview (vous pouvez prĂ©fixer le nom du testnet dĂ©sirĂ©, par exemple : https://pyrmont.launchpad.ethereum.org/overview pour le testnet de pyrmont).

Lisez attentivement les 10 étapes (un récapitulatif ne fais jamais de mal), et vous devriez arriver sur cette page:

Vous pouvez choisir les logiciels que l’on utilise : geth, puis Lighthouse

Maintenant indiquez le nombre de validateurs que vous voulez lancer (dans mon cas, 2)

Puis cochez la case qui certifie que vous avez copié vos mnemoniques et votre mot de passe, et cliquez sur Continue.

Sur la page suivante, vous allez uploader votre fichier deposit_data dont on a parlĂ© Ă  tout Ă  l’heure. Mais comment faire ? Le fichier se trouve sur mon serveur, pas du mon ordinateur ! Pas de panique ! J’ai la solution : scp !

scp est un programme qui permet de copier des fichiers depuis un serveur vers votre ordinateur (ou dans l’autre sens) de façon sĂ©curisĂ©.

D’abord crĂ©ons un dossier pour stocker nos fichiers :

cd ~
 mkdir validateurs
 cd validateurs

Sur votre terminal, dĂ©connectez-vous de votre machine (tapez exit), puis entrez simplement (en remplacant, comme d’habitude
) :

scp -r -P numerodeport utilisateur@adresseip:lighthouse-docker/validator_keys .

Et voilĂ  le travail ! Vous devriez maintenant pouvoir cliquer sur le gros bouton + prĂ©sent sur la page, et aller chercher le fichier deposit_data qui se trouve dans le dossier validateurs, dans votre rĂ©pertoire d’utilisateur (home directory).

Maintenant vous devriez pouvoir uploader le fichier deposit_data :

Et vous devriez voir cet Ă©cran ! (si vous ne vous ĂȘtes pas trompĂ©s de rĂ©seau !)

Maintenant il faut faire le dĂ©pĂŽt. Je vous laisse suivre le tutoriel d’installation de Metamask (vous pouvez y connecter votre Ledger si jamais c’est cela que vous utilisez)

Obtenir du gETH

Si vous vous apprĂȘtez Ă  faire un dĂ©pĂŽt sur un testnet, la monnaie utilisĂ©e n’est pas l’ETH mais le gETH (görli-ETH). Il peut s’obtenir via des faucets, ou en rejoignant le Discord d’EthStaker.

Attention : je suis ici sur pyrmont.launchpad.ethereum.org car j’ai fait ce tutoriel sur le testnet de pyrmont. Si vous voulez dĂ©poser sur le mainnet, il faut ĂȘtre sĂ»r dĂȘtre sur launchpad.ethereum.org !

Une fois Metamask installĂ©, soyez sĂ»rs d’ĂȘtre sur la bonne chaĂźne : Ethereum Mainnet pour un dĂ©pĂŽt sur le mainnet, et Goerli pour un dĂ©pĂŽt sur un testnet.

Vous n’avez plus qu’à lancer la transaction
 et tada ! Votre dĂ©pĂŽt aura Ă©tĂ© effectuĂ© ! Vous pouvez dĂ©sormais suivre l’état de vos validateurs : dans metamask, cliquez sur la transaction que vous venez d’effectuer.

DĂ©pĂŽt sur le testnet Pyrmont

Puis cliquez sur la flùche qui vous mùnera à l’explorateur de block :

Et ici vous pouvez voir les clĂ©s publique associĂ©es ! Vous pouvez consulter l’état de votre validateur en cliquant dessus.

Ici nous utilisons le site beaconscan. Un autre explorateur connu est beaconcha.in. Dans cette photo, mon dĂ©pĂŽt n’a pas encore Ă©tĂ© inclus : en effet, une votre dĂ©pĂŽt effectuĂ©, il faut du temps afin qu’il soit « inclus » et que votre validateur apparaisse dans la liste « officielle » des validateurs. Plus d’info sur ce procĂ©dĂ©.

Monitoring

Cette partie est optionelle : il s’agit de mettre en place un systĂšme de monitoring (afin de garder un oeil sur sa machine !). Nous allons utiliser Grafana et Prometheus : Prometheus va se charger de rĂ©cupĂ©rer des donnĂ©es de nos logiciels (mĂ©moire utilisĂ©e etc), et Grafana se chargera de les afficher.

Encore une fois, docker va nous sauver ! Nous allons cloner le repo lighthouse-metrics qui a déjà tout de préparé pour nous :

cd ~
 git clone https://github.com/sigp/lighthouse-metrics
 cd lighthouse-metrics

Ensuite, nous allons lancer grafana et prometheus grñce à la commande
 docker-compose ! Notez l’utilisation de -d, qui permet de le lancer en tñche de fond.

sudo docker-compose up -d

Maintenant nous pouvons passer Ă  la derniĂšre Ă©tape : visualiser les donnĂ©es ! DĂ©connectez-vous du serveur (tappez exit), et tappez la commande suivante (en remplacant, comme d’habitude):

ssh -p numerodeport -L 127.0.0.1:3000:127.0.0.1:3000 utillisateur@adresseip

Et maintenant, sur votre navigateur, tapez cette URL : localhost:3000 ! Vous devriez arriver sur un panneau de configuration ! Le nom d’utilisateur est admin et le mot de passe changeme. Ensuite, vous devrez cliquer sur le bouton Manage

Puis cliquez sur le bouton Import

Maintenant vous devez visiter cette page et en copier le contenu, et le coller le contenu dans la box « Import panel via JSON »

Puis cliquez sur Load et Import et
 tada !!

C’est un panneau de monitoring global, il vous est bien sĂ»r possible de modifier et l’adapter Ă  vore convenance !

Aller plus loin

Des amĂ©liorations sont toujours possibles ! Vous pourriez crĂ©er des services qui se relancent automatiquement, avoir un systĂšme de sauvegarde, avoir un meilleur systĂšme de logging
 cependant ce guide n’est lĂ  que pour couvrir les bases. Il ne faut vraiment pas hĂ©siter Ă  aller chercher de l’aide et poser des questions, voici donc quelques recommandations de site / communautĂ©s qui pourraient vous intĂ©resser :

https://reddit.com/r/ethstaker/ : Le subreddit d’une communautĂ© de staker (je vous recommande de rejoindre le Discord, c’est un des meilleurs endroits pour poser des questions)
https://reddit.com/r/ethereum : Le subreddit officiel d’Ethereum
https://lighthouse-book.sigmaprime.io/ : La documentation officielle de Lighthouse
https://docs.prylabs.network/docs/getting-started/ : La documentation officielle de Prysm
https://docs.teku.consensys.net/en/latest/ : La documentation officielle de Teku
https://status-im.github.io/nimbus-eth2/ : La documentation officielle de Nimbus

Pour se renseigner sur le protocole en général il y a bien entendu :
– La spĂ©cification officielle : https://github.com/ethereum/eth2.0-specs
– Cet article que j’ai particuliĂšrement apprĂ©ciĂ© : https://ethos.dev/beacon-chain/
– Les spĂ©cifications commentĂ©es de Vitalik et de Ben Edgington

Appendice

Détails sur les pénalités

Base de données des Slashings

Une des rĂšgles du rĂ©seau est qu’un validateur ne doit jamais publier deux messages conflictuels pour un mĂȘme block. Pour ĂȘtre sĂ»r qu’il ne publie jamais de messages conflictuels, un validateur tient Ă  jour une base de donnĂ©e de tous les messages qu’il a envoyĂ©. Cette base de donnĂ©e (souvent appellĂ©e slashing protection database, et situĂ©e dans ~/lighthouse-docker/lighthouse-data) est TRES importante, car si vous la perdez, votre validateur pourrait bien publier deux messages conflictuels et se faire pĂ©naliser !

Il est donc recommandĂ© d’en faire une sauvegarde rĂ©guliĂšrement ! Et si vous la perdez, il est recommandĂ© d’attendre plusieurs heures avant de relancer votre validateur, afin de rĂ©duire les chances qu’il produise des messages conflictuels.

Il y a deux grosses catégories de pénalités que vous pourriez encourir :

  1. Slashing : une grosse partie de vos ETH sont retirĂ©s instantanĂ©ment, et votre validateur se fait exclure (il ne peut plus staker). Cela pourrait se produire si vous lancez deux fois le mĂȘme validateur, ou si vous utillisez une version malicieuse d’un client. Cela pourrait aussi se produire dans le cas ou vous perdez votre base de donnĂ©e de protection (voir l’encart juste au-desus).
  2. Leaking : C’est le fait d’avoir une « fuite » d’ETH dĂ» Ă  une absence. Si votre validateur n’est pas en ligne, il subit des pertes. Ces pertes sont proportionelles au nombre de validateurs qui sont hors-ligne en mĂȘme temps que vous. Si vous ĂȘtes tout seul, les pĂ©nalitĂ©s sont minimes (de l’ordre de 0.3% par semaine, ce qui vous laisse LARGEMENT le temps de revenir en ligne), mais si la moitiĂ© du rĂ©seau en hors-ligne en mĂȘme temps, alors les pĂ©nalitĂ©s augmentent trĂšs rapidement. Il y a donc un risque Ă  avoir votre machine chez un hĂ©bergeur type AWS ou netcup.eu : s’ils tombent en panne, vous ne serez pas le seul Ă  ĂȘtre hors-ligne et encourerez donc des peines plus Ă©levĂ©es


Se connecter via l’interface de Netcup.eu

Rendez-vous sur le servercontrolpanel et cliquez sur votre machine. Ensuite cliquez sur la « Console » en haut Ă  droite de l’écran (entourĂ© en rouge sur la photo).

Une fenĂȘtre pop-up devrait s’ouvrir (si elle ne s’ouvre pas vĂ©rifiez les paramĂštres de votre navigateur). Ici, il vous suffit de vous connecter en entrant d’abord le nom d’utilisateur, puis le mot de passe de votre utilisateur. Si vous n’avez pas encore d’utilisateur, utilisez les identifiants de root.

Cela vous donne accĂšs Ă  un shell classique : Ă  vous de rĂ©soudre les problĂšmes afin de pouvoir vous reconnecter depuis votre interprĂȘteur ! (Probablement un problĂšme de port SSH / pare-feu
)

Infura et autres ETH1 endpoints

Si votre machine est peu performante, une solution possible est d’utiliser un « fournisseur » d’accĂšs Ă  ETH1 plutĂŽt que de faire tourner votre propre instance de geth. C’est plus risquĂ© (car vous devez faire confiance Ă  votre fournisseur plutĂŽt que de lancer un client par vous-mĂȘme), mais cela devrait rĂ©duire les ressouces utilisĂ©es par votre machine.

Infura

Je vais ici donner un exemple de mise en place avec Infura. Si vous avez dĂ©jĂ  votre fournisseur d’accĂšs Ă  Ethereum 1, vous pouvez passer cette Ă©tape.

Rendez-vous sur le site infura.io et créez un nouveau compte.

Une fois votre compte crĂ©Ă©, cliquer sur l’onglet Ethereum dans la barre de gauche.

CrĂ©ez ensuite un nouveau projet en cliquant sur « Create New Project » (il se peut que l’interface soit diffĂ©rente si c’est votre premier projet)

Ensuite cliquez sur votre projet et allez dans l’onglet Settings.

En bas de la page vous trouverez les informations qui nous intĂ©ressent : le menu dĂ©roulant vous permet de choisir le rĂ©seau (mainnet pour le rĂ©seau officiel, Görli pour les testnets). Puis vous pouvez copier l’URL (entourĂ© en rouge) qui vous servira dans l’étape suivante.

Modifications Ă  apporter

GrĂące Ă  docker-compose, cette modification est un rĂ©el jeu d’enfant : il n’y a que deux lignes Ă  modifier !

nano .env

Ensuite les deux lignes Ă  modifier sont : START_GETH qui doit ĂȘtre vide, et VOTING_ETH1_NODES qui doit ĂȘtre mis Ă  l’URL du fournisseur d’accĂšs Ă  ETH1 (celui que vous avez copiĂ© si vous avez suivi le tutoriel Infura).

START_GETH=
 VOTING_ETH1_NODES=urldufournisseur

Les autres paramÚtres sont à laisser comme dans décrit plus haut dans le guide.

Et voilà le travail ! Maintenant lorsque vous lancerez vos logiciels (sudo docker-compose up), vous passerez par votre fournisseur plutÎt que par geth ! Vous pouvez donc supprimer le dossier geth maintenant pour libérer de la place sur votre machine :

sudo rm -rf ~/lighthouse-docker/geth-data

Migrer vos validateurs

La migration de validateurs d’un serveur Ă  un autre est une opĂ©ration facile mais qui nĂ©cessite une attention particuliĂšre. Le dossier important Ă  copier se trouve dans lighthouse-data/mainnet/validators (ou /testnet/ si sur testnet).

Attention, cette migration ne sert que si vous changez de machine mais comptez utiliser le meme client (Lighthouse). En attendant l’EIP-3076, changer de client n’est PAS recommandĂ©.

De plus nous copierons aussi le dossier secret afin d’éviter de devoir importer les validateurs de nouveau.

Ok premiĂšre Ă©tape : s’assurer que nos validateurs sont Ă©teints. Pour ça :

tmux a

Puis CTRL+c et ensuite

sudo docker-compose down

Sont-ils vraiment Ă©teints ?

Pour vous assurer que vos validateurs sont Ă©teints, vous pouvez entrer la commande sudo docker container ls --format {{.Names}} et vĂ©rifier que rien la sortie de cette commande est vide (ou au moins qu’elle ne contient pas « validator_client ».

Nous allons devoir autoriser la connexion en tant que root. Oui c’est une mauvaise pratique, et nous ne le ferons que temporairement, car les fichiers qui se trouvent dans validators appartiennent à root.

Pour ce faire, il faut aller éditer le fichier /etc/ssh/sshd_config et changer la ligne « PermitRootLogin no » en « PermitRootLogin yes« . Pour que cette modification ait lieu, il faut ensuite redémarrer le service ssh : sudo systemctl restart ssh.

Maintenant vous pouvez vous déconnecter de la machine (exit), et vous déplacer dans le dossier Validateurs que nous avions créé précédemment.

cd ~/validateurs

De lĂ  il ne nous reste plus qu’à copier le dossiers validators ainsi que les dossiers secrets et wallets (les derniers ne sont pas nĂ©cessaires mais ils son pratiques). Bien sĂ»r il vous faut remplacer numerodeportssh, utilisateur, et adresseip (et mainnet si vous utilisez un testnet).

scp -r -P numerodeportssh root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/validators .
scp -r -P numerodeportssh root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/secrets .
scp -r -P numerodeportssh root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/wallets .

Une fois cette opération effectuée, vous pouvez retourner sur le serveur et retirer le login en tant que root (PermitRootLogin).

Maintenant il faut faire le chemin inverse : c’est Ă  dire envoyer vos dossiers validators et secrets sur votre nouvelle machine, dans le bon rĂ©pertoire. Je pars du principe ici que la nouvelle machine est dĂ©jĂ  crĂ©e, et que vous avez dĂ©jĂ  clonĂ© les repo lighthouse-docker (que vous avez suivi ce tuto quoi !). Assurez-vous aussi que PermitRootLogin est mis sur yes. La manipulation est simple :

scp -r -P numerodeportssh validators root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/validators
scp -r -P numerodeportssh wallets utilisateur@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/wallets
scp -r -P numerodeportssh secrets utilisateur@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/secrets

Enfin nous allons copier le dossier validator_keys afin qu’il soit sur notre serveur aussi :

scp -r -P numerodeport ~/validateurs/validator_keys utilisateur@adresseip:lighthouse-docker/validator_keys

Et voilà ! Le tour est joué ! Vous pouvez commencer à valider sur cette nouvelle machine ! Assurez-vous de bien avoir remis PermitRootLogin no, et assurez-vous de bien avoir éteint votre ancienne machine !

Mettre Ă  jour les logiciels

Eh oui, en tant que validateur sur le rĂ©seau, il vous faudra vous assurer d’ĂȘtre Ă  jour !

D’abord Ă©teindre grafana et prometheus :

cd ~/lighthouse-metrics
 sudo docker-compose down

Puis Ă©teindre le BN, geth et les VC en attachant tmux

tmux a

Puis en l’interrompant (CTRL+c), puis en le stoppant :

sudo docker-compose down

Quittez votre session tmux en appuyant sur CTRL+d.

Maintenant vous pouvez mettre Ă  jour les paquets :

sudo apt update && sudo apt upgrade

Puis mettre Ă  jour les logiciels :

cd ~/lighthouse-metrics && git checkout . && git pull origin stable && sudo docker-compose pull
 cd ~/lighthouse-docker && git checkout . && git pull && sudo docker-compose pull

Maintenant il faut retourner Ă  l’étape de crĂ©ation du fichier .env (en haut de cette page !), puis vous pourrez relancer les logiciels : d’abord tmux, puis sudo docker-compose up, puis CTRL+b, puis d, ensuite cd ~/lighthouse-metrics, puis sudo docker-compose up -d !

The post Guide pour débutants : staker sur Ethereum 2 ! first appeared on Ethereum France.

Ethereum France Live: Se préparer à Ethereum 2 avec Mehdi Zerouali

November 22nd 2020 at 23:31

Mardi 24 Novembre, Ethereum France a le plaisir de recevoir Mehdi Zerouali, cofondeur et directeur de Sigma Prime pour une présentation de Lighthouse.

Venez nombreux Ă  l’heure du dĂ©jeuner sur Youtube pour dĂ©couvrir ce client Ethereum 2 et poser toutes vos questions Ă  Mehdi, notamment sur les aspects pratiques de la participation Ă  la preuve d’enjeu (Proof of Stake) sur Ethereum.

Giorgio da Castelfranco, dit Giorgione (1477-1510), Les trois philosophes (1504) Kunsthistorisches Museum, Wien

Alors que la génération du premier bloc de la beacon-chain est prévue au plus tÎt pour le mercredi 2 décembre 2020, il est urgent de se préparer à ce changement.

AprĂšs avoir accueilli Mamy Ratsimbazafy (dĂ©veloppeur du client Ethereum 2 Nimbus chez Status) la semaine derniĂšre, c’est au tour d’un autre français de venir vous parler du client Lighthouse que dĂ©veloppe sa sociĂ©tĂ© Sigma Prime. Mehdi a dĂ©jĂ  eu l’occasion d’exposer ses travaux Ă  EthCC en 2019 (vous pouvez retrouver son intervention ici).

Rendez-vous Ă  12h30 mardi 24 novembre sur notre chaĂźne Youtube.

The post Ethereum France Live: Se préparer à Ethereum 2 avec Mehdi Zerouali first appeared on Ethereum France.

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.

Ethereum France – Live: En route pour l’EIP-1559 avec BarnabĂ© Monnot

November 7th 2020 at 18:40

Mardi 10 Novembre, Ethereum France reçoit BarnabĂ© Monnot pour une prĂ©sentation de l’EIP-1559 Ă  l’heure du dĂ©jeuner sur Youtube.

La forge de Vulcain – Diego Velázquez, 1630

Alors que le contrat de dĂ©pĂŽts pour participer Ă  la preuve d’enjeu sur Ethereum 2 vient d’ĂȘtre dĂ©ployĂ©, une autre Ă©volution majeure d’Ethereum se prĂ©pare: l’EIP-1559.

L’association Ethereum France recevra BarnabĂ© Monnot, chercheur au Robust Incentives Group de la Fondation Ethereum, pour une prĂ©sentation de l’EIP-1559 ce mardi 10 novembre Ă  12h30. Cet Ă©vĂ©nement aura lieu en direct sur notre chaĂźne Youtube, Ă  cette adresse. Vous pourrez poser toutes vos questions Ă  BarnabĂ© sur le chat et sur le slack de notre association (pour le rejoindre c’est par ici!). Venez nombreux!

Cette proposition veut transformer de fonds en comble le fonctionnement du systĂšme des frais de transaction et peut ĂȘtre Ă  juste titre prĂ©sentĂ©e comme l’ultime Ă©lĂ©ment de la politique monĂ©taire du protocole.

En effet, depuis le dĂ©but de l’annĂ©e les frais de transaction se sont montrĂ©s trĂšs volatiles notamment avec l’explosion des applications de finance dĂ©centralisĂ©e. Cela a mis en Ă©vidence les inefficiences du systĂšme actuel de frais de transaction qui se rapproche en pratique Ă  type d’enchĂšre trĂšs commun (en anglais First-price sealed-bid auction). Les utilisateurs signent une transaction avec des frais associĂ©s puis les mineurs intĂšgrent dans le prochain bloc les transactions avec les frais les plus hauts jusqu’à Ă©puisement de la place dans le bloc. Chaque utilisateur paye ce qu’il a proposĂ© au moment de la signature et des mĂ©thodes d’estimation complexes sont nĂ©cessaires pour suggĂ©rer aux utilisateurs un juste prix (voir cet article pour une analyse du problĂšme sur bitcoin). Au final, les utilisateurs paient souvent plus cher qu’ils n’auraient dĂ» ou bien se retrouvent Ă  attendre plus longtemps que prĂ©vu avant que leurs transactions ne soient traitĂ©es. Ce problĂšme a nĂ©anmoins en partie Ă©tĂ© rĂ©glĂ© par l’émergence de services comme les relayeurs dont Vincent le Gallic a dĂ©crit le fonctionnement dans cet article.

Enfin Ă  moyen terme la chaĂźne que nous connaissons aujourd’hui comme le rĂ©seau principal d’Ethereum ne devrait plus rĂ©compenser les mineurs pour la crĂ©ation de nouveau bloc et cela met en cause les mĂ©canismes d’incitation que l’EIP-1559 va permettre de corriger.

Rendez-vous mardi Ă  l’heure du dĂ©jeuner pour faire le tour de cette EIP Ă  l’un des experts du sujet!

The post Ethereum France – Live: En route pour l’EIP-1559 avec BarnabĂ© Monnot first appeared on Ethereum France.
❌