add

.gitignore

@@ -52,3 +52,9 @@ examples/fibonacci/fibonacci-plonk.bin
 
 # C++
 .vscode/c_cpp_properties.json
+
+**/.yarn
+**/yarn.lock
+book/.pnp.cjs
+book/.pnp.loader.mjs
+book/.yarnrc.yml

book/docs/developers/common-issues.md

@@ -51,7 +51,7 @@ This is likely due to two different versions of `alloy_sol_types` being used. To
 
 ```toml
 [dependencies]
-sp1-sdk = { version = "4.0.0-rc.8", default-features = false }
+sp1-sdk = { version = "4.0.0", default-features = false }
 ```
 
 This will configure out the `network` feature which will remove the dependency on `alloy_sol_types` and configure out the `NetworkProver`.

book/docs/generating-proofs/prover-network/versions.md

@@ -17,14 +17,14 @@ You must switch to a supported version before submitting a proof. To do so, repl
 
 ```toml
 [dependencies]
-sp1-zkvm = "4.0.0-rc.8"
+sp1-zkvm = "4.0.0"
 ```
 
 replace the `sp1-sdk` version in your script's `Cargo.toml`:
 
 ```toml
 [dependencies]
-sp1-sdk = "4.0.0-rc.8"
+sp1-sdk = "4.0.0"
 ```
 
 Re-build your program and script, and then try again.

book/docs/generating-proofs/setup.md

@@ -32,7 +32,7 @@ name = "script"
 edition = "2021"
 
 [dependencies]
-sp1-sdk = "4.0.0-rc.8"
+sp1-sdk = "4.0.0"
 ```
 
 The `sp1-sdk` crate includes the necessary utilities to generate, save, and verify proofs.

book/docs/verification/off-chain-verification.md

@@ -16,7 +16,7 @@ the [Groth16 Example](https://github.com/succinctlabs/sp1/tree/main/examples/gro
 Import the following dependency in your `Cargo.toml`:
 
 ```toml
-sp1-verifier = {version = "4.0.0-rc.8", default-features = false}
+sp1-verifier = {version = "4.0.0", default-features = false}
 ```
 
 ### Usage

book/docs/writing-programs/compiling.mdx

@@ -6,17 +6,21 @@ Once you have written an SP1 program, you must compile it to an ELF file that ca
 
 ## Development Builds
 
-> WARNING: This may not generate a reproducible ELF which is necessary for verifying that your binary corresponds to given source code.
+> WARNING: Running `cargo prove build` may not generate a reproducible ELF which is necessary for verifying that your binary corresponds to given source code.
 >
-> Use the [reproducible build system](#production-builds) for production builds.
+> Use SP1's [reproducible build system](#production-builds) for production builds.
 
 To build a program while developing, simply run the following command in the crate that contains your SP1 program:
 
 ```bash
+# Enter the directory containing your SP1 program.
+cd path/to/your/program
+
+# Build the program.
 cargo prove build
 ```
 
-This will compile the ELF that can be executed in the zkVM. The output from the command will look something like this:
+This will compile the ELF that can be executed in the zkVM. The output from the command will look similar to this:
 
 ```bash
 [sp1]     Compiling version_check v0.9.4
@@ -34,17 +38,27 @@ Under the hood, this CLI command calls `cargo build` with the `riscv32im-succinc
 
 ### Advanced Build Options
 
-You can pass additional arguments to the `cargo prove build` command to customize the build process, like configuring what features are enabled, customizing the output directory and more. To see all available options, run `cargo prove build --help`. Many of these options mirror the options available in the `cargo build` command.
+The `cargo prove build` command supports several configuration options to customize the build process for your program:
+
+- `--features`: Enable specific features
+- `--output-directory`: Specify a custom output location for the ELF
+- `--elf-name`: Set a custom name for the output ELF file
+- `--no-default-features`: Disable default features
+- `--locked`: Ensure Cargo.lock remains unchanged
+- `--packages`: Build only specified packages
+- `--binaries`: Build only specified binaries
+
+Run `cargo prove build --help` to see the complete list of options. Some options mirror those available in the standard `cargo build` command.
 
 ## Production Builds
 
-For production builds of programs, you can build your program inside a Docker container which will generate a **reproducible ELF** on all platforms. To do so, just use the `--docker` flag and optionally the `--tag` flag with the release version you want to use (defaults to `latest`). For example:
+For production builds, use Docker to generate a **reproducible ELF** that will be identical across all platforms. Simply add the `--docker` flag to your build command. You can also specify a release version using `--tag` (if omitted, defaults to `latest`). For example:
 
 ```bash
