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 Nicolas Bacca, cofondateur et directeur innovation chez Ledger.
Bonjour Nicolas, merci de prendre un peu de temps pour Ethereum-France aujourdâhui. Pour commencer, tu es un cofondateur et le directeur innovation chez Ledger, est-ce que tu pourrais te prĂ©senter en quelques phrases?  Â
Je viens du monde de la carte Ă puce. Jâai crĂ©Ă© plusieurs boĂźtes avant de monter Ledger. Mon obsession a toujours Ă©tĂ© la carte Ă puce. Câest un objet que tout le monde a dans la main, dans son portefeuille ou dans son tĂ©lĂ©phone et qui a une particularitĂ© assez amusante. Une carte Ă puce, câest dĂ©tenir des secrets, mais ce ne sont pas tes secrets. Câest-Ă -dire que lorsque tu as une carte Ă puce aujourdâhui, tu dĂ©tiens le secret de ta banque ou de ton opĂ©rateur, mais ce serait quand mĂȘme vachement bien que ce soit tes secrets que tu dĂ©tiens. On sait Ă©galement que câest trĂšs dur de casser une carte Ă puce. Personne nâa jamais vraiment rĂ©ussi. Du coup que pourrait-on imaginer comme produit en ayant une carte Ă puce dans laquelle on pourrait mettre son secret? Au dĂ©part jâai pensĂ© aux mots de passe. Les gens pourraient protĂ©ger leurs mots de passes. Je me suis rendu compte que ça ne marchait pas vraiment, jâai crĂ©Ă© une boite lĂ dedans avant et lâexpĂ©rience mâa montrĂ© que cela importait peu aux gens. En dĂ©couvrant la blockchain, jâai eu une forme de dâĂ©piphanie : quand on attache de lâargent Ă un secret, tout de suite, les gens sont beaucoup plus intĂ©ressĂ©s par sa protection parce quâon panique quand on perd mĂȘme 10 euros. On a une peur primaire de perdre de lâargent. Du coup, jâai enfin trouvĂ© un intĂ©rĂȘt pour mettre ses secrets dans une carte Ă puce: lâargent. Mon intĂ©rĂȘt pour la blockchain est arrivĂ© de lĂ .Â
Câest comme ça que Ledger est arrivĂ©. Depuis, Ledger a pas mal grossi et je tiens particuliĂšrement Ă remercier la blockchain Ethereum car suite au boom des ICOs en 2017, on a pu vendre Ă©normĂ©ment dâappareils. Aujourdâhui, on en est Ă peu prĂšs 200 employĂ©s. Au niveau de lâinnovation, mon rĂŽle est de fluidifier la roadmap, qui commence Ă ĂȘtre un petit peu complexe sur nos produits avec 200 personnes. Je me prĂ©sente comme un entrepreneur âin houseâ. Jâanalyse des projets que je trouve intĂ©ressants autour de moi et je regarde comment faciliter lâintĂ©gration de ces projets dans Ledger, et, en mĂȘme temps, jâessaie de voir oĂč Ledger pourrait aller dans quelques annĂ©es. Câest-Ă -dire Ă quoi ressemblera le prochain hardware wallet? Est-ce quâil sera intĂ©grĂ© dans un tĂ©lĂ©phone, dans une montre, dans un frigidaire ?
Est-ce que tu as une formation qui tâa permis dâintĂ©grer lâĂ©cosystĂšme de la blockchain plus facilement. Es-tu cryptographe ?Â
Je ne suis pas cryptographe, je suis un vile utilisateur de cryptographie. Je nâĂ©cris pas dâalgorithme. Par contre, jâai des gens, mes Ă©quipes, qui Ă©crivent des algorithmes. Moi, jâessaye de les utiliser le mieux possible. Jâessaye de faire de la cryptographie qui sera adaptĂ©e Ă des usages un peu particuliers, tels que « comment faire pour aller le plus vite possible sur un appareil qui va ĂȘtre le plus restreint possible? » « Comment faire pour ĂȘtre le plus sĂ©curisĂ© possible? » Jâai une formation dâingĂ©nieur avec une formation monĂ©tique. Je suis sorti de lâENSI de Caen, qui sâappelait lâISMRA Ă lâĂ©poque. Dans la monĂ©tique, on a eu la chance dâavoir un professeur qui Ă©tait un des crĂ©ateurs du Minitel. Jâai commencĂ© Ă tomber un peu dans les cartes Ă puce Ă ce moment lĂ . Je suis assez autodidacte â jâai bidouillĂ© pas mal depuis mon plus jeune Ăąge â je commence Ă ĂȘtre un peu vieux dans la communautĂ© (rires), et enfant jâai fait partie du « plan informatique pour tous ». On mettait des Ă©tudiants sur des ordinateurs fantastiques qui sâappelaient des MO5 quâon mettait en rĂ©seau. On pouvait dessiner des trucs sur des tĂ©lĂ©s, ça sâappelait des crayons optiques. On avait une tortue physique qui se baladait sur une table Ă qui on donnait des ordres en lui disant de tourner Ă gauche, tourner Ă droite⊠Ca peut paraĂźtre un peu curieux maintenant.Â
Tu as dĂ©couvert la blockchain par ton intĂ©rĂȘt pour les cartes Ă puces, quand Ă©tait-ce, et quelle en Ă©tait ta premiĂšre impression? Â
Je suis tombĂ© sur le Bitcoin en mi-2012 et, tout de suite, ça a cliquĂ©. Je me suis dit « ce truc coche toutes les cases », câest-Ă -dire quâil a rĂ©ussi, lĂ oĂč dâautres avaient tentĂ©, Ă faire des choses avec de la cryptographie grĂące Ă lâajout dâune dynamique de thĂ©orie des jeux; une dynamique Ă©conomique. Dans ma tĂȘte, un systĂšme qui tourne avec la cupiditĂ© -un des principaux moteurs pour faire avancer les choses- ça ne pouvait que fonctionner. Câest un truc oĂč des gens peuvent gagner de lâargent et en mĂȘme temps, ça permet de crĂ©er une monnaie complĂštement dĂ©centralisĂ©e, hors de toute contrainte et sur laquelle on a enfin la main. Le lien avec ce que jâessayais de faire sur des cartes Ă puce, pour moi, Ă©tait juste Ă©vident. Ă lâĂ©poque, jâavais une boite sur laquelle on faisait pas mal de choses en consulting. Jâai prĂ©venu mes acolytes que jâavais commencĂ© Ă mâintĂ©resser à ça. Ils commençaient Ă avoir lâhabitude parce que par le passĂ©, je mâĂ©tais dĂ©jĂ intĂ©ressĂ© Ă des trucs bizarres. De ma dĂ©couverte du Bitcoin à « on peut faire quelque chose avec la carte Ă puce et Bitcoin » ça a quand mĂȘme pris un an et demi. On a dĂ©veloppĂ© Ă sec, sans ĂȘtre soutenu par qui que ce soit, avant dâaller sur une des premiĂšres confĂ©rences Ă lâĂ©poque qui sâappelait la San JosĂ© Bitcoin Conference en 2013 qui Ă©tait un endroit absolument surrĂ©aliste. Aujourdâhui, les confĂ©rences crypto sont assez ennuyeuses comme pas mal des confĂ©rences dâindustrie. Sur Ethereum câest encore diffĂ©rent, mais quand on assiste Ă des confĂ©rences non dĂ©veloppeurs, câest un peu classique. LĂ , on avait de tout, des libertariens, on avait des gars qui chantaient, qui essayaient de fabriquer des objets et de les vendre en Bitcoin. CâĂ©tait un premier contact assez fun.Â
Du coup, tu fais tes dĂ©buts sur Bitcoin, quâest-ce qui tâa intĂ©ressĂ© chez Ethereum?
Je trouve que les deux systĂšmes sont totalement diffĂ©rents et en mĂȘme temps totalement complĂ©mentaires. On a une courbe dâapprentissage extrĂȘmement complexe sur Bitcoin, mais on a un systĂšme trĂšs stable, un systĂšme qui est vraiment fait pour tourner dâune certaine façon, il est le moins paramĂ©trable possible. Ăa permet de bien montrer les concepts Ă©conomiques et comment les concepts Ă©conomiques interagissent avec la technique en sachant que la technique reste fiable. On se concentre sur lâĂ©conomie, on regarde ce qui se passe derriĂšre et ça permet de faire des choses. Ethereum jâai envie de dire que câest un petit peu le principe inverse puisque la courbe dâapprentissage est minuscule. Beaucoup de gens peuvent essayer de faire des trucs. AprĂšs comme beaucoup de gens peuvent se lancer, cela a permis la crĂ©ation de choses bizarres mais câest un terrain dâexpĂ©rimentation absolument fantastique, aussi bien sur les parties techniques quâĂ©conomiques. Quand jâai commencĂ© Ă mâintĂ©resser Ă Ethereum jâavais investi un petit peu de Bitcoin dans la prĂ©vente que jâai instantanĂ©ment perdu aprĂšs la prĂ©vente, en essayant de les Ă©changer sur Kraken. Pour donner une idĂ©e de mon expertise de trader, lors de mon premier trade jâai confondu « buy » et « sell » et ça ne sâest pas trĂšs bien passĂ© (rires).
Jâai continuĂ© Ă mâintĂ©resser Ă Ethereum, pour justement voir dans ce bouillonnement crĂ©atif ce quâon pouvait faire. Pour en revenir Ă la cryptographie, elle avance super vite, on a des applications, des nouveaux algorithmes cryptographiques, notamment en ce qui concerne la protection de la vie privĂ©e. Toutes les choses que lâon fait aujourdâhui sur les « privacy chains », « privacy coins », sur Ethereum, on peut retrouver ça dans des grappes dâalgorithmes plus gros qui vont servir Ă protĂ©ger la vie privĂ©e. Câest sur les crypto-monnaies quâon voit ces algorithmes arriver en production. GrĂące à ça, ces algorithmes subissent le test le plus violent qui puisse exister, Ă savoir le test monĂ©taire. Jâai lâhabitude de dire, concernant la sĂ©curitĂ©, que les blockchains sont des « bug bounties » gĂ©ants (de la recherche de bugs pour laquelle on va ĂȘtre payĂ©). Quand on veut organiser ça pour une boite, on doit organiser des choses formelles. On engage des hackers et leur proposant une rĂ©munĂ©ration sâils trouvent quelque chose. Au final, on nâa jamais vraiment la garantie de trouver les bons hackers et eux nâont pas la garantie dâĂȘtre payĂ©. Alors que sur une blockchain, on a une « incentive » immĂ©diate pour casser des choses. Que ce soit casser la partie technique, Ă©conomique ou cryptographique. Ce qui est magnifique sur Ethereum, câest quâon combine tout en mĂȘme temps. On a des « bug bounties » fabuleux pour tester les nouvelles classes dâalgorithmes cryptographiques, notamment au niveau de la « privacy » et au niveau de la « scalability », puisque quand on voit ce qui se passe au niveau de la « scalability », on a recours Ă des techniques de cryptographie modernes.
Avec tout ce quâon arrive Ă dĂ©montrer aujourdâhui sur Ethereum on se retrouve avec des classes dâalgorithmes qui nâexistaient pas auparavant et quâon pourra appliquer sur plein dâautres choses. Par exemple, aujourdâhui, on voit tous les dĂ©bats qui se font autour des applications de traçage tels que stop COVID, etc. Si on avait des algorithmes qui Ă©taient rĂ©putĂ©s solides pour pouvoir collecter des gros morceaux de donnĂ©es et en faire des rapports les plus anonymes possibles, ça serait quand mĂȘme trĂšs utile. Quand on est face Ă des monstres qui peuvent potentiellement collecter des donnĂ©es utilisateurs dans tous les sens, si on arrive Ă , dĂšs le dĂ©part, Ă©crire des algorithmes qui garantissent que tout ce quâon collecte va passer dans une moulinette, et donner des donnĂ©es utilisables, mais quâon ne pourra jamais revenir Ă lâutilisateur, on a quelque chose de super utilisable et les crypto-monnaies vont nous permettre dâĂ©prouver ces algorithmes. Je considĂšre les crypto-monnaies aujourdâhui comme une espĂšce de laboratoire gĂ©ant de nouvelles techniques cryptographiques qui permettent de les faire Ă©voluer beaucoup plus vite que tout ce quâon a pu constater jusquâĂ prĂ©sent.Â
Les crypto monnaies sont donc un bac Ă sable pour faire avancer la cryptographie selon toi?Â
Je le vois complĂštement comme ça ! Les blockchains sont des bacs Ă sable, surtout Ethereum, pour faire avancer Ă©normĂ©ment de choses. Quand on voit tout ce qui se passe au niveau de la DeFi (finance dĂ©centralisĂ©e), on voit Ă©merger des considĂ©rations qui pourraient ĂȘtre Ă©conomiques et sociales. Beaucoup de gens parlent de revenu universel, et si on rĂ©flĂ©chissait une Ă©tape plus loin en se demandant ce que lâon pourra faire lorsquâon recevra ce revenu universel? Comment se faire des prĂȘts entre soi, comment garantir que quelquâun va nous rembourser, comment peut-on ĂȘtre plus flexible, comment modĂ©liser un contrat lĂ©gal, avec une exĂ©cution nĂ©cessitant le moins de ressources possibles pour garantir quâil soit bien exĂ©cutĂ©? On a des rĂ©ponses Ă tous ces problĂšmes qui passent par la cryptographie, et qui passent aussi par des gros efforts dâinterface utilisateur. Quand je vois les blockchains comme un bac Ă sable, ce nâest pas dans le sens dâun jouet mais comme une façon de faire progresser la sociĂ©tĂ© Ă une vitesse qui nâa jamais Ă©tĂ© possible jusquâĂ prĂ©sent.
Aujourdâhui, Ledger, pour le grand public est un hard wallet permettant de sĂ©curiser sa clef et dâavoir accĂšs Ă ses crypto-monnaies. Si la crypto-monnaie est le bac Ă sable qui va permettre la sortie dâautres applications au sein de la blockchain, en tant que directeur innovation, est-ce que tu rĂ©flĂ©chis au positionnement de Ledger pour ces futures applications? Est-ce que vous avez dĂ©jĂ des produits permettant de stocker dâautres types dâinformation?
ComplĂštement. Justement, câest vraiment pour ça que Ethereum mâintĂ©resse. Aujourdâhui, on essaye de rĂ©soudre deux problĂšmes chez Ledger. Le premier problĂšme, câest la sĂ©curitĂ©: la dĂ©tention de la clef privĂ©e, et le deuxiĂšme problĂšme, câest un problĂšme dâinterface utilisateur. Aujourdâhui, quand on interagit avec des blockchains, avec ce type de contrat, on nâest pas juste en train dâutiliser sa clĂ© privĂ©e pour signer quelque chose. Câest-Ă -dire que si on prend des logiques de composition quâon a en DeFi, par exemple, quand on place en ordre sur une plateforme de trading dĂ©centralisĂ©e, ce serait utile dâavoir un hardware wallet nous indiquant « attention, vous allez placer un ordre qui vous permet dâacheter tel token Ă tel prix », plutĂŽt que de dire « attention, vous allez signer avec votre clef privĂ©e ce message complĂštement illisible, en hexadĂ©cimales ». On clique car on se sent en sĂ©curitĂ© avec son « hardware wallet » mais on ne comprend pas vraiment ce quâon a fait. LĂ dessus on a beaucoup de travail pour simplifier lâexpĂ©rience utilisateur et ma vision dĂ©finitive, lĂ oĂč jâaimerais bien quâon arrive, câest quâon ait cette interface super sĂ©curisĂ©e qui permette en mĂȘme temps dâexpliquer dâune maniĂšre trĂšs claire Ă lâutilisateur ce quâon est en train de faire. Quâon ait un rĂ©flexe, quand on veut faire quelque chose en ligne, de prendre son ledger, de savoir que, quand on est sur un ordinateur qui peut ĂȘtre complĂštement infectĂ©, on aura toujours une information trĂšs claire affichĂ©e sur son Ledger de lâordre quâon est en train dâeffectuer et du coup Ledger devient un outil de protection de la vie digitale. Un outil de protection qui permet en mĂȘme temps de clarifier et de simplifier ce quâon est en train de faire. Expliquer ce quâon fait est aussi important que de protĂ©ger la clĂ©. Ethereum est un fantastique bac Ă sable pour tester ces problĂ©matique dâUX parce quâelles sont complexes.Â
Ce nâest pas un petit chantier de sâattaquer Ă lâUX dans la blockchain.Â
Non, en effet ce nâest pas dans ce petit chantier! On va commencer un pilote avec un moteur de trading dĂ©centralisĂ©: Deversifi, oĂč on va avoir la signature des ordres qui va ĂȘtre directement rĂ©alisĂ©e sur le hardware wallet. Câest un petit exemple oĂč on peut aller. AprĂšs, je pense quâĂ terme, on aura une forme de dissociation de la logique du smart contract et de son interface utilisateur quâon pourra tĂ©lĂ©charger et on saura que lorsquâon interagit avec tel « smart contract », on va avoir cette interface utilisateur qui va arriver. AprĂšs, on se rend compte que quand on commence Ă parler de composition, effectivement, ça donne des problĂšmes atroces. Quand on propose trois smart contracts entre eux, on a envie dâavoir une vision claire pour lâutilisateur de ce quâil se prĂ©sente. Donc lĂ , on doit encore pousser la rĂ©flexion un cran plus loin. En tout cas câest une problĂ©matique super intĂ©ressante Ă rĂ©soudre.
Jâai un petit exercice pour toi, par rapport Ă Ledger, que ce soit sur la problĂ©matique dâUX ou sur les wallets. Est ce que tu pourrais mâexpliquer comme si jâavais 12 ans ce que tu fais?Â
Je vais regarder les diffĂ©rentes choses qui vont se mettre en place dans lâĂ©cosystĂšme, je vais prendre mes « inputs » pour voir quels sont les services qui sont populaires et quels sont les services aujourdâhui sur lesquels on commence Ă constater une traction intĂ©ressante. Ensuite, je vais rĂ©flĂ©chir Ă comment, sur ces services lĂ , on doit modifier notre support pour quâon puisse dâabord sĂ©curiser ces services. Ensuite, comprendre un peu et dĂ©cortiquer ces services pour voir ce que ça implique, dâexpliquer simplement Ă lâutilisateur ce que ce service va rĂ©aliser. En gĂ©nĂ©ral, je rĂ©alise des « proof of concepts » pour analyser ce que ça implique, sur notre « stack » technique pour dâabord ĂȘtre capable de sĂ©curiser ce protocole et ensuite ĂȘtre capable dâexpliquer clairement Ă lâutilisateur ce que le protocole est en train de faire. Parce quâune fois quâon lâa clairement expliquĂ© Ă lâutilisateur, on peut faire plein de choses. Certes, juste afficher lâinteraction, câest la version la plus bĂȘte et mĂ©chante: afficher sur le hardware wallet ce quâon est en train de faire. Mais aprĂšs, si on rĂ©flĂ©chit Ă nos produits industriels comme le Vault, on est capable de poser des conditions dâexĂ©cution supplĂ©mentaires. Câest-Ă -dire que, par exemple, si on a conscience aujourdâhui du fonctionnement dâun protocole de trading, au lieu de signer des ordres dâune maniĂšre assez simpliste, on peut poser des limites en disant « sur cette plateforme de trading je vais mâautoriser Ă signer uniquement pour tel montant par jour ». La comprĂ©hension du fonctionnement du protocole permet non seulement de mieux expliquer Ă lâutilisateur, mais aussi poser des rĂšgles de sĂ©curitĂ© complĂ©mentaires. Câest pour ça que jâai tendance Ă dire que la sĂ©curitĂ© et lâinterface utilisateur vont de pair puisquâune bonne interface utilisateur va renforcer la sĂ©curitĂ©. LĂ dessus, mon rĂŽle, ça va ĂȘtre dâavancer sur ces deux aspects et dâexpliquer comment on peut glisser ça dans notre roadmap et de voir comment on va pouvoir arriver Ă fournir ça de maniĂšre industrielle le plus rapidement possible, dans toutes les diffĂ©rentes branches de Ledger. Jâarrive vraiment au dĂ©marrage des nouveaux produits.
Merci beaucoup! Je reviens sur quelque chose que tu disais quant Ă ta mĂ©saventure de trader sur Kraken, est-ce que tu peux mâexpliquer ton rapport Ă la spĂ©culation qui se fait autour des crypto- monnaies?
Je suis un trĂšs, trĂšs mauvais trader. Jâai arrĂȘtĂ© la spĂ©culation, mais je remercie trĂšs fortement les personnes qui spĂ©culent parce que câest grĂące Ă eux quâon arrive Ă avoir plus dâintĂ©rĂȘt sur les crypto-monnaies. Pour moi, on a Ă©normĂ©ment de gens qui sont entrĂ©s dans les crypto-monnaies par la spĂ©culation. Quelque part, ils font intĂ©gralement partie du systĂšme et ils aident Ă populariser le systĂšme. Si on regarde aujourdâhui comment Bitcoin fonctionne, Bitcoin ne peut pas fonctionner sans la partie monĂ©taire et je pense que câest vraiment une composante critique du systĂšme que lâon retrouve Ă tous les niveaux. Une blockchain tourne toujours avec un token. Si le token nâa pas de valeur, lâapplication ne va pas ĂȘtre sĂ©curisĂ©e et comprendre le mĂ©canisme de sĂ©curisation de son token passe par la rĂ©flexion des attaques possibles et ça, ça passe par la spĂ©culation. Si personne ne spĂ©cule sur son token, au final, on a un systĂšme sans offre ni demande et sur lequel on ne peut rien tester. Je remercie trĂšs fortement les spĂ©culateurs de faire vivre le systĂšme.Â
La spĂ©culation aide donc Ă populariser cette technologie encore trĂšs niche malgrĂ© 10 ans dâexistence. Chez ledger vous vous attaquez aux difficultĂ©s de lâexpĂ©rience utilisateur, frein connu de lâadoption massive, est-ce que tu en vois dâautres?Â
Pour moi, lâinterface utilisateur, câest trĂšs probablement le plus gros frein parce quâon voit aujourdâhui que, quand on commence Ă vouloir gĂ©rer lâargent, on perd tout le monde dĂšs le dĂ©part. Lâutilisateur est accueilli par ces 24 mots Ă devoir Ă©crire quelque part, et les mettre dans un coffre fort⊠câest dĂ©jĂ perdu. Je pense quâon a Ă©normĂ©ment dâefforts Ă faire au niveau des interfaces utilisateurs. La difficultĂ© se situe sur un Ă©quilibre Ă trouver entre lâexpĂ©rience utilisateur et la dĂ©centralisation: oĂč place-t-on le curseur pour avoir lâexpĂ©rience utilisateur la plus simple possible et ne pas perdre la dĂ©centralisation? Le conflit est entre dĂ©centralisation et expĂ©rience utilisateur, plutĂŽt quâentre expĂ©rience utilisateur et sĂ©curitĂ©. On peut avoir des choses trĂšs sĂ©curisĂ©es avec une bonne expĂ©rience utilisateur, par contre, garder un fonctionnement trĂšs dĂ©centralisĂ©, câest compliquĂ©. Je dirais quâun autre frein est simplement la rĂ©gulation. On commence Ă concevoir des produits complexes, comme toutes les solutions DeFi. Les dĂ©veloppeurs sâarrachent dĂ©jĂ les cheveux pour comprendre ce quâils font car en effet, il ne faut pas ĂȘtre juste dĂ©veloppeur. Quand on analyse une application comme ça, il faut ĂȘtre dĂ©veloppeur, Ă©conomiste, professionnel de la thĂ©orie des jeux, etc. Il faut se dire que la rĂ©gulation derriĂšre tout ça, elle est quelques annĂ©es en arriĂšre, quand on voit les lois qui sont passĂ©es, les rĂ©gulateurs sont tout juste en train de comprendre les ICOâŠÂ Câest bien, mais câĂ©tait il y a trois ans. Lâincertitude quâon va avoir concernant la rĂ©gulation et le manque de passerelles avec le monde rĂ©el, que cette absence de rĂ©gulation engendre sont problĂ©matiques. Aujourdâhui, câest vrai que la plupart des applications sont essentiellement financiĂšres, mais on voit poindre des applications touchant le monde rĂ©el, tel que Kleros. On a un systĂšme de rĂ©solution de litiges extrĂȘmement simplifiĂ©. Câest une application qui aujourdâhui pourrait complĂštement sortir du monde de la blockchain et ĂȘtre proposĂ© Ă des gens qui Ă©crivent du contenu ou Ă des gens qui font nâimporte quel type de de service. Ils ne verraient mĂȘme pas quâil y a une blockchain derriĂšre, tout serait cachĂ© pour un utilisateur. On a des applications qui pourraient ĂȘtre prĂ©sentĂ©es pour autre chose que financier. Et mĂȘme au sein de la finance, pas la spĂ©culation mais la finance classique, recrĂ©er un compte bancaire complĂštement dĂ©centralisĂ© aurait clairement son intĂ©rĂȘt. Etre capable de mettre en place tous les services dâune banque, un livret A, faire un prĂȘt, etc. on en a la capacitĂ© technique, mais il reste le frein de la rĂ©gulation ainsi que le problĂšme dâinterface utilisateur. En termes de blocages pour lâadoption massive je dirai donc que loin devant câest lâinterface utilisateur, et derriĂšre la rĂ©gulation.  Â
Tu as mentionnĂ© lâĂ©quilibre Ă trouver entre expĂ©rience utilisateur et dĂ©centralisation. Est-ce que tu as dĂ©cidĂ© de lâorientation de ton curseur? Ce que tu serais prĂȘt Ă lĂącher en termes de dĂ©centralisation au profit de lâexpĂ©rience utilisateur ? On voit au sein de lâĂ©cosystĂšme de plus en plus dâapplications qui sont obligĂ©es dâaller vers un peu de centralisation pour permettre cette gestion. Est ce que câest quelque chose que tu envisages Ă©galement?
Câest vraiment quelque chose que jâenvisage aujourdâhui. Je pense quâil faut quâon apprenne Ă ĂȘtre bien modulaire dans la dĂ©centralisation. Aujourdâhui, pour moi, ce qui est trĂšs important surtout, câest de ne pas de crĂ©er de « lock-in » câest-Ă -dire de bloquer les utilisateurs. On peut avoir des systĂšmes qui sont dĂ©centralisĂ©s, mais qui vont ĂȘtre, par exemple, implantĂ©s par juste quelques acteurs. Si un nouvel acteur peut arriver dans le systĂšme, et peut remplacer un des acteurs du systĂšme qui serait dĂ©faillant, je considĂšre quâon a dĂ©jĂ un systĂšme plus dĂ©centralisĂ© quâun systĂšme complĂštement fermĂ©. Donc, aujourdâhui, tout simplement si le service tombe, je sais que je suis capable de rĂ©cupĂ©rer les fonds parce que le systĂšme est crĂ©Ă© de telle façon que tout est lĂ . Si je sais que quelquâun dâautre peut arriver dans le systĂšme et commencer Ă construire des services qui peuvent ĂȘtre passablement concurrents du mien, je pense que la dĂ©centralisation est toujours lĂ . Un bon test de dĂ©centralisation câest de se demander si le service que je suis en train de construire permet Ă un concurrent de se crĂ©er. Si la rĂ©ponse est oui, le test de dĂ©centralisation a rĂ©ussi.
Jâai une derniĂšre question quâon garde toujours comme petite question de fin Ă laquelle tu as un peu dĂ©jĂ rĂ©pondu. Et jâaurais peut ĂȘtre une question bonus pour toi, si tu veux bien. Dâabord, est-ce aujourdâhui tu as une application construite sur Ethereum que tu considĂšres dĂ©jĂ utile pour le grand public? Tu as parlĂ© de Kleros, est-ce que tu en as une autre?Â
Jâaime bien lâexemple de Kleros parce que je trouve que câest un exemple qui permet de cacher complĂštement la technologie. Ca va rĂ©pondre Ă des problĂšmes de la vie courante. La rĂ©solution de litige arrive Ă nâimporte qui pour nâimporte quoi. Kleros tourne avec des « incentives » qui sont liĂ©es Ă une blockchain, mais ça, on le sait que si on creuse. Un utilisateur de site e-commerce lambda peut trĂšs bien utiliser un systĂšme comme ça pour faire son propre systĂšme de rĂ©solution. En technique qui cache ce quâon a derriĂšre la blockchain, ce qui est, Ă mon avis, la meilleure façon de la populariser, je trouve que câest un bon exemple.Â
Merci beaucoup, la petite question bonus, du coup, tu parlais un peu de la rĂ©gulation et du lĂ©ger retard que les rĂ©gulateurs ont par rapport Ă la technologie. Est-ce que tu a un peu un avis sur la rĂ©gulation dans lâĂ©cosystĂšme français? Ledger fait partie de lâADAN (Association pour le DĂ©veloppement des Actifs NumĂ©riques) dont la volontĂ© est dâaccĂ©lĂ©rer la discussion et dâarriver plus rapidement Ă des solutions en termes de rĂ©gulation. Est-ce que tu as un avis sur lâĂ©cosystĂšme français, est-il favorable au dĂ©veloppement des applications blockchain?Â
Jâai envie de dire quâil y a beaucoup dâapprentissage Ă faire. Je ne pense pas quâon soit rĂ©ellement Ă la ramasse. Je pense quâon fait les choses Ă la vitesse de la rĂ©gulation. On ne peut pas demander Ă la rĂ©gulation dâaller aussi vite que le dernier protocole DeFi. Pour lâinstant, ça passe encore par des processus qui sont assez longs. HonnĂȘtement, je nâai pas lâimpression quâon soit Ă la ramasse, surtout que lâon nâest pas parmi les pays les plus faciles pour pas mal de choses. Ma principale critique au niveau de la rĂ©gulation en France, câest plus sur le double discours quâon a au niveau des banques. Si une sociĂ©tĂ© dans les crypto-actifs cherche Ă se crĂ©er, elle va se retrouver face Ă des murs. Les sociĂ©tĂ©s qui ont eu des problĂšmes pendant la crise et qui ont cherchĂ© des aides gouvernementales nâont pas eu beaucoup de succĂšs. Il nây a pas de problĂšme dans la rĂ©gulation, par contre, derriĂšre, il manque clairement des chaĂźnons de transmission. Les consignes ne sont pas bien transmises, volontairement ou involontairement, mais ça, câest un autre dĂ©bat.Â
The post Les français qui font Ethereum #10 : Nicolas Bacca de Ledger first appeared on Ethereum France.
EthereumReport câest :
Tout ça en francais et dans votre boite mail chaque mardi !
Bonjour Ă tous et bienvenus dans cette huitiĂšme Ă©dition dâEthereumReport.
Nous connaissons enfin lâendroit ou se dĂ©roulera la prochaine Devcon, puisque aprĂšs le Japon lâannĂ©e derniĂšre, direction la Colombie en 2021 ! Câest en effet Ă Bogota que se situera la Devcon6, mettant en avant lâAmĂ©rique du Sud et ses nombreux acteurs/utilisateurs de la finance dĂ©centralisĂ©e.
Si ce nâest pas vraiment le fameux flipening attendu depuis des annĂ©es entre Ethereum et Bitcoin (en terme de valuation) qui se dĂ©roulera le premier, ce serait plutĂŽt celui de la valuation de lâether contre la valuation des tokens ERC20 dĂ©ployĂ©s sur le rĂ©seau. Bien Ă©videmment, cela marque simplement lâadoption dâEthereum dans lâutilisation de token, on voit tout ça dans lâexplication de la semaine.
Enfin, gros Big UP pour les copains de BanklessFrance, qui ont dĂ©marrĂ© leurs activitĂ©s la semaine passĂ©e. Pour ceux qui ne suivent pas leur projet, il sâagit dâune newsletter francophone autour de la finance dĂ©centralisĂ©e sur Ethereum. De gros dossiers dâexplications, des analyses et tout ça en français.
The post EthereumReport #9 first appeared on Ethereum France.
Article de Griffin Ichiba Hotchkiss sur blog.ethereum.org, traduit par Jean Zundel
Les articles prĂ©cĂ©dents traitaient de Stateless Ethereum en gĂ©nĂ©ral, en faisant le point sur la recherche et en balayant tous les sujets concernĂ©s. Celui-ci se concentre sur la maniĂšre dont la spĂ©cification du sans-Ă©tat est rĂ©digĂ©e. On y aborde notamment la structure dâun witness, la notation formelle des rĂšgles de grammaire et le comportement de certains bisons de lâĂ©tat de New York.
Comme beaucoup dâentre nous ont un peu de temps libre, jâai pensĂ© que câĂ©tait lâoccasion de passer Ă quelque chose dâautre ; un peu aride, peut-ĂȘtre, mais fondamental pour le projet Stateless Ethereum. Il sâagit de comprendre la spĂ©cification formelle des signatures tĂ©moins.
Tout comme le Battlecruiser de StarCraft, on va commencer en douceur. La spĂ©cification des signatures nâest pas un concept particuliĂšrement compliquĂ©, mais il est profond. Cette profondeur peut paraĂźtre impressionnante mais lâexploration en vaut la peine, car elle fournira des notions qui, pour votre plus grand plaisir de nerd, sâĂ©tendent bien au-delĂ du monde de la blockchain ou mĂȘme de lâinformatique !
Ă la fin de cette introduction, vous devriez au moins avoir acquis assez de confiance en vous pour comprendre en quoi consiste la spĂ©cification des signatures tĂ©moins dans Stateless Ethereum. Jâessaierai aussi de ne pas rester trop sĂ©rieux tout le temps.
Stateless Ethereum est bien entendu un terme un peu inappropriĂ©, car lâobjet de cette initiative est en fait lâĂ©tat, et plus particuliĂšrement le moyen de rendre optionnel le fait de conserver cet Ă©tat. Si vous nâavez pas suivi cette sĂ©rie, vous pourrez trouver profitable de jeter un Ćil sur mon introduction Ă lâĂ©tat de Stateless Ethereum. En voici cependant un bref rĂ©sumĂ©. Vous pouvez le sauter si vous pensez suffisamment maĂźtriser ce sujet.
Ce que lâon appelle « Ă©tat » complet dâEthereum dĂ©crit le statut actuel de tous les comptes et de tous les soldes, ainsi que la mĂ©moire collective de tous les contrats autonomes dĂ©ployĂ©s dans lâEVM. Tout bloc finalisĂ© dans la blockchain ne possĂšde quâun seul Ă©tat, lequel est acceptĂ© par tous les participants du rĂ©seau. Cet Ă©tat est modifiĂ© Ă chaque nouveau bloc ajoutĂ© Ă la chaĂźne.
LâĂ©tat dâEthereum est reprĂ©sentĂ© in silico par un trie de Merkle-Patricia : une structure de hashes, dâempreintes cryptographiques de donnĂ©es, qui organise toutes les informations (comme le solde dâun compte) en une unitĂ© massivement connectĂ©e dont lâunicitĂ© peut ĂȘtre vĂ©rifiĂ©e. Le trie dâĂ©tat complet est trop Ă©norme pour ĂȘtre visualisĂ©, mais il en existe une « version jouet » qui nous sera utile quand nous en arriverons aux signatures tĂ©moins :
Comme des chenilles cryptographiques magiques, les comptes et le code des contrats vivent dans les feuilles et les branches de cet arbre qui, par des opĂ©rations successives de hachage, mĂšnent Ă une empreinte de racine unique. Quand vous voulez savoir si deux copies dâun trie dâĂ©tat sont les mĂȘmes, il suffit de comparer les empreintes des racines. La maintenance dâun consensus relativement sĂ»r et indiscutable concernant un Ă©tat « canonique » constitue lâessence de ce que fait une blockchain.
Pour soumettre une transaction Ă inclure dans le bloc suivant, ou pour valider quâun changement est cohĂ©rent avec le dernier bloc inclus, les nĆuds Ethereum doivent conserver une copie complĂšte de lâĂ©tat et recalculer lâempreinte cryptographique racine (encore et toujours). Stateless Ethereum est un ensemble de changements destinĂ©s Ă Ă©liminer cette exigence en ajoutant ce que lâon appelle un witness, une signature tĂ©moin.
Avant de plonger dans la spĂ©cification, il sera utile de prĂ©senter la notion de signature tĂ©moin. Encore une fois, une explication plus dĂ©taillĂ©e se trouve dans lâarticle sur lâĂ©tat dâEthereum dont le lien se trouve plus haut.
Une signature ressemble un peu Ă une antisĂšche pour un Ă©tudiant (client) nĂ©gligent (sans Ă©tat). Elle ne contient que lâinformation minimale nĂ©cessaire pour passer lâexamen (soumettre un changement dâĂ©tat valide Ă inclure dans le bloc suivant). Au lieu de lire tout le livre de cours (conserver une copie de lâĂ©tat courant), lâĂ©tudiant nĂ©gligent (le client sans Ă©tat) demande Ă un ami (un nĆud complet) une antisĂšche pour donner sa rĂ©ponse.
 En termes trĂšs abstraits, une signature fournit toutes les empreintes cryptographiques dâun trie dâĂ©tat, combinĂ© avec des informations « structurelles » sur lâemplacement de ces empreintes dans le trie. Cela permet Ă un nĆud « nĂ©gligent » dâinclure de nouvelles transactions dans son Ă©tat et de calculer une nouvelle empreinte racine localement, sans avoir besoin de tĂ©lĂ©charger une copie complĂšte du trie dâĂ©tat.
