Decentralizing Credit 203

towards an ecology of settlement

This is part of a series of articles on experimental or research phase topics, especially scaling. For an introduction to the Ethereum Credit Guild, start here.

I recently posted about the idea of “rolling up” the state of Ethereum, not into a monolithic bundle like Optimism or Arbitrum, but on a per-user or per-contract basis. I call these state blobs, pieces of state that can be updated in isolation according to their own rules, interact with other blobs, combine with other blobs, or separate into more blobs. They are similar to UTXOs, but more general.

Each state blob can have on its own rules for proposer selection, challenge period duration, and so on. The basic model is a “based optimistic rollup” where anyone who posts a proposer bond to a shared bridge/staking contract can propose state updates, and likewise can submit challenges to other proposers, and where the loser of a challenge is slashed.

Dynamic Time to Finality

Ethereum throughput is rivalrous. In a rollup-centric future where L1 is primarily used for final settlement rather than transaction execution, we can expect that the costs of settlement will increase during periods of higher volatility, as more frequent arbitrage occurs among rollups or between rollups and centralized exchanges.

Some prior discussion has focused on base layer censorship risk — validators colluding to exclude valid L2 proposer transactions. I consider this danger negligible, and am much more concerned with L2 proposer themselves performing an attack. That said, this article and that linked prior introduce two highly useful concepts:

• the size of bond required from a proposer need not be the same for every use case

• the challenge period can be different for different parts of the state

What’s more, neither of these parameters need be constant for any given piece of the state, whether a user-account or a stateful contract. This opens up some interesting possibilities:

• when gas is expensive, delay finality to ensure it is possible for an invalid state transition to be challenged cost effectively

• when an urgent operation needs to be performed, like liquidation, allow faster finality with a larger proposer bond

We can take it one step weirder if we remember that state blobs can be combined and separated. This means that two rollups which have separate state roots (bytes32 hashes) and finality rules can merge into one rollup with a single state root and finality rule. One way to think of it is bridging the entire rollup to another rollup.

The result is a “finality preference curve” where an individual user can specify a complex preference set such as :

• so long as baseFee < X, maintain challenge period of 1 hr

• when baseFee > X, increase challenge period to 1 day

• proposerBondMin = baseFee * Z

And then all the users and contracts with the same preference can be grouped in a “tick”, a la Uniswap v3. The finality preference curve itself can and should be rolled up, not computed on mainnet, and the proposer can reference this data when making state updates on a given rollup.

Conclusion

I believe that an immutable and non extractive “rules hub” as illustrated here would be a useful building block for applications on Ethereum, in a similar vein to Eigenlayer restaking. Next time, we’ll dive into more concrete examples regarding lending, trading, and finality in the Ethereum Credit Guild context.