| Commit message (Collapse) | Author | Age | Lines | SHA |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The old method of having functions for every parsing action of a
function definition produced messy results. We're replacing it with a
struct which will hold a wide assortment of parsed values. This makes
the interface much sleaker with only a minor increase in code.
The downside is a lot of data gets repeated, however since this struct
will only be used in macros, i.e. compile-time, that doesn't matter too
much.
|
| |
|
|
|
|
|
|
|
|
| |
Recently ZKM introduced a bug, where SNARK_SETUP would crash, but the
witness would be generated. So we introduced a hack where we would run
SNARK_SETUP, ignore the crash and rerun the program again, without
SNARK_SETUP.
Now they fixed it, so with SNARK_SETUP, the witnesses would be generated
and the proving process will be done directly after.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We first need to generate witnesses before proving. This is done by
running the binary with SNARK_SETUP=true. Currently, the command crashes
right after those witnesses are generated. As a workaround, we ignore
the crash and just start it normally, using the generated witnesses.
|
| |
|
|
|
|
|
|
|
| |
Recently, RISC0 have added code to their SDK which adds magic bytes to
the (already compiled) ELF. Since we're taking another route than
intended, we'll need to replicate this step too.
We're doing things in a different fashion, because their SDK normally
compiles the guest, and doesn't allow you to supply a prebuilt ELF.
|
| | |
|
| |
|
|
| |
Update according to their new methods.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
return type
Currently we create an "Output" type, which contains a tuple with all
public inputs and the function return type. In most zkVMs, public and
private inputs are not distinguished from the start, public inputs are
returned by the guest program and private are not.
Thus, most of the time we need a more complicated return type. However,
sometimes this is not the case, and the public/private distinction is
done upfront (and we don't need to output inputs). So we need to add the
appropriate type.
|
| |
|
|
|
|
|
| |
Update SDK usage, according to their new methods.
ZKM moved their Go library to the zkVM repo. Their updated SDK also
don't require the patch.
|
| |
|
|
| |
bytemuck_derive
|
| | |
|
| |
|
|
| |
This follows the same change which was made in mcl-blockchain
|
| |
|
|
|
|
|
|
|
| |
All crates use the zkVM packages (from nix-blockchain-development) as
cargo path dependencies. For each zkVM, they're found in the host, guest
and wrapper crates.
Since there are a lot of places to update, we're introducing a script
which automates this.
|
| |
|
|
|
|
|
| |
With the commit for improving the metrics output we introduced a bug for
the milliseconds where we would lose information about leading zeros.
This has been now fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have improved the format of the benchmarking output. Now the metrics
follow a more standard CSV style.
Example:
```
name,guest,total duration,repeats,average
jolt,fibonacci,1.33,2,0.516
nexus,fibonacci,177.388,2,88.694
risc0,fibonacci,3.828,2,1.914
sp1,fibonacci,13.330,2,6.665
zkm,fibonacci,279.394,2,139.697
zkwasm,fibonacci,106.161,2,53.80
```
|
| |
|
|
|
|
| |
early return
This test should be pretty difficult for Noir, but less so for the zkVMs
|
| | |
|
| |
|
|
|
| |
zkVMs are multithreaded, so having parallel execution will result in
inconsistent results, as every zkVM is fighting for resources
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Ported from
https://github.com/blocksense-network/noir/tree/6a4f172c0cbee1e2baea7d4c0684121d5921c09a/test_programs/plonky2_prove_success/zk_dungeon
Co-authored-by: Stan Manilov <stanislav.manilov@gmail.com>
|
| | |
|
| |
|
|
| |
anything
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is meant to be used in our codebase, especially in CI pipelines
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
zkVMs with guests
You need to add a ".no_zkvm" file in the guests/guest/ directory for
your guest and zkvm. You may add details on why the zkVM is not
supported inside the file itself, but it is not mandatory.
|
| |
|
|
| |
So you can make code modifications compile-time, based on the zkVM
|
| |
|
|
|
|
|
| |
The newest toolchain causes errors, an issue has been filed upstream:
https://github.com/zkMIPS/toolchain/issues/4
However, it is not certain when it will be resolved, so for now this
workaround will be used.
|
| |
|
|
|
|
|
| |
The SDK is out of date. A PR is opened:
https://github.com/zkMIPS/zkm-project-template/pull/54
However, its not certain it will be merged soon, so for now this
workaround will have to do.
|
| |
|
|
|
|
|
|
| |
This includes:
- Updating flake.lock
- Updating all host and guest Cargo.toml and Cargo.lock files
- Making zkvm default.nix file modifications to account for toolchain
and setup changes
|
| |
|
|
|
| |
Allows the host and guest program toolchains to differ. Generally, you
should only need to set one.
|
| |
|
|
|
|
|
|
|
|
| |
Adds the ability to specify an `extraLockfile` attribute in args. Its
value should evaluate to a string path. It's included in the beginning,
so it overshadows dependencies, which are specified in the other
Cargo.lock files.
Must be added to commonArgs (i.e. to both `buildDepsOnly` and
`buildPackage` args).
|
| |
|
|
|
|
|
|
|
| |
Allows you to add `overrideVendorCargoPackage` and
`overrideVendorGitCheckout` to args, which allow the overriding of
vendored dependencies, as is implemented in crane.lib.
The respective attribute must be added to commonArgs (i.e. to both
`buildDepsOnly` and `buildPackage` args).
|
| |
|
|
|
|
| |
Certain zkVMs may use clap with versions lower than 4.5 (e.g. 4.5.9).
Here we do not really care about the version, so this change will fix
compatibility issues.
|
