Adapt low degree proof on G2 for compatibility with perpetual power of tau #222

bxue-l2 · 2024-01-30T21:12:15Z

Why are these changes needed?

We uses the SRS generated by perpetual power of tau

Although the perpetual power of tau is designed to have 2^28 points, in the setup, they actually generated 2^29-1 g1 points. https://github.com/dcbuild3r/ptau-deserializer/blob/main/deserialize/ptau.go#L25. Whereas there are only 2^28 G2 points. It is my miss that didn’t catch it .

Then the problem is the adversary can create a wrong degree proof. I.e the following equation
e( [poly(tau)] g1, tau^[max-claimedDegree] g2) = e( [poly(tau^(max-claimedDegree))] g1, [1] g2 )
left hand side g1 is the commitment, right hand side g1 is the degree proof.

Since adversray actually know [2max]g1 due to the artifact of the setup, the adversary can use a higher degree polynomial than claimed, and create a wrong proof by using the higher degree g1. Can you confirm?

Here is a fix, we swap g1 and g2 for the degree proof. Since adversary cannot find a higher g2, then we are safe.
Then we prove the equivalence of [poly(tau)] g1 used in universal verifier and [poly(tau)]_ g2 used in the new degree proof, by following equation
e([poly(tau)] g1, g2) = e(g1, poly(tau) g2)

Since all pairing have common g2 on the left hand side, we can batch all the pairing with 2 MSM. What do you think.

Checks