Mettons de cĂŽtĂ© cette idĂ©e caricaturale et passons Ă une reprĂ©sentation plus concrĂšte. Voici la « vraie » visualisation dâun tĂ©moin :
Je recommande dâouvrir cette image dans un nouvel onglet afin de pouvoir zoomer pour mieux lâapprĂ©cier. Ce tĂ©moin a Ă©tĂ© sĂ©lectionnĂ© parce quâil est relativement petit et quâil est facile dâen dĂ©gager des dĂ©tails. Chaque petit carrĂ© dans cette image reprĂ©sente un simple nibble, ou la moitiĂ© dâun octet, et vous pouvez le vĂ©rifier par vous-mĂȘme en comptant le nombre de carrĂ©s quâil vous faut « traverser » en commençant par la racine pour arriver Ă un solde en ether (vous devriez obtenir 64). Puisque nous en sommes Ă cette image, observez le gros bout de code dans lâune des transactions qui doit ĂȘtre inclus pour un appel de contrat ; le code prend une part non nĂ©gligeable de la signature et pourrait ĂȘtre rĂ©duit par merklisation de code (que nous explorerons un autre jour).
Lâune des principales caractĂ©ristiques dâEthereum en tant que protocole est son indĂ©pendance vis Ă vis dâune implĂ©mentation donnĂ©e. Câest pourquoi, au lieu dâun seul client officiel comme nous le voyons avec Bitcoin, il existe plusieurs versions complĂštement diffĂ©rentes de clients Ethereum. Ces clients, Ă©crits dans diffĂ©rents langages de programmation, doivent adhĂ©rer au Ethereum Yellow Paper qui exprime en termes formels comment un client doit se comporter pour participer au protocole Ethereum. Le dĂ©veloppeur dâun client Ethereum nâa donc pas Ă se prĂ©occuper de possibles ambiguĂŻtĂ©s dans le systĂšme.
La Witness Specification a le mĂȘme but : fournir une description sans ambiguĂŻtĂ© de ce quâest une signature tĂ©moin pour faciliter son implĂ©mentation dans nâimporte quel langage pour nâimporte quel client. Si Stateless Ethereum devient une rĂ©alitĂ©, la spĂ©cification des signatures pourra ĂȘtre insĂ©rĂ©e en annexe dans le Yellow Paper.
La signification de « sans ambiguĂŻtĂ© » dans ce contexte est plus stricte que ce que lâon entend par lĂ dans un discours ordinaire. Ce nâest pas tant que la spĂ©cification formelle est une description vraiment, mais vraiment, mais alors vraiment dĂ©taillĂ©e dâune signature et de son comportement. Cela signifie que, idĂ©alement, il existe littĂ©ralement une et une seule maniĂšre de dĂ©crire une signature donnĂ©e. Si lâon adhĂšre Ă la spĂ©cification formelle, il devient impossible dâĂ©crire une implĂ©mentation de Stateless Ethereum qui gĂ©nĂšre des signatures diffĂ©rentes dâune autre implĂ©mentation se conformant aux mĂȘmes rĂšgles. Câest essentiel car la signature va (espĂ©rons-le) devenir un nouveau pilier du protocole Ethereum ; elle doit ĂȘtre correcte par construction.
Bien que le « dĂ©veloppement blockchain » implique gĂ©nĂ©ralement quelque chose de nouveau et dâexcitant, il faut bien dire que lâessentiel en provient de traditions bien plus anciennes et matures en informatique, en cryptographie et en logique formelle. Tout ceci apparaĂźt dans la spĂ©cification des signatures ! Afin de comprendre comment cela fonctionne, nous devons nous familiariser avec certains termes techniques, et Ă cet effet nous allons faire un petit dĂ©tour par la linguistique et la thĂ©orie des langages formels.
Lisez Ă haute voix les deux phrases suivantes, et faites trĂšs attention Ă votre intonation et Ă la cadence :
Je parie que votre diction pour la premiĂšre phrase Ă©tait un peu robotique, avec une accentuation plate et une pause aprĂšs chaque mot. En revanche, la seconde a semblĂ© naturelle bien quâun peu loufoque. MĂȘme si elle ne veut rien dire, la seconde phrase possĂšde un sens que la premiĂšre nâa pas. Il sâagit ici de vous diriger intuitivement vers la distinction entre syntaxe et sĂ©mantique. Si vous parlez français, vous comprenez ce que reprĂ©sentent les mots (leur contenu sĂ©mantique) mais cela nâa aucune importance ici ; vous avez remarquĂ© une diffĂ©rence entre une grammaire valide et une grammaire invalide (leur syntaxe).
Cette phrase en exemple provient dâun article de 1956 par un certain Noam Chomsky, dont le nom peut vous dire quelque chose. Bien quâil soit maintenant connu comme un influent penseur politique et social, ses premiĂšres contributions acadĂ©miques furent dans le domaine de la logique et de la linguistique et, dans cet article, il a crĂ©Ă© lâun des systĂšmes les plus utiles de classification des langages formels.
Chomsky se consacrait Ă la description mathĂ©matique de la grammaire, Ă la maniĂšre dont on peut catĂ©goriser les langages dâaprĂšs leurs rĂšgles grammaticales, et aux propriĂ©tĂ©s de ces catĂ©gories. Lâune des propriĂ©tĂ©s qui nous intĂ©resse ici est lâambiguĂŻtĂ© syntaxique.
ConsidĂ©rons la phrase anglaise suivante, qui est grammaticalement correcte : « Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo. » Câest un exemple classique qui illustre Ă quel point la syntaxe anglaise peut ĂȘtre ambiguĂ«. Si vous comprenez que, selon le contexte, le mot « buffalo » peut ĂȘtre utilisĂ© comme un verbe (intimider), un adjectif (de Buffalo, NY) ou un nom (bison) qui peut ĂȘtre invariable en anglais, vous pouvez analyser la phrase selon lâappartenance de chaque mot.
Nous pouvons aussi employer des mots complĂštement diffĂ©rents, en plusieurs phrases. « Vous connaissez ces bisons de lâĂ©tat de New York que dâautres bisons de lâĂ©tat de New York intimident ? Eux-mĂȘmes intimident. Plus prĂ©cisĂ©ment, ils intimident des bisons de lâĂ©tat de New York ». Ou, plus simplement, « Les bisons de Buffalo que des bisons de Buffalo intimident intimident des bisons de Buffalo ».
Et si nous voulons retirer cette ambiguĂŻtĂ©, tout en nous restreignant au seul emploi du mot « buffalo », dans une seule phrase ? Câest possible mais nous devons un peu modifier les rĂšgles de lâanglais. Notre nouveau « langage » deviendra un peu plus exact. Une façon possible de faire serait de marquer chaque mot pour indiquer son rĂŽle dans la phrase, comme ceci :
Buffalo{pn} buffalo{n} Buffalo{pn} buffalo{n} buffalo{v} buffalo{v} Buffalo{pn} buffalo{n}
Tout ceci reste peut-ĂȘtre encore obscur pour le lecteur. Pour que ce soit encore plus exact, essayons une petite substitution pour nous aider Ă regrouper quelques-uns de ces « buffalo » en troupeau. Tout bison de Buffalo, NY nâest quâune version particuliĂšre de ce quâon appelle un groupe nominal ou noun phrase, <NP>
. Nous pouvons substituer <NP>
dans la phrase Ă chaque fois que nous rencontrons la chaĂźne Buffalo{pn} buffalo{n}
. Comme nous devenons un peu plus formels, utilisons une notation plus brĂšve pour cette rĂšgle de substitution et celles Ă venir en Ă©crivant :
<NP> ::= Buffalo{pn} buffalo{n}
oĂč ::=
signifie « Ce qui est Ă gauche peut ĂȘtre remplacĂ© par ce qui est Ă droite ». Attention, cette relation ne doit pas fonctionner dans lâautre sens ; imaginez lâĂ©tat dans lequel se mettrait le bison de Boulder !
En appliquant notre rĂšgle de substitution Ă toute la phrase, elle devient :
<NP> <NP> buffalo{v} buffalo{v} <NP>
Cela dit, la confusion persiste nĂ©anmoins, car cette phrase contient une proposition relative implicite, qui peut ĂȘtre explicitĂ©e en insĂ©rant le pronom « that » (qui) dans la premiĂšre partie de notre phrase, câest-Ă -dire <NP> *that* <NP> buffalo{v}âŠ
Donc créons une rÚgle de substitution qui regroupe la proposition relative (relative clause) en <RC>
, et Ă©crivons :
<RC> ::= <NP> buffalo{v}
De plus, comme une proposition relative ne fait que clarifier un groupe nominal, les deux pris ensemble sont Ă©quivalents Ă un autre groupe nominal :
<NP> ::= <NP><RC>
Ces rÚgles étant établies et appliquées, nous pouvons écrire la phrase :
<NP> buffalo{v} <NP>
Cela commence Ă ressembler Ă quelque chose, et on parvient ainsi au cĆur de la relation exprimĂ©e par cette phrase : un groupe donnĂ© de bisons intimide un autre groupe de bisons.
Au point oĂč nous en sommes, pourquoi ne pas aller jusquâau bout ? Chaque fois que « buffalo » en tant que verbe prĂ©cĂšde un nom, nous pourrions appeler cela un groupe verbal (verb phrase) ou <VP>
, et définir une rÚgle :
<VP> ::= buffalo{v}<NP>
Cela fait, nous avons notre phrase unique, complĂšte et valide, que nous pouvons appeler S :
S ::= <NP><VP>
Ce que nous avons fait ici peut ĂȘtre reprĂ©sentĂ© visuellement :
Cette structure semble Ă©trangement familiĂšre, nâest-ce pas ?
Lâexemple du Buffalo est un peu idiot et pas trĂšs rigoureux, mais il suffit pour montrer Ă quoi ressemble lâĂ©trange langage mathĂ©matique de la spĂ©cification des signatures tĂ©moins, que jâai sournoisement introduit dans lâexposĂ© sur les bisons. Elle sâappelle la forme de Backus-Naur, et elle est souvent employĂ©e dans des spĂ©cifications formelles telles que celle-ci pour de nombreux scĂ©narios du monde rĂ©el.
Les « rÚgles de substitution » que nous avons définies pour notre sous-ensemble de langue anglaise nous ont permis de nous assurer que, étant donné un troupeau de « buffalo », nous pouvions construire une phrase anglaise « valide » sans connaßtre la signification du mot buffalo dans le monde réel. Dans la premiÚre classification déterminée par Chomsky, un langage possédant des rÚgles de grammaire suffisamment exactes pour arriver à ce résultat est appelé un langage non-contextuel.
Le plus important est que cette rĂšgle assure que pour chaque phrase comprenant le(s) mot(s) buffalo{np|n|v}
, il existe une et une seul maniĂšre de construire la structure de donnĂ©es illustrĂ©e dans le diagramme de lâarborescence ci-dessus. DĂ©sambiguĂŻsation !
Un witness nâest finalement quâun grand objet encodĂ© dans un tableau dâoctets. Du point de vue (anthropomorphique) dâun client sans Ă©tat, ce tableau dâoctets ressemble un peu Ă une longue phrase composĂ©e de mots trĂšs similaires. Tant que tous les clients suivent le mĂȘme ensemble de rĂšgles, le tableau dâoctets ne peut se convertir quâen une et une seul structure de donnĂ©es, quelle que soit la façon dont lâimplĂ©mentation choisit de la reprĂ©senter en mĂ©moire ou sur disque.
Les rĂšgles de production, rĂ©digĂ©es en section 3.2, sont un peu plus complexes et beaucoup moins intuitives que celles que nous avons employĂ©es dans notre petit exemple, mais lâesprit reste le mĂȘme : exprimer des lignes directrices sans ambiguĂŻtĂ© pour un client sans Ă©tat (ou un dĂ©veloppeur Ă©crivant un client), lignes directrices Ă suivre pour ĂȘtre certain dâarriver Ă un rĂ©sultat correct.
Jâai volontairement omis de nombreuses choses dans cet exposĂ© et le labyrinthe des langages formels va Ă©videmment bien plus loin. Je voulais simplement fournir une introduction suffisante pour dĂ©passer ce premier obstacle Ă la comprĂ©hension. Maintenant, il est temps de passer Ă Wikipedia et de vous attaquer au reste par vous-mĂȘme !
Comme toujours, si vous avez des retours, des questions ou des requĂȘtes de nouveaux sujets, vous pouvez joindre @gichiba ou @JHancock sur Twitter.
The post 1.X Files : Introduction à la spécification des signatures témoins first appeared on Ethereum France.
EthereumReport câest :
Tout ça en francais et dans votre boite mail chaque mardi !
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.
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 :
Tout ça en francais et dans votre boite mail chaque mardi !
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.
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.
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.
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.
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.
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.
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.
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 :
Tout ça en français et dans votre boite mail chaque mardi !
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.
EthereumReport câest :Â
Tout ça en français et dans votre boite mail chaque mardi !
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.