6f3288814c
The GetPeers requests sent while crawling the network are randomly load-balanced over available peers. But at the very beginning, they may be both routed to the same peer, causing network initialization to be delayed while the second one times out (since zcashd only ever responds to the first addr message). Only sending one GetPeers request per candidate set update means we crawl the network a little more slowly, but avoids hanging on start. |
||
|---|---|---|
| .github | ||
| book | ||
| design | ||
| 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 | ||
| Dockerfile | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| clippy.toml | ||
| cloudbuild.yaml | ||
| codecov.yml | ||
| firebase.json | ||
| katex-header.html | ||
| prometheus.yaml | ||
README.md
Hello! I am Zebra, an ongoing Rust implementation of a Zcash node.
Zebra is a work in progress. It is developed as a collection of zebra-*
libraries implementing the different components of a Zcash node (networking,
chain structures, consensus rules, etc), and a zebrad binary which uses them.
Most of our work so far has gone into zebra-network, building a new
networking stack for Zcash, zebra-chain, building foundational data
structures, zebra-consensus, implementing consensus rules, and
zebra-state, providing chain state.
Rendered docs from the main branch.
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.