#46 - Horizontal Scaling with ZKThreads
Canonical ZK sharding framework for dApps
Stanford Blockchain Review
Volume 5, Article No. 6
📚Authors:
Louis Guthmann — Starkware
Tarrence Van As — Cartridge Gaming Company
🌟Technical Prerequisite: Intermediate
Summary
StarkWare and Cartridge introduce “ZKThreads,” a novel framework for execution sharding that provides scalability and customizability without fragmentation.
ZKThreads enable leaner and more flexible scaling, ensuring liveness at every step by allowing for direct fallback onto the base layer.
This results in greater security, composability, and interoperability, improving user experience and reducing transaction costs.
The first implementation can be found under this repository under the Saya settlement service.
More details about the implementation are available in an EthResearch post.
Introduction
Validity (or zero-knowledge) rollups have exploded in popularity in recent years. Until now, many applications, from rollups to coprocessors and other sharding approaches, have relied on in-house, custom-built tech stacks. This has resulted in liquidity fragmentation, reduced interoperability, and poor user experience.
To address these challenges, StarkWare and Cartridge are proud to introduce ZKThreads: a novel approach to scaling that balances security, composability, and interoperability for provable applications. This builds on the fractal scaling vision that StarkWare introduced in 2021 [1].
In this post, we will explain why ZKThreads are needed, cover their architectural design, and finally, illustrate how they open the door to new types of applications. With the addition of ZKThreads to Starknet’s existing suite of fractal-scaling technologies, Starknet expands its full-scope ZK operating system to fit any provable application [2].
Why ZKThreads?
History may not repeat itself, but it often rhymes. Before the introduction of the ERC-20 standard in November 2015, creating a new “token” or “coin” required constructing and maintaining an entire blockchain [3]. Even if you only wanted a memecoin, you’d have had to hard fork and bootstrap liquidity on your own blockchain, as was the case with Dogecoin. It’s no surprise that most tokens launched before the ERC-20 standard are now extinct.
Before ERC-20, tokens were highly integrated with the consensus protocol. Transfer mechanisms were not features that could be plucked out on their own. ERC-20, however, introduced a canonical standard to create and transact tokens on Ethereum itself without the need to hard fork and create an entirely new chain. Once projects began launching their own ERC-20s, liquidity became concentrated on Ethereum. This made it feasible to construct DEXs, lending protocols, stablecoins, and the entire DeFi ecosystem that exists today.
In the same vein, we face a comparable challenge in provable application development. Various applications, such as bridges, rollups, and ZK coprocessors, utilize ZK proofs, each with its own proof library, virtual machine (VM), and tech stack. The lack of interoperability between these stacks is cumbersome and often results in a less-than-ideal user experience.
Take, for instance, the case of the ZK coprocessor. In the simplest sense, a ZK coprocessor relies on a “compute offchain, verify onchain” model, where the “compute” ranges from specific tasks (such as computations over historical data) to Turing-complete, general-purpose computation [3]. The “verification” in this model refers to posting a ZK proof onto a settlement layer that attests to the validity of execution results. This allows developers to run computationally intensive programs offchain and prove their validity onchain. Still, the ZK coprocessor’s design poses several challenges:
Security: ZK coprocessors can guarantee proof of correctness, but they can’t guarantee liveness. In other words, they can’t guarantee that they will actually provide the proofs.
Composability: Every tech stack has its own technical standard, whether through custom ZK libraries or circuits. This results in a lack of composability between these different layers.
Interoperability: Because of (1) and (2), applications running on ZK coprocessors are siloed from one another, leading to fragmented liquidity and a lack of interoperability.
Instead, we need a common interface—just like ERC-20—to standardize the development of provable applications and open the door to applications that require interoperability, pooled liquidity, and other shared resources.
Enter ZKThreads.
Leveraging Starknet’s position as a leading validity rollup and Cairo’s natural advantage as an easily provable language, ZKThreads standardize the development of provable applications and provides the following guarantees:
Security: ZKThreads allow for executing directly on Starknet when needed, ensuring liveness at every step and a leaner design for dApps.
Composability: Through introducing the ZKThread standard, developers are provided with a standard, composable toolkit to develop a wide variety of provable applications, including native bridging, common DA layers, and security mechanisms.
Interoperability: All applications using the ZKThread standard will natively interoperate with each other, minimizing fragmentation and opening up numerous new use cases.
How do ZKThreads work?
The overall goal of the ZKThreads architecture is to allow provable applications to balance performance, composability, and interoperability. Architecturally, it is composed of:
The ZKThread – This includes a batcher, a prover, and contracts.
The ZKThread Verifier – A contract on Starknet that verifies state changes in each ZKThread
The operational logic of the ZKThread is as follows:
Application logic is deployed in the thread’s app contracts, which produce transactions and state changes in the dApp ZKThread.
Transactions in the ZKThread become batched in a sub-block.
The prover creates a STARK proof of the sub-block state changes and sends it to the L2 sequencer.
The ZKThread Verifier verifies the proof of the state changes against the canonical record it holds of the dApp.
The ZKThread Verifier either accepts or rejects the state changes. If accepted, the canonical record is updated. If rejected, it cancels the ZKThread transaction on the L2.
The ZKThread Verifier’s primary goal is to attest to the validity of the state-change proof emitted by a ZKThread. It does this by recording the canonical state of each dApp and the OS version, and then checking the list of state changes against the canonical state. If everything adds up, the ZKThread transaction is accepted and the canonical state is updated. If not, the transaction is rejected.
By remaining in the canonical state, ZKThreads enable much easier interoperability between the different threads and contrasts with L3 design, which holds a completely different state.
What ZKThreads bring to the table
Processes and threads are not only different components in the world of traditional operating systems but also in the world of blockchain. L2 and L3 appchains are the Starknet versions of processes, while ZKThreads are comparable to their namesake in operating systems. Here’s how ZKThreads differs from L2 and L3 appchains:
L2 and L3 appchains run isolated processes—each with its separate resources, designs, and states. Although it is possible to use shared data availability frameworks and other mechanisms to achieve forms of interoperability, these are far from ideal.
ZKThreads are the blockchain version of threads in the world of operating systems. Their processes operate on shared system resources and are natively interfaced through the dApps canonical state. ZKThreads are designed from the very start to be interoperable, introducing a simple yet elegant design that implements a new canonical framework for ZK coprocessing.
By combining L2 and L3 appchains and ZKThreads into its scalability buffet, Starknet creates an operating system that balances performance, composability, and interoperability. Some of the benefits of ZKThreads are:
Improved UX: Due to the interoperability enabled by ZKThreads, users of apps built as ZKThreads can move from app to app without switching networks and other infrastructure.
Lower costs: Like L3s, ZKThreads enable additional scaling on Starknet by adding another layer of proof compression before settlement. That means even lower costs than on the public L2.
No fees on the Thread: Apps operating as a ZKThread update the base layer at regular intervals in bulk, meaning users won’t need to pay fees on their individual transactions within the thread. Fees will only be paid when settling on the base layer.
ZKThreads: Use cases
Just as the ERC-20 standard paved the way for various use cases in crypto we see today, ZKThreads open the door to provable applications that require an additional level of interoperability that can’t exist under an L3 model. They expand the panel of scaling solutions available within Starknet. Consider the following:
L2 DEXes
ZKThreads open the door to decentralized exchanges (DEXes) on Starknet. Think, for example, of dYdX, powered by StarkEx. Operating such a platform directly on Starknet today would be unfeasible because users would have to pay fees on every single trade. With ZKThreads, users only have to pay fees when they cash out.
Session-based Games
ZKThreads offer the same solution for session-based games, such as poker and chess. Rather than having to pay a fee on every move, players only pay fees once the game is over and the result is submitted to public Starknet from the thread. This opens up the fully onchain game design space to a wider variety of game genres.
ZK-secured middleware and shared liquidity infrastructure
With ZKThreads, Oracles, bridges, and other forms of middleware do not need to bootstrap a validator set from scratch, nor do they need to rely on forms of restaking that may pose centralization risks to the underlying chain. Instead, they could directly build functionality as a ZKThread, and let the ZK proofs generated in the ZKThread framework guarantee security and interoperability. This is especially true in the case of liquidity infrastructure, much of which can be shared between different applications.
Take, for example, Uniswap Hooks, the plugins available to customize how pools, swaps, fees, and LP positions interact on Uniswap [5]. The boilerplate code for Uniswap Hooks is the same as regular Uniswap, but certain aspects of the protocol can be customized to fit specific needs. In the ZKThread design, most of the program could be hosted as a ZKThread, while the stored canonical version could offer a customizable API with hooks that other ZKThreads and applications can use.
Onchain AI, social networking, and other common utilities
Onchain AI systems, social graphs (the databases that track user touch points across platforms), and other libraries that can be shared across various applications could all benefit from the vast library of common digital resources mentioned above. ZKThreads offer the computational flexibility and resources to host an onchain AI agent or model. The canonical state of this model can then be mirrored in the ZKThread Manager for use in various applications, spanning from gaming to social networking to productivity tools.
Marching toward verifiable applications
Of course, the above list of potentially new dApps is not exhaustive of all the potential types of applications that can be built using ZKThreads. Still, they provide insight into what ZKThreads enable: a design that merges security, composability, and interoperability. Just like ERC-20s, the ZKThreads standard marks a pivotal point in the maturation of blockchain. With the addition of ZKThreads to Starknet’s suite of other industry-leading technologies, Starknet will expand its full-scope ZK operating system that aims to create a thriving ecosystem of verifiable applications, where all arbitrary computation can be proven correct. Trustlessness has long been a promise of the blockchain space. Validity proofs embody this pursuit of truthfulness as one of the best examples of how the industry marks a paradigm shift in computing history. And so we march onward toward a world of verifiable applications.
About the Authors
Louis Guthmann
Louis Guthmann is Head of Product and Market Strategy at Starkware. He has been involved in the blockchain and cryptography space for several years prior as the co-founder of ZK-Global meetups and his various contributions to the Ethereum open-source community, and has two M.Sc. in Computer Science and in Business Administration, respectively from Ecole Centrale Paris and ESSEC Business School.
Tarrence Van As
Tarrence is the co-founder of Starknet gaming console Cartridge and on-chain gaming ecosystem Dope Wars. At Cartridge, he is focused on enabling onchain gaming universes, improving ux for players and dx for builders. Previously, Tarrence worked at Tally, building infrastructure for onchain governance, and at Magic Leap, researching deep learning algorithms for 3D world reconstruction.
[1] https://starkware.co/fractal-scaling-from-l2-to-l3/
[2] https://starkware.co/what-are-appchains/
[3] https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
[4] https://dydx.exchange/
[5] https://docs.uniswap.org/contracts/v4/overview