Introduction

EIP-7702 permet aux portefeuilles Ethereum simples (EOAs) de se mettre à niveau en portefeuilles de contrats intelligents, qui offrent une sécurité améliorée, des fonctionnalités avancées, la possibilité de parrainage de gaz et d'autres avantages. Historiquement, les portefeuilles intelligents devaient être créés à partir de zéro, mais avec l'introduction de l'EIP-7702, les portefeuilles traditionnels, avec tous leurs actifs et leur historique onchain, peuvent se mettre à niveau et conserver la même adresse de portefeuille. C'est comme passer d'un téléphone fixe à un smartphone sans avoir à obtenir un nouveau numéro.

Les EOAs se mettent à jour en définissant une "désignation de délégation", un pointeur vers un contrat intelligent deleGate, dont la logique gouverne ensuite l'EOA. Les EOAs mis à jour peuvent donc avoir des fonctions, définir un stockage, émettre des événements et faire tout ce qu'un contrat intelligent peut faire. Les EOAs peuvent changer ou supprimer cette délégation à tout moment avec une nouvelle autorisation EIP-7702 signée. Bien que cela ouvre de nombreuses nouvelles possibilités, cette fonctionnalité puissante introduit également de nouveaux défis en matière de sécurité qui nécessitent une attention particulière et des solutions innovantes.

Pour permettre aux EOA d'agir en tant que portefeuilles de contrats intelligents, nous avons développé le EIP7702Proxy, un légerproxy ERC-1967contrat conçu pour servir de deleGate EIP-7702 pour un EOA. En plus du transfert logique de base effectué par un proxy, le EIP7702Proxy contient des fonctionnalités supplémentaires et des choix de conception qui résolvent plusieurs problèmes uniques aux comptes délégués EIP-7702. Un objectif dans la conception du EIP7702Proxy était d'assurer la parité la plus proche possible entre les Portefeuilles Intelligents Coinbase « standard-deploy » et les Portefeuilles Intelligents Coinbase délégués EIP-7702, ce qui signifiait abstraire la complexité supplémentaire exigée par la mécanique de l'EIP-7702 dans le proxy dédié et continuer à s'appuyer sur l'implémentation originale du CoinbaseSmartWallet. La solution à ce défi peut être utilement appliquée à toute logique d'implémentation, pas seulement à l'implémentation du CoinbaseSmartWallet, tout en aidant les EOAs à rester en sécurité dans un environnement activé 7702.

Nous décrivons ci-dessous les défis spécifiques et les solutions de conception correspondantes qui nous permettent d'adapter en toute sécurité toute mise en œuvre de portefeuille de contrat intelligent existante pour être utilisée pour les mises à niveau EIP-7702.

Défi n°1 : Renforcer une initialisation sécurisée

