You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How much on-chain work should MACI do to make the final vote tally available?
How much on-chain work should client applications do to access the final vote tally?
Two more questions:
How much on-chain work should MACI or client apps do to allow client apps to access the entire tally?
Can there be a compromise in the case where client apps can efficiently access the tally of one or more vote option(s) at a time?
As of the time of writing, our answers to the following questions are:
A minimal amount. We should just expose a cryptographic commitment to the final tally.
As much is needed.
MACI: a minimal amount. Just publish the final tally off-chain. Client apps: as much as needed
Yes. This issue will describe two ways to do this. The first way is to stick with PR Use a tree to compute the result commitment #89 where the commitment to the final tally is a Merkle root, and to access a leaf in the final tally, the client app can just provide a Merkle proof to the leaf they need. The downside is that we need one proof per leaf.
The second way is as such:
At the end of the final tally, we have the commitment to the final results = c
Then, we publish [b0, b1, b2, b3] which are hashes of each batch of leaves [l0, l1, l2, l3], [l4, l5, l6, l7], and so on
We also publish the leaves off-chain.
When a client app wants to access the raw value of l5in a trustless (verifiable) way, it does this:
a. Provide a Merkle proof p from b1 to c
b. Provide the raw values of [l4 ... l7]
If p is valid and hash([l4...l7]) == b1, then access l5. One benefit is that the client app can also access l4, l6, and l7 at the same time.
We currently won't implement this second method but we'll keep this issue open as a reference.
The text was updated successfully, but these errors were encountered:
Closing this as we have functions on the Tally contract to verify the final tally, and the Tally file is usually published to ipfs and accessed by frontends to show results + facilitate verifiaction
Related to #89 and #90.
Here are two related questions:
Two more questions:
As of the time of writing, our answers to the following questions are:
The second way is as such:
c
[b0, b1, b2, b3]
which are hashes of each batch of leaves[l0, l1, l2, l3]
,[l4, l5, l6, l7]
, and so onl5
in a trustless (verifiable) way, it does this:a. Provide a Merkle proof
p
fromb1
toc
b. Provide the raw values of
[l4 ... l7]
p
is valid andhash([l4...l7]) == b1
, then accessl5
. One benefit is that the client app can also accessl4
,l6
, andl7
at the same time.We currently won't implement this second method but we'll keep this issue open as a reference.
The text was updated successfully, but these errors were encountered: