Cardano transactions rarely fail because validation is not dependent on a shared global state. This is a key distinction between Cardano’s UTxO model and Ethereum’s account-based model. Cardano’s approach allows for predictable and deterministic transaction validation and script execution. The outcome is known in advance, which is particularly beneficial for the implementation of ZK Rollups. These can be implemented without the need for centralized sequencers. In this article, we will first delve into an explanation of determinism and the reasons why transactions on Ethereum can fail. Then we explain the fundamental principles of ZK Rollups on Ethereum. Following that, we will explore how ZK Rollups could differ within the Cardano ecosystem.
Introduction to ZK Rollups
A Zero-Knowledge Rollup (ZK Rollup) is a Layer-2 (L2) scaling solution. It can take a portion of the state (typically user account balances) from Layer 1 (L1) and transfer it to L2. This allows for complex computations to occur in L2, which would otherwise be slow and resource-intensive if performed on-chain (i.e., in L1). In other words, the computation takes place off-chain, providing an efficient solution for scaling.
State changes, such as transaction validation and smart contract execution, are computed off-chain and subsequently validated on-chain using Zero-Knowledge Proofs (ZK Proofs or ZKP). ZK Rollups significantly enhance transaction throughput and minimize transaction costs, all while inheriting the security of the base-layer network they are connected to for settlement.
ZK Rollups periodically submit a small data subset to Layer 1 (L1). This data is the result of processing a large volume of data in Layer 2 (L2). In this way, ZK Rollups effectively leverage the censorship resistance and security of the base layer for final transaction settlement.
The Need for Context in Transaction Validation
In any financial system, validating a transaction—a transfer of value between two or more participants—requires some context or state for verification. The system must, among other things, verify that the sender’s account has sufficient funds. It also needs to ensure that users do not spend the same funds more than once, thereby addressing the well-known double-spend problem.
Blockchain is a distributed financial system where transaction processing, or state transitions, are achieved by adding new blocks to the end of the blockchain. Each block contains multiple transactions.
As depicted in the image, the global state changes with each newly added block. The last state change occurred after adding block N+4, making the current global state N+4.
Cardano and Ethereum employ different contexts for transaction validation.
In the case of Ethereum, the validation of transactions or smart contracts is contingent on the global state at a specific moment. This global state encompasses the current status of all accounts, inclusive of their balances and the state of any existing smart contracts. Transactions within a block are arranged in a fixed sequence, and each transaction has the potential to alter the global state. Consequently, the outcome of a transaction execution can be influenced by the transactions that were executed before it within the same block.
As depicted in the image, the most recently added block is N+3, making the global state N+3. The network attempts to transition to a new state, N+4, and thus a new N+4 block is constructed. It’s important to note that the validation of the transaction in block N+4 (indicated by the green box) is dependent on the global state. Once the transaction is incorporated into block N+4, the subsequent transaction can be validated, which will be dependent on both the global state and the preceding transaction.
One of the reasons Ethereum transactions can fail is due to the unpredictability of the global state at the time of transaction validation. When a transaction is being constructed, it’s impossible to predict its outcome. The global state during transaction validation may differ from the state during transaction construction. In the interim between transaction submission and validation, the account balances of the transaction participants may have changed. These changes in account balances could prevent the transaction from being executed as originally intended by the submitter.
The figure illustrates the period between the submission of transaction TX 10, which occurred around block N+2 (state +2), and the subsequent validation of the transaction following the validation of transaction TX 9. During this period, numerous changes in the global state occurred. The validation of transaction TX 10 is dependent on both the global state and the changes introduced by transaction TX 9. Transaction TX 9, or any preceding change, could potentially cause transaction TX 10 to fail.
Ethereum transactions can be characterized as stateful.
Contrastingly, Cardano operates without a global state and employs a UTxO model. In this model, transaction validation is based on its inputs and outputs, eliminating the need for a global state reference. Each transaction consumes certain UTXOs as inputs and generates new UTXOs as outputs. The validity of a transaction solely depends on whether the consumed UTXOs are valid and unspent, and if the total value of the inputs matches the total value of the outputs.
Transaction validations are independent of each other. UTxOs are immutable objects, and exclusive access can be ensured. Within block validation, it is straightforward to ensure that each input UTxO is consumed only once and in its entirety. The order of transactions within a Cardano block is inconsequential in the context of the state.
The image depicts a network that generates a new block, N+4, containing transactions TX 9 and TX 10. The new transactions, TX 9 and TX 10 consume the old output UTxOs (represented by green boxes) to form the input UTxOs (represented by red boxes). The order of transactions within the block is irrelevant, as the transactions are independent and do not influence each other. Transaction TX 10, submitted shortly after the production of block N+2, can consume the UTxO from the transaction within that block. The addition of the new N+4 block results in the creation of new UTxOs from the input UTxOs, signifying a state change.
Cardano transactions are inherently stateless. Both inputs and outputs are known at the time of transaction submission. This allows for local transaction validation before submission, ensuring that it will likely pass the network’s validation. The ability to spend input UTxOs (their existence and the ability to spend them with the correct signature) can be verified locally, as well as the result of script execution (which depends on the input data added in the transaction by the submitter). This gives the submitter a high degree of confidence that the transaction will not fail.
Unlike Ethereum, Cardano operates predictably and deterministically. This fundamental difference significantly impacts the use of ZK Proofs.
It’s important to clarify that Ethereum does validate transactions deterministically in the sense that given the same inputs (transaction data) and the same state (the current global state of the Ethereum blockchain), the EVM will always produce the same output. However, the result of transaction validation is non-deterministic. The validation outcome may differ from the user’s expectations.
During transaction submission, the user cannot predict what the global state will be at the time of transaction validation. Therefore, it’s impossible to estimate the validation result with a high degree of certainty. It can only be assumed.
ZK Rollup Maintains State
In Layer 2 solutions such as ZK Rollups, transaction validation is crucial to maintain system integrity. This includes safeguards against double-spending and the unauthorized creation of new tokens.
Much like Ethereum’s Layer 1, ZK Rollups (L2) also preserve a global state. This global state is updated with every transaction, making the sequence of transactions significant.
State maintenance in ZK Rollups is considerably less complex than in the Ethereum blockchain, primarily because a centralized entity, known as a sequencer, typically oversees it. As a result, a single server can manage the balances on user accounts.
Users wishing to utilize ZK Rollups are required to lock tokens that have been minted on Ethereum. They accomplish this by employing an Ethereum smart contract that locks the tokens and generates an equivalent amount in the second layer.
In the second layer, users can submit transactions. These transactions alter the balances of user accounts in Layer 2. However, it’s important to note that all state changes occurring in Layer 2 do not impact the global state of Ethereum at that particular moment.
The global state within the Ethereum network changes independently of Layer 2’s state.
Should users wish to exit Layer 2 and unlock tokens secured in the Ethereum smart contract, they are required to initiate a withdrawal from the ZK Rollup. This action results in the burning of their tokens in Layer 2 and the unlocking of an equivalent quantity of tokens in Layer 1. Throughout this process, any changes in token ownership that occurred in Layer 2 are duly reflected.
To withdraw tokens from a ZK Rollup, a ZK Proof must be provided.
When a user wishes to transfer her tokens from the ZK Rollup back to Ethereum, she initiates a withdrawal request. This request specifies the quantity of tokens she intends to withdraw and the Ethereum address to which the tokens should be sent.
Subsequently, the ZK Rollup system generates a Zero-Knowledge (ZK) proof that validates this withdrawal request.
This proof essentially confirms that ‘The user indeed owns these tokens on Layer 2, and they have not been spent’.
This ZK Proof is then submitted to the smart contract on Ethereum. If the smart contract verifies the proof as valid, the requested amount of tokens is unlocked from the smart contract and transferred to the user’s Ethereum address.
To summarize:
Ethereum locks users’ tokens as a result of a deposit transaction, affecting both the global state of Ethereum and the state of the ZK Rollup simultaneously. Users can only utilize tokens in Layer 2. Transactions made in ZK Rollup primarily affect the Layer 2 state. We will further illustrate how state changes in the ZK Rollup also impact the Layer 1 state. If users wish to transfer tokens from Layer 2 back to Ethereum, they must submit a withdrawal transaction that unlocks the tokens in Layer 1. This action once again alters the states of both Layer 1 and Layer 2.
While the balances in Ethereum and ZK Rollup are interconnected, they are not always equivalent and they operate somewhat independently.
How Does ZK Rollup Work?
In Layer 2, each user maintains an account with a balance. Users submit transactions, which could involve transfers of value between accounts. These transactions are gathered and sequenced by a centralized entity known as a sequencer.
The sequencer forms a new batch of transactions, representing a group of individual transactions that have been processed off-chain.
User transactions are not included in the new state root or the ZK proof. Instead, they are stored separately in the Data Availability Layer, an off-chain storage. This data is crucial for reconstructing the state of the Rollup, and storing it off-chain enhances scalability.
Based on the batch, the sequencer computes a new global state, also known as the state root, and a ZK Proof.
In the context of ZK cryptography, Layer 1 acts as the verifier and Layer 2 as the prover.
The sequencer periodically sends a new transaction to Ethereum. Each transaction includes a ZK proof and a new state root (global state).
The state root is a cryptographic commitment to the new state of the ZK Rollup after the batch of transactions has been processed. It signifies the net effect of all the transactions in the batch.
The ZK proof is a cryptographic proof that attests to the validity of the state transition represented by the batch. It verifies that the batch of transactions was processed correctly and resulted in the new global state.
Both the ZK proof and the new global state are dependent on and cryptographically derived from, the batch of transactions. They offer a secure and efficient way to represent the batch of transactions on the main chain, without the need to process each transaction on-chain.
The Ethereum smart contract (verifier) does not require a batch of transactions for verification. It only needs the ZK proof and the new state root. Ethereum only needs to confirm that the batch as a whole is valid (as attested by the ZK proof) and understand the net effect on each account balance.
In the image, you can see the user transactions at the very top. The sequencer (ZK Rollup prover) takes the latest user transactions, orders them, and creates a batch of transactions. It generates a ZK Proof and a new global state (state root) from the batch (red arrows represent the cryptographic dependency on the batch) and sends it to Ethereum for validation in the transaction. Ethereum (ZK verifier) will validate and store the transaction in the blockchain, thereby altering its global state.
Ethereum retains the ZK Proof and the new global state transmitted by the sequencer, thereby ensuring the integrity of the ZK Rollup.
The Ethereum Virtual Machine (EVM) can operate within a ZK Rollup. This implies that developers can write smart contracts in the same manner as they would for the Ethereum mainnet. This compatibility with the EVM facilitates the porting of a decentralized application (DApp) from Ethereum to a ZK Rollup.
This essentially shifts the execution of the DApp’s smart contracts from Ethereum to the ZK Rollup. While smart contracts continue to adhere to the rules of the EVM, their execution becomes more scalable and efficient since it occurs on Layer 2.
The ease of migrating smart contracts to Layer 2 solutions is one of the reasons why ZK Rollups (and other Layer 2 solutions) adopt an account-based model akin to that used by Ethereum.
Advantages Of Cardano’s Determinism
The Ethereum community has been actively exploring various methods to enhance scalability and efficiency, with Zero-Knowledge technology being one of the promising solutions under investigation. The introduction of sequencers in ZK Rollups is a key mechanism for managing and ordering transactions in the Layer 2 network.
Sequencers serve as a solution to the issue of transaction ordering and determinism, playing a pivotal role in the functioning of ZK Rollups. However, the use of sequencers introduces a level of centralization, which raises concerns in the context of blockchain’s principle of decentralization. The sequencer, being a single entity with the power to order transactions, could potentially become a point of failure or manipulation.
Cardano’s transaction validation is deterministic, allowing for the creation of transactions where the outcome is known and predictable at the time of building the transaction. This is possible because Cardano’s transaction validation relies solely on the inputs and outputs of the transaction, and not on any global state.
In the context of ZK proofs, this deterministic nature is advantageous. When creating a ZK proof, you’re essentially proving that you know a secret input that, when subjected to a certain computation, results in a known output. Because the computation is deterministic, you can predict the output when building the ZK Proof.
Given that all knowledge of UTxOs being spent, the UTxOs being produced, and validators (smart contracts) being run is known during transaction construction, it is feasible to create a ZK proof to prove that a validator (encoded as an arithmetic circuit) executed successfully.
The ZK Proof witness can be constructed off-chain as a result of more complex computation. The on-chain validator contains an arithmetic circuit that verifies the correctness of any provided ZK Proof witness.
This is why the need for a sequencer can be reduced or even potentially eliminated. Off-chain computation could potentially be done without a sequencer due to the determinism of transactions. In Cardano’s ZK Rollup, each transaction only needs to know about its specific inputs and outputs, and does not need to interact with a global state. In other words, the advantages of the UTxO model in L1 can be transferred to L2.
In Ethereum, ZK Proof scaling solutions utilize sequencers to sequence batches of transactions in a deterministic manner so that the state can be known for the creation of the required proof (ZK Proof witness).
While constructing Ethereum transactions, perfect knowledge of the relevant state is not available. This makes it practically impossible to construct proof in the first place without trusted sequencers (operators) because the state of the contract is not known at the time the transaction is processed.
However, in Cardano, there is no need to know where a transaction will appear in the block because where it appears in the block does not affect the smart contract’s state. Only one transaction can interact with the state - UTxO’s Datum - per block.
This deterministic nature of Cardano allows for the creation of ZK proofs without needing a sequencer. It is even theoretically possible to do without an external Data Availability Layer.
In the L2 network, there must be an entity (ZK Prover) that will construct transactions for L1. The L2 state will not be a global state like in Ethereum, but rather the state of all independent transactions.
In a ZK Rollup, UTxOs can operate independently of each other, much like in Layer 1. This allows for a high level of parallelism and independence among transactions.
Even in the absence of a sequencer and transaction batching, it’s likely necessary to relay the state of Layer 2 to Layer 1 in some manner to ensure system integrity and consistency. While Cardano doesn’t require a sequencer to achieve determinism, L2 still relies on L1 for security.
ZK Rollups that utilize the UTxO model can be more easily decentralized, unlike those in the Ethereum ecosystem. The deterministic nature and the UTxO model pave the way for new implementation possibilities. It might be significantly easier to develop a ZK Rollup implementation that is more efficient and decentralized than what can be achieved with an account-based model.
It remains to be seen whether any team will manage to create a ZK Rollup that operates without a sequencer and maintains system integrity through the use of validator scripts and ZK proofs.
Conclusion
Cardano’s UTxO model presents several benefits, including deterministic transactions, the strong potential for use for ZK proofs, the elimination of the need for sequencers, and the theoretical possibility of constructing ZK Rollups without a data availability layer. These advantages make it a more favorable choice for ZK Rollups compared to Ethereum’s account-based model. The upcoming Chang’s hard fork will introduce ZK cryptography to Cardano, marking the beginning of a new chapter for the entire ecosystem.