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.

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

Plonk: code cleanup #58

Open
2 of 3 tasks
vesselinux opened this issue Jul 20, 2022 · 2 comments
Open
2 of 3 tasks

Plonk: code cleanup #58

vesselinux opened this issue Jul 20, 2022 · 2 comments
Assignees

Comments

@vesselinux
Copy link
Collaborator

vesselinux commented Jul 20, 2022

  • Have explicit struct members of the a,b,c polynomials currently stored as a single vector W_polys_blinded_at_secret_g1[a,b,c] in the plonk_proof class. Similarly, have explicit struct members for the q_L, q_R, q_O, q_M, a_C selector polynomials currently stored as a single vector Q_polys in the circuit struct.

  • In all header files: leave only functions that are externally visible to calling code. If a function is only used "internally" in the implementation then just leave it in the .tcc (and not in the .hpp), potentially in the internal namespace (to hide it from other code). See also discussion: [BASE] Plonk #49 (comment)

  • Make sure that all functions do not rely on the caller for allocating the correct sizes of the return parameters. Make the latter to be allocated inside the functions that compute them. See also [BASE] Plonk #49 (comment)

@vesselinux
Copy link
Collaborator Author

vesselinux commented Jul 22, 2022

Just to confirm regarding bullet 1 above: in a previous discussion we weren't of a strong opinion whether this should be implemented now or later or if at all. Should I proceed with implementing it now, or shall we leave it as an optional TODO for later?

@vesselinux
Copy link
Collaborator Author

Added two fixes regarding bullet 7. Did not find other cases.

To the best of my abilities checked that the code complies to the rule in bullet 4. Did not find any violations, but may be worth discussing.

vesselinux pushed a commit that referenced this issue Jul 22, 2022
…lector_polynomials to allocate the size of their return values inside of the function i.e. not to rely on the caller to pass inputs with correct size. addressing issue #58, bullet 7
vesselinux pushed a commit that referenced this issue Jul 29, 2022
…lector_polynomials to allocate the size of their return values inside of the function i.e. not to rely on the caller to pass inputs with correct size. addressing issue #58, bullet 7
vesselinux pushed a commit that referenced this issue Jul 29, 2022
…lector_polynomials to allocate the size of their return values inside of the function i.e. not to rely on the caller to pass inputs with correct size. addressing issue #58, bullet 7
vesselinux pushed a commit that referenced this issue Aug 17, 2022
…lector_polynomials to allocate the size of their return values inside of the function i.e. not to rely on the caller to pass inputs with correct size. addressing issue #58, bullet 7
vesselinux pushed a commit that referenced this issue Oct 13, 2022
…lector_polynomials to allocate the size of their return values inside of the function i.e. not to rely on the caller to pass inputs with correct size. addressing issue #58, bullet 7
dtebbs pushed a commit that referenced this issue Oct 26, 2022
…lector_polynomials to allocate the size of their return values inside of the function i.e. not to rely on the caller to pass inputs with correct size. addressing issue #58, bullet 7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant