Decentralizing Credit 201
on latency, settlement, and trust
Start here with the “101” 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 “201” series about the questions under active research that will help us build a more resilient and scalable decentralized credit system.
Today’s article is about scaling. I’ve been chewing on this topics for the better part of a year since Dan Elitzer wrote this article which got me thinking in the direction that led here.
Today’s rollups are scary
Creating an EVM compatible optimistic rollup is a complicated task to get right even once, and is also a moving target, since the EVM is being continuously updated. As a result, both Optimism and Arbitrum are optimized for upgradeability. They are controlled not by token governance, but by a small set of multisig signers. Optimism has a multisig composed of anonymous individuals that can upgrade the protocol with no delays, and Arbitrum is little better. Furthermore, neither has a decentralized mechanism for proposer (sequencer) selection, which is instead subject to a whitelist under the control of the aforementioned multisig.
We greatly desire to scale the ECG to bring user costs down to a minimal level. Unfortunately, while we may hope that the signer sets of today’s rollups are trustworthy, they pose an unacceptable risk as the foundation for an immutable credit system. A smart contract system is only as immutable as the layer it lives on.
Keeping it simple
We do not need an EVM compatible rollup to scale the mechanisms of the ECG. Instead, we can create an application specific rollup, or rollapp, tailored to suit the needs of the protocol, which are much simpler than a Turing complete system such as the EVM. The resulting rollapp contracts can be immutable, since their scope is clearly defined.
From the point of view of the ECG, the rollapp sequencer should be authorized to post certain state transition information to mainnet, such as changes in the circulating CREDIT supply, bad debt or interest accrued from lending terms, adjustments in gauge votes that occur on the rollapp, and so on, and also to read this data in from mainnet. This is a simplification, but the state that exists on the rollup is more or less the following. The bolded parameters should be synced between the rollapp and mainnet directly with each state transition, the others can be reported to mainnet only through the usual rollup mechanism of state root + calldata:
total circulating CREDIT
total CREDIT borrowed
debtDiscountRate
set of lending terms and their current available debt
outstanding loans
open auctions
users, their balances, and any gauge votes
current gauge weights
The transactions included in the current block including signatures
Finding our limits
What is it that actually constrains rollup throughput? Are rollups (or rollapps) rivalrous in their consumption of mainnet resources? How low can we push transaction fees?
The cost of posting calldata to Ethereum will soon come down with introduction of a blobspace market via EIP-4844. The maximum throughput of all rollups and rollaps will be basically constrained by the available amount of blobspace. In the early period, we can expect that blobspace will not be strongly rivalrous, and it will always be possible to reliably include transactions at reasonable cost. In the long run, demand from rollups may drive the cost of blobspace back up, but it will still be cheaper than paying the old way.
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. Part of this cost is fixed (the state root), the rest grows based on the amount of state change happening in the rollup. This means that more transactions will lead to a slightly lower per transaction cost. Less frequent sequencer updates mean lower costs, but higher latency is generally bad for users in that prices on the rollup are more likely to deviate from those elsewhere in a system with infrequent updates, which leaks value from users.
We suspect the cost of blobspace will be variable, and so the optimal frequency of sequencer updates will also be variable. The latter will depend both on the cost of blobspace and the rollup’s TVL. A large rollup will naturally want updates as close to every block as possible, and may raise its transaction fees to account for an upward drift in blobspace costs, while a niche rollapp, let’s say for the store of an onchain game, might be content to have state transitions occur on mainnet only once an hour during periods when blobspace is expensive, but otherwise prefer once every ten minutes.
Iterative Immutability > Temporary Trust
There are promising research directions to further improve rollup scalability, for example, using Verkle Trees instead of Merkle Trees, that would require either an upgrade or a redeployment of existing systems. The ECG design can optimize for voluntary migration to a new system through a mechanism on mainnet to assign or reduce a CREDIT debt limit to a rollapp. This allows individuals to choose where to mint or hold CREDIT, and also allows for the onboarding of new system components without any code changes to the existing protocol. Introducing a new rollap would be similar to introducing a new category of lending term with a special liquidation rule or a new denomination of CREDIT token.
If GUILD holders can assign debt limits to a rollapp of their choice, we can also picture the creation of execution environments with arbitrary configurations to support various user categories. For example, a “slow and cheap” rollapp that is optimized for account sizes below $1000 with low leverage available, or a “high performance” rollapp that is exclusively dedicated to ETH lending terms with a full order book for CREDIT/ETH.
Proposer Selection and MEV
The proposer, also known as a sequencer, is the entity who posts the next rollup or rollapp block to mainnet. Today’s rollups have centralized, trusted sequencers. Our proposed solution to sequencer selection is by auction, where the bids are in CREDIT and the proceeds are burnt. There is no need for GUILD holders, but a sequencer bond in the form of CREDIT can be considered on top of the auction bid to protect against griefing, and the same is required to prevent malicious challenges to state transitions. After minimizing MEV with efficient mechanisms, capturing what remains at the protocol level will lead to better outcomes for lenders, borrowers, and GUILD holders alike.
tldr
Unlike the 101 series, I can’t promise what topic the next 201 research article will focus on, only that it will be interesting to me. I suspect it will have to do with auctions, since we have been debating the right configuration for the AuctionHouse and whether this should be part of the lending term parameters, or standardized.
Comments are greatly welcomed — I’m still scratching my head about latency optimization.
Until next time,
Kirk