Auteur : Institut de recherche CoinW
Résumé
Avec le développement d'applications telles que DeFi, l'abstraction des comptes et les agents IA, l'autorisation sur la chaîne évolue progressivement d'une simple signature unique vers une autorité exécutive réutilisable et à long terme. En parallèle, de nouveaux changements se produisent : les agents IA commencent à être capables de demander automatiquement des services et de réaliser automatiquement des paiements. Par exemple, le protocole x402 utilise le code d'état HTTP 402 pour permettre aux agents de payer instantanément des ressources et des services en stablecoin sans intervention humaine. Cela rend les actions sur la chaîne non plus des transactions isolées, mais un processus continu de collaboration automatisée.
Dans ce contexte, les questions d'autorisation sont encore plus accentuées. Les méthodes d'autorisation actuelles dans le système Web3 restent encore floues dans leurs limites et grossières dans leur expression, résolvant souvent uniquement la question de savoir si un actif peut être utilisé ou non, sans pouvoir répondre précisément à ce qui est autorisé et dans quelle mesure. Le ERC-8004 a justement été proposé dans ce contexte. Il ne définit pas de nouveaux actifs, ni ne modifie la manière dont les transactions ou les paiements sont exécutés, mais il tente plutôt d'établir un modèle de permissions pouvant être compris et vérifié par le système pour les actions sur la chaîne, permettant ainsi à l'autorisation elle-même de devenir un objet décrivable, contrôlable et gérable.
D'un point de vue systémique plus large, l'ERC-8004 ne se situe pas en concurrence avec des protocoles automatisés de paiement tels que l'abstraction de compte et x402, mais plutôt à différents niveaux de division et de coopération : x402 résout le problème d'échange de valeur après qu'une action a eu lieu, tandis que l'ERC-8004 se concentre sur ce qui se passe avant l'action, à savoir qui est autorisé à agir et si les autorisations sont dépassées. Dans des scénarios tels que les DeFi, les agents d'IA, ainsi que les entreprises et les actifs réels numérisés (RWA), cette structure où les autorisations précèdent les paiements pourrait permettre de faire passer l'autorisation du niveau des actifs au niveau des actions, offrant ainsi une base contrôlable pour des collaborations automatisées plus complexes et à long terme. Bien qu'il rencontre encore des défis concrets en matière de coût d'apprentissage, de prise en charge des portefeuilles et d'expérience utilisateur, l'ERC-8004 n'est pas un outil narratif à court terme, mais plutôt un standard fondamental sur lequel repose la capacité du Web3 à supporter le fonctionnement de systèmes complexes.
1. Motivation der Einreichung von ERC-8004
Alors que l'infrastructure sur la chaîne continue d'évoluer, les capacités liées à l'enregistrement des actifs sur la chaîne et à l'exécution des transactions sont constamment abstraites et renforcées. Des ERC-20, des NFT, aux portefeuilles multisignatures et à l'abstraction des comptes (ERC-4337), le seuil d'entrée pour les utilisateurs souhaitant participer aux activités sur la chaîne diminue constamment, et les comptes eux-mêmes deviennent de plus en plus intelligents.
Mais au cours de ce processus, une question fondamentale n’a toujours pas été résolue de manière systématique : le mécanisme d’autorisation lui-même n’a connu que peu d’évolutions substantielles. Dans le Web3 initial, l’autorisation signifiait une signature unique avec une clé privée. Les utilisateurs exprimaient leur accord par une signature, qu’il s’agisse d’un transfert, d’un appel de contrat ou d’une opération approve. L’autorisation était perçue comme une confirmation unique, et les limites des risques incombaient entièrement à l’utilisateur.
Cependant, l'environnement sur la chaîne aujourd'hui a changé. Dans le contexte de la finance décentralisée (DeFi), l'autorisation est souvent valable sur une longue période ; sous les systèmes de stratégies automatisées et de clés de session, l'autorisation est réutilisée de manière répétée ; dans les modèles où les agents IA ou les bots exécutent des transactions, les utilisateurs ne participent même plus directement à chaque opération. L'autorisation évolue d'une confirmation ponctuelle vers une capacité d'exécution continue, ressemblant davantage à céder le pouvoir d'agir pendant une certaine période.
Le problème réside dans le fait que l'infrastructure actuelle de Web3 ne fournit presque pas de moyen clair et uniforme pour imposer des états d'autorisation à long terme. La portée floue des autorisations, la difficulté de révocation et les risques imprévisibles constituent la source de nombreux incidents de sécurité. En parallèle, l'abstraction des comptes accentue davantage cette contradiction : lorsque les comptes peuvent exécuter automatiquement des transactions et que des tiers paient le Gas à leur place, ce qu'ils peuvent ou ne peuvent pas faire devient encore plus incertain.
C'est dans ce contexte que l'ERC-8004 a été proposé. Il tente de combler un maillon manquant depuis longtemps dans le Web3 : établir un modèle clair, contraignant et compréhensible par le système pour l'autorisation elle-même.
2. Contenu principal de l'ERC-8004
Le point d'entrée de l'ERC-8004 ne réside pas dans la forme des actifs ou dans la manière d'exécuter les transactions, mais dans le fait que les autorisations puissent être décrites de manière individuelle, vérifiées de façon indépendante et gérées de manière continue au niveau du système.
2.1 Qu'est-ce que ERC-8004 définit ?
Selon la définition du site officiel des Ethereum Improvement Proposals (EIP) : l'ERC-8004 est un protocole standard utilisé pour découvrir, sélectionner et interagir avec des agents autonomes fiables sur Ethereum. Il construit une infrastructure d'agents permettant des interactions décentralisées sans nécessiter de confiance préalable, grâce à un enregistrement sur la chaîne, à un mécanisme de réputation et à des mécanismes de vérification.
Les agents autonomes ici ne sont pas limités aux agents IA, mais désignent tout sujet pouvant être autorisé et agir de manière indépendante, tels que des contrats, des scripts automatisés, des signatures multiples ou des processus de service. L'ERC-8004 se concentre sur la capacité des sujets exécutants à disposer d'une autorisation claire et d'une limite de pouvoir définie, et l'agent IA n'en est qu'une application typique.
D'un point de vue plus général, l'ERC-8004 n'est pas un nouveau standard d'actif ou un nouveau type de compte, mais un cadre d'expression et de vérification des autorisations sur la chaîne, utilisé pour décrire quelles actions un sujet est autorisé à effectuer sous quelles conditions, et pour effectuer une vérification avant l'opération. Ainsi, l'ERC-8004 se concentre non pas sur « ce qu'est l'argent » ou « comment les transactions sont exécutées », mais sur « quelles actions sont autorisées ». Il ne crée pas de nouveaux actifs ni ne modifie les propriétés des actifs existants, mais ajoute simplement une couche claire et vérifiable de règles d'autorisation au-dessus des actifs et des comptes.
De plus, ERC-8004 n'est pas une alternative à l'abstraction de compte (ERC-4337). L'abstraction de compte se concentre sur la manière dont les transactions sont exécutées, tandis qu'ERC-8004 résout la question de la détermination des autorisations avant qu'une transaction ne se produise. Si l'abstraction de compte rend les comptes plus flexibles, ERC-8004 établit des limites claires à cette flexibilité.
Le cœur de l'ERC-8004 réside dans le fait de transférer l'autorisation d'une action implicite dans la signature, vers un objet de permission clairement décrit, pouvant être vérifié de manière indépendante et géré de manière continue.
2.2 Cadre mécanique central de l'ERC-8004
Pour comprendre le mécanisme central de l'ERC-8004, on peut d'abord ignorer l'implémentation technique complexe et le considérer comme un "manuel des autorisations sur la chaîne". Dans la logique d'autorisation traditionnelle, les utilisateurs prennent souvent une décision générale : « J'accepte que vous manipuliez mes actifs. » En ce qui concerne ce qu'ils peuvent exactement faire, dans quelle mesure et pendant combien de temps, le système ne fait pas de distinction supplémentaire. Dans le cadre de l'ERC-8004, une autorisation n'est plus un accord vague, mais est décomposée en un ensemble de règles clairement décrits et exécutés de manière obligatoire par le système. Ce « manuel des autorisations » comprend généralement cinq types d'informations clés.
Sujet autorisé (Qui) : Qui est autorisé à exécuter ?
Il est d'abord essentiel de clarifier à qui les pouvoirs d'exécution sont octroyés. Dans l'ERC-8004, l'objet autorisé ne se limite plus à une adresse de portefeuille fixe, mais peut également être un contrat, un agent automatisé, voire une clé de session destinée à des opérations à court terme. Cela permet aux autorisations d'être adaptées à davantage de scénarios complexes, tels que permettre à un contrat de stratégie d'effectuer des opérations dans un périmètre limité, ou permettre à un agent d'accomplir des tâches spécifiques sans avoir à signer répétitivement. Il est important de noter que les droits sont toujours octroyés à « un sujet clairement identifié », et non pas confiés de manière floue.
Comportement exécutable (What) : Quelles opérations sont autorisées ?
Deuxièmement, il s'agit de savoir quels comportements sont autorisés. L'autorisation traditionnelle est souvent tout ou rien : une fois accordée, elle permet par défaut à un contrat d'agir librement dans les limites des autorisations reçues. Dans la conception de l'ERC-8004, les autorisations peuvent être précises au type d'action, par exemple, permettre uniquement l'exécution de swap, de transfer, ou d'un type particulier d'appel de fonction, au lieu d'autoriser par défaut toutes les opérations possibles. L'ERC-8004 répond non pas à la question de savoir si l'on peut ou non utiliser, mais à celle de savoir jusqu'où l'on peut aller dans l'utilisation.
Contraintes (Sous quelles conditions) : Sous quelles conditions peut-on exécuter ?
C'est la partie clé qui distingue l'ERC-8004 des autorisations traditionnelles. Dans les documents de permissions, les autorisations sont généralement accompagnées de restrictions explicites, par exemple : un plafond d'un montant unique ou cumulé ; des limites de fréquence ou de nombre d'exécutions ; ou encore une application uniquement à des protocoles, des pools ou des adresses de contrats spécifiques. Ces conditions ne sont pas des règles de surveillance a posteriori, mais des conditions préalables qui doivent être remplies avant l'exécution. Dès lors que ces conditions ne sont pas remplies, l'opération elle-même ne peut pas être exécutée.
Règles d'effet et de fin (When) : Quand les autorisations prennent-elles effet et quand prennent-elles fin ?
L'ERC-8004 introduit également des concepts clairs de temps et de cycle de vie. Les autorisations peuvent être configurées de la manière suivante : (a) valables uniquement pendant une période spécifique ; (b) expirant automatiquement après une utilisation unique ; (c) révocables à tout moment. Cela rend l'autorisation non plus un fardeau à long terme irrécupérable, mais une capacité temporaire pouvant être gérée avec précision.
Mode de vérification (How enforced) : Comment les règles sont-elles réellement appliquées ?
Enfin, et c'est souvent le point le plus négligé : comment ces règles sont-elles appliquées. L'idée centrale d'ERC-8004 est de vérifier les autorisations avant qu'une opération ne se produise. Si un comportement ne respecte pas les règles d'autorisation définies à l'avance, le système refusera directement son exécution, plutôt que de rechercher des responsabilités après que le problème se soit produit. C'est précisément là la différence fondamentale entre ERC-8004 et la logique traditionnelle de contrôle des risques.
2.3 Nouveau type de capacité avec ERC-8004 : pourquoi cela n'était pas possible avant ?
À première vue, ERC-8004 n'affine que la gestion des autorisations, mais le modèle d'autorisation initial d'Ethereum ne pouvait en réalité pas exprimer une logique d'autorisation complexe. L'autorisation traditionnelle ne vérifie qu'une adresse est autorisée à effectuer une opération ou non, et une fois l'autorisation accordée, ce que l'on peut faire, combien, et à quel moment, ne peuvent pas être reconnus par le système.
La percée centrale de l'ERC-8004 réside dans le passage de l'autorisation basée sur « l'identification de l'identité » à celle basée sur « l'analyse des actions ». Le système commence à évaluer si une opération est conforme aux limites de permissions définies par l'utilisateur, au-delà de simplement confirmer qui a initié l'action. Cela permet à l'autorisation d'inclure naturellement des conditions telles que le montant, la fréquence, l'étendue et la durée de validité, sans dépendre de l'annulation manuelle ultérieure ou d'une surveillance humaine.
Lorsque la logique d'autorisation est structurée, elle acquiert pour la première fois la capacité d'être composable et réutilisable. Les opérations à plusieurs étapes et transversales aux protocoles peuvent être clairement limitées à l'étape d'autorisation, plutôt que laissées à une évaluation temporaire au moment de l'exécution. C'est précisément pour cette raison que l'ERC-8004 ouvre véritablement des possibilités pour les scénarios d'agents. Les programmes automatisés n'ont plus besoin d'une "autorisation illimitée", mais sont restreints à un ensemble clair et vérifiable d'actions, et toute tentative de franchir ces limites est refusée.
Le ERC-8004 n'ajoute pas simplement une « autorisation plus sécurisée », mais rend la logique d'autorisation compréhensible et exécutable par le système, ce qui en constitue la différence essentielle avec les mécanismes d'autorisation traditionnels.
3. Applications potentielles de l'ERC-8004
L'ERC-8004 n'est pas un standard conçu pour un produit spécifique, il ressemble davantage à une langue commune pour une capacité d'autorisation. Ainsi, sa valeur d'application ne se manifeste pas dans une explosion ponctuelle d'un seul scénario, mais dans la demande commune de la même capacité, lorsque plusieurs systèmes, après une complexification de l'autorisation, ont besoin de cette même capacité.
DeFi : du « décentralisation au niveau des actifs » vers la « décentralisation au niveau des actions »
Dans le système actuel de DeFi, la méthode d'autorisation la plus courante reste l'autorisation unique à montant illimité. Par exemple, pour effectuer un swap, un prêt ou un dépôt de garantie, l'utilisateur doit d'abord approuver le contrat, ce qui revient fondamentalement à céder l'ensemble du contrôle sur ses actifs. Cela est très efficace en termes d'expérience utilisateur, mais comporte aussi un risque évident : une fois qu'un contrat est mis à jour, attaqué, ou utilisé dans un contexte logique non prévu par l'utilisateur, l'autorisation elle-même devient un amplificateur de risque. L'autorisation ERC-8004 ne concerne plus les actifs, mais plutôt des actions spécifiques. Par exemple, l'utilisateur peut exiger : ce n'est pas que je permette à ce contrat d'utiliser indéfiniment mes USDC, mais plutôt que je lui permette d'utiliser au maximum 1 000 USDC pendant 24 heures, pour effectuer une seule opération de swap. Bien que certains projets aient déjà tenté de limiter la portée et la durée des autorisations, ces initiatives restent pour l'essentiel isolées. La valeur de l'ERC-8004 réside dans la normalisation des autorisations au niveau des actions, permettant une gestion des autorisations réutilisable et combinable, et améliorant ainsi fondamentalement la capacité de contrôle des risques.
Agent IA : Fournir des limites d'autorisation vérifiables pour l'exécution automatisée
Alors que les agents d'IA participent progressivement aux décisions et exécutions sur la chaîne, les questions d'autorisation sont amplifiées à un nouveau niveau. La valeur des agents réside dans leur fonctionnement continu et leur exécution automatique, mais cela signifie aussi qu'ils doivent détenir un certain niveau de privilèges opérationnels sur une longue période. Si les limites des autorisations ne sont pas claires, l'agent n'est en réalité qu'un programme automatisé sous le contrôle complet de l'utilisateur, et les risques ne diminuent pas pour autant en raison de l'« intelligence ». L'ERC-8004 fournit aux agents une limite d'autorisation vérifiable au niveau du système. Quels opérations peuvent être autorisées à l'agent, dans quel périmètre il peut agir, s'il existe des restrictions temporelles, ces règles peuvent être vérifiées avant l'exécution, plutôt que de dépendre d'une surveillance a posteriori. Seule une autorisation structurée et vérifiable permet de poser les bases d'une exécution automatisée fiable.
Collaboration avec le protocole x402 : rendre le comportement des agents "autorisable et facturable"
Dans le contexte des agents, un autre problème clé en dehors de l'autorisation est le suivant : une fois qu'un comportement est autorisé, comment la valeur est-elle échangée. Certains protocoles de couche d'application tentent de résoudre ce problème. Par exemple, le protocole x402 réactive le code d'état HTTP 402 (Paiement requis), permettant aux agents d'accomplir automatiquement des paiements en stablecoin lorsqu'ils demandent des ressources ou des services. Dans cette architecture, ERC-8004 et x402 se situent à des niveaux différents, mais forment une relation complémentaire. ERC-8004 se concentre sur « qui peut faire quoi, et s'il est autorisé », établissant des limites de permissions et de confiance pour les comportements ; x402 résout la question de « comment effectuer le paiement et le règlement lorsqu'un comportement se produit ». Le premier ne dépend pas du second pour fonctionner, et le second ne repose pas sur ERC-8004 comme prérequis. Cependant, dans l'économie des agents, les deux assument respectivement les rôles de couche d'autorisation et de couche de paiement. Cette collaboration en couches permet aux agents d'accomplir, sans intervention humaine, l'ensemble du processus allant de la vérification des autorisations à l'échange de valeur, tout en évitant la complexité liée à la combinaison de la gestion de l'identité, des autorisations et des logiques de paiement au sein d'un même système. Alors que l'activité des agents augmente dans des scénarios tels que l'accès au contenu, l'appel de données et les services de calcul, ce type de combinaison devient progressivement une forme d'infrastructure évolutive prometteuse.
Entreprise et scénario RWA : les autorisations comme expression fondamentale de la conformité
Dans les applications d'entreprise et les scénarios de RWA (actifs du monde réel), la valeur de l'ERC-8004 se manifeste davantage en matière de conformité et d'explicabilité. La gestion d'actifs dans le monde réel nécessite souvent des réponses claires à la question suivante : qui a été autorisé à effectuer quels actes, sous quelles conditions. Comparativement à savoir si l'actif lui-même est enregistré sur la chaîne, la manière dont les autorisations sont définies et enregistrées constitue en revanche la clé pour intégrer le système financier réel. L'ERC-8004 ne résout pas directement les problèmes de conformité, mais il fournit un soutien fondamental pour l'expression structurée des autorisations, rendant naturellement possible l'audit, le suivi et la vérification de ces dernières. Cette capacité ne changera pas immédiatement l'expérience utilisateur, mais elle réduira considérablement les coûts d'intégration entre les systèmes Web3 et les organisations traditionnelles.
À partir de ces applications potentielles, on peut voir que l'ERC-8004 n'est pas un standard "drivé par des scénarios", mais plutôt une capacité fondamentale qui émerge naturellement lorsque la complexité de l'autorisation augmente. Lorsque les comportements sur la chaîne évoluent d'une simple opération ponctuelle vers des comportements systémiques à long terme, un mode d'expression clair et vérifiable des autorisations devient presque une option incontournable.
4. Défis et valeur à long terme de l'ERC-8004
Défis réels
D'abord, il y a le coût d'apprentissage. Comparé à l'autorisation simple d'un clic, l'ERC-8004 introduit une logique de description des autorisations plus fine. Que ce soit pour les développeurs ou les utilisateurs, il faudra réapprendre à comprendre ce que signifie l'autorisation au sein du système. Ce coût cognitif nécessitera un certain temps d'absorption par le marché. Ensuite, il y a le soutien des portefeuilles et des infrastructures. Les capacités de l'ERC-8004 ne peuvent pleinement s'exprimer que si les portefeuilles, les SDK et les environnements d'exécution les comprennent et les prennent en charge. À ses débuts, il s'agit davantage d'une capacité utilisable mais non universelle, difficile de générer immédiatement un effet d'échelle. Enfin, il y a l'expérience utilisateur. Si les autorisations complexes sont exposées directement aux utilisateurs, cela n'augmentera que la charge opérationnelle. Comment transformer un ensemble de règles structurées et vérifiables par machine en une interface intuitive et acceptée par les utilisateurs ordinaires, déterminera directement si l'ERC-8004 a la possibilité de s'implanter à grande échelle.
ERC-4008 ne résout pas le présent, mais la prochaine phase
En raison de ces barrières réelles, l'ERC-8004 n'est pas adapté en tant qu'outil narratif à court terme. Il n'entraînera pas immédiatement une explosion du nombre d'utilisateurs, ni ne génère directement de nouveaux modèles de revenus. L'ERC-8004 ne cherche pas à rendre le monde plus rapide, mais à maintenir le système contrôlable, explicable et vérifiable même après sa complexification. Sa valeur ne réside pas dans le nombre de fonctionnalités, mais dans le fait qu'il prévoie ou non une base de permissions évolutives et durables pour l'automatisation future, la collaboration entre agents et la participation institutionnelle. En ce sens, l'ERC-8004 n'est pas un standard né pour un cycle particulier, mais l'une des capacités fondamentales déterminant si le Web3 pourra supporter des relations collaboratives complexes.