The post Les français qui font Ethereum #4 : Guy-Louis Grau de Status appeared first on Ethereum France.

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.

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

• Twitter: https://twitter.com/Ethereum_France
• Discord: https://discord.com/invite/2cGc5JP4JC
• Youtube: https://www.youtube.com/channel/UCf7zF8tFOb9T58nBo09BhAw
• Meetup: https://www.meetup.com/fr-FR/ethereum-france/?_locale=fr-FR

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

• Twitter: https://twitter.com/Ethereum_France
• Discord: https://discord.com/invite/2cGc5JP4JC
• Youtube: https://www.youtube.com/channel/UCf7zF8tFOb9T58nBo09BhAw
• Meetup: https://www.meetup.com/fr-FR/ethereum-france/?_locale=fr-FR

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

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.

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…

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 :

• Social Slashing (Eric Wall)
• The Fight for MEV (Alex Vinyas)
• Cost of Feudalism: Towards a Theory of MEV (Guillermo Angeris, Tarun Chitra)

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

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.

• What to know about Zero Knowledge (Vitalik Buterin)
• ZK Applications Design Patterns (Yi Sun, Lakshman Sankar)
• ZK Badges: A new primitive for self sovereign identities (Hadrien, Sismo)
• ZKPs and « Programmable Cryptography (Gubsheep)

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

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 :

• Account Abstraction Panel (Julien Niset, Vitalik Buterin)
• ELI5: Account Abstraction (Liraz)
• Account Abstraction on Starknet (Martin Triay)

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

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

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 :

• Bad Proofs in Formal Verification (Uri Kirstein)
• Read-only Reentrancy – a Novel Vulnerability class responsible for 100m+ funds at risk (Ioannis Sachinoglou)

« 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… »

« 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 ! »

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.

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

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

• Making sense of the Ethereum Foundation (Josh Stark)
• Mental Health and Avoiding Burnout in your crypto gig (Hudson Jameson)
• Positive Framing and Communication for Web3 (Oliver JL Renwick)
• Original Sin (Taylor Monahan)

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 !

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

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

• Twitter: https://twitter.com/Ethereum_France
• Discord: https://discord.com/invite/2cGc5JP4JC
• Youtube: https://www.youtube.com/channel/UCf7zF8tFOb9T58nBo09BhAw
• Meetup: https://www.meetup.com/fr-FR/ethereum-france/?_locale=fr-FR

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

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”?

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 

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:

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

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

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

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.

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.

• Solo staking (nécessite 32 ETH): https://ethereum.org/en/staking/solo/?.
  Nous avons également écrit un guide sur Ethereum-France, que vous retrouverez ic i: https://www.ethereum-france.com/guide-pour-debutants-staker-sur-ethereum-2/#mise-en-place-des-logiciels
  (nous vous recommandons cependant de switcher vers eth-docker VS lighthouse)
• SaaS (Staking As A Service) : https://ethereum.org/en/staking/saas/ 
• Pool Staking : https://ethereum.org/en/staking/pools/ 

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

• The Merge sur le blog ethereum.org: https://ethereum.org/en/upgrades/merge/ 
• PoS: sur le blog ethereum.org: https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/  
• Mega Merge Resource List https://notes.ethereum.org/Moiv99h9QTmI-imPL8pvQg?view 
• Q&As: https://ethmerge.com/ 
• Client Diversity: https://clientdiversity.org/#switch 
• Supply d’Ethereum: https://ultrasound.money/ 
• Comptes Twitter pour suivre les annonces Ethereum et du Merge
  • Compte de la fondation Ethereum
  • Ethereum-France 
  • Liste: https://twitter.com/NathanSexer/status/1536756748194832386?s=20&t=XEOBBneAFkupVCQAXgy0pg 

Pour suivre Ethereum-France

• Twitter: https://twitter.com/Ethereum_France
• Discord: https://discord.com/invite/2cGc5JP4JC
• Youtube: https://www.youtube.com/channel/UCf7zF8tFOb9T58nBo09BhAw
• Meetup: https://www.meetup.com/fr-FR/ethereum-france/?_locale=fr-FR

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

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

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

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

Mécanismes de consensus : PoS, PoW, PoA

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

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

Implémentation d’Ethereum

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

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

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

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

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

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

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

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

La mise en jeu exige un effort actif

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

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

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

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

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

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

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

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

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

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

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

Censure limitée des sous-minorités

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

Censure agressive de la sous-minorité

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

Censure limitée des minorités

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

Censure agressive des minorités

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

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

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

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

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

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

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

Améliorations possibles d’Ethereum

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

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

Principaux malentendus

PoS = Gouvernance onchain

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

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

PoS = Banque centrale

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

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

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

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

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

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

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

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

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

PoS = Pas de ventes forcées

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

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

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

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

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

PoS = aucune consommation réelle de ressources

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

PoS = mauvaise complexité

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

Risques réels

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

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

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

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

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

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

Qu’est-ce que cela signifie pour moi ?

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

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

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

Conclusion

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

Annexe

Définitions

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

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

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

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

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

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

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

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

La cinquième édition de l’Ethereum Community Conference (EthCC[5]), organisée par Ethereum-France, a débuté aujourd’hui.

Elle se tient à Paris, à la Maison de la Mutualité, du 19 au 21 Juillet 2022.

Cette année, ce sont plus de 280 speakers et plus de 2000 participants qui sont présents à l’évènement.

Nous pensons que le partage et la transmission des connaissances sont le moyen le plus efficace de développer un écosystème positif et fertile. Pour cette raison, l’EthCC couvre de nombreux sujets différents et s’adresse à différents niveaux de compréhension de la technologie blockchain, à travers des conférences et des ateliers.

Accès en direct et enregistrements

L’intégralité des talks sont enregistrés et retranscris en direct ICI.

L’agenda et la liste des talks, c’est par LÀ.

Agenda

EthCC[5] est composée de 12 Tracks: Blockchain economics, Blockchain for good, Decentralised Finance, Developer Tools, Enterprise, Ethereum Layers, Gaming, Governance, NFTs, Security & Privacy, UX/UI, Web3.0 de talks et workshops, répartis dans 6 salles.

Remerciements

L’évènement est rendu possible grâce à au support de nos sponsors et partenaires médias, que vous retrouverez sur notre site https://ethcc.io/, ainsi qu’à nos +100 volontaires, que nous remercions chaleureusement.

EthCCWeek

En parallèle, nous hébergeons l’EthCCWeek, une initiative collaborative rassemblant les +100 évènements ouverts à tous qui s’organisent de manière organique autour d’EthCC.

Pour ne rien manquer

