L'avenir possible du protocole Ethereum (6) : prospérité
Certaines choses sont difficiles à classer. Dans la conception du protocole Ethereum, de nombreux "détails" sont cruciaux pour le succès d'Ethereum. Environ la moitié du contenu concerne différents types d'améliorations EVM, le reste étant constitué de divers sujets de niche, c'est là tout le sens de "prospérité".
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 bénéficier de comptes plus sûrs et plus pratiques.
Optimiser les frais de transaction économiques, améliorer la scalabilité tout en réduisant les risques
Explorer la cryptographie avancée pour améliorer de manière significative Ethereum à 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'extension ultérieure difficiles. De plus, l'efficacité de l'EVM est faible, ce qui complique la mise en œuvre de nombreux cryptographies avancées, sauf si un support explicite est fourni par des précompilations.
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), prévu pour être inclus dans le prochain hard fork. EOF est une série de EIP qui spécifie une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus remarquable étant :
Le code ( peut être exécuté, mais ne peut pas être lu depuis l'EVM. Les données ) peuvent être lues, mais ne peuvent pas exécuter la séparation (.
Interdiction de redirection dynamique, seule la redirection statique est autorisée
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, 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 par le biais d'un code byte légèrement réduit grâce aux caractéristiques de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à EOF ou à la réduction des coûts de gas.
Après l'introduction de EOF, il est devenu plus facile de procéder à des mises à niveau, le développement le plus avancé étant l'extension arithmétique du module EVM ) EVM-MAX (. EVM-MAX crée un ensemble de nouvelles opérations spécifiquement destinées aux 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 plus récente est de combiner EVM-MAX avec la caractéristique SIMD (Single Instruction Multiple Data) ), SIMD en tant que concept d'Ethereum existe depuis longtemps, 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 les réseaux. La combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées performances un appariement naturel.
Une conception générale d'un ensemble de EIP commencera par le EIP-6690, puis :
Autoriser (i) tout nombre impair ou (ii) toute puissance de 2 ne dépassant pas 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 qui utilise 7 constantes immédiates : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dans le code Python, le rôle de ces opcodes est similaire à :
python
pour i dans la plage(compte):
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 des puissances de 2. En même temps, ajouter ISZERO( 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 champs( 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 peuvent également être mises en œuvre, mais jusqu'à présent, elles ont reçu moins d'attention.
(# 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 - certaines fonctionnalités ont été temporairement retirées lors de précédents hard forks, le faire poserait toutefois de grands défis. Retirer EOF signifie 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é des infrastructures. 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 qui privilégie l'amélioration continue d'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.
Un travail important à réaliser est d'implémenter des fonctionnalités similaires à EVM-MAX avec SIMD, et de réaliser des tests de référence sur la consommation de gaz des différentes opérations cryptographiques.
)# Comment interagir avec les autres parties de la feuille de route?
L1 ajuste son EVM afin que L2 puisse également s'adapter plus facilement. Si les deux ne sont pas ajustés de manière synchronisée, cela pourrait entraîner des incompatibilités et des impacts négatifs. 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 plus de précompilations par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas affecter considérablement l'efficacité.
abstraction de compte
Quel problème a été résolu ?
Actuellement, la vérification des transactions ne peut se faire que par un moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à dépasser 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ésistante aux quantiques
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
Utilisez une clé pour des opérations de faible valeur, utilisez 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, réduisant ainsi significativement sa complexité et éliminant un point de dépendance central clé.
Depuis la proposition de l'abstraction des comptes en 2015, son objectif a également été élargi pour inclure un grand nombre de "cibles de commodité", par exemple, un compte sans ETH mais possédant quelques ERC20 pourrait payer les frais de gas avec des ERC20.
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 à 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 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 fournit la "fonctionnalité pratique" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes détenus aujourd'hui, 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, le principal objectif de sécurité du projet d'abstraction de compte initialement proposé ne peut être atteint qu'en revenant sur le problème d'origine et en le résolvant : 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 la mise en œuvre sécurisée, ce qui constitue un défi.
)# Qu'est-ce que c'est, 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 favorable à l'entretien 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 la mempool valides, alors une seule transaction inversant la valeur de S pourrait rendre toutes les autres transactions dans la mempool invalides. Cela permettrait à un attaquant d'envoyer des transactions indésirables à la mempool à 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é trouvée : ERC-4337.
Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux phases : la vérification et l'exécution. Toutes les vérifications sont d'abord traitées, puis toutes les exécutions. Dans la pool de mémoire, 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 de variables d'environnement. Cela peut prévenir les attaques de double dépense. De plus, des limites de gaz strictes 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 (, 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, nous avons récemment réalisé la nécessité d'incorporer au moins une partie de cela 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 le besoin de transférer des garanties créées par la liste vers les utilisateurs d'abstraction de compte.
De plus, l'ERC-4337 étend deux fonctionnalités :
Agents de paiement ) Paymasters ( : permet à un compte de payer des frais au nom d'un autre compte, ce qui viole la règle selon laquelle seule le compte de l'expéditeur peut être accessible pendant la phase de validation. Par conséquent, un traitement spécial a été introduit pour garantir la sécurité du mécanisme des agents de paiement.
Agrégateurs): supporte 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.
(# Le travail restant et les compromis
Actuellement, le principal problème à résoudre est de savoir comment introduire complètement l'abstraction de compte dans le protocole. Le protocole d'abstraction de compte récemment populaire est l'EIP-7701, qui met en œuvre l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une partie de code distincte pour la validation. Si le compte a défini cette partie de code, celle-ci sera exécutée lors de l'étape de validation des transactions provenant de ce compte.
L'attrait de cette méthode réside dans le fait qu'elle indique clairement les deux perspectives équivalentes de l'abstraction des comptes locaux :
Intégrer l'EIP-4337 en tant que protocole.
Un nouveau type d'EOA, dont l'algorithme de signature est l'exécution du code EVM.
Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la vérification - interdisant l'accès à l'état externe, et même les limites de gas fixées au début étant si basses qu'elles sont inefficaces pour les applications de résistance quantique ou de protection de la vie privée - alors la sécurité de cette approche est très claire : il suffit de remplacer la vérification 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 très important de permettre aux applications de protection de la vie privée de fonctionner sans relais, ainsi que la résistance quantique. Pour cela, nous devons trouver des moyens plus flexibles de traiter les risques de déni de service )DoS(, sans exiger que les étapes de vérification soient extrêmement simplifiées.
Le principal compromis semble être "écrire rapidement une solution qui satisfait moins de personnes" contre "attendre plus longtemps
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.
18 J'aime
Récompense
18
5
Reposter
Partager
Commentaire
0/400
LonelyAnchorman
· Il y a 1h
Quand est-ce que ce truc EVM va enfin être plus fluide...
Voir l'originalRépondre0
GateUser-2fce706c
· Il y a 14h
Profitez de l'opportunité d'amélioration de l'EVM pour établir un grand plan... J'avais déjà anticipé cette direction de développement.
Voir l'originalRépondre0
PoetryOnChain
· Il y a 14h
C'est bientôt fini, V God a enfin compris.
Voir l'originalRépondre0
wagmi_eventually
· Il y a 14h
Cette mise à jour est vraiment géniale.
Voir l'originalRépondre0
ThreeHornBlasts
· Il y a 14h
Ne vous faites plus avoir par les frais de gas à l'avenir.
Perspectives futures du protocole Ethereum : Améliorations de l'EVM et abstraction de compte menant à la prospérité
L'avenir possible du protocole Ethereum (6) : prospérité
Certaines choses sont difficiles à classer. Dans la conception du protocole Ethereum, de nombreux "détails" sont cruciaux pour le succès d'Ethereum. Environ la moitié du contenu concerne différents types d'améliorations EVM, le reste étant constitué de divers sujets de niche, c'est là tout 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'extension ultérieure difficiles. De plus, l'efficacité de l'EVM est faible, ce qui complique la mise en œuvre de nombreux cryptographies avancées, sauf si un support explicite est fourni par des précompilations.
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), prévu pour être inclus dans le prochain hard fork. EOF est une série de EIP qui spécifie 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, 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 par le biais d'un code byte légèrement réduit grâce aux caractéristiques de sous-routine, puis grâce aux nouvelles fonctionnalités spécifiques à EOF ou à la réduction des coûts de gas.
Après l'introduction de EOF, il est devenu plus facile de procéder à des mises à niveau, le développement le plus avancé étant l'extension arithmétique du module EVM ) EVM-MAX (. EVM-MAX crée un ensemble de nouvelles opérations spécifiquement destinées aux 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 plus récente est de combiner EVM-MAX avec la caractéristique SIMD (Single Instruction Multiple Data) ), SIMD en tant que concept d'Ethereum existe depuis longtemps, 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 les réseaux. La combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées performances un appariement naturel.
Une conception générale d'un ensemble de EIP commencera par le EIP-6690, puis :
python pour i dans la plage(compte): 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.
(# 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 - certaines fonctionnalités ont été temporairement retirées lors de précédents hard forks, le faire poserait toutefois de grands défis. Retirer EOF signifie 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é des infrastructures. 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 qui privilégie l'amélioration continue d'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.
Un travail important à réaliser est d'implémenter des fonctionnalités similaires à EVM-MAX avec SIMD, et de réaliser des tests de référence sur la consommation de gaz des différentes opérations cryptographiques.
)# Comment interagir avec les autres parties de la feuille de route?
L1 ajuste son EVM afin que L2 puisse également s'adapter plus facilement. Si les deux ne sont pas ajustés de manière synchronisée, cela pourrait entraîner des incompatibilités et des impacts négatifs. 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 plus de précompilations par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas affecter considérablement l'efficacité.
abstraction de compte
Quel problème a été résolu ?
Actuellement, la vérification des transactions ne peut se faire que par un moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à dépasser 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, réduisant ainsi significativement sa complexité et éliminant un point de dépendance central clé.
Depuis la proposition de l'abstraction des comptes en 2015, son objectif a également été élargi pour inclure un grand nombre de "cibles de commodité", par exemple, un compte sans ETH mais possédant quelques ERC20 pourrait payer les frais de gas avec des ERC20.
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 à 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 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 fournit la "fonctionnalité pratique" de l'abstraction de compte à tous les utilisateurs, y compris les comptes externes détenus aujourd'hui, 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, le principal objectif de sécurité du projet d'abstraction de compte initialement proposé ne peut être atteint qu'en revenant sur le problème d'origine et en le résolvant : 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 la mise en œuvre sécurisée, ce qui constitue un défi.
)# Qu'est-ce que c'est, 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 favorable à l'entretien 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 la mempool valides, alors une seule transaction inversant la valeur de S pourrait rendre toutes les autres transactions dans la mempool invalides. Cela permettrait à un attaquant d'envoyer des transactions indésirables à la mempool à 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é trouvée : ERC-4337.
Le fonctionnement d'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux phases : la vérification et l'exécution. Toutes les vérifications sont d'abord traitées, puis toutes les exécutions. Dans la pool de mémoire, 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 de variables d'environnement. Cela peut prévenir les attaques de double dépense. De plus, des limites de gaz strictes 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 (, 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, nous avons récemment réalisé la nécessité d'incorporer au moins une partie de cela dans le protocole.
Deux raisons clés sont les suivantes :
De plus, l'ERC-4337 étend deux fonctionnalités :
(# Le travail restant et les compromis
Actuellement, le principal problème à résoudre est de savoir comment introduire complètement l'abstraction de compte dans le protocole. Le protocole d'abstraction de compte récemment populaire est l'EIP-7701, qui met en œuvre l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une partie de code distincte pour la validation. Si le compte a défini cette partie de code, celle-ci sera exécutée lors de l'étape de validation des transactions provenant de ce compte.
L'attrait de cette méthode réside dans le fait qu'elle indique clairement les deux perspectives équivalentes de l'abstraction des comptes locaux :
Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la vérification - interdisant l'accès à l'état externe, et même les limites de gas fixées au début étant si basses qu'elles sont inefficaces pour les applications de résistance quantique ou de protection de la vie privée - alors la sécurité de cette approche est très claire : il suffit de remplacer la vérification 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 très important de permettre aux applications de protection de la vie privée de fonctionner sans relais, ainsi que la résistance quantique. Pour cela, nous devons trouver des moyens plus flexibles de traiter les risques de déni de service )DoS(, sans exiger que les étapes de vérification soient extrêmement simplifiées.
Le principal compromis semble être "écrire rapidement une solution qui satisfait moins de personnes" contre "attendre plus longtemps