5929e05e52
PushPeers is more complicated to thread into the rest of our architecture (we would need to establish a data path connecting our service handling inbound requests to the network layer's auto-crawler), and since we crawl the network automatically anyways, we don't actually need to accept them in order to get updated address information. The only possible problem with this approach is that zcashd refuses to answer multiple address requests from the same connection, ostensibly for fingerprinting prevention (although it's totally happy to give exactly the same information, as long as you hang up and reconnect first, lol). It's unclear how this will interact with our design -- on the one hand, it could mean that we don't get new addr information when we ask, but on the other hand, we may have enough churn in our connection pool that this isn't a problem anyways. |
||
|---|---|---|
| .github/workflows | ||
| design | ||
| zebra-chain | ||
| zebra-client | ||
| zebra-consensus | ||
| zebra-network | ||
| zebra-rpc | ||
| zebra-script | ||
| zebra-storage | ||
| zebrad | ||
| .firebaserc | ||
| .gitignore | ||
| .rustfmt.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| Dockerfile | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| clippy.toml | ||
| cloudbuild.yaml | ||
| firebase.json | ||
README.md
zebra 🦓
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.
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.