allow initializing MerkleTree with caller-provided precomputed zero hashes

[Asim-Shaik]

Allow initializing MerkleTree with caller-provided precomputed zero hashes
instead of computing them during construction.

closes #20

[alrevuelta]

thanks for the contribution, but mind elaborating on the use case of this?
the precomputed zeros depend on the DEPTH and hash function, so not sure why someone would like to call this function. the zeros are already initialized in the constructor. what's your use case for this?

[Asim-Shaik]

to ensure deterministic Merkle roots across different environments like Rust, js, circom, and on-chain programs like solana. In ZK and blockchain setups, even minor differences in poseidon encoding or endianness can lead to mismatched roots, so providing precomputed zero hashes guarantees cross-environment consistency.

it is a very specific use case for a rather general purpose crate XD

[alrevuelta]

Still dont follow. The merkle roots this crate produces are deterministic and compatible with any other merkle tree implementation. As long as you use the same:

• hash function
• depth

If you add a with_precomputed_zeros, the precomputed shall match this https://github.com/bilinearlabs/rs-merkle-tree/blob/main/src/tree.rs#L72-L75 to be consistent. So why adding with_precomputed_zeros in the first place?

Can you elaborate on your use case? Whatever it is, I'm not sure this is the way to fix it.

[Asim-Shaik]

I use a hashing script to precompute the canonical zero hashes namespaced to a specific domain by using strings like "domain-occupied". I’m using this as a way to keep my different environments rust , solana, and circom circuits perfectly deterministic and in sync.

is this a bad way of doing it?

[alrevuelta]

still dont follow. can you put an example on how you would calculate your zero hashes?

how do you include your "domain-occupied" in the hash? and well, if you include that to hash zeros, dont you have to include it as well to hash the tree?