Layered Networks/Chains
Layered Networks/Chains

Layered Networks/Chains

Ethereum: Optimism/Arbitrum/ZKSync/Starkware/Polygon

Cosmos: Thorchain/Terra/Osmosis/Secret/ Binance.

Polkadot: Centrifuge/Moonbeam/Acala

Not sure about the other 3

(Comment: The map means nothing. It’s a meme chain’s way of trying to leverage Ethereum’s popularity.

The future is definitely not multi chain. The future is Ethereum plus shard chains and rollups. Or some other L1 that solves scalability.

But the idea that people will bother securing secondary chains in masses large enough to securely decentralize is highly unlikely.)

What Is a Side Chain?

A sidechain is a side blockchain that is linked to another blockchain, referred to as the main chain, via a two-way peg.

Imagine a global decentralized network of various blockchains, each with their own sets of rules, functionalities and purposes, that remain independent from each yet form one seamless ecosystem. That’s the sidechain vision.

This sophisticated cryptographic mechanism enables tokens and other digital assets to move back and forth freely from the main chain. An example of a sidechain is the Liquid Network, a settlement layer that allows traders and trading platforms to enjoy faster and more private transactions, as well as digital asset creation. Since the Liquid Network is pegged to Bitcoin, which is the main chain in this example, only activities involving Bitcoin are possible. 

It works like this: 

The main chain user first needs to send coins or other digital assets to an output address where they are locked and unspendable anywhere else. After the transaction is complete, a confirmation is relayed across the chains. This is followed by a waiting period for added security. Afterward, the coins or assets will be fully transferred on the sidechain, enabling users to move them around freely on the new network. If a user wants to send the coins back to the main chain, he only needs to reverse the process.

Sidechains come in many variations depending on the functions they are built for. While both Liquid and Rootstock are Bitcoin sidechains, they function very differently, since the latter is specifically created for the purpose of running smart contracts more efficiently. 

Ethereum 2.0 has its own variation of sidechains called shard chains that are attached to the recently launched Beacon Chain, which aims to ultimately become the main chain of proof-of-stake (PoS)-based Ethereum.




There is a trilemma in blockchain systems that can be visualized in form of a triangle known as DCS triangle, what it conveys is “It is impossible to achieve all three Decentralization, Consistency, and Scalability simultaenously. A tradeoff is necessary (you can choose any two but not all)”.

Sharding is an attempt to solve this challenge. It simply means partitioning large chains (databases) into smaller, faster ones hence making the entire system more scalable. How? To solve scalability, we split the state and history stored on the main chain into shards. Each shard manages itself, has its own transaction history, and the effect of transactions in some shard are limited to that shard only.

Examples for this would be: A dApp having a whole shard by himself so that all tx’s related to it will be on that one shard only. Several dApps related to a particular domain will be on one single shard.

The later phases of ETH2.0 considers the possibility of cross-shard communications.

Sharding also introduces different types of nodes like “Light Node”, “Super-Full Node” etc. depending upon how much data it downloads, how much it verifies.

The Scalability Trilemma

The Scalability Trilemma claims that blockchain systems can only, at most, have two of the following three properties:

  • Decentralization (defined as the system being able to run in a scenario where each participant only has access to O(c) resources, i.e. a regular laptop or small VPS)
  • Scalability (defined as being able to process many transactions)
  • Security (defined as being secure against attackers with up to O(n) resources)

The key challenge of scalability is finding a way to achieve all three at the base layer of a blockchain – sharding is one such attempt at solving this challenge.

What is sharding?

Currently, in all blockchain protocols, each node stores the entire state (account balances, contract code and storage, etc.) and processes all transactions. This provides a large amount of security, but greatly limits scalability: a blockchain cannot process more transactions than a single node can. In large part, because of this, Bitcoin is limited to ~3-7 transactions per second, Ethereum to 7-15, etc.

However, this poses a question: are there ways to create a new mechanism, where only a small subset of nodes verifies each transaction? As long as there are sufficiently many nodes verifying each transaction, then the system is still highly secure. But a sufficiently small percentage of the total validator set that the system can process many transactions in parallel, could we not split up transaction processing between smaller groups of nodes to greatly increase a blockchain’s total throughput?

What is the basic idea behind sharding?

