Auxiliary opening data

[autquis]

I added the auxiliary data of the prover for opening. The name is CommitmentState, since it is a state/data related to each commitment, not to the committer. We can change the name though.

closes: #128

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (master)
• Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer

[weikengchen]

@Pratyush what is your preference about the name? I would try to avoid "state" since it is too generic.

[autquis]

Can you also have a look at #128, please? @Pratyush @weikengchen
It will answer the question of whether we can merge this auxiliary data into Randomness or not.

[Pratyush]

I think CommitmentState is fine; being generic/vague is a feature here because the State differs across different schemes, each of which might stash different kinds of data there.

[mmagician]

Ah so in the light of the discussion in #128, this is just a rename for the currently implemented schemes. For the other, currently PR'ed schemes, we will see a noticeable improvement in the opening time for the prover. LGTM

Edit: seems like we need to do a bit more than described here.

[autquis]

A PR to crypto-primitive will fix the CI issue. In the meantime, the PR is ready for review.

[Pratyush]

This looks good! A future change that we can do is that open currently takes in the commitment, and we can remove that, as without loss of generality the state can contain the commitment.

[mmagician]

@Pratyush currently commit outputs both the commitment and the state - if we bundle them into one struct, then there's a larger danger of misusing the API and sharing the entire state with the verifier (e.g. if serialized?).
I agree that this would make the open signature cleaner, but let's keep the above in mind.

[mmagician]

We could remove the CanonicalSerialize derives from the state, for example. I'm not sure if what I'm saying makes sense or we should just clean up the signature as much as possible.

Anyway, this PR is ready @Pratyush modulo the docstring for state above

[Pratyush]

Ah no, I just meant the following change:

//before:
fn commit() -> (Commitment, Randomness);

fn open(cm, ..., state) -> Proof;

// after:
fn commit() -> (Commitment, State);

fn open(state, ...) -> Proof; // Notice that we don't take cm as input any more.

That is, commit still produces Commitment and State, but now open doesn't take Commitment as input because wlog we can additionally store cm inside state if needed.