Qu'est-ce que le Delegation Toolkit et que pouvez-vous créer avec ?

Le contrôle des comptes sur Ethereum a toujours été rigide. Les comptes externes (EOA, Externally Owned Accounts) sont simples et largement utilisés, mais leurs fonctionnalités restent limitées. Les comptes à contrats intelligents (SCA, Smart Contract Accounts) offrent bien plus de flexibilité, mais jusqu'à récemment, ils ne pouvaient pas fonctionner de manière autonome. Il fallait toujours un EOA pour initier et payer chaque transaction.

Cela a changé avec ERC-4337, car les SCA peuvent désormais prendre en charge nativement des fonctionnalités telles que la prise en charge du gas, le regroupement de transactions (combinaison de plusieurs transactions en une seule), les clés de session et l'abstraction de chaîne, ce qui améliore la sécurité, la flexibilité et le contrôle des utilisateurs.

Pour autant, les EOA n'ont pas disparu. Et pour cause : tous les utilisateurs ne trouvent pas utile de disposer d'un compte prenant en charge une logique de vérification arbitraire. À quoi bon migrer vers un SCA dès maintenant ?

Mais comment s'assurer alors que, lorsqu'ils seront prêts à effectuer la migration — ou même à exploiter temporairement une ou plusieurs fonctionnalités de compte ERC-4337 — ils ne soient pas contraints de créer un nouveau type de compte de zéro ? Comment permettre aux EOA de bénéficier des fonctionnalités d'un SCA pour des transactions spécifiques, sans renoncer à leur configuration habituelle ?

C'est là qu'intervient EIP-7702 (Set-EOA-account-code).

Dans le cadre de la prochaine mise à niveau Pectra, EIP-7702 permettra aux EOA de se comporter temporairement comme des SCA en déléguant le contrôle à du code de contrat intelligent qui s'exécute directement depuis leurs adresses. Les utilisateurs n'auront donc pas à migrer vers de nouveaux comptes pour profiter de ces fonctionnalités avancées. Cela garantit la rétrocompatibilité tout en faisant avancer Ethereum.

Malgré ces améliorations, il reste un aspect UX majeur à débloquer pour atteindre pleinement une expérience comparable au web2. Il s'agit de permissions granulaires et flexibles, permettant à l'utilisateur de partager facilement le pouvoir d'effectuer une action spécifique en son nom avec un autre utilisateur. Cela se fait de manière contrôlée, avec des garde-fous stricts et la possibilité de révoquer les permissions en cas de besoin.

C'est le défi que le Delegation Toolkit est conçu pour résoudre. Mais avant de plonger dans ce qu'il est et comment il fonctionne, examinons de plus près les deux ERC qui pilotent cette prochaine phase de l'UX des comptes Ethereum.

ERC 7710 : Délégation de contrats intelligents

ERC-7710 est une proposition visant à standardiser la façon dont les comptes à contrats intelligents délèguent des permissions spécifiques à d'autres comptes Ethereum. Il introduit une interface commune permettant aux délégants d'accorder une autorité aux délégués selon des règles claires et applicables.

Avec ERC-7710, les développeurs peuvent créer des systèmes dans lesquels un compte autorise en toute sécurité un autre à agir en son nom sous certaines conditions, comme des limites de dépenses, des restrictions temporelles ou des permissions spécifiques à une tâche. Tout cela est géré via un flux de délégation sécurisé et prévisible.

Que signifie alors « délégation » dans ce contexte ?

À un niveau élevé, il s'agit de séparer la propriété du compte de son exécution. Un délégant conserve toujours la propriété des actifs ou de la logique, mais peut transférer temporairement ou définitivement des pouvoirs spécifiques à quelqu'un d'autre, sans pour autant céder le contrôle total.

Du point de vue du réseau, ERC-7710 apporte clarté et composabilité à la façon dont les permissions sont transmises entre les comptes. Au lieu que chaque application développe sa propre logique de délégation, nous disposons désormais d'une base commune sur laquelle les contrats et les outils peuvent s'appuyer.

ERC 7715 : Accorder des permissions depuis les wallets

ERC-7715 est une proposition visant à simplifier la façon dont les dapps demandent des permissions aux wallets des utilisateurs. Il introduit un modèle de permissions permettant aux dapps de demander un accès clairement délimité et pré-approuvé au compte d'un utilisateur, sans nécessiter de confirmations répétées pour chaque interaction.

Aujourd'hui, le flux d'interaction typique est maladroit : une dapp demande à envoyer une transaction ou à interagir avec un contrat, et le wallet invite l'utilisateur à approuver chaque fois. Il n'existe aucun moyen de spécifier des limites, des durées ou de restreindre la portée de ce qu'une dapp peut faire, ni de méthode standard permettant aux utilisateurs de consulter ou de révoquer ces approbations ultérieurement.

ERC-7715 change cela. Il introduit une nouvelle méthode, wallet_grantPermissions, qui permet à une dapp de demander des capacités spécifiques à l'avance. Par exemple, elle pourrait demander la permission de dépenser jusqu'à 10 USDC au cours de l'heure suivante, ou d'interagir avec un seul contrat intelligent lors des prochaines sessions. L'utilisateur examine cela en amont et l'approuve ou le rejette en toute clarté.

Du point de vue d'une dapp, cela fluidifie l'onboarding et permet des expériences basées sur des sessions ou automatisées qui n'interrompent pas constamment l'utilisateur. Pour les wallets, cela introduit une structure claire et auditable pour la gestion des permissions et le suivi de ce qui a été accordé. Pour les utilisateurs, cela offre une meilleure visibilité, plus de contrôle et moins de pop-ups intempestifs, le tout sans compromettre la sécurité.

Que peuvent donc créer les développeurs avec ces standards ?

Voici quelques fonctionnalités qui peuvent être débloquées en combinant ERC-7710 et ERC-7715 :

• Définir des limites de dépenses quotidiennes depuis un wallet sécurisé en utilisant ERC-7710 pour déléguer une allocation fixe à un wallet utilisé plus fréquemment, en conservant la majeure partie des fonds hors ligne en toute sécurité.

• Simplifier l'onboarding en permettant aux utilisateurs d'effectuer des actions comme le minting ou la réclamation de récompenses sans configuration préalable du wallet ni approbation de transaction, grâce à des délégations pré-délimitées qui accordent automatiquement des permissions limitées.

• Laisser des agents IA trader en votre nom en attribuant des permissions d'exécution limitées via ERC-7710, ERC-7715 facilitant l'approbation de ces permissions via votre wallet.

• Laisser une dapp couvrir les frais de gas des utilisateurs en attribuant des droits de parrainage à un SCA exploitant la délégation ERC-7710, permettant à des transactions spécifiques d'être traitées sans que l'utilisateur ait besoin d'ETH.

• Révoquer les approbations de tokens en toute sécurité en déléguant la permission à un contrat auxiliaire qui appelle approve(0) en votre nom, en utilisant ERC-7710 pour délimiter strictement ce qu'il peut faire et assurer la compatibilité avec tout token ERC-20 standard.

Et bien plus encore.

Définir le Delegation Toolkit

La façon la plus simple de décrire le Delegation Toolkit est de le présenter comme une suite d'outils comprenant deux packages principaux :

1. Le Delegation Core SDK – Un package qui permet aux développeurs de créer des comptes à contrats intelligents conformes à ERC-4337 (comptes délégants) bénéficiant de toutes les fonctionnalités introduites par l'abstraction de compte ERC-4337.

2. Le Delegation Framework – Un système qui permet aux comptes à contrats intelligents de déléguer des permissions à d'autres comptes Ethereum via le standard ERC-7710, et qui permet aux sites web, aux dapps, ou à terme à n'importe quoi, de demander des permissions à votre compte via ERC-7715 (bientôt disponible).

En termes simples, le Delegation Toolkit permet de créer des dapps prenant en charge les comptes à contrats intelligents (SCA) ERC-4337, de déléguer des permissions à d'autres SCA ou EOA, et de permettre aux dapps de demander ces permissions, que ce soit depuis des comptes intelligents ou, suite à la mise à niveau Pectra, même depuis des EOA.

Si vous connaissez le fonctionnement des comptes à contrats intelligents, vous savez déjà à quoi vous attendre du package Delegation Core VIEM. Sinon, n'hésitez pas à consulter la documentation officielle pour approfondir le sujet. Dans la suite de cet article, nous nous concentrerons sur le Delegation Framework lui-même et mettrons en avant certains des principes clés qui le rendent si puissant.

Délégation hors chaîne

Les délégations n'ont pas besoin d'exister on-chain pour être valides. Une fois que le Compte A a signé une délégation pour le Compte B, celle-ci peut être stockée n'importe où — IPFS, cache du navigateur, stockage cloud, ou même téléchargée localement — car elle est cryptographiquement sécurisée et uniquement utilisable par le délégué prévu. Cela rend l'ensemble du système plus évolutif et flexible.

Par exemple, B peut récupérer la délégation signée lorsque nécessaire et l'utiliser dans une transaction sans nécessiter de stockage on-chain ni de frais de gas initiaux.

Permissions révocables

Les délégations ne sont pas permanentes. Le délégant d'origine, disons le Compte A, peut révoquer toute délégation active qu'il a émise, même si cette délégation a déjà été transmise via une délégation transitive (voir la section sur la délégation transitive ou en chaîne ci-dessous). Une fois révoquée, le gestionnaire de délégation rejettera toute tentative de la faire valoir, y compris toutes les sous-délégations qui en dépendent. C'est essentiel pour la sécurité.

Si le Compte A soupçonne une compromission ou souhaite mettre à jour les permissions, il peut immédiatement couper l'accès, rendant l'ensemble de la chaîne de confiance invalide. C'est comme pouvoir couper le courant à tout moment sans avoir à retrouver toutes les personnes impliquées.

Délégations délimitées

Avec le Delegation Toolkit, les délégations sont généralement délimitées à un délégué spécifique. Cela signifie que si le Compte A signe une délégation pour le Compte B, seul B peut la faire valoir. Même si quelqu'un d'autre obtient la délégation signée, elle lui est inutile car elle est cryptographiquement liée à B.

Il existe cependant une prise en charge des délégations ouvertes. Ce sont des délégations qui ne spécifient pas de délégué à l'avance et peuvent être utilisées par n'importe quel compte. Les délégations ouvertes sont utiles lorsque vous ne savez pas encore qui sera le délégué, mais elles doivent être utilisées avec prudence pour éviter les abus. Vous pouvez en créer une en définissant le champ delegate sur la constante spéciale ANY_BENEFICIARY (0x0000000000000000000000000000000000000a11).

Si le Compte B souhaite ensuite transmettre une permission délimitée au Compte C, il doit explicitement créer une nouvelle délégation de B à C. Cela garantit que les limites des permissions restent claires et intentionnelles, même lors de l'utilisation de flux ouverts ou transitifs.

Caveats

Les caveats sont les règles qui définissent comment une délégation peut être utilisée. Considérez-les comme des conditions personnalisées que le délégant peut associer à une délégation. Par exemple, si le Compte A délègue au Compte B, il peut inclure un caveat stipulant que B ne peut transférer que jusqu'à 1 ETH ou interagir uniquement avec un contrat spécifique dans les 24 prochaines heures.

Les caveats sont appliqués à l'exécution à l'aide de contrats spéciaux appelés caveat enforcers, qui vérifient que les règles sont respectées avant qu'une action soit exécutée. Ainsi, même si B a le droit d'agir, il opère toujours dans un cadre bien défini établi par A. Consultez ici la liste complète des caveats pris en charge ou apprenez à créer votre propre caveat personnalisé.

Délégation transitive ou en chaîne

L'une des fonctionnalités les plus puissantes du Delegation Framework est que la délégation n'a pas à s'arrêter à un seul transfert. Avec la délégation transitive, un compte qui reçoit une permission — disons le Compte B — peut à son tour déléguer tout ou partie de cette autorité à un autre compte, formant ainsi une chaîne de délégations provenant d'un seul compte.

Chaque maillon de la chaîne est signé cryptographiquement et délimité par ses propres caveats, ce qui signifie que les permissions peuvent être réduites ou redéfinies à chaque niveau. En d'autres termes, ces sous-délégations peuvent être un sous-ensemble de l'original, avec des contraintes plus strictes ou des capacités limitées.

Il est important de noter que le délégant d'origine conserve toujours le contrôle total et peut révoquer la délégation initiale à tout moment, ce qui invalide automatiquement toutes les délégations en aval dans la chaîne, créant ainsi une chaîne de confiance flexible mais sécurisée, idéale pour des configurations de permissions complexes comme les DAO et les wallets partagés.

Quelle est la suite ?

Le Delegation Toolkit vous donne les outils nécessaires pour apporter des systèmes de permissions plus sûrs, plus intelligents et plus flexibles à vos dapps. Que vous cherchiez à activer les dépenses déléguées, les parrainages de gas, les workflows automatisés ou un onboarding fluide, tout cela est désormais possible sans réinventer la roue.

Dans les prochains articles, nous passerons à la pratique, en commençant par un tutoriel sur la création d'une fonctionnalité « Inviter un ami », un exemple concret de délégation en action. Restez à l'écoute pour la suite de la série, où nous aborderons d'autres fonctionnalités que vous pouvez implémenter dès aujourd'hui.

Si vous souhaitez explorer ces idées plus en détail, gardez un œil sur le prochain Gator Hackathon d'avril, où vous aurez l'occasion de créer avec le Delegation Toolkit aux côtés d'autres développeurs.