-cargo prove build --docker --tag v1.0.1
+cargo prove build --docker --tag v4.0.0
 ```
 
-To verify that your build is reproducible, you can compute the SHA-512 hash of the ELF on different platforms and systems with:
+To verify that your build is truly reproducible across different platforms and systems, compute the SHA-512 hash of the generated ELF file. The hash should be identical regardless of where you build it:
 
 ```bash
 $ shasum -a 512 elf/riscv32im-succinct-zkvm-elf
@@ -61,7 +75,7 @@ The path passed in to `build_program` should point to the directory containing t
 
 ```toml
 [build-dependencies]
-sp1-build = "4.0.0-rc.8"
+sp1-build = "4.0.0"
 ```
 
 You will see output like the following from the build script if the program has changed, indicating that the program was rebuilt:
@@ -82,19 +96,17 @@ The above output was generated by running `RUST_LOG=info cargo run --release -vv
 
 To configure the build process when using the `sp1-build` crate, you can pass a [`BuildArgs`](https://docs.rs/sp1-build/latest/sp1_build/struct.BuildArgs.html) struct to to the [`build_program_with_args`](https://docs.rs/sp1-build/latest/sp1_build/fn.build_program_with_args.html) function. The build arguments are the same as the ones available from the `cargo prove build` command.
 
-As an example, you could use the following code to build the Fibonacci example with the `docker` flag set to `true` and a custom output directory for the generated ELF:
+As an example, you could use the following code to build the Fibonacci example with the `docker` flag set to `true` and a custom name for the generated ELF. This will generate a reproducible ELF file (with Docker) with the name `fibonacci-elf`:
 
 ```rust
 use sp1_build::{build_program_with_args, BuildArgs};
 
 fn main() {
     let args = BuildArgs {
         docker: true,
-        output_directory: "./fibonacci-program".to_string(),
+        elf_name: "fibonacci-elf".to_string(),
         ..Default::default()
     };
     build_program_with_args("../program", &args);
 }
-```
-
-**Note:** If you want reproducible builds with the `build.rs` approach, you should use the `docker` flag and the `build_program_with_args` function, as shown in the example above.
+```

book/docs/writing-programs/cycle-tracking.mdx

@@ -6,41 +6,74 @@ When writing a program, it is useful to know how many RISC-V cycles a portion of
 
 ## Tracking Cycles with Annotations
 