• EthCC Agenda: https://ethcc.io/agenda
• EthCC Livestreams: https://ethcc.interspace.chat/
• EthCCweek: https://ethccweek.fr/
• Twitter: https://twitter.com/EthCC, https://twitter.com/EthCCweek, https://twitter.com/Ethereum_France
• Telegram: https://t.me/ethccweek & https://t.me/ETHcc2023
• Discord: https://discord.com/invite/2cGc5JP4JC
• Meetup: https://www.meetup.com/fr-FR/ethereum-france/?_locale=fr-FR

Dans notre série de textes de référence, après le Manifeste d’un Cypherpunk, voici la traduction française par philh du Manifeste DarkFi. DarkFi est un projet à la fois politique et technologique, s’inscrivant dans la veine cypherpunk la plus pure. Il est animé par Amir Taaki, Ivan Jelincic et Rose O’Leary.

Nous sommes en 2013. Le directeur du FBI prononce un discours intitulé “Le problème de la fuite dans l’obscurité”. Il met solennellement en garde contre une menace émergente pour les forces de l’ordre. Depuis les révélations de Snowden, la sensibilisation croissante du public à la surveillance a encouragé l’utilisation à grande échelle des technologies de chiffrement – ce qu’il considère être la technologie idéale pour les criminels.

Malheureusement, la législation est en retard par rapport à la technologie, et ce décalage a permis l’apparition d’un problème significatif de sécurité publique. Nous l’appelons “la fuite dans l’obscurité” (“Going Dark”).
– James Comey, directeur du FBI

Ce discours a mis en lumière un nouveau risque : la diffusion massive du chiffrement menace de créer un environnement en ligne impénétrable, que les forces de l’ordre ne pourront pas investir. Nous affirmons que ces zones d’ombre sont indispensables à la réalisation d’une société véritablement démocratique. Le développement récent des DAO et de la finance décentralisée (DeFi) représente un pas de plus dans cette direction.

D’autres percées dans le domaine de la cryptographie, telles que les preuves à divulgation nulle de connaissance (zero-knowledge proofs), ouvrent une nouvelle ère de remises en cause et de bouleversements. Ce document donne un aperçu de ces avancées et présente notre projet : DarkFi.

DarkFi n’est pas une start-up. C’est une expérience économique démocratique, un système d’exploitation pour la société.

Destruction sociale et Megamachine

La situation s’est développée depuis que le discours de Comey en 2013. La logique de l’expansion permanente de l’État, accompagnée d’une émission monétaire débridée et de l’industrialisation de masse ont plongé la société dans un état de guerre permanent. Le pouvoir et l’appareil d’État contrôlent, oppriment et surveillent la société tandis que la big tech nous emprisonne dans une cage numérique.

Cet état de guerre a été appelé “sociocide”. La société est progressivement privée de sa nature morale et politique. Le peuple se transforme en masse docile.

L’Internet devient un moyen d’extraire du profit à partir de la plus inepte des activités : cliquer sur des publicités. Il conduit à la collecte massive de données personnelles et à l’édification d’une méga-machine de surveillance. Il encourage la docilité et la consommation plutôt qu’à une utilisation active individualisée. Il s’agit d’une architecture d’oppression basée sur le contrôle de l’utilisateur.

Des intelligences artificielles sont constamment perfectionnées pour faire la guerre à la résistance et renforcer l’aliénation des personnes incarcérées dans des mégapoles géantes. Avec l’arrivée des monnaies numériques des banques centrales (CBDC) et du revenu de base universel (UBI), le pouvoir centralisé cherche à fermer les arènes économiques concurrentes. L’État corporatif tend à monopoliser la vie économique. L’introduction du crédit social en Chine a été une expérience instructive que les États occidentaux cherchent à imiter.

Ce qui reste dans ce monde appauvri est une nouvelle et sinistre forme de fascisme et une société épuisée qui a perdu son tissu moral et politique. Une telle société est incapable de s’auto-organiser ou d’agir de son propre chef. La méga-machine produit constamment des méthodes innovantes pour extraire le pétrole du sol, le poisson des océans et le sang de la société, alors même que ces ressources s’épuisent jusqu’au point de non-retour.

Pendant 20 ans, nous avons contribué au logiciel libre. C’était un mouvement d’une vitalité et d’une créativité incroyables, qui explorait des idées bien avant que l’industrie du logiciel propriétaire n’ose y toucher. Mais être un développeur de logiciels libres à plein temps était difficile. Nous avions beau créer énormément de valeur, nous étions pour la plupart sans ressources. Il n’y avait pas de moyen de récupérer une partie de cette valeur que nous produisions. Cette incapacité limitait l’expansion du mouvement. De brillants concepts n’ont pu être réalisés et la société n’a pas profité de leurs bénéfices potentiels.

Pourtant, le mouvement du logiciel libre disposait de développeurs de premier plan et d’une communauté convaincue. Mais le mouvement manquait tout simplement de ressources en raison de l’absence de modèle économique.

Tokenisation

La tokenisation nous offre à présent une alternative. La monnaie programmable présente tout un éventail de techniques permettant de développer l’économie des réseaux.

L’ingénierie des tokens et les DAO sont en train de briser le moule de l’ancien monde. L’ancien monde est extractif, hiérarchique et rigide. Le nouveau monde est riche, intense et créatif.

Dans le modèle traditionnel de l’entreprise, il y a une dichotomie consommateur-producteur. Cette distinction n’existe pas en crypto. L’accent est mis sur la communauté et la richesse collective. A la différence du modèle de l’entreprise exploitant les utilisateurs à des fins lucratives et monopolisant le profit, les propriétaires et les producteurs constituent eux-mêmes la communauté.

La valeur d’un projet est directement proportionnelle à sa communauté. Les tokens capturent la valeur générée par une communauté et la lui retournent. La capacité des projets à stimuler l’enthousiasme et l’engagement est donc cruciale. Les communautés encouragent l’autonomie des individus par la participation et le narratif. Cela conduit à son tour à des transformations démocratiques induites par la sensibilisation de l’individu aux valeurs d’autogestion et d’autodéveloppement.

Cette évolution sociale n’est nulle part plus apparente que dans les DAO. Les DAO sont une nouvelle forme de gouvernance qui permet aux forces démocratiques latentes de se rassembler et de s’organiser avant que les forces du pouvoir et du capital ne puissent les dominer. Elles permettent d’explorer des modes de libération nouveaux. Les utilisateurs deviennent des parties prenantes participant directement aux décisions de gouvernance. Ils peuvent influer sur les objectifs de développement, les caractéristiques des projets, les modes de rémunération, l’allocation des capitaux, les investissements.

