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.
The post
Quâest-ce quâun relayeur de transactions et comment ça marche ? first appeared on
Ethereum France .