Why I am not optimistic about Based Rollup? Is the expansion roadmap wrong?

Author: Potuz, Developer Source: X, @potuz_eth Translation: Shan Ouba, Golden Finance

In the current situation, I am quite bearish on the rollup scheme based on on-chain data, and I think L2 preconfirmations are nothing more than castles in the air (let's put it that way). But I think the rollup vision based on on-chain data is correct and is nothing more than an unattainable dream. This brief discussion below will explain why.

People complain about the user experience (UX) and liquidity fragmentation of rollups. They are right. L2 is operated by profit-seeking companies, and even if these companies are fully aligned with Ethereum and sincerely seek to expand L1, they will be incentivized to capture activity. They want Uniswap to run on their L2, and they want fast access to L1 state so that users have a better experience during the bridge process. They can even have different components that interoperate well with each other as long as you don't leave L2. Think Arbitrum's Orbit chain or Optimism's Superchain.

But rollups shouldn't need to drive activity, they should only drive execution. They shouldn't be where people do Uniswap trades, Uniswap should send intensive computations to rollups, but the actual activity (and its assets) should stay on L1.

In a sense, rollup should just be a coprocessor for L1, and L1 can move some computations that don't require atomicity and allow slightly weaker security to rollup (either trusting a zero-knowledge proof system or trusting the 1/N assumption of the validator). In this hypothetical world, users would send transactions on L1, their ETH in exchange for pixelated monkey JPEGs or whatever, and any computation would be done on some L2, but both the ETH and the monkey would stay on L1.

In this hypothetical world, L1 wants fast access to L2 state, not the other way around. It wants to get callbacks from transactions on L2. It wants to have special opcodes to trigger execution on L2 (yes, this inevitably leads to a rigid rollup scheme). Flashbot’s SUAVE vision isn’t far off from this (but requires sidechains, some trusted execution environments (TEEs), and Intel’s trust assumptions). And, if anything, on-chain rollups seem more compatible with this vision than general-purpose rollups that pursue activity.

I’d be more bullish on an on-chain rollup project if it publicly built an L1 coprocessor, and I’d even temporarily accept the lie about decentralization (all pre-confirmation-based designs I’ve seen are worse than centralized trusted sorters).