feat(examples): add merkle tree package

[albttx]

Why this PR

I'm currently working on a Merkle Airdrop contract in Gno. you can see the ongoing progress on my fork albttx#1

This PR needs crypto/sha256 implemented #580

Description

This PR add a new package p/merkle for creating Merkle Tree.

I did my best to make it as simple as possible and to provide the minimum features required.

• The tree is compliant with merkletreejs/merkletreejs
• The tree is not compliant with RFC-6962 but can easily be added as an option on the NewTree function.

How has this been tested?

using gnodev

[thehowl]

CI seems to be failing for the issue in #668

Could you add sha256 and hex in the whitelist in the meantime, for this PR?

[thehowl]

merkle.gno also needs more documentation and comments

[thehowl]

maybe add a go equivalent to the js code?

[albttx]

the merkle.gno is 100% go compatible.. with a quick look at the gno code, you can have the go code... is it really mendatory ?

[thehowl]

No, not necessarily. But it seems weird then that there is an example of JS code inside of the directory of a gno package :)

[albttx]

@thehowl thanks for your review, everything has beed fixed :)

wdyt ?

[thehowl]

A small performance suggestion but code-wise looks good. However, I do think it would be better if the exported symbols had proper documentation. I know most packages in p/demo have little-to-no documentation as well, but I think it's also a trend that needs to change.

[thehowl]

No, not necessarily. But it seems weird then that there is an example of JS code inside of the directory of a gno package :)

[moul]

I appreciate this PR. However, since Gno already utilizes an automatic Merkle tree, it would be beneficial to compare the performance of this Merkle tree implementation against alternatives such as the avl package or built-in native types that are automatically merkelized.

The evaluation may yield a nuanced result, indicating that for groups of over N entries, this package outperforms others in terms of speed or cost-effectiveness.

If this package proves to be less efficient than alternative solutions, I suggest considering a different name to avoid misleading users into assuming similar advantages to those found in other platforms.

Overall, it would be beneficial to create more packages like this to provide diverse options for content management. Thank you!

[albttx]

@moul rebased

[albttx]

it would be beneficial to compare the performance of this Merkle tree implementation against alternatives such as the avl package or built-in native types that are automatically merkelized.

I don't understand your point, an avl tree will be stored on chain, which could be a lot of memory.
The goal of a Merkle tree is that the tree is stored off-chain, only the Merkle Root is on chain, so to ensure a key is good, we compute off-chain a merkle proof, witch will be validate on-chain.

Maybe a different approach would have been to add a "Proof" system on the avl tree ? 🤔 But AFAIK, most project use merkletreejs on client side to generate the merkle proof in the browser.

cc: @moul

[moul]

Understood. This package wasn't initially designed as an internal proof verification system for an alternative tree storage. Its primary purpose is to facilitate proof generation in the browser and enable contract usage of the Verify function.

Naming it "merkletree" effectively highlights the included proof system. Let's proceed with the current name and focus on showcasing practical usage examples.

To maintain simplicity and composability, we can extend avl.Tree with a proof system, possibly named avl.ProofTree, or even consider making merkletree dependent on avl.Tree. However, let's prioritize obtaining usage examples first.