MaalChain Architecture

MAAL blockchain network is a blockchain application platform that provides Bridged Proof-of-Stake.
Architecturally, the beauty of MAAL blockchain is its elegant design, which features a generic validation layer separated from varying execution environments like full-blown EVM sidechains.
To enable decentralized governance on MaalChain, a Validator DAO is proposed which is detailed further in this doc under "Maal Validator DAO".
Ethereum is the first basechain MAAL blockchain supports as it uses Polygon edge, and as Polygon intends to offer support for additional basechains to enable an interoperable decentralized Layer 2 blockchain platform, MAAL will also support those basechains.
MaalChain has a three-layer architecture:
  1. 1.
    IBFT Consensus Mechanism
  2. 2.
    Heimdall (Proof of Stake layer)
  3. 3.
    Bor (Block producer layer)

IBFT Consensus Mechanism

IBFT ensures a single, deterministically defined order of transactions in the digital ledger. It additionally, ensures one block settlement finality. IBFT was proposed by Amis Technologies and later implemented by JP Morgan’s Quorum as one of the consensus mechanisms in Geth.

Key Advantages of IBFT

  • Immediate block finality IBFT allows one block for each block height since it can be added by elected block producer. This feature eradicates the possibility of any forking, uncle blocks and provides immediate confirmation of executed transactions.
  • Reduced time between blocks Since every block producer gets its chance to add block deterministically, the effort required to write and validate blocks is reduced significantly (as compared to PoW), greatly increasing the throughput of the chain.
  • High data integrity and fault tolerance IBFT based Blockchain deals with a consortium of BPs. This ensures that only trust-worthy BPs contribute who maintain the integrity of every new block. Additionally, a two-third majority of these BPs are required to sign any block prior to adding it to the blockchain, making forgery in block producing extremely difficult. As mentioned earlier, every member in this consortium of block producer gets its chance. That essentially means, that no block producer will get a chance to hold the power for a long time. This removed the chance of even any faulty block producer to influence the ledger for a long time.
  • Operationally flexible The consortium of BPs can be updated in time, ensures trustworthy BPs remain the member of the consortium.

IBFT Consensus Model

  • IBFT uses a pool of block producing nodes (BPs) operating on the Ledgerium Blockchain to determine if a proposed block is suitable for addition to the chain.
  • One BP among the consortium of BPs will deterministically be selected as the Proposer and will propose a new candidate block to the consortium. Once, the supermajority (~66%) is achieved by signing enough no of BPs, the new block will be added to the blockchain.
  • Once the new block is added i.e. consensus round is completed, the role of the Proposer will move to the next in line BP.
  • By adding a new block to the chain means, that state machine is updated across all the BPs and the new block is appended by every BP in their respective public state at the same block height.
  • If not enough no of BPs has signed the block or reject the candidate block, the block will not be inserted and eventually, the Proposer role will be moved to the next BP in line and the process will start afresh.
  • The IBFT consensus implements ‘Block Locking’ mechanism that essentially means, that once the block is inserted, it is finalised, and it cannot be altered later point in time.
  • The IBFT consensus provides system integrity by ensuring that as long as more than 2/3 of the BPs are behaving correctly, the mining or the process of adding new block process continues unabated. This means F (the number of faulty nodes) can be tolerated by the system in order to consensus mechanism to function properly i.e. maximum 1/3 of the BPs are allowed to behave incorrectly (either due to being compromised or due to faulty code).

Heimdall (Proof-of-Stake validator layer)

Heimdall is the PoS validator node that works in consonance with the Staking contracts on the network to enable the PoS mechanism on MAAL. We have implemented this by building on top of Polygon edge which further builds upon 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. 1.
    Validates all the blocks since the last checkpoint
  2. 2.
    Creates a merkle tree of the block hashes
  3. 3.
    Publishes the merkle root to the main chain
Checkpoints are important for two reasons:
  1. 1.
    Providing finality on the Root Chain
  2. 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 MAAL. 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.