EthereumReport c’est :

• Une newsletter hebdomadaire dédiée à Ethereum.
• Un recap’ de l’actualité de l’écosystème.
• Une explication illustrée.
• La découverte d’un média à creuser.

Tout ça en francais et dans votre boite mail chaque mardi !

---

Le récap d’EthereumReport

Bonjour à tous et bienvenus dans cette huitième édition d’EthereumReport.

La semaine passée, ce fut la version 1 d’Argent et 2 d’Uniswap qui ont fait beaucoup parlé d’eux, deux franches réussites. Nous les avions déjà évoqués plus en détails dans la précédente édition. En dehors des différentes évolutions des projets existant et leur développement soutenu, ce fut la création de plus de 1500 WTC qui semble marquer un intérêt croissant pour le développement d’une DeFi autour de Bitcoin, sur Ethereum.

Mais c’est une nouveauté dans le cadre des tokens non-fongible qui m’intéresse également. Cette proposition de nouveau standard permettrait de mettre en place des frais perpétuels, payés au créateur du token lors de chaque échange. Dans la pratique ça permettrait par exemple à des artistes de recevoir des payements à chaque vente de leurs œuvres numériques.

En parlant de NFT, je vous propose la lecture des explications de Besancia, qui décrit le processus de création d’un token non-fongible avec des solutions clés en main. Il vous suffira d’avoir une idée de votre NFT et de payer quelques frais afin de repartir avec votre propre token. Également, je vous invite à vous plonger dans la rediffusion du dernier Meetup DeFi France X Table Ronde du Cercle du Coin autour de Bitcoin, Ethereum et la DeFi.

---

La semaine passée de l’écosystème

Suivez Ethereum 2.0 :

• Les dernières mises à jours de différents clients de l’écosystème : Lighthouse, Lodestar et Prysmatic.
• L’interpréteur WASM Fizzy, programmé en C++ sort sa version 0.1.
• Dans la suite des explications autour des validateur ETH2.0, aujourd’hui les différentes types de clés.

Des nouvelles de l’écosystème :

• Fuel réalise une démonstration de son “optimistic rollup” afin de réduire les frais payés par Reddit, si la plateforme utilisait le réseau principal d’Ethereum.
• Loopring dépasse le million de trades effectués sur leur plateforme d’échange.

Questions de gouvernance et de DAO :

• Aragon attaqué par sa communauté pour avoir arrêter le support d’une bourse communautaire.
• MetaCartel devient un incubateur de DAO.
• Les DAO, une nouvelle forme d’institution sociales ?

Propositions de standards :

• ERC2665 : Une extension du standard des NFT, permettant de mettre en place un frais supplémentaire à chaque transactions, distribué au créateur originel.
• ERC2666 : Rend les coûts d’utilisation d’Ethereum plus transparents.

Vos Dapps favorites :

• Sortie de la V2 d’Uniswap, avec de nombreuses nouveautés à découvrir !
• Pariez sur Ethereum contre Bitcoin grâce au token synthétique ETHBTC d’UMA.
• Les frais de stabilisation de Maker passent à 0.75% pour l’USDC, 1% pour WBTC.
• Ce sont désormais plus de 5200BTC déployés sur Ethereum, grâce notamment aux 1500 WBTC émis le 21 mai.
• Diego Maradona débarque sur Ethereum.

Régulations et études

• Ce que l’écosystème a à apprendre de l’adoption difficile de Visa.
• “Blockchain Code as Antitrust” de Thibault Schrepel et Vitalik Buterin.
• Le staking d’Ethereum 2.0 permettra à l’éther de devenir une réserve de valeur.
• Les jumeaux Winklevosses annoncent qu’ils possèdent environ autant d’éthers que de bitcoins.

---

Mais aussi quelques autres surprises !

The post EthereumReport #8 first appeared on Ethereum France.

Qui construit Ethereum ? Pour répondre à cette question, cette série d’interviews présente les français qui y contribuent au sens large : développeurs du protocole, développeurs d’applications, graphistes, investisseurs, utilisateurs, membres actifs de la communauté…

Aujourd’hui nous rencontrons Sylvain Laurent, software engineer pour Codefi chez ConsenSys

Bonjour Sylvain, nous sommes ravis de t’avoir parmi nos français qui construisent Ethereum. Pour commencer peux-tu te présenter en quelques mots?

Bonjour, je m’appelle Sylvain, j’ai 30 ans. Je suis développeur. J’ai commencé à toucher à la programmation quand j’avais 6-7 ans. J’ai ensuite évolué dans plusieurs milieux allant de la sécurité à la diffusion de vidéos et plus récemment l’univers des blockchains et toutes les technologies associées.

Quelle est ton occupation principale ?

Je travaille pour ConsenSys. J’ai récemment rejoint un nouveau projet qui consiste à travailler sur une infrastructure pour Ethereum 2.0 et des outils associés. Le but est de faciliter l’usage d’Eth 2.0. Ce n’est pas encore sorti mais il faut commencer en amont. Il faudra qu’il y ait des services et des fonctionnalités dès son arrivée.

ETH 2.0 sera différent à utiliser ?

En effet, ce sera un peu différent, ce sera une nouvelle technologie avec de nouvelles applications qui s’y connectent. Il y a également un aspect financier, on a récemment sorti un calculateur pour ETH 2.0, qui permet de calculer la rentabilité de ce que l’on souhaite miser dans le système. C’est une matrice où l’on rentre une valeur et elle en sort le revenu.  

Tu crées donc des outils très larges sur l’efficience d’Ethereum 2.0? 

Moi, plus spécifiquement, ce sur quoi je travaille c’est l’infrastructure qui fait tourner les validateurs 24h sur 24. L’infrastructure comprend notamment la gestion des clés privées: mettre en place des mécanismes et trouver des moyens pour éviter qu’un développeur puisse accéder aux clés, mais qu’un outil y ait accès. Cela passe par tout un tas de stratégies, d’infrastructure, de logiciels créés.

La cible de ton infrastructure, ce sont les entreprises ?

On a vocation d’aider l’écosystème de façon générale. Ce qu’on cherche à faire c’est  d’aider l’écosystème à faciliter la transition. Cela englobe tous les acteurs potentiels du réseau car ils sont tous concernés par ces outils.
Durant les quelques jours à DevCon V, j’ai passé du temps à regarder les clients ETH 2.0 pour ensuite les utiliser pour capitaliser les ethers dans Ethereum 2.0. L’idée est de créer l’infrastructure la plus résiliente possible, autant que la blockchain peut l’être.

Pourquoi Ethereum, qu’est-ce qui t’y a mené  ?

Je fais partie de ces gens qui ont supprimé plusieurs fois leur wallet bitcoin. Je sais qu’a un moment j’avais plusieurs bitcoins à l’époque où l’on pouvait encore les miner avec des CPU. A l’école, en 2011, j’avais lancé une cinquantaine d’ordinateurs qui minaient. Je trouvais ça drôle, puis comme ça prenait beaucoup de place sur mon ordinateur, j’ai tout supprimé, wallet compris.
Quelques années plus tard, en 2014, une ancienne amie du collège-lycée m’a contactée pour rejoindre un altcoin qu’elle était en train de monter: Neucoin, une crypto-monnaie qui permettait le staking et dont la mission était de faire des micro-transactions. On a travaillé avec  des mathématiciens de Polytechnique et des core développeurs d’altcoins pour produire une blockchain basée sur du staking paramétré pour permettre des micro-transactions en s’inspirant de plusieurs autres altcoins tels que Peercoin et Blackcoin pour le moteur de staking… justement car des gens avaient trouvé des failles potentielles dans les algorithmes existants. On avait levé $4 millions en 3 jours, au même moment Ethereum faisait son ICO.
Malheureusement on a pas eu la traction suffisante et quelques problèmes d’attaque de bots. Des sites partenaires avaient dû enlever une partie des services qu’ils offraient avec cet altcoin car ils se faisaient attaquer par des bots. Les bots récupéraient de l’argent et revendaient la crypto-monnaie. On a vu la lente descente aux enfers du prix qui a chuté. Suite à ça j’ai fait un burnout, je n’ai plus touché un ordinateur pendant 3 mois. 
J’ai ensuite rencontré les membres de Blockchain Partner et j’ai commencé à faire du freelance pendant deux ans en travaillant beaucoup avec eux. Il y avait beaucoup de prototypage et d’audit, ainsi qu’un peu de consulting. Cette expérience m’a beaucoup plus, j’ai beaucoup aimé toucher à Ethereum…
Après une période un peu difficile il y a deux ans, j’ai voulu rejoindre une grosse boîte, j’ai cherché la plus grosse boite sur Ethereum et j’ai postulé pour ConsenSys Paris que j’ai rejoint il y a un an.

Tu as découvert ETH chez Blockchain Partner ?

Je connaissais déjà Ethereum, mais je n’avais pas encore réalisé de projet. Le premier projet professionnel basé sur Ethereum auquel j’ai participé concernait la revente de e-billets pour un grand groupe industriel français. J’ai eu l’occasion de travailler sur tous les aspects de A à Z; autant l’interfacage, le service qui tourne dans le cloud et les smart-contracts, les démonstrations clients et la documentation. Ce fut un gros rush de 2-3 semaines et il fallait, en plus, tout expliquer au client. Il voulait comprendre, c’était un prototype, une expérimentation.. C’était très intéressant. Cela m’a permis de me remettre à jour sur tout ce que j’avais fait précédemment, mais sur Ethereum.
Avant, j’avais commencé à regarder les codes de Bitcoin et voir les différents commits. J’observais comment le système évoluait. J’analysais les similarités et différences entre Ethereum et Bitcoin. C’est très intéressant de voir qu’Ethereum s’est beaucoup inspiré de Bitcoin tout en faisant quelque chose de différent. Mais Ethereum a repris la dette technique de Bitcoin, dette technique que ETH 2.0 essaye d’enlever.

Ethereum 2.0 est vraiment réécrit de zéro ?

Oui et non. Ethereum comme c’est un protocole, c’est le protocole que tu modifies. Quand on analyse le protocole existant d’Ethereum on se rend compte que certains algorithmes ne sont pas spécialement les plus efficients. Ici, on a la possibilité de relancer les dés, réfléchir et apprendre de notre expérience. Cela fait cinq ans que le système tourne.

Tu as donc une petite expérience d’implémenteur Ethereum 2.0 ?

Je dirais plutôt que j’ai une expérience de hackeur sur Ethereum 1.0. J’ai passé beaucoup de temps à lire le code d’Ethereum dans tous les sens. J’ai fait un commit, qui résolvait un crash.

Quel est ton rapport à la spéculation autour des crypto-monnaies ?

Je suis un crypto-hobo et je suis pas un hodler. J’ai 0.5 BTC en tout et pour tout. Par contre si vous voulez m’en envoyer, je les accepte.
J’ai fait quelques expérimentations. Quand je travaillais avec Neucoin, j’avais essayé de vivre pendant tout un mois uniquement avec des bitcoins (sauf loyer etc.). Je me suis nourri exclusivement en bitcoins en 2014. Pizza.fr acceptait les bitcoins (pizza, kebab, sushi). Cependant, il y avait souvent des boutiques qui n’étaient pas encore ouvertes mais pour lesquelles tu avais déjà payé. Quand je demandais un remboursement ils voulaient un IBAN mais je voulais me faire rembourser en bitcoins. Techniquement, une boutique me doit toujours 0.2 BTC. 
Une des raisons pour laquelle je ne suis pas intéressé à l’aspect financier de tout ça est que je ne crois pas que gagner de l’argent en capitalisant soit une bonne chose. En tant que développeur j’ai beaucoup de chance de pouvoir travailler facilement. Après je suis particulier, je ne travaille pas dans un objectif de gagner plus d’argent que nécessaire à ma vie quotidienne. Cela me divertit de mon objectif de faire mieux.

As-tu un exemple d’une application Ethereum utile à nous partager?

Oui. Déjà rien que le fait qu’il existe des stablecoins, c’est déjà un use case passionnant. A la Devcon, les volontaires ont utilisé Kickback. Mais cela peut être plus un frein dans des secteurs pas encore très crypto car Kickback ne fonctionne qu’avec des crypto-monnaies. 
Je parie plus sur une crise pour l’explosion des crypto-monnaies. C’est une crise du système actuel qui va faire en sorte que les usages vont changer. Quand ils vont perdre leur argent, ils vont chercher à faire quelque chose d’autre. L’écosystème sera prêt.

Tu es bénévole pour la conférence Devcon, quel est ton intérêt pour être bénévole lors d’une conférence ?

Tu peux arriver, connaître personne, pour ceux qui sont anxieux socialement, c’est bien lorsqu’il y a un cadre. Tu vas rencontrer plein de gens avec le volontariat. Correspondre avec d’autres humains. De facto, cela sera plus facile d’approcher les gens car tu rentres dans un rôle précis. C’est une bonne approche pour rentrer dans les conférences et événements.
Et aussi c’est fun, t’envoies de l’amour et de la joie aux gens. Personne ne s’est plaint.

The post Les français qui font Ethereum #9 : Sylvain Laurent de ConsenSys first appeared on Ethereum France.

EthereumReport c’est :

• Une newsletter hebdomadaire dédiée à Ethereum.
• Un recap’ de l’actualité de l’écosystème.
• Une explication illustrée.
• La découverte d’un média à creuser.

Tout ça en francais et dans votre boite mail chaque mardi !

---

Le récap d’EthereumReport

Bonjour à tous et bienvenus dans cette septième édition d’EthereumReport.

Une semaine chargée pour Ethereum, de très bonne nouvelles pour cet écosystème que nous apprécions. Si la réctification de Vitalik sur le déploiement d’Eth2.0 a fait beaucoup de bruits, ce sont les mises à jour d’Uniswap et d’Argent par exemple qui semblent bien plus pertinentes. Sans parler de Reddit qui a choisi Ethereum (enfin un de ses testnets pour le moment) pour ses tokens communautaires et le développement continuel d’Ethereum et d’Ethereum 2.0.

Découvrez également en fin de publication la prochaine édition des meetups de DeFi France. Au programme un mélange des genres puisque la thématique de la semaine est Bitcoin et DeFi. Quelles sont les différences entre le développement de produits financiers sur Ethereum et Bitcoin, y a-t’il une interopérabilité possible ? Découvrez les différents enjeux des deux chaines et les positions des acteurs des ces deux écosystèmes.

---

La semaine passée de l’écosystème

Coté Ethereum :

• Mise à jour de d’OpenEthereum, la suite développement de l’ancien client Parity par l’équipe de gnosis.
• Le rapport de la dernière réunion des développeur. Les sujets étaient principalement des discussions autour des EIP intégrés au prochain hard-fork de mise-à-jour.
• La création d’un token pour le gas, collatéralisé par des ethers.

Suivez Ethereum 2.0 :

• Dernière publication de “What’s new in eth2”.
• La proposition d’un flux des prix de certains actifs intégré à la beacon chain. Réponse de Vitalik Buterin.
• Des nouvelles du réseau de test Schlesi : Teku et Nimbus sont dans la place.

Des nouvelles de l’écosystème :

• Tornado.cash avance dans sa quête de l’immuabilité en réussissant sa ceremonie communautaire de vérification, avec plus 1100 participants.
• Les résultats du sondage sur le stacking réalisé par ConsensSy.
• Ethereum dans les plans de Visa, d’après certains brevets.
• Mjolnir, l’outil de déploiement de chaines Ethereum de Brave.
• Ce sont désormais plus de 2300 WBTC qui sont sur Ethereum, contre 900BTC sur Lightning-Network.
• De nouveaux contrats à termes pour Ethereum, gérés par ErisX.

Vos Dapps favorites :

• Reddit lance ses tokens communautaire pour r/forniteBR et r/cryptocurrency. Actuellement sur le réseau de test Rinkeby, Reddit souhaite les déployer au réseau Ethereum principal.
• Kyber atteind le milliard de dollars d’échanges réalisés.
• Clap de fin pour Sai, donc les tokens peuvent encore être échangés contre des ethers.

---

Mais aussi quelques autres surprises !

The post EthereumReport #7 first appeared on Ethereum France.

Qui construit Ethereum ? Pour répondre à cette question, cette série d’interviews présente les français qui y contribuent au sens large : développeurs du protocole, développeurs d’applications, graphistes, investisseurs, utilisateurs, membres actifs de la communauté…

Aujourd’hui nous rencontrons Mokhtar Bacha, fondateur et CEO de Shipl

