The implementation of `io:Read` for `ResponseLazyReader` used to return
only one byte regardless of the size of the provided `buf`, which
significantly degraded the performance of loading the response.
This change makes use of the provided `buf`. On my machine with Rust
1.64, the downloading speed went up from ~100 KiB/s to ~2 MiB/s.
However, as before this change, the process still uses 100% of a single
CPU thread when downloading the response. The most likely reason is that
we still manually read each byte of the response. I can download the
same data with ~ 50 MiB/s on my machine using a different HTTP client.
This fix seems to be sufficient for now.
* Download sprout parameters in-memory
* Add download_sapling_parameters and deprecate download_parameters
* This avoids confusion between sprout and sapling downloads,
while maintaining backward compatibility.
* Download a single file, rather than parts
* This is more efficient, because TCP adjusts its transfer speed
in the first ~20 seconds of each new connection.
* Only download files if needed, but always check the hashes
* Allow the caller to specify a response timeout
* Stream downloads from server to disk
* Refactor file loads to use the same verifying function as downloads
* Check file sizes to help debug parameter load failures
* Remove downloaded files on error (but leave existing files alone)
* Add a sprout and sapling download example
* Move the download Read impl into its own module
* Derive standard traits on SaplingParameterPaths
* Require features for the load parameters method
Nullifier computation only requires the nullifier deriving key,
not the entire Sapling viewing key. This separation of concerns
will be needed for batch decryption when wallet-internal keys
will need to be considered.
We use the `redjubjub` crate for batch validation, because the demo
batch validation API in `zcash_primitives::redjubjub` cannot be used
outside that crate, and using `redjubjub` enables this to be published
as a point release of `zcash_proofs`.
The new `SaplingVerificationContextInner` struct handles accumulation of
`cv`, and preparation of the inputs to proof and signature verification.
`SaplingVerificationContext` uses it to maintain its existing inline
unbatched verification API.
`PublicKey::verify` now always uses post-ZIP 216 validation rules, which
is fine in non-consensus contexts.
`SaplingVerificationContext` is used by `zcashd`'s consensus rules.
Requires patching three dependencies:
- bellman is pending a new release.
- nom is part of the funty breakage; we are blocking on a new release.
- orchard is in development.
Jack Grigg
Kris Nuttycombe
Sean Bowe
Marek
teor
Daira Hopwood
Dimitris Apostolou
Jack Grigg
Kris Nuttycombe