Making `jolt` `no_std` compatible

[amaloz]

Description

We at Galois have been exploring making jolt-core work in a bare-metal environment (mostly to run the verifier on bare-metal, potentially to run the prover as well). I've done some initial work on this and have a compiling version, although I'm still working on running an actual example in an emulated bare-metal environment. As part of this process, I've identified several concrete steps (read: PRs) that could get jolt to a no_std-compliant form. The goal of course is for everything to still work as-is when compiling as normal, with the added benefit of no_std support when compiling with --no-default-features.

The steps are listed below, would love to hear your thoughts and/or if I should start supplying PRs.

Steps

Steps listed with a * are PR-ready, and steps listed with a ^ need more work. Text in italics discusses changes that go beyond just jolt code.

• * Make the common crate no_std-compliant. This one is fairly straightforward. (Make the common crate no_std-compliant #677)
• * Make the tracer crate no_std-compliant. This one is only slightly more involved, with the exception that we need... (Make tracer no_std compatible #680)
• * Change the ELF loading API to use the ELF contents as a Vec<u8> versus a PathBuf. There are several instances, in both jolt-core and tracer, where the ELF to execute is given by its path versus its contents. Obviously in a no_std environment paths are not available, so this task would change the API to deal with the ELF contents itself, and then the higher level application could do whatever conversion from file-to-contents is necessary. (Make tracer no_std compatible #680)

Those are the initial "easy" steps. Things get trickier with the jolt-core crate, in particular with its use of rayon.

• * Make the binius-field crate no_std-compliant. Almost all crates used already have no_std compliance, except binius. Fortunately, we only use binius-field, and the changes there are relatively straightforward. However, this would either require a fork of binius or for us to try to merge those changes back into binius. binius-field is not longer used.
• ^ Either (1) feature-mask all uses of rayon (not fun) or use (2) biniuss maybe-rayon crate, adapted as necessary. I'm still exploring this second option, and did the first option as part of my effort to get everything compiled (it works, but is obviously not sustainable). This change would require a dependency on biniuss maybe-rayon, and changes made to maybe-rayon as well
• * Replace std with core / alloc where appropriate, plus other changes. This is straightforward, but a lot of changes.
• * Make the jolt-sdk crate no_std-compliant. Straightforward, modulo not being able to generate the guest compile function (since it calls out to cargo).
• ^ Develop an example (or use an existing example) to utilize no_std, alongside documentation on how to run it in, e.g., qemu.

[jprider63]

One thought: maybe the ELF loader should take a &[u8] instead of a Vec<u8> (exposed as a separate function so the existing API doesn't change?).

[moodlezoup]

Thanks for putting this list together @amaloz. The good news is that we've removed binius as a dependency, so that should simplify things slightly.

Let's move forward with the "easy" steps.
Regarding the trickier steps, personally I'd be more interested in making the verifier no_std compliant, so maybe we can start by feature-gating any uses of rayon in the verifier? Of course we'll eventually need to split the prover and verifier into separate crates.

This change would require a dependency on biniuss maybe-rayon, and changes made to maybe-rayon as well

What changes to maybe-rayon do we need?

[amaloz]

What changes to maybe-rayon do we need?

So far it looks like ParallelExtend and ParallelSlice are missing, presumably there are others.

I think using something like maybe_rayon greatly simplifies the changes necessary (feature-masking all the uses of rayon results in serious code bloat), so probably a fork of biniuss maybe_rayon (which is itself a fork of another maybe_rayon crate) is probably the way to go.

[moodlezoup]

I think using something like maybe_rayon greatly simplifies the changes necessary (feature-masking all the uses of rayon results in serious code bloat), so probably a fork of biniuss maybe_rayon (which is itself a fork of another maybe_rayon crate) is probably the way to go.

got it, I agree that this is the way to go