@maci-protocol/website 0.0.0-ci.00107eb

package/versioned_docs/version-v3.x/guides/subgraph.md

@@ -0,0 +1,79 @@
+---
+title: Subgraph Deployment
+description: How to deploy a MACI Subgraph
+sidebar_label: Subgraph Deployment
+sidebar_position: 1
+---
+
+# Subgraph Deployment
+
+In some instances like a frontend you might need to deploy a subgraph, in the MACI repository you can find the configuration to deploy a subgraph on The Graph Network or Alchemy Subgraphs.
+
+:::important
+While the free plan of The Graph and Alchemy can work well, it's recommended to use a paid plan for production.
+:::
+
+## Configuration
+
+Head to the subgraph folder in the app folder.
+
+```bash
+cd apps/subgraph
+```
+
+Edit the `network.json` file in the `config` folder. Adding the network it was deployed, the MACI contract and the block where it was deployed.
+
+```json
+{
+  "network": "optimism-sepolia",
+  "maciContractAddress": "0xD18Ca45b6cC1f409380731C40551BD66932046c3",
+  "maciContractStartBlock": 11052407
+}
+```
+
+:::note
+See the supported networks of The Graph **[here](https://thegraph.com/docs/en/developing/supported-networks/)**.
+:::
+
+Create a subgraph in [the graph studio](https://thegraph.com/studio/) and name it `maci-subgraph`.
+
+## The Graph Deployment
+
+The first thing you need to do is to copy the `key` in subgraph studio dashboard and run the following command to authenticate:
+
+```bash
+graph auth --studio {key}
+```
+
+Then run the following commands to build and deploy the subgraph:
+
+```bash
+pnpm run build && \
+pnpm run deploy
+```
+
+:::important
+The `pnpm run deploy` command uses `maci-subgraph` as the subgraph name by default, but if you named your subgraph differently (e.g. maci-graph, my-graph, etc.), please change the command to `graph deploy --node https://api.studio.thegraph.com/deploy/ your_subgraph_name`
+:::
+
+## Alchemy Deployment
+
+Deploying to the Alchemy subgraph service requires some changes to the `subgraph.template.yaml` file located in the `templates` folder. You need to remove the following keys:
+
+```yaml
+indexerHints:
+  prune: auto
+```
+
+Now you can run the deploy command with some minor changes:
+
+```bash
+graph deploy SUBGRAPH_NAME \
+  --version-label VERSION \
+  --node https://subgraphs.alchemy.com/api/subgraphs/deploy \
+  --deploy-key API_KEY
+```
+
+:::note
+In order to get a subgraph deploy key for alchemy, head to the subgraph dashboard section and select `add subgraph` and pick `Deploy a New Subgraph` here you will see the deploy key.
+:::

package/versioned_docs/version-v3.x/guides/testing/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Testing",
+  "position": 7
+}

package/versioned_docs/version-v3.x/guides/testing/testing-in-detail.md

@@ -0,0 +1,191 @@
+---
+title: MACI Testing in Detail
+description: How MACI tests work in detail
+sidebar_label: Testing in detail
+sidebar_position: 2
+---
+
+# Testing in detail
+
+This doc expands on our [introduction to testing](/docs/guides/testing/testing-introduction) doc and explains how MACI tests work in greater detail. This information should be used by MACI's maintainers as well as contributors.
+
+## Automated Tests
+
+### Integration Tests
+
+Integration tests follow a similar fashion of the e2e tests, though they also ensure that the tally results are as expected.
+
+Currently, tests are defined using a JSON file, here is one example:
+
+```json
+{
+  "name": "Happy path",
+  "description": "Full tree, 4 batches, no bribers",
+  "numVotesPerUser": 1,
+  "numUsers": 15,
+  "expectedTally": [15, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
+  "expectedSpentVoiceCredits": [15, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
+  "expectedTotalSpentVoiceCredits": 15
+}
+```
+
+This test will generate 15 signups (as expressed in `numUsers`), and submit one vote (`numVotesPerUser`) for each of the users. As we did not provide any vote detail, it will use the default: `weight = 1`, `option = 0` for all voters. This will result of course in a tally result of 15 for option 0, and 0 for all other options.
+
+Finally, the whole process of merging the state and message trees is performed, proofs are generated and the tally result is verified against the expected result.
+
+#### How to implement a new test case
+
+To add a new test case, it is quite simple. You can amend the `testing/ts/__tests__/data/suites.json` file and add your test declaration in there.
+
+```json
+{
+  "name": "4 voters 1 vote per user",
+  "description": "has correct results",
+  "numUsers": 4,
+  "numVotesPerUser": 1,
+  "votes": {
+    "0": {
+      "0": { "voteOptionIndex": 0, "voteWeight": 1, "valid": true }
+    },
+    "1": {
+      "0": { "voteOptionIndex": 0, "voteWeight": 1, "valid": true }
+    },
+    "2": {
+      "0": { "voteOptionIndex": 0, "voteWeight": 1, "valid": true }
+    },
+    "3": {
+      "0": { "voteOptionIndex": 0, "voteWeight": 1, "valid": true }
+    }
+  },
+  "expectedTally": [4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
+  "expectedSpentVoiceCredits": [4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
+  "expectedTotalSpentVoiceCredits": 4
+}
+```
+
+Let's look at the fields in detail:
+
+- `name`: the name of the test case
+- `description`: a description of the test case
+- `numUsers`: the number of users to generate
+- `numVotesPerUser`: the number of votes to generate for each user
+- `votes`: the votes to generate. This is an object where the key is the user index, and the value is another object where the key is the message index, and the value is the vote details. If you do not provide any vote details, the default will be used: `weight = 1`, `option = 0` for all voters.
+- `expectedTally`: the expected tally result for each vote option (in order)
+- `expectedSpentVoiceCredits`: the expected spent voice credits for each vote option (in order)
+- `expectedTotalSpentVoiceCredits`: the expected total spent voice credits
+
+As an example, let's try to implement a test given the following criteria:
+
+1. We want 10 users to signup
+2. We want each user to publish a different vote
+3. We want to verify that the tally result is as expected
+
+```json
+{
+  "name": "10 Users test",
+  "description": "Should signup 10 users, submit 10 votes and tally the results",
+  "numUsers": 10,
+  "numVotesPerUser": 1,
+  "votes": {
+    "0": {
+      "0": { "voteOptionIndex": 0, "voteWeight": 5 }
+    },
+    "1": {
+      "0": { "voteOptionIndex": 0, "voteWeight": 9 }
+    },
+    "2": {
+      "0": { "voteOptionIndex": 5, "voteWeight": 3 }
+    },
+    "3": {
+      "0": { "voteOptionIndex": 3, "voteWeight": 2 }
+    },
+    "4": {
+      "0": { "voteOptionIndex": 0, "voteWeight": 1 }
+    },
+    "5": {
+      "0": { "voteOptionIndex": 9, "voteWeight": 1 }
+    },
+    "6": {
+      "0": { "voteOptionIndex": 4, "voteWeight": 7 }
+    },
+    "7": {
+      "0": { "voteOptionIndex": 7, "voteWeight": 5 }
+    },
+    "8": {
+      "0": { "voteOptionIndex": 3, "voteWeight": 10 }
+    },
+    "9": {
+      "0": { "voteOptionIndex": 8, "voteWeight": 2 }
+    }
+  },
+  "expectedTally": [15, 0, 0, 12, 7, 3, 0, 5, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0],
+  "expectedSpentVoiceCredits": [107, 0, 0, 104, 49, 9, 0, 25, 4, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
+  "expectedTotalSpentVoiceCredits": 299
+}
+```
+
+**Why expectedTally as above**
+
+[(5 + 9 + 1), 0, 0, (2 + 10), 7, 3, 0, 5, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0] -> [15, 0, 0, 12, 7, 3, 0, 5, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0]
+
+**Why 299 voice credits spent**
+
+- 5 ** 2 + 9 ** 2 + 3 ** 2 + 2 ** 2 + 1 ** 2 + 1 ** 1 + 7 ** 2 + 5 ** 2 + 10 ** 2 + 2 ** 2 = 25 + 81 + 9 + 4 + 1 + 1 + 49 + 25 + 100 + 4 = 299
+
+**Why expectedSpentVoiceCredits as above**
+
+[(25 + 81 + 1), 0, 0, (4 + 100), 49, 0, 25, 4, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0] -> [107, 0, 0, 104, 49, 0, 25, 4, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
+
+#### MACI keys integration tests
+
+Another test file which is found inside the integration tests folder is the `maciKeys.test.ts` file. This file contains a number of tests that are used to verify that the MACI keys work as expected. These tests are written in TypeScript and use the `mocha` and `chai` frameworks.
+
+They are testing that between the `contracts`, `domainobjs` and `crypto` packages, the MACI keys are working correctly, and are serialized/deserialized as expected. This is particularly important to test due to different data formats for keys, especially when parsed from the smart contract events.
+
+### Contract tests
+
+Within the contracts folder, there are a number of tests that are used to verify that the contracts work as expected. These tests are written in TypeScript and use the `hardhat` framework.
+
+These tests interact with all other packages, such as crypto, domainobjs and core, where mock data comes from. Their main goal is to ensure that the smart contracts have the correct parameters when deployed, privileged functions cannot be called by non-privileged users, and that the contract state is as expected after a series of operations.
+
+### Circuits tests
+
+Within the circuits folder, there are a number of tests that are used to verify that the circuits work as expected. These tests are written in TypeScript and use the `circom_tester` (which runs on top of `mocha` and `chai`).
+
+These tests often use mock data from the `core` package. For instance, when testing the `processMessages` circuit, we are required to generate the parameters from the `core` packing, using the `Poll:processMessages` function. The same applies to vote tallying, where we need the `Poll:tally` function to be run first with mock users and vote messages.
+
+All of the tests run using test parameters, usually `10, 20, 2`, aside from the tests inside: [`ceremonyParam`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/ts/__tests__/CeremonyParams.test.ts) which use the parameters of the latest MACI ceremony. More details on the trusted setup can be found [here](/docs/security/trusted-setup).
+
+### Core
+
+The core package contains a number of tests that are used to verify that the core functions work as expected. These tests are written in TypeScript and use the `mocha` and `chai` frameworks.
+
+These tests interact with the crypto and dombinobjs packages, where mock data comes from. Their main goal is to ensure that the core functions work as expected, and that the state is as expected after a series of operations.
+
+Currently, there is a blend of e2e and unit tests, where e2e tests are used to verify that the entire MACI local processing works as expected (users signup, publish votes, messages are processed and finally these votes are tallied). Unit tests on the other hand are used to verify that the core functions work as expected, such as `MessageProcessor` and `VoteTally`. You will find them in separate files, with e2e being [here](https://github.com/privacy-scaling-explorations/maci/blob/main/core/ts/__tests__/e2e.test.ts) and unit tests in the other files.
+
+### Domainobjs/Crypto tests
+
+These tests are used to verify that MACI's primitives such as private keys work as expected. They are written in TypeScript and use the `mocha` and `chai` frameworks.
+
+## "Manual" Testing
+
+To ensure that the MACI stack works as expected, without having to run the entire test suite (or even just the e2e tests), there is a [bash script](https://github.com/privacy-scaling-explorations/maci/blob/main/packages/contracts/testScriptLocalhost.sh) inside the contracts folder which can be used.
+
+This script contains a number of actions which touch all of the parts of MACI, and resemble exactly what other e2e tests do.
+
+Looking at this in more details we do the following:
+
+1. Deploy a `VerifyingKeysRegistry` contract
+2. Set the verification keys on this smart contract
+3. Deploy a `MACI` contract (and associated utility contracts)
+4. Deploy a Poll from the MACI contract.
+5. Signup 1 user
+6. Publish 2 messages
+7. Travel in time (local blockchain node) to arrive at the end of the poll
+8. Merge the tree commitments on chain
+9. Generate proofs for the message processing and vote tallying
+10. Update the on chain state
+11. Verify that proofs and tally are correct
+
+The above is the minimum required to ensure that the stack works as expected, as it encompasses actions from both voters and the coordinator.

package/versioned_docs/version-v3.x/guides/testing/testing-introduction.md

@@ -0,0 +1,190 @@
+---
+title: Testing MACI
+description: An introduction on how to test MACI
+sidebar_label: Testing Introduction
+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:tally
+```
+
+This test command will run `Tally.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
+```
+
+To run e2e tests for hardhat tasks for `contracts` using the in-memory hardhat network:
+
+```bash
+pnpm run test:hardhat
+```
+
+You can update the `deploy-config.json` file to change policies or other deployment settings used by the test.
+
+You can enhance test reporting and gas cost estimation by adding the following variables to your `.env` file:
+
+```bash
+# CoinMarkerCap api key for prices (gas reporter)
+COINMARKETCAP_API_KEY=
+# Gas price for gas reporter
+# Allows you to manually specify the gas price (e.g. 3 gwei)
+GAS_REPORTER_PRICE=
+```
+
+These variables are used by `hardhat-gas-reporter` to show cost estimates for gas usage in the test reports.
+
+If you would like to run these E2E tests against a different [supported networks](/docs/supported-networks/), you can override the network like this:
+
+```bash
+pnpm exec hardhat test --network {NETWORK} ./tests/e2e/hardhatTasks.test.ts
+```
+
+### 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, `MessageProcessor` and `VoteTally`.
+
+:::info
+The `MessageProcessor` and `VoteTally` circuits are also provided in a non-quadratic voting (non-QV) and in a full credits voting (full) versions. 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 smart contract tasks require them as part of the JSON configuration file.
+
+For testing purposes you can download the required artifacts using the [`download-zkeys:test`](https://github.com/privacy-scaling-explorations/maci/blob/main/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 ../../zkeys
+```
+
+**for wasm witness generator**
+
+```bash
+pnpm build:circuits-wasm -- --outPath ../../zkeys
+```
+
+**generate zkeys**
+
+```bash
+pnpm setup:zkeys --outPath ../../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 `testing/zkeys` folder.
+:::
+
+### Run CLI tests
+
+You can find the tests in `maci/testing/ts/__tests__`.
+
+To run the tests first start a hardhat node in the background:
+
+```bash
+cd packages/contracts
+pnpm run hardhat &
+cd ../testing/ts
+```
+
+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
+```
+
+To run e2e tests with full credits voting (full):
+
+```bash
+pnpm run test:e2e-full
+```
+
+To run integration tests:
+
+```bash
+pnpm run test:integration
+```

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

@@ -0,0 +1,206 @@
+---
+title: Troubleshooting
+description: How to troubleshoot MACI's failures
+sidebar_label: Troubleshooting
+sidebar_position: 5
+---
+
+# Troubleshooting
+
+## cli: `generateProofs` command failure
+
+### Case: missing `.dat` files
+
+If your logs look like the following, then make sure you have `MessageProcessorQv_10-2-1-2_test.dat` and `VoteTallyQv_10-1-2_test.dat` files in the same directory as your zkeys:
+
+```
+node build/ts/index.js generateProofs -x 0xf204a4Ef082f5c04bB89F7D5E6568B796096735a \
+>     -sk macisk.49953af3585856f539d194b46c82f4ed54ec508fb9b882940cbe68bbc57e59e \
+>     -o 0 \
+>     -r ~/rapidsnark/build/prover \
+>     -wp ./zkeys/MessageProcessorQv_10-2-1-2_test \
+>     -wt ./zkeys/VoteTallyQv_10-1-2_test \
+>     -zp ./zkeys/MessageProcessorQv_10-2-1-2_test.0.zkey \
+>     -zt ./zkeys/VoteTallyQv_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/MessageProcessorQv_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/generateProofs.ts:339:25
+    at step (/home/ubuntu/maci/cli/build/generateProofs.js:33:23)
+    at Object.next (/home/ubuntu/maci/cli/build/generateProofs.js:14:53)
+    at fulfilled (/home/ubuntu/maci/cli/build/generateProofs.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 `generateProofs` 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 `generateProofs` run.
+
+In [core/Poll.ts](https://github.com/privacy-scaling-explorations/maci/blob/main/packages/core/ts/Poll.ts):
+
+```
+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 `generateProofs` 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 `generateProofs` 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 main`) 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 [`VerifyingKeysRegistry` contract](/docs/technical-references/smart-contracts/VerifyingKeysRegistry) 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.
+
+### Proof generation process is killed
+
+If your terminal output ends like this:
+
+```
+[i] Starting to fetch logs from block 8386826
+[i] Generating proofs of message processing...
+[i] Progress: 1 / 1
+[i] Wait until proof generation is finished
+Killed
+ELIFECYCLE  Command failed with exit code 137.
+```
+
+This typically indicates the proof generation process was terminated due to exceeding the system's available memory limit (exit code `137` = SIGKILL by the OS, often due to OOM).
+
+Increase Node.js' memory allocation by setting the `NODE_OPTIONS` environment variable before running the command:
+
+```bash
+export NODE_OPTIONS="--max-old-space-size=4096"
+# You can increase the value further (e.g., 8192 for 8GB) if your system has enough RAM:
+export NODE_OPTIONS="--max-old-space-size=8192"
+```
+
+### Error: Not enough or too many values for input signals
+
+If you see errors like:
+
+```
+Error: Not enough values for input signal currentVoteWeightsPathElements
+at /home/maci/node_modules/.pnpm/circom_runtime@0.1.28/node_modules/circom_runtime/build/main.cjs:513:27
+...
+```
+
+```
+Error: Too many values for input signal ballots
+at /home/maci/node_modules/.pnpm/circom_runtime@0.1.28/node_modules/circom_runtime/build/main.cjs:513:27
+...
+```
+
+This usually happens when the Merkle tree depth configured in your MACI deployment does not match the depth expected by the zkey files used during proof generation.
+To solve this:
+
+- Download the correct zkey files from a trusted source.
+- Verify that the `stateTreeDepth`, `messageTreeDepth`, and `voteOptionTreeDepth` used in your CLI or config match the values used to generate those zkey files.