# Signatures pour les programmes invités

> Initiative QL-03. La vérification de signatures adaptées au ZK et post-quantiques, offerte à tout programme invité sous forme d’appel, pour que l’autorisation dans une application native blockchain tienne en une ligne de code.

QL-03 Signatures pour les programmes invités Statut : développement actif

Presque toute application native blockchain pose la même question à chaque requête : est-ce la bonne clé qui a autorisé ceci? Dans la v1.0.0, un programme invité y répond par du code. La récupération de clé secp256k1, c’est `k256` qui s’exécute sur les circuits délégués `MOD_MUL` et `EC_ADD`, ce qui rend abordables les signatures propres à Ethereum; tout le reste passe par des instructions ordinaires. QL-03 fait de la vérification de signatures une opération de premier rang des programmes invités.

## Les schémas

Qu’un schéma de signature soit peu coûteux à prouver ou non tient presque entièrement à son algorithme de *vérification* : quelle arithmétique il effectue, dans quel corps, et quelle fonction de hachage il appelle. Le signataire ne s’exécute jamais dans la preuve. Quatre conceptions couvrent l’espace :

| Schéma | Idée | Pourquoi c’est important pour un programme invité |
| --- | --- | --- |
| Schnorr sur une courbe native | Le protocole de Schnorr sur une courbe dont le corps de base est le corps même du système de preuve, comme Grumpkin pour BN254 | le moins coûteux par construction : arithmétique et hachage tous deux natifs au circuit |
| ML-DSA (FIPS 204) | Schnorr transposé aux réseaux, avec une réponse courte maintenue uniforme par échantillonnage par rejet | la principale signature post-quantique du NIST; un coût dominé par son hachage et, sauf si la clé est fixe, par l’expansion de sa matrice |
| FN-DSA (Falcon) | hacher-puis-signer avec une trappe de réseau, masquée par échantillonnage gaussien | le moins d’arithmétique et le moins de hachage des trois schémas post-quantiques |
| SLH-DSA (FIPS 205) | des signatures construites à partir d’une fonction de hachage seulement | aucune algèbre, et quelque deux mille appels de hachage; l’hypothèse la plus conservatrice |

Les quatre vérificateurs procèdent par calcul puis comparaison, sans secret ni branchement sur des secrets, et c’est ce qui rend chacun d’eux prouvable. L’exposé [*ZK-Friendly Signature Schemes*](https://www.gweb3networks.com/expositories/zk-friendly-signature-schemes.html) les examine un à un sur un exemple jouet et compare leurs coûts en circuit.

## Ce qui détermine le coût

Deux leviers font bouger chaque chiffre :

- **Le corps sur lequel travaille le prouveur.** Un schéma est natif quand son arithmétique est celle du circuit. Le schéma le moins coûteux dépend donc du changement de corps de [QL-02](https://apogee.gweb3networks.com/docs/quantum-leap/post-quantum#refield), et le choix se fait en même temps que lui.
- **Le hachage.** Les vérificateurs post-quantiques sont dominés par leur hachage normalisé, non par leur algèbre. Le remplacer par un hachage arithmétique fait sortir de la norme, et c’est la variante que retiennent les constructions orientées ZK; le conserver est ce qu’exige l’interopérabilité avec les clés existantes. Les deux ont leur place, et c’est le programme invité qui décide.

## Pour les développeurs

Le but : un programme invité qui vérifie une autorisation comme il calcule aujourd’hui un hachage, en un seul appel délégué à un circuit, sans cryptographie dans le code propre de l’application. Cela ouvre la voie aux modèles sur lesquels se construisent les applications natives blockchain : des comptes dont les clés ne sont pas celles de la chaîne, l’approbation multipartite au sein de la fonction de transition d’état, les clés de session, et des identités qui restent valides après la chute des courbes sur lesquelles elles sont nées.

Retour au [breffage de mission](https://apogee.gweb3networks.com/docs/quantum-leap).