In a world where Ethereum is the King of smart contract platforms, we need a Queen. As it is on a Chess board, the King is slow and moves little steps, but it is the most important Chess piece. On the other hand, the Queen is pretty fast; she can travel to any square almost freely.

The Ethereum blockchain is slow, and due to this slowness, gas fees can be very high from time to time. So, some people began to introduce layer-2s. Layer-2s are smart contract platforms that may or may not be a blockchain themselves. These platforms are much faster, much lighter, and, most crucially, much cheaper. Despite all the differences, almost all of them have one similar point. They all rely on the Ethereum blockchain and serve as a layer-2 to the King.

Since the Ethereum blockchain is slow, we need a way to scale it. Some scaling solutions directly affect the Ethereum blockchain itself, and some are happening out of this platform. Meaning that we can make the Ethereum blockchain faster and cheaper, or we can take some calculations out of the blockchain, compute them somewhere else, and finally give the result back to the Ethereum blockchain. This technique is called “Layer-2.”

Lots of different techniques to create layer-2s exist:

• Rollups

  • Optimistic

  • Zero-Knowledge

• State Channels

• Sidechains

• Plasmas

• Validiums

These different layer-2 solutions have different functionalities and ways of working. We will describe only some of them here since all of them are not a priority to understand the Polygon PoS chain and Plasma Chain. But, Polygon, as a whole, uses almost all of them in various products. As much as Polygon works on different products, one can say that Polygon wants the future of layer-2 technology all to itself.

To understand just two very related products of Polygon, we need to establish two layer-2 technologies: Sidechains and Plasmas.

A sidechain is a separate blockchain that runs independently of Ethereum and is connected to Ethereum Mainnet by a two-way bridge. Sidechains can have separate block parameters and consensus algorithms, often designed to process transactions efficiently. Using a sidechain involves trade-offs, though, as they do not inherit Ethereum's security properties. Unlike layer-2 scaling solutions, sidechains do not post state changes and transaction data back to Ethereum Mainnet.

Sidechains also sacrifice some measure of decentralization or security to achieve high throughput (scalability trilemma).

Scalability Trilemma

As Vitalik Buterin, co-founder of the Ethereum blockchain, stated: “there are three properties that a blockchain tries to have, and that if you stick to “simple” techniques, you can only get two of those three.” These three properties are:

• Scalability: The blockchain needs to process more transactions per second as the number of users soars. This must be so that the transaction fee does not increase dramatically.

• Decentralization: The blockchain must run without the need for trust. Meaning that no centralized authority is in charge of creating and submitting transactions, and a decentralized network is in charge of such work. This way, the need for trust in one centralized authority is diminished.

• Security: The blockchain must be resistant to the attack of a large number of peers, ideally 50%. Because this attack can risk the security of people's funds since a double-spending attack would be enabled.

Now, let us take a look at three classes of “easy solutions,” as Vitalik proposed:

• Traditional blockchains: including Bitcoin, pre-PoS/sharding Ethereum, Litecoin, and other similar chains. These rely on every participant running a full node that verifies every transaction; hence they have decentralization and security but not scalability.

• High-TPS chains: including the DPoS family, but also many others. These rely on a small number of nodes (often 10-100) maintaining consensus among themselves, with users having to trust a majority of these nodes. This is scalable and secure (using the definitions above), but it is not decentralized.

• Multi-chain ecosystems: this refers to the general concept of “scaling out” by having different applications live on different chains and using cross-chain-communication protocols to talk between them. This is decentralized and scalable, but it is not secure because an attacker need only get a consensus node majority in one of the many chains (so often <1% of the whole ecosystem) to break that chain and possibly cause ripple effects that cause great damage to applications in other chains.

Now that we are familiar with the scalability trilemma, it is time to get back to sidechains and how they work.

Sidechains are independent blockchains with different histories, development roadmaps, and design considerations. While a sidechain may share some surface-level similarities with Ethereum, it has several distinctive features.

Consensus Algorithms

One of the qualities that make sidechains unique (i.e., different from Ethereum) is the consensus algorithm used. Sidechains don't rely on Ethereum for consensus and can choose alternative consensus protocols that suit their needs. Some examples of consensus algorithms used on sidechains include:

• Proof-of-authority (PoA),

• Delegated proof-of-stake (DPoS),

• Byzantine fault tolerance (BFT).

Like Ethereum, sidechains have validating nodes that verify and process transactions, produce blocks, and store the blockchain state. Validators are also responsible for maintaining consensus across the network and securing it against malicious attacks.

Block Parameters

Ethereum places limits on block times (i.e., the time it takes to produce new blocks) and block sizes (i.e., the amount of data contained per block denominated in gas). Conversely, sidechains often adopt different parameters, such as faster block times and higher gas limits, to achieve high throughput, fast transactions, and low fees.

While this has some benefits, it has critical implications for network decentralization and security. Block parameters, like fast block times and big block sizes, increase the difficulty of running a full node—leaving a few “supernodes” responsible for securing the chain. In such a scenario, the possibility of validator collusion or a malicious takeover of the chain increases.

For blockchains to scale without harming decentralization, running a node must be open to everyone—not necessarily parties with specialized hardware. This is why efforts are underway to ensure everyone can run a full node on the Ethereum network.

EVM Compatibility

Some sidechains are EVM-compatible and are able to execute contracts developed for the Ethereum Virtual Machine (EVM). EVM-compatible sidechains support smart contracts written in Solidity, as well as other EVM smart contract languages, which means smart contracts written for Ethereum Mainnet will also work on EVM-compatible sidechains.

This means if you want to use your dApp on a sidechain, it's just a matter of deploying your smart contract to this sidechain. It looks, feels, and acts just like Mainnet—you write contracts in Solidity and interact with the chain via the sidechains RPC.

Because sidechains are EVM-compatible, they are considered a useful scaling solution for Ethereum-native dapps. With your dapp on a sidechain, users can enjoy lower gas fees and faster transactions, especially if Mainnet is congested.

However, as explained previously, using a sidechain involves significant trade-offs. Each sidechain is responsible for its security and doesn't inherit Ethereum's security properties. This increases the possibility of malicious behavior affecting your users or putting their funds at risk.

As an important point, it is good to notice that all layer-2 sidechains are EVM-compatible since they are layer-2s for the Ethereum blockchain and must be compatible with its needs.

Asset Movements

In order for a separate blockchain to become a sidechain to Ethereum Mainnet, it requires the ability to facilitate the transfer of assets from and to Ethereum Mainnet. This interoperability with Ethereum is achieved using a blockchain bridge. Bridges use smart contracts deployed on Ethereum Mainnet and a sidechain to control the bridging of funds between them.

While bridges help users move funds between Ethereum and the sidechain, the assets are not physically moved across the two chains. Instead, mechanisms that typically involve minting and burning are used for transferring value across chains.

Pros and Cons of Sidechains

A Plasma chain is a separate blockchain anchored to Ethereum Mainnet but executing transactions off-chain with its own mechanism for block validation. Plasma chains are sometimes referred to as “child” chains, essentially smaller copies of the Ethereum Mainnet. Plasma chains use fraud proofs (like optimistic rollups) to arbitrate disputes.

Merkle trees enable the creation of an endless stack of these chains that can work to offload bandwidth from parent chains (including Ethereum Mainnet). However, while these chains derive some security from Ethereum (via fraud proofs), their security and efficiency are affected by several design limitations.

Plasma chains are built atop another blockchain (called a “root chain”). Each “child chain” extends from the root chain and is generally managed by a smart contract deployed on the parent chain.

The Plasma contract functions, among other things, as a bridge allowing users to move assets between Ethereum Mainnet and the plasma chain. Although this makes them similar to sidechains, plasma chains benefit—at least to some extent—from Ethereum Mainnet's security. This is unlike sidechains that are solely responsible for their security.

Some basic components of the Plasma framework are:

• Off-chain computation: Ethereum's current processing speed is limited to ~ 15–20 transactions per second, reducing the short-term possibility of scaling to handle more users. This problem exists mainly because Ethereum's consensus mechanism requires many peer-to-peer nodes to verify every update to the blockchain's state.

  Although Ethereum's consensus mechanism is necessary for security, it may not apply to every use case. For example, Alice may not need her daily payments to Bob for a cup of coffee verified by the entire Ethereum network since some trust exists between both parties.

  Plasma supposes that Ethereum Mainnet doesn't need to verify all transactions. Instead, we can process transactions off Mainnet, freeing nodes from having to validate every transaction.

  Off-chain computation is necessary since Plasma chains can optimize for speed and cost. For example, a Plasma chain may—and most often does—use a single “operator” to manage the ordering and execution of transactions. With just one entity verifying transactions, processing times on a plasma chain are faster than Ethereum Mainnet.

