Feature/tables

[druiz0992]

Table calculation is done only for G1. I show how to use the table pre-calculation in the test in different scenarios

Pending things include:

• G2 tables -> Should be same as G1
• multi threading
• Use it in actual prover
• Write tables content to file during Trusted Setup phase
• Synchronize reading table file with Mexp computation for long files

To do it correctly, we should fork pairing library as there are several improvements that can be done:

• Doubling operation is not exported and it is more efficient than adding by itself (as i am currently doing)
• MakeAffine function is not exported. Addition of a Jacobian and Affine point is more efficient than adding two Jacobian points.
• In order to avoid repeating the code in for G2 tables, we could add an interface?
• I saw the code and they use 4 corrdinates. Not sure why they use the fourth one (It is z^2). I think we can leave without this 4th coordinate and save the time to compute it.

[druiz0992]

I added some additional changes after requesting pull request. Not sure how to proceed.

• I added G2. However, i don't like how i did it. I copied the code of G1. I am not sure how to do it unless i use empty interface or modify original G1/G2 code.
• I used one of the 4 options implemented (No doubles and calculate tables within proof). To further reduce times we could pre-calculate tables during setup. Even like this, savings are considerable

[ed255]

This looks very promising! Here are some notes regarding the PR

Format

Go has some canonical formatting rules that we follow strictly thanks to the gofmt tool. I see that your code uses inconsistent levels of indentation and uses different rules of spacing between tokens.

We use gofmt (usually configured as an editor plugin so that every time we save a file it is formatted). This allows having a consistent format across all the code base an removes discussions about formatting (we just follow what gofmt says). So I would ask you to run gofmt over your code.

Number of commits

In every PR we try to stick to a low number of commits. In general we try to organize the commits into meaningful and related packets of work done / features. So we try to avoid implementing a single feature into two commits. In your PR I can see for example that there are 3 commits named Update tables.md which could be merged together. Or a Fixed merge conflicts that could be merged into another commit. I'm not sure if you're familiar with git rebase. It allows you to squash commits (join them), and reorder them. I suggest you try to reorganize the commits a bit; you can make a new branch and try git rebase -i 8c81f5041ec12016abb602f0432651cf183f0088 there and experiment with git rebase.

Git commit subject

This is a very minor thing, but we try to follow the rule of having the commit subject in imperative tone. I won't ask you to change the subjects for this PR, but please be aware of this convention in the future :)

Repeated code in ScalarMultNoDoubleG1 and ScalarMultNoDoubleG2

I will take a look and see if I can come up with a nice solution.

[arnaucube]

I've executed the proof generation for circuits of 1k, 5k, 10k, 20k, 50k constraints in my laptop and in the intel nuc and the results are very nice!! :smile_cat:

• intel nuc: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz, with 32GB of RAM with 8 cores

constraints	before this PR	with this PR
1k	185.853367ms	211.110172ms
5k	875.408321ms	488.589314ms
10k	1.724526371s	828.930297ms
20k	3.434832853s	1.517834681s
50k	8.179939441s	3.375135829s

• thinkpad x270: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, with 16GB of RAM with 4 cores

constraints	before this PR	with this PR
1k	454.637472ms	330.973803ms
5k	2.133982394s	969.211664ms
10k	4.204777476s	1.731214548s
20k	8.541817521s	3.362511834s
50k	20.645559622s	7.931245895s

[druiz0992]

Switched to #10.