Tag: Chain

Categories
Network

Polygon Matic

  • Post author By
  • Post date


Polygon believes in Web3 for all.

Polygon is a decentralised Ethereum scaling platform that enables developers to build scalable user-friendly dApps with low transaction fees without ever sacrificing on security.

Polygon is a scaling solution for public blockchains.
Based on an adapted implementation of Plasma framework (Plasma MoreVP) – with an account based implementation (read more here), Polygon supports all the existing Ethereum tooling along with faster and cheaper transactions.

Polygon Network 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.

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, as well as a set of incentivized validators running Heimdall and Bor nodes.

Ethereum is the first basechain Polygon supports, but Polygon intends to offer support for additional basechains, based on community suggestions and consensus, to enable an interoperable decentralized Layer 2 blockchain platform.

Polygon has a three-layer architecture:

  1. Staking and Plasma smart contracts on Ethereum
  2. Heimdall (Proof of Stake layer)
  3. Bor (Block producer layer)

Polygon smart contracts (on Ethereum)

Polygon maintains a set of smart contracts on Ethereum, which handle the following:

  • Staking management for the Proof-of-Stake layer
  • Delegation management including validator shares
  • Plasma contracts for MoreVP, including checkpoints/snapshots of sidechain state

Heimdall (Proof-of-Stake validator layer)

Heimdall is the PoS validator node that works in consonance with the Staking contracts on Ethereum to enable the PoS mechanism on Polygon. We have implemented this by building on top of the Tendermint consensus engine with changes to the signature scheme and various data structures. It is responsible for block validation, block producer committee selection, checkpointing a representation of the sidechain blocks to Ethereum in our architecture and various other responsibilities.

Heimdall layer handles the aggregation of blocks produced by Bor into a merkle tree and publishing the merkle root periodically to the root chain. This periodic publishing are called checkpoints.
For every few blocks on Bor, a validator (on the Heimdall layer):

  1. Validates all the blocks since the last checkpoint
  2. Creates a merkle tree of the block hashes
  3. Publishes the merkle root to the main chain

Checkpoints are important for two reasons:

  1. Providing finality on the Root Chain
  2. Providing proof of burn in withdrawal of assets

A bird’s eye view of the process can be explained as:

  • A subset of active validators from the pool are selected to act as block producers for a span. The Selection of each span will also be consented by at least 2/3 in power. These block producers are responsible for creating blocks and broadcasting it to the remaining of the network.
  • A checkpoint includes the root of all blocks created during any given interval. All nodes validate the same 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 same on the main-chain.
  • The responsibility of creating blocks and also proposing checkpoints is variably dependent on a validator’s stake ratio in the overall pool.

Bor (Block Producer Layer)

Bor is Polygon block producer layer – the entity responsible for aggregating transactions into blocks.

Block producers 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.

How is Polygon different from other implementations of Plasma?

Polygon’s implementation of Plasma is built on state-based side chains which run on EVM, while the other implementations of Plasma primarily use UTXOs which restricts them to being payment specific.
Having state based side chains allows Polygon to provide scalability for generic smart contracts as well.

Secondly, Polygon uses a public checkpointing layer which publishes checkpoints after periodic intervals (unlike checkpoints after every block in Plasma Cash) allowing the side chains to operate at high speeds while publishing the checkpoints in batches.

These checkpoints along with the fraud proofs ensure that Polygon’s side chains operate in a secure manner and any fraudulent activity can be detected on Ethereum mainchain and be penalized by slashing the stakes of the bad actors.
This mainchain security is supplementary to the PoS protocol security on the side chains.

📜Resources

📎 Bor Architecture: https://forum.matic.network/t/matic-system-overview-bor/126
📎 Heimdall Architecture: https://forum.matic.network/t/matic-system-overview-heimdall/125
📎 Checkpoint Mechanism: https://forum.matic.network/t/checkpoint-mechanism-on-heimdall/127

Categories
Network

Injective Protocol

  • Post author By
  • Post date

Injective Protocol is a fully decentralized layer-2 DEX protocol built for the next generation of decentralized derivatives exchange.

The Injective Chain is a Tendermint-based IBC-compatible blockchain which supports a decentralized orderbook-based DEX protocol and a trustless ERC-20 token bridge to the Ethereum blockchain.

It is the first layer-2 fully decentralized exchange protocol for decentralized perpetual swaps, futures, and spot trading that unlocks the full potential of decentralized derivatives and borderless DeFi. Every component of the protocol has been built to be fully trustless, censorship-resistant, publicly verifiable, and front-running resistant.

