Ajouter une transaction à la blockchain est parfois un casse tête. La taille des blocs étant limitée, les mineurs sélectionnent en priorité les transactions les plus profitables pour eux. 

Si vous êtes un développeur ou un utilisateur du réseau, vous avez probablement déjà été confronté au problème des transactions “stucks” (coincées). C’est un état qu’on pourrait qualifier d’attente interminable de traitement. 

Comment se retrouve-t-on dans cette situation, pourquoi par “effet domino”, cela bloque-t-il toutes nouvelles transactions avec ce compte ? Quelles solutions peuvent apporter les relayeurs de transaction ?

Pourquoi est-ce parfois compliqué d’inclure des transactions dans la Blockchain?

Pour rappel, les transactions sur Ethereum sont ordonnancées par un nombre associé à la transaction et appelé « nonce ». Chaque compte sur la chaîne dispose d’un « nonce » qui est incrémenté à chaque transaction. Ainsi, la première transaction d’un compte aura le nonce 1, tandis que la troisième aura le nonce 3. Les transactions doivent s’exécuter dans l’ordre des nonces : la transaction 3 d’un compte ne pourra être intégrée dans un bloc et exécutée avant la 2.

Si plusieurs comptes sont en compétition pour passer leur transaction dans les meilleurs délais, le gas price va subitement grimper. Imaginons dans ce contexte qu’un compte ait soumis une transaction avec un gas price trop bas, elle sera alors “coincée” par l’afflux de transactions plus rentables pour les mineurs. Le compteur de transaction (nonce) du compte n’étant plus incrémenté, ce sont toutes les transactions du compte émisent depuis l’incident qui se retrouvent alors bloquées. 

Pour sortir de cette situation dans un délai raisonnable, il faut annuler ou remplacer la transaction “coincée” par une nouvelle avec un nonce identique et un gasprice plus élevé. Il faut répéter l’opération en augmentant le gas price jusqu’à l’inclusion de la transaction dans un bloc. 

Enfin, sauf à forcer un usage séquentiel du compte (ce qui est impossible si les transactions sont émises depuis le wallet d’un utilisateur par exemple) il reste à gérer l’accumulation des transactions “en attente” du compte avec un gas price potentiellement décorrélé du nouveau prix du marché.

Rendu célèbre par Cryptokitty et les ICOs, c’est aujourd’hui aux protocoles de finance décentralisée de faire face à ce challenge. Heureusement ces problèmes restent occasionnels sur Ethereum. Néanmoins lorsqu’ils se produisent, c’est un un bug critique pour l’application. Côté utilisateur, la frustration ressemble à celle qu’on peut ressentir lorsque le paiement ne fonctionne pas sur un site e-commerce. Côté application, en plus du support que cela génère, cela se traduit généralement pas une perte de revenu. 

Utilisateurs et développeurs ont hérité d’un problème inextricable sur Ethereum 1.x. Cette situation a probablement contribué à ternir l’image du protocole. Elle a aussi montré que la communauté est capable de se mobiliser pour proposer des améliorations. 

L’une d’entre elles est basée sur l’utilisation des meta-transactions. 

Une solution basée sur les meta-transactions

Le concept de meta-transaction permet à des utilisateurs d’interagir avec la blockchain avec seulement une paire de clés publique/privée. Ce mécanisme est souvent utilisé pour rendre possible l’envoi de “gasless” transactions, c’est-à-dire émises depuis un compte (EOA) sans Ether. 

Côté utilisateur, la construction de la meta-transaction est similaire à une transaction standard (from, to, value… et signature) sauf qu’au lieu de l’envoyer directement à la Blockchain, il envoie sa meta-transaction à un tiers qui prendra en charge le gas. 

Ce tiers construit une nouvelle transaction qui contient la meta-transaction et l’envoie vers un smart contract proxy (ou seulement une fonction proxy dans un contrat). Le contrat vérifie la validité de la meta-transaction (grâce à sa signature) avant de l’exécuter.

Ce mécanisme est de plus en plus utilisé par les applications pour améliorer l’onboarding de leurs utilisateurs. Elles peuvent ainsi sponsoriser l’usage de leur service en payant le gas tout en préservant les bénéfices d’un système décentralisé pour l’utilisateur. (non-corruptibility, non-repudiation, etc).

Si l’application peut assurer elle-même le relai des transactions de ses utilisateurs, à quel moment a-t-on besoin d’un relayer?

