-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix!: roll back the compress_selectors
logic
#322
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good! I just have an important comment about the change you did in the "serialization" example.
// TEST for "compress_selectors" logic correctness | ||
let s = meta.selector(); | ||
meta.create_gate("selector gate", |meta| { | ||
let s = meta.query_selector(s); | ||
let a = meta.query_advice(a, Rotation::cur()); | ||
let b = meta.query_advice(b, Rotation::cur()); | ||
vec![s * (a - b)] | ||
}); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would consider removing this. The reason is that this circuit is called StandardPlonk
, and this gate is not part of the standard plonk; so as an example it can be confusing.
Moreover, I don't see any update on the example that assigns values to the new selector s
.
I think it's better to have a unit test for selector to fixed checks (both compression and without, different number of selectors, different expression degree, etc.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#[cfg(feature = "circuit-params")] | ||
params, | ||
); | ||
let (_, _, cs) = compile_circuit(k, circuit, compress_selectors) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is why I tried to implement compile_circuit_cs
originally. So that we could do vk_read
without having to call synthesize on the circuit :(
But unfortunately it's not possible; the cs needs the conversion of selector expressions; and that requires selector assignments, which we obtain by calling synthesize in compile_circuit
.
As a result the methods vk_read
and pk_read
do a lot of work.
Nevertheless the frontend-backend split API methods for reading vk and pk don't suffer from this:
halo2/halo2_backend/src/plonk.rs
Line 99 in 9eedeb5
pub fn read<R: io::Read>( |
So I think this is acceptable :)
compress_selectors
compress_selectors
logic
@guorong009 There's a specific commit (where do you get the old logic) to check? |
The specific commit is referenced in #321 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@@ -44,17 +44,15 @@ use std::io; | |||
pub fn vk_read<C: SerdeCurveAffine, R: io::Read, ConcreteCircuit: Circuit<C::Scalar>>( | |||
reader: &mut R, | |||
format: SerdeFormat, | |||
k: u32, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unfortunate that we need to pass k
because the serialized key already has k
. https://github.com/privacy-scaling-explorations/halo2/blob/9eedeb5d6eb9a119d34307697e670b0bb043a5a5/halo2_backend/src/plonk.rs#L115C9-L115C38
But anyway, this is for the legacy API so I think it's OK. But it makes me wonder, should we deprecate the legacy API at some point? It would make our lives easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I believe that we would need to deprecate the legacy API in near future.
But, I also believe that it should come after discussion with community.
In addition, I think we don't need more work with legacy API, later.
assert!(test_mycircuit(false, false).is_ok()); | ||
} | ||
|
||
#[should_panic] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this test panic from an out of bounds array access?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly.
Fyi, the test panics with following error message.
thread '<unnamed>' panicked at /.../halo2/halo2_backend/src/plonk/evaluation.rs:81:17:
index out of bounds: the len is 2 but the index is 2
Before merging, could you add this piece of documentation in the new test? I think it will help understand what's happening for the compress true/false case:
Maybe this could go as a comment in the test |
b39d0bd
to
95c6bac
Compare
Description
Roll back the logic of compressing selectors in
compile_circuit
Related issue
Changes
compile_circuit_cs
compile_circuit
create_proof_custom_with_engine
halo2_proofs/examples
(additional)