Les développeurs d’Ethereum repensent tranquillement l’un des éléments de base du protocole : quelle fonction de hachage cryptographique devrait faire entrer le réseau dans sa prochaine ère. Le débat terminé Fonctions de hachage Ethereum a refait surface maintenant qu’un nouveau système de preuve appelé Flock a supprimé une contrainte qui façonnait autrefois chaque décision : la nécessité de conceptions adaptées aux circuits comme Poséidon. Cette exigence ayant disparu, les chercheurs comparent SHA-2, SHA-3/Keccak, BLAKE2, BLAKE3 et une variante non standard de SHA-2 uniquement sur la sécurité et la vitesse, et l’analyse publiée sur le forum Ethereum Research montre à quel point ces options sont différentes une fois que la convivialité des circuits n’est plus envisagée.
Points clés à retenir
- Ethereum n’a plus besoin de hachages adaptés aux circuits car Flock, un système de preuve post-quantique pour les circuits binaires, gère efficacement le hachage quel que soit l’algorithme choisi.
- Les fonctions de hachage sous-tendent les signatures de couche consensus, la construction d’arbres d’état, les preuves zkVM et les signatures de couche d’exécution à travers le protocole.
- SHA-2 est rapide mais n’est pas un véritable oracle aléatoire en raison d’une faiblesse d’extension de longueur ; SHA-3 offre une marge de sécurité élevée mais s’exécute plus lentement ; BLAKE2 et BLAKE3 sont plus rapides mais contiennent des enregistrements de cryptanalyse plus fins.
- Les benchmarks montrent que BLAKE3 est la fonction de hachage la plus rapide pour les messages longs, tandis que SHA-3 est la plus lente parmi les principaux candidats.
- Un classement minimisant les risques place SHA-3 en premier, BLAKE2 et la variante SHA-2 à égalité aux deuxième et troisième places, BLAKE3 étant classé plus bas.
Exigences de la fonction de hachage d’Ethereum à l’ère post-quantique
Le choix de la fonction de hachage d’Ethereum n’est plus limité par l’efficacité du circuit de preuve, ce qui permet aux ingénieurs de donner la priorité à la sécurité et à la vitesse brute. Ce changement est le résultat direct de l’entrée en scène d’une nouvelle architecture de preuve, et il modifie tout le calcul derrière la sélection des primitives cryptographiques pour le réseau.
Le système de preuve de Flock supprime la contrainte de hachage respectueuse des circuits
Pendant des années, toute fonction de hachage candidate pour Ethereum devait être efficace dans des circuits à connaissance nulle, ce qui a effectivement poussé l’écosystème vers des conceptions algébriques et respectueuses des circuits telles que Poséidon. Cette contrainte a désormais largement disparu. Avec l’émergence de Flock en tant que système de preuve post-quantique conçu pour les circuits binaires – les hachages en particulier – Ethereum n’a plus besoin de hachages spécifiques adaptés aux circuits pour les protocoles dont le calcul doit être prouvé. En pratique, cela signifie que le réseau peut évaluer les fonctions de hachage sur leurs mérites natifs plutôt que de forcer un compromis entre la solidité cryptographique et la compatibilité du système de preuve.
Cas d’utilisation clés : consensus, arbres d’état, preuves zkVM et couche d’exécution
Les fonctions de hachage restent profondément ancrées dans l’architecture d’Ethereum et leurs performances touchent presque toutes les couches du protocole. Ils sont importants pour les signatures de couche consensus utilisant une variante XMSS, pour agréger ces signatures via un système de preuve post-quantique, pour construire l’arborescence d’état au niveau de la couche d’exécution et pour les schémas de signature de couche d’exécution tels que SPHINCS+. Chacun de ces cas d’utilisation repose sur un hachage itératif, où les règles de remplissage et la taille des fragments de l’algorithme choisi affectent directement les performances du monde réel.
Comparaison des principaux candidats aux fonctions de hachage
Aucun candidat ne gagne à lui seul en termes de sécurité et de vitesse, c’est exactement pourquoi les chercheurs d’Ethereum effectuent une comparaison côte à côte au lieu de régler la question par défaut. L’analyse restreint le champ à cinq options : SHA-2, SHA-3/Keccak, BLAKE2, BLAKE3 et une variante SHA-2 modifiée.
SHA-2, sa variante et SHA-3/Keccak : vitesse par rapport à la marge de sécurité
SHA-2 est rapide et testé au combat, mais ce n’est pas un oracle aléatoire tel quel en raison d’une vulnérabilité d’extension de longueur bien connue héritée de sa construction Merkle-Damgard. Une variante SHA-2 corrigée corrige l’écart d’indifférenciabilité tout en gardant intacte la majeure partie de la cryptanalyse d’origine, bien qu’elle rompe la compatibilité avec la norme et nécessite une valeur d’initialisation non standard.
SHA-3/Keccaken revanche, apporte une marge de sécurité élevée grâce à sa construction en éponge, ayant survécu à des années de cryptanalyse sans interruption pratique. Cette sécurité a un coût : le grand état interne de SHA-3 le rend considérablement plus lent, tant en mode natif qu’en interne, par rapport à SHA-2 et à la famille BLAKE.
Question de compatibilité Keccak de BLAKE2, BLAKE3 et Ethereum
BLAKE2 se classe parmi les fonctions de hachage les plus rapides disponibles et inclut une fonction de compression dont il est prouvé qu’elle est indifférenciable, ce qui lui confère une épine dorsale de sécurité formelle qui manque à SHA-2. Son inconvénient est l’examen minutieux : il existe moins de 10 articles de cryptanalyse sur BLAKE2, bien loin de la couverture dont bénéficient SHA-2 ou SHA-3. BLAKE3 pousse les performances d’environ 40 % plus loin en réduisant la conception de 10 tours à 7 et en modifiant les opérations de chiffrement par bloc internes, mais ces changements suppriment entièrement la preuve d’indifférenciabilité et rompent la compatibilité avec la cryptanalyse BLAKE2 précédente, ce qui signifie que sa sécurité doit être réévaluée à partir de zéro.
Un problème distinct affecte spécifiquement Ethereum : la mise en œuvre de Keccak par le réseau diffère du SHA-3 standardisé dans son schéma de remplissage. Les deux versions sont également sécurisées selon leurs propres conditions, mais elles ne sont interopérables dans aucun sens, ce qui ajoute une couche de complexité de mise en œuvre que les clients Ethereum ont dû contourner.
Sécurité, performances et classement basé sur les risques
Lorsque les données de sécurité et de performances sont placées côte à côte, les compromis deviennent plus précis que ne le suggère une seule mesure. Chaque candidat se protège différemment contre les attaques par collision et par pré-image, et chacun se comporte très différemment une fois que de véritables tests matériels entrent en scène.
Résistance aux collisions et aux pré-images sous surveillance
La résistance aux attaques par collision et par pré-image est le point où l’enregistrement de cryptanalyse sépare le plus clairement les candidats. Les attaques de SHA-2 restent loin d’être pratiques, laissant une marge confortable. La conception de SHA-3 n’a fait face qu’à des attaques limitées par collision et par pré-image, renforçant ainsi sa réputation de large tampon de sécurité. BLAKE2s n’a pas d’attaque de collision ou de quasi-collision publiée sur le hachage complet. La structure de BLAKE3 a été sondée avec moins de tentatives cryptanalytiques jusqu’à présent, laissant sa résistance à long terme moins minutieusement testée que celle de son frère aîné.
Résultats de référence et classement de chaque fonction de hachage
La vitesse brute raconte une histoire très différente de celle de l’examen minutieux de la sécurité. En matière de hachage de messages longs, BLAKE3 est le plus rapide du groupe, tandis que SHA-3 est le plus lent parmi les principaux candidats testés. Cet écart illustre la tension au cœur du Sécurité cryptographique Ethereum débat : l’option la plus rapide n’est pas la plus scrutée, et l’option la plus scrutée n’est pas la plus rapide.
En mettant en balance les contrôles de sécurité et les performances, le classement de minimisation des risques place SHA-3 en premier lieu, avec BLAKE2 et le variante SHA-2 à égalité aux deuxième et troisième places. BLAKE3 arrive plus bas sur la liste, reflétant son historique plus mince en matière de cryptanalyse indépendante malgré de solides performances brutes. En pratique, ce cadrage montre pourquoi le choix n’est pas purement technique : il s’agit d’un pari sur le poids que le réseau accorde à des années de surveillance publique par rapport à l’importance qu’il accorde à la réduction des millisecondes de chaque appel de hachage.
L’implication plus large est que la décision de hachage d’Ethereum après Poséidon dépend désormais moins de l’efficacité du circuit de preuve que du niveau de risque cryptographique que le protocole est prêt à supporter en échange de vitesse, un compromis qui continuera probablement à évoluer à mesure que BLAKE2 et BLAKE3 attireront une cryptanalyse plus indépendante au fil du temps.
FAQ
Pourquoi Ethereum ne nécessite-t-il plus de fonctions de hachage adaptées aux circuits ?
Parce que le système de preuve post-quantique Flock pour les circuits binaires élimine le besoin de hachages spécifiques adaptés aux circuits.
Quelles sont les principales utilisations des fonctions de hachage dans Ethereum aujourd’hui ?
Les fonctions de hachage sont utilisées pour les signatures de couche consensus, l’agrégation des signatures avec des preuves post-quantiques, la construction de l’arborescence d’état, les preuves zkVM et les signatures de couche d’exécution.
Comment SHA-2 et SHA-3 se comparent-ils dans les contextes Ethereum ?
SHA-2 est rapide et testé au combat, mais souffre d’une vulnérabilité d’extension de longueur, tandis que SHA-3 a une marge de sécurité plus élevée mais des performances natives et de circuit plus lentes.
Quels sont les principaux avantages et inconvénients de BLAKE2 et BLAKE3 ?
BLAKE2 est rapide et possède des composants de sécurité prouvables mais moins de cryptanalyse ; BLAKE3 est plus rapide mais manque de preuve d’indifférenciabilité et de compatibilité ascendante avec la cryptanalyse.
