ec00ee4cf0
Some systems have a very small /dev/shm, for example, see: https://github.com/docker-library/postgres/issues/416 So we should just use the temporary directory on all operating systems. Also: * use TempDir to generate the temporary path * delete the code that we copied from sled * prefix the temporary path with the state version and network |
||
|---|---|---|
| .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.