What Lies Ahead for Ethereum? Exploring Modular Blockchain and Database Design
In the world of blockchain and smart contracts, we have made significant progress in recent years. Now, the question worth millions or even billions of dollars is: what is the future of Ethereum?
In this article, I will argue that Ethereum has reached its peak in terms of valuation of all crypto assets (ETH.D) and relative usage and adoption. I will start by exploring the concept of modular blockchain and comparing it to traditional database design principles, and then relate all of this back to Ethereum and its future.
Modular Blockchain
There is now a more principled way of thinking about what makes a well-functioning blockchain and a reasonable approach to decoupling (and scaling) core components. This is the debate between monolith and modularity.
The core idea behind modular blockchain is four basic functions:
1. Execution: determining the state “after” a transaction. If I send tokens to a specific wallet, the execution layer will determine the relevant balances before and after the transaction.
2. Settlement: determining if the submitted transaction is “valid.” After sending tokens, the settlement layer confirms whether the balance is xyz – settling the correctness of xyz.
3. Consensus: determining the final state after a bundle of transactions. This layer determines 1) the correct order of a given set of transactions and 2) the final state after processing these transactions.
4. Data Availability: in order for any of the above three functions to exist, there needs to be a previous state and an end state. The function of Data Availability is to provide the state to the execution layer and update the state based on the final result of consensus.
Just like any engineering problem, a “perfect” blockchain only makes sense when there are well-defined use cases. The existence of this framework allows for more specialized blockchain designs, with blockchains built for high throughput gaming having different requirements than blockchains designed to be globally decentralized ledgers. This thinking framework reminds me a lot of principles in database design, especially the debate around SQL and noSQL.
Database Design
Databases have been around for decades longer than blockchain. The consensus on their design is that there is no perfect database. Just like most engineering problems, everything requires trade-offs.
Building a scalable database framework comes back to “what are the use cases?” I would ask some questions before making a decision:
1. What is the rough ratio of read to write? In applications like Telegram or Slack, the read and write volumes are similar, while on Twitter, the read volume is several orders of magnitude higher than the write volume.
2. In distributed systems, there is the concept of consistency vs. availability. In other words, this can be reframed as: do we care more about inaccurate data or downtime of the application? This again depends on the situation. For fintech applications, consistency (accurate data) would be much more important.
3. How important is the distinction between stale and fresh data? How does this relate to the read-write load? Does our database allow us to implement a strategy to handle concurrent writes and reads? For example, how do we prevent the classic double-spending problem when my wife withdraws cash from my bank while I swipe my debit card?
4. What are the read patterns? Do you need flexible access to data, or is the data typically predefined? Do you perform a lot of joins across different datasets?
In addition to technical considerations, it’s important to understand the following:
1. How many engineers are proficient in this technology? How many engineers actually want to use this technology to build?
2. If we want to fork the underlying code and make adjustments, is there a way to get positive support?
The Future of Ethereum
Now let’s tie all of this together – there is no such thing as a “perfect” blockchain. Good engineering is about trade-offs, and there is no one-size-fits-all solution. So how did Ethereum become such a “dominant” platform? Why does Ethereum’s valuation make it seem like it is the perfect blockchain? And finally, what lies ahead for Ethereum?
How did Ethereum become such a “dominant” platform?
Four years ago, Ethereum was the preferred platform for building smart contracts. It had excellent development tools like Hardhat and CryptoZombies compared to all other platforms. Additionally, it had a loyal user base, and the chain and tokens were “decentralized.” At that time, centralized blockchains were more likely to be scams. ETH as an asset was also cheaper, meaning gas fees were lower.
Today, developers have more smart contract platforms to choose from, each with unique trade-offs. While scams still exist, the situation has significantly reduced compared to four years ago, with more talent and capital entering the space.
The reasons why Ethereum was successful in the past are also the reasons why it will fail in the future. There was a time when Ethereum was the only viable smart contract platform for developers. Legitimate use cases like DeFi and NFTs gave ETH a significant advantage. However, during this phase, the focus shifted towards value accumulation (super stablecoins) and competing with Bitcoin to become the internet-native default store of value (flippening).
The desire to simultaneously be a smart contract platform and a decentralized “super stablecoin” created significant friction for marginal users and developers (higher gas costs, congested network). As Confucius (and GCR) said: “A man who chases two rabbits catches none.”
What lies ahead for Ethereum?
Users will flow to places where applications exist and are cost-effective, while application developers tend to be more cautious and long-term oriented. They have much greater expenses compared to users themselves. Developers will build on platforms that offer long-term growth and scalability potential for their applications.
Now look at Ethereum, with an average transaction speed of 15-20 TPS and gas fees often soaring to $200. There are very clear limitations on the types of applications that can be built on Ethereum, which require minimal interaction. For example, a lending protocol is a good application on Ethereum because I may interact with it a few times a year.
But if I were an application developer planning to build an app that intends to scale to 100,000 or 1 million users with higher usage patterns, building such an app on Ethereum is not feasible.
This becomes increasingly evident as viable alternatives emerge.
FriendTech is building on Base L2.
Pacman and Blur teams are considering launching their own L2.
DYDX uses its own specific application chain.
The modular blockchain framework provides a set of trade-offs that blockchains can choose from. We are now in a state where blockchain infrastructure supporting points along the trade-off curve is starting to emerge.
Lastly, and most importantly, are the incentives.
As Charlie Munger always says, “Show me the incentives, and I will show you the outcome.” The incentive structure built on Ethereum is poor compared to other existing blockchains. Venture capital firms and new L1 teams are very interested in building a strong, thriving ecosystem. As an investor, I would question why my team should build on Ethereum when there are other blockchains with lower L1 valuations that promote application development in my best interest.
The replies to this tweet make things very clear.
ETH is no longer at the cutting edge of blockchain design.
Regardless of where you want to be on the trade-off curve, there are superior smart contract platform choices and incentive structures. Unless there is a fundamental change in how Ethereum operates as a community and organization, its relative advantage in valuation and usage has reached its peak.
