7a1ccfcead
Fixes #1496 Also, a step towards #1572 This PR implements the steps needed in `CompositeBackend` to implement dynamic VADCOP. In summary: - If a machines size (a.k.a. "degree") is set to `None`, fixed columns are computed in all powers of too in some hard-coded range. This fixes #1572. As a result, machines with a size set to `None` are available in multiple sizes. If the size is explicitly set by the user, the machine is only available in that one size. - Note that the ASM linker still sets the size of machines without a size. So, currently, this can only happen when coming from PIL directly. - `CompositeBackend` instantiates a new backend for each machine *and size*: - The verification key contains a key for each machine and size. - When proving, it it uses the backend of whatever size the witness has. The size chosen is also stored in the proof. - When verifying, the verification key of the reported size is used. - Witness generation currently chooses the largest available size. This will change in a future PR. This is an example: ``` $ cargo run pil test_data/pil/vm_to_block_dynamic_length.pil -o output -f --field bn254 --prove-with halo2-mock-composite ... == Proving machine: main (size 256) ==> Machine proof of 256 rows (0 bytes) computed in 209.101166ms == Proving machine: main__rom (size 256) ==> Machine proof of 256 rows (0 bytes) computed in 226.87175ms == Proving machine: main_arith (size 1024) ==> Machine proof of 1024 rows (0 bytes) computed in 432.807583ms ```
powdr
WARNING: This codebase is experimental and has not been audited. DO NOT USE FOR PRODUCTION!
For detailed documentation please visit the powdr book.
If you have any questions or want to contribute, feel free to write us in our Matrix Chat.
powdr is a toolkit that helps build zkVMs and similar proof frameworks.
It has two main components:
- powdr-asm: an extensible assembly IR language to perform dynamic executions.
- powdr-PIL: a low level constraint language that allows you to define arithmetic constraints, lookups, etc. It includes a functional meta-constraint language to describe how constraints are generated.
Both frontend and backend are highly flexible.
As an example, powdr contains a frontend that enables you to write code in (no-std) Rust, which is compiled to RISCV, then to powdr-asm and finally to powdr-PIL.
powdr-pil can be used to generate proofs using multiple backends, such as:
- Halo2, using PSE's
- eSTARK, using
- Plonky3 (ongoing work): https://github.com/powdr-labs/powdr/pull/1158
All stages are fully automatic, which means you do not need to write any additional code for witness generation besides your Rust code. All witnesses are automatically inferred from the constraints. Since the witnesses are inferred, powdr can ensure that the system is not underconstrained, i.e. there are no additional unwanted witnesses.
All artifacts from the compilation pipeline are human-readable. You can inspect the RISCV assembly files, the powdr-asm IR, and the compiled PIL file.
The assembly language is designed to be extensible and does not have a single native instruction. Instead, all instructions are user-defined and because of that, it is easy to adapt powdr assembly to any VM.
Notes on Efficiency
The current focus of the project is VM support and developer experience. The compiler generates many unnecessary columns. We will soon start writing optimizer steps that should bring performance closer to existing production systems.
Project structure
For an overview of the project structure, run:
cargo doc --workspace --no-deps --open
Contributing
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as below, without any additional terms or conditions.
License
This project is licensed under either of
at your option.