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

refactor: Parametrization of lib.rs tests for various EvaluationEngines #70

Merged
merged 1 commit into from
Oct 16, 2023

Conversation

huitseeker
Copy link
Contributor

@huitseeker huitseeker commented Oct 13, 2023

microsoft/171 introduced enhanced genericity in tests to facilitate unit testing across diverse curve cycles. Since then, the lib.rs tests, being designed to verify certain behaviors of the decider SNARK, tend to embed the use of a RelaxedR1CSSnark<G, EE>. They do this under the alias (where the test carefully chooses a specific import path for RelaxedR1CSSnark):

type S1<G> = RelaxedR1CSSnark<G, ipa_pc::EvaluationEgine<G>>

Effectively, this constrains the PCS utilized by that decider to the IPA, even if the only thing the test function needed to be specific about is RelaxedR1CSSnark.

Hence, these generic tests then had to accommodate constraints facilitating the use of the IPA, specifically:

<G::CE as CommitmentEngineTrait<G>>::CommitmentKey: CommitmentKeyExtTrait<G>

This is because the IPA operates exclusively with a "splittable" key, a concept delineated by the CommitmentKeyExtTrait.

However, two core adjustments are required:

  • For the inclusion of different PCSs (for instance, Zeromorph), it's imperative to render EE<G>: EvaluationEngineTrait<G> configurable.
  • Parametrizing the tests based on the EvaluationEngineTrait implementation eliminates boundaries associated with CommitmentKeyExtTrait. Such boundaries matching the EvaluationEngine and CommitmentEngine only materialize when the scheme is instantiated (i.e., during test invocation), a point where they are seamlessly met.

The present PR effects this parametrization, effectively making the lib.rs tests functions variable based on the evaluation engine in use.

[microsoft/171](microsoft/Nova#171) introduced enhanced genericity in tests to facilitate unit testing across diverse curve cycles.  Since then, the lib.rs tests, being designed to verify certain behaviors of the decider SNARK, tend to embed the use of a RelaxedR1CSSnark<G, EE>. They do this under the alias (where the test carefully chooses a specific import path for RelaxedR1CSSnark):

```rust
type S1<G> = RelaxedR1CSSnark<G, ipa_pc::EvaluationEgine<G>>
```
Effectively, this constrains the PCS utilized by that decider to the IPA, even if the only thing the test function needed to be specific about is `RelaxedR1CSSnark`.

Hence, these generic tests then had to accommodate constraints facilitating the use of the IPA, specifically:

```
<G::CE as CommitmentEngineTrait<G>>::CommitmentKey: CommitmentKeyExtTrait<G>
```
This is because the IPA operates exclusively with a "splittable" key, a concept delineated by the CommitmentKeyExtTrait.

However, two core adjustments are required:

- For the inclusion of different PCSs (for instance, Zeromorph), it's imperative to render `EE<G>: EvaluationEngineTrait<G>` configurable.
- Parametrizing the tests based on the `EvaluationEngineTrait` implementation eliminates boundaries associated with `CommitmentKeyExtTrait`. Such boundaries matching the `EvaluationEngine` and `CommitmentEngine` only materialize when the scheme is instantiated (i.e., during test invocation), a pointwhere they are seamlessly met.

The present PR effects this parametrization, effectively making the lib.rs tests functions variable based on the evaluation engine in use.
@huitseeker huitseeker changed the title refactor: Parametrization of lib.rs Tests for Various Evaluation Engines refactor: Parametrization of lib.rs tests for various EvaluationEngines Oct 13, 2023
@huitseeker huitseeker mentioned this pull request Oct 13, 2023
2 tasks
Copy link
Contributor

@mpenciak mpenciak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@huitseeker huitseeker added this pull request to the merge queue Oct 16, 2023
Merged via the queue into dev with commit 852ee44 Oct 16, 2023
@huitseeker huitseeker deleted the ee_in_tests branch October 16, 2023 11:12
mpenciak pushed a commit to mpenciak/arecibo that referenced this pull request Oct 27, 2023
…nes (lurk-lang#70)

[microsoft/171](microsoft/Nova#171) introduced enhanced genericity in tests to facilitate unit testing across diverse curve cycles.  Since then, the lib.rs tests, being designed to verify certain behaviors of the decider SNARK, tend to embed the use of a RelaxedR1CSSnark<G, EE>. They do this under the alias (where the test carefully chooses a specific import path for RelaxedR1CSSnark):

```rust
type S1<G> = RelaxedR1CSSnark<G, ipa_pc::EvaluationEgine<G>>
```
Effectively, this constrains the PCS utilized by that decider to the IPA, even if the only thing the test function needed to be specific about is `RelaxedR1CSSnark`.

Hence, these generic tests then had to accommodate constraints facilitating the use of the IPA, specifically:

```
<G::CE as CommitmentEngineTrait<G>>::CommitmentKey: CommitmentKeyExtTrait<G>
```
This is because the IPA operates exclusively with a "splittable" key, a concept delineated by the CommitmentKeyExtTrait.

However, two core adjustments are required:

- For the inclusion of different PCSs (for instance, Zeromorph), it's imperative to render `EE<G>: EvaluationEngineTrait<G>` configurable.
- Parametrizing the tests based on the `EvaluationEngineTrait` implementation eliminates boundaries associated with `CommitmentKeyExtTrait`. Such boundaries matching the `EvaluationEngine` and `CommitmentEngine` only materialize when the scheme is instantiated (i.e., during test invocation), a pointwhere they are seamlessly met.

The present PR effects this parametrization, effectively making the lib.rs tests functions variable based on the evaluation engine in use.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants