From e0547cd3bf48620fb8fbb556ee41ffa9d5cb9e3f Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Mon, 11 Mar 2024 06:44:51 +0100 Subject: [PATCH] docs: fix typos --- website/versioned_docs/version-v1.x/audit.md | 8 +-- .../versioned_docs/version-v1.x/circuits.md | 10 ++-- .../versioned_docs/version-v1.x/contracts.md | 4 +- .../version-v1.x/coordinator-processing.md | 2 +- .../version-v1.x/installation.md | 2 +- .../version-v1.x/integrating.md | 2 +- .../versioned_docs/version-v1.x/key-change.md | 2 +- .../versioned_docs/version-v1.x/primitives.md | 4 +- .../versioned_docs/version-v1.x/purpose.md | 2 +- website/versioned_docs/version-v1.x/spec.md | 50 +++++++++---------- .../version-v1.x/testing-in-detail.md | 2 +- .../versioned_docs/version-v1.x/testing.md | 2 +- .../versioned_docs/version-v1.x/workflow.md | 2 +- 13 files changed, 46 insertions(+), 46 deletions(-) diff --git a/website/versioned_docs/version-v1.x/audit.md b/website/versioned_docs/version-v1.x/audit.md index 08842a6064..9150dd285b 100644 --- a/website/versioned_docs/version-v1.x/audit.md +++ b/website/versioned_docs/version-v1.x/audit.md @@ -25,7 +25,7 @@ In March 2023, Veridise responsibly disclosed a number of issues to the MACI tea Out of five issues disclosed, only three were relevant and have been since fixed by the MACI team. The other two issues were disregarded as they were present in older version of code which is not in use anymore. -We would like to thank you the Veridise team for their effort in keeping open source projects safe. +We would like to thank the Veridise team for their effort in keeping open source projects safe. ### Issue 1 @@ -50,7 +50,7 @@ This was fixed by adding a new Template, `SafeLesThan` which uses `Num2Bits` as ```javascript // the implicit assumption of LessThan is both inputs are at most n bits -// so we need add range check for both inputs +// so we need to add range check for both inputs template SafeLessThan(n) { assert(n <= 252); signal input in[2]; @@ -86,7 +86,7 @@ This issue is the same issue number 1, this time for the input signal index. As with issue number 1, a new template `SafeGreaterThan` was added: ```javascript -// N is the number of bits the input have. +// N is the number of bits the input have. // The MSF is the sign bit. template SafeGreaterThan(n) { signal input in[2]; @@ -112,7 +112,7 @@ greaterThan[i].in[1] <== index; **Description** -In the template `QuinGeneratePathIndices`, the constrains of the `signal n[levels + 1]` don't perform well for division and modulo counting. +In the template `QuinGeneratePathIndices`, the constraints of the `signal n[levels + 1]` don't perform well for division and modulo counting. **Code Location** diff --git a/website/versioned_docs/version-v1.x/circuits.md b/website/versioned_docs/version-v1.x/circuits.md index bb675327f3..d474275c04 100644 --- a/website/versioned_docs/version-v1.x/circuits.md +++ b/website/versioned_docs/version-v1.x/circuits.md @@ -19,7 +19,7 @@ MACI has three main zk-SNARK [circuits](https://github.com/privacy-scaling-explo The rest of the circuits are utilities templates that are required for the main circuits to work correctly. These include utilities such as float math, conversion of private keys, and Poseidon hashing/encryption. -Each circuit is parameterised and it is important to set the right parameters that matches your use case. For example, if you want to support up to 3125 messages, the message tree depth parameter should be set to `5` (as $5^5 = 3125$). +Each circuit is parameterised and it is important to set the right parameters that match your use case. For example, if you want to support up to 3125 messages, the message tree depth parameter should be set to `5` (as $5^5 = 3125$). ## Background @@ -49,7 +49,7 @@ The circuits are used by the coordinator (the prover) to prove that they have co 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. -The `processMessages` 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 process these messages via the different state transitions to finally check that the expected state is correct. +The `processMessages` 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: - the related Poll has ended @@ -297,7 +297,7 @@ The subsidy circuit is used to implement pairwise subsidy. This is a technique t #### Process Messages Input Hasher -An utility circuit used by the main `processMessages` circuit to hash its inputs. +A utility circuit used by the main `processMessages` circuit to hash its inputs. ![ProcessMessagesInputHasher](/img/circuits/processMessagesInputHasher.svg) @@ -312,7 +312,7 @@ It outputs one field element, which is the SHA256 hash of the following inputs: #### Tally Votes Input Hasher -An utility template that generates a sha256 hash of the provided tally inputs. +A utility template that generates a sha256 hash of the provided tally inputs. ![TallyVotesInputHasher](/img/circuits/tallyInputHasher.svg) @@ -325,7 +325,7 @@ It outputs one field element, which is the SHA256 hash of the following inputs: #### ResultsCommitmentVerifier -An utility circuit used by the main `tallyVotes` circuit to verify that the results commitment is correct. +A utility circuit used by the main `tallyVotes` circuit to verify that the results commitment is correct. ![ResultsCommitmentVerifier](/img/circuits/resultsCommitmentVerifier.svg) diff --git a/website/versioned_docs/version-v1.x/contracts.md b/website/versioned_docs/version-v1.x/contracts.md index fcc8c1c4e8..ec8f892321 100644 --- a/website/versioned_docs/version-v1.x/contracts.md +++ b/website/versioned_docs/version-v1.x/contracts.md @@ -53,10 +53,10 @@ Next, we have the `signUp` function, which allows users to `signUp` using a `Sig This function does the following: -- checks that the maximum number of signups have not been reached. As of now, this will be $5 ** 10 - 1$ due to circuit limitations. +- checks that the maximum number of signups has not been reached. As of now, this will be $5 ** 10 - 1$ due to circuit limitations. - checks that the provided public key is within the allowed boundaries - increases the number of signups -- registers the user using the sign up gatekeeper contract. It is important that whichever gatekeeper is used, it reverts if an user tries to sign up twice. +- registers the user using the sign up gatekeeper contract. It is important that whichever gatekeeper is used, it reverts if a user tries to sign up twice. - calls the voice credit proxy to retrieve the number of allocated voice credits for the calling account - hashes the voice credits alongside the calling address and the current time - enqueues this hashed data into the `stateAq` contract diff --git a/website/versioned_docs/version-v1.x/coordinator-processing.md b/website/versioned_docs/version-v1.x/coordinator-processing.md index 24a56dccc4..dc38ec0305 100644 --- a/website/versioned_docs/version-v1.x/coordinator-processing.md +++ b/website/versioned_docs/version-v1.x/coordinator-processing.md @@ -1,6 +1,6 @@ --- title: Coordinator local processing -description: How does the coordinator process and tallies messages locally +description: How does the coordinator process and tally messages locally sidebar_label: Coordinator local processing sidebar_position: 16 --- diff --git a/website/versioned_docs/version-v1.x/installation.md b/website/versioned_docs/version-v1.x/installation.md index 33d4a03cec..a1e5bb1566 100644 --- a/website/versioned_docs/version-v1.x/installation.md +++ b/website/versioned_docs/version-v1.x/installation.md @@ -159,7 +159,7 @@ pnpm setup:zkeys ### Download `.zkey` files (if you would like to use the default parameters or the trusted setup artifacts) -MACI has two main zk-SNARK circuits (plus an optional Subsidy circuit). Each circuit is parameterised. There should one +MACI has two main zk-SNARK circuits (plus an optional Subsidy circuit). Each circuit is parameterised. 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 diff --git a/website/versioned_docs/version-v1.x/integrating.md b/website/versioned_docs/version-v1.x/integrating.md index 1448892c38..ca5bf02e56 100644 --- a/website/versioned_docs/version-v1.x/integrating.md +++ b/website/versioned_docs/version-v1.x/integrating.md @@ -25,7 +25,7 @@ Deployment order is: 7. Deploy Topup credit 8. Deploy MessageProcessorFactory, PollFactory, SubsidyFactory, TallyFactory 9. Deploy MACI, AccQueueQuinaryMaci -10. Deploy Poll, AccQueueQuinaryMaci, MessageProcessor, Tally and Susbsidy (optional) +10. Deploy Poll, AccQueueQuinaryMaci, MessageProcessor, Tally and Subsidy (optional) Before running the deploy command make sure you have [zkey files](https://maci.pse.dev/docs/trusted-setup) from trusted setup and env variables `ETH_PROVIDER` (RPC endpoint) and `ETH_SK` (wallet private key) are set. For production environment make sure you don't use zkey files from our examples. diff --git a/website/versioned_docs/version-v1.x/key-change.md b/website/versioned_docs/version-v1.x/key-change.md index dbae3e7f08..02ae41a15f 100644 --- a/website/versioned_docs/version-v1.x/key-change.md +++ b/website/versioned_docs/version-v1.x/key-change.md @@ -34,7 +34,7 @@ If messages were processed in the same order as they were submitted, Alice's vot On the other hand, due to messages being processed in reverse order, Alice's last message would be counted as valid as the key change would have not been processed yet. Then, Bob's vote would not be counted as valid as the current key for Alice would be $pub1$. -> Note that a key change message should have the nonce set to 1 in order for it to be valid. We'll see it a code example in the next sections. +> Note that a key change message should have the nonce set to 1 in order for it to be valid. We'll see a code example in the next sections. ## Then how can a voter change their key and submit a new vote? diff --git a/website/versioned_docs/version-v1.x/primitives.md b/website/versioned_docs/version-v1.x/primitives.md index 49fe77027f..dc3689e71b 100644 --- a/website/versioned_docs/version-v1.x/primitives.md +++ b/website/versioned_docs/version-v1.x/primitives.md @@ -7,7 +7,7 @@ sidebar_position: 6 ## MACI primitives -This section provides a short introduction of the main primitives used by MACI. +This section provides a short introduction to the main primitives used by MACI. ### Elliptic Curves @@ -213,4 +213,4 @@ The code to derive $A_{b_x}$ and $A_{b_y}$ is [here](https://github.com/iden3/ci 3. Use the method to convert a buffer to a point on the BabyJub curve described in [2.3.2]. 4. Multiply the point by 8. The result is the point with x-value $A_{b_x}$ and y-value $A_{b_y}$ -Given the [elliptic curve discrete logarithm problem](https://wstein.org/edu/2007/spring/ent/ent-html/node89.html), we assume that no-one knows the private key $s \in {F}_p$ and by using the public key generation procedure in [1.4], we can derive $A_{b_x}$ and $A_{b_y}$. Furthermore, the string above (`PedersenGenerator...`) acts as a nothing-up-my-sleeve value. +Given the [elliptic curve discrete logarithm problem](https://wstein.org/edu/2007/spring/ent/ent-html/node89.html), we assume that no one knows the private key $s \in {F}_p$ and by using the public key generation procedure in [1.4], we can derive $A_{b_x}$ and $A_{b_y}$. Furthermore, the string above (`PedersenGenerator...`) acts as a nothing-up-my-sleeve value. diff --git a/website/versioned_docs/version-v1.x/purpose.md b/website/versioned_docs/version-v1.x/purpose.md index d1d298f739..2159b3ec10 100644 --- a/website/versioned_docs/version-v1.x/purpose.md +++ b/website/versioned_docs/version-v1.x/purpose.md @@ -9,7 +9,7 @@ sidebar_position: 2 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 layed out in that post: +Below we attempt to summarize some of the points laid out in that post: ## Security requirements of a voting system diff --git a/website/versioned_docs/version-v1.x/spec.md b/website/versioned_docs/version-v1.x/spec.md index b41316c37b..5844b8269a 100644 --- a/website/versioned_docs/version-v1.x/spec.md +++ b/website/versioned_docs/version-v1.x/spec.md @@ -29,7 +29,7 @@ The commit hashes relevant to this audit are the following: The scope of the audit with regards to the `circomlib` library covers: - all the JS files that MACI references, **excluding** those which are not referenced by MACI's TS files -- all circuit files **excluding** whose which are not referenced by MACI's circuit files +- all circuit files **excluding** those which are not referenced by MACI's circuit files ### Statements that we wish to challenge @@ -75,7 +75,7 @@ The generator point of Baby Jubjub $G$ is: A private key is a random integer in the field $\mathbb{F}_p$. -MACI uses the Node.js [`crypto.randomBytes(32)`](https://nodejs.org/api/crypto.html#crypto_crypto_randombytes_size_callback) function to generate a cryptographically strong pseudorandom 32-byte value, as well as an algorithm to prevent [modulo bias](https://research.kudelskisecurity.com/2020/07/28/the-definitive-guide-to). In pseduocode this is expressed as: +MACI uses the Node.js [`crypto.randomBytes(32)`](https://nodejs.org/api/crypto.html#crypto_crypto_randombytes_size_callback) function to generate a cryptographically strong pseudorandom 32-byte value, as well as an algorithm to prevent [modulo bias](https://research.kudelskisecurity.com/2020/07/28/the-definitive-guide-to). In pseudocode this is expressed as: ``` lim = 2 ** 256 @@ -274,7 +274,7 @@ A verifying key is used to validate a zk-SNARK proof. Each unique permutation of ### 2.2. Private key -A private key $k$ represents a participant's ability to broadcast or decrypt messages under an unique identity and generation of a shared key [1.9], it translates to a scalar point on the Baby Jubjub elliptical curve. To avoid confusion with Ethereum's ECDSA encryption, MACI requires serialisation bound with the prefix `macisk.` +A private key $k$ represents a participant's ability to broadcast or decrypt messages under a unique identity and generation of a shared key [1.9], it translates to a scalar point on the Baby Jubjub elliptical curve. To avoid confusion with Ethereum's ECDSA encryption, MACI requires serialisation bound with the prefix `macisk.` #### 2.2.1. Serialisation @@ -369,7 +369,7 @@ To decrypt a message using $k_s$ is expressed as $[p, R8[0], R8[1], cm_s]$ = $\mathsf{poseidonDecrypt}(M, k_s[0], k_s[1], cm_n, 7)$ -To unpack $p$ to it's original five parameters, it must be separated into 50 bit values from the parent 250 bit value. To extract 50 bits at byte $n$, we: +To unpack $p$ to its original five parameters, it must be separated into 50 bit values from the parent 250 bit value. To extract 50 bits at byte $n$, we: 1. initialise 50 bits 2. shift left by $n$ bits @@ -462,15 +462,15 @@ To clarify how this works, consider the following situation between Alice and Ev 2. The sign up period ends and the voting period begins, Eve bribes Alice to oppose option A 3. Alice casts a message for option A, in which she simultaneously: - Votes in opposition of A - - Changes her keypair through submitting a new public key + - Changes her keypair by submitting a new public key 4. Eve is uncertain whether Alice has voted for her preference due to the secrecy of the message, regardless she assumes confirmation upon receiving the transaction hash 5. Alice broadcasts a message from the new keypair registered in step 3 and casts a vote in support of poll A in turn, voiding her initial vote in opposition -Eve is doubtful whether her request was actually satisfied and is unaware to Alice casting a new vote to void the first, she decides not compensate Alice because of the uncertainty surrounding her compliance. +Eve is doubtful whether her request was actually satisfied and is unaware of Alice casting a new vote to void the first, she decides not to compensate Alice because of the uncertainty surrounding her compliance. ### 3.3. Gatekeeper contract -The gatekeeper contract is an abstraction of logic that any deployment of MACI can modify. It is a way to whitelist signups to the system. For example, a custom gatekeeper contract may only allow addresses which own a certain ERC721 token for registration. +The gatekeeper contract is an abstraction of logic that any deployment of MACI can modify. It is a way to whitelist signups to the system. For example, a custom gatekeeper contract may only allow addresses that own a certain ERC721 token for registration. ### 3.4. Initial voice credit proxy @@ -483,19 +483,19 @@ In MACI there are two zkSNARK circuits each ensuring: - the correct registration of messages to the state tree - the correct execution of the tallying of votes -Each of these circuits involve ownership of an independent verifying key to validate each when successfully executed, these are generated during the trusted setup and are initialised to the registry for generating proofs. +Each of these circuits involves ownership of an independent verifying key to validate each when successfully executed, these are generated during the trusted setup and are initialised to the registry for generating proofs. ### 3.6. State #### The state tree -Each leaf the state tree encodes a participant's identity (public key) and the Unix timestamp at which they signed up. It has an arity of 5 and its depth is hardcoded to 10. +Each leaf of the state tree encodes a participant's identity (public key) and the Unix timestamp at which they signed up. It has an arity of 5 and its depth is hardcoded to 10. The default leaf value is the hash of a blank state leaf [2.8.1], insertions begin at index 1. Leaf 0 is reserved to inhibit a denial-of-service attack as explained below in [6.1]. #### The ballot tree (per poll) -Each leaf within the ballot trees stores a participants vote within a poll, it shares the same arity and depth as the state tree. It also has index 0 reserved for a blank leaf following the same basis. +Each leaf within the ballot trees stores a participant's vote within a poll, it shares the same arity and depth as the state tree. It also has index 0 reserved for a blank leaf following the same basis. #### The message tree (per poll) @@ -505,7 +505,7 @@ Each leaf within the message tree correlates to a command cast from participants #### When a user signs up -Registration is initiated through fulfilling the requirements specified in the gatekeeper contract and calling the `signUp()` method in the MACI contract. This enqueues adding a new leaf to the state tree for it to be merged by the coordinator once appropriate. +Registration is initiated by fulfilling the requirements specified in the gatekeeper contract and calling the `signUp()` method in the MACI contract. This enqueues adding a new leaf to the state tree for it to be merged by the coordinator once appropriate. #### When a user publishes a message @@ -513,7 +513,7 @@ Publishing messages requires users to encrypt a command using a shared key gener #### When the coordinator merges the state queue -To subsidise gas costs for users, registration does not require the state root to be updated at its full depth, which would incur a gas cost linear to the depth. Rather, the use the Accumulator Queue system described in [1.10] enqueues leaves. As such, the coordinator must compute the state tree root after the voting period is over and before they process messages. +To subsidise gas costs for users, registration does not require the state root to be updated at its full depth, which would incur a gas cost linear to the depth. Rather, the use of the Accumulator Queue system described in [1.10] enqueues leaves. As such, the coordinator must compute the state tree root after the voting period is over and before they process messages. Which first requires the merging of subroots [1.10.1], this creates the shortest possible tree that contains all the state leaves. Which may or may not require multiple transactions (in the form of batches) due to the restriction of the block gas limit. Once all the subroots have been computed they are merged [1.10.2] to compute the state root at its full depth. @@ -608,28 +608,28 @@ The integration tests and shell scripts in the `cli` directory provide examples | `isProcessVkSet(uint256 _sig)` | Non-applicable | Query whether a signature is valid for message processing | | `isTallyVkSet(uint256 _sig)` | Non-applicable | Query whether a signature valid for tallying votes | | `genProcessVkSig(uint256 _stateTreeDepth, uint256 _messageTreeDepth, uint256 _voteOptionTreeDepth, uint256 _messageBatchSize)` | Non-applicable | Generate a signature (used for verifying key mapping lookups) for message processing by compressing parameters into a singular value | -| `genTallyVkSig(uint256 _stateTreeDepth, uint256 _intStateTreeDepth, uint256 _voteOptionTreeDepth)` | Non-appicable | Generate a signature (used for verifying key mapping lookups) for vote tallying by compressing parameters into a singular value | +| `genTallyVkSig(uint256 _stateTreeDepth, uint256 _intStateTreeDepth, uint256 _voteOptionTreeDepth)` | Non-applicable | Generate a signature (used for verifying key mapping lookups) for vote tallying by compressing parameters into a singular value | | `setVerifyingKeys( uint256 _stateTreeDepth, uint256 _intStateTreeDepth, uint256 _messageTreeDepth, uint256 _voteOptionTreeDepth, uint256 _messageBatchSize, VerifyingKey memory _processVk, VerifyingKey memory _tallyVk)` | Coordinator only | Initialise verifying keys for processing and tallying to the contract alongside specifying each tree depth | | `hasProcessVk(uint256 _stateTreeDepth, uint256 _messageTreeDepth, uint256 _voteOptionTreeDepth, uint256 _messageBatchSize)` | Non-applicable | Query whether the signature of the parameters is valid for message processing | | `getProcessVkBySig(uint256 _sig)` | Non-applicable | Query a processing verifying key by providing a valid signature | | `getProcessVk(uint256 _stateTreeDepth, uint256 _messageTreeDepth, uint256 _voteOptionTreeDepth, uint256 _messageBatchSize)` | Non-applicable | Query a processing verifying key by providing parameters to generate a valid signature | -| `hasTallyVk(uint256 _stateTreeDepth, uint256 _intStateTreeDepth, uint256 _voteOptionTreeDepth)` | Non-appicable | Query whether the signature of the parameters is valid for vote tallying | +| `hasTallyVk(uint256 _stateTreeDepth, uint256 _intStateTreeDepth, uint256 _voteOptionTreeDepth)` | Non-applicable | Query whether the signature of the parameters is valid for vote tallying | | `getTallyVkBySig(uint256 _sig)` | Non-applicable | Query a tallying verifying key by providing a valid signature | -| `getTallyVk(uint256 _stateTreeDepth, uint256 _intStateTreeDepth, uint256 _voteOptionTreeDepth)` | Non-appicable | Query a tallying verifying key by providing parameters to generate a valid signature | +| `getTallyVk(uint256 _stateTreeDepth, uint256 _intStateTreeDepth, uint256 _voteOptionTreeDepth)` | Non-applicable | Query a tallying verifying key by providing parameters to generate a valid signature | ### 5.5. PollProcessorAndTallyer | Function | Permissions | Notes | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | -| `sha256Hash(uint256[] memory array)` | Non-appicable | Hash an array of values (using SHA256) moduluo the snark field size | +| `sha256Hash(uint256[] memory array)` | Non-applicable | Hash an array of values (using SHA256) moduluo the snark field size | | `processMessages(Poll _poll, uint256 _newSbCommitment, uint256[8] memory _proof)` | Executable only by the coordinator and after the voting period | Process state messages relative to a new state-ballot commitment given that the proof is valid | -| `verifyProcessProof(Poll _poll, uint256 _currentMessageBatchIndex, uint256 _messageRoot, uint256 _currentSbCommitment, uint256 _newSbCommitment, uint256[8] memory _proof)` | Non-appicable | Query whether a message processing proof is valid | -| `genProcessMessagesPublicInputHash(Poll _poll, uint256 _currentMessageBatchIndex, uint256 _messageRoot, uint256 _numSignUps, uint256 _currentSbCommitment, uint256 _newSbCommitment)` | Non-appicable | Hash of the coordinators public key, `packedVals`, current state-ballot commitment and message root | -| `genProcessMessagesPackedVals( Poll _poll, uint256 _currentMessageBatchIndex, uint256 _numSignUps)` | Non-appicable | Generate a packed 250-bit value `packedVals` for message processing | -| `genTallyVotesPackedVals( uint256 _numSignUps, uint256 _batchStartIndex, uint256 _tallyBatchSize)` | Non-appicable | Generate a packed 100-bit value `packedVals` for vote tallying | -| `genTallyVotesPublicInputHash( uint256 _numSignUps, uint256 _batchStartIndex, uint256 _tallyBatchSize, uint256 _newTallyCommitment )` | Non-appicable | Hash of the current tally commitment, the new tally commitment, `packedVals` and the state-ballot commitment | +| `verifyProcessProof(Poll _poll, uint256 _currentMessageBatchIndex, uint256 _messageRoot, uint256 _currentSbCommitment, uint256 _newSbCommitment, uint256[8] memory _proof)` | Non-applicable | Query whether a message processing proof is valid | +| `genProcessMessagesPublicInputHash(Poll _poll, uint256 _currentMessageBatchIndex, uint256 _messageRoot, uint256 _numSignUps, uint256 _currentSbCommitment, uint256 _newSbCommitment)` | Non-applicable | Hash of the coordinators public key, `packedVals`, current state-ballot commitment and message root | +| `genProcessMessagesPackedVals( Poll _poll, uint256 _currentMessageBatchIndex, uint256 _numSignUps)` | Non-applicable | Generate a packed 250-bit value `packedVals` for message processing | +| `genTallyVotesPackedVals( uint256 _numSignUps, uint256 _batchStartIndex, uint256 _tallyBatchSize)` | Non-applicable | Generate a packed 100-bit value `packedVals` for vote tallying | +| `genTallyVotesPublicInputHash( uint256 _numSignUps, uint256 _batchStartIndex, uint256 _tallyBatchSize, uint256 _newTallyCommitment )` | Non-applicable | Hash of the current tally commitment, the new tally commitment, `packedVals` and the state-ballot commitment | | `tallyVotes(Poll _poll, uint256 _newTallyCommitment, uint256[8] memory _proof)` | Executable only by the coordinator and after the voting period | Tally votes relative to a new tally commitment given that the proof is valid | -| `verifyTallyProof(Poll _poll, uint256[8] memory _proof, uint256 _numSignUps, uint256 _batchStartIndex, uint256 _tallyBatchSize, uint256 _newTallyCommitment)` | Non-appicable | Query whether a vote tallying proof is valid | +| `verifyTallyProof(Poll _poll, uint256[8] memory _proof, uint256 _numSignUps, uint256 _batchStartIndex, uint256 _tallyBatchSize, uint256 _newTallyCommitment)` | Non-applicable | Query whether a vote tallying proof is valid | ## 6. zk-SNARKs @@ -765,7 +765,7 @@ This method requires fewer circuit constraints than if we verified a Merkle proo #### How messages are decrypted and applied -The circuit uses Poseidon decryption [1.9] to decrypt each message. The shared key is derived using ECDH [1.10] and the nonce is always equal to a value of`0`. +The circuit uses Poseidon decryption [1.9] to decrypt each message. The shared key is derived using ECDH [1.10] and the nonce is always equal to a value of `0`. The procedure to apply a command to a state leaf and ballot leaf is as such: @@ -797,7 +797,7 @@ If the command is invalid: 1. Verify that the state leaf at index 0 is a member of the state root 2. Verify that the ballot leaf at index 0 is a member of the ballot root -The state leaf at index 0 is a _blank state leaf_, and the ballot leaf at index 0 is an _blank ballot leaf_. It should be impossible to update the 0th state leaf or 0th ballot leaf. The reason that these blank leaves exist at index 0 is to prevent an attack where a user sets $cm_i$ to the maximum possible value ($5^{10}$), which would force the coordinator to have to compute the Merkle path of leaf $5_{10} - 1$. Which is would take such a long time that it would constitute a denial-of-service attack on the coordinator that prevents them from generating proofs in a reasonable time. +The state leaf at index 0 is a _blank state leaf_, and the ballot leaf at index 0 is a _blank ballot leaf_. It should be impossible to update the 0th state leaf or 0th ballot leaf. The reason that these blank leaves exist at index 0 is to prevent an attack where a user sets $cm_i$ to the maximum possible value ($5^{10}$), which would force the coordinator to have to compute the Merkle path of leaf $5_{10} - 1$. Which is would take such a long time that it would constitute a denial-of-service attack on the coordinator that prevents them from generating proofs in a reasonable time. ##### Order of message processing @@ -914,7 +914,7 @@ The commitment to `stateRoot`, `ballotRoot`, and `sbSalt`: $\mathsf{poseidon_3}([\mathsf{stateRoot}, \mathsf{ballotRoot}, \mathsf{sbSalt}])$ -Proving preimage of `sbCommitment` is one out of the several steps required to prove that the votes were tallied correctly. By establishing that the coordinator knows `ballotRoot`, the coordinator can (using other parts of the circuit) prove that that they know the preimage of the ballot leaves in the batch being tallied. +Proving preimage of `sbCommitment` is one out of the several steps required to prove that the votes were tallied correctly. By establishing that the coordinator knows `ballotRoot`, the coordinator can (using other parts of the circuit) prove that they know the preimage of the ballot leaves in the batch being tallied. ##### `currentTallyCommitment` and `newTallyCommitment` diff --git a/website/versioned_docs/version-v1.x/testing-in-detail.md b/website/versioned_docs/version-v1.x/testing-in-detail.md index f9c37cd9ec..5ade3d0642 100644 --- a/website/versioned_docs/version-v1.x/testing-in-detail.md +++ b/website/versioned_docs/version-v1.x/testing-in-detail.md @@ -46,7 +46,7 @@ Finally, the whole process of merging the state and message trees is performed, #### How to implement a new test case -To add a new test cases, it is quite simple. You can amend the `integrationTests/ts/__tests__/data/suites.json` file and add your test declaration in there. +To add a new test case, it is quite simple. You can amend the `integrationTests/ts/__tests__/data/suites.json` file and add your test declaration in there. ```json { diff --git a/website/versioned_docs/version-v1.x/testing.md b/website/versioned_docs/version-v1.x/testing.md index 135bf1c4e3..7207fa484a 100644 --- a/website/versioned_docs/version-v1.x/testing.md +++ b/website/versioned_docs/version-v1.x/testing.md @@ -324,7 +324,7 @@ The following compiled circuits and zkeys are available to download: ### Prod Size Ceremony :::info -These artifacts have undergong a trusted setup and can be used in production. Subsidy is not included. +These artifacts have undergone a trusted setup and can be used in production. Subsidy is not included. ::: - [maci-ceremony-artifacts-v1.2.0.tar.gz](https://maci-develop-fra.s3.eu-central-1.amazonaws.com/v1.2.0/maci-ceremony-artifacts-v1.2.0.tar.gz) (0.76 GB) diff --git a/website/versioned_docs/version-v1.x/workflow.md b/website/versioned_docs/version-v1.x/workflow.md index 7cf47000b4..0894d23bda 100644 --- a/website/versioned_docs/version-v1.x/workflow.md +++ b/website/versioned_docs/version-v1.x/workflow.md @@ -47,7 +47,7 @@ Once a voting poll has completed (i.e. the voting deadline has elapsed), the coo #### Trust assumptions -We say the coordinator is a "trusted" coordinator, because there's areas where a corrupt (or inept) coordinator could disrupt the "happy path" of the MACI workflow. +We say the coordinator is a "trusted" coordinator, because there are areas where a corrupt (or inept) coordinator could disrupt the "happy path" of the MACI workflow. For instance, a coordinator can: