Unless Ethereum undergoes fundamental changes in its community and organizational operations, its relative advantages in valuation and usage have reached their peak.
(Module Blockchain
Database Design
The future of Ethereum)
How did Ethereum become such a dominant platform?
How will Ethereum develop next? In this article, I discuss modular blockchains and database design, and quote GCR’s perspective to try to answer these questions.
The argument of the innovator’s dilemma can be summarized as follows: “Successful companies often cannot adapt to changes in their models, especially in terms of technological innovation. The reason is that they focus too much on making their products successful rather than trying new and unfamiliar ideas.”
In the world of blockchain and smart contracts, we have made significant progress in the past few years. Now, the million-dollar or rather $250 billion question is: What is the future of Ethereum?
Through this article, I will argue that Ethereum has reached its peak in terms of 1) valuation of all crypto assets (ETH.D); and 2) relative usage and adoption. I will start by exploring the concept of modular blockchains and comparing it to traditional database design principles, and then relate it all back to Ethereum and its future.
Now, people have a more principled way of thinking about what constitutes a well-functioning blockchain and a reasonable approach to decoupling (and scaling) core components. This is the debate between monolithic and modular.
The core idea behind modular blockchains is four basic functions:
Execution: Determines the “after” state of a transaction. If I send tokens to a specific wallet, the execution layer determines the relevant balance before and after the transaction.
Settlement: Determines whether the submitted transaction is “valid.” After sending tokens, the balance is xyz – settlement determines if xyz is correct.
Consensus: Determines 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.
Data availability: In order to exist for any of the above three functions, there needs to be a previous state and an ending 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.
Like any engineering problem, a “perfect” blockchain only makes sense when there are clearly defined use cases. This framework allows for more professional blockchain designs, with different requirements for blockchains built for high throughput gaming and those designed to be global decentralized ledgers. This thinking framework reminds me a lot of database design principles, especially the debate around SQL vs. NoSQL.
Databases have been around for decades longer than blockchains. There is no perfect database consensus on their design. Like most engineering problems, everything needs to be balanced.
Building scalable modular databases brings us back to “What is the use case?” Before making a decision, I would ask some questions:
What is the approximate 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.
In distributed systems, there is the concept of consistency and availability. In other words, this can be rephrased as: Do we care more about inaccurate data or application downtime? This, again, depends on the situation. For fintech applications, consistency (accurate data) is much more important.
How important is stale data vs. fresh data? How does this relate to the read-write load? Does our database allow us to employ 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?
What is the read pattern like? Do you need flexible access to data or are the data usually pre-defined? Do you perform a lot of joins across different datasets?
In addition to technical considerations, it is important to understand the following:
How many engineers are proficient in this technology? How many engineers actually want to use this technology to build?
If we want to fork the underlying codebase and make adjustments, is there a way to get active support?
Now, let’s tie it all together – there is no perfect blockchain. Good engineering is about trade-offs, and there is no one-size-fits-all approach. So, how did Ethereum become such a dominant platform? Why does Ethereum’s pricing seem like it is the perfect blockchain? Lastly, how will Ethereum develop next?
Four years ago, Ethereum was the preferred platform for building smart contracts. Compared to all other platforms, it had excellent development tools such as Hardhat, CryptoZombies, etc.
Furthermore, 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 was also cheaper as an asset, which meant lower gas fees.
Today, developers have more options for smart contract platforms, each with its own unique trade-offs. While scams still exist, the situation has significantly improved compared to four years ago with more talent and capital entering the field.
The reasons why Ethereum succeeded 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 (DeFi, NFTs) provided ETH with a significant head start. But at this stage, the focus shifted towards value accumulation (stablecoins) and competing with Bitcoin to become the default store of value on the internet.
The desire to simultaneously be a smart contract platform and a decentralized “super stablecoin” added significant friction for marginal users and developers (higher gas costs, congested network). As Confucius (and GCR) said: “A man who chases two rabbits catches neither.”
Users will flow to places where applications exist and are cost-effective, while application developers tend to be more cautious and long-term. Their expenses are much greater compared to the users themselves. Developers will build on platforms that have long-term growth and scaling potential for their applications.
Now, look at Ethereum, which has an average transaction speed of 15-20 TPS, and gas fees often skyrocket to $200. There are very clear limitations on the applications that can be built on Ethereum, which require very little 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 looking to build a high-usage application with hundreds of thousands or millions of users and higher usage patterns, building such an application on Ethereum is not feasible.
This becomes increasingly evident as viable alternative solutions emerge.
FriendTech is building on Base L2.
Pacman and Blur teams are considering launching their own L2.
DYDX uses their own specific application chain.
The modular blockchain framework provides a set of trade-offs for blockchains to choose from. We are now at a stage where blockchain infrastructure supporting points along the trade-off curve is starting to emerge.
Last but not least is the incentive structure.
As Charlie Munger has always said, “Show me the incentive, and I will show you the outcome.” The incentive structure for building on Ethereum is relatively 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 tokens are so dispersed and the ecosystem is already crowded. Why not promote application development on a blockchain where L1 valuations are much lower?
The replies in this tweet make it very clear.
ETH is no longer the front-runner in blockchain design. There are better smart contract platforms to choose from at various points along the trade-off curve, and the same goes for incentive structures. Unless Ethereum undergoes fundamental changes in its community and organizational operations, its relative advantages in valuation and usage have reached their peak.