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.