Skip to content

Rollup workflow on Cardano

Overview

The basis for our ZK Rollup is a smart contract (the rollup validator) that holds user funds and validates ZK Rollup Ledger state transitions. Transactions on a ZK Rollup Ledger are posted on Cardano in a compressed batched format.

On-chain rollup architecture

In the currently implemented prototype, the transaction batch to be validated is split into n "raw data chunks". Each data chunk is posted on Cardano as a redeemer of a "data chunk token" minting policy. The policy requires the token name to be equal to the hash of the chunk. To maximize efficiency, every data chunk token is minted in a separate transaction where the data chunk itself takes most of the transaction size, reaching 16KB under the current protocol parameters.

The Rollup state transition transaction references all the data chunk tokens that were created since the last transition. The Rollup validator script commits to the list of the referenced tokens and verifies a ZK proof of a correct transition. The proof is generated by a transaction aggregation server. The chunk data serves as witness in this protocol. The state transition transaction may also contain a fee output and some bridge outputs. The fee output is used to collect fees for the transaction aggregation server, while the bridge outputs is used to bridge assets in and out of the ZK Rollup Ledger.

Below we define the Plutus scripts that are used in the rollup workflow.

Plutus scripts

There are two main scripts associated with the rollup: rollupData and rollup. The first one posts data on-chain while the second one references this data and advances the state of the rollup ledger.

rollupData

It is a minting policy that executes one of two possible checks (depending on the redeemer):

  1. The redeemer passes data as a list of builtin-byte-strings: script ensures that exactly one token is minted, having as token name the hash of said data.
  2. The redeemer passes a "burn" flag: script ensures that all tokens with the rollupData minting policy passed as inputs in the transaction get burned. This allows the recovery of the Ada being locked because of those data tokens.

rollup

It is a spending script that locks outputs at the rollup address. Such outputs can be spent in a number of cases:

  1. The output associated with the rollup state can be spent to update this state.
  2. The output holding some value locked in the rollup can be spent alongside the “state” output.
  3. The outputs holding locked non-ada value can be spent in order to combine that value to a single output.
  4. The outputs holding locked ada value can be spent to adjust the stake delegation of that value.
  5. Finally, any rollup outputs can be spent to move to a new version of the rollup script (it needs further specification).

Advancing the rollup state

Let us describe case 1. in the list above. Each rollup state is identified by the state hash of type F (a field element). The next state is computed as the hash of a 4-tuple consisting of:

  1. The previous state.
  2. The update (list of hashes of "data updates").
  3. A list of bridge outputs (described below).
  4. The validity interval.

Prover computes a ZK proof for the (next) state. This proof, together with the update (list of hashes), is passed as a redeemer to the rollup validator. The (previous) state is stored as datum in the rollup UTxO.

The proof computed by the prover corresponds to a circuit that verifies that all transactions are valid and the new state is correct.

To advance the rollup state, the rollup validator:

  • Must be parameterized by the ledger rules (this enforces the PlonkUp verifier), the currency symbol of the data tokens, the thread value that serves to identify the UTxO holding the state, and the address collecting the fees.
  • Computes the next state from the datum, the update passed as redeemer, the bridge outputs in the transaction, and the rollup fee.
  • Verifies the proof against the state stored in the datum.
  • Checks that the passed update list corresponds to the list of token names of referenced "data tokens". (These data tokens can be stored in one or more reference inputs.)
  • Ensures the presence and persistence of the thread token that identifies the UTxO with the datum (state) being validated on each rollup.
  • Ensures the address and value of the fee output are correct.

The outputs of the rollup transaction are as follows:

  • The first output is the rollup state output. (Continuity of the thread token is checked for this output.)
  • The second output is the fee output.
  • The remaining outputs, except for the very last one, are bridge outputs, which serve the purpose of bridging assets in and out of the ZK Rollup Ledger. These can be sent either to the rollup script, in which case the value is being sent to the rollup ledger, or outside the rollup ledger. Bridge outputs must contain a datum hash. (The validity check of the bridging outputs is currently forwarded to the rollup ledger rules.)
  • The last output corresponds to the change output of the transaction aggregation server. (Note that it does not contain a datum hash.)