https://github.com/mzabaluev/mrkl
Generic, minimalist, parallelizable Merkle tree
https://github.com/mzabaluev/mrkl
hash-trees merkle-tree rust
Last synced: about 1 month ago
JSON representation
Generic, minimalist, parallelizable Merkle tree
- Host: GitHub
- URL: https://github.com/mzabaluev/mrkl
- Owner: mzabaluev
- License: apache-2.0
- Created: 2017-12-19T11:41:11.000Z (over 7 years ago)
- Default Branch: master
- Last Pushed: 2018-10-09T00:53:17.000Z (over 6 years ago)
- Last Synced: 2025-03-24T03:23:44.882Z (about 2 months ago)
- Topics: hash-trees, merkle-tree, rust
- Language: Rust
- Size: 93.8 KB
- Stars: 13
- Watchers: 0
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE-APACHE
Awesome Lists containing this project
README
# Generic Merkle Tree
This crate provides a generic, composable, and parallelizable way to
construct Merkle trees, also known as hash trees, from input data.
The basic design is agnostic to the choice of the hashing algorithm,
the type of input data, and what information derived from the input
gets stored inside leaf nodes.
## Design assumptions
* Merkle trees are normally built once when the hashed content is
"sealed". Appending to a previously calculated tree is only done by adding
new levels on top of the sealed tree root. An application design that needs
to repeatedly recalculate a Merkle tree over variable content has
questionable usefulness and efficiency. Therefore, the data structures
representing fully constructed trees can be made immutable.
* Merkle trees are not generally used to contain the hashed input data.
However, some information about the input may need to be stored in the
leaf nodes. Therefore, the design should provide flexible choices for
leaf data extraction, including trees without leaf data and
trees taking ownership of the input as leaf data.
* The application should have a choice in the hashing algorithm that is
not restricted to a particular digest API. The Rust Crypto project's API,
however, should be supported out of the box.
* The application should have flexibility in how the hash over child nodes
is calculated for their parent node. The popular way of prepending a byte
value distinguishing a leaf node from a non-leaf node, to protect against
second-preimage attacks, can be provided by default.
* Building both left-filled, uniform-leaf-depth binary trees permitting
rightmost "angle" internal nodes (as in Bitcoin), and full, but not
necessarily balanced binary trees (as in Certificate Transparency),
should be supported as primary use cases.
* Calculation of Merkle trees is eminently parallelizable, so an
implementation using a work-stealing thread pool should be provided
as an optional feature.
## Design notes
The design uses the builder pattern to separate the Merkle tree data model,
which is immutable, from various construction facilities that are represented
by `tree::Builder`, `tree::parallel::Builder`, and related types.
## Future additions
Audit paths, consisting of the root hash and a chain of side node hashes
needed to verify integrity of a leaf's data, need to be supported.
The input to make a leaf node cannot yet be provided incrementally. There is
an idea how to implement this in an elegant way.
An extension can be provided to build trees from iterated input where
data to hash is delivered multiplexed alongside the values to store as
leaf data (like in the item values of `std::iter::Enumerate`).
## License
Licensed under either of
* Apache License, Version 2.0
([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
* MIT license
([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
at your option.
## Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be
dual licensed as above, without any additional terms or conditions.