The concept of Account Abstraction (AA) is gaining significant momentum in the blockchain space. Despite the promise it holds, AA faces a major challenge: the high costs associated with calldata. In this blog post, I'll explain this issue and why zkSync's state diff model is crucial for our infrastructure.

Rollups: Rollups are, in essence, blockchains. They have a state transition function, full nodes, and, hopefully in the future, trustless light clients. Their main functionality lies in performing off-chain computations without any extra trust assumptions. However, the reality is often much different than what we think.

Rollups are communicating Ethereum with a smart contract bridge. This bridge is so important for Rollup's security because assets are secured via the smart contract (I know it is much more complex in reality; rollups are not real, but this is not today's topic). What's happening in Rollup Bridges? Rollup bridges maintain a state root on Ethereum. This state root represents the Rollups state, and changing the state root requires integrity proof mechanisms such as ZK proofs and fraud proofs, but why?

Ethereum cannot know what's happening outside of the Ethereum blockchain. Thus, rollup executions should be calculated from zero, or we need to find a way to prove it to the blockchain. This is why we need integrity proofs. In practice, we see two proof systems: fraudulent proofs and zero-knowledge proofs. They're different, and it's important to understand what we need on the data availability side.

Fraud Proofs: Fundamentally, Fraud Proofs only prove invalid computations. I won't go into detail about the two types of fraud proofs (non-interactive and interactive). Optimistic rollups (rollups that use fraud proofs) assume that all state transitions are valid unless a fraud proof exists. All state transitions are happening after a challenge window, to be sure that watchers have enough time to create a fraud proof and sent it to mainnet. To prove the invalidity of a fraud proof, fully onchain DA is essential. Thus, using various Data Availability Layers becomes difficult since, due to the nature of Fraud Proofs, if the DA layer posts invalid data, there is no way to prove it to the mainnet. And also state diffs (we’ll dive into details) are useless for Optimistic Rollups because fraud proofs are requiring fully onchain data.

Zero Knowledge Proofs: Zero Knowledge Proofs (also known as validity proofs) prove the validity of computations using cryptographic algorithms. Consequently, state transitions rely on cryptographic algorithms, not on game theory. ZK Rollups can utilize different data availability layers or methods with minimal security changes (compared to optimistic rollups). This is because users don’t need to trust the Data Availability layer to be sure that state transitions are valid. Therefore, we've seen the emergence of solutions like validium and volutions, which decrease the costs of Data Availability with some minimal security changes. And also this is why ZK Rollups can utilize both State Diff and TxData data (also know as transaction data input) posting functions.

Data Availability: Data Availability is required for three things:

Censorship Resistance and Liveness: Rollups aim to inherit the security conditions of the base layer, and censorship resistance is one of these aspects. Ideally, a rollup should enable everyone to construct the state, even if they are not running a full node for the rollup. Additionally, it should allow users to access the chain even if the prover or sequencer stops working. This aspect is crucial for both liveness and censorship resistance. Onchain DA is needed to construct the rollup’s state and

Security: As I have mentioned, rollups strive to inherit the cryptoeconomic and social security of Layer 1 (L1). Therefore, in many cases, on-chain Data Availability is essential.

State Diff: Data Availability is important but sending all transaction data to ethereum can be problem because Ethereum’s DA capacity is not scalable right now. State Diff is an another method for posting the data to base layer with some trade offs on finality side. Let’s explain how state diffs are working and what trade offs are coming with it.

Finality: Finality on rollups can be thought in two perspectives.

• For a user who doesn’t run a full node on Layer 2 (L2), a transaction is finalized when the state root of Layer 1 (L1) changes, incorporating the user’s transaction in a block, and this block is finalized through consensus.

• For a user who runs a full node on Layer 2, a transaction is finalized when a batch includes the transaction is sent to Ethereum, and the block that includes this batch is finalized.

For rollups that post all transaction data to Ethereum, users who run a full node can achieve faster finality. They can directly verify that their transaction is included in the batch. However, users of state diff rollups should wait for finality on Layer 1.

However State Diff is coming with a significant improvement: users are only paying for functions that changes L2’s storage slot in L1 instead of paying for all transaction data. State diff rollups are posting only overall change to the state from the batch of transactions (not just one transaction). This is why, if a user had an oracle that updated the same slot 100 times in a single batch, it is only charged for 1 update, because you only care about the last state of the storage slot. Users don't care about the 99 that were overwritten.


Account Abstraction and State Diff:
Quick Reminder: Users pay for three things on rollups: the Layer 2 (L2) execution fee, the Layer 1 (L1) calldata cost (for Data Availability), and the proof verification cost (specific to ZK Rollups)

ERC 4337 and 4337 like protocol-level improvements (such as zkSync's and Starknet's Account Abstraction) introduce a new transaction type that includes two functions: Verification and Execution. In State Diff rollups, the verification process does not alter any slot in Layer 1 (L1). As a result, users only pay for the Layer 2 (L2) execution cost, instead of paying for all transaction data. Additionally, users benefit from the cost improvements associated with State Diff on the transaction execution side.

As a Clave, we are building an infrastructure to be pioneer of payments in Web3. As a payment focused app, we need cheap way to achieve self custody + smart wallet features. zkSync’s state diff’s are helping us to decrease the calldata cost that comes with Secure Enclave based signer. Also with the upcoming EIP-7212 implementation, Clave accounts are going to be first class citizens in ZK Stack chains. Furthermore, with the upcoming decentralization of zkSync, we will be able to achieve enhanced security guarantees regarding finality.

At the end of day, we (Clave + MatterLabs team) are trying to solve the gas issue with;

EIP-7212 integration for L2’s execution fee: The EIP-7212 contract is a precompiled contract designed for gas efficiency and secure operations on the secp256r1 curve. Since zkSync currently does not support modexp, the estimated gas amount for r1 verification without EIP-7212 is around 2 million gas. Consequently, the zkSync team is working on integrating EIP-7212 to improve the usability of passkeys and wallets based on hardware signers.
State Diff’s for reducing L1’s Calldata Cost: As I have mentioned earlier, state diffs are so powerful for reducing the calldata overhead that comes with account abstraction.

Boojum + Shared Bridge Upgrade to Reduce the Gas Cost for Proof Verification: As I explained in the ZK Stack article, proof verification will become much cheaper with the upcoming ZK Stack chains. Additionally, zkSync has recently changed their proof system to one that is more cost-effective.

However, there are already additional approaches being implemented to reduce calldata costs, with most of them focusing on compression:

Bulk by Daimo Team
BLS aggregation by 4337 team
BLS wallet by wax team
Rollup Compression by Vitalik

Thanks a lot to Donnoh for answering my questions and helping me to understand the differentiators between state diff and txdata rollups. Also special thanks to Anthony for giving valuable feedbacks on the thread and Ori for helping me within answering my questions.