Actu-crypto

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
☑ ☆ ✇ Ethereum France

Qu’est-ce qu’un relayeur de transactions et comment ça marche ?

By: vincentlg —

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?

Photo by Daniel Jensen on Unsplash

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.

☑ ☆ ✇ Ethereum France

OnChainReport #11

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

EthereumReport c’est : 

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

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


Le rĂ©cap d’EthereumReport

Bienvenue dans cette onziĂšme EthereumReport.

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

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

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

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


La semaine passĂ©e de l’écosystĂšme

Coté Ethereum :

Des nouvelles de l’écosystĂšme :

Questions de gouvernance et de DAO :

Propositions de standards :

Propositions de standards :

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

Vos Dapps favorites :


Mais aussi quelques autres surprises !

☑ ☆ ✇ Ethereum France

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

By: Bettina Boon Falleur —

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. 

☑ ☆ ✇ Ethereum France

EthereumReport #9

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

EthereumReport c’est :

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

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


Le rĂ©cap d’EthereumReport

Bonjour Ă  tous et bienvenus dans cette huitiĂšme Ă©dition d’EthereumReport.

Nous connaissons enfin l’endroit ou se dĂ©roulera la prochaine Devcon, puisque aprĂšs le Japon l’annĂ©e derniĂšre, direction la Colombie en 2021 ! C’est en effet Ă  Bogota que se situera la Devcon6, mettant en avant l’AmĂ©rique du Sud et ses nombreux acteurs/utilisateurs de la finance dĂ©centralisĂ©e.

Si ce n’est pas vraiment le fameux flipening attendu depuis des annĂ©es entre Ethereum et Bitcoin (en terme de valuation) qui se dĂ©roulera le premier, ce serait plutĂŽt celui de la valuation de l’ether contre la valuation des tokens ERC20 dĂ©ployĂ©s sur le rĂ©seau. Bien Ă©videmment, cela marque simplement l’adoption d’Ethereum dans l’utilisation de token, on voit tout ça dans l’explication de la semaine.

Enfin, gros Big UP pour les copains de BanklessFrance, qui ont dĂ©marrĂ© leurs activitĂ©s la semaine passĂ©e. Pour ceux qui ne suivent pas leur projet, il s’agit d’une newsletter francophone autour de la finance dĂ©centralisĂ©e sur Ethereum. De gros dossiers d’explications, des analyses et tout ça en français.


La semaine passĂ©e de l’écosystĂšme

Ethereum :

Suivez Ethereum 2.0 :

Solutions layer 2 :

Propositions de standards :

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

Vos Dapps favorites :


Mais aussi quelques autres surprises !

☑ ☆ ✇ Ethereum France

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

By: Jean Zundel —

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.

☑ ☆ ✇ Ethereum France

EthereumReport #8

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

EthereumReport c’est :

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

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


Le rĂ©cap d’EthereumReport

Bonjour Ă  tous et bienvenus dans cette huitiĂšme Ă©dition d’EthereumReport.

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 :

Des nouvelles de l’écosystĂšme :

Questions de gouvernance et de DAO :

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 :

RĂ©gulations et Ă©tudes


Mais aussi quelques autres surprises !

☑ ☆ ✇ Ethereum France

Les français qui font Ethereum #9 : Sylvain Laurent de ConsenSys

By: Bettina Boon Falleur —

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

la cinquantaine d’ordinateurs servant a miner

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.

☑ ☆ ✇ Ethereum France

EthereumReport #7

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

EthereumReport c’est :

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

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


Le rĂ©cap d’EthereumReport

Bonjour Ă  tous et bienvenus dans cette 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 :

Suivez Ethereum 2.0 :

Des nouvelles de l’écosystĂšme :

Vos Dapps favorites :


Mais aussi quelques autres surprises !

☑ ☆ ✇ Ethereum France

Les français qui font Ethereum #8 : Mokhtar Bacha de Shipl

By: Bettina Boon Falleur —

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.

SchĂ©ma d’une mĂ©ta transaction

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Ă©.

☑ ☆ ✇ Ethereum France

1.X Files : L’Arbre des technologies d’un Ethereum sans Ă©tat – mise Ă  jour

By: Jean Zundel —

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.

☑ ☆ ✇ Ethereum France

EthereumReport #6

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

EthereumReport c’est :

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

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


Le rĂ©cap d’EthereumReport

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 :

Suivez Ethereum 2.0 :

Des nouvelles de l’écosystĂšme :

Questions de gouvernance et de DAO :

Vos Dapps favorites :


Mais aussi quelques autres surprises !

☑ ☆ ✇ Ethereum France

EthereumReport #5

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

EthereumReport c’est : 

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

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


Le rĂ©cap d’EthereumReport

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 :

Questions de gouvernance et de DAO :

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 :


Mais aussi quelques autres surprises !

☑ ☆ ✇ Ethereum France

1.X Files : Le Sommet du Sans-État

By: Jean Zundel —

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.

The 1.X Files

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.

☑ ☆ ✇ Ethereum France

EthereumReport #4

By: Guillaume Chanut —

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 :

Des nouvelles de l’écosystĂšme :

Questions de gouvernance et de DAO :

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 :


☑ ☆ ✇ Ethereum France

1.x Files: (Sans) État de l’Union

By: Jean Zundel —

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


❌