Implement user-facing API for recursive proving of IVC

[str4d]

The user-facing layer is typed on a single application curve, and hides all of the underlying scaffolding (#247). In particular, the end user doesn't need to care about the existence of the other curve in the cycle, or any of the recursive-proof-checking components (both the other-curve circuit, and the component inserted into their application circuit).

[str4d]

@ebfull and I paired on figuring out the DAG. There are two main components to the user-facing API:

• Circuits.
  • Forced to use a certain field.
  • Given opportunity to configure and synthesize as now.
  • Circuits need some way to expose public inputs. This differs from now (they need to go through PCD), so need some kind of payload structure.
  • They need a way to consume the public inputs of previous proofs (but privately).
  • They need to know "am I the base case?" (indicating whether the previous proofs are valid at all).
    • Perhaps this will also require circuits to specify what the "default public input payload" should be in this base case? (In case it helps the application circuit impl.)
• The tree description of the circuits and how they relate to each other.
  • E.g. "these circuits are leaves, and we compose two together".

[nikkolasg]

Forced to use a certain field.

I can think of some situations where you would like to have constraints on one field acting as the "scalar field", for operations with scalars and constraints on the other field acting as the base field for operations with points on the subgroup of the curve which has the order of the former field, to do points operations efficiently. In that case, it seems having the ability to design constraints in both "sides" is actually useful. Do you think the API you are designing will allow for that ?

[str4d]

The high-level API being designed for this issue won't allow for that use case, because getting that cross-circuit interaction right is tricky and requires care, and is and not something we want every user to need to deal with. But you should be able to use the underlying scaffolding from #247 for this, since the recursive circuit itself will be doing precisely this kind of work. I suspect once we've built both the underlying scaffolding and the other-field-oblivious API, we'll be in a better position to figure out ways to make it easier to write user circuits that leverage the cycle (and will probably end up building that API as part of writing the recursion circuit itself). In any case, that API is out of scope for this issue; I've opened #494 for discussing it further.