zkSync Era: LLVM Compiler, Account Abstraction Guide

Frequently Asked Questions

01.What is the zkSync Era LLVM compiler pipeline and how does it differ from standard Solidity compilation?

zkSync Era uses a three-stage LLVM-based compiler pipeline. The zksolc compiler first invokes the standard solc compiler as a subprocess to generate Yul or EVM assembly IR (Stage 1), then translates that IR into LLVM IR using the Matter Labs fork of the LLVM framework (Stage 2), then the LLVM backend emits EraVM bytecode (Stage 3). This differs from standard Solidity compilation which targets EVM bytecode directly. EraVM bytecode is not EVM-compatible, enabling zkSync-specific optimizations like linear memory growth pricing and native account abstraction at the VM level.

02.How does zkSync Era native account abstraction differ from ERC-4337?

zkSync Era implements account abstraction natively at the protocol level through its bootloader system contract, whereas ERC-4337 operates as an application-layer standard using an alternative mempool and a singleton EntryPoint contract on Ethereum. Every account on zkSync Era, including externally owned accounts, can implement the IAccount interface to customize validation and execution logic. Paymasters on zkSync Era can interact with any storage slots without throttling, unlike ERC-4337 paymasters which face storage access restrictions. zkSync Era also has no separate bundler infrastructure requirement since the sequencer handles UserOperation processing natively.

03.What are the two paymaster flow types in zkSync Era and when should each be used?

zkSync Era defines two paymaster flows encoded in the paymasterInput field. The General Flow, encoded with the general(bytes calldata data) selector, is used when the paymaster requires no preliminary actions from the user and can sponsor transactions unconditionally or based on off-chain allowlists. The Approval-Based Flow, encoded with approvalBased(address token, uint256 minAllowance, bytes innerInput), is used when the paymaster needs the user to pre-approve a specific ERC-20 token allowance before fee processing. Use General Flow for protocol-subsidized transactions and dApp onboarding. Use Approval-Based Flow for ERC-20 fee payment and token-gated access patterns.

04.What is the EraVM type classification for zkSync Era and what are its EVM compatibility trade-offs?

zkSync Era is classified as a Type 4 zkEVM in Vitalik Buterin's classification framework, meaning it compiles high-level language source code to a custom VM rather than providing bytecode-level EVM equivalence. Type 2 equivalence systems like Scroll run unmodified EVM bytecode. The Type 4 approach gives zkSync Era advantages including native account abstraction at the VM level, linear memory pricing, and the ability to eventually support Rust and C++ smart contracts via LLVM. The primary trade-off is that contracts must be recompiled using zksolc or zkvyper rather than deploying existing EVM bytecode, and some EVM opcodes like SELFDESTRUCT behave differently or are unsupported.

05.What security audits has zkSync Era undergone and what were the key findings?

zkSync Era underwent multiple OpenZeppelin security audits prior to and following its March 2023 mainnet launch. The February 2023 L1 diff audit identified 22 issues total: zero critical, two high severity, six medium, and five low. Key findings included a deposit cap counter that failed to decrement on withdrawals, an ETH withdrawal limit logic flaw where balance checks ran after prior withdrawals had already modified state, and insufficient test coverage for critical contracts like MailboxFacet. Matter Labs resolved one high-severity and three medium-severity issues before mainnet launch. The team also ran public bug bounties and independent monitoring as part of the Fair Onboarding Alpha phase.