L’équipe de Plonky3 a publié une mise à jour via une pull request sur GitHub, intégrant la récursivité native pour les vérificateurs FRI, uni-stark et batch-stark. Concrètement, cela signifie que les points d’entrée natifs de ces algorithmes passent désormais par des traits (Arith et Lift) qui utilisent directement les éléments de champ, évitant de copier des logiques de vérification. Un circuit backend peut dorénavant utiliser ces traits pour réutiliser chaque vérification ou noyau de calcul sans avoir à recréer la structure.

Cette optimisation ne modifie pas le comportement des vérificateurs FRI, uni-stark ou batch-stark ; les chemins d’accès natifs appellent simplement les versions génériques en spécifiant le trait Native. On voit l’intérêt, car cela permet de construire des circuits qui vérifient les mêmes preuves en capitalisant sur le travail déjà fait.

L’architecture des preuves en circuit

L’annonce détaille également l’ajout de p3-circuit, un circuit bâti avec des tables fixes prouvées via batch-stark. Chaque valeur est traitée comme un fil « écriture unique » sur un bus LogUp, identifié par son ID de fil et portant ses parties d’extension. Ce circuit utilise des composants standardisés comme BaseAlu et ExtAlu pour les opérations arithmétiques, et des fonctions de permutation Poseidon2.

L’optimisation passe notamment par la manière dont les ouvertures de Merkle sont réutilisées, employant le parcours OpeningPlan natif avec le sponge Poseidon2. Les contraintes AIR sont capturées symboliquement une seule fois, ce qui est une bonne nouvelle pour la complexité globale.

En parlant de complexité, d’autres recherches montrent que le passage à l’agrégation de signatures post-quantiques reste un défi. Selon une étude publiée par Ethereum Research, tenter de « plier » les vérifications leanXMSS directement dans un méta-vérificateur engendrerait au moins 7,1 millions de contraintes R1CS par signature, ce qui représente environ quatre fois le coût de vérification par signature de leanVM utilisé dans l’agrégateur.

La récursivité et la gestion de la mémoire

Au-delà des améliorations sur les vérificateurs, Plonky3 introduit recursion::aggregate, un circuit conçu pour valider plusieurs preuves batch. Les valeurs publiques des enfants restent privées et sont intégrées au digest du nœud via un sponge Poseidon2. L’approche se concentre sur la façon dont les étapes de Merkle et les multiplications sont abaissées dans le circuit, assurant une structure bien définie.

Les tests mentionnés dans l’annonce témoignent d’un gain notable en performance sur des scénarios complexes. Par exemple, lors d’un benchmark sur l’AMD Ryzen 9 9950X3D, le temps de configuration pour un circuit vérifiant une preuve de circuit a chuté : les lignes Value sont passées de 277 124 à 58 889, et les lignes BaseAlu de 1 186 337 à 61 434. Cela suggère que l’architecture native réduit significativement le nombre de lignes nécessaires pour représenter la même logique.

Parallèlement, d’autres projets abordent la gestion des ressources lors de preuves complexes. Sur le projet lambda_vm, des ajustements ont été faits pour optimiser la mémoire lors de l’utilisation d’un vérificateur « retire-LDE ». En introduisant LAMBDA_STREAM_LDE=auto, le système tente d’estimer le besoin en mémoire pour décider quand « retirer » les états de calcul, évitant ainsi le dépassement de pic d’allocation.

Ce travail sur l’estimation est sensible : il dépend d’un pré-passe analytique, et si ce dernier est absent, le mode auto émet un avertissement au lieu de forcer le calcul sans le mode activé. Ce niveau de granularité dans la gestion des états est ce qui fait la différence entre une preuve qui tient sur la machine et une preuve qui échoue.

Il faudra suivre attentivement comment ces optimisations de représentation des preuves s’articulent avec les exigences de latence des réseaux décentralisés, où le temps de propagation des agrégats, même réduits à quelques centaines de kilobytes, reste un facteur critique.

Sources

• feat: native recursion for FRI, WHIR and Flock proofs, with XMSS and SLH-DSA signature aggregation by tcoratger · Pull Request #2533 ·…, github.com
• Prove-and-retire prover (Approach 1), per-table and batched by jotabulacios · Pull Request #994 · yetanotherco/lambda_vm, github.com
• Folding vs full-verifier recursion for PQ signature aggregation in leanVM: measurements and negative results, Ethereum Research, 8 novembre 2026

Crédits photo

• Image en une : Interior StorageTek tape library NERSC, par auteur inconnu, CC0, via Rawpixel via Openverse (recadrée)
• Image dans l’article : Free technology image, par auteur inconnu, CC0, via Rawpixel via Openverse (recadrée)