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

Key verification #39

Merged
merged 13 commits into from
Sep 30, 2020
Merged

Key verification #39

merged 13 commits into from
Sep 30, 2020

Conversation

dtebbs
Copy link
Contributor

@dtebbs dtebbs commented Aug 10, 2020

  • Gadget to check hash of nested vk, parameterized by hash gadget
  • Refactor aggragtor gadget so that the caller controls variable allocation
  • Move control of variable allocation and use of key hashing gadget into circuit wrapper class

@dtebbs dtebbs force-pushed the key-verification branch 2 times, most recently from a79220e to 58525f1 Compare August 24, 2020 13:35
@dtebbs dtebbs changed the title WIP: Key verification WIP: Key verification (depends on #40) Sep 1, 2020
@dtebbs dtebbs changed the base branch from zecale-client to update-zeth September 1, 2020 15:24
@dtebbs dtebbs force-pushed the key-verification branch 4 times, most recently from 66d4bdf to a8dff09 Compare September 2, 2020 15:17
@dtebbs dtebbs changed the title WIP: Key verification (depends on #40) Key verification (depends on #40) Sep 16, 2020
@AntoineRondelet AntoineRondelet changed the base branch from update-zeth to develop September 25, 2020 09:34
libzecale/circuits/aggregator_circuit_wrapper.hpp Outdated Show resolved Hide resolved
libzecale/circuits/aggregator_circuit_wrapper.tcc Outdated Show resolved Hide resolved
libzecale/circuits/null_hash_gadget.hpp Outdated Show resolved Hide resolved
using nppT = other_curve<wppT>;
using wsnarkT = typename wverifierT::snark;
using npp = other_curve<wppT>;
using nsnark = typename nverifierT::snark;

static const size_t batch_size = 2;
static const size_t public_inputs_per_proof = 1;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not add the size of the instance as part of another attribute of the application pool: https://github.com/clearmatics/zecale/blob/develop/libzecale/core/application_pool.hpp?
As such the new attribute app_pool.nb_pub_inputs (or however it is named) can be passed to the aggregator circuit to instantiate it's internal constants. That allows to check that the instance size of the extended proofs push'ed in the application pool equals app_pool.nb_pub_inputs and enables to fail early (before starting the assignment of circuit wires)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch. I've added it to aggregator server for now, since that's where most of these checks and error handling is currently done (I added a bunch in a previoius PR, but didn't add this one).
Eventually it would be great to include the number of inputs in the proof / vk types so that these errors are caught at compile time / when the tx is decoded, but that might be a more fundamental change.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch. I've added it to aggregator server for now, since that's where most of these checks and error handling is currently done (I added a bunch in a previoius PR, but didn't add this one).

That's fine for now to keep this on the server. Nevertheless, that shouldn't be where this value is set in the long run. The "uncompressed" instance size is function of the underlying base application and so checking received instance size outside of the scope of the application doesn't really make sense and affects the "genericity" of the Zecale server. The base app "compressed" instance size (the output of the hash function - see "GGPR's trick" - used on the base app instance) is a Zecale protocol param however, and so that's fine to set this on the aggregator server.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right. Eventually it seems we may be able to support a per-application number of inputs (up to some predetermined max). Note, it would not really be feasible to keep this as a variable yet anyway - we need a generic snarkT::verification_key_get_num_inputs() method first. clearmatics/zeth#291

@dtebbs dtebbs changed the title Key verification (depends on #40) Key verification Sep 28, 2020
@AntoineRondelet
Copy link
Contributor

LGTM

@AntoineRondelet AntoineRondelet merged commit a8ac008 into develop Sep 30, 2020
@AntoineRondelet AntoineRondelet deleted the key-verification branch October 27, 2020 13:38
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