Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: update keygen instructions for Base #37

Merged
merged 1 commit into from
Apr 30, 2024
Merged

docs: update keygen instructions for Base #37

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 21 additions & 5 deletions axiom-query/KEYGEN.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

# Proving and Verifying Key Generation

To generate the exact proving and verifying keys we use in production on Ethereum Mainnet, you can do the following:
To generate the exact proving and verifying keys we use in production on Ethereum Mainnet and Base Mainnet, you can do the following:

1. Download the KZG trusted setup that we use with [this script](../trusted_setup_s3.sh).

Expand All @@ -25,14 +25,23 @@ Additional details about the binary can be found [here](./src/bin/README.md).

3. Generate the proving and verifying keys for one of our production configurations.

We have multiple aggregation configurations that we use in production. These are specified by intent YAML files in the [`configs/production`](./configs/production/) directory. The configurations, ordered by the sum of generated proving key sizes, are:
We have multiple aggregation configurations that we use in production. These are specified by intent YAML files in the [`configs/production`](./configs/production/) directory.

The configurations that we have generated and use on all chains, ordered by the sum of generated proving key sizes, are:

- `all_small.yml`
- `all_32_each_default.yml`
- `all_128_each_default.yml`
- `all_large.yml`
- `all_max.yml`

The following configurations in [`configs/production/base_specific`](./configs/production/base_specific) are enabled and used **only** on Base Mainnet:

- `base_specific/all_32_each_rct_medium_st_depth_14.yml`
- `base_specific/all_128_each_default_st_depth_14.yml`
- `base_specific/all_large_st_depth_14.yml`
- `base_specific/all_max_st_depth_14.yml`

We will refer to one of these files as `$INTENT_NAME.yml` below. To generate all proving keys and verifying keys for the configuration corresponding to `$INTENT_NAME.yml`, run:

