The MPC-ZKP Architecture
Network Architecture
Fundamentally, Renegade simply consists of a p2p gossip network of many independent relayers that constantly handshake and perform MPCs with each other as new orders enter the system. Relayers never custody assets, and are merely given view access to the wallet in order to compute pairwise MPCs.
In the above diagram, there are three independent relay clusters: The Public Gateway, a Private Cluster 1, and a Private Cluster 2. The Public Gateway is a large publicly-accessible cluster for those who don't want to run their own nodes, but is a relay cluster just like the rest (i.e., it has no special permissions).
When a new order is entered into a wallet managed by one of the clusters, the cluster will propagate a handshake tuple, which is a tuple of commitments to the order data, alongside a zero-knowledge proof that the order is valid. All other relayers monitor for new handshake tuples, and if a new tuple has been detected, will contact the origination cluster and proceed with an MPC.
The MPC computes matching engine execution. That is, given the two orders (each held privately by different relayers), the two parties will compute a MPC that implements matching engine execution on those two orders. This allows for full anonymity, as no information whatsoever is leaked about the order in advance of the MPC. After the MPC, the parties only learn what tokens were swapped; if there was no match between the orders, then no additional information is leaked.
Collaborative SNARKs
As mentioned in What is MPC, multi-party computation protocols themselves have no guarantees about the validity of input data. To solve this, we re-compute the commitments to order data inside of the MPC. If the re-computed commitments disagree with the publicly-known commitments from the handshake tuple, then the output matches list is zeroed out, which functions to prevent adversarial manipulation with fake orders.
In addition to the input consistency problem, a naive application of MPC would lead to problems around atomic settlement. In particular, we must ensure that the MPC output cannot be revealed without it being possible for either party to record the match on-chain. If either party could learn the MPC output and hangup the connection before actually swapping tokens, then the protocol would leak order information.
To solve this atomic settlement problem, we use the collaborative SNARK framework from Ozdemir and Boneh. By wrapping zero-knowledge proof generation inside of a MPC algorithm, collaborative SNARKs allow for the relayers to collaboratively prove a particular NP statement, VALID MATCH MPC. This statement essentially claims that given the publicly-known commitments to order information and a public commitment to a matches tuple, both traders do indeed know valid input orders.
Once this collaborative proof of VALID MATCH MPC has been computed, either party can submit it to the smart contract, thereby actually swapping the tokens. Instead of just running matching engine execution directly, collaborative proving gives both parties assurance that matching (i.e., determining what tokens are swapped) is atomic with settlement (i.e., actually swapping the tokens).
So, by realizing this MPC-ZKP framework via collaborative SNARKs, we have created a DEX that is both completely atomic (i.e., neither party may back out after the MPC has been performed) and completely private, both pre-trade and post-trade.
For more details on the precise contents of the handshake tuple, and for more details about the various NP statements that are proven by each node, see the full Whitepaper.
Last updated