This depends on the type of transaction; see Table.
As stated earlier, in a zkRollup, by applying verifiable computing on \( \text{STF} \), it is shown that L2 indeed computed \( \text{newState}_2 = \text{STF}(\text{oldState}_2, \text{txBatch}) \) correctly from oldState₂ and txBatch. However, the fact that the Sequencer has access to a zkProver means that the latter can issue verifiable statements, or attestations, about the state of the rollup data in the form of zkProofs. Examples include:
Now observe that these statements are all relative to L2 and the rollup. But here comes the real twist!
But note that Mina started before zkVMs existed, so specific SNARKs had to be developed to make this idea work. With zkVMs, the development of this mechanism is much faster.
Note that these zkProofs are like certified checks. By sending them to other chains, cross-chain transfers become possible (see below).
\( A_1 - B_1 \)
Suppose we want to transfer assets from A Layer 1 to B Layer 1; for concreteness, let's use Avalanche and ETH as an example. Since we have two different main chains, an atomic transaction is out of the question, so we resort to first-destroy-then-create.
But how can one convince the ETH blockchain that some asset destruction transaction TX on Avalanche has taken place? Neither main chain has any reason to trust information coming from outside. However, both will accept a full zkProof that some transaction was finalized on the other chain.
There are two strategies for this:
1 -- Backward zkProof-of-Transaction: Suppose a smart contract on Ethereum has the Avalanche genesis block hard-coded in it. Then one can do the following: the transaction data (\( TX \)) is sent to a zkProver who, using recursive proof techniques à la Mina, produces a zkProof. The \( TX \) and the zkProof are sent to the smart contract, which verifies and accepts them. This zkProof functions like a certified check, proving that some asset has been destroyed, thus authorizing the creation of an equivalent value on the other chain. In this way, we implement cross-chain asset transfer from Avalanche to Ethereum, essentially what a bridge does, but without the need for an intermediate entity.
2 -- Forward zkProof-of-Transaction: Say \( TX \) is included in block \( M \). We wait \( N \) blocks, where \( N \) is sufficiently large to guarantee that no rollback has occurred. The hash of block \( M + N \) is included in the proof-of-transaction. The zkProver, who understands the logic of the Avalanche blockchain, produces a validity proof showing that:
The reason this constitutes a zkProof that TX has been settled is simple: falsifying such a proof would be equivalent to developing an alternative fork of Bitcoin, which, by assumption, is impossible.
So, like the above example, this zkProof functions as a certified check, proving that an asset has been destroyed, allowing it to be redeemed elsewhere—i.e., cross-chain asset transfer.
Observe that the use of zkProofs here is unrelated to the rollup; it only takes advantage of the existence of a zkVM. Also, the VM on the receiving chain must be powerful enough to support a zkProver. In the case of Bitcoin, this is not true, which requires very specific solutions.
This article was written by Jeroen van de Graaf, Senior Cryptographer at ZKM. Part Three of the series will explore the applications of the Entangled Rollup in more detail.
This depends on the type of transaction; see Table.
As stated earlier, in a zkRollup, by applying verifiable computing on \( \text{STF} \), it is shown that L2 indeed computed \( \text{newState}_2 = \text{STF}(\text{oldState}_2, \text{txBatch}) \) correctly from oldState₂ and txBatch. However, the fact that the Sequencer has access to a zkProver means that the latter can issue verifiable statements, or attestations, about the state of the rollup data in the form of zkProofs. Examples include:
Now observe that these statements are all relative to L2 and the rollup. But here comes the real twist!
But note that Mina started before zkVMs existed, so specific SNARKs had to be developed to make this idea work. With zkVMs, the development of this mechanism is much faster.
Note that these zkProofs are like certified checks. By sending them to other chains, cross-chain transfers become possible (see below).
\( A_1 - B_1 \)
Suppose we want to transfer assets from A Layer 1 to B Layer 1; for concreteness, let's use Avalanche and ETH as an example. Since we have two different main chains, an atomic transaction is out of the question, so we resort to first-destroy-then-create.
But how can one convince the ETH blockchain that some asset destruction transaction TX on Avalanche has taken place? Neither main chain has any reason to trust information coming from outside. However, both will accept a full zkProof that some transaction was finalized on the other chain.
There are two strategies for this:
1 -- Backward zkProof-of-Transaction: Suppose a smart contract on Ethereum has the Avalanche genesis block hard-coded in it. Then one can do the following: the transaction data (\( TX \)) is sent to a zkProver who, using recursive proof techniques à la Mina, produces a zkProof. The \( TX \) and the zkProof are sent to the smart contract, which verifies and accepts them. This zkProof functions like a certified check, proving that some asset has been destroyed, thus authorizing the creation of an equivalent value on the other chain. In this way, we implement cross-chain asset transfer from Avalanche to Ethereum, essentially what a bridge does, but without the need for an intermediate entity.
2 -- Forward zkProof-of-Transaction: Say \( TX \) is included in block \( M \). We wait \( N \) blocks, where \( N \) is sufficiently large to guarantee that no rollback has occurred. The hash of block \( M + N \) is included in the proof-of-transaction. The zkProver, who understands the logic of the Avalanche blockchain, produces a validity proof showing that:
The reason this constitutes a zkProof that TX has been settled is simple: falsifying such a proof would be equivalent to developing an alternative fork of Bitcoin, which, by assumption, is impossible.
So, like the above example, this zkProof functions as a certified check, proving that an asset has been destroyed, allowing it to be redeemed elsewhere—i.e., cross-chain asset transfer.
Observe that the use of zkProofs here is unrelated to the rollup; it only takes advantage of the existence of a zkVM. Also, the VM on the receiving chain must be powerful enough to support a zkProver. In the case of Bitcoin, this is not true, which requires very specific solutions.
This article was written by Jeroen van de Graaf, Senior Cryptographer at ZKM. Part Three of the series will explore the applications of the Entangled Rollup in more detail.
