# The Narrative of 3rd Generation Blockchains *Author: Victor Wei* In this article I explore what 3rd generation blockchains are and what they hope to solve. I then briefly compare my initial thoughts on both the Cosmos and Polkadot blockchains. ## What are 3rd generation blockchains? These blockchains claim to be the next evolution of blockchain technology, and have three key narratives to them: scalability, customizability, and interoperability. The 3rd gens that I've explored have similar architectural concepts--a main chain, which connects many other "application-blockchains" together. If we view each blockchain as a network (which is pretty accurate), then what 3rd generation blockchains build is a "network of networks", or Internet of Blockchains. Thus, the primary value proposition of these blockchains are interoperability and customizability. But before we go deeper, we need to explore what came before the 3rd generation. ## A Bit of History ### The First Generation First generation blockchains, like Bitcoin, lay within the realm of cryptocurrencies. These blockchains had one overarching purpose--facilitate the transaction of currency in a P2P manner. The coins were simply meant to be used for monetary transfer. For example, BTC was created to be the electronic equivalent of physical cash, not function as NFTs, stablecoins, staking collateral, or voting rights. Furthermore, 1st generation blockchains are a monolithic codebase that includes the networking protocols, consensus mechanism, and application layer logic, ie, the state transition function (UTXO model for BTC), all in one, inseparable stack. As one can imagine, this makes it very difficult for developers to customize Bitcoin for other uses, or even to adjust blockchain parameters, like changing the consensus algorithm. This non-customizability severely limited 1st generation blockchains. What if you wanted to lend and borrow BTC, lock them up, make them non-fungible, or in general do something special with them besides simple transfers? The only way to do such things was by forking the codebase or building on top of it, and the limitations of the Bitcoin scripting language exacerbated the situation. ### The Second Generation This led to the development of 2nd generation blockchains, like Ethereum, and the introduction of smart contracts. The main value of Ethereum was that it created a general-purpose blockchain, some may call a world-computer, that allowed developers to write their own applications on top of Ethereum, and thus achieve much more customization easily. This allowed developers to create their own tokens, financial protocols, and much more, by simply writing smart contracts. The currency, ETH, became not just a way to transact, but more so a way to pay for interacting with smart contracts--it became known as “gas”. How did 2nd generation blockchains manage to allow developers to write Turing-complete code on top of the blockchain? The key concept is separating the application layer from the rest of the stack (networking and consensus layers), and the key technology is a virtual machine. By separating the application layer from the networking and consensus layers, the idea was that developers could write their own application layer logic, and not have to worry about consensus or propagating transactions on the network. By "plugging and playing", developers could focus on their application, and simply rely on the security offered by the underlying base layers, ie, the *core protocol*. > In Ethereum, a virtual machine (EVM) was created to function as the glue between the logic that developers write in applications and the underlying layers. Developers write dApps in EVM-compatible languages, like Solidity, which compiles into EVM bytecode. Since all nodes are running a copy of the EVM, all nodes can understand the application code. So in summary, 2nd gen blockchains improve 1st gen blockchains by allowing developers to write their own general-purpose applications while relying on the security of the underlying L1 layer. The codebase is made less monolithic. #### The Problem While making it much easier to develop apps and greatly increasing interoperability and customizability, note, however, that applications built on 2nd gen blockchains are still reliant on the underlying consensus and networking layers. Although the security afforded by this reliance is nice, this is also a handicap. There remain three main issues with second generation blockchains: 1. **Scalability** - dApps built on top of 2nd gen blockchains are restricted by the underlying scalability of the blockchain they are built on. For example, in Ethereum, apps are limited to the 15 tx/s throughput, and must compete for that space, making gas fees rocket. This is because every node has to process every transaction--there is no parallelization. 2. **Customizability (still)** - dApps are still constrained by the parameters of the underlying L1 blockchain. For example, block time, block size, validator set, type of consensus algorithm, etc. are all determined by underlying layers. What if you wanted a UTXO model for your dApp instead of an account-based model? What if you wanted PoW instead of PoS, or some other consensus algorithm? 3. **Sovereignty** - the governance of the application is limited by the governance of the L1 chain. For example, an application on Ethereum cannot change the EVM or the block size–this vote must go through ETH governance first. Conversely, a vote for change in ETH governance may adversely affect the governance of the applicaiton. > For example, Livepeer has many of their protocol parameters defined in terms of ETH parameters–that a "round" may take 2000 ETH blocks. This makes it difficult for them to gain independence. What if a change in the ETH core protocol made block times 3x faster? This makes a Livepeer round much shorter, which may violate their security model, and now the team needs to redefine it. All of these issues have a common underlying pattern: **the underlying layers (networking and consensus) limit the freedom of the application**. These restrictions may affect the governance, the scalability, or the overall customizability of the app. ## The 3rd Generation, revisited These problems have led to the development of 3rd generation blockchains. So how do these blockchains tackle the issues of scalability, customizability, and interoperability? First, scalability is tackled by sharding, which allows for the parallelization of transactions. Second, to tackle customizability, these blockchains take an interesting approach. Clearly, the problem is that making all apps rely on a common base layer limits applications, so the solution is to free apps from this reliance. What if people can build their own L1 blockchains? That is, what if developers, instead of just building the application layer, built their own custom consensus and networking layers as well? This introduces two new problems. First, building these underlying layers is incredibly complex and time consuming. That is why Ethereum took the approach they did. Second, this introduces a huge issue of interoperability. If everyone starts building their own blockchains, what we’ll have in effect is a ton of isolated blockchains. And it's notably difficult to bootstrap blockchains, due to network effects. So what may end up being created is an ecosystem of isolated, useless chains! The way 3rd gen blockchains solve these issues was hinted at in the introduction. Essentially, 3rd gen blockchains are made up of a **main chain**, which many **application-specific chains** are connected to. Each of these application-specific blockchains are full blockchains in their own right, complete with their own networking and consensus layer. Each of these "sub-chains" functions as a *heterogeneous shard*, allowing transactions to be processed in parallel. Further, a framework is offered to help make building blockchains easier, and a protocol helps to make blockchains interoperable. Let's take a look at the tools... ## A (very) Brief Look at the Technology So we now know that 3rd gen blockchains seek to build a network of interoperable, custom-built blockchains. In order to do this, there are two main tools: - An SDK or Framework to help developers build blockchains - A protocol that enables these blockchains to communicate with each other ## A (high-level) Case-by-Case Analaysis ### POLKADOT Polkadot is a 3rd gen blockchain. It allows many “custom-built” chains to connect to their main chain, the relay chain. Each custom-chain is a shard, leading to heterogeneous sharding, enabling scalability. Each heterogeneous blockchain shard is called a parachain. They are bonded to the relay chain when people invest enough DOT (the native token) to bond the chain. The shards can communicate with each other by using message passing and a communication protocol (XCM), thus enabling interoperability. Finally, Polkadot offers the Substrate framework, a modular framework that allows developers to build blockchains with ease. ### COSMOS Cosmos is another 3rd gen blockchain. It is very similar in goal to Polkadot. The Cosmos network has a “hub and zone” architecture. Hubs connect zones together, and zones connected to a hub are all interoperable with each other via the Inter-Blockchain Communication protocol (IBC). The hub is analogous to the Polkadot relay chain, while zones are analogous to parachains. To help ease development of blockchains, Cosmos offers the Cosmos SDK, which is connected to an underlying Tendermint BFT Engine (which provides network and consensus layers). ## Some Closing Thoughts The development and goals of 3rd generation blockchains is very exciting to me. Although the abstractions provided by Ethereum is nice, I do notice limitations that apps must conform to. Interoperability is always a plus. What these blockchains are aiming to do, is kind of like what NSFNET did by unifying many networks, and thus creating a network of networks, forming the basis for the Internet. And it's worked out pretty well. The question often comes down to: will there be one chain to rule them all? That is, will something like Ethereum serve as the basis for all dApps? While I used to be of that mindset, in awe of Ethereum's generalizability, I have now come to see the limitations of smart contracts and the EVM--there is only so much you can do with those tools. I think Ethereum still offers great value--there are certain applications that fit its model very well. In that view, I think Ethereum will come to be just another "zone" on the "hub". So in summary: instead of building dApps on a common base layer, developers now build blockchains themselves, each of which are custom-built to support their own native application. Instead of a having a million dApps built on top of one L1 blockchain, all competing for throughput on that single base layer, what 3rd gen blockchains seek to enable is one million apps built on one million interconnected blockchains. The 3rd generation returns to the 1st generation, offering the same customizability as forking a codebase does, but making the development process much, much easier, while also offering interoperability.