Le dilemme entre “faire soi-même” ou “acheter une solution” est bien connu des développeurs.  La réponse dépend toujours du contexte. Pizza Hut continue de livrer ses pizzas quand la majorité des restaurateurs utilisent Uber Eat ou Deliveroo. Comme pour les restaurants, les infrastructures de relais étant complexes à développer et coûteuses à maintenir, de plus en plus d’applications intègrent des APIs pour relayer leurs transactions.

Envoyez vos meta-transactions, le relayer s’occupe de tout !

En plus d’améliorer l’inclusion des transactions dans la blockchain, les relayeurs peuvent proposer des services pour faciliter la mise en place de “gasless” transactions.

Comment un relayeur améliore-t-il l’inclusion des transactions dans la Blockchain ?

Pour un compte donné, les transactions doivent être ordonnées et validées de manière séquentielle. Dans le cas où l’on souhaite envoyer 3 transactions par exemple, la transaction 3 restera en attente tant que la 1 et la 2 n’auront pas été traitées. Le nombre de transactions en attente pour un compte est limité par le noeud (sur geth la limite par défaut est de 64 par exemple). Au delà de cette limite, le noeud peut arbitrairement supprimer des transactions de sa file d’attente.

Pour contourner ces limitations, un relayer peut dispatcher l’envoi de ses meta-transactions à partir de plusieurs comptes. Par exemple avec trois comptes le nombre de transactions pouvant être en attente sur un noeud passe de 64 à 192 dans le cas de Geth. De plus, quand une transaction est bloquée sur un des comptes, le relayer peut déporter l’envoi sur les deux comptes restant et ainsi continuer à distribuer ses transactions.

Un autre point à considérer est le système de nonce (permettant de se protéger contre le replay attack) utilisé par le smart contract relayeur. La solution choisie aura un impact sur la façon dont les transactions seront traitées.Par exemple, si l’on souhaite faire de l’ancrage de certificat, on veut pouvoir envoyer un grand nombre de transactions simultanément et l’ordre n’a pas d’importance. 

Une application peut avoir besoin d’envoyer certaines transactions de manière séquentielle et d’autres de manière simultané. En cas de volume de transactions important, les technique pour estimer le prix du gas et et les solutions de protection contre les replay attack “on chain”  peuvent avoir des impact important sur le coût des transactions. Les relayeurs permettent aux développeurs de s’affranchir de ces questions en leur mettant à disposition des services simples prêt à l’usage.

Comment un relayeur facilite-t-il la mise en place de “gasless” transactions?

La nécessité d’avoir de l’Ether sur son compte pour modifier l’état d’un smart contract rend l’onboarding utilisateur laborieux sur Ethereum. Aucune application grand public n’aura un taux de conversion élevée tant qu’elle imposera à ses utilisateurs d’acheter de l’Ether avant son utilisation.

Certaines applications proposent tout simplement de payer le gas pour leurs utilisateurs. Cette approche est souvent négligée par les développeurs car elle s’écarte de la philosophie du protocole qui vise à garantir une indépendance dans l’usage du réseau. Dans ce modèle plus traditionnel, l’application considère le gas comme un coût d’infrastructure, au même titre qu’une consommation CPU sur AWS par exemple. La génération de revenus étant généralement corrélée à l’usage des smart contract, c’est un modèle économiquement viable dans la plupart des cas.

L’application et l’utilisateur peuvent également s’accorder on chain pour un remboursement automatique des frais de gas. Avec l’émergence des services de DeFi, de plus en plus d’utilisateurs possèdent des Token sans posséder d’Ether. Certains systèmes permettent alors à leurs utilisateurs de payer leurs transactions avec un token ERC20.

L’application peut également distribuer à ses utilisateurs ses propres token au moment de l’inscription. Ce mécanisme est comparable à une distribution de coupons gratuits utilisables seulement sur les contrats de l’application.

Un relayeur aidera à mettre en place la bonne stratégie de remboursement de gas sans que cela ne nécessite de lourds investissements en recherche et développement. 

Comment s’utilise un relayeur ? 

Idéalement, tous ces services doivent fonctionner de manière transparente pour les développeurs, c’est-à-dire sans modifier ses smart contract ou le code de leurs applications.

Les services de relais sont généralement exposés via une API web classique. Ils peuvent également être disponibles en tant que proxy devant un “web3 provider” entre l’application et le noeud pour faciliter leur usage avec des librairies comme web3js.

Enfin, le design de la solution doit permettre à ses utilisateurs de vérifier que le relayer ne peut ni rejouer, ni modifier les données des meta-transactions.

Le fonctionnement d’un relayer est finalement assez similaire à celui d’une liste d’attente d’un noeud, mais il ajoute plusieurs fonctionnalités indispensables pour les applications en production (live sur le mainnet).

Existe-t-il un standard pour les relayeurs?

Décentralisation, simplicité, vie privée, sécurité, … choisir comment relayer une transaction sur Ethereum implique de prendre en compte beaucoup de critères et à nouveau, selon le contexte, les applications font des choix différents. 

GSN (Gas Station Network) est une des initiatives les plus visibles dans ce domaine. Cette solution a permis la construction d’un réseau de relayeurs décentralisés. L’utilisation d’un hub de relayeurs permet de mettre en compétition des acteurs prêts à traiter des transactions contre une commission. GSN nécessite d’importants efforts d’intégration. C’est une solution adaptée surtout lorsque l’utilisation d’un réseau P2P de relais est importante. Pour comprendre pourquoi aucun consensus autour d’un standard n’existe, comparons deux wallets: Metamask et Argent.xyz.

Le premier gère l’identité de ses utilisateurs avec un EOA, le second utilise des smart contract. Implémenter naïvement un “proxy relayeur” sur des transactions émises depuis MetaMask se révèle plus complexe qu’il n’y paraît. L’utilisation de msg.sender dans les contrats de l’application serait proscrite car elle contiendrait l’adresse du relayer et non l’adresse publique de l’utilisateur.

Argent.xyz utilise quand à lui un account contract qu’il faut déployer pour chaque utilisateur. C’est un coût supplémentaire pour Argent.xyz mais la vérification et le relai des transactions se font directement dans ce contrat, aucune modification sur les contrats de destination n’est alors requise.

Les contrats des applications peuvent aussi directement vérifier et exécuter la signature des meta-transactions en implémentant deux fonctions. Une pour se protéger contre les attaques par rejeu et l’autre pour vérifier et exécuter la transaction. Une solution qui présente de nombreux avantages mais qui reste inutilisable sur les contrats déjà déployés.

Pour aller plus loin sur les différentes philosophies de relai sur Ethereum, @wighawag à récemment proposé l’idée d’un “Minimal And Extensible Meta Transaction Forwarder” #2585. Cet EIP montre bien à quel point le sujet est vaste et activement débattu dans la communauté.

Conclusion

Les applications avec d’importants volumes de transactions paient systématiquement des commissions de réseau beaucoup trop chères. Ce gaspillage ne leur évite pas de devoir intervenir lorsqu’une transaction est bloquée. Pour les applications plus petites ou en cours de création, créer et maintenir une infrastructure de relai nécessite des investissements importants. Les prestataire de services de paiement comme Paypal ou Stripe ont permis aux développeurs d’accepter des paiements électroniques simplement sur Internet. Ethereum permet de supprimer ou limiter le pouvoir des intermédiaires. Ce protocole doit pourtant se doter de passerelles pour simplifier son utilisation. Les relayeurs répondent à ce challenge en mettant à disposition des développeurs des infrastructures fiables d’acheminement de transactions tout en étant limité “by design” à leur rôle de relaie grâce à l’utilisation exclusive de transactions pré-autorisées par les utilisateurs.

Chez Rockside.io, nous nous sommes fixé pour objectif il y a 8 mois de construire le meilleur relayeur sur Ethereum, nous traitons déjà des centaines de transactions quotidiennement pour des startups et des grands comptes. Cela traduit un besoin réel chez les développeurs. L’utilisation en progression de ce type de service montre également que le rapport des entreprises à la blockchain évolue. Nous passons d’une volonté de comprendre à une volonté d’utiliser la technologie.

The post Qu’est-ce qu’un relayeur de transactions et comment ça marche ? first appeared on Ethereum France.

EthereumReport c’est : 

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

Tout ça en 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 :

• L’analyse de l’EIP1559 (les changements du fonctionnement des frais de transactions).
• Dernier appel des core dev. Discussions autour du réseau de test YOLO, ainsi que de l’EIP2565.
• La version v1.9.15 inclus une implémentation des EIP du prochain fork, Berlin.

Des nouvelles de l’écosystème :

• La dernière édition de “What’s new in Eth2”.
• Dernier appel des développeurs d’EThereum2.0.
• Comprendre ETH2.0, la prochaine génération d’Ethereum.
• L’explication de la phase 0 d’ETH2.0.

Questions de gouvernance et de DAO :

• “A quel point les information d’Etherscan sont précises ?”
• L’analyse d’Ethereum permet la reconnaissance de ses utilisateurs. Néanmoins, des bonnes pratiques pratiques existent, suivez le guide.

Propositions de standards :

• “DAO : Gouvernance As A Service”.
• Plus de possibilités de management pour les DAO avec Minion.

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 :

• ConsenSys propose un service de KYC/AML.
• “Ethereum peut apporter de la scalabilité à Bitcoin” de Gavin Andressen.

