Skip to content
This repository was archived by the owner on Jul 5, 2024. It is now read-only.

Update workspace to newest Halo2 version #341

Merged
merged 16 commits into from
Feb 25, 2022
Merged

Update workspace to newest Halo2 version #341

merged 16 commits into from
Feb 25, 2022

Conversation

CPerezz
Copy link
Contributor

@CPerezz CPerezz commented Feb 21, 2022

This updates the entire workspace to work with the latest version of
appliedzkp/main. Resolves: #337

For now it is at rev = 514152c8b83de27a5ce17ef70cc44c4092240bd1 but we should try to start at least tagging our versions.

It also introduces the usage of AssignedCell replacing the (Cell, F)
primitive. Which closes: #320

@github-actions github-actions bot added the crate-keccak Issues related to the keccak workspace member label Feb 21, 2022
@github-actions github-actions bot added T-opcode Type: opcode-related and focused PR/Issue crate-zkevm-circuits Issues related to the zkevm-circuits workspace member labels Feb 22, 2022
@CPerezz CPerezz marked this pull request as ready for review February 22, 2022 17:33
@CPerezz CPerezz changed the title Update keccak256 to newest Halo2 version Update workspace to newest Halo2 version Feb 23, 2022
Copy link
Collaborator

@ChihChengLiang ChihChengLiang left a comment

Choose a reason for hiding this comment

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

First round of comments

@@ -12,7 +13,7 @@ pub struct TestCircuit<F> {
block: Block<F>,
}

impl<F: FieldExt> Circuit<F> for TestCircuit<F> {
impl<F: FieldExt + PrimeField<Repr = [u8; 32]>> Circuit<F> for TestCircuit<F> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we need PrimeField everywhere?

It seems if we use use halo2_proofs::arithmetic::FieldExt; instead of use pairing::arithmetic::FieldExt;, it can work with use pairing::bn256::Fr as Fp;.

https://github.com/appliedzkp/halo2/blob/641b4b5f94cb7bbdd710eba0e84f94d1d23ca0c3/halo2_proofs/examples/simple-example-3.rs#L10

@kilic Any comments on this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I discussed with @kilic this and since there are no more to/from_bytes methods, to/from_repr has to be used.

That means that F needs to define it's repr type. And since it's trait bounds, anything that interacts with it needs to have the same bounds which has lead to the propagation of the PrimeField trait.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see. Makes sense to me.

Copy link
Member

Choose a reason for hiding this comment

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

On a different point of view: could we define an alias like:

trait Field: FieldExt + PrimeField<Repr = [u8; 32]> {}

Just to reduce verbosity?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@ed255 I like your proposal

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! Thanks for taking care of this tedious task :)

Take a look at my comment about making the usage of the Field trait less verbose.

@@ -12,7 +13,7 @@ pub struct TestCircuit<F> {
block: Block<F>,
}

impl<F: FieldExt> Circuit<F> for TestCircuit<F> {
impl<F: FieldExt + PrimeField<Repr = [u8; 32]>> Circuit<F> for TestCircuit<F> {
Copy link
Member

Choose a reason for hiding this comment

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

On a different point of view: could we define an alias like:

trait Field: FieldExt + PrimeField<Repr = [u8; 32]> {}

Just to reduce verbosity?

@CPerezz
Copy link
Contributor Author

CPerezz commented Feb 23, 2022

Regarding #341 (comment), @ed255 it looks fine to me to add this alias/supertrait.

It kinda masks a bit the Repr but it might be worth it!
WDYT @ChihChengLiang @han0110 ? If you agree I'll change it since I like it!

@CPerezz
Copy link
Contributor Author

CPerezz commented Feb 24, 2022

After working a bit on the issue @ed255 I've seen that we can create quite an issue with this approach (Correct me if I'm wrong).

SO basically we're creating a new trait in each workspace member. And this trait is basically not implemented for pairing::bn256::Fr. Which leads to rustc having big issues in order to compile all this.

Also the traits are the same but defined in different crates (as there's no crate which is used everywhere in others).

So I'm not sure anymore this is the best solution.
We might prefer to stay with F: FieldExt + PrimeField<Repr = [u8; 32]>. Which I agree is verbose but it's not the worst.

WDYT?

@CPerezz
Copy link
Contributor Author

CPerezz commented Feb 25, 2022

@ed255 @ChihChengLiang I just added it.

Can you confirm whether this is ok and then I merge?

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!

This updates the entire workspace to work with the latest version of
`appliedzkp/main` which works towards #337.

It also introduces the usage of `AssignedCell` replacing the `(Cell, F)`
primitive. Which closes: #320
This adds the trait bounds require to be able to perform byte
serialization for Field Elements.

This updates `eth_types` member to work with the latest version of
`appliedzkp/main` which works towards #337.
Instead of storing `Option<F>` and `Cell` is easier to simply store
`AssignedCell<F,F>` and to reduce the verbosity.
 - Add descriptions for each Lookup.
 - Add trait bounds to enable de/serialization with `To/From_repr`.
 - Remove legacy and unused code.
With the new version of Halo2, serialization is done via `to/from_repr`
which requires to demmand for traits like `ToScalar<F>` which is the
`Repr` used for it's byte repr.
- Make usage of the new Proof generation primitives.
- Refactor the setup generation with the unsafe_fast setup gen. (Just
  for testing).
- Added `ff` as a dependency to gain access to `PrimeField` trait used
  to specify repr details.
- Updated trait bounds for structs and fns that required them since they
  interact with evm/state circuits which have extra trait bounds
  associated to serialization.
Instead of constraining to `FieldExt` + `PrimeField<Repr>` @ed255
suggested to add a supertrait that enforces both and use it across the
workspace.
Copy link
Collaborator

@ChihChengLiang ChihChengLiang left a comment

Choose a reason for hiding this comment

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

LGTM

@CPerezz CPerezz merged commit fecbbcb into main Feb 25, 2022
@CPerezz CPerezz deleted the halo2_update branch February 25, 2022 11:20
CPerezz added a commit that referenced this pull request Mar 3, 2022
As @han0110 said. Before #341 &[&[]] is passed
(as single proof instance with no instnace columns values).
Now we were passing &[] only for instances.
Which basically means that num_proofs=0.

This was causing the errors during the benchmarks triggered in #352.

Co-authored-by: @han0110
@CPerezz CPerezz mentioned this pull request Mar 3, 2022
CPerezz added a commit that referenced this pull request Mar 3, 2022
As @han0110 said. Before #341 &[&[]] is passed
(as single proof instance with no instnace columns values).
Now we were passing &[] only for instances.
Which basically means that num_proofs=0.

This was causing the errors during the benchmarks triggered in #352.

Co-authored-by: @han0110
zemse pushed a commit to zemse/zkevm-circuits that referenced this pull request Mar 22, 2023
* Replace to Rust smart cache in CI.

* Update

* Update and try cache restore.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
crate-keccak Issues related to the keccak workspace member crate-zkevm-circuits Issues related to the zkevm-circuits workspace member T-opcode Type: opcode-related and focused PR/Issue
Projects
None yet
3 participants