Skip to content
This repository has been archived by the owner on May 3, 2024. It is now read-only.

Eip 4844 #125

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Eip 4844 #125

wants to merge 6 commits into from

Conversation

mabbamOG
Copy link

@mabbamOG mabbamOG commented Jul 4, 2023

Reopening PR because of mistake, previous PR: #106

Description

This PR adds the circuit required to integrate Taiko with EIP 4844. Basically it takes data stored in the circuit and uses it for function evaluation. This is then compared with the blob opening checked in the smart contract with EIP 4844. Make sure the data fed into this circuit is checked to be the same as all the other claims of the proof.

Issue Link

#37

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Contents

Contain the new circuit as well as dependencies which support the latest traits along with the latest halo2curves (hence the breaking change...but the circuit has not been integrated into the rest of the zkEVM so everything compiles for now)

Rationale

Required for the L2 to make use of EIP 4844 Blobs, greatly improving costs for publishing new proofs

How Has This Been Tested?

unit tests


Copy link

@vlopes11 vlopes11 left a comment

Choose a reason for hiding this comment

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

Looks good! I like that we have both positive & negative test cases. I added a couple of preliminary questions before the final review, to sync about some points

@@ -0,0 +1,3 @@

target/
Cargo.lock
Copy link

Choose a reason for hiding this comment

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

optional nit: since this is a binary endpoint, we don't necessarily have to ignore the cargo lock. ref

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
halo2_proofs = { git = "https://github.com/mabbamOG/halo2.git" }
Copy link

Choose a reason for hiding this comment

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

Any reason why we are not using the main remote? Might be beneficial to leave a comment of what is blocking and requiring a fork

/// in a single commitment on the EVM, which can then be opened using EVM precompiles.
/// If the same data is also used in the zkEVM circuits, then the two are linked and the ZKP constraints are validated
/// over the same data. To prove that the same data is used in the zkEVM circuits, we could either do a commitment-equivalency
/// test over thta data, or just take the witness data directly and make a function evaluation over it, which is what a KZG
Copy link

Choose a reason for hiding this comment

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

typo thta

///
/// APPROACH:
/// We are going to be implementing the above formula to at the same time interpolate and evaluate over many points
/// of a polynomial. The computations need to be performed in a different field, which is why we make use of Halo2wrong.
Copy link

Choose a reason for hiding this comment

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

consider adding context on why it needs to be performed in a different/non-native field

integer_config: IntegerConfig,
}

/// W is the wrong field, N is the native field
Copy link

Choose a reason for hiding this comment

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

wrong does make sense under the halo2wrong context, but might be a bit confusing without this prior

nbits,
} = self.witness_values;

// 0. JUT MAKE SURE X IS NOT IN THE ROOT-OF-UNITY DOMAIN (otherwise formula doesn't work)

Choose a reason for hiding this comment

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

It's a matter of code style, but I usually don't perform non-constrained checks inside of a circuit. a malicious prover would just remove this code, and this adds overhead to honest provers. If we need to validate input data, we might want to do that a step before the circuit instantiation, also to help the user to debug potential errors.

Ok(assigned_d_i)
})
.collect::<Result<Vec<_>, Error>>()?;
assert!(assigned_datapoints.len() == NUMBER_OF_POINTS);

Choose a reason for hiding this comment

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

Ditto; consider using debug_assert

.collect::<Result<Vec<_>, Error>>()?
.try_into()
.unwrap();
let assigned_x2is: [AssignedInteger<W, N, NUMBER_OF_LIMBS, BIT_LEN_LIMB>; 256] =

Choose a reason for hiding this comment

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

Question: do we need to allocate the entire x2is array? We use the powers only for the bits that aren't enabled


const NUMBER_OF_POINTS: usize = 4096;

fn main() {

Choose a reason for hiding this comment

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

It's unclear why we have a main function testing hardcoded values. Maybe move this to a test case?

}

#[test]
#[should_panic]

Choose a reason for hiding this comment

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

Instead of panic, it might be better to expect a specific error variant, as the panic might be happening for reasons different than the expected. I believe MockProver will return error variants pointing to the constraint that failed - so we can be sure it is the right one

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants