- Remove all crates that are not linked with `autoprecompiles`,
`openvm`, `constraint-solver`
- Remove tests and artifacts linked with removed crates
- Adjust CI
Need to first merge https://github.com/powdr-labs/stark-backend/pull/11.
And then merge https://github.com/powdr-labs/openvm/pull/32.
Original comment by @Schaeff:
```
so here's my suspicion:
to get the number of columns of an air, we use executor.air().width(), in fully qualified syntax openvm_stark_backend::p3_air::BaseAir::width(&executor.air())
this is the number of main trace columns, which does not include interaction columns
in order to get the full number of columns, we need to do what we already do for get_constraints but additionally call InteractionPhaseAirBuilder::finalize_interactions on the symbolic builder to materialize the interactions. Sadly InteractionPhaseAirBuilder is pub(crate) so it seems we need to change stark-backend
```
This PR follows the comment above, but has additional changes:
1. Instead of using `finalize_interactions`, call lower level functions
for greater efficiency.
2. Refactored `AirMetrics` related functions, so we always show the
number of main constraint vs bus interaction columns.
Next step:
1. We should calculate log up columns for APCs as well during PGO.
---------
Co-authored-by: Thibaut Schaeffer <schaeffer.thibaut@gmail.com>
Simple one. Update patch so that it matches up exactly to the git
dependencies.
Before this PR, I had many compilation errors (cuz we are missing a
couple local crates) when syncing up patches during local development,
so might as well push to main so others don't need to fix up in the
future ;)
All APCs need access to periphery chips such as the range checker or the
xor chip.
These chips are expensive to create in memory, but they are not needed
in the end and just get thrown away.
Before this PR, each APC creates one instance of them.
After this PR, a single instance is created and then shared across all
APCs.
This PR adds a new `powdr_expression` crate, containing a simplified
version of `powdr_ast::analyzed::AlgebraicExpression`. The idea here is
that this decouples our Autoprecompiles code from the PowdrVM & PIL
codebase. This will allow us to gradually change the expression type
according to our needs. See #2832 and #2833 as work-in-progress
examples.
Differences to previous `AlgebraicExpression`:
- Generic over the reference type (but
`powdr_autoprecompiles::legacy_expression` adds `AlgebraicReference` and
defines `type AlgebraicExpression<T> = ActualAlgebraicExpression<T,
AlgebraicReference>`, for now)
- Removed `AlgebraicExpression::{PublicReference,Challenge}` variants
- Removed `AlgebraicBinaryOperator::Pow` variant
- `degree_with_cache()` -> `degree()`, as we don't have intermediate
polynomials anymore
I included a `powdr_ast::analyzed::AlgebraicExpression <-->
powdr_autoprecompiles::legacy_expression::AlgebraicExpression`
conversion, which is only used to interact with the `powdr_pilopt`
crate, which still is used by the APC codebase and the PowdrVM / PIL
codebase.
Based on commit 1dbe4db
- Split into two crates, lib and cli
- upgrade stwo, marked one stwo test `should_panic` @ShuangWu121
- various clippy and fmt fixes linked to the rust version update
- bring all rust versions to 2025-05-14. CI still installs other
versions for openvm which uses them internally. The stable rust version
we test on is bumped to 1.85
- remove `examples` and related tests, which test the powdr crate on the
previous version of powdr (since it uses another nightly). Happy to
discuss this if it's important @leonardoalt
cargo CLI tool to generate powdr host/guest templates, install tooling,
etc. Currently only does the former.
The template was copied from the latest version of
https://github.com/powdr-labs/powdr-template . Should we also copy
README?
It can be installed via the cmd below, and it's quite quick:
```console
cargo install --git https://github.com/powdr-labs/powdr --branch cargo-powdr cargo-powdr
```
(without the branch after it's merged)
It can be used via any of these options:
```console
$ cargo-powdr new # creates project 'my-powdr-host' with guest dir 'guest' and guest name 'my-powdr-guest'
$ cargo-powdr new host # creates project 'host' with guest dir 'guest' and guest name 'my-powdr-guest'
$ cargo-powdr new host111 --guest-name guest222 # creates project 'host111' with guest dir 'guest' and guest name 'guest222'
```
This is a major change to the plonky3 prover to support proving many
machines.
# Sharing costs across tables
- at setup phase, fixed columns for each machine are committed to for
each possible size. This happens in separate commitments, so that the
prover and verifier can pick the relevant ones for a given execution
- for each phase of the proving, the corresponding traces across all
machines are committed to jointly
- the quotient chunks are committed to jointly across all tables
# Multi-stage publics
The implementation supports public values for each stage of each table.
This is tested internally in the plonky3 crate but not end-to-end in
pipeline tests.
---------
Co-authored-by: Leo Alt <leo@powdrlabs.com>
This is a (yet unused) component that takes an `Analyzed` and a list of
names and turns these names into `fn(u64) -> u64` to be called directly.
Not all syntax is supported yet (and no built-in functions).
The first goal is not be able to compile all constant functions.
The benchmarks show that `sqrt` is roughly 10 times faster than the
evaluator.
---------
Co-authored-by: Gastón Zanitti <gzanitti@gmail.com>
Co-authored-by: Georg Wiese <georgwiese@gmail.com>
As suggested by @lvella .
I'm not too sure about this actually. I agree that compiling Rust ->
powdr-asm should have a separate pipeline somewhere, but before we could
do Rust -> proof in a single command, and with this we can't anymore.
- Do we expose the `prove` command and everything else here as well?
That'd be a lot of duplicated code.
- Do we force the user to first run `powdr-rs compile <rust_proj>` then
`powdr pil/prove ...`? That's potentially worse UX than right now.
- Do we keep all the Rust stuff in the `cli` crate?
- Refactor `CoProcessors` into a `Runtime` with submachines and syscalls
- Calls into prover functionality and submachines done via `ecall`
instead of "call symbol replacement"
- Call `poseidon_gl` machine with riscv registers by using the stack
(~50% speedup in many_chunks benchmark)
- New `riscv-syscalls` crate keeps the list of syscalls and related
constants
Remove dangling function in macro
Fix variable name in schema_update.rs
Read the version number at runtime instread of compile time
Fix version_number parsing and write new schema after it
Add schemars feature `preserve_order`
Change unwrap for expect in schema_update.rs
Moved schema binary in its own crate
Graceful error management in powdr-schema instead of panic
Better graceful error handling in the pipeline and the cli
Fix clippy
Put the magic number at the start of the serialized data
Revert magic at the start of the file
Moved the SerializedAnalyzed to the schemas crate
Changed serialized.rs to analyzed.rs
Changed the magic number to be the ASCII `powdr`
