From 47eac3393678b3ccc2fbd084e5d099c973946302 Mon Sep 17 00:00:00 2001 From: Yuwen Zhang Date: Tue, 12 Nov 2024 14:51:38 -0800 Subject: [PATCH] docs: docker on mac (#1771) --- .github/actions/setup/action.yml | 2 ++ audits/rkm0959.md | 2 +- book/generating-proofs/basics.md | 3 ++- book/getting-started/hardware-requirements.md | 4 +++- book/verification/onchain/getting-started.md | 3 ++- crates/recursion/gnark-ffi/src/ffi/docker.rs | 4 +++- 6 files changed, 13 insertions(+), 5 deletions(-) diff --git a/.github/actions/setup/action.yml b/.github/actions/setup/action.yml index d12a1d16aa..d928b91df6 100644 --- a/.github/actions/setup/action.yml +++ b/.github/actions/setup/action.yml @@ -1,3 +1,5 @@ +# Note: this is only compatible with Linux runners. + name: Test setup inputs: pull_token: diff --git a/audits/rkm0959.md b/audits/rkm0959.md index 3fb90318af..2c09f508d5 100644 --- a/audits/rkm0959.md +++ b/audits/rkm0959.md @@ -393,7 +393,7 @@ this passes each core verification, and since the RecursionPublicValue of proof - shard 1, 2's committed_value_digest = `0` - shard 3, 4's committed_value_digest = `x` -this passes each core verification, as proof #2 thinks shard 3 is its "first" shard - so it actually thinks that the `committed_value_digest` didn't change. This means that the whole "no cpu chip means `commited_value_digest` equal" thing actually just passes. Then, in the compress verification, we'll just see the committed_value_digest go from `0` to `x`, which is also completely fine. However, the committed_value_digest will go `0, 0, x, x`, where the change occurs on a shard without cpu chip - which isn't supposed to happen. +this passes each core verification, as proof #2 thinks shard 3 is its "first" shard - so it actually thinks that the `committed_value_digest` didn't change. This means that the whole "no cpu chip means `committed_value_digest` equal" thing actually just passes. Then, in the compress verification, we'll just see the committed_value_digest go from `0` to `x`, which is also completely fine. However, the committed_value_digest will go `0, 0, x, x`, where the change occurs on a shard without cpu chip - which isn't supposed to happen. While this is a slight incompatibility, the main invariant (if nonzero, public digest can only be one non-zero value) is preserved. Therefore, we did not fix this observation. diff --git a/book/generating-proofs/basics.md b/book/generating-proofs/basics.md index 85273d96ba..7bde99bbc1 100644 --- a/book/generating-proofs/basics.md +++ b/book/generating-proofs/basics.md @@ -13,7 +13,8 @@ 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.
-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. +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. You might only be able to generate proofs for small inputs locally.
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/getting-started/hardware-requirements.md b/book/getting-started/hardware-requirements.md index 828ea96080..3877d22e84 100644 --- a/book/getting-started/hardware-requirements.md +++ b/book/getting-started/hardware-requirements.md @@ -31,7 +31,9 @@ which can be parallelized with multiple cores. Our prover requires keeping large matrices (i.e., traces) in memory to generate the proofs. Certain steps of the prover have a minimum memory requirement, meaning that if you have less than this amount of memory, the process will OOM. -This effect is most noticeable when using the Groth16 or PLONK provers. +This effect is most noticeable when using the Groth16 or PLONK provers. If you're running the Groth16 or Plonk provers locally +on Mac or Windows using docker, you might need to increase the memory limit for +[docker desktop](https://docs.docker.com/desktop/settings-and-maintenance/settings/#resources). ### Disk diff --git a/book/verification/onchain/getting-started.md b/book/verification/onchain/getting-started.md index 8519d620a8..715b100d58 100644 --- a/book/verification/onchain/getting-started.md +++ b/book/verification/onchain/getting-started.md @@ -14,7 +14,8 @@ By default, the proofs generated by SP1 are not verifiable onchain, as they are > WARNING: The Groth16 and PLONK provers are only guaranteed to work on official releases of SP1. To > use Groth16 or PLONK proving & verification locally, ensure that you have Docker installed and have -> at least 128GB of RAM. +> at least 32GB of RAM. Note that you might need to increase the memory limit for +> [docker desktop](https://docs.docker.com/desktop/settings-and-maintenance/settings/#resources) if you're running on Mac. ### Example diff --git a/crates/recursion/gnark-ffi/src/ffi/docker.rs b/crates/recursion/gnark-ffi/src/ffi/docker.rs index 119253d492..bf0f2865bd 100644 --- a/crates/recursion/gnark-ffi/src/ffi/docker.rs +++ b/crates/recursion/gnark-ffi/src/ffi/docker.rs @@ -47,8 +47,10 @@ fn call_docker(args: &[&str], mounts: &[(&str, &str)]) -> Result<()> { } cmd.arg(get_docker_image()); cmd.args(args); - if !cmd.status()?.success() { + let result = cmd.status()?; + if !result.success() { log::error!("Failed to run `docker run`: {:?}", cmd); + log::error!("Execution result: {:?}", result); return Err(anyhow!("docker command failed")); } Ok(())