Add a MerkleProof.processProof utility function

[Amxx]

Fixes #2840

PR Checklist

• Tests (covered by existing tests)
• Changelog entry

[frangio]

Can we do index * 2 for overflow protection?

Suggested change

	index <<= 1;
	index *= 2;

[frangio]

@Amxx If this suggestion isn't relevant can you explain why?

[Amxx]

I originally cared mostly about consistency between line 50 and 57, but the overflow protection is really interesting.

• if we use "multiply", we protect against overflow that would happen if there is a right-branching at least 256 down in the tree. For that to happen, the Merkle tree would have to be more than 256 levels depth, which is only required if the tree contains more than 2**256 leaves. (which means there much be duplicates or collisions in the leaves
• if we use "shift", we don't have this protection.

This protection is technically a breaking changes because some proofs won't be verifiable anymore. These proofs will only realistically happen if trees are not built properly. Without this protection, the returned index value becomes unreliable if trees have more then 256 levels ...

My conclusion

• In all reasonable cases, adding the protection should have no positive impact on security, and just add some gas cost.
• In some corner cases, the protection will prevent verifying valid proofs, that were accepted before this PR.
• I'd go for using shift.

[frangio]

the Merkle tree would have to be more than 256 levels depth, which is only required if the tree contains more than 2**256 leaves

Are trees necessarily balanced?

[Amxx]

The contract do not require any balancing, but effectiveness of the merkle structure is optimized if the most frequently proved leaves are higher... In practice, this means that any good tooling will try to balance the tree ... and I don't expect we would ever have production trees that are so obviously unbalanced

[frangio]

LGTM

[Amxx]

After discussion, we decided to remove the indexing feature from this PR, as it doesn't feel ready.

The previous implementation suffers from some issues:

• Depending on the tree shape, we are not able to guarantee that the indices are sequential.
• Depending on the tree shape, indices computation could overflow, and break the uniqueness property.
• Depending on the way leaves hashes are produced, it might be possible to produce valid proofs for inner nodes, which would take the indices of one of the leaves in the subtree.

We will try designing a better mechanism, but until then we recommend building sequential indices inside the leaves (like uniswap does in the MerkleDistributor)