Background

In this post, I propose an extreme way to make Ethereum instances lightweight. I call it the Franchised Sequencer. I’ve pitched it to many of you in the Ethereum community over the past couple of years, but never put pen to paper.

The Franchised Sequencer allows normal apps to run on Ethereum. It stores just a fingerprint of the app’s state on Ethereum. It is private, as many apps prefer to be, but can also be compliant. The Franchised Sequencer posts validity proofs to Ethereum. This means you effectively have an app running lightly on Ethereum, without too much performance cost (except computing proofs, which I admit will be a limiting cost for some apps). You can then ensure that, if the app servers go down, or the app developer starts to misbehave, then a tender can go out to ask someone else to take over the running of the service.

Yesterday I saw several posts pointing to very similar ideas to the Franchised Sequencer, from Sreeram and from Wei Dai, and Nitanshu posted something directionally similar in January, which has finally provoked me to write this down!

After years of piling infra on top of infra, the Ethereum community seems ready to drop its more gothic tendencies, and tap into a performant, responsive Ethereum.

To become ubiquitous, Ethereum needs to become as invisible as TLS, and the Franchised Sequencer is one model to make that happen.

If you just want to get straight to the Franchised Sequencer proposal without motivation, scroll down to the end of the article.

Prerequisite Knowledge: What’s a Sequencer?

Most readers will know what a sequencer is, but here’s an intro to help newcomers.

In this article, I talk a lot about sequencers: a term that’s peculiar to blockchains.

Sequencing essentially means processing, mostly like a computer does.

Blockchains select sequencers at random, block by block: new block, new sequencer. When selected, the sequencer fishes transactions out of the pool of candidate transactions.

As the blockchain doesn’t ‘know’ when a transaction entered the pool, there is nothing to stop the sequencer from ordering those candidate transactions as they like. That’s why they are called a sequencer: they choose the order!

That’s why historically blockchains have sought to decentralise the sequencer: to avoid a single player having power over this crucial process.

Once the sequencer has ordered the transactions, they compute the new state of Ethereum based on these transactions: that is the ‘processing’ bit. They work out how these transactions change peoples’ data, according to the smart contract logic these transactions observe.

In this article I’m going to suggest that, at the application level, a centralised sequencer is often fine, and that dumping the assumption of decentralising this crucial function, we can make enormous gains.

We can bring Ethereum to large universe of Web2 engineers, for whom Ethereum mainnet is prohibitively public and too clunky.

The Stone Computer

“As the Vogon craft screamed through the air, … the ships hung in the sky in much the same way that bricks don’t”

— Hitchhiker’s Guide to the Galaxy, Douglas Adams

Raising for Aztec in 2018 was hard.

Back then we were trying to graft classical assets (loans, bonds) onto Ethereum: that’s where we first saw a need for cryptographic privacy.

In 2018-era Ethereum, the benefits didn’t clearly outweigh the risks. The world had spent centuries shifting away from bearer assets locked in vaults — bond notes, stock certificates — to the softer, error-correcting safety nets of contracts and law. Why would we want to go back?

Yes, Ethereum was clearly the hardest and most durable writing material ever discovered: and magically this new tablet handled bits, the runes of the modern world.

But it was also hostile and unforgiving of error.

Investors intuited these problems almost without looking: in Ethereum they perceived the “Vogon Computer”, a stone CPU in the sky, slow as a Nokia 3310, expensive and indelible, and globally visible — a nightmarish panipticon for compute.

The Little Green Light

In response, we tried to sketch Ethereum in the asymptote: essentially invisible, except for a ‘little green light’ in the corner of your browser that said, ‘welcome to world state, you’re in sync: now read and write to history’.

The good news since 2017 is that ZKPs and optimistic rollups moved us closer to this vision of a softer, less hostile Ethereum.

But we will need to take more liberties to make hooking into Ethereum a ‘no brainer’ for the world’s engineers.

We need to go back to the thing that inspired Vitalik to dream Ethereum into existence in the very first place: the durability of worlds. As he recounted in 2021, when Blizzard shut off his warlock’s favoured spell:

“I cried myself to sleep … I realised what horrors centralised services can bring.”

— Vitalik Buterin, Ethereum

Ethereum and Durable Worlds

I’m not talking about worlds born inside the crypto community: cargo cults whose first populations are united only by financial impulse — guaranteeing that those worlds will dissolve into financial recursion.

I’m talking about worlds people visit for their own sake.

For those worlds, Ethereum unlocks ontology; real existence of digital matter. It supplies a hard and permanent foundation for those worlds: a global paperweight on digital history.

Through Ethereum, worlds can outlive the studios that built them, but to do this, Ethereum needs to be:

• very small (no need to know app state, so long as it verifies / attests to it), but also
• very heavy (high economic security = extreme hardness)

We need just enough Ethereumness to supply dwellers of virtual worlds with a notion of existence, a provable past tense, and an escape hatch if that virtual world starts to deteriorate under centralised control.

Ethereum and the Past Tense

