Skip to content

Commit

Permalink
docs: move background info to intro docs and reference that page
Browse files Browse the repository at this point in the history
  • Loading branch information
@samajammin
samajammin committed Feb 20, 2024
1 parent 7702fa6 commit b124570
Show file tree
Hide file tree
Showing 2 changed files with 14 additions and 28 deletions.
22 changes: 3 additions & 19 deletions website/blog/2024-02-28-maci-v1.2.0.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -17,25 +17,7 @@ This is our first release since [MACI v1.1.1](/blog/maci-v1-1-1-release) just ov

## Background

MACI - Minimal Anti-Collusion Infrastructure - is an Ethereum application that provides privacy and collusion resistance for on-chain voting, both in a [quadratic](https://vitalik.eth.limo/general/2019/12/07/quadratic.html) and non-quadratic fashion. It was originally created after Vitalik's [resarch post](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413), and has been maintained and improved since thanks to support from the Ethereum Foundation.

The participants of a MACI voting process are: 1) the voters and 2) a trusted coordinator. The coordinator is in charge of setting up the system, deploying polls, and computing the tally of the votes. Through smart contracts and ZK-proofs, MACI ensures that everything is done in a fair manner.

Below are MACI's main properties.

| Property | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Collusion Resistance | No one except a trusted coordinator should be certain of the validity of a vote, reducing the effectiveness of bribery. |
| Receipt-freeness | No one can prove (besides to the coordinator) which way they voted. |
| Privacy | No one except a trusted coordinator should be able to decrypt a vote. |
| Uncensorability | No one — not even the trusted coordinator, should be able to censor a vote. |
| Unforgeability | Only the owner of a user's private key may cast a vote tied to its corresponding public key. |
| Non-repudiation | No one may modify or delete a vote after it is cast, although a user may cast another vote to nullify it. |
| Correct execution | No one, not even the trusted coordinator, should be able to produce a false tally of votes. |

MACI's effectiveness can be seen in projects such as [clr.fund](https://github.com/clrfund) and [QF](https://github.com/privacy-scaling-explorations/qf) - both quadratic funding implementations, a mechanism which otherwise is highly susceptible to collusion and bribery. Most notably, clr.fund is already working on integrating MACI v1.2.0, after having used v0.x until now. You can follow their development effort under this [GitHub branch](https://github.com/clrfund/monorepo/tree/feat/maci-v1).

If you're new to MACI, we first recommend referring to our [Technical Introduction to MACI](/blog/maci-1-0-technical-introduction) for a deep dive of MACI's technical details.
MACI - Minimal Anti-Collusion Infrastructure - is an Ethereum application that provides privacy and collusion resistance for on-chain voting. If you're new to MACI, we first recommend reading our [Introduction documentation](/docs/introduction) for background information and referring to our [Technical Introduction to MACI](/blog/maci-1-0-technical-introduction) for a deep dive of MACI's technical details.

## Refactoring Work

Expand Down Expand Up @@ -135,6 +117,8 @@ For any other questions or feedback, please reach out to us via [PSE's Discord](
- [Minimal anti-collusion infrastructure - Vitalik](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413)
- [Discord server](https://discord.com/invite/sF5CT5rzrR)

MACI's effectiveness can be seen in projects such as [clr.fund](https://github.com/clrfund) and [QF](https://github.com/privacy-scaling-explorations/qf) - both quadratic funding implementations, a mechanism which otherwise is highly susceptible to collusion and bribery. Most notably, clr.fund is already working on integrating MACI v1.2.0, after having used v0.x until now. You can follow their development effort under this [GitHub branch](https://github.com/clrfund/monorepo/tree/feat/maci-v1).

## Release

Here's the link to the new release code in GitHub: [v1.2.0 Release](https://github.com/privacy-scaling-explorations/maci/releases/tag/v1.2.0).
20 changes: 11 additions & 9 deletions website/versioned_docs/version-v1.x/introduction.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -24,15 +24,15 @@ user privacy and discourage collusion or bribery for public goods funding.

MACI offers the following guarantees:

| Property | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Collusion Resistance | No one except a trusted coordinator should be certain of the validity of a vote, reducing the effectiveness of bribery. |
| Receipt-freeness | No one can prove (besides to the coordinator) which way they voted. |
| Privacy | No one except a trusted coordinator should be able to decrypt a vote. |
| Uncensorability | No one — not even the trusted coordinator, should be able to censor a vote. |
| Unforgeability | Only the owner of a user's private key may cast a vote tied to its corresponding public key. |
| Non-repudiation | No one may modify or delete a vote after it is cast, although a user may cast another vote to nullify it. |
| Correct execution | No one, not even the trusted coordinator, should be able to produce a false tally of votes. |
| Property | Description |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
| **Collusion Resistance** | No one except a trusted coordinator should be certain of the validity of a vote, reducing the effectiveness of bribery. |
| **Receipt-freeness** | No one can prove (besides to the coordinator) which way they voted. |
| **Privacy** | No one except a trusted coordinator should be able to decrypt a vote. |
| **Uncensorability** | No one — not even the trusted coordinator, should be able to censor a vote. |
| **Unforgeability** | Only the owner of a user's private key may cast a vote tied to its corresponding public key. |
| **Non-repudiation** | No one may modify or delete a vote after it is cast, although a user may cast another vote to nullify it. |
| **Correct execution** | No one, not even the trusted coordinator, should be able to produce a false tally of votes. |

Under the hood, MACI uses Ethereum smart contracts, ECDH encryption, and zero-knowledge proofs.
It inherits security and uncensorability from the underlying Ethereum
Expand All @@ -44,6 +44,8 @@ The participants of a MACI voting process are: 1) the voters and 2) a trusted co
Note that MACI presumes an identity system where each legitimate member
controls a unique Ethereum private key.

For information on MACI's latest features, please check out our [MACI v1.2.0 release post](/blog/maci-v1-2-0-release).

## Background

MACI was originally proposed by Vitalik Buterin in [this ethresear.ch
Expand Down

0 comments on commit b124570

Please sign in to comment.