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

Prover and Verifier are **not** type-safe #713

Closed
ureeves opened this issue Oct 24, 2022 · 1 comment
Closed

Prover and Verifier are **not** type-safe #713

ureeves opened this issue Oct 24, 2022 · 1 comment
Labels
team:research type:enhancement Issues concerning code or feature improvement (performance, refactoring, etc)

Comments

@ureeves
Copy link
Member

ureeves commented Oct 24, 2022

Describe what you want implemented
While these structures are type-safe while in memory, the moment they're serialized and subsequently de-serialized, they cease to be so. This means that it is possible, for example, to de-serialize a Verifier<C1> from a payload of Verifier<C2> with C1 != C2.

Describe "Why" this is needed
Type-safety is not a requirement per-se, but since it is one of the design goals it should probably be taken seriously.

Describe alternatives you've considered
A solution for this would be to include information about the circuit type with the serialized Prover and Verifier.

Additional context
In the process of migrating rusk-abi, I came understand that the choosing of the circuit was made more difficult by the newer plonk API, but also realized how serialization can easily be abused.

@ureeves ureeves added type:enhancement Issues concerning code or feature improvement (performance, refactoring, etc) team:research labels Oct 24, 2022
@ureeves ureeves changed the title Prover and Verifier are *not* type-safe Prover and Verifier are **not** type-safe Oct 24, 2022
@marta-belles
Copy link

Not applicable anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team:research type:enhancement Issues concerning code or feature improvement (performance, refactoring, etc)
Projects
None yet
Development

No branches or pull requests

2 participants