Ethereum can be the natural ground truth for every digital action: you can say “this happened” about something that was only ever electrons. Magic!

Suppose you wish to form a cabal through Discord. You can supply an unforgeable proof about some historical event in that virtual world, popping a proof through a messaging service. Whomever you’re seeking to persuade will know you’re telling a truthful fact about world history.

This grants digital reality a factual superiority over physical reality (where evidence decays). As Arnaud Schenk puts it: “Soon, we will look back at the internet of the early 00’s and be shocked at how shallow and friable it felt.”

Durable Worlds are Coming

This stuff is not theory.

The first durable world of substance (not some coins-and-monkeys economy), attracting users for its own sake, went into beta last month.

The Franchised Sequencer became immediately convincing to me when I visited Hilmar, CEO at Eve Online, in mid 2023 at his London offices. His decision to build his next world on Ethereum was so unlike any other application developer I’d met: it was a practical requirement to give his users some basic digital rights, not a cargo cult.

My three takeaways were:

1. Eve users trust Eve the company day-to-day: Players are used to Eve knowing their data, handling it, executing the logic, and behaving well. Eve created the world; if Eve starts to behave badly, users will leave. Eve is aligned. Players are relaxed day-to-day: they just need to know the game can outlast the company.
2. Eve is Generational: Few games have shown such durable loyalty as Eve. Players who joined in the 1990s aged 20-30 are now 50-60. A generational asset handover was approaching. Players had established social capital in these worlds: in some cases, perhaps more than in physical reality. But with no formal title or property rights, these loyal players had nothing to pass to the next generation.
3. Eve is a Developing Economy with Perfect Collateral: Whilst Eve might benefit from financial markets, financial markets are not the business of Eve. It is better for games such as Eve to allow others to experiment with financial primitives such as lending, leasing and so on. Eve is the very definition of an emerging economy: a world people are already living in and want to occupy for its own sake, but lacking market structures. Eve is the natural economy for Ethereum to win. Its utility assets (ships, weaponry, etc) are born digital: defined and governed by software. They’re the perfect collateral for on-chain credit systems. Just as physical assets are bad collateral for Ethereum contracts, digital assets are bad assets for legal contracts. On-chain credit finally has a robust source of collateral.

It is for cases such as Eve where the Franchised Sequencer could be most appealing.

The Franchised Sequencer: Making Ethereum as Light as the Cloud

The franchised sequencer is almost identical to a rail franchise.

Rail is naturally a monopoly sport: just like “world-running” (running the servers for a multi-player computer game).

To avoid the obvious rent extraction and dilapidation risks of a private monopoly, rail franchises create some of the effects of competition, through a tender process that runs every few years. If the incumbent starts to behave badly, delivers bad service, or charges exorbitant fees, they will lose the franchise.

The franchised sequencer is almost the same thing for Ethereum worlds: letting the operators of virtual worlds (games or other applications) get on with running the servers day-to-day, but placing restrictions on their powers via Ethereum.

If the world builder misbehaves or their quality of service declines, then over time they can have their right to run the game revoked.

1. Defining the Franchised Sequencer

Here’s how the franchised sequencer might look:

• A simple, single-sequencer Ethereum instance: A single, centralised sequencer runs the servers. It’s a ‘validium’ — that is, they supply proofs of each update to the application.
• It is private: App state is encrypted. Likely it is encrypted through threshold encryption, so that if the sequencer disappears, the data can be recovered by some majority of guardians, and the world can be rebooted through a new franchisee.
• Data availability: The app can safeguard against the sequencer running away, using e.g. Eigenlayer or Celestia to store its encrypted state. For most applications, 5-10x closer to AWS levels of replication is probably sensible.

2. The Guarantees of a Franchised Sequencer

The franchised sequencer gives strong guarantees that if the sequencer disappears, another bidder can step into their shoes:

• Open Source All Code: Once an application with network effects has reasonable traction, the application should be safe to open source all code: front end, back end, everything. The network is the asset, not the code.
• Franchise Retender: If the sequencer misbehaves — going offline for long periods, raising fees, or ordering transactions in malicious ways, the users need to be able to call a vote to depose them, and allow other app-runners to tender an offer to run the game.
  • Note: the original game maker can probably enshrine a royalty fee at the base layer (perhaps a cut on transactions on in-game assets), which if not too high, might enable it to receive IP fees in acknowledgment of its role as the primogenitor of the world, even if it loses its own franchise at a later date.
• Voting Weights: You could weight votes by allocating more voting power to the most active users, and weighting by the recency of that user’s activity e.g. a Boltzman-type sum. The true stakeholders in the game would have the most influence in which franchisee takes charge of the next era in the game.
• Hostile Takeover Defences: The risk is that hostile takeovers could be executed by swarming the system with new players. In such an instance, it’s likely that forks, rather than voting schemas, would supply the last-ditch defence.

3. Other Benefits

The franchised sequencer has some very appealing consequences for:

• Interactive Privacy: The centralised rollup can limitlessly allow user state to interact, handling battles and wars in a performant manner
• Provable Facts: Virtual worlds written to Ethereum have a past tense. Users can make concrete proofs about things they did in their virtual universe, and supply proofs
• Liability Limitation: The app developer will love this — for example, gamemakers can ensure they’re not liable for peoples’ money, not taking deposits, which for them is a risk
• Compliance: The private relayer is now squarely responsible for compliance. This eliminates the compliance risks of other types of private computation, which could make it an easier route to market.
  • It seems Lyron Koh Ting Keh has been thinking about a soft landing for on-chain privacy: read his sketch of a chaperoned version of privacy here.

4. The Paired Business, the Trust Residue, and Private Compute

We always urged Geometry founders building protocols to seek out the ‘paired business’: the business for which the protocol is a go-to-market advantage.

Crypto blew up the status of the protocol, which came to be viewed as the end and not the means:

The charitable explanation is that ZK rollup systems dwarf the complexity of building SSL in the early days: so it looks more like a construction project and less like a feature.

The less charitable explanation is that the reinforcement learning model of the crypto community was broken by fast money: beyond the deployment horizon was instant gold, and after gold you need no product. I’ll dwell on this in a later post.

Cryptography teams forget that their mighty infrastructure is not an economic engine: it should become as invisible and ubiquitous as TLS.

So in crypto, everyone is building NextJS, but neglecting to build Vercel.

Seek THE TRUST RESIDUE

Where is this paired business then?

A reasonable place to search is in the ‘trust residue’ around your protocol: what are trustful services that take this protocol to an end market, where trust simply cannot be extinguished?

Users are willing to pay up for services they’re dependent on (SaaS). Users will often tolerate significant margin, for good services to stay alive and flourish.

EXAMPLE 1: Virtual Worlds

For durable worlds, a trust residue remains between the world operator and the user:

• Improving the texture and content of worlds
• Staying online, avoiding outages
• Maintaining user privacy
• Sequencing fairly

The builder of the virtual world is regulated by a franchised sequencer, ensuring its fair behaviour, but these trust residues above cannot easily be removed. In those remaining trust assumptions, the world builder can earn their margin.

EXAMPLE 2: ZK Accelerators

Downstream from world builders are ZK accelerators (“ZK Cloud”). ZK accelerators will allow franchised sequencers to process the events occurring in their virtual worlds into succinct proofs, ensuring they continue to operate the world in a valid way.

ZK accelerators supply:

• High performance compute to the company running this virtual world
• A guarantee that this compute is delivered back to the application at low latency
• Privacy guarantees (they will see the information happening in these worlds, and must keep it confidential)

A strong relationship of trust is therefore formed between the application builder and the cloud provider

So whilst ZK accelerators will find a beachhead market in aggregation for zkVMs (proofs for batching large pools of transactions, intermediated by networks such as L2s, and therefore zero margin), their end business will be supplying discreet and performant resources directly to applications: i.e. “ZK Cloud”.

They are a fusion between cloud and corporate VPN services: both high margin businesses.

As Ethereum shifts from leisure mode to business mode, information asymmetries must be preserved. Compute must shift from 99% public to 99% private. ZKPs will shift from luxury scaling technology to operational prerequisite: you cannot do without them.

In this view of the world, the ZK accelerators might just occupy one of the most compelling ‘trust residues’ in world computation.

The business models start to look abundant, once you start looking for the trust residues, and stop fixating on decentralisation.

From custody services, to compute, to vuln detection, to world-running, the trust residue is a long trail ripe for many healthy businesses.

5. Concluding Remarks

I’d love to see people building franchised sequencers: but doing so because they’re building apps, not more infra, nor seeking an excuse for some new token.

If you must build yet more developer software, take care of your developers from start to finish. Build Firebase for Ethereum: own the developer UX, start to finish. Buy in trusted, best-in-class prover performance. Use best-in-class custody solutions. Sell not to developers building ‘smart contracts’ and crusty protocols, but instead those building more expressive Ethereum software. Talk less about rollups, and more about instances. Push towards continuous deployment paradigms, not annual migrations.

I long to see Ethereum recede from visibility, reducing down to the little green light in the corner of our screens, and becoming the concrete foundation for digital life that we all thought we glimpsed a decade ago.

And as I sat there brooding on the old, unknown world, I thought of Gatsby’s wonder when he first picked out the green light at the end of Daisy’s dock. He had come a long way to this blue lawn, and his dream must have seemed so close that he could hardly fail to grasp it. He did not know that it was already behind him, somewhere back in that vast obscurity beyond the city, where the dark fields of the republic rolled on under the night.

— The Great Gatsby, F Scott Fitzgerald

Thanks to reviewers: Omer Shlomovits, Ben Levy, Claudia Richoux, Alex Evans, Nitya Subramanian, Lyron Koh Ting Keh, Wei Dai, Tim Robinson, Drew Van der Werff, Tracy Livengood and Eito Miyamura