L'abstraction de compte vise à améliorer les expériences des utilisateurs et des développeurs dans l'ensemble de l'écosystème Ethereum. En rendant les expériences sur chaîne plus accessibles et agréables pour les utilisateurs, cela permet également aux développeurs de faire des choses plus puissantes sur Ethereum et de servir les utilisateurs de manière encore plus significative.

Notre classification des approches de l'abstraction de compte est la suivante:

1. Amélioration de l'EOA/programmabilité : Cela inclut les modifications au niveau du protocole qui permettent aux EOA (Externally Owned Accounts) de redéfinir la partie logique d'exécution de leurs règles de validité. Comme bien connu au sein de la communauté de développement, les EOA sont généralement associés aux utilisateurs finaux. Par conséquent, les solutions qui relèvent de cette approche donneront plus de contrôle aux comptes des utilisateurs finaux sur le type d'actions qu'ils peuvent autoriser, par rapport à la manière dont cela peut être géré aujourd'hui.
2. Conversion/migration de EOA : Cette approche comprend des propositions visant la conversion complète des EOA en CA (comptes de contrat). L'idée intégrale de cette approche est que les comptes de contrat offrent déjà la plupart des avantages offerts par les comptes intelligents, donc il ne devrait plus être nécessaire de compliquer les choses davantage ; tout le monde devrait simplement utiliser un compte de contrat comme leur compte principal (via des portefeuilles de contrats intelligents).

Cette approche comprend des mécanismes qui permettent à un EOA de passer à un CA sans avoir à déplacer ses actifs, tels que EIP 7377etEIP 5003 (lorsqu'il est considéré aux côtés de l'EIP 3074).

1. Comptes intelligents: Ce groupe de propositions comprend des conceptions qui permettent aux EOAs et aux CAs de se comporter comme des «comptes intelligents» en leur permettant de redéfinir totalement leurs règles de validité.

Diverses propositions ont été précédemment faites pour la création de comptes intelligents et l'abstraction de compte au niveau du protocole;EIP-86etEIP-2938sont parmi les plus cités. Cependant, il y a eu beaucoup de résistance en raison de la complexité perçue introduite par cette conception et de l'opinion assez majoritaire selon laquelle Ethereum n'est pas prêt pour une telle complexité.

Suite au regain d'intérêt de Vitalik après la fusion,ERC-4337a été proposée comme une version facultative de la norme de compte intelligent, similaire à l'infrastructure PBS (Proposer-Builder Separation) pour la valeur extractible maximale (MEV). Ainsi, les utilisateurs qui cherchent à accéder aux avantages des comptes intelligents pourraient simplement utiliser le pipeline ERC-4337 pour redéfinir la logique de leur compte et les règles de validité des transactions dans des structures appelées UserOperation (ou UserOps pour faire court).

ERC 4337 apporte les avantages des comptes intelligents à l'Ethereum d'aujourd'hui sans consacrer aucune des complexités, en fonctionnant comme une alternative hors protocole aux comptes intelligents consacrés. Cependant, cela ne signifie pas que l'infrastructure est optimale dans son état actuel, car sa propre complexité reste un point de défaillance considérable.

Pour faire face à cette complexité, RIP 7560a été rédigé comme une version consacrée de l'infrastructure ERC 4337 à travers Ethereum et ses L2s, de sorte qu'il hérite des schémas de résistance sybil du réseau plutôt que de devoir définir un nouveau ensemble de règles (comme le fait ERC 4337 avec ERC 7562).

Dans ce rapport, nous nous concentrerons sur l'exploration de la programmabilité de l'EOA, en évaluant les divers EIP qui décrivent des solutions dans cette voie et en discutant de leurs mérites et inconvénients. Dans les parties 2 et 3 de cette série, nous couvrirons les deux classes restantes d'approche de l'abstraction de compte en cours d'exploration au sein d'Ethereum.

Une introduction aux comptes et transactions Ethereum

Afin de rechercher ce qui peut être abstrait, nous avons besoin d'une image (quelque peu) complète de la conception actuelle du compte. Cette section servira principalement de révision pour ce que sont réellement les comptes sur Ethereum, et comment leurs transactions sont validées et exécutées.

Les comptes Ethereum sont des entités avec un solde en ether (ETH) et la possibilité d’envoyer des transactions sur la blockchain Ethereum. Ils sont représentés sous la forme d’une « adresse » hexadécimale de 42 caractères, qui sert de pointeur unique vers les avoirs et les transactions du compte.

Une adresse agit comme une clé dans l'arbre d'état de la blockchain. Les nœuds feuilles de cet arbre sont des structures de données de compte qui peuvent être décomposées en quatre champs:

1. nonce: Un compteur linéaire utilisé pour indiquer le nombre de transactions sortantes initiées par un compte. Il est également crucial pour prévenir les attaques de rejeu.
2. solde: Le montant d'éther (ETH) détenu par un compte, exprimé en wei.
3. codeHash : Un hachage du code exécutable par EVM contenu dans un compte. L'EVM (Machine Virtuelle Ethereum) est l'environnement d'exécution exclusif d'Ethereum responsable de la gestion de transitions d'état complexes au-delà des simples transactions « envoyer ». Le contenu de code d'un compte est programmé de manière immuable pour effectuer des formes spécifiques de transition d'état sur la blockchain Ethereum, via l'EVM.
4. storageHash: Un hachage de la racine de stockage d'un compte, utilisé pour représenter le contenu du stockage d'un compte sous la forme d'un hachage de 256 bits d'un nœud racine d'un trie de merkle patricia. En somme, il s'agit d'un hachage des données de variable d'état relatives au contenu du code d'un compte.

Les contenus de ces quatre champs sont utilisés pour définir le type de compte, et finalement déterminer l'étendue de ses fonctionnalités. Ainsi, les deux types de comptes Ethereum sont :

1. Comptes détenus à l'extérieur (EOA) - qui sont initialisés en tant que paire de clés cryptographiques :

• Une clé privée qui est un caractère hexadécimal de 64 bits chiffrable et démontrablement aléatoire, et son homologue complémentaire;
• Une clé publique dérivée de la clé privée à l'aide de l'ECDSA (Elliptic Curve Digital Signature Algorithm).

Les EOAs ont des champs codeHash et storageHash vides et ne peuvent être contrôlés que par quiconque possède les clés privées. Leurs adresses peuvent être obtenues à partir de la clé publique correspondante en préfixant "0x" aux vingt derniers caractères du hachage keccak-256 de la clé publique du compte.

