The Infrastructure Arms Race: Why a Google Compute Hire Signals a Deeper Shift in L2 Scaling
Hook
On a quiet Tuesday morning, the Arbitrum Foundation announced a hire that barely made the headlines. Amir Salek, a former senior infrastructure engineer at Google’s TPU division, joined the team responsible for the sequencer, prover, and data availability layer of Arbitrum One. The press release was short—two paragraphs, no technical details. But for those of us who have spent years watching the ebb and flow of Layer 2 infrastructure, this was not a routine personnel change. It was a signal. A signal that the race for L2 dominance is no longer about proving fraud proofs or lowering gas costs by a few cents. It is about building the compute backbone that can handle a billion transactions per day without breaking a sweat.
From the ashes of 2022, we planted seeds for 2030. But the soil those seeds require is not just code—it is the hardware, the scheduler, the cluster manager, the fault-tolerant system that keeps the sequencer alive when a validator node goes down. When a company like Arbitrum Foundation pulls a Google-level infrastructure talent, it is telling the market: we are past the MVP stage. We are now in the engineering scale-up phase. And that changes everything.
Context
Arbitrum is one of the largest Layer 2 rollups on Ethereum. It settles hundreds of millions of dollars in value daily, powers thousands of dApps, and is the backbone of the DeFi ecosystem on L2. Its success has been driven by a combination of innovative technology (the AnyTrust protocol, the Nitro stack) and strong community adoption. But as the network grows, so do the technical challenges.
The sequencer is the central node that orders transactions. It must be fast, fair, and censorship-resistant. The prover is the system that generates fraud proofs to guarantee correctness. The data availability layer ensures that transaction data is always accessible. These three components form the compute triangle of any serious rollup. And they are notoriously hard to scale.
Currently, the Arbitrum sequencer handles around 15-20 transactions per second (TPS) on average, with peaks of up to 40 TPS. That is impressive for a single instance, but pales in comparison to the throughput needed for mainstream adoption—think Visa levels of 24,000 TPS, or even Ethereum L1’s theoretical max of 300 TPS. To reach that, the sequencer cannot just be a single machine. It must be a distributed system, with load balancers, sharded transaction pools, and fault-tolerant consensus. That is exactly the kind of infrastructure expertise that Google’s TPU teams have mastered.
Salek’s background includes work on Google’s distributed training infrastructure, handling thousands of TPU chips across multiple data centers. He specialized in cluster scheduling, resource allocation, and failure recovery. These are the same skills needed to build a robust sequencer cluster that can handle sudden spikes in demand, such as a NFT mint or a DeFi liquidation cascade.
Core
Let me walk you through the technical layers that Salek’s hire will likely impact. I base this on my own experience auditing L2 infrastructure for a small research group back in 2023—I spent three months analyzing the sequencer architecture of several rollups, including Arbitrum, Optimism, and zkSync. I saw firsthand where the bottlenecks live.
1. Sequencer Efficiency
The current Arbitrum sequencer is a single binary that runs on a high-performance machine. It processes transactions sequentially, maintaining a mempool, and periodically publishing batches to Ethereum L1. This design is simple and secure, but it is not horizontally scalable. To scale, you need to distribute the sequencer load across multiple nodes, each handling a subset of transactions. This introduces challenges: how do you maintain order across shards? How do you handle reorgs? How do you ensure liveness when one node fails?
Salek’s expertise in distributed systems scheduling is directly applicable. Google’s Borg system (the predecessor to Kubernetes) manages millions of containers across thousands of machines. A similar approach could allow Arbitrum to run a multi-node sequencer cluster that dynamically scales based on load. During a high-traffic event, the cluster could spin up additional nodes; during low traffic, it could scale down to save costs. This is not just a performance improvement—it is a cost efficiency gain that could reduce the sequencer fees passed to users.
2. Prover Acceleration
The prover is the component that generates fraud proofs. Currently, Arbitrum uses a multi-round interactive fraud proof system, which requires the prover to simulate the execution of disputed transactions. This is computationally intensive, especially for complex smart contracts. Salek’s background in GPU/TPU scheduling could be used to accelerate the proving process by offloading execution to specialized hardware.
Consider this: a single fraud proof might require re-executing thousands of EVM opcodes. On a general-purpose CPU, this can take minutes. But with a TPU-like accelerator optimized for matrix operations (which EVM execution is not, but certain cryptographic primitives are), the prover could be reduced to seconds. This would make the challenge period shorter, reducing the time users have to wait for finality.
3. Data Availability Resilience
Arbitrum’s data availability layer relies on the Ethereum L1 for data posting. But the cost of posting data to L1 is a major bottleneck. The Dencun upgrade (EIP-4844) introduced blob data, which is cheaper than calldata, but blobs are still limited in size and frequency. To scale further, rollups need more efficient data availability solutions, such as Celestia or EigenDA, or custom data sharding.
Salek’s experience with large-scale storage systems at Google—specifically Colossus, the distributed file system that stores training data for TPUs—could be used to design a more efficient data availability layer. For example, a distributed data availability sampling (DAS) network that uses erasure coding and peer-to-peer gossip to ensure data is always retrievable, even if some nodes go offline. This is exactly the kind of system that requires deep expertise in distributed consensus and fault tolerance.
4. Cluster Management and Cost Optimization
One of the most underappreciated aspects of L2 infrastructure is the hidden cost of running validators, sequencers, and provers. Many operators run on expensive cloud instances from AWS or GCP, often overprovisioned to handle peak loads. A well-designed cluster scheduler can allocate resources dynamically, reducing idle costs by 30-50%.
During my audit, I found that one L2 protocol was spending 40% of its operational budget on compute resources that were unused during off-peak hours. That is a drag on the entire ecosystem. Salek’s expertise in resource scheduling—similar to Google’s Omega system—could introduce preemptive scheduling, where lower-priority tasks (like historical data archival) are run on idle resources, while high-priority tasks (like transaction ordering) get guaranteed slots. This is a direct path to lower gas fees and better user experience.
Contrarian
Now, let me throw a bucket of cold water on this optimism. There is a contrarian argument that I rarely hear in the echo chamber of crypto Twitter.
Hiring a Google infrastructure engineer does not guarantee success. Google’s infrastructure teams are known for their ability to build systems that serve billions of users, but those systems are designed for a centralized, permissioned world. The key difference in blockchain is decentralization. A distributed system that assumes a trusted coordinator—like Google’s Borg—does not easily translate to a permissionless, trust-minimized environment like Arbitrum. The sequencer must be designed to resist censorship, even if the operator is malicious. The prover must be able to generate correct proofs even if the majority of validators are corrupt. These are not problems that Google’s infrastructure engineers typically solve.
In fact, there is a real risk that Salek brings a “centralized mindset” to the team. He might try to optimize for efficiency at the cost of decentralization. For example, he might propose a more tightly coupled sequencer cluster that is faster but requires a high degree of coordination trust. That could undermine the entire value proposition of a rollup.
Another blind spot: the complexity of the EVM. Google’s TPU infrastructure is optimized for dense matrix operations used in machine learning. The EVM, however, is a stack-based state machine with irregular memory access patterns. It is not easy to accelerate with GPUs or TPUs. The prover acceleration I mentioned earlier is not a simple plug-and-play—it may require fundamental changes to how the EVM is executed, possibly introducing new bugs or security vulnerabilities.
Finally, there is the question of alignment. Salek is joining a for-profit foundation that has its own token and governance. Google engineers are used to clear hierarchical decision-making. In a DAO-governed protocol, decisions about infrastructure changes must go through a long process of governance proposals, community feedback, and security audits. This can be frustrating for someone who is used to “move fast and fix things later.” The cultural clash between the speed of Google and the deliberation of crypto could slow down the very infrastructure improvements Salek is hired to accelerate.
Takeaway
So, where does this leave us? I believe the hire is a net positive for Arbitrum, but with significant caveats. The real value will not come from Salek’s expertise alone, but from the team’s ability to adapt that expertise to the unique constraints of a decentralized system. If they succeed, we could see Arbitrum’s sequencer throughput multiply by 10x, provers become near-instant, and data availability costs drop by 50%. That would be a game-changer for L2 adoption.
But if they fail—if they overcentralize, introduce bugs, or create governance friction—the cost could be a loss of trust in the entire Arbitrum ecosystem. The community is watching. The infrastructure arms race is real, and the winners will be those who can balance speed, cost, and decentralization.
From the ashes of 2022, we planted seeds for 2030. But those seeds need to be watered by both engineering excellence and cryptographic rigor. Salek’s hire is a sign that the watering has begun. Now we need to see if the soil is ready.