chore: separate the code in three different crates#206
chore: separate the code in three different crates#206dartdart26 wants to merge 4 commits intoWizardOfMenlo:mainfrom
Conversation
Separate to the `prover`, `common`, `verifier` and `cli`. Rationale is that we'd like to be able to run the verifier without randomness, say on onchain targets (Solana SBF, WASM-based chains, etc.). Use the `custom` feature for getrandom in order to silence the linker when building for targets without support as the verifier doesn't need randomness anyway. Add an `onchain` Cargo profile that can be used to compile such targets. Also support cases in NTT where usize::BITS is not 64 for 2 adicity (e.g. WASM). To test some of these targets, go to the verifier dir and: ``` CARGO_PROFILE_RELEASE_LTO=fat \ CARGO_PROFILE_RELEASE_DEBUG=false \ CARGO_PROFILE_RELEASE_STRIP=symbols \ CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1 cargo build-sbf ``` or ``` cargo build --target wasm32-unknown-unknown ``` Co-authored-by: Tsvetomir Dimitrov <tsv.dimitrov@gmail.com>
They remove static variable such that their names don't take space in the ELF symbol table. `disable-hash-counter`: disables the `HashCounter` static cached counter `disable-ntt-cache`: disables the static `NttEngine` engine cache Also, make the `parallel` feature optional in the `common` crate and the `spongefish` dependencies and use `parallel` in the `prover` crate only.
This allows for more efficient use by avoiding cloning inside the verifier that would happen every time.
|
Can we do this through feature flags instead? E.g. have an optional Separating prover from verifier as proposed makes protocol development complicated as two tightly related parts become widely spaced apart. Another viable alternative is to implement a 2nd standalone verifier that maybe only supports a subset of the protocol, but caters to the needs of very underpowered targets. |
Hey, I somehow missed your message, sorry about that. Let me remember the details and will get back to you! |
2 participants
Separate to the
prover,common,verifierandcli.Rationale is that we'd like to be able to run the verifier without randomness, say on onchain targets (Solana SBF, WASM-based chains, etc.). Use the
customfeature for getrandom in order to silence the linker when building for targets without support as the verifier doesn't need randomness anyway.Add an
onchainCargo profile that can be used to compile such targets.Also support cases in NTT where usize::BITS is not 64 for 2 adicity (e.g. WASM).
To test some of these targets, go to the verifier dir and:
or