Matic is a hybrid Plasma + Proof-of-Stake (PoS) platform. We use a dual-consensus architecture on the Matic Network to optimise for speed and decentralisation. We consciously architected the system to support arbitrary state transitions on our sidechains, which are EVM-enabled
Plasma security guarantees hold for specific state transitions such as the ones we write Plasma predicates for (that we got into details in our last article on predicates – https://blog.matic.network/plasma-predicates-one-step-towards-generalized-plasma/). However, the architecture is such that developers can choose to make use of both in the same application based on their needs.
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 our hybrid construction.
To enable the PoS mechanism on our platform, we employ a set of staking management contracts on Ethereum, as well as a set of incentivized validators running Heimdall and Bor nodes. These implement 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 Matic Network
- Enable penalties/slashing for activities such as double signing, validator downtime, etc.
The PoS mechanism also acts as a mitigation to the data unavailability problem for our sidechains in terms of Plasma.
We have a fast finality layer that finalizes the sidechain state periodically via checkpoints. The fast finality helps us cement 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 and hence high decentralization.
Heimdall (Validator layer)
Heimdall (“the All-Protector) is the purveyor of all that happens in the Matic Proof-of-Stake system – good or bad. It is the all-seeing eye, the one who looks after everyone…never mind. I am going overboard.
Heimdall is our Proof-of-Stake Verifier layer, which is responsible for checkpointing a representation of the Plasma blocks to the main chain in our architecture. We have implemented this by building on top of the Tendermint consensus engine with changes to the signature scheme and various data structures.
The main chain Stake Manager contract works in conjunction with the Heimdall node to act as the trust-less stake management mechanism for the PoS engine, including selecting the Validator set, updating validators, etc. Since staking is actually done on the Ethereum smart contract, we do not rely on validator honesty and instead inherit Ethereum chain security for this key part.
Ensuring sync of Heimdall with Ethereum staking smart contracts
The main difference between Matic’s PoS system and that of others is that 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.
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.
Successfully submitting a checkpoint on Tendermint is a 2-phase commit process; a proposer, selected via the above-mentioned algorithm, sends a checkpoint with his address in the proposer field and all other proposers validate that before adding it in their state.
The next proposer then sends an acknowledgment transaction to prove that the previous checkpoint transaction has succeeded on the Ethereum mainnet. Every Validator set change will be relayed by the Validators node on Heimdall which is embedded onto the validator node. This allows Heimdall to remain in sync with the Matic contract state on the Ethereum mainchain at all times.
The Matic contract deployed on mainchain is considered to be the ultimate source of truth, and therefore all validation is done via querying the mainchain contract.
We have now integrated the Ethereum event relay bridge with the Heimdall node, which allows the trustless relaying of events from Ethereum to Heimdall and vice versa, based on validator consensus.
Generic state event transmitter
Work has begun on a generic event transmitter for contracts on Ethereum to convey events to corresponding Matic entities on the sidechain. We initially anticipated that DApps deployed on Ethereum will exist for a certain time on both chains, and we, therefore, want to ensure that communication is maintained between contracts on both chains.
Bor (the Block Producer layer)
The Bor node or the Block Producer implementation is basically the sidechain operator. The sidechain VM is EVM-compatible. Currently, it is a basic Geth implementation with custom changes done to the consensus algorithm. However, this will be built from the ground up to make it lightweight and focused.
Block producers are chosen from the Validator set and are shuffled using historical Ethereum block hashes for the same purpose. However, we are exploring sources of randomness for this selection.
Our Matic Plasma solution is account-based and uses event logs to track state. This is easily done in the EVM-compatible sidechain VM.
We are excited to roll this out in our upcoming release!