Bonjour Mokhtar, merci de prendre un peu de temps pour Ethereum-France aujourd’hui. Pour commencer pourrais-tu te présenter en quelques mots?

Bonjour, je suis Mokhtar Bacha, CEO de Shipl. Shipl est une startup qui résout le problème d’UX des dApps.

Sacrée promesse que tu nous fais avec Shipl ! Comment traites-tu les difficultés liées à l’UX ?

Oui, clairement. Les difficultés liées à l’UX se divise en deux sous-problèmes : la gestion des clés privées et la gestion de l’Ether (gas, prix, coût et volatilité).
La gestion des clefs privée est aujourd’hui complexe. L’utilisateur doit installer un wallet tel que Metamask, une extension Chrome, et il est souvent difficile voir impossible pour lui de récupérer son wallet en cas de perte de la clef privée.
La gestion du gas est compliquée pour l’utilisateur moyen, car cela nécessite pour lui d’aller acheter de l’Ether sur une plateforme d’échange et de payer pour chaque interaction avec une dApp. C’est un peu comme si l’on demandait aux utilisateur de Netflix de payer et leur abonnement Netflix et les services d’AWS.
Concernant la gestion des clefs privées : on crée un smart contract wallet avec une des clés privées sauvegardées sur nos serveurs. L’utilisateur peut donc prendre contrôle des clés privées s’il le souhaite, et avoir un smart wallet complètement décentralisé.   

La gestion des clés privées, ce n’est pas simple, n’y a-t-il pas des problèmes de sécurité lié à la conservation des clés sur un même serveur ? Quelles sont les problématiques particulières à la conservation sur le plan technique ?

Chez Shipl, les clés privées sont stockées sur des HSM (Hardware Security Module) dans le cloud. Cela permet un bon niveau de sécurité. On ne voit jamais la clé privée, le contrôle est délégué au compte AWS. Il faut donc sécuriser le compte AWS, et c’est pour cela que nous avons des audits de sécurité pour s’assurer  que nous sommes conforment aux normes les plus exigeantes tel que SOC 2 Type 2 ou PCI/DSS. 
Concernant le débat autour de la centralisation des clefs privées, chez Shipl nous abordons ce problème d’un point de vue technologique de manière pragmatique et non idéologique, ce qui en fait un problème fondamentalement simple à résoudre. Pour un utilisateur moyen,  un wallet centralisé, ne pose pas de  problème. Surtout que nous permettons à nos utilisateurs de pouvoir utiliser leur wallet de façon décentralisée s’ils le souhaitent. 
Concernant la deuxième difficulté évoquée, à savoir la gestion de l’Ether, nous proposons un deuxième produit chez Shipl:  notre service de Meta Transactions. De manière générale, lorsqu’un utilisateur souhaite signer une transaction et l’exécuter, mais n’a pas d’Ether sur son compte, il est bloqué car il ne peut pas payer le coût du gas. Notre service de Meta Transactiosn lui permet  de signer la transaction mais l’exécution de celle-ci est déléguée à un smart-contract wallet qui représente l’utilisateur. Celui qui envoie la transaction sur le réseau n’est plus l’utilisateur mais un relais : Shipl. C’est donc Shipl qui paye les frais de gas à la place de l’utilisateur.

Quel est le rôle des relayeurs et quel est leur intérêt ?

Shipl est un SaaS : les créateurs de dApps créent un compte, puis créditent ce compte et obtiennent ainsi une balance de gas. Ils formalisent ensuite les règles d’attribution de cette balance. Par exemple, ils peuvent décider de payer un certain nombre de transactions de leurs utilisateurs et les bloquer ensuite. Ils intègrent ensuite le SDK Shipl dans leur dApp avec seulement  une ligne de code. 
A chaque fois qu’un utilisateur exécute une transaction, c’est Shipl qui paye les frais de transactions dès lors que la balance du compte est suffisante.
Nous travaillons également pour développer  un niveau d’abstraction encore plus élevé où l’utilisateur n’aura plus besoin d’Ethers pour interagir avec les dApps. Notre vision est de créer une expérience qui soit blockchain-less.
Nous prévoyons de lancer le produit dans le courant de l’été 2020.

Du coup, pourquoi as-tu choisi de rentrer dans l’écosystème Ethereum et décidé de construire Shipl sur Ethereum ?

En 2015, je travaillais sur le diagnostic du paludisme. A 15 ans c’est compliqué d’avoir accès à de larges échantillons de paludisme, du coup avec les informations que j’avais, je n’ai pas pu entrainer mes algorithmes de machine learning pour diagnostiquer le paludisme. Au même moment je me suis éduqué sur la blockchain, cela m’intéressait, et je me suis demandé si je pouvais utiliser la blockchain pour des applications de santé. J’ai donc développé une première dApp sur Ethereum pour gérer les données de santé entre hôpitaux. J’ai postulé à un concours organisé par le gouvernement de Dubaï sur la blockchain. J’ai donc été en 2017 à Dubaï, pour pitcher mon projet devant le gouvernement du pays. Les 3 premières personnes du bureau de ConsenSys à Dubaï étaient présentes lors de cet événement. Ils ont aimé mon travail et ont organisé un call avec Joseph Lubin. Joe m’a apprécié et m’a invité à New York.
Ma dernière année de lycée, je suis parti deux mois à New York, pour rejoindre ConsenSys et continuer à travailler sur la santé et Ethereum. Au final, j’ai été recruté comme plus jeune employé de ConsenSys, en tant que développeur,  a 17 ans.
En travaillant chez ConsenSys, j’ai compris que le problème d’UX touchait énormément de dApps sur le marché et c’est donc ainsi que j’ai commencé à travailler dessus. En juillet 2018, j’ai eu l’idée de faire un SDK de Meta Transactions as a service. En 2019 j’ai pu commencer à travailler sur Shipl à plein temps, grâce à un investissement en pre-seed de ConsenSys.

Pour toi c’était donc une évidence de rester sur Ethereum? Tu avais regardé d’autres blockchains?

Aujourd’hui Ethereum est la blockchain dominante sur le marché des dApps et encore plus pour la DeFi (finance décentralisée).
Malgré tout chez Shipl nous sommes blockchain agnostiques, il y a beaucoup de projets intéressants, je crois que le marché va beaucoup évoluer dans les années à venir.

Quel est ton rapport à la spéculation autour des crypto-monnaies ?

J’ai acheté du bitcoin il y a très longtemps, j’ai fais une petite plus value qui m’a permis de lancer ma première startup et d’acheter mon premier ordinateur. Je ne suis pas un investisseur, ni un spéculateur. Dans un monde idéal, j’aimerai un prix de l’Ether stable. 

Peux-tu nous parler d’une application Ethereum utile ?

Je suis un fan de DapperLabs et de ce qu’ils font dans l’industrie du jeu vidéo. Sinon j’aime beaucoup Dharma, l’UX est vraiment top.
Malgré tout je crois que c’est une mauvaise compréhension du marché que de croire que la croissance du marché dApp proviendra d’une “killer dApp”. Je pense que la croissance est déjà là et elle provient de l’agrégation de nombreux smart contacts et protocoles composés ensemble. Cette tendance a déjà commencé dans la DeFi où des primitives financières construites par différentes équipes indépendantes sont combinées ensemble pour créer des produits plus complexes et avancés (par example MakerDao + Compound = Dharma). La limite est vraiment l’imagination des développeurs ce qui me rend très optimiste quant au futur du marché.

Article de Griffin Ichiba Hotchkiss sur blog.ethereum.org, traduit par Jean Zundel

Cet article – toujours aussi technique – revient sur l’amélioration du réseau Ethereum actuel, celui qui tourne en production en attendant les bouleversements d’ETH 2.0. Le sommet de Paris a permis de mieux dégager les grandes lignes de la recherche, résumées ici dans une nouvelle version de ce fameux arbre des technologies.

Désolé pour le retard de cet article ; certaines distractions inévitables sont récemment venues perturber ma vie, tout comme la vôtre certainement. J’espère que vous faites du mieux que vous pouvez dans ces circonstances et je vous supplie de monter votre niveau d’empathie à 11 dans les mois qui viennent et d’aider autant que possible les gens à risque dans votre communauté. 

Cela dit, parlons de Stateless Ethereum et des changements dans l’arbre des technologies !

D’un point de vue graphique, l’arbre a été complètement retravaillé, mais si vous le comparez à l’original, vous remarquerez qu’une grande partie du contenu est identique. Dans un souci d’exhaustivité et pour éviter toute confusion, cet article passera en revue tous les sujets : vous pouvez aussi bien fermer cet onglet que vous venez d’ouvrir en arrière-plan. Sans plus attendre, je vous présente l’Arbre des Technologies Du Sans État mis à jour :

Chaque étape majeure en rose représente une catégorie définie à grosses mailles qui doit être « résolue » avant de passer aux suivantes. Elles sont volontairement un peu vagues, et ne représentent pas d’EIP ni de fonctionnalité homogène, bien que certaines d’entre elles puissent y correspondre.

Les petits éléments en violet représentent des dépendances plus spécifiques qui mèneront au « déblocage » des étapes. Elles sont requises dans le sens où elles doivent être pleinement comprises avant que l’étape puisse être considérée comme atteinte, mais elles n’ont pas besoin d’être implémentées ou acceptées. Par exemple, il est possible qu’après certaines recherches, nous découvrions que la merklisation du code ne réduise pas suffisamment la taille des signatures témoins (les witnesses) pour justifier le temps et les efforts nécessaires à leur implémentation ; nous le considérerions comme « fini », parce qu’il ne serait plus nécessaire de l’étudier.

Comme vous pouvez déjà le deviner, les cases en vert représentent les « quêtes parallèles » qui seraient théoriquement utiles pour Stateless Ethereum, mais qu’un chercheur peut ne pas considérer comme prioritaires. D’autres pourront être découvertes en chemin ; je les ajouterai au fur et à mesure.

Nous avons aussi des éléments en jaune qui tombent dans la catégorie des outils. Encore inexistants, ils nous aideront à valider des hypothèses et des implémentations de test, et, plus généralement, ils accélèreront les travaux. Idéalement, ces outils seront d’une qualité suffisante et seront assez correctement maintenus pour bénéficier à tout l’écosystème des développeurs, y compris hors du contexte de Stateless Ethereum.

Un autre protocole de synchronisation

La plus importante des leçons à retenir du sommet est que la synchronisation est la première étape majeure pour Stateless Ethereum. Plus précisément, nous devons trouver un moyen pour que les nouveaux nœuds récupèrent le trie d’état actuel sans se reposer sur la primitive réseau GetNodeData. Tant qu’une autre méthode n’a pas été trouvée (beam sync et fast sync en dépendent), les efforts pour arriver à Stateless Ethereum seront entravés voire contre-productifs. Il nous faut maintenant creuser un peu ce sujet pour expliquer en quoi il pose problème. Si vous n’êtes pas familier avec les bases de l’état dans Ethereum, je recommande de consulter mes précédents articles dans cettes série.

D’abord, démystifions ce jargon. Il n’existe pas vraiment de définition technique pour le terme « primitive réseau » dans ce contexte, sinon « la grammaire de base des communications réseau d’Ethereum ». Un client demande « Hola, quelles sont les données du nœud avec le hash 0xtoto ? Et un pair peut répondre « Hmm, c’est 0xlulu ». Dans la plupart des cas, la réponse contient des hashs supplémentaires de nœuds fils dans le trie, que l’on peut ensuite requêter de la même manière. Ce jeu de colin-maillard continue jusqu’à ce que le requérant soit satisfait, généralement après avoir demandé chacun des 400 millions de nœuds dans le trie d’état actuel.

Cette synchronisation peut quand même être rapide parce qu’un client est évidemment multi-tâches et peut demander à de nombreux autres nœuds complets des fragments différents de l’état en même temps. Mais il reste un problème plus fondamental dû à la façon dont fonctionne la primitive : ceux qui demandent l’état – les leechers – le font à leur convenance, et il ne peuvent obtenir ce dont ils ont besoin que de seeders, des nœuds avec un état complet. Cette relation asymétrique constitue la base du fonctionnement actuel et, jusqu’ici, tout va bien en raison de deux faits liés concernant le réseau. D’abord, il existe un nombre suffisant de nœuds complets qui présentent l’état aux requêtes. Ensuite, ceux qui demandent l’état finissent par devenir des nœuds complets, et la demande d’état se limite d’elle-même.

Nous voyons maintenant en quoi cela représente un problème pour un Ethereum sans état : dans ce dernier paradigme, les nœuds qui ne conservent pas les données de l’état vont demander continûment des données. S’il est plus facile de faire tourner un nœud sans état qu’un nœud complet (c’est le cas), nous pouvons nous attendre à ce que le nombre de ceux-là dépasse rapidement le nombre de ceux-ci, jusqu’à ce que le réseau soit finalement incapable de propager assez rapidement l’état. Aïe.

Nous n’avons pas le temps d’aller plus avant dans les détails. Je vous renvoie à la présentation de ce problème par Piper, et nous allons pouvoir passer aux solutions émergentes, qu’il s’agisse d’améliorer le protocole de synchronisation de l’état, d’atténuer le problème ou de le résoudre complètement. Voici les trois protocoles les plus prometteurs :

Ethereum Snapshot Protocol (SNAP). Nous en avons déjà parlé, mais je l’avais appelé state tiling, « mosaïque de l’état ». Il a été plus longuement décrit par Peter dans le repo devp2p. Snap sépare l’état en quelques parties de grande taille avec leurs preuves (de l’ordre de 10000 nœuds de trie) qui peuvent être réassemblées pour constituer un nœud complet, et en un court laps de temps obtenir une image presque valide de l’état en accolant une centaine de racines d’état similaires. Pour finir, le client complète cette image en repassant à getNodeData, ceci jusqu’à obtenir un état valide.

Fire Queen’s Sync. Pas de grand changement depuis ce qui en a été dit dans le premier article sur l’arbre des technologies, sinon pour le nom, qui est une combinaison de firehose (bouche d’incendie) et Red Queen’s. Ce sont des propositions très similaires de remplacement de getNodeData par un autre ensemble de primitives pour divers aspects de l’état.

Merry-go-round. Il s’agit d’une nouvelle idée exposée rapidement sur ethresear.ch et plus concrètement décrite dans les notes. Dans cette synchronisation en manège, tout l’état est passé dans un ordre prédéterminé, afin que tous les participants diffusent la même partie de l’état au même moment. Pour synchroniser tout l’état, il faut terminer une « révolution » complète sur le manège en ayant couvert toutes les parties de l’état. Ce concept possède quelques propriétés intéressantes. D’abord, il permet aux nouveaux nœuds de contribuer immédiatement à la propagation de l’état au lieu de ne devenir utiles au réseau qu’après une synchronisation complète. Ensuite, il inverse le modèle actuel de synchronisation gouvernée par la demande où ceux qui n’ont pas de données peuvent demander des parties de l’état à volonté. Ces nouveaux nœuds sauraient quelles parties de l’état seraient offertes à un moment donné et pourraient s’ajuster en conséquence.

La dernière méthode de synchronisation qui vaille la peine d’être mentionnée ici est beam sync, maintenant supportée par deux clients. Beam sync repose toujours sur getNodeData, mais il offre un point d’entrée idéal pour expérimenter et collecter des données pour les autres méthodes de synchronisation. Il faut noter qu’il reste de nombreuses inconnues concernant la synchronisation et qu’il est important de multiplier les approches différentes pour résoudre ce problème. Les prochains mois pourront ressembler à une sorte de hackathon, dont les idées seront prototypées et testées. Idéalement, les meilleurs aspects de chacun de ces protocoles pourront être assemblés dans un nouveau standard pour Stateless Ethereum.

Prototype de spécification de signature

Il existe une ébauche dans le repository des spécifications pour Stateless Ethereum qui décrit à un haut niveau la structure d’une signature témoin de bloc, et les sémantiques de création et de modification depuis le trie d’état. Le but de ce document est de définir sans ambiguïté les signatures afin que les programmeurs, quelque soit le langage utilisé, puissent écrire leur propre implémentation avec une bonne probabilité d’aboutir au même résultat qu’une autre écrite d’après les mêmes spécifications.

Comme je l’ai mentionné dans le dernier call digest, il ne semble pas qu’il y ait des inconvénients à écrire une implémentation de référence pour les signatures témoins de bloc et à l’incorporer dans les clients existant à fins de tests. Une fonctionnalité de prototype de signature serait une option externe à activer, et quelques testeurs sur le réseau produisant et relayant les signatures fourniraient des informations intéressantes que les chercheurs pourraient intégrer dans les améliorations ultérieures.

Deux problèmes doivent être « résolus » avant que les signatures soient assez résilientes pour être considérées prêtes pour une généralisation de leur usage.

Indexation des signatures. Celle-ci est relativement simple : nous avons besoin d’une manière fiable de déterminer si la signature correspond à un bloc donné et à son état associé. Cela pourrait être aussi simple qu’un champ witnessHash dans l’en-tête du bloc, ou bien quelque chose similaire mais d’une autre manière.

Validation de transactions sans état. C’est un problème intéressant apparu dès le départ et décrit exhaustivement sur les forums de etheresear.ch. En bref, les clients doivent rapidement vérifier si les transactions entrantes (qui attendent d’être minées) sont au moins éligibles pour être incluses dans un futur bloc. Cela empêche les attaquants de spammer le réseau par des transactions invalides. La vérification actuelle, cependant, demande d’accéder à des données faisant partie de l’état, à savoir le nonce et le solde du compte de l’expéditeur. Un client sans état ne pourra pas effectuer cette vérification.

Il y a certainement plus de pain sur la planche que ces deux problèmes spécifiques qui nous attendent avant que de pouvoir disposer d’un prototype fonctionnel de signatures, mais ces deux-là doivent absolument être résolus pour mettre à disposition un prototype viable de nœud beam sync près de chez vous.

EVM

Comme dans la version originelle de l’arbre des technologies, des changements seront nécessaires à l’intérieur de l’abstraction de l’EVM. Les signatures, en particulier, doivent être générées et propagées à travers le réseau, et cette activité doit être prise en compte dans les opérations de l’EVM. Les sujets liés à cette étape sont liés aux incitations et aux coûts induits, ainsi qu’à la façon de les estimer et de les implémenter avec un impact minimal sur les couches supérieures.

Prise en compte du gaz des signatures. Rien ne change par rapport aux articles précédents. Chaque transaction sera responsable d’une petite partie de la signature du bloc. La génération d’icelle implique des calculs effectués par le mineur du bloc et se verra donc associer un coût en gaz, payé par l’émetteur de la transaction.

Merklisation du code. L’une des principales composantes d’une signature est le code qui l’accompagne. Sans cela, une transaction contenant un appel à un contrat devrait contenir le code complet de celui-ci pour vérifier son codeHash, ce qui peut représenter beaucoup de données selon le contrat. La « merklisation » du code consiste à éclater le bytecode du contrat pour que seule la portion du code appelé soit requise pour générer et vérifier la signature témoin d’une transaction. Cette technique réduit drastiquement la taille moyenne des signatures témoins, mais n’a pas encore été étudiée à fond.

Les changements de UNGAS / Versionless Ethereum ont maintenant été retirés du « chemin critique » de Stateless Ethereum. Ces fonctionnalités restent potentiellement intéressantes mais il est devenu clair au cours du sommet que leurs mérites et leurs particularités peuvent et doivent être traités indépendamment des buts du sans-état.

La transition vers un trie binaire

Le passage à une structure de trie binaire de l’état est la clef pour obtenir des tailles de signatures assez petites pour être diffusées dans le réseau sans se heurter à des problèmes de bande passante ou de latence. On devrait théoriquement obtenir au moins une réduction d’un facteur 3, mais elle devrait être en pratique moins importante (à cause de la taille du code des contrats dans les signatures, d’où l’importance potentielle de la merklisation du code).

La transition vers une représentation des données complètement différente constitue un changement radical, et l’activation de cette transition par un hard fork sera un processus délicat. Deux stratégies soulignées dans l’article précédent restent inchangées :

Progressive. Le trie d’état sénaire serait transformé petit à petit sur une longue période de temps. Toute transaction, toute exécution de l’EVM touchant à une partie de l’état encoderait de ce fait les changements de l’état dans la nouvelle forme binaire. Cela implique l’adoption d’une structure de trie « hybride » laissant les parties dormantes de l’état dans leur représentation sénaire actuelle. Le processus resterait de fait toujours incomplet et complexifierait l’implémentation des clients, mais isolerait en grande partie les utilisateurs et les développeurs d’applications des changements opérés en couche 0.

En masse. Cette stratégie calculerait une nouvelle représentation binaire du trie de l’état à un moment prédéterminé, puis continuerait sous forme binaire une fois le nouvel état calculé. Bien que plus simple à mettre en œuvre, une action de masse demande la coordination de tous les opérateurs de nœuds, et elle impliquerait presque certainement une perturbation limitée du réseau en affectant les utilisateurs et les développeurs pendant la transition.

Il existe cependant une nouvelle proposition de transition qui offre un compromis entre ces deux stratégies. Elle est intégralement décrite sur les forums de ethresear.ch.

Overlay. Dans ce scénario de superposition, les nouvelles valeurs issues de transactions après un certain temps sont stockées directement dans un arbre binaire situé « au-dessus » du sénaire, alors que l’arbre sénaire « historique » est converti en tâche d’arrière-plan. Quand la couche de base aura été complètement convertie, les deux pourront être fusionnées.

Un facteur supplémentaire à prendre en compte pour la transition vers un trie binaire est l’organisation de la base de données des clients. Actuellement, tous les clients utilisent l’approche « naïve » pour le trie d’état, en stockant chaque nœud du trie sous forme de paire [clef, valeur] où le hash du nœud est la clef. Il est possible que la stratégie de transition puisse offrir aux clients l’opportunité de basculer vers une autre structure de base de données, suivant en cela l’exemple de turbo-geth.

Un vrai Ethereum sans état

Les dernières parties de l’arbre s’assembleront après avoir testé et amélioré le prototype de signature témoin, effectué les changements nécessaires sur l’EVM et passé le trie d’état en binaire. Ces quêtes plus lointaines et ces quêtes parallèles doivent être réalisées à la fin, mais il vaut mieux ne pas trop y penser avant que des sujets plus pressants aient été terminés.

Signatures obligatoires. Les signatures témoins doivent être générées par les mineurs, et on ne sait pas si ceux-ci vont chercher à éviter les quelques millisecondes de génération de la signature. Cela peut être en partie compensé en ajustant les frais que les mineurs touchent des signatures partielles incluses avec les transactions, mais le moyen le plus sûr est de l’intégrer au protocole d’Ethereum. Ce changement ne peut se produire qu’après nous être assurés que tout fonctionne comme prévu, et il se retrouve donc à la fin de l’arbre.

Découpage des signatures. Autre fonctionnalité à envisager, la possibilité pour un réseau sans état de diffuser des morceaux de signatures au lieu de blocs entiers. Cela bénéficierait surtout aux nœuds à état partiel, qui pourraient choisir de conserver les parties de l’état qui les intéressent en premier lieu puis de récupérer d’autres parties pour d’autres transactions.

Accumulateurs historiques. Conçus à l’origine comme un système mathématique vaudou à divulgation nulle de connaissance, un accumulateur historique faciliterait grandement la vérification d’une signature historique. Cela permettrait à un nœud sans état d’effectuer des requêtes et des vérifications sur, par exemple, le solde historique d’un compte qui l’intéresse, sans avoir besoin de récupérer une partie spécifique d’état archivé.

Données de chaîne sur DHT. Bien que l’idée d’un réseau de distribution de données d’état par table de hachage ait été plus ou moins abandonné, il resterait utile et plus facile à implémenter pour les données de chaîne historiques comme les reçus de transactions. Cela pourrait fournir une autre approche pour permettre aux clients sans état d’accéder à volonté aux anciennes données qui seraient normalement obtenues depuis un nœud archive.

Restez chez vous, restez en ligne

Merci d’avoir lu, et merci pour tous les commentaires positifs que j’ai récemment reçu sur ces mises à jour. J’ai quelque chose de plus… magique en prévision pour les articles suivants sur la recherche concernant Stateless Ethereum, que je posterai occasionnellement sur le forum Fellowship of the Ethereum Magicians, ainsi que sur ce blog quand je le jugerai utile. En attendant, restez à distance et lavez-vous souvent les mains !

Comme toujours, si vous avez des retours, des questions ou des requêtes de nouveaux sujets, vous pouvez joindre @gichiba ou @JHancock sur Twitter.

EthereumReport c’est :

• Une newsletter hebdomadaire dédiée à Ethereum.
• Un recap’ de l’actualité de l’écosystème.
• Une explication illustrée.
• La découverte d’un média à creuser.

Tout ça en français et dans votre boite mail chaque mardi !

---

Le récap d’EthereumReport

Bonjour à tous et bienvenus dans cette sixième édition d’Ethereum Report.

Vous êtes toujours plus à nous rejoindre dans ce que j’espère deviendra un rendez-vous hebdomadaire. N’hésitez pas à partager autour de vous cette newsletter si elle vous plait, c’est notre seul moyen de toucher plus de personnes aujourd’hui !

Cette semaine fut relativement calme pour l’écosystème, qui a tout de même été animé par les débats relatifs aux “humans ICO”. Nous pouvons citer le cas du français Alex Masmej qui a décidé de lever 20.000 euros pour financer son projet de vie, entreprendre à San Francisco. Ce sont donc des tokens à son nom qui proposa en échange des fonds, qui donneront droit à des rentes tirés des revenus futurs de l’intéressé. Une pratique qui soulève de nombreuses questions si elle venait à être démocratisée, reposant principalement sur la confiance (on y reviens souvent :D) accordé à l’initiateur.

---

La semaine passée de l’écosystème

Coté Ethereum :

• Le guide complet pour installer un nœud ETH1 (ou 2 en testnet) sur un Rasberry Pi 4. 👨‍💻
• Découvrez les nœuds Hyperledger Besu pour le réseau Ethereum principal. ⛓

Suivez Ethereum 2.0 :

• L’“eth2 quick update” épisode 11 est disponible. 📰
• Le client Teku de l’équipe de PegaSys a réussit à se synchroniser sur le réseau de test Schlesi. 🙌
• Une explication claire de la politique d’émission des ethers dans le temps (PoW et PoS). 💸
• Quel est le materiel necessaire pour faire du staking d’éthers ? 🕵🏻‍♂️

Des nouvelles de l’écosystème :

• La suite Besu d »Hyperledger est désormais disponible sur la place de marché du cloud Azure. 👨‍💻

Questions de gouvernance et de DAO :

• Un guide de démarrage pour lancer votre propre DAO en utilisant les outils de MolochDAO. 📃
• De nouvelle options pour la délégations des pouvoirs de vote au sein de KyberDAO. 🗣
• EIP2633: formaliser l’évolution de la gouvernance d’Ethereum. ⛓
• EIP2628: Modifier les header des StatusMessages pour mieux résister aux attaques Sybils. 📃

Vos Dapps favorites :

• 75 façons d’utiliser les monnaies sociales. 💰
• Que penser de la tokenisation des individus ? 🤷‍♂️
• Découvrez Strike. 🔥
• OpenRaise, lever des fonds de manière distribué. 💸
• Coup dur pour RealT qui a été bloqué par Paypal. Le projet utilise désormais Wyre. 😅

---

Mais aussi quelques autres surprises !

EthereumReport c’est : 

• Une newsletter hebdomadaire dédiée à Ethereum.
• Un recap’ de l’actualité de l’écosystème.
• Une explication illustrée.
• La découverte d’un média à creuser.

Tout ça en français et dans votre boite mail chaque mardi !

---

Le récap d’EthereumReport

Bonjour à tous et bienvenus dans cette cinquième édition d’EthereumReport.

Cette semaine dans les grandes lignes c’est les ajouts de WBTC et de l’USDT sur les protocoles respectifs Maker et Compound. C’est également la création d’un fond d’investissement de 512 millions de dollars dédié à l’écosystème des cryptomonnaies. Mais c’est également le développement en vitesse de croisière de nombreux projets, la présentations de nouveaux potentiels ERC qui souhaitent faire évoluer Ethereum.

Enfin je vous propose d’aller plus loin dans votre suivi/compréhension de la finance décentralisée d’Ethereum, en français. C’est donc un article sur l’ajout du wrapped-BTC dans le fonctionnement de la stabilité du Dai ainsi qu’une explication en vidéo qui vous attend en fin de publication.

---

La semaine passée de l’écosystème

Coté Ethereum :

• Suivez la dernière réunion des développeurs. Au programme les EIPs liés aux courbes elliptiques et des sous-routines de l’EVM. Clap de fin pour ProgPow qui n’a pas atteins de franc consensus. 📃
• Analyse de l’EIP2315, les sous-routines de l’EVM. 🕵🏻‍♂️
• Compte-rendu de la réunion sur les changements de la gestion des frais de transaction. 📃
• Foire au questions de Vitalik sur les changements du fonctionnement des frais de transactions (EIP1559). 🤔

Des nouvelles de l’écosystème :

• Pensez à renouveler vos noms de domaines ENS. ✌️
• ZapperFi : la fusion de DeFiZap et DeFiSnap. 👥
• Les plans de DForce et de LendFMe pour leurs utilisateurs. 💸
• Un début de proposition pour un token liés aux frais de transactions. 💰
• OpenBazaar accepte désormais l’ETH. 🙌

Questions de gouvernance et de DAO :

• Ajout du Wrapped-BTC à Maker. 📰
• L’USDT est désormais disponible sur Compound. 💰
• MetaClan : une DAO le développement de l’Esport. 👨‍💻

Propositions de standards :

• Phase finale pour l’ERC1363. ⛓
• Phase finale pour l’ERC1193. ⛓
• ERC2611: Ethereum pour les applications de tracing en marge du Covid-19. 🕵🏻‍♂️
• ERC2612: Ajout d’une fonction permit. 👨‍💻
• ERC2357: Remplacement de la difficulté actuelle par la difficulté totale dans les headers des blocs. ⛓

Vos Dapps favorites :

• UMA a réalisé une Uniswap Initial Offering. Les prix ont flambés, jusqu’à x5/x10 pour certains investisseurs. 🔥
• Présentation d’Everest, un regroupement de projets Ethereum pour leurs apporter plus de visibilités. 👥
• A16z leve 515 millions de dollars pour un fond d’investissement crypto. 💸
• Une étude des 10.000 adresse Ethereum les plus fournies. 📃

---

Mais aussi quelques autres surprises !

Article de Griffin Ichiba Hotchkiss sur blog.ethereum.org, traduit par Jean Zundel

La série sur Stateless Ethereum se poursuit. Cette évolution de la chaîne actuellement en production permettra aussi bien à des clients complets qu’à des clients sans état ou n’en conservant qu’une partie de rejoindre le réseau en toute sécurité. Il s’agit également de préparer la transition vers Eth2.0, l’évolution radicale vers le PoS et le sharding. Pour rappel, le sommet s’est tenu dans le cadre du Unhackathon à l’ESGI juste après EthCC.

Il serait illusoire de prétendre à un résumé objectif et représentatif juste après cette semaine à Paris ; comme tous ceux qui y étaient présents, je vais passer les prochaines semaines à en extraire la substantifique moelle et à en tirer les leçons pour l’année à venir.

Mais pour toi, cher lecteur, qui a ressenti le FOMO de Paris et qui en a attendu avec impatience des nouvelles, je vais livrer en un simple survol ma collection personnelle et incomplète d’idées, de décisions et de résultats du premier Stateless Ethereum Summit.

À quoi cela ressemblait-il ?

Le sommet a duré deux jours, avec une première réunion d’un grand groupe, structurée au minimum, pour discuter de sujets vastes ou importants, puis un éclatement en deux ou trois discussions simultanées. Avec une trentaine de participants en tout, la taille des groupes était quasiment parfaite pour permettre aussi bien des études de fond que des séances informelles de questions-réponses. Bien entendu, c’était aussi l’occasion de mettre des visages sur les noms d’utilisateurs, et de se connecter au groupe de manière plus humaine.

Je pense que, pour la plupart des participants (moi compris), le premier résultat du sommet a été un « nivellement par le haut » de notre compréhension des problèmes à résoudre et des solutions proposées. Les quelques personnes à l’origine de cette initiative (Piper, Alexey et leurs équipes) y ont trouvé l’occasion de passer un peu de temps au tableau blanc pour rattraper et poser toutes les petites questions que nous n”osions pas poser dans un forum.

Je souligne ce fait car l’un des buts principaux de ce rassemblement était de présenter plus clairement les opportunités et les défis des tâches en attente. Plus ces tâches peuvent être clairement exposées aux intéressés, plus il est facile de se joindre à ces efforts pour contribuer. Je dirais qu’à cet égard le sommet est déjà une réussite éclatante, et nous avons « accroché » des gens qui restaient sur le banc de touche jusqu’à présent.

De quoi a-t-on parlé ?

D’un peu de tout, en fait. Avec une seule paire d’oreilles à ma disposition, j’ai pu écouter des discussions sur la plupart des sujets de l’arbre des technologies dans leur contexte, et comme je l’ai indiqué dans la section précédente, il s’agissait surtout de se réunir pour s’accorder sur une vision simple et commune d’un Ethereum sans état. Quel est le principal problème à résoudre ? Quelle est la première étape que l’on peut raisonnablement atteindre ? Est-il bien la peine d’étudier un système de divulgation nulle de connaissance pour les signatures témoins historiques ?

Voici ce que je crois avoir été les sujets principaux :

• Primitives de synchronisation ;
• Transition vers un trie binaire ;
• EVM ;
• Délivrance de données dans un paradigme sans état ;
• Ébauche de spécification de signature témoin.

Alexey a très justement proposé que le but de ce sommet soit de s’occuper de tout ce qui ne pouvait être accompli sur l’internet, et de réserver ce qui peut être fait en ligne pour le travail à distance. Les désaccords se règlent bien plus facilement en personne qu’en ligne, et les décisions sur des problèmes complexes sont prises plus rapidement. Donc, en plus de la récapitulation générale et du partage de connaissances sur les principaux sujets, nous avons employé notre temps à exposer les arguments pour ou contre des décisions nécessaires, comme ce sur quoi travailler en premier, ou les outils indispensables pour que les travaux puissent même commencer. Le plus important a été que ce sommet a été l’occasion de préciser et de mieux définir l’étendue de ces travaux, et de percevoir tous ensemble ce qui définirait leur réussite, et de quels points de vue.

Qu’a-t-on décidé ? Quoi de neuf ?

Encore une fois, et je ne peux assez le souligner, il ne s’agit que de mes réactions personnelles à la manière dont s’est passé le sommet. Je n’ai même pas consulté mes notes ni mes enregistrements. Mais voici les points principaux que j’ai retenus, dans le désordre, des nouvelles perspectives issues de la discussion du week-end qui alimenteront les réflexions futures.

• La synchronisation, et plus spécifiquement la primitive getNodeData, est ce qui doit avant tout changer pour avancer dans cette quête du sans-état. Cela doit être amélioré avant que la transition vers le trie binaire puisse avoir lieu, et cela demandera une coordination entre toutes les équipes des clients. Felix de l’équipe Geth a mené une discussion très productive sur la synchronisation et il est devenu clair que la plupart des propositions sont en train de converger depuis des points de départ différents. L’amélioration de la synchronisation permettra également une transition moins brutale vers le trie binaire.
• Alors qu’à l’origine on pensait que la stratégie la plus raisonnable vers un trie binaire demanderait un arrêt momentané de la chaîne et le recalcul d’un nouvel état binaire, l’opinion actuelle est que la transition peut être accomplie sans interruption du réseau avec une coordination suffisante des clients.
• Plusieurs éléments nouveaux ont fait plus ou moins écarter les plans et les idées autour de la création d’un réseau complet de délivrance des données pour l’état. D’abord, de nouveaux venus avec une expertise plus poussée ont expliqué à quel point il serait difficile de le mettre en œuvre. Ensuite, un tel réseau peut être construit de manière incrémentale, et une version beaucoup plus simple (qui ne servirait que des en-têtes, des transactions et des reçus, par exemple) fournirait une plus-value immédiate et pourrait être améliorée ultérieurement.
• Les changements de l’EVM sont les plus complexes, et il n’y a eu ni décision ni résolution claire concernant leur nature pour sa compatibilité avec le sans-état. Il faut comprendre que la plupart des propositions actuellement étudiées en font plus que ce qui est strictement nécessaire pour le sans-état, et il faut donc évaluer la valeur, la complexité et les efforts nécessaires pour réaliser ces améliorations additionnelles. Il faut aussi noter que certaines opérations sur le gaz devraient devenir plus coûteuses de toute manière, mais rien n’a été réellement décidé au sujet de l’EVM, et nous ne pourrons pas connaître la direction à prendre avant de disposer de plus de données.
• NOUS DEVONS CONSTRUIRE DES PYLÔNES SUPPLÉMENTAIRES – Comme dans Starcraft, une partie des travaux sert à rendre l’ensemble plus productif et profitable. Ces méta-travaux entrent dans deux catégories : les outils facilitant la collecte et l’analyse de données ; les ressources aidant les autres à contribuer plus efficacement, comme la documentation sur le sans-état pour les nouveaux chercheurs rejoignant les équipes. Cela dit, je crois qu’il reste des désaccords substantiels sur la part de travail à consacrer à court terme à la construction d’outils, et sur les outils dont on a le plus besoin. Les semaines prochaines, nous allons réviser l’arbre des technologies et l’embellir pour qu’il soit plus représentatif du projet que Stateless Ethereum est devenu. Il s’agira d’aider la communauté à conserver la trace de tout ce qui se passe et d’aider les nouveaux venus à contribuer plus efficacement.

Comme toujours, si vous avez des questions, des requêtes de nouveaux sujets, ou si vous voulez participer à la recherche sur Stateless Ethereum, venez vous présenter sur ethresear.ch et/ou joignez @gichiba ou @JHancock sur Twitter.

EthereumReport c’est : 

• Une newsletter hebdomadaire dédiée à Ethereum.
• Un recap’ de l’actualité de l’écosystème.
• Une explication illustrée.
• La découverte d’un média à creuser.

Tout ça en francais et dans votre boite mail chaque mardi !

---

Bonjour à tous et bienvenus dans cette présentation de la quatrième edition d’EthereumReport, qui est vous l’aurez compris une newsletter dédiée à Ethereum et à son écosystème. Merci beaucoup à toute l’équipe derrière Ethereum France pour me permettre de publier ici.

Le récap d’EthereumReport

Une semaine un peu plus chargée, avec de très bonnes nouvelles qui nous attendent. Au programme donc nous aurons les dernières données sur les testnets qui s’annoncent très encourageantes pour la suite. Deux propositions d’ERC intéressantes et comment calculer vos revenus futur du staking d’éthers.Enfin, la communauté teste de nouvelles façons de monétiser la création de contenus, avec la version 2 de Cent, les paiements via Twitter de Dharma et les services de 2key. Nous reviendrons également sur le lancement de Topaz et des premiers stakers de ce réseau. 

---

La semaine passée de l’écosystème

Coté Ethereum :

• Une réunion autour de l’implémentation de l’EIP1559 (la refonte des frais de transactions) prévue le 30 avril prochain. 👥

Suivez Ethereum 2.0 :

• Les dernières informations à propos du client Lighthouse, un lancement prochain du prochain réseau de test public et des travaux sur l’interopérabilité des réseaux de tests. 📰
• Retour sur le lancement réussi du réseau de test Topaz.🚀
• Un calculateur web des récompenses de staking d’Ethereum 2.0. 💸

Des nouvelles de l’écosystème :

• OpenZeppelin présente la version 3 de ses smart-contracts, fonctionnant sur Solidity v0.6. 👨‍💻
• L’attaquant de la plateforme lendf.me a rendu les cryptos-actifs dérobés. Il avait en effet laissé paraître son adresse IP personnelle. 🤷‍♂️
• Cloudflare devient un validateur du réseau de test Rinkeby. 🔨

Questions de gouvernance et de DAO :

• Greg Colvin a ajouté le controversé ProgPow aux discussions du prochain appel des développeurs. 👥

Propositions de standards :

• ERC2615 : Un standard de NFT dédié à la propriété sur des actifs. 📖
• ERC2612 : Une extension/amélioration des permissions du token ERC-20. 📖

Vos Dapps favorites :

• Gnosis présente un marchÉ de prédictions liées aux Covid-19. ⛓
• Cent présente sa version 2. Une grande amélioration du système souhaitant permettre de nouveaux formats de financement des créateurs de contenus. 💸
• Status publie une comparaison entre leurs services et ceux des applications de messageries Telegram et Signal, très appréciés dans la communauté crypto. 🤔
• Présentation de la dernière version d’Aave. 🚀
• Utiliser Twitter pour envoyer des fonds à travers le monde est désormais possible via Dharma. 💸
• Monétisez vos conférences zoom avec les services de 2key. 💰
• Est-il trop risqué d’utiliser le token Dai ? 🤔

---

Article de Griffin Ichiba Hotchkiss sur blog.ethereum.org, traduit par Jean Zundel

