MerkleTreeMiMC7_test.sol:24:25: Error: Array is too large to be encoded. public returns (bytes32[MAX_NUM_NODES] memory)

[yanyanho]

when I ran test_merkle_tree_contract.py, I came across this problem.

[AntoineRondelet]

Thanks for the issue @yanyanho, that's a good catch!
We used the protocol parameters for the tests - i.e. a Merkle tree of depth 32 - which is way too big to be used with the test function that returns the encoded tree (we don't return the full tree in the protocol, i.e. outside of the tests - see the protocol specifications Chapter 4: https://github.com/clearmatics/zeth-specifications/blob/master/zeth-protocol-specification.pdf for more details on the client logic).
This is fixed in #229, where I used some testing parameters to process a Merkle tree of depth 8 in the test_merkle_tree_contract.py test. It all works well on my end, please let me know if you have any further troubles.

[yanyanho]

Thanks very much, I hava a further trouble. A Merkle tree of depth 8 can only support 2^8 transfers, can you give the demo dynamic creating merkel trees. A Merkle tree of depth 32 takes too long time (20s , mac docker test ) to generating proof, I want to decrease the tree depth but I need to dynamic creating merkel trees. What's more , Can you give some suggestion to short the time of generating proof.

[dtebbs]

Hi @yanyanho.

The Merkle tree size is controlled by the ZETH_MERKLE_TREE_DEPTH constants in constants.py and zeth_constants.hpp, and DEPTH in BaseMerkleTree.sol. These must all be set to the same value BEFORE the prover is built and the contract deployed. (Unfortunately we do not yet have a nicer way of configuring this). This affects the verification and proving keys for the ZK proofs, and so at present we do not have a practical way to dynamically change the depth of the tree.

Regarding proving times, it's worth checking the fundamentals (ensure you are running an optimized multi-threaded build and that the docker container has enough resources, or try a native mac build etc) to get the max performance, but a substantial improvement would require optimization of the arithmetic circuit, and even this is only possible up to a point.

You may be interested in Chapter 4 of the protocol spec https://github.com/clearmatics/zeth-specifications/blob/master/zeth-protocol-specification.pdf which discusses performance, snark-friendly primitives and some of the trade-offs in this proof-of-concept.

[AntoineRondelet]

@yanyanho this ticket has been addressed in #229 which is now merged in develop, and which will then be introduced in the next release.
As such, I will close this ticket. As mentioned above, the ZETH_MERKLE_TREE_DEPTH is a protocol parameter that is a constant in the c++, python, and solidity sides of the code-base. You may decide to change this value to lower the proof generation time - but I would strongly advise to think about the consequences of decreasing the cardinality of the notes anonymity set.

Further discussion and details are discussed in the protocol specifications linked above.

[yanyanho]

Hi @yanyanho.

The Merkle tree size is controlled by the ZETH_MERKLE_TREE_DEPTH constants in constants.py and zeth_constants.hpp, and DEPTH in BaseMerkleTree.sol. These must all be set to the same value BEFORE the prover is built and the contract deployed. (Unfortunately we do not yet have a nicer way of configuring this). This affects the verification and proving keys for the ZK proofs, and so at present we do not have a practical way to dynamically change the depth of the tree.

Regarding proving times, it's worth checking the fundamentals (ensure you are running an optimized multi-threaded build and that the docker container has enough resources, or try a native mac build etc) to get the max performance, but a substantial improvement would require optimization of the arithmetic circuit, and even this is only possible up to a point.

You may be interested in Chapter 4 of the protocol spec https://github.com/clearmatics/zeth-specifications/blob/master/zeth-protocol-specification.pdf which discusses performance, snark-friendly primitives and some of the trade-offs in this proof-of-concept.

hi, I may not explicit it clearly. What I want to do is creating more than one tree(depth is the same). I want decrease the depth (for example set depth 5 rather than 32 )of merkeltree to shorten the time of generating proof. Meanwhile, I need to create more trees(depth is 5) to contain the utxo . Do you have the solution?

[AntoineRondelet]

Creating multiple small trees may look appealing at first glance, but tremendously weakens the protocol as the merkle root associated to each tx leaks in which small anonymity set the inputs/outputs belong. That of course, constitute valuable information for the adversary. Moreover, managing multiple MK Tree complexifies the protocol as we may have inputs and outputs that do not belong to the same merke tree, hence forcing us to create several merkle roots during the proof generation etc. That being said, the big drawback of using shallow trees really is the leakages associated to this solution. Keeping a single and big anonymity set really is essential to minimize metadata leakages.

[AntoineRondelet]

This actually is already moved to its own ticket: #238