La politique est fondée sur le développement d’espaces publics de délibération. C’est sous cet angle que la crypto est profondément politique. La politique consiste à prendre des décisions concernant les intérêts collectifs de la société, tels que le bien-être, la sécurité et la liberté des individus qui la composent. En ce sens, politique et démocratie directe convergent.

L’ancien modèle technologique est anti-politique car il ôte la propriété au peuple et la place entre les mains de monopoles. L’ancien modèle encourage foncièrement la passivité et l’indifférence, en réduisant les gens à des consommateurs. C’est essentiellement ce à quoi conduit la technologie moderne, depuis l’origine de la civilisation il y a 5000 ans.

L’entrée Wikipedia (en anglais) pour “civilisation” indique :

La civilisation concentre le pouvoir en étendant le contrôle de l’homme sur le reste de la nature, y compris sur les autres êtres humains.

Au cours de l’histoire, la lutte entre la société démocratique et le système étatique de la civilisation est passée par des phases d’intensité variable. Parfois, cette lutte a éclaté en conflit ouvert. A d’autres moments, une paix précaire s’est installée. Le conflit s’est intensifié à l’ère moderne. La société est aujourd’hui confrontée à des moyens de coercition automatisés, à la surveillance de masse et à des opérations de manipulation visant à saper la liberté morale et politique du peuple.

Groupes politiques autonomes

Le totalitarisme ne peut pas être défait sans insurgence. La déférence ne fait qu’enhardir les puissants. La terreur totalitaire se déchaîne quand l’opposition disparait et que le pouvoir en place ne la craint plus. La complaisance nourrit le totalitarisme. Pour le contrer, résister est essentiel.

Les sociétés parallèles constituent des poches de liberté, renforcent l’idéologie de résistance et forment la base d’une nouvelle société. Elles peuvent être consacrées aux technologies, à l’économie, à l’éducation ou à la culture.

Avec les DAOs et la finance décentralisée (DeFi), nous pouvons créer des nations démocratiques où cultures, ethnicités et options politiques diverses cohabitent au sein d’une structure confédérale.

DAOs + DeFi = Groupes Politiques Autonomes

Sous la forme de groupes politiques autonomes, de nombreuses nations peuvent exister en ligne, libre de toute domination externe. Ces nations sont contrôlées par leurs propres communautés. Les décisions proviennent de la base.

Multi-Chaines

Il y a une histoire de la monnaie qui se résume ainsi : au début des temps, les gens troquaient ce qu’ils avaient en trop. Tu as une pomme. Elle a une orange. Le commerce nécessite un moyen d’échange. La monnaie émerge en réponse à ce besoin.

Nous avons tous entendu cette histoire. Sauf que c’est un mythe. Elle ne s’est jamais produite dans la réalité.

La Mésopotamie ancienne a connu des réseaux bancaires sophistiqués bien avant que la monnaie n’existe. Ces réseaux permettaient toutes les opérations offertes par les banques modernes, telles que les prêts, les dépôts, l’échange de devises et le réglement des dettes. Babylone, le berceau de la civilisation humaine, était la florissante capitale financière de la région et un marché actif de contrats à terme. L’argent a émergé de ce système de réseaux de crédit. Bordereaux de dépôt et contrats à terme étaient échangés sous la forme de jetons d’argile qui pouvaient être brisés. Ce n’est que plus tard, lors de l’émergence de l’empire Perse, que le système monétaire bimétallique à base d’or et d’argent est apparu.

La leçon de l’Histoire est la suivante : les réseaux économiques viennent en premier. C’est le transfert de valeur au sein de réseaux qui donnent à la monnaie une signification qu’elle ne possède pas intrinsèquement. La monnaie hérite de propriétés issues des réseaux financiers dans lesquels elle est utilisée.

En 2010, le concept de monnaie saine était au coeur de la création du Bitcoin. Le monde crypto s’est ensuite développé en produisant de nouvelles classes d’actifs. Nous avons vu d’abord de nouvelles blockchains comportant des fonctionnalités uniques, comme Monero. Ethereum fut la première à offrir une architecture de généralisation des traitements, suivie par la multiplication des ERC20 (standard de tokens que chacun peut créer sur Ethereum) et l’explosion des ICO (Initial Coin Offering, mise en vente initiale de tokens). Mais la nature du monde crypto a fondamentalement changé. La DeFi nous invite à penser dans une perspective d’écosystème, à considérer des réseaux d’échange de valeur plutôt que des tokens isolés.

Nous étions habitués à appréhender les crypto-monnaies et leurs blockchains de façon indépendante. Ceci est Bitcoin, ceci est Monero, ceci est Ethereum. Nous raisonnions à partir d’entités atomiques et autonomes. La DeFi rend possible un autre mode de raisonnement, basé sur les écosystèmes, les réseaux, les flux de liquidité.

Avec la DeFi, nous voyons surgir un système financier parallèle sophistiqué. Les tokens natifs de blockchains perdent de leur prééminence au profit d’instruments et de réseaux. L’ingénierie financière permet d’interconnecter ces réseaux, d’amortir la volatilité des cours et de transférer efficacement les actifs. Il s’agit d’un environnement quasi-bancaire dédié au monde crypto, qui y gagne un avantage radical : les fonctions financières sont plus puissantes et plus fondamentales que la seule monnaie.

Plus de 1% de tous les bitcoins émis à ce jour sont aujourd’hui sur Ethereum et ce nombre grandit rapidement. Nous nous attendons à ce que cette tendance se poursuive.

Divulgation nulle de connaissance

La crypto-anarchie consiste à utiliser la cryptographie pour créer des espaces de liberté résistant à la force coercitive exercée par les monopoles du pouvoir et du capital.

Un tel espace de liberté est la semence d’une nouvelle société démocratique. Ces structures sociales sont résistantes par construction au contrôle d’état et au pouvoir totalitaire. Elles contrent l’atomisation sociale et promeuvent des relations librement établies entre ceux qui chérissent la liberté.

Ce sont des espaces dissimulés, utilisés par une alliance de forces démocratiques.

Le Zero-knowledge (ZK, en français “divulgation nulle de connaissance”) est une science aux applications puissantes, susceptible d’ouvrir de vastes espaces de liberté.

ZK nous permet de créer des smart contracts (programmes exécutés sur une blockchain) anonymes. N’importe qui peut écrire un programme anonyme fournissant une “preuve”. Même si la donnée utilisée est chiffrée, la preuve fournit une déclaration à propos de cette donnée, déclaration qui ne peut être falsifiée.

