Clean up codes and docs in pairing of BN256 & Pluto #147

John-Gong-Math · 2024-03-28T03:17:16Z

This PR is aimed to clean up the pairing implementations bn256/engine.rs and pluto_eris/engine.rs.

Correct and detail the docs by adding more references and intuitions, especially about the type G2Prepared and the case U<0 of the curve Pluto.
Clean up the code used in pluto_eris/engine.rs to make it in line with the BN256 case.

kilic · 2024-03-30T18:41:19Z

@John-Gong-Math Can we go a little further and merge two loops over NEG_SIX_U_PLUS_2_NAF and as a result get rid of G2Prepared?

davidnevadoc · 2024-04-03T15:25:06Z

src/pluto_eris/engine.rs

-/// Points of G2 in Jacobian coordinates.
-/// These are points lie in the twisted curve E'(Fp2).
+/// The type `G2Prepared`` holds the vector of tuples of coefficients which   
+/// are generated during the process of finding [6U + 2]Q. These coefficients 


Q here is a point of the twisted curve E'(Fp2)?

Yes, the input Q is always an affine point in E'(Fp2).

davidnevadoc · 2024-04-03T15:26:14Z

src/pluto_eris/engine.rs

    }

-    /// Prepares a G2 point in affine coordinates.
+    /// Given an affine point Q in E'(Fp2), output the coefficients.


These coefficient are the jacobian coordinates?

I should have made it precise as output the vector of tuples of coefficients.
Each tuple of coefficient is either (tmp0, tmp3, tmp6) in the doubling case or (t10, t1, t9) in the addition case, depends on the bits in 6U+2. Recall the value l of line evaluation can be made out of such coefficients.

davidnevadoc · 2024-04-03T15:33:55Z

src/pluto_eris/engine.rs

-
-        for i in (0..last_position).rev() {
+        // The loop starts from the index of len - 2 instead of len - 1,
+        // see line 3, Algorithm 1 https://eprint.iacr.org/2013/722.pdf


I think this should be line 2:

Good catch!

Oh, I think I meant the Algorithm 1 in the paper: https://eprint.iacr.org/2010/354.pdf
My bad!

Oh, that makes much more sense! :)
Let's update to the paper in the comment then.

davidnevadoc · 2024-04-03T15:41:29Z

src/pluto_eris/engine.rs

+
+        // Initialize the temporary point as Q in Miller loop,
+        // see line 2, Algorithm 1 https://eprint.iacr.org/2013/722.pdf
        let mut r: G2 = q.into();


What is r in the paper notation?
I thought it was T, but then it should be:

line 1: T = 2Q
line 2: T = T + Q

so, T = 3Q before starting the loop.
Am I missing something?

My bad! I meant the Algorithm 1 in the paper: https://eprint.iacr.org/2010/354.pdf

davidnevadoc · 2024-04-03T15:50:52Z

src/pluto_eris/engine.rs

+        // see line 3, Algorithm 1 https://eprint.iacr.org/2013/722.pdf
+        // since the value of NEG_SIX_U_PLUS_2_NAF[len - 1] should always 
+        // be 1, see the original Optimal Ate Pairing paper:
+        // Algorithm 1, https://eprint.iacr.org/2008/096.pdf.


I'm not sure if this justification is enough 🤔 . The algorithm is:

Unlike the other algorithm, the decomposition of s ( l in the other algorithm) is written as a sum from 0 to L without defining L = log_2(s),
so when we see s_L = 1 this just means that we choose the min number of bits L to fit s.

Not sure if I fully understood your point.
In my opinion, s here is simply the binary form where the MSB should always be 1, right? In our case, we use NAF which is another kind of binary form except we accept the bit = -1, but the MSB should always be 1 as well. Thus we can safely ignore the value of MSB bit of NAF of 6U + 2.

davidnevadoc · 2024-04-03T15:57:16Z

src/pluto_eris/engine.rs

+        // Given inputs r , q which exactly stand for the points R, Q in the paper, 
+        // the output is the tuple of three temporary values used for line evaluation 
+        // in this round of Miller loop. Meanwhile, the mutable variable r receives the new
+        // G2 point: Q + R.


Is the output of this function the Fp6 element l?

The output is (t10, t1, t9) as showed in the algorithm, which are Fp2 coordinates of l_0 and l_1 as Fp6 elements. Again, l_0, l_1 are Fp6 coordinates of l as Fp12 element.

davidnevadoc · 2024-04-03T16:11:46Z

src/pluto_eris/engine.rs

