L'avenir potentiel du protocole Ethereum (six) : prospérité
Rédigé par : Vitalik Buterin
Certaines choses sont difficiles à classer dans une seule catégorie. Dans la conception du protocole Ethereum, de nombreux "détails" sont très importants pour le succès d'Ethereum. En fait, environ la moitié du contenu concerne différents types d'améliorations de l'EVM, tandis que l'autre partie est constituée de divers sujets de niche, c'est là le sens de la "prospérité".
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 pratique.
Optimiser les frais de transaction économiques, améliorer l'évolutivité tout en réduisant les risques.
Explorer des cryptographies avancées pour améliorer significativement Ethereum à long terme
amélioration EVM
Quel problème a été résolu ?
Actuellement, l'EVM est difficile à analyser statiquement, ce qui rend la création d'implémentations efficaces, la vérification formelle du code et l'extension 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 par le biais d'un soutien explicite via des précompilations.
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), qui est prévu pour être inclus dans le prochain hard fork. L'EOF est une série d'EIP qui spécifie une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus notable étant :
La séparation entre le code (exécutable, mais non lisible depuis l'EVM) et les données (lisibles, mais non exécutables)
Interdiction des sauts dynamiques, seuls les sauts statiques sont autorisés
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 être contraints de se convertir en code EOF). Les nouveaux contrats bénéficieront des gains d'efficacité apportés par EOF------tout d'abord grâce à un bytecode légèrement réduit par la fonctionnalité de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à EOF ou à la réduction des coûts de gaz.
Après l'introduction de l'Eof, les mises à niveau ultérieures sont devenues plus faciles. Le développement le plus abouti à ce jour est l'extension arithmétique du module EVM (EVM-MAX). EVM-MAX crée un ensemble de nouvelles opérations spécifiquement pour les opérations modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui permet l'utilisation d'optimisations telles que la multiplication de Montgomery.
Une idée plus récente est de combiner EVM-MAX avec des caractéristiques de traitement SIMD (Single Instruction, Multiple Data). Le SIMD, en tant que concept d'Ethereum, existe depuis longtemps, ayant été initialement proposé 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 de 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 la performance un couple 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 d'un maximum de 2768 comme module
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 fonctionnent de manière similaire à :
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.
Il est possible d'ajouter XOR, AND, OR, NOT et SHIFT (y compris les cycles et non-cycles), au moins pour les modules de puissance 2. En même temps, ajouter ISZERO (qui poussera la sortie vers la pile principale de l'EVM), ce qui sera suffisamment puissant pour réaliser la cryptographie à courbe elliptique, la cryptographie sur petits domaines (comme Poseidon, Circle STARKs), les fonctions de hachage traditionnelles (comme SHA256, KECCAK, BLAKE) et la cryptographie basée sur les réseaux. D'autres mises à niveau de l'EVM pourraient é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 le retirer à la dernière minute ------ des fonctionnalités ont été temporairement retirées lors de précédents hard forks, le faire représenterait un grand défi. Retirer EOF signifie que toute mise à niveau future de l'EVM devra être effectuée 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 avec SIMD et de procéder à des tests de référence sur la consommation de gaz pour diverses opérations cryptographiques.
Comment interagir avec les autres parties de la feuille de route ?
L1 ajuste son EVM afin que L2 puisse également être ajusté plus facilement. Si les deux ne sont pas ajustés de manière synchronisée, cela peut entraîner des incompatibilités et avoir des conséquences néfastes. De plus, EVM-MAX et SIMD peuvent réduire les coûts en gas de nombreux systèmes de preuve, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de nombreuses précompilations par du code EVM capable d'exécuter les mêmes tâches, sans que cela n'impacte significativement l'efficacité.
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 n'importe quel code EVM. Cela peut activer une gamme d'applications :
Passer à la cryptographie résistant aux quantiques
Rotation des anciennes clés (largement considéré comme une pratique de sécurité recommandée)
Portefeuille multi-signature et portefeuille de récupération social
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 relais, ce qui réduit considérablement sa complexité et élimine un point de dépendance central clé.
Depuis la proposition de l'abstraction des comptes en 2015, son objectif s'est également élargi pour inclure de nombreux « objectifs de commodité », par exemple, un compte n'ayant pas d'ETH mais possédant certains ERC20 peut payer des frais de gas avec des ERC20. Voici un tableau récapitulatif de ces objectifs :
MPC (calcul multipartite) est une technologie existante depuis 40 ans, utilisée pour diviser une clé en plusieurs parties et les stocker sur plusieurs dispositifs, en 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 concernant la fourniture de la commodité d'abstraction de compte au bénéfice de tous les utilisateurs (y compris les utilisateurs EOA), visant à améliorer l'expérience de tous les utilisateurs à court terme et à éviter 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 pratiques » de l'abstraction des comptes à tous les utilisateurs, y compris les EOA d'aujourd'hui (comptes détenus par des entités externes, c'est-à-dire des comptes contrôlés par des signatures ECDSA).
On peut voir sur le graphique que, 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 de sécurité principal du projet d'abstraction de compte initialement proposé ne peut être atteint qu'en revenant sur et en résolvant le problème original : permettre au code des contrats intelligents de contrôler la validation des transactions. La raison pour laquelle cela n'a pas encore été réalisé est la mise en œuvre sécurisée, qui représente un défi.
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 mise en œuvre de cela d'une manière qui favorise le maintien d'un réseau décentralisé et prévient 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 actuelle S 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 vers le pool de mémoire à un coût très faible, ce qui obstrue les ressources des nœuds du réseau.
Après des années d'efforts visant à étendre les fonctionnalités tout en limitant le risque d'attaque par déni de service (DoS), une solution pour réaliser "l'abstraction idéale des comptes" a finalement été trouvée : ERC-4337.
Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux phases : validation et exécution. Toutes les validations sont d'abord traitées, puis toutes les exécutions. Dans la mémoire tampon, une opération utilisateur n'est acceptée que si la phase de validation 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 strictes de gas sont également imposées à l'étape de validation.
ERC-4337 a été conçu comme un standard 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 des objets appelés opérations utilisateur, plutôt que des transactions conventionnelles. Cependant, nous avons récemment réalisé qu'il était nécessaire d'écrire au moins une partie de ce contenu dans le protocole.
Les deux raisons clés sont les suivantes :
EntryPoint en tant qu'inefficacité inhérente au contrat : chaque bundle a un coût fixe d'environ 100 000 gas, ainsi que plusieurs milliers de gas supplémentaires pour chaque opération utilisateur.
Assurer la nécessité des attributs Ethereum : comme la liste incluse qui crée des garanties devant être transférées aux utilisateurs abstraits de compte.
De plus, l'ERC-4337 a également étendu deux fonctionnalités :
Agents de paiement (Paymasters) : Permettent à un compte de payer des frais au nom d'un autre compte, ce qui viole la règle selon laquelle la phase de validation ne peut accéder qu'au compte de l'expéditeur lui-même. Par conséquent, un traitement spécial a été introduit pour garantir la sécurité du mécanisme des agents de paiement.
Agrégateurs : prennent en charge la fonction d'agrégation de signature, comme l'agrégation BLS ou l'agrégation basée sur SNARK. Cela est nécessaire pour atteindre la meilleure efficacité des données sur Rollup.
Liens de recherche existants
Discours sur l'histoire de l'abstraction de compte :
ERC-4337 :
EIP-7702：
Code BLSWallet (utilisant la fonction d'agrégation) :
EIP-7562 (abstraction de compte pour le protocole d'écriture) :
EIP-7701 (protocole d'abstraction de compte d'écriture basé sur EOF) :
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.
17 J'aime
Récompense
17
5
Partager
Commentaire
0/400
TokenRationEater
· 07-22 23:46
Vitalik Buterin recommence à rêver, n'est-ce pas ?
Voir l'originalRépondre0
AirdropBlackHole
· 07-22 00:12
Connaissance chaude : all in Éther
Voir l'originalRépondre0
AirdropCollector
· 07-21 05:33
Vitalik Buterin continue à travailler sur le protocole
Voir l'originalRépondre0
SelfStaking
· 07-21 05:30
Vitalik Buterin a vraiment un grand ton, l'analyse statique est difficile, tant pis.
Voir l'originalRépondre0
CryptoTarotReader
· 07-21 05:23
Alors on change l'evm comme ça ? Autant réduire le gas~
L'avenir prospère d'Ethereum : amélioration de l'EVM, abstraction de compte et mise à niveau du protocole
L'avenir potentiel du protocole Ethereum (six) : prospérité
Rédigé par : Vitalik Buterin
Certaines choses sont difficiles à classer dans une seule catégorie. Dans la conception du protocole Ethereum, de nombreux "détails" sont très importants pour le succès d'Ethereum. En fait, environ la moitié du contenu concerne différents types d'améliorations de l'EVM, tandis que l'autre partie est constituée de divers sujets de niche, c'est là le sens de la "prospérité".
Prospérité : objectif clé
amélioration EVM
Quel problème a été résolu ?
Actuellement, l'EVM est difficile à analyser statiquement, ce qui rend la création d'implémentations efficaces, la vérification formelle du code et l'extension 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 par le biais d'un soutien explicite via des précompilations.
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), qui est prévu pour être inclus dans le prochain hard fork. L'EOF est une série d'EIP qui spécifie une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus notable étant :
Les anciens contrats continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés (et même être contraints de se convertir en code EOF). Les nouveaux contrats bénéficieront des gains d'efficacité apportés par EOF------tout d'abord grâce à un bytecode légèrement réduit par la fonctionnalité de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à EOF ou à la réduction des coûts de gaz.
Après l'introduction de l'Eof, les mises à niveau ultérieures sont devenues plus faciles. Le développement le plus abouti à ce jour est l'extension arithmétique du module EVM (EVM-MAX). EVM-MAX crée un ensemble de nouvelles opérations spécifiquement pour les opérations modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui permet l'utilisation d'optimisations telles que la multiplication de Montgomery.
Une idée plus récente est de combiner EVM-MAX avec des caractéristiques de traitement SIMD (Single Instruction, Multiple Data). Le SIMD, en tant que concept d'Ethereum, existe depuis longtemps, ayant été initialement proposé 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 de 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 la performance un couple naturel.
Une conception générale d'un EIP combiné commencera par l'EIP-6690, puis :
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 le retirer à la dernière minute ------ des fonctionnalités ont été temporairement retirées lors de précédents hard forks, le faire représenterait un grand défi. Retirer EOF signifie que toute mise à niveau future de l'EVM devra être effectuée 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 avec SIMD et de procéder à des tests de référence sur la consommation de gaz pour diverses opérations cryptographiques.
Comment interagir avec les autres parties de la feuille de route ?
L1 ajuste son EVM afin que L2 puisse également être ajusté plus facilement. Si les deux ne sont pas ajustés de manière synchronisée, cela peut entraîner des incompatibilités et avoir des conséquences néfastes. De plus, EVM-MAX et SIMD peuvent réduire les coûts en gas de nombreux systèmes de preuve, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de nombreuses précompilations par du code EVM capable d'exécuter les mêmes tâches, sans que cela n'impacte significativement l'efficacité.
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 n'importe quel code EVM. Cela peut activer une gamme d'applications :
Permettre au protocole de confidentialité de fonctionner sans relais, ce qui réduit considérablement sa complexité et élimine un point de dépendance central clé.
Depuis la proposition de l'abstraction des comptes en 2015, son objectif s'est également élargi pour inclure de nombreux « objectifs de commodité », par exemple, un compte n'ayant pas d'ETH mais possédant certains ERC20 peut payer des frais de gas avec des ERC20. Voici un tableau récapitulatif de ces objectifs :
MPC (calcul multipartite) est une technologie existante depuis 40 ans, utilisée pour diviser une clé en plusieurs parties et les stocker sur plusieurs dispositifs, en 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 concernant la fourniture de la commodité d'abstraction de compte au bénéfice de tous les utilisateurs (y compris les utilisateurs EOA), visant à améliorer l'expérience de tous les utilisateurs à court terme et à éviter 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 pratiques » de l'abstraction des comptes à tous les utilisateurs, y compris les EOA d'aujourd'hui (comptes détenus par des entités externes, c'est-à-dire des comptes contrôlés par des signatures ECDSA).
On peut voir sur le graphique que, 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 de sécurité principal du projet d'abstraction de compte initialement proposé ne peut être atteint qu'en revenant sur et en résolvant le problème original : permettre au code des contrats intelligents de contrôler la validation des transactions. La raison pour laquelle cela n'a pas encore été réalisé est la mise en œuvre sécurisée, qui représente un défi.
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 mise en œuvre de cela d'une manière qui favorise le maintien d'un réseau décentralisé et prévient 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 actuelle S 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 vers le pool de mémoire à un coût très faible, ce qui obstrue les ressources des nœuds du réseau.
Après des années d'efforts visant à étendre les fonctionnalités tout en limitant le risque d'attaque par déni de service (DoS), une solution pour réaliser "l'abstraction idéale des comptes" a finalement été trouvée : ERC-4337.
Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux phases : validation et exécution. Toutes les validations sont d'abord traitées, puis toutes les exécutions. Dans la mémoire tampon, une opération utilisateur n'est acceptée que si la phase de validation 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 strictes de gas sont également imposées à l'étape de validation.
ERC-4337 a été conçu comme un standard 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 des objets appelés opérations utilisateur, plutôt que des transactions conventionnelles. Cependant, nous avons récemment réalisé qu'il était nécessaire d'écrire au moins une partie de ce contenu 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
restant