L'avenir possible du protocole Ethereum (six) : prospérité
Dans la conception du protocole Ethereum, de nombreux "détails" sont cruciaux pour son succès. 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" à haute performance et stable
Introduire l'abstraction des comptes dans le protocole, permettant à tous les utilisateurs de profiter d'un compte plus sécurisé et pratique.
Optimiser les frais de transaction économiques, améliorer la scalabilité tout en réduisant les risques
Explorer la cryptographie avancée pour améliorer significativement Ethereum à long terme.
Amélioration de l'EVM
a résolu quel problème ?
Actuellement, l'EVM est difficile à analyser statiquement, ce qui rend difficile la création d'implémentations efficaces, la vérification formelle du code et l'extension ultérieure. 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é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), prévu pour être inclus dans le prochain hard fork. EOF est une série de EIP, spécifiant une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus remarquable étant :
Le code ( peut être exécuté, mais il est impossible de lire ) à partir de l'EVM, et les données ( peuvent être lues, mais ne peuvent pas être exécutées entre la séparation de ).
Interdire les redirections dynamiques, seules les redirections statiques sont autorisées
Le code EVM ne peut plus observer les informations liées au carburant.
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 au profit des anciens contrats ( et même éventuellement convertis de force en code EOF ). Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par l'Eof - d'abord grâce à un bytecode légèrement réduit par les caractéristiques de sous-routine, puis avec les nouvelles fonctionnalités spécifiques à l'Eof ou les coûts en gas réduits.
Après l'introduction de l'EOF, les mises à niveau supplémentaires 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 l'arithmétique modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui permet d'utiliser des optimisations telles que la multiplication de Montgomery.
Une idée relativement nouvelle est de combiner EVM-MAX avec la fonctionnalité SIMD (Single Instruction Multiple Data) (. SIMD, en tant que concept d'Ethereum, existe depuis longtemps, ayant été proposé pour la première fois 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 des réseaux. La combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées vers la performance un couple naturel.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Un design général d'un EIP combiné commencera avec 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 (, ajouter 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 agissent de manière 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.
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 comme modulo. En même temps, l'ajout de ISZERO) poussera la sortie vers la pile principale de l'EVM(, ce qui sera suffisamment puissant pour réaliser la cryptographie par courbes elliptiques, la cryptographie sur petits domaines) comme Poseidon, Circle STARKs(, des 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 peu d'attention.
) lien de recherche existant
EOF:
EVM-MAX:
SIMD:
Le travail restant et les compromis
Actuellement, le plan est d'inclure EOF 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, faire cela serait très difficile. Retirer EOF signifie que toute mise à niveau future de l'EVM devra se faire sans EOF, bien que cela soit faisable, cela pourrait être plus compliqué.
Le principal compromis de l'EVM réside dans la complexité de L1 et la complexité des infrastructures. 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 bénéficier d'autres avantages. On peut dire que la feuille de route priorisant l'amélioration continue d'Ethereum L1 devrait inclure et s'appuyer sur EOF.
Un travail important à réaliser est de mettre en œuvre des fonctionnalités similaires à EVM-MAX ajoutées à SIMD, et de réaliser des tests de référence sur la consommation de gas pour diverses opérations cryptographiques.
Comment interagir avec les autres parties de la feuille de route ?
L1 ajuste son EVM pour permettre à L2 d'effectuer des ajustements correspondants plus facilement. Si les deux ne sont pas synchronisés, cela pourrait entraîner des incompatibilités et des impacts négatifs. 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 précompilés par du code EVM pouvant exécuter les mêmes tâches, ce qui ne devrait pas avoir un 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
) a résolu quel problème ?
Actuellement, les transactions ne peuvent être vérifiées que par un seul moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à dépasser 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 résistant aux quantiques
Le remplacement de l'ancienne clé ### est largement considéré comme une pratique de sécurité recommandée (
Portefeuille multi-signature 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 grande valeur
Permettre au protocole de confidentialité de fonctionner sans intermédiaire, réduisant considérablement sa complexité et éliminant un point de dépendance central clé.
Depuis que l'abstraction de compte a été proposée en 2015, son objectif s'est également étendu pour inclure de nombreux "objectifs de commodité", par exemple, un compte sans ETH mais possédant des ERC20 pourrait utiliser des ERC20 pour payer le gas.
MPC) le calcul multipartite ( est une technologie qui a 40 ans d'histoire, 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 dans la prochaine fourche dure. EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir une facilité 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 la "fonctionnalité de commodité" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes possédés aujourd'hui par EOA), c'est-à-dire les comptes contrôlés par la signature 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 EIP-7702, l'objectif de sécurité principal du projet d'abstraction de compte, initialement proposé, 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 été réalisé jusqu'à présent réside dans la mise en œuvre sécurisée, ce qui représente un défi.
![Vitalik sur 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 des comptes est simple : permettre aux contrats intelligents d'initier des transactions, et pas seulement aux EOA. Toute la complexité provient de la manière de réaliser cela d'une manière qui soit conviviale 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 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 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 phases : vérification et exécution. Toutes les vérifications sont d'abord traitées, puis toutes les exécutions. Dans la mémoire, une opération des utilisateurs 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 d'éviter les attaques par échec multiple. De plus, des limites strictes de gas sont également imposées à l'étape de vérification.
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 classiques. Cependant, récemment, nous avons pris conscience de la nécessité d'écrire au moins une partie de son contenu dans le protocole.
Les deux raisons clés sont les suivantes :
EntryPoint en tant qu'inefficacité inhérente du 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 Ethereum : comme les garanties créées par la liste incluse qui doivent être transférées au compte des utilisateurs abstraits.
![Vitalik sur le futur possible d'Ethereum (six) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
De plus, l'ERC-4337 étend deux fonctionnalités :
Agence 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, d'où l'introduction d'un traitement spécial pour assurer la sécurité du mécanisme d'agence 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 réaliser 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:
Le code BLSWallet ) utilise la fonction d'agrégation ###:
EIP-7562( écrit dans le protocole d'abstraction de compte ) :
EIP-7701( Compte abstrait d'écriture basé sur le protocole EOF ):
( le travail restant et les compromis
Actuellement, le principal problème à résoudre est comment introduire complètement l'abstraction des comptes dans le protocole. La proposition d'abstraction des comptes du protocole récemment populaire est l'EIP-7701, qui réalise l'abstraction des comptes au-dessus de l'EOF. Un compte peut avoir une partie de code distincte pour la validation. Si ce code est configuré pour le compte, il sera exécuté lors de l'étape de validation 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.
17 J'aime
Récompense
17
5
Reposter
Partager
Commentaire
0/400
GweiTooHigh
· 08-12 00:28
L'abstraction de compte peut-elle réellement se généraliser ?
Voir l'originalRépondre0
MEVictim
· 08-10 08:39
C'est juste une question d'EVM, c'est ennuyeux.
Voir l'originalRépondre0
BlockchainDecoder
· 08-10 08:39
Selon les données de l'article RV de 2022, l'efficacité de la pile de l'architecture EVM actuelle n'est que de 42 %, ce qui nécessite effectivement une optimisation.
Voir l'originalRépondre0
PessimisticOracle
· 08-10 08:39
On a parlé pendant longtemps, mais n'est-ce pas toujours du vent ? Si ça se concrétise, je perds.
Aperçus futurs de l'Ethereum : mise à niveau de l'EVM et abstraction de compte menant à une nouvelle phase de prospérité
L'avenir possible du protocole Ethereum (six) : prospérité
Dans la conception du protocole Ethereum, de nombreux "détails" sont cruciaux pour son succès. 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 de l'EVM
a résolu quel problème ?
Actuellement, l'EVM est difficile à analyser statiquement, ce qui rend difficile la création d'implémentations efficaces, la vérification formelle du code et l'extension ultérieure. 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é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), prévu pour être inclus dans le prochain hard fork. EOF est une série de EIP, spécifiant une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus remarquable étant :
Les anciens contrats continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés au profit des anciens contrats ( et même éventuellement convertis de force en code EOF ). Les nouveaux contrats bénéficieront des améliorations d'efficacité apportées par l'Eof - d'abord grâce à un bytecode légèrement réduit par les caractéristiques de sous-routine, puis avec les nouvelles fonctionnalités spécifiques à l'Eof ou les coûts en gas réduits.
Après l'introduction de l'EOF, les mises à niveau supplémentaires 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 l'arithmétique modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, ce qui permet d'utiliser des optimisations telles que la multiplication de Montgomery.
Une idée relativement nouvelle est de combiner EVM-MAX avec la fonctionnalité SIMD (Single Instruction Multiple Data) (. SIMD, en tant que concept d'Ethereum, existe depuis longtemps, ayant été proposé pour la première fois 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 des réseaux. La combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées vers la performance un couple naturel.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Un design général d'un EIP combiné commencera avec 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.
) lien de recherche existant
Le travail restant et les compromis
Actuellement, le plan est d'inclure EOF 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, faire cela serait très difficile. Retirer EOF signifie que toute mise à niveau future de l'EVM devra se faire sans EOF, bien que cela soit faisable, cela pourrait être plus compliqué.
Le principal compromis de l'EVM réside dans la complexité de L1 et la complexité des infrastructures. 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 bénéficier d'autres avantages. On peut dire que la feuille de route priorisant l'amélioration continue d'Ethereum L1 devrait inclure et s'appuyer sur EOF.
Un travail important à réaliser est de mettre en œuvre des fonctionnalités similaires à EVM-MAX ajoutées à SIMD, et de réaliser des tests de référence sur la consommation de gas pour diverses opérations cryptographiques.
Comment interagir avec les autres parties de la feuille de route ?
L1 ajuste son EVM pour permettre à L2 d'effectuer des ajustements correspondants plus facilement. Si les deux ne sont pas synchronisés, cela pourrait entraîner des incompatibilités et des impacts négatifs. 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 précompilés par du code EVM pouvant exécuter les mêmes tâches, ce qui ne devrait pas avoir un 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
) a résolu quel problème ?
Actuellement, les transactions ne peuvent être vérifiées que par un seul moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à dépasser 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 considérablement sa complexité et éliminant un point de dépendance central clé.
Depuis que l'abstraction de compte a été proposée en 2015, son objectif s'est également étendu pour inclure de nombreux "objectifs de commodité", par exemple, un compte sans ETH mais possédant des ERC20 pourrait utiliser des ERC20 pour payer le gas.
MPC) le calcul multipartite ( est une technologie qui a 40 ans d'histoire, 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 dans la prochaine fourche dure. EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir une facilité 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 la "fonctionnalité de commodité" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes possédés aujourd'hui par EOA), c'est-à-dire les comptes contrôlés par la signature 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 EIP-7702, l'objectif de sécurité principal du projet d'abstraction de compte, initialement proposé, 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 été réalisé jusqu'à présent réside dans la mise en œuvre sécurisée, ce qui représente un défi.
![Vitalik sur 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 des comptes est simple : permettre aux contrats intelligents d'initier des transactions, et pas seulement aux EOA. Toute la complexité provient de la manière de réaliser cela d'une manière qui soit conviviale 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 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 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 phases : vérification et exécution. Toutes les vérifications sont d'abord traitées, puis toutes les exécutions. Dans la mémoire, une opération des utilisateurs 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 d'éviter les attaques par échec multiple. De plus, des limites strictes de gas sont également imposées à l'étape de vérification.
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 classiques. Cependant, récemment, nous avons pris conscience de la nécessité d'écrire au moins une partie de son contenu dans le protocole.
Les deux raisons clés sont les suivantes :
![Vitalik sur le futur possible d'Ethereum (six) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
De plus, l'ERC-4337 étend deux fonctionnalités :
( Liens de recherche existants
( le travail restant et les compromis
Actuellement, le principal problème à résoudre est comment introduire complètement l'abstraction des comptes dans le protocole. La proposition d'abstraction des comptes du protocole récemment populaire est l'EIP-7701, qui réalise l'abstraction des comptes au-dessus de l'EOF. Un compte peut avoir une partie de code distincte pour la validation. Si ce code est configuré pour le compte, il sera exécuté lors de l'étape de validation des transactions provenant de ce compte.
Cette méthode est fascinante.