Ceci crée un nouveau champ des possibles pour les applications anonymes. La technologie est mature, disponible pour être utilisée et appliquée.

On pourrait penser que l’utilisation de ZK dégrade les performances, mais ce n’est pas le cas. Il est plus rapide de vérifier une preuve ZK que d’effectuer un calcul non-ZK pour obtenir le même résultat à partir des données non chiffrées. Et quelle que soit la taille des données en entrée, la preuve est toujours de taille constante.

Par exemple, il est possible de comprimer une blockchain toute entière dans une preuve ZK. Au lieu de télécharger 300 Go de données lors de la synchronisation initiale du réseau, il suffit de télécharger une preuve de 22 Ko confirmant que l’état actuel est cohérent avec la chaine des transactions depuis le début ! Il y a déjà des projets offrant cette possibilité. Cette propriété de ZK est appelée concision.

Voici un programme tout simple :
def foo(s, x, y): if s: return x * y else: return x + y

Posons qu’Alice calcule z = foo(True, 4, 110). Pour prouver que z est calculé de façon correcte, Alice donne à Bob les valeurs de z, s, x, y, puis Bob exécute la fonction pour vérifier qu’il obtient le même résultat qu’Alice. Ce n’est pas anonyme, puisque Bob peut voir les valeurs en entrée de la fonction. A la place, Alice peut utiliser une preuve ZK qui montre que la fonction a été correctement calculée, sans révéler les valeurs en entrée.

En utilisant cette technique, nous pouvons mettre en place des marchés financiers complètement furtifs : un réseau économique décentralisé et mondial, opérant de façon totalement anonyme.

ZK ouvre des possibilités inédites aux développeurs. C’est aussi une architecture computationnelle différent du modèle Von Neumann qui nous est familier. Certaines opérations sont plus adaptées, d’autres plus compliquées à réaliser. Il y a encore beaucoup à faire pour améliorer l’outillage autour des ZK, comme les compilateurs qui sont encore très primitifs.

Mais il s’agit du premier pas vers un nouveau modèle économique basé sur la technologie et non sur l’exploitation des utilisateurs.

DarkFi

DarkFi est une fondation technique multi-chaines pour les applications et les smart contracts anonymes.

Vous pouvez accéder au code ici :
github.com/darkrenaissance/darkfi

DarkFi est un environnement incluant un langage pour écrire des smart contracts à divulgation nulle de connaissance. La recherche en la matière en est à ses débuts, mais nous avons déjà un testnet (réseau de test) opérationnel.

ZK déverrouille un nouvel espace de conception d’applications anonymes. Auparavant, si vous vouliez créer une application anonyme, il fallait tenter de combiner plusieurs approches cryptographiques existantes. Le résultat pouvait s’avérer lent, ou même impraticable. Avec ZK, nous disposons d’une approche cryptographique générique que tout programmeur peut utiliser pour créer des applications anonymes.

Nous pouvons créer des services anonymes : les utilisateurs interagissent avec des DAO et des marchés en présentant des preuves cryptographiques de leurs qualifications, sans pour autant révéler leur identité.

Nous avons déjà un testnet connecté aux réseaux Bitcoin et Solana. Nous prévoyons d’y ajouter bientôt Ethereum et Monero. Vous pouvez l’utiliser pour exécuter une application et envoyer des paiements.

Notre priorité est de permettre des échanges anonymes de tokens et une DAO pour la gouvernance. Nous nous attellerons également à la mise en place d’outils collaboratifs et au développement de notre écosystème. Rejoignez-nous dans cette aventure de création d’un nouveau monde !

Nous recherchons des développeurs politiquement engagés et nous offrons des rémunérations compétitives. Nous créons un écosystème où de nombreux projets seront lancés et financés par DarkFi.

Un meeting pour les développeurs est organisé chaque lundi à 16:00 CET sur le channel #dev.

Nous sommes plus que des créateurs d’outils. Nous construisons des applications et soutenons les autres équipes qui développent les leurs sur DarkFi. Nous accueillons chacun dans ce voyage vers un monde nouveau.

Que l’obscurité nous dissimule

Sous le masque, il y a plus qu’un visage. Sous le masque, il y a une idée. Et les idées sont indestructibles.
— V

Chacun peut sentir qu’un événement économique ou politique majeur va survenir dans les années qui viennent. Chacun est profondément insatisfait de la domination exercée par les monopoles du pouvoir et du capital.

Quel est le prochain modèle qui devrait résoudre cette situation ? Voici la réponse :

Nous ne devrions pas penser en termes de modèle ou de système. Les êtres humains ne sont pas des objets au sein d’un modèle mathématique. C’est ce mode de pensée qui nous a mis dans cette situation en premier lieu.

De quel mode de pensée avons-nous besoin ?

Que se passe-t-il autour de nous ? Que font les gens ? Quels problèmes affrontent-ils ? Où est le vrai, le beau et le bien ? Comment stimuler les aspects de l’humanité et de la nature que nous voulons voir croître ?

Par chance, nous disposons d’une contre-économie agoriste, qui n’est pas une simple philosophie mais un puissant agent de changement. Exercez ce pouvoir, faites bouger les choses.

Les régulateurs sont déjà après nous. Ils nous voient comme des gamins avec des vêtements trop grands. Ils veulent nous remettre à notre place, nous réduire au silence, ou nous gronder parce que nous faisons trop de bruit. Qui sont ces gens et d’où viennent-ils ? Dans leurs cages dorées, ils n’auraient jamais pris le risque de parier sur Bitcoin en 2010. Pourtant, ils se considèrent socialement au sommet, et pensent qu’ils doivent s’assurer que les choses sont faites selon leur conception.

Le narratif crypto est aujourd’hui dominé par les préoccupations d’une classe privilégiée : GameFi, ArtFi, SocialMediaFi – le business des célébrités et des distractions.

Mais il suffit de noter ce que les monopoles du pouvoir et du capital cherchent à contrôler et interdire pour comprendre les facteurs clés de libération de la nation démocratique.

Ils s’apprêtent à réglementer ce qui fait l’essence de la crypto, comme l’envoi direct de crypto-actifs de personne à personne sur la planète. Ou comme la formation d’organisations auto-gouvernées. Tout ce qui menace les systèmes monopolistiques de capital et de pouvoir.

Le monde crypto se scindera en deux. La RegFi (Regulated Finance) sera inutilisable parce que verrouillée, sans possibilité de remettre en cause le statu quo. L’autre côté sera le DarkFi underground. Il aura des griffes et des dents.

DarkFi n’est pas un projet ni une startup. Nous sommes une communauté et un mouvement.

