So what is a commit chain? How is it different from a sidechain? And what makes Polygon Commit Chain a commit chain rather than a sidechain? We’ll answer all of these questions in this article. 

Let’s start with understanding what exactly a sidechain is. 

Sidechain 

A sidechain, in essence, is a separate blockchain that can be used as one of the ways of scaling a Layer 1 blockchain such as Ethereum or Bitcoin. As the name suggests, a sidechain runs in parallel or “on the side” of the main chain. 

Sidechains have their own consensus mechanisms usually in the form of Proof-Of-Stake, Delegated-Proof-Of-Stake or Proof-Of-Authority. 

Sidechains allow users to send their tokens from the main chain and receive them on the sidechain. Once the funds are transferred to the sidechain they can be used within the sidechain ecosystem. Similarly, users can withdraw their tokens from a sidechain back to the main chain. The whole process is called a 2-way peg or a 2-way bridge. Thing to note is that once the user tokens are on the sidechain then they are completely reliant on the consensus mechanism of the sidechain

Initially, all scaling solutions such as sidechains, Plasma and rollups were classified as Layer 2 solutions as they are built on top of Layer 1. 

After a while, the Ethereum community started differentiating between scaling solutions fully secured by the Ethereum main chain – Layer 2 and other scaling options with their own consensus mechanisms – sidechains. At the moment, pretty much all scaling solutions are classified as either one or the other. 

When it comes to Polygon Commit Chain, it is worth differentiating it from a sidechain as it has a lot of extra features that rely on the security of the main Ethereum layer.

Let’s review them one by one. 

Permissionless Validators on Ethereum

Many sidechains use a consensus mechanism that limits the number of entities able to verify the chain. For example, in a Delegated-Proof-Of-Stake (DPoS) there are usually 21 validators who are chosen by the token holders and only these validators are able to validate the state of the blockchain. Similarly, in a Proof-Of-Authority (PoA) model the chain initiator chooses authorities to run the chain. This excludes most participants and creates a situation where only a selected few are responsible for making sure the transactions are validated correctly.  

In Polygon PoS Chain anyone can join the network and start validating the state of the blockchain. This is important as it allows any participants to become validators and check by themselves that all transactions are processed correctly. 

Validators on Polygon PoS Chain have to stake their MATIC tokens and run a full node. 

MATIC tokens are staked on the Ethereum main chain. This is also where the set of all validators is maintained. If a validator starts acting in a malicious way, for example, by double signing or having a significant downtime their stake is slashed.  

This is also a good time to introduce 2 core components of the Polygon PoS Chain architecture – Heimdall Chain and Bor Chain.

Heimdall & Bor

Heimdall works in conjunction with the Stake Manager contract deployed on the Ethereum mainnet to coordinate validator selection and updating validators.

Since staking is actually done on the Ethereum smart contract, we don’t have to rely on validator honesty and instead inherit Ethereum chain security for this key part. Even if a majority of validators collude and start acting maliciously, the community can come together and redeploy the contracts on Ethereum to fork out, i.e. slash the malicious validators, and the chain can continue to operate as intended. 

Heimdall is also responsible for checkpointing – more on this later in the article. 

Bor is the block producer layer of the PoS Chain architecture that is responsible for aggregating transactions into blocks. 

Bor block producers are a subset of the validators that are periodically shuffled by the Heimdall validators. Block producers are selected to validate blocks only for a set number of blocks, also called “span”. After this time period, the selection process is triggered again. 

Let’s have a closer look at the process of selecting block producers

1. Let’s suppose we have 3 validators in the pool, and they are Alice, Bill and Clara.
2. Alice staked 100 MATIC tokens whereas Bill and Clara staked 40 MATIC tokens each.
3. Validators are given slots according to their stake, as Alice has 100 MATIC tokens staked, and there are 10 tokens per slot (maintained by validator’s governance), Alice will get 5 slots in total. Similarly, Bill and Clara get 2 slots in total.
4. All the validators are given these slots [ A, A, A, A, A, B, B, C, C ]
5. Using the historical Ethereum blocks as a seed we shuffle this array.
6. After shuffling the slots using the seed we get this array [ A, B, A, A, C, B, A, A, C]
7. Now depending on Producer count(maintained by validator’s governance), we pop validators from the top, for eg if we want to select 5 producers we get the producer set as [ A, B, A, A, C]
8. Hence the producer set for the next span is defined as [ A: 3, B:1, C:1 ].
9. Using this validator set and Tendermint’s proposer selection algorithm we choose a producer for every sprint on Bor.

This model allows anyone to participate in securing the network with any amount of MATIC tokens. It also doesn’t sacrifice the speed of transaction as not all validators have to validate blocks all the time. 

Let’s go back to the other important function of Heimdall – checkpointing. 

Checkpointing 

Checkpoints are important as they provide finality on the Ethereum chain.

