Zero-Knowledge-Wahlsysteme wie das Commitra-Protokoll versprechen geheime, token-gewichtete Abstimmungen auf EVM-Blockchains. In der Praxis zeigen jedoch fehlende mathematische Bindungen in den verwendeten Groth16-Schaltkreisen, dass kryptografische Garantien leicht durch zentrale Vertrauensannahmen ersetzt werden können. Dieser Artikel fasst die wichtigsten Sicherheits- und Schaltkreis-Grenzen des Commitra-Protokolls zusammen, stellt sie dem industriellen Standard von Vocdoni DAVINCI gegenüber und beleuchtet die mathematischen Hürden beim diskreten Logarithmus für 18-Dezimal-Token-Gewichtungen.

Kerndefizite im Commitra-Protokoll

Fehlende Bindungen in Groth16-Schaltkreisen

Die Groth16-Schaltkreise binden lediglich Hash-Werte von Chiffraten. Ohne explizite Constraints wird weder die Gültigkeit der ElGamal-Kurvenpunkte noch der zulässige Plaintext-Bereich (0 ≤ plaintext < q) erzwungen. Das bedeutet, dass ein Angreifer Chiffrate beliebiger Zahlenwerte oder ungültige Gruppenpunkte erzeugen kann, die dennoch einen korrekten Hash ergeben.

Ungebundener Nullifier und Mehrfachabstimmung

Ein vom Merkle-Leaf ungebundener Nullifier ermöglicht es, mehrfach über modifizierte Client-Eingaben abzustimmen. Zwar wird auf-Chain geprüft, dass ein Nullifier nur einmal pro voteId verbraucht wird, doch fehlt die Bindung des Nullifiers an den Leaf, sodass ein neuer privater Nullifier-Secret aus demselben Leaf generiert werden kann.

Diskreter Logarithmus und Token-Gewichtungen

Die Auszählung (Tally) erfolgt über den Baby-Step-Giant-Step-Algorithmus (BSGS). Für Token-Gewichtungen mit 18 Dezimalstellen (typisch für ERC-20) übersteigt der Wertebereich die praktische Suchspanne von BSGS (2^32 bis 2^40, also etwa 4 bis 40 Milliarden Einheiten) bei weitem. Damit wird die Berechnung des diskreten Logarithmus zur Skalierungsgrenze.

Vergleich mit industriellen Standards – Vocdoni DAVINCI & Threshold-ElGamal

Im Gegensatz zum Einzelschlüssel-Modell von Commitra setzt das DAVINCI-Protokoll von Vocdoni auf dezentrale Non-Interactive Distributed Key Generation (NI-DKG) und Threshold-Homomorphic ElGamal-Encryption über die BabyJubJub-Kurve. Dadurch kann kein einzelner Sequencer/Koordinator einzelne Stimmzettel vor oder nach der Aggregation entschlüsseln.

• Verifikationszeit des DAVINCI-ZisK-State-Transition-Proofs auf Ethereum: ca. 300 ms (Jahr 2025)
• Größe des komprimierten Wahl-Batch-Beweises in zkVM-Infrastruktur: 2,7 KB (Jahr 2025)
• Technologie-Stack: Kombination aus zkVM/PLONK und EIP-4844 KZG-Blobs für Batch-Verifikation
• Schlüsselfragmentierung: Private Schlüssel werden über NI-DKG auf mehrere Knoten verteilt; Entschlüsselung erfolgt nur kooperativ.

Diese Architektur eliminiert das Risiko, dass ein einzelner Koordinator einzelne Chiffrate entschlüsseln kann, und adressiert damit das zentrale Vertrauensproblem, das im Commitra-Design besteht.

Mathematische Grenzen des diskreten Logarithmus bei 18-Dezimal-Token

Homomorphe exponentielle ElGamal-Verschlüsselung erfordert zur Entschlüsselung der Summe das Lösen des diskreten Logarithmus auf der elliptischen Kurve. Für Standard-ERC20-Token mit 18 Dezimalstellen liegt der mögliche Wertebereich bei 10^18, während die maximale praktische Suchspanne von BSGS im Browser oder auf einem Single-Node-Server nur 2^32 bis 2^40 beträgt. Das bedeutet, dass der Algorithmus bei realen Token-Gewichtungen nicht mehr praktikabel ist.

Um diese Schranke zu überwinden, setzen produktionsreife Systeme auf:

• Radix-Zerlegung (Segment-Splitting): Aufteilung großer Token-Salden in mehrere kleinere Exponentenblöcke, die parallel aggregiert werden können.
• Multi-Exponentiation: Kombinierte Berechnung mehrerer Exponenten, um die Anzahl der diskreten Logarithmus-Operationen zu reduzieren.