La contre-économie nous donne des outils pour édifier des communautés libres.

La crypto-anarchie est la tactique d’emploi de la cryptographie au bénéfice de la contre-économie.

Les technologies de protection des données personnelles s’imposent et sont désormais inarrêtables.

Combinez tout ceci et vous obtenez : DarkFi.

L’opacité s’étend sur le monde numérique. Elle ne peut être stoppée, ses avantages sont trop grands. Les potentialités latentes de l’humanité qui ont été réprimées pourront enfin s’exprimer. Nous détenons un grand pouvoir qui doit être utilisé avec respect.

Souvenez-vous que chaque révolution technologique dans l’histoire a fait face à des opposants rétrogrades, cherchant à faire rentrer le génie dans sa bouteille. Ils sont toujours trainés dans le futur contre leur gré, inexorablement.

Il ne s’agit pas ici de juger ou de condamner. Juste de reconnaître la réalité.

Qu’on le veuille ou non, le futur sera agoriste.

Que l’opacité s’installe.

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

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.

É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 !

• EthCC 
• Ethereum-France 
• EthCCWeek 
• EthCCweek 
• Discord

On se voit à Paris

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

• Twitter: https://twitter.com/Ethereum_France
• Discord: https://discord.com/invite/2cGc5JP4JC
• Meetup: https://www.meetup.com/fr-FR/ethereum-france
• Youtube: https://www.youtube.com/channel/UCf7zF8tFOb9T58nBo09BhAw

Le P2P Festival a lieu du 27 au 31 Avril à Ground Control à Paris.

Lors de la première édition du festival en 2019, de nombreux membres de la communauté Ethereum en France avaient assisté ou participé en présentant leurs projets.

Cette année, l’association Ethereum France est un partenaire actif du festival, puisque nous animons sa soirée d’ouverture, le 27 avril, sur le thème des technologies Zero Knowledge (preuves à divulgation nulle de connaissance).

Nous y accueillerons Starkware, Sismo et Consensys, à partir de 18h :

• Leo Sayous, CTO de Sismo, présentera Tornado Cash, en tant qu’exemple d’application d’utilisant le ZK à grande échelle.

• Olivier Bégassat de Consensys proposera une présentation de zk-EVM.

• Enfin, Henri Lieutaud de Starkware décrira l’état de l’art des ZK et des ZK rollups.

En complément, le One Arm Crypto Bandit Machine de Distributed Gallery sera exposée et vous proposera une approche sensible et ludique de la génération de clés privées sur Ethereum — et la possibilité très très très improbable de voler les actifs de quelqu’un via une collision de clés !

Jeudi 28, la soirée sera consacrée à Bitcoin, avec un talk d’Alexandre Vinot de WiseMining, une présentation sur la sécurité des données dont Bitcoin peut procurer, avec Gilles Cadignan de Woleet, et une discussion des questions énergétiques du Bitcoin et de leur verdissement, avec Pierre Noizat.

Vendredi 29, l’après-midi sera consacrée à IPFS avec le fondateur de Protocol Labs, Juan Benet, et les équipes de Berty. De nombreux workshops pratiques auront lieu en parallèle, sur des sujets très divers : les messages p2p sur Dogecoin, l’utilisation d’arbres de Merkle pour l’authentification des smart contracts, l’utilisation d’Aleph.im, du protocole P2P Fluence ou des solutions de déploiement de Starton.

En début de soirée, une série de talks abordera le thème de la décentralisation des organisations, avec Louis Giraux (Twoplus), Romain Figuereo (Paladin), Laszlo Szabo (Skillz), et Vladimir Oustinov (Jericho).

Le samedi 30 avril, le hackathon débutera et durera tout le weekend. Pour s’inscrire, c’est ici : https://www.p2p.paris/hackathon

En parallèle, un grand nombre de talks et de workshops seront offerts tout le weekend à Ground Control.

Citons notamment des talks sur libp2p, IPFS, Berty protocol, Gossipsub. Les talks du dimanche après-midi traiteront d’infrastructure décentralisée, avec notamment Zdeadex de Stake Lab sur Cosmos, d’identité décentralisée (FX Thoorens) et de l’histoire de l’humanité et des protocoles décentralisés (Adli Takkal Bataille), pour se conclure avec une perspective sur la cryptographie post-quantique, avec JP Aumasson.

Le P2P festival est gratuit et fait la place belle aux rencontres et échanges informels, encouragés par le cadre du tiers-lieu Ground Control.

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.

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

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

A bientôt!

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.

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.

En mars 2020, lors d’EthCC[3], la conférence annuelle au sujet d’Ethereum qui se tient chaque année à Paris, j’ai eu l’occasion de présenter “Un tour d’horizon des tokens non-fongibles (NFT)” au sein de la ‘French Track’ aux côtés de Nicolas Julia (Sorare), Nicolas Pouard (Ubisoft) et Pierre-Nicolas Hurstel (Arianee).

Depuis, les tokens non-fongibles connaissent un essor incroyable, porté par celui de la blockchain, et plus particulièrement par un intérêt grandissant des institutions, grandes entreprises, célébrités et médias qui ont largement repris le sujet (à l’image de mon passage dans l’Express — “Pourquoi ces jetons numériques s’arrachent à prix d’or?”)

La grande majorité de l’activité autour des NFTs se passant sur Ethereum, il apparaissait évident d’en faire une tribune avec Ethereum-France. Cet état des lieux a pour objectif de rappeler les tenants et aboutissants de ces objets numériques, préciser le contexte dans lequel leur essor s’inscrit, et proposer un aperçu de l’état actuel du marché, des applications le composant, un zoom sur le marché Français et quelques perspectives d’avenir.

Qu’est-ce qu’un Token Non-Fongible (NFT) ?

Un token est un actif numérique émis et échangeable sur une blockchain. Trop souvent appelées « crypto-monnaies », ils n’ont pas tous vocation à devenir une monnaie. Ce sont des actifs qui permettent la représentation et l’échange de valeur sur la blockchain.

Les tokens fongibles sont des tokens identiques entre eux et divisibles. Tout comme l’Euro ou le Dollar, un Bitcoin (BTC) ou un Ether (ETH) est fongible. Un BTC est égal à un autre BTC et il est possible de diviser, d’acheter et d’échanger des fractions de BTC (0.002 BTC).

A l’inverse, les spécificités principales des tokens non-fongibles (ou crypto-collectible, ou Non-Fungible Tokens aka NFT) sont qu’ils sont uniques et non individualisables. Un NFT est toujours différent d’un autre NFT, on ne peut également pas les diviser ni en échanger des fractions comme c’est le cas pour les tokens fongibles.

