# Engagements

> Chaque colonne engagée est ouverte avec Mercury, un engagement multilinéaire sur KZG dont l’ouverture est de taille constante. Ce qu’il coûte, comment un shard regroupe toutes ses colonnes en une seule ouverture, et comment la récursion diffère le couplage.

Chaque colonne qu’engage Apogee est un polynôme multilinéaire, une table de `2^n` évaluations sur l’hypercube booléen. Chacune est engagée et ouverte avec **Mercury** (Eagen et Gabizon, ePrint 2025/385), complété par l’ouverture KZG groupée de BDFG20 (Boneh, Drake, Fisch et Gabizon, ePrint 2020/081). La spécification fixe ce que les articles laissent ouvert et ajoute deux choses : un lot de nombreuses colonnes en un même point, et une forme différée que replie l’arbre de récursion.

## L’engagement

Un engagement Mercury est exactement l’engagement KZG de la table d’évaluations lue comme une suite de coefficients : une seule multiplication multi-scalaire sur les `n` premières puissances du `τ` de la cérémonie, un seul point de G1, 64 octets. Il n’y a aucun second schéma derrière. Il en découle deux propriétés, et le reste du système utilise l’une et l’autre :

- **Il est linéaire.** L’engagement de `Σ ρ^i·f_i` est `Σ ρ^i·cm_i`, ce qui permet à de nombreuses colonnes de partager une seule ouverture.
- **Les coefficients nuls n’ajoutent rien.** Une colonne prolongée par des lignes nulles conserve son engagement : les trois engagements de la table de lookup générique servent donc à toute hauteur qui contient la table, et ce sont des constantes de la cérémonie.

Les colonnes sont engagées à leur largeur entière : une colonne de bits, d’octets, de demi-mots ou de mots passe par une MSM sur des scalaires `u32`, recodés à partir de 32 bits au lieu de 254, ce qui garde peu coûteux l’engagement d’une trace.

## L’ouverture

Mercury scinde en deux moitiés un point d’ouverture `u` de `s = 2t` variables, replie le polynôme par un défi `α`, et prouve les deux produits scalaires qui restent avec un témoin symétrisé, pour finir par une seule ouverture KZG groupée en trois points. La preuve compte **huit points de G1 et six éléments du corps : 704 octets**, pour toute taille. D’où une exigence : le nombre de variables doit être pair, et c’est pourquoi chaque hauteur au menu est une puissance paire de deux.

Le vérificateur effectue `O(t)` opérations sur le corps, des MSM de dix et de deux points, et **une seule vérification de couplage à deux paires**. Les deux relations qu’il vérifie s’écrivent `e(A, [1]_2) = e(B, [x]_2)` : les deux arguments de G2 sont donc des constantes de la mise en place, et le vérificateur n’effectue aucune arithmétique dans G2. C’est aussi cette forme qui permet à la récursion de différer le couplage au lieu de le calculer.

## Les colonnes d’un shard, une seule ouverture

La passe GKR se termine avec une affirmation sur chaque colonne engagée d’un shard, toutes au même point `u`. Aucun sumcheck de fusion des affirmations n’est donc nécessaire : l’ouverture les regroupe toutes. Un défi `ρ`, tiré après chaque engagement et chaque valeur annoncée, pondère la colonne `i` par `ρ^i`; le prouveur ouvre `Σ ρ^i·f_i` une seule fois, et le vérificateur forme `Σ ρ^i·cm_i` par une MSM à `k` points. Une affirmation fausse survit avec une probabilité d’au plus `(k − 1)/|Fr|`.

Les colonnes du lot proviennent de trois endroits, dans un ordre fixe qui fait partie de ce qui est prouvé : les engagements des colonnes mémoire, tirés de l’énoncé; ceux des colonnes témoins, tirés de la preuve du shard; et ceux des colonnes de mise en place, tirés de la clé de vérification. C’est le fait de prendre les engagements de mise en place dans la clé qui fait que l’ouverture lie les tables décodées et l’image qu’engage l’identité du programme.

## Vérification différée

Une vérification différée exécute tout sauf le couplage, et conserve les termes de la relation sous forme de douze entrées `(side, scalar, point)`. La récursion utilise exactement cela : chaque nœud de l’arbre calcule les douze scalaires d’un shard dans sa propre arithmétique, les pondère par de nouveaux défis et les ajoute à une seule paire de points cumulative `(A, B)`. L’ouverture de chaque shard de l’arbre entier se replie en une seule affirmation `e(A, [1]_2) = e(B, [x]_2)`, que seul le contrat sur Ethereum vérifie en fin de compte. [Récursion et règlement](https://apogee.gweb3networks.com/docs/architecture/recursion) montre le repliement.

## Mesures

Sur un Apple M5 Pro à 18 cœurs :

| Opération | Temps |
| --- | --- |
| Engager une colonne de `2^22` | 1,30 s |
| Ouvrir une colonne de `2^22` | 2,89 s |
| 16 colonnes de `2^20`, ouvertes en un seul lot | 1,01 s, vérifiées en 4,8 ms |
| Les mêmes 16, ouvertes une à une | 9,79 s, vérifiées en 62 ms |

## Sécurité

La solidité de connaissance (*knowledge soundness*) tient dans le modèle du groupe algébrique sous q-DLOG, avec Fiat–Shamir sur la transcription Poseidon2 dans le modèle de l’oracle aléatoire, et une SRS dont personne ne connaît le `τ`. Les termes statistiques, Schwartz–Zippel sur les défis, restent inférieurs à `2^−220` pour chaque instance utilisée : le niveau de sécurité est donc celui de BN254, environ 100 bits. Rien n’est masquant (*hiding*) et rien n’est aveuglé : Apogee v1.0.0 n’est pas à divulgation nulle de connaissance.

La SRS est celle des puissances de tau perpétuelles de PSE, contribution 80, solide tant qu’un seul contributeur a été honnête. Son fichier est décodé, et l’on vérifie que chaque point se trouve sur sa courbe et dans le bon sous-groupe; rien ne prouve qu’un fichier est bien celui de cette cérémonie, et c’est pourquoi un vérificateur compare le condensé SRS à celui de la cérémonie, obtenu par son propre canal.

La spécification : [Mercury](https://apogee.gweb3networks.com/docs/auditors/spec/mercury), [La chaîne de référence structurée](https://apogee.gweb3networks.com/docs/auditors/spec/srs).