chore: use free witness for offset generator in batch_mul

[suyash67]

resolves AztecProtocol/barretenberg#1585

tldr: we make the offset generator a free witness while performing batch_mul

Current Way of Masking Points

While performing batch_mul we create ROM tables of linear combinations of the group elements. If we have an MSM of the form $[(s_1, s_2, \dots, s_n), (G_1, G_2, \dots, G_n)]$ then the ROM tables are of the form:

Index	Element
0	$G_1 + G_2 + \dots + G_5 + G_6$
1	$G_1 + G_2 + \dots + G_5 - G_6$
2	$G_1 + G_2 + \dots - G_5 - G_6$
$\vdots$	$\vdots$
$2^6 - 1$	$- G_1 - G_2 - \dots - G_5 - G_6$

To avoid any entries of the ROM table to be a point at infinity, we add a multiple of an offset generator:

$G'_i := G_i + 2^{i-1}\delta \cdot G_{\textsf{offset}} \quad \forall i \in [0, 6).$

and then we create a ROM table with $(G'_1, G'_2, \dots, G'_6)$. Here, $\delta$ is a verifier-sent challenge so the prover cannot know it beforehand.

Proposed Masking of Points

Instead of sampling a challenge $\delta$, we make the offset generator $G_{\textsf{offset}}$ a free witness in the circuit, so the masked generators become:

$G'_i := G_i + 2^{i-1}\cdot G_{\textsf{offset}} \quad \forall i \in [0, 6).$

We only constrain $G_{\textsf{offset}}$ to be a valid point on the curve. This approach should also be safe because if a malicious prover tries to exploit the fact that he can freely choose $G_{\textsf{offset}}$ the circuit will be unsatisfiable. An honest prover must choose a random point on the curve as $G_{\textsf{offset}}$.

[suyash67]

The gate count reduction is because we do not sample the extra challenge $\delta$ and we do not compute the scalar multiplication $(\delta \cdot G_{\textsf{offset}})$.

[suyash67]

This is the main change. Previously we did the following:

$G_{\textsf{masking}} = \delta \cdot G_{\textsf{offset}}$

Now we make $G_{\textsf{masking}}$ a free witness and it must be a valid curve point.

[ledwards2225]

Makes sense to me. Nice that it amounts to cleanup in a few places

[arielgabizon]

maybe I just don't remember the tag stuff well, but confused by this line - I'd expect us to just not have this challenge_tag now that we don't have the challenge? Why is it set to this evaluation_point.get_origin_tag?

[ledwards2225]

A little while ago we updated the tag mechanism to alert us to combinations like A*\alpha + B, where e.g. A, B are commitments, \alpha a hash that accounts only for A. (This for example would have caught the bug we had in the PG verifier where we converted a bunch of size 2 MSMs into one larger one without proper fiat shamir). But this can give false positives since sometimes B is constrained by some other aspect of the protocol, as is the case here. Here W acts like B (really its more like A + B*\alpha) but it's constrained by the pairing to be correct so the prover isn't free to tamper with it. Setting the tag of W to match that of the challenge z is just the way we tell the tool not to complain. This is what the comment // OriginTag false positive was trying to explain but it could be clearer

[suyash67]

I've added this in the comment, thanks for explaining Luke!