L'avenir possible du protocole Ethereum (6) : prospérité
La conception du protocole Ethereum comporte de nombreux "détails" qui sont cruciaux pour le succès d'Ethereum. En réalité, environ la moitié du contenu concerne différents types d'améliorations de l'EVM, le reste étant constitué de divers sujets de niche, c'est là que réside le sens de "繁荢".
Prospérité : objectif clé
Transformer l'EVM en un "état final" performant et stable
Introduire l'abstraction de compte dans le protocole, permettant à tous les utilisateurs de bénéficier d'un compte plus sûr et plus pratique.
Optimiser les coûts de transaction, améliorer la scalabilité tout en réduisant les risques
Explorer des cryptographies avancées, permettant à Ethereum de s'améliorer de manière significative à long terme
Amélioration EVM
Quel problème a été résolu ?
L'EVM actuelle est difficile à analyser statiquement, ce qui rend la création d'implémentations efficaces, la vérification formelle du code et l'expansion ultérieure difficiles. De plus, l'efficacité de l'EVM est faible, rendant difficile la mise en œuvre de nombreuses formes de cryptographie avancée, sauf si un support explicite par précompilation est fourni.
Qu'est-ce que c'est et comment ça fonctionne ?
La première étape de la feuille de route d'amélioration de l'EVM actuelle est le format d'objet EVM (EOF), prévu pour être inclus dans le prochain hard fork. EOF est une série d'EIP, spécifiant une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus significative étant :
Le code ( est exécutable, mais il n'est pas possible de lire ) depuis l'EVM et les données ( peuvent être lues, mais ne peuvent pas être exécutées entre ).
Interdiction de redirection dynamique, uniquement redirection statique
Le code EVM ne peut plus observer les informations liées au combustible.
Ajout d'un nouveau mécanisme de sous-routine explicite.
Les anciens contrats continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés, et même contraints de se convertir en code EOF (. Les nouveaux contrats bénéficieront des gains d'efficacité apportés par l'Eof - d'abord grâce à un bytecode légèrement réduit par les caractéristiques de sous-programme, puis grâce à de nouvelles fonctionnalités spécifiques à l'Eof ou à une réduction des coûts en gas.
Après l'introduction de l'Eof, les mises à niveau ultérieures sont devenues plus faciles. Le développement le plus complet à ce jour est l'extension arithmétique du module EVM ) EVM-MAX (. EVM-MAX crée un nouvel ensemble d'opérations spécifiquement pour les calculs modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui rend possible l'utilisation d'optimisations telles que la multiplication de Montgomery.
Une idée relativement récente est de combiner EVM-MAX avec la fonctionnalité SIMD (Single Instruction, Multiple Data) ), le SIMD en tant que concept d'Ethereum existe depuis longtemps, proposé pour la première fois par Greg Colvin dans l'EIP-616. Le SIMD peut être utilisé pour accélérer de nombreuses formes de cryptographie, y compris les fonctions de hachage, les STARKs 32 bits et la cryptographie basée sur les réseaux, la combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées vers les performances un appariement naturel.
Une conception générale d'un EIP combiné commencera par l'EIP-6690, puis :
Autoriser (i) tout nombre impair ou (ii) toute puissance de 2 ne dépassant pas 2768 comme modulo.
Pour chaque opcode EVM-MAX ( addition, soustraction, multiplication ), ajoutez une version qui n'utilise plus 3 constantes immédiates x, y, z, mais 7 constantes immédiates : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dans le code Python, ces opcodes ont un effet similaire à :
python
for i in range(count):
mem[z_start + z_skip * count] = op(
mem[x_start + x_skip * count],
mem[y_start + y_skip * count]
)
Dans la mise en œuvre réelle, cela sera traité de manière parallèle.
Peut ajouter XOR, AND, OR, NOT et SHIFT( y compris les boucles et non boucles), au moins pour les puissances de 2 modulos. En même temps, ajouter ISZERO( poussera la sortie vers la pile principale EVM), ce qui sera suffisamment puissant pour réaliser la cryptographie à courbe elliptique, la cryptographie de petits domaines( comme Poseidon, Circle STARKs), des fonctions de hachage traditionnelles( comme SHA256, KECCAK, BLAKE) et la cryptographie basée sur les grilles. D'autres mises à niveau EVM peuvent également être mises en œuvre, mais jusqu'à présent, elles ont reçu moins d'attention.
(# Liens de recherche existants
EOF:
EVM-MAX:
SIMD:
)# Le travail restant et les compromis
Actuellement, EOF est prévu pour être inclus dans le prochain hard fork. Bien qu'il soit toujours possible de l'enlever à la dernière minute - des fonctionnalités ont été temporairement retirées lors de précédents hard forks, le faire poserait cependant un grand défi. Enlever EOF signifierait que toute mise à niveau future de l'EVM devrait se faire sans EOF, bien que cela soit faisable, cela pourrait être plus difficile.
Le principal compromis de l'EVM réside dans la complexité de L1 et la complexité de l'infrastructure. L'EOF nécessite l'ajout d'un grand nombre de codes à l'implémentation de l'EVM, et la vérification statique du code est également relativement complexe. Cependant, en échange, nous pouvons simplifier les langages de haut niveau, simplifier l'implémentation de l'EVM et d'autres avantages. On peut dire que la feuille de route pour l'amélioration continue de l'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.
Un travail important à réaliser est de mettre en œuvre des fonctionnalités similaires à EVM-MAX et SIMD, et de réaliser des tests de référence sur la consommation de gas des différentes opérations cryptographiques.
Comment interagir avec d'autres parties de la feuille de route ?
L1 ajuste son EVM pour que L2 puisse également être ajusté plus facilement. Si les deux ne sont pas synchronisés, cela pourrait entraîner des incompatibilités et avoir des conséquences négatives. De plus, EVM-MAX et SIMD peuvent réduire le coût en gas de nombreux systèmes de preuve, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de nombreux précompilés par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir un impact majeur sur l'efficacité.
![Vitalik sur l'avenir potentiel d'Ethereum (6) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp###
( abstraction de compte
)# Quel problème a été résolu ?
Actuellement, les transactions ne peuvent être vérifiées que par un moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à aller au-delà de cela, permettant à la logique de vérification des comptes d'être tout code EVM arbitraire. Cela peut activer une série d'applications :
Passer à la cryptographie post-quantique
Le remplacement des anciennes clés ### est largement considéré comme une pratique de sécurité recommandée ###
Portefeuille multi-signatures et portefeuille de récupération sociale
Utiliser une clé pour des opérations de faible valeur, utiliser une autre clé ( ou un ensemble de clés ) pour des opérations de haute valeur
Permettre au protocole de confidentialité de fonctionner sans intermédiaire, réduisant ainsi considérablement sa complexité et éliminant un point de dépendance central clé.
Depuis que l'abstraction des comptes a été proposée en 2015, son objectif s'est également élargi pour inclure un grand nombre de "cibles pratiques", par exemple, un compte sans ETH mais possédant quelques ERC20 pourrait utiliser des ERC20 pour payer le gaz.
MPC( le calcul multipartite ) est une technologie qui existe depuis 40 ans, utilisée pour diviser une clé en plusieurs parties et les stocker sur plusieurs appareils, utilisant des techniques cryptographiques pour générer des signatures, sans avoir besoin de combiner directement ces parties de clé.
EIP-7702 est une proposition prévue pour être introduite dans le prochain hard fork. EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir la commodité de l'abstraction de compte au bénéfice de tous les utilisateurs (, y compris les utilisateurs EOA ), et vise à améliorer l'expérience de tous les utilisateurs à court terme, tout en évitant la division en deux écosystèmes.
Ce travail a commencé avec l'EIP-3074 et a finalement abouti à l'EIP-7702. L'EIP-7702 offre les "fonctionnalités de commodité" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes possédés aujourd'hui (EOA(), c'est-à-dire les comptes contrôlés par des signatures ECDSA ).
Bien que certains défis (, en particulier le défi de la "commodité", puissent être résolus par des technologies progressives telles que le calcul multipartite ou l'EIP-7702, l'objectif principal de sécurité du projet d'abstraction de compte initialement proposé ne peut être atteint qu'en revenant en arrière et en résolvant le problème original : permettre au code de contrat intelligent de contrôler la validation des transactions. La raison pour laquelle cela n'a pas encore été réalisé réside dans l'implémentation sécurisée, ce qui représente un défi.
![Vitalik concernant l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
)# Qu'est-ce que c'est et comment ça fonctionne ?
Le cœur de l'abstraction de compte est simple : permettre aux contrats intelligents d'initier des transactions, et pas seulement aux EOA. Toute la complexité vient de la manière de réaliser cela d'une manière qui favorise le maintien d'un réseau décentralisé et de prévenir les attaques par déni de service.
Un défi clé typique est le problème de la défaillance multiple:
Si la fonction de validation de 1000 comptes dépend d'une seule valeur S, et que la valeur S actuelle rend toutes les transactions dans le pool de mémoire valides, alors une seule transaction inversant la valeur de S pourrait rendre toutes les autres transactions dans le pool de mémoire invalides. Cela permet à un attaquant d'envoyer des transactions indésirables au pool de mémoire à un coût très faible, bloquant ainsi les ressources des nœuds du réseau.
Après des années d'efforts, visant à étendre les fonctionnalités tout en limitant les risques de déni de service ( DoS ), une solution pour réaliser "l'abstraction idéale des comptes" a finalement été élaborée : ERC-4337.
Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : la vérification et l'exécution. Toutes les vérifications sont d'abord traitées, puis toutes les exécutions sont traitées. Dans la mémoire tampon, une opération de l'utilisateur n'est acceptée que lorsque la phase de vérification n'implique que son propre compte et ne lit pas les variables d'environnement. Cela permet de prévenir les attaques par double échec. De plus, des limites de gas strictes sont également imposées à l'étape de vérification.
ERC-4337 a été conçu comme une norme de protocole supplémentaire ### ERC (, car à l'époque, les développeurs de clients Ethereum se concentraient sur la fusion ) Merge ( et n'avaient pas d'énergie supplémentaire pour traiter d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise un objet appelé opération utilisateur, plutôt que des transactions conventionnelles. Cependant, récemment, nous avons réalisé qu'il était nécessaire d'écrire au moins une partie de cela dans le protocole.
Les deux raisons clés sont les suivantes :
EntryPoint en tant qu'inefficacité inhérente des contrats : chaque bundle a un coût fixe d'environ 100 000 gas, ainsi que des milliers de gas supplémentaires pour chaque opération utilisateur.
Assurer la nécessité des propriétés d'Ethereum : comme le garantit le protocole créé par la liste des inclusions qui doit être transféré aux utilisateurs abstraits de compte.
De plus, l'ERC-4337 a également étendu deux fonctionnalités :
Agents de paiement ) Paymasters ( : permet à un compte de payer des frais au nom d'un autre compte, ce qui enfreint la règle selon laquelle la phase de validation ne peut accéder qu'au compte de l'expéditeur lui-même, c'est pourquoi un traitement spécial a été introduit pour garantir la sécurité du mécanisme d'agent de paiement.
Agrégateurs): prend en charge des fonctionnalités d'agrégation de signatures, telles que l'agrégation BLS ou l'agrégation basée sur SNARK. Cela est nécessaire pour atteindre une efficacité maximale des données sur Rollup.
(# Liens de recherche existants
Discours sur l'histoire de l'abstraction des comptes:
ERC-4337:
EIP-7702:
Le code BLSWallet ) utilise la fonction d'agrégation ( :
EIP-7562) écriture de l'abstraction de compte du protocole ### :
EIP-7701( protocole d'écriture sur les comptes abstraits basés sur EOF ):
(# Le travail restant et les compromis
Le principal problème à résoudre actuellement est comment intégrer complètement l'abstraction de compte dans le protocole. Le récent EIP d'abstraction de compte populaire est l'EIP-7701, qui met en œuvre l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une section de code distincte pour la vérification. Si le compte a défini cette section de code, ce code sera exécuté lors de l'étape de vérification des transactions provenant de ce compte.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
10 J'aime
Récompense
10
5
Partager
Commentaire
0/400
SignatureAnxiety
· Il y a 17h
Avec ce gas économisé, on peut acheter quoi ?
Voir l'originalRépondre0
BlockchainRetirementHome
· 08-02 07:21
Enfin, la mise à jour de la version EVM est arrivée, Légende dorée
Voir l'originalRépondre0
Web3ExplorerLin
· 08-02 07:20
hypothèse : l'evm est comme un ancien ordinateur cherchant sa forme finale... fascinant de voir comment il reflète l'évolution de la conscience humaine, pour être honnête.
Voir l'originalRépondre0
WenAirdrop
· 08-02 07:09
Ne fais pas de bêtises, les frais de gas restent horriblement élevés, d'accord ?
Voir l'originalRépondre0
MEVictim
· 08-02 07:08
Combien de temps la réforme des frais peut-elle encore être retardée... Ne compliquez pas l'EVM.
Mise à niveau de l'EVM d'Ethereum et abstraction de compte : construire une infrastructure blockchain plus efficace et sécurisée
L'avenir possible du protocole Ethereum (6) : prospérité
La conception du protocole Ethereum comporte de nombreux "détails" qui sont cruciaux pour le succès d'Ethereum. En réalité, environ la moitié du contenu concerne différents types d'améliorations de l'EVM, le reste étant constitué de divers sujets de niche, c'est là que réside le sens de "繁荢".
Prospérité : objectif clé
Amélioration EVM
Quel problème a été résolu ?
L'EVM actuelle est difficile à analyser statiquement, ce qui rend la création d'implémentations efficaces, la vérification formelle du code et l'expansion ultérieure difficiles. De plus, l'efficacité de l'EVM est faible, rendant difficile la mise en œuvre de nombreuses formes de cryptographie avancée, sauf si un support explicite par précompilation est fourni.
Qu'est-ce que c'est et comment ça fonctionne ?
La première étape de la feuille de route d'amélioration de l'EVM actuelle est le format d'objet EVM (EOF), prévu pour être inclus dans le prochain hard fork. EOF est une série d'EIP, spécifiant une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus significative étant :
Les anciens contrats continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés, et même contraints de se convertir en code EOF (. Les nouveaux contrats bénéficieront des gains d'efficacité apportés par l'Eof - d'abord grâce à un bytecode légèrement réduit par les caractéristiques de sous-programme, puis grâce à de nouvelles fonctionnalités spécifiques à l'Eof ou à une réduction des coûts en gas.
Après l'introduction de l'Eof, les mises à niveau ultérieures sont devenues plus faciles. Le développement le plus complet à ce jour est l'extension arithmétique du module EVM ) EVM-MAX (. EVM-MAX crée un nouvel ensemble d'opérations spécifiquement pour les calculs modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui rend possible l'utilisation d'optimisations telles que la multiplication de Montgomery.
Une idée relativement récente est de combiner EVM-MAX avec la fonctionnalité SIMD (Single Instruction, Multiple Data) ), le SIMD en tant que concept d'Ethereum existe depuis longtemps, proposé pour la première fois par Greg Colvin dans l'EIP-616. Le SIMD peut être utilisé pour accélérer de nombreuses formes de cryptographie, y compris les fonctions de hachage, les STARKs 32 bits et la cryptographie basée sur les réseaux, la combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées vers les performances un appariement naturel.
Une conception générale d'un EIP combiné commencera par l'EIP-6690, puis :
python for i in range(count): mem[z_start + z_skip * count] = op( mem[x_start + x_skip * count], mem[y_start + y_skip * count] )
Dans la mise en œuvre réelle, cela sera traité de manière parallèle.
(# Liens de recherche existants
)# Le travail restant et les compromis
Actuellement, EOF est prévu pour être inclus dans le prochain hard fork. Bien qu'il soit toujours possible de l'enlever à la dernière minute - des fonctionnalités ont été temporairement retirées lors de précédents hard forks, le faire poserait cependant un grand défi. Enlever EOF signifierait que toute mise à niveau future de l'EVM devrait se faire sans EOF, bien que cela soit faisable, cela pourrait être plus difficile.
Le principal compromis de l'EVM réside dans la complexité de L1 et la complexité de l'infrastructure. L'EOF nécessite l'ajout d'un grand nombre de codes à l'implémentation de l'EVM, et la vérification statique du code est également relativement complexe. Cependant, en échange, nous pouvons simplifier les langages de haut niveau, simplifier l'implémentation de l'EVM et d'autres avantages. On peut dire que la feuille de route pour l'amélioration continue de l'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.
Un travail important à réaliser est de mettre en œuvre des fonctionnalités similaires à EVM-MAX et SIMD, et de réaliser des tests de référence sur la consommation de gas des différentes opérations cryptographiques.
Comment interagir avec d'autres parties de la feuille de route ?
L1 ajuste son EVM pour que L2 puisse également être ajusté plus facilement. Si les deux ne sont pas synchronisés, cela pourrait entraîner des incompatibilités et avoir des conséquences négatives. De plus, EVM-MAX et SIMD peuvent réduire le coût en gas de nombreux systèmes de preuve, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de nombreux précompilés par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir un impact majeur sur l'efficacité.
![Vitalik sur l'avenir potentiel d'Ethereum (6) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp###
( abstraction de compte
)# Quel problème a été résolu ?
Actuellement, les transactions ne peuvent être vérifiées que par un moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à aller au-delà de cela, permettant à la logique de vérification des comptes d'être tout code EVM arbitraire. Cela peut activer une série d'applications :
Permettre au protocole de confidentialité de fonctionner sans intermédiaire, réduisant ainsi considérablement sa complexité et éliminant un point de dépendance central clé.
Depuis que l'abstraction des comptes a été proposée en 2015, son objectif s'est également élargi pour inclure un grand nombre de "cibles pratiques", par exemple, un compte sans ETH mais possédant quelques ERC20 pourrait utiliser des ERC20 pour payer le gaz.
MPC( le calcul multipartite ) est une technologie qui existe depuis 40 ans, utilisée pour diviser une clé en plusieurs parties et les stocker sur plusieurs appareils, utilisant des techniques cryptographiques pour générer des signatures, sans avoir besoin de combiner directement ces parties de clé.
EIP-7702 est une proposition prévue pour être introduite dans le prochain hard fork. EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir la commodité de l'abstraction de compte au bénéfice de tous les utilisateurs (, y compris les utilisateurs EOA ), et vise à améliorer l'expérience de tous les utilisateurs à court terme, tout en évitant la division en deux écosystèmes.
Ce travail a commencé avec l'EIP-3074 et a finalement abouti à l'EIP-7702. L'EIP-7702 offre les "fonctionnalités de commodité" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes possédés aujourd'hui (EOA(), c'est-à-dire les comptes contrôlés par des signatures ECDSA ).
Bien que certains défis (, en particulier le défi de la "commodité", puissent être résolus par des technologies progressives telles que le calcul multipartite ou l'EIP-7702, l'objectif principal de sécurité du projet d'abstraction de compte initialement proposé ne peut être atteint qu'en revenant en arrière et en résolvant le problème original : permettre au code de contrat intelligent de contrôler la validation des transactions. La raison pour laquelle cela n'a pas encore été réalisé réside dans l'implémentation sécurisée, ce qui représente un défi.
![Vitalik concernant l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
)# Qu'est-ce que c'est et comment ça fonctionne ?
Le cœur de l'abstraction de compte est simple : permettre aux contrats intelligents d'initier des transactions, et pas seulement aux EOA. Toute la complexité vient de la manière de réaliser cela d'une manière qui favorise le maintien d'un réseau décentralisé et de prévenir les attaques par déni de service.
Un défi clé typique est le problème de la défaillance multiple:
Si la fonction de validation de 1000 comptes dépend d'une seule valeur S, et que la valeur S actuelle rend toutes les transactions dans le pool de mémoire valides, alors une seule transaction inversant la valeur de S pourrait rendre toutes les autres transactions dans le pool de mémoire invalides. Cela permet à un attaquant d'envoyer des transactions indésirables au pool de mémoire à un coût très faible, bloquant ainsi les ressources des nœuds du réseau.
Après des années d'efforts, visant à étendre les fonctionnalités tout en limitant les risques de déni de service ( DoS ), une solution pour réaliser "l'abstraction idéale des comptes" a finalement été élaborée : ERC-4337.
Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : la vérification et l'exécution. Toutes les vérifications sont d'abord traitées, puis toutes les exécutions sont traitées. Dans la mémoire tampon, une opération de l'utilisateur n'est acceptée que lorsque la phase de vérification n'implique que son propre compte et ne lit pas les variables d'environnement. Cela permet de prévenir les attaques par double échec. De plus, des limites de gas strictes sont également imposées à l'étape de vérification.
ERC-4337 a été conçu comme une norme de protocole supplémentaire ### ERC (, car à l'époque, les développeurs de clients Ethereum se concentraient sur la fusion ) Merge ( et n'avaient pas d'énergie supplémentaire pour traiter d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise un objet appelé opération utilisateur, plutôt que des transactions conventionnelles. Cependant, récemment, nous avons réalisé qu'il était nécessaire d'écrire au moins une partie de cela dans le protocole.
Les deux raisons clés sont les suivantes :
De plus, l'ERC-4337 a également étendu deux fonctionnalités :
(# Liens de recherche existants
(# Le travail restant et les compromis
Le principal problème à résoudre actuellement est comment intégrer complètement l'abstraction de compte dans le protocole. Le récent EIP d'abstraction de compte populaire est l'EIP-7701, qui met en œuvre l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une section de code distincte pour la vérification. Si le compte a défini cette section de code, ce code sera exécuté lors de l'étape de vérification des transactions provenant de ce compte.
Ce type