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

peerDAS: Initial refactor of recover_polynomial() #3591

Merged
merged 11 commits into from
Feb 14, 2024

Conversation

asn-d6
Copy link
Contributor

@asn-d6 asn-d6 commented Jan 31, 2024

Hello all,

took a stab at splitting recover_polynomial() into three helper functions, as discussed in #3557.

I also sprinkled a few comments around with references to Vitalik's ethresearch post. Comments can and should be greatly improved in the future.

Commit 06a5d03 is a slightly opinionated refactor of construct_vanishing_polynomial() which I don't have a strong opinion on.

IMO the recover_polynomial() function can be further improved in terms of helper functions, variable naming, and overall documentation, but I suggest we do this in iterated steps.

/cc @hwwhww @dankrad @jtraglia

@asn-d6 asn-d6 force-pushed the peerdas_refactor_recovery_polynomial branch from 06a5d03 to 212c1fe Compare January 31, 2024 12:04
Copy link
Member

@jtraglia jtraglia left a comment

Choose a reason for hiding this comment

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

Looks much better! Here's my initial review.

specs/_features/eip7594/polynomial-commitments-sampling.md Outdated Show resolved Hide resolved
specs/_features/eip7594/polynomial-commitments-sampling.md Outdated Show resolved Hide resolved
specs/_features/eip7594/polynomial-commitments-sampling.md Outdated Show resolved Hide resolved
specs/_features/eip7594/polynomial-commitments-sampling.md Outdated Show resolved Hide resolved
specs/_features/eip7594/polynomial-commitments-sampling.md Outdated Show resolved Hide resolved
specs/_features/eip7594/polynomial-commitments-sampling.md Outdated Show resolved Hide resolved
"""
Given Z(x), return polynomial Q_1(x)=(E*Z)(k*x) and Q_2(x)=Z(k*x) and k^{-1}
"""
shift_factor = BLSFieldElement(PRIMITIVE_ROOT_OF_UNITY)
Copy link
Member

Choose a reason for hiding this comment

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

The c-kzg prototype currently uses 5, but I think it makes sense to use PRIMITIVE_ROOT_OF_UNITY (7); I will update c-kzg to use this. I'm not exactly sure if it makes a difference. Also, we call it scale_factor which I slightly prefer.

Copy link
Contributor

Choose a reason for hiding this comment

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

5 is not a primitive root of unity. This was a mistake we had in some research code some years ago. (Not important here but it is in the rest of the code -- we need to use the same sequence of roots of unity everywhere)

Here the only thing that matters is that it's not in our evaluation domain, so there is no risk that the vanishing polynomial is zero anywhere on the shifted domain.

@hwwhww hwwhww added the EIP-7594 PeerDAS label Feb 1, 2024
Copy link
Contributor

@hwwhww hwwhww left a comment

Choose a reason for hiding this comment

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

The last assertion in recover_polynomial:

    for cell_id, cell in zip(cell_ids, cells):
        start = cell_id * FIELD_ELEMENTS_PER_CELL
        end = (cell_id + 1) * FIELD_ELEMENTS_PER_CELL
        assert reconstructed_data[start:end] == cell

In what case it would fail? Or it's just for debugging?

specs/_features/eip7594/polynomial-commitments-sampling.md Outdated Show resolved Hide resolved
@asn-d6
Copy link
Contributor Author

asn-d6 commented Feb 5, 2024

The last assertion in recover_polynomial:

    for cell_id, cell in zip(cell_ids, cells):
        start = cell_id * FIELD_ELEMENTS_PER_CELL
        end = (cell_id + 1) * FIELD_ELEMENTS_PER_CELL
        assert reconstructed_data[start:end] == cell

In what case it would fail? Or it's just for debugging?

It's a sanity check similar to the asserts in construct_vanishing_polynomial(). If the function works properly, those asserts should never fail.

The asserts essentially check that the recovered data is consistent with the data we used to do the recovery.

@asn-d6
Copy link
Contributor Author

asn-d6 commented Feb 5, 2024

Updated the PR here based on your reviews. Thanks all!

Copy link
Member

@jtraglia jtraglia 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 👍 two small nits which could be ignored.

@dankrad
Copy link
Contributor

dankrad commented Feb 6, 2024

lgtm

Copy link
Contributor

@hwwhww hwwhww left a comment

Choose a reason for hiding this comment

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

lgtm! good job @asn-d6 👍

@hwwhww hwwhww merged commit 2faa44b into ethereum:dev Feb 14, 2024
30 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EIP-7594 PeerDAS
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants