Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updates from the June 7 and June 14 meetings #24

Merged
merged 5 commits into from
Jun 28, 2024
Merged

Updates from the June 7 and June 14 meetings #24

merged 5 commits into from
Jun 28, 2024

Conversation

daira
Copy link
Collaborator

@daira daira commented Jun 10, 2024 •
edited
Loading

Thankyou to the participants in the workshop at ZKProof 6 for suggestions! ❤️

First commit: Updates from the June 7 meeting.

  • Fix a bug in the definition of $q_v$: it needs to be a vector of polynomials of width given by the table width $L_v$.
  • Treat fixed columns as a special case of abstract columns, removing the need for $S_F$.
  • Simplify notation:
    • $t_I$ -> $t$
    • $m_F + m_A$ -> $m$
    • $m_F$ -> $m_f$
    • $\equiv_A$ -> $\equiv$
    • $S_I$ and $S_F$ -> $S$
    • $q_v$ -> $q_{v,s}$
    • $\mathsf{ROW}_j$ -> $\vec{w}_j$
    • update variable names for multivariate polynomials to avoid clashes
    • improve notation for comprehensions and type declarations.
  • Simplify the definition of optimization hints, allowing only offsets and not rotations.
  • Take into account lookups in optimization. fixes Start implementing the PLONKish relation in plonk-relation #5

Second commit: Updates from the June 14 meeting.

  • State that we intend to use terminology consistent with the Community Reference.
  • Fix some inconsistencies that were introduced by Daira-Emma in the June 7 changes.
  • Rename:
    • $\mathsf{instance}$ -> $x$
    • $u$ -> $g'$ and $v$ -> $a'$ (to avoid multiple uses of the variable names $u$ and $v$)
  • Define "abstract cell" and "concrete cell" in the optimizations doc, and make sure its use of terminology is consistent with the relation doc.
  • Other minor wording tweaks.

Third commit: Allow several fixed abstract cells with the same value to be mapped to the same concrete cell.

Fourth commit: Improve the presentation of the relation.

Fifth commit: Fix compilation correctness to handle negative $e_i$ and improve the presentation/clarity of the optimization doc.

@daira daira changed the title Updates from the June 7 meeting. Updates from the June 7 meeting Jun 10, 2024
daira
daira commented Jun 10, 2024
View reviewed changes
src/optimizations.md Outdated Show resolved Hide resolved
daira
daira commented Jun 10, 2024
View reviewed changes
src/relation.md
| $S$ | A set $S \subseteq ([0,m) \times [0,n)) \times [0,t)$ indicating which instance entries must be used in the advice. |
| $m_f \leq m$ | Number of columns that are fixed. |
| $f$ | The fixed content of the first $m_f$ columns, $f \mathrel{⦂} \mathbb{F}^{m_f \times n}$. |
| $\mathsf{CUS}_u$ | Sets $\mathsf{CUS}_u \subseteq [0,n)$ indicating which rows the custom functions $p_u \mathrel{⦂} \mathbb{F}^{m} \mapsto \mathbb{F}$ are applied to. |
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to call them "custom" constraints, given that there are no "standard" constraints in this model? Perhaps we should call them something like "gate constraints".

daira
daira commented Jun 10, 2024
View reviewed changes
src/optimizations.md
The values of concrete cells not corresponding to any used abstract cell are arbitrary.

The instance columns are zero-extended to $n'$ rows.
The values of concrete cells not corresponding to any constrained abstract cell are arbitrary.
Copy link
Collaborator Author

@daira daira Jun 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation caveat: it has to be possible to assign uniformly random values on the blinding rows (if used).

@daira @mmaller
Updates from the June 7 meeting.
7980f15 
* Fix a bug in the definition of $q_v$: it needs to be a vector of
  polynomials of width given by the table width $L_v$.
* Treat fixed columns as a special case of abstract columns, removing
  the need for $S_F$.
* Simplify notation:
  * $t_I$ -> $t$
  * $m_F + m_A$ -> $m$
  * $m_F$ -> $m_f$
  * $\equiv_A$ -> $\equiv$
  * $S_I$ -> $S$
  * $q_v$ -> $q_{v,s}$
  * $\mathsf{ROW}_j$ -> $\vec{w}_j$
  * update variable names for multivariate polynomials to avoid clashes
  * improve notation for comprehensions and type declarations.
* Simplify the definition of optimization hints, allowing only offsets
  and not rotations.
* Take into account lookups in optimization.

Co-authored-by: Mary Maller <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
daira
daira commented Jun 14, 2024
View reviewed changes
src/optimizations.md
and similarly for lookups:
$$
\mathsf{LOOK}'_v = \{ \mathbf{r}(j) : j \in \mathsf{LOOK}_v \} \\
j' \in \mathsf{LOOK}'_v \Rightarrow [q_{v,s}\left([w'[h_i, j' + e_i] : i \leftarrow 0 \text{..} m]\right) : s \leftarrow 0 \text{..} L_v] \in \mathsf{TAB}_v
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change fixes #5.

@daira daira changed the title Updates from the June 7 meeting Updates from the June 7 and June 14 meetings Jun 14, 2024
@daira @mmaller @str4d
Updates from the June 14 meeting.
b8d3abf 
* State that we intend to use terminology consistent with the Community
  Reference.
* Fix some inconsistencies that were introduced by Daira-Emma in the
  June 7 changes.
* Rename:
  * $\mathsf{instance}$ -> $x$
  * $u$ -> $g'$ and $v$ -> $a'$ (to avoid multiple uses of the variable names
    $u$ and $v$)
* Define "abstract cell" and "concrete cell" in the optimizations doc, and
  make sure its use of terminology is consistent with the relation doc.
* Other minor wording tweaks.

Co-authored-by: Mary Maller <[email protected]>
Co-authored-by: Jack Grigg <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
@daira
Fix the issue mentioned at zkpstandard#24 (comment)
bf61e05 
about allowing fixed abstract cells with the same value to be mapped to
the same concrete cell.

Signed-off-by: Daira-Emma Hopwood <[email protected]>
@daira
Improve the presentation of the relation.
acadd7d 
Signed-off-by: Daira-Emma Hopwood <[email protected]>
@daira
Fix compilation correctness to handle negative $e_i$ and improve the
2683ccd 
presentation/clarity of the optimization doc.

Signed-off-by: Daira-Emma Hopwood <[email protected]>
@mmaller mmaller merged commit 2e15ad2 into zkpstandard:main Jun 28, 2024
8 checks passed
This was referenced Jun 28, 2024
Open
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mmaller mmaller mmaller approved these changes

Assignees

@str4d str4d

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Start implementing the PLONKish relation in plonk-relation
3 participants
@daira @mmaller @str4d