Principalement basés sur Ethereum, ces tokens non-fongibles héritent des spécificités de cette blockchain sous-jacente: une blockchain décentralisée, en accès libre, transparente et immuable. Les caractéristiques des blockchains publiques comme Ethereum s’appliquent aux tokens non-fongibles, ils sont par conséquent :

• Infalsifiables : tout comme chaque événement sur Ethereum ne peut être remis en question
• Traçables : chaque transaction est publique et visible par tous (eg. via etherscan)
• Interopérables: les NFTs se basent sur les mêmes standards, ce qui rend possible et facile l’interopérabilité de ces actifs entre les projets
• Monétisables : les standards de NFTs rendent facile leur incorporation dans des places de marchés qui permettent leur achat et vente. Un détenteur de NFT est réellement propriétaire de cet actif et donc libre d’en faire ce qu’il souhaite; le vendre notamment. La mise en place de royalties est également facilitée, entre autre grâce à leur traçabilité.

Spécificités des tokens non-fongibles :

• Unicité : Un NFT est unique. Il ne peut pas être copié à l’identique car la blockchain en garde une trace publique et immuable.
• Indivisibilité : Il est impossible de diviser un NFT en plusieurs parties, ce qui n’est pas le cas d’autres tokens. Cette deuxième propriété renforce la première.

La majorité des tokens non-fongibles fonctionnent via des smart-contracts (scripts automatisés) déployés sur la blockchain Ethereum. La plupart suit des standards bien établis tels que les ERC-721 & ERC-1155. 

Comment expliquer la fièvre des NFTs ?

Les NFTs font l’objet d’un engouement médiatique sans précédent, notamment lié à la participation de célébrités telles que Elon Musk, Jack Dorsey, Paris Hilton, Lindsay Lohan, Steve Aoki, Soulja Boy, Kings of Leon, Mike Shinoda, Pelé, Eminem, The Weekend qui vendent des morceaux de musique, des oeuvres d’art ou même des tweets historiques sous forme de NFT. Des entreprises telles que McDonald’s France ou Taco Bell ont également sauté le pas en mettant en vente des œuvres d’arts sous forme de NFT.

Mais c’est aussi et surtout grâce aux ventes records de NFTs que l’on parle d’eux. L’artiste Beeple notamment, a realisé une vente de $69M début mars 2021 chez Christie’s ce qui a suscité de vives réactions dans la presse. Traité ici par The Verge, Techcrunch ou encore le NYTimes et son titre provocateur “JPG File Sells for $69 Million, as ‘NFT Mania’ Gathers Pace”. La vente de Beeple est historique car c’est la 3ème plus grosse vente jamais réalisée par un artiste de son vivant. Sotheby’s a d’ailleurs rapidement emboîté le pas à Christie’s en effectuant à son tour des ventes de NFTs de plusieurs dizaines de millions de dollars. Ce sont donc les deux plus grandes maisons d’enchères au monde qui ont misé gros sur ces NFTs.

Les volumes globaux des NFTs ont explosé et continuent leur ascension fulgurante. Ce sont dorénavant des centaines de millions de dollars qui s’échangent chaque mois sur les plateformes de ventes publiques de NFT, comme le montre ce graphique publié par Messari :

Si ces ventes explosent, ce sont grâce à leurs émetteurs (ie. célébrités, marques, artistes) qui réalisent et exploitent cette technologie pour vendre leur art mais aussi bien évidemment grâce aux acheteurs (fans, collectionneurs, crypto-millionnaires) qui dépensent des fortunes dans ces objets digitaux.

En somme, les NFTs permettent à des utilisateurs de posséder et collectionner des biens digitaux en les achetant directement auprès de leurs créateurs. Cela permet aux marques et personnalités d’interagir directement avec leur communauté, en diversifiant leurs sources de revenus et d’interactions. Posséder un NFT est un signe d’appartenance pour l’acheteur, qui peut montrer son bien et faire partie d’un club restreint et privilégié. Le vendeur peut quant à lui monétiser ses créations tout en ciblant avec précision sa communauté.

“Les NFTs permettent de monétiser des actifs nativement digitaux.”

Dans quel contexte cet essor s’inscrit-il ?

Cet essor s’inscrit dans un contexte bien plus large. La technologie sous-jacente de la blockchain et notamment Ethereum est en forte croissance de popularité depuis quelques années à travers l’adoption par de nombreuses institutions (régulateurs, banques), entreprises internationales (Paypal, Venmo, Visa ou même Tesla qui autorise l’achat de voitures en Bitcoin) et l’investissement massif d’entreprises tels que Microstrategy ou Square qui intègrent des cryptos à leur bilan comptable. La semaine dernière Coinbase a fait son entrée en bourse, propulsant une nouvelle fois la blockchain sous les projecteurs médiatiques. Le secteur de la blockchain gagne en attention et dans son sillon ses sous-jacents tels que Ethereum ou  les NFTs.

Depuis la vague de la “Decentralized Finance” (DeFi) sur Ethereum lors de l’été 2020, le marché crypto est en effervescence; les investisseurs particuliers et professionnels sont attentifs et à la recherche du « next big thing ». La vague de NFTs est arrivée à point nommé.

En plus de l’intérêt généré par la blockchain et la DeFi, les NFTs représentent un cas d’usage simple, concret et visuel, les rendant accessibles. L’arrivée des Cryptokitties en 2017 connut un succès tel que la blockchain Ethereum s’était trouvée congestionnée à cause d’ une sur-utilisation soudaine du réseau, mais le soufflet lié à ces chats tokenisés est retombé par faute d’utilité, d’interopérabilité et d’accessibilité. Aujourd’hui, chacun peut créer, vendre, échanger, collectionner et utiliser des NFTs de multiples manières. La technologie est arrivée à un stade de maturité propice à son expansion. De plus, les NFTs représentent un cas d’usage concret pour expliquer les tenants aboutissants (rareté digitale, traçabilité, horodatage, monétisation, interopérabilité) des caractéristiques des blockchains publiques comme Ethereum. Ils sont donc largement montrés comme exemple par les acteurs et médias blockchains.

L’écosystème des Tokens Non-Fongibles

Voici un bon article récapitulatif de l’écosystème NFT https://niftycryptonomad.com/nft-ecosystem-overview/, tiré d’une étude de The Block.

Ce mapping, loin d’être exhaustif, permet de repérer les catégories d’utilisation qui émergent dans l’écosystème NFT :