1. Comptes de contrat (CAs) - qui ne peuvent être créés que par un EOA préexistant. Ils sont initialisés en raison d'un EOA déployant du contenu de code exécutable sur l'EVM. Ce contenu de code (stocké sous forme de codeHash) est consacré dans l'EVM et est responsable de contrôler le compte en définissant sa logique et ses interactions.

Leurs transactions sont entièrement basées sur le pull et fondées sur la logique de leur code déployé.

Étant donné que ces comptes ne peuvent être contrôlés que par leur contenu de code, ils n'ont pas besoin de clé privée et n'ont qu'une clé publique. Ainsi, tout agent ayant la capacité de mettre à jour/changer le contenu du code d'un compte de contrat pourrait accéder à son solde.

L'adresse d'un CA est dérivée de l'adresse de son créateur et de son nonce jusqu'au point de déploiement du contrat.

Transactions

Nous avons récemment décrit les comptes comme des entités ayant la capacité d'envoyer des transactions à travers Ethereum. Nous pouvons donc comprendre qu'un objectif principal d'un compte est d'envoyer et de recevoir des transactions, tandis que la blockchain agit en tant que registre enregistrant l'historique des transactions ainsi que la description de la manière dont les transactions modifient les champs du compte en fonction des règles décrites dans la spécification du protocole de la blockchain.

Alors, qu'est-ce que ces "transactions"?

Les transactions sont des opérations envoyées depuis un compte, qui provoquent un changement d'état du réseau. Ce sont des instructions signées cryptographiquement provenant de comptes, qui entraînent une mise à jour de l'état à l'échelle du réseau lorsqu'elles sont exécutées.

La permissionless s'accompagne du coût d'incitations perverses, pour y faire face, des directives strictes (ou règles de validité) doivent être définies pour les interactions dans de tels environnements.

Dans ce contexte, les transactions doivent suivre certaines règles de validité pour être considérées comme valides et exécutées. La plupart de ces règles de validité sont mises en œuvre via des contraintes placées sur le compte envoyant la transaction, et varient en fonction du type de compte.

Comptes et validité des transactions

Sur Ethereum, les EOAs sont optimisés pour la convivialité car ils sont orientés vers les utilisateurs finaux. Ils ont la capacité d'envoyer des transactions de manière spécifique et d'opérer parfaitement de manière autonome. Ils peuvent également être créés localement, la méthode la plus courante étant l'utilisation de fournisseurs de portefeuilles tels que MetaMask, Rainbow, Rabby, etc.

D'autre part, les comptes de contrat ne peuvent envoyer que des transactions autorisées par leur logique, en réponse à un "appel". De plus, ils ne peuvent être créés que par un EOA disposant d'un solde suffisant pour payer leur stockage d'état.

Une description plus générale serait que les EOAs ne peuvent détenir qu'un solde, tandis que les CAs peuvent détenir à la fois un solde et une logique qui dicte comment ce solde peut être dépensé.

Ces propriétés sont dues aux paramètres logiques suivants qui définissent les règles auxquelles les transactions d'un compte doivent se conformer :

1. Logique d'authentification - Utilisée pour définir comment un compte prouve son identité au réseau tout en changeant son solde et/ou sa logique.
2. Logique d'autorisation - Utilisée pour définir la politique d'accès d'un compte, c'est-à-dire qui est en mesure d'accéder et de modifier le solde et/ou la logique du compte.
3. Logique de nonce - qui définit l'ordre dans lequel les transactions d'un compte doivent être exécutées.
4. Logique de paiement de gaz - Utilisée pour définir la partie responsable du règlement des frais de gaz d'une transaction.
5. Logique d'exécution - Utilisée pour définir les formes de transactions qu'un compte peut envoyer, ou comment une transaction doit être exécutée.

Ces paramètres sont conçus pour être rigides pour les EOAs ainsi :

• L'authentification et l'autorisation sont assurées par une clé privée basée sur ECDSA, c'est-à-dire qu'un utilisateur qui souhaite envoyer une transaction à partir de son EOA doit utiliser sa clé privée pour accéder au compte et ainsi prouver qu'il a le droit d'effectuer des modifications de son solde.
• La logique du nonce met en œuvre un schéma de compteur séquentiel, qui permet l'exécution séquentielle d'une seule transaction par nonce unique par compte.
• La logique de paiement du gaz spécifie que les frais de gaz pour les transactions doivent être réglés par le compte expéditeur/d'origine.
• La logique d'exécution spécifie que les comptes externes autonomes (EOA) ne peuvent envoyer que les formes de transaction suivantes :

1. Transferts réguliers entre deux EOAs.
2. Déploiement de contrat.
3. appels de contrat qui ciblent la logique d'un compte de contrat déployé.

Plus généralement, la logique d'exécution des EOAs les contraint à une transaction par signature valide.

D'autre part, les CA ont plus de flexibilité autour de ces paramètres:

• L'authentification n'est pas nécessaire, car leurs transactions sont conséquentielles/tirées par nature.
• L'autorisation pour les AC peut prendre deux formes:

1. Capacité à "appeler" le code du contenu des CA (ou exécuter son smart contract), qui dépend de la logique du smart contract du compte et de ses invariants.
2. Capacité à apporter des modifications au code du contenu des AC, qui dépend principalement de la possibilité ou non de mettre à niveau le code du contenu.

Dans la plupart des cas pratiques, la logique utilisée dans ce cas est un schéma de multi-signature qui stipule qu'un M de N signatures valides (où M < N) est requis à partir de comptes spécifiques (généralement des EOAs) afin qu'un changement de logique du CA soit valide.

• Leur ordonnancement des transactions est basé sur la nonce avec une certaine souplesse. Le CA lui-même est capable d'envoyer autant de transactions à autant d'appelants différents que possible, cependant chaque appelant est limité en fonction de ses propres capacités.
• Le paiement de l'essence est généralement géré par l'appelant de la logique de la CA.
• La logique d'exécution des CA est plus diversifiée pour permettre des améliorations de l'expérience utilisateur telles que les transactions multicall et les transactions atomiques.

En évaluant ces fonctionnalités, nous observons que chaque type de compte est conçu pour présenter un compromis entre autonomie et programmabilité.

Les EOAs ont une autonomie complète mais une programmabilité limitée; ils peuvent autoriser et envoyer des transactions quand ils le souhaitent, mais ces transactions doivent suivre un format rigide pour être considérées comme valides. Les CA ont une programmabilité complète (limitée uniquement par la conception de l'EVM) mais une autonomie limitée; leurs transactions ne doivent suivre aucun format rigide, mais ne peuvent être envoyées que si leur logique est appelée en premier.

Dans la sous-section suivante, nous étudierons maintenant les implications de ces choix de conception, afin de bien comprendre la proposition de chaque EIP discutée tout au long de cette série.

Le dilemme du compte Ethereum

Maintenant que nous avons une connaissance assez succincte des fonctionnalités des différents comptes, nous pouvons facilement identifier leurs arguments de vente ainsi que les problèmes qu’ils présentent pour l’expérience utilisateur et développeur sur Ethereum.

Comme nous l'avons mentionné précédemment, les EOAs sont conçus comme des comptes de premier ordre destinés aux utilisateurs finaux. Les applications sont conçues pour interagir facilement avec eux, il n'y a presque aucune complexité et bien sûr, il n'y a aucun coût pour en créer un. Cependant, sa simplicité entraîne une perte significative de nouveauté car ils sont conçus pour être strictement déterministes.

Voici quelques-unes des préoccupations qui les entourent :

1. Vulnérabilité aux attaques quantiques - Le schéma de signature ECDSA utilisé par leur paire de clés n'est pas résistant aux attaques quantiques, et avec un calendrier optimiste de 5 à 10 ans pour que les systèmes quantiques industriels soient réalisés, cela représente une menace importante pour Ethereum et ses applications qui reposent fortement sur le schéma ECDSA pour les preuves cryptographiques et la sécurité.
2. Manque d'expression - Le format rigide des règles de validité des EOAs élimine la possibilité pour les utilisateurs d'exprimer leurs transactions de manière plus concise via des fonctionnalités telles que l'atomicité des transactions et leur regroupement, ainsi que la délégation des transactions.
3. Auto-suffisance – Tout le monde a eu sa part équitable de moments où "je suis tombé en panne d'essence" en plein milieu d'une transaction. Cela est dû à l'exigence selon laquelle les EOAs règlent eux-mêmes le gaz pour leurs transactions, ce qui ne serait pas trop demander si l'éther (ETH) n'était pas la seule devise de gaz acceptable. Bien que ce soit un problème général avec les machines à état basées sur des comptes (et même sur des UTXO), Ethereum a toujours eu l'intention d'être différente.

Tout le monde ne veut pas (ou ne serait pas en mesure de) détenir toujours de l'ETH (je veux dire, regardez cette action de prix), donc les solutions viables seraient soit d'autoriser plusieurs devises de gaz (trop difficile, casse trop d'invariants comme décrit dans la section "Monnaie"ici) ou permettre que les paiements de gaz soient réglés par un autre compte qui n'est pas l'origine de la transaction.

À l'autre bout du spectre des comptes, les CA ciblent les développeurs et une base d'utilisateurs plus techniques. Ils servent de véhicules pour les contrats intelligents (c'est-à-dire que nous considérons les contrats intelligents comme leur logique contenue ou leur contenu de code) et peuvent donc mettre en œuvre de nouveaux formats de transaction rendus possibles par l'EVM.

Cependant, pour toutes ces fonctionnalités, ils sont des comptes de deuxième classe glorifiés car ils n'ont aucune autonomie. Voici quelques-uns de leurs inconvénients :

1. Manque total d'autonomie - les CA ne peuvent pas commencer une transaction, ils ne peuvent envoyer des transactions qu'en réponse à une invocation très particulière.
2. La susceptibilité à l'erreur humaine dans leur logique - Le manque de rigidité conduit souvent à une définition incorrecte des invariants et d'autres logiques similaires, ce qui a entraîné des pertes de milliards de dollars en raison d'exploitations et de piratages de contrats intelligents. Cependant, il s'agit presque d'un sujet entièrement différent qui dépasse le cadre de notre discussion ici.

Après avoir examiné les choix de conception qui ont conduit aux problèmes définis dans cette sous-section, nous pouvons maintenant procéder à l'évaluation des solutions proposées.

Une chronologie de l'abstraction de compte

Le concept d’abstraction de compte (via les comptes intelligents au moins) a toujours fait partie intégrante de la feuille de route d’Ethereum. La tradition est que la complexité entourant sa mise en œuvre menaçait de retarder davantage le lancement d’Ethereum, et qu’il a donc été abandonné pour la conception actuelle avec différents comptes offrant différentes fonctionnalités. Il a de nouveau été retardé par l’accent mis par Ethereum sur The Merge, et refait maintenant surface en tant qu’élément principal de la prochaine mise à niveau majeure du réseau - Pectra. Cependant, sa complexité est toujours considérée comme un inconvénient important empêchant sa consécration, d’autant plus qu’Ethereum a pivoté vers une feuille de route centrée sur le rollup.

Les exigences sont désormais de deux ordres :

1. Les normes de compte doivent être plus expressives, mais sans perte d'autonomie. Une nouvelle norme qui scelle la division entre les normes EOA et CA.
2. La nouvelle norme doit combler le fossé entre les EOAs et les CAs, tout en restant parfaitement compatible avec Ethereum et ses écosystèmes L2.

Intuitivement, ce concept joue un rôle plus important dans le contexte de l'abstraction de compte et de l'interopérabilité, cependant notre champ d'application tout au long de ce rapport se limite aux initiatives techniques prises pour atteindre l'abstraction de compte elle-même.

L'abstraction de compte vise à combiner les meilleures fonctionnalités des EOAs et des CAs dans une nouvelle norme de compte - les comptes intelligents, qui permettent une séparation complète ou partielle des règles de validité de n'importe quel compte en une logique de validation et une logique d'exécution; de sorte que les comptes peuvent définir leurs propres règles de validité - tel que permis par l'EVM - tout comme les comptes de contrat, tout en restant entièrement autonomes, comme les comptes appartenant à des tiers.

Il y a souvent de la confusion autour des différences entre les comptes intelligents et les portefeuilles de contrats intelligents, alors décrivons explicitement ces différences ci-dessous :

• Les comptes intelligents sont des comptes Ethereum qui sont conceptualisés pour fournir des parties égales de programmabilité et d'autonomie. L'idée est que les EOAs et les CAs peuvent devenir des comptes intelligents simplement en utilisant un mécanisme quelconque (par exemple, ERC 4337) qui leur permet de remplacer leurs règles de validité imposées par le réseau par des règles de validité sur mesure, comme bon leur semble.
• Les portefeuilles de contrats intelligents, en revanche, sont simplement des fournisseurs de portefeuilles qui servent d'interfaces aux comptes de contrats (oui, un portefeuille n'est pas un compte).

La commercialisation des portefeuilles de contrats intelligents a facilité l'adoption des AC par un marché plus large, permettant aux utilisateurs moins techniques de profiter des fonctionnalités qu'ils offrent. Cependant, ils rencontrent toujours les pièges associés aux AC.

Revenons à la conversation ; Nous avons précédemment discuté des paramètres qui sont utilisés pour définir les règles de validité des transactions de comptes :

• Authentification
• Autorisation
• Logique de nonce
• Logique de paiement de gaz
• Logique d'exécution

Les valeurs des quatre premiers paramètres peuvent être collectivement appelées la logique de validation du compte, qui sont des vérifications qui se produisent avant le début de l'exécution d'une transaction.

Le dernier paramètre définit comment l'exécution de la transaction doit être effectuée.

Dans l’introduction, nous avons donné un aperçu général du paysage actuel des AA sous la forme d’une sorte de classification pour les différentes conceptions proposées. Nous allons maintenant nous concentrer sur la première classe de solutions au dilemme des comptes d’Ethereum : la programmabilité EOA.

EOAs programmables

Le plus grand attrait d'Ethereum est son écosystème DeFi jeune mais dynamique, qui comprend une variété d'applications décentralisées qui sont ses principaux puits de liquidité. La plupart de ces DApps sont optimisées pour servir les EOAs, ce qui les rend difficiles à interfacer avec les CAs et finalement les comptes intelligents. Bien que les portefeuilles de contrats intelligents aident les CAs dans ce cas, ils présentent leurs propres limitations et une expérience utilisateur totalement différente.

Une solution provisoire en cours d'exploration alors que les DApps et les fournisseurs de portefeuille s'habituent à la norme de compte intelligent consiste à fournir des améliorations temporaires aux EOAs qui leur permettent de surmonter la plupart de leurs restrictions imposées, qu'il s'agisse de leur validation ou de leur logique d'exécution.

Ci-dessous, nous passons en revue les spécifications de trois EIP majeurs qui offrent des voies d'action vers la programmabilité des comptes EOA ; du moins connu EIP 5806, à l'ambitieux EIP 3074et enfin finalement au victorieux EIP 7702.

Programmabilité via EIP-5806

Cette proposition vise à apporter plus de fonctionnalités à la norme EOA en lui permettant d'effectuer des appels délégués à la logique d'un compte de contrat (son contrat intelligent). Cela fait en sorte que le contrat intelligent soit exécuté dans le contexte de l'EOA appelant, c'est-à-dire que l'EOA reste sous le contrôle de sa logique de validation, tandis que sa logique d'exécution est gérée par la logique correspondante du CA.

Avant d'aller plus loin, faisons un voyage dans le temps de l'évolution d'Ethereum àEIP-7.

EIP-7 a proposé la création de l'opcode 0xf4/DELEgateCALL, qui est utilisé pour envoyer des appels de message dans un compte principal avec la logique d'un compte secondaire, tout en maintenant les valeurs des champs [sender] et [value] du compte principal.

En d'autres termes, le compte principal « hérite » (ou emprunte si vous préférez) la logique du compte secondaire pendant une certaine durée spécifiée dans l'appel de message, de sorte que la logique de ce dernier est exécutée dans le contexte du premier.

Cet opcode permettait aux développeurs de dApp de diviser la logique de leur application en plusieurs contrats intelligents tout en maintenant l'interdépendance, de sorte qu'ils pouvaient contourner facilement les limites de taille du code et les limites de gaz.

EIP-5806 résumé

D'accord, alors quelles appels de délégué permettent aux CA d'être interdépendants? Eh bien, l'EIP-5806 utilise l'EIP-7 comme inspiration pour proposer l'extension de la fonctionnalité d'appel de délégué aux EOAs également; c'est-à-dire, permettons également aux EOAs d'être interdépendants avec les CA, car pourquoi pas.

Spécifications

L'EIP 5806 introduit un nouveau conforme à l'EIP-2718type de transaction qui est emballé comme suit :

rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Ces transactions sont conçues de sorte que le champ [to] - qui représente l'adresse du destinataire - ne peut accepter que des adresses en tant qu'entrées de 20 octets, empêchant l'expéditeur d'utiliser l'opcode CREATE.

La motivation derrière chaque composant du schéma RLP est la suivante :

• chainID: L'identificateur conforme à l'EIP-115 de la chaîne actuelle rembourré à 32 octets. Cette valeur offre une protection contre les attaques de rejeu, de sorte que les transactions sur la chaîne d'origine ne sont pas facilement répliquées sur des chaînes EVM alternatives ayant une histoire similaire et une sécurité économique moindre.
• nonce : un identifiant unique pour chaque transaction qui offre également une protection contre les attaques par rejeu.
• max_priority_fee_per_gas et max_fee_per_gas : Les valeurs des frais de gaz qu'une transaction EIP-5806 doit payer pour la commande et l'inclusion respectivement.
• limite_de_gaz: La quantité maximale de gaz qu'une transaction de type 5806 unique peut consommer.
• destination: Le destinataire de la transaction
• data : le contenu du code exécutable
• access_list: Les agents qui sont conditionnellement autorisés à exécuter des transactions EIP-5806.
• signature_y_parity, signature_r et signature_s : trois valeurs qui représentent ensemble une signature secp256k1 sur le message — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Alors que l'emballage des transactions EIP-5806 dans des enveloppes EIP-2718 leur permet d'être largement rétrocompatibles, les EOAs ne sont pas équivalents aux CAs. Ainsi, certaines restrictions doivent être définies dans la manière dont un EOA utilise les appels délégués pour éviter toute rupture d'invariant.

Ces restrictions visent les opcodes suivants :

• SSTORE/0x55： Cet opcode permet à un compte de sauvegarder une valeur dans le stockage. Il est restreint dans les transactions EIP-5806 pour empêcher les EOAs de définir / accéder au stockage en utilisant des appels délégués, empêchant ainsi les problèmes potentiels qui pourraient survenir à l'avenir en raison de la migration des comptes.
• CREATE/0xF0, CREATE2/0xF5, et SELFDESTRUCT/0xFF : Ces opcodes permettent largement à l'appelant de créer un nouveau compte. L'accès à ceux-ci est restreint pour empêcher l'altération du nonce d'un EOA dans un cadre d'exécution différent (dans ce cas, la création/destruction de contrat) tout en effectuant une transaction EIP-5806, afin d'éviter l'invalidation de l'attente que les transactions portent des nonces consécutifs.

Potentiel d'Applicabilité/Utilisation

La principale applicabilité de l'EIP 5806 est l'abstraction d'exécution pour les EOAs. Permettre aux EOAs d'interagir de manière digne de confiance avec les contrats intelligents au-delà des appels simples à leur logique leur accorde des fonctionnalités telles que:

• Exécution conditionnelle des transactions
• Regroupement de transactions
• Transactions multicall (par exemple, approuver et appeler)

Critiques

Les changements proposés par l'EIP-5806, tout en permettant les fonctionnalités nécessaires, ne sont pas particulièrement novateurs ; son existence repose principalement sur un EIP-7 déjà fonctionnel. Cela lui permet de contourner de nombreux obstacles potentiels à son acceptation.

L'une des principales préoccupations exprimées dès ses débuts était le risque potentiel de permettre aux EOAs d'accéder au stockage et de le modifier, tout comme le font actuellement les CAs. Cela rompt avec de nombreux invariants enracinés dans le réseau concernant la manière dont les EOAs doivent effectuer des transactions, et cela a été traité en introduisant les restrictions mentionnées dans le paragraphe précédent.

Une deuxième critique (qui est un peu à double tranchant) est la simplicité de l'EIP-5806 ; il y a un sentiment selon lequel les récompenses dues à l'acceptation de l'EIP-5806 pourraient ne pas valoir le coût, car il ne permet que l'abstraction d'exécution et pas grand-chose d'autre. Toutes les autres restrictions de validité restent définies par le réseau pour les EOAs qui optent pour l'EIP-5806, contrairement à d'autres EIPs quelque peu similaires que nous discutons dans les sous-sections suivantes.

Programmabilité via EIP-3074

L'EIP-3074 propose de permettre aux EOAs de déléguer la plupart de leur logique de validation à des comptes de contrat spécialisés, appelés invocateurs, en superposant la logique d'autorisation de ces derniers sur la leur pour des formes spécifiques de transactions.

Il réalise cela en signant leur politique d'accès à un contrat d'invocation, qui devient ensuite responsable de la définition de la politique d'accès de l'EOA.

Cette EIP propose l'ajout de deux nouvelles opcodes à l'EVM:

• [AUTH] qui définit une variable de contexte [autorisé] du compte pour agir au nom d'un second compte [autorité], en fonction de la signature ECDSA de ce dernier.
• [AUTHCALL] qui envoie / met en œuvre des appels pour le compte [autorité] à partir du / en tant que compte [autorisé].

Ces deux opcodes permettent à un EOA de déléguer le contrôle à une autorité de certification préétablie, et ainsi, d’agir comme un seul à travers elle, sans avoir à déployer un contrat et à encourir les coûts et les externalités qui y sont associés.

Spécifications

EIP-3074 permet aux transactions d'utiliser un format de signature [MAGIC] pour éviter les collisions avec d'autres formats de signature de transaction. Le compte actif auquel les instructions [AUTHCALL] sont transmises est défini comme un champ de variable de contexte nommé [authorized], qui ne persiste que pendant une seule transaction et doit être redéfini pour chaque nouveau [AUTHCALL].

Avant d’aborder les complexités de chaque opcode, voici les entités impliquées dans une transaction EIP-3074 :

• [autorité]: Le compte de signature principal (un EOA) qui délègue l'accès/le contrôle à un deuxième compte, qui est généralement un compte de contrat.
• [authorized] : le compte auquel les instructions [AUTHCALL] doivent être transmises pour exécution. En d’autres termes, il s’agit du compte dans lequel la logique d’un [AUTHCALL] est exécutée, pour le compte de l'[autorité], à l’aide de contraintes définies par un [invoker].
• [invoker]: Un contrat subsidiaire destiné à gérer les interactions entre le compte [autorisé] et la logique de [AUTHCALL], en particulier dans les cas où la logique principale du code de contrat de ce dernier est le parrainage de gaz.

Les contrats Invoker reçoivent des messages [AUTH] avec une valeur [COMMIT] de [authority]; cette valeur définit les restrictions que le compte souhaite imposer à l'exécution des instructions [AUTHCALL] par [authorized].

Ainsi, les appelants sont responsables de s’assurer que le [contract_code] défini dans un compte [autorisé] n’est pas malveillant et qu’il a la capacité de satisfaire les invariants placés par le compte de signature principal dans une valeur [COMMIT].

L'opcode [AUTH] a trois entrées d'éléments de pile ; ou plus simplement - il est défini par trois entrées qui calculent une seule sortie. Ces entrées sont :

1. autorité : qui est l'adresse de l'EOA qui génère la signature
2. compenser
3. longueur

Les deux dernières entrées sont utilisées pour décrire une plage de mémoire modifiable de 0 à 97, où :

1. [mémoire(décalage : décalage+1)] - [yParity]
2. [mémoire(décalage+1 : décalage+33] – [r]
3. [mémoire(décalage+33 : décalage+65)] – [s]
4. [mémoire(offset+65 : offset+97)] – [COMMIT]

Les variables [yParity], [r] et [s] sont collectivement interprétées comme une signature ECDSA, [magic], sur la courbe secp256k1 sur le message:

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

où :

• [MAGIC] est une signature ECDSA résultant de la combinaison des variables :
  • [chainID] qui est l'identifiant conforme à l'EIP 115 de la chaîne actuelle utilisé pour fournir une protection contre les attaques de rejeu sur des chaînes EVM alternatives avec une histoire similaire et une sécurité économique moindre.
  • [nonce] qui est le nonce actuel de l'adresse du signataire de la transaction, complété à gauche pour atteindre 32 octets.
  • [invokerAddress] qui est l'adresse du contrat qui contient la logique pour l'exécution de [AUTH].
• [COMMIT] est une valeur de 32 octets utilisée pour spécifier des conditions de validité de transaction supplémentaires dans la logique de prétraitement de l’appelant.

Si la signature calculée est valide et que l'adresse du signataire est égale à [authority], le champ [authorized] est mis à jour avec la valeur fournie par [authority]. Si l'une de ces conditions n'est pas satisfaite, le champ [authorized] reste inchangé dans son état précédent ou comme une valeur non définie.

Le coût en gaz de cet opcode est calculé comme la somme de:

1. Des frais fixes pour le précompilé [ecrecover] et des frais supplémentaires pour un hachage keccak256 et une logique supplémentaire, d'une valeur de 3100 unités
2. Des frais d’extension de mémoire qui sont calculés de la même manière que l’opcode [RETURN], et appliqués lorsque la mémoire est étendue au-delà de la plage spécifiée de l’allocation actuelle (97 unités)
3. Un coût fixe de 100 unités encouru pour une [autorité] chaude et de 2600 unités pour une [autorité] froide afin de prévenir les attaques dues à une erreur de tarification des opcodes d’accès à l’état.

[AUTH] est implémenté pour ne pas modifier la mémoire, et prend la valeur de [authority] en tant qu'argument afin qu'il soit trivial de vérifier sa valeur à partir de la signature fournie.

L’opcode [AUTHCALL] a sept entrées d’élément de pile qui sont utilisées pour calculer une sortie d’élément de pile unique.

Il a la même logique que l’opcode [CALL], c’est-à-dire ; Il est utilisé pour envoyer des appels de messages dans un compte et déclencher une logique spécifique dans ses contrats. La seule déviation dans leur logique est que [AUTHCALL] est conçu pour définir la valeur de [CALLER] avant de procéder à l’exécution.

Ainsi, [AUTHCALL] est utilisé par [l’autorité] pour déclencher un comportement spécifique au contexte dans [autorisé] avec des vérifications logiques procédant comme suit :

1. Vérifiez la valeur de [authorized]. Si elle n'est pas définie, l'exécution est considérée comme invalide et le cadre est immédiatement quitté. Cela permet d'éviter des frais injustes dus à des défaillances imprévues.
2. Vérifie les frais de gaz du comportement prévu de [authorized].
3. Vérifie la valeur conforme à EIP-150 de l'opérande [gas].
4. Vérifie la disponibilité du coût total du gaz –[valeur]– dans le solde de [autorité].
5. L’exécution a lieu après déduction de [valeur] du solde du compte de [autorité]. Si [valeur] est supérieur à leur solde, l’exécution est invalidée.

Le coût de gaz pour [AUTHCALL] est calculé comme la somme de :

• Un coût fixe pour l'appel [warm_storage_read]
• Un coût d’extension de mémoire [memory_expansion_fee] ; qui est calculé de la même manière que le coût du gaz pour l’opcode [CALL]
• Un coût dynamique [dynamic_gas]
• Le coût d'exécution de l'appel secondaire [subcall_gas]

Les données renvoyées depuis un [AUTHCALL] sont accessibles via:

• [RETURNDATASIZE] - qui pousse la taille du tampon de données de retour sur la pile de sortie
• [RETURNDATACOPY] - qui copie les données du tampon de données de retour dans la mémoire.

Pour résumer avec beaucoup moins de jargon technique ; les transactions Ethereum spécifient généralement deux valeurs :

1. tx.origin - qui fournit l'autorisation pour la transaction.
2. msg.sender - dans lequel la transaction se produit réellement.

Dans les EOAs, comme mentionné précédemment, l'autorisation est étroitement liée à l'exécution, c'est-à-dire; (tx.origin == msg.sender). Cette invariance simple donne lieu à la plupart des problèmes que nous avons expliqués dans la sous-section "Comptes et validité des transactions" de ce rapport.

Les messages [AUTH] de [autorité] lui permettent de compenser la fonction tx.origin par [autorisé], tout en restant le msg.sender. Cela lui permet également de définir des restrictions à ce privilège en utilisant une valeur [COMMIT].

[AUTHCALL] permet ensuite à [authorized] d'accéder à la logique d'un contrat, en utilisant un [invoker] comme intermédiaire pour s'assurer que le contrat auquel il souhaite accéder est sans danger. Autrement dit, pour chaque [AUTHCALL], [authorized] doit spécifier un [invoker] particulier pour leur [COMMIT].

Potentielles applications/cas d'utilisation

EIP 3074 est principalement responsable de permettre aux EOAs de déléguer leur logique d'autorisation à un compte différent, cependant sa conception ouverte permet beaucoup plus dans différents contextes.

La logique de validation complète d'un EOA peut être abstraite en appliquant diverses contraintes/innovations à l'invocateur selon les besoins, certains des designs possibles basés sur leur logique cible comprennent:

• Logique de nonce: EIP-3074 permet au nonce des EOAs de rester inchangé après l'envoi d'un message [AUTH], tandis que son nonce pour chaque [AUTHCALL] dépend de l'invocateur avec lequel il interagit. De cette manière, il permet la parallélisme des nonces pour les EOAs, afin qu'ils puissent envoyer autant de [AUTHCALL] non superposés qu'ils le souhaitent.
• Logique de paiement du gaz:Comme spécifiédans l'EIP, les appelants peuvent être conçus pour permettre le parrainage de gaz. Ainsi, les frais de gaz pour un [COMMIT] d'un utilisateur pourraient être déduits de l'origine de la transaction, ou de n'importe quel compte de soutien, qu'il s'agisse d'un compte personnel ou d'un relais basé sur le service (services de parrainage de gaz).

De plus, la logique d'exécution est intuitivement abstraite ; après tout, l'invocateur (qui est un CA) est désormais responsable de l'exécution des demandes de transaction au nom de l'EOA.

Critiques

• Centralisation Invoker

Quotingl'un de ses auteurs : « Je ne m'attendrais pas à ce que les portefeuilles exposent une fonctionnalité pour signer sur des déclencheurs arbitraires... ». Peut-être le plus gros problème posé par l'initiative 3074 est que l'innovation qui en découle aura très facilement tendance à des flux d'accords autorisés et propriétaires ; tout comme les itérations actuelles des marchés MEV et PBS d'Ethereum.

Par défaut, les contrats invokers doivent être fortement audités afin de prévenir des attaques encore plus graves que celles actuellement possibles. Cela tendra inévitablement vers un écosystème où seulement quelques contrats invokers développés par des figures influentes seront adoptés comme étant les paramètres par défaut pour les développeurs de portefeuilles. Ainsi, il s'agit d'un compromis entre suivre la voie difficile de la décentralisation en auditant et en soutenant constamment les contrats invokers au risque de la sécurité des utilisateurs ; ou simplement adopter des contrats invokers provenant de sources établies et réputées offrant de meilleures garanties de sécurité pour les utilisateurs et une surveillance moindre de la sécurité du contrat.

Un autre aspect de ce point est la fonction de coût associée à la conception, à l'audit et au marketing d'un invocateur fonctionnel et sûr. Les petites équipes seront presque toujours surpassées par de plus grandes organisations - notamment sur le front du marketing - qui ont déjà une certaine réputation établie, même si leur produit est meilleur.

• Problèmes de compatibilité ascendante

L'EIP-3074 consolide le schéma de signature ECDSA, car il est toujours considéré comme plus valide que le schéma d'autorisation introduit via l'invokeur. Bien qu'il y ait des arguments selon lesquels la résistance quantique n'est pas actuellement un problème définitif, et qu'il y ait bien pire en jeu dans un avenir où ECDSA est corrompu ; L'objectif quelque peu implicite d'Ethereum est d'être toujours en avance sur de tels problèmes. Sacrifier potentiellement la résistance quantique et à la censure pour des améliorations marginales de l'expérience utilisateur pourrait ne pas être le meilleur choix à l'avenir proche.

Un autre point concernant l'argument de la compatibilité ascendante est que, pendant que les avantages de 3074 étaient encore en cours d'évaluation, ERC-4337 (qui ne nécessite aucune modification de protocole) a maintenant un marché important, donc il faut être compatible avec lui aussi pour éviter la compartimentation des écosystèmes.

Même avec la feuille de route d'abstraction de compte native, les opcodes [AUTH] et [AUTHCALL] finiraient par devenir obsolètes dans l'EVM, introduisant une grande quantité de dette technique à Ethereum afin de fournir une quantité marginale d'amélioration de l'expérience utilisateur.

• Irrévocabilité du schéma ECDSA

Après avoir envoyé un message [AUTH] et délégué le contrôle, il est attendu de l'EOA qu'il évite le schéma d'autorisation habituel de clé privée, car l'envoi d'une transaction « normale » révoque l'autorisation qu'il a déléguée à chaque utilisateur.

Ainsi, le schéma ECDSA reste strictement supérieur à tout autre schéma d'autorisation que les contrats associés peuvent permettre, ce qui signifie qu'une perte de clés privées entraînerait une perte totale des actifs du compte.

Programmabilité via EIP-7702

Cette proposition avait initialement été présentée comme une variation quelque peu minimaliste de l'EIP 3074, et était même signifiéêtre une mise à jour de celui-ci. Il est né pour répondre aux prétendues inefficacités de l'EIP 3074, en particulier les préoccupations concernant son incompatibilité avec l'écosystème 4337 déjà florissant et la proposition d'abstraction de compte native - RIP 7560.

Son approche consiste à ajouter un nouveau type de transaction conforme à l'EIP 2718 - [SET_CODE_TX_TYPE] - qui permet à un EOA de se comporter comme un compte intelligent pour des transactions spécifiées.

Ce design permet les mêmes fonctionnalités que l'EIP 5806 et quelques autres, tout en restant compatible avec la feuille de route de l'abstraction de compte native et les initiatives existantes.

Spécifications

EIP-7702 permet à un EOA d'"importer" le contenu du code d'un contrat via une transaction conforme à [SET_CODE_TX_TYPE] 2718 du format :

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Cette charge utile est entièrement similaire à celle de l'EIP 5806, à l'exception qu'elle introduit une "liste d'autorisation". Cette liste est une séquence ordonnée de valeurs de format :

[[chain_id, address, nonce, y_parity, r, s], …]

où chaque tuple définit la valeur de l'[adresse].

Avant de continuer, les parties impliquées dans un SET_CODE_TX_TYPE sont :

• [autorité]: qui est le compte de signature EOA/principal
• [adresse]: qui est l'adresse d'un compte contenant un code délégable.

Lorsque [authority] signe un SET_CODE_TX_TYPE spécifiant [address], un désignateur de délégation est créé. Il s'agit d'un « programme pointeur » qui fait en sorte que toutes les demandes de récupération de code dues aux actions de [authority] à n'importe quel instant soient canalisées vers le code observable de [address].

Pour chaque tuple [chain_id, address, nonce, y_parity, r, s], le flux logique d'une transaction de type 7702 est le suivant :

1. Vérification de la signature de l'autorité à partir du hash fourni en utilisant: autorité = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Prévention des attaques de rejeu inter-chaînes et autres vecteurs d'attaquepar vérification de l'ID de la chaîne.
3. Vérification si [autorité] a déjà un contenu de code.
4. Vérification du nonce pour s'assurer que le nonce de [l'autorité] est égal au nonce inclus dans le tuple.
5. Si la transaction est la première transaction SET_CODE_TX_TYPE de [autorité], elle est facturée un coût PER_EMPTY_ACCOUNT_COST. Dans le cas où son solde est inférieur à la valeur de cette taxe, l'opération est abandonnée.
6. La désignation de délégation se produit, où le code d'[autorité] est défini sur un pointeur de [adresse].
7. Le nonce du signataire –[autorité]– est augmenté de un.
8. [autorité] est ajoutée à une liste d'adresses accessibles, qui (simplifié à l'extrême) est un ensemble d'adresses qui sont conçues de telle sorte que la réversion d'une portée d'une transaction à partir d'elles les amène (l'adresse) à être ramenées à leur état précédent, avant que la portée révertie ne soit entrée. C'est comme défini dans EIP-2929pour permettre la mise en cache des valeurs réutilisables et éviter des frais inutiles.

Ouf ! Pour tout ramener à l'essentiel ; cet EIP permet aux EOAs d'envoyer des transactions qui définissent un pointeur vers le code d'un contrat, leur permettant de mettre en œuvre cette logique comme la leur dans les transactions ultérieures. De cette manière, il est strictement plus fort que l'EIP 5806, car il permet aux EOAs d'avoir réellement un contenu de code aussi longtemps qu'ils le souhaitent (par opposition à l'EIP 5806 qui permet simplement aux EOAs d'envoyer des appels délégués).

Potentiel d'application/Cas d'utilisation

• Abstraction d'exécution

Bien qu'on puisse soutenir qu'il ne s'agit plus d'une abstraction puisque l'EOA prend activement en charge la logique qu'elle souhaite exécuter, elle n'est toujours pas le "propriétaire principal" de ladite logique. De plus, elle ne contient pas directement la logique, elle spécifie simplement un pointeur vers la logique (afin de réduire la complexité computationnelle). Donc, nous optons pour l'abstraction d'exécution!

• Parrainage de gaz

Bien que l'invariant require (msg.sender == tx.origin) soit violé pour permettre l'auto-parrainage, l'EIP permet toujours l'intégration de relais de transactions parrainées. Cependant, l'inconvénient est que de tels relais nécessitent un système basé sur la réputation ou les enjeux afin de prévenir les attaques de harcèlement.

• Politiques d'accès conditionnel

Les EOAs ne peuvent pointer que vers une partie spécifique du code du compte, de sorte que seule la logique de cette partie est exécutable dans leur contexte.

Cela permet également l'existence de sous-clés qui permettent la «dégradation des privilèges», de sorte que des dAPP spécifiques n'aient accès au solde d'un compte que dans des conditions spécifiques. Par exemple, vous pouvez imaginer une autorisation de dépenser des jetons ERC-20 mais pas d'ETH, ou de dépenser jusqu'à 1% du solde total par jour, ou d'interagir uniquement avec des applications spécifiques.

• Déploiement de contrats intelligents inter-chaînes

En raison de sa nature non restrictive, une transaction EIP-7702 pourrait permettre à un utilisateur d'accéder à l'opcode CREATE2 et de l'utiliser pour déployer du bytecode à une adresse sans aucun autre paramètre restrictif tel que la logique du marché des frais (par exemple, EIP-1559 et EIP-4844). Cela permet à l'adresse d'être récupérée et utilisée à travers plusieurs machines d'état, avec le même bytecode, où son compte sur chaque chaîne est alors responsable de définir les autres paramètres de contexte variable.

Les critiques

• Manque de compatibilité ascendante

Bien que l'EIP-7702 soit encore très récente, il y a déjà eu beaucoup de prototypage et de test pour ses dépendances et ses inconvénients potentiels, mais son modèle minimaliste lui garantit beaucoup de flexibilité et donc d'utilité dans différents contextes. Cependant, il casse beaucoup trop d'invariants et n'est pas immédiatement rétrocompatible.

Certains de ses logiques incluent:

1. Modification du nonce d'EOA en cours de transaction: EIP-7702 ne limite aucun opcode dans le but de garantir la cohérence. Cela signifie qu'un EOA peut implémenter des opcodes tels que CREATE, CREATE2 et SSTORE tout en exécutant une transaction EIP-7702, ce qui permet d'augmenter son nonce dans un contexte différent.
2. Permettre aux comptes ayant une valeur codeHash non nulle d'être des initiateurs de transactions: L'EIP-3607 a été implémenté pour réduire les conséquences potentielles d'une «collision d'adresses» entre les EOAs et les CAs. Une collision d'adresses se produit lorsque la valeur de 160 bits de l'adresse d'un EOA est entièrement équivalente à celle de l'adresse d'un CA.

La plupart des utilisateurs ne sont pas familiarisés avec le contenu réel d'un compte (ou même avec la différence entre un compte et une adresse !), ce qui signifie que permettre des collisions d'adresses signifie qu'un EOA pourrait se faire passer pour un CA et attirer les fonds des utilisateurs dans un processus long et compliqué pour finalement tout voler. L'EIP-3607 a abordé cette question en stipulant que les comptes contenant du code ne devraient pas être en mesure de dépenser leur solde en utilisant leur propre logique d'autorisation. Cependant, l'EIP 7702 brise cette invariance afin de permettre aux EOAs de rester autonomes même après avoir acquis une certaine programmabilité.

• Ressemblance à l'EIP-3074

Signer l'adresse d'un compte plutôt que son contenu de code est essentiellement similaire au schéma 3074 avec les invokers. Cela ne garantit pas strictement la cohérence du contenu du code entre les chaînes, car une adresse peut avoir un contenu de code différent sur différentes chaînes. Cela signifie qu'une adresse dont le contenu de code contient la même logique sur une chaîne pourrait être prédatrice ou carrément malveillante sur une autre chaîne, ce qui pourrait entraîner une perte de fonds pour les utilisateurs.

Conclusion

Les EOAs dans leur forme actuelle sont très limités car ils ne permettent pas aux utilisateurs de profiter des fonctionnalités de programmation offertes par l'EVM. Bien qu'il existe diverses voies pour mettre à niveau les comptes, comme nous l'avons expliqué au début de ce rapport, la solution choisie doit maintenir les principes d'une garde sécurisée et autonome. De plus, les mises à niveau des EOAs peuvent avoir un impact significatif sur l'expérience utilisateur et les développeurs d'applications, de sorte que toutes les voix des parties prenantes doivent être prises en compte.

Permettre aux EOAs d'exécuter du code de n'importe quelle manière étend considérablement les fonctionnalités des comptes, mais cette nouvelle expressivité comporte des risques significatifs et des écueils possibles. Résoudre ces compromis est essentiel pour offrir une mise à niveau avec des avantages UX incontestés pour les utilisateurs d'Ethereum.

La culture de discussion ouverte d'Ethereum en fait un excellent terrain de test pour de telles innovations, car presque chaque implication de chaque conception est minutieusement déconstruite par des experts du sujet. Cette considération globale devrait aider à atténuer les risques de malversation de la part des adversaires.

EIP-7702 est actuellement l'enfant chéri des mécanismes visant à apporter la programmabilité de l'EVM aux EOAs, ayant été désigné comme un remplacement de la fente de l'EIP 3074 dans la mise à niveau de Pectra. Il hérite de la conception ouverte du mécanisme 3074 tout en réduisant considérablement la surface d'attaque / les risques. Il permet également beaucoup plus en évitant les restrictions de l'EIP 3074 à certaines classes d'opcodes.

Alors qu'il reste encore quelques ajustements à apporter à la conception de la proposition, elle a déjà recueilli beaucoup de bonne volonté et de soutien de la part des développeurs, surtout parce qu'elle bénéficie directement du soutien de Vitalik.

Au sein de la communauté, il y a des affirmations selon lesquelles cette approche de l'abstraction de compte pourrait même être meilleure que les comptes intelligents. Ce commentaire souligne que cette voie nécessite moins de modifications et n'est pas aussi complexe, et que les EOAs sont déjà consacrés. Cependant, nous devons nous rappeler de l'étape future de la sécurité quantique à tous les niveaux du réseau Ethereum. Cette sécurité quantique est irréalisable avec le modèle de compte actuel en raison de l'utilisation de schémas de signature basés sur ECDSA pour l'autorisation des EOAs.

Ainsi, la programmabilité des EOA est à considérer comme une étape sur le chemin des comptes intelligents et non comme la destination. Cela suralimente les EOA et permet une meilleure expérience utilisateur et développeur, tout en restant compatible avec l'objectif ultime d'abstraction de compte des comptes intelligents.

Dans notre prochain rapport, nous plongerons dans les schémas de migration EOA pour voir à quel point ils correspondent à la feuille de route de l'abstraction de compte, restez à l'écoute!

Clause de non-responsabilité :

1. Cet article est repris de [ 2077.xyz], Tous les droits d'auteur appartiennent à l'auteur original [zhev]. Si vous avez des objections à cette réimpression, veuillez contacter le Gate Apprendrel'équipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun 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.