Actu-crypto

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierEthereum France

OnChainReport #11

L’attribut alt de cette image est vide, son nom de fichier est 2C31FAB2-5265-49D6-BF66-EFF661EDD1C8.png.

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

Bienvenue dans cette onzième EthereumReport.

Cette semaine fut animé par trois transactions exceptionnelles, puisque si les montants échangés restent classiques, les frais de transactions s’élèvent à plus de 2300 ethers !

La communauté a rapidement relayé la nouvelle et les théories sont nombreuses :

  • Erreur de configuration de transactions automatiques ?
  • Blanchiment d’argent via les frais de transactions avec la complicité d’une pool de minage ?
  • Utilisation d’une faille de sécurité afin de faire pression sur des plateformes d’échanges.

Nous vous proposons également dans cette édition la lecture du dernier guide de la série “1.X Files” et l’épisode du podcast 21Millions dédié à la finance décentralisée.


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

Coté Ethereum :

Des nouvelles de l’écosystème :

Questions de gouvernance et de DAO :

Propositions de standards :

Propositions de standards :

  • EIP2711: Séparer celui qui paie les frais de transactions de celui qui effectue cette dernière.
  • EIP2718: Une enveloppe pour les futurs types de transactions.

Vos Dapps favorites :


Mais aussi quelques autres surprises !

Les français qui font Ethereum #10 : Nicolas Bacca de Ledger

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. 

EthereumReport #9

L’attribut alt de cette image est vide, son nom de fichier est 2C31FAB2-5265-49D6-BF66-EFF661EDD1C8.png.

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.

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.


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

Ethereum :

Suivez Ethereum 2.0 :

Solutions layer 2 :

Propositions de standards :

  • ERC2680 : Un standard de portefeuille Eth2.
  • ERC2678 : EthPM v3.
  • EIP2681 : Une restriction de la taille du nonce d’un compte à 2^64-1.
  • EIP2677 : Une limite de taille pour les initcode.

Vos Dapps favorites :


Mais aussi quelques autres surprises !

1.X Files : Introduction à la spécification des signatures témoins

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.

Récapitulons : ce que vous devez savoir sur l’état

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.

Schéma d’une signature

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

Quelques formalités

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.

Une question de sémantique (et de syntaxe)

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 :

  • vertes furieusement idées d’incolores dorment
  • d’incolores idées vertes dorment furieusement

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.

Ambiguïté du buffalo

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}

::= 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 !

Allez, et lisez la spec

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.

❌