Kernpunkte

Die mobile Beweisgenerierung lief über 14× schneller.

Einige Transaktionstests wurden in unter 200 Millisekunden abgeschlossen.

Die Netzwerkbestätigung bleibt ein separater Vorgang.

Wallet-Integrationen entscheiden, wer von den Verbesserungen profitiert.

Die Verzögerung entsteht, bevor Zcash die Zahlung sieht

Bevor eine private Zcash-Zahlung das Netzwerk erreicht, muss das Wallet des Senders verwendbare Notes auswählen, die Transaktion vorbereiten, einen Zero-Knowledge-Beweis generieren und das Ergebnis signieren. Die Beweisgenerierung macht einen Großteil der lokalen Wartezeit aus, da sie nachweisen muss, dass die Zahlung gültig ist, ohne Absender, Empfänger oder überwiesenen Betrag preiszugeben. Dieser lokale Berechnungsschritt war historisch einer der praktischen Kompromisse shielded Zahlungen gegenüber transparenten Zahlungen, bei denen das Wallet vor dem Broadcast deutlich weniger kryptografische Arbeit leistet.

Zakura gibt an, dass seine Open-Source-Common-Bibliotheken diesen Vorgang in einigen Tests von über drei Sekunden auf unter 200 Millisekunden reduzierten. Auf der Benchmark-Hardware des Teams lief die mobile Beweisgenerierung über 14-mal schneller, während sich die Desktop-Generierung um mehr als das Fünffache verbesserte.

Die Ergebnisse stammen aus Zakuras eigenen Tests und nicht aus unabhängigen Wallet-Benchmarks. Die tatsächliche Leistung hängt vom Gerät, Betriebssystem, der Transaktionszusammensetzung und der Wallet-Implementierung ab – ein älteres Telefon kann die genannten Zahlen daher möglicherweise nicht erreichen.

Wo die 200 Millisekunden enden

Eine Zcash-Zahlung durchläuft weiterhin drei separate Phasen:

Konstruktion: Das Wallet erstellt die Transaktion und generiert den Datenschutz-Beweis auf dem Gerät des Nutzers. Zakura Common beschleunigt diese Phase.

Broadcast und Bestätigung: Das Wallet übermittelt die fertige Transaktion an Zcash-Knoten. Sie bleibt unbestätigt, bis ein Miner sie in einen Block aufnimmt.

Settlement-Gewissheit: Jeder weitere Block fügt eine zusätzliche Bestätigung hinzu und verringert die Möglichkeit einer Rückgängigmachung durch eine Chain-Reorganisation.

Die Zcash-Dokumentation definiert die erste Bestätigung als den Zeitpunkt, an dem eine Transaktion in einen Block aufgenommen wird. Das Ergebnis von unter 200 Millisekunden endet vor dem Broadcast; Blockproduktion, Mempool-Bedingungen und die Bestätigungsrichtlinie des Empfängers bestimmen weiterhin, wann die Zahlung als abgewickelt gilt.

Die Verbesserungen gehen über den Senden-Button hinaus

Zakura maß zudem Verbesserungen in drei Vorgängen, die Transaktionsverarbeitung, Wallet-Synchronisierung und Knotenleistung betreffen:

Sinsemilla-Hashing: In Zakuras Tests über 21-mal schneller. Zcash nutzt diese Hash-Funktion innerhalb seines Shielded-Protokolls, sodass eine schnellere Ausführung einen Teil der kryptografischen Arbeitslast reduziert.

Test-Entschlüsselung (Trial Decryption): über 1,5-mal schneller. Wallets nutzen diesen Vorgang beim Scannen der Blockchain, um shielded Outputs zu identifizieren, die ihnen gehören.

zk-SNARK-Verifizierung: zwischen vier- und achtmal schneller. Knoten nutzen die Verifizierung, um einen shielded Beweis zu prüfen, ohne die geschützten Informationen zu erfahren.

Schnellere Test-Entschlüsselung könnte Wallet-Synchronisierung und Kontowiederherstellung verkürzen, während eine günstigere Verifizierung die Arbeitslast der Knoten reduziert. Zakura erwartet zudem, dass die Full-Node-Verbesserungen schnellere Transaktionsweitergabe und weniger verwaiste Blöcke unterstützen.

Der Zeitpunkt ist relevant, da mehr ZEC in neuere Shielded-Infrastruktur wandert. Wie zuvor berichtet, war Ironwood kurz nach Aktivierung zum größten Shielded-Pool von Zcash geworden und hatte Orchard überholt. Mit wachsender Shielded-Aktivität werden langsame Wallet-Konstruktion und -Synchronisierung zu Problemen, denen mehr Nutzer begegnen können.

Kein Hard Fork bedeutet auch kein automatisches Rollout

Zakura Common verändert, wie Software bestehende kryptografische Arbeit ausführt, ohne die Konsensregeln von Zcash zu ändern. Die Bibliotheken erzeugen Beweise, die das heutige Netzwerk bereits versteht, sodass Wallet-Entwickler sie nutzen können, ohne auf die Aktivierung eines Hard Forks durch Miner und Knoten zu warten. Dieser rein softwarebasierte Upgrade-Pfad ist charakteristisch für Zcasts jüngste Protokollarbeit, bei der Optimierungen auf Wallet- und Bibliotheksebene Nutzer über normale App-Releases erreichen können statt über koordinierte Netzwerk-Upgrades.

Das Common-Repository ist unter MIT- und Apache-2.0-Lizenzen verfügbar. Ein separates wallet-libraries-Repository verbindet Wallet-Komponenten mit dem optimierten Stack.

Diese Kompatibilität beseitigt eine netzwerkweite Einsatzbarriere, doch jeder Wallet-Entwickler muss den Code prüfen, integrieren und testen, bevor er ihn an Nutzer ausliefert. Wallets, die ihren aktuellen Proving-Stack behalten, behalten ihre bisherige Leistung.

Zakura gibt an, dass die kommende Version 1.3.0 Common verwenden wird. Danach richtet sich die Aufmerksamkeit auf unabhängige mobile Wallets. deren Release Notes und Tests auf echten Geräten zeigen werden, ob sich die Verbesserung über Zakuras eigene Software hinaus verbreitet.

Die Wallet-Adoption ist nun der Engpass

Zakuras Benchmarks zeigen, dass Shielded-Beweisgenerierung deutlich schneller laufen kann, ohne das Zcash-Netzwerk zu verändern. Das praktische Ergebnis hängt nun davon ab, ob etablierte Wallets die Bibliotheken ausliefern und ob unabhängige Tests die Gewinne auf gängigen Telefonen reproduzieren.

Auch Synchronisierungs- und Wiederherstellungszeiten sind relevant. Wenn diese Wartezeiten ohne höhere Fehlerraten sinken, wird Common mehr verbessert haben als den Moment, in dem ein Nutzer „senden“ drückt.

Zakura hat gezeigt, dass die Wallet-seitige Verzögerung reduziert werden kann, ohne Zcash selbst zu ändern. Die offene Frage ist, wie viele Wallet-Entwickler diese Geschwindigkeit in die Hände der Nutzer bringen werden.

Der Beitrag Zcash Wallet Upgrade Makes Private Payments Faster erschien zuerst auf Coindoo.