Description
See: #287 (and #287 (comment)) for context.
For now and to simply proof verification on-chain (especially in the context of Zecale which uses BW6-761), negating proof.b before passing the proof on-chain was proposed (see links above for context). As discussed, this required to change the API of the prover_server which is a bit counter-intuitive to change this API to "solve for" something that happens later down the line on chain.
Alternatively, some elements of the VK can be negated. This alternative is appealing because it is a low hanging fruit, and because the VK is only processed once when fetched from the prover_server (resp. aggregator_server in Zecale) and passed to the constructor of the protocol contract.
However, modifying the cpp API like this means that "application registration" in Zecale will need to be done with specially crafted VKs which will need to have some negated elements. That's not a big deal if libzeth is used all the way through, but one of the nice things about using gRPC/Protobuf is to allow software components written in different languages to interact together. This means that anyone willing to register an application to the Zecale aggregator will need to be extra careful with the API and with how the VK to deposit needs to be encoded.
That's fine for now, all of this can be refined going forward. Hence this ticket.
I think it would make sense to add an endpoint to the prover_server API (e.g. FetchConfig) in order to allow the client to fetch some configuration from the server. This would work as follows:
- Start
prover_server(necessary to generate proofs) - On first invocation of the client
zeth:- If config is not initialized, then: fetch server config by calling
FetchConfig. Initialize the client config with the server response, and cache the config (e.g. write in file) for persistence and later use. - Else (i.e. if the config file exists), behave as usual (i.e.
FetchConfigis NOT called)
- If config is not initialized, then: fetch server config by calling
Doing so would allow to fetch, for instance, the pairing group name (e.g. ALT_BN128, BLS12_377 etc - see: CMakeLists.txt of cpp code) and would allow the client to select the right local parameters to use (e.g. the characteristics of scalar/base field for the right groups) which ultimately enables to do some tighter type checks on the received pieces of data (i.e. proofs) as well as carry out operations on the received elements (e.g. field inversions etc). Doing so would allow to keep some changes (like negating elements for contract implementation simplicity/optimization) to the right scope (we ideally don't want to propagate such modifs to cpp backend code) etc.
Furthermore, that would lessen some of the logistic troubles related to configuration duplication across Python code and cpp code.