Baseline Rollup
Private zero-knowledge proofs batching
Last updated
Private zero-knowledge proofs batching
Last updated
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.
Private messages containing data required to compute the L2 rollup state are delivered to each participant's published NATS endpoint; these out-of-band messages contain the private inputs required by each participant to calculate and verify state transitions.
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.¹
¹ This design is still pending further technical due diligence.
Each participant in a workgroup uses the API to generate individual and composite proofs (i.e., using MNT4 or BLS2-377 and BW761 or MNT6, respectively), perform proof verification and signing (i.e., using Ed25519 or 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).
² This proof represents a private input to the BaselineRollup circuit which shields the exit commitments and nullifiers, effectively anchoring the rollup state, as-agreed off-chain at certain inflection points throughout the lifecycle of a workgroup and its individual workflows.
In the case of a business process, for example, the exit proof could indicate that specific terms have been satisfied and payment can be issued or an asset could be tokenized.
