Die Wahl der kryptografischen Hashfunktion bestimmt maßgeblich die Leistungsfähigkeit, die Rechenkosten und die Sicherheit von Zero-Knowledge-Beweissystemen. In Anwendungsbereichen wie Zk-EVMs, Zk-Rollups oder DAO-Verifikationen auf Ethereum spielt die Effizienz von Hashes eine zentrale Rolle – besonders wenn Post-Quanten-Sicherheit und praktische Anpassungsfähigkeit gefordert sind. Dieser Artikel fasst die wesentlichen Fakten zu Poseidon, klassischen Hashes (Keccak-256, SHA-2) und dem neuen Binärfeld-SNARK-System Binius zusammen.

Warum klassische Hashes in traditionellen SNARK-Arithmetisierungen ineffizient sind

Standard-SNARK-Frameworks wie R1CS arbeiten über großen Primkörpern (z. B. BN254). Bitweise Operationen wie XOR müssen dabei in einzelne Bit-Constraints zerlegt werden. Das führt zu Tausenden von Constraints pro 256-Bit-Block, wodurch Hashes wie Keccak-256 oder SHA-256 in klassischen SNARKs extrem langsam sind.

• Bitzerlegung erzeugt tausende Constraints pro Hash-Block.
• Resultierende Rechenkosten machen den Einsatz in praktischen ZK-Anwendungen kaum machbar.

Poseidon: HADES-Design und Rundenstruktur

Poseidon basiert auf der HADES-Architektur, die volle und partielle Runden kombiniert, um statistische und algebraische Angriffe mit minimalem S-Box-Aufwand abzuwehren. Für einen Zustand von t = 10 über einem 256-Bit-Körper wird standardmäßig die folgende Rundenkonfiguration verwendet:

• 8 volle Runden ( RF ) – Standard für 128-Bit-Sicherheit über Primkörpern (2021).
• typischerweise über 80 partielle Runden ( RP ) – in der Praxis häufig 83, also insgesamt 91 Runden.

In jeder partiellen Runde durchläuft nur ein Zustandselement die Potenzierungs-S-Box ( x^d ), was die Anzahl der S-Box-Anwendungen stark reduziert (1 pro partielle Runde, Messwert 2021).

Messwerte zur Constraint-Reduktion

• Standard-Sicherheitsniveau Poseidon (Prime Field): 128 Bit (2021, Quelle S1).
• Typische Constraint-Reduktion Poseidon vs. SHA-256 in R1CS: Faktor 8-15 (2021, Quelle S1).

Bedeutung der Sponge-Kapazität für klassische und Quanten-Sicherheit

In Sponge-Konstruktionen bestimmt die Kapazität c die Obergrenze der Preimage- und Kollisionssicherheit. Klassisch liefert die Kapazität c Bits Sicherheit; unter Grovers Algorithmus wird diese Sicherheit auf c/2 Bits reduziert.

• Klassische Preimage-Sicherheit: c Bits (2020).
• Grover-Preimage-Sicherheit: c/2 Bits (2020).

Für ein 256-Bit-Primfeld wird daher eine Kapazität von 256 Bits empfohlen, um sowohl klassische als auch quantenresistente Sicherheit zu gewährleisten (127,5 Bit klassisch / 63,75 Bit quantum, wie in Diskussionen erwähnt).

Binius-Proof-Systeme und nativer Umgang mit bitweisen Hashfunktionen

Binius ist das erste SNARK-System, das Binärfelder ( 𝔽₂^k ) nutzt und damit bitweise Logik (XOR, AND, Rotationen) direkt ausführen kann. Dadurch entfällt die zuvor notwendige Constraint-Explosion.

• Constraint-Zahl pro SHA-256 in Binius (geschätzt, 2026): ± 10 000 – vergleichbar mit algebraischen Hashes.
• Hash-Verifikationsgeschwindigkeit in Binius (Theorie, 2026): 1,5 Millionen Proofs pro Sekunde bei SHA-256-Komplexität.
• Basisfeldgröße Binius: 2 Elemente (0, 1) (2024, Quelle S2).
• Constraint-Reduktion SHA-256 in Binius vs. Plonk: Faktor 50-100 (2025, Quelle S3).