By providing the unrestricted and unprecedented ability to express diverse views in the decentralized financial markets, we are striving to empower individuals with the ability to more efficiently allocate capital in our society.

Key Features & Highlights

  • Fully Decentralized: Injective transforms an exchange into a decentralized public utility by open-sourcing every single component of the exchange, from the front-end exchange interface to back-end infrastructure to orderbook liquidity.
  • Permissionless: Full decentralization turns the traditional business model of an exchange on its head, as we eliminate the technical barrier to entry for users by creating a permissionless and highly performant exchange for both spot and derivatives markets.
  • Censorship Resistant: Full decentralization combined with permissionless access ensures an open and unrestricted market, resistant to censorship.
  • Community Owned: Nodes on the Injective Chain are incentivized through token economics to act as order relayers, host a decentralized orderbook, and serve as a decentralized trade execution coordinator.
  • Scalable: Injective brings an order of magnitude speedup by scaling trade execution and settlement on layer-2.

Injective Protocol’s infrastructure is comprised of three principal components:

  1. Injective Chain
  2. Injective Exchange Service
  3. Injective Ethereum Bridge

Injective Chain

The Injective Chain is a layer-2 sidechain and Cosmos Zone connected to Ethereum.
The chain itself is built on top of Tendermint and allows for the transferring and trading of Ethereum-based assets on the Injective Chain.

The Injective Chain’s primary purpose is to power the Injective Exchange protocol, which is a decentralized peer-to-peer spot and derivatives exchange protocol. The protocol allows individuals to create and trade on arbitrary derivative markets.

Injective Exchange Service

Unlike traditional exchanges which serve as gatekeepers to the crypto industry, Injective transforms an exchange into a decentralized public utility. What truly differentiates Injective is that we bring every component of a decentralized exchange to the public. Everything — from the front-end exchange interface to back-end infrastructure to orderbook liquidity — is provided openly and for free.
This transforms the traditional business model of exchanges as we eliminate the technical barrier to entry for individuals to freely run a highly performative exchange.

Injective’s model rewards relayers in the Injective network for sourcing liquidity. By doing so, exchange providers are incentivized to better serve users as they compete amongst each other to provide better user experiences. Thus, this allows users from all around the world to access decentralized financial markets.

Injective Chain

The Injective Chain is the core backbone for Injective’s layer-2 derivatives platform.

Beyond the standard imported modules from the Cosmos-SDK, the Injective chain itself is comprised of 5 unique modules:

  1. auction
  2. exchange
  3. insurance
  4. oracle
  5. peggy

    Injective Accounts

    Injective defines its own custom Account type that uses Ethereum’s ECDSA secp256k1 curve for keys. This satisfies the EIP84 for full BIP44 paths. The root HD path for Injective-based accounts is m/44'/60'/0'/0.

    Addresses and Public Keys

    There are 3 main types of Addresses/PubKeys available by default on Injective:

    • Addresses and Keys for accounts, which identify users (e.g. the sender of a message). They are derived using the eth_secp256k1 curve.
    • Addresses and Keys for validator operators, which identify the operators of validators. They are derived using the eth_secp256k1 curve.
    • Addresses and Keys for consensus nodes, which identify the validator nodes participating in consensus. They are derived using the ed25519 curve.
    Address bech32 Prefix Pubkey bech32 Prefix Curve Address byte length Pubkey byte length
    Accounts inj injpub eth_secp256k1 20 33 (compressed)
    Validator Operator injvaloper injvaloperpub eth_secp256k1 20 33 (compressed)
    Consensus Nodes injvalcons injvalconspub ed25519 20 32

    Address formats for clients

    EthAccounts can be represented in both Bech32 and hex format for Ethereum’s Web3 tooling compatibility.

    The Bech32 format is the default format for Cosmos-SDK queries and transactions through CLI and REST clients. The hex format on the other hand, is the Ethereum common.Address representation of a Cosmos sdk.AccAddress.

    • Address (Bech32): inj14au322k9munkmx5wrchz9q30juf5wjgz2cfqku
    • Address (EIP55 Hex): 0xAF79152AC5dF276D9A8e1E2E22822f9713474902
    • Compressed Public Key: {"@type":"/injective.crypto.v1beta1.ethsecp256k1.PubKey","key":"ApNNebT58zlZxO2yjHiRTJ7a7ufjIzeq5HhLrbmtg9Y/"}