TL;DR
- Ethlabs a proposé de rendre Ethereum résistant à l'ordinateur quantique et plausiblement prêt pour l'ère post-AI d'ici 2027, en avançant les travaux de sécurité avant les mises à jour non essentielles à cet objectif.
- Le groupe retirera les Quick Slots de Hegotá et réorientera les ressources vers les comptes post-quantiques, le consensus, l'agrégation de signatures et la disponibilité des données.
- Ethlabs affirme que l'accélération des capacités de l'IA augmente l'incertitude concernant la cryptographie et la sécurité logicielle, bien que les développeurs principaux d'Ethereum n'aient pas encore approuvé formellement sa feuille de route réseau proposée pour 2027.
Ethlabs a proposé de faire avancer la cible de préparation d’Ethereum face à l’après-quantique et « plausible après l’IA » à 2027, arguant que les capacités croissantes de l’intelligence artificielle rendent plus difficile la prévision des délais de sécurité à long terme. Dans sa pqai27 proposal, le groupe de recherche a déclaré que le protocole devrait privilégier la résilience cryptographique et le renforcement des clients au détriment des mises à jour en dehors de ce chemin critique. La proposition ferait de la sécurité contre les menaces cryptographiques émergentes une priorité à court terme pour Ethereum, mais les développeurs principaux n’ont pas officiellement adopté la cible de 2027.
Ethlabs redessinerait Hegotá autour de la préparation post-quantique
Sous pqai27, Ethlabs distingue entre être « pqai-ready » et « pqai-scaled ». La première étape rendrait le consensus post-quantique et offrirait à chaque utilisateur un chemin post-quantique pour sécuriser ses comptes, permettant à Ethereum de continuer à fonctionner à capacité réduite si la cryptographie classique échoue de manière inattendue. Une préparation à pleine échelle restaurerait ultérieurement la capacité normale pour les transactions et les blobs post-quantiques. Cette approche accélérerait la feuille de route post-quantique existante du réseau, qui a déjà avancé vers des objectifs antérieurs par rapport à l'ancien calendrier de 2029.

Atteindre cet objectif nécessiterait de réévaluer les priorités de Hegotá. Ethlabs a déclaré qu'elle retirerait sa proposition de Quick Slots de la mise à jour et réorienterait les ressources vers pqai27, tout en poursuivant des créneaux plus rapides en 2028. Les EIPs pour les comptes aux formats Frames et post-quantique restent centraux, car ils pourraient offrir aux utilisateurs des mécanismes d'authentification et de migration flexibles, tandis que les développeurs doivent encore résoudre la question de la rendue quantiquement résistante du consensus lui-même. L'agrégation des signatures via EIP-8288 et la disponibilité des données post-quantiques sont des éléments clés de l'objectif de capacité maximale, bien que le plan reste techniquement ambitieux.
Ethlabs a également mentionné des signaux de migration externes, notant que le gouvernement américain a avancé son objectif de planification des risques quantiques de 2035 à 2030 et que Google vise désormais une préparation post-quantique d'ici 2029. Le groupe soutient qu'agir plus tôt est moins coûteux que de changer plus tard, car des travaux supplémentaires de hardfork pourraient rendre un changement motivé par la sécurité plus perturbateur et plus coûteux pour les équipes de développement principal. L'IA est la deuxième raison pour laquelle Ethlabs souhaite accélérer le calendrier. Le groupe affirme que les modèles de pointe résolvent des problèmes mathématiques auparavant ouverts et détectent des vulnérabilités logicielles à une échelle croissante, créant de l'incertitude autour des hypothèses cryptographiques et de la sécurité des clients. Ethlabs ne prétend pas que l'IA peut actuellement casser la cryptographie d'ethereum, et il décrit la résilience « post-IA » comme plausible plutôt que prouvable. Sa défense proposée combine moins d'hypothèses cryptographiques avec une vérification formelle plus robuste et une diversité des clients, tandis que Glamsterdam se poursuivra comme prévu et que les travaux au-dessus du protocole de base resteront inchangés.





