Circuit builder initial ideas impl #303
Conversation
We need a way to treat the circuits on a generic way which allows us to serialize the preprocessed circuits as well as operate with them as gadgets to fill composers. This is a first a approach with some ideas on how to do it.
CPerezz
added
API-design
area:cryptography
| Self: Sized + Default, | ||
| { | ||
| /// Gadget implementation used to fill the composer. | ||
| fn gadget( |
There was a problem hiding this comment.
I see the gadgets as components of the circuit, and the circuit a composition of gadgets combined into a specific logic.
Seems more logical to me to name this function as circuit or implementation
There was a problem hiding this comment.
I'm not sure. A gadget for me is the same as a circuit, the only difference is that is not meant to be used as a circuit.
|
|
||
| /// Circuit representation for a gadget with all of the tools that it | ||
| /// should implement. | ||
| pub trait Circuit<'a> |
There was a problem hiding this comment.
There should be a method size or capacity defined as Fn() -> usize that will return the capacity of the circuit.
| ) -> Result<(Vec<PublicInput>, usize), Error>; | ||
| /// Compiles the circuit by using a function that returns a `Result` | ||
| /// with the `ProverKey`, `VerifierKey` and the circuit size. | ||
| fn compile( |
There was a problem hiding this comment.
The compilation should have a standard implementation that will validate important things such as the size being a power of 2.
This implementation will rarely differ between different circuits, that's why it should be standard
There was a problem hiding this comment.
The size doesn't have t obe a pow of two. The padded one will be. but the padding is done in the preprocessing and proving stages. So that's not a problem for now.
src/circuit_builder.rs
Outdated
| pub_params: &PublicParameters, | ||
| prover_key: &ProverKey, | ||
| inputs: CircuitInputs, | ||
| transcript_initialisation: Option<&'static [u8]>, |
There was a problem hiding this comment.
The transcript is mandatory for Plonk. If we leave an Option there, there will be the impression it is not mandatory when internally we set a default.
There was a problem hiding this comment.
kk I'll change that
src/circuit_builder.rs
Outdated
| pub_params: &PublicParameters, | ||
| verifier_key: &VerifierKey, | ||
| inputs: CircuitInputs, | ||
| transcript_initialisation: Option<&'static [u8]>, |
src/circuit_builder.rs
Outdated
| fn gadget( | ||
| composer: &mut StandardComposer, | ||
| inputs: CircuitInputs, | ||
| ) -> Result<(Vec<PublicInput>, usize), Error>; |
There was a problem hiding this comment.
I think we should return only the [PublicInput] since the circuit size can be trivially obtained by the consumer via the mutated composer.
This way we simplify the documentation and the signature
There was a problem hiding this comment.
The idea is that you, as a user never interact with the composer at all. So therefore we need to return this.
|
|
||
| /// Public Input | ||
| #[derive(Debug, Copy, Clone)] | ||
| pub enum PublicInput { |
There was a problem hiding this comment.
We should have mechanisms to serialize/deserialize a combination of PublicInput so these can be trivially broadcasted
There was a problem hiding this comment.
If they are public there should be no need to broadcast them no?
There was a problem hiding this comment.
They must always be stored on the chain or sent via the network with the proof.
There was a problem hiding this comment.
Ye but they aren't sent like that. You should just send the values. not the positions that they occupy inside the PI vector.
This is the initial idea on how to treat generically the circuits build using PLONK in order to be able to do the most common operations with them in foreign libraries in a structured and efficient way.