Decentralizing Credit 202
stateless optimistic rollups
Start here with the “100” series if you’re looking for an introduction to the Ethereum Credit Guild and why we’re so fired up about scaling lending without oracles. This article, and the rest in the “200” series about the questions under active research that will help us build a more resilient and scalable decentralized credit system. Scaling is a core part of the ECG, not an afterthought or something to be left to others.
Even blobspace has its limits
Any rollup faces a similar set of constraints to Ethereum itself. There is a tradeoff between the number of nodes who can effectively participate in the network and throughput. If requirements are too high, not enough participants will be able to act as sequencers to post valid state transitions and challenge invalid ones posted by others. Users who can’t run their own node must place their trust in someone who does, and some amount of value is inevitably leaked in this process. On the other hand, more throughput means lower transaction costs for users.
This is one of many reasons that we’re skeptical of monolithic rollups, as there is unlikely to be a single fixed correct point in the consensus parameter space, but rather a varying economic optimum for each user. Can a rollup be more like a Uniswap pool, where many exist within the same application?
Last time, we considered why a dedicated “rollapp” rather than a general purpose rollup is beneficial for making an immutable yet scalable system. We noted there :
The minimum transaction cost for a rollup, then, is the cost of committing the state root update to mainnet, and the rest of the state data to blobspace.
This is true for conventional optimistic rollups and for the rollapp we proposed, but there is a way to push things further. Why does a rollup need to post the state change as calldata, which will soon be cheaper thanks to EIP-4844 but still costly? Rollups like Arbitrum and Optimism assumes user do not have access to their own state data, and thus cannot process withdrawals or act as a sequencer unless the data is accessible from an Ethereum node, if not from inside the EVM. If the data were not posted to L1, the sequencer could deny access to data to users and take funds hostage.
Bring your own blob
In the narrow context of a rollapp, it is perhaps clearer how we can get around this problem. Instead of using Ethereum as data availability layer to store blobspace, we can define a protocol for users to provide sequencer nodes with the necessary data they need to process transactions, while still using Ethereum to process fraud proofs. We can submit only a state root to mainnet, but not submit anything to calldata.
As in the previous article, we propose electing a sequencer on mainnet via auction. A participant in the protocol should observe the following rules:
If a sequencer proposes a block, they will broadcast the relevant state data to other peer nodes, using a heuristic like cumulative mainnet gas expenditure as a threshold to limit the network size to a reasonable number of legitimate peers, and cutting off and blacklisting peers that act maliciously
if a node witnesses a state update onchain but does not receive the relevant state data, it will attempt to request it from its peers
if it does not receive this data before the end of the challenge period, it will initiate a challenge which works the same as a normal interactive fraud proof
It is important that on mainnet, in the case of a successful challenge, the defender slashed, but in an unsuccessful challenge, while the challenger can pay some cost, it should still be less than what the defender bid in the proposer auction. This is necessary so that a node cannot grief the network by submitting a valid state transition but withholding the data and forcing a failed challenge. With this setup it encourages all nodes to challenge invalid state transitions, yet it is costly to DDoS the network by withholding data and forcing honest nodes to challenge and demand data. The only other difference between Arbitrum fraud proofs is that the rollapp state is encoded differently in the state root.
Be Your Own Data Availability Layer
We observe that users have a strong incentive to verify the correctness of state changes to their own accounts, and also are the ones who should pay the cost for the storage of their own data. To facilitate this, the “leaf” nodes in the state tree will be the hash of a user account.
Users should run light nodes. They only need to store their own transaction history on the rollapp. When they submit a transaction, they will provide their state history to the sequencer node along with the signed transaction. Whenever a state transition occurs on the rollapp, they will act the same as a full node, requesting data from peers. The difference is that they will only request the data related to their own account(s), which, if a Verkle tree is used, is only a small portion of the total state, keeping networking overhead and compute costs to verify the state change to a minimum.
If either no node can provide them with the data needed to validate any changes to their own account(s), or confirm that there were no changes to their account(s) in that block, they will challenge the sequencer.
How low can you go?
I believe this is the lowest it will be possible to push transaction fees while maintaining the security guarantees of Ethereum L1. While it’s impossible to know for sure the future costs of blobspace, what’s key is that this reduces the L1 gas fee cost of rollup state changes from proportional to the size of the rollup state, to a fixed cost of submitting the state root. I would greatly appreciate feedback about this model, which I am calling a supercalifragilisticexpialidocious *ahem*, a stateless optimistic rollup. Unsurprisingly, this term originates outside of Ethereum, though the design it references is not identical to the one presented here. DeFi developers would do well to look carefully at Cosmos, Celestia, and similar systems to understand the ins and outs of data availability and consensus.
I promise, we’ll go into auctions soon. In the meantime, I’m always happy to talk shop in the comments or on Twitter.