mrkl

Crates.iomrkl
lib.rsmrkl
version0.0.4
sourcesrc
created_at2017-12-19 12:57:23.874526
updated_at2018-10-09 00:53:55.065702
descriptionGeneric, minimalist, parallelizable Merkle tree
homepage
repositoryhttps://github.com/mzabaluev/mrkl
max_upload_size
id43641
size100,070
Mikhail Zabaluev (mzabaluev)

documentation

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

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.

Commit count: 96

cargo fmt