De nombreuses personne décrivent l’abstraction de compte (account abstraction) comme une solution pour executer “automatiquement” une transaction a partir du moment ou certaines conditions sont rencontré. Seul une fraction de ces situations sont possible si vous implémentez l’abstraction de compte sans état - Ce que vous devriez faire
Qu’est-ce que l’abstraction de compte ?
En général, l’abstraction de compte défini la possibilité de programmer des conditions de validité d’une transaction.
Ce que n’est pas l’abstraction de compte
-
payer les frais de transaction des utilisateurs
-
Avoir nativement des multi-sig
-
des “logins social” “type web3auth
Ce ne sont que des conséquences de la mise en œuvre de l'abstraction de compte.
L'EIP-4337, que nous couvrirons plus en détail plus tard, écrit par Vitalik et al., dit : "Atteindre l'objectif clé de l'abstraction de compte : permettre aux utilisateurs d'utiliser des smartcontracts wallets contenant une logique de vérification arbitraire plutôt que des EOAs comme compte principal".
Actuellement, sur Ethereum, une transaction est valide si et seulement si :
-
Il y a un solde suffisant pour payer les frais de gaz.
-
Le nonce est correct.
-
Il a une signature numérique valide.
Mais que se passerait-il si les développeurs pouvaient définir un ensemble de conditions différentes dans lesquelles les transactions sont valides ?
Abstraction de compte avec état vs. sans état
Avant de continuer, il est important de noter qu'il existe deux types d'abstraction de compte : sans état et avec état.
Beaucoup de gens décrivent l'abstraction de compte comme un moyen d'"exécuter automatiquement des transactions une fois qu'une condition est remplie". Seul un sous-ensemble de ces situations est possible si vous implémentez l'abstraction de compte sans état - ce que vous devriez faire !
Sans état = ne dépend pas de l'état externe, n'a pas d'effets secondaires.
Avec état = peut dépendre de l'état externe, a accès à l'état de la chaîne.
Dans une implémentation d'abstraction de compte avec état, le smartcontract qui définit les conditions de validité a accès à l'état de la chaîne. Le soucis est qu'une condition qui est vraie à un moment donné peut ne pas l’être à un autre. En pratique, cela ressemblerait à un nœud envoyant une transaction qui est actuellement valide et devient invalide plus tard. Par exemple, disons que vous vouliez exécuter une transaction au bloc 1000000 automatiquement. Au bloc 1000000, vous pourriez soumettre une opération utilisateur dans la mempool, qui serait valide à ce moment-là. Mais, lorsque le bundleur essaie de la mettre dans le prochain bloc, il se pourrait qu'elle ne soit pas valide car le numéro de bloc a augmenté.
Le nœud receveur doit alors utiliser des ressources pour valider quelque chose qui ne sera jamais onchain et ne peut pas mettre sur liste noire “ce” qui a envoyé la transaction car elle était valide au moment de l'envoi.
Dans l'ERC4337, que nous aborderons plus en détail plus tard, les chercheurs ont passé beaucoup de temps à trouver comment éviter cela. La spécification interdit l'utilisation d'opcodes spécifiques comme blockNumber pour cette raison.
Avec l'abstraction de compte sans état, vous ne courez jamais le risque de changer la validité - elle est monotone.
L’implémentation de l’AA sans état selon Fuel
Nous parlerons bientôt de la manière dont d'autres écosystèmes implémentent l'abstraction de compte. En commençant par Fuel, vous verrez la différence entre construire un nouveau système en partant de zéro et la thèse modulaire, par rapport à la construction pour un système existant.
Fuel implémente l'abstraction de compte sans état avec des prédicats. Un prédicat est simplement une condition selon laquelle vous pouvez dépenser un UTXO (Unspent Transaction Output). Les prédicats sont des scripts dans lesquels la fonction principale renvoie un booléen. Une fonction pure où les actifs sous ce prédicat sont débloqués et peuvent être dépensés par l’utilisateurs si elle répond comme true. Un prédicat possède ou contrôle des UTXO.
Note : UTXO signifie "Unspent Transaction Output", ou en français "sortie de transaction non dépensée". La compréhension fondamentale des UTXOs est que pour chaque transaction, la totalité du solde, ou du nombre de jetons, est dépensée. Le montant que vous envoyez à votre destinataire leurs reviens, et le reste est brûlé, puis minté à nouveau, ce qui donne une nouvelle sortie de transaction non dépensée.
Le facteur clé à propos des prédicats de Fuel est que vous pouvez introspecter, ou examiner, les entrées et les sorties des prédicats, ce qui vous permet d'avoir des accords qui vous permettent de construire un carnet d'ordres d'échange ou de réaliser un échange atomique entre plusieurs parties.
Au niveau des transactions, les transactions UTXO décrivent un sous-ensemble des effets exacts d'une transaction. Ce sous-ensemble d'effets peut se voir attaché à des conditions dans l'abstraction de compte sans état. Fuel y parvient grâce à la décision de conception d'un modèle UTXO. C'est ce qui permet au système de connaître les entrées et les sorties d'une transaction. Sur Ethereum, vous ne connaissez que les entrées. Avec Fuel, vous pourriez utiliser les sorties pour écrire une logique qui dit que si vous fournissez X, alors Y se produira.
En termes pratiques,
Vous pourriez verrouiller des jetons dans une prédicat avec une validité programmable qui dirait : "ces jetons sont dépensables si, en retour, une certaine quantité d'un actif Y est envoyée à une certaine adresse". De même, vous pourriez avoir une certaine logique qui dit que cette transaction n'est valide que si X est échangé à un certain prix. L'astuce ici n'est pas que vous envoyez quelque chose. Cela a déjà été envoyé. Vous voyez les effets finaux de la transaction, dans ce cas, où les jetons ont été envoyées.
Validité des prédicats
Les prédicats ne sont pas vérifiés pendant l'exécution encadrée. Ils sont vérifiés lors de la validation de la transaction. Un prédicat peut vérifier si les entrées de la transaction ont des propriétés spécifiques, mais il ne se soucie pas de savoir si ces entrées sont valides (existantes, signées). Elles doivent être des entrées valides pour que la transaction soit valide, mais ce n'est pas le prédicat qui impose cette validité.
Bientôt™
Actuellement, les prédicats Fuel sont limité par le nombre d'octets comme moyen de les mesurer. À l'avenir, l'équipe va contraindre les prédicats avec du gaz, permettant l'utilisation de boucles. Cela rend possible de faire de la cryptographie comme du hachage personnalisé et de la vérification de signature, qui nécessitent généralement des boucles.
Avantages de la mise en œuvre conçu par Fuel
Note : passez cette section si vous voulez passer à ce que vous pouvez faire avec l’AA.
Introspection UTXO
Sur Bitcoin et Ethereum, ainsi que sur les protocoles qui utilisent des implémentations similaires, il n'est pas possible d'effectuer une introspection des transactions. Cela signifie que vous ne pouvez pas examiner la transaction qui l'a dépensée, et vous ne pouvez pas définir de manière programmable ce qu'il faut faire en fonction des sorties.
Fondamentalement, l'implémentation de l’AA de Fuel offre aux développeurs, et par conséquent aux utilisateurs, une plus grande flexibilité car ces choses ne sont pas codées au niveau du protocole. L'abstraction de compte de Fuel permet aux développeurs de définir des schémas de vérification personnalisés au niveau de l'application.
L'équipe de Fuel Labs a un exemple de récupération de clé privée EC pour Ethereum. Si vous vouliez une récupération EC pour des courbes différentes, un développeur pourrait en écrire une au niveau de l'application ! Jetez un coup d'œil à cette implémentation de BLS12-381 et Edwards25519 par Hashcloack, écrite en Sway.
EC RECOVER : Lorsque vous envoyez une transaction au réseau Ethereum, vous devez signer cette transaction avec votre clé privée. EC Recover déplace cette fonctionnalité de vérification d'une signature dans un smartcontract plutôt qu’être quelque chose qu’uniquement un nœud Ethereum peut faire. Avec cela, vous pouvez vérifier bien plus que la signature de la transaction elle-même.
Pas d'augmentation de l'état
L'abstraction de compte sans état ne gonfle pas (autant) l'état car même lorsqu'elle est dépensée, elle n'entre jamais dans l'état de la blockchain, seulement dans l'historique.
Avec les prédicats, il n'y a pas de contrats, d'état ou de stockage. Les prédicats n'ont pas d'état au départ, et si quelqu'un dépense au nom du prédicat, vous n'obtenez qu'une seule entrée de base de données, seulement pour l'UTXO au lieu d'un arbre d'état.
Comment d'autres équipes mettent en œuvre l'abstraction de compte
Comme la plupart des choses en informatique, l'abstraction de compte peut être mise en œuvre de multiples façons. Aucune implémentation n'est standard dans l'ensemble de l'industrie.
Ethereum L'EIP-2938 était une proposition initiale pour permettre à un contrat d'être le compte de niveau supérieur qui paie les frais et lance les transactions. L'implémentation consistait à introduire un nouvel opcode EVM pour signaler la validité afin d'étendre les conditions des transactions avec l'exécution de bytecode EVM arbitraire. Cette proposition n'a pas été intégrée dans le protocole car les développeurs étaient occupés avec d'autres changements comme le merge et ne pouvaient pas risquer un changement de protocole d'une telle ampleur.
L'ERC-4337 est la première proposition/norme d'abstraction de compte qui introduit l'abstraction de compte sur Ethereum sans nécessiter de changements de protocole de base. Cela est réalisé en déplaçant la validation des transactions en dehors du protocole lui-même et en la transférant à un niveau supérieur - Au niveau du smartcontract avec un point d'entrée spécial.
Sur Ethereum, les EOAs sont des comptes sur Ethereum dont la fonctionnalité est codée en dur dans le protocole. La définition de la manière dont ils paient les frais de gaz, signent des transactions, utilisent un nonce, etc. Cette norme s'éloigne de la nature codée en dur des comptes que les EOAs nous donnent.
Starknet
Starknet est un zk-rollup sur Ethereum. Starkware implémente une version modifiée du modèle de l'EIP-4337 pour Ethereum. En savoir plus à ce sujet ici.
ZkSync
zkSync est également un zk-rollup sur Ethereum. zkSync met en œuvre une version modifiée de l'EIP-4337. En savoir plus sur leur implémentation ici.
Biconomy AA
Biconomy est une plateforme d'outils pour développeurs axée sur l'infrastructure et les outils pour l'écosystème Ethereum. Biconomy implémente également une version modifiée de l'EIP-4337 et offre des fonctionnalités telles que le paiement des frais de gaz des utilisateurs dans le cadre d'un SDK. En savoir plus sur leur implémentation ici.
Design Modulaire
L'éthos modulaire consiste à ne pas concevoir un système étroitement couplé à un autre système, ce qui permet alors une plus grande flexibilité. L'implémentation de l'abstraction de compte de Fuel en est un exemple. L'implémentation de l'abstraction de compte de Fuel permet une plus grande flexibilité et un environnement hautement personnalisable où les développeurs peuvent, au niveau de l'application, définir des conditions de validité sans dépendre du protocole Fuel pour le prendre en charge.
Parce que Fuel n'a pas été construit exclusivement pour Ethereum ou tout autre système, son implémentation n'est pas entravée par le poids d'un autre système et a de la place pour l'innovation.
Alors que zkSync, Starkware et Biconomy implémentent tous une version modifiée de l'EIP-4337, Fuel a mis en œuvre une abstraction de compte unique et plus performante. Comme Fuel sera déployé en tant que rollup sur Ethereum, Ethereum dispose déjà, selon certains comptes, de l'abstraction de compte.
Ce que vous pouvez faire avec l'abstraction de compte
Les nouvelles expériences que vous voyez en cours de développement sont des fonctionnalités rendues possibles grâce à l'abstraction de compte, mais pas directement liées à l'abstraction de compte elle-même. Des choses comme le paiement des frais de gaz pour un autre utilisateurs et d’autres choses comme Web3Auth sont des fonctionnalités au niveau de la couche d'application, construites au-dessus de l'abstraction de compte. Ces fonctions sont intrinsèquement possibles grâce au mécanisme de base de l'abstraction de compte : la capacité de définir les conditions de validité d'une transaction de manière programmable.
Voici des exemples de choses construites au-dessus de l'abstraction de compte :
-
Web3auth
-
Paiement des frais de gaz pour d'autres utilisateurs
-
Liberté de schéma de vérification de signature
-
Vérification multiples de signatures (multi-sig native)
Découvrez ces projets qui ont exploité l'abstraction de compte de Fuel :
-
Authsome - Système de connexion sans portefeuille. Ce portefeuille est ensuite utilisé comme base pour une infrastructure d'authentification plug-and-play, similaire à Web3Auth.
-
Thunder - Une place de marché NFT sur Fuel qui peut exécuter en groupes des transactions d'un seul clic.
-
Poolshark - un protocole pour gérer la liquidité de façon directionnelle. Poolshark correspond aux ordres conditionnels en utilisant l'abstraction de compte de Fuel avec une liquidité mutualisée pour améliorer l'accessibilité et réduire les frais pour les traders avancés.
Amélioration de l’expérience utilisateurs (UX)
-
Récupération sociale des portefeuilles
-
Regroupement de transactions
-
Les applications peuvent payer les frais de gaz des transactions de leurs utilisateurs
-
Utilisation de portefeuilles provenant de différents écosystèmes (ou même écosystème utilisant des schémas de signature différents)
-
Connexion Web3 sans portefeuille
-
Les utilisateurs n'ont pas besoin d'ETH dans leur portefeuille "régulier" pour initier des transactions
-
Capacité de mettre 100% des fonds dans un contrat multisig et d'initier des transactions directement à partir de là
Nouvelle applications possibles
"Personne ne sait vraiment, mais c'est provocateur. Cela stimule les gens !"
La vérité est celle-ci : nous ne savons pas encore exactement quelles nouvelles applications peuvent être débloquées, mais nous pouvons commencer à apporter d'énormes améliorations à l'expérience utilisateur des applications existantes, et c'est un excellent point de départ.
Rendre la blockchain accessible à tous
Il y a quelques années, le problème d'expérience utilisateur avec les blockchains était tels, uq'elles étaient financièrement inaccessibles pour la plupart des gens dans le monde. Avec les progrès continus et la prolifération des solutions de Layer 2, nous arrivons à une nouvelle frontière : l'expérience utilisateur (UX).
Soudainement, nous pouvons réduire suffisamment les frais pour rendre les blockchains utilisables, mais l'expérience utilisateur des applications doit être plus agréable et robuste. Au cours du prochain cycle, nous prévoyons que davantage d'équipes se concentreront sur les améliorations de l'expérience utilisateur et des flux rendus possibles par l'abstraction de compte. Il s'agira d'un autre outil nécessaire pour offrir une expérience semblable à celle du Web 2.0 avec les propriétés de garde du Web 3.0.
Remerciements :
John Adler, Kristof Gazso, Yuan Han Li, James Prestwich, Ryan Sproule.
⚡️Suivre Fuel ⚡️
A propos de Fuel
Fuel est le layer d'exécution modulaire le plus rapide. Puissante et élégante, cette technologie permet une exécution parallèle des transactions, offrant aux développeurs le débit maximum le plus flexible et une sécurité maximale nécessaire pour scaler. Les développeurs choisissent FuelVM pour son expérience de développement supérieure et sa capacité à aller au-delà des limitations de l'EVM.