Remove VerifierState from state manager #1066
Conversation
andrewmilson
force-pushed
the
11-03-remove_verifierstate_from_state_manager
branch
from
b3514d8 to
6029e4b
Compare
andrewmilson
force-pushed
the
11-03-remove_proofs_and_commitments_from_state_manager
branch
from
4e0aa10 to
2bd93f2
Compare
andrewmilson
force-pushed
the
11-03-remove_verifierstate_from_state_manager
branch
from
6029e4b to
41a33d1
Compare
andrewmilson
force-pushed
the
11-03-remove_verifierstate_from_state_manager
branch
from
41a33d1 to
ec73528
Compare
andrewmilson
force-pushed
the
11-03-remove_proofs_and_commitments_from_state_manager
branch
from
2bd93f2 to
4311823
Compare
andrewmilson
changed the base branch from
11-03-remove_proofs_and_commitments_from_state_manager
to
graphite-base/1066
andrewmilson
force-pushed
the
graphite-base/1066
branch
from
4311823 to
025c012
Compare
andrewmilson
force-pushed
the
11-03-remove_verifierstate_from_state_manager
branch
from
ec73528 to
23e20c3
Compare
andrewmilson
force-pushed
the
11-03-remove_verifierstate_from_state_manager
branch
2 times, most recently
from
00d50a2 to
2caff3b
Compare
0xAndoroid
left a comment
0xAndoroid
left a comment
There was a problem hiding this comment.
Everything else looks good, except for the jolt_dag refcator.
There was a problem hiding this comment.
I strongly prefer current way of dag construction. I don't think that this refactor to the dag adds any clarity, while making the code a lot more verbose. I would like to keep the stageX_instances initialization.
There was a problem hiding this comment.
My 2 cents here is that I like having the different stage methods for organization
If we end up going with my proposed JoltProverBackend trait, we'll end up having the stages explicit at the whole-DAG level, rather than implementing SumcheckStagesProver for each component. So we'd end up somewhere in-between the current state and the changes in this PR.
@andrewmilson are you planning to reintroduce the stage methods with the JoltProverBackend trait, or are you proposing that we toss them out entirely?
There was a problem hiding this comment.
Plan is still to introduce stage methods on JoltProverBackend trait. I just want to slightly modify them so we don't pass state_manager and instead store state on the prover struct (I think this will make different backend state management much easier for us). The goal of this stack is to decouple everything in our codebase from state manager (which I think is good in itself for various reasons - testing for instance) which will help make this change and the prover/verifier split possible. Does that sound ok?
There was a problem hiding this comment.
ok, that sounds good to me
There was a problem hiding this comment.
I moved each stage to its own function.
Let me know what you guys think.
There was a problem hiding this comment.
looks good to me, let's add the symmetric prover functions for each stage in #1071
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
andrewmilson
force-pushed
the
11-03-remove_verifierstate_from_state_manager
branch
from
5c2aa34 to
e1d453f
Compare
andrewmilson
force-pushed
the
11-03-remove_verifierstate_from_state_manager
branch
2 times, most recently
from
809952e to
714a108
Compare
andrewmilson
force-pushed
the
11-03-remove_verifierstate_from_state_manager
branch
from
714a108 to
a66654b
Compare
No description provided.