| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Thus, if a user sees "Command log" in their output, they'll be able to
easily find where in the codebase the log is outputted.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
In each zkVM we'll write the size to /tmp/proof_size and then guest_io
will read that value and place it inside our metrics output. This is not
the most elegant, and in certain zkVMs the file output is a part of the
benchmark timing, but it will have to do.
|
| | |
|
| |
|
|
| |
These are the zkvm name, rev, guest name and benchmarks repo rev
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We're using benchexec's runexec to track how much memory our program
uses. Because of nix compatibility troubles, for now we've disabled
runexec's container feature. This could result in less accurate data.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Following the new output format, we'll run the guest program for each
zkVM, for each operation (execute, prove, verify with --benchmark flag).
Then we'll combine the resultant JSON outputs into one big JSON object.
For now we're only printing the result object. Later we'll add the
ability to write it into any file.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
appropriate
If we're not appending to a file with contents, then when we write our
data, we're going to be overwriting the old data. If the old data is
longer than the new one, we'll have some leftover text in the end, which
will cause a problem with JSON parsing.
We'll be truncating the file (i.e. emptying it out), but only when not
appending to it.
|
| | |
|
| | |
|
| |
|
|
| |
zkvsm_host_io lib
|
| | |
|
| | |
|
| |
|
|
|
|
| |
There are no package version updates. The primary difference is that
RISC0 is now compiled with the unstable feature. All other hash updates
come from the switch from rust-bin to fenix.
|
| | |
|
| |
|
|
|
| |
In certain cases, we would get errors that the "x" type cannot be
inferred.
|
| |
|
|
|
|
|
|
| |
The AWK script goes to the next line when a property is found. If the
lock file ends on a property, the next line will be "fetched", but that
is after the end of the file, so we'll never reach the printing logic.
We're adding a blank line to the end of the lock file, so we never hit
this edge case.
|
| | |
|
| |
|
|
|
|
| |
The `sep` variable is used below, in `output_type`, where the public
types are laid out. Before, we checked the count of all types, including
private ones, which caused a crash when we have no private inputs.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
`cargo add` modifies the Cargo.lock, and optional dependencies will be
removed if the feature is not passed through
|
| |
|
|
|
|
|
|
|
|
|
| |
instead of default
To get the new Nix outPaths for all zkVMs, we used to execute a `nix
run` command, which found the paths from the nix-blockchain-development
repo, default branch on latest commit.
Since that could differ from what repo our flake actually uses, we're
updating the logic.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Originally tried by Dimo Dimov
Co-authored-by: Dimo99 <dimodimov1999@gmail.com>
|
| | |
|
| |
|
|
| |
Simple program which tests the SHA256 hashing algorithm
|
| |
|
|
|
|
| |
Before grouping transformed vec![a,b,...] into "(a,b,...)", but with
FunctionDefinition, grouping transforms vec![a,b,...] into "a,b,...".
This change wasn't reflected in Nexus and ZKM
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