• State commitments: While Plasma executes transactions off-chain, they are settled on the main Ethereum execution layer—otherwise, Plasma chains cannot benefit from Ethereum's security guarantees. But finalizing off-chain transactions without knowing the state of the plasma chain would break the security model and allow the proliferation of invalid transactions. This is why the operator, the entity responsible for producing blocks on the plasma chain, is required to publish “state commitments” on Ethereum periodically.

  A commitment scheme is a cryptographic technique for committing to a value or statement without revealing it to another party. Commitments are “binding” in the sense that you cannot change the value or statement once you've committed to it. State commitments in Plasma take the form of “Merkle roots” (derived from a Merkle tree) which the operator sends at intervals to the Plasma contract on the Ethereum chain.

  Merkle roots are cryptographic primitives that enable compressing of large amounts of information. A Merkle root (also called a “block root” in this case) could represent all the transactions in a block. Merkle roots also make it easier to verify that a small piece of data is part of the larger dataset. For instance, a user can produce a Merkle proof to prove the inclusion of a transaction in a specific block.

  Merkle roots are important for providing information about the off-chain's state to Ethereum. You can think of Merkle roots as “save points”: the operator is saying, “This is the state of the Plasma chain at x point in time, and this is the Merkle root as proof.” The operator is committing to the current state of the plasma chain with a Merkle root, which is why it is called a “state commitment.”

Now that we know these two ideas in the layer-2 subject, it is time to introduce Polygon (Matic) and its most important products: Polygon PoS chain and Polygon Plasma.

Polygon launched as Matic Network in 2017. It was co-founded by Jaynti Kanani, Sandeep Nailwal, and Anurag Arjun to tackle blockchain scaling and usability issues.

In 2017, Plasma was at the forefront of blockchain scaling, and Matic featured a plasma-driven scaling approach and Proof-of-Stake (PoS) sidechains to assist Ethereum as user demand for the network grew. Over time, Matic POS became a prominent scaling option for various applications.

Matic rebranded to Polygon in February 2021 to become a Swiss Army knife for scaling solutions. Polygon plans to add support for rollups and Validium to its already-existing Plasma/POS chain. The project recognizes that Ethereum may not scale from a single solution in isolation.

Since the Polygon Network's core focus is on mass user adoption, it is ideal that a deep dive into the Polygon Network's technical architecture should start from a user journey.

When users transfer ETH or ERC20 tokens on the Ethereum network, they have to wait for the confirmation of the block, which ranges from 14 seconds to 20 seconds. Even then, the users have to wait for multiple block confirmations to ensure the transaction's finality. Let's say you buy a coffee or pay tokens to watch a movie. On each transaction, not only do you pay a high fee, but you also wait for it to be confirmed. That serves as a deterrent for users wanting to use the service.

Moreover, during peak loads, a large number of transactions clog the Ethereum network, and gas fees increase on each transaction in order to obtain faster confirmations. The Polygon Network is proposed as a solution to overcome these problems.

Before diving into the technology and understanding how it works, we need to understand some terminologies.

Validators

Validator is a participant in the network who locks up MATIC tokens in the system and runs Heimdall validator and Bor block producer nodes in order to help run the network (we will explain Heimdall and Bor later in this article). Validators stake their MATIC tokens as collateral to work for the security of the network and, in exchange for their service, earn rewards.

Rewards are distributed to all stakers proportional to their stake at every checkpoint, with the exception being the proposer getting an additional bonus. User reward balance gets updated in the contract, which is referred to while claiming rewards.

Stakes are at risk of getting slashed in case the validator node commits a malicious act like double signing, which also affects the linked delegators at that checkpoint.

Validators on the Polygon network are selected through an on-chain auction process, which happens at regular intervals. These selected validators participate as block producers and verifiers. Once the participants validate a checkpoint, updates are made on the parent chain (the Ethereum mainnet), which releases the rewards for validators depending on their stake in the network.

Polygon relies on a set of validators to secure the network. The role of validators is to run a full node, produce blocks, validate and participate in consensus, and commit checkpoints on the Ethereum mainnet. To become a validator, one needs to stake their MATIC tokens with staking management contracts residing on the Ethereum mainnet.

Delegators

Delegators are token holders who cannot or do not want to run a validator node themselves. Instead, they secure the network by delegating their stake to validator nodes and play a critical role in the system, as they are responsible for choosing validators. They run their delegation transaction on the staking contract on the Ethereum mainnet.

The MATIC tokens are bonded with the next checkpoint committed on the Ethereum mainnet. Delegators also have the option to opt-out of the system whenever they want. Similar to validators, delegators have to wait for the unbonding period, which consists of approximately 9 days, to end before withdrawing their stake.

Delegators stake their tokens by delegating them to a validator, obtaining a percentage of their rewards in exchange. Because delegators share rewards with their validators, delegators also share risks. Should a validator misbehave, each of their delegators is at risk of being partially slashed in proportion to their delegated stake.

Validators set a commission percentage to determine the percentage of rewards that will go to them. Delegators are able to view the commission rate of each validator to understand each validator's reward distribution and a relative rate of return on their stake.

Span

Span is a logically defined set of blocks for which a set of validators is chosen from all the available validators. The selection of each span is decided by at least 2/3 of the validators in terms of the staking power.

Proposer

A proposer is a validator selected by the algorithm to propose a new block. A proposer is also responsible for collecting all signatures for a particular checkpoint and committing the checkpoint to the Ethereum mainnet.

We can continue with Polygon architecture and its components now that we know what these terms mean in the Polygon system.

Polygon is a blockchain application platform that provides hybrid Proof-of-Stake and Plasma-enabled sidechains.

Architecturally, the beauty of Polygon is its elegant design, which features a generic validation layer separated from varying execution environments like Plasma enabled chains, full-blown EVM sidechains, and in the future, other layer-2 approaches such as Optimistic Rollups.

Polygon has some key features listed below:

• Speed: The Polygon Network uses a high-throughput blockchain with consensus provided by a group of Block Producers selected by stakeholders at each checkpoint. A Proof of Stake layer is used to validate blocks and periodically post proofs of Block Producers to the Ethereum mainnet. This enables rapid block confirmation rates of about 2 seconds while preserving a high amount of decentralization, resulting in excellent throughput for the network.

• Scalability: Polygon Network achieves a hypothetical transaction speed of fewer than 2 seconds on a single sidechain. Using multiple sidechains helps the network to handle millions of transactions per second. This mechanism (already demonstrated in the first Matic sidechain) allows the Polygon network to scale easily.

• Security: Polygon's smart contracts rely on Ethereum's security. To safeguard the network, it employs three critical security models. It uses Ethereum's staking management contracts and a group of incentivized validators running Heimdall and Bor nodes. Developers can also implement both models (Hybrid) into their dApp.

The Polygon PoS Network has a three-layer architecture:

• Ethereum layer (Staking and Plasma smart contracts): Polygon Network maintains a set of smart contracts on Ethereum, which manages staking functions and rewards for Polygon's Proof-of-Stake layer. These contracts are also responsible for delegation management (including validator shares) and Plasma contracts for MoreVP (including checkpoints/snapshots of sidechain state).

