Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open question: data availability of the final vote option tally #91

Closed
weijiekoh opened this issue May 3, 2020 · 1 comment
Closed
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@weijiekoh
Copy link
Contributor

weijiekoh commented May 3, 2020

Related to #89 and #90.

Here are two related questions:

  1. How much on-chain work should MACI do to make the final vote tally available?
  2. How much on-chain work should client applications do to access the final vote tally?

Two more questions:

  1. How much on-chain work should MACI or client apps do to allow client apps to access the entire tally?
  2. 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:

  1. A minimal amount. We should just expose a cryptographic commitment to the final tally.
  2. As much is needed.
  3. MACI: a minimal amount. Just publish the final tally off-chain. Client apps: as much as needed
  4. 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:

  1. At the end of the final tally, we have the commitment to the final results = c
  2. 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
  3. We also publish the leaves off-chain.
  4. When a client app wants to access the raw value of l5 in 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]
  5. 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.

@ctrlc03
Copy link
Collaborator

ctrlc03 commented Jun 6, 2024

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

@ctrlc03 ctrlc03 closed this as completed Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
No open projects
Development

No branches or pull requests

2 participants