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

package/versioned_docs/version-v2.x/guides/testing/testing.md

@@ -0,0 +1,163 @@
+---
+title: Testing MACI
+description: An introduction on how to test MACI
+sidebar_label: Testing
+sidebar_position: 1
+---
+
+# Testing introduction
+
+## Unit tests
+
+Unit tests within the project are built using [Mocha](https://mochajs.org/) and [Chai](https://www.chaijs.com/). Mocha is a test framework that provides the environment to write and run JavaScript tests, while Chai is an assertion library that allows us to write assertions in a more expressive and readable way.
+
+The following submodules contain unit tests: `core`, `crypto`, `circuits`,
+`contracts`, and `domainobjs`.
+
+You can run all unit tests from the root directory of the repo by running:
+
+```bash
+pnpm run test
+```
+
+Or you can run unit tests within each submodule. for example to run the `crypto` tests:
+
+```bash
+cd packages/crypto
+pnpm run test
+```
+
+You can also run individual tests within submodules, for example:
+
+```bash
+cd packages/contracts
+pnpm run test:accQueue
+```
+
+This test command will run `AccQueue.test.ts`
+
+### Contracts
+
+First, compile the contracts.
+
+From the main `maci/` directory, run:
+
+```bash
+cd packages/contracts && \
+pnpm run compileSol
+```
+
+To run Contracts only tests, run:
+
+```bash
+pnpm run test
+```
+
+### Circuits
+
+To test the circuits, from the main `maci/` directory, run:
+
+```bash
+cd packages/circuits && \
+pnpm run test
+```
+
+Tests are run using [Mocha](https://mochajs.org/) and [`circom_tester`](https://github.com/iden3/circom_tester).
+
+## CLI
+
+You can test the CLI locally. First, you need to either generate `.zkey` files,
+or download them. Please remember to not use these testing `.zkey` files in production.
+
+### Download `.zkey` files or the witness generation binaries
+
+MACI has two main zk-SNARK circuits, `processMessages` and `tallyVotes`.
+
+:::info
+The `processMessages` and `tallyVotes` circuits are also provided in a non-quadratic voting (non-QV) version. Currently these new versions have not undergone a trusted setup ceremony.
+:::
+
+Each circuit is parameterised and there should be one
+`.zkey` file for each circuit and set of parameters.
+
+Unless you wish to generate a fresh set of `.zkey` files, you should obtain
+them from someone who has performed a multi-party trusted setup for said
+circuits.
+
+Note the locations of the `.zkey` files as the CLI requires them as
+command-line flags.
+
+For testing purposes you can download the required artifacts using the [`download-zkeys:test`](https://github.com/privacy-scaling-explorations/maci/blob/dev/package.json#L15). The script will place all required artifacts inside the `cli/zkeys` folder.
+
+You can run the script directly with bash or use pnpm: `pnpm run download:test-zkeys` from the monorepo root.
+
+### Compile the circuits and generate zkeys (if decided to generate from scratch)
+
+From the root folder, run:
+
+**for c++ witness generator**
+
+```bash
+pnpm build:circuits-c -- --outPath ../cli/zkeys
+```
+
+**for wasm witness generator**
+
+```bash
+pnpm build:circuits-wasm -- --outPath ../cli/zkeys
+```
+
+**generate zkeys**
+
+```bash
+pnpm setup:zkeys --outPath ../cli/zkeys
+```
+
+### Check the Rapidsnark binary
+
+Next, ensure that the `prover` binary of `rapidsnark` is in
+`~/rapidsnark/build/prover`.
+
+:::info
+This step is only required if you wish to use rapidsnark, for faster proof generation. You can also use the WASM witnesses provided in the `cli/zkeys` folder.
+:::
+
+### Run CLI tests
+
+You can find the tests in `maci/cli/tests`.
+
+To run the tests first start a hardhat node in the background:
+
+```bash
+cd packages/contracts
+pnpm run hardhat &
+cd ../cli
+```
+
+Then run the tests (this will run all tests):
+
+```bash
+pnpm run test
+```
+
+To run e2e tests (quadratic voting):
+
+```bash
+pnpm run test:e2e
+```
+
+To run e2e tests with normal voting (not quadratic voting):
+
+```bash
+pnpm run test:e2e-non-qv
+```
+
+### Run integration tests
+
+You can find the tests in `maci/integrationTests/`.
+
+You can run them with:
+
+```bash
+pnpm run test
+```

package/versioned_docs/version-v2.x/guides/troubleshooting.md

@@ -0,0 +1,161 @@
+---
+title: Troubleshooting
+description: How to troubleshoot MACI's failures
+sidebar_label: Troubleshooting
+sidebar_position: 5
+---
+
+# Troubleshooting
+
+## cli: `genProofs` command failure
+
+### Case: missing `.dat` files
+
+If your logs look like the following, then make sure you have `ProcessMessages_10-2-1-2_test.dat` and `TallyVotes_10-1-2_test.dat` files in the same directory as your zkeys:
+
+```
+node build/ts/index.js genProofs -x 0xf204a4Ef082f5c04bB89F7D5E6568B796096735a \
+>     -sk macisk.49953af3585856f539d194b46c82f4ed54ec508fb9b882940cbe68bbc57e59e \
+>     -o 0 \
+>     -r ~/rapidsnark/build/prover \
+>     -wp ./zkeys/ProcessMessages_10-2-1-2_test \
+>     -wt ./zkeys/TallyVotes_10-1-2_test \
+>     -zp ./zkeys/ProcessMessages_10-2-1-2_test.0.zkey \
+>     -zt ./zkeys/TallyVotes_10-1-2_test.0.zkey \
+>     -t tally.json \
+>     -f proofs
+
+fromBlock = 0
+Generating proofs of message processing...
+terminate called after throwing an instance of 'std::system_error'
+  what():  open: No such file or directory
+Aborted (core dumped)
+
+terminate called after throwing an instance of 'std::system_error'
+  what():  open: No such file or directory
+Aborted (core dumped)
+
+Error: could not generate proof.
+Error: Error executing ./zkeys/ProcessMessages_10-2-1-2_test /tmp/tmp-9904-zG0k8YPTATWB/input.json /tmp/tmp-9904-zG0k8YPTATWB/output.wtns
+    at genProof (/home/ubuntu/maci/circuits/ts/index.ts:44:15)
+    at /home/ubuntu/maci/cli/ts/genProofs.ts:339:25
+    at step (/home/ubuntu/maci/cli/build/genProofs.js:33:23)
+    at Object.next (/home/ubuntu/maci/cli/build/genProofs.js:14:53)
+    at fulfilled (/home/ubuntu/maci/cli/build/genProofs.js:5:58)
+```
+
+You can generate the missing `.dat` files using the following command:
+
+```bash
+pnpm build:circuits-c -- --outPath ../cli/zkeys
+```
+
+## contracts: `prove` command failure
+
+### Case `Commitment mismatch`
+
+If your log looks like the following, that's because you have already run the `prove` command. You can access the `cli` and attempt again by executing the `genProofs` command.
+
+```
+Error: commitment mismatch
+    at Prover.validateCommitment (/home/user/Documents/maci/contracts/tasks/helpers/Prover.ts:458:13)
+    at Prover.proveTally (/home/user/Documents/maci/contracts/tasks/helpers/Prover.ts:390:12)
+    at processTicksAndRejections (node:internal/process/task_queues:95:5)
+    at async SimpleTaskDefinition.action (/home/user/Documents/maci/contracts/tasks/runner/prove.ts:235:7)
+    at async Environment._runTaskDefinition (/home/user/Documents/maci/node_modules/.pnpm/hardhat@2.22.2_ts-node@10.9.2_typescript@5.4.3/node_modules/hardhat/src/internal/core/runtime-environment.ts:359:14)
+    at async Environment.run (/home/user/Documents/maci/node_modules/.pnpm/hardhat@2.22.2_ts-node@10.9.2_typescript@5.4.3/node_modules/hardhat/src/internal/core/runtime-environment.ts:192:14)
+    at async main (/home/user/Documents/maci/node_modules/.pnpm/hardhat@2.22.2_ts-node@10.9.2_typescript@5.4.3/node_modules/hardhat/src/internal/cli/cli.ts:323:7)
+ ELIFECYCLE  Command failed with exit code 1.
+ ELIFECYCLE  Command failed with exit code 1.
+```
+
+This is because commitments are generated using random salts, thus will differ at each `genProofs` run.
+
+In [core/Poll.ts](/docs/technical-references/typescript-code/typedoc/core/classes/Poll):
+
+```
+let newSbSalt = genRandomSalt();
+while (this.sbSalts[this.currentMessageBatchIndex!] === newSbSalt) {
+  newSbSalt = genRandomSalt();
+}
+```
+
+## General Failure
+
+### Case `AssertionError`
+
+This could happen when you run `prove` in the `contracts` package, or run `genProofs` in the `cli` package. If your log looks like the following, there are two possible reasons:
+
+1. If your MACI keypair for the coordinator was generated based on a previous version, it may have been generated incorrectly due to a breaking change in a third-party package (`zk-kit/eddsa-poseidon`). Please generate a new pair and run the whole process again.
+2. The provided private key is unmatched to the public key which deployed the poll, you will need to input the correct private key.
+
+```
+An unexpected error occurred:
+
+AssertionError [ERR_ASSERTION]: false == true
+    at genMaciStateFromContract (/home/user/Documents/maci/contracts/ts/genMaciState.ts:156:9)
+    at processTicksAndRejections (node:internal/process/task_queues:95:5)
+    at async SimpleTaskDefinition.action (/home/user/Documents/maci/contracts/tasks/runner/prove.ts:127:25)
+    at async Environment._runTaskDefinition (/home/user/Documents/maci/node_modules/.pnpm/hardhat@2.22.2_ts-node@10.9.2_typescript@5.4.3/node_modules/hardhat/src/internal/core/runtime-environment.ts:359:14)
+    at async Environment.run (/home/user/Documents/maci/node_modules/.pnpm/hardhat@2.22.2_ts-node@10.9.2_typescript@5.4.3/node_modules/hardhat/src/internal/core/runtime-environment.ts:192:14)
+    at async main (/home/user/Documents/maci/node_modules/.pnpm/hardhat@2.22.2_ts-node@10.9.2_typescript@5.4.3/node_modules/hardhat/src/internal/cli/cli.ts:323:7) {
+  generatedMessage: true,
+  code: 'ERR_ASSERTION',
+  actual: false,
+  expected: true,
+  operator: '=='
+}
+```
+
+### Cannot filter non-indexed parameters
+
+If you encountered the following error log:
+
+```
+TypeError: cannot filter non-indexed parameters; must be null (argument="contract._messageRoot", value=4658669366154318429589992378027343879410506110087584229116806667655891474709, code=INVALID_ARGUMENT, version=6.11.1)
+    at makeError (/home/user/Documents/maci/node_modules/.pnpm/ethers@6.11.1/node_modules/ethers/src.ts/utils/errors.ts:687:21)
+    at assert (/home/user/Documents/maci/node_modules/.pnpm/ethers@6.11.1/node_modules/ethers/src.ts/utils/errors.ts:715:25)
+    at assertArgument (/home/user/Documents/maci/node_modules/.pnpm/ethers@6.11.1/node_modules/ethers/src.ts/utils/errors.ts:727:5)
+    at /home/user/Documents/maci/node_modules/.pnpm/ethers@6.11.1/node_modules/ethers/src.ts/abi/interface.ts:1047:31
+    at Array.forEach (<anonymous>)
+    at Interface.encodeFilterTopics (/home/user/Documents/maci/node_modules/.pnpm/ethers@6.11.1/node_modules/ethers/src.ts/abi/interface.ts:1042:16)
+    at /home/user/Documents/maci/node_modules/.pnpm/ethers@6.11.1/node_modules/ethers/src.ts/contract/contract.ts:108:39
+    at processTicksAndRejections (node:internal/process/task_queues:95:5)
+    at async getSubInfo (/home/user/Documents/maci/node_modules/.pnpm/ethers@6.11.1/node_modules/ethers/src.ts/contract/contract.ts:502:18)
+    at async Proxy.queryFilter (/home/user/Documents/maci/node_modules/.pnpm/ethers@6.11.1/node_modules/ethers/src.ts/contract/contract.ts:938:38) {
+  code: 'INVALID_ARGUMENT',
+  argument: 'contract._messageRoot',
+  value: 4658669366154318429589992378027343879410506110087584229116806667655891474709n,
+  shortMessage: 'cannot filter non-indexed parameters; must be null'
+}
+```
+
+This could happen during running `genProofs` in `cli` package, or running `prove` in `contracts` package.
+Be aware that we updated several parameters to `indexed`:
+
+```javascript
+event MergeMaciStateAqSubRoots(uint256 indexed _numSrQueueOps);
+event MergeMaciStateAq(uint256 indexed _stateRoot, uint256 indexed _numSignups);
+event MergeMessageAqSubRoots(uint256 indexed _numSrQueueOps);
+event MergeMessageAq(uint256 indexed _messageRoot);
+```
+
+Please remember to pull the latest MACI repo updates(`git fetch origin && git pull origin dev`) and run `pnpm build` in the root of this monorepo.
+
+### Verifier contract found the proof invalid
+
+If your log looks like the following, that's because the zkey and wasm files added to the [`VkRegistry` contract](/docs/technical-references/smart-contracts/VkRegistry) are different from what you use to run the **prove** command. Check if you're using the correct zkey and wasm files.
+
+```
+Error: The verifier contract found the proof invalid.
+    at Prover.proveMessageProcessing (/home/user/Documents/maci/contracts/tasks/helpers/Prover.ts:215:15)
+    at processTicksAndRejections (node:internal/process/task_queues:95:5)
+    at async SimpleTaskDefinition.action (/home/user/Documents/maci/contracts/tasks/runner/prove.ts:185:7)
+    at async Environment._runTaskDefinition (/home/user/Documents/maci/node_modules/.pnpm/hardhat@2.22.2_ts-node@10.9.2_typescript@5.4.4/node_modules/hardhat/src/internal/core/runtime-environment.ts:359:14)
+    at async Environment.run (/home/user/Documents/maci/node_modules/.pnpm/hardhat@2.22.2_ts-node@10.9.2_typescript@5.4.4/node_modules/hardhat/src/internal/core/runtime-environment.ts:192:14)
+    at async main (/home/user/Documents/maci/node_modules/.pnpm/hardhat@2.22.2_ts-node@10.9.2_typescript@5.4.4/node_modules/hardhat/src/internal/cli/cli.ts:323:7)
+```
+
+### The on-chain verification of total spent voice credits failed
+
+If you ran the `verify` command and got this error, please ensure consistency in your use of quadratic voting throughout interactions with MACI, including poll deployment, proof generation, and verification.

package/versioned_docs/version-v2.x/introduction.md

@@ -0,0 +1,146 @@
+---
+title: What is MACI?
+description: High-level introduction to Minimum Anti-Collusion Infrastructure (MACI)
+sidebar_label: What is MACI?
+sidebar_position: 1
+---
+
+# Welcome to MACI
+
+![MACI card](/img/maci-card.png)
+
+## What is MACI?
+
+**Minimal Anti-Collusion Infrastructure (MACI)** is an open-source public good that serves as infrastructure for private on-chain voting.
+
+MACI 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. A common problem among today’s on-chain voting (or public good funding) processes is how easy it is to bribe voters into voting for a particular option. Since all transactions on the blockchain are public by default, without MACI, voters can easily prove to the briber which option they voted for and therefore receive the bribe rewards.
+
+MACI counters this problem by using encryption and zero-knowledge proofs (zk-SNARKs) to hide how each person voted while still publicly revealing the final result. User’s cannot prove which option they voted for, and therefore bribers cannot reliably trust that a user voted for their preferred option. For example, a voter can tell a briber that they are voting for option A, but in reality they voted for option B. There is no reliable way to prove which option the voter actually voted for, so the briber has less incentive to pay voters to vote their way.
+
+Applications like [clr.fund](https://clr.fund/) or protocols like [Allo](https://github.com/gitcoinco/MACI_QF) build atop MACI to increase
+user privacy and discourage collusion or bribery for public goods funding.
+
+## Why MACI Matters
+
+To understand the promise of on-chain voting and the purpose of MACI, we highly recommend reading [Vitalik's post on blockchain voting](https://vitalik.eth.limo/general/2021/05/25/voting2.html). He provides an overview of the incredible potential of e-voting and why blockchains are an excellent technology to implement e-voting solutions on top of.
+
+Below we attempt to summarize some of the points laid out in that post:
+
+### Security requirements of a voting system
+
+Any voting system requires a few crucial security properties in order to be trusted by users:
+
+- **Correct execution**: the result (tally of votes) must be correct, and the result must be guaranteed by a transparent process (so that everyone is convinced that the result is correct)
+- **Censorship resistance**: anyone eligible to vote should be able to vote, and it should not be possible to interfere with anyone's attempt to vote or to prevent anyone’s vote from being counted
+- **Privacy:** you should not be able to tell which candidate someone specific voted for, or even if they voted at all
+- **Coercion resistance:** you should not be able to prove to someone else how you voted, even if you want to
+
+### Voting systems
+
+Looking at various approaches to implement a voting system, we can see how they compare across these properties.
+
+#### In-person voting systems
+
+In short, it's hard to know for sure how current voting systems operate. Governments and corporations spend lots of resources on their systems and processes in an attempt to ensure their integrity, but ultimately neither the systems nor the processes are fully auditable, so we must trust that these security properties are being enforced.
+
+|                       | In-person |
+| --------------------- | --------- |
+| Correct execution     | 🤷‍♂️        |
+| Censorship resistance | 🤷‍♂️        |
+| Privacy               | 🤷‍♂️        |
+| Collusion resistance  | 🤷‍♂️        |
+
+#### Blockchain voting systems
+
+Blockchains provide two key properties: correct execution and censorship resistance. In terms of execution, the blockchain accepts inputs (transaction) from users, correctly processes them according to some pre-defined rules, and returns the correct output. No one is able to change the rules. Any user that wants to send a transaction and is willing to pay a high enough fee can send the transaction and expect to see it quickly included on-chain.
+
+By default, however, Blockchain voting applications face challenges. Ethereum, like most blockchains, is completely transparent - all transaction data is public, so there is no privacy for voters or their votes. This makes bribery very easy as a result: someone can easily show a transaction receipt that proves how they voted. In some cases, bribery can be completely automated via smart contracts to make collusion entirely trustless.
+
+|                       | In-person | Ethereum |
+| --------------------- | --------- | -------- |
+| Correct execution     | 🤷‍♂️        | ✅       |
+| Censorship resistance | 🤷‍♂️        | ✅       |
+| Privacy               | 🤷‍♂️        | ❌       |
+| Collusion resistance  | 🤷‍♂️        | ❌       |
+
+#### Blockchain voting systems (with ZKPs)
+
+Enter zero-knowledge proofs (ZKPs), which when combined with blockchains like Ethereum, can enable private on-chain voting but maintain public on-chain results that are verifiable by anyone (including smart contracts). Vote tallying takes place off-chain but ZKPs are submitted and verified on-chain, which guarantees votes are counted correctly without revealing the individual votes.
+
+|                       | In-person | Ethereum | Ethereum w/ ZK |
+| --------------------- | --------- | -------- | -------------- |
+| Correct execution     | 🤷‍♂️        | ✅       | ✅             |
+| Censorship resistance | 🤷‍♂️        | ✅       | ✅             |
+| Privacy               | 🤷‍♂️        | ❌       | ✅             |
+| Collusion resistance  | 🤷‍♂️        | ❌       | ✅             |
+
+This, in essence, is why MACI exists. By combining these technologies in novel ways, we believe we can achieve all the core security properties that a voting system must have.
+
+## Features
+
+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.                             |
+
+Under the hood, MACI uses Ethereum smart contracts, ECDH encryption, and zero-knowledge proofs.
+It inherits security and uncensorability from the underlying Ethereum
+blockchain, ensures unforgeability via asymmetric encryption, and achieves
+collusion resistance, privacy, and correct execution via zk-SNARK proofs.
+
+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. Although MACI can provide collusion resistance only if the coordinator is honest, a dishonest coordinator can neither censor nor tamper with its execution.
+
+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 v2.0.0 release post](/blog/2024-v2).
+
+## Background
+
+MACI was originally proposed by Vitalik Buterin in [this ethresear.ch
+post](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) and has been maintained and improved since thanks to support from the Ethereum Foundation. For a general overview, the history and the importance of MACI, see [Release Announcement: MACI 1.0](/blog/maci-1-0-release) by Wei Jie, one of the creators. He also created a helpful [overview of MACI video](https://www.youtube.com/watch?v=sKuNj_IQVYI). Kyle Charbonnet wrote a great [Technical Introduction to MACI 1.0](/blog/maci-1-0-technical-introduction) that provides a walkthrough on how MACI operates.
+
+## Credits
+
+MACI is a public good infrastructure that is supported by the [Ethereum Foundation](https://ethereum.foundation/) within [Privacy & Scaling Explorations (PSE)](https://pse.dev/). It's also continuously improved by our open source community! Many people have contributed to MACI, but below are some notable contributors.
+
+**[MACI v1.0](/blog/maci-1-0-release) was originally developed by:**
+
+- [Barry WhiteHat](https://github.com/barryWhiteHat)
+- [Cory Dickson](https://github.com/corydickson)
+- [Chih-Cheng Liang](https://twitter.com/ChihChengLiang)
+- [Han Jian](https://han0110.github.io/)
+- [Kendrick Tan](https://kndrck.co/)
+- [Kirill Goncharov](https://github.com/xuhcc)
+- [Kobi Gurkan](http://kobi.one/)
+- [Koh Wei Jie](https://kohweijie.com)
+- [Samuel Gosling](https://twitter.com/xGozzy)
+
+**[MACI v1.1.1](/blog/maci-v1-1-1-release) was primarily developed by:**
+
+- [ctrlc03](https://github.com/ctrlc03)
+- [chaosma](https://github.com/chaosma)
+- [baumstern](https://github.com/baumstern)
+- [daodesigner](https://github.com/daodesigner)
+- [0xjei](https://github.com/0xjei)
+
+**Currently, MACI (v1.2.0 and beyond) is maintained and continuously improved by a core development team:**
+
+- [ctrlc03](https://github.com/ctrlc03)
+- [samajammin](https://github.com/samajammin)
+- [0xmad](https://github.com/0xmad)
+- [kittybest](https://github.com/kittybest)
+- [crisgarner](https://github.com/crisgarner)
+
+Our core team continues to work on improving the protocol and its documentation with help from our open source community.
+
+:::info
+If you are using one of the previous versions of MACI, see the [MACI v1.2](/docs/v1.2/introduction) documentation.
+:::

package/versioned_docs/version-v2.x/processes/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Processes",
+  "position": 11
+}

package/versioned_docs/version-v2.x/processes/ci-pipeline.md

@@ -0,0 +1,38 @@
+---
+title: CI Pipeline
+description: Introduction to how MACI's CI works
+sidebar_label: CI
+sidebar_position: 2
+---
+
+# Continuous Integration (CI) Pipeline
+
+CI (Continuous Integration) pipeline is an automated workflow to ensure that software is always in a working state. An event like opening a pull request causes a pipeline to run. The pipeline consists of an automated build process and a suite of automated tests (See [Testing](https://pse.dev/docs/testing) for more details).
+
+![cicd-maci drawio-7](https://user-images.githubusercontent.com/1610146/185962260-091cd952-5444-44f3-89e3-be64e81d4c21.png)
+
+## Pipeline Triggers
+
+### Commit to Main Branch
+
+Each commit (i.e. a merged PR) to the main branch triggers the pipeline. The pipeline creates packages that can be deployed to any environment. Packages are uploaded to an artifact repository (e.g. npm).
+
+![cicd-maci drawio-12](https://user-images.githubusercontent.com/1610146/183404579-8bcb76fe-34b6-4748-a5ae-e2e4b010bd86.png)
+
+### Pull Request (PR)
+
+When a pull request has been created (or updated), it triggers the PR pipeline. It gives the reviewer confidence that the software works as expected with the introduced code changes.
+
+![cicd-maci drawio-9](https://user-images.githubusercontent.com/1610146/183391880-d3a20f29-2708-4d72-988d-4781c0396e48.png)
+
+### Nightly
+
+Nightly build runs every midnight. It is to ensure that all required dependencies are present and to show no bugs have been introduced.
+
+![cicd-maci drawio-11](https://user-images.githubusercontent.com/1610146/183404455-cc2aaace-fe52-40f4-b5e4-3c852c5ff516.png)
+
+### Tag Push
+
+When a tag has been pushed, it triggers a release pipeline. It will draft a release note with an auto-generated changelog and publish npm package(s).
+
+![cicd-maci drawio-5](https://user-images.githubusercontent.com/1610146/185958513-51dadaf1-7f72-404b-b482-149b91edcaab.png)

package/versioned_docs/version-v2.x/processes/versioning.md

@@ -0,0 +1,94 @@
+---
+title: MACI versioning and release process
+description: How MACI's versioning and release process works
+sidebar_label: MACI versioning
+sidebar_position: 1
+---
+
+# MACI versioning and release process
+
+This document outlines the approach to versioning and releasing the MACI project. The primary goal here is to set clear expectations and provide a consistent user experience for developers integrating MACI and its packages.
+
+## MACI code
+
+MACI code consists 3 core parts: Circom circuits, Solidity contracts and JS (TS) libraries, from which we release a total of 7 NPM packages. See the [codebase overview](/docs/overview) for more details.
+
+## MACI versioning
+
+MACI follows the [Semantic Versioning Specification (SemVer)](https://semver.org/).
+
+All MACI packages are organized in our monorepo and follow a global release approach, meaning that all packages have the same version.
+
+Currently, MACI core team manually decides when to release and what the version should be. Packages are released [automatically via CI](https://github.com/privacy-scaling-explorations/maci/blob/dev/.github/workflows/release.yml) when a new tag is created in GitHub. [You can view our releases and tags in GitHub](https://github.com/privacy-scaling-explorations/maci/releases).
+
+## MACI Release Process
+
+To release a new version of MACI, follow these steps:
+
+:::warning
+Version number '1.2.3' is used here as an example. You should replace the version number '1.2.3' with the version number you are planning to release
+:::
+
+1. Verify that tests have passed on GitHub Actions
+
+2. Clone maci:
+
+```
+git clone https://github.com/privacy-scaling-explorations/maci
+```
+
+3. Switch to the `dev` branch:
+
+```
+git checkout dev
+```
+
+4. Install required dependencies:
+
+```
+pnpm install
+```
+
+5. Run `lerna version` to update CHANGELOG and version numbers of sub-packages:
+
+```
+pnpm exec lerna version --no-push --no-git-tag-version --conventional-commits 1.2.3
+```
+
+6. Commit changes:
+
+```
+git commit --message "chore(release): publish 1.2.3"
+```
+
+7. Push changes and create a pull request
+
+After the pull request has been merged:
+
+8. Retrieve merged commit
+
+9. Add a tag:
+
+```
+git tag --sign v1.2.3 --message v1.2.3
+```
+
+10. Publish tag:
+
+```
+git push v1.2.3
+```
+
+Once the tag is pushed, GitHub Actions will automatically publish the packages to npm.js and create a release on GitHub.
+
+---
+
+The following packages will be published on NPM:
+
+- [`@maci-circuits`](https://www.npmjs.com/package/maci-circuits)
+- [`@maci-contracts`](https://www.npmjs.com/package/maci-contracts)
+- [`@maci-cli`](https://www.npmjs.com/package/maci-cli)
+- [`@maci-core`](https://www.npmjs.com/package/maci-core)
+- [`@maci-crypto`](https://www.npmjs.com/package/maci-crypto)
+- [`@maci-domainobjs`](https://www.npmjs.com/package/maci-domainobjs)
+- [`@maci-integrationtests`](https://www.npmjs.com/package/maci-integrationtests)

package/versioned_docs/version-v2.x/resources.md

@@ -0,0 +1,33 @@
+---
+title: Resources
+description: A collection of resources for better understanding MACI
+sidebar_label: Resources
+sidebar_position: 13
+---
+
+## Articles
+
+- [ethresear](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) - Vitalik Buterin 05/2019
+- [MACI Anonymization](https://ethresear.ch/t/maci-anonymization-using-rerandomizable-encryption/7054) - Kobi Gurkan 03/2020
+- [Release Announcement: MACI 1.0](/blog/maci-1-0-release) - Koh Wei Jie 05/2020
+- [Technical Introduction to MACI 1.0](/blog/maci-1-0-technical-introduction) - Kyle Charbonnet 01/2022
+- [MACI v1.1.1 Release](/blog/maci-v1-1-1-release) - ctrlc03 && chaosma 01/2023
+- [MACI v1.2.0 release post](/blog/maci-v1-2-0-release) - ctrlc03 02/2024
+- [MACI v2.0.0 release post](/blog/2024-v2) - ctrlc03 08/2024
+- [Getting Started With MACI](https://medium.com/@bbaraona/getting-started-with-maci-5cc145d00e04) - Benjamin Barahona 12/04/2024
+
+## Videos
+
+- [Overview of MACI](https://www.youtube.com/watch?v=sKuNj_IQVYI) - Koh Wei Jie 05/2020
+- [Making sense of MACI](https://www.youtube.com/watch?v=ooxgPzdaZ_s) - Koh Wei Jie 08/2020
+- [MACI on ZKPodcast](https://www.youtube.com/watch?v=f9nUGPD5I3o) - Koh Wei Jie 12/2020
+- [Anonymity in MACI](https://www.youtube.com/watch?v=X54LaXfJTn4) - Marija Mikić 07/2023
+- [Seeing like a Voting](https://youtu.be/euhugXsTUgY?si=jNhqmvFYD9F0r-tB) - Daehyun 11/2023
+- [MACI - Private Voting](https://www.youtube.com/watch?v=85bZwcQIgEo&t=1382s) - ctrlc03 03/2024
+- [Construyendo votaciones privadas onchain con MACI](https://www.youtube.com/watch?v=3u5VJJsKLfg) - Crisgarner 03/2024
+- [MACI - Starting From Scratch](https://www.youtube.com/watch?v=qVuhWlHnQF0) - Doris Chan 03/2024
+- [MACI Workshop](https://www.youtube.com/watch?v=AimgqnMjG0o) - ctrlc03 04/2024
+- [MACI Starter Kit Demo](https://www.youtube.com/watch?v=pYoBLLtVEoI&t=1s) - Yash 05/2024
+- [MACI Tutorial Deploying Contracts and Subgraph](https://www.youtube.com/watch?v=-QA0VB9EUMk) - Crisgarner 09/2024
+- [MACI Tutorial Frontend Deployment 🚀](https://www.youtube.com/watch?v=q0yS8RfwDcw) - Crisgarner 09/2024
+- [Finalizing a MACI Round](https://www.youtube.com/watch?v=nlS3hOC0ljw) - Crisgarner 09/2024

package/versioned_docs/version-v2.x/security/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Security",
+  "position": 8
+}