```bash
Expand All @@ -44,7 +53,7 @@ where `$CIRCUIT_DATA_DIR` is the directory you want to store the output files. A

Check that the top level `"circuit_id"` in `$INTENT_NAME.tree` equals `e94efbee3e07ae4224ed1ae0a6389f5128d210ff7a2a743e459cff501e4379ab`, _regardless of which `$INTENT_NAME` you used_. This is the circuit ID of the final Axiom Aggregation 2 circuit, which is the same for all configurations because Axiom Aggregation 2 is a universal aggregation circuit. The `aggregate_vk_hash` commits to the aggregation configuration and is used to distinguish between them.

⚠️ **Special Note:** The `all_max.yml` configuration is very large. The largest proving key generated is 200 GB. To run `axiom-query-keygen` on `all_max.yml`, you need a machine with at least 500 GB of RAM, or enough [swap](https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-22-04) to make up the difference.
⚠️ **Special Note:** The `all_max.yml` and `all_max_st_depth_14` configurations are very large. The largest proving key generated is 200 GB. To run `axiom-query-keygen` on `all_max.yml`, you need a machine with at least 500 GB of RAM, or enough [swap](https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-22-04) to make up the difference.

4. Rename and forge format the Solidity SNARK verifier file for the `AxiomV2QueryVerifier` smart contract:

Expand All @@ -56,9 +65,16 @@ bash src/bin/rename_snark_verifier.sh $CIRCUIT_DATA_DIR/e94efbee3e07ae4224ed1ae0

The final Solidity file will be output to `AxiomV2QueryVerifier.sol`.

5. Compare the summary `*.tree` JSONs with the ones we use in production [here](./data/production/).
5. Compare the summary `*.tree` JSONs with the ones we use in production [here](./data/production/proof_trees/).

6. Check the top level aggregate vkey hashes in the `*.tree` JSONs match the ones we use in production:

- The list we use in production is provided [here](./data/production/aggregate_vk_hashes.json)
**Ethereum Mainnet**

- The list we use in production on is provided [here](./data/production/aggregate_vk_hashes/eth_mainnet.json)
- These aggregate vkey hashes are part of the constructor arguments of our `AxiomV2Query` smart contract on Ethereum mainnet: see [logs](https://etherscan.io/tx/0xab7e570b6fbcc78841a0a5bde473e47737285aabf5fb9fb4876bd2b8043d9301#eventlog).

**Base Mainnet**

- The list we use in production on is provided [here](./data/production/aggregate_vk_hashes/base_mainnet.json)
- These aggregate vkey hashes are part of the constructor arguments of our `AxiomV2Query` smart contract on Base mainnet: see [logs](https://basescan.org/tx/0x8d71fee1e78bd62c43b5c79e16d04dae5e008e73ff0519a58c814dce88e7feda#eventlog).
326 changes: 326 additions & 0 deletions axiom-query/configs/production/base_specific/all_128_each_default_st_depth_14.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,326 @@
AxiomAgg2:
k: 23
force_params:
num_advice: 1
num_lookup_advice: 1
num_fixed: 1
axiom_agg1_intent:
k: 22
force_params:
num_advice: 13
num_lookup_advice: 2
num_fixed: 1
intent_verify_compute:
k: 22
core_params:
subquery_results_capacity: 128
svk: "0100000000000000000000000000000000000000000000000000000000000000"
client_metadata:
version: 0
numAdvicePerPhase:
- 4
numLookupAdvicePerPhase:
- 1
numRlcColumns: 0
numFixed: 1
numInstance:
- 2304
numChallenge:
- 0
maxOutputs: 128
isAggregation: false
preprocessed_len: 13
loader_params:
comp_loader_params:
max_height: 5
shard_caps:
- 4000
intent_keccak:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Leaf:
k: 20
core_params:
capacity: 4000
intent_subquery_agg:
k: 22
deps:
- Header:
Node:
k: 21
num_children: 2
child_intent:
Leaf:
k: 21
core_params:
max_extra_data_bytes: 32
capacity: 132
loader_params:
comp_loader_params:
note: intent_keccak
max_height: 5
shard_caps:
- 4000
- Account:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Leaf:
k: 21
core_params:
capacity: 33
max_trie_depth: 14
loader_params:
- comp_loader_params:
note: intent_keccak
max_height: 5
shard_caps:
- 4000
- comp_loader_params:
note: Header
max_height: 1
shard_caps:
- 132
- Storage:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Leaf:
k: 21
core_params:
capacity: 33
max_trie_depth: 14
loader_params:
- comp_loader_params:
note: intent_keccak
max_height: 5
shard_caps:
- 4000
- comp_loader_params:
note: Account
max_height: 2
shard_caps:
- 33
- Tx:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Leaf:
k: 21
core_params:
chip_params:
max_data_byte_len: 8192
max_access_list_len: 4096
enable_types:
- true
- true
- true
capacity: 16
max_trie_depth: 6
loader_params:
- comp_loader_params:
note: intent_keccak
max_height: 5
shard_caps:
- 4000
- comp_loader_params:
note: Header
max_height: 1
shard_caps:
- 132
- Receipt:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Leaf:
k: 21
core_params:
chip_params:
max_data_byte_len: 1024
max_log_num: 80
topic_num_bounds:
- 0
- 4
capacity: 4
max_trie_depth: 6
loader_params:
- comp_loader_params:
note: intent_keccak
max_height: 5
shard_caps:
- 4000
- comp_loader_params:
note: Header
max_height: 1
shard_caps:
- 132
- SolidityMapping:
Node:
k: 21
num_children: 2
child_intent:
Node:
k: 21
num_children: 2
child_intent:
Leaf:
k: 21
core_params:
capacity: 32
loader_params:
- comp_loader_params:
note: intent_keccak
max_height: 5
shard_caps:
- 4000
- comp_loader_params:
note: Storage
max_height: 2
shard_caps:
- 33
- ResultsRoot:
Leaf:
k: 22
core_params:
enabled_types:
- false
- true
- true
- true
- true
- true
- true
capacity: 128
loader_params:
- comp_loader_params:
note: intent_keccak
max_height: 5
shard_caps:
- 4000
- params_per_component:
axiom-query:ComponentTypeHeaderSubquery:
max_height: 1
shard_caps:
- 132
- 132
axiom-query:ComponentTypeAccountSubquery:
max_height: 2
shard_caps:
- 33
- 33
- 33
- 33
axiom-query:ComponentTypeStorageSubquery:
max_height: 2
shard_caps:
- 33
- 33
- 33
- 33
axiom-query:ComponentTypeTxSubquery:
max_height: 3
shard_caps:
- 16
- 16
- 16
- 16
- 16
- 16
- 16
- 16
axiom-query:ComponentTypeReceiptSubquery:
max_height: 5
shard_caps:
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
- 4
axiom-query:ComponentTypeSolidityNestedMappingSubquery:
max_height: 2
shard_caps:
- 32
- 32
- 32
- 32
Loading
Loading