
zkSync and Solana Founders Clash on Twitter: zkEVM vs. Solana, Who Represents the Future?
TechFlow Selected TechFlow Selected

zkSync and Solana Founders Clash on Twitter: zkEVM vs. Solana, Who Represents the Future?
Zero-knowledge proofs achieve infinite scalability without compromise.
By rick awsb
The Twitter exchange between the founders of zkSync and Solana is a rare high-level clash between two visionaries. Their understanding of the fundamental logic behind their ecosystems will shape the future of both the EVM and Solana ecosystems. This is essential reading for every investor! Here's a summary:
The discussion began with a tweet from fund manager Justin Bons (founder and CIO of Cyber Capital): "No matter what you think about SOL hitting its scaling limits today, at least SOL is trying, while ETH gave up on scaling long ago. SOL’s actual daily usage has already exceeded 1,000 TPS! Meanwhile, ETH has been stuck at 100 TPS for the past three years — they’ve lost all relevance!"
Alex @gluk64, founder of @zksync, responded with a long thread: "1k TPS is just a drop in the ocean compared to global Web3 demand. The internet cannot rely on a single server. The value layer of the internet cannot depend on one monolithic blockchain, no matter how fast it is or how much decentralization you're willing to sacrifice. The ultimate goal is the zero-knowledge singularity:
⧫ Thousands of permissionless superchains, each capable of thousands of TPS;
⧫ Zero-knowledge proofs of every block across each chain recursively aggregated into one;
⧫ Final settlement completed on the most decentralized, fair, and neutral layer (gm Ethereum!);
Every transaction among millions verified by every user on every smartphone in under one second (if individual users can't verify it, is it even really a blockchain?).
TL;DR: Zero-knowledge enables infinite scalability without compromise (yes, we can solve data availability too in the long run — most data will be hosted by end users).
But what about user experience and liquidity fragmentation?
Users on these chains will seamlessly interact with any contract or user on any other chain within seconds — no additional cost or trust assumptions. Just one wallet confirmation enables instant finality, similar to how we can send an email from any inbox to any other inbox today. Liquidity will flow freely across zk-powered superchains without trusting validators or bridges. Some of these chains may be private and privacy-preserving (operated by banks and financial institutions), yet still interoperate seamlessly with the rest of the ecosystem. This will create network effects for liquidity orders of magnitude greater than anything previously seen on-chain."
User question: Alex, why do you think people at Solana don’t see this? Is it purely economic, or are there other unspoken factors?
Alex’s reply: @Justin_Bons and @aeyakovenko (Solana co-founder), what are your thoughts? "Let’s set aside tribalism and strengthen each other’s arguments. I deeply respect Solana’s thesis: pushing the boundaries of what a single synchronized blockchain engine can handle. Its innovations are impressive, especially in parallel execution and native fee markets. These are things all Layer 2s must adopt. There's truth in the concern that fragmented L2s could lead to fractured UX and liquidity. We'll start with independent, infinitely scalable zk-based L2 ecosystems. Initially, zkSync’s superchains will be infinitely scalable and interoperable among themselves, but not with Polygon or Scroll. But once one zk ecosystem succeeds, that’s enough to realize the vision. Eventually, we might converge on a single L2 bridging contract on Ethereum that connects all solutions."
Solana co-founder Toly joins the conversation, replying to Alex: "ZKPs are indeed great! But they don’t solve database hotspots. If they did, there would be around $100 billion in database revenue up for grabs. They also don’t make information propagate faster globally. The two problems Solana is focused on are synchronizing state at the speed of light and handling as many concurrent hotspots as possible within a single atomic state machine. If ZKPs help solve those, Solana will use them. High TPS is just a side effect of efficient channel utilization — not the goal."
Alex replies: "You didn’t strengthen my argument. Yes, you can build an efficient database state sync engine that handles 1,000,000 TPS. But how should users of such a system verify it? Synchronously processing 1M TPS with ZK proofs is infeasible. Asynchronous processing, however, poses no problem. Verification time: <1 second."
Toly replies: Run a full node. Those who derive more value than the cost of running a full node will do so.
Alex replies: A full node handling 1M TPS would require a computing cluster (massive computational power). Thanks, but I’d rather verify ZK proofs on my phone.
Toly replies: 1 million TPS might require fewer than 16 cores. Verifying ZK proofs on a phone is indeed great. But as I said, I care about maximizing concurrent hotspots and synchronizing all state at the speed of light. Either way, this is a high-bandwidth, highly available system.
Alex replies: Claiming '1 million TPS on 16 cores' is extremely superficial when Solana’s current peak TPS is only around 1,000. And in real-world usage at 1M TPS, how many petabytes of state would I need to keep in RAM to sustain that speed?
Toly replies: Transactions can consume more or fewer compute units. The system only needs to hold in RAM the amount of state matching what it processes concurrently. Load 64k transactions processed across 16 cores — using 10MB of state, less than 1GB total. What exactly are we arguing about? Solana is the most efficient implementation of a globally synchronized, atomic, single-state machine. If ZK helps with that, it’ll use it. The system exists for its functionality. If a ZK system can’t perform that specific task, it doesn’t matter if it handles 10M TPS. Functional overlap with other systems is irrelevant. Users will choose the solution most effective for them.
Alex replies: My argument is this: if the most efficient state-sync system caps out around 1,000 TPS, then you absolutely need zero-knowledge proofs to achieve truly globally verifiable computation at scale — through parallelized proving and recursive proof aggregation. I challenge claims of significantly higher throughput that impose unrealistic requirements on users running full nodes. Another user asked: If zkSync doesn’t sustainably reach 1,000 TPS over any 48-hour window in 2024 while using ETH L1 for data availability, what then?
Alex replies: @zksync — a single ZK Stack superchain instance — sustained 60 TPS during the inscription craze, surpassing any other L2, peaking at 200 TPS. Today, deploying just four additional ZK Stack superchains would get you to 1,000 TPS.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