---

Mais aussi quelques autres surprises !

The post OnChainReport #11 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 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 :

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

• Le dernier appel des développeurs. Il portait principalement sur les EIPs implémentés lors du prochain hard-fork : Berlin. Un réseau de test à ce propos est en cours d’élaboration.
• La dernière réunion autour de l’EIP1559, portant sur les modifications des frais de transactions.
• La prochain Devcon sera à Bogota, en 2021 pour sa 6e édition.

Suivez Ethereum 2.0 :

• La nouvelle édition de “What’s new in eth2”, la mort du réseau de test Schlesi et la naissance de Witti !
• Comment staker sur Witti ?
• Le dernier appel des implémenteurs ETH2.
• Les 8 choses à considérer avant de décider de stake sur Eth2.

Solutions layer 2 :

• L’explication de l’utilisation des zk-rollups afin de rendre une blockchain plus scalable.
• Comprendre les “optimistic rollups” en construisant le vôtre.

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 :

• Eijin déploie un plugin Minecraft permettant de tokeniser des objets du jeu.
• DeFi777 : du token ERC20 au nom de domaine ENS.
• RenVM apporte BTC, BCH et ZEC sur EThereum.
• “Ethereum est sous-évalué” par Ryan Sean Adams.
• Retrouver tous les projets de l’événement Hack Money (120 projets !).
• Les bonnes pratiques des DAOs.
• Simplifier les leviers dans la DeFi avec Oasis.
• Investir dans des entreprises en mode DeFi : Centrifuge.

---

Mais aussi quelques autres surprises !

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.

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}

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 !

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.

The post 1.X Files : Introduction à la spécification des signatures témoins first appeared on Ethereum France.

EthereumReport c’est :

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

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

---

Le récap d’EthereumReport

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

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

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

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

---

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

Suivez Ethereum 2.0 :

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

Des nouvelles de l’écosystème :

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

Questions de gouvernance et de DAO :

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

Propositions de standards :

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

Vos Dapps favorites :

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

Régulations et études

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

---

Mais aussi quelques autres surprises !

The post EthereumReport #8 first appeared on Ethereum France.

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

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

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

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

Quelle est ton occupation principale ?

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

ETH 2.0 sera différent à utiliser ?

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

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

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

La cible de ton infrastructure, ce sont les entreprises ?

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

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

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

Tu as découvert ETH chez Blockchain Partner ?

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

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

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

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

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

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

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

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

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

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

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

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

EthereumReport c’est :

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

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

---

Le récap d’EthereumReport

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

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

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

---

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

Coté Ethereum :

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

Suivez Ethereum 2.0 :

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

Des nouvelles de l’écosystème :

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

Vos Dapps favorites :

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

---

Mais aussi quelques autres surprises !

The post EthereumReport #7 first appeared on Ethereum France.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Un autre protocole de synchronisation

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

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

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

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

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

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

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

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

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

Prototype de spécification de signature

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

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

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

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

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

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

EVM

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

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

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

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

La transition vers un trie binaire

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

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

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

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

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

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

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

Un vrai Ethereum sans état

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

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

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

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

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

Restez chez vous, restez en ligne

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

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

EthereumReport c’est :

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

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

---

Le récap d’EthereumReport

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

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

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

---

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

Coté Ethereum :

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

Suivez Ethereum 2.0 :

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

Des nouvelles de l’écosystème :

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

Questions de gouvernance et de DAO :

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

Vos Dapps favorites :

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

---

Mais aussi quelques autres surprises !

EthereumReport c’est : 

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

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

---

Le récap d’EthereumReport

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

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

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

---

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

Coté Ethereum :

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

Des nouvelles de l’écosystème :

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

Questions de gouvernance et de DAO :

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

Propositions de standards :

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

Vos Dapps favorites :

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

---

Mais aussi quelques autres surprises !

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

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

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

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

À quoi cela ressemblait-il ?

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

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

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

De quoi a-t-on parlé ?

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

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

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

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

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

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

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

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

EthereumReport c’est : 

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

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

---

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

Le récap d’EthereumReport

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

---

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

Coté Ethereum :

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

Suivez Ethereum 2.0 :

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

Des nouvelles de l’écosystème :

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

Questions de gouvernance et de DAO :

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

Propositions de standards :

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

Vos Dapps favorites :

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

---

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

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

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

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

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

Le cadre général

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

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

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

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

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

Ce qu’on sait qu’on sait

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

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

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

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

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

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

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

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

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

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

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

Ce qu’on sait qu’on ne sait pas

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

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

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

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

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

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

À Paris !

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

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