Auteur : Vitalik Buterin
Compilé par : Deng Tong, Golden Finance
Un merci spécial à Justin Drake, Hsiao-wei Wang, @antonttc et Francesco pour leurs commentaires et critiques.
Initialement, « fusion » faisait référence à l’événement le plus important de l’histoire du protocole Ethereum depuis son lancement : la transition tant attendue et durement gagnée du Proof-of-Work au Proof-of-Stake. Aujourd'hui, Ethereum est un système de preuve de participation stable et fonctionnel depuis près de deux ans, qui a extrêmement bien fonctionné en termes de stabilité, de performances et d'évitement des risques de centralisation. Cependant, il existe encore des domaines importants dans lesquels la preuve de participation doit être améliorée.
Ma feuille de route pour 2023 la décompose en plusieurs parties : améliorations des fonctionnalités techniques telles que la stabilité, les performances et l'accessibilité aux validateurs plus petits, et changements économiques pour faire face aux risques de centralisation. Le premier a repris le titre de "Merge", tandis que le second est devenu une partie de "The Scourge".
Cet article se concentrera sur la partie « fusion » : que peut-on améliorer d'autre dans la conception technique de la preuve de participation, et quels sont les moyens d'obtenir ces améliorations ?
Il ne s'agit pas d'une liste exhaustive des améliorations qui pourraient être apportées à la preuve de participation, mais plutôt d'une liste d'idées qui sont activement examinées.
Finalité du slot unique et démocratisation du jalonnement
Quel problème résolvons-nous ?
Aujourd'hui, il faut 2 à 3 époques (~ 15 minutes) pour terminer un bloc et il faut 32 ETH pour devenir un jalonneur. Il s’agissait à l’origine d’un compromis visant à trouver un équilibre entre trois objectifs :
Maximiser le nombre de validateurs pouvant participer au staking (cela signifie directement minimiser l'ETH minimum requis pour le staking)
Minimiser le temps de réalisation
Minimiser la surcharge des nœuds en cours d'exécution
Ces trois objectifs sont en conflit les uns avec les autres : pour atteindre une finalité économique (c'est-à-dire qu'un attaquant devrait détruire une grande quantité d'ETH pour récupérer un bloc finalisé), chaque validateur devrait signer deux messages par finalisation. Donc, si vous avez de nombreux validateurs, soit le traitement de toutes les signatures prendra beaucoup de temps, soit vous aurez besoin de nœuds très puissants pour traiter toutes les signatures en même temps.
Notez que tout cela dépend d’un objectif clé d’Ethereum : garantir que même une attaque réussie impose un coût élevé à l’attaquant. C'est ce que l'on entend par le terme de « finalité économique ». Si nous n'avons pas cet objectif, nous pouvons alors résoudre ce problème en sélectionnant au hasard un comité (comme le fait Algorand) pour finaliser chaque emplacement. Mais le problème de cette approche est que si un attaquant contrôle 51 % des validateurs, il peut attaquer à un coût très faible (récupération des blocs finalisés, censure ou retard de finalisation) : seule une partie des nœuds du comité peut être détectée comme participant. dans les attaques et puni, soit par des coupures, soit par une poignée de fourchettes souples. Cela signifie qu’un attaquant peut attaquer la chaîne à plusieurs reprises. Donc, si nous voulons une finalité économique, une simple approche basée sur un comité ne fonctionnera pas et, à première vue, nous avons besoin d'un ensemble complet de validateurs pour participer.
Idéalement, nous souhaitons préserver la finalité économique tout en améliorant le statu quo de deux manières :
Finaliser les blocs dans un créneau horaire (idéalement conserver voire réduire la durée actuelle de 12 secondes) au lieu de 15 minutes
Autoriser les validateurs à miser avec 1 ETH (réduit de 32 ETH à 1 ETH)
Le premier objectif est mis en évidence par deux objectifs, qui peuvent tous deux être considérés comme « aligner les propriétés d’Ethereum avec celles des chaînes L1 (plus centralisées) axées sur les performances ».
Premièrement, cela garantit que tous les utilisateurs d’Ethereum bénéficient d’un niveau de sécurité plus élevé obtenu grâce au mécanisme de finalisation. Aujourd'hui, la plupart des utilisateurs ne bénéficient pas de cette garantie car ils ne sont pas disposés à attendre 15 minutes ; avec un mécanisme de finalisation à un seul emplacement, les utilisateurs peuvent voir la transaction finalisée presque immédiatement après sa confirmation. Deuxièmement, cela simplifie le protocole et l'infrastructure environnante si les utilisateurs et les applications n'ont pas à s'inquiéter de la possibilité d'un retour en arrière de la chaîne (sauf cas relativement rare de fuites d'inactivité).
Le deuxième objectif est motivé par la volonté de soutenir les parties prenantes individuelles. Un sondage après l'autre a montré à plusieurs reprises que la principale chose qui empêche davantage de personnes de miser seules est le minimum de 32 ETH. Abaisser le minimum à 1 ETH résoudrait ce problème au point que d’autres problèmes deviendraient le principal facteur limitant le jalonnement individuel.
Il y a un défi : les objectifs d’une finalité plus rapide et d’un jalonnement plus démocratisé entrent tous deux en conflit avec l’objectif de minimiser les frais généraux. En fait, c’est la seule raison pour laquelle nous n’adoptons pas en premier lieu le déterminisme à emplacement unique. Cependant, des recherches récentes suggèrent quelques solutions possibles à ce problème.
Qu'est-ce que c'est et comment ça marche ?
La finalité à emplacement unique implique l'utilisation d'un algorithme de consensus qui finalise les blocs dans un emplacement. Ce n’est pas un objectif inaccessible en soi : de nombreux algorithmes (comme le consensus Tendermint) y parviennent déjà avec des propriétés optimales. Une propriété souhaitable unique à Ethereum que Tendermint ne prend pas en charge est la fuite d'inactivité, qui permet à la chaîne de continuer à fonctionner et éventuellement de récupérer même si plus d'un tiers des validateurs sont hors ligne. Heureusement, ce souhait a déjà été exaucé : il existe déjà des propositions visant à modifier le consensus de type Tendermint pour tenir compte des fuites d'inactivité.
Proposition définitive de premier plan à emplacement unique
La partie la plus difficile du problème est de trouver comment faire fonctionner la finalité à emplacement unique avec un nombre de validateurs très élevé sans encourir une surcharge extrêmement élevée de l'opérateur de nœud. Il existe plusieurs solutions phares pour cela :
Option 1 : Brute Force - Travailler à un meilleur protocole d'agrégation de signatures, éventuellement en utilisant des ZK-SNARK, ce qui nous permettrait essentiellement de traiter les signatures de millions de validateurs par emplacement.
Horn, l'une des conceptions proposées pour de meilleurs protocoles d'agrégation.
Option 2 : Comité Orbite - Un nouveau mécanisme qui permet à un comité médium sélectionné au hasard d'être responsable de la finalisation de la chaîne, mais d'une manière qui préserve les propriétés de coût d'attaque que nous recherchons.
Une façon de penser à Orbit SSF est qu'il ouvre un espace d'options de compromis, allant de x=0 (comité de style Algorand, pas de finalité économique) à x=1 (situation actuelle d'Ethereum), ouvrant un point intermédiaire. , Ethereum Il y a encore suffisamment de finalité économique pour atteindre une sécurité extrême, mais en même temps, nous obtenons l'avantage d'efficacité de n'exiger qu'un échantillon aléatoire de validateurs de taille modérée pour participer à chaque époque.
Orbit exploite l’hétérogénéité préexistante dans la taille des dépôts des validateurs pour obtenir autant de finalité économique que possible, tout en donnant aux petits validateurs un rôle pertinent. De plus, Orbit utilise une rotation lente des comités pour garantir un degré élevé de chevauchement entre les quorums adjacents, garantissant ainsi que sa finalité économique s'applique toujours aux limites de rotation des comités.
Option 3 : Jalonnement à deux niveaux - un mécanisme dans lequel les jalonneurs sont divisés en deux catégories, l'une avec des exigences de dépôt plus élevées et l'autre avec des exigences de dépôt plus faibles. Seuls les niveaux ayant des exigences de dépôt plus élevées sont directement impliqués dans la finalité économique. Il existe diverses propositions quant à la nature exacte des droits et responsabilités pour les niveaux avec des exigences de dépôt inférieures (voir, par exemple, l'article Rainbow Staking). Les idées courantes incluent :
Le droit de déléguer des intérêts à des actionnaires de niveau supérieur
Une partie prenante de niveau inférieur sélectionnée au hasard certifie et doit terminer chaque bloc
Droit de générer des listes d’inclusion
Quels sont les liens avec les recherches existantes ?
Voies vers la finalité à emplacement unique (2022) : https://notes.ethereum.org/@vbuterin/single_slot_finality
Proposition spécifique pour le protocole de finalité à emplacement unique d'Ethereum (2023) : https://eprint.iacr.org/2023/280
Orbit SSF : https://ethresear.ch/t/orbit-ssf-gestion-de-lensemble-de-validateurs-conviviaux-pour-le-staking-en-solo-pour-ssf/19928
Analyse plus approfondie de la mécanique du style Orbit : https://notes.ethereum.org/@anderselowsson/Vorbit_SSF
Horn, protocole d'agrégation de signatures (2022) : https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
Fusion de signatures pour un consensus à grande échelle (2023) : https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn
Protocole d'agrégation de signatures proposé par Khovratovich et al. : https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
Agrégation de signatures basée sur STARK (2022) : https://hackmd.io/@vbuterin/stark_aggregation
Jalonnement arc-en-ciel : https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683
Que reste-t-il à faire ? Quels sont les compromis ?
Il existe quatre chemins principaux possibles (on peut aussi emprunter des chemins hybrides) :
maintenir le statu quo
Orbite SSF
SSF puissant
SSF avec deux niveaux de jalonnement
(1) signifie ne pas faire de travail et conserver le jalonnement tel quel, mais cela rendrait l’expérience de sécurité d’Ethereum et les propriétés de centralisation du jalonnement pires qu’elles ne le seraient autrement.
(2) Évitez la « haute technologie » et résolvez le problème en repensant intelligemment les hypothèses du protocole : nous avons assoupli l'exigence de « finalité économique » de sorte que nous exigeons que le coût de l'attaque soit élevé, mais acceptons que le coût de l'attaque puisse être 10 fois inférieur. qu’aujourd’hui (par exemple, le coût de l’attaque est de 2,5 milliards de dollars, et non de 25 milliards de dollars). Il est largement admis qu’Ethereum a aujourd’hui bien plus de finalité économique que nécessaire, et que ses principaux risques de sécurité résident ailleurs, il s’agit donc sans doute d’un sacrifice acceptable.
L'effort principal consiste à vérifier que le mécanisme Orbit est sûr et possède les propriétés souhaitées, puis à le formaliser et à le mettre en œuvre entièrement. De plus, EIP-7251 (Augmenter le solde maximum valide) permet une consolidation volontaire du solde du validateur, ce qui réduit immédiatement les frais de validation de la chaîne et constitue une phase initiale efficace pour le déploiement d'Orbit.
(3) Éviter de repenser intelligemment et plutôt de forcer brutalement les problèmes liés à la haute technologie. Pour ce faire, il faut collecter un grand nombre de signatures (plus d’un million) en très peu de temps (5 à 10 secondes).
(4) Cela évite une refonte intelligente et la haute technologie, mais cela crée un système de jalonnement à deux niveaux qui présente toujours des risques de centralisation. Le risque dépend fortement des droits spécifiques acquis par les niveaux de mise inférieurs. Par exemple:
Si les intervenants de niveau inférieur doivent déléguer leurs droits d'attestation à des intervenants de niveau supérieur, alors la délégation peut devenir centralisée et nous nous retrouvons avec deux niveaux de jalonnement hautement centralisés.
Si un échantillonnage aléatoire des niveaux inférieurs est nécessaire pour approuver chaque bloc, un attaquant peut dépenser une infime quantité d'ETH pour empêcher la finalité.
Si les acteurs de bas niveau ne peuvent créer que des listes d'inclusion, alors la couche de preuve peut toujours être centralisée, auquel cas une attaque à 51 % sur la couche de preuve peut censurer la liste d'inclusion elle-même.
Plusieurs stratégies peuvent être combinées, telles que :
(1 + 2) : ajoute Orbit sans effectuer de finalité à emplacement unique.
(1 + 3) : utilisez des techniques de force brute pour réduire la taille minimale du dépôt sans imposer la finalité d'un seul emplacement. La quantité de polymérisation requise est 64 fois inférieure à celle du cas pur (3), le problème devient donc plus facile.
(2 + 3) : Exécutez Orbit SSF avec des paramètres conservateurs (par exemple, un comité de validation de 128 000 au lieu de 8 000 ou 32 000) et utilisez des techniques de force brute pour le rendre super efficace.
(1 + 4) : ajoute le jalonnement arc-en-ciel sans imposer la finalité d'un seul emplacement.
Comment interagit-il avec les autres parties de la feuille de route ?
Entre autres avantages, la finalité à emplacement unique réduit le risque de certains types d’attaques MEV multiblocs. De plus, dans un monde à créneau unique, la conception de la séparation entre le prouveur et le proposant et les autres pipelines de production de blocs intra-protocoles doivent être conçus différemment.
La faiblesse des stratégies de force brute est qu’elles rendent plus difficile la réduction du temps de créneau.
Élection d'un chef secret unique
Quel problème essayons-nous de résoudre ?
Aujourd’hui, quel validateur proposera le prochain bloc est connu à l’avance. Cela crée une faille de sécurité : un attaquant pourrait surveiller le réseau, identifier quels validateurs correspondent à quelles adresses IP et lancer une attaque DoS sur les validateurs alors qu'ils s'apprêtent à proposer un blocage.
qu'est-ce que c'est? Comment ça marche ?
La meilleure façon de résoudre le problème DoS est de masquer les informations sur le validateur qui générera le prochain bloc, au moins jusqu'à ce que le bloc soit réellement généré. Notez que cela est facile si nous supprimons l'exigence « unique » : une solution serait de laisser n'importe qui créer le bloc suivant, mais d'exiger que randao révèle moins de 2256/N. En moyenne, un seul validateur répond à cette exigence – mais parfois il y en a deux ou plus, et parfois il y en a zéro. Combiner l’exigence de « confidentialité » avec l’exigence d’« unité » a toujours été un problème difficile.
Le protocole d'élection du leader secret unique résout ce problème en utilisant certaines techniques cryptographiques pour créer un identifiant de validateur « aveugle » pour chaque validateur, puis en donnant à de nombreux proposants la possibilité de mélanger et de rendre aveugle le pool d'identifiants aveugles (cela est similaire à Comment les réseaux hybrides fonctionnent). À chaque période, un identifiant aveugle aléatoire est sélectionné. Seul le propriétaire du blind ID peut générer une preuve valide pour proposer un blocage, mais personne ne sait à quel validateur correspond le blind ID.
Protocole SSLE fouetté
Quels sont les liens vers des recherches existantes ?
Article de Dan Boneh (2020) : https://eprint.iacr.org/2020/025.pdf
Whisk (une proposition pratique pour Ethereum, 2022) : https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763
Étiquette d'élection de leader secret unique sur ethresear.ch : https://ethresear.ch/tag/single-secret-leader-election
SSLE simplifié utilisant des signatures en anneau : https://ethresear.ch/t/simplified-ssle/12315
Que reste-t-il à faire ? Quels sont les compromis ?
En réalité, il ne reste plus qu'à trouver et implémenter un protocole suffisamment simple pour que nous puissions facilement l'implémenter sur le réseau principal. Nous prenons Ethereum très au sérieux en tant que protocole assez simple et nous ne voulons pas que la complexité augmente davantage. Les implémentations SSLE que nous avons vues ont ajouté des centaines de lignes de code canonique et introduit de nouvelles hypothèses en matière de chiffrement complexe. Trouver une implémentation suffisamment efficace du SSLE à résistance quantique est également un problème ouvert.
Il se peut que la « complexité supplémentaire marginale » de SSLE ne diminue que lorsque nous introduisons un mécanisme général de preuve de connaissance nulle sur L1 du protocole Ethereum pour d'autres raisons (par exemple, les arbres d'état, ZK-EVM) à un niveau suffisamment bas.
Une autre option consiste à ignorer SSLE et à utiliser à la place des atténuations hors protocole (comme au niveau de la couche p2p) pour résoudre les problèmes de DoS.
Comment interagit-il avec les autres parties de la feuille de route ?
Si nous ajoutons un mécanisme de séparation prouveur-proposant (APS), tel que des tickets d'exécution, alors l'exécution de blocs (c'est-à-dire des blocs contenant des transactions Ethereum) ne nécessitera pas SSLE car nous pouvons compter sur des constructeurs de blocs spécialisés. Cependant, pour les blocs de consensus (c'est-à-dire les blocs contenant des messages de protocole (par exemple des preuves, éventuellement des parties de listes, etc.)), nous bénéficierons toujours de SSLE.
Confirmation de transaction plus rapide
Quel problème résolvons-nous ?
Il serait utile de réduire davantage les délais de confirmation des transactions d’Ethereum, de 12 secondes à 4 secondes. Cela améliorera considérablement l'expérience utilisateur L1 et basée sur l'agrégation tout en rendant le protocole defi plus efficace. Cela facilitera également la décentralisation de L2, car cela permettra à un grand nombre d'applications L2 de fonctionner sur un ordre basé sur l'agrégation, réduisant ainsi la nécessité pour L2 de créer son propre ordre décentralisé basé sur un comité.
qu'est-ce que c'est? Comment ça marche ?
Il existe en gros deux techniques ici :
Réduisez le temps de créneau, par exemple à 8 secondes ou 4 secondes. Cela ne signifie pas nécessairement 4 secondes de finalité : la finalité nécessite essentiellement trois tours de communication, on pourrait donc faire de chaque cycle de communication un bloc distinct, avec au moins un accusé de réception préliminaire après 4 secondes.
Les proposants sont autorisés à émettre des pré-confirmations pendant le créneau. Dans des cas extrêmes, les proposants pourraient intégrer les transactions qu'ils voient dans leurs blocs en temps réel et publier immédiatement un message de pré-confirmation pour chaque transaction ("Ma première transaction était 0x1234...", "I La deuxième transaction est 0×5678. ...”). La situation dans laquelle un proposant émet deux confirmations contradictoires peut être traitée de deux manières : (i) en coupant le proposant, ou (ii) en utilisant des prouveurs pour voter pour lequel est le premier.
Quels sont les liens vers des recherches existantes ?
Basé sur des préconfirmations : https://ethresear.ch/t/based-preconfirmations/17353
Engagements du proposant imposés par le protocole (PEPC) : https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
Périodes échelonnées sur les chaînes parallèles (idées de faible latence en 2018) : https://ethresear.ch/t/staggered-periods/1793
Que reste-t-il à faire et quels sont les compromis ?
On ne sait pas dans quelle mesure la réduction du temps de créneau sera pratique. Aujourd’hui encore, les acteurs du secteur ont du mal à obtenir des preuves dans de nombreuses régions du monde. Tenter un créneau de 4 secondes risque de concentrer l'ensemble des validateurs et de rendre impossible la possibilité de devenir un validateur en dehors de quelques régions privilégiées en raison de la latence.
La faiblesse de la méthode de préconfirmation du proposant est qu'elle améliore grandement le temps d'inclusion moyen du dossier, mais pas le temps d'inclusion dans le pire des cas : si le proposant actuel fonctionne bien, votre transaction sera préconfirmée en 0,5 seconde, alors qu'elle ne l'est pas (en moyenne) 6 secondes à inclure, mais si le proposant actuel est hors ligne ou ne fonctionne pas bien, vous devez toujours attendre 12 secondes complètes avant que le créneau suivant puisse démarrer et proposer un nouveau proposant.
En outre, la question reste ouverte de savoir comment encourager la pré-confirmation. Les proposants sont incités à maximiser leur optionnalité le plus longtemps possible. Si le prouveur signe la ponctualité de la pré-confirmation, alors l'expéditeur de la transaction peut subordonner une partie des frais à la pré-confirmation immédiate, mais cela imposera une charge supplémentaire au prouveur et pourrait rendre plus difficile pour le prouveur de continuer à agir comme un "tuyau muet" neutre.
D'un autre côté, si nous n'essayons pas de le faire et maintenons le temps de finalisation à 12 secondes (ou plus), l'écosystème mettra davantage l'accent sur le mécanisme de pré-confirmation mis en place par la couche 2 et les interactions à travers la couche 2 prendront plus de temps. plus longtemps.
Comment interagit-il avec les autres parties de la feuille de route ?
La pré-confirmation basée sur le proposant repose en fait sur des mécanismes de séparation prouveur-proposant (APS) tels que les tickets d'exécution. Dans le cas contraire, la pression exercée pour fournir des pré-confirmations en temps réel pourrait créer une pression trop centralisée sur les validateurs réguliers.
Autres domaines de recherche
51 % de récupération d'attaque
Il est généralement admis qu'en cas d'attaque à 51 % (y compris les attaques qui ne peuvent pas être prouvées cryptographiquement, comme la censure), la communauté se rassemblera pour mettre en œuvre un soft fork minoritaire, garantissant que les bons gagnent et que les méchants sont fuite ou réduite en raison de l'inactivité. Cependant, ce niveau de dépendance excessive à l’égard du niveau social est sans doute malsain. Nous pouvons essayer de réduire la dépendance à l’égard de la couche sociale et rendre le processus de récupération aussi automatisé que possible.
Une automatisation complète n'est pas possible, car si elle l'était, cela compterait comme un algorithme de consensus tolérant aux pannes > 50 %, et nous connaissons déjà les limitations (très strictes) mathématiquement prouvables de tels algorithmes. Mais on peut parvenir à une automatisation partielle : par exemple, un client peut automatiquement refuser d'accepter une chaîne comme définitive, voire refuser de l'accepter en tête d'une sélection de fork, si le client a examiné une transaction qu'il voit depuis longtemps. assez. Un objectif clé est de garantir que les méchants de l’attaque n’obtiennent pas au moins une victoire rapide.
Augmenter le seuil de quorum
Aujourd'hui, si 67% des acteurs le soutiennent, le bloc sera finalisé. Certains pensent que c'est trop radical. Dans toute l’histoire d’Ethereum, il n’y a eu qu’un (très bref) échec final. Si ce pourcentage était augmenté à 80 %, le nombre d’époques non définitives accrues serait relativement faible, mais Ethereum gagnerait en sécurité : en particulier, bon nombre des situations les plus controversées entraîneraient une suspension temporaire de la finalité. Cela semble beaucoup plus sain que de gagner immédiatement du « mauvais côté », que le mauvais côté soit l'attaquant ou qu'il y ait un bug du côté client.
Cela répond également à la question « A quoi sert un jalonneur distinct ? » Aujourd’hui, la majorité des parieurs investissent déjà via des pools, et il semble peu probable qu’un seul parieur reçoive jusqu’à 51 % des ETH mis en jeu. Cependant, amener un joueur solo à atteindre une minorité qui bloque la majorité semble possible si nous faisons de gros efforts, surtout si la majorité atteint 80 % (il ne faut donc que 21 % pour bloquer la majorité). Tant que les solitaires ne participeront pas à une attaque à 51 % (qu'il s'agisse d'un renversement de finalité ou d'une révision), cette attaque ne permettra pas d'obtenir une « victoire nette », et les solitaires aideront activement à organiser des soft forks minoritaires.
Résistance quantique
Metaculus estime actuellement que, bien qu’avec de grandes marges d’erreur, les ordinateurs quantiques commenceront probablement à briser la cryptographie dans les années 2030 :
Des experts en informatique quantique tels que Scott Aaronson ont récemment commencé à prendre plus au sérieux la possibilité que les ordinateurs quantiques fonctionnent réellement à moyen terme. Cela a des implications pour l’ensemble de la feuille de route d’Ethereum : cela signifie que chaque partie du protocole Ethereum qui repose actuellement sur des courbes elliptiques aura besoin d’une sorte d’alternative basée sur le hachage ou d’une autre alternative résistante aux quantiques. Cela signifie en particulier que nous ne pouvons pas supposer que nous pourrons un jour compter sur les propriétés supérieures de l’agrégation BLS pour gérer les signatures d’un grand nombre de validateurs. Cela justifie le conservatisme dans les hypothèses de performance de conception de preuve d’enjeu et constitue une raison pour développer de manière plus agressive des alternatives résistantes aux quantiques.
