StateSync-GKR, un moteur de preuve développé en Rust, apporte des améliorations notables par rapport à ses versions précédentes. Selon l’annonce faite sur arxiv.org, ce système intègre un frontend Sparse-Merkle, ce qui permet de gérer les transitions d’état authentifiées sans surcharger la mémoire. L’optimisation est drastique : la réduction de couche éparse maintient l’allocation mémoire additionnelle 3 242 fois inférieure à celle de son moteur de référence dense, même avec une largeur de 4 096.

L’amélioration ne concerne pas uniquement la consommation de ressources. La version 1.2.0 a permis d’augmenter le débit de preuve préparée de 2,4 à 2,7 fois sur un hôte bare-metal équipé de 192 cœurs. De plus, un nouveau chemin de service permet de traiter chaque tâche dès qu’un travailleur est disponible, et les preuves sont renvoyées dans l’ordre de la requête, ce qui simplifie l’usage pour les services intégrant cette technologie.

En environnement virtualisé, les performances restent impressionnantes. Sur une machine virtuelle de 192 cœurs gérant 1 000 requêtes par seconde, la latence jusqu’à l’acceptation vérifiée chute de 440 à 34 millisecondes. Les tests montrent que le système peut supporter une connexion unique avec 3 300 requêtes par seconde. Deux connexions ont même dépassé les 5 000 requêtes par seconde en quinze secondes.

Efficacité en ressources et débits élevés

La gestion de la mémoire est le point fort de StateSync-GKR. Grâce à la réduction de couche éparse, l’allocation mémoire additionnelle est maintenue 3 242 fois inférieure à celle du moteur dense de référence. Sur des scénarios intenses, le taux de réussite maximal a augmenté, passant de 500 à 2 000 requêtes par seconde en quinze secondes sur 48 cœurs.

Ces avancées s’inscrivent dans un cadre théorique solide. D’ailleurs, d’autres travaux sur arxiv.org confirment l’importance de la robustesse de ces protocoles. Une publication aborde la preuve de la solidité du protocole GKR pour les mises à jour Sparse-Merkle, démontrant la validité des affirmations pour les arbres de toute profondeur dans un contexte de délégation, en supposant des sous-circuits de hachage corrects.

Convergence entre théorie et implémentation

Il est intéressant de noter que les avancées théoriques, comme le premier bornage de solidité de GKR vérifié par machine pour les circuits en couches générales, sont étroitement liées à cette implémentation pratique. Des recherches menées par Ethereum Research confirment cette convergence, mentionnant le lien entre les preuves formelles (dans Isabelle/HOL) et l’implémentation en Rust, notamment concernant les preuves d’état identiques.

Cette approche permet de maintenir l’intégrité des preuves tout en rendant le système utilisable en production. Pour un service intégrant ce système, l’utilisation de moins de serveurs peut atteindre le même taux de preuve avec une latence de queue bornée, sans que les vérificateurs existants aient à modifier leurs algorithmes pour accepter les preuves GKR.

Le défi réside toutefois dans les hypothèses cryptographiques de base. Les chercheurs indiquent que le hachage de nœud implémenté, une permutation tronquée de Poseidon2, n’est pas collision-résistant. Par conséquent, l’affirmation qu’une exécution pour une clé et une racine donnée affirme le même élément se réduit à une propriété de liaison de position dans l’arbre, qui constitue l’unique hypothèse cryptographique de ces énoncés interactifs. Il faudra surveiller comment ces prouesses d’optimisation seront adoptées par les infrastructures décentralisées, surtout face à la nécessité de renforcer les hypothèses cryptographiques sous-jacentes.

Sources

• StateSync-GKR: Design and Evaluation of a Reusable Sparse GKR Engine, arxiv.org
• Soundness of the GKR Protocol for Sparse-Merkle Updates, with a Machine-Checked Core, arxiv.org
• GKR with a Machine-Checked Core, and a Sparse Prover Made Faster with Byte-Identical Proofs, Ethereum Research, 7 novembre 2026