ZK Rollups Deep Dive (ZK-ZK-Rollups, SNARKS, STARKS, Privacy, zkEVMs, DAOs)

Notes

• Payment systems and scaling Ethereum solutions started to implement ZK first. New projects are emerging around privacy and interoperability as well as experimentation around digital identity, gaming, governance, and compliance with ZKPs.
• These three requirements are widely misunderstood within the crypto space. Ironically, the majority of ZK-rollup scaling solutions today do not incorporate the transaction-shielding privacy component of the third requirement. This means transactions on most ZK L2s are not private by nature, though some L2 rollups, such as Aztec Network, operate what’s known as a ZK-ZK-rollup with privacy preserving features.
• Haichen Shen @shenhaichen: Zk-rollup is not zero knowledge. It only uses compression feature from zk for scaling. We should have a better name for it, eg. succinct rollup or validity rollup. Any better idea? 12 Oct, 2022
• zk-SNARKs are not post-quantum (PQ) secure because of their reliance on public-private key pairs. This results in SNARKs being less future-proof than its more recent cousin, STARKs.
• STARKs are a newer form of cryptographic technology and share similarities with SNARKs. STARK stands for “Scalable Transparent Argument of Knowledge.” For one, STARKs do not need any trusted setup. STARKs instead leverage a leaner form of collision-resistant cryptography. All STARKS are also PQ secure because they are built on hash functions versus elliptic curve algorithms. Though these benefits are obvious, STARK proof sizes are much larger than SNARK, which creates challenges for scalability and implementation.
• As further research occurs, the lines between the two implementations are beginning to blur. Recent iterations of zk-SNARKs, for example, neither need a trusted setup nor are post-quantum insecure. Currently, most implementations of SNARKs are based on pre-quantum assumptions.
• Notably, though the proof might have certain qualities, the resulting system must also have secure properties. As an example, L2s that currently use STARKs do not have PQ private keys. Though STARKs are PQ secure, there is a risk that private keys might be compromised.
• One big advancement to the tech behind zk-SNARKs in recent years has been PlonK, a zk proving system used by zkSync, Mina, Zcash, and other leading crypto protocols. PlonK was invented by the team behind Aztec Network, a privacy-focused L2 rollup.
• A large differentiator between PlonK from predecessor proving systems like Groth16 is its ability to handle universal preprocessed zk-SNARK constructions. This means one zk-SNARK setup could be used for the whole scheme instead of needing to create multiple setups for each prover/verifier relationship.
• PlonK’s ability to handle a single trusted setup meant proof size and verification time increased. As a result, research into even newer proof systems continues. For example, Polygon announced their own proof system, Plonky2, a recursive proof system designed to verify proofs quicker than PlonK. Polygon has incorporated Plonky2 into its prover system. As more capital is deployed by ZK teams for research in the blockchain space, it’s fair to expect further advancements to this crucial bottleneck of ZK tech.
• srikar @SrikarVaradaraj: When the history of cryptocurrencies and permissionless, decentralized technologies is written decades from now, three events will stand out above all: Bitcoin's creation, Ethereum's creation + smart contracts, and the development of practical zk-proving systems. 2 May, 2022
• STARKs are larger than SNARK proofs. While a STARK is around 40-50 kilobytes, a SNARK is only around 288 bytes. Therefore, a STARK is a much larger proof by a factor of several multiples. A single proof compresses data, but proofs can also be compressed to cheapen computation.Recursive proofs via Cairo recently went into production for StarkEx and StarkNet. They aggregate multiple proofs into a single, compressed proof for verification through parallel proof generation. These proofs increase the number of transactions that can be written to Ethereum via a single proof.
• The first such privacy network to use ZK tech was Zcash (ZEC), a fork of Bitcoin with zk-SNARKs to prove that all requirements for a valid transaction are satisfied without revealing additional details.
• Mixers offer another alternative for privacy. These services allow users to deposit some amount into a mixed pool, then withdraw it some time later to another address. Using this system, the linkage between capital inflow and outflow from and to various accounts becomes difficult to track. Liquidity is critical for mixers to be successful. Mixers with high liquidity make it easier for users to obfuscate their capital while those with lower liquidity see less inflow/outflow volumes. The most liquid mixer remains Tornado Cash on Ethereum, although forks such as Typhoon and Cyclone exist on other L1 networks.
• In August 2022, a Tornado Cash developer was arrested in Amsterdam for his work on the protocol. Though mixers aren’t illegal, they operate in a gray area of existing regulation. Regulation, which, should be noted, is outdated for blockchains and newer technologies.
• Ethereum was built as a public blockchain first. That’s why newer generations of privacy networks like Aleo and Iron Fish merge the ability to build smart contracts with privacy-first L1 blockchain. The end result is application-level privacy for dapps built on these networks.
• Most of the progress with privacy-first networks is still early. Both Aleo and Iron Fish need to and are undergoing incentivized testnets before rolling out their product to mainnet. Attracting developers is also an important step that must be completed.
• For example, Aleo maintains unique features in its network: zkCloud, the snarkOS blockchain, and snarkVM. Developers who want to build dapps for the Aleo ecosystem must learn a new programming language, Leo, and become familiar with its custom Aleo Virtual Machine. All these efforts take time, making mass adoption of privacy-first blockchains likely one or two years out.
• If Ethereum does hope to integrate more privacy into its suite of dapps, it will need to rely on modular privacy via L2s. As mentioned, Aztec Network is the leader in privacy-first rollups with Polygon Nightfall an alternative designed more for enterprises.
• In July 2022, Aztec launched Aztec Connect, a bridge between Aztec’s privacy-secure rollup and Ethereum dapps. Aztec Connect acts like a VPN for dapps. Developers can either bridge their DeFi app to the Aztec privacy rollup or opt to integrate the Connect standard development kit (SDK) with their dapps front-end design. Both solutions enable end users to make trades on the Aztec privacy-secure ZK-ZK-rollup.
• ZK-rollups were built to be special purposes, mainly for payments or swaps because application-specific circuits (ASICs) for an application (payments in this case) are easier to design than a general-purpose circuit. The alternative was to take this overhead of circuit development away from the developer and build the latter, which is where zkEVMs come in.
• EVM compatibility for an L2 refers to the ability for developers to easily port contracts from Ethereum L1. There is language-level and bytecode-level compatibility at the granular level. Ethereum has an established presence and projected staying power in crypto, thus EVM compatibility is desired for the derived reliability and security.
• The alternative, Optimistic Rollups (ORUs), can more easily achieve EVM compatibility than ZK-rollups, which run into mathematically complex operations to prove EVM execution. As a result, the zkEVM debate often coalesces towards the definition of “true” EVM compatibility, where achieving perfect compatibility hits diminishing returns if the majority of development does not require full 1:1 opcode conversion.
• Meanwhile, the Privacy and Scaling Explorations (PSE) team housed within the Ethereum Foundation is slowly building a perfectly compatible zkEVM, but the difference between PSE and Scroll is the storage solution used. PSE uses the Keccack hash function as the EVM and a Merkle Patricia Trie (data structure), which have large proving costs and why zkEVM projects are choosing to use alternatives. Alternative routes can break compatibility.
• These projects lead the zkEVM race, while newer contestants such as Taiko, Kakarot, and Consensys zkEVM are emerging.
• To the end-user navigating a zkEVM, dapps should provide a seamless and secure experience. The system differences will only impact developers closer to the code. Opcodes are instructions read by a virtual machine. Part of EVM compatibility depends on the amount of opcode coverage on the non-EVM machine, which has 141 opcodes. None of the current zkEVMs en route to production have full-opcode coverage, and reasons range from upcoming deprecation, not commonly used, or unable to cover due to compatibility limitations.
• For the average developer, the intricacies of EVM complexity do not matter. However, when it comes to low-level bytecode optimizations to achieve things like lowered gas consumption, developers will run into issues with a non-perfect zkEVM.
• Given the starkly different phases of development that each zkEVM, it is difficult to compare them against each other. Currently, none of the more established zkEVMs have an open-source prover. In zkSync’s case, the prover has not yet been implemented into the public testnet.
• Ideally, L2 tokens would earn a monetary premium. Though nothing has been confirmed, all major L2s and zkEVMs in production have hinted at plans to have gas fees paid in ETH. Meanwhile, StarkNet, which is en route to decentralization, has opted to use the STARK token for gas fees. Transacting on StarkNet, users would dump ETH for STARK, taking fees away from operators in L1 and toward the L2. This is disadvantageous to the Ethereum ecosystem but beneficial to the L2.
• zkSync 2.0 is in line to be the first zkEVM to have a mainnet. It has existed the longest and has had the proper time to test and audit the rollup before production. Whichever zkEVM does reach mainnet first will have first mover advantage. Compared to the other systems, zkSync will be a volition system where the user will ultimately decide where data availability takes place – providing a place for cheaper fees. Scroll and Polygon are in the earlier stages of testnet, so there’s no user activity/developer to look at yet.
• To see what the potential for rollups can be, we can look at wallet and bridging activity. As of November 14, there are about 455,000 zkSync unique addresses, 16% of which are Argent addresses – the rest are on other Ethereum wallets. Argent is an L2 wallet for Ethereum and is able to offer speed and low costs to users. It is the wallet users must obtain to interact with zkSync. Since its inception, Argent has seen a steady growth in wallet count, rising from 62,930 at the start of 2022 to 72,951 in November.
• Argent X is the first wallet on StarkNet, launched on the Chrome Store. As of now, there have been 100,000+ installations. Argent X is a developer tool (not a user wallet) that lets users create and manage accounts on StarkNet applications. This shows that as StarkNet gets closer to launching a token, there is a burgeoning developer base in the works already.
• Arbitrum and Optimism have EVM clients and full opcode coverage. Developers can build for either of these chains with existing EVM infrastructure – one might ask why we need zkEVMs. Since ORUs already have mainnet and an ecosystem, they have first mover advantage, and in time it might be tough for users and developers to offboard and move to ZK-rollups since these two systems drastically differ in terms of development.
• ZK-rollups approach scalability with no upper bound because of the ability to distribute computation to any machine in a trustless manner. zkSync already achieves lower fees for sending ETH – ZK-rollups will have the lowest fees once they are live and easier to run, contingent on hardware and software.
• Also, L2s have yet to reach their final form. As highlighted by Vitalik in his rollup classification post, rollups must have “training wheels” when they first onboard a user base. Users should be able to withdraw funds from the bridge if the L2 node is not responsive. Arbitrum and Optimism currently do not have an escape hatch mechanism, while zkSync does.
• Further, all rollup sequencers remain centralized and have yet to achieve Ethereum’s security. Until then, all rollups compete to acquire users and developers.
• At the protocol level, Ethereum is moving in the ZK direction. In Vitalik’s updated roadmap for Ethereum, the Verge will signify the new method of verifying blocks. This would entail a fully SNARKed Ethereum, which would use PQ-secure SNARKs.
• In a world of heterogeneous ecosystems, a multi-chain future is inevitable, but the road to interoperability is a treacherous one.
• Bridging infrastructure for L1s is not performant, and several remain reliant on a central party to log changes from the source chain to the target chain. These weak trust assumptions erode security and promote risk of compromised bridges – which alone accounted for an estimated 90% of lost capital in 2022 as of August.
• Projects using ZKPs in bridge architecture are actively addressing the decentralization and security concerns in incumbent builds. Instead of multisig committees attesting transfers, on-chain light clients are used. Light clients only download block headers to keep track of state, which can be used to build bridge communication. A light client would keep track of its own chain (Chain A), but it is being hosted on Chain B, which gives Chain B access to all data on Chain A.
• However, a light client is generally too complex and expensive to host on-chain within a smart contract, especially between blockchains with different VMs. Computation can be performed off-chain where it's less expensive, and then have a proof submitted on-chain to verify the computation. Succinct uses ZKPs to verify computation, providing 'Proof of Consensus' for light clients at a manageable computational cost.
• Higher-order ZK-rollups (L2, L3) will require trustless bridging. Recursive proofs enable fractal scaling, where L3s would submit validity proofs to L2 as L2 does L1. The compression multiple increases with order, which means greater scalability than L2s alone can achieve.
• However, L1 bridge design does not solve what rollups require. Inter-rollup bridges face their own trilemma:
• Remaining trustless
• Not interacting with L1
• Transfers beyond swaps
• Such a construction would allow for any data or function call to be bridged between rollups and with the non-interaction with the L1, no L1 fees are involved.
• ZKPs are useful for digital identity verification. ZKPs can verify a person and their reputation without revealing any of that information, which is true sovereignty. Attestation infrastructure can help with membership into communities and DAOs without revealing any information or parts of one’s identity (ENS address, memberships to other communities). It can also help accrue reputational information.
• As mentioned, Web2 has a chokehold on our data and reputation that can actually help the shift to Web3 if bridged over. Sismo is a protocol focused on decentralization and privacy, which issues ZK badges, which is a non-transferrable token that one can mint with information from a Web2 account. This is crucial in on-ramping reputation from Web2 to Web3 such that users are not working from scratch to build reputation. Eligibility to the community is determined by a smart contract (ZK attester).
• DAOs are nebulous and non-regulated entities.
• Anonymity is one of the trademarks of crypto-based systems and KYC services natively cannot support anonymity in this process as that user data must be handed over. Instead of singular KYC providers conducting and having custody of client data and the client having to go through several providers for different reasons, ZKPs can facilitate KYC without handing over any data to central parties.
• Further applications of ZK within a DAO can come in the form of shielded voting. Snapshot has implemented shielded voting via threshold cryptography to hide votes during a voting period, but this is only in the short-term voting period. Though this voting is shielded, the member’s identity might still be public in other parts of the DAO. ZK proofs can help trustlessly manage one’s membership and governance activity in a DAO.
• Bringing ZK tech to market has actually taken less time than many expected. But because most proof systems depend on elliptic-based circuit computation, the resulting system is at risk of centralization because of specialized hardware requirements.
• Circuits are hard. To build them, developers must write low-level code. To prove a ZK computation was correct, the computation has to be represented as an arithmetic circuit, and blockchain operations are not easily translated to a circuit well. Additionally, proof generation time does not scale well and can be expensive.
• Software development practices in Web3 are also nascent. There is a disconnect between developers and repositories and marketing speak in Web3. It is often difficult to discern progress and stage of development without reading available code, and clarity is crucial in ZK as this tech is complex and bugs are common.
• The irony of these challenges is that several are perpetuated by the recent influx of venture funding into the ZK space. Building interoperable applications requires a common tech stack. However, each project’s ability to raise capital independently has led to overlapping R&D teams, fragmented software, and isolated ecosystems. Any wash-out of investment in the near future is a double-edged sword: it reduces the path of growth, but optimistically, could be the catalyst to force various projects to work closer together.
• Who would have thought 40 years after the first ZKP that there would be this real-world use case? Certainly not one of the creators, Shafi Goldwasser, who has expressed delight at her invention finding a home in blockchains. It’s a great example of a theoretical field becoming applied as technology continues to evolve.