Heimdall layer allows for aggregating blocks produced by Bor into a single Merkle root and periodically publishing it to the Ethereum main chain. This published state is also called a checkpoint hence the whole process is known as checkpointing. 

Checkpoint proposers are initially selected via Tendermint’s weighted round-robin algorithm. A further custom check is implemented based on the success of checkpoint submission. This allows Polygon PoS Chain to decouple from Tendermint proposer selection and provides it with abilities like selecting a proposer only when the checkpoint transaction on the Ethereum mainnet succeeds or submitting a checkpoint transaction for previous blocks if the checkpoint transaction failed. 

Submitting a checkpoint on Tendermint is a 2-phase commit process. A proposer, selected via the above-mentioned algorithm, sends a checkpoint with their address in the proposer field and all other proposers validate it.

The next proposer then sends an acknowledgement transaction to prove that the previous checkpoint transaction has succeeded on the Ethereum mainnet. Every Validator set change will be relayed by the validator node on Heimdall which is embedded onto the validator node. This allows Heimdall to remain in sync with the Polygon contract state on the Ethereum mainchain at all times.

The Polygon PoS Chain contract deployed on the main chain is considered to be the ultimate source of truth, and therefore all validation is done via querying the Ethereum main chain contract.

Checkpoints also provide “proof of burn” in the withdrawal of assets. 

Speaking about withdrawals, let’s have a look at another important element of the PoS chain – the two-way Ethereum Bridge.

Two-way Ethereum Bridge

Typical two-way bridges rely on a small set of authorities which are often not even staked, nor part of the sidechains’s validators set – basically bridges are often operated, i.e. controlled by several PoA signers. This is a significant security concern.,. 

Polygon provides 2 separate ways for moving assets between Ethereum and Polygon – Plasma Bridge and the PoS Bridge.

Plasma Bridge provides increased security guarantees due to the Plasma exit mechanism. However, there is a 7-day withdrawal period associated with all exits/withdrawals caused by certain restrictions in the Plasma architecture. 

The PoS Bridge doesn’t have this restriction and it is secured by a robust set of validators that we discussed earlier in this article. The state of these validators is maintained on the Ethereum mainnet and they are secured by all the funds staked in the system – around $500M at the time of writing this article. To the best of our knowledge, the PoS bridge is the only bridge secured by the whole validator set of a bridged chain; bridges are normally secured by a small set of PoA signers, as already mentioned earlier. 

As we can see, Polygon PoS Chain offers a lot of extra security measures based on the Ethereum main chain and it is not just a mere sidechain. Perhaps, a commit chain is a better name for it. 

So what do you think about Polygon Commit Chain? Do you think it’s valuable to differentiate it from a sidechain?

If you enjoyed reading this article you can also check out Finematics on Youtube and Twitter.

So what is Ethereum Layer 2 scaling all about? And what is the difference between projects such as Optimism, xDai, OMG and Loopring? We’ll answer all of these questions in this article. 

Need For Scaling

Ethereum scaling has been one of the most discussed topics pretty much since the time when the network launched. The scaling debate always heats up after a period of major network congestion. 

One of the first periods like this was the 2017 crypto bull market where infamous CryptoKitties, together with ICOs, were able to clog up the entire Ethereum network causing a major spike in the gas fees. 

This year the network congestion came back even stronger, this time caused by the popularity of DeFi and yield farming. There were periods of time when even gas fees as high as 500+ gwei would not get your transaction verified for a while. 

When it comes to scaling Ethereum or blockchains in general, there are 2 major ways of doing it: scaling the base layer itself (Layer 1) or scaling the network by offloading some of the work to another layer – Layer 2. 

Layers 1 vs Layer 2 Scaling 

Layer 1 is our standard base consensus layer where pretty much all transactions are currently settled. The concept of layers is not an Ethereum-specific concept. Other blockchains such as Bitcon or Zcash also use it extensively.   

Layer 2 is another layer built on top of Layer 1. There are a few important points here. Layer 2 doesn’t require any changes in Layer 1, it can be just built on top of Layer 1 using its existing elements such as smart contracts. Layer 2 also leverages the security of Layer 1 by anchoring its state into Layer 1.

Ethereum can currently process around 15 transactions per second on its base layer (Layer 1). Layer 2 scaling can dramatically increase the number of transactions. Depending on the solution, we’re talking about processing between 2000-4000 tx/second. 

How about Ethereum 2.0? Wasn’t that supposed to scale Ethereum? 

Yes. Ethereum 2.0 introduces Proof of Stake and sharding that will dramatically increase the transaction throughput on the base layer. 

Does it mean we don’t need Layer 2 scaling when Ethereum 2.0 ships? 

Not really, even with sharding Ethereum will still need Layer 2 scaling to be able to handle hundreds of thousands or even millions of tx per second in the future. 

