Zero-Knowledge-Rollups und andere kryptografische Protokolle auf Ethereum benötigen Hashfunktionen, die innerhalb arithmetischer Schaltkreise extrem wenige Constraints erzeugen und gleichzeitig langfristige Resistenz gegen klassische sowie quantenbasierte Urbild-Angriffe garantieren. In diesem Artikel werden die Sicherheit und Effizienz von Poseidon – einer algebraischen Hashfunktion – gegenüber dem traditionellen Bit-Hash Keccak-256 analysiert. Dabei stehen die Auswirkungen von Grovers Algorithmus, die Parameterwahl in der Sponge-Konstruktion und die praktische Diskussion in der Ethereum-Community im Fokus.

Poseidon vs. Keccak-256: Grundlagen und Unterschiede

Poseidon ist für den Einsatz in zk-SNARKs und zk-STARKs konzipiert und arbeitet direkt mit nativer Körperarithmetik (z. B. $x^d \bmod p$) über Primkörpern wie BN254. Keccak-256 hingegen basiert auf 64-Bit-Bitoperationen (XOR, AND, Rotationen). In algebraischen Beweissystemen muss jedes Bit eines 256-Bit-Worts einzeln als Constraint abgebildet werden, was zu tausenden zusätzlichen Constraints führt. Diese strukturelle Differenz macht Poseidon in zk-Schaltkreisen um ein Vielfaches effizienter.

Arithmetisierungskompatibilität: Primkörper-Operationen vs. Bit-Zerlegung

Standard-Hashes wie Keccak-256 erfordern eine Bit-Decomposition, weil die zugrunde liegenden Operationen bitweise definiert sind. In einem Feld-basierten System (z. B. BN254) entsteht für jedes einzelne Bit ein separater Constraint. Poseidon nutzt hingegen direkte Primkörper-Operationen und reduziert den Beweisaufwand drastisch.

• Constraint-Reduktion in R1CS/PlonK: Faktor 10 bis 100 (Jahr 2021, Quelle S1)
• Reduktion linearer Multiplikationen in Poseidon2: bis zu 90 % (Jahr 2023, Quelle S4)
• Constraint-Reduktion in PlonK-Schaltkreisen durch Poseidon2: bis zu 70 % (Jahr 2023, Quelle S4)

Sicherheitsanalyse: Klassische und quantenbasierte Preimage-Angriffe

Eine Poseidon-Konfiguration mit 127,5 Bit klassischer Sicherheit liefert nach Anwendung von Grovers Algorithmus etwa 63,75 Bit quantenmechanische Preimage-Sicherheit. Durch Hinzufügen von Kapazitätselementen (Capacity Elements) in der Sponge-Konstruktion über einem 256-Bit-Primkörper kann die Sicherheitsmarge auf 256 Bit klassisch bzw. 128 Bit post-quantum skaliert werden.

Die Sicherheit einer Sponge-Konstruktion wird maßgeblich durch die Kapazität $c$ bestimmt:

• Bei $c = 1$ in einem 256-Bit-Feld: klassische Kollisionssicherheit ≈ 128 Bit, Preimage-Sicherheit 256 Bit.
• Unter Grover-Algorithmus halbiert sich die Preimage-Sicherheit auf ≈ 128 Bit.
• Bei kleineren Ausgabedimensionen oder unzureichender Kapazität sinkt die Sicherheit auf bedenkliche ≈ 64 Bit.

Die quanten-Preimage-Komplexität folgt dem bekannten $O(2^{n/2})$-Verhalten (Jahr 2021, Quelle S3).

HADES-Design und Rundenkonfigurationen von Poseidon

Poseidon verwendet das HADES-Design, das volle Runden ($RF$) und partielle Runden ($RP$) kombiniert. Volle Runden bieten Diffusion gegen statistische Angriffe, partielle Runden schützen gegen algebraische Angriffe. Die exakte Rundenanzahl ist mathematisch durch Sicherheitsmargen gegen Gröbner-Basis- und Interpolationsangriffe festgelegt und kann nicht beliebig reduziert werden.

Typische Konfiguration für $t=3$ (BN254):

• 8 volle Runden
• 57 partielle Runden

Diese Parameter ergeben 128 Bit klassische Sicherheit (Jahr 2021, Quelle S1). Für breitere Zustände (z. B. $t=10$) wird häufig von 91 Gesamtrunden (8 volle + 83 partielle) gesprochen, was zu einer erheblichen Anzahl von Feldoperationen führt.

Effizienzgewinne durch Poseidon2

Poseidon2, eine Weiterentwicklung von Poseidon, optimiert die lineare Schicht und reduziert den Aufwand in PlonK-Schaltkreisen deutlich:

• Bis zu 90 % Reduktion linearer Multiplikationen.
• Bis zu 70 % weniger Constraints in PlonK-Beweisen.

Diese Verbesserungen stärken die Argumentation, dass algebraische Hashes in zk-Beweissystemen deutlich performanter sind als bitweise Hashes.

Praktische Diskussion aus der Ethereum-Community

In einem öffentlichen Forum äußerten mehrere Nutzer Bedenken gegenüber Poseidon:

• Ein Beitrag behauptete, Poseidon-Hash für Ethereum sei nicht sicher, weil die klassische Preimage-Sicherheit 127,5 Bit und die quantenbasierte Sicherheit nur 63,75 Bit betragen.
• Ein anderer Nutzer erklärte, dass das Hinzufügen von mindestens einem Kapazitätselement im 256-Bit-Feld die Sicherheit auf 256 Bit klassisch und 128 Bit post-quantum bringe.
• Diskussionen über die Wahl von $t=10$ zeigten, dass 91 Runden (8 volle + 83 partielle) zu 910 partiellen Feldoperationen führen und damit die Effizienz von Poseidon im Vergleich zu Keccak-256 stark beeinträchtigen könnten.
• Mehrere Kommentare betonten, dass Keccak-256 in zk-STARKs nicht einfach verwendet werden kann, weil die Bit-Zerlegung zu tausenden zusätzlichen Constraints führt – ein Argument, das mit den in INFO 1 genannten Daten übereinstimmt.

Die Debatte verdeutlicht das zentrale Dilemma moderner Zero-Knowledge-Architekturen: die Balance zwischen kryptografischer Reife (Keccak-256 hat jahrzehntelange Analyse) und arithmetischer Effizienz (Poseidon reduziert Constraints signifikant).

FAQs zum Thema Poseidon und Keccak in zk-Beweisen

• Warum kann Keccak-256 in STARKs/SNARKs nicht einfach wie gewohnt verwendet werden? Keccak nutzt bitweise Logikgatter wie XOR und Rotationen. In zk-Schaltkreisen über Primkörpern muss jeder 256-Bit-Wert in 256 einzelne Bits zerlegt werden, was den Beweis-Aufwand um Größenordnungen erhöht (Quelle S2).
• Wie schützt man Poseidon vor quantenbasierten Preimage-Angriffen? Durch Erhöhung der Kapazität der Sponge-Konstruktion auf mindestens zwei 256-Bit-Körperelemente oder durch Setzen der Ausgabegröße auf mindestens 256 Bit, sodass nach Grovers quadratischer Reduktion noch mindestens 128 Bit Quantensicherheit verbleiben (Quellen S1, S3).

Fazit

Poseidon und seine Weiterentwicklung Poseidon2 zeigen, dass algebraische Hashfunktionen in Zero-Knowledge-Beweissystemen erhebliche Effizienzvorteile gegenüber traditionellen Bit-Hashes wie Keccak-256 bieten. Durch native Primkörper-Operationen reduziert sich der Constraint-Aufwand um Faktoren von zehn bis hundert, und die optimierten Runden-Designs gewährleisten 128 Bit klassische Sicherheit. Quantensicherheit kann durch geeignete Wahl von Kapazitätselementen in der Sponge-Konstruktion auf 128 Bit post-quantum angehoben werden, selbst wenn Grovers Algorithmus die Preimage-Sicherheit halbiert. Während Keccak-256 über lange Zeit robust analysiert wurde, bleibt seine Nutzung in zk-STARKs und zk-SNARKs aufgrund der erforderlichen Bit-Decomposition ineffizient. Die aktuelle Diskussion in der Ethereum-Community bestätigt, dass die praktische Implementierung von Poseidon sorgfältige Parameterwahl erfordert, insbesondere bei breiteren Zuständen (z. B. $t=10$). Insgesamt überwiegen die arithmetischen Vorteile von Poseidon in zk-Umgebungen, sofern die Sicherheitsparameter korrekt gewählt werden.