Original author: JAY
Original translation: TechFlow
So, what will happen to Ethereum next? In this article, I talked about modular blockchains, database design, and cited GCRs views to try to answer this question.
The innovators dilemma thesis can be summarized as follows: Successful companies often fail to adapt to paradigm shifts, especially when it comes to technological innovation, because they focus too much on making their products successful rather than trying newer and less familiar ideas.
In the world of blockchain and smart contracts, we’ve come a long way in the past few years. Now, the million dollar or $250 billion question is: what’s next for Ethereum?
Throughout this post, I will argue that Ethereum has reached the pinnacle in terms of 1) valuation (ETH.D) of all crypto assets and 2) relative usage and adoption. I will begin by exploring the concept of modular blockchains, comparing it to traditional database design principles, and then tying it all back to Ethereum and its future.
Modular blockchain
Now, there is a more principled way of thinking about what makes a well-functioning blockchain, and a sensible way to decouple (and scale) core components. This is the monolith vs. modular debate.
The core idea behind blockchain modularity is that there are four basic functions:
Execution. Determines the state of a transaction “after”. If I send tokens to a specific wallet, the execution layer determines the relative balances before and after the transaction.
Settlement. Determines if the submitted transaction is legal. After sending tokens, the balance is xyz - settlement determines if xyz is correct.
Consensus. Determine the final state after a bundle of transactions. This layer determines 1) the correct order given a series of transactions, and 2) the final state after processing those transactions.
Data availability. For any of the three functions above to exist, there needs to be a previous state and an end state. The function of the DA is to provide the state to the execution layer and update the state based on the final result of the consensus.
As with any engineering problem, the perfect blockchain only makes sense when well-defined use cases exist. The existence of this framework allows for more specialized blockchain designs, a blockchain built for high-throughput gaming has very different needs than a blockchain designed to be a global decentralized ledger. This framework for thinking reminds me very much of the principles of database design, specifically the debate around SQL vs. noSQL.
Database Design
Databases have been around for decades longer than blockchains. The consensus about their design is that there is no perfect database. Like most engineering problems, everything requires tradeoffs.
A framework for building a scalable database comes back to “what is the use case?” There are some questions I ask before making a decision:
What is the approximate ratio of reads to writes? On apps like Telegram or Slack, the reads and writes are of similar magnitude, while on Twitter, the reads are several orders of magnitude higher than the writes.
In distributed systems, there is the concept of consistency vs. availability. In other words, this can be restated as: do we care more about inaccurate data or application downtime? Again, it 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 read and write load? Does our database allow us to implement a strategy to handle concurrent writes and reads? For example, how do I prevent the classic double-spend problem when my wife withdraws cash from my bank while I swipe my debit card?
What is your read pattern? Do you need flexible access to data, or is it generally predefined? Do you perform a lot of joins across different data sets?
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 build with this technology?
If we want to fork the underlying code and make tweaks, is there a way to get active support?
The Future of Ethereum
Now to put this all in context - the perfect blockchain does not exist. Good engineering is all about trade-offs, there is no one-size-fits-all approach. So how did Ethereum become such a dominant platform? Why is Ethereum priced as if it is the perfect blockchain? And finally, whats next for Ethereum?
How did Ethereum become such a “dominant” platform?
Four years ago, Ethereum was the platform of choice for building smart contracts. It had excellent developer tools like Hardhat, CryptoZombies, etc. compared to all other platforms. In addition, 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 many more smart contract platforms to choose from, each with unique tradeoffs. While scams still exist, they are significantly less than they were four years ago as more talent and capital enter the space.
The reasons Ethereum succeeded in the past are also the reasons 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) gave ETH a huge head start. But during this phase, the focus turned to value accumulation (super stablecoins) and competing with Bitcoin to become the default store of value native to the internet (flipping).
The desire to be both a smart contract platform and a decentralized super stablecoin adds significant friction for marginal users and developers (higher gas costs, congested networks). As Confucius (and GCR) said: He who chases two rabbits catches neither.
What’s next for Ethereum?
Users will flow to where apps exist and where costs are reasonable, while app developers tend to be more cautious and long-term. Because their overhead is much greater than the users themselves. Developers will build on platforms where their apps have long-term growth and expansion potential.
Looking at Ethereum right now, it has an average transaction speed of 15-20 TPS and gas fees often soar to $200. There are very clear limits on the applications that can be built on Ethereum, and these applications require very minimal interaction. For example, a lending protocol is a great application on Ethereum because I might interact with it a few times a year.
But if I’m an application developer building an application that’s intended to scale to 100,000 or 1 million users and have higher usage patterns, it’s not feasible to build such an application on Ethereum.
This is increasingly evident as viable alternatives emerge left and right.
FriendTech is built 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 that blockchains can choose from. We are now at a point where infrastructure that supports blockchains at points along the trade-off curve is beginning to emerge.
The last and most important thing is incentives.
As Charlie Munger always says: Show me the incentives and Ill show you the results. The incentive structure built on Ethereum is inferior to other existing blockchains. VCs and new L1 teams are very interested in building a strong, thriving ecosystem. As an investor, I would think, why would my team build on Ethereum when the token is so fragmented and the ecosystem is already so crowded? Why not promote application development on a blockchain where I have a stake, where L1 valuations are much lower.
The replies in this tweet made things very clear.
ETH is no longer at the efficient frontier of blockchain design. No matter where you look on the tradeoff curve, there are better smart contract platform choices, and the same goes for incentive structures. Unless Ethereum makes fundamental changes in how communities and organizations operate, its relative advantage in valuation and usage has peaked.