Geeks, cet article est pour vous, tout comme L’arbre des technologies d’un Ethereum sans état auquel il succède dans la série des 1.X Files (dont la lecture préalable est très fortement recommandée). Il résume la recherche récente sur les évolutions nécessaires pour que la chaîne actuelle continue de fonctionner au mieux en attendant Ethereum 2.0, et sera très rapidement suivi du compte-rendu du Stateless Summit.

Cet article constitue un simple résumé ainsi qu’une mise à jour générale ; nous y récapitulerons les problèmes en cours de discussion, et nous préparerons le Stateless Ethereum call n° 4 ainsi que le sommet des chercheurs 1.X qui suivra EthCC.

Il suppose une bonne compréhension des concepts en jeu, car il y a beaucoup de sujets à rattraper. Si ce domaine est nouveau pour vous, je recommande de lire L’arbre des technologies d’un Ethereum sans état afin de vous imprégner du contexte.

Ce diagramme issu de l’article précité pourra vous être utile :

Le cadre général

Stateless Ethereum est un projet consistant à améliorer le protocole actuel d’Ethereum afin de permettre un paradigme de clients « sans état », dans lequel les nœuds n’ont pas tous besoin de conserver une copie à jour du trie d’état. Les clients sans état se fient alors à une signature témoin appelée « witness » produite par un nœud à état complet pour exécuter les nouveaux blocs.

Ces signatures constituent le concept central des discussions sur le sans état, et la plupart des recherches à ce sujet sont conduites sur deux fronts :

• Format et implémentation des signatures
• Disponibilité de l’état et des signatures

En premier, nous nous interrogeons sur la structure des signatures elles-mêmes, les modifications à apporter au format du trie d’état, les implémentations de la base de données des clients et les optimisations pour limiter la taille supposée des signatures.

Le second pose des questions moins bien cernées sur la topologie réseau, les protocoles de gossip de distribution de signatures et, d’un point de vue quantitatif, les incitations et les performances réseau.

Ce qu’on sait qu’on sait

Pour arriver à destination, certaines choses devront certainement se produire. Elles sont détaillées dans l’article de Vitalik, Protocol Changes to bound Witness Size :

• Une transition vers un trie binaire par une stratégie soit « progressive », soit par une coupure nette. Un basculement progressif demande des arbres de Merkle épars, alors qu’une coupure nette provoquera probablement une perturbation temporaire de la chaîne ;
• Les signatures seront produites par les mineurs qui conservent une copie de l’état complet, et devront être payées en gaz inclus dans la transaction. Cela devrait engendrer des augmentations de prix en gaz pour les opcodes EXTCODESIZE, BALANCE, CALL et SLOAD ;

À ces points généraux viennent s’ajouter des données fiables provenant d’expérimentations menées par Igor Mandrigen :

Les signatures dans une représentation en arbre binaire sont toujours plus optimisées en taille qu’en sénaire et pèsent dans les environs de 0.3-1.4 Mo selon la signature. source

Dans le cas de nœuds à état partiel, il est possible de substantiellement réduire les exigences de stockage en conservant des données partielles dans le cache et en construisant le cache de manière incrémentale à partir des signatures témoin. source

Enfin, une première ébauche a été soumise sur le repository des spécifications de Stateless Ethereum et se trouve actuellement en cours d’examen. Une spécification formelle de signature constitue une étape importante pour implémenter un prototype sans état.

Ce qu’on ne sait pas vraiment… mais on devrait pouvoir s’en sortir

Quelques points de recherche entrent dans la catégorie de « Nous savons que nous devons faire ceci, nous ne savons pas exactement comment nous allons nous y prendre, mais notre intuition nous laisse à penser qu’une solution est possible ».

La merklisation du code en offre un exemple. Afin d’éviter des signatures témoins trop grandes, la merklisation du code éclate le code du contrat pour que seule la portion du code appelé n’ait besoin d’être incluse dans la signature de la transaction. Il en existe actuellement un prototype qui utilise les instructions JUMPDEST présentes dans le code pour l’éclater en morceaux d’une taille plus facile à gérer, mais on considère cela comme une abstraction « poreuse » en exposant les tailles de signature aux sémantiques du code. Il vaudrait mieux employer des tailles de code fixes, ce qui est faisable au prix de quelques méta-données dans chaque signature (spécifiant les destinations des sauts valides), ou si le code est validé avec tous les sauts statiques imposés à la validation.

Un autre besoin manifeste est l’indexation des signatures, c’est-à-dire qu’un identifiant « canonique » pour tous les nœuds permettrait de savoir facilement qu’ils ont récupéré la signature témoin correcte pour un bloc donné avant de le valider en local. La manière la plus simple d’y arriver requiert un changement du protocole pour intégrer un witnessHash dans l’en-tête du bloc. Cela évite des vecteurs d’attaque potentiels et fait de la génération d’une signature une exigence explicite pour les mineurs produisant des blocs.

On trouve aussi dans cette catégorie une vaste palette d’éléments « méta » qui permettront à la recherche de continuer et d’accélérer. Cela comprend des outils de développement pour expérimenter et collecter des données utiles provenant de la chaîne historique, les sémantiques formelles de l’EVM, et une plateforme pour lancer des simulations de réseau.

Ce qu’on sait qu’on ne sait pas

Bien d’autres questions plus fondamentales concernant le réseau tombent dans la catégorie de l’« inconnu ». Ce sont des questions qui demandent d’autres investigations avant que nous puissions être confiants quant à la direction à prendre.

La découverte et la délivrance de données pour les nœuds en cours de synchronisation sont un problème majeur pour le Stateless Ethereum, car, au contraire du paradigme actuel de synchronisation, un nouveau nœud ne peut pas s’attendre à ce qu’un groupe aléatoire de pairs dispose de tous les bouts d’état dont il a besoin pour exécuter le bloc courant.

Comme le protocole Eth actuel ne fournit pas d’interface pour que les clients puissent demander quel est l’état dont disposent les pairs connectés, ce problème n’est pas trivial. Les nœuds ont au minimum besoin d’interroger leurs pairs pour plusieurs types de données, comme les en-têtes, les reçus, les transactions et des parties spécifiques de l’état. Les questions ouvertes abondent dans ce domaine concernant la manière dont les données sont délivrées aux nœuds ; celle dont les nœuds complets s’orienteront dans un réseau avec beaucoup de pairs sans état ; et comment le réseau empêchera les données d’état d’être à jamais perdues. Un exposé plus détaillé de ce sujet par Piper Mirriam a été posté sur le forum de ethresear.ch.

Le défi inhérent à ces questions plus lointaines tient à ce que la topologie du réseau d’un Ethereum sans état ne peut qu’être devinée en se fondant sur des suppositions de comportement rationnel et sur l’activité actuelle. Cependant, à l’inverse de la recherche sur Eth2, Stateless Ethereum est assez proche de la chaîne actuelle pour que les statistiques historiques de Eth1 s’avèrent pertinentes et utiles pour les tests. Il faudra néanmoins plus de données, et de meilleure qualité, pour avancer sur la topologie du réseau.

Une ligne parallèle d’investigations émergera une fois un groupe de nœuds beam-syncing prêt pour l’étude et l’attaque. Un nœud beam-syncing est essentiellement un prototype bricolé à la va-vite d’un nœud sans état, utilisant une primitive « naïve » (getNodeData) pour collecter (et conserver) des pièces manquantes de l’état. Nous pourrons en apprendre beaucoup sur les primitives réseau souhaitables en essayant de casser ce beam sync, puis en itérant sur ces leçons pour se rapprocher progressivement du paradigme de synchronisation sans état « réel ».

Les questions spécifiques à la transition finale vers Eth2 restent largement sans réponse, bien que le scénario de transition Eth1 <> Eth2 de Vitalik soit en ligne avec la réflexion actuelle dans le groupe 1.X.

À Paris !

Les chercheurs 1.x se rencontreront à Paris pour exposer les problèmes et travailler aux solutions en personne, le week-end après EthCC. Ce petit sommet fournira une belle opportunité de faire avancer les travaux et de collaborer sur les défis les plus obscurs et les moins bien compris de Stateless Ethereum. Allons-y !

NdT : Le sommet s’est tenu dans les locaux de l’ESGI dans le cadre du Unhackathon, en parallèle à d’autres rencontres. Compte-rendu à suivre…