L'avenir possible 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 réalité, environ la moitié du contenu concerne différents types d'améliorations de l'EVM, tandis que le reste est constitué de divers sujets de niche, c'est là que réside le sens de "prospérité".
Prospérité : objectif clé
Transformer l'EVM en un "état final" performant et stable
Introduire l'abstraction des comptes dans le protocole, permettant à tous les utilisateurs de bénéficier d'un compte plus sûr et plus pratique.
Optimiser les frais de transaction économiques, améliorer la scalabilité tout en réduisant les risques
Explorer la cryptographie avancée, permettant à Ethereum de s'améliorer considérablement à long terme.
Amélioration de l'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 par un support explicite via des précompilés.
Qu'est-ce que c'est, 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. 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 :
Le code ( est exécutable, mais il est impossible de lire la séparation entre ) dans l'EVM et les données ( qui peuvent être lues, mais ne peuvent pas être exécutées ).
Interdiction des redirections dynamiques, seules les redirections statiques sont autorisées
Le code EVM ne peut plus observer les informations liées au combustible.
Ajout d'un nouveau mécanisme de sous-routine explicite.
Prospérité : amélioration de l'EVM ( continuation )
Les anciens contrats continueront d'exister et pourront être créés, même s'ils pourraient finalement être progressivement abandonnés, et les anciens contrats ( pourraient même être contraints de se convertir en code EOF ). Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par EOF------ d'abord grâce à un bytecode légèrement réduit en raison des caractéristiques de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à EOF ou à la 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 avancé 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 rend possible l'utilisation d'optimisations telles que la multiplication de Montgomery.
Une idée relativement nouvelle est de combiner EVM-MAX avec la caractéristique SIMD (Single Instruction Multiple Data) (, SIMD en tant que concept d'Ethereum existe depuis longtemps, ayant été initialement proposé par Greg Colvin dans l'EIP-616. 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 la performance un couple naturel.
Un design général d'un EIP combiné commencera par l'EIP-6690, puis :
Autoriser )i( tout nombre impair ou )ii( toute puissance de 2 n'excédant pas 2768 comme module
Pour chaque opcode EVM-MAX ) addition, soustraction, multiplication (, ajoutez une version qui n'utilise plus 3 valeurs immédiates x, y, z, mais utilise 7 valeurs immédiates : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dans le code Python, ces opcodes agissent 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 boucles et les non-boucles(, au moins pour les puissances de 2. 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(, 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 peuvent également être mises en œuvre, mais jusqu'à présent, elles ont reçu moins d'attention.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# Travail restant et 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 de grands défis. Retirer EOF signifie que toute mise à niveau future de l'EVM devrait se faire sans EOF, bien que cela soit possible, cela pourrait être plus difficile.
Le compromis principal 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 lignes de code à l'implémentation de l'EVM, et l'analyse 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 procéder à des tests de référence sur la consommation de gas des différentes opérations cryptographiques.
Comment interagir avec les autres parties de la feuille de route?
L1 ajuste son EVM de manière à ce que L2 puisse également effectuer des ajustements correspondants plus facilement. Si les deux ne s'ajustent pas de manière synchronisée, cela pourrait entraîner des incompatibilités et avoir des effets 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 rend également plus facile le remplacement de nombreuses précompilations par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir d'impact significatif sur l'efficacité.
![Vitalik sur le futur possible 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 seul moyen : la signature ECDSA. À l'origine, l'abstraction des comptes 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 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 multisignature 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 relais, ce qui réduit considérablement sa complexité et élimine un point de dépendance central clé.
Depuis que l'abstraction de compte a été proposée en 2015, son objectif s'est également élargi pour inclure de nombreux "objectifs pratiques", par exemple, un compte qui n'a pas d'ETH mais qui possède 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, 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 lors du prochain hard fork. EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir une abstraction de compte pour bénéficier à 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 la "fonctionnalité pratique" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes détenus aujourd'hui par des EOA), 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 initial ne peut être atteint qu'en revenant sur 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é réside dans la mise en œuvre sécurisée, ce qui représente un défi.
(# Qu'est-ce que c'est, comment ça fonctionne ?
Le cœur de l'abstraction des comptes 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 soit amicale pour 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 de compte idéale" a finalement été trouvée : ERC-4337.
Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : validation et exécution. Toutes les validations sont d'abord traitées, suivies de toutes les exécutions. Dans la piscine de mémoire, une opération d'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 peut prévenir les attaques par échec multiple. 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), n'ayant 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 ordinaires. Cependant, récemment, nous avons réalisé la nécessité d'incorporer au moins une partie de son contenu dans le protocole.
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 des milliers de gas supplémentaires pour chaque opération utilisateur.
Assurer la nécessité des attributs d'Ethereum : comme les garanties créées par la liste doivent être transférées au compte utilisateur abstrait.
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 l'étape de validation ne peut accéder qu'au compte de l'expéditeur lui-même, d'où la nécessité d'introduire un traitement spécial pour garantir la sécurité du mécanisme d'agent de paiement.
Agrégateurs ( : prend en charge la fonction d'agrégation de signatures, 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.
![Vitalik sur le futur possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Travail restant et compromis
Actuellement, le principal défi est de savoir comment intégrer complètement l'abstraction de compte dans le protocole. Le récent EIP d'abstraction de compte qui a gagné en popularité est l'EIP-7701, qui implémente l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une partie de code distincte pour la vérification ; si ce code est défini pour le compte, celui-ci sera exécuté lors de l'étape de vérification des transactions provenant de ce compte.
Le charme de cette méthode réside dans le fait qu'elle indique clairement les deux perspectives équivalentes de l'abstraction de compte local :
Intégrer l'EIP-4337 en tant que partie du protocole
Un nouveau type d'EOA, dont l'algorithme de signature est l'exécution de code EVM
Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la validation ------ en interdisant l'accès à l'état externe, même avec une limite de gaz fixée au départ si basse qu'elle rend les applications de résistance quantique ou de protection de la vie privée inefficaces ------ alors la sécurité de cette approche est très claire : il s'agit simplement de remplacer la validation ECDSA par une exécution de code EVM nécessitant un temps similaire.
Cependant, avec le temps, nous devons assouplir ces limites, car il est permis d'utiliser des applications de protection de la vie privée sans intermédiaire.
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.
L'avenir du protocole Ethereum : les nouvelles opportunités offertes par la mise à niveau de l'EVM et l'abstraction de compte
L'avenir possible 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 réalité, environ la moitié du contenu concerne différents types d'améliorations de l'EVM, tandis que le reste est constitué de divers sujets de niche, c'est là que réside le sens de "prospérité".
Prospérité : objectif clé
Amélioration de l'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 par un support explicite via des précompilés.
Qu'est-ce que c'est, 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. 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 :
Prospérité : amélioration de l'EVM ( continuation )
Les anciens contrats continueront d'exister et pourront être créés, même s'ils pourraient finalement être progressivement abandonnés, et les anciens contrats ( pourraient même être contraints de se convertir en code EOF ). Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par EOF------ d'abord grâce à un bytecode légèrement réduit en raison des caractéristiques de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à EOF ou à la 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 avancé 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 rend possible l'utilisation d'optimisations telles que la multiplication de Montgomery.
Une idée relativement nouvelle est de combiner EVM-MAX avec la caractéristique SIMD (Single Instruction Multiple Data) (, SIMD en tant que concept d'Ethereum existe depuis longtemps, ayant été initialement proposé par Greg Colvin dans l'EIP-616. 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 la performance un couple naturel.
Un design général 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.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# Travail restant et 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 de grands défis. Retirer EOF signifie que toute mise à niveau future de l'EVM devrait se faire sans EOF, bien que cela soit possible, cela pourrait être plus difficile.
Le compromis principal 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 lignes de code à l'implémentation de l'EVM, et l'analyse 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 procéder à des tests de référence sur la consommation de gas des différentes opérations cryptographiques.
Comment interagir avec les autres parties de la feuille de route?
L1 ajuste son EVM de manière à ce que L2 puisse également effectuer des ajustements correspondants plus facilement. Si les deux ne s'ajustent pas de manière synchronisée, cela pourrait entraîner des incompatibilités et avoir des effets 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 rend également plus facile le remplacement de nombreuses précompilations par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir d'impact significatif sur l'efficacité.
![Vitalik sur le futur possible 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 seul moyen : la signature ECDSA. À l'origine, l'abstraction des comptes 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 série 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 que l'abstraction de compte a été proposée en 2015, son objectif s'est également élargi pour inclure de nombreux "objectifs pratiques", par exemple, un compte qui n'a pas d'ETH mais qui possède 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, 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 lors du prochain hard fork. EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir une abstraction de compte pour bénéficier à 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 la "fonctionnalité pratique" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes détenus aujourd'hui par des EOA), 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 initial ne peut être atteint qu'en revenant sur 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é réside dans la mise en œuvre sécurisée, ce qui représente un défi.
(# Qu'est-ce que c'est, comment ça fonctionne ?
Le cœur de l'abstraction des comptes 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 soit amicale pour 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 de compte idéale" a finalement été trouvée : ERC-4337.
Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : validation et exécution. Toutes les validations sont d'abord traitées, suivies de toutes les exécutions. Dans la piscine de mémoire, une opération d'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 peut prévenir les attaques par échec multiple. 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), n'ayant 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 ordinaires. Cependant, récemment, nous avons réalisé la nécessité d'incorporer au moins une partie de son contenu dans le protocole.
Deux raisons clés sont les suivantes :
De plus, l'ERC-4337 a également étendu deux fonctionnalités :
![Vitalik sur le futur possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Travail restant et compromis
Actuellement, le principal défi est de savoir comment intégrer complètement l'abstraction de compte dans le protocole. Le récent EIP d'abstraction de compte qui a gagné en popularité est l'EIP-7701, qui implémente l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une partie de code distincte pour la vérification ; si ce code est défini pour le compte, celui-ci sera exécuté lors de l'étape de vérification des transactions provenant de ce compte.
Le charme de cette méthode réside dans le fait qu'elle indique clairement les deux perspectives équivalentes de l'abstraction de compte local :
Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la validation ------ en interdisant l'accès à l'état externe, même avec une limite de gaz fixée au départ si basse qu'elle rend les applications de résistance quantique ou de protection de la vie privée inefficaces ------ alors la sécurité de cette approche est très claire : il s'agit simplement de remplacer la validation ECDSA par une exécution de code EVM nécessitant un temps similaire.
Cependant, avec le temps, nous devons assouplir ces limites, car il est permis d'utiliser des applications de protection de la vie privée sans intermédiaire.