[Source](https://jessewalden.com/layers-not-eras-of-blockchain-computing/)
# Layers (not eras) of blockchain computing
Last year, I wrote a post: [4 Eras of Blockchain Computing](https://jessewalden.com/4-eras-of-blockchain-computing-degrees-of-composability/), which introduced composibility (the lego-block approach to software) as a killer feature of blockchains. Recently, my view evolved so here's a thread & new model for thinking about the ecosystem👇
**Rather than the distinct eras, a better framing is **_Layers_** of Blockchain Computing.** This is a model that highlights how diverse architectures lead to specialization and a more dynamic, valuable stack.
This model mirrors the evolution of the internet stack itself: a layer cake of protocols and languages that are still in (slow!) development, but one that composes into a truly amazing, dynamic and seamless experience of file transfer, email, websites and more.
While IP was born amidst a number of more opinionated and feature rich protocols, many say it won because of its simplicity, and it has certainly hung in there. Today, IPv6 is only at 10% adoption nearly 20 years after its initial release!
So what are the implications for thinking about blockchains?
In the [original post](http://jessewalden.com/4-eras-of-blockchain-computing-degrees-of-composability), I labeled Bitcoin a calculator (a single purpose computer), ETH a generalized mainframe to be followed by more scalable, app-specific server era blockchains, and then a highly scalable, composable, decentralized "cloud"
Where this goes wrong, I think, is in positing a linear evolution and suggesting that each era cannibalizes the next on the dimension of scale and internal composibility.
Rewind to 2014, when Bitcoin was largely regarded as internet-wide payment rails. It was clear Bitcoin's throughput did not support internet scale, but had you waited around for a protocol upgrade, you might've missed Bitcoin tipping into its emergent role as a non-sovereign, digital store of value, which has much less need for scalability.
Similarly, Ethereum's early narrative, "a world computer", initially led many to 1) think Ethereum could replace Bitcoin because of its programmability and 2) assess it on the dimension of whether it could scale to provide internet-scale computation.
The latter is an especially dangerous assumption, because it can easily lead to the mistaken view that next generation smart contract platforms are defacto Ethereum killers, simply because they offer more scalability.
Well, just as Ethereum hasn't killed Bitcoin, scalable decentralized computation may not kill the leading "mainframe" era blockchain. Ethereum's utility today is not compute, but that of a _world accounting system_
DeFi and DAOs are the emergent use cases, and they take advantage of its strengths as a battle-tested, slow and secure computer for token-based applications like crowdfunding, lending, digital incorporation, and voting.
Even with network congestion leading to high fees, or wait times on the order of minutes or hours, these applications beat the UX of going to a bank for a loan, shareholder voting, or incorporation or dissolution of an LLC.
**What comes next—the "server" and "cloud" eras of blockchain computing—are less likely to kill Ethereum than to expand the adjacent possible and play host to a different set of applications that take advantage of their unique features.**
Application-specific, "server era" blockchains that roll their own networks (e.g. those building on Cosmos SDK) are also distinct from "cloud" era networks like Dfinity, Near, Polkadot and ETH 2.0, in that the latter take a top-down approach to network building by issuing security from a central base chain.
Each of these architectures may end up serving different applications. Add layers for privacy, storage, L2 scalability, node-SaaS, custodians and wallets and you start to have a thick, composable layer cake akin to that of the internet itself.
As most analogies, this one is imperfect, but a takeaway is that if you expect individual blockchains to scale comprehensively, it's very easy to miss the unique purpose that they specialize in, and how specialization can ensure an ongoing place in a larger, evolving stack.
Following this, projects that we now think of as competitive may turn out to instead be interoperable.
**The development of more advanced technologies does not necessarily eat the use cases of lower layers, but instead results in a complex, specialized stack.** The space on top of these discrete foundations is much bigger than we currently know.