Die Notwendigkeit dieser Techniken wird durch die in INFO 1 genannten Datenpunkte (praktische BSGS-Spanne 2^32-2^40) und die Erklärung, dass 18-Dezimal-Token-Werte die O(√N)-Schranke von BSGS deutlich überschreiten, eindeutig belegt.

Performance-Overhead und weitere Risiken

Die Implementierung vollständiger ElGamal-Punktvalidierung, Non-Zero/Subgroup-Prüfungen und Plaintext-Range-Checks in browserseitigen Groth16-Circuits führt zu einer Vervielfachung der R1CS-Constraint-Anzahl. Das kann zu hohen Prover-Zeiten auf mobilen Endgeräten führen.

• Performance-Overhead: Voll-Validierung erhöht die Constraint-Anzahl signifikant.
• Receipt-Freeness fehlt: Homomorphe Systeme erlauben Wählern, ihre Zufallswerte (Nonces) offenzulegen, was Stimmenkauf und Nötigung ermöglicht. MACI adressiert dieses Problem durch sequenzielle Zustandsaktualisierungen.

Zusätzlich bestehen weitere Trust-Assumptions im Commitra-Design:

• Der einzelne Koordinator besitzt den privaten Schlüssel und kann individuelle Chiffrate entschlüsseln.
• Der Koordinator kann beliebige Roots ohne Bindung an Snapshots akzeptieren, Abstimmungen vorzeitig schließen und Dummy-Registrierungen manipulieren.
• Die Groth16-Proving-Keys wurden einseitig von einer einzelnen Partei erzeugt; ein Multi-Party-Ceremony fehlt.

FAQ – häufig gestellte Fragen zum Commitra-Protokoll

Warum reicht es nicht aus, den Hash der Chiffrate im ZK-Beweis zu verifizieren?

Ein Hash bindet lediglich die Identität der übergebenen Daten, beweist aber nicht deren mathematische Gültigkeit. Ohne zusätzliche algebraische Constraints kann ein Angreifer Chiffrate willkürlicher Zahlenwerte oder ungültige Gruppenpunkte erzeugen, die dennoch einen korrekten Hash ergeben.

Wie verhindert Threshold-ElGamal den Missbrauch durch den Koordinator?

Bei Threshold-ElGamal wird der private Schlüssel über ein Distributed-Key-Generation-Protokoll (DKG) auf mehrere unabhängige Knoten aufgeteilt. Eine Entschlüsselung ist nur kooperativ für die Gesamtsumme möglich; kein einzelner Akteur besitzt den vollständigen Schlüssel, um individuelle Stimmzettel einzusehen.

Was bedeutet „segment splitting“ für große Token-Gewichtungen?

Raw-Token-Balances mit 18 Dezimalstellen machen einen einzelnen BSGS-Bereich impraktisch. Segment-Splitting teilt das Gewicht in mehrere kleinere Exponentenblöcke, die jeweils innerhalb der praktischen BSGS-Grenze (2^32-2^40) liegen und parallel verarbeitet werden können.

Welche Vorteile bietet die Threshold-Decryption gegenüber dem Einzelschlüssel-Modell?

Threshold-Decryption eliminiert die Möglichkeit, dass ein einzelner Koordinator einzelne Stimmen entschlüsselt. Stattdessen wird die Entschlüsselung der aggregierten Summe durch mehrere Teil-Entschlüsselungen und zugehörige Proofs abgesichert.

Fazit

Die Analyse des Commitra-Protokolls verdeutlicht, dass fehlende algebraische Bindungen in Groth16-Circuits, ein ungebundener Nullifier und die Skalierungsgrenze des diskreten Logarithmus bei 18-Dezimal-Token erhebliche Sicherheitslücken erzeugen. Industrielle Standards wie Vocdoni DAVINCI zeigen, wie diese Probleme durch Threshold-ElGamal, NI-DKG und optimierte Verifikations-Stacks (PLONK, KZG-Blobs) adressiert werden können. Gleichzeitig bleibt die mathematische Herausforderung des diskreten Logarithmus bestehen, was Radix-Zerlegung und Multi-Exponentiation zu unverzichtbaren Techniken macht. Für eine sichere, skalierbare und vertrauenslose token-gewichtete Abstimmung auf EVM-Blockchains sind daher sowohl erweiterte ZK-Constraints als auch dezentrale Schlüssel-Architekturen unabdingbar.