This blogpost outlines the choices that a dapp inevitably faces if they decide to venture into the rollups ecosystem. It showcases the options and changes it has with its current limitations. Lastly, it examines a possible improvement on the design in order to allow the dapps to enjoy the benefits of rollups without sacrificing security, decentralisation or their value offering.

For this post we will use a fictional DeFi application called BBVE. Any resemblance with real dapps is purely coincidental.

Our example dapp, BBVE, is widely successful in the Ethereum L1 space. It has managed to gain vast amount of “treasures” for its liquidity pools and many many thousands of users. It is enjoying the fruits of the labour.

Occasionally BBVE notices, that some users start parting ways and moving to other services offering better cost and speeds in the uncharted territory of the rollups. BBVE has the winning recipe (pun intended) and reputation, so moving into the rollups space will mean retaining users, getting new users, better efficiencies and even further success. It does not take much deliberation to decide to venture there.

BBVE has two main competing options on how to get into the rollups space. The choice between the two we jokingly call “the cutlery wars”.

Option 1 we call the “Fork” approach. Forking enables BBVE to replicate itself into any rollup and offer its service there. Option 2 we call the “Spoon” approach - modify itself into a single homogenous app across many rollups. In the next sections we will examine both approaches.

Forking is a straightforward approach and is what most multi-chain dapps have opted to do. You can see many instances of one app across different rollups.

The massive adoption of the forking approach seams sensible and less risky for the dapps. First, its safe - BBVE does not need to modify its codebase at all, but rather, deploy it again. Second, with the codebase already complete, moving into any rollup is quick. BBVE can continue doing everything it has been doing in L1 inside any rollup, right away, just by replicating its infrastructure.

On the surface, forking looks brilliant, but it does not come without its drawbacks. Forking is fragmentation. Fragmentation naturally lowers security, hinders UX and actually increases operating costs proportionally.

While BBVE can enjoy security and offer great value in L1 due to its massive liquidity pools, each of the new forks has its own liquidity pools - much smaller pools. Smaller pools can result in bigger slippages or requirements for higher commission fees. Downstream, this impacts the users and hinders the value proposition of BBVE.

Furthermore, the user experience for BBVE now worsens. If the user wants to use another instance of BBVE, they now need to move funds via bridges. This introduces complexity and sometimes might even be impossible - for example if the user first needs to repay a loan before moving. Users can get locked into a single fork, with its own isolated accounting and weakened security. Moreover, BBVE now needs to show the holdings of the user in various rollups, thus requiring complications in the user interface.

Last but not least, costs for running BBVE increase proportionally with each new fork. All the infrastructure maintained for L1 now needs to be replicated and maintained for the latest fork.

Based on the liquidity of the ETH/USDC Pair on UniswapV3 on Ethereum, Arbitrum, Polygon and Optimism we can derive that loss from swaps executed on less liquid instances of Uniswap ETH/USDC Pair (L2s/Polygon) are estimated at $14.38m/year [1]. This number is for a single pair and a single dApp within the ecosystem. As we can imagine, inefficiencies due to dApp fragmentation lead to hundreds of millions per year.

Spooning is a much harder approach that few have attempted. It has been mostly adopted by wallets or wallet-like dapps, where the control over where and how transactions are sent can be hidden under the hood.

For a dapp to morph into a homogenous app across all integrated rollups, it is required to:

The last requirement is a major systemic risk for BBVE. It requires a completely new set of trust assumptions spanning across various rollups. This is why we have not seen any actual proper homogenous rollup dApps, but rather just very small “tea spoons”.

One notable example of a “tea spoon” is the xSwap feature of Sushiswap. It allows users to use the same user interface to directly swap from one network to another.

Tea spoons use existing infrastructure, like bridges, and ask the user to move its liquidity into the homebase rollup. Bridges, however, are notorious for being the biggest attack surfaces in all the blockchain space. Furthermore, liquidity is not the only data that needs to pass between rollups. Arbitrary data would be needed in the homebase - for example, deposits and withdrawals are needed in order for accounting to be correct. Very few services can offer this arbitrary message passing and all of them have at least to some degree similar trust assumptions and security implications as bridges.

While on the surface this sounds like the upper ceiling of spooning, and the tombstone of the approach, we can look deeper into it and try to imagine an actual spoon, that is a viable (if not better) choice for BBVE.

In order for an actual spoon to exist, we need to imagine an infrastructure and a system that does not introduce new trust assumptions, security issues and UX hurdles. It needs to be easy to integrate from a smart contract and client-side standpoint.

Firstly, such an infrastructure would need to be able to pass messages between rollups. This process needs to be as close to the security level of L1 as possible in order for BBVE to trust it. Much like zkRollups are deriving its security from L1, without introducing new trust assumptions, ZK-based message passing is a viable solution here. A ZK-based approach would involve creating ZK proofs and crypto-economical incentives that will guarantee safe, truthful and quick data relay.

Secondly, such an infrastructure needs to be extremely easy to integrate for BBVE. It should require making minimal or no changes in the existing codebase. The ideal minimal change would be migrating from accounting based on msg.sender to accounting based on the sender of the data coming from another rollup. Incoming standards such as Account Abstraction will prove very useful for such homogenous dApps.

Thirdly, the infrastructure should enable BBVE costs to scale logarithmically with the addition of new supported rollups. Ideally, adding new rollups should reuse existing infrastructure and the homebase accounting should work out of the box.

Lastly, the infrastructure should hide the cross-rollup complexities from the user, thus maintaining a similar UX to a single rollup/network app. This means that certain interactions (f.e. data receipt) are outsourced to the dApp or other parties and are not required of the user to do (as is sometimes the case with bridging). A practical example of this can be using third-party relayers to facilitate the transfers of funds when an interaction happens in such a homogenous dApp.

Given an infrastructure that meets the four requirements above, spoons can actually become a superior approach for migrating dApps. Spoons won't cause liquidity or user fragmentation. Spoons won't deter security or introduce new major trust assumptions. Spoons won't incur costs that scale linearly to the supported rollups. Spoons will allow users to have a unified experience of the dApp regardless of the roll-up they are using.

The rollup cutlery wars are an interesting conundrum for the dApps - to fork, meaning create copy instances on every newly adopted rollup, or to spoon, meaning try to be a homogeneous app across many rollups.

While forks are currently the practical and safe choice, they are also ripe for disruption and introduce significant risks. Spoons have the potential to be a superior solution but are still theoretical due to the complex nature of the infrastructure needed to support them. Only the most capable and resourceful dApps have decided to go with that approach and the barrier is high at the moment.

We believe that the infrastructure for spoons is possible and will come to reality soon.