This is also where the famous Scalability Trilemma comes into play. In theory, we could just skip Layer 2 entirely and focus on scaling the base layer instead. This would require highly specialized nodes to handle the increased workload which would lead to higher centralization and, therefore, lowering security and censorship-resistant properties of the network. 

Sticking to the fact that scalability should never come at the expense of security and decentralization, we are left with a combination of Layer 1 and Layer 2 scaling going forward into the future. 

Layer 2 Scaling Solutions

Layer 2 scaling is a collective term for solutions that help with increasing the capabilities of Layer 1 by handling transactions off-chain (off Layer 1). The 2 main capabilities that can be improved are transaction speed and transaction throughput. On top of that, Layer 2 solutions can greatly reduce the gas fees. 

When it comes to actual scaling solutions there are multiple options available. Whilst some of the options are available right now and can increase Ethereum network throughput in the near to medium-term, others are aiming for a medium to long-term time horizon.  

Some of the scaling solutions are application-specific, for example, payment channels. Others, such as optimistic rollups, can be used for any arbitrary contract executions.

To understand these differences better let’s explore the most popular Layer 2 scaling solutions.

Channels

Channels are one of the first widely discussed scaling solutions. They allow participants to exchange their transactions off-chain a number of times while only submitting two transactions to the base layer.  

The most popular types of channels are state channels and their subtype – payment channels.

Although channels have the potential to easily process thousands of transactions per second, they come with a few downsides. They don’t offer open participation – participants have to be known upfront and users have to lock up their funds in a multisig contract. On top of that, this scaling solution is application-specific and cannot be used to scale general-purpose smart contracts. 

The main project that leverages the power of state channels on Ethereum is Raiden. The concept of payment channels is also extensively used by Bitcoin’s Lightning Network. 

Plasma

Plasma is a Layer 2 scaling solution that was originally proposed by Joseph Poon and Vitalik Buterin. It’s a framework for building scalable applications on Ethereum.

Plasma leverages the use of smart contracts and Merkle trees to enable the creation of an unlimited number of child chains – copies of the parent Ethereum blockchain. 

Offloading transactions from the main chain into child chains allows for fast and cheap transactions. One of the drawbacks of Plasma is a long waiting period for users who want to withdraw their funds from Layer 2. Plasma, similarly to channels, cannot be used to scale general-purpose smart contracts.

The OMG Network is built on their own implementation of Plasma, called MoreViable Plasma. Matic Network is another example of a platform using an adapted version of the Plasma framework. 

Sidechains 

Sidechains are Ethereum-compatible, independent blockchains with their own consensus models and block parameters.

Interoperability with Ethereum is made possible by using the same Ethereum Virtual Machine, so contracts deployed to the Ethereum base layer can be directly deployed to the sidechain. xDai is an example of such a sidechain. 

Rollups 

Rollups provide scaling by bundling or “rolling up” sidechain transactions into a single transaction and generating a cryptographic proof, also known as a SNARK (succinct non-interactive argument of knowledge). Only this proof is submitted to the base layer. 

With rollups, all transaction state and execution are handled in sidechains. The main Ethereum chain only stores transaction data. 

There are 2 types of rollups: Zk rollups and optimistic rollups. 

Zk rollups, although faster and more efficient than optimistic rollups, do not provide an easy way for the existing smart contracts to migrate to Layer 2. 

Optimistic rollups run an EVM compatible Virtual Machine called OVM (Optimistic Virtual Machine) which allows for executing the same smart contracts as can be executed on Ethereum. This is really important as it makes it easier for the existing smart contracts to maintain their composability, which is extremely relevant in DeFi where all major smart contracts were already battle-tested.  

One of the main projects working on optimistic rollups is Optimism, which is getting closer and closer to their mainnet launch. 

When it comes to Zk rollups, Loopring and Deversifi are good examples of decentralized exchanges built on Layer 2. On top of that we have ZkSync enabling scalable crypto payments.

Rollups’s scalability can also be magnified by Ethereum 2.0. In fact, because rollups only need the data layer to be scaled, they can get a tremendous boost already in Ethereum 2.0 Phase 1 which is about the sharding of data.

Summary

Despite a spectrum of Layer 2 scaling solutions available, it looks like the Ethereum community is converging on the approach of mainly scaling through rollups and Ethereum 2.0 Phase 1 data sharding. 

This approach was also confirmed in a recent post by Vitalik Buterin called “A rollup centric Ethereum roadmap” that I will link in the description box below. 

In our future articles, we’ll explore the base layer scaling with Ethereum 2.0 and how both layer 1 and layer 2 scaling can help with making decentralized finance more accessible to everyone. Stay tuned by subscribing to the channel. 

So what do you think about Ethereum’s approach to scaling? And which scaling solution would you like to learn more about?

If you enjoyed reading this article you can also check out Finematics on Youtube and Twitter.