• Gaming studio : studios de jeux vidéos comme Ubisoft qui travaille sur le sujet des NFTs depuis quelques années avec notamment les Lapins Crétins en NFT et plus récemment l’annonce de OneShotLeague ; un jeu développé avec SoRare, célèbre startup Française dans le secteur du gaming, football et NFT.
  
• Domains : les noms de domaines sur Ethereum (aka “domains”) est l’un des cas d’usage le plus ancien des NFTs avec ENS qui permet à chacun d’acheter un nom de domaine en ‘.eth’ qui permet de rendre lisibles les adresses Ethereum normalement constituées d’une suite hexadécimal type: 0x3942394(…)
  
• Marketplaces : les places de marchés NFTs comme Opensea sont en vogue et à l’épicentre de la “révolution NFT” car elles rendent possible l’achat et vente de ces objets digitaux, dont la liquidité est une des caractéristiques primordiales. C’est via ces plateformes que se passent la majorité des ventes, et parfois même l’émission de NFTs, rendus simples grâce à certaines tel que Rarible (cf. tutoriel plus bas).
  
• VR : Les mondes virtuels construits sur la blockchain qui ont pour but ultime de construire le metaverse utilisent quasiment tous les NFTs, tels que CryptoVoxels (qui manque au mapping ci-dessus)
  
• DeFi x NFT : Applications qui mixent NFTs et Finance Décentralisée (DeFi). comme Charged Particles, qui permet d’intégrer aux NFTs des mécanismes de finance ou encore Cometh, un jeu stratégique qui a pour but de construire un écosystème DeFi autour d’un jeu centré autour des NFTs.
  
• DAO : Des DAOs (Decentralized Autonomous Organizations) se forment autour des NFTs dans le but de rassembler des artistes, d’investir ou encore de prendre des décisions collégiales sur des projets liés aux NFTs. Ce sont des outils de coordination communautaires qui se forment spécifiquement sur cette verticale.
  
• Collectibles : cas d’usage primaire des NFTs, exploitant parfaitement les caractéristiques principales de la technologie. Par exemple les  crypto-collectibles ou crypto-art qui sont des NFTs permettant la valorisation et possession réelle d’œuvres d’art purement digitales.

• Games : Beaucoup de jeux construits sur la blockchain utilisent cette technologie des NFTs. C’est un des cas d’usage les plus répandus, pour plusieurs raisons : Les joueurs sont sensibles aux nouvelles technologies et comme avec les collectibles, ils permettent aux joueurs de posséder des actifs du jeu qu’ils peuvent potentiellement monétiser et/ou utiliser dans d’autres jeux, ce qui rend les NFTs attrayant pour cette catégorie d’utilisateurs.

• Infrastructure : (détaillé dans la prochaine partie ie. layer 1 & layer 2)

Le mapping omet quelques autres catégories émergentes telles que: 

• Agencies : Agence de création avec comme spécialisation la création et commercialisation de NFTs, tel que 6 agency
• Media : médias spécialisés en blockchain
• Funds & Grants : Organismes de financement spécialisés autour des NFTs comme FlamingoDAO

Une bonne analyse de Messari classifie également les différents acteurs de l’écosystème NFT par “couche de technologie”:

• Layer 5 : Les aggrégateurs, regroupant de multiples services autour des NFTs.
• Layer 4 : Les couches financières adossées aux NFTs (p. ex.  Charged Particles) permettant de fractionner, prêter/emprunter etc. des NFTs. 
• Layer 3 : Les applications permettant d’émettre des NFTs
• Layer 2 : Les sidechains, favorisant la rapidité à la décentralisation 
• Layer 1 : Les blockchains généralistes (Ethereum) ou spécialisées (Flow)

Cette classification invite au débat car beaucoup de projets se situent à plusieurs niveaux (comme Opensea) et il manque une couche entre “Layer 3” et “Layer 4”: celle des applications. Une autre analyse de Messari place ces applications au sein des catégories ci-dessous :

Dans les applications ; comme Messari le rappelle, se trouvent un certain nombre de cas d’usages, tels que:
“+ Digital Trading Cards
+ Art 
+ Provenance Tracking 
+ Gaming items
+ Domain names 
+ Content 
+ Tokenized luxury goods
+ Financial Products
+ Event Tickets 
+ Tokenized Content”
et bien d’autres encore.

Écosystème Français des Tokens Non Fongibles