• Heimdall layer (Proof of Stake layer): a set of proof-of-stake Heimdall nodes running parallel to the Ethereum mainnet, monitoring the set of staking contracts deployed on the Ethereum mainnet and committing the Polygon Network checkpoints to the Ethereum mainnet. These nodes handle the aggregation of blocks produced by the Bor layer into a Merkle tree. It publishes the Merkle root to the root chain periodically. The Heimdall layer is based on Peppermint, a forked version of Tendermint (we'll talk about these consensus mechanisms later).

• Bor layer (Block producer layer): a set of block-producing Bor nodes shuffled by Heimdall nodes. This layer is responsible for aggregating transactions into blocks. Bor is based on Go Ethereum (Geth) with custom changes to the consensus algorithm.

Currently, developers can use Plasma for specific state transitions for which Plasma predicates have been written, such as ERC20, ERC721, asset swaps, or other custom predicates. For arbitrary state transitions, they can use PoS. Or both! This is made possible by Polygon's hybrid construction.

To enable the PoS mechanism on our platform, a set of staking management contracts are deployed on Ethereum, and a set of incentivized validators run Heimdall and Bor nodes. Ethereum is the first base chain Polygon supports, but Polygon intends to offer support for additional base chains to enable an interoperable decentralized layer-2 blockchain platform based on community suggestions and consensus.

Ethereum Layer

To enable the Proof-of-Stake (PoS) mechanism on Polygon, the system employs a set of staking management contracts on the Ethereum mainnet.

The staking contracts implement the following features:

• Anyone can stake MATIC tokens on the staking contracts on the Ethereum mainnet and join the system as a validator.

• Earn staking rewards for validating state transitions on the Polygon Network.

• Save checkpoints on the Ethereum mainnet.

The PoS mechanism also acts as a mitigation to the data unavailability problem for the Polygon sidechains.

Heimdall Layer

Heimdall is the proof of stake validation layer that handles the aggregation of blocks produced by Bor into a Merkle tree and publishes the Merkle root periodically to the root chain. The periodic publishing of snapshots of the Bor sidechain is called checkpoints.

1. Validates all the blocks since the last checkpoint.

2. Creates a Merkle tree of the block hashes.

3. Publishes the Merkle root hash to the Ethereum mainnet.

Checkpoints are important for two reasons:

1. Providing finality on the root chain.

2. Providing proof of burn in withdrawal of assets.

An overview of the process:

• A subset of active validators from the pool is selected to act as block producers for a span. These block producers are responsible for creating blocks and broadcasting the created blocks on the network.

• A checkpoint includes the Merkle root hash of all blocks created during any given interval. All nodes validate the Merkle root hash and attach their signature to it.

• A selected proposer from the validator set is responsible for collecting all signatures for a particular checkpoint and committing the checkpoint on the Ethereum mainnet.

• The responsibility of creating blocks and proposing checkpoints is variably dependent on a validator's stake ratio in the overall pool.

Tendermint Consensus Mechanisms

Tendermint is a software for securely and consistently replicating an application on many machines. By securely, we mean that Tendermint works even if up to ⅓ of machines fail in arbitrary ways. By consistently, we mean that every non-faulty machine sees the same transaction log and computes the same state. Secure and consistent replication is a fundamental problem in distributed systems; it plays a critical role in the fault tolerance of a broad range of applications, from currencies to elections, to infrastructure orchestration and beyond.

Tendermint is an easy-to-understand, mostly asynchronous, BFT consensus protocol. The protocol follows a simple state machine that looks like this:

Participants in the protocol are called validators; they take turns proposing blocks of transactions and voting on them. Blocks are committed in a chain, with one block at each height. A block may fail to be committed, in which case the protocol moves to the next round, and a new validator gets to propose a block for that height. Two voting stages are required to commit a block successfully; we call them pre-vote and pre-commit. A block is committed when more than ⅔  of validators pre-commit for the same block in the same round.

There is a picture of a couple doing the polka because validators are doing something like a polka dance. When more than two-thirds of the validators pre-vote for the same block, we call that a polka. Every pre-commit must be justified by a polka in the same round.

Validators may fail to commit a block for several reasons; the current proposer may be offline, or the network may be slow. Tendermint allows them to establish that a validator should be skipped. Validators wait a small amount of time to receive a complete proposal block from the proposer before voting to move to the next round. This reliance on a timeout makes Tendermint a weakly synchronous protocol rather than an asynchronous one. However, the rest of the protocol is asynchronous, and validators only make progress after hearing from more than two-thirds of the validator set. A simplifying element of Tendermint is that it uses the same mechanism to commit a block to skip to the next round.

Assuming less than one-third of the validators are Byzantine, Tendermint guarantees that safety will never be violated—validators will never commit conflicting blocks at the same height. To do this, it introduces a few locking rules which modulate which paths can be followed in the flow diagram. Once a validator precommits a block, it is locked on that block. Then,

1. it must pre-vote for the block it is locked on

2. it can only unlock and pre-commit for a new block if there is a polka for that block in a later round

Peppermint Consensus Mechanism

Peppermint is a forked version of the Tendermint consensus mechanism. It is changed to make it compatible with Ethereum addresses and verifiable on the Ethereum chain. Polygon network uses this Peppermint consensus mechanism as the consensus mechanism of its Heimdall layer. Peppermint does some minor changes to Tendermint, and in most parts, they are the same. The main idea is the same for both, but some implementation differences exist.

Bor Layer

Bor is Polygon's sidechain block producer layer. This entity is responsible for aggregating transactions into blocks. Currently, it is a basic Geth implementation with custom changes to the consensus algorithm.

Block producers are a subnet of the validators and are periodically shuffled via committee selection on Heimdall in durations termed as a span in Polygon. Blocks are produced at the Bor node, and the sidechain VM is EVM-compatible. Blocks produced on Bor are also validated periodically by Heimdall nodes, and a checkpoint consisting of the Merkle tree hash of a set of blocks on Bor is committed to Ethereum periodically.

The Bor node or the Block Producer implementation is basically the sidechain operator. The sidechain VM is EVM-compatible–a Geth implementation with custom changes to the consensus mechanism. However, this will be built from the ground up to make it lightweight and focused.

Checkpoint Mechanism on Heimdall

The main difference between Polygon Matic's PoS system and others is that Polygon Matic is not a Layer 1 platform, and it depends on Ethereum as a layer-1 settlement layer. Therefore, all staking mechanics also need to be in sync with the Ethereum chain smart contracts.

On Polygon Network's checkpointing layer, the basis of Polygon Network's PoS mechanism, for every few blocks on the block layer of the Polygon Network, a proposer will be chosen among the stakeholders to propose a checkpoint on the main chain. Proposers for a checkpoint are initially selected via Tendermint's weighted round-robin algorithm. A further custom check is implemented based on checkpoint submission success. This allows us to decouple with Tendermint proposer selection and provides us with abilities like selecting a proposer only when the checkpoint transaction on the Ethereum mainnet succeeds.

These checkpoints are created by the proposer after validating all the blocks on the block layer of the Polygon Network and creating the Merkle tree of the block hashes since the last checkpoint. The Merkle root is then broadcasted to the Staker network for their signatures. The other stakeholders also verify the proof. They will approve the proposed block by providing their signatures if the block is valid.

The system needs the approval of ⅔ of the stakeholders to propose a “header block” to the root contract. Once the checkpoint is proposed on the mainchain, anyone on the Ethereum mainchain can challenge the proposed checkpoint within a specified period. If no one challenges it and the challenge period ends, the checkpoint is formally included as a valid checkpoint on the main chain.

Apart from providing finality on the mainchain, Checkpoints have a very important role to play in withdrawals, as they contain the proof-of-burn (withdrawal) of tokens in the event of user withdrawal. It enables the users to prove their remaining tokens on the root contract using Patricia-Merkle proof and header block proof. Note that the header block must be committed to the Root Chain through PoS (Stakeholders) to prove the remaining tokens. The withdrawal process will incur Ethereum gas fees as usual.

The Polygon Network achieves a high transaction speed, a high degree of decentralization, and finality on the mainchain through this mechanism. In its first version, which has Ethereum as the base chain, the Ethereum root contract enforces solvency and finality through header blocks (checkpoints) very efficiently.

Multi Chain Support (Horizontal Sharding)

The Polygon Network public checkpointing layer supports multiple side chains by design. Theoretically, there can be an infinite number of side chains working under the secured and decentralized layer of checkpoints. Businesses can have their dedicated sidechains connected to the public checkpointing layer having full control of their execution environments while still retaining the immutability, provability, and security of transactions via the checkpointing mechanism.

Key factors influencing the design of this sharding process are expected to be:

1. Scheduling of checkpointing layer to periodically propose checkpoints for different side chains;

2. Movement of assets across multiple side chains;

3. Users will be able to send assets across side chains using chain ids and receipts;

4. Users will be provided with an intuitive wallet interface to perform inter-chain transactions;

5. Developers will be provided with API/SDKs to build programmable interfaces for inter-chain transactions;

6. Movement of the assets from one chain to another will be managed at the checkpointing layer and may not require any interaction with the mainchain. Research is currently underway to facilitate faster (possibly instant) inter-sidechain transfers.

The Ethereum main chain is the first base/mainchain that Polygon Network securely integrates with, using an adapted implementation of the Plasma framework. In addition, the Polygon network intends to integrate multiple leading smart contract platforms, cryptocurrencies such as Bitcoin, and others to provide a universal platform for users to use/exchange their assets from various blockchains.

It can also provide a strong foundation for large DEXs (Decentralized exchanges) hosting assets from multiple blockchains. Also, having a single platform with assets from multiple blockchains can create dramatically new use cases on which the developer ecosystems can conceptualize their future products. It is an exciting area of exploration for the Matic Development team.

Judging from the proliferation of layer-1 blockchains, it is a given that there might be more than 2-3 public blockchains that will be adopted by the mainstream eventually, rather than only a single winning blockchain platform. Therefore, the Polygon Development Team expects to see hitherto unseen use cases arising from the decentralized application movement across these blockchains. The vision of the Polygon Development Team is to provide infrastructure and interfaces such that anyone who wishes to build decentralized applications on any blockchain will be able to do it easily—and communicate and transfer value across multiple blockchains.

Polygon provides three types of security models for developers to build their dApps upon:

• Proof of Stake security

• Plasma security

• Hybrid (Plasma + PoS)

Proof of Stake Security

Proof of Stake (PoS) security is provided by the Heimdall & Bor layers, built on top of Tendermint. A checkpoint is committed to the root chain only when ⅔ of the validators have signed on it.

To enable the PoS mechanism on the platform, they employ a set of staking management contracts on Ethereum, as well as a set of incentivized validators running Heimdall and Bor nodes. This implements the following features:

• The ability for anyone to stake MATIC tokens on the Ethereum smart contract and join the system as a Validator

• Earn staking rewards for validating state transitions on Polygon

The PoS mechanism also mitigates the data unavailability problem for our sidechains in terms of Plasma.

The platform has a fast finality layer that finalizes the sidechain state periodically via checkpoints. The fast finality helps it cement the sidechain state. The EVM-compatible chain has few validators and faster block time with high throughput. It chooses scalability over high degrees of decentralization. Heimdall ensures that the final state commit is bulletproof and passes via a large validator set, hence high decentralization.

Plasma Security

Polygon provides “Plasma Guarantees” with respect to various attack scenarios. Two main cases considered are:

• The chain operator (or in Polygon, the Heimdall layer) is corrupt, or

• The user is corrupt

In either case, if a user's assets on the plasma chain have been compromised, they need to start mass exiting. Polygon provides constructions on the rootchain smart contract that can be leveraged.

Effectively, the security offered by Polygon's Plasma contracts piggybacks on Ethereum's security. Users' funds are only ever at risk if Ethereum fails. Put simply, a plasma chain is as secure as the main chain consensus mechanism. This can be extrapolated to say that the plasma chain can use really simple consensus mechanisms and still be safe.

Hybrid

Apart from pure Plasma security and pure Proof of Stake security which is possible in dApps deployed on Polygon, there is also a Hybrid approach that developers can follow—which simply means having both Plasma and Proof of Stake guarantees on some particular workflows of the dApp.

This approach is better understood with an example:

Consider a gaming dApp with a set of smart contracts that describe the game's logic. Let's say the game uses its own ERC20 token to reward players. Now, the smart contracts defining the game logic can be deployed on the Polygon Matic sidechain directly—guaranteeing Proof of Stake security to the contracts, while the ERC20 token transfer can be secured with Plasma guarantees and fraud-proof embedded in Polygon's root chain contracts.

To see Heimdal and Bor layer systems of consensus and governance, please go to appendix 1.

As we mentioned earlier, Polygon is planning to become the biggest layer-2 solution to scale the Ethereum blockchain. The product described above is just one of its products to scale Ethereum. It is its oldest product, named Matic sidechain. When they rebranded to Polygon, they began to work on many other scaling solutions, not only to make the Ethereum blockchain scale better but also to make themselves one of the key companies in the cryptocurrency world. Polygon's list of products goes a long way. We are going to introduce them (and only introduce them) below:

• Polygon PoS: EVM-compatible Ethereum sidechain, secured by a permissionless set of PoS validators. This product has been live and running for a long time. We discussed this product above as the PoS sidechain and Plasma solution.

• Polygon zkEVM: The first open-source zkProver that provides complete EVM opcode equivalence and the security of Ethereum. This product is in the public testnet phase. It is not live as a complete solution, but people can test it and report any bugs to Polygon's team.

• Polygon Avail: A general-purpose, scalable data availability-focused blockchain targeted for standalone chains and off-chain scaling solutions. This product is in the hands of developers and not running.

• Polygon Edge: A modular and extensible framework for building private or public Ethereum-compatible blockchain networks. Polygon Edge is live and running, and developers can use it freely.

• Polygon Nightfall: A one-of-a-kind scaling solution that uses optimistic rollups along with Zero-knowledge cryptography (zkRollup). This product is live on mainnet, but it is in beta version. People may use it easily, but they must know there might be some bugs since it is in the beta version.

• Polygon Miden: A zk-STARK-based zkRollup with support for arbitrary smart contracts. Polygon Maiden is still in development and is not for public use.

• Polygon Zero: A highly scalable, Ethereum-compatible zkRollup. It uses an incredibly fast recursive proof system that is Ethereum-friendly. Polygon Zero is under development.

• Polygon Supernets: End-to-end service to build and power your dedicated blockchain. This product is fully live and running.

• Polygon Hermez: Hermez zkRollup is a layer-2 construction on top of Ethereum that solves its scalability through mass transfer processing rolled into a single transaction. The “zero-knowledge proof” (ZK) technology is used to present and publicly record the validity and correctness of the rolled transfers processed on the Ethereum blockchain. By storing just the proof and the compressed data of a batch of transfers, the network's efficiency and throughput are multiplied. Polygon Hermez is live and running. This product was formerly known as Hermez. After showing success in its work, Polygon acquired it for $250 million.

The Polygon network consists of two parts:

1. The blockchain layer, which has many commits and is constantly updated;

2. The smart contract layer, which has fewer commits.

Both layers are constantly upgraded and have good commit rates, but the second one has fewer commits.

I had no time to read the smart contract layer fully, but I read the bridge contract in their GitHub, and if we trust the security score that CertiK gave to other contracts (a solid 92), we can trust this one, and it works well.

A double-spending bug in Polygon's Plasma bridge was identified in October 2021; the code relates to a contract that locks up to $1 billion worth of funds on layer-1 and is utilized when users move funds to and from the Polygon network. Fortunately, the existence of Polygon's bug bounty program on ImmuneFi helped identify and rectify the vulnerability before it could be exploited. Gerhard Wagner discovered the vulnerability, which could have led to a string of attacks totaling approximately $850 million, it took 30 minutes for Polygon to begin fixing the issue, and Wagner was subsequently awarded $2 million from the bug bounty program.

Matic Foundation co-founders:

• Jaynti Kanani. Co-founder and Chief Executive Officer. Contributor to Web3, Plasma, and WalletConnect. Previously, data scientist at Housing.com.

• Anurag Arjun. Co-founder and Chief Product Officer. Previously AVP (Product Management), IRIS Business. Stints at SNL Financial, Dexter Consultancy, and Cognizant Tech.

• Sandeep Nailwal. Co-founder and Chief Operating Officer. Blockchain Programmer and Entrepreneur. Previously CEO Scopeweaver, CTO (Ecommerce) Welspun Group.

Added co-founder after rebranding to Polygon Foundation:

• Mihailo Bjelic. Co-founder and Information Systems Engineer. Graduated from the University of Belgrade.

Coinbase ventures have invested in Polygon by buying some tokens. They have MATIC tokens worth $15 billion.

• **Hudson Jameson: **COO and Blockchain Lead at Oaken Innovation. Working in the Ethereum.

• Anthony Sassano: Co-founder of EthHub

• **Ryan Sean Adams: **Founder of Mythos Adams and working in Bankless.

• **John Lilic: **Strategy and Operation Lead at ConsenSys.

At its initial private sale in 2017, 3.8% of MATIC's max supply was issued. In the April 2019 launchpad sale, another 19% of the total supply was sold. The MATIC price was $0.00263 per token, and $5 million was generated.

The remaining MATIC tokens are distributed as follows:

• Team tokens: 16% of the total supply.

• Advisors tokens: 4% of the total supply.

• Network Operations tokens: 12% of the total supply.

• Foundation tokens: 21.86% of the total supply.

• Ecosystem tokens: 23.33% of the total supply.

According to the release schedule, all the tokens will be released by December 2022. At the time of writing this article, the mentioned time has passed by less than a month.

The MATIC tokens are used as incentives for validators and delegators. This token has a fixed supply and a limited number of tokens. Also, it has a 5-year vesting schedule from which almost all of it has already gone. There is no burn program for this token.

The supply and vesting mechanisms are as the following image:

• Polygon | Ethereum's Internet of Blockchains, https://polygon.technology/. Accessed 8 January 2022.

• CryptoMiso - Ranking cryptocurrencies based on Github commits of past 12 months, https://www.cryptomiso.com/. Accessed 8 January 2022.

• Polygon (MATIC) Blockchain Explorer, https://polygonscan.com/. Accessed 8 January 2022.

• Buterin, Vitalik. “Why sharding is great: demystifying the technical properties.” Vitalik Buterin's Website, 07 Apr 2021, https://vitalik.ca/general/2021/04/07/sharding.html. Accessed 3 January 2023.

• CertiK. “Polygon.” CertiK, https://www.certik.com/projects/matic. Accessed 8 January 2022.

• Coin Bureau. “Crypto News: BTC, Polygon, OpenDAO, AAVE & More!!” YouTube, 3 January 2022, https://www.youtube.com/watch?v=py8IDJrcsfw. Accessed 8 January 2022.

• Coin Bureau. “MATIC: L2 Network With MASSIVE POTENTIAL!!”

Definitions of Some of the Terms in the Tables Below:

Hardfork

A hardfork happens when the node software changes, so the new version is no longer backward-compatible with earlier blocks. This is usually the result of a change in the consensus calculation, meaning that blocks validated using the new calculation will produce a different hash.

In the current style of change implementation, hardfork block numbers are broadcasted by the Polygon team after an initial staggered rollout to the larger nodes. A block number is selected before which all nodes in the network should have upgraded to the new version. Nodes running the old version will stop working (will be disconnected from the canonical chain after the hardfork block).

Should there be ⅓+1 staked MATIC in disagreement with the fork, two canonical chains will temporarily form until the end of the current span. After this, Bor will stop producing blocks, and the chain will halt until a consensus is reached.

Softfork

This type of change is backward-compatible with the pre-fork blocks. This protocol change does not require nodes to upgrade before a deadline. Therefore, multiple versions of the node software can be running at once and be able to validate transactions.

Rough Consensus

It is defined as the 'dominant view' of a group as determined by the current consensus framework. Without a vote that can carry out a synchronous update across the network, the 'dominant view.' is defined by the node software used by each validator, weighted by its total stake.

In the case of the Polygon PoS chain, this is programmatically defined by ⅔+1 of total staked MATIC.

Governance module

The Polygon PoS consensus engine (Heimdall) has an inbuilt governance module that can synchronously carry consensus parameter changes across the network. Users can submit proposals to the module along with a deposit containing the proposed changes. Each validator tallies votes cast by validators. Once the defined voting parameters are met, each validator automatically updates itself with the proposal data.

The current voting parameters (denominated in staked MATIC):

• Quorum: 33.4%

• Threshold: 50%

• Veto: 33.4%

Polygon Improvement Proposal (PIP)​

The PIP process, as defined in PIP-1, outlined a preliminary approach for allowing the community to put forward-protocol upgrades that improve the network.

This takes inspiration from the PEP process, which has become a standard used for open-source projects, including Ethereum and Bitcoin.

Due to the permissionless nature of governance on the Polygon PoS chain, ⅔+1 of the total stake can change the network by simply updating their node software. This fact is also actual for the Ethereum Beacon chain. However, no change is considered for inclusion unless a proposal passes through the right track.

As a guiding rule, it is recommended that all changes originate from the Polygon community forum in the form of a proposal written in line with PIP-1.

In a world where Ethereum is the King of smart contract platforms, we need a Queen. As it is on a Chess board, the King is slow and moves little steps, but it is the most important Chess piece. On the other hand, the Queen is pretty fast; she can travel to any square almost freely.

The Ethereum blockchain is slow, and due to this slowness, gas fees can be very high from time to time. So, some people began to introduce layer-2s. Layer-2s are smart contract platforms that may or may not be a blockchain themselves. These platforms are much faster, much lighter, and, most crucially, much cheaper. Despite all the differences, almost all of them have one similar point. They all rely on the Ethereum blockchain and serve as a layer-2 to the King.

Since the Ethereum blockchain is slow, we need a way to scale it. Some scaling solutions directly affect the Ethereum blockchain itself, and some are happening out of this platform. Meaning that we can make the Ethereum blockchain faster and cheaper, or we can take some calculations out of the blockchain, compute them somewhere else, and finally give the result back to the Ethereum blockchain. This technique is called “Layer-2.”

Lots of different techniques to create layer-2s exist:

• Rollups

  • Optimistic

  • Zero-Knowledge

• State Channels

• Sidechains

• Plasmas

• Validiums

These different layer-2 solutions have different functionalities and ways of working. We will describe only some of them here since all of them are not a priority to understand the Polygon PoS chain and Plasma Chain. But, Polygon, as a whole, uses almost all of them in various products. As much as Polygon works on different products, one can say that Polygon wants the future of layer-2 technology all to itself.

To understand just two very related products of Polygon, we need to establish two layer-2 technologies: Sidechains and Plasmas.

A sidechain is a separate blockchain that runs independently of Ethereum and is connected to Ethereum Mainnet by a two-way bridge. Sidechains can have separate block parameters and consensus algorithms, often designed to process transactions efficiently. Using a sidechain involves trade-offs, though, as they do not inherit Ethereum's security properties. Unlike layer-2 scaling solutions, sidechains do not post state changes and transaction data back to Ethereum Mainnet.

Sidechains also sacrifice some measure of decentralization or security to achieve high throughput (scalability trilemma).

Scalability Trilemma

As Vitalik Buterin, co-founder of the Ethereum blockchain, stated: “there are three properties that a blockchain tries to have, and that if you stick to “simple” techniques, you can only get two of those three.” These three properties are:

• Scalability: The blockchain needs to process more transactions per second as the number of users soars. This must be so that the transaction fee does not increase dramatically.

• Decentralization: The blockchain must run without the need for trust. Meaning that no centralized authority is in charge of creating and submitting transactions, and a decentralized network is in charge of such work. This way, the need for trust in one centralized authority is diminished.

• Security: The blockchain must be resistant to the attack of a large number of peers, ideally 50%. Because this attack can risk the security of people's funds since a double-spending attack would be enabled.

Now, let us take a look at three classes of “easy solutions,” as Vitalik proposed:

• Traditional blockchains: including Bitcoin, pre-PoS/sharding Ethereum, Litecoin, and other similar chains. These rely on every participant running a full node that verifies every transaction; hence they have decentralization and security but not scalability.

• High-TPS chains: including the DPoS family, but also many others. These rely on a small number of nodes (often 10-100) maintaining consensus among themselves, with users having to trust a majority of these nodes. This is scalable and secure (using the definitions above), but it is not decentralized.

• Multi-chain ecosystems: this refers to the general concept of “scaling out” by having different applications live on different chains and using cross-chain-communication protocols to talk between them. This is decentralized and scalable, but it is not secure because an attacker need only get a consensus node majority in one of the many chains (so often <1% of the whole ecosystem) to break that chain and possibly cause ripple effects that cause great damage to applications in other chains.

Now that we are familiar with the scalability trilemma, it is time to get back to sidechains and how they work.

Sidechains are independent blockchains with different histories, development roadmaps, and design considerations. While a sidechain may share some surface-level similarities with Ethereum, it has several distinctive features.

Consensus Algorithms

One of the qualities that make sidechains unique (i.e., different from Ethereum) is the consensus algorithm used. Sidechains don't rely on Ethereum for consensus and can choose alternative consensus protocols that suit their needs. Some examples of consensus algorithms used on sidechains include:

• Proof-of-authority (PoA),

• Delegated proof-of-stake (DPoS),

• Byzantine fault tolerance (BFT).

Like Ethereum, sidechains have validating nodes that verify and process transactions, produce blocks, and store the blockchain state. Validators are also responsible for maintaining consensus across the network and securing it against malicious attacks.

Block Parameters

Ethereum places limits on block times (i.e., the time it takes to produce new blocks) and block sizes (i.e., the amount of data contained per block denominated in gas). Conversely, sidechains often adopt different parameters, such as faster block times and higher gas limits, to achieve high throughput, fast transactions, and low fees.

While this has some benefits, it has critical implications for network decentralization and security. Block parameters, like fast block times and big block sizes, increase the difficulty of running a full node—leaving a few “supernodes” responsible for securing the chain. In such a scenario, the possibility of validator collusion or a malicious takeover of the chain increases.

For blockchains to scale without harming decentralization, running a node must be open to everyone—not necessarily parties with specialized hardware. This is why efforts are underway to ensure everyone can run a full node on the Ethereum network.

EVM Compatibility

Some sidechains are EVM-compatible and are able to execute contracts developed for the Ethereum Virtual Machine (EVM). EVM-compatible sidechains support smart contracts written in Solidity, as well as other EVM smart contract languages, which means smart contracts written for Ethereum Mainnet will also work on EVM-compatible sidechains.

This means if you want to use your dApp on a sidechain, it's just a matter of deploying your smart contract to this sidechain. It looks, feels, and acts just like Mainnet—you write contracts in Solidity and interact with the chain via the sidechains RPC.

Because sidechains are EVM-compatible, they are considered a useful scaling solution for Ethereum-native dapps. With your dapp on a sidechain, users can enjoy lower gas fees and faster transactions, especially if Mainnet is congested.

However, as explained previously, using a sidechain involves significant trade-offs. Each sidechain is responsible for its security and doesn't inherit Ethereum's security properties. This increases the possibility of malicious behavior affecting your users or putting their funds at risk.

As an important point, it is good to notice that all layer-2 sidechains are EVM-compatible since they are layer-2s for the Ethereum blockchain and must be compatible with its needs.

Asset Movements

In order for a separate blockchain to become a sidechain to Ethereum Mainnet, it requires the ability to facilitate the transfer of assets from and to Ethereum Mainnet. This interoperability with Ethereum is achieved using a blockchain bridge. Bridges use smart contracts deployed on Ethereum Mainnet and a sidechain to control the bridging of funds between them.

While bridges help users move funds between Ethereum and the sidechain, the assets are not physically moved across the two chains. Instead, mechanisms that typically involve minting and burning are used for transferring value across chains.

Pros and Cons of Sidechains

A Plasma chain is a separate blockchain anchored to Ethereum Mainnet but executing transactions off-chain with its own mechanism for block validation. Plasma chains are sometimes referred to as “child” chains, essentially smaller copies of the Ethereum Mainnet. Plasma chains use fraud proofs (like optimistic rollups) to arbitrate disputes.

Merkle trees enable the creation of an endless stack of these chains that can work to offload bandwidth from parent chains (including Ethereum Mainnet). However, while these chains derive some security from Ethereum (via fraud proofs), their security and efficiency are affected by several design limitations.

Plasma chains are built atop another blockchain (called a “root chain”). Each “child chain” extends from the root chain and is generally managed by a smart contract deployed on the parent chain.

The Plasma contract functions, among other things, as a bridge allowing users to move assets between Ethereum Mainnet and the plasma chain. Although this makes them similar to sidechains, plasma chains benefit—at least to some extent—from Ethereum Mainnet's security. This is unlike sidechains that are solely responsible for their security.

Some basic components of the Plasma framework are:

• Off-chain computation: Ethereum's current processing speed is limited to ~ 15–20 transactions per second, reducing the short-term possibility of scaling to handle more users. This problem exists mainly because Ethereum's consensus mechanism requires many peer-to-peer nodes to verify every update to the blockchain's state.

  Although Ethereum's consensus mechanism is necessary for security, it may not apply to every use case. For example, Alice may not need her daily payments to Bob for a cup of coffee verified by the entire Ethereum network since some trust exists between both parties.

  Plasma supposes that Ethereum Mainnet doesn't need to verify all transactions. Instead, we can process transactions off Mainnet, freeing nodes from having to validate every transaction.

  Off-chain computation is necessary since Plasma chains can optimize for speed and cost. For example, a Plasma chain may—and most often does—use a single “operator” to manage the ordering and execution of transactions. With just one entity verifying transactions, processing times on a plasma chain are faster than Ethereum Mainnet.

• State commitments: While Plasma executes transactions off-chain, they are settled on the main Ethereum execution layer—otherwise, Plasma chains cannot benefit from Ethereum's security guarantees. But finalizing off-chain transactions without knowing the state of the plasma chain would break the security model and allow the proliferation of invalid transactions. This is why the operator, the entity responsible for producing blocks on the plasma chain, is required to publish “state commitments” on Ethereum periodically.

  A commitment scheme is a cryptographic technique for committing to a value or statement without revealing it to another party. Commitments are “binding” in the sense that you cannot change the value or statement once you've committed to it. State commitments in Plasma take the form of “Merkle roots” (derived from a Merkle tree) which the operator sends at intervals to the Plasma contract on the Ethereum chain.

  Merkle roots are cryptographic primitives that enable compressing of large amounts of information. A Merkle root (also called a “block root” in this case) could represent all the transactions in a block. Merkle roots also make it easier to verify that a small piece of data is part of the larger dataset. For instance, a user can produce a Merkle proof to prove the inclusion of a transaction in a specific block.

  Merkle roots are important for providing information about the off-chain's state to Ethereum. You can think of Merkle roots as “save points”: the operator is saying, “This is the state of the Plasma chain at x point in time, and this is the Merkle root as proof.” The operator is committing to the current state of the plasma chain with a Merkle root, which is why it is called a “state commitment.”

Now that we know these two ideas in the layer-2 subject, it is time to introduce Polygon (Matic) and its most important products: Polygon PoS chain and Polygon Plasma.

Polygon launched as Matic Network in 2017. It was co-founded by Jaynti Kanani, Sandeep Nailwal, and Anurag Arjun to tackle blockchain scaling and usability issues.

In 2017, Plasma was at the forefront of blockchain scaling, and Matic featured a plasma-driven scaling approach and Proof-of-Stake (PoS) sidechains to assist Ethereum as user demand for the network grew. Over time, Matic POS became a prominent scaling option for various applications.

Matic rebranded to Polygon in February 2021 to become a Swiss Army knife for scaling solutions. Polygon plans to add support for rollups and Validium to its already-existing Plasma/POS chain. The project recognizes that Ethereum may not scale from a single solution in isolation.

Since the Polygon Network's core focus is on mass user adoption, it is ideal that a deep dive into the Polygon Network's technical architecture should start from a user journey.

When users transfer ETH or ERC20 tokens on the Ethereum network, they have to wait for the confirmation of the block, which ranges from 14 seconds to 20 seconds. Even then, the users have to wait for multiple block confirmations to ensure the transaction's finality. Let's say you buy a coffee or pay tokens to watch a movie. On each transaction, not only do you pay a high fee, but you also wait for it to be confirmed. That serves as a deterrent for users wanting to use the service.

Moreover, during peak loads, a large number of transactions clog the Ethereum network, and gas fees increase on each transaction in order to obtain faster confirmations. The Polygon Network is proposed as a solution to overcome these problems.

Before diving into the technology and understanding how it works, we need to understand some terminologies.

Validators

Validator is a participant in the network who locks up MATIC tokens in the system and runs Heimdall validator and Bor block producer nodes in order to help run the network (we will explain Heimdall and Bor later in this article). Validators stake their MATIC tokens as collateral to work for the security of the network and, in exchange for their service, earn rewards.

Rewards are distributed to all stakers proportional to their stake at every checkpoint, with the exception being the proposer getting an additional bonus. User reward balance gets updated in the contract, which is referred to while claiming rewards.

Stakes are at risk of getting slashed in case the validator node commits a malicious act like double signing, which also affects the linked delegators at that checkpoint.

Validators on the Polygon network are selected through an on-chain auction process, which happens at regular intervals. These selected validators participate as block producers and verifiers. Once the participants validate a checkpoint, updates are made on the parent chain (the Ethereum mainnet), which releases the rewards for validators depending on their stake in the network.

Polygon relies on a set of validators to secure the network. The role of validators is to run a full node, produce blocks, validate and participate in consensus, and commit checkpoints on the Ethereum mainnet. To become a validator, one needs to stake their MATIC tokens with staking management contracts residing on the Ethereum mainnet.

Delegators

Delegators are token holders who cannot or do not want to run a validator node themselves. Instead, they secure the network by delegating their stake to validator nodes and play a critical role in the system, as they are responsible for choosing validators. They run their delegation transaction on the staking contract on the Ethereum mainnet.

The MATIC tokens are bonded with the next checkpoint committed on the Ethereum mainnet. Delegators also have the option to opt-out of the system whenever they want. Similar to validators, delegators have to wait for the unbonding period, which consists of approximately 9 days, to end before withdrawing their stake.

Delegators stake their tokens by delegating them to a validator, obtaining a percentage of their rewards in exchange. Because delegators share rewards with their validators, delegators also share risks. Should a validator misbehave, each of their delegators is at risk of being partially slashed in proportion to their delegated stake.

Validators set a commission percentage to determine the percentage of rewards that will go to them. Delegators are able to view the commission rate of each validator to understand each validator's reward distribution and a relative rate of return on their stake.

Span

Span is a logically defined set of blocks for which a set of validators is chosen from all the available validators. The selection of each span is decided by at least 2/3 of the validators in terms of the staking power.

Proposer

A proposer is a validator selected by the algorithm to propose a new block. A proposer is also responsible for collecting all signatures for a particular checkpoint and committing the checkpoint to the Ethereum mainnet.

We can continue with Polygon architecture and its components now that we know what these terms mean in the Polygon system.

Polygon is a blockchain application platform that provides hybrid Proof-of-Stake and Plasma-enabled sidechains.

Architecturally, the beauty of Polygon is its elegant design, which features a generic validation layer separated from varying execution environments like Plasma enabled chains, full-blown EVM sidechains, and in the future, other layer-2 approaches such as Optimistic Rollups.

Polygon has some key features listed below:

• Speed: The Polygon Network uses a high-throughput blockchain with consensus provided by a group of Block Producers selected by stakeholders at each checkpoint. A Proof of Stake layer is used to validate blocks and periodically post proofs of Block Producers to the Ethereum mainnet. This enables rapid block confirmation rates of about 2 seconds while preserving a high amount of decentralization, resulting in excellent throughput for the network.

• Scalability: Polygon Network achieves a hypothetical transaction speed of fewer than 2 seconds on a single sidechain. Using multiple sidechains helps the network to handle millions of transactions per second. This mechanism (already demonstrated in the first Matic sidechain) allows the Polygon network to scale easily.

• Security: Polygon's smart contracts rely on Ethereum's security. To safeguard the network, it employs three critical security models. It uses Ethereum's staking management contracts and a group of incentivized validators running Heimdall and Bor nodes. Developers can also implement both models (Hybrid) into their dApp.

The Polygon PoS Network has a three-layer architecture:

• Ethereum layer (Staking and Plasma smart contracts): Polygon Network maintains a set of smart contracts on Ethereum, which manages staking functions and rewards for Polygon's Proof-of-Stake layer. These contracts are also responsible for delegation management (including validator shares) and Plasma contracts for MoreVP (including checkpoints/snapshots of sidechain state).

• Heimdall layer (Proof of Stake layer): a set of proof-of-stake Heimdall nodes running parallel to the Ethereum mainnet, monitoring the set of staking contracts deployed on the Ethereum mainnet and committing the Polygon Network checkpoints to the Ethereum mainnet. These nodes handle the aggregation of blocks produced by the Bor layer into a Merkle tree. It publishes the Merkle root to the root chain periodically. The Heimdall layer is based on Peppermint, a forked version of Tendermint (we'll talk about these consensus mechanisms later).

• Bor layer (Block producer layer): a set of block-producing Bor nodes shuffled by Heimdall nodes. This layer is responsible for aggregating transactions into blocks. Bor is based on Go Ethereum (Geth) with custom changes to the consensus algorithm.

Currently, developers can use Plasma for specific state transitions for which Plasma predicates have been written, such as ERC20, ERC721, asset swaps, or other custom predicates. For arbitrary state transitions, they can use PoS. Or both! This is made possible by Polygon's hybrid construction.

To enable the PoS mechanism on our platform, a set of staking management contracts are deployed on Ethereum, and a set of incentivized validators run Heimdall and Bor nodes. Ethereum is the first base chain Polygon supports, but Polygon intends to offer support for additional base chains to enable an interoperable decentralized layer-2 blockchain platform based on community suggestions and consensus.

Ethereum Layer

To enable the Proof-of-Stake (PoS) mechanism on Polygon, the system employs a set of staking management contracts on the Ethereum mainnet.

The staking contracts implement the following features:

• Anyone can stake MATIC tokens on the staking contracts on the Ethereum mainnet and join the system as a validator.

• Earn staking rewards for validating state transitions on the Polygon Network.

• Save checkpoints on the Ethereum mainnet.

The PoS mechanism also acts as a mitigation to the data unavailability problem for the Polygon sidechains.

Heimdall Layer

Heimdall is the proof of stake validation layer that handles the aggregation of blocks produced by Bor into a Merkle tree and publishes the Merkle root periodically to the root chain. The periodic publishing of snapshots of the Bor sidechain is called checkpoints.

1. Validates all the blocks since the last checkpoint.

2. Creates a Merkle tree of the block hashes.

3. Publishes the Merkle root hash to the Ethereum mainnet.

Checkpoints are important for two reasons:

1. Providing finality on the root chain.

2. Providing proof of burn in withdrawal of assets.

An overview of the process:

• A subset of active validators from the pool is selected to act as block producers for a span. These block producers are responsible for creating blocks and broadcasting the created blocks on the network.

• A checkpoint includes the Merkle root hash of all blocks created during any given interval. All nodes validate the Merkle root hash and attach their signature to it.

• A selected proposer from the validator set is responsible for collecting all signatures for a particular checkpoint and committing the checkpoint on the Ethereum mainnet.

• The responsibility of creating blocks and proposing checkpoints is variably dependent on a validator's stake ratio in the overall pool.

Tendermint Consensus Mechanisms

Tendermint is a software for securely and consistently replicating an application on many machines. By securely, we mean that Tendermint works even if up to ⅓ of machines fail in arbitrary ways. By consistently, we mean that every non-faulty machine sees the same transaction log and computes the same state. Secure and consistent replication is a fundamental problem in distributed systems; it plays a critical role in the fault tolerance of a broad range of applications, from currencies to elections, to infrastructure orchestration and beyond.

Tendermint is an easy-to-understand, mostly asynchronous, BFT consensus protocol. The protocol follows a simple state machine that looks like this:

Participants in the protocol are called validators; they take turns proposing blocks of transactions and voting on them. Blocks are committed in a chain, with one block at each height. A block may fail to be committed, in which case the protocol moves to the next round, and a new validator gets to propose a block for that height. Two voting stages are required to commit a block successfully; we call them pre-vote and pre-commit. A block is committed when more than ⅔  of validators pre-commit for the same block in the same round.

There is a picture of a couple doing the polka because validators are doing something like a polka dance. When more than two-thirds of the validators pre-vote for the same block, we call that a polka. Every pre-commit must be justified by a polka in the same round.

Validators may fail to commit a block for several reasons; the current proposer may be offline, or the network may be slow. Tendermint allows them to establish that a validator should be skipped. Validators wait a small amount of time to receive a complete proposal block from the proposer before voting to move to the next round. This reliance on a timeout makes Tendermint a weakly synchronous protocol rather than an asynchronous one. However, the rest of the protocol is asynchronous, and validators only make progress after hearing from more than two-thirds of the validator set. A simplifying element of Tendermint is that it uses the same mechanism to commit a block to skip to the next round.

Assuming less than one-third of the validators are Byzantine, Tendermint guarantees that safety will never be violated—validators will never commit conflicting blocks at the same height. To do this, it introduces a few locking rules which modulate which paths can be followed in the flow diagram. Once a validator precommits a block, it is locked on that block. Then,

1. it must pre-vote for the block it is locked on

2. it can only unlock and pre-commit for a new block if there is a polka for that block in a later round

Peppermint Consensus Mechanism

Peppermint is a forked version of the Tendermint consensus mechanism. It is changed to make it compatible with Ethereum addresses and verifiable on the Ethereum chain. Polygon network uses this Peppermint consensus mechanism as the consensus mechanism of its Heimdall layer. Peppermint does some minor changes to Tendermint, and in most parts, they are the same. The main idea is the same for both, but some implementation differences exist.

Bor Layer

Bor is Polygon's sidechain block producer layer. This entity is responsible for aggregating transactions into blocks. Currently, it is a basic Geth implementation with custom changes to the consensus algorithm.

Block producers are a subnet of the validators and are periodically shuffled via committee selection on Heimdall in durations termed as a span in Polygon. Blocks are produced at the Bor node, and the sidechain VM is EVM-compatible. Blocks produced on Bor are also validated periodically by Heimdall nodes, and a checkpoint consisting of the Merkle tree hash of a set of blocks on Bor is committed to Ethereum periodically.

The Bor node or the Block Producer implementation is basically the sidechain operator. The sidechain VM is EVM-compatible–a Geth implementation with custom changes to the consensus mechanism. However, this will be built from the ground up to make it lightweight and focused.

Checkpoint Mechanism on Heimdall

The main difference between Polygon Matic's PoS system and others is that Polygon Matic is not a Layer 1 platform, and it depends on Ethereum as a layer-1 settlement layer. Therefore, all staking mechanics also need to be in sync with the Ethereum chain smart contracts.

On Polygon Network's checkpointing layer, the basis of Polygon Network's PoS mechanism, for every few blocks on the block layer of the Polygon Network, a proposer will be chosen among the stakeholders to propose a checkpoint on the main chain. Proposers for a checkpoint are initially selected via Tendermint's weighted round-robin algorithm. A further custom check is implemented based on checkpoint submission success. This allows us to decouple with Tendermint proposer selection and provides us with abilities like selecting a proposer only when the checkpoint transaction on the Ethereum mainnet succeeds.

These checkpoints are created by the proposer after validating all the blocks on the block layer of the Polygon Network and creating the Merkle tree of the block hashes since the last checkpoint. The Merkle root is then broadcasted to the Staker network for their signatures. The other stakeholders also verify the proof. They will approve the proposed block by providing their signatures if the block is valid.

The system needs the approval of ⅔ of the stakeholders to propose a “header block” to the root contract. Once the checkpoint is proposed on the mainchain, anyone on the Ethereum mainchain can challenge the proposed checkpoint within a specified period. If no one challenges it and the challenge period ends, the checkpoint is formally included as a valid checkpoint on the main chain.

Apart from providing finality on the mainchain, Checkpoints have a very important role to play in withdrawals, as they contain the proof-of-burn (withdrawal) of tokens in the event of user withdrawal. It enables the users to prove their remaining tokens on the root contract using Patricia-Merkle proof and header block proof. Note that the header block must be committed to the Root Chain through PoS (Stakeholders) to prove the remaining tokens. The withdrawal process will incur Ethereum gas fees as usual.

The Polygon Network achieves a high transaction speed, a high degree of decentralization, and finality on the mainchain through this mechanism. In its first version, which has Ethereum as the base chain, the Ethereum root contract enforces solvency and finality through header blocks (checkpoints) very efficiently.

Multi Chain Support (Horizontal Sharding)

The Polygon Network public checkpointing layer supports multiple side chains by design. Theoretically, there can be an infinite number of side chains working under the secured and decentralized layer of checkpoints. Businesses can have their dedicated sidechains connected to the public checkpointing layer having full control of their execution environments while still retaining the immutability, provability, and security of transactions via the checkpointing mechanism.

Key factors influencing the design of this sharding process are expected to be:

1. Scheduling of checkpointing layer to periodically propose checkpoints for different side chains;

2. Movement of assets across multiple side chains;

3. Users will be able to send assets across side chains using chain ids and receipts;

4. Users will be provided with an intuitive wallet interface to perform inter-chain transactions;

5. Developers will be provided with API/SDKs to build programmable interfaces for inter-chain transactions;

6. Movement of the assets from one chain to another will be managed at the checkpointing layer and may not require any interaction with the mainchain. Research is currently underway to facilitate faster (possibly instant) inter-sidechain transfers.

The Ethereum main chain is the first base/mainchain that Polygon Network securely integrates with, using an adapted implementation of the Plasma framework. In addition, the Polygon network intends to integrate multiple leading smart contract platforms, cryptocurrencies such as Bitcoin, and others to provide a universal platform for users to use/exchange their assets from various blockchains.

It can also provide a strong foundation for large DEXs (Decentralized exchanges) hosting assets from multiple blockchains. Also, having a single platform with assets from multiple blockchains can create dramatically new use cases on which the developer ecosystems can conceptualize their future products. It is an exciting area of exploration for the Matic Development team.

Judging from the proliferation of layer-1 blockchains, it is a given that there might be more than 2-3 public blockchains that will be adopted by the mainstream eventually, rather than only a single winning blockchain platform. Therefore, the Polygon Development Team expects to see hitherto unseen use cases arising from the decentralized application movement across these blockchains. The vision of the Polygon Development Team is to provide infrastructure and interfaces such that anyone who wishes to build decentralized applications on any blockchain will be able to do it easily—and communicate and transfer value across multiple blockchains.

Polygon provides three types of security models for developers to build their dApps upon:

• Proof of Stake security

• Plasma security

• Hybrid (Plasma + PoS)

Proof of Stake Security

Proof of Stake (PoS) security is provided by the Heimdall & Bor layers, built on top of Tendermint. A checkpoint is committed to the root chain only when ⅔ of the validators have signed on it.

To enable the PoS mechanism on the platform, they employ a set of staking management contracts on Ethereum, as well as a set of incentivized validators running Heimdall and Bor nodes. This implements the following features:

• The ability for anyone to stake MATIC tokens on the Ethereum smart contract and join the system as a Validator

• Earn staking rewards for validating state transitions on Polygon

The PoS mechanism also mitigates the data unavailability problem for our sidechains in terms of Plasma.

The platform has a fast finality layer that finalizes the sidechain state periodically via checkpoints. The fast finality helps it cement the sidechain state. The EVM-compatible chain has few validators and faster block time with high throughput. It chooses scalability over high degrees of decentralization. Heimdall ensures that the final state commit is bulletproof and passes via a large validator set, hence high decentralization.

Plasma Security

Polygon provides “Plasma Guarantees” with respect to various attack scenarios. Two main cases considered are:

• The chain operator (or in Polygon, the Heimdall layer) is corrupt, or

• The user is corrupt

In either case, if a user's assets on the plasma chain have been compromised, they need to start mass exiting. Polygon provides constructions on the rootchain smart contract that can be leveraged.

Effectively, the security offered by Polygon's Plasma contracts piggybacks on Ethereum's security. Users' funds are only ever at risk if Ethereum fails. Put simply, a plasma chain is as secure as the main chain consensus mechanism. This can be extrapolated to say that the plasma chain can use really simple consensus mechanisms and still be safe.

Hybrid

Apart from pure Plasma security and pure Proof of Stake security which is possible in dApps deployed on Polygon, there is also a Hybrid approach that developers can follow—which simply means having both Plasma and Proof of Stake guarantees on some particular workflows of the dApp.

This approach is better understood with an example:

Consider a gaming dApp with a set of smart contracts that describe the game's logic. Let's say the game uses its own ERC20 token to reward players. Now, the smart contracts defining the game logic can be deployed on the Polygon Matic sidechain directly—guaranteeing Proof of Stake security to the contracts, while the ERC20 token transfer can be secured with Plasma guarantees and fraud-proof embedded in Polygon's root chain contracts.

To see Heimdal and Bor layer systems of consensus and governance, please go to appendix 1.

As we mentioned earlier, Polygon is planning to become the biggest layer-2 solution to scale the Ethereum blockchain. The product described above is just one of its products to scale Ethereum. It is its oldest product, named Matic sidechain. When they rebranded to Polygon, they began to work on many other scaling solutions, not only to make the Ethereum blockchain scale better but also to make themselves one of the key companies in the cryptocurrency world. Polygon's list of products goes a long way. We are going to introduce them (and only introduce them) below:

• Polygon PoS: EVM-compatible Ethereum sidechain, secured by a permissionless set of PoS validators. This product has been live and running for a long time. We discussed this product above as the PoS sidechain and Plasma solution.

• Polygon zkEVM: The first open-source zkProver that provides complete EVM opcode equivalence and the security of Ethereum. This product is in the public testnet phase. It is not live as a complete solution, but people can test it and report any bugs to Polygon's team.

• Polygon Avail: A general-purpose, scalable data availability-focused blockchain targeted for standalone chains and off-chain scaling solutions. This product is in the hands of developers and not running.

• Polygon Edge: A modular and extensible framework for building private or public Ethereum-compatible blockchain networks. Polygon Edge is live and running, and developers can use it freely.

• Polygon Nightfall: A one-of-a-kind scaling solution that uses optimistic rollups along with Zero-knowledge cryptography (zkRollup). This product is live on mainnet, but it is in beta version. People may use it easily, but they must know there might be some bugs since it is in the beta version.

• Polygon Miden: A zk-STARK-based zkRollup with support for arbitrary smart contracts. Polygon Maiden is still in development and is not for public use.

• Polygon Zero: A highly scalable, Ethereum-compatible zkRollup. It uses an incredibly fast recursive proof system that is Ethereum-friendly. Polygon Zero is under development.

• Polygon Supernets: End-to-end service to build and power your dedicated blockchain. This product is fully live and running.

• Polygon Hermez: Hermez zkRollup is a layer-2 construction on top of Ethereum that solves its scalability through mass transfer processing rolled into a single transaction. The “zero-knowledge proof” (ZK) technology is used to present and publicly record the validity and correctness of the rolled transfers processed on the Ethereum blockchain. By storing just the proof and the compressed data of a batch of transfers, the network's efficiency and throughput are multiplied. Polygon Hermez is live and running. This product was formerly known as Hermez. After showing success in its work, Polygon acquired it for $250 million.

The Polygon network consists of two parts:

1. The blockchain layer, which has many commits and is constantly updated;

2. The smart contract layer, which has fewer commits.

Both layers are constantly upgraded and have good commit rates, but the second one has fewer commits.

I had no time to read the smart contract layer fully, but I read the bridge contract in their GitHub, and if we trust the security score that CertiK gave to other contracts (a solid 92), we can trust this one, and it works well.

A double-spending bug in Polygon's Plasma bridge was identified in October 2021; the code relates to a contract that locks up to $1 billion worth of funds on layer-1 and is utilized when users move funds to and from the Polygon network. Fortunately, the existence of Polygon's bug bounty program on ImmuneFi helped identify and rectify the vulnerability before it could be exploited. Gerhard Wagner discovered the vulnerability, which could have led to a string of attacks totaling approximately $850 million, it took 30 minutes for Polygon to begin fixing the issue, and Wagner was subsequently awarded $2 million from the bug bounty program.

Matic Foundation co-founders:

• Jaynti Kanani. Co-founder and Chief Executive Officer. Contributor to Web3, Plasma, and WalletConnect. Previously, data scientist at Housing.com.

• Anurag Arjun. Co-founder and Chief Product Officer. Previously AVP (Product Management), IRIS Business. Stints at SNL Financial, Dexter Consultancy, and Cognizant Tech.

• Sandeep Nailwal. Co-founder and Chief Operating Officer. Blockchain Programmer and Entrepreneur. Previously CEO Scopeweaver, CTO (Ecommerce) Welspun Group.

Added co-founder after rebranding to Polygon Foundation:

• Mihailo Bjelic. Co-founder and Information Systems Engineer. Graduated from the University of Belgrade.

Coinbase ventures have invested in Polygon by buying some tokens. They have MATIC tokens worth $15 billion.

• **Hudson Jameson: **COO and Blockchain Lead at Oaken Innovation. Working in the Ethereum.

• Anthony Sassano: Co-founder of EthHub

• **Ryan Sean Adams: **Founder of Mythos Adams and working in Bankless.

• **John Lilic: **Strategy and Operation Lead at ConsenSys.

At its initial private sale in 2017, 3.8% of MATIC's max supply was issued. In the April 2019 launchpad sale, another 19% of the total supply was sold. The MATIC price was $0.00263 per token, and $5 million was generated.

The remaining MATIC tokens are distributed as follows:

• Team tokens: 16% of the total supply.

• Advisors tokens: 4% of the total supply.

• Network Operations tokens: 12% of the total supply.

• Foundation tokens: 21.86% of the total supply.

• Ecosystem tokens: 23.33% of the total supply.

According to the release schedule, all the tokens will be released by December 2022. At the time of writing this article, the mentioned time has passed by less than a month.

The MATIC tokens are used as incentives for validators and delegators. This token has a fixed supply and a limited number of tokens. Also, it has a 5-year vesting schedule from which almost all of it has already gone. There is no burn program for this token.

The supply and vesting mechanisms are as the following image:

• Polygon | Ethereum's Internet of Blockchains, https://polygon.technology/. Accessed 8 January 2022.

• CryptoMiso - Ranking cryptocurrencies based on Github commits of past 12 months, https://www.cryptomiso.com/. Accessed 8 January 2022.

• Polygon (MATIC) Blockchain Explorer, https://polygonscan.com/. Accessed 8 January 2022.

• Buterin, Vitalik. “Why sharding is great: demystifying the technical properties.” Vitalik Buterin's Website, 07 Apr 2021, https://vitalik.ca/general/2021/04/07/sharding.html. Accessed 3 January 2023.

• CertiK. “Polygon.” CertiK, https://www.certik.com/projects/matic. Accessed 8 January 2022.

• Coin Bureau. “Crypto News: BTC, Polygon, OpenDAO, AAVE & More!!” YouTube, 3 January 2022, https://www.youtube.com/watch?v=py8IDJrcsfw. Accessed 8 January 2022.

• Coin Bureau. “MATIC: L2 Network With MASSIVE POTENTIAL!!”

Definitions of Some of the Terms in the Tables Below:

Hardfork

A hardfork happens when the node software changes, so the new version is no longer backward-compatible with earlier blocks. This is usually the result of a change in the consensus calculation, meaning that blocks validated using the new calculation will produce a different hash.

In the current style of change implementation, hardfork block numbers are broadcasted by the Polygon team after an initial staggered rollout to the larger nodes. A block number is selected before which all nodes in the network should have upgraded to the new version. Nodes running the old version will stop working (will be disconnected from the canonical chain after the hardfork block).

Should there be ⅓+1 staked MATIC in disagreement with the fork, two canonical chains will temporarily form until the end of the current span. After this, Bor will stop producing blocks, and the chain will halt until a consensus is reached.

Softfork

This type of change is backward-compatible with the pre-fork blocks. This protocol change does not require nodes to upgrade before a deadline. Therefore, multiple versions of the node software can be running at once and be able to validate transactions.

Rough Consensus

It is defined as the 'dominant view' of a group as determined by the current consensus framework. Without a vote that can carry out a synchronous update across the network, the 'dominant view.' is defined by the node software used by each validator, weighted by its total stake.

In the case of the Polygon PoS chain, this is programmatically defined by ⅔+1 of total staked MATIC.

Governance module

The Polygon PoS consensus engine (Heimdall) has an inbuilt governance module that can synchronously carry consensus parameter changes across the network. Users can submit proposals to the module along with a deposit containing the proposed changes. Each validator tallies votes cast by validators. Once the defined voting parameters are met, each validator automatically updates itself with the proposal data.

The current voting parameters (denominated in staked MATIC):

• Quorum: 33.4%

• Threshold: 50%

• Veto: 33.4%

Polygon Improvement Proposal (PIP)​

The PIP process, as defined in PIP-1, outlined a preliminary approach for allowing the community to put forward-protocol upgrades that improve the network.

This takes inspiration from the PEP process, which has become a standard used for open-source projects, including Ethereum and Bitcoin.

Due to the permissionless nature of governance on the Polygon PoS chain, ⅔+1 of the total stake can change the network by simply updating their node software. This fact is also actual for the Ethereum Beacon chain. However, no change is considered for inclusion unless a proposal passes through the right track.

As a guiding rule, it is recommended that all changes originate from the Polygon community forum in the form of a proposal written in line with PIP-1.