chore(docs): migrate to docusaurus

book/.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

book/README.md

@@ -0,0 +1,41 @@
+# Website
+
+This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
+
+### Installation
+
+```
+$ yarn
+```
+
+### Local Development
+
+```
+$ yarn start
+```
+
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
+
+### Build
+
+```
+$ yarn build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+### Deployment
+
+Using SSH:
+
+```
+$ USE_SSH=true yarn deploy
+```
+
+Not using SSH:
+
+```
+$ GIT_USER=<Your GitHub username> yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

book/create-markdown-templates.sh

@@ -0,0 +1,45 @@
+#!/bin/bash
+
+# Define an array of file paths
+paths=(
+  "../examples/fibonacci/script/bin/execute.rs"
+  "../examples/fibonacci/script/src/main.rs"
+  "../examples/fibonacci/script/bin/groth16_bn254.rs"
+  "../examples/fibonacci/script/build.rs"
+  "../examples/fibonacci/script/src/main.rs"
+  "../examples/groth16/program/src/main.rs"
+  "../examples/groth16/script/src/main.rs"
+  "../examples/io/program/src/main.rs"
+  "../examples/cycle-tracking/program/bin/normal.rs"
+  "../crates/zkvm/lib/src/lib.rs"
+  "../examples/fibonacci/script/bin/compressed.rs"
+  "../examples/fibonacci/program/src/main.rs"
+)
+
+# Ensure the ./static directory exists
+mkdir -p ./static
+
+# Loop over the paths and process each file
+for file in "${paths[@]}"; do
+  if [[ -f "$file" ]]; then
+    # Get the full path and strip everything before 'sp1/'
+    stripped_path=$(readlink -f "$file" | sed -e 's|.*sp1/||')
+
+    # Replace slashes with underscores for the target file name
+    target_name=$(echo "$stripped_path" | tr '/' '_')
+
+    # Define the target markdown file path
+    target="./static/${target_name}.mdx"
+
+    # Write the content into the markdown file
+    {
+      echo "\`\`\`rust"
+      cat "$file"
+      echo "\`\`\`"
+    } > "$target"
+
+    echo "Processed $file -> $target"
+  else
+    echo "File not found: $file"
+  fi
+done

book/generating-proofs/advanced.md → book/docs/generating-proofs/advanced.mdx

@@ -1,23 +1,22 @@
+import Compressed from "../../static/examples_fibonacci_script_bin_compressed.rs.mdx";
+import Execute from "../../static/examples_fibonacci_script_bin_execute.rs.mdx";
+
 # Advanced Usage
 
 ## Execution Only
 
 We recommend that during the development of large programs (> 1 million cycles) you do not generate proofs each time.
 Instead, you should have your script only execute the program with the RISC-V runtime and read `public_values`. Here is an example:
 
-```rust,noplayground
-{{#include ../../examples/fibonacci/script/bin/execute.rs}}
-```
+<Execute />
 
 If the execution of your program succeeds, then proof generation should succeed as well! (Unless there is a bug in our zkVM implementation.)
 
 ## Compressed Proofs
 
 With the `ProverClient`, the default `prove` function generates a proof that is succinct, but can have size that scales with the number of cycles of the program. To generate a compressed proof of constant size, you can use the `prove_compressed` function instead. This will use STARK recursion to generate a proof that is constant size (around 7Kb), but will be slower than just calling `prove`, as it will use recursion to combine the core SP1 proof into a single constant-sized proof.
 
-```rust,noplayground
-{{#include ../../examples/fibonacci/script/bin/compressed.rs}}
-```
+<Compressed />
 
 You can run the above script with `RUST_LOG=info cargo run --bin compressed --release` from `examples/fibonacci/script`.
 
@@ -27,7 +26,7 @@ You can use `utils::setup_logger()` to enable logging information respectively.
 
 **Logging:**
 
-```rust,noplayground
+```rust
 utils::setup_logger();
 ```
 
@@ -55,7 +54,7 @@ sp1-sdk = { version = "2.0.0", features = ["neon"] }
 
 For maximal performance, you should run proof generation with the following command and vary your `shard_size` depending on your program's number of cycles.
 
-```rust,noplayground
+```rust
 SHARD_SIZE=4194304 RUST_LOG=info RUSTFLAGS='-C target-cpu=native' cargo run --release
 ```
 
@@ -64,6 +63,6 @@ SHARD_SIZE=4194304 RUST_LOG=info RUSTFLAGS='-C target-cpu=native' cargo run --re
 To reduce memory usage, set the `SHARD_BATCH_SIZE` environment variable depending on how much RAM
 your machine has. A higher number will use more memory, but will be faster.
 
-```rust,noplayground
+```rust
 SHARD_BATCH_SIZE=1 SHARD_SIZE=2097152 RUST_LOG=info RUSTFLAGS='-C target-cpu=native' cargo run --release
 ```

book/generating-proofs/basics.md → book/docs/generating-proofs/basics.mdx

@@ -1,19 +1,19 @@
-# Generating Proofs: Basics
+import Example from "../../static/examples_fibonacci_script_src_main.rs.mdx";
+
+# Basics
 
 All the methods you'll need for generating proofs are included in the `sp1_sdk` crate. Most importantly, you'll need to use the `ProverClient` to setup a proving key and verifying key for your program and then use the `execute`, `prove` and `verify` methods to execute your program, and generate and verify proofs.
 
 To make this more concrete, let's walk through a simple example of generating a proof for a Fibonacci program inside the zkVM.
 
 ## Example: Fibonacci
 
-```rust,noplayground
-{{#include ../../examples/fibonacci/script/src/main.rs}}
-```
+<Example />
 
 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>
 
-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.
+We recommend using the [prover network](./prover-network.md) to generate proofs. Read more about the [recommended workflow](./recommended-workflow) for developing with SP1.

book/generating-proofs/proof-types.md → book/docs/generating-proofs/proof-types.md

@@ -11,7 +11,7 @@ For a full list of options, see the following [docs](https://docs.rs/sp1-sdk/1.2
 The default prover mode generates a list of STARK proofs that in aggregate have size proportional to
 the size of the execution. Use this in settings where you don't care about **verification cost / proof size**.
 
-```rust,noplayground
+```rust
 let client = ProverClient::new();
 client.prove(&pk, stdin).run().unwrap();
 ```
@@ -21,7 +21,7 @@ client.prove(&pk, stdin).run().unwrap();
 The compressed prover mode generates STARK proofs that have constant size. Use this in settings where you
 care about **verification cost / proof size**, but not onchain verification. Compressed proofs are also useful because they can be cheaply recursively verified within SP1 itself (see the [proof aggregation](../writing-programs/proof-aggregation.md) section).
 
-```rust,noplayground
+```rust
 let client = ProverClient::new();
 client.prove(&pk, stdin).compressed().run().unwrap();
 ```
@@ -32,7 +32,7 @@ The Groth16 prover mode generates a SNARK proof that is ~260 bytes large and can
 
 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.
 
-```rust,noplayground
+```rust
 let client = ProverClient::new();
 client.prove(&pk, stdin).groth16().run().unwrap();
 ```
@@ -43,7 +43,7 @@ The PLONK prover mode generates a SNARK proof that is ~868 bytes large and can a
 
 PLONK does not require a trusted setup.
 
-```rust,noplayground
+```rust
 let client = ProverClient::new();
 client.prove(&pk, stdin).plonk().run().unwrap();
 ```

book/generating-proofs/prover-network/usage.md → book/docs/generating-proofs/prover-network/usage.md

@@ -6,7 +6,7 @@
 
 To use the prover network to generate a proof, you can run your script that uses `sp1_sdk::ProverClient` as you would normally but with additional environment variables set:
 
-```rust,noplayground
+```rust
 // Generate the proof for the given program.
 let client = ProverClient::new();
 let (pk, vk) = client.setup(ELF);
@@ -40,7 +40,7 @@ To skip the simulation step and directly submit the program for proof generation
 
 By using the `sp1_sdk::NetworkProver` struct directly, you can call async functions directly and have programmatic access to the proof ID and download proofs by ID.
 
-```rust,noplayground
+```rust
 impl NetworkProver {
     /// Creates a new [NetworkProver] with the private key set in `SP1_PRIVATE_KEY`.
     pub fn new() -> Self;

book/generating-proofs/recommended-workflow.md → book/docs/generating-proofs/recommended-workflow.mdx

@@ -1,3 +1,5 @@
+import Example from "../../static/examples_fibonacci_script_bin_execute.rs.mdx";
+
 # Recommended Workflow for Developing with SP1
 
 We recommend the following workflow for developing with SP1.
@@ -6,9 +8,7 @@ We recommend the following workflow for developing with SP1.
 
 While iterating on your SP1 program, you should **only execute** the program with the RISC-V runtime. This will allow you to verify the correctness of your program and test the `SP1Stdin` as well as the `SP1PublicValues` that are returned, without having to generate a proof (which can be slow and/or expensive). If the execution of your program succeeds, then proof generation should succeed as well!
 
-```rust,noplayground
-{{#include ../../examples/fibonacci/script/bin/execute.rs}}
-```
+<Example />
 
 Note that printing out the total number of executed cycles and the full execution report provides helpful insight into proof generation latency and cost either for local proving or when using the prover network.
 
@@ -44,7 +44,7 @@ In SP1, there is a fixed overhead for proving that is independent of your progra
 
 - An average Ethereum block can be between 100-500M cycles (including merkle proof verification for storage and execution of transactions) with our `keccak` and `secp256k1` precompiles.
 - For a Tendermint light client, the average cycle count can be between 10M and 50M cycles (including our ed25519 precompiles).
-- We consider programs with <2M cycles to be "small" and by default, the fixed overhead of proving will dominate the proof latency. If latency is incredibly important for your use-case, we can specialize the prover network for your program if you reach out to us.
+- We consider programs with \<2M cycles to be "small" and by default, the fixed overhead of proving will dominate the proof latency. If latency is incredibly important for your use-case, we can specialize the prover network for your program if you reach out to us.
 
 Note that if you generate Groth16 or PLONK proofs on the prover network, you will encounter a fixed overhead for the STARK -> SNARK wrapping step. We're actively working on reducing this overhead in future releases.
 
@@ -54,4 +54,4 @@ The prover network is currently in beta and has limited capacity. For high volum
 
 ### Generating proofs locally
 
-If you want to generate proofs locally, you can use the `sp1_sdk` crate to generate proofs locally as outlined in the [Basics](./basics.md) section. By default, the `ProverClient` will generate proofs locally using your CPU. Check out the hardware requirements for locally proving [here](../getting-started/hardware-requirements.md#local-proving).
+If you want to generate proofs locally, you can use the `sp1_sdk` crate to generate proofs locally as outlined in the [Basics](./basics) section. By default, the `ProverClient` will generate proofs locally using your CPU. Check out the hardware requirements for locally proving [here](../getting-started/hardware-requirements.md#local-proving).

book/generating-proofs/setup.md → book/docs/generating-proofs/setup.md

@@ -1,4 +1,4 @@
-# Generating Proofs: Setup
+# Setup
 
 In this section, we will teach you how to setup a self-contained crate which can generate proofs of programs that have been compiled with the SP1 toolchain inside the SP1 zkVM, using the `sp1-sdk` crate.
 
@@ -24,7 +24,7 @@ cd script
 
 Inside this crate, add the `sp1-sdk` crate as a dependency. Your `Cargo.toml` should look like as follows:
 
-```rust,noplayground
+```rust
 [workspace]
 [package]
 version = "0.1.0"

book/generating-proofs/sp1-sdk-faq.md → book/docs/generating-proofs/sp1-sdk-faq.md

@@ -4,7 +4,7 @@
 
 You can use `sp1_sdk::utils::setup_logger()` to enable logging information respectively. You can set the logging level with the `RUST_LOG` environment variable.
 
-```rust,noplayground
+```rust
 sp1_sdk::utils::setup_logger();
 ```
 

book/getting-started/quickstart.md → book/docs/getting-started/quickstart.md

@@ -116,7 +116,7 @@ The program by default is quite small, so proof generation will only take a few
 
 ## Recommended Workflow
 
-Please see the [Recommended Workflow](../generating-proofs/recommended-workflow.md) section for more details on how to develop your SP1 program and generate proofs.
+Please see the [Recommended Workflow](../generating-proofs/recommended-workflow) section for more details on how to develop your SP1 program and generate proofs.
 
 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.
 

book/introduction.md → book/docs/introduction.md

@@ -1,4 +1,4 @@
-# SP1
+# Introduction 
 
 *Documentation for SP1 users and developers*.