+/// true when the given point Q is the infinity. 
 #[derive(Clone, Debug)]
 pub struct G2Prepared {
    pub(crate) coeffs: Vec<(Fp2, Fp2, Fp2)>,


I'm quite confused about what these coefficient are.
3 Fp2 elements can be 2 different things in this context, as far as I can tell:

The Jacobian coordinates of a point of a curve over Fp2 (E'(Fp2))

Result of the line evaluation ( an Fp6 element ?) ( l in the following algorithm)
For context:

I'm pretty sure it is not option 1, but I don't fully understand option 2. Would it be possible to specify more clearly what are these coefficients?

I agree this point is quite confusing, I am trying to explain as following and let me know if any doubt remains:

The three coefficients are tmp_0, tmp_3 and tmp_6 as showed in the algorithm, which are Fp2 elements.

tmp_0, tmp_3 and tmp_6 are Fp2 coordinates of a_0, a_1 as Fp6 elements, as showed in line 18, 19.

The temporary value of line evaluation: l = a_0 + a_1 w are Fp12 element in G_t as required, where a_0, a_1 as Fp6 coordinates.

davidnevadoc · 2024-04-03T16:22:02Z

src/bn256/engine.rs

 pub const BN_X: u64 = 4965661367192848881;

-// 6U+2 for in NAF form
+/// 6U+2 for in NAF form


This is may go beyond the scope of this PR, but could we specify how this NAF representation?
And also, what do we mean by NAF? I assumed "non-adjacent form", but that can't be it since there are many consecutive non-zero entries...

I am also wondering why there are consecutive non-zero entries in this case?

I also don't know exact reason.
But, I found that there was similar discussion about NAF representation.
ethereum/go-ethereum#27957

In addition, I found that there are several sources for 6u + 2 NAF value.
https://github.com/cloudflare/bn256/blob/master/optate.go#L115
https://github.com/AntelopeIO/bn256/blob/4370b6964a4fccc599c42fa7449fb042e59372c5/src/optate.h#L142
https://github.com/randombit/pairings.py/blob/master/bn256.py#L121
https://github.com/matter-labs/pairing/blob/master/src/bn256/mod.rs#L28
~~Seems that they use different NAF algorithm for representation.~~

I have found some answers. @davidnevadoc @John-Gong-Math

Simple answer:
This SIX_U_PLUS_2_NAF is not real NAF representation.
At least, it includes the consecutive non-zero entries.
The real SIX_U_PLUS_2_NAF presentation is:

pub const SIX_U_PLUS_2_NAF: [i8; 66] = [ 0, 0, 0, 1, 0, 1, 0, -1, 0, 0, -1, 0, 0, 0, 1, 0, 0, -1, 0, -1, 0, 0, 0, 1, 0, -1, 0, 0, 0, 0, -1, 0, 0, 1, 0, -1, 0, 0, 1, 0, 0, 0, 0, 0, -1, 0, 0, -1, 0, 1, 0, -1, 0, 0, 0, -1, 0, -1, 0, 0, 0, 1, 0, -1, 0, 1, ];

Even though the current SIX_U_PLUS_2_NAF looks weird, it is correct for computation.
Since it is a borrow from other repos, like go-ethereum.
I still don't know what algo is used for this "NAF" representation.

Long answer:
First of all, the bn256 curve in halo2curves repo is, in essence, bn254(or alt_bn_128) curve, where u = 4965661367192848881.
The go-ethereum developers found & discussed the issue here.
Also, they resolved the issue in this PR.
If you want more information about bn254 curve, you should read this.

Many projects(go-ethereum, matter-labs, Antelope) use the bn256 curve, same as halo2curves.
They all use the same SIX_U_PLUS_2_NAF value(weird NAF from same u value).
Hence, I believe that the current SIX_U_PLUS_2_NAF could've been "borrowed" from other project.
(@kilic can you give some info about this?)

The real NAF representation of SIX_U_PLUS_2_NAF can be computed with cloudflare tool.
We can find more details & code here. (You need to use the correct u value for computation)

After all of this inquiry, I think we have 2 options:

keep the current SIX_PLUS_2_NAF

use the real NAF representation

Since they are all valid for computation, I think we can determine which one to use.
In case of 1st option, it is good for compatibility.(identical to value in other repos)
In case of 2nd option, it does not bring confusion we had.

John-Gong-Math · 2024-04-04T14:46:24Z

@John-Gong-Math Can we go a little further and merge two loops over NEG_SIX_U_PLUS_2_NAF and as a result get rid of G2Prepared?

Thank for both of you for the comments. I will update the codes in the next commits.

add comments and clean up codes in pairing of BN256/Pluto

463c74d

John-Gong-Math changed the title ~~Clean up the codes and docs in pairing of BN256 & Pluto~~ Clean up codes and docs in pairing of BN256 & Pluto Mar 29, 2024

davidnevadoc reviewed Apr 3, 2024

View reviewed changes

davidnevadoc closed this Dec 20, 2024

Clean up codes and docs in pairing of BN256 & Pluto #147

Clean up codes and docs in pairing of BN256 & Pluto #147

Uh oh!

Conversation

John-Gong-Math commented Mar 28, 2024

Uh oh!

kilic commented Mar 30, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

John-Gong-Math Apr 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

John-Gong-Math Apr 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duguorong009 Apr 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duguorong009 Apr 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

John-Gong-Math commented Apr 4, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

kilic commented Mar 30, 2024 •

edited

Loading

John-Gong-Math Apr 4, 2024 •

edited

Loading

John-Gong-Math Apr 4, 2024 •

edited

Loading

duguorong009 Apr 10, 2024 •

edited

Loading

duguorong009 Apr 11, 2024 •

edited

Loading