Zebra is a Zcash node written in Rust.
zebrad binary uses a collection of
which implement the different components of a Zcash node
(networking, chain structures, validation, rpc, etc).
Rendered docs from the
Join us on the Zcash Foundation Engineering Discord.
Zcash is a cryptocurrency designed to preserve the user’s privacy. Like most cryptocurrencies, it works by a collection of software nodes run by members of the Zcash community or any other interested parties. The nodes talk to each other in peer-to-peer fashion in order to maintain the state of the Zcash blockchain. They also communicate with miners who create new blocks. When a Zcash user sends Zcash, their wallet broadcasts transactions to these nodes which will eventually reach miners, and the mined transaction will then go through Zcash nodes until they reach the recipient’s wallet which will report the received Zcash to the recipient.
The original Zcash node is named
zcashd and is developed by the Electric Coin
Company as a fork of the original Bitcoin node. Zebra, on the other hand, is
an independent Zcash node implementation developed from scratch. Since they
implement the same protocol,
zcashd and Zebra nodes can communicate with each
other and maintain the Zcash network together.
These are some of the advantages or benefits of Zebra:
- Better performance: since it was implemented from scratch in an async, parallelized way, Zebra
is currently faster than
- Better security: since it is developed in a memory-safe language (Rust), Zebra is less likely to be affected by memory-safety and correctness security bugs that could compromise the environment where it is run.
- Better governance: with a new node deployment, there will be more developers who can implement different features for the Zcash network.
- Dev accessibility: supports more developers, which gives new developers options for contributing to Zcash protocol development.
- Runtime safety: with an independent implementation, the detection of consensus bugs can happen quicker, reducing the risk of consensus splits.
- Spec safety: with several node implementations, it is much easier to notice bugs and ambiguity in protocol specification.
- User options: different nodes present different features and tradeoffs for users to decide on their preferred options.
- Additional contexts: wider target deployments for people to use a consensus node in more contexts e.g. mobile, wasm, etc.
Zebra Feature Flags
zebrad feature flags are available at compile time:
getblocktemplate-rpcs: Experimental mining pool RPC support (currently incomplete)
prometheus: export metrics to prometheus.
progress-bar: shows key metrics in the terminal using progress bars, and automatically configures Zebra to send logs to a file.
Read the metrics section of the book for more details.
Sending traces to different subscribers:
- configuring a
tracing.log_file: appends traces to a file on disk.
journald: send tracing spans and events to
sentry: send crash and panic events to sentry.io.
flamegraph: generate a flamegraph of tracing spans.
Changing the traces that are collected:
filter-reload: dynamically reload tracing filters at runtime.
error-debug: enable extra debugging in release builds.
tokio-console: enable tokio’s
console-subscriber(needs specific compiler flags)
- A set of features that skip verbose tracing.
The default features ignore
tracelogs in release builds.
Read the tracing section of the book for more details.
proptest-impl: enable randomised test data generation.
lightwalletd-grpc-tests: enable Zebra JSON-RPC tests that query
- Zebrad Abscissa Application
- Zebrad Subcommands
- Holds components of a Zebra node.
- Zebrad Config
- Application-local prelude: conveniently import types/functions/macros which are generally useful and should be available everywhere.
- Integration with sentry.io for event reporting.
- Error type alias to make working with tower traits easier.