-To track the number of cycles spent in a portion of the program, you can either put `println!("cycle-tracker-start: block name")` + `println!("cycle-tracker-end: block name")` statements (block name must be same between start and end) around the portion of your program you want to profile or use the `#[sp1_derive::cycle_tracker]` macro on a function. An example is shown below:
-
-<Example />
-
-Note that to use the macro, you must add the `sp1-derive` crate to your dependencies for your program.
-
-```toml
-[dependencies]
-sp1-derive = "4.0.0-rc.8"
-```
-
-In the script for proof generation, setup the logger with `utils::setup_logger()` and run the script with `RUST_LOG=info cargo run --release`. You should see the following output:
-
-```
-$ RUST_LOG=info cargo run --release
-    Finished release [optimized] target(s) in 0.21s
-     Running `target/release/cycle-tracking-script`
-2024-03-13T02:03:40.567500Z  INFO execute: loading memory image
-2024-03-13T02:03:40.567751Z  INFO execute: starting execution
-2024-03-13T02:03:40.567760Z  INFO execute: clk = 0 pc = 0x2013b8
-2024-03-13T02:03:40.567822Z  INFO execute: ┌╴setup
-2024-03-13T02:03:40.568095Z  INFO execute: └╴4,398 cycles
-2024-03-13T02:03:40.568122Z  INFO execute: ┌╴main-body
-2024-03-13T02:03:40.568149Z  INFO execute: │ ┌╴expensive_function
-2024-03-13T02:03:40.568250Z  INFO execute: │ └╴1,368 cycles
-stdout: result: 5561
-2024-03-13T02:03:40.568373Z  INFO execute: │ ┌╴expensive_function
-2024-03-13T02:03:40.568470Z  INFO execute: │ └╴1,368 cycles
-stdout: result: 2940
-2024-03-13T02:03:40.568556Z  INFO execute: └╴5,766 cycles
-2024-03-13T02:03:40.568566Z  INFO execute: finished execution clk = 11127 pc = 0x0
-2024-03-13T02:03:40.569251Z  INFO execute: close time.busy=1.78ms time.idle=21.1µs
-```
-
-Note that we elegantly handle nested cycle tracking, as you can see above.
+SP1 provides two methods to track cycle usage in your program:
+
+1. Using print statements:
+   ```rust
+   #![no_main]
+   sp1_zkvm::entrypoint!(main);
+
+   fn main() {
+        let mut nums = vec![1, 1];
+
+        // Compute the sum of the numbers.
+        println!("cycle-tracker-start: compute");
+        let sum: u64 = nums.iter().sum();
+        println!("cycle-tracker-end: compute");
+
+        // Print the result.
+        println!("result: {}", sum);
+   }
+   ```
+
+   To save the cycle counts to the `ExecutionReport`, you can use the `cycle_tracker_report_start` and `cycle_tracker_report_end` annotations.
+
+   ```rust
+   #![no_main]
+   sp1_zkvm::entrypoint!(main);
+
+   fn main() {
+        let mut nums = vec![1, 1];
+
+        // Compute the sum of the numbers.
+        println!("cycle-tracker-report-start: compute");
+        let sum: u64 = nums.iter().sum();
+        println!("cycle-tracker-report-end: compute");
+
+        // Print the result.
+        println!("result: {}", sum);
+   }
+   ```
+
+   To read from tracked cycles from the `ExecutionReport`, you can read from the `cycle_tracker` map after executing the program.
+
+   ```rust
+   let report = client.execute(ELF, &stdin).run().unwrap();
+   let cycle_count = report.cycle_tracker.get("compute").unwrap();
+   println!("compute cycle count: {}", cycle_count);
+   ```
+
+2. Using the cycle tracker macro:
+   ```rust 
+   #![no_main]
+   sp1_zkvm::entrypoint!(main);
+
+   #[sp1_derive::cycle_tracker]
+    pub fn expensive_function(x: usize) -> usize {
+        let mut y = 1;
+        for _ in 0..100 {
+            y *= x;
+            y %= 7919;
+        }
+        y
+    }
+   ```
+
+   To use the cycle tracker macro, add `sp1-derive` to your program's dependencies:
+
+   ```toml
+   sp1-derive = "4.0.0"
+   ```
 
 ### Get Tracked Cycle Counts
 
@@ -79,7 +112,7 @@ Once you have your script it should look like the following:
 As well you must enable the profiling feature on the SDK:
 
 ```toml
-    sp1-sdk = { version = "4.0.0-rc.8", features = ["profiling"] }
+    sp1-sdk = { version = "4.0.0", features = ["profiling"] }
 ```
 
 The `TRACE_FILE` env var tells the executor where to save the profile, and the `TRACE_SAMPLE_RATE` env var tells the executor how often to sample the program.

book/docs/writing-programs/setup.md

@@ -32,7 +32,7 @@ name = "program"
 edition = "2021"
 
 [dependencies]
-sp1-zkvm = "4.0.0-rc.8"
+sp1-zkvm = "4.0.0"
 ```
 
 The `sp1-zkvm` crate includes necessary utilities for your program, including handling inputs and outputs,