(Listing d’entreprises dont le(s) fondateur(s) ou dirigeant(s) est(sont) Français, parfois francophone (ie. MagNFT) évoluant dans le secteur des NFTs. Nous listons des projets suite à un appel public à projet et ne garantissons pas ni la qualité de ceux-ci ni l’exhaustivité du mapping. Vous souhaitez en faire partie? Remplissez ce formulaire: https://xjh0am5b6o1.typeform.com/to/CrTl0GqM)

Communautés

• Les Collectionneurs: Communauté Francophone d’artistes NFT
• Blockchain Gaming Alliance: Collectifs d’acteurs du blockchain gaming
• Obvious Art: Artistes NFT & AI pionniers sur SuperRare
• SnailsForce: Communautés de joueurs Cometh
• MoCA (Museum of Crypto Art): Musée d’NFT dans Cryptovoxels

Jeux

• Sorare: jeu de football avec cartes à collectionner
• Cometh: jeu stratégique spatial avec composantes DeFi
• The Sandbox: monde virtuel en Voxel avec créations des joueurs en NFT
• Ubisoft: développe des jeux avec NFTs comme LapinsCretins & OneShotLeague
• Etherplay: studio de jeu-vidéo blockchain NFT développant actuellement Conquest: jeu stratégique et diplomatique dans l’espace
• Atari: studio de jeu-vidéo impliqué dans les NFTs avec l’Atari Capsule &co.
• Cryptopick: marché de prédictions avec des NFTs à gagner
• Everdreamsoft: studio de jeu-vidéo derrière Spells of Genesis et CrystalSuite intégrant les NFTs
• B2Expand: Studio pionnier de jeux-vidéos blockchain et NFT Français, derrière LightTrailRush

Collection

• Legends of Cryptonia: Expérience sociale sous forme de jeu de rôle discord où les propriétaires de NFTs dirigent l’histoire
• SolidNFT: Service d’impression de NFT pour “passer du digital au physique”
• Poost: Des NFTs “poos”
• HASHink: Des autographes en NFT

Marketplace

• Ternoa: Marketplace de NFT (sur Polkadot)
• Sushiswag:  NFT à l’effigie de Sushiswap
• Auctionity: Maison d’enchères de NFT
• Ultra: Plateforme de gaming permettant l’intégration de NFTs via SDK

Defi x NFT 

• NFT20: Protocol de trading décentralisé de NFTs
• StakeDAO: Projet DeFi intégrant des NFTs à collectionner
• BlackPool: Fonds d’investissement NFT

Luxe & Fashion

• Arianee: NFT pour la traçabilité d’objets de luxe
• Aura: NFT pour la traçabilité d’objets de luxe
• Satoshi-studio: Produits haut de gamme soutenus par des NFTs
• Exclusible: Marketplace pour NFTs de grandes marques de luxe.

Médias

• nonfungible.com: aggrégateur NFT
• Tryshowtime: réseau social NFT
• MetaversalFR: version francophone de « Metaversal” par Bankless
• MagNFT: media NFT historique (anglophone)

Infrastructure

• Aleph: NFT backup
• Ownest: Technologie de suivi de supplychain via NFT

Artistes

• Pascal Boyart
• Arthur Simony
• Arke
• RFTKT
• Vangart
• Money Alotta
• Cryptomaniac
• Jwavi
• Hadrien
• Ziwek
• Xavier Magaldi
• (…) Voir la liste des https://lescollectionneurs.org/artiste/, qui ont également leur propre musée en 3D dans CryptoVoxels

Comment acheter des NFT

Nous en parlions à travers cet article. Acheter des NFTs peut s’effectuer de plusieurs manières :

• A travers des plateformes d’échange telles que OpenSea, Rarible, SuperRare qui permettent aux émetteurs de lister leurs NFTs et aux acheteurs de les revendre.

NB: Une propriété intéressante des NFTs est qu’ils permettent à leurs émetteurs de fixer, en partenariat avec ces places de marchés, des “royalties”, c’est-à-dire un pourcentage qui sera reversé aux émetteurs à chaque revente des NFTs sur le marché secondaire. Leur traçabilité facilite grandement cela.

• Directement auprès de leurs émetteurs, sur les plateformes des projets eux-mêmes (voir projets ci-dessus)

Comment émettre des NFT

Émettre et vendre des NFTs est accessible à tous !

Une manière simple d’y parvenir est de passer par des plateformes telles que Rarible qui ont démocratisé le processus de création d’NFTs. Il suffit de suivre les étapes suivantes :

1. Choisir son média :  (PNG, GIF, WEBP, MP4 or MP3 etc.)
2. Connecter/Créer un crypto-wallet Ethereum (-> Metamask) 
3. Y transférer de l’ETH afin de pouvoir effectuer des transactions (depuis n’importe quelle plateforme d’échange tel que Coinbase ou Kraken)
4. Se connecter à une plateforme telle que Opensea, Rarible etc.

5. Uploader son média via la section création, exemple avec Rarible: https://rarible.com/create 

Si vous êtes développeur(e), regardez ces ressources par OpenZeppelin, ce superbe article ou encore ce tutoriel Youtube qui expliquent comment “coder” un NFT.

Émettre un NFT a actuellement un coût important car il est nécessaire de payer des frais de gaz lors de l’utilisation du réseau Ethereum. Ce dernier étant actuellement en hyper-demande, les frais peuvent être très élevés.

Quelles sont les perspectives ?

Les NFTs sont-ils en train de vivre leurs 15 minutes de gloire ou sommes-nous specta(c)teurs d’une nouvelle aventure d’applications inédites offertes par la technologie de la blockchain? L’attrait pour les NFTs par des segments de population de plus en plus diversifiés et s’éloignant des archétypes classiques, nous laisse imaginer que l’engouement pour ces actifs numériques continuera de grandir. Comme d’habitude, les chiffres actuels sont probablement exagérés, tout comme l’hyper médiatisation est théâtrale , mais ces effets provoquant des bulles sont néanmoins symptomatiques d’une vague de fond que nous pensons persistante. 

La technologie des NFTs a pour vocation à évoluer et notamment à se spécialiser par sous catégories (art, jeux etc.) et cas d’usages. Inédite, elle fait beaucoup parler d’elle aujourd’hui, mais comme toute technologie, son implantation et sa pérennité seront assurées lorsque l’on en entendra plus parler. En effet, tels les protocoles internet aujourd’hui que tout le monde utilise sans en connaître l’existence (ie. TCP/IP), les NFTs se répandront comme technologie sous-jacente pour toutes formes de médias, de biens digitaux et physiques; que ce soit sous leur forme actuelle (ie. standards sur Ethereum) ou autre.

“Le concept d’unicité digitale est extrêmement puissant et persistera à travers les âges.”

Nous vivons une révolution de la « Creator economy », l’économie digitale créée autour de l’économie de l’attention et des réseaux sociaux, où la création de contenu est à la portée de tous. En effet, tout le monde crée du contenu, mais personne ne le possédait réellement jusqu’à aujourd’hui. Les créateurs sont à la merci des plateformes qui contrôlent leurs créations, revenus et fans.

Les NFTs offrent la possibilité aux créateurs de réduire voire supprimer les intermédiaires, multiplier et diversifier leurs sources de revenu ainsi qu’aux utilisateurs de réellement posséder du contenu digital. Les NFTs cristallisent un changement de paradigme dans la manière de créer, partager et monétiser nos actifs sur internet apporté par Ethereum.

Suivez  nous sur Twitter ⇒

https://twitter.com/Ethereum_France
https://twitter.com/NathanSexer

Venez à EthCC en Juillet ⇒ https://ethcc.io/

Fondateur / Core-team de projet(s) Ethereum? Remplissez ce formulaire: https://xjh0am5b6o1.typeform.com/to/CrTl0GqM 

Merci à Bettina Boon Falleur et Chloé Lautier pour la relecture.
Merci à Gauthier Zuppinger, Gundam-Z et aux Collectionneurs pour leurs apports.

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

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 fractionnaires¹ 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 quantitatif² (quantitative easing ou QE). Certains économistes estiment même que la MNBC pourrait conduire à un système de « monnaie pleine³ », 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

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 seigneuriage⁴ » (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

¹Le 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.

²L’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.

³La 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.

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

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 :

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 :

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 :

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.

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.

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.

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

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

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

Qu’est-ce que l’EIP 1559 ?

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

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

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

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

Pour citer un ancien article :

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

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

L’EIP 1559 présente ces avantages :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Actuellement, cela conduirait à la situation suivante :

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

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

Examinons maintenant la situation avec l’EIP 1559 :

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

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

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

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

Statu quo :

EIP 1559 :

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

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

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

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

Pourquoi les mineurs incluraient-ils des transactions ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Autres ressources

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

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

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

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 ?

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 !

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.

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

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.

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.

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 » !

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

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

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

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

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 !

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.

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.

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 .

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

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)

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.

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

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

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 !