From c447655c82ba9d66b8bd58480038b1b5ac4130e7 Mon Sep 17 00:00:00 2001 From: baitcode Date: Tue, 14 Jan 2025 04:43:26 +0300 Subject: [PATCH 1/2] Prover parameters --- docs/pages/usage/parameters.md | 164 +++++++++++++++++++++++++++++ helpers/calculate_fri_step_list.py | 12 +-- test_generate_files.sh | 4 +- vocs.config.ts | 1 + 4 files changed, 169 insertions(+), 12 deletions(-) create mode 100644 docs/pages/usage/parameters.md diff --git a/docs/pages/usage/parameters.md b/docs/pages/usage/parameters.md new file mode 100644 index 00000000..6ab37be6 --- /dev/null +++ b/docs/pages/usage/parameters.md @@ -0,0 +1,164 @@ +### Stone prover parameters file format +```json +{ + "field": "PrimeField0", + "use_extension_field": false, + "stark": { + "fri": { + "fri_step_list": [4, 4, 2], + "last_layer_degree_bound": 64, + "n_queries": 18, + "proof_of_work_bits": 24 + }, + "log_n_cosets": 4 + }, + "verifier_friendly_channel_updates": true, + "verifier_friendly_commitment_hash": "poseidon3", + "channel_hash": "poseidon3", + "n_verifier_friendly_commitment_layers": 1000, + "pow_hash": "keccak256", + "commitment_hash": "keccak256_masked160_lsb", +} +``` + +### Stone prover parameters + +#### Prime field definition + +```json +{ + "field": "PrimeField0", + "use_extension_field": false, + ... +} +``` + +Fields `field` and `use_extension_field` define parameters for generation of +prime field ([finite field](https://en.wikipedia.org/wiki/Finite_field) modulus prime number) + +Available values for field `field`: +- TestField +- PrimeField0 +- PrimeField1 +- PrimeField2 +- PrimeField3 +- PrimeField4 +- LongField +- ExtensionLongField +- ExtensionTestField +- ExtensionPrimeField0 + +`PrimeField0` is a STARK compatible field with element size 252 bits. Should be picked for Cairo programs. `ExtensionPrimeField0` is also STARK compatible, operations in that field introduce computational overhead in exchange for better security. + +`use_extension_field` - is a flag that asserts that field selected in `field` is an extension field. In other words: it should be set to `true` if you picked one of: +`ExtensionLongField`, `ExtensionTestField`, `ExtensionPrimeField0` as a `field` value. + +#### STARK and Fast Reed-Solomon IOP of Proximity (FRI) + +This section configures parameters of the proof itself. + +```json +{ + ... + "stark": { + "fri": { + "fri_step_list": [4, 4, 2], + "last_layer_degree_bound": 64, + "n_queries": 18, + "proof_of_work_bits": 24 + }, + "log_n_cosets": 4 + }, + ... +} +``` + +`n_queries` - amount of checks to be performed against the proof the more queries the higher soundness. In order to achieve the required soundness of the protocol, the query phase is repeated multiple times. For a blowup factor of 2ⁿ, each query roughly contributes n bits of security. + +`log_n_cosets` - defines the size of the points where polinomial will be calculated (evaluation domain). The bigger the size of the coset the higher soundness FRI have, but also bloats prooving time. Reduce to make prooving faster. + +`fri` - The FRI protocol is crucial to the soundness of STARK proofs. It reduces the complexity of the proximity proofs generated by STARK and can be fine-tuned to balance performance and security. + +`fri_step_list` - The FRI step parameters do not affect the soundness of the proof, but they affect the proof length and verification time. By default it is recommended to use *[4, 4, 2]* value (see below). + +As you increase a certain FRI step, more values need to be revealed from the corresponding Merkle tree but the number of Merkle trees reduces. However, the number of values that is revealed is 2^step, so the step cannot be too big. +The last layer size plays a similar role - as you increase it you need less Merkle trees but reveal more values. Exact formula for calculation the optimal value is unknown but stone prover developers discovered that the array of size 3 usually provides best results. If the proof is large the recommendation is to start with a number \[4\] and end with number \[2\] or [2, 2]. +This example defines that the proof size will reduce by a factor of *4* for the first three steps, and by a factor of *2* at the last step. In case you encounter error during the proof generation that looks like: +``` +Fri parameters do not match stark degree bound. +Expected FRI degree from FriParameters: 8192. STARK: 2097152 +``` +Please, consult with `/helpers/calculate_fri_step_list.py`. This script will generate value for fri_step_list depending on desired FRI degree parameter. This script generates the steps value so that equation: +``` +log₂(last_layer_degree_bound) + ∑fri_step_list = log₂(#steps) + 4 +``` +would stand. + +`last_layer_degree_bound` - Another FRI optimization used to reduce the proof size is to terminate the FRI protocol earlier than when the last layer reaches a constant value. In such case, instead of having the prover send only the constant value of the last layer as a commitment, the prover sends the coefficients of the polynomial representing the last layer instead. This allows the verifier to complete the protocol as before, without the need for commitments (and sending decommitments for field elements in the smaller last layers). In our Alpha version, the FRI commit phase is typically terminated when it reaches a polynomial pⱼ of degree less than 64. The exact number may vary depending on the trace size. With that said last layer degree bound should be *32* or *64* + +`proof_of_work_bits` - (`proof_of_work_bits`): Adds (grinding) computational complexity for generating proofs to deter brute-force attacks. As mentioned above, every query adds a certain number of bits to the security (soundness) of the proof. However, it also implies sending more decommitments by the prover which increases proof size. One mechanism to reduce the need for many queries is to increase the cost of generating a false proof by a malicious prover. We achieve this by adding to the above protocol a requirement that following all the commitments made by the prover, it also finds a 256 bit nonce that hashed together with the state of the hash chain results in a predefined template of a required length. The length of the template defines a certain amount of work that the prover must perform before generating the randomness representing the queries. As a result, a malicious prover that attempts to generate favorable queries will need to repeat the grinding process every time that a commitment is changed. On the other hand, an honest prover, only needs to perform grinding once. + +For example: + +```json +"proof_of_work_bits": 24 +``` + +### Proof optimisation + +To summarize the above: + +`n_queries` - If you decrease n_queries, then verification time goes down. Soundness and gets worse, proof size gets less. Can be traded for `proof_of_work_bits` or/and `log_n_cosets`. + +`proof_of_work_bits` - If you decrease proof_of_work_bits proof generation time goes down. Soundness gets worse. Can be traded for n_queries (more proof_of_work_bits for less queries). + +`fri_step_list` - less layers, less proof size, but increased verification time. + +`log_n_cosets` - decrease to decrease verification time. Can be traded for n_queries. More `n_queries` - less `log_n_cosets`. + +### Air verifier parameters + +```json +{ + ... + "verifier_friendly_channel_updates": true, + "verifier_friendly_commitment_hash": "poseidon3", + "channel_hash": "poseidon3", + "n_verifier_friendly_commitment_layers": 1000, + "pow_hash": "keccak256", + "commitment_hash": "keccak256_masked160_lsb", + ... +} +``` + +These parameters are often found in configuration files related to the verifier, and they aim to optimize the verification process. + +`verifier_friendly_channel_updates - If true, sets input hash function for channel to verifier_friendly_channel_updates value. + +```json +"verifier_friendly_channel_updates": true +``` + +verifier_friendly_commitment_hash - Specifies the type of hash function used for the verifier's commitment, optimized for verification. Example: + +```json +"verifier_friendly_commitment_hash": "poseidon3" +``` + +`channel_hash` - Specifies the hash function used for secure communication between the prover and verifier. Example: + +```json +"channel_hash": "poseidon3" +``` + +`commitment_hash` - Hash function used for generating commitments, which are crucial for zero-knowledge proofs. + +```json +"commitment_hash": "keccak256_masked160_lsb" +``` + +`pow_hash` - Defines the hash used for proof-of-work, ensuring security in proof generation. + +```json +"pow_hash": "keccak256" +``` \ No newline at end of file diff --git a/helpers/calculate_fri_step_list.py b/helpers/calculate_fri_step_list.py index 949c528f..83e31d59 100644 --- a/helpers/calculate_fri_step_list.py +++ b/helpers/calculate_fri_step_list.py @@ -1,4 +1,5 @@ import sys +import math ''' Whenever you encounter error like: @@ -23,17 +24,8 @@ to_process = desired_degree_bound // last_layer_degree_bound -def highest_power_of_2_in(n): - power = 0 - - while n % 2 == 0: - n //= 2 - power += 1 - - return power - fri_step_list = [] -highest_power_of_2 = highest_power_of_2_in(to_process) +highest_power_of_2 = math.log2(to_process) while True: if highest_power_of_2 <= 4: diff --git a/test_generate_files.sh b/test_generate_files.sh index 5a179f18..3aff0621 100755 --- a/test_generate_files.sh +++ b/test_generate_files.sh @@ -3,8 +3,8 @@ # TODO(baitcode): Should live in a scripts folder CAIRO1_RUNNER=../cairo-vm/cairo1-run -TEST_FILES=$(pwd)/test_files -PROGRAMS_DIR=$(pwd)/e2e_test/Cairo +TEST_FILES=$(pwd)/docs/test_files +PROGRAMS_DIR=$(pwd)/docs/e2e_test/Cairo ESCAPED_PWD=$(printf '%s' "$(pwd)" | sed 's/[\/&]/\\&/g') # TODO(baitcode): should be moved out of the script to a common place diff --git a/vocs.config.ts b/vocs.config.ts index a2b8faf0..8cb747fa 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -47,6 +47,7 @@ export default defineConfig({ items: [ { text: "Generating execution artifacts", link: "/usage/execution" }, { text: "Stone Prover configuration", link: "/usage/configuration" }, + { text: "Stone Prover parameters file", link: "/usage/parameters" }, { text: "Proving execution", link: "/usage/proving" }, { text: "Verifying proof", link: "/usage/verifying" }, ], From 144cda8947a5a778069db7342ac74f136cc03ba4 Mon Sep 17 00:00:00 2001 From: baitcode Date: Wed, 15 Jan 2025 01:57:53 +0300 Subject: [PATCH 2/2] Remove old page Better hash description --- docs/pages/usage/configuration.md | 234 ------------------------------ docs/pages/usage/parameters.md | 45 +++--- vocs.config.ts | 1 - 3 files changed, 23 insertions(+), 257 deletions(-) delete mode 100644 docs/pages/usage/configuration.md diff --git a/docs/pages/usage/configuration.md b/docs/pages/usage/configuration.md deleted file mode 100644 index 8b9eee97..00000000 --- a/docs/pages/usage/configuration.md +++ /dev/null @@ -1,234 +0,0 @@ -## Stone Prover Configuration - -This guide will explain how to create a configuration file for the Stone prover, focusing on the security settings of the FRI protocol and the format of the configuration file. It also covers detailed instructions on configuring specific parameters for an optimal balance between security and performance. - -### 1. Overview of the Stone Prover Configuration - -The Stone Prover Configuration defines the parameters that govern how the Stone prover operates in proving systems based on the STARK protocol. These configurations can significantly affect both the performance and security of the proving and verification processes. The configuration is stored in JSON files, such as `cpu_air_params.json` and `cpu_air_prover_config.json`, which allow the user to set up various aspects of the prover and verifier interaction. - -A breakdpwn of key areas in Stone Prover configuration: - -**i. Field Configuration** - -The field configuration is one of the most fundamental aspects of the proving system, as it defines the arithmetic field in which computations take place. - -Field Type (`field`): The proving system relies on operations in a specific prime field. This configuration option defines the field. For example: - - `"field": "PrimeField0"` - - In this example, computations are performed in a prime field denoted as `PrimeField0`. - -**ii. STARK Configuration** - -This section encompasses the STARK-related configurations, which include how the Fast Reed-Solomon Interactive Oracle Proofs of Proximity (FRI) protocol is set up. - -FRI Protocol (`fri`): The FRI protocol is crucial to the soundness of STARK proofs. It reduces the complexity of the proximity proofs generated by STARK and can be fine-tuned to balance performance and security. - -Step List (`fri_step_list`): A list that controls the size of the proof at each step of the FRI process. Each number represents the rate at which the proof size decreases in the corresponding step. For instance: - - `"fri_step_list": [4, 4, 4, 1]` - -This configuration defines that the proof size will reduce by a factor of 4 for the first three steps, and by a factor of 1 at the last step. - -* **Last Layer Degree Bound** (`last_layer_degree_bound`): Specifies the maximum degree of the polynomial at the last layer, ensuring the proof’s accuracy. Example: - - `"last_layer_degree_bound": 64` - -* **Number of Queries** (`n_queries`): Determines the number of proximity queries performed to validate the proof. A higher value increases security but also increases the cost of the verification process. - - `"n_queries": 18` - -* **Proof of Work Bits** (`proof_of_work_bits`): Adds computational complexity for generating proofs to deter brute-force attacks. For example: - - `"proof_of_work_bits": 24` - -* **Cosets** (`log_n_cosets`): This parameter defines how many cosets (subgroups of elements) are involved in the polynomial evaluations of the STARK protocol. - -* **Use of Extension Fields** (`use_extension_field`): In some cases, extension fields may be used to enhance security. Setting this parameter to `false` disables this feature: - - `"use_extension_field": false ` - -**iii. **Prover Configuration**** - -The prover configuration is another critical section that governs how the prover operates during the proof generation phase. - - * **Cached LDE Configuration** (`cached_lde_config`): LDE (Low Degree Extension) is an important optimization for speeding up polynomial evaluations. The `cached_lde_config` object holds settings to control whether to store the full LDE and whether to use FFT (Fast Fourier Transform) for evaluations. - - * **Store Full LDE** (`store_full_lde`): If set to `true`, the full Low Degree Extension is cached, potentially speeding up subsequent operations but using more memory. Example: - - `"store_full_lde": false` - - * **Use FFT for Evaluation** (`use_fft_for_eval`): Determines whether to use FFT to accelerate polynomial evaluations. For example: - - `"use_fft_for_eval": false` - -* **Constraint Polynomial Task Size** (`constraint_polynomial_task_size`): This defines the size of tasks for evaluating constraint polynomials, influencing the prover's parallelism. - - `"constraint_polynomial_task_size": 256` - -* **Out-of-Memory Merkle Layers** (`n_out_of_memory_merkle_layers`): This parameter controls the number of Merkle layers that are processed out-of-memory. Increasing this can reduce the memory footprint but may slow down the proving process. - - `"n_out_of_memory_merkle_layers": 1` - -* **Table Prover Tasks** (`table_prover_n_tasks_per_segment`): Specifies the number of tasks assigned to each segment during proof generation. This impacts how the prover workload is distributed. - - `"table_prover_n_tasks_per_segment": 32` - -**iv. **Verifier Settings**** - -These parameters are often found in configuration files related to the verifier, and they aim to optimize the verification process. - -* **Verifier-Friendly Channel Updates**(`verifier_friendly_channel_updates`): If true, this option configures the prover to update the verification channel in a way that simplifies verification. - - `"verifier_friendly_channel_updates": true` - -* **Verifier-Friendly Commitment Hash** (`verifier_friendly_commitment_hash`): Specifies the type of hash function used for the verifier's commitment, optimized for verification. Example: - - `"verifier_friendly_commitment_hash": "poseidon3"` - -**V. Hash Function** - -Several cryptographic hash functions are utilized in the configuration for security purposes: - -* **Channel Hash** (`channel_hash`): Specifies the hash function used for secure communication between the prover and verifier. Example: - - `"channel_hash": "poseidon3"` - -* **Commitment Hash** (`commitment_hash`): Hash function used for generating commitments, which are crucial for zero-knowledge proofs. - - `"commitment_hash": "keccak256_masked160_lsb"` - -* **Proof-of-Work Hash** (`pow_hash`): Defines the hash used for proof-of-work, ensuring security in proof generation. - - `"pow_hash": "keccak256"` - -### 2. Security Settings fof the FRI Protocol - -In the context of the `STARK` proof system, the FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity) protocol is an essential part of ensuring the soundness of the proof by reducing the proximity query overhead. Key security settings related to FRI are: - - * `fri_step_list`: This list defines the step sizes used in FRI, where each entry specifies the reduction rate in proof size at each FRI layer. Larger numbers indicate fewer layers but bigger proofs. For example: - - `"fri_step_list": [4, 4, 4, 1]` - - This shows that in the first three layers, the proof size reduces by a factor of 4, and in the final layer by a factor of 1. - - * `last_layer_degree_bound`: This parameter represents the maximum degree of the polynomial in the last layer. Setting this value helps in bounding the error probability. For example: - - `"last_layer_degree_bound": 64` - - * `n_queries`: This is the number of proximity queries performed in the proof to ensure correctness. Higher values increase security at the cost of efficiency. For Example: - - `"n_queries": 18` - - * `proof_of_work_bits`: This determines the computational difficulty of proof generation, acting as a deterrent against brute force attacks. For example: - - `"proof_of_work_bits": 24` - -### 3. Configuration File Format -The configuration file typically contains parameters that define how the prover and verifier should function in a STARK system, with particular focus on FRI parameters. Here are key sections in the configuration files, as observed from your examples: - -Example Structure (`cpu_air_params.json`) - -```json -{ - "field": "PrimeField0", - "stark": { - "fri": { - "fri_step_list": [4, 4, 4, 1], - "last_layer_degree_bound": 64, - "n_queries": 18, - "proof_of_work_bits": 24 - }, - "log_n_cosets": 4 - }, - "use_extension_field": false -} -``` - -* `field`: Specifies the type of prime field used in computations (e.g., PrimeField0). - -* `stark`: Contains the main STARK settings. - - * `fri`: Includes all the FRI-related configurations (described above). - - * `log_n_cosets`: Determines the number of cosets (subgroups of elements) involved in polynomial evaluation. Example: - - `"log_n_cosets": 4` - -* `use_extension_field`: Indicates whether or not to use an extension field for higher security. Example: - - `"use_extension_field": false` - -Example Structure (`cpu_air_prover_config.json`) - -```json -{ - "cached_lde_config": { - "store_full_lde": false, - "use_fft_for_eval": false - }, - "constraint_polynomial_task_size": 256, - "n_out_of_memory_merkle_layers": 1, - "table_prover_n_tasks_per_segment": 32 -} -``` - -* `cached_lde_config`: Configures caching for Low Degree Extension (LDE). - - * `store_full_lde`: If `true`, the full LDE will be stored for later use. Example: - - `"store_full_lde"`: false - - * `use_fft_for_eval`: Determines if FFT (Fast Fourier Transform) should be used for evaluation. Example: - - `"use_fft_for_eval": false` - -* `constraint_polynomial_task_size`: Defines the task size for constraint polynomial evaluation. Example: - - `"constraint_polynomial_task_size": 256` - -* `n_out_of_memory_merkle_layers`: Specifies the number of Merkle layers processed out of memory to reduce computational load. Example: - - `"n_out_of_memory_merkle_layers": 1` - - * `table_prover_n_tasks_per_segment`: Defines the number of tasks assigned per table segment during proving. Example: - - `"table_prover_n_tasks_per_segment": 32` - -**3.1 How to Create a Configuration File** - -creating a configuration file for a Stone Prover, follow these steps: - -i. Step 1: Define the basic STARK settings, focusing on the FRI protocol configurations. Start by deciding on `fri_step_list`, `last_layer_degree_bound`, `n_queries`, and `proof_of_work_bits` based on your security requirements. - -ii. Step 2: Specify additional fields like `log_n_cosets` and `use_extension_field` based on whether you're using an extension field for added security. - -iii. Step 3: For prover-specific settings (as shown in `cpu_air_prover_config.json`), decide on the task size for constraint polynomial evaluations, whether to store the full LDE, and how many tasks are assigned per segment. - -iv. Step 4: Save the configuration file in a `.json` format, adhering to the structure outlined above. -Example of a custom Configuration File: - -**3.2 Example of a Configuration File** - -```json -{ -"field": "PrimeField0", -"stark": { - "fri": { - "fri_step_list": [4, 4, 4, 1], - "last_layer_degree_bound": 64, - "n_queries": 18, - "proof_of_work_bits": 24 - }, - "log_n_cosets": 4 -}, -"use_extension_field": false, -"cached_lde_config": { - "store_full_lde": false, - "use_fft_for_eval": false -}, -"constraint_polynomial_task_size": 256, -"n_out_of_memory_merkle_layers": 1, -"table_prover_n_tasks_per_segment": 32 -} -``` diff --git a/docs/pages/usage/parameters.md b/docs/pages/usage/parameters.md index 6ab37be6..17f1ac28 100644 --- a/docs/pages/usage/parameters.md +++ b/docs/pages/usage/parameters.md @@ -106,6 +106,8 @@ For example: ### Proof optimisation +Important fact: the num of security bits for the stone proof calculated by (n_queries * log_n_cosets) + proof_of_work_bits. + To summarize the above: `n_queries` - If you decrease n_queries, then verification time goes down. Soundness and gets worse, proof size gets less. Can be traded for `proof_of_work_bits` or/and `log_n_cosets`. @@ -122,43 +124,42 @@ To summarize the above: { ... "verifier_friendly_channel_updates": true, + "n_verifier_friendly_commitment_layers": 1000, + "verifier_friendly_commitment_hash": "poseidon3", "channel_hash": "poseidon3", - "n_verifier_friendly_commitment_layers": 1000, "pow_hash": "keccak256", "commitment_hash": "keccak256_masked160_lsb", ... } ``` -These parameters are often found in configuration files related to the verifier, and they aim to optimize the verification process. -`verifier_friendly_channel_updates - If true, sets input hash function for channel to verifier_friendly_channel_updates value. +#### Hashes -```json -"verifier_friendly_channel_updates": true -``` +These parameters are often found in configuration files related to the verifier, and they aim to optimize the verification process. -verifier_friendly_commitment_hash - Specifies the type of hash function used for the verifier's commitment, optimized for verification. Example: +`commitment_hash` - Hash function used for generating commitments, which are crucial for zero-knowledge proofs. Default value: `keccak256_masked160_msb`. -```json -"verifier_friendly_commitment_hash": "poseidon3" -``` +`channel_hash` - Specifies the input hash function used for transcript channel security. Transcript used for exchanging data between prover and verifier. All queries are communicated over it. +Default value is `keccak256`. -`channel_hash` - Specifies the hash function used for secure communication between the prover and verifier. Example: +`verifier_friendly_channel_updates` - If verifier_friendly_channel_updates is true, then the channel initialization is performed by a hash of the verifier friendly hash function (`n_verifier_friendly_commitment_layers` layers are being created), and afterwards the channel continues to produce numbers based on the channel_hash function. Otherwise, the channel_hash is used for the entire process. Deafult value is `false`. -```json -"channel_hash": "poseidon3" -``` +`verifier_friendly_commitment_hash` - Specifies the type of hash function used for the verifier's commitment, optimized for verification. Default value is taken from `commitment_hash`. -`commitment_hash` - Hash function used for generating commitments, which are crucial for zero-knowledge proofs. +`n_verifier_friendly_commitment_layers` - defines the number of layers in transcript that have the `verifier_friednly_commitment_hash`, the rest of the layers (bigger ones) are defined by `commitment_hash` - This is basically tradeoff, you can increase the number of layers that use zk friendly hash function (eg poseidon) to make verification cheaper, but proving will be longer -```json -"commitment_hash": "keccak256_masked160_lsb" -``` +`pow_hash` - Defines the hash used for proof-of-work, ensuring security in proof generation. Default value is `blake256`. This hash function must produce 256 bit long digest (can't be poseidon) -`pow_hash` - Defines the hash used for proof-of-work, ensuring security in proof generation. +`commitment_hash`, `channel_hash`, `verifier_friendly_channel_updates`, `verifier_friendly_commitment_hash`, `verifier_friendly_commitment_hash`, `pow_hash` - are all different hash functions. Available set of hash function names can be defined as follows: + +- "keccak256" - Keccak hash with 256 bit digest. +- "blake2s256" - Blake hash with 256 bit digest. +- "pedersen" - Pedersen Keccak hash with 256 bit digest. +- "poseidon3" - Poseidon3 Keccak hash with 252 bit digest. +- "keccak256_masked_160_msb" - This is similar to `keccak256` but the size of digest is truncated to 160 bits, 96 least significant bits are thrown away. +- "blake2s256_masked_160_msb" - This is similar to `blake2s256` but the size of digest is truncated to 160 bits, 96 least significant bits are thrown away. +- "blake2s256_masked_248_lsb" - This is similar to `blake2s256` but the size of digest is truncated to 248 bits, 8 most significant bits are thrown away. +- "keccak256_masked_160_lsb" - This is similar to `keccak256` but the size of digest is truncated to 248 bits, 96 most significant bits are thrown away. -```json -"pow_hash": "keccak256" -``` \ No newline at end of file diff --git a/vocs.config.ts b/vocs.config.ts index 8cb747fa..3bd7bcc1 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -46,7 +46,6 @@ export default defineConfig({ collapsed: true, items: [ { text: "Generating execution artifacts", link: "/usage/execution" }, - { text: "Stone Prover configuration", link: "/usage/configuration" }, { text: "Stone Prover parameters file", link: "/usage/parameters" }, { text: "Proving execution", link: "/usage/proving" }, { text: "Verifying proof", link: "/usage/verifying" },