Am 17. Juni um 18:00 Uhr UTC nahmen die an das Zcash-Netzwerk übermittelten abgeschirmten Transaktionen dramatisch zu. Infolgedessen haben Wallets von Drittanbietern eine geringere Leistung erfahren. Das Netzwerk blieb und bleibt stabil und betriebsbereit, und Transaktionen werden normal verarbeitet.
Das ECC-Kernteam arbeitete über die Feiertage am 4. Juli an der Implementierung eines neuen Batch-Validierungsalgorithmus, um die Verifizierungszeit um weitere 80 % zu reduzieren. Ihre Bemühungen führten dazu, dass Release zcashd 5.1.0 live ging.
Zusammenfassung
Diese Version zielt hauptsächlich darauf ab, die Validierungsleistung von Sapling- und Orchard-Transaktionen sowie eine inkrementelle Verbesserung der Scanleistung von Post-NU5-Blöcken zu verbessern. Die Version verbesserte auch die Leistung von getblocktemplate und fügte Orchard-Informationen zu getrawtransaction und decoderawtransaction hinzu. Wir werden weiterhin verbleibende Probleme mit der Scanleistung in nachfolgenden Versionen beheben.
Bemerkenswerte Änderungen
Schnellere Blockvalidierung für Sapling- und Orchard-Transaktionen
Die Blockvalidierung in zcashd ist hauptsächlich ein Single-Thread-Prozess, da die von Bitcoin Core geerbte Chain-Update-Logik geschrieben ist. Bestimmte rechenintensivere Prüfungen werden jedoch effizienter durchgeführt, als alles einzeln zu prüfen:
ECDSA-Signaturen auf transparenten Eingaben werden per Multithreading geprüft. RedPallas-Signaturen auf Orchard-Aktionen werden per Batch-Validierung geprüft.
Ab dieser Version wendet zcashd diese Techniken auf weitere Sapling- und Orchard-Komponenten an:
RedJubjub-Signaturen auf Sapling Spends werden per Batch-Validierung geprüft. Groth16 Proofs für Sapling Spends und Outputs werden per Batch-Validierung und Multithreading geprüft. Halo 2-Proofs für Orchard Actions werden per Batch-Validierung und Multithreading geprüft.
Dies reduziert die Blockvalidierungszeiten im schlimmsten Fall für beobachtete historische Blöcke auf einer Ryzen 9 5950X-CPU um etwa 80 %.
Die Anzahl der Threads, die für die Überprüfung von Groth16- und Halo-2-Proofs verwendet werden (sowie für deren Erstellung bei der Ausgabe von Geldern), kann über die Umgebungsvariable RAYON_NUM_THREADS festgelegt werden.
Handhabung von Optionen
Ein neues Argument -preferredtxversion ermöglicht es dem Knoten, vorzugsweise Transaktionen einer bestimmten Version zu erstellen, wenn eine Transaktion keine Komponenten enthält, die eine Erstellung mit einer bestimmten Version erfordern. Beispielsweise bewirkt die Einstellung -preferredtxversion=4, dass der Knoten V4-Transaktionen erstellt, wenn die Transaktion keine Orchard-Komponenten enthält. Dies kann hilfreich sein, wenn Empfänger von Transaktionen wahrscheinlich Legacy-Wallets verwenden, die noch nicht aktualisiert wurden, um das Parsen von V5-Transaktionen zu unterstützen.
RPC-Schnittstelle
Die RPC-Methode getblocktemplate überspringt jetzt Beweis- und Signaturprüfungen für von ihr erstellte Vorlagen, da diese Vorlagen nur Transaktionen enthalten, die zuvor beim Hinzufügen zum Mempool überprüft wurden. Die RPC-Methoden getrawtransaction und decoderawtransaction enthalten jetzt Details zu Orchard-Aktionen innerhalb von Transaktionen.
Geldbörse
Die Rescan-Leistung von Post-NU5-Blöcken wurde leicht verbessert (die Gesamtrescan-Zeit für eine Brieftasche mit einem Konto verringert sich um etwa 6 % auf einem Ryzen 9 5950X). Weitere Verbesserungen werden in zukünftigen Versionen implementiert, um den Effekt von Blöcken voller abgeschirmter Ausgänge abzumildern. Das CWallet::UpdatedTransaction-Signal wird nicht mehr aufgerufen, während die cs_main-Sperre gehalten wird. Dies behebt ein Problem, bei dem RPCs auf zcashd-Knoten mit großen Brieftaschen für längere Zeit blockieren konnten. Downstream-Code-Forks, die das NotifyTransactionChanged-Wallet-Signal wieder verbunden haben, sollten diese Änderung zur Kenntnis nehmen und sich dort nicht auf den Zugriff auf durch cs_main geschützte Globals verlassen. Einige zcashd 5.0.0-Knoten würden einige Zeit nach dem Start mit dem Fehler ThreadNotifyWallets: Failed to read heruntergefahren Blockieren Sie X, während Sie Wallets über Blocktrennungen benachrichtigen. zcashd versucht nun, die Situation zu korrigieren, und informiert den Benutzer andernfalls vor dem Herunterfahren darüber, dass eine Neuindizierung erforderlich ist.
Veraltet
Ab dieser Version sind die folgenden zuvor veralteten Funktionen standardmäßig deaktiviert, können jedoch mit -allowdeprecated=
Die Dumpwallet-RPC-Methode ist deaktiviert. Es kann mit allowdeprecated=dumpwallet wieder aktiviert werden. dumpwallet sollte nicht verwendet werden; Es ist für Sicherungszwecke unsicher, da es keine Schlüsselinformationen für Schlüssel zurückgibt, die zum Ableiten abgeschirmter Adressen verwendet werden. Verwenden Sie stattdessen z_exportwallet.
Ab dieser Version sind die folgenden Funktionen veraltet, bleiben aber standardmäßig verfügbar. Diese Funktionen können durch die Einstellung -allowdeprecated=none deaktiviert werden. Nach mindestens 3 Veröffentlichungen von Nebenversionen werden diese Funktionen standardmäßig deaktiviert, und die folgenden Flags für -allowdeprecated sind erforderlich, um ihre weitere Verwendung zuzulassen:
wallettxvjoinsplit – steuert die Verfügbarkeit des veralteten vjoinsplit-Attributs, das von der RPC-Methode gettransaction zurückgegeben wird.
Die Zcash-Zeitplanseite wurde aktualisiert, um die Version 5.1.0 widerzuspiegeln.