We split the state and history of Ethereum up into partitions that we call “shards”. For example, a sharding scheme on Ethereum might put all addresses starting with 0x00 into one shard, all addresses starting with 0x01 into another shard, etc. In the simplest form of sharding, each shard also has its own transaction history, and the effect of transactions in some shard are limited to the state of shard of that same shard. One simple example would be a multi-asset blockchain, where there are many shards and where each shard stores the balances and processes the transactions associated with one particular asset. In more advanced forms of sharding, there exists some form of cross-shard communication capability, where transactions on one shard can trigger events on other shards.

What might a basic design of a sharded blockchain look like?

There exists a set of validators (ie. proof of stake nodes), who randomly get assigned the right to create shard blocks. During each slot (eg. an 8-second period of time), for each shard in [0…999] a random validator gets selected, and given the right to create a block on a shard, which might contain up to, say, 32 kb of data. Also, for each shard, a set of 100 validators get selected as attestors. The header of a block, together with at least 67 of the attesting signatures, can be published as an object that gets included in the “main chain” (also called the beacon chain).

Note that there are now several “levels” of nodes that can exist in such a system:

  • Super-full node – downloads the full data of the beacon chain and every shard block referenced in the beacon chain.
  • Top-level node – processes the beacon chain blocks only, including the headers and signatures of the shard blocks, but does not download all the data of the shard blocks.
  • Single-shard node – acts as a top-level node, but also fully downloads and verifies every collation on some specific shard that it cares more about.
  • Light node – downloads and verifies the block headers of main chain blocks only; does not process any collation headers or transactions unless it needs to read some specific entry in the state of some specific shard, in which case it downloads the Merkle branch to the most recent collation header for that shard and from there downloads the Merkle proof of the desired value in the state.

What is the merge?

It’s important to remember that initially, the Beacon Chain shipped separately from Mainnet – the chain we use today. Ethereum Mainnet continues to be secured by proof-of-work, even while the Beacon Chain runs in parallel using proof-of-stake. The merge is when these two systems finally come together.

Imagine Ethereum is a space ship that isn’t quite ready for an interstellar voyage. With the Beacon Chain the community has built a new engine and a hardened hull. When it’s time, the current ship will dock with this new system, merging into one ship, ready to put in some serious lightyears and take on the universe.

Merging with Mainnet

When ready, Ethereum Mainnet will “merge” with the Beacon Chain, becoming its own shard which uses proof-of-stake instead of proof-of-work.

Mainnet will bring the ability to run smart contracts into the proof-of-stake system, plus the full history and current state of Ethereum, to ensure that the transition is smooth for all ETH holders and users.

After the merge

This will signal the end of proof-of-work for Ethereum and start the era of a more sustainable, eco-friendly Ethereum. At this point Ethereum will be one step closer to achieving the full scale, security and sustainability outlined in its Eth2 vision.

It is important to note that an implementation goal of the merge is simplicity in order to expedite the transition from proof-of-work to proof-of-stake. Developers are focusing their efforts on this transition, and minimizing additional features that could delay this goal.

This means a few features, such as the ability to withdraw staked ETH, will have to wait a little longer after the merge is complete. Plans include a post-merge “cleanup” upgrade to address these features, which is expected to happen very soon after the merge is completed.

Relationship between upgrades

The Eth2 upgrades are all somewhat interrelated. So let’s recap how the merge relates to the other upgrades.

The merge and the Beacon Chain

Once the merge happens, stakers will be assigned to validate the Ethereum Mainnet. Mining will no longer be required so miners will likely invest their earnings into staking in the new proof-of-stake system.The Beacon Chain

The merge and the post-merge cleanup

Immediately after the merge, some features such as withdrawing staked ETH, will not yet be supported. These are planned for a separate upgrade to follow shortly after the merge.

Stay up-to-date with the EF Research and Development Blog. For those curious, learn more about What Happens After the Merge, presented by Vitalik at the April 2021 ETHGlobal event.

The merge and shard chains

Originally, the plan was to work on shard chains before the merge – to address scalability. However, with the boom of layer 2 scaling solutions, the priority has shifted to swapping proof-of-work to proof-of-stake via the merge.

This will be an ongoing assessment from the community as to the need for potentially multiple rounds of shard chains to allow for endless scalability.

On Friday the 20th we had a very minor incident on the Beacon Chain. It’s only the second interesting incident in the chain’s nine month life so far. Honestly, if the chain didn’t run near-perfectly most of the time, I doubt we would even have noticed anything was up.

The summary is that one of Lido’s providers, that manages around 4000 validators (~2% of the total network), was suffering degraded service and producing a lot of orphaned blocks. This reduced the total block space available for including attestations, so a small number of attestations was getting dropped and not included on chain. The result was some (very) minor penalties for validators, and a drop in overall participation rate of a percent or two. Nothing dramatic. On further study it turned out that the problem had been amplified by (1) Prysm not handling the orphaned block situation correctly, and (2) Prysm also being the dominant client on the network.

Check the following write-ups for more info:

  • My initial tweet thread explainer. Don’t miss the fork.
  • Lido’s own Postmortem with lots of info about the root cause on their side. [Aside: why do we call it a postmortem? Nothing died.]
  • A detailed data analysis of the incident from Shyam Sridhar of the Ethereum Foundation’s Robust Incentives Group

Layer 2 Scaling

This category of off-chain solutions derives its security from Mainnet Ethereum.

Most layer 2 solutions are centered around a server or cluster of servers, each of which may be referred to as a node, validator, operator, sequencer, block producer, or similar term. Depending on the implementation, these layer 2 nodes may be run by the individuals, businesses or entities that use them, or by a 3rd party operator, or by a large group of individuals (similar to Mainnet). Generally speaking, transactions are submitted to these layer 2 nodes instead of being submitted directly to layer 1 (Mainnet). For some solutions the layer 2 instance then batches them into groups before anchoring them to layer 1, after which they are secured by layer 1 and cannot be altered. The details of how this is done vary significantly between different layer 2 technologies and implementations.

A specific layer 2 instance may be open and shared by many applications, or may be deployed by one project and dedicated to supporting only their application.

Ethereum’s L1 (sharding) and L2 solutions (plasma, state channels, truebit)

  1. Polkadot:

Polkadot and Ethereum 2.0

Polkadot and Ethereum 2.0 are both sharded blockchain protocols. As such, they provide scalability by executing transactions in separate shards and provide a protocol to send messages between shards.


The shards in Ethereum 2.0 all have the same state transition function (STF), as in the rules governing how the blockchain can change state with each block. This STF provides an interface for smart contract execution. Contracts exist on a single shard and can send asynchronous messages between shards.

Likewise, in Polkadot, each shard hosts core logic, the shards are executed in parallel, and Polkadot can send cross-shard asynchronous messages. However, each Polkadot shard (in Polkadot terminology, “parachain“) has a unique STF. Applications can exist either within a single shard or across shards by composing logic. Polkadot uses WebAssembly (Wasm) as a “meta-protocol”. A shard’s STF can be abstract as long as the validators on Polkadot can execute it within a Wasm environment. Polkadot will support smart contracts through parachains. To offer some perspective, on Ethereum, smart contracts can call each other synchronously in the same shard and asynchronously between shards. On Polkadot, smart contracts will be able to call each other synchronously in the same parachain and asynchronously across parachains.


Ethereum 2.0#

Ethereum 2.0’s main chain is called the Beacon Chain. The primary load on the Beacon Chain is attestations, which are votes on the availability of shard data and Beacon Chain validity. Each shard in Ethereum 2 is simply a blockchain with the Ethereum Wasm (eWasm) interface.

Ethereum 2.0 launched phase 0 of a multi-phase rollout in December 2020, operating in parallel to the legacy Ethereum 1.0 chain:

  • Phase 0 provisioned the Beacon Chain, accepting deposits from validators and implementing proof-of-stake consensus, eventually among many shards.
  • Phase 1 launches 64 shards as simple chains, to test the Beacon Chain’s finality. Each shard submits “crosslinks” to the Beacon Chain, which contains the information to finalize shard data.
  • Phase 1.5 integrates Eth 1 as a shard to finalize the proof-of-work chain’s blocks.
  • Phase 2 implements the eWasm interface, phasing out proof-of-work, finally making the system usable to end-users. [1]

After the launch of the Beacon Chain in phase 0, the roadmap was altered to prioritize the transition of the legacy Ethereum 1.0 chain from Proof-of-Work to Ethereum 2.0’s Proof-of-Stake consensus, preceding the rollout of shards on the network. [2]

The network will also have “side chains” to interact with chains that are not under the finality protocol of Ethereum 2.0.


Like Ethereum 2.0, Polkadot also has a main chain, called the Relay Chain, with several shards, called parachains. Parachains are not restricted to a single interface like eWasm. Instead, they can define their own logic and interface, as long as they provide their STF to the Relay Chain validators so that they can execute it.

Polkadot, now live as a Relay Chain, only plans to launch the ability to validate up to 20 shards per block, gradually scaling up to 100 shards per block. Besides parachains, which are scheduled for execution every block, Polkadot also has parathreads, which are scheduled on a dynamic basis. This allows chains to share the sharded slots, much like multiple small airlines might share a gate at an airport.

In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has bridge parachains that offer two-way compatibility.


Both Ethereum 2.0 and Polkadot use hybrid consensus models where block production and finality each have their own protocol. The finality protocols – Casper FFG for Ethereum 2.0 and GRANDPA for Polkadot – are both GHOST-based and can both finalize batches of blocks in one round. For block production, both protocols use slot-based protocols that randomly assign validators to a slot and provide a fork choice rule for unfinalized blocks – RandDAO/LMD for Ethereum 2.0 and BABE for Polkadot.

There are two main differences between Ethereum 2.0 and Polkadot consensus:

  1. Ethereum 2.0 finalizes batches of blocks according to periods of time called “epochs”. The current plan is to have 32 blocks per epoch, and finalize them all in one round. With a predicted block time of 12 seconds, this means the expected time to finality is 6 minutes (12 minutes maximum). [3] Polkadot’s finality protocol, GRANDPA, finalizes batches of blocks based on availability and validity checks that happen as the proposed chain grows. The time to finality varies with the number of checks that need to be performed (and invalidity reports cause the protocol to require extra checks). The expected time to finality is 12-60 seconds.
  2. Ethereum 2.0 requires a large number of validators per shard to provide strong validity guarantees. Polkadot can provide stronger guarantees with fewer validators per shard. Polkadot achieves this by making validators distribute an erasure coding to all validators in the system, such that anyone – not only the shard’s validators – can reconstruct a parachain’s block and test its validity. The random parachain-validator assignments and secondary checks performed by randomly selected validators make it impossible for the small set of validators on each parachain to collude.

Staking Mechanics#

Ethereum 2.0 is a proof-of-stake network that requires 32 ETH to stake for each validator instance. Validators run a primary Beacon Chain node and multiple validator clients – one for each 32 ETH. These validators get assigned to “committees”, which are randomly selected groups to validate shards in the network. Ethereum 2.0 relies on having a large validator set to provide availability and validity guarantees: They need at least 111 validators per shard to run the network and 256 validators per shard to finalize all shards within one epoch. With 64 shards, that’s 16_384 validators (given 256 validators per shard). [4][5]

Polkadot can provide strong finality and availability guarantees with much fewer validators. Polkadot uses Nominated Proof of Stake (NPoS) to select validators from a smaller set, letting smaller holders nominate validators to run infrastructure while still claiming the rewards of the system, without running a node of their own. Polkadot plans to have 1_000 validators by the end of its first year of operation, and needs about ten validators for each parachain in the network.


Every shard in Ethereum 2.0 has the same STF. Each shards will submit “crosslinks” to the beacon chain and implement an eWasm execution environment. EWasm is a restricted subset of Wasm for contracts in Ethereum. The eWasm interface provides a set of methods available to contracts. There should be a similar set of development tools like Truffle and Ganache to develop for eWasm. [7]

Every shard in Polkadot has an abstract STF based on Wasm. Each shard can expose a custom interface, as long as the logic compiles to Wasm and the shard provides an “execute block” function to Polkadot validators. Polkadot has the Substrate development framework that allows full spectrum composability with a suite of modules that can be configured, composed, and extended to develop a chain’s STF.

Message Passing#

Shards in Ethereum 2.0 will have access to each other’s state via their crosslinks and state proofs. In the model of Ethereum 2.0 with 64 shards, each one posts a crosslink in the Beacon Chain for every block, [4] meaning that shards could contain logic that executes based on some light client proof of a transaction on another shard. [8] Ethereum 2.0 has not released a specification for which nodes pass messages between shards.

Polkadot uses Cross-Chain Message Passing (XCMP) for parachains to send arbitrary messages to each other. Parachains open connections with each other and can send messages via their established channels. Given that collators will need to be full nodes of the Relay Chain as well, they will be connected and will be able to relay messages from parachain A to parachain B.. Messages do not pass through the Relay Chain, only proofs of post and channel operations (open, close, etc.) go into the Relay Chain. This enhances scalability by keeping data on the edges of the system.

Polkadot will add a protocol called SPREE that provides shared logic for cross-chain messages. Messages sent with SPREE carry additional guarantees about provenance and interpretation by the receiving chain.


Ethereum 2.0 governance is still unresolved. Ethereum currently uses off-chain governance procedures like Github discussions, All Core Devs calls, and Ethereum Magicians to make decisions about the protocol. [9]

Polkadot uses on-chain governance with a multicameral system. There are several avenues to issue proposals, e.g. from the on-chain Council, the Technical Committee, or from the public. All proposals ultimately pass through a public referendum, where the majority of tokens can always control the outcome. For low-turnout referenda, Polkadot uses adaptive quorum biasing to set the passing threshold. Referenda can cover a variety of topics, including fund allocation from an on-chain Treasury or modifying the underlying runtime code of the chain. Decisions get enacted on-chain and are binding and autonomous.


Upgrades on Ethereum 2.0 will follow the normal hard-fork procedure, requiring validators to upgrade their nodes to implement protocol changes.

Using the Wasm meta-protocol, Polkadot can enact chain upgrades and successful proposals without a hard fork. Anything that is within the STF, the transaction queue, or off-chain workers can be upgraded without forking the chain.


Ethereum 2.0 and Polkadot both use a sharded model where shard chains (“shards” in Ethereum 2.0 and “parachains/parathreads” in Polkadot) are secured by a main chain by linking shard state in the blocks of the main chains. The two protocols differ in a few main areas. First, all shards in Ethereum 2.0 has the same STF, while Polkadot lets shards have an abstract STF. Second, governance processes in Ethereum 2.0 are planned to be off-chain and thus require coordination for a hard fork to enact governance decisions, while in Polkadot the decisions are on-chain and enacted autonomously. Third, the validator selection mechanisms are different because Polkadot can provide strong availability and validity guarantees with a smaller number of validators per shard.


Others say on background that while they understand the developer benefits and need for more scaleable blockchains than Ethereum, Solana still needs more developer mindshare to prove its long-term worth and it’s not there yet. According to Solana itself, there are currently 608 validators helping secure the Solana Network and 47 decentralized applications (or “dapps”) powered by Solana. Meanwhile, there were reportedly 33,700 active validators helping to secure “Eth 2.0” as of late December and 3,000 dapps running on the Ethereum blockchain as of February.

In fairness, the Ethereum network went live in 2015, so it has a three-year head start on Solana. In the meantime, Solana has a lead of its own, says Yakovenko, who is based in San Francisco and has assembled a distributed team of 50 employees, including numerous former Qualcomm colleagues. Asked about other projects that have embraced a proof-of-history approach, he says that while it’s “all open source” and “anybody can go do it,” there “isn’t a set of our biggest competitors saying they’re going to rework their system and use this.”

One likely reason is that it’s almost comically complicated. “It just takes a lot of work to build these systems,” Yakovenko says. “It takes two to three years to build a new layer one, and you can’t really take an idea for one and stuff it in the other one. If you try to do that, you’re going to set yourself back by six to nine months at the least and potentially introduce bugs and vulnerabilities.”

Either way, Solana, which itself has a $12 billion market cap, isn’t interested in competing with Ethereum and other cryptocurrencies on every front, suggests Yakovenko. All it really wants is to completely disrupt Wall Street and the rest of the global markets.

He knows it sounds crazy. But the way he sees it, what Solana is building is “an open, fair, censorship-resistant global marketplace” that’s better than anything inside of the New York Stock Exchange or any other means of settling trades. It’s certainly a much bigger opportunity than he imagined backed at that cafe.