Use a tree to compute the result commitment

[weijiekoh]

Currently, during the tally process, we use MiMCSponge to hash all the results and a salt to create a result commitment:

commitment = hash([...results, salt])

When we switch to Poseidon hashes, however, we will need a different way. This is because the Poseidon EVM code supports up to 5 elements, while we need to support many more than 5 vote options. correction, 3 May 2020: this is incorrect; we can still safely use Poseidon for more than 5 elements

The solution presented in this PR is to generate the commitment by using a Merkle tree:

commitment = hashLeftRight(computeRoot(results), salt)

This means that we can simply use PoseidonT3 (to hash 2 elements) for the Merkle tree and for hashLeftRight, so we won't need to write new EVM code or a PoseidonSponge.

edit, 3 May 2020: This also means that a client application can verifiably prove that they know the value of any leaf by providing a Merkle path from the leaf to the root.

Original QVT circuit: 121466 constraints
New QVT circuit: 141266 constraints

Original proveVoteTallyBatch(): 740772 gas
New proveVoteTallyBatch(): 740860 gas

Using zkutil, the difference in proof generation time is negligible.

There is also a bugfix in cli/ts/utils.ts which makes genMaciStateFromContract correctly read the tree depths from the contract.

Related to #88

[weijiekoh]

This PR should be OK to merge even though the latest test failed (as of 5pm today -https://circleci.com/workflow-run/c9a47f2f-c1a4-43be-9119-33fb3b25ce14). This is due to the low performance of the CircleCI VM, not a problem with the code.

[weijiekoh]

There is one issue which this PR does not address: the final invocation of proveVoteTallyBatch() requires that the sender pass in a uint256[] memory _finalResults value. There may be an upper limit on the size of the array (e.g. perhaps if we pass in 1024 values), and make it impossible to tally the final batch. Let's address this in #90.

[weijiekoh]

In lieu of #91, this PR will also remove the requirement that the coordinator must publish the final tally on-chain.

[ChihChengLiang]

Only a nitpick. Other parts look good.

Note that changes in this PR are not reflected in the specs.
It might be tedious to do that in every PR, so I created a tracking issue #93. When we feel something that requires a spec update we just refer to #93.

[ChihChengLiang]

This should be emptyVoteOptionTreeRoot?

Suggested change

	computeEmptyRoot(_treeDepths.voteOptionTreeDepth, 0),
	emptyVoteOptionTreeRoot,

[weijiekoh]

Oops! Computing the root twice wastes gas. Thank you for spotting this. I'll push a commit to fix it.

[weijiekoh]

Updated the spec :D