signature trait

[zhenfeizhang]

Description

First task of #52

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 (main)
• 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

[chancharles92]

LGTM

[zhenfeizhang]

So let me summarize the candidate solutions here

• candidate 1: 0a1f220
• candidate 2: db66184

Candidate 1: define our own signature trait where we can configure the message space
Candidate 2: follow Arkwork's signature trait, and define an additional trait where message space is field elements

Pros of candidate 1: more flexible. Cleaner. We do not need a separate trait.
Cons of candidate 1: not compatible with upstream.

For both candidate, a CAP caller will need to import own own trait for the field based hashes. So importing Arkwork's does not reduce complexity here.

Seem like we have converged to the first candidate? @chancharles92 @alxiong

[chancharles92]

Seem like we have converged to the first candidate? @chancharles92 @alxiong

Agree

[zhenfeizhang]

Okay. now this branch implements our own signature trait, and is ready for review.
FYI: code with arkworks signature trait is stashed here: https://github.com/EspressoSystems/jellyfish/tree/arkwork's-signature-api

[chancharles92]

LGTM, do we want to add this into tag-release 0.0.1 or should we add it after the tag-release PR?

[zhenfeizhang]

Perhaps after. There are likely breaking changes after this.