Le premier obstacle majeur à la mise en œuvre de l'EIP-7702 découle de ses contraintes d'initialisation. Les portefeuilles de contrats intelligents traditionnels, y compris le CoinbaseSmartWallet, gèrent généralement l'initialisation sécurisée (l'établissement de la propriété du compte) de manière atomique lors de leur déploiement via un contrat de fabrique séparé. Cette atomicité signifie que de nombreuses mises en œuvre de ce type ont des fonctions d'initialisation non protégées qui peuvent être appelées exactement une fois. Cependant, la conception de l'EIP-7702 ne permet pas l'exécution des données d'initialisation pendant le processus de délégation de code (l'étape comparable au "déploiement") et, par conséquent, cela ne peut pas être fait de manière atomique.

Cette séparation des étapes crée une fenêtre de vulnérabilité critique. Lorsqu'un contrat d'implémentation est « déployé » vers un EOA via EIP-7702, il n'y a aucune garantie que cette mise à niveau 7702 et la transaction EVM standard qui initialise le portefeuille seront exécutées de manière atomique. Le code définissant l'autorisation pourrait techniquement être appliqué indépendamment de la transaction d'initialisation, même s'ils sont soumis simultanément, et cela pourrait permettre à un attaquant de devancer la transaction d'initialisation avec son propre payload et de revendiquer la propriété du compte intelligent.

Solution : Exiger la signature EOA pour définir de manière atomique l'implémentation et l'initialiser.

Notez que les portefeuilles intelligents Coinbase existants sont déployés derrière unproxy ERC-1967 avec un UUPSUpgradeablel'implémentation (la logique réelle de CoinbaseSmartWallet). Le code à l'adresse du compte réel est un proxy, et le proxy utilise un emplacement de stockage conventionnel défini par l'ERC-1967 pour conserver un pointeur vers sa logique d'implémentation. Notre solution à la vulnérabilité d'initialisation dans un contexte 7702 consiste à reconnaître que toute logique d'implémentation ne devient active (et donc dangereuse) que lorsque le proxy établit effectivement une connexion avec elle. Par conséquent, si nous ne pouvons pas imposer un déploiement atomique avec initialisation, nous pouvons plutôt imposer un réglage d'implémentation atomique avec initialisation.

Architecture du contrat CoinbaseSmartWallet EIP-7702 et flux de délégation logique

Dans le contexte de l'EIP-7702, l'EOA lui-même est l'autorité initiale sur tout changement apporté à son compte, et doit fournir une signature pour autoriser l'initialisation et établir tout propriétaire du nouveau compte intelligent. Notre contrat EIP7702Proxy implémente une fonction setImplementation qui peut définir de manière atomique la nouvelle implémentation logique et initialiser le compte. La fonction setImplementation :

1. Valide une signature de l'EOA sur des données clés telles que l'adresse du nouveau contrat d'implémentation, les données d'initialisation, l'adresse d'un contrat de validation qui évaluera la sécurité de l'état du compte résultant, et des protections de base contre la rejouabilité de la signature telles qu'un nonce et une date d'expiration.
2. Définit la valeur du pointeur ERC-1967 vers la nouvelle implémentation et exécute les données d'appel fournies contre la nouvelle implémentation logique.
3. Fait un appel à la fonction validateAccountState qui doit être implémentée par le validateur inclus dans la signature.

Le validateur est un contrat spécifique à l'implémentation qui contient une logique pour évaluer s'il considère que l'état du compte résultant est sécurisé. Par exemple, dans le cas du CoinbaseSmartWallet, le CoinbaseSmartWalletValidator vérifiera si l'état de propriété du compte est non vide, et n'est donc plus susceptible d'initialisation arbitraire.

Défi n°2 : Stockage partagé entre les délégués EIP-7702

Peut-être que le défi le plus complexe de l'EIP-7702 concerne la gestion du stockage. L'EOA peut librement redéléguer sa logique à différents contrats, ou supprimer complètement la délégation à tout moment. Tous les délégués partagent le même espace de stockage à l'adresse EOA. Plusieurs contrats partageant l'accès au même stockage au fil du temps peuvent entraîner un problème de "collision de stockage". Les collisions de stockage se produisent lorsque deux contrats apportent des modifications différentes ou font des hypothèses différentes sur le même emplacement de stockage, ce qui peut potentiellement entraîner des bogues imprévisibles.

La gestion des collisions de stockage est déjà un problème familier dans l'espace de conception des proxys, où une logique d'implémentation mutable est utilisée pour régir le stockage partagé. Même si les proxys évolutifs peuvent changer d'implémentations, le code du proxy lui-même (pour les adresses non-7702) ne peut pas changer. Cela apporte certitude et garanties au processus de mise à niveau. La re-délégation 7702 introduit une autre couche de mutabilité totale à la logique potentielle qui peut régir ce stockage partagé. Cela supprime essentiellement toutes les garanties concernant l'effet qu'un délégataire arbitraire peut avoir sur le stockage. Par exemple, si un EOA délégue de A à B et revient à A, le délégataire de retour ne peut pas faire d'assumptions sur l'état de son stockage, qui peut avoir été effacé ou manipulé par le délégataire B dans un état qui aurait été impossible à atteindre uniquement par la logique du délégataire A. Cela est vrai pour tout délégataire 7702, quelle que soit le modèle de délégation, car un délégataire précédent peut avoir stocké ou supprimé n'importe quoi dans n'importe quel emplacement de stockage.

Exemple d'un état invalide pour DeleGate A induit par le modèle de délégation A → B → A

Solution : Externalisation des valeurs de stockage critiques pour la sécurité

La délégation EOA peut affecter arbitrairement l'état du compte. Si un EOA délègue à un contrat malveillant ou destructeur, aucun délégataire en place ne peut protéger contre cela. Comme la signature d'une transaction de vidage, autoriser des délégataires 7702 malveillants pourrait être désastreux, et se protéger contre ces résultats est en dehors de notre portée de conception.

Nous avons conçu le EIP7702Proxy pour être auto-défensif contre les problèmes prévisibles dans un écosystème multi-portefeuille, activé 7702, composé d'acteurs bien intentionnés mais potentiellement chaotiques. Il ne peut pas protéger les EOA qui autorisent des deleGates vraiment malveillants ou bogués.

Un problème prévisible concerne les signatures pour les appels setImplementation et les risques introduits par l'état mutable du compte. Le EIP7702Proxy s'appuie sur les signatures EOA pour définir la logique d'implémentation et initialiser à un état sûr. Ces signatures pourraient devenir des responsabilités si elles étaient un jour reproductibles. Par exemple, si une signature autorise un propriétaire initial qui est ensuite compromis et retiré, une signature reproductible pourrait rétablir le propriétaire compromis ou rétrograder de force l'implémentation.

La protection commune contre la rejoue de signature utilise des nonces dans les messages signés, marqués comme consommés lorsqu'ils sont vérifiés. Le risque pour les comptes 7702 : d'autres délégataires pourraient compromettre ce stockage de suivi de nonce. Si le stockage du suivi de l'utilisation des nonces est effacé, la signature setImplementation de l'EOA (disponible publiquement dans le mempool) pourrait être réappliquée lors de la délégation vers le EIP7702Proxy.

Pour garantir la non-rejouabilité des signatures, nous avons mis en œuvre un singleton NonceTracker séparé qui maintient le statut des nonces dans un emplacement de contrat immuable en dehors du stockage du compte. Seul l'EOA peut affecter ses nonces (uniquement de manière incrémentale), empêchant ainsi d'autres délégataires de manipuler ces valeurs critiques pour la sécurité. Le NonceTracker garantit que chaque signature setImplementation ne fonctionne qu'une seule fois, quel que soit le changement de stockage du compte.

Défi n°3 : Risque accru des emplacements de stockage conventionnels partagés

Des emplacements de stockage standardisés comme ceux définis par ERC-1967sont particulièrement vulnérables aux collisions de stockage potentielles en raison de leur nature de lieux conventionnels susceptibles d'être utilisés par plusieurs implémentations de deleGate. L'emplacement de stockage d'ERC-1967 est le seul emplacement de stockage standard utilisé dans le EIP7702Proxy et il contient l'adresse de l'implémentation logique pointée par le proxy. Notre conception garantit que, indépendamment de la valeur à cet emplacement de stockage (qui détermine une grande partie de la logique disponible au compte), le EIP7702Proxy sera toujours capable de définir avec succès sa logique d'implémentation sur un contrat souhaité par l'EOA.

Pour illustrer plus clairement le problème résolu, notez que lorsqu'un compte passe d'un délégataire à un autre (A→B→A) où les deux délégataires mettent en œuvre des modèles de proxy ERC-1967, le délégataire B utilisera naturellement le même emplacement de stockage que le délégataire A utilisait pour stocker son adresse d'implémentation. Pendant son mandat, le délégataire B pourrait modifier ou écraser cet emplacement, soit intentionnellement, soit comme une partie normale de ses propres opérations de proxy. Dans un modèle de proxy UUPSUpgradeable, la logique de mise à niveau d'une implémentation est définie sur le contrat d'implémentation lui-même. Si l'implémentation mise en place à cet emplacement par le délégataire B ne contient pas l'interface upgradeToAndCall attendue sur une implémentation, alors, lors du retour au délégataire A, le mécanisme même pour changer son implémentation peut ne pas exister sur la logique actuellement disponible.

Exemple de remplacement d'un emplacement de stockage conventionnel partagé par un nouveau deleGate

Solution : Mécanisme de mise à niveau disponible sur le EIP7702Proxy

Notre EIP7702Proxy aborde cela grâce à sa fonction setImplementation, qui fournit un mécanisme de mise à niveau indépendant de l'implémentation directement sur le proxy lui-même. Cela garantit que même si un deleGate intermédiaire a pointé l'implémentation ERC-1967 vers une implémentation invalide (ou l'a complètement supprimée), l'EOA d'origine, après avoir délégué à nouveau vers un EIP7702Proxy, conserve la capacité de reconfigurer le pointeur ERC-1967 du proxy vers leur implémentation logique choisie.

Défi n°4 : Compatibilité ascendante avec le comportement standard EOA

Un objectif de conception du EIP7702Proxy était de maintenir la compatibilité ascendante avec la fonctionnalité EOA du compte en plus de la nouvelle fonctionnalité de contrat intelligent. La présence ou l'absence de code à une adresse peut affecter le flux d'exécution des protocoles interagissant avec l'adresse, car ils se basent sur cette qualité pour différencier les EOAs des contrats intelligents. Cela a nécessité de prendre en compte deux comportements principaux : la vérification de signature et le comportement de réception de jetons.

Vérification de signature

Les contrats intelligents ont une norme différente pour la validation des signatures par rapport aux EOAs standard. Les contrats intelligents mettent en œuvre l'interface isValidSignature définie par ERC-1271 et sont libres de définir une logique arbitraire qui détermine si le contrat considère une signature comme valide. Pour les EOA standard, une signature est validée avec un contrôle ecrecover standard qui garantit que le signataire se rétablit à l'adresse EOA attendue.

Pour garantir que les signatures EOA existantes ou futures continueront d'être honorées au niveau de l'EOA après une mise à niveau 7702, le EIP7702Proxy implémente une version de isValidSignature qui délègue d'abord la validation des signatures à la fonction isValidSignature qui devrait être définie sur l'implémentation logique, mais suit une validation échouée avec une vérification finale d'ecrecover. Si cela passe, la signature est considérée comme valide. De cette manière, les EOAs utilisant le EIP7702Proxy peuvent garantir que les simples signatures EOA seront toujours honorées à leur adresse, indépendamment de l'implémentation de isValidSignature de leur portefeuille de contrat intelligent.

Reçu de jeton

Certain standards de jetons (spécifiquement ERC-1155 et ERC-721) tenter de protéger contre les jetons se retrouvant bloqués dans des contrats intelligents qui peuvent ne pas avoir la capacité de les gérer. Ces jetons nécessitent que tout contrat intelligent qui recevra de tels jetons déclare cette capacité en implémentant des interfaces standard de réception de jetons qui sont appelées par le contrat de jeton lors d'un envoi de jeton. Il est également essentiel que la logique au niveau de l'EOA mis à jour contienne une fonction de réception standard ou un fallback payable pour pouvoir recevoir des jetons natifs. Un compte ne devrait jamais être dans un état qui le laisse incapable de recevoir de l'ETH ou d'autres jetons, même brièvement.

Puisque notre proxy manque d'une mise en œuvre initiale, nous incluons une mise en œuvre par défaut Immutable DefaultReceiver comme logique par défaut pour le EIP7702Proxy en l'absence d'un pointeur ERC-1967. Ce récepteur implémente une fonction de réception et les hooks de récepteur pour ces standards de jetons courants, garantissant que le compte peut accepter des transferts de jetons avant de définir explicitement une nouvelle mise en œuvre.

Conclusion

La conception de EIP7702Proxy nous permet de maintenir une parité étroite avec les Portefeuilles CoinbaseSmartWallets standard déployés et de continuer à utiliser l'implémentation existante de CoinbaseSmartWallet tout en résolvant les défis de sécurité uniques qui se posent dans le contexte de l'EIP-7702. En considérant attentivement la sécurité d'initialisation, les implications de l'impermanence du stockage et de l'interférence, la nécessité d'une gestion ininterrompue des tokens et de la compatibilité ascendante avec la vérification de signature EOA standard, nous avons créé un proxy pour déléguer et gérer en toute sécurité les Portefeuilles de contrat intelligent EIP-7702. Bien que le EIP7702Proxy ait été conçu en tenant compte de l'implémentation de CoinbaseSmartWallet V1, ce proxy est finalement indépendant de l'implémentation. Nous encourageons les développeurs à évaluer cette solution pour la protection contre le 7702 d'autres implémentations de Portefeuilles de contrats intelligents.

Avertissement:

1. Cet article est reproduit de [}Blog d'ingénierie de base]. Tous les droits d'auteur appartiennent à l'auteur original [Amie Corso]. S'il y a des objections à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Avertissement de responsabilité : Les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.