I've made sure the lint is passing in this PR.
I've made sure the tests are passing. Note that there might be a few flaky tests, in that case, please comment that they are not relevant.
Testing Strategy
- Unit tests
- Integration tests
- This PR is not tested :(

ian-shim · 2024-01-31T23:14:54Z

api/proto/node/node.proto

@@ -108,16 +108,19 @@ message Bundle {
 message BlobHeader {
 	// The KZG commitment to the polynomial representing the blob.
 	bytes commitment = 1;


while we're making this breaking change, should we update the API so that it returns x and y coordinates of the commitment instead of the serialized bytes?
same as length_commitment and length_proof

Or JSON, it's much more widely accepted than gob

yup either one
@bxue-l2 if you want me to work on it let me know. I can work on a separate PR that this can rebase onto

that will be great

ian-shim · 2024-01-31T23:18:20Z

core/encoding/encoder.go

@@ -98,8 +99,8 @@ func (e *Encoder) Encode(data []byte, params core.EncodingParams) (core.BlobComm
 }

 func (e *Encoder) VerifyBlobLength(commitments core.BlobCommitments) error {
-
-	return e.EncoderGroup.VerifyCommit(commitments.Commitment.G1Point, commitments.LengthProof.G1Point, uint64(commitments.Length-1))
+	//commitments.Commitment.G1Point,


jianoaix · 2024-02-01T17:23:18Z

pkg/encoding/kzgEncoder/encoder.go

 	}

 	// compute commit for the full poly
 	commit := g.Commit(poly.Coeffs)
+	lowDegreeCommitment := bls.LinCombG2(g.Srs.G2[:len(poly.Coeffs)], poly.Coeffs)


How does the verifier know this is committing to the same polynomial as the above commitment (just use a different group)?

jianoaix · 2024-02-01T17:27:42Z

pkg/encoding/kzgEncoder/batchCommitEquivalence.go

The file name convention has been using underscore to connect subparts

jianoaix · 2024-02-01T17:49:49Z

api/proto/node/node.proto

@@ -108,16 +108,19 @@ message Bundle {
 message BlobHeader {
 	// The KZG commitment to the polynomial representing the blob.
 	bytes commitment = 1;
+  	// The KZG commitment to the polynomial representing the blob on G2, it is uesd 


uesd -> used.
The length_proof is used to prove the degree, not length_commitment?

jianoaix · 2024-02-01T17:50:17Z

api/proto/node/node.proto

@@ -108,16 +108,19 @@ message Bundle {
 message BlobHeader {
 	// The KZG commitment to the polynomial representing the blob.
 	bytes commitment = 1;


Or JSON, it's much more widely accepted than gob

mooselumph · 2024-02-02T18:11:17Z

core/encoding.go

@@ -14,6 +14,16 @@ type Commitment struct {
 	*bn254.G1Point
 }



I think we should do away with all of these custom types. My suggestion:

We have

type G1Point struct { *bn254.G1Point } type G2Point struct { *bn254.G2Point }

And create seralization/deserialization methods for these.

If we want to, we can also do some type aliasing, i.e.

type LengthProof = G2Point type RevealProof = G1Point

I think it's probably okay to fully drop the Commitment and LengthCommitment tpyes/aliases and just use the G1Point and G2Point types directly.

I like this suggestion.
What about creating a new type instead of type aliasing though (type LengthProof G2Point)? I think it's safer to use stronger types

Doing the stronger typing here obviously has the disadvantage that you can't use any methods like serialization/deserialization of the G2Point directly on the LengthProof object. You'd have unwrap, call the method, or call the method and then wrap.

I don't have a strong sense of the advantages of the stronger typing in this case, but I'm happy to defer to you.

mooselumph · 2024-02-02T18:20:25Z

core/data.go

-	Commitment  *Commitment `json:"commitment"`
-	LengthProof *Commitment `json:"length_proof"`
-	Length      uint        `json:"length"`
+	Commitment       *Commitment       `json:"commitment"`


I wonder if it would be clearer/cleaner to just call the Commitment and LengthCommitment fields G1Commitment and G2Commitment?

Wdyt @bxue-l2, @jianoaix, @ian-shim?

For the name of the type, yeah that sounds clearer

mooselumph · 2024-02-02T18:37:49Z

pkg/encoding/kzgEncoder/batchCommitEquivalence_test.go

+	"github.com/stretchr/testify/require"
+)
+
+func TestBatchEquivalence(t *testing.T) {


Should we add a failing test case for difference commits?

mooselumph

Looks good, just a few comments on naming and tests.

mooselumph · 2024-02-02T23:53:00Z

Looks like this may need to be rebased to the current master.

Co-authored-by: Robert Raynor <[email protected]> Co-authored-by: Jian Xiao <[email protected]> Co-authored-by: steven <[email protected]> Co-authored-by: steven <[email protected]> Co-authored-by: siddimore <[email protected]> Co-authored-by: Ian Shim <[email protected]> Co-authored-by: bolatfurkan <[email protected]> Co-authored-by: Peter Straus <[email protected]> Co-authored-by: WELLINGTON MIRANDA BARBOSA <[email protected]> Co-authored-by: Wellington Barbosa <[email protected]> Co-authored-by: Jian Xiao <[email protected]> Co-authored-by: buldazer <[email protected]> Co-authored-by: Madhur Shrimal <[email protected]> Co-authored-by: Daniel Mancia <[email protected]>

bxue-l2 · 2024-02-03T00:31:44Z

Looks like this may need to be rebased to the current master.

rebased

bxue-l2 · 2024-02-03T00:33:58Z

Will addressed in a PR for cleanup

The file name convention has been using underscore to connect subparts from Jian
#222 (comment)

uesd -> used. Nix from Jian
#222 (comment)

Unwrap and string typing from Robert
#222 (comment)

CommitmentType from Robert
#222 (comment)

ian-shim · 2024-02-03T01:35:33Z

Also needs to address this one in the follow up PR: #222 (comment)

bxue-l2 changed the title ~~init change~~ Adapt low degree proof on G2 for compatibility with perpetual power of tau Jan 31, 2024

bxue-l2 requested review from mooselumph, jianoaix and ian-shim January 31, 2024 07:03

bxue-l2 marked this pull request as ready for review January 31, 2024 18:23

ian-shim reviewed Jan 31, 2024

View reviewed changes

jianoaix reviewed Feb 1, 2024

View reviewed changes

mooselumph reviewed Feb 2, 2024

View reviewed changes

Ubuntu and others added 10 commits February 3, 2024 00:08

init change

cb2fa53

fix test

75807e1

fix lint

ec3e711

working e2e

194a708

fix retriver and change method name to xxBatch

9b7038b

fix retrieve test

b1a784b

fix integration test

d54ec48

fix batch equivalence test

5f89ad2

rebase fix

bd6f70d

bxue-l2 force-pushed the adapt-low-degree-proof-to-g2 branch from 2261b80 to bd6f70d Compare February 3, 2024 00:22

ian-shim approved these changes Feb 3, 2024

View reviewed changes

jianoaix approved these changes Feb 3, 2024

View reviewed changes

bxue-l2 merged commit 3aabde7 into Layr-Labs:master Feb 3, 2024
4 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adapt low degree proof on G2 for compatibility with perpetual power of tau #222

Adapt low degree proof on G2 for compatibility with perpetual power of tau #222

bxue-l2 commented Jan 30, 2024 •

edited

Loading

ian-shim Jan 31, 2024

jianoaix Feb 1, 2024

ian-shim Feb 2, 2024

bxue-l2 Feb 2, 2024

ian-shim Feb 2, 2024

ian-shim Jan 31, 2024

jianoaix Feb 1, 2024

jianoaix Feb 1, 2024

jianoaix Feb 1, 2024

jianoaix Feb 1, 2024

mooselumph Feb 2, 2024

ian-shim Feb 2, 2024

mooselumph Feb 2, 2024

mooselumph Feb 2, 2024

jianoaix Feb 2, 2024

mooselumph Feb 2, 2024

mooselumph left a comment

mooselumph commented Feb 2, 2024

bxue-l2 commented Feb 3, 2024

bxue-l2 commented Feb 3, 2024

ian-shim commented Feb 3, 2024

Adapt low degree proof on G2 for compatibility with perpetual power of tau #222

Adapt low degree proof on G2 for compatibility with perpetual power of tau #222

Conversation

bxue-l2 commented Jan 30, 2024 • edited Loading

Why are these changes needed?

Checks

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mooselumph left a comment

Choose a reason for hiding this comment

mooselumph commented Feb 2, 2024

bxue-l2 commented Feb 3, 2024

bxue-l2 commented Feb 3, 2024

ian-shim commented Feb 3, 2024

bxue-l2 commented Jan 30, 2024 •

edited

Loading