-
Notifications
You must be signed in to change notification settings - Fork 0
Description
As I re-read the Ragu book I spotted a few inconsistencies that I found worth flagging if that can help in any ways.
I'm noting them below in no particular order as I go through my notes...
Endoscalars notations
a) In the section below (from https://tachyon.z.cash/ragu/protocol/extensions/endoscalar.html)
The group G1 isn't defined so it's not clear that it is an elliptic curve defined over Fq.
I'd suggest to change:
Consider a random verifier challenge \alpha \in Fp produced in a circuit over Fp where we want to compute \alpha \cdot G \in G1.
to
Consider a random verifier challenge \alpha \in Fp produced in a circuit over Fp where we want to compute \alpha \cdot G where G \in E(Fq) (i.e. a point on a curve defined over Fq)
b) Confusing notations for endoscaling
The section above reads slightly confusing imo because we use \cdot for both scalar multiplication and endoscaling operator.
I think it would be clearer to define an endoscale function or smthg to write something like this instead:
endoscale(s_bar, G) = [lift(s_bar)] \cdot G
Same thing in the section below (from https://tachyon.z.cash/ragu/protocol/core/accumulation/pcs.html) where the notation seems to be slightly abused (the extract returns a bit string not a field element, so the types don't check)
Unless I miss something, it would be clearer to add an argument to the lift function to make things crystal clear in terms of "which field we lift the extracted endoscalar to". Given that endoscalars are used as "cross circuit scalars" it'll be clearer to make the "field we move to" more explicit by passing a field parameter (or a field characteristic) to the lift function.
Something like
Then the consistency property could be written as:
where
And the transcript bridging step mentioned above could use these notations for clarity:
Revdot Products to Polynomial Predicates
See here: https://tachyon.z.cash/ragu/protocol/core/nark.html
- Inconcistent superscript
nfor 0 vectors, see e.g.
The 0 vector (of n elements) which forms the \vec{r} vector misses the "n" exponent.
- Unless I miss something the polynomial product
\hat{r}(X) * r(zX)should ber(X) * r(zX)(or else we shoudld have a normal dot product between the r vector and the rz vector - but to stick to the revdot from the expression above we should probably just remove the "hat" on the\hat{r}(X)polynomial)
Small nitpicks
- Use consistent notations for groups: G_{host}, G_1, G^{(1)} etc
e.g
- In https://tachyon.z.cash/ragu/protocol/prelim/nested_commitment.html -> we use
G_{host},G_{nested} - In https://tachyon.z.cash/ragu/protocol/core/accumulation/index.html -> we use
G^{(1)},G^{(0)}(yet, in https://tachyon.z.cash/ragu/protocol/prelim/bulletproofs.html a very similar notation is used on the G and H vectors)
Given that a lot of times we switch between curves and fields, it could be beneficial to almost have table like
| Field | Curve 1 | Curve 2 |
|---|---|---|
| Base | Fp | Fr |
| Scalar | Fr | Fp |
A bit like below, and use the same p, r subscripts on the fields throughout to represent the base and scalar fields of our curves in the cycle. We can also use a notation G_p and G_r to denote the groups defined by the elliptic curves defined over Fp and Fr respectively.
With recursion I find it sometimes confusing to use terms like "foreign field" or "outer curve" because these are all depend on the context (i.e. which curve / circuit we're currently operating on).
- Use consistent notations for finite fields
Super tiny nitpick, in https://tachyon.z.cash/ragu/protocol/prelim/bulletproofs.html - we use Zq while we stick to Fq notations everywhere else.


