Skip to content
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

Merged
merged 30 commits into from
May 11, 2024

Conversation

guorong009
Copy link

@guorong009 guorong009 commented May 6, 2024

Description

Roll back the logic of compressing selectors in compile_circuit

Related issue

Changes

  • remove compile_circuit_cs
  • roll back the implementation of compressing selectors in compile_circuit
  • remove the create_proof_custom_with_engine
  • correct the related codes
  • add unit test about compressing selectors
  • add a new CI check of running halo2_proofs/examples(additional)

@guorong009 guorong009 requested a review from ed255 May 6, 2024 14:08
Copy link
Member

@ed255 ed255 left a 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.

Comment on lines 51 to 59
// 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)]
});

Copy link
Member

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.)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ed255
I add the unit tests for compress_selectors.
Pls check this file if it is able to cover all possible cases.

#[cfg(feature = "circuit-params")]
params,
);
let (_, _, cs) = compile_circuit(k, circuit, compress_selectors)
Copy link
Member

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:

pub fn read<R: io::Read>(

So I think this is acceptable :)

@ed255 ed255 linked an issue May 7, 2024 that may be closed by this pull request
@guorong009 guorong009 changed the title [draft]: experiment about compress_selectors fix!: roll back the compress_selectors logic May 7, 2024
@adria0
Copy link
Member

adria0 commented May 7, 2024

@guorong009 Roll back the logic of compressing selectors in compile_circuit

There's a specific commit (where do you get the old logic) to check?

@ed255
Copy link
Member

ed255 commented May 7, 2024

@guorong009 Roll back the logic of compressing selectors in compile_circuit

There's a specific commit (where do you get the old logic) to check?

The specific commit is referenced in #321
Basically it's PR #290 and within that PR this commit eddbe95

@guorong009 guorong009 requested a review from ed255 May 9, 2024 14:43
@guorong009 guorong009 self-assigned this May 9, 2024
@guorong009 guorong009 marked this pull request as ready for review May 9, 2024 14:43
Copy link
Member

@ed255 ed255 left a 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,
Copy link
Member

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.

Copy link
Author

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]
Copy link
Member

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?

Copy link
Author

@guorong009 guorong009 May 10, 2024

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

@ed255
Copy link
Member

ed255 commented May 10, 2024

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:

# compress = false

selector `s_add` -> fixed `s_add`
- 1 when `s_add` enabled, 0 otherwise
selector `s_mul` -> fixed `s_mul`
- 1 when `s_mul` enabled, 0 otherwise
selector `s_cubed` -> fixed `s_cubed`
- 1 when `s_cubed` enabled, 0 otherwise

Selector queries in expressions become the corresponding fixed column queries
at rotation 0.

# compress = true

selector `s_add`, `s_mul` -> fixed `s_add_mul`
- 0 when `s_add` disabled and `s_mul` disabled
- 1 when only `s_add` enabled
- 2 when only `s_mul` enabled
selector `s_cubed` -> fixed `s_cubed`
- 1 when `s_cubed` enabled, 0 otherwise
- NOTE: `s_cubed` is not compressed to avoid growing the max degree which is 3

Selector query for `s_add` becomes (`s_add_mul`)*(2 - `s_add_mul`)
Selector query for `s_mul` becomes (`s_add_mul`)*(1 - `s_add_mul`)
Selector query for `s_cubed` becomes the corresponding fixed column query
at rotation 0.

Maybe this could go as a comment in the test test_success. Or as a comment before the tests (wherever you see fit).

@guorong009 guorong009 force-pushed the gr@fix-compile-circuit-cs-experiment branch from b39d0bd to 95c6bac Compare May 10, 2024 12:42
@guorong009 guorong009 merged commit 54a8fd8 into main May 11, 2024
16 checks passed
@guorong009 guorong009 deleted the gr@fix-compile-circuit-cs-experiment branch May 11, 2024 08:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Broken selector compression
3 participants