@maci-protocol/website 0.0.0-ci.1e276ed

package/blog/2024-02-28-maci-v1.2.0.md

@@ -0,0 +1,121 @@
+---
+slug: maci-v1-2-0-release
+title: MACI v1.2.0 Release
+description: "MACI v1.2.0: Enhancing Blockchain Privacy & Security with Developer-Friendly Updates"
+authors:
+  name: ctrlc03
+  title: MACI team
+  url: https://pse.dev
+  image_url: /img/pse-logo-round.png
+tags: [release, audit, security, documentation]
+excerpt: "We are pleased to announce the release of MACI v1.2.0"
+---
+
+# MACI v1.2 Release
+
+We are pleased to announce the release of MACI [v1.2.0](https://github.com/privacy-scaling-explorations/maci/releases/tag/v1.2.0)!
+
+This is our first release since [MACI v1.1.1](/blog/maci-v1-1-1-release) just over one year ago. This new release focuses on improved developer experience, security, performance and clearer documentation for users looking to learn and use MACI.
+
+## Background
+
+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 [documentation](/docs/introduction) for background information and technical details.
+
+## Refactoring Work
+
+We prioritized enhancing MACI's developer experience by refactoring its code, fixing bugs, and improving documentation.
+
+Key refactoring activities were:
+
+1. Upgrading libraries to their latest versions and substituting obsolete dependencies with up-to-date and actively maintained alternatives.
+2. Making the code standardized, modular, well-documented, and uniformly formatted.
+3. Fixing bugs and community-reported issues.
+
+### Library Updates
+
+MACI has relied on custom code and dependencies since its initial implementation, notably from repositories by one of the original MACI developers, [Koh Wei Jie](https://github.com/weijiekoh). We felt that MACI could benefit from a dependency refresh, so we've shifted towards using actively maintained open-source libraries, such as [circomkit](https://github.com/erhant/circomkit) and [zk-kit](https://github.com/privacy-scaling-explorations/zk-kit).
+
+Circomkit has become our go-to for circuit-related tasks, such as compiling circuits, generating test zkeys, and unit tests.
+
+We've moved reusable circuit logic, like our [Poseidon permutation](https://github.com/privacy-scaling-explorations/zk-kit/tree/main/packages/poseidon-cipher) encryption and decryption code, into zk-kit. This not only benefits MACI through more circuit usage and testing but also supports wider community adoption.
+
+These efforts are part of a broader initiative at [Privacy and Scaling Explorations (PSE)](https://pse.dev/) to foster open-source development and contribute to public goods. By aligning MACI with these values, we aim to enhance its utility and encourage collaborative growth. In the coming months, we're committed to extracting more of our circuit logic for broader use ([track progress here](https://github.com/privacy-scaling-explorations/zk-kit/issues/131)) and contributing to projects that align with [our mission](/roadmap#maci-mission--vision).
+
+### Code Refactor
+
+We've undergone extensive efforts to clean up MACI's code:
+
+- Removed dead and redundant code.
+- Split monolithic files into smaller, logically structured ones.
+- Improved documentation with detailed code comments and tools like ([TypeDoc](https://typedoc.org/) and [solidity-docgen](https://github.com/OpenZeppelin/solidity-docgen)) for automatic doc generation.
+- Enforced strong type safety on the TypeScript components.
+- Optimized and modularized the smart contract code.
+- Extended the test suites.
+
+These improvements aim to simplify the onboarding process for new developers, ensuring they can easily navigate and effectively utilize MACI.
+
+## New Features
+
+### Flexible Voting Strategies
+
+After years of built-in quadratic voting (QV) in MACI, we now support non-quadratic voting polls. This opens up the door to potential integrations with a wider variety of projects, such as DAO governance applications.
+
+The new version of the Tally circuit (specific for non-QV), has reduced constraints, enabling a quicker proof generation process for vote tallying.
+
+We invite projects interested in leveraging this secure, on-chain voting mechanism to reach out for potential integrations. We hope to continue to expand support for additional voting methodologies, so please let us know your project's needs!
+
+### New Gatekeeper
+
+In our effort to fortify MACI against Sybil attacks, we've integrated an innovative gatekeeper mechanism: [EAS](https://attest.sh/) - you can [view the contract here](https://github.com/privacy-scaling-explorations/maci/blob/v1.2.0/contracts/contracts/gatekeepers/EASGatekeeper.sol).
+
+As part of configuring a MACI deployment, the coordinator sets a user signup gatekeeper contract. This contract dictates the criteria a user must pass in order to participate in a poll. For example, user might need to prove ownership of a certain NFT, or prove that they have passed some sort of proof-of-personhood verification.
+
+With the addition of this new gatekeeper, EAS (and soon™ [Hats Protocol](https://www.hatsprotocol.xyz/), MACI instances could be configured to e.g. only allow Ethereum accounts with a trusted EAS attestation or those designated with a specific role by the Hats Protocol. These modules open up new avenues for access control strategies.
+
+We expect to continue to expand our [gatekeeper capabilities](https://github.com/privacy-scaling-explorations/maci/tree/v1.2.0/contracts/contracts/gatekeepers) and welcome the community to come up with new and innovative ways to grant access to MACI's rounds, helping make MACI more customizable and sybil-resilient. The Hats Protocol gatekeeper is [currently in progress](https://github.com/privacy-scaling-explorations/maci/pull/1191) and will be released soon™ (in v1.2.1).
+
+### Documentation Website
+
+We're excited to announce that all MACI documentation has been unified on our new website, [maci.pse.dev](/)!
+
+This platform will serve as the definitive resource for all information related to MACI, including [blog](/blog) releases, [documentation](/docs/introduction) updates, and [roadmap](/roadmap) progress. Please report any inconsistencies you may find. As always, we welcome suggestions on how to make it better.
+
+## Security Audit
+
+Thanks to thorough reviews by PSE's internal Audit team, clr.fund's developer, [yuetloo](https://github.com/yuetloo), and our core development team, we've identified and addressed several bugs during our recent refactoring efforts. Most notably, a critical bug in MACI v1.x discovered by [Kyle](https://github.com/kcharbo3), which could have allowed coordinators to censor votes, has been [fixed](https://github.com/privacy-scaling-explorations/maci/pull/1170).
+
+For more details on our recent audit, please [refer to our audit docs](/docs/security/audit#pse-audit-202402) or [view the full report](/audit_reports/20240223_PSE_Audit_audit_report.pdf).
+
+After this audit and the resulting fixes, we feel more confident with MACI and its security.
+
+## Trusted Setup Ceremony
+
+Following the successful completion of our [MACI trusted setup ceremony](https://ceremony.pse.dev/projects/Maci%20v1%20Trusted%20Setup%20Ceremony) for [MACI v1.1.1](/blog/maci-v1-1-1-release), we are preparing for a new ceremony to cover the security enhancements added in our v1.2.0 circuits.
+
+To accomplish this, we'll leverage the tooling of [P0tion](https://github.com/privacy-scaling-explorations/p0tion), which helps to streamline and automate Groth16 phase2 ceremonies.
+
+We'll update this page after the ceremony completes to include the production-ready zkey artifacts. In the meantime, the artifacts for v.1.1.1 can be found on our [website](/docs/security/trusted-setup), and the [`tallyVotes`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/tallyVotes.circom) artifacts can still be used in production.
+
+## Get Involved
+
+MACI is deeply committed to our community, through our open initiatives like [public roadmaps](https://github.com/privacy-scaling-explorations/maci/discussions/859), transparent [repository management](https://github.com/privacy-scaling-explorations/maci/discussions/847), and a [public Discord channel](https://discord.com/invite/sF5CT5rzrR) for interaction with our team.
+
+With every issue, PR, feature and roadmap iteration, we welcome feedback to ensure that the continued development of MACI reflects your and the community's needs. Keep an eye out on our [documentation](/), [GitHub discussions](https://github.com/privacy-scaling-explorations/maci/discussions) and our official [Twitter/X account](https://twitter.com/zkMACI) for updates.
+
+For those looking to contribute directly, report bugs, or offer feedback, our [GitHub repository](https://github.com/privacy-scaling-explorations/maci) is open for issues and discussions. We're eager to assist with your projects or contributions.
+
+For practical implementation insights, review our docs as well as the [clr.fund](https://github.com/clrfund/monorepo/) and [QF](https://github.com/quadratic-gardens/qfi) repositories as reference implementations. Both are 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).
+
+For any other questions or feedback, please reach out to us via [PSE's Discord](https://discord.com/invite/sF5CT5rzrR), in our [`#🗳️-maci` channel](https://https//discord.com/channels/943612659163602974/1164613809730748507). We're excited to connect and collaborate with you!
+
+## References
+
+- [MACI GitHub repository](https://github.com/privacy-scaling-explorations/maci)
+- [MACI documentation](/docs/introduction)
+- [A technical introduction to MACI 1.0 - Kyle Charbonnet](/blog/maci-1-0-technical-introduction)
+- [Minimal anti-collusion infrastructure - Vitalik](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413)
+- [PSE Discord server](https://discord.com/invite/sF5CT5rzrR)
+
+## 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).

package/blog/2024-04-10-roadmap-q2.md

@@ -0,0 +1,96 @@
+---
+slug: 2024-q2-roadmap
+title: 2024 Q2 Roadmap update
+description: A review of Q1 and our plans for MACI in Q2 2024
+authors:
+  name: Sam Richards
+  title: MACI team lead
+  url: https://x.com/samonchain
+  image_url: https://avatars.githubusercontent.com/u/8097623?v=4
+tags: [roadmap, rpgf, qf, qv]
+excerpt: "Glad to have you here! We have a few MACI roadmap updates to share.Before we hop into our Q2 plans, let's take a look at what we did in Q1:"
+---
+
+Greetings anon,
+
+Glad to have you here! We have a few MACI roadmap updates to share.
+
+Before we hop into our Q2 plans, let's take a look at what we did in Q1:
+
+## Q1 in review
+
+In our [kickoff of 2024](/blog/2024-team-roadmap), we aimed at [a few major Q1 goals](https://github.com/privacy-scaling-explorations/maci/discussions/859#discussioncomment-7849385) that all tied together:
+
+### ✅ Release MACI v1.2
+
+We completed a significant refactor to simplify the codebase and improve developer experience. After an internal audit and revamped documentation, we released a new MACI version - see our [MACI v1.2 release post](/blog/maci-v1-2-0-release) to read up on the details of that upgrade.
+
+### ✅ Support clr.fund upgrade
+
+[clr.fund](https://clr.fund/#/), a quadratic funding (QF) project which has distributed millions of dollars to Ethereum public goods, is the longest-running production application built on MACI (since 2020!). Thanks primarily to the hard work of their core dev [yuetloo](https://github.com/yuetloo), clr.fund successfully upgraded from MACI 0.x to our fresh v1.2 release. Nicely done!
+
+### ✅ Support ETH Latam QF round
+
+We teamed up with [ETH Latam](https://ethlatam.org/) to help them run a QF round using the clr.fund stack (running on MACI v1.2). Over 60 conference attendees participated (using [Zupass](https://zupass.org/) tickets as the gatekeeper to the faucet and round) to distribute over 30,000 DAI to public good projects across Central America and the Caribbean - [view the round results](https://qf.ethlatam.org/#/leaderboards/0x86F33909474c0dEf2Cb7F93d2eE0B8aF26112BF6/networks/optimism) and learn more in [ETH Kipu's ETH Latam recap post](https://mirror.xyz/ethlatam.eth/OoDqW3Omy8NbOGosdDQ8XUp_fZjP4sf_s4VHkaPWZXM)!
+
+### ✅ Support ETH Colombia QF round
+
+The ETH Colombia team ran a [QF round for their community](https://www.ethcolombia.org/quadratic-funding-ethco-2024-q1) - [view the round results here](https://qf.ethcolombia.org/#/leaderboards/0xa73Ec044b47186646D84D614b8a194dA3bE00260/networks/optimism).
+
+### ✅ Community engagement via events
+
+We participated in our first hackathons ([ETHGlobal Circuit Breaker](https://www.youtube.com/live/iTea0pvwUzw?si=HBycM7oXVAc_grb3), [ETHGlobal London](https://ethglobal.com/events/london2024/prizes#ethereum-foundation), [ETH Latam](https://taikai.network/ethlatam/hackathons/honduras/overview), [ETHTaipei](https://taikai.network/en/ethtaipei/hackathons/hackathon-2024/overview) and [ETHDam](https://www.youtube.com/live/Y5b7K058Nvk?si=36P2bBOTnZpmf5B2&t=4568)) and distributed over $10,000 in bounties. We had a blast engaging with hackers from around the world, receiving feedback, and seeing innovative project ideas on MACI come to life. Thank you to all those who participated!
+
+## Q2 Roadmap
+
+Now let's look at what we're excited to build over the next few months:
+
+### 🎯 MACI-RPGF
+
+[Retroactive Public Goods Funding](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) (RPGF) has been building momentum over the past few years and really took the crypto space by storm after [Optimism's recent round of 30 million OP](https://community.optimism.io/docs/governance/retropgf-3/).
+
+In February we [proposed MACI as a solution for Optimism's RPGF tech stack](https://gov.optimism.io/t/building-a-private-on-chain-implementation-for-retropgf/7733), thanks to MACI's strong guarantees of correct execution, censorship resistance, privacy, and collusion resistance. Since releasing a demo of our [full-stack MACI-RPGF implementation](https://github.com/privacy-scaling-explorations/maci-rpgf/) in March, we've received positive feedback and interest from various communities in running RPGF rounds on MACI.
+
+This quarter we're excited to keep building out MACI-RPGF with additional functionality and improved UX. Our efforts will include supporting community organizers who want to fork and operate MACI-RPGF rounds in production. If you're interested in running a round for your community, [please get in touch](https://qf.pse.dev/apply)!
+
+### 🎯 MACI Coordinator Service
+
+From [years of supporting QF rounds on MACI](https://qf.pse.dev/case-studies) we've learned a lot about the pain-points of community organizers. The blunt truth is that many technical barriers still exist - in order to operate a MACI poll (whether in a QF round or a simple voting application), you essentially must be a developer to deploy the smart contracts, execute on-chain transactions, and run tooling to generate zero-knowledge proofs to guarantee the integrity of a MACI poll. This is no trivial feat, and as a result, MACI is simply not a viable option for many communities to use today.
+
+We're aiming to change this by building a "Coordinator Service" to simplify the [role of the coordinator](/docs/overview/workflow#coordinator), automate tasks, and remove technical barriers to running MACI-RPGF (and all MACI) rounds. This will include a web interface to deploy and operate MACI instances as well as a server to generate proofs and submit them on-chain. We're confident this tooling will accelerate community adoption by offloading the technical overhead and domain knowledge currently required to use this technology stack. More details to come on this soon!
+
+### 🎯 MACI Core Protocol Improvements
+
+After our thorough refactor of MACI's code, which led to the release of v1.2, we're now in position to add new features and improvements to the core protocol. As always, we are open to suggestions from the community, so please let us know what ideas and feature requests you have!
+
+Currently, we have a couple of focus areas:
+
+**Unconditional Privacy**
+
+As of now, MACI's [coordinator](/docs/overview/workflow#coordinator) can track [user key changes](/docs/core-concepts/key-change), which allows them to associate voters with their respective votes, and thus potentially collude with bribers to deanonymize users. We're investigating ways to prevent this possibility. The [3227](https://3327.io/) team implemented a [proof of concept](https://github.com/privacy-scaling-explorations/maci/issues/796) using El-Gamal to remove the link between a new MACI key and their original key. Furthermore, there is a proposal under discussion on how to implement anonymous poll signups, which would provide the same benefits of the El-Gamal protocol, though with a much better user experience.
+
+**Deployment Improvements**
+
+MACI's deployment process can certainly be made easier and more efficient. We will explore ways to improve this, for instance making it cheaper to deploy MACI by implementing patterns to only deploy contracts once if they can be reused across MACI instances. We aim to make it more user-friendly as well by providing a better interface to deploy MACI instances.
+
+### 🎯 Support Gitcoin Allo protocol integration
+
+In our [initial 2024 roadmap](/roadmap) we outlined our plans to engage more with the broader Ethereum ecosystem in order to validate the value of MACI by exploring integrations and gathering input from community developers. Gitcoin is a great example: we've been in discussions with them to explore a MACI integration into their Allo protocol - the smart contracts that power Gitcoin Grants Stack - in order to increase user privacy and bribery resistance in their public good funding infrastructure.
+
+We're already in the process of supporting this integration, thanks to [Nick Lionis and Tse Lao and their ETHDam hackathon project](https://taikai.network/cryptocanal/hackathons/ethdam2024/projects/cluxse8cz00pjz3010wbq3thf/idea). We're excited to see this integration come to life in production and to support Gitcoin in their efforts to improve public goods funding on Ethereum!
+
+### 🎯 Support ETHDam hackathon QV round
+
+Given the privacy focus of [ETHDam](https://www.ethdam.com/), we're excited to support a private quadratic voting (QV) round for the hackathon, powered by MACI. Conference attendees will use clr.fund to vote on their favorite hackathon projects in order to allocate $10,000 to hackathon projects building novel privacy and security solutions in the ecosystem. The round is live at [ethdamqf.com](https://ethdamqf.com/#/), so stay tuned for results!
+
+### 🎯 MACI starter kit
+
+We're teaming up with [Buidl Guild](https://buidlguidl.com/) and the [Scaffold-ETH](https://scaffoldeth.io/) team to build a MACI starter kit: a web app that integrates MACI in order to run polls. We expect this to be a useful template for any developer prototyping on MACI or just looking for a simple reference implementation. Whether you're a dev that prefers reading through code vs. documentation, or you're a builder who merely wants to understand how the MACI user flow works, we hope this will be a great resource for you!
+
+## How does that sound?
+
+Questions? Concerns? Ideas? We’d love to hear from you!
+
+If there is a feature you think we should work on, or an initiative you'd like to collaborate with us on, please let us know! We welcome input from anyone in the community. The best ways to get in touch are to hop in [our Discord](https://discord.com/invite/sF5CT5rzrR) (`#🗳️-maci` channel), [tag us on X](https://twitter.com/zkmaci) or [create an issue on GitHub](https://github.com/privacy-scaling-explorations/maci/).
+
+Onward and upward 🚀

package/blog/2024-05-08-ethdam.md

@@ -0,0 +1,169 @@
+---
+slug: ethdam-bug
+title: ETHDam(n)
+description: A post mortem of the MACI bug that caused a denial of service during the ETHDam Quadratic Funding round
+authors:
+  name: ctrlc03
+  title: MACI dev
+  url: https://x.com/ctrlc03
+  image_url: https://avatars.githubusercontent.com/u/93448202?v=4
+tags: [security, bug, babyjubjub, input validation]
+excerpt: "During ETHDam's Quadratic Funding round, run on clr.fund, we discovered a critical bug in MACI. The issue stemmed from the lack of validation on MACI public keys within the [Poll contract]. A user (spoiler alert, it was a self-inflicted denial of service (DoS)) was able to submit a MACI public key which was not a point of the Baby JubJub elliptic curve, and it broke everything."
+---
+
+During [ETHDam's Quadratic Funding round](https://ethdamqf.com/#/), run on [clr.fund](https://clr.fund), we discovered a critical bug in MACI. The issue stemmed from the lack of validation on MACI public keys within the [Poll contract](/docs/developers-references/smart-contracts/solidity-docs/Poll). A user (spoiler alert, it was a self-inflicted denial of service (DoS)) was able to submit a MACI public key which was not a point of the Baby JubJub elliptic curve, and it broke everything.
+
+## So... what happened, really?
+
+Well, during the ETHDam round, there was an issue with the subgraph that caused the frontend web app to incorrectly display that the voting period had ended, which prevented users from voting.
+
+A quick way for us to identify the issue was to directly call the Poll's [smart contract](https://gnosisscan.io/address/0x37f9dcBd2486eDCa7fF2aaD52f1dd7d7D7d70A7c#code) to submit an invalid vote. If the contract accepted votes, that meant that it was not a MACI issue. Given the contract accepted votes, it immediately helped us confirm that the bug was a frontend issue. What we didn't know at the time was that this vote, as well as its associated key, would cause a denial of service.
+
+The message in question can be seen on Gnosis Chain's [block explorer](https://gnosisscan.io/tx/0x69bb877937e95ebeffc5256f59f8fccf92be9d42eb8b560f4e18ed26bc881090). Below is proof that the wallet which submitted the invalid key is from one of our teammates (just in case you thought we'd want to censor it :P).
+
+```json
+{
+  "address": "0xc59975735ed4774b3Ee8479D0b5A26388B929a34",
+  "msg": "This is proof that I control this wallet and dossed MACI by mistake while doing an invalid vote",
+  "sig": "0x8962b66462630f12476d7bdb348f08af574ba40dd32c6f149ea26717830f13f50f4e95574e8fc909dd3dd1e20bcd85ae2c3caaf41bed6b123973353635483b7f1b",
+  "version": "2"
+}
+```
+
+One can verify the message using [etherscan](https://etherscan.io/verifiedSignatures#), paste the address, message and signature. Don't take our word for it, verify!
+
+The message was sent alongside an invalid MACI public key. As a result, due to how MACI messages are processed, the zk-SNARK circuit failed to generate a proof, which prevented the QF round from finalizing.
+
+A MACI public key is (supposedly, at least) a point on the [Baby JubJub elliptic curve](https://eips.ethereum.org/EIPS/eip-2494). The mistake that MACI's code made was to not validate at the smart contract level that the keys accepted as arguments were actually valid points on the curve. At the time the bug was triggered, the two coordinates of the point (x and y) were only checked to be less or equal to the curve [prime order](https://github.com/privacy-scaling-explorations/zk-kit/blob/main/packages/baby-jubjub/src/baby-jubjub.ts#L13).
+
+The MACI key in question looked like the below object:
+
+```json
+{
+  "x": 1,
+  "y": 1
+}
+```
+
+In MACI, messages are (well, **_should be_**) encrypted using a shared key generated using a random keypair and the coordinator's public key. This allows for the coordinator to reverse the process - as long as they have the random public key - and decrypt the message using the same shared key. This is achieved using [Elliptic-curve Diffie–Hellman (ECDH)](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman).
+
+Shared key generation from the user's side:
+
+```
+ECDH(randomKeyPair.privateKey, coordinatorPublicKey)
+```
+
+Shared key generation from the coordinator's side:
+
+```
+ECDH(coordinatorPrivateKey, randomKeyPair.publicKey)
+```
+
+The `randomKeyPair.publicKey` that was sent as `{x: 1, y: 1}` was eventually passed by the coordinator to a zk-SNARK circuit to try and decrypt the corresponding message and perform further processing.
+
+When passed to the circuit, the code would perform the ECDH operation by performing a scalar multiplication between the public and the coordinator private key. This happens inside the [`MessageToCommand`](https://github.com/privacy-scaling-explorations/maci/blob/v1.2.0/circuits/circom/messageToCommand.circom#L41) template, which calls the [`ECDH` template](https://github.com/privacy-scaling-explorations/zk-kit.circom/blob/main/packages/ecdh/src/ecdh.circom). Here, there is a call to [`escalarMulAny`](https://github.com/privacy-scaling-explorations/zk-kit.circom/blob/main/packages/ecdh/src/ecdh.circom#L25) which in turns calls [`SegmentMulAny`](https://github.com/iden3/circomlib/blob/master/circuits/escalarmulany.circom#L154), where we encounter the final call to [`Edwards2Montgomery`](https://github.com/iden3/circomlib/blob/master/circuits/escalarmulany.circom#L78) where the error pops up.
+
+Looking inside the [`Edwards2Montgomery`](https://github.com/iden3/circomlib/blob/master/circuits/montgomery.circom#L21-L40) template, we can see the operation that is performed on the public key. In short, the point is [converted](https://en.wikipedia.org/wiki/Montgomery_curve#Equivalence_with_twisted_Edwards_curves) from the Twisted Edwards form to Montgomery form, as it allows for cheaper operations inside the circuit (whereas outside it is represented in its original Twisted Edward form).
+
+The equation to convert between the two forms is presented below:
+
+```bash
+                1 + y       1 + y
+    [u, v] = [ -------  , ---------- ]
+                1 - y      (1 - y)x
+
+```
+
+We can see how passing a `y` of 1, the equation would result in a division by zero. Below you can see the full stack trace of the error:
+
+```bash
+Error in template Edwards2Montgomery_349 line: 38
+Error in template SegmentMulAny_362 line: 81
+Error in template EscalarMulAny_364 line: 163
+Error in template Ecdh_365 line: 23
+```
+
+> Please note that passing `x` as 0 would also trigger this error, though within the `EscalarMulAny` template, this case is handled and the G8 point is passed [instead](https://github.com/iden3/circomlib/blob/master/circuits/escalarmulany.circom#L161), preventing an error while generating the proof.
+
+Given this issue, we weren't able to complete the proof generation for message processing. It is somewhat good news, as once a message is posted to MACI's smart contracts, it's not possible to censor it even if these messages trigger bugs.
+
+## How was the round saved?
+
+After understanding the bug, the team came up with a solution that would both allow EthDAM to pay out projects with cryptographic guarantee of the results, as well as provide a solution that is fully transparent and verifiable. After all, MACI is all about verifiability.
+
+Given that the clr.fund round was run using a token with no monetary value (EthDAMToken), instead of spinning up a new round and asking users to re-submit their votes, we opted for an automated solution which would scrap all signups and contribution of this token, as well as all messages, and to re-submit them to the new clr.fund round contracts.
+
+This way, voters can validate that all signups and votes were included, and by not submitting this invalid message, being able to generate zk-SNARK proofs and validate publicly the final tally result.
+
+The script in question can be found [in a gist](https://gist.github.com/ctrlc03/714bd5dc5cc21456396dd3742801c3cd). In a nutshell, the script pulled all signups from the original round [fundingRound](https://gnosisscan.io/address/0xdc36cb99274e7007864512129202f97637832b61#code) contract, and submitted them on the [new contract](https://gnosisscan.io/address/0xAbCF7403c8806B1DEF9c83D90dd2Ef6bAA5BcbD4), after having approved the new contract to spend all EthDAMToken tokens. Then, it pulls the messages, aside from the invalid one, and posts them to the new [Poll](https://gnosisscan.io/address/0x3A56A74326550f333587Aa25A2D7a2640589A5B4) contract.
+
+After this, the EthDAM team was able to complete the tally alongside ZK proofs to be submitted on chain.
+
+## How did we fix MACI?
+
+To fix the bug, we added code to validate that a given point is on the curve. The Solidity [library](https://github.com/yondonfu/sol-baby-jubjub), found within the original Baby JubJub paper, was originally developed by [yondonfu](https://github.com/yondonfu) and for sake of simplicity, it was copied over to the MACI's repo. The code needed just a couple of small upgrades to work with more recent Solidity versions (0.8.20).
+
+```solidity
+/**
+ * @dev Check if a given point is on the curve
+ * (168700x^2 + y^2) - (1 + 168696x^2y^2) == 0
+ */
+function isOnCurve(uint256 _x, uint256 _y) internal pure returns (bool) {
+  uint256 xSq = mulmod(_x, _x, Q);
+  uint256 ySq = mulmod(_y, _y, Q);
+  uint256 lhs = addmod(mulmod(A, xSq, Q), ySq, Q);
+  uint256 rhs = addmod(1, mulmod(mulmod(D, xSq, Q), ySq, Q), Q);
+  return submod(lhs, rhs, Q) == 0;
+}
+```
+
+As seen in the code above, the function will evaluate the Baby JubJub equation using the input public key x and y values. Any value that is not on the curve, will be rejected, as shown below:
+
+```solidity
+// check if the public key is on the curve
+if (!CurveBabyJubJub.isOnCurve(_encPubKey.x, _encPubKey.y)) {
+  revert InvalidPubKey();
+}
+```
+
+The bug was fixed with this [PR](https://github.com/privacy-scaling-explorations/maci/pull/1408). On top of preventing such invalid values from being accepted by the contract, we also added more validation across the TypeScript libraries to make it harder for users to make such mistakes.
+
+## Footnote
+
+The MACI team would like to first of all thank [EthDAM's team](https://www.ethdam.com/) for their patience while we navigated through this issue, and trusting us with coming up with a transparent solution for the round.
+
+Furthermore, we thank [mikerah](https://twitter.com/badcryptobitch) from [HashCloak](https://hashcloak.com/) for helping to review the fix, and their expertise in handling security incidents like this. Together with them, we looked at other repositories using similar code, looking for the same mistake, though we did not find similar protocols where an invalid key would cause a denial of service. If you are a ZK developer reading this, we hope this was a lesson that would help remind us all to always validate user input for future scenarios.
+
+Finally, a big thank you to [Raphael](https://x.com/rrtoledo_) for explaining the math behind the issue, and suggesting that full point validation would end up being a much better solution than just not accepting `y = 1`.
+
+## Contract addresses
+
+Below is a list of the contract addresses for this EthDAM round. All code is verified on Gnosis's block explorer and can be reviewed.
+
+**RoundToken**
+
+- [EthDAMToken](https://gnosisscan.io/address/0xBbbe1B8460b5fBC7f43C1dd6929A66F54c1B90ef)
+
+**clr.fund Instance**
+
+- [clr.fund](https://gnosisscan.io/address/0x55ff8c4dCccE90989b5B173587a0981AA4a84319)
+
+**Original round**
+
+- [FundingRound](https://gnosisscan.io/address/0xdc36cb99274e7007864512129202f97637832b61#code)
+- [MACI](https://gnosisscan.io/address/0xf5aa8c642bd4eec9c44fe6997a790b57bcd410d5)
+- [Poll](https://gnosisscan.io/address/0x37f9dcBd2486eDCa7fF2aaD52f1dd7d7D7d70A7c)
+
+**New Round**
+
+- [Funding Round](https://gnosisscan.io/address/0xAbCF7403c8806B1DEF9c83D90dd2Ef6bAA5BcbD4)
+- [MACI](https://gnosisscan.io/address/0x3F08b072570abb12df93A826ee87aDcF08979847)
+- [Poll](https://gnosisscan.io/address/0x3A56A74326550f333587Aa25A2D7a2640589A5B4)
+- [Tally](https://gnosisscan.io/address/0xCbE6241208a329a1b1F205e75ABa19fbaD6c571e)
+- [MessageProcessor](https://gnosisscan.io/address/0xD25C88A92228b5F9171A3622B92f2c757cbFafaE)
+
+## MACI New Version
+
+We decided to publish a new version of MACI with the fix (and other changes made since the 1.2 release). The new version is [1.2.1](https://github.com/privacy-scaling-explorations/maci/releases/tag/v1.2.1).
+
+Please do not use the 1.2 version of the contracts for any new deployments, as it contains the bug described in this post. All other packages are safe, though 1.2.1 is the recommended version to use.

package/blog/2024-05-22-the-origins-of-maci.md

@@ -0,0 +1,38 @@
+---
+slug: maci-origins
+title: The Origins of MACI - Vitalik’s Vision for Secure Digital Voting
+description: An introduction to MACI's history
+authors:
+  name: Vee
+  title: MACI marketing manager
+  url: https://github.com/Vee-18
+  image_url: /img/pse-logo-round.png
+tags: [maci, voting, history, vitalik]
+excerpt: "Minimal Anti-Collusion Infrastructure (MACI), is making waves in the world of private, digital voting. But where did this technology originate? Vitalik Buterin is the mind that thought of MACI. In this post, we’ll dive into his vision for a more secure and private digital voting system."
+---
+
+Minimal Anti-Collusion Infrastructure (MACI), is making waves in the world of private, digital voting. But where did this technology originate? Vitalik Buterin is the mind that thought of MACI. In this post, we’ll dive into his vision for a more secure and private digital voting system.
+
+## Who is Vitalik Buterin?
+
+For those unfamiliar with the name, [Vitalik Buterin](https://vitalik.eth.limo/) is a Russian-Canadian programmer who co-founded Ethereum. Ethereum is a blockchain platform that has been a game-changer in the world of cryptocurrency and beyond. Vitalik’s passion for blockchain technology led him to explore various applications, including digital voting, which eventually culminated in the [proposal](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) of MACI.
+
+## What Inspired MACI?
+
+Vitalik was deeply concerned with the issues plaguing traditional and digital voting systems, such as fraud, lack of privacy, and potential manipulation. He imagined a system that could handle digital voting with utmost integrity, transparency, and security, ensuring that people’s votes would genuinely make a difference. This led to the birth of Minimum Anti-Collusion Infrastructure or MACI.
+
+## Breaking Down MACI
+
+MACI is a system designed for digital voting that protects against collusion and bribery, while ensuring privacy, authenticity, and that no vote can be censored. How? Through cleverly employing smart contracts on the Ethereum blockchain and something called Zero-Knowledge Proofs (ZKPs). This combination makes sure that no one, aside from a trusted coordinator who helps tally results, can view the votes. However, absolutely no one, not even the coordinator, can tamper with the results.
+
+## The Importance of Privacy
+
+One of Vitalik’s major concerns was the privacy of voters. In a world where data is often exposed or misused, the anonymity of a voter is of utmost importance in maintaining the integrity of the voting process. MACI ensures that votes remain a secret, and that only a trusted coordinator has the ability to decrypt them.
+
+## A Democratic Revolution
+
+Through MACI, Vitalik sought to revolutionise the democratic process. Imagine a world where communities could make decisions without fear of interference or manipulation. Where funds could be raised and allocated for public goods and services in a fair and transparent way. That’s what MACI is all about.
+
+## Final Thoughts
+
+Vitalik’s vision for MACI was not just a technological advancement, but a stride towards a more just and democratic society. Through blockchain technology, he has shown how innovation can be harnessed for the greater good, by protecting the sanctity of each vote. MACI is a testament to how technology can be a powerful tool in upholding democratic values and ensuring that every voice is heard. If you’re keen on learning more, dig in to our documentation [**here**](https://maci.pse.dev/docs/introduction). Also, join us in building our future, connect with our team on [Discord](https://discord.com/invite/sF5CT5rzrR)!

package/blog/2024-05-28-upcoming-grants.md

@@ -0,0 +1,85 @@
+---
+slug: upcoming-grants-2024
+title: Upcoming grants for MACI protocol improvements
+description: Dive into the next MACI protocol changes and improvements.
+authors:
+  name: ctrlc03
+  title: MACI dev
+  url: https://x.com/ctrlc03
+  image_url: https://avatars.githubusercontent.com/u/93448202?v=4
+tags: [voting, security, anonymity, roadmap, grants]
+excerpt: "Minimal Anti Collusion Infrastructure (MACI) is a public good that allows one to run secure, private, on-chain voting polls."
+---
+
+Minimal Anti Collusion Infrastructure ([MACI](https://github.com/privacy-scaling-explorations/maci)) is a public good that allows one to run secure, private, on-chain voting polls.
+
+Given MACI's open source nature, it's common for our core team to develop new features or to fix issues based on community feedback. However, it's been less common for external contributors to make significant changes to the core protocol.
+
+Well, this soon will be a reality thanks to a MACI improvement proposal sent by the [3327](https://3327.io/) team. 3327 is collective of 10+ people working on improving blockchain technologies, with a focus on research and engineering. Their engineering team previously worked on implementing the [ElGamal flow](https://github.com/0x3327/maci/blob/feat/elgamal/docs/elgamal-flow.md) into MACI ([here's a nice presentation on it from Marija Mikić at EthCC [6]](https://www.youtube.com/live/X54LaXfJTn4)). The work described in this post aims to be its direct replacement due to its simplified nature and several additional benefits.
+
+This proposal can be divided into two parts:
+
+1. bring unconditional privacy to MACI's voters
+2. optimise inefficient merkle tree structure holding messages, by replacing it with a hash chain
+
+## 1) Enable unconditional voter privacy
+
+Currently with MACI, if a voter performs a [key change](/docs/core-concepts/key-change), the voter's new key would not be anonymous to the coordinator. The coordinator could collude with a bad actor to inform the latter of the key change, as the coordinator would have access to all decrypted messages.
+
+The key focus of this improvement is to enable users to be completely anonymous by removing the link between the original signup key and the key used for voting. How would this work? Well, users sign up to vote via the [MACI contract](/docs/developers-references/smart-contracts/MACI), and depending on the [gatekeeper](/docs/developers-references/smart-contracts/Gatekeepers) in use, they'd have to prove that they've passed the entry condition. Now, given knowledge of this key, they can signup with a new key to polls deployed by this same MACI contract.
+
+Thus, voters can prove anonymously that they know the preimage of a [`StateLeaf`](/docs/developers-references/typescript-code/typedoc/domainobjs/classes/StateLeaf), by passing this information to a zk-SNARK circuit, and validating this proof within the poll contract when joining with the new key. You might be thinking that everyone knows the preimage of a state leaf, as it's public information that can be taken from the contracts' logs. However, the circuit will not accept the public key directly but would instead take the private key and use it to generate the public key. This way, only users with knowledge of a specific private key can generate a valid inclusion proof.
+
+Now after signing up to the Poll with this new key, there will not be any link to the original key, and users will effectively be anonymous. Of course users should ensure that they are using different wallets where possible.
+
+Finally, with the use of a nullifier, it will not be possible for the same original key to be used to signup more than once for each new poll.
+
+Are there any drawbacks? Well, yes. There will be an extra step for users to register to individual Polls. We aim to offset this cost and additional step soon either with gasless transactions or by moving some logic off-chain.
+
+## 2) Message structure optimisation
+
+On top of the improvements to anonymity, the [3327 team](https://3327.io/) aims to also replace the Merkle tree used for storing messages with a [hash chain](https://csrc.nist.gov/glossary/term/hash_chain). Some of the benefits of this approach are:
+
+- unlimited number of messages
+- removal of expensive merge operations from the coordinator
+- cheaper to send messages as only one hash is required to update the hash chain
+- less constraints on the circuits due to simplified logic
+
+**Unlimited messages**
+
+Merkle trees are usually bound by a depth property. Together with the number of leaves per node, we can calculate the max capacity of a tree. For instance, for a binary tree with a depth of 10, we can host up to **2^10** (1024) leaves. On the other hand, hash chains do not have a limit, unless if we wanted to set one, so we technically can support an unlimited number of messages.
+
+**Cheaper operations**
+
+Hashing the previous hash chain with the message is cheaper than inserting into a Merkle tree. Additionally, removing the need for the coordinator to perform merge operations on the accumulator queues that were used on chain will greatly reduce costs and processing time.
+
+**Smaller circuits**
+
+As cited in their proposal, processing message inclusion proofs for **k** messages in a tree with height **h** requires **k \* h** hashing operations within the circuit with **2 \* k \* h** signal values for inclusion proofs. Processing messages with chain hashes removes the unnecessary inclusion proofs and requires only **k** hashes to be computed for **k** messages without any extra signals, as the requirement is to prove that the order and inclusion of all messages are correct.
+
+## A call for MACI grant proposals
+
+So what does this mean for you, Anon?
+
+As an open-source project of [PSE](https://pse.dev) with support from the Ethereum Foundation, MACI is fortunate to have the resources to invest in the maintenance and improvement of the protocol. This means we're able to fund full-time developers as well as allocate grants for various research and development initiatives.
+
+We encourage all community members to contribute to the improvement and ongoing development of MACI! After all, our goal is to build the most secure e-voting system, and this cannot be accomplished without all of your support.
+
+As a team, we are incredibly excited about this proposal and will continue to work hard to help the [3327 team](https://3327.io/) get this upgrade production-ready over the next 3 months.
+
+To contribute to MACI, submit issues, or learn more about it, you can reach out to us either via [Discord](https://discord.com/invite/sF5CT5rzrR) or [GitHub issues](https://github.com/privacy-scaling-explorations/maci/issues/new/choose).
+
+If you have an ambitious idea you'd like to work on, reach out to us and we could create a proposal to build together! If you don't yet have a specific idea but are still keen to work on MACI, we have some research ideas which might inspire you and we could collaborate on a grant together. Feel free to explore these ideas below and get in touch:
+
+- [MACI coordinator in a TEE](https://github.com/privacy-scaling-explorations/maci/discussions/1385)
+- [Group wise matching](https://github.com/privacy-scaling-explorations/maci/issues/905)
+- [Folding schemes for MACI's circuits](https://github.com/privacy-scaling-explorations/maci/issues/904)
+
+## References
+
+- [3327 team](https://3327.io/)
+- [3327 ElGamal flow](https://github.com/0x3327/maci/blob/feat/elgamal/docs/elgamal-flow.md)
+- [3327 ElGamal API](https://github.com/0x3327/maci/blob/feat/elgamal/docs/elgamal-api.md)
+- [Marija Mikić - Anonymity in MACI - EthCC [6]](https://www.youtube.com/live/X54LaXfJTn4)
+- [MACI Original idea](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413)
+- [MACI Anonymization](https://ethresear.ch/t/maci-anonymization-using-rerandomizable-encryption/7054)

package/blog/2024-06-17-understanding-maci.md

@@ -0,0 +1,63 @@
+---
+slug: maci-for-beginners
+title: Understanding MACI - A Beginner's Guide to Private On-Chain Voting
+description: An introduction to MACI's
+authors:
+  name: Vee
+  title: MACI contributor
+  url: https://github.com/Vee-18
+  image_url: /img/pse-logo-round.png
+tags: [maci, voting, history, vitalik]
+excerpt: "In this blog post, we’ll give a high-level, beginner friendly introduction of what Minimal Anti-Collusion Infrastructure (MACI) is, and how it could be used in a real-world context. We’ll take you through the essentials of MACI, making complex concepts accessible regardless of your background in the blockchain space."
+---
+
+Hey Anon!
+
+In this blog post, we’ll give a high-level, beginner friendly introduction of what Minimal Anti-Collusion Infrastructure (MACI) is, and how it could be used in a real-world context. We’ll take you through the essentials of MACI, making complex concepts accessible regardless of your background in the blockchain space.
+
+## What is MACI?
+
+MACI is a cutting-edge solution that ensures private, reliable voting on the blockchain.
+
+## Blockchain Voting Challenges for Beginners
+
+On-chain voting is a method of casting votes directly on the blockchain, leveraging its decentralized and transparent nature. While this provides us with censorship resistance and guarantees correct execution, the transparency of blockchains can be a double-edged sword. Given all transaction data is public by default, it means everyone can see how anyone voted. This ensures all votes are correctly counted but the visibility could lead to undue influence on voters' decisions, and potentially opens doors for unethical practices like voter bribery. The challenge, therefore, lies in preserving the privacy of each vote while maintaining the core principles of blockchain: transparency, process integrity, and security.
+
+## How MACI Offers a Solution
+
+Minimal Anti-Collusion Infrastructure, or MACI, steps in as an elegant solution to these challenges. Despite operating on-chain, it protects the privacy of voters and votes, thereby significantly reducing the chances of vote manipulation through bribery. How does it achieve this? By employing advanced cryptographic techniques like zero-knowledge proofs (zk-SNARKs), **MACI ensures that while the outcome of the vote is public and transparent, individual voting choices remain private**. For instance, let's say you vote in an election using MACI, you could claim to everyone that you voted for a particular candidate, but in reality, you might have voted for someone else. There's no way for anyone to verify your claim, making bribery less appealing.
+
+## Key Features of MACI
+
+MACI isn't just a tool; it's a fortress safeguarding the integrity of on-chain voting. Let's break down its key features:
+
+- **Collusion Resistance**: MACI makes it virtually impossible for voters to be swayed by bribes, as they can't prove how they voted.
+- **Privacy**: Your vote is your secret. Only you know where your support lies, thanks to the encryption technology MACI employs.
+- **Uncensorability**: Every vote counts and cannot be blocked, edited or removed, ensuring a fair voting process.
+- **Unforgeability**: Your vote is tied to your unique digital identity, preventing anyone else from casting a vote in your place.
+- **Non-repudiation**: Once cast, your vote is set in stone. You can change your mind and vote again, but you can't erase your previous vote.
+- **Correct Execution**: The final tally is accurate and tamper-proof, ensuring that the true voice of the voting population is heard.
+
+These features come together to create a voting environment where your voice is heard, loud and clear, without fear of external influence or manipulation.
+
+## Technical Overview Simplified
+
+At its heart, MACI is built on Ethereum, a blockchain platform. This foundation provides a high level of security and trust. The real magic, however, lies in something called zk-SNARKs. Think of zk-SNARKs as a cloak of invisibility for your vote; they hide your voting choices while still guaranteeing the overall vote count to be tallied accurately. This blend of Ethereum's robust framework and the innovative use of zk-SNARKs makes MACI a reliable and secure choice for on-chain voting, ensuring that your vote is both private and counted.
+
+If you’re interested in more of the technical details, check out the MACI documentation.
+
+## Real-World Applications and Limitations
+
+Imagine a world where funding for public goods, like community projects or open-source software, is decided through fair and transparent voting. This is where MACI shows its true potential. [Quadratic funding](/docs/use-cases/public-goods-funding/quadratic-funding) is already harnessing MACI's capabilities to enhance user privacy and discourage any form of collusion in funding decisions.
+
+However, like any system, MACI isn't perfect. Its effectiveness hinges on the honesty of the coordinator – the entity or person overseeing the voting process and tallying the results. A dishonest coordinator could pose risks, but thankfully, MACI is designed to minimise even this possibility, maintaining a high level of integrity in the voting process.
+
+## Conclusion
+
+As we've explored, Minimal Anti-Collusion Infrastructure (MACI) stands as a testament to the innovative solutions being developed in the blockchain space, especially for those new to this technology. It addresses the critical need for privacy and fairness in on-chain voting, ensuring that your vote remains your own, free from external pressures and manipulation.
+
+Blockchain technology is continually evolving, and with tools like MACI, it's becoming more accessible and trustworthy. Whether you're a blockchain enthusiast, a developer, or someone just starting to explore this exciting field, MACI represents a significant step forward in creating a more democratic and transparent digital world.
+
+We encourage you to delve deeper into MACI and the broader world of blockchain by reading through our [documentation](/docs/introduction) and installing MACI. Join us too on our [Discord](https://discord.com/invite/sF5CT5rzrR) to report any bugs or to chat with our team. Your involvement can help shape a future where digital voting is not just secure, but also truly representative of the people's voice.
+
+Together, let's embrace these advancements and contribute to a fairer, more transparent digital voting landscape.