Heimdall — Vaibhav Chellani — The all — seeing & all — hearing protector of Matic!

Matic Network has a three-layered security architecture in which there are the following entities involved:

1) Block Producers -aka BOR chain: These are involved in batching transactions in blocks to ensure faster confirmation times

2) Validator Layer — aka Heimdall: These are validator nodes that batch the blocks produced by the block producers and push them to the Ethereum

3) Network Watchers -They are actors on the Ethereum, and use fraud proofs to challenge any transaction that they deem fraudulent on the sidechains.

Matic Network -Simplified Architecture Diagram

Heimdall is a large group of validator nodes that serve as a bridge to connect the Ethereum chain and Bor. Anyone can become a validator and run a validator node on Matic chain by staking on Ethereum chain.

Responsibilities of validators under Heimdall include the following:

Verifying transactions in the blocks produced by block producer nodes

Creating the Merkle root of 256 or more blocks

Reaching consensus among validators and pushing the Merkle root to the Ethereum

Communicating with other validator nodes and reaching consensus on the set of blocks to be included in a checkpoint

All validators on receiving a checkpoint, verify it querying their block producer nodes if the Merkle root in a checkpoint matches with the Merkle root they produced for the same set of blocks

Pushing a checkpoint to the mainchain after it has been validated by 2/3rd majority of validators on Heimdall

This is what a checkpoint looks like ?

Heimdall chain makes sure that block producer nodes don’t commit any sort of fraud, hence they don’t trust any information they receive from Bor. Heimdall relies only on Ethereum as a source of truth, for everything ranging from incoming new validators, exiting validators, to reward distribution to validators, etc happens on the Ethereum chain. After a validator related action is performed on smart-contract, the validator can submit a validatorJoin or validatorExit or validatorUpdate transaction on Heimdall. All validators query the smart-contract that manages the validators and validates transactions on Heimdall.

Here are some of the problems we have faced while designing the validator node:

Ethereum and Heimdall are friends for sure, but they don’t share `states` with each other, hence sharing information between these two disjointed chains is difficult.

Ethereum stores all information about who Heimdall has appointed as validators, but has no idea which validator will decide the proposer for the next checkpoint.

Validators on Heimdall need to prove that they have agreed on a checkpoint by signing on it. The signatures would be checked on-chain, Tendermint usesed25519curve like bitcoin whereas Ethereum uses secp256k1so a change of signature scheme on Tendermint chain had to be performed to make it Ethereum compatible.

Data on smart contract changes as validators enter, exit, and new state changes occur. How is a newly synced node supposed to validate transactions which involve interaction with another chain in such cases?

Maintaining sync between Ethereum and Heimdall is hard, but not impossible. In the course of development, we came up with several approaches to solve these issues. It took us many iterations on the drawing board to make this work elegantly.

Here is how sending a checkpoint via Heimdall works right now:

Proposer selected from the validator pool creates a checkpoint by calculating the Merkle root of 256 blocks or more while verifying transactions inside the blocks.

A proposer proposes a checkpoint to all the validators. The checkpoint contains meta information about it so that all other validators can validate it.

All validators on receiving a checkpoint checks if the Merkle root for the given blocks matches with what they have.

If the checkpoint is correct, the validators using the Tendermint consensus engine gossip votes to each other.

Once the checkpoint receives votes from 2/3+ of all validators, the checkpoint is queued on Heimdall to be sent to the Ethereum.

This is when the proposer picks up the votes and submits them on the Ethereum proving to the smart contract that the checkpoint has achieved consensus on Heimdall.

The smart contract on Ethereum chain maintains a record of how many checkpoints have been received and by whom were they submitted and other essential data.

Once the transaction on Ethereum is successful the proposer sends another transaction on Heimdall called ACK ; which contains the checkpoint number which has been assigned to the checkpoint by the smart contract to all the validators that the checkpoint transaction has been accepted by Ethereum.

Everyone is such a skeptic on Heimdall that they themselves check with Ethereum whether the checkpoint was right or not and only then process the transaction. It follows the adage — “Don’t trust. Verify” to the boot.

And finally, a checkpoint is confirmed on Heimdall ?

But but but… What if a proposer doesn’t submit a checkpoint? ?

11. After a certain interval, the next validators in line send a NoAck transaction to all validators, signaling that a checkpoint hasn’t been submitted to the smart contract in a long time and they want to send a checkpoint.

12. Heimdall checks if this is true and allows the next proposer in line to restart the process ?

This two-phase checkpointing allows us to easily keep both the chains in sync and helps us punish proposers who did not submit checkpoint and reward good validators.

We hope this post gave you an overview of how the Validator layer interacts with Ethereum. We will be continuing this series to give you a deeper insight into Heimdall.

May Heimdall reign long!

Source : blog.polygon