We have been busy building the core components of Matic Network and are excited to share the progress that we have made to make scaling a reality.
Taking off from our previous update, below is a brief introduction to our network architecture:
ICYMI — Matic Network — Technical Update #1
Technically, any EVM smart contract is deployable on the Matic Network, because we employ an EVM-compatible virtual machine — the Matic VM. However, in the initial versions of the Matic Network, based on the schedule below, generic smart contracts (other than ERC20, ERC721, and specific protocols), will have security guarantees from the PoS layer only rather than both PoS layer and Plasma guarantees which is the case for assets.
The Matic Network has a three-layered network security architecture:
Three Layered Network Security
The aim is to build Plasma fraud proofs for state transitions in the following stages:
Stage 1: Plasma security guarantees hold for ERC20 and ERC721. Other states are secured by a Proof-of-Stake and Delegate layer. Stage 1 development is ongoing right now.
Stage 2: In the second stage, specific protocols will be secured by Plasma guarantees in addition to ERC20 and ERC721. Examples include the 0x decentralized exchange, Dharma debt protocol, etc. Other states are secured by a Proof-of-Stake and Delegate layer.
Stage 3: In the final stage, we will introduce support for general state transitions and thereby generic smart contracts, fully secured by Plasma guarantees. This is a thorny problem, and we have been evaluating many approaches. We will come to this when it is time.
Matic Network on Kovan testnet
We have had our testnet live on Kovan since May 2018. You can see our contracts on Github
The following workflow is currently live on the testnet:
- User deposits crypto assets in Matic contract on the Kovan testnet
- Once deposited tokens get confirmed on the Kovan testnet, tokens will appear on the Matic chain using the Matic Deposit bridge
- The user can now transfer tokens to anyone they want almost instantly (Matic chain has faster blocks — approximately 1 second or less) for almost negligible fees
- Whenever the user wishes to, they can withdraw tokens to the Kovan chain by establishing proof of remaining tokens on Root contract (contract deployed on Kovan chain)
Additionally, any EVM-compatible smart contract is deployable on the testnet.
We are upgrading the testnet shortly with the new Stake Manager contracts as well as integration with the new Proof-of-Stake validator testnet.
In terms of a demo, we have a working prototype of a simple application that is used to demonstrate the capabilities of the Matic Network. We have already released initial developer documentation to access the Matic testnet.
Matic Network — Alpha mainnet
We are actively working on releasing an alpha version of the Matic mainnet shortly. The objective is to release the mainnet to selected DApp partners and ensure full performance and security testing of the network in a real-world scenario.
The alpha mainnet will also support the same workflow as in the Kovan Testnet. Additionally, any EVM-compatible smart contract is deployable on the Alpha mainnet.
We will be releasing developer documentation to access the Matic alpha mainnet shortly.
Plasma smart contracts
We are actively working on the Plasma smart contracts required to secure the Matic Network.
Currently, we are actively working on writing the fraud proofs for securing ERC721 assets, using an account-based Plasma implementation. Fraud proofs for securing ERC20 assets is already developed. Code for fraud proofs can be seen here. Note that development is still going on for these.
It helps developers to move assets from Ethereum chain to Matic chain, transfer assets on Matic and withdraw from Matic to Ethereum using fraud proofs.
We will be improving this library on an ongoing basis to make all features available like Plasma Faster Exit, Challenge exit, Finalize exit and more.
Plasma Exits, including faster withdrawals
Plasma exits have been implemented as well. In our Plasma implementation, when a user wants to withdraw funds from the side-chain, she has to wait for 7 days. When initiating the withdrawal, the user is provided an exit token, structured as a non-fungible ERC721 token, using which they can collect their funds on the expiry of the challenge period. Same ERC721 token can also be used for faster exit through 0x, Dharma & RCN Protocol.
More details can be found here!
We have a Proof-of-Stake Verifier layer (codenamed Heimdall), which is responsible for checkpointing a representation of the Plasma blocks to the main chain in our architecture. We have implemented this by heavily customising the Tendermint client.
The main chain Stake Manager contract (WIP, but almost complete — Check on Github) acts as the trust-less stake management mechanism for the PoS engine in Tendermint, including selecting the Validator set for a round, updating validators, etc.
Our Proof-of-Stake Validator node implementation is almost complete and undergoing final rounds of testing. We intend to release this on testnet shortly.
- We have customised Tendermint for our Proof-of-Stake Validator node (codenamed Heimdall). It runs its own leader selection algorithm on top of Tendermint.
- Proposers aka leaders for a checkpoint are initially selected via the same round robin algorithm Tendermint uses to select proposers. A further custom check is implemented based on checkpoint submission success. This allows us to decouple with Tendermint proposer selection and provides us abilities like selecting proposer only when checkpoint transaction on Ethereum mainnet succeeds.
- Successfully submitting 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 acknowledgement transaction to prove that the previous checkpoint transaction has succeeded on Ethereum mainnet. Every Validator set change will be relayed by the Validators node on Heimdall via a bridge. This allows Heimdall to remain in sync with the Matic contract state on 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 implemented a tokenized proof-of-stake mechanism in the Stake Manager contract, which will enable the staker to get an NFT — ERC721 token on staking funds. Upon unstaking, the ERC721 token is burnt. The token can be used to sell the staking slot to other willing parties via 0x or other protocols. This could also be used as collateral for a CDO (collateralized debt obligation), on say Dharma. Tokenized-PoS will enable smooth UX for validators, where new validators can come and go without much friction (just by transfer of validator stake NFT).
Stake pooling support has been added as well. We will be building the pooling mechanism later. This will allow participants with less than the minimum stake needed to become a Staker to pool in resources and still participate in the Staking process.
With wallets like MetaMask, you experience some kind of rigidity when you try accessing it on multiple browsers/devices. You end up re-entering your seed phrase to migrate your account from one device to another. That also increases the vulnerability of having your private key on multiple devices. Our wallet helps you manage your Ethereum accounts, wallets and contracts easily and securely.
The Matic wallet app also makes the transition for DApp end-users to switch between the Ethereum mainnet and the Matic network very simple, with just a few clicks.
We have integrated with WalletConnect for our Wallet application. WalletConnect helps relay messages using a Bridge server without having access to any of its contents. By connecting your desktop DApp to Matic’s Wallet one can interact with the DApp without your private keys leaving your device and also get notifications on mobile to sign any transactions.
Development on the wallet is in full swing, and we have released a closed alpha version for functional testing. UI design and integration is ongoing. See a snapshot of some screens for an early preview:
Wallet App (UI)
Dagger is a tool, built on top of the Ethereum Network, which provides a way to listen to incoming and outgoing transactions from accounts and contracts, and as well as logs.
With Dagger, if you subscribe to certain kind of topics, then whenever a transaction occurs which complies with subscribed topics, you get a message. Dagger provides a variety of topics to listen to multiple things, including new blocks, incoming/outgoing transactions, new receipts, event logs (with and without filter) and contract creation.
You can read here for more details.
Dagger is available on the Mainnet, and both testnets — Kovan & Ropsten. We are committed to provide Dagger as a production-grade hosted service for DApps and other apps. We are also starting work on a robust data processing open-source platform, codenamed Hermione, which will be announced shortly.
Dagger + Zapier Integration
We’ve published a tutorial for developers & businesses recently. This integration allows you to instantly connect Dagger For Ethereum with 1000 + apps to automate and get transaction detail.
Tutorial for Dagger + Zapier Integration
Signing off and wishing everyone a Happy New Year!