chore: formatting for World ID (#46)

* chore: formatting for World ID

* chore: circuit doc fmt

* chore: fmt

README.md

@@ -1,19 +1,19 @@
-# Batch WorldID proof verification with Axiom
+# Batch World ID proof verification with Axiom
 
-This repo implements batch verification of [WorldID](https://worldcoin.org/world-id) proofs to enable cheaper batch claims of WLD grants.
+This repo implements batch verification of [World ID](https://worldcoin.org/world-id) proofs to enable cheaper batch claims of WLD grants.
 
 It is implemented via two components:
 
-- ZK circuits for batch WorldID proof verification using Axiom's ZK circuit libraries.
-- Smart contracts implementing WLD grant claims based on batch-verified WorldID proof results.
+- ZK circuits for batch World ID proof verification using Axiom's ZK circuit libraries.
+- Smart contracts implementing WLD grant claims based on batch-verified World ID proof results.
 
 In what follows, we describe two different flows for WLD grants using this integration.
 
 **Note:** The work in this repo has not been audited and should not be deployed in production prior to additional security review.
 
 ## Worldcoin Grant Protocol
 
-We implement two versions of WLD grants based on batch verification of WorldID proofs.
+We implement two versions of WLD grants based on batch verification of World ID proofs.
 
 - `WorldcoinAggregationV1`: After proof verification, all the receivers in the batch immediately have their grant transferred to them.
 - `WorldcoinAggregationV2`: After proof verification, the receivers (or someone on their behalf) can prove into a Merkle root and transfer the grant to the receiver.
@@ -29,19 +29,19 @@ The V1 grant contract supports at most `MAX_NUM_CLAIMS` at once, and receives as
 ```
 - vkeyHash - the Keccak hash of the flattened Groth16 vkey
 - numClaims - the number of claims, which should satisfy 1 <= numClaims <= MAX_NUM_CLAIMS
-- root - the WorldID root the proofs are relative to
+- root - the World ID root the proofs are relative to
 - grantIds_i for i = 1, ..., MAX_NUM_CLAIMS
 - receivers_i for i = 1, ..., MAX_NUM_CLAIMS
 - nullifierHashes_i for i = 1, ..., MAX_NUM_CLAIMS
 ```
 
 The ZK proof verifies in ZK that:
 
-1. For `0 <= idx < numClaims`, there are valid WorldID proofs corresponding to `(root, claimedNullifierHashes[idx], receivers[idx], grantIds[idx])` with the given Groth16 `vkeyHash`.
+1. For `0 <= idx < numClaims`, there are valid World ID proofs corresponding to `(root, claimedNullifierHashes[idx], receivers[idx], grantIds[idx])` with the given Groth16 `vkeyHash`.
 
 The V1 grants contract then:
 
-- checks the `vkeyHash` for the WorldID Groth16 proof is valid
+- checks the `vkeyHash` for the World ID Groth16 proof is valid
 - checks that `grantIds[idx]` is valid for `0 <= idx < numClaims`
 - checks for each claiming grantee that the nullifier hash was not previously used
 - sends `WLD` to fulfill the claim
@@ -56,18 +56,18 @@ The V2 grant contract supports at most `MAX_NUM_CLAIMS` at once, where `MAX_NUM_
 
 ```
 - vkeyHash - the Keccak hash of the flattened Groth16 vkey
-- root - the WorldID root the proofs are relative to
+- root - the World ID root the proofs are relative to
 - claimsRoot - the Keccak Merkle root of the tree with `MAX_NUM_CLAIMS` leaves
 ```
 
 The ZK proof verifies that
 
-1. There is a value `1 <= numClaims <= MAX_NUM_CLAIMS` and arrays `grantIds`, `receivers` and `claimedNullifierHashes` so that for `0 <= idx < numClaims`, there are valid WorldID proofs corresponding to `(root, claimedNullifierHashes[idx], receivers[idx], grantIds[idx])`.
+1. There is a value `1 <= numClaims <= MAX_NUM_CLAIMS` and arrays `grantIds`, `receivers` and `claimedNullifierHashes` so that for `0 <= idx < numClaims`, there are valid World ID proofs corresponding to `(root, claimedNullifierHashes[idx], receivers[idx], grantIds[idx])`.
 2. The hash `claimsRoot` is the Keccak Merkle root of the tree with `MAX_NUM_CLAIMS` leaves, where the first `numClaims` leaves are given by `abi.encodePacked(grantIds[idx], receivers[idx], claimedNullifierHashes[idx])` and the remaining leaves are `abi.encodePacked(uint256(0), address(0), byte32(0))`.
 
 The V2 grants contract then:
 
-- checks the `vkeyHash` for the WorldID Groth16 proof is valid
+- checks the `vkeyHash` for the World ID Groth16 proof is valid
 - stores `claimsRoot` for grantees to claim WLD against
 
 Grantees can claim `WLD` rewards from the V2 grants contract by passing a Merkle proof into:
@@ -137,8 +137,8 @@ We deployed the following other contracts to mock different aspects of the World
 
 ### Repository Overview
 
-- `circuit/`: Circuits and prover backend for standalone batch WorldID aggregation.
-  - `README.md`: Documentation for the standalone WorldID aggregation circuits for WLD grants can be found in their own README.
+- `circuit/`: Circuits and prover backend for standalone batch World ID aggregation.
+  - `README.md`: Documentation for the standalone World ID aggregation circuits for WLD grants can be found in their own README.
 - `src/`
   - `WorldcoinAggregationV1.sol`: The smart contract for the `WorldcoinAggregationV1` version.
   - `WorldcoinAggregationV2.sol`: The smart contract for the `WorldcoinAggregationV2` version.

circuit/README.md

@@ -1,10 +1,10 @@
-# WorldID Proof Aggregation
+# World ID Proof Aggregation
 
-This subdirectory implements ZK circuits and backend prover endpoints for batch WorldID proof verification.
+This subdirectory implements ZK circuits and backend prover endpoints for batch World ID proof verification.
 
 ## Summary
 
-- [Batch WorldID Verification Circuits](#batch-worldid-verification-circuits)
+- [Batch World ID Verification Circuits](#batch-worldid-verification-circuits)
 - [Prover Backend Architecture](#prover-backend-architecture)
 
 ## Folder structure
@@ -33,7 +33,7 @@ This subdirectory implements ZK circuits and backend prover endpoints for batch
 └── README.md
 ```
 
-## Batch WorldID Verification Circuits
+## Batch World ID Verification Circuits
 
 The architecture for the SNARK circuits used in the V1 and V2 designs follow the same MapReduce
 structure which uses SNARK aggregation.
@@ -48,7 +48,7 @@ We now proceed to discuss the details of the V1 and V2 circuits within this fram
 
 ### V1 Circuit Design
 
-The V1 circuit verifies the WorldID Groth16 proofs in batch, and exposes as a public output the Keccak hash of the following quantities.
+The V1 circuit verifies the World ID Groth16 proofs in batch, and exposes as a public output the Keccak hash of the following quantities.
 
 - `vkey_hash` - the Keccak hash of the flattened vk
 - `num_claims` - the number of claims, which should satisfy `1 <= num_claims <= MAX_NUM_CLAIMS`
@@ -151,7 +151,7 @@ cargo run --release --bin keygen --features "keygen, v1(or v2)" -- --srs-dir ${S
 
 where the feature `v1` or `v2` should be specified based on whether V1 or V2 circuits should be used.
 
-The resulting proving keys, verification keys, and on-chain verification contract will be written to `${CIRCUIT_DATA_DIR}`, together with a `${CIDS_NAME}.cids` JSON file which encodes the aggregation tree as a list of the circuit IDs at each depth of the tree. The `.cids` file extension is an acronym standing for Circuit IDs -- the file type is JSON, and the extension is used to emphasize this is a special file containing the circuit IDs of an aggregation tree. The `${CIDS_NAME}` can be any string. It is meant to be an operator specified identifier to distinguish between different aggregation trees (e.g., which have different tree structures or circuit configurations). All nodes at the same depth in the aggregation tree use the same circuit, so they all have the same circuit ID. The `*.cids` file is context-dependent: it only works for the WorldID verification circuits in this repository. The file is not meant to be interoperable with other generic Halo2 circuits.
+The resulting proving keys, verification keys, and on-chain verification contract will be written to `${CIRCUIT_DATA_DIR}`, together with a `${CIDS_NAME}.cids` JSON file which encodes the aggregation tree as a list of the circuit IDs at each depth of the tree. The `.cids` file extension is an acronym standing for Circuit IDs -- the file type is JSON, and the extension is used to emphasize this is a special file containing the circuit IDs of an aggregation tree. The `${CIDS_NAME}` can be any string. It is meant to be an operator specified identifier to distinguish between different aggregation trees (e.g., which have different tree structures or circuit configurations). All nodes at the same depth in the aggregation tree use the same circuit, so they all have the same circuit ID. The `*.cids` file is context-dependent: it only works for the World ID verification circuits in this repository. The file is not meant to be interoperable with other generic Halo2 circuits.
 
 ## Prover Backend Architecture
 
@@ -172,7 +172,7 @@ We now describe the architecture of these components in more detail.
 
 ### Scheduler
 
-The scheduler provides the highest level API for interacting with the backend. It receives the request for an entire proving workload, whose final output is the serialized bytes of a SNARK proof proving `MAX_NUM_CLAIMS` WLD grant claims. To achieve this, the scheduler must schedule proving tasks according to a computation DAG, namely the aggregation tree structure depicted in [Batch WorldID Verification Circuits](#batch-worldid-verification-circuits).
+The scheduler provides the highest level API for interacting with the backend. It receives the request for an entire proving workload, whose final output is the serialized bytes of a SNARK proof proving `MAX_NUM_CLAIMS` WLD grant claims. To achieve this, the scheduler must schedule proving tasks according to a computation DAG, namely the aggregation tree structure depicted in [Batch World ID Verification Circuits](#batch-worldid-verification-circuits).
 
 We provide two implementations of the scheduler:
 
@@ -283,7 +283,7 @@ For integration with the scheduler, the dispatcher must be implemented as a web
 ### Prover
 
 The prover is the most computation intensive component of the system. It is responsible for generating the SNARK proof for a given circuit. We implement the prover as a REST API server
-which can generate proofs for any of the circuits described in [Batch WorldID Verification Circuits](#batch-worldid-verification-circuits). The prover accepts a typeless request consisting of the circuit ID and the proof input. The proving server infers the circuit type from the circuit ID and proof input to determine which circuit to prove for.
+which can generate proofs for any of the circuits described in [Batch World ID Verification Circuits](#batch-worldid-verification-circuits). The prover accepts a typeless request consisting of the circuit ID and the proof input. The proving server infers the circuit type from the circuit ID and proof input to determine which circuit to prove for.
 
 The prover first loads configuration files and the proving key from `${CIRCUIT_DATA_DIR}` directory, using the circuit ID to determine which files to load. The prover will store the proving key in memory after the first load, keeping it in memory for future proof requests until it is told via API request to reset the memory. Because we expect the proving time of a single circuit to not exceed typical connection disconnect thresholds, the proving server keeps the HTTP connection open for the duration of the proving process. Once proving is complete, the prover returns the proof in the response. The prover does not cache any proof results.