Arbitrum, Optimism, zkSync, and Starknet are all representative scaling solutions in today’s Ethereum Layer2 ecosystem. Although these networks all aim to “lower costs and increase throughput,” they differ clearly in their underlying verification methods, state security models, development compatibility, and scaling paths.
As Ethereum gradually forms a modular structure of “mainnet + Layer2”, competition among Layer2 networks is no longer just a simple comparison of TPS. It has become a competition between different scaling philosophies. Some Layer2 networks place more emphasis on EVM compatibility, some focus more on the efficiency of ZK technology, and others pay closer attention to long term on-chain computation capabilities and the account abstraction experience. Understanding Starknet and how it differs from other Layer2 networks helps clarify the future direction of Ethereum’s scaling ecosystem.
Starknet, Arbitrum, Optimism, and zkSync are often discussed together because they are all Ethereum Layer2 scaling networks. The problem they are all trying to solve is the long standing performance bottleneck of the Ethereum mainnet.
With the development of DeFi, NFTs, blockchain games, and on-chain social applications, Ethereum has gradually faced high gas fees, low throughput, and congestion. When the network is busy, even a simple transaction can become expensive, while complex smart contract interactions cost even more. This situation has pushed Layer2 to become an important direction for Ethereum scaling.
At a high level, the core goal of Layer2 is to move a large portion of transaction execution off the main chain and submit only the final results to Ethereum for security verification. This preserves Ethereum’s security while significantly reducing transaction costs and on-chain load.
However, different Layer2 networks take very different approaches to “how security is guaranteed” and “how performance is scaled.” For example, Arbitrum and Optimism use Optimistic Rollup, while Starknet and zkSync belong to the ZK Rollup camp. At the same time, there are clear differences in development compatibility, proof systems, account structures, and data processing methods.
Therefore, although these Layer2 networks share similar goals, they essentially represent competition between different technical paths.
The mainstream Ethereum Layer2 approaches today can roughly be divided into two categories: Optimistic Rollup and ZK Rollup.
Arbitrum and Optimism belong to Optimistic Rollup, while Starknet and zkSync belong to ZK Rollup.
The biggest difference between the two lies in “how Layer2 transactions are proven valid.”
The core logic of Optimistic Rollup is that “transactions are valid by default.” Layer2 first submits transaction results to Ethereum, and the network does not immediately verify whether the computation process is correct. Instead, it assumes the submitted result is trustworthy. The system then keeps a Challenge Period, during which other participants can dispute an incorrect state.
If someone finds a problem, they can submit a Fraud Proof to overturn the incorrect result. For this reason, Optimistic Rollup works more like an “after the fact review” model.
By contrast, ZK Rollup follows a “prove first, then submit” model.
In Starknet, large numbers of transactions are first executed on Layer2, then a STARK Proof, or zero knowledge proof, is generated to prove that the entire state transition process is correct. The Ethereum mainnet does not verify each transaction itself. It verifies this mathematical proof.
This structure means that:
ZK Rollup does not require a long challenge period
Withdrawal confirmation is usually faster
The mainnet does not need to re execute all transactions
Security verification is more mathematical
However, ZK Rollup is also more technically complex. Generating zero knowledge proofs requires substantial computational resources, so the proof system, Prover architecture, and proof compression technology become important components of overall network performance.
Therefore, Optimistic Rollup places greater emphasis on compatibility and fast deployment, while ZK Rollup focuses more on long term scaling efficiency and mathematical verification.
Although Starknet and zkSync are both ZK Rollups, their technical philosophies still differ significantly.
zkSync places greater emphasis on EVM compatibility.
Its core goal is to allow Ethereum developers to migrate existing Solidity applications with as little friction as possible. For this reason, zkSync prioritizes compatibility with Solidity, the EVM toolchain, and Ethereum development habits.
This path means:
Lower migration costs for developers
Existing DApps are easier to deploy
Faster absorption of the Ethereum ecosystem
At the same time, however, its underlying architecture is also affected by the historical design limitations of the EVM.
Starknet takes a more ambitious path.
Starknet does not fully adopt the EVM. Instead, it has built an independent Cairo virtual machine and Cairo programming language.
Its core logic is:
The EVM itself was not designed for zero knowledge proofs, so over the long term, rebuilding an execution environment better suited to ZK may offer a higher scaling ceiling.
For this reason, many of Cairo’s design choices are built around “how to generate STARK Proofs more efficiently.”
Although this path raises the development threshold, it also gives Starknet stronger potential in areas such as:
Provable computation
Parallel execution
Native account abstraction
Highly complex on-chain applications
Put simply:
zkSync is more like “ZK enabled Ethereum”
Starknet is more like “a new execution layer for the ZK era”
This is the largest structural difference between the two.
The core goal of Arbitrum and Optimism is to scale performance without changing Ethereum’s development paradigm.
Therefore, they try to preserve:
Solidity compatibility
EVM equivalence
Ethereum toolchain compatibility
Native MetaMask support
The biggest advantage of this path is that it can quickly attract developers and capital to migrate.
Many Ethereum DApps can be deployed directly on Arbitrum or Optimism with only minor changes. As a result, their ecosystems often expand more quickly.
However, their long term scalability is still limited by the EVM execution structure.
Starknet’s scaling logic, by contrast, leans more toward “redesign.”
Starknet is not only trying to lower gas costs. It is attempting to build:
A virtual machine better suited to ZK
A more efficient proof system
A more flexible account system
A more scalable computation structure
For example, Starknet’s native account abstraction is not an add on feature introduced later. It is part of the protocol’s underlying design.
At the same time, Cairo’s computation model is also better suited to complex proof generation.
As a result, Starknet is more like an attempt to prepare for future “large scale on-chain computation,” rather than a short term TPS improvement solution.
This difference also means:
Arbitrum / Optimism are more like “Ethereum scaling layers”
Starknet is more like “a new ZK execution network”
The difference between Cairo and the EVM essentially represents two completely different technical paths.
The EVM is Ethereum’s core execution environment, and almost the entire Ethereum ecosystem is built around EVM compatibility.
Its advantages are very clear:
A large developer base
Mature Solidity tooling
A well developed tool ecosystem
Low migration costs
For this reason, most Layer2 networks prioritize EVM compatibility.
However, the EVM itself was not designed for zero knowledge proofs.
In a ZK Rollup, all computation eventually needs to be converted into proofs, and many of the EVM’s historical structures reduce proving efficiency.
That is why Starknet chose Cairo.
Cairo’s core goal is to make program execution naturally suited to generating STARK Proofs.
In other words, Cairo is more like a “provable computation language.”
Although this design increases the development threshold, it also brings many long term possibilities, such as:
Higher proving efficiency
More complex on-chain logic
Stronger parallelization potential
Better suitability for AI and high computation scenarios
At the same time, Starknet’s account system is also clearly different from the EVM model.
Traditional Ethereum accounts rely on EOAs, while Starknet uses smart contract accounts by default, so it natively supports:
Multisig
Session Key
Social recovery
Custom signature logic
Therefore, the Cairo path is not simply a matter of “using a different language.” It is a redesign of the underlying interaction structure of Layer2.
The technical paths of different Layer2 networks also determine which scenarios they are better suited to.
Arbitrum and Optimism are better suited to:
Rapid migration of Ethereum applications
DeFi adoption
EVM native ecosystem expansion
Low migration cost development
For this reason, many existing Ethereum protocols often choose to deploy on these networks first.
zkSync is better suited to:
Applications that want to combine ZK and EVM
Lower gas cost scenarios
Payments and high frequency transactions
A smoother ZK migration path
Starknet is better suited to:
Highly complex on-chain computation
AI + blockchain
Native account abstraction applications
Large scale blockchain games
Long term ZK infrastructure
Especially in scenarios that require complex computational proofs, Starknet’s Cairo and STARK path may offer greater potential.
Therefore, Layer2 is unlikely to end with “one chain only.” It is more likely to form a long term structure in which multiple technical paths coexist.
Starknet’s greatest advantage lies in its technical ceiling.
Its STARK Proofs, SHARP aggregated proofs, Cairo VM, and native account abstraction form a highly unified ZK native architecture.
Compared with some paths that “add ZK compatibility later,” Starknet was designed around provable computation from the ground up.
This means that as demand grows for:
AI on-chain computation
High frequency blockchain games
Massive scale Web3 applications
Parallel computation
Starknet may have stronger long term scaling potential.
At the same time, STARK technology itself also offers:
No need for a Trusted Setup
Stronger potential quantum resistance
Greater recursive proving capability
These characteristics also explain why Starknet has long received attention at both the academic and infrastructure levels.
However, Starknet also faces clear challenges.
First, Cairo has a higher learning curve, and developer migration is harder than on EVM networks.
Second, much of Ethereum’s current liquidity and many protocols still heavily depend on the EVM compatible ecosystem, so Starknet’s ecosystem expansion has been relatively slower.
In addition, Layer2 itself faces liquidity fragmentation. As more Rollups emerge, users, assets, and protocols may be spread across different networks.
For this reason, Starknet is more like a “long term infrastructure path” than a scaling network that relies on short term ecosystem migration.
Although Starknet, Arbitrum, Optimism, and zkSync are all Ethereum Layer2 networks, their underlying design philosophies differ significantly. Arbitrum and Optimism place greater emphasis on EVM compatibility and ecosystem migration efficiency, while zkSync and Starknet lean more toward the long term scaling path of ZK Rollup.
Starknet stands out for its Cairo VM, STARK Proofs, and native account abstraction architecture. Rather than simply copying Ethereum’s execution environment, Starknet is trying to build a new on-chain execution layer for the future ZK era. Therefore, its competitive focus is not merely TPS, but long term scalable computation capability.
Yes. Starknet is a ZK Rollup network based on STARK Proofs.
Because they assume transactions are valid by default and only re verify transactions when someone submits a challenge.
zkSync places greater emphasis on EVM compatibility, while Starknet focuses more on Cairo’s native ZK architecture.
Cairo is a language designed specifically for provable computation, making it better suited to generating zero knowledge proofs.
Not necessarily. ZK Rollup offers stronger security efficiency, but it also has higher development complexity and greater ecosystem migration difficulty.
Because its underlying architecture is better suited to highly complex computation, native account abstraction, and large scale ZK application expansion.





