chore: Add c-kzg library behind a runtime flag #6119
Conversation
|
This closes #6107 though note that we cannot have two c-kzg libraries in this repository because the c-kzg library links to a c static lib, so the mainnet path will always be "affected" -- Another solution would be to maintain a branch that gets merged into stable which has the rust library and the c-kzg-4844 code. Then another branch which is used for peerdas which has both c-kzg-peerdas and the rust lib. This mainly just imposes a cost to maintaining both branches. |
| let blob_bytes: &[u8; BYTES_PER_BLOB] = blob | ||
| .as_ref() | ||
| .try_into() | ||
| .expect("Expected blob to have size {BYTES_PER_BLOB}"); | ||
| if self.use_ckzg { | ||
| let (cells, proofs) = | ||
| c_kzg::Cell::compute_cells_and_kzg_proofs(blob, &self.trusted_setup)?; | ||
|
|
||
| let (cells, proofs) = self | ||
| .context | ||
| .prover_ctx() | ||
| .compute_cells_and_kzg_proofs(blob_bytes) | ||
| .map_err(Error::ProverKZG)?; | ||
| let cells = cells.map(|c| Box::new(c.to_bytes())); | ||
| let proofs = proofs.map(|p| KzgProof::from(p.to_bytes().into_inner())); | ||
|
|
||
| // Convert the proof type to a c-kzg proof type | ||
| let c_kzg_proof = proofs.map(KzgProof); | ||
| Ok((cells, c_kzg_proof)) | ||
| Ok((cells, proofs)) | ||
| } else { | ||
| let blob_bytes: &[u8; BYTES_PER_BLOB] = blob | ||
| .as_ref() | ||
| .try_into() | ||
| .expect("Expected blob to have size {BYTES_PER_BLOB}"); | ||
|
|
||
| let (cells, proofs) = self | ||
| .context | ||
| .prover_ctx() |
There was a problem hiding this comment.
Ideally two new files are created for these two codepaths
| &trusted_setup.g1_monomial_points(), | ||
| &trusted_setup.g1_lagrange_points(), | ||
| &trusted_setup.g2_monomial_points(), |
There was a problem hiding this comment.
Since we changed this from a list of points to a list of flat bytes, I think we should update the names.
| &trusted_setup.g1_monomial_points(), | |
| &trusted_setup.g1_lagrange_points(), | |
| &trusted_setup.g2_monomial_points(), | |
| &trusted_setup.g1_monomial_bytes(), | |
| &trusted_setup.g1_lagrange_bytes(), | |
| &trusted_setup.g2_monomial_bytes(), |
| pub fn g1_lagrange_points(&self) -> Vec<u8> { | ||
| self.g1_lagrange_points.iter().flat_map(|p| { | ||
| let stripped = strip_prefix(p); | ||
| hex::decode(stripped).expect("expected g1 lagrange points to be well formed hex strings") | ||
| }).collect() | ||
| } | ||
| pub fn g1_monomial_points(&self) -> Vec<u8> { | ||
| self.g1_monomial_points.iter().flat_map(|p| { | ||
| let stripped = strip_prefix(p); | ||
| hex::decode(stripped).expect("expected g1 monomial points to be well formed hex strings") | ||
| }).collect() | ||
| } | ||
| pub fn g2_monomial_points(&self) -> Vec<u8> { | ||
| self.g2_monomial_points.iter().flat_map(|p|{ | ||
| let stripped = strip_prefix(p); | ||
| hex::decode(stripped).expect("expected g2 monomial points to be well formed hex strings") | ||
| }).collect() |
There was a problem hiding this comment.
Small nit, I've been trying to use consistent order for these: g1_monomial, g1_lagrange, g2_monomial.
Can we move the middle function to the top?
| let c_kzg_proof = proofs.map(KzgProof); | ||
|
|
||
| Ok((cells, c_kzg_proof)) |
There was a problem hiding this comment.
This should be plural. Plus minor c_kzg vs ckzg nit. Going with ckzg, like use_ckzg.
| let c_kzg_proof = proofs.map(KzgProof); | |
| Ok((cells, c_kzg_proof)) | |
| let ckzg_proofs = proofs.map(KzgProof); | |
| Ok((cells, ckzg_proofs)) |
|
@kevaundray I had a chat with @michaelsproul and he suggested that it might not be a good idea to have two versions of So it might be better to hold off on this one and add this switch once the |
|
Now that we've merged
|
Issue Addressed
This adds back the c-kzg library (updated to the latest commit).
This PR is reliant on #6117 since the new c-kzg API requires g1_monomial. Once that gets merged, then the lines modified should reduce.
Proposed Changes
Please list or describe the changes introduced by this PR.
Additional Info
Please provide any additional information. For example, future considerations
or information useful for reviewers.