@maci-protocol/website 0.0.0-ci.e3476db → 0.0.0-ci.eb89f0b

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

@@ -17,12 +17,12 @@ As an example, a [contract](https://github.com/ctrlc03/minimalQF/blob/main/contr
 
 ```javascript
 /// @inheritdoc IMACI
-function signUp(PubKey memory _pubKey, bytes memory _signUpPolicyData) public virtual {
+function signUp(PublicKey memory _publicKey, bytes memory _signUpPolicyData) public virtual {
   // ensure we do not have more signups than what the circuits support
   if (leanIMTData.size >= maxSignups) revert TooManySignups();
 
   // ensure that the public key is on the baby jubjub curve
-  if (!CurveBabyJubJub.isOnCurve(_pubKey.x, _pubKey.y)) {
+  if (!CurveBabyJubJub.isOnCurve(_publicKey.x, _publicKey.y)) {
     revert InvalidPubKey();
   }
 
@@ -31,13 +31,13 @@ function signUp(PubKey memory _pubKey, bytes memory _signUpPolicyData) public vi
   signUpPolicy.enforce(msg.sender, _signUpPolicyData);
 
   // Hash the public key and insert it into the tree.
-  uint256 pubKeyHash = hashLeftRight(_pubKey.x, _pubKey.y);
+  uint256 pubKeyHash = hashLeftRight(_publicKey.x, _publicKey.y);
   uint256 stateRoot = InternalLeanIMT._insert(leanIMTData, pubKeyHash);
 
   // Store the current state tree root in the array
   stateRootsOnSignUp.push(stateRoot);
 
-  emit SignUp(leanIMTData.size - 1, block.timestamp, _pubKey.x, _pubKey.y);
+  emit SignUp(leanIMTData.size - 1, block.timestamp, _publicKey.x, _publicKey.y);
 }
 ```
 
@@ -71,7 +71,7 @@ On the other hand, the Poll contract can be inherited to expand functionality su
 ```javascript
 function joinPoll(
   uint256 _nullifier,
-  PubKey calldata _pubKey,
+  PublicKey calldata _publicKey,
   uint256 _stateRootIndex,
   uint256[8] calldata _proof,
   bytes memory _signUpPolicyData,
@@ -86,7 +86,7 @@ function joinPoll(
   pollNullifiers[_nullifier] = true;
 
   // Verify user's proof
-  if (!verifyJoiningPollProof(_nullifier, _stateRootIndex, _pubKey, _proof)) {
+  if (!verifyJoiningPollProof(_nullifier, _stateRootIndex, _publicKey, _proof)) {
     revert InvalidPollProof();
   }
 
@@ -100,7 +100,7 @@ function joinPoll(
   );
 
   // Store user in the pollStateTree
-  uint256 stateLeaf = hashStateLeaf(StateLeaf(_pubKey, voiceCreditBalance, block.timestamp));
+  uint256 stateLeaf = hashStateLeaf(StateLeaf(_publicKey, voiceCreditBalance, block.timestamp));
 
   uint256 stateRoot = InternalLazyIMT._insert(pollStateTree, stateLeaf);
 
@@ -108,7 +108,7 @@ function joinPoll(
   pollStateRootsOnJoin.push(stateRoot);
 
   uint256 pollStateIndex = pollStateTree.numberOfLeaves - 1;
-  emit PollJoined(_pubKey.x, _pubKey.y, voiceCreditBalance, block.timestamp, _nullifier, pollStateIndex);
+  emit PollJoined(_publicKey.x, _publicKey.y, voiceCreditBalance, block.timestamp, _nullifier, pollStateIndex);
 }
 ```
 

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

@@ -176,7 +176,7 @@ This script contains a number of actions which touch all of the parts of MACI, a
 
 Looking at this in more details we do the following:
 
-1. Deploy a `VkRegistry` contract
+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.

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

@@ -7,14 +7,14 @@ sidebar_position: 5
 
 # Troubleshooting
 
-## cli: `genProofs` command failure
+## cli: `generateProofs` 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 \
+node build/ts/index.js generateProofs -x 0xf204a4Ef082f5c04bB89F7D5E6568B796096735a \
 >     -sk macisk.49953af3585856f539d194b46c82f4ed54ec508fb9b882940cbe68bbc57e59e \
 >     -o 0 \
 >     -r ~/rapidsnark/build/prover \
@@ -38,10 +38,10 @@ 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)
+    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:
@@ -54,7 +54,7 @@ pnpm build:circuits-c -- --outPath ../cli/zkeys
 
 ### 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.
+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
@@ -69,7 +69,7 @@ Error: commitment mismatch
  ELIFECYCLE  Command failed with exit code 1.
 ```
 
-This is because commitments are generated using random salts, thus will differ at each `genProofs` run.
+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/dev/packages/core/ts/Poll.ts):
 
@@ -84,7 +84,7 @@ while (this.sbSalts[this.currentMessageBatchIndex!] === newSbSalt) {
 
 ### 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:
+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.
@@ -130,7 +130,7 @@ TypeError: cannot filter non-indexed parameters; must be null (argument="contrac
 }
 ```
 
-This could happen during running `genProofs` in `cli` package, or running `prove` in `contracts` package.
+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
@@ -144,7 +144,7 @@ Please remember to pull the latest MACI repo updates(`git fetch origin && git pu
 
 ### 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.
+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.

package/versioned_docs/version-v3.x/quick-start.md

@@ -73,7 +73,7 @@ Currently, the ceremony artifacts work with MACI version up to 2.x
 In order to run MACI polls, a coordinator is required to publish their MACI public key. You will need to generate a MACI keypair, and treat the private key just as your ethereum private keys. Please store them in a safe place as you won't be able to finish a round if you lose access, or if compromised a bad actor could decrypt the vote and publish them online. You can generate a new key pair using maci-cli by running the following command in the root of the project:
 
 ```bash
-pnpm run genMaciKeyPair
+pnpm run generateMaciKeyPair
 ```
 
 ### Set the .env
@@ -131,9 +131,9 @@ For testing we suggest using the **FreeForAlPolicy** as it allows anyone to sign
 | **stateTreeDepth** | Defines how many users the system supports. |
 | **policy**         | Defines which policy to use.                |
 
-#### VkRegistry
+#### VerifyingKeysRegistry
 
-The VkRegistry hold the verifying keys used to verify the proofs, on the zkeys field we define the path to the zero knowledge artifacts we downloaded in the previous steps.
+The VerifyingKeysRegistry hold the verifying keys used to verify the proofs, on the zkeys field we define the path to the zero knowledge artifacts we downloaded in the previous steps.
 
 | Property                | Description                                                                          |
 | ----------------------- | ------------------------------------------------------------------------------------ |
@@ -156,7 +156,7 @@ The recommended values for test keys are: **10-1-2-2-1**. For ceremony keys: **1
 | --------------------------- | ----------------------------------------------------------------- |
 | **pollStartDate**           | Defines when the poll starts in seconds.                          |
 | **pollEndDate**             | Defines how long is going to be the poll in seconds.              |
-| **coordinatorPubkey**       | Defines the coordinator public MACI key.                          |
+| **coordinatorPublicKey**    | Defines the coordinator public MACI key.                          |
 | **useQuadraticVoting**      | Defines if the poll uses quadratic voting or not.                 |
 | **policy**                  | Defines the policy of the poll.                                   |
 | **relayers**                | Defines an array of addresses that are allowed to relay messages. |
@@ -277,7 +277,7 @@ Once the proofs are generated, and results tallied, the results (Tally) are writ
     "salt": "0x24f57b75c227987727c13d1e83409d70478b42bdc12a4a4df8129c72fbaf5aaf",
     "commitment": "0xb4ebe68b0da828c0b978ddee86ba934b8e215499ac766491f236ad85fd606de"
   },
-  "perVOSpentVoiceCredits": {
+  "perVoteOptionSpentVoiceCredits": {
     "tally": [
       "81",
       "0",
@@ -315,4 +315,4 @@ We observe an array named results, which holds the aggregated votes for each opt
 
 The `totalSpentVoiceCredits` object contains the total amount of voice credits spent in the poll. This is the sum of all voice credits spent by all voters, and in quadratic voting, is the sum of the squares of all votes.
 
-The `perVOSpentVoiceCredits` will contain the amount of voice credits spent per vote option. In this case, the first option received 81 voice credits, and every other option received 0 voice credits. This is because there was only one valid vote casted, with a weight of 9. Given the quadratic voting formula, the total amount of voice credits spent is 81.
+The `perVoteOptionSpentVoiceCredits` will contain the amount of voice credits spent per vote option. In this case, the first option received 81 voice credits, and every other option received 0 voice credits. This is because there was only one valid vote casted, with a weight of 9. Given the quadratic voting formula, the total amount of voice credits spent is 81.

package/versioned_docs/version-v3.x/security/audit.md

@@ -38,7 +38,7 @@ We would like to thank the Veridise team for their effort in keeping open source
 
 **Description**
 
-In the template `QuinSelector`, if you want to confirm the input signal index is a valid integer less than 2\*\*3, you should add Num2bits(3) to check it.
+In the template `QuinarySelector`, if you want to confirm the input signal index is a valid integer less than 2\*\*3, you should add Num2bits(3) to check it.
 
 **Code Location**
 
@@ -119,7 +119,7 @@ greaterThan[i].in[1] <== index;
 
 **Description**
 
-In the template `QuinGeneratePathIndices`, the constraints of the `signal n[levels + 1]` don't perform well for division and modulo counting.
+In the template `QuinaryGeneratePathIndices`, the constraints of the `signal n[levels + 1]` don't perform well for division and modulo counting.
 
 **Code Location**
 

package/versioned_docs/version-v3.x/supported-networks/deployed-contracts.md

@@ -7,7 +7,7 @@ sidebar_position: 2
 
 There are a number of MACI's smart contracts which can be re-used by different deployments. These are the following:
 
-- [VkRegistry](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VkRegistry.sol)
+- [VerifyingKeysRegistry](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VerifyingKeysRegistry.sol)
 - [PoseidonHashers](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/crypto/Hasher.sol)
 - [PollFactory](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/PollFactory.sol)
 - [MessageProcessorFactory](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/MessageProcessorFactory.sol)
@@ -29,7 +29,7 @@ cd cli && node build/ts/index.js checkVerifyingKeys -q false -vk 0x74569d524a193
 ```
 
 :::info
-You should change the -vk parameter to the VkRegistry address for the chain you are deploying to. Also you might need to modify the parameters based on the circuit configuration. Please refer to the [circuits page](/docs/technical-references/zk-snark-circuits/setup) for more information. Also you can add `-uq false` if you want to check non quadratic voting keys.
+You should change the -vk parameter to the VerifyingKeysRegistry address for the chain you are deploying to. Also you might need to modify the parameters based on the circuit configuration. Please refer to the [circuits page](/docs/technical-references/zk-snark-circuits/setup) for more information. Also you can add `-uq false` if you want to check non quadratic voting keys.
 :::
 
 ## Contract Addresses

package/versioned_docs/version-v3.x/technical-references/smart-contracts/MACI.md

@@ -62,12 +62,12 @@ This function does the following:
 - hashes the public key and inserts it into the state tree.
 
 ```ts
-function signUp(PubKey memory _pubKey, bytes memory _signUpPolicyData) public virtual {
+function signUp(PublicKey memory _publicKey, bytes memory _signUpPolicyData) public virtual {
   // ensure we do not have more signups than what the circuits support
   if (leanIMTData.size >= maxSignups) revert TooManySignups();
 
   // ensure that the public key is on the baby jubjub curve
-  if (!CurveBabyJubJub.isOnCurve(_pubKey.x, _pubKey.y)) {
+  if (!CurveBabyJubJub.isOnCurve(_publicKey.x, _publicKey.y)) {
     revert InvalidPubKey();
   }
 
@@ -76,13 +76,13 @@ function signUp(PubKey memory _pubKey, bytes memory _signUpPolicyData) public vi
   signUpPolicy.register(msg.sender, _signUpPolicyData);
 
   // Hash the public key and insert it into the tree.
-  uint256 pubKeyHash = hashLeftRight(_pubKey.x, _pubKey.y);
+  uint256 pubKeyHash = hashLeftRight(_publicKey.x, _publicKey.y);
   uint256 stateRoot = InternalLeanIMT._insert(leanIMTData, pubKeyHash);
 
   // Store the current state tree root in the array
   stateRootsOnSignUp.push(stateRoot);
 
-  emit SignUp(leanIMTData.size - 1, block.timestamp, _pubKey.x, _pubKey.y);
+  emit SignUp(leanIMTData.size - 1, block.timestamp, _publicKey.x, _publicKey.y);
 }
 ```
 
@@ -156,5 +156,5 @@ Polls require the following information:
 - `voteOptions`: the number of vote options for the poll
 
 :::info
-Please be advised that the number of signups in the MACI contract (number of leaves in the merkle tree holding MACI's state) considers the initial zero leaf as one signup. For this reason, when accounting for the real users signed up to MACI, you should subtract one from the value returned from the `numSignUps` function.
+Please be advised that the number of signups in the MACI contract (number of leaves in the merkle tree holding MACI's state) considers the initial zero leaf as one signup. For this reason, when accounting for the real users signed up to MACI, you should subtract one from the value returned from the `totalSignups` function.
 :::

package/versioned_docs/version-v3.x/technical-references/smart-contracts/Poll.md

@@ -26,7 +26,7 @@ The `joinPoll` function looks as follows:
   /// @inheritdoc IPoll
   function joinPoll(
     uint256 _nullifier,
-    PubKey calldata _pubKey,
+    PublicKey calldata _publicKey,
     uint256 _stateRootIndex,
     uint256[8] calldata _proof,
     bytes memory _signUpPolicyData,
@@ -41,7 +41,7 @@ The `joinPoll` function looks as follows:
     pollNullifiers[_nullifier] = true;
 
     // Verify user's proof
-    if (!verifyJoiningPollProof(_nullifier, _stateRootIndex, _pubKey, _proof)) {
+    if (!verifyJoiningPollProof(_nullifier, _stateRootIndex, _publicKey, _proof)) {
       revert InvalidPollProof();
     }
 
@@ -55,7 +55,7 @@ The `joinPoll` function looks as follows:
     );
 
     // Store user in the pollStateTree
-    uint256 stateLeaf = hashStateLeaf(StateLeaf(_pubKey, voiceCreditBalance, block.timestamp));
+    uint256 stateLeaf = hashStateLeaf(StateLeaf(_publicKey, voiceCreditBalance, block.timestamp));
 
     uint256 stateRoot = InternalLazyIMT._insert(pollStateTree, stateLeaf);
 
@@ -63,7 +63,7 @@ The `joinPoll` function looks as follows:
     pollStateRootsOnJoin.push(stateRoot);
 
     uint256 pollStateIndex = pollStateTree.numberOfLeaves - 1;
-    emit PollJoined(_pubKey.x, _pubKey.y, voiceCreditBalance, block.timestamp, _nullifier, pollStateIndex);
+    emit PollJoined(_publicKey.x, _publicKey.y, voiceCreditBalance, block.timestamp, _nullifier, pollStateIndex);
   }
 ```
 
@@ -72,7 +72,7 @@ The `joinPoll` function looks as follows:
 The `publishMessage` function looks as follows:
 
 ```ts
-function publishMessage(Message calldata _message, PubKey calldata _encPubKey) public virtual isOpenForVoting {
+function publishMessage(Message calldata _message, PublicKey calldata _encPubKey) public virtual isOpenForVoting {
   // check if the public key is on the curve
   if (!CurveBabyJubJub.isOnCurve(_encPubKey.x, _encPubKey.y)) {
     revert InvalidPubKey();
@@ -84,7 +84,7 @@ function publishMessage(Message calldata _message, PubKey calldata _encPubKey) p
   }
 
   // compute current message hash
-  uint256 messageHash = hashMessageAndEncPubKey(_message, _encPubKey);
+  uint256 messageHash = hashMessageAndPublicKey(_message, _encPubKey);
 
   // update current message chain hash
   updateChainHash(messageHash);
@@ -96,7 +96,7 @@ function publishMessage(Message calldata _message, PubKey calldata _encPubKey) p
 The `publishMessageBatch` function looks as follows:
 
 ```ts
-function publishMessageBatch(Message[] calldata _messages, PubKey[] calldata _encPubKeys) public virtual {
+function publishMessageBatch(Message[] calldata _messages, PublicKey[] calldata _encPubKeys) public virtual {
   if (_messages.length != _encPubKeys.length) {
     revert InvalidBatchLength();
   }

package/versioned_docs/version-v3.x/technical-references/smart-contracts/Tally.md

@@ -16,14 +16,14 @@ This contract should be deployed alongside a `Poll`, with the the constructor ac
 ```ts
   constructor(
     address _verifier,
-    address _vkRegistry,
+    address _verifyingKeysRegistry,
     address _poll,
     address _mp,
     address _tallyOwner,
     Mode _mode
   ) payable {
     verifier = IVerifier(_verifier);
-    vkRegistry = IVkRegistry(_vkRegistry);
+    vkRegistry = IVkRegistry(_verifyingKeysRegistry);
     poll = IPoll(_poll);
     messageProcessor = IMessageProcessor(_mp);
     mode = _mode;

package/versioned_docs/version-v3.x/technical-references/smart-contracts/VkRegistry.md

@@ -1,15 +1,15 @@
 ---
-title: VkRegistry Smart Contract
-description: VkRegistry smart contract
-sidebar_label: VkRegistry
+title: VerifyingKeysRegistry Smart Contract
+description: VerifyingKeysRegistry smart contract
+sidebar_label: VerifyingKeysRegistry
 sidebar_position: 8
 ---
 
 :::info
-Code location: [VkRegistry.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VkRegistry.sol)
+Code location: [VerifyingKeysRegistry.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VerifyingKeysRegistry.sol)
 :::
 
-The VkRegistry is a contract that holds the verifying keys for the zk-SNARK circuits. It holds four different sets of keys:
+The VerifyingKeysRegistry is a contract that holds the verifying keys for the zk-SNARK circuits. It holds four different sets of keys:
 
 - `processVks` - The keys for the processMessages circuit
 - `tallyVks` - The keys for the tallyVotes circuit

package/versioned_docs/version-v3.x/technical-references/zk-snark-circuits/joinPoll.md

@@ -21,8 +21,8 @@ Users need to provide a valid proof to the Poll smart contract to join a poll, a
 
 | Input signal           | Description                                                                                                                                                                        |
 | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `privKey`              | The user's private key                                                                                                                                                             |
-| `pollPubKey`           | The poll's public key                                                                                                                                                              |
+| `privateKey`           | The user's private key                                                                                                                                                             |
+| `pollPublicKey`        | The poll's public key                                                                                                                                                              |
 | `siblings`             | The siblings for the merkle tree inclusion proof                                                                                                                                   |
 | `indices`              | The indices for the merkle tree inclusion proof                                                                                                                                    |
 | `nullifier`            | The nullifier                                                                                                                                                                      |
@@ -44,9 +44,8 @@ Users will use this circuit to anonymously prove that they joined a poll. This c
 
 | Input signal           | Description                                                                                                                                                                        |
 | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `privKey`              | The user's private key                                                                                                                                                             |
+| `privateKey`           | The user's private key                                                                                                                                                             |
 | `voiceCreditsBalance`  | The user's initial voice credits balance                                                                                                                                           |
-| `joinTimestamp`        | The timestamp of when the user joined the poll                                                                                                                                     |
 | `pathElements`         | The path elements for the merkle tree inclusion proof                                                                                                                              |
 | `pathIndices`          | The path indices for the merkle tree inclusion proof                                                                                                                               |
 | `stateRoot`            | The MACI state tree root                                                                                                                                                           |

package/versioned_docs/version-v3.x/technical-references/zk-snark-circuits/processMessages.md

@@ -7,7 +7,7 @@ sidebar_position: 3
 
 [**Repo link**](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core)
 
-This circuit allows the coordinator to prove that they have correctly processed each message in reverse order, in a consecutive batch of 5 ^ msgBatchDepth messages to the respective state leaf within the state tree. Coordinators would use this circuit to prove correct execution at the end of each Poll.
+This circuit allows the coordinator to prove that they have correctly processed each message in reverse order, in a consecutive batch of 5 ^ messageBatchDepth messages to the respective state leaf within the state tree. Coordinators would use this circuit to prove correct execution at the end of each Poll.
 
 The [`processMessages`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core/qv/processMessages.circom) circuit will try to decrypt the messages, and based on the content of the message, update within itself the trees, to generate a proof that the coordinator's off-chain processing was done correctly. In other words, the circuit takes a final state, an initial state, and the leaves (messages and user signups) - it processes these messages via the different state transitions to finally check that the expected state is correct.
 The pre-requisites for this circuit are:
@@ -36,17 +36,17 @@ A version working with non quadratic voting (non-qv) is also [available](https:/
 
 | Input signal                     | Description                                                                             |
 | -------------------------------- | --------------------------------------------------------------------------------------- |
-| `numSignUps`                     | Number of users that have completed the sign up                                         |
+| `totalSignups`                   | Number of users that have completed the sign up                                         |
 | `index`                          | The batch index of current message batch                                                |
 | `pollEndTimestamp`               | The Unix timestamp at which the poll ends                                               |
-| `msgRoot`                        | The root of the message tree                                                            |
-| `msgs`                           | The batch of messages as an array of arrays                                             |
-| `msgSubrootPathElements`         | As described below                                                                      |
+| `messageRoot`                    | The root of the message tree                                                            |
+| `messages`                       | The batch of messages as an array of arrays                                             |
+| `messageSubrootPathElements`     | As described below                                                                      |
 | `coordinatorPublicKeyHash`       | $\mathsf{poseidon_2}([cPk_x, cPk_y])$                                                   |
 | `newSbCommitment`                | As described below                                                                      |
-| `coordPrivKey`                   | The coordinator's private key                                                           |
+| `coordinatorPrivateKey`          | The coordinator's private key                                                           |
 | `batchEndIndex`                  | The last batch index                                                                    |
-| `encPubKeys`                     | The public keys used to generate shared ECDH encryption keys to encrypt the messages    |
+| `encryptionPublicKeys`           | The public keys used to generate shared ECDH encryption keys to encrypt the messages    |
 | `currentStateRoot`               | The state root before the commands are applied                                          |
 | `currentStateLeaves`             | The state leaves upon which messages are applied                                        |
 | `currentStateLeavesPathElements` | The Merkle path to each incremental state root                                          |
@@ -74,9 +74,9 @@ The salt used to produce `currentSbCommitment` (see above).
 
 The salt used to produce `newSbCommitment` (see above).
 
-##### `msgSubrootPathElements`
+##### `messageSubrootPathElements`
 
-The index of each message in `msgs` is consecutive. As such, in order to prove that each message in `msgs` is indeed a leaf of the message tree, we compute the subtree root of `msgs`, and then verify that the subtree root is indeed a subroot of `msgRoot`.
+The index of each message in `messages` is consecutive. As such, in order to prove that each message in `messages` is indeed a leaf of the message tree, we compute the subtree root of `messages`, and then verify that the subtree root is indeed a subroot of `messageRoot`.
 
 A simplified example using a tree of arity 2:
 
@@ -100,7 +100,7 @@ This method requires fewer circuit constraints than if we verified a Merkle proo
 
 1. That the prover knows the preimage to `currentSbCommitment` (that is, the state root, ballot root, and `currentSbSalt`)
 2. That `maxVoteOptions <= (5 ^ voteOptionTreeDepth)`
-3. That `numSignUps <= (2 ^ stateTreeDepth)`
-4. That `coordinatorPublicKeyHash` is a hash of public key that is correctly derived from `coordPrivKey`
-5. That each message in `msgs` exists in the message tree
+3. That `totalSignups <= (2 ^ stateTreeDepth)`
+4. That `coordinatorPublicKeyHash` is a hash of public key that is correctly derived from `coordinatorPrivateKey`
+5. That each message in `messages` exists in the message tree
 6. That after decrypting and applying each message, in reverse order, to the corresponding state and ballot leaves, the new state root, new ballot root, and `newSbSalt` are the preimage to `newSbCommitment`

package/versioned_docs/version-v3.x/technical-references/zk-snark-circuits/tallyVotes.md

@@ -25,7 +25,7 @@ A version working with non quadratic voting (non-qv) is also [available](https:/
 
 | Input signal                            | Description                                                      |
 | --------------------------------------- | ---------------------------------------------------------------- |
-| `numSignUps`                            | The number of users that signup                                  |
+| `totalSignups`                          | The number of users that signup                                  |
 | `index`                                 | Start index of given batch                                       |
 | `sbCommitment`                          | Described below                                                  |
 | `currentTallyCommitment`                | Described below                                                  |
@@ -72,7 +72,7 @@ $poseidon_3([tc_r, tc_t, tc_p])$
 #### Statements that the circuit proves
 
 1. That the coordinator knows the preimage of `sbCommitment`
-2. That `index` is less than or equal to `numSignUps`
+2. That `index` is less than or equal to `totalSignups`
 3. That each ballot in `ballots` is in a member of the ballot tree with the Merkle root `ballotRoot` at indices `batchStartIndex` to `batchStartIndex + (5 ** intStateTreeDepth)`
 4. That each set of votes (`votes[i]`) has the Merkle root $blt_r$ whose value equals `ballots[i][1]`
 5. That the tally is valid, which is:

package/versioned_docs/version-v3.x/technical-references/zk-snark-circuits/utilities.md

@@ -15,7 +15,7 @@ It outputs one field element, which is the SHA256 hash of the following inputs:
 
 1. `packedVals`
 2. `pollEndTimestamp`
-3. `msgRoot`
+3. `messageRoot`
 4. `coordinatorPubKeyHash`
 5. `newSbCommitment`
 6. `currentSbCommitment`
@@ -39,11 +39,11 @@ A utility circuit used by the main `tallyVotes` circuit to verify that the resul
 
 ![ResultsCommitmentVerifier](/img/circuits/resultsCommitmentVerifier.svg)
 
-#### QuinCheckRoot
+#### QuinaryCheckRoot
 
 Utility circuit that given a quin Merkle root and a list of leaves, check if the root is the correct result of inserting all the leaves into the tree in the given order.
 
-![QuinCheckRoot](/img/circuits/quinCheckRoot.svg)
+![QuinaryCheckRoot](/img/circuits/quinCheckRoot.svg)
 
 #### CalculateTotal
 
@@ -100,11 +100,11 @@ Utility circuit used to unpack an input element.
 
 ![UnpackElement](/img/circuits/unpackElement.svg)
 
-#### QuinSelector
+#### QuinarySelector
 
 Utility circuit used to select one element from an array of n elements at a given index.
 
-![QuinSelector](/img/circuits/quinSelector.svg)
+![QuinarySelector](/img/circuits/quinSelector.svg)
 
 #### Splicer
 
@@ -118,11 +118,11 @@ Utility circuit used to check if a batch of leaves exists in a quinary tree.
 
 ![QuinBatchLeavesExists](/img/circuits/quinBatchLeavesExists.svg)
 
-#### QuinGeneratePathIndices
+#### QuinaryGeneratePathIndices
 
 Utility circuit used to generate the indices needed to traverse the tree until we find the leaf we are looking for.
 
-![QuinGeneratePathIndices](/img/circuits/quinGeneratePathIndices.svg)
+![QuinaryGeneratePathIndices](/img/circuits/quinGeneratePathIndices.svg)
 
 #### ProcessOne