Private zero-knowledge proofs batching
The application of Provide Privacy for Layer 2 consensus alongside the Baseline rollup circuit for Layer 1 exit is being deployed in production within large commercial supply chain solutions. Our approach represents one way this API can be used to build advanced privacy into enterprise ecosystems. The architecture enables the latest cryptographic research to be applied on L2; upon exit, the fully-executed rollup commitment is verified, shielded and anchored under zero-knowledge on the public blockchain. This is accomplished without requiring specific elliptic curve precompiles to be included in, for example, the EVM, to enable productive use.
This privacy microservice is a fundamental building block for achieving L2 consensus-- including L2 rollups-- using arbitrary elliptic curves without the use of a sidechain. Bit-for-bit consensus can be achieved under zero-knowledge by the parties to a workgroup by way of commitments and nullifiers. In this sense, proving membership in the workgroup involves computing the new root and leaf values of a merkle tree by "replaying" the immutable stream of each state transition (i.e., each commitment). In the corollary sense, the update or deletion of a previous commitment is affected by re-computing the roots and leaves to recommit and nullify previous state. A nullifier is typically used in the context of "spending" commitments; to nullify state is to reveal or exit.
A merkle tree is used to track commitments which modify L2 state. A second data structure and methodology is needed to track the nullification of a previous state such that it can be eligible to exit. The embodiment of this second data structure to track exits could be (i) a second nullifier merkle tree maintained by each workgroup participant for off-chain proof verification (i.e., whereby events used to track commitments are essentially co-located in the second merkle tree and knowledge of the leaf index of a commitment can be used to determine if such commitment has been spent by reading the same index in the nullifier tree) or (ii) a reverse hash tree, wherein workgroup identifiers are used to calculate the hash of parent nodes.¹
Each participant in a workgroup uses the API to generate individual and composite proofs (i.e., using
MNT6, respectively), perform proof verification and signing (i.e., using
babyJubJub) and finally generate an exit proof² based on the signature and rollup proof (i.e., using
Groth16, which is supported today within the EVM).