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

Backport PRs to release-0.20 #1260

Merged
merged 27 commits into from Jan 17, 2024
Merged

Backport PRs to release-0.20 #1260

merged 27 commits into from Jan 17, 2024

Conversation

flaub
Copy link
Member

@flaub flaub commented Dec 20, 2023

No description provided.

SchmErik and others added 5 commits December 19, 2023 16:14
Projects such as llvm require code to conform to rv32i2p1_m2p0 and no
longer support rv32i2p0_m2p0. This breaks compilation when these files
are linked by llvm giving errors like so:

```
error: invalid arch name 'rv32i2p0_m2p0', unsupported version number 2.0 for extension 'i'
        .attribute      5, "rv32i2p0_m2p0"
                           ^
```

This change relaxes the architecture versioning by dropping the version
numbers for each feature and using `rv32im` instead. By doing so, we
will be able to use newer versions of rust and llvm to generate the
guest code.
…D_SIZE (#1239)

There are cases where guest code might request allocations with
alignments greater than WORD_SIZE. For example, aligning a struct to a
page boundary could help with locality when accessing those structures.

Fixes: #1209
`sys_log` doesn't insert a newline and makes the terminal output messy.
Add a newline for cleaner output.

---------

Co-authored-by: Frank Laub <flaub@risc0.com>
As described in #1243, our use of
the `jal` instruction in our entrypoint breaks when the jump distance
becomes too far. This PR changes the instruction to the `call`
psuedo-instruction to allow the assembler flexibility to solve this
issue and implement a far jump.

Co-authored-by: @weikengchen
Resolves: #1243

---------

Co-authored-by: Frank Laub <frank@risczero.com>
Co-authored-by: Frank Laub <flaub@risc0.com>
Rust naming guidelines recommend C-GETTER conventions for "getter
function". This PR renames `env::get_cycle_count` to `env::cycle_count`
to follow these guidelines


https://rust-lang.github.io/api-guidelines/naming.html#getter-names-follow-rust-convention-c-getter

---------

Co-authored-by: Frank Laub <frank@risczero.com>
@flaub flaub self-assigned this Dec 20, 2023
Copy link

vercel bot commented Dec 20, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
website ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 17, 2024 4:46am

flaub and others added 18 commits January 16, 2024 17:26
Co-authored-by: Frank Laub <flaub@risc0.com>
This PR changes the Bonsai SDK to incorporate composition:
- [x] Add the option to include a list of UUID representing receipts as
part of the `create_session` payload
- [x] Add the `upload_receipt` route
- [x] Add the test to both new additions
- [x] Update alpha_async crate
- [x] Update Bonsai SDK crate
- [x] Update ethereum crate
- [x] Update rest-api-mock-crate
This PR adds the `resolve` method to the `Client` API such that a
succinct receipt can be generated by repeated calls to the lift, join,
and resolve methods on `Client`.
Adds a JSON Web Token validator to demonstrate validating RS256 signed
tokens in the guest.

---------

Co-authored-by: Frank Laub <flaub@risc0.com>
Composition currently does not work in client/server mode because
receipts are not sent from client to server. This PR adds the required
plumbing to send the assumptions from client to server.

Resolves: #1236
Happy New Year! I've omitted the circuit from this PR but I will make a
separate update after updating WIP and bootstrapping. It looks like tests in
doc-test/version-0.18 is failing due to the `risc0-zkvm-methods` crate
failing to build. I'm going to omit changes to that directory for the time being.
I spent a momment to look into the minimal guest programs under `std`
and `no_std` configurations, and found that in the `std` case we can
drop the non-standard lines we use today. This PR changes the minimal
`std` guest in our examples and templates to the following:

```rust
use risc0_zkvm::guest::env;

fn main() {
    env::commit("hello");
}
```

By contrast, here was the `std` guest we were using before:

```rust

use risc0_zkvm::guest::env;

risc0_zkvm::guest::entry!(main);

fn main() {
    env::commit(&0xf00u64);
}
```

In the case of `no_std`, I attempted to improve upon the current minimal
guest, and did find an alternative. What I discovered is that removing
`#![mo_main]` means we will need to define a `start` langauge symbol. I
found that the standard way to do that is with the `start` feature,
resulting in the following guest.

```rust

use risc0_zkvm::guest::env;

fn main(_: isize, _: *const *const u8) -> isize {
    env::commit("hello");
    0
}
```

Comapred with what we have, this seems less readable. As a result, I am
not suggesting we change the minimal prgram from `no_std`. It will
remain as:

```rust

use risc0_zkvm::guest::env;

risc0_zkvm::guest::entry!(main);

fn main() {
    env::commit(&0xf00u64);
}

```

This PR additionally removes the `pub` visibility modifier from all
`main` functions except `r0vm`, as it is not needed.

---------

Co-authored-by: Frank Laub <flaub@risc0.com>
The changes the MemorySet trace event to use a vector of bytes instead of a u32. By doing so, TraceEvent can capture bytes written a call to `store_region` using one trace event.

Fixes: #1194

---------

Co-authored-by: Frank Laub <flaub@risc0.com>
We had a bug previously where execution statistics were reported with
inaccurate values. This PR seeks to solve this issue.
This PR adds a basic example of composition. Building upon the proof of
known factors, this example exponentiates a number mod a composite with
known factors. This takes inspiration from RSA encryption, and is kind
of a stripped down (and insecure) version of verifiable encryption such
that the message is provably decrypt-able by some party.

Resolves: #1299

---------

Co-authored-by: Frank Laub <flaub@risc0.com>
This change removes SYS_READ_AVAIL because it's not POSIX compliant and
introduces some difficulty in cases where the number of available bytes
might
be undefined or non-deterministic concerning guest execution.

This change removes the SYS_READ_AVAIL support from the host and guest.
The
guest syscall libraries used SYS_READ_AVAIL to create a buffer of the
correct
size. Due to its removal, we're allowing cases where EOF is encountered
earlier
and a shorter read than requested is possible through the guest syscall
handlers provided. The underlying handler in the prover has changed to
reflect this reality by removing asserts. This is based on
@austinabell's
solution with minor adjustments.

Summary of guest-side syscall handler changes:

The previous implementation relied on the number of bytes returned by
SYS_READ_AVAIL or has been requested. Logic in SYS_READ has been changed
to use
the actual amount of bytes read from the syscall. Also, if the guest
requests
more bytes than available, it short-circuits the requests and returns
the
amount of read bytes.

Summary of host changes:

Changed the host to allow the guest to request more bytes than
available. In this case, the host will hit an EOF and return the buffer
to the
caller while still allowing the last unaligned word to be read.

Fixes: #1254

---------

Co-authored-by: Austin Abell <austinabell8@gmail.com>
Although very clever, the term "corroborating receipt" was introducing
uncessesary confusion.
This removes the use of the word "corroborating" with reference to
receipts that attest the the validity of assumptions.
…example version (#1320)

Co-authored-by: Frank Laub <flaub@risc0.com>
)

This PR adds terminology entries to the website for terms/concepts
related to composition. Additionally is adds a bit more documentation to
types and methods related to composition, and additionally refactors the
`ExecutorEnv::add_assumption` method to accept `impl Into<Assumption>`
which allows the user to pass in a receipt without any transformation.

---------

Co-authored-by: Tim Zerrell <tim.zerrell@risczero.com>
Groth16 prover

* Add workflow for generation of groth16 proof of STARK verification.
* Fix xtask bootstrap to break cyclic dependency

---------

Co-authored-by: Frank Laub <flaub@risc0.com>
…ns (#1334)

Newer toolchains have a more detailed panic message in the guest
including the line number of the panic. Without this change the 1.75.0
toolchain will fail the `guest_error_forwarding` test like so:

```
running 1 test
test host::api::tests::guest_error_forwarding - should panic ... FAILED

failures:

---- host::api::tests::guest_error_forwarding stdout ----
thread 'host::api::tests::guest_error_forwarding' panicked at risc0/zkvm/src/host/api/tests.rs:146:22:
called `Result::unwrap()` on an `Err` value: Guest panicked: panicked at src/bin/multi_test.rs:99:13:
MultiTestSpec::Panic invoked
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
note: panic did not contain expected string
      panic message: `"called `Result::unwrap()` on an `Err` value: Guest panicked: panicked at src/bin/multi_test.rs:99:13:\nMultiTestSpec::Panic invoked"`,
 expected substring: `"Guest panicked: panicked at 'MultiTestSpec::Panic invoked'"`
```

Update the expected panic message so it works for older and newer
toolchains.
austinabell and others added 2 commits January 16, 2024 17:53
Currently this will read past the first digest until the block is full
(2*digest). In the case that the second digest is directly after the
first in memory, this read is just redundant. In the case that they are
not, when reading just one, there are unnecessary reads done past the
first digest in memory.

I might be missing something here, but checking manually and running
some basic tests work, so just opening this to see if and what
changes/breaks to see if I am missing something.

---------

Co-authored-by: Frank Laub <flaub@risc0.com>
@flaub flaub merged commit 53d6037 into release-0.20 Jan 17, 2024
26 checks passed
@flaub flaub deleted the flaub/backports branch January 17, 2024 05:24
@flaub flaub added this to the 0.20.0 milestone Jan 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants