Introduction
Many so-called ‘ZK-Rollups’ are not ‘Zero-Knowledge’ e.g. zkSync, StarkNet, Polygon zkEVM. In fact, the transaction data is visible on-chain. A more accurate term is ‘Validity Rollups’.
Transaction execution occurs at L2, and transactions are finalized at L1 (leveraging security and decentralization of L1).
A proof is generated that attests to the validity of these transactions and the change of state. The rollup’s smart contract at L1 checks this proof, and if it is correct, the state is considered final.
There are 2 instances of ‘blocks’
- At L2 (on validity rollups these include the individual transaction details) and
- L1 rollup block (which verifies the validity of transactions computed at L2).
Validity Rollup Examples
EVM Compatible+ include:
Non-EVM compatible include:
Nansen published a report covering the different ZK-Rollup models in July which can be read here.
zkSync 2.0
Blocks on zkSync at the L2 and L1 Level
L2: Transactions are processed immediately by the operator (zkSync) and added to blocks. This will be decentralized in the future which will increase block production time to ~several seconds.
Operator: carries out rollup functions e.g. producing blocks, packaging txs, conducting calculations and submitting data to L1 for verification.
L1 - sets of blocks are submitted to L1 (blocks are batched to lower tx fees). These contain all their transactions in chronological order. Time taken for batches depends on L2 activity. More activity = faster batch times.
It appears that there is no trace API for zkSync at present. However, this is expected to be released in the future.
zkSync High-Level Operation
- User creates a tx.
- Operator creates rollup operation and adds it to the block.
- Once block is complete, it is sent to the L1 zkSync smart contract as a block commitment. The smart contract checks the logic of the rollup operations.
- The block’s validity proof is sent to the zkSync smart contract for verification. If successful, the new state is considered final.
zkSync’s block explorer shows for each block and transaction:
- Tx hash - identifier of the transaction
- Commit tx hash - hash of L1 tx in which the transaction was committed
- Execute tx hash - hash of L1 tx in which the transaction was executed
- Prove tx hash - hash of L1 tx in which the transaction was proven
Block Example
Transaction Example
Note the current lack of ‘Internal Txns’ or traces (which are expected to be included in the near future).
For further reading, check out Nansen's report on zkSync.
StarkNet
StarkNet is a general-purpose validity rollup. It is not EVM compatible, and the StarkNet OS uses the programming language Cairo.
Block Example
Transaction Example
The transaction data is quite comprehensive (click the link to see all data). Note Starknet shows internal transactions (traces) on transactions, whereas zkSync is not yet displaying this.
For further reading check out Nansen's Starkware report and StarkNet's docs.
Aztec
Aztec offers transaction-level privacy through zero-knowledge technology. This is partially enabled by Aztec’s use of a UTXO account model (which Bitcoin also uses). Most chains, such as Ethereum, use an account-based model. It is considered more difficult to encrypt transactions in an account-based model than UTXO (which is essentially a ledger of ongoing transactions).
Privacy is not absolute.
- When depositing into Aztec from L1, address is visible.
- When withdrawing from Aztec, L1 receiving address is visible.
This means that the tx amount is visible when depositing and withdrawing, which could enable some way for identifying users in some cases.
UX Issues
- Privacy is not guaranteed.
- Transaction limits (to discourage illicit activity) of 5 ETH / 10,000 DAI
- Transactions are batched in order to reduce costs for users. However, this results in latency making it wholly unsuited for trading. This problem lessens with more users, but user fluctuations will mean unreliable UX.
Aztec has a DSL called Noir which is Rust based and designed to make it easier to build ZK-apps. However, the adoption of this language remains to be seen.
Block Example (L2)
Block at L1
Further reading: Blockcrunch article on Aztec for a non-technical deep dive. For a more technical understanding, check out their docs.
L3s
L3 is still a concept. However, zkSync has stated they will have a PoC this year. Privacy has been strongly stated as one of the key use cases. Many L3s will likely be application specific.
L3s should be trackable if the operator doesn’t privatise data. For example, with a validium - data availability is off-chain. However, if the operator maintains an explorer showing all the transactions then this will be trackable. However, privacy focused validiums and L3 applications will likely be untrackable.
Some of these L3s are expected to be both extremely scalable and private. It appears unlikely that on-chain tracking will be possible for these.
Here is Starknet’s depiction (as included in Vitalik’s L3 blogpost).
Conclusion
- Starknet and zkSync are both scalable and transparent - and preliminary analysis shows that they should be trackable.
- Privacy-focused solutions with advancing ZK cryptography may be impossible to track. Highly scalable and private L3 instances may pose a threat. However, total privacy is something that governments are eager to inhibit. Also, transparency is a key value proposition to blockchains with many benefits. It is unlikely to be completely replaced with privacy.
- We can still be considered ‘early’ in crypto. Many people in crypto today value privacy more than the general population. Are we overestimating how important privacy will be?
