Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: docker on mac #1771

Merged
merged 7 commits into from
Nov 12, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions .github/actions/setup/action.yml
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
# Note: this is only compatible with Linux runners.

name: Test setup
inputs:
pull_token:
Expand Down
2 changes: 1 addition & 1 deletion audits/rkm0959.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
3 changes: 2 additions & 1 deletion book/generating-proofs/basics.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

<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.
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.
</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.
4 changes: 3 additions & 1 deletion book/getting-started/hardware-requirements.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yuwen01 I did run into this issue today. The error message is very cryptic and I suggest making a note on the Quickstart page.

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

Expand Down
3 changes: 2 additions & 1 deletion book/verification/onchain/getting-started.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
4 changes: 3 additions & 1 deletion crates/recursion/gnark-ffi/src/ffi/docker.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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(())
Expand Down
Loading