At Matic Network, we have been busy the last few months on building the core platform. Matic provides scalable, secure and instant transactions using Plasma-based sidechains. In short, it allows anyone to create scalable DApps with Ethereum’s security.
Here is a link to our Medium blog on “What is Matic Network” and the technical architecture.
You can also read our whitepaper here.
Key things Matic wants to do:
- Solve scalability by providing Layer 2 solutions
- Application platform for DApp developers on Matic (Like Stripe for DApps/payments)
- Provide assets interoperability for DEXs through 0x protocol and other DApps
- Better UX/UI for mass adoption while having better security and scalability
While we have already announced some of the following updates on social media platforms such as Twitter, this blog is intended to be a collation of all the Technical updates till now.
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 weaker security guarantees — but still equivalent to that of say, NEO or EOS.
The Matic Network has a three layered network security architecture:
- Delegate layer verification (slashing in case of faulty transactions)
- Staker layer verification (slashing in case of faulty transactions)
- Main chain Plasma contracts (bonded fraud proofs)
The aim is to build Plasma fraud proofs for state transitions in the following stages:
Plasma security guarantees hold for ERC20 and ERC721. Other states are secured by a Proof-of-Stake and Delegate layer.
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.
In the final stage, we will introduce support for general state transitions and thereby generic smart contracts, fully secured by Plasma guarantees.
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.
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.
Here is a demo that we presented at the BSIC meetup in Mumbai
We will be releasing developer documentation to access the Matic testnet shortly.
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.
This was the starting point for our foray into the problem of blockchain scaling. Currently, we are actively working on writing the fraud proofs for securing ERC20 and ERC721 assets, using an account-based Plasma implementation.
Code for fraud proofs can be seen here.
Note that development is still going on for these.
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 sidechain, 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.
The beauty of this is that the exit token is now tradable as well 🙂
You can see the ExitNFT being used here — https://github.com/maticnetwork/contracts/blob/master/contracts/root/WithdrawManager.sol. The ExitNFT code is here — https://github.com/maticnetwork/contracts/blob/master/contracts/token/ExitNFT.sol.
For faster withdraws, we are implementing a debt contract mechanism with Dharma Protocol.
On a Plasma chain, there is the concept of a priority queue for exits. Plasma recommends to have a wait period of 7 days in this priority queue. This wait time is very crucial for the security on the sidechain. However, it results in a poor user experience for the users as they have to wait for 7 days to get their assets back on the Mainnet. They should be able to have alternate mechanisms to take their assets out as soon as possible, even if there is a small fee/discount attached to it.
An integration with Dharma can provide faster exits to sidechain users. The exiting user could open a debt request via Dharma for a period of 7 days, with some interest component. A potential Lender could fill this request — say the user wants to withdraw 10 ETH, then she would get 9.98 ETH, which is received immediately from the Lender. We maintain a unique exitToken for any exits on the Plasma chain. This exitToken can be “bought” by another user. This could act as the collateral in the debt contract. If the user does not pay back the 10 ETH to the Lender, a default happens and the exitToken owner can be changed to the Lender, and she will receive the 10 ETH on the mainchain.
Technically, how we ensure risk-free withdrawals in Plasma is by a combination of a 7-day waiting period, watchers (the user or third-parties, including Matic) watching the chain for fraud transactions and the priority queue. As long as someone is watching the chain, there is zero risk in getting the funds withdrawn. Therefore, it would seem Matic or any third-party “chain watchers” can act as the Underwriters and provide appropriate attestation.
Please note that there is significant incentive for watchers to watch the chain and challenge fraud transactions, in case there are any fraud transactions. We can assume that for an Underwriter, since the motivation is getting underwriting fees on loan transactions, they would be open to providing some sort of cover on the loan, if in case the whole mechanism above fails (extremely low probability — no watching happening, etc.).
In the future, we could introduce some sort of staking mechanism for underwriting — but there is sufficient incentive currently to watch and report fraud transactions in terms of bonds to be taken on-chain.The exitToken will be an NFT and the withdrawal money goes to the owner of the NFT. After the 7-day period, once the money is transferred to the owner of the NFT, the NFT also gets burnt so that it can’t be reused ever.
You could also sell the exitToken at a discount at a decentralized exchange as well!
We have a Proof-of-Stake Verifier layer, which is responsible for checkpointing a representation of the Plasma blocks to the main chain in our architecture. We are experimenting with Tendermint to implement this. Development on this front is progressing well.
Our PoS implementation will be built with a combination of Validator nodes and Solidity contracts.
Not all validators will have the same “weight” in the consensus protocol. Voting power will be denominated in Matic tokens.
The main chain Stake Manager contract (currently WIP — Check on Github) will act as the trust-less stake management mechanism for the PoS engine in Tendermint, including selecting the Validator set for a round, updating validators, etc.
The Verifier layer is responsible for activities such as Checkpointing the Plasma blocks, verifying for rogue transactions, etc. in the Matic Network.
- Checkpointing Plasma blocks and transactions
- Validating cryptographic signatures of transactions
This work is progressing well, and we might also end up implementing multiple signature scheme support in Tendermint 🙂
The implementation of Deposit/Withdraw bridges is now complete. These are important infrastructure components, that ensure the correct syncing of assets from the Ethereum main chain to the Matic Plasma chain and vice versa.
This code resides on our private Gitlab repo for now, and we will take a decision on when to open-source it later.
Plasma blocks to SQL sync
Since the Matic Plasma blocks are of ~1 second frequency and can have a theoretical limit of ~65k transactions in 1 block in 1 sidechain, it is very important to have a relational database representation as well for every full node in the Plasma chain. This ensures that querying the node for deep queries is efficient.
This has various internal use cases, including withdraw proof construction, block explorer implementation and others. The implementation of this is almost complete now, and it is in our Gitlab repo.
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 plan to release an alpha version of the wallet shortly.
Dagger is a simple tool, built on top of the Ethereum Network. It 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.
We are proud to announce our recent integration with Zapier. With the Zapier integration up and running you can now listen to events through Dagger such as a “New ERC20 Token Transfer” or a “New Transaction” and then create notifications on multiple apps such as receiving an Email or getting Slack channel message.
For more details, you can read a blog post on this here.
You can also check create your own Zap using Dagger For Ethereum. For more details you can access this link.
Bug Bounty program
We are also initiating discussions with third-party firms such as HackerOnefor our Bug Bounty program. We plan to run a well-funded bounty program for any flaws found in our smart contracts and other software components.