Consider larger trees: 2^64 leaves

[drewstone]

I know this would make the tree much larger, but I actually think we might want to support a larger tree from the get-go.

[drewstone]

As I continue to spec a larger system out, the complexity is growing, but also the need to make good design decisions for the future. If the future holds that we will use non-membership proofs as well, then we can consider storing nullifiers only once on chain for the time being and eventually off-chain once the tools are sufficient for it.

[lazovicff]

Making a tree bigger is merely changing a parameter. Underlying proof construction lib will dictate the scalability.
For supporting non-membership proofs we need to use a sparse Merkle tree with similar on-chain impl to #8

[drewstone]

Yea, we are missing from the SMT how we actually assign indices to leaf values. Right now, we just update at a given index in our tests which isn't exactly correct afaik.