Problem to Solve

The most important objective is to enable synchronous composability of operations across multiple zones. In addition to this, we want to model the system in a general way to support privacy-preserving payments and general Zk verification.

Protocol Overview

For this purpose, we will combine 3 components: partial transactions, matching and proof aggregation.

In this protocol we assume the following:

Zones define their own VM (ie they are sovereign).
Zones don't have knowledge of other Zones by default. There exists the case where Zones can read each other's VM, but the general synchronous composability protocol is not designed for that use case.
Zones run a Zk bridge for state validation. While it is possible to run fully-sovereign sidechains on Nomos, these techniques don't apply to those. This Zk bridge ensures that the deposits and withdrawals balance out, but the internal rules of the Zone Txs are arbitrary and allowed as long as the bridge respects the rules of any other CL account. In other words, a bridge is a CL account.
Zones may use a separate internal Zk proving scheme, but bridges with the CL are defined in CL's Zk scheme and verified by the CL. In this case, the proof of state transition needs to be proven itself in the CL Zk scheme.

In this document, we will start with a direct “naive” implementation, and then we will proceed to simplify it. Then we will generalize it.

A Synchronous Transfer Between Zones

Transfers between zones are comprised of two parts: a withdrawal and a deposit. The objective is to do them atomically. However, note that these operations are not necessarily atomic either, so we will start by making them atomic, and then composing them together.

Note that commitments and nullifiers are just a privacy-preserving encoding of UTXO, so we will refer to them in this manner for simplicity.

Withdrawing

This is the base protocol of a withdrawal:

$z_A$ has minted asset $X_A$ to Bob. In other words, Bob owns certain amount of $X_A$. Bob creates a transfer transaction to the bridge contract (not a partial transaction).
This transaction is sent to the bridge $B_A$, which is a native program (in $z_A$'s VM) set up by $z_A$ to bridge in/out of Nomos CL.
- This is the first phase of the withdrawal.
- The ZK predicate or contract must ensure the following asset $X_A$ is either burned or locked.
After the tx is consumed at the Zone-side of the bridge, the CL-side of the bridge $B_{CL}$ reads the operation on the other side.
- This is the second phase of the withdrawal.
- This part of the bridge is implemented in Taiga (or whatever VM we choose for the CL).
- A message can be left in a mailbox for simplicity, like bridges such as Arbitrum's does, but the specifics of this is an implementation detail.
- The ZK predicate on this side of the bridge ensures that the corresponding asset $X_{CL}$ is minted. Note that the asset $X_A ≠ X_{CL}$. The only thing that binds them is this contract, and optionally a contract in the CL that defines the base asset in the CL, which is what ensures the correspondence (otherwise arbitrary, as the tokens don't necessarily have the same ID or name). In other words, the equivalence is a social agreement, encoded as a contract (Zk program in our case).
- To further clarify this, see how bridged tokens are oftentimes called similarly, but not the same: LINK/anyLINK (multichain bridge), eETH/weETH (Arbitrum bridge), USD/axlUSD (Axelar bridge).