Ethereum rollups provide an offchain, asynchronous process for ordering and executing Ethereum transactions that runs parallel to Ethereum consensus. The separation and parallelization of functions opens a wide design/problem space for developers
I’m interested in exploring the rollup design space--in particular the problems rollup operators are encountering. The goal of this blog post is to maintain an ongoing list of these problems, along with ideas for potential solutions.
The rollup operator is the rollup sequencer, prover (if ZK), and full nodes, collectively. A single rollup can have multiple operators.
By design rollups outsource consensus to Ethereum. The rollup operator has no ability of its own to get consensus on the validity of updated chain state.
Rollups have operational costs. Some costs are fixed. Some costs are variable and scale along with tx volume. An example of a variable cost is consensus fees paid to Ethereum.
The operator collects fees from individual rollup user transactions, and uses the funds to pay for total operating costs.
Users can pay priority fees to get better service from the rollup.
Rollup operators cannot easily steal user funds. This, as well as competition, may lessen credible neutrality requirements.
Fixed
Server/infrastructure costs
Salaries
Variable
Transaction commitment costs
Data availability costs
Proof generation costs (if ZK rollup)
There is a timing mismatch between when the operator collects fees from individual user transactions and when the chain operator pays operation costs
Problem validation:
Rollup transaction fees are in part determined by estimating future prices of variable operating costs at transaction time. Estimated prices may be materially different than actual prices. Any divergence between actuals and estimates is a cost to the operator.
Potential solutions:
Fee estimation
Operation cost denomination may be different from the denomination of fees collected from user transactions.
Problem validation:
If a currency mismatch exists between fees and operating costs, then there can be no guarantee the amount of fees collected at transaction time will be sufficient to pay for operating costs, as the relationship between two different currencies is continuously changing.
In order to remain credibly neutral, the rollup operator offers publicly available interfaces that do not require permissions. A public interface exposes the chain to potential DoS attacks.
Problem validation:
Without a permission policy, it is trivially easy for an attacker to flood the chain with garbage transactions that eventually overwhelm the full nodes. The network will become unusable. This can happen even with ill defined transaction fee mechanisms.
Solution:
This problem is solved by the chain’s transaction fee mechanism. Also, the sequencer can help filter out garbage transactions; although this is not necessary for the chain to function properly.
All accounts transact on the same fee curve. Spam accounts live on the same fee curve as a casual user who is using DeFi products to manage their finances.
Problem validation:
In order to protect the chain from sybil attackers, we cannot distinguish between the variety of user profiles. Thus, blockchain transaction fee mechanisms ignore user willingness and propensity to pay. This may disadvantage casual users, and benefit professional users.
Potential solution:
Note, real problems around sybil must be solved for outbox base fees to be viable.
What cost premiums would rollup operators pay to know their costs at tx time?
Can operational costs be better estimated at tx time?
How detailed is rollup operator cost accounting?
Do rollup operators need to charge at cost for every user tx?
What information do sequencer’s know about the users that are sending txs to its endpoint?
What transaction fee mechanism modifications would provide more user and developer benefit while maintaining the chain’s proper functioning and credibly neutrality?