Original title: Ethereum and the innovators dillema

Original author: Jay

Original compilation: Luccy, BlockBeats

Editors note: He who chases two rabbits will gain nothing. Global Competition Review (GCR) once expressed this view on social media platforms.

GCR is the complete source of news and analysis for competition practitioners. Crypto researcher Jay started from the perspectives of modular blockchain, database design and GCR, and deeply discussed the current situation and prospects of Ethereum as a smart contract platform, revealing the challenges that Ethereum may face when facing new technology choices and competitors. challenges, and the importance of factors such as incentives, developer support, and technology selection.

Where will Ethereum go next? I discussed modular blockchain, database design, and quoted GCRs perspective to try to answer this question. Just to be clear, I am net long on Ethereum.

The core idea of ​​the Innovators Dilemma can be summarized as:

Successful companies often have difficulty adapting to paradigm shifts, especially when it comes to technological innovation. The reason is that they are too focused and over-invested in what makes their products successful, and are unwilling to try new and unfamiliar ideas.

In the field of blockchain and smart contracts, we have made significant progress in the past few years. Now, the million-dollar or $250 billion question is: What is the fate of Ethereum?

Through this article, I will make the following point: Ethereum leads the way in terms of both valuation and relative adoption relative to all cryptoassets (ETH.D).

I’ll start by exploring the concept of modular blockchains versus traditional database design principles, and then tie everything back to Ethereum and its future.

Modular blockchain

Now we have a more principled way of thinking about the logical approach to building a well-functioning blockchain and decoupling (and extending) the core components. This is the monolithic vs. modular debate.

When it comes to modularity of blockchain, the core idea is that there are four basic functions:

· Execution: Determine the state after the transaction. If I send tokens to a specific wallet, the execution layer determines how the relevant balance changed before and after the transaction.

· Settlement: Determine whether the submitted transaction is legal. After sending the token, the balance is xyz, and the settlement layer determines whether xyz is correct.

· Consensus: Determining the final state after a set of transactions. This layer determines what the final state is after processing these transactions, given the correct order in a series of transactions.

· Data availability: In order for the above 3 functions to exist, there needs to be a previous state and a final state. The function of data availability is to provide state to the execution layer and update the state based on consensus finality.

As with any engineering problem, the concept of a “perfect” blockchain only makes sense if there are clearly defined use cases. The existence of this framework allows for more specialized blockchain design, a blockchain built for high-throughput gaming will have completely different needs than a blockchain designed to be a global, decentralized ledger.

This framework of thinking reminds me very much of the principles of database design, especially the debate surrounding SQL vs. noSQL.

Database Design

Databases have been around for decades longer than blockchain. The consensus in terms of its design is that no database is perfect. As with most engineering problems, it all comes down to trade-offs.

When building a framework for scalable databases, you need to think about what are the use cases? Before making a decision, I would ask some questions:

· In an application like Telegram or Slack, what is the approximate ratio of reads to writes? On Twitter, the number of reads will be orders of magnitude higher than writes.

· In distributed systems, there are concepts of consistency and availability. In other words, this can be rephrased as: are we more concerned about inaccurate data or downtime for our applications? Again, it depends on the situation. For fintech applications, consistency (accurate data) is even more important.

· How important is stale data relative to fresh data? How does this relate to read vs. write workloads? Does our database allow us to implement a strategy for handling concurrent writes and reads? For example, when my wife withdraws cash from my bank and I swipe my debit card at the same time - how do we prevent the classic double-spend problem?

· What is the read mode? Do you need flexibility in data access, or is it usually predefined? Are there many join operations between different data sets?

Even beyond technical considerations, its important to understand the following:

· How many engineers are familiar with this technology? How many engineers actually want to build with this technology?

· If we want to fork the underlying code and make adjustments, is there a way to get active support?

The future of Ethereum

Now looking at the whole issue, a perfect blockchain does not exist. Good engineering design is all about trade-offs, and no one size fits all. So how did Ethereum become such a “dominant” platform? Why is Ethereum’s price behaving as if it’s the perfect blockchain? Finally, where will Ethereum go from here?

How did Ethereum become such a “dominant” platform?

Four years ago, Ethereum became the platform of choice for building smart contracts. Compared to other competitors, it has excellent development tools such as Hardhat, CryptoZombies, etc. In addition, there is a dedicated user group, and the chain and token are decentralized. At that point, centralized blockchains are more likely to be a means of fraud. ETH is also a much cheaper asset, which means gas fees are lower as well.

Fast forward to today, and developers have many more smart contract platforms to build on, each with a unique set of trade-offs. While some fraud still exists, it has decreased significantly relative to four years ago as more talent and capital enter the space.

What made Ethereum successful in the past is exactly why it will fail in the future. There was a time when Ethereum was the only viable smart contract platform for developers to build on. Legitimate use cases (DeFi, NFTs) put ETH a big step ahead. But at this stage, the focus turns to value accumulation (ultrasonic currency) and competing with Bitcoin to become the de facto Internet-native store of value (flippening).

The desire to be both a smart contract platform and a decentralized “ultrasonic currency” adds significant resistance (higher gas costs, network congestion) for edge users and developers. As Confucius (and GCR) said, he who chases two rabbits will gain nothing.

Where will Ethereum go in the future?

Users will choose where the application is available and cost-effective. However, app developers tend to be more thoughtful and long-term because they have more overhead than the users themselves. Developers will build on platforms that have the potential to grow and scale their applications over the long term.

Now look at Ethereum, which has average transaction speeds of 15-20 TPS and gas fees that regularly soar to over $200. There are very obvious limitations to what can be built on Ethereum, which are applications that require very little interaction. For example, on Ethereum, the lending protocol is a great application because I will probably only interact with it a few times a year.

But if Im an application developer who plans to scale my application to 100,000 or 1,000,000 users and have higher frequency of usage, building on Ethereum is basically not feasible.

This is becoming increasingly evident as viable alternatives continue to emerge.

· FriendTech is built on Base L2.

· The Pacman and Blur teams are planning to launch their own L2.

· DYDX utilizes their own specific application chain.

Modular blockchain frameworks provide a set of trade-offs that can be chosen. We are now in a state where blockchain infrastructure is starting to emerge that supports various points on the trade-off curve.

Finally, motivation, motivation, motivation.

As Charlie Munger always says, Show me the incentives and Ill show you the results. There are disadvantages to building the incentive structure on Ethereum compared to other existing blockchains. Venture capital firms and new L1 teams have a vested interest in building a strong and prosperous ecosystem. As an investor, I would think, why would I want my team to build on Ethereum when the currency is so widely distributed and the ecosystem is already so crowded? Why not promote application development on a blockchain where I have a vested interest and where the L1 valuation is lower?

In terms of blockchain design, Ethereum is no longer on the efficient frontier. No matter where you want to fall on the trade-off curve, there are superior smart contract platform options, and the incentive structure sets the goal against them. Unless there are fundamental changes in the way Ethereum operates, both as a community and as an organization, the relative advantage over valuation and usage has peaked.

Original link