succinctlabs · yuwen01 · Oct 29, 2024 · Oct 29, 2024 · Oct 29, 2024 · Nov 5, 2024
diff --git a/book/developers/common-issues.md b/book/developers/common-issues.md
@@ -8,7 +8,7 @@ If you are using a library that has an MSRV specified, you may encounter an erro
 package `alloy v0.1.1 cannot be built because it requires rustc 1.76 or newer, while the currently active rustc version is 1.75.0-nightly`
 ```
 
-This is due to the fact that your current Succinct Rust toolchain has been built with a lower version than the MSRV of the crates you are using. 
+This is due to the fact that your current Succinct Rust toolchain has been built with a lower version than the MSRV of the crates you are using.
 
 You can check the version of your local Succinct Rust toolchain by running `cargo +succinct --version`. The latest release of the Succinct Rust toolchain is **1.81**. You can update to the latest version by running [`sp1up`](../getting-started/install.md).
 

diff --git a/book/generating-proofs/basics.md b/book/generating-proofs/basics.md
@@ -12,8 +12,6 @@ To make this more concrete, let's walk through a simple example of generating a
 
 You can run the above script in the `script` directory with `RUST_LOG=info cargo run --release`. Note that running the above script will generate a proof locally.
 
-<div class="warning">
-WARNING: Local proving often is much slower than the prover network and for certain proof types (e.g. Groth16, PLONK) require a significant amount of RAM and will likely not work on a laptop.
-</div>
+> WARNING: Local proving often is much slower than the prover network and for certain proof types (e.g. Groth16, PLONK) require a significant amount of RAM and will likely not work on a laptop.
 
 We recommend using the [prover network](./prover-network.md) to generate proofs. Read more about the [recommended workflow](./recommended-workflow.md) for developing with SP1.
diff --git a/book/generating-proofs/hardware-acceleration.md b/book/generating-proofs/hardware-acceleration.md
@@ -1,7 +1,8 @@
 # Hardware Acceleration
 
 SP1 supports hardware acceleration on the following platforms:
+
 - [AVX256/AVX512](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) on x86 CPUs
 - [CUDA](https://en.wikipedia.org/wiki/CUDA) on Nvidia GPUs
 
-To enable hardware acceleration, please refer to the platform specific instructions available in this section.
+To enable hardware acceleration, please refer to the platform specific instructions available in this section.
diff --git a/book/generating-proofs/hardware-acceleration/avx.md b/book/generating-proofs/hardware-acceleration/avx.md
@@ -27,4 +27,4 @@ To enable AVX512 acceleration, you can set the `RUSTFLAGS` environment variable
 RUSTFLAGS="-C target-cpu=native -C target-feature=+avx512f" cargo run --release
 ```
 
-Note that the `+avx512f` flag is required to enable AVX512 acceleration.
+Note that the `+avx512f` flag is required to enable AVX512 acceleration.
diff --git a/book/generating-proofs/hardware-acceleration/cuda.md b/book/generating-proofs/hardware-acceleration/cuda.md
@@ -1,9 +1,6 @@
 # CUDA
 
-<div class="warning">
-WARNING: CUDA proving is still an experimental feature and may be buggy.
-</div>
-
+> WARNING: CUDA proving is still an experimental feature and may be buggy.
 
 SP1 supports CUDA acceleration, which can provide dramatically better latency and cost performance
 compared to using the CPU prover, even with AVX acceleration.
@@ -23,4 +20,4 @@ Please make sure you have the following installed before using the CUDA prover:
 ## Usage
 
 To use the CUDA prover, you can compile the `sp1-sdk` crate with the `cuda` feature enabled. You
-can use the normal methods on the `ProverClient` to generate proofs.
+can use the normal methods on the `ProverClient` to generate proofs.
diff --git a/book/generating-proofs/proof-types.md b/book/generating-proofs/proof-types.md
@@ -4,7 +4,7 @@ There are a few different types of proofs that can be generated by the SP1 zkVM.
 
 The `ProverClient` follows a "builder" pattern that allows you to configure the proof type and other options after creating a `ProverClient` and calling `prove` on it.
 
