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

Ethereum Verkle tries - IPA refactoring (part 1) #392

Merged
merged 8 commits into from
Jun 11, 2024
Merged

Conversation

mratsim
Copy link
Owner

@mratsim mratsim commented Jun 11, 2024

This PR is a follow-up to the Verkle Tries and IPA PRs from @agnxsh and @advaita-saha:

It addresses part of the cleanup mentioned in #367 and #361.
Part 1 focuses on Lagrange polynomials.

The new proc are generic to any size of polynomials and any field and any domain with specialization for linear [0, ..., N-1] domains like Ethereum Verkle Tries.

  • reimplement Lagrange polynomials in a generic way and replace barycentric_form.nim.
    Implementation removes duplication with KZG-4844 Lagrange polynomial (that uses roots of unity instead of a generic domain) where it makes sense. Address evalInDomain / evalOutside domain and the Lagrange form of IPA are duplicates of KZG the polynomial functions (used in EIP-4844) need to be deduplicated and parallelized. from IPA / Verkle tree cleanups #367
    • Introduce PolyEvalDomain, PolyEvalRootsDomain and PolyEvalLinearDomain types to specialize for different kinds of evaluation domains for KZG and IPA commitments.
    • Introduce various vanishing polynomials functions.
  • multiScalarMul_reference_vartime now supports the same range as input as the optimized impl (openArrays, pointer+length, field elements ...) to workaround MSM - optimized MSM wrong result in IPA verifier. #390. Address scalarMul needs an overload for field element and not just big ints from IPA / Verkle tree cleanups #367
  • research into using Verkle Tries with roots of unity. Unfortunately not possible as 2-adicity is too small.
  • rename trusted_setups folder to commitments_setups as inner product argument setup is transparent and is not trusted. Note: we might want to use protocols_setup if we have some non-commitment setup that appear in the future.
  • batchInversion for finite field had a bug with zeros, they were skipped instead of returning zero like a single inversion does. They are now part of finite_fields.nim instead of codecs_banderwagon

A follow-up PR will generalize the current Verkle-only IPA implementation.

@@ -1,6 +1,6 @@
# Trusted Setups
# Reference Strings & Trusted Setups
Copy link
Owner Author

Choose a reason for hiding this comment

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

With IPA, we now need to support transparent setups, CRS / URS for Common/Universal Reference Strings. Those are opposed to SRS, (hidden) structured reference strings, which have a toxic secret that no one should have access to, i.e. a trusted setup.

The folder likely should be named protocol_setups but since those setups are related to the polynomial commitments, it's nice to have both close to each other

type
IPASettings* = object
SRS*: array[VerkleDomain,EC_P]
Copy link
Owner Author

Choose a reason for hiding this comment

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

IPA has no trusted setup (SRS), it uses a transparent setup (CRS).

type
PrecomputedWeights* = object
barycentricWeights*: array[512,Fr[Banderwagon]]
invertedDomain*: array[510,Fr[Banderwagon]]
Copy link
Owner Author

Choose a reason for hiding this comment

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

Those are now integrated in the polynomial evaluation domain.

type
IPASettings* = object
SRS*: array[VerkleDomain,EC_P]
Q_val*: EC_P
Copy link
Owner Author

Choose a reason for hiding this comment

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

We can inline the generator at compile-time with Nim. And store it in affine coordinates instead of projective to reduce memory cost.

Q_val*: EC_P
precompWeights*: PrecomputedWeights
crs*: array[EthVerkleDomain, ECP_TwEdwards_Aff[Fp[Banderwagon]]]
domain*: PolyEvalLinearDomain[EthVerkleDomain, Fr[Banderwagon]]
numRounds*: uint32
Copy link
Owner Author

Choose a reason for hiding this comment

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

Note that numRounds is actually unused in the code

for degree, root in enumerate(roots):
print(f'degree: {2**degree}, root: {hex(root)}')
print(f' check root^{2**degree} (mod r) = {hex(pow(root, 2**degree, r))}')

Copy link
Owner Author

Choose a reason for hiding this comment

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

Unfortunately, the biggest power of 2 that factorizes p-1 is 32, so not large enough for a domain of size 256.

doAssert (abs == 100).bool() == true, "Absolute value should be 100!"
doAssert (abs < 0).bool() == false, "Value was negative!"

testAbsInteger()
Copy link
Owner Author

Choose a reason for hiding this comment

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

Negative precomputations are not needed.

discard x_fr
points[k] = point

discard lagrange_values
Copy link
Owner Author

Choose a reason for hiding this comment

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

unused

var arr_byte {.noInit.}: array[256, array[32, byte]]
discard arr_byte.serializeBatch(ipaConfig.SRS)

doAssert arr_byte[0].toHex() == "0x01587ad1336675eb912550ec2a28eb8923b824b490dd2ba82e48f14590a298a0", "Failed to generate the 1st point!"
Copy link
Owner Author

Choose a reason for hiding this comment

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

already tested line 183 (old) 193 (new)

tmpc *= x

res.prod(tmpa, tmpb)
res *= tmpc
Copy link
Owner Author

Choose a reason for hiding this comment

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

moved directly in the test as too much context is missing here.

@mratsim mratsim merged commit 465ab98 into master Jun 11, 2024
12 checks passed
@mratsim mratsim deleted the ipa-refactoring branch June 11, 2024 21:51
@mratsim mratsim linked an issue Jun 11, 2024 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Polynomial refactoring
1 participant