440e183d32
UTXO requests during transaction input verification can time out because: 1. The block that creates the UTXO is queued for download or verify, but it hasn't been committed yet. The creating block might spend UTXOs that come from other recent blocks, so UTXO verification can depend on a (non-contiguous) sequence of block verifications. In this case, Zebra should wait for additional block download and verify tasks to complete. 2. The block that creates the UTXO isn't queued for download. This can happen because the block is gossiped block that's much higher than the current tip, or because a peer sent the syncer a bad list of block hashes. In this case, Zebra should discard the timed out block, and restart the sync. We need to choose a timeout that balances these two cases, so we time out after 180 seconds. Assuming Zebra can download at least 1 MB per second, 180 seconds is enough time to download a few hundred blocks. So Zebra should be able to download and verify the next block before the UTXOs that it creates time out. (Since Zebra has already verified all the blocks before the next block, its UTXO requests should return immediately.) Even if some peers time out downloads, a block can only be pending download for 80 seconds (4 retries * 20 second timeout) before the download fails. So the UTXO timeout doesn't need to be much larger than this overall download timeout - because the download timeout will happen first on slow networks. Alternately, if the download for the creating block was never queued, Zebra should timeout as soon as possible - so it can restart the sync and download the creating block. As a side-effect, a lower UTXO timeout also makes it slightly easier to debug UTXO issues, because unsatisfiable queries fail faster. |
||
|---|---|---|
| .github | ||
| book | ||
| design | ||
| docker | ||
| tower-batch | ||
| tower-fallback | ||
| zebra-chain | ||
| zebra-client | ||
| zebra-consensus | ||
| zebra-network | ||
| zebra-rpc | ||
| zebra-script | ||
| zebra-state | ||
| zebra-test | ||
| zebra-utils | ||
| zebrad | ||
| .firebaserc | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| clippy.toml | ||
| cloudbuild.yaml | ||
| codecov.yml | ||
| firebase.json | ||
| katex-header.html | ||
| prometheus.yaml | ||
README.md
🚧 UNDER CONSTRUCTION 🚧
Zebra is the Zcash Foundation's independent, consensus-compatible implementation of the Zcash protocol, currently under development. Please join us on Discord if you'd like to find out more or get involved!
Unlike zcashd, which originated as a Bitcoin Core fork and inherited its
monolithic architecture, Zebra has a modular, library-first design, with the
intent that each component can be independently reused outside of the zebrad
fullnode. For instance, the zebra-network crate containing the network stack
can also be used to implement anonymous transaction relay, network crawlers, or
other functionality, without requiring a full node.
Our first goal is to be able to participate in the network and replicate the Zcash chain state, and we intend to ship an alpha before the end of 2020 with this functionality. In 2021, we intend to add RPC support and wallet integration. This phased approach allows us to test the independent implementation of the consensus rules before asking users to entrust it with their funds.
At a high level, the fullnode functionality required by zebrad is factored
into several components:
-
zebra-chain, providing definitions of core data structures for Zcash, such as blocks, transactions, addresses, etc., and related functionality. It also contains the implementation of the consensus-critical serialization formats used in Zcash. The data structures inzebra-chainare defined to enforce structural validity by making invalid states unrepresentable. For instance, theTransactionenum has variants for each transaction version, and it's impossible to construct a transaction with, e.g., spend or output descriptions but no binding signature, or, e.g., a version 2 (Sprout) transaction with Sapling proofs. Currently,zebra-chainis oriented towards verifying transactions, but will be extended to support creating them in the future. -
zebra-network, providing an asynchronous, multithreaded implementation of the Zcash network protocol inherited from Bitcoin. In contrast tozcashd, each peer connection has a separate state machine, and the crate translates the external network protocol into a stateless, request/response-oriented protocol for internal use. The crate provides two interfaces: an auto-managed connection pool that load-balances requests over available peers, and aconnect_isolatedmethod that produces a peer connection completely isolated from all other node state. This can be used, for instance, to safely relay data over Tor, without revealing distinguishing information. -
zebra-scriptprovides script validation. Currently, this is implemented by linking to the C++ script verification code fromzcashd, but in the future we may implement a pure-Rust script implementation. -
zebra-consensusperforms semantic validation of blocks and transactions: all consensus rules that can be checked independently of the chain state, such as verification of signatures, proofs, and scripts. Internally, the library usestower-batchto perform automatic, transparent batch processing of contemporaneous verification requests. -
zebra-stateis responsible for storing, updating, and querying the chain state. The state service is responsible for contextual verification: all consensus rules that check whether a new block is a valid extension of an existing chain, such as updating the nullifier set or checking that transaction inputs remain unspent. -
zebradcontains the full node, which connects these components together and implements logic to handle inbound requests from peers and the chain sync process. -
zebra-rpcandzebra-clientwill eventually contain the RPC and wallet functionality, but as mentioned above, our goal is to implement replication of chain state first before asking users to entrust Zebra with their funds.
All of these components can be reused as independent libraries, and all communication between stateful components is handled internally by internal asynchronous RPC abstraction ("microservices in one process").
The Zebra website contains user documentation, such as how to run or configure Zebra, set up metrics integrations, etc., as well as developer documentation, such as design documents. We also render API documentation for the external API of our crates, as well as internal documentation for private APIs.
License
Zebra is distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT.