Skip to content

Small recommendations for the book #59

@AntoineRondelet

Description

@AntoineRondelet

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)

Image

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

Image

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)

Image

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

$$\text{lift}(\underline{s}, \mathbb{F}) \to s \in \mathbb{F}$$

Then the consistency property could be written as:

$$\text{endoscale}(\underline{s}, G) = [\text{lift}(\underline{s}, \mathbb{F}_q)] \cdot G$$

where $\mathbb{F}_q$ is $G$'s scalar field

And the transcript bridging step mentioned above could use these notations for clarity:

$$\underline{s} := \text{extract}(s) \in {0,1}^\lambda, s' := \text{lift}(\underline{s}, \mathbb{F}_p) \in \mathbb{F}_p$$

Revdot Products to Polynomial Predicates

See here: https://tachyon.z.cash/ragu/protocol/core/nark.html

  1. Inconcistent superscript n for 0 vectors, see e.g.
Image

The 0 vector (of n elements) which forms the \vec{r} vector misses the "n" exponent.

  1. Unless I miss something the polynomial product \hat{r}(X) * r(zX) should be r(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)
Image

Image

Small nitpicks

  1. Use consistent notations for groups: G_{host}, G_1, G^{(1)} etc

e.g

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.

Image

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).

  1. 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.

Image

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions