Consider switching to the merklix tree

[chjj]

There's a merklix tree implementation on the merklix branch.

You could say the way the urkel tree currently handles bit collisions is naive, but in benchmarks, there are no noticeable differences between the urkel tree and a merklix tree in terms of performance or storage. The average case proof size is also identical.

Still, we have to consider the possibility that people may try to DoS the tree. In this case, the merklix tree holds up better.

So, I'm hesitating here for two reasons:

1. This adds massive complexity to the implementation of the tree and proof verification.
2. In order to reduce storage, nodes have to be stored as a variable size. I've been given advice to try a "merklix-2" or "merklix-4" tree (where only 2/4 colliding bits are stored on internal nodes, thus allowing us a constant size node), but I find this even more convoluted since it basically requires combining both methods of handling bit collisions. This also adds complexity with a new "pointer" system you'll notice on the merklix branch.
3. As a result of the last issue, memory usage increases a lot, I want to say it's nearly double, since we now have a lot more properties/objects in memory to track size/bits/etc.

If we can solve the memory issue, I have no issue with using our merklix implementation.

Opening this up to discussion.

[chjj]

I managed to reduce memory usage with some hacks.

If we want to switch to the merklix tree, I think we should wait until it's more tested and understood. Having people audit the code would be good. It's a lot more complex than the urkel tree in its current state.

[chjj]

Update: implementation moved to: https://github.com/handshake-org/urkel/tree/master/lib/radix