# Polynom-Commitments

> Jede committete Spalte wird mit Mercury geöffnet, einem multilinearen Commitment über KZG mit einer Öffnung konstanter Größe. Was es kostet, wie ein Shard alle seine Spalten in einer einzigen Öffnung bündelt und wie die Rekursion das Pairing aufschiebt.

Jede Spalte, die Apogee committet, ist ein multilineares Polynom, eine Tabelle von `2^n` Auswertungen über dem booleschen Hyperwürfel. Jede davon wird mit **Mercury** (Eagen und Gabizon, ePrint 2025/385) committet und geöffnet, abgeschlossen durch die gebündelte KZG-Öffnung von BDFG20 (Boneh, Drake, Fisch und Gabizon, ePrint 2020/081). Die Spezifikation legt fest, was die Arbeiten offenlassen, und fügt zwei Dinge hinzu: einen Batch vieler Spalten an einem Punkt und eine aufgeschobene Form, die der Rekursionsbaum faltet.

## Das Commitment

Ein Mercury-Commitment ist genau das KZG-Commitment der Auswertungstabelle, gelesen als Koeffizienten: eine Multi-Skalar-Multiplikation über die ersten `n` Potenzen des `τ` der Zeremonie, ein G1-Punkt, 64 Byte. Dahinter steht kein zweites Verfahren. Daraus folgen zwei Eigenschaften, und der Rest des Systems nutzt beide:

- **Es ist linear.** Das Commitment von `Σ ρ^i·f_i` ist `Σ ρ^i·cm_i`; deshalb können sich viele Spalten eine Öffnung teilen.
- **Nullkoeffizienten tragen nichts bei.** Eine um Nullzeilen erweiterte Spalte behält ihr Commitment; die drei Commitments der generischen Lookup-Tabelle dienen also jeder Höhe, die die Tabelle aufnimmt, und sie sind eine Konstante der Zeremonie.

Spalten werden mit ihrer Ganzzahlbreite committet: Eine Bit-, Byte-, Halbwort- oder Wortspalte läuft durch eine MSM über `u32`-Skalare, umkodiert aus 32 statt 254 Bit, was das Committen eines Trace günstig hält.

## Die Öffnung

Mercury teilt einen Öffnungspunkt `u` mit `s = 2t` Variablen in zwei Hälften, faltet das Polynom mit einer Challenge `α` und beweist die beiden verbleibenden inneren Produkte mit einem symmetrisierten Witness, abgeschlossen durch eine einzige gebündelte KZG-Öffnung an drei Punkten. Der Beweis besteht aus **acht G1-Punkten und sechs Körperelementen: 704 Byte**, für jede Größe. Daraus folgt eine Anforderung: Die Zahl der Variablen muss gerade sein, und deshalb ist jede Höhe in der Auswahl eine Zweierpotenz mit geradem Exponenten.

Der Verifier führt `O(t)` Körperoperationen, MSMs über zehn und über zwei Punkte und **eine Pairing-Prüfung mit zwei Paaren** aus. Beide Relationen, die er prüft, sind als `e(A, [1]_2) = e(B, [x]_2)` geschrieben; beide G2-Argumente sind also Konstanten des Setups, und der Verifier führt überhaupt keine G2-Arithmetik aus. Diese Form erlaubt es der Rekursion auch, das Pairing aufzuschieben, statt es zu berechnen.

## Die Spalten eines Shards, eine Öffnung

Der GKR-Durchlauf endet mit Behauptungen über jede committete Spalte eines Shards am selben Punkt `u`. Es braucht also keinen Sumcheck, der Behauptungen zusammenführt: Die Öffnung bündelt sie alle. Eine Challenge `ρ`, gezogen nach jedem Commitment und jedem behaupteten Wert, gewichtet Spalte `i` mit `ρ^i`; der Prover öffnet `Σ ρ^i·f_i` einmal, und der Verifier bildet `Σ ρ^i·cm_i` durch eine MSM über `k` Punkte. Eine falsche Behauptung überlebt mit Wahrscheinlichkeit höchstens `(k − 1)/|Fr|`.

Die Spalten im Batch stammen aus drei Quellen, in einer festen Reihenfolge, die Teil dessen ist, was bewiesen wird: die Commitments der Speicherspalten aus der Aussage, die der Witness-Spalten aus dem Shard-Beweis und die der Setup-Spalten aus dem Verifikationsschlüssel. Weil die Setup-Commitments dem Schlüssel entnommen werden, bindet die Öffnung die dekodierten Tabellen und das Image, die die Programmidentität committet.

## Aufgeschobene Verifikation

Eine aufgeschobene Prüfung führt alles außer dem Pairing aus und behält die Terme der Relation als zwölf Einträge `(side, scalar, point)`. Genau das nutzt die Rekursion: Jeder Knoten des Baums berechnet die zwölf Skalare eines Shards in seiner eigenen Arithmetik, gewichtet sie mit frischen Challenges und addiert sie in ein einziges laufendes Punktepaar `(A, B)`. Die Öffnung jedes Shards im gesamten Baum wird in eine einzige Behauptung `e(A, [1]_2) = e(B, [x]_2)` gefaltet, die erst der Contract auf Ethereum endgültig prüft. [Rekursion und Abwicklung](https://apogee.gweb3networks.com/docs/architecture/recursion) zeigt das Falten.

## Gemessen

Auf einem Apple M5 Pro mit 18 Kernen:

| Operation | Zeit |
| --- | --- |
| Eine `2^22`-Spalte committen | 1,30 s |
| Eine `2^22`-Spalte öffnen | 2,89 s |
| 16 Spalten der Größe `2^20`, als ein Batch geöffnet | 1,01 s, verifiziert in 4,8 ms |
| Dieselben 16 einzeln geöffnet | 9,79 s, verifiziert in 62 ms |

## Sicherheit

Knowledge Soundness gilt im algebraischen Gruppenmodell unter q-DLOG, mit Fiat–Shamir über dem Poseidon2-Transkript im Random-Oracle-Modell und einem SRS, dessen `τ` niemand kennt. Die statistischen Terme, Schwartz–Zippel über die Challenges, bleiben für jede verwendete Instanz unter `2^−220`; das Sicherheitsniveau ist also das von BN254, etwa 100 Bit. Nichts ist hiding, und nichts wird verblindet: Apogee v1.0.0 ist nicht zero-knowledge.

Als SRS dienen die Perpetual Powers of Tau der PSE, Beitrag 80, deren Soundness gegeben ist, solange ein Beitragender ehrlich war. Ihre Datei wird dekodiert, und für jeden Punkt wird geprüft, dass er auf seiner Kurve und in der richtigen Untergruppe liegt; nichts beweist, dass eine Datei die dieser Zeremonie ist, und deshalb vergleicht ein Verifier den SRS-Digest mit dem der Zeremonie aus seinem eigenen Kanal.

Die Spezifikation: [Mercury](https://apogee.gweb3networks.com/docs/auditors/spec/mercury), [Der strukturierte Referenzstring](https://apogee.gweb3networks.com/docs/auditors/spec/srs).