←back to thread

141 points bibiver | 1 comments | | HN request time: 0.205s | source
Show context
bibiver ◴[] No.45655191[source]
We've just released rs-merkle-tree, a Merkle tree crate designed with performance and modularity in mind. It comes with the following key features:

* Fixed depth: All proofs have a constant size equal to the depth of the tree. The depth can be configured via a const generic.

* Append-only: Leaves are added sequentially starting from index 0. Once added, a leaf cannot be modified.

* Optimized for Merkle proof retrieval: Intermediate nodes are stored so that proofs can be fetched directly from storage without recomputation, resulting in very fast retrieval times.

* Configurable storage and hash functions: Currently supports Keccak and Poseidon hashers, and in-memory, Sled, RocksDB, and SQLite stores.

The Rust ecosystem already offers several Merkle tree implementations, but rs-merkle-tree is built for a specific use case: append-only data structures such as blockchains, distributed ledgers, audit logs, or certificate transparency logs. It’s particularly optimized for proof retrieval, storing intermediate nodes in a configurable and extensible storage backend so they don’t need to be recomputed when requested.

replies(3): >>45656124 #>>45657554 #>>45657562 #
xpe ◴[] No.45656124[source]
For those in the know... Do you have any recommended reading for Merkle-curious people that may have some scars from blockchain-related hype? It would be nice to find a nice introductory resource that covers some interesting use-cases that may not be well-known. Perhaps with nice graphics, interactivity, etc.?

For example, here is a slick web site that shows how certificate transparency uses Merkle trees: https://certificate.transparency.dev/howctworks/

replies(4): >>45656589 #>>45657564 #>>45658018 #>>45660006 #
raphinou ◴[] No.45660006[source]
I'm working on a project where I need to prove that a file in a git repo is append only, ie all changes to the file only added lines. The only way I can think of is looking at the git history of the file, but would there be a faster way using Merkel trees somehow?
replies(1): >>45661360 #
jmount ◴[] No.45661360[source]
Is this trying to deal with that git history can be replaced?
replies(1): >>45665367 #
1. raphinou ◴[] No.45665367[source]
We handle the case to prevent git history rewrites, but an alternative solution could be adopted if less cumbersome.