Actu-crypto

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterdayEthereum France

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

June 17th 2020 at 16:27

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.

❌