Closed duguorong009 closed 6 months ago
From this PR, my only worry is breaking the API for
create_proof
; I wrote an idea that could resolve that.
@ed255 Can you share your idea here? (I cannot see your writing anywhere. š )
From my end, I believe we should break the API for create_proof
since it needs the compress_selectors
info.
As long as we go for option of removing compress_selectors
from VerifyingKey
, we should manually feed compress_selectors
to the create_proof
func.
This is kinda side effect.
I focused on keygen part when starting this draft PR.
But, as we can see, it is closely related to create_proof
func, too.
From this PR, my only worry is breaking the API for
create_proof
; I wrote an idea that could resolve that.@ed255 Can you share your idea here? (I cannot see your writing anywhere. š )
Oh how unfortunate, I had written it as a review comment, but for some reason it was not submitted.
From my end, I believe we should break the API for
create_proof
since it needs thecompress_selectors
info. As long as we go for option of removingcompress_selectors
fromVerifyingKey
, we should manually feedcompress_selectors
to thecreate_proof
func.This is kinda side effect. I focused on keygen part when starting this draft PR. But, as we can see, it is closely related to
create_proof
func, too.
My idea was to break the create_proof
method into two versions: create_proof
and create_proof_custom
.
Then we'd have the following:
compress_selectors = true
: keygen_pk
, keygen_vk
, create_proof
compress_selectors
parameter: keygen_pk_custom
, keygen_vk_custom
, create_proof_custom
.This way we don't break the API, and the resulting API looks consistent.
My idea was to break the
create_proof
method into two versions:create_proof
andcreate_proof_custom
. Then we'd have the following:
- methods that assume
compress_selectors = true
:keygen_pk
,keygen_vk
,create_proof
- methods that receive
compress_selectors
parameter:keygen_pk_custom
,keygen_vk_custom
,create_proof_custom
.This way we don't break the API, and the resulting API looks consistent.
Wow, thanks for the idea! @ed255 I believe it is best idea for both compatibility and new API.
Description
Remove the
compress_selectors
field fromVerifyingKey
Related issues
-
Changes
keygen_pk_custom
utilkeygen_pk
,keygen_pk_custom
,keygen_vk
&keygen_vk_custom
addcompress_selectors
field tohalo2_proofs::plonk::create_proof
funccreate_proof_custom_with_engine
func for both compatibility & new APIContext
While working in PR #304, I found that
compress_selectors
field is essentially not needed inVerifyingKey
. It was there because @ed255 didn't find appropriate solution while doing frontend-backend split work. But, after frontend-backend split, it is clear thatcompress_selectors
is for frontend(compile circuit), andVerifyingKey
is only for backend stuff. Regarding this issue, I had a bit of discussion with @ed255 He gave some good ideas:compress_selectors
fromVerifyingKey
compress_selectors
param to legacykeygen_pk
(safe, but break API)keygen_pk_custom
with assumption ofkeygen_pk
havingcompress_selectors: true
(compatible, but user could misuse)He recommended to create draft PR for discussing the possible solutions with other members. This PR serves the purpose of discussing the better solutions regarding the
compress_selectors
inVerifyingKey