Durch diese Eigenschaften wird Keccak-256 oder SHA-256 plötzlich effizient beweisbar, was den Geschwindigkeitsvorteil spezialisierter algebraischer Hashes wie Poseidon potenziell obsolet macht.

Kontroverse und Gegenargumente aus der Community

Die Diskussion in der Ethereum-Research-Community wirft mehrere kritische Punkte auf:

• Verkürzte Kryptoanalyse algebraischer Hashes: Poseidon und ähnliche Funktionen haben erst wenige Jahre intensiver Analyse hinter sich, wodurch sie anfälliger für neue algebraische Angriffe sein könnten als etablierte Hashes.
• Implementierungskomplexität von Binärfeld-SNARKs: Binius bietet theoretische Vorteile, ist jedoch technisch aufwendig, schwer auditierbar und erfordert komplexe Arithmetisierungen sowie Folding-Verfahren.
• Skalierungsmöglichkeiten von Binärfeld-Proofs: Derzeit ist die Skalierung an spezielle Hard- oder Software-Implementierungen gebunden und kann nicht ohne GPU-basierte Parallelisierung weiter optimiert werden.

In einem öffentlichen Forum wurden zudem konkrete technische Einwände geäußert:

• Ein Nutzer argumentierte, dass bei einer Konfiguration t = 10 und 8 vollen Runden die Diffusion nicht ausreichend sei und mehr Runden (z. B. 20) die Effizienz zerstören würden.
• Ein anderer Beitrag betonte, dass die korrekte Konfiguration über das offizielle Conda-Script generiert werden sollte und dass Keccak kein algebraischer Hash ist, weshalb er in zkSTARKs nicht direkt nutzbar sei.
• Mehrere Beiträge wiesen darauf hin, dass die Kosten für die Bitzerlegung bei klassischen SNARKs zu „tausenden“ Constraints führen, während Binius diese Kosten eliminiert.

FAQ zu Poseidon und Binius

Warum war Keccak-256 in klassischen SNARKs bisher so langsam?

Klassische SNARKs arbeiten über großen Primkörpern. Bitweise Operationen wie XOR erfordern die Aufteilung jedes 256-Bit-Worts in einzelne Bits, was tausende Constraints pro Hash-Block erzeugt. Binius vermeidet das, indem es direkte Boolesche Feldarithmetik nutzt.

Was bedeutet ‚Kapazität‘ in Poseidon?

Die Kapazitätselemente bleiben im Sponge-Zustand verdeckt und verhindern Preimage- und Kollisionsangriffe. Mehr Kapazität erhöht die Sicherheit; für 256-Bit-Körperformate werden 256 Bit Kapazität empfohlen, um maximale klassische und quantenresistente Sicherheit zu erreichen.

Warum ist Binius ein Paradigmenwechsel?

Binius nutzt binäre Felder für SNARKs, wodurch traditionelle bitweise Hashfunktionen wie Keccak-256 ohne zusätzlichen Beweis-Overhead nativ und schnell unterstützt werden. Dadurch verlieren spezialisierte algebraische Hashes wie Poseidon ihren Geschwindigkeitsvorteil.

Fazit

Poseidon bietet mit seinem HADES-Design und einer gut abgestimmten Kombination aus vollen und partiellen Runden eine effiziente und sichere Lösung für Zero-Knowledge-Beweise über große Primkörper. Die Sicherheit hängt jedoch stark von der gewählten Sponge-Kapazität ab, insbesondere im Hinblick auf zukünftige Quantenangriffe. Gleichzeitig eröffnet Binius durch die direkte Verarbeitung von Bit-Operationen über Binärfelder neue Möglichkeiten: klassische Hashes wie Keccak-256 und SHA-256 werden plötzlich konkurrenzfähig, was den Bedarf an spezialisierten algebraischen Hashes reduzieren könnte.

Dennoch bleiben offene Fragen: Die relativ kurze Kryptoanalyse von Poseidon, die Komplexität der Implementierung von Binärfeld-SNARKs und die derzeitige Abhängigkeit von speziellen Hardware- und Software-Stacks könnten die breite Adoption von Binius bremsen. Die zukünftige Entwicklung wird zeigen, ob Binius als universelle Plattform für Zero-Knowledge-Proofs etabliert wird und damit die Bedeutung von spezialisierten Hash-Designs wie Poseidon langfristig erodiert.