-For a full list of options, see the following [docs](https://docs.rs/sp1-sdk/1.2.0/sp1_sdk/action/struct.Prove.html).
+For a full list of options, see the following [docs](https://docs.rs/sp1-sdk/latest/sp1_sdk/action/struct.Prove.html).
 
 ## Core (Default)
 
@@ -28,7 +28,7 @@ client.prove(&pk, stdin).compressed().run().unwrap();
 
 ## Groth16 (Recommended)
 
-The Groth16 prover mode generates a SNARK proof that is ~260 bytes large and can be verified onchain for around ~270k gas. 
+The Groth16 prover mode generates a SNARK proof that is ~260 bytes large and can be verified onchain for around ~270k gas.
 
 The trusted setup for the Groth16 circuit keys uses the [Aztec Ignition ceremony](https://github.com/AztecProtocol/ignition-verification) + entropy contributions from members of the Succinct team.
 

diff --git a/book/generating-proofs/prover-network/key-setup.md b/book/generating-proofs/prover-network/key-setup.md
@@ -4,7 +4,7 @@ The prover network uses Secp256k1 keypairs for authentication, similar to Ethere
 
 > **You do not need to hold any funds in this account, it is used solely for access control.**
 
-### Generate a Public Key
+## Generate a Public Key
 
 Prover network keypair credentials can be generated using the
 [cast](https://book.getfoundry.sh/cast/) CLI tool.
@@ -31,7 +31,7 @@ The "Address" what you should submit in the [form](https://forms.gle/rTUvhstS8PF
 secure. When interacting with the network, you will set your `SP1_PRIVATE_KEY` environment variable
 to this value.
 
-### Retrieve an Existing Key
+## Retrieve an Existing Key
 
 If you already have an existing key you would like to use, you can also use `cast` retrieve your address:
 

diff --git a/book/generating-proofs/setup.md b/book/generating-proofs/setup.md
@@ -20,7 +20,7 @@ cargo new script
 cd script
 ```
 
-#### Cargo Manifest
+### Cargo Manifest
 
 Inside this crate, add the `sp1-sdk` crate as a dependency. Your `Cargo.toml` should look like as follows:
 

diff --git a/book/generating-proofs/sp1-sdk-faq.md b/book/generating-proofs/sp1-sdk-faq.md
@@ -12,4 +12,4 @@ Example of setting the logging level to `info` (other options are `debug`, `trac
 
 ```bash
 RUST_LOG=info cargo run --release
-```
+```
diff --git a/book/getting-started/hardware-requirements.md b/book/getting-started/hardware-requirements.md
@@ -1,12 +1,9 @@
 # Proof Generation Requirements
 
-<div class="warning">
-We recommend that developers who want to use SP1 for non-trivial programs generate proofs on our prover network. The prover network generates SP1 proofs across multiple machines, reducing latency and also runs SP1 on optimized hardware instances that result in faster + cheaper proof generation times.
+> WARNING: We recommend that developers who want to use SP1 for non-trivial programs generate proofs on our prover network. The prover network generates SP1 proofs across multiple machines, reducing latency and also runs SP1 on optimized hardware instances that result in faster + cheaper proof generation times.
 
 We recommend that for any production benchmarking, you use the prover network to estimate latency and costs of proof generation.
 
-</div>
-
 ## Local Proving
 
 If you want to generate SP1 proofs locally, this section has an overview of the hardware requirements required. These requires depend on which [types of proofs](../generating-proofs/proof-types.md) you want to generate and can also change over time as the design of the zKVM evolves.

diff --git a/book/getting-started/install.md b/book/getting-started/install.md
@@ -41,6 +41,7 @@ You can check the version of the Succinct Rust toolchain by running:
 ```bash
 RUSTUP_TOOLCHAIN=succinct cargo --version
 ```
+
 or equivalently:
 
 ```bash
@@ -75,12 +76,9 @@ Or, you can remove the `cargo-prove` that was installed through `sp1up`:
 rm ~/.sp1/bin/cargo-prove
 ```
 
-
 ## Option 2: Building from Source
 
-<div class="warning">
-Warning: This option will take a long time to build and is only recommended for advanced users. 
-</div>
+> WARNING: This option will take a long time to build and is only recommended for advanced users.
 
 Make sure you have installed the [dependencies](https://github.com/rust-lang/rust/blob/master/INSTALL.md#dependencies) needed to build the rust toolchain from source.
 

diff --git a/book/getting-started/quickstart.md b/book/getting-started/quickstart.md
@@ -29,7 +29,7 @@ git clone https://github.com/succinctlabs/sp1-project-template.git
 
 Your new project will have the following structure (ignoring the `contracts` folder, if you are using the project template):
 
-```
+```console
 .
 ├── program
 │   ├── Cargo.lock
@@ -51,7 +51,8 @@ Your new project will have the following structure (ignoring the `contracts` fol
 6 directories, 4 files
 ```
 
-There are 2 directories (each a crate) in the project: 
+There are 2 directories (each a crate) in the project:
+
 - `program`: the source code that will be proven inside the zkVM.
 - `script`: code that contains proof generation and verification code.
 
@@ -62,17 +63,17 @@ Note that if you use `cargo prove new` inside a monorepo, you will need to add t
 
 Before we can run the program inside the zkVM, it must be compiled to a RISC-V executable using the `succinct` Rust toolchain. This is called an [ELF (Executable and Linkable Format)](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format). To compile the program, you can run the following command:
 
-```
+```bash
 cd program && cargo prove build
 ```
 
-which will output the compiled ELF to the file `program/elf/riscv32im-succinct-zkvm-elf`. 
+which will output the compiled ELF to the file `program/elf/riscv32im-succinct-zkvm-elf`.
 
 Note: the `build.rs` file in the `script` directory will use run the above command automatically to build the ELF, meaning you don't have to manually run `cargo prove build` every time you make a change to the program!
 
 ## Execute
 
-To test your program, you can first execute your program without generating a proof. In general this is helpful for iterating on your program and verifying that it is correct. 
+To test your program, you can first execute your program without generating a proof. In general this is helpful for iterating on your program and verifying that it is correct.
 
 ```bash
 cd ../script
@@ -89,7 +90,8 @@ RUST_LOG=info cargo run --release -- --prove
 ```
 
 The output should show something like this:
-```
+
+```console
 n: 20
 2024-07-23T17:07:07.874856Z  INFO prove_core:collect_checkpoints: clk = 0 pc = 0x2017e8
 2024-07-23T17:07:07.876264Z  INFO prove_core:collect_checkpoints: close time.busy=2.00ms time.idle=1.50µs
@@ -110,7 +112,7 @@ Successfully generated proof!
 fib(n): 10946
 ```
 
-The program by default is quite small, so proof generation will only take a few seconds locally. After it generates, the proof will be verified for correctness. 
+The program by default is quite small, so proof generation will only take a few seconds locally. After it generates, the proof will be verified for correctness.
 
 **Note:** When benchmarking proof generation times locally, it is important to note that there is a fixed overhead for proving, which means that the proof generation time for programs with a small number of cycles is not representative of the performance of larger programs (which often have better performance characteristics as the overhead is amortized across many cycles).
 
@@ -121,4 +123,3 @@ Please see the [Recommended Workflow](../generating-proofs/recommended-workflow.
 We *strongly recommend* that developers who want to use SP1 for non-trivial programs generate proofs on the beta version of our [Prover Network](../generating-proofs/prover-network.md). The prover network generates SP1 proofs across multiple machines, reducing latency and also runs SP1 on optimized hardware instances that result in faster + cheaper proof generation times.
 
 We recommend that for any production benchmarking, you use the prover network to estimate latency and costs of proof generation. We also would love to chat with your team directly to help you get started with the prover network--please fill out this [form](https://partner.succinct.xyz/).
-
diff --git a/book/introduction.md b/book/introduction.md
@@ -4,10 +4,9 @@
 
 [![Telegram Chat][tg-badge]][tg-url]
 
-![](./sp1.png)
+![SP1 Logo](./sp1.png)
 
-
-SP1 is a performant, open-source zero-knowledge virtual machine (zkVM) that verifies the execution of arbitrary Rust (or any LLVM-compiled language) programs. 
+SP1 is a performant, open-source zero-knowledge virtual machine (zkVM) that verifies the execution of arbitrary Rust (or any LLVM-compiled language) programs.
 
 [tg-badge]: https://img.shields.io/endpoint?color=neon&logo=telegram&label=chat&url=https%3A%2F%2Ftg.sumanjay.workers.dev%2Fsuccinct%5Fsp1
 [tg-url]: https://t.me/+AzG4ws-kD24yMGYx
@@ -16,11 +15,10 @@ SP1 has undergone multiple audits from leading ZK security firms and is currentl
 
 ## The future of ZK is writing normal code
 
-Zero-knowledge proofs (ZKPs) are one of the most critical technologies to blockchain scaling, interoperability and privacy. But, historically building ZKP systems was extremely complicated--requiring large teams with specialized cryptography expertise and taking years to go to production. 
+Zero-knowledge proofs (ZKPs) are one of the most critical technologies to blockchain scaling, interoperability and privacy. But, historically building ZKP systems was extremely complicated--requiring large teams with specialized cryptography expertise and taking years to go to production.
 
 SP1 provides a performant, general-purpose zkVM that enables **any developer** to use ZKPs by writing normal code (in Rust), and get cheap and fast proofs. SP1 will enable ZKPs to become mainstream, introducing a new era of verifiability for all of blockchain infrastructure and beyond.
 
-
 ## SP1 enables a diversity of use-cases
 
 ZKPs enable a diversity of use-cases in blockchain and beyond, including:

diff --git a/book/what-is-a-zkvm.md b/book/what-is-a-zkvm.md
@@ -17,19 +17,17 @@ For blockchain applications, the verification usually happens inside of a [smart
 
 At a high level, SP1 works with the following steps:
 
-* Write a program in Rust that defines the logic of your computation for which you want to generate a ZKP.
-* Compile the program to the RISC-V ISA (a standard Rust compilation target) using the `cargo prove` CLI tool (installation instructions [here](./getting-started/install.md)) and generate a RISC-V ELF file.
-* SP1 will prove the correct execution of arbitrary RISC-V programs by generating a STARK proof of execution.
-* Developers can leverage the `sp1-sdk` crate to generate proofs with their ELF and input data. Under the hood the `sp1-sdk` will either generate proofs locally or use a beta version of Succinct's prover network to generate proofs.
+- Write a program in Rust that defines the logic of your computation for which you want to generate a ZKP.
+- Compile the program to the RISC-V ISA (a standard Rust compilation target) using the `cargo prove` CLI tool (installation instructions [here](./getting-started/install.md)) and generate a RISC-V ELF file.
+- SP1 will prove the correct execution of arbitrary RISC-V programs by generating a STARK proof of execution.
+- Developers can leverage the `sp1-sdk` crate to generate proofs with their ELF and input data. Under the hood the `sp1-sdk` will either generate proofs locally or use a beta version of Succinct's prover network to generate proofs.
 
 SP1 leverages performant STARK recursion that allows us to prove the execution of arbitrarily long programs and also has a STARK -> SNARK "wrapping system" that allows us to generate small SNARK proofs that can be efficiently verified on EVM chains.
 
-## Proof System 
+## Proof System
 
 For more technical details, check out the SP1 technical note that explains our proof system in detail. In short, we use:
 
-* STARKs + FRI over the Baby Bear field
-* We use performant STARK recursion that allows us to prove the execution of arbitrarily long programs
-* We have a system of performant precompiles that accelerate hash functions and cryptographic signature verification that allow us to get substantial performance gains on blockchain workloads
-
-
+- STARKs + FRI over the Baby Bear field
+- We use performant STARK recursion that allows us to prove the execution of arbitrarily long programs
+- We have a system of performant precompiles that accelerate hash functions and cryptographic signature verification that allow us to get substantial performance gains on blockchain workloads
diff --git a/book/why-use-sp1.md b/book/why-use-sp1.md
@@ -7,8 +7,9 @@ Zero-knowledge proofs (ZKPs) are a powerful primitive that enable **verifiable c
 Historically, building ZKP systems has been extremely complicated, requiring large teams with specialized cryptography expertise and taking years to go to production. SP1 is a performant, general-purpose zkVM that solves this problem and creates a future where all blockchain infrastructure, including rollups, bridges, coprocessors, and more, utilize ZKPs **via maintainable software written in Rust**.
 
 SP1 is especially powerful in blockchain contexts which rely on verifiable computation. Example applications include:
+
 - [Rollups](https://ethereum.org/en/developers/docs/scaling/zk-rollups/): SP1 can be used in combination with existing node infrastructure like [Reth](https://github.com/paradigmxyz/reth) to build rollups with ZKP validity proofs or ZK fraud proofs.
-- [Coprocessors](https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA): SP1 can be used to outsource onchain computation to offchain provers to enable use cases such as large-scale computation over historical state and onchain machine learning, dramatically reducing gas costs. 
+- [Coprocessors](https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA): SP1 can be used to outsource onchain computation to offchain provers to enable use cases such as large-scale computation over historical state and onchain machine learning, dramatically reducing gas costs.
 - [Light Clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/): SP1 can be used to build light clients that can verify the state of other chains, facilitating interoperability between different blockchains without relying on any trusted third parties.
 
 SP1 has already been integrated in many of these applications, including but not limited to:
@@ -23,7 +24,6 @@ SP1 is used by protocols in production today:
 - [SP1 Blobstream](https://github.com/succinctlabs/sp1-blobstream): A bridge that verifies [Celestia](https://celestia.org/) “data roots” (a commitment to all data blobs posted in a range of Celestia blocks) on Ethereum and other EVM chains.
 - [SP1 Vector](https://github.com/succinctlabs/sp1-vector): A bridge that relays [Avail's](https://www.availproject.org/) merkle root to Ethereum and also functions as a token bridge from Avail to Ethereum.
 
-
 ## 100x developer productivity
 
 SP1 enables teams to use ZKPs in production with minimal overhead and fast timelines.
@@ -38,9 +38,6 @@ SP1 is the fastest zkVM and has blazing fast performance on a variety of realist
 
 Read more about our benchmarking results [here](https://blog.succinct.xyz/sp1-benchmarks-8-6-24).
 
-## Open Source 
+## Open Source
 
 SP1 is 100% open-source (MIT / Apache 2.0) with no code obfuscation and built to be contributor friendly, with all development done in the open. Unlike existing zkVMs whose constraint logic is closed-source and impossible to audit or modify, SP1 is modularly architected and designed to be customizable from day one. This customizability (unique to SP1) allows for users to add “precompiles” to the core zkVM logic that yield substantial performance gains, making SP1’s performance not only SOTA vs. existing zkVMs, but also competitive with circuits in a variety of use-cases.
-
-
-
diff --git a/book/writing-programs/basics.md b/book/writing-programs/basics.md
@@ -1,4 +1,4 @@
-# Writing Programs: Basics 
+# Writing Programs: Basics
 
 The easiest way to understand how to write programs for the SP1 zkVM is to look at some examples.
 
@@ -10,6 +10,6 @@ This program is from the `examples` [directory](https://github.com/succinctlabs/
 {{#include ../../examples/fibonacci/program/src/main.rs}}
 ```
 
-As you can see, writing programs is as simple as writing normal Rust. 
+As you can see, writing programs is as simple as writing normal Rust.
 
-After you've written your program, you must compile it to an ELF that the SP1 zkVM can prove. To read more about compiling programs, refer to the section on [Compiling Programs](./compiling.md). To read more about how inputs and outputs work, refer to the section on [Inputs & Outputs](./inputs-and-outputs.md).
+After you've written your program, you must compile it to an ELF that the SP1 zkVM can prove. To read more about compiling programs, refer to the section on [Compiling Programs](./compiling.md). To read more about how inputs and outputs work, refer to the section on [Inputs & Outputs](./inputs-and-outputs.md).