The `halo2_proofs/multicore` flag must be disabled when running wasm
builds; this ensures that we do not accidentally include it as a
transitive dependency when building with `--no-default-features`.
The actions-rs/* actions are unmaintained. See actions-rs/toolchain#216
for more information.
- actions-rs/toolchain is replaced by rust-toolchain.toml.
- actions-rs/cargo is replaced by direct cargo usage.
- actions-rs/tarpaulin is replaced by the cargo-tarpaulin container.
We currently retain a few usages due to a current lack of alternatives:
- actions-rs/toolchain to enable beta (for Clippy warnings) and nightly
(for building the book).
- actions-rs/clippy-check so Clippy results are published as annotations
on PRs.
We also now require via rust-toolchain.toml that people building from
the repo have the clippy and rustfmt components installed. This is fine
because they will need to ensure these pass when making PRs.
This change makes it possible for wallets using the
`zcash_client_backend::data_api::wallet` module to perform transaction
preparation, including input selection and fee calculation, as an
independent step prior to creating proofs and signatures. This can be
used to improve user experience by making it possible to report the
proposed effects of the transaction to the wallet user (including
privacy implications) prior to authorizing the transaction.
Previously, if a caller wanted to use a block source to perform
scanning from the first available block, they would have to guess
at the block height to start from. Changing this to an optional
argument makes this explicit.
This allows callers to validate smaller intervals of the given
`BlockSourceT` shortening processing times of the function call at the
expense of obtaining a partial result on a given section of interest of
the block source.
`params: &ParamsT` has been removed from the arguments since they were
only needed to fall back to `sapling_activation_height` when `None` as
passed as the `validate_from` argument. Passing `None` as validation
start point on a pre-populated `block_source` would result in an error
`ChainError::block_height_discontinuity(sapling_activation_height - 1, current_height)`
With this new API callers must specify a concrete `validate_from`
argument and assume that `validate_chain` will not take any default
fallbacks to chain `ParamsT`.
The addition of a `limit` to the chain validation function changes the
meaning of its successful output, being now a `BlockHeight, BlockHash)`
tuple indicating the block height and block hash up to which the chain
as been validated on its continuity of heights and hashes. Callers
providing a `limit` aregument are responsible of subsequent calls to
`validate_chain()` to complete validating the remaining blocks stored on
the `block_source`.
Closeszcash/librustzcash#705
While the Groth16 proofs have identical encodings, they are technically
for different circuits, and we need the ability to differentiate them
during bundle building.
The MSRVs of the component crates are left as-is, partly because our
dependencies don't require us to bump them, and partly because those
crates have no pending changes and are relatively stable. We also plan
to split the component crates out into a separate repository, where it
will be easier to have a separate MSRV.
Closeszcash/librustzcash#759.
Kris Nuttycombe
str4d
Francisco Gindre
Francisco Gindre
dependabot[bot]
Daira Hopwood