@maci-protocol/website 0.0.0-ci.f9da2fc → 0.0.0-ci.fc91dc9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +1 -2
- package/blog/2024-02-28-maci-v1.2.0.md +1 -1
- package/blog/2024-08-10-maci-v2.md +1 -1
- package/package.json +4 -4
- package/src/pages/roadmap.md +39 -80
- package/static/img/circuits/MACI-Circuits.excalidraw +28 -28
- package/static/img/circuits/ecdh.svg +1 -1
- package/static/img/circuits/messageToCommand.svg +1 -1
- package/static/img/circuits/messageValidator.svg +1 -1
- package/static/img/circuits/privToPubkey.svg +1 -1
- package/static/img/circuits/processMessages.svg +1 -1
- package/static/img/circuits/processMessagesInputHasher.svg +1 -1
- package/static/img/circuits/processMessages_2_0.svg +1 -1
- package/static/img/circuits/processOne.svg +1 -1
- package/static/img/circuits/processTopup.svg +1 -1
- package/static/img/circuits/tallyInputHasher.svg +1 -1
- package/static/img/circuits/verifySignature.svg +1 -1
- package/versioned_docs/version-v3.x/core-concepts/key-change.md +25 -25
- package/versioned_docs/version-v3.x/core-concepts/maci-keys.md +1 -1
- package/versioned_docs/version-v3.x/core-concepts/poll-types.md +2 -2
- package/versioned_docs/version-v3.x/core-concepts/polls.md +3 -3
- package/versioned_docs/version-v3.x/core-concepts/spec.md +33 -99
- package/versioned_docs/version-v3.x/guides/compile-circuits.md +7 -7
- package/versioned_docs/version-v3.x/guides/integrating.md +8 -8
- package/versioned_docs/version-v3.x/guides/testing/testing-in-detail.md +1 -1
- package/versioned_docs/version-v3.x/guides/troubleshooting.md +11 -11
- package/versioned_docs/version-v3.x/quick-start.md +6 -6
- package/versioned_docs/version-v3.x/supported-networks/deployed-contracts.md +2 -2
- package/versioned_docs/version-v3.x/technical-references/smart-contracts/MACI.md +5 -5
- package/versioned_docs/version-v3.x/technical-references/smart-contracts/Poll.md +7 -7
- package/versioned_docs/version-v3.x/technical-references/smart-contracts/Tally.md +2 -2
- package/versioned_docs/version-v3.x/technical-references/smart-contracts/VkRegistry.md +5 -5
- package/versioned_docs/version-v3.x/technical-references/zk-snark-circuits/joinPoll.md +3 -3
- package/versioned_docs/version-v3.x/technical-references/zk-snark-circuits/processMessages.md +12 -12
- package/versioned_docs/version-v3.x/technical-references/zk-snark-circuits/tallyVotes.md +2 -2
- package/versioned_docs/version-v3.x/technical-references/zk-snark-circuits/utilities.md +1 -1
|
@@ -16,14 +16,14 @@ This contract should be deployed alongside a `Poll`, with the the constructor ac
|
|
|
16
16
|
```ts
|
|
17
17
|
constructor(
|
|
18
18
|
address _verifier,
|
|
19
|
-
address
|
|
19
|
+
address _verifyingKeysRegistry,
|
|
20
20
|
address _poll,
|
|
21
21
|
address _mp,
|
|
22
22
|
address _tallyOwner,
|
|
23
23
|
Mode _mode
|
|
24
24
|
) payable {
|
|
25
25
|
verifier = IVerifier(_verifier);
|
|
26
|
-
vkRegistry = IVkRegistry(
|
|
26
|
+
vkRegistry = IVkRegistry(_verifyingKeysRegistry);
|
|
27
27
|
poll = IPoll(_poll);
|
|
28
28
|
messageProcessor = IMessageProcessor(_mp);
|
|
29
29
|
mode = _mode;
|
|
@@ -1,15 +1,15 @@
|
|
|
1
1
|
---
|
|
2
|
-
title:
|
|
3
|
-
description:
|
|
4
|
-
sidebar_label:
|
|
2
|
+
title: VerifyingKeysRegistry Smart Contract
|
|
3
|
+
description: VerifyingKeysRegistry smart contract
|
|
4
|
+
sidebar_label: VerifyingKeysRegistry
|
|
5
5
|
sidebar_position: 8
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
:::info
|
|
9
|
-
Code location: [
|
|
9
|
+
Code location: [VerifyingKeysRegistry.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VerifyingKeysRegistry.sol)
|
|
10
10
|
:::
|
|
11
11
|
|
|
12
|
-
The
|
|
12
|
+
The VerifyingKeysRegistry is a contract that holds the verifying keys for the zk-SNARK circuits. It holds four different sets of keys:
|
|
13
13
|
|
|
14
14
|
- `processVks` - The keys for the processMessages circuit
|
|
15
15
|
- `tallyVks` - The keys for the tallyVotes circuit
|
|
@@ -21,8 +21,8 @@ Users need to provide a valid proof to the Poll smart contract to join a poll, a
|
|
|
21
21
|
|
|
22
22
|
| Input signal | Description |
|
|
23
23
|
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
24
|
-
| `
|
|
25
|
-
| `
|
|
24
|
+
| `privateKey` | The user's private key |
|
|
25
|
+
| `pollPublicKey` | The poll's public key |
|
|
26
26
|
| `siblings` | The siblings for the merkle tree inclusion proof |
|
|
27
27
|
| `indices` | The indices for the merkle tree inclusion proof |
|
|
28
28
|
| `nullifier` | The nullifier |
|
|
@@ -44,7 +44,7 @@ Users will use this circuit to anonymously prove that they joined a poll. This c
|
|
|
44
44
|
|
|
45
45
|
| Input signal | Description |
|
|
46
46
|
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
47
|
-
| `
|
|
47
|
+
| `privateKey` | The user's private key |
|
|
48
48
|
| `voiceCreditsBalance` | The user's initial voice credits balance |
|
|
49
49
|
| `pathElements` | The path elements for the merkle tree inclusion proof |
|
|
50
50
|
| `pathIndices` | The path indices for the merkle tree inclusion proof |
|
package/versioned_docs/version-v3.x/technical-references/zk-snark-circuits/processMessages.md
CHANGED
|
@@ -7,7 +7,7 @@ sidebar_position: 3
|
|
|
7
7
|
|
|
8
8
|
[**Repo link**](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core)
|
|
9
9
|
|
|
10
|
-
This circuit allows the coordinator to prove that they have correctly processed each message in reverse order, in a consecutive batch of 5 ^
|
|
10
|
+
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.
|
|
11
11
|
|
|
12
12
|
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.
|
|
13
13
|
The pre-requisites for this circuit are:
|
|
@@ -36,17 +36,17 @@ A version working with non quadratic voting (non-qv) is also [available](https:/
|
|
|
36
36
|
|
|
37
37
|
| Input signal | Description |
|
|
38
38
|
| -------------------------------- | --------------------------------------------------------------------------------------- |
|
|
39
|
-
| `
|
|
39
|
+
| `totalSignups` | Number of users that have completed the sign up |
|
|
40
40
|
| `index` | The batch index of current message batch |
|
|
41
41
|
| `pollEndTimestamp` | The Unix timestamp at which the poll ends |
|
|
42
|
-
| `
|
|
43
|
-
| `
|
|
44
|
-
| `
|
|
42
|
+
| `messageRoot` | The root of the message tree |
|
|
43
|
+
| `messages` | The batch of messages as an array of arrays |
|
|
44
|
+
| `messageSubrootPathElements` | As described below |
|
|
45
45
|
| `coordinatorPublicKeyHash` | $\mathsf{poseidon_2}([cPk_x, cPk_y])$ |
|
|
46
46
|
| `newSbCommitment` | As described below |
|
|
47
|
-
| `
|
|
47
|
+
| `coordinatorPrivateKey` | The coordinator's private key |
|
|
48
48
|
| `batchEndIndex` | The last batch index |
|
|
49
|
-
| `
|
|
49
|
+
| `encryptionPublicKeys` | The public keys used to generate shared ECDH encryption keys to encrypt the messages |
|
|
50
50
|
| `currentStateRoot` | The state root before the commands are applied |
|
|
51
51
|
| `currentStateLeaves` | The state leaves upon which messages are applied |
|
|
52
52
|
| `currentStateLeavesPathElements` | The Merkle path to each incremental state root |
|
|
@@ -74,9 +74,9 @@ The salt used to produce `currentSbCommitment` (see above).
|
|
|
74
74
|
|
|
75
75
|
The salt used to produce `newSbCommitment` (see above).
|
|
76
76
|
|
|
77
|
-
##### `
|
|
77
|
+
##### `messageSubrootPathElements`
|
|
78
78
|
|
|
79
|
-
The index of each message in `
|
|
79
|
+
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`.
|
|
80
80
|
|
|
81
81
|
A simplified example using a tree of arity 2:
|
|
82
82
|
|
|
@@ -100,7 +100,7 @@ This method requires fewer circuit constraints than if we verified a Merkle proo
|
|
|
100
100
|
|
|
101
101
|
1. That the prover knows the preimage to `currentSbCommitment` (that is, the state root, ballot root, and `currentSbSalt`)
|
|
102
102
|
2. That `maxVoteOptions <= (5 ^ voteOptionTreeDepth)`
|
|
103
|
-
3. That `
|
|
104
|
-
4. That `coordinatorPublicKeyHash` is a hash of public key that is correctly derived from `
|
|
105
|
-
5. That each message in `
|
|
103
|
+
3. That `totalSignups <= (2 ^ stateTreeDepth)`
|
|
104
|
+
4. That `coordinatorPublicKeyHash` is a hash of public key that is correctly derived from `coordinatorPrivateKey`
|
|
105
|
+
5. That each message in `messages` exists in the message tree
|
|
106
106
|
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`
|
|
@@ -25,7 +25,7 @@ A version working with non quadratic voting (non-qv) is also [available](https:/
|
|
|
25
25
|
|
|
26
26
|
| Input signal | Description |
|
|
27
27
|
| --------------------------------------- | ---------------------------------------------------------------- |
|
|
28
|
-
| `
|
|
28
|
+
| `totalSignups` | The number of users that signup |
|
|
29
29
|
| `index` | Start index of given batch |
|
|
30
30
|
| `sbCommitment` | Described below |
|
|
31
31
|
| `currentTallyCommitment` | Described below |
|
|
@@ -72,7 +72,7 @@ $poseidon_3([tc_r, tc_t, tc_p])$
|
|
|
72
72
|
#### Statements that the circuit proves
|
|
73
73
|
|
|
74
74
|
1. That the coordinator knows the preimage of `sbCommitment`
|
|
75
|
-
2. That `index` is less than or equal to `
|
|
75
|
+
2. That `index` is less than or equal to `totalSignups`
|
|
76
76
|
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)`
|
|
77
77
|
4. That each set of votes (`votes[i]`) has the Merkle root $blt_r$ whose value equals `ballots[i][1]`
|
|
78
78
|
5. That the tally is valid, which is:
|