Problem
Currently compilation of guest programs depend on forks of the Rust compiler maintained by zkVM teams. This is not ideal as it:
- Introduces supply chain risk
- Requires zkVM maintainers to regularly update their fork to the latest upstream Rust
Suggested Solution
- We can use the upstream targets that are maintained by Rust such as
rv64im-unknown-none-elf and add a CI job to ensure its always compatible.
The main blocker for this is the guest program being no_std compatible. The forked Rust compilers had support for std, so we didn't have this issue.
Upon further investigation, the affected crates look like:
Asked AI to order them in terms of hardest to change:
-
ethrex-rlp — Almost no std dependencies. Mostly just gate thiserror/std. Minimal changes needed.
-
ethrex-crypto — Small crate. Gate tracing, kzg-rs, and thiserror/std. The k256 and sha3 already support
no_std.
-
ethrex-trie — Gate tracing, rayon, crossbeam, serde_json, lazy_static, anyhow behind std. Replace
rustc_hash::FxHashMap/FxHashSet with hashbrown equivalents. Handle rkyv/bytecheck feature gating.
-
ethrex-common — Larger surface area. Gate serde_json, kzg-rs, rayon, tracing, url, hex-simd, once_cell,
libc, lazy_static behind std. Replace FxHashMap with hashbrown. Gate serde derives on types containing Bytes.
Handle k256::ecdsa::Error no_std differences.
-
ethrex-vm — Mostly a thin wrapper. Gate tracing, rayon, rkyv, bincode, ethereum-types behind std. Replace
FxHashMap with hashbrown. Add hashbrown/rayon to std feature.
-
ethrex-levm — Hardest by far. Many precompile crypto deps (p256, ripemd, malachite, lambdaworks-math,
bls12_381, ark-bn254, ark-ec, ark-ff) all pull std transitively and must be made optional behind std. Need a
stub precompiles module for no_std. Replace derive_more::Display with thiserror. Replace FxHashMap/FxHashSet
with hashbrown. Gate strum default features. Gate malachite-dependent modexp function. Gate p256 constants.
Ordering seems to be intuitive, though the changes suggested can be done differently
Problem
Currently compilation of guest programs depend on forks of the Rust compiler maintained by zkVM teams. This is not ideal as it:
Suggested Solution
rv64im-unknown-none-elfand add a CI job to ensure its always compatible.The main blocker for this is the guest program being
no_stdcompatible. The forked Rust compilers had support for std, so we didn't have this issue.Upon further investigation, the affected crates look like:
Asked AI to order them in terms of hardest to change:
ethrex-rlp — Almost no std dependencies. Mostly just gate thiserror/std. Minimal changes needed.
ethrex-crypto — Small crate. Gate tracing, kzg-rs, and thiserror/std. The k256 and sha3 already support
no_std.
ethrex-trie — Gate tracing, rayon, crossbeam, serde_json, lazy_static, anyhow behind std. Replace
rustc_hash::FxHashMap/FxHashSet with hashbrown equivalents. Handle rkyv/bytecheck feature gating.
ethrex-common — Larger surface area. Gate serde_json, kzg-rs, rayon, tracing, url, hex-simd, once_cell,
libc, lazy_static behind std. Replace FxHashMap with hashbrown. Gate serde derives on types containing Bytes.
Handle k256::ecdsa::Error no_std differences.
ethrex-vm — Mostly a thin wrapper. Gate tracing, rayon, rkyv, bincode, ethereum-types behind std. Replace
FxHashMap with hashbrown. Add hashbrown/rayon to std feature.
ethrex-levm — Hardest by far. Many precompile crypto deps (p256, ripemd, malachite, lambdaworks-math,
bls12_381, ark-bn254, ark-ec, ark-ff) all pull std transitively and must be made optional behind std. Need a
stub precompiles module for no_std. Replace derive_more::Display with thiserror. Replace FxHashMap/FxHashSet
with hashbrown. Gate strum default features. Gate malachite-dependent modexp function. Gate p256 constants.
Ordering seems to be intuitive, though the changes suggested can be done differently