EIP-7594: Add cryptography specs for sampling

[dankrad]

Add the spec for the cryptography that is required for sampling

---

Deneb change:

• Add KZG_SETUP_G1_MONOMIAL to the trusted setup file

Known TODOs in other PRs:

• Fix linter
• Fix roots of unity preset
• Accelerate the performance (in algorithm or use other binding)
• Refactor
• Add more test cases

[mratsim]

Something like:

Public functions MUST accept raw bytes as input, serialized according to:

• https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html#name-bls12-381
• https://github.com/zkcrypto/pairing/blob/34aa52b0f7bef705917252ea63e5a13fa01af551/src/bls12_381/README.md#serialization

and perform the following checks:

• Field element a:
  • in the range 0 <= a < r
• Elliptic curve point P:
  • field coordinates (x, y) are in the range 0 <= x, y < p
  • Point is on the curve (G1: y² = x³ + b, G2: y² = x³ + ξb, with ξ the multiplicative twist)
  • Point is in the proper subgroup

Details are available in the IETF spec for KeyValidate, but identity point is allowed: https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html#name-keyvalidate

[jtraglia]

Looking great! Here are some things I noticed during my initial review.

Also, how would you feel about a more complex sample structure? For example:

class Sample(Container):
    data: Vector[BLSFieldElement, FIELD_ELEMENTS_PER_SAMPLE]
    proof: KZGProof
    row_index: uint64
    column_index: uint64

I got this idea from the aggregated sample verification proof of concept here. When I made the changes to my prototyping work, I found that it simplified a lot and made the code more human readable.

[jtraglia]

This function would benefit from being broken up into smaller pieces 😅

[hwwhww]

Discussed with @dankrad today.

Some TODO actions:

• [@hwwhww] clean up cryptography specs:
  • move to _features/peerdas folder.
  • make it executable there.
• [@hwwhww] sync the naming: use “cell” for the unit in matrix
• Find cryptographers to help review the cryptography logic

[asn-d6]

Awesome work here! Did an initial rudimentary review. I would like to spend some time next week to think how to break down recover_samples_impl() into more granular functions.

[asn-d6]

Awesome work here! Did an initial rudimentary review. I would like to spend some time next week to think how to break down recover_samples_impl() into more granular functions.

From an initial investigation (and reading the corresponding ethresearch post), I think we can split recover_samples_impl() into the following subroutines:

• construct_vanishing_polynomial() which constructs the vanishing "subset" polynomial (i.e. up to the first round of asserts)
• recover_shifted_data() (i.e. up to eval_shifted_reconstructed_poly)
• recover_original_data() (i.e. up to the end of the func)

It might be possible to split recover_shifted_data() further into what Vitalik calls Q_1, Q_2, Q_3 in his post, but we can see about that.

I can take a stab at it next week.

[asn-d6]

Awesome work here! Did an initial rudimentary review. I would like to spend some time next week to think how to break down recover_samples_impl() into more granular functions.

From an initial investigation (and reading the corresponding ethresearch post), I think we can split recover_samples_impl() into the following subroutines:

• construct_vanishing_polynomial() which constructs the vanishing "subset" polynomial (i.e. up to the first round of asserts)
• recover_shifted_data() (i.e. up to eval_shifted_reconstructed_poly)
• recover_original_data() (i.e. up to the end of the func)

It might be possible to split recover_shifted_data() further into what Vitalik calls Q_1, Q_2, Q_3 in his post, but we can see about that.

I can take a stab at it next week.

FWIW, after discussion with @hwwhww we decided to do this sort of refactoring after the spec is executable and minimally tested, to avoid introducing bugs during the refactor.

[hwwhww]

Changelog:

• Add KZG_SETUP_G1_MONOMIAL to trusted setup files (Thank @CarlBeek for updating upstream files!)
• Move new docs to the new peerdas feature folder
• Fix some helpers (03583b1)
• Add basic verification tests
• Add PeerDAS CI job

[hwwhww]

@asn-d6 @dankrad

I added successful tests for verification and recover functions! @dankrad it was amazing that (I think) there was no tricky bug! 👏 👏

@asn-d6 feel free to go refactor the recover function. I will try to settle down the format of roots of unity in the meanwhile.

[hwwhww]

Per the typing, there is still a mess around PolynomialCoeff. However, to make it mergeable, I skipped the linter check for PeerDAS feature. If anyone wants to add it back, just revert 09c2519

@asn-d6 and I suggest that we merge this PR as status-quo and add more iteration PRs later.

Known TODOs in other PRs:

• Fix linter
• Fix roots of unity preset
• Accelerate the performance (in algorithm or use other binding)
• Refactor
• Add more test cases