Claim Your Chain: An Open Letter To Monoliths

This week, Kyle Samani released a provocative piece called The Hidden Cost of Modular Systems. We're building modular systems at Eclipse, so I figured this is as good of a time as ever to put my thoughts in writing.

Kyle shows an impressive understanding of the modular stack. I agree with Kyle on some points such that modular chains don't make code execute faster, they don't make things cheaper (unless you're on Ethereum - though I have some nuance to add below), and they don't solve congestion better than local fee markets.

However, I disagree with the following arguments in Kyle's essay:

  1. "App Roll Ups Do Not Create New Monetization Opportunities For Developers"

  2. "Flexibility Is Overrated"

He arguably misses the fundamental benefit of modularity and app chains as a whole – ownership. I'm going to make four points to explain where Kyle goes wrong:

  1. Ownership means new monetization opportunities

  2. Ownership means you control the flexibility

  3. Ownership means less risk.

  4. Ownership isn't for everyone.

I'll close with some general thoughts about monoliths (or "integrated systems" as Kyle calls them).

Be A Homeowner, Not A Rent Seeker

Crypto at its core is all about ownership and control, and modularity is no different.

Ownership means new monetization opportunities.

"Proponents of app chains/rollups argue that incentives will lead app developers to build roll ups rather than on an L1 or L2 so that they can capture MEV back to their own tokens." - Kyle Samani

In Kyle's quote above, he seems to infer that MEV is the only place app developers capture value. In reality, the answer is much simpler: when developers have their own chain, they can charge a premium on transaction fees. For example, let's look at Base. Base officially launched in August and has already captured ~$2M in revenue.

Source: Dune dashboard from TK Research
Source: Dune dashboard from TK Research

More generally, the biggest difference between having your own chain vs. deploying to a shared chain is the unit economics. With a shared chain, you are a rent seeker, and with every transaction, you're paying rent to the shared chain. When you have your own chain, you're the homeowner. You incur a fixed cost for operating the chain (relatively high for a full L1 app chain, but nevertheless fixed), and with every transaction, you're paying that off (and possibly charging a premium, since fees are completely controlled by the chain owner).

App chains open up the possibility for a variety of new business models where you can get increasing returns to scale as you handle more transactions, whereas a shared chain will give you constant returns to scale at best and decreasing at worst. App-specific rollups are inherently a hybrid solution where your fixed cost is substantially lower, but your marginal cost per transaction is higher, since now you're paying for blockspace on another Layer 1. This is exactly why Zebec moved from Solana to their own Eclipse chain.

Ownership means you control the flexibility.

Flexibility doesn't necessarily mean that you can do things that are inherently impossible on a shared chain. After all, shared chains can implement whatever modification you made to your app chain. The reason why flexibility is often cited for app chains is because now you get to choose how you customize the chain – which means you don't have to work with core developers to get your idea implemented.

For example, you might just disagree with the architectural or community values of existing chains. Vitalik originally proposed something similar to Ethereum which posted block data to Bitcoin, but the Bitcoin community rejected posting non-Bitcoin data to the ledger at the time. (Clearly the Bitcoin community has changed since then with Taproot.)

Today, for Ethereum power users who want the latest-and-greatest EIPs before they're live, they can go ahead and implement those on their own chain. This is exactly what Opclave did. Monoliths are slow when it comes to adopting improvement proposals and rightfully so given the number of stakeholders involved.

Or maybe you have an expensive computation which typically takes 10+ transactions. You have to pay for the cost of running all 10+ of those transactions – unless you roll the operation into its own native program (precompile). Such a precompile would never get implemented on a shared chain.

Ownership means less risk.

The reality is many blockchains have collapsed and application developers often end up as collateral damage. A notable example in recent times is Terra, a once robust ecosystem that imploded within 48 hours.

This might not matter for a Solana maxi, but non-crypto natives don't have the sophistication to know which blockchain is on the crux of a bust cycle. They'd rather hedge their bets and deploy with infrastructure which they know enables them to move to another L1 if needed.

One of the major appeals for the large gaming studios that Eclipse works with is that app-specific rollups allow them to mitigate volatility that’s often present in crypto. An example of this in the Eclipse ecosystem is Gridiron, who were originally web2 game developers. By taking the modular approach, they are able to remove any permanent dependencies from their infrastructure and focus on building a high quality game.

Ownership isn't for everyone.

The reason why not every application should have its own chain is because there's a fixed cost. If your project doesn't have much transaction volume, it won't be possible to pay off this fixed cost. This includes small NFT projects, decentralized identity (to some degree), and web2 games that are just looking to put a few NFTs onchain.

With a shared chain, you get to easily compose with all of the apps already there, so for the time being, if you're yield farming or doing something that requires a lot of composability, then there will be a little more friction on your own chain.

Apps should start by deploying to a shared chain. If a developer wants to build with no constraints, then they should look to app rollups.

The Hidden Costs Of Monoliths

It's only fair that we point out the hidden costs of monoliths, which are rarely acknowledged.

Monoliths sacrifice evolutionary pressure.

Modular architectures create increased competition at every layer of the stack, which means the infrastructure is constantly being improved upon. Developers benefit from the best attributes of each layer and competitive pricing. This structure allows for the development of infrastructure that’s optimized for specific needs.

For example, now we have Celestia and Eigen DA, which are two totally different approaches to data availability. The modular stack led to the development of zk-prover markets like RISC Zero, Axiom, and Nil Foundation, and now we have general purpose zk-VMs. In a monolithic world, the cost is stagnation.

Monoliths cannot support all types of apps.

As mentioned above, ownership isn't for everyone. But there are times when it is strictly necessary. Below are some examples of apps that have hit constraints on shared chains.

There are cases like Helium which is forced to use an offchain centralized oracle network as-is, because it's uneconomical to run the computation on Solana. You might argue that this is merely "hot state" as Kyle describes, but for some applications, the throughput is continuously needed.

As mentioned in Kyle's piece, some apps utilize threshold encryption methods where the chain only allows transactions to be decrypted after some specified block, critical for auctions. The status quo is a trusted oracle which writes a private key onchain, but now that oracle can frontrun the auction. This is what Fairblock is solving.

One point I agree with Kyle on is that derivatives-focused DEXs make sense for a standalone chain or rollup. This is something we have thought a lot about at Eclipse given our Chief Business Officer Vijay’s background as Head of BD at dYdX and Uniswap.

By encouraging developers to constrain themselves to the designs of monoliths we incur the cost of innovation.

Monoliths are largely economically unsustainable.

Alt L1s like Solana aim to solve the problem of congestion and fees through an improved virtual machine and validator architecture. But two factors threaten the economic sustainability of high throughput, cheap blockchains like Solana:

  1. Validator requirements are substantially higher than blockchains like Ethereum

  2. We still need a large validator set to ensure decentralization

The total transaction fees need to be enough to compensate all of these beefy validators, or else the difference must come out of inflation, causing the protocol's native token to depreciate. In other words, Solana’s cheap transactions are artificially subsidized through token inflation.

Napkin Math Analysis

We can lower bound the Solana network cost as $20K annually per validator * ~3,000 validators = $60M a year. I'll upper bound Solana's transaction volume at 4,000 TPS * 60 * 60 * 24 * 365 = ~125B transactions a year. The average transaction fee varies but I'll estimate it at 1.5 * 10^-5 SOL, or $0.000225 USD at the time of writing. Then the network brings in somewhere around $30M a year in revenue, so there is a $30M deficit. This is an underestimate of the annual loss, since I'm being generous with the estimates and it doesn't account for the opportunity cost of the capital locked as stake.

The loss is currently paid via inflation, but as a greater percent of the Solana token gets staked, this method of compensating validators becomes less effective. You can solve for the required inflation to compensate validators for their deficit:

At the time of writing, Solana is roughly $8 billion FDV with ~75% staked, so paying a $30 million deficit would require inflating the supply by ~$120 million. Notice that there is no way to pay a deficit greater than the unstaked supply. All of this is to say that Solana needs to increase its transaction volume or price per transaction. Or stakers need to pay higher fees. As Toly puts it, “there is no free lunch”.

L1 app chains don't solve this problem of enormous fixed costs, but rollups can. I can't say who, but we're talking with a number of L1 blockchains about migrating their community to their own rollup for this reason.

Some Closing Thoughts

While Kyle Samani's piece offers some valuable insights on modularity, I believe that the modular thesis is really about ownership down to the infrastructure level. Ownership is not just a term; it translates into tangible benefits like new monetization opportunities, increased control over flexibility, and reduced risk. The idea of modular blockchains brought to us by Celestia is just the first step towards a future state of verifiable blockchains that is easily accessible by an even wider audience. Rollup networks such as Eclipse are the destination.

If you’re interested in learning about rollups or just want to chat more, feel free to reach out to me. I would love to speak with you and learn about what you are building.

Subscribe to sydney
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.