56d7391f6d
Because we represent each transaction version as a different variant of the Transaction enum, we end up in a situation where fields that are common to different transaction versions are awkward to access, requiring a match statement with identical match arms. To fix this, this commit adds the following convenience methods: * `Transaction::inputs() -> impl Iterator<Item=&TransparentInput>`; * `Transaction::outputs() -> impl Iterator<Item=&TransparentOutput>`; * `Transaction::lock_time() -> LockTime`; * `Transaction::expiry_height() -> Option<ExpiryHeight>`; The last returns an `Option` because the field is only present in V3 and V4 transactions. There are some remaining fields that do not get common accessors, because it probably doesn't make sense to access independently of knowing the transaction version: `joinsplit_data`, `shielded_data`, `value_balance`. |
||
|---|---|---|
| .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.
Most of our work so far has gone into zebra-network, building a new
networking stack for Zcash, and zebra-chain, building foundational data
structures.
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.