We have been keeping our heads down and building the core components of Matic Network’s infrastructure, and are excited to share details about the progress that we are making on our journey towards scaling the Ethereum ecosystem.
To remind readers, we have a 3-layered architecture at Matic Network:
Matic Network — Alpha-mainnet
We released an alpha version of the Matic mainnet, termed the Alpha-mainnet, in June 2019. The objective was to release the mainnet to selected DApp partners and ensure full performance and security testing of the network in a real-world scenario.
Any EVM-compatible smart contract is deployable on the Alpha-mainnet with PoS security guarantees.
The Plasma contracts on the Alpha-mainnet support the following workflow:
- User deposits crypto assets in Matic contract on Ethereum
- Once deposited tokens get confirmed on Ethereum, tokens will appear on the Matic Alpha-mainnet 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 Ethereum by establishing proof of remaining tokens on the Root contract (contract deployed on Ethereum)
You can refer to https://blog.matic.network/developer-details-for-alpha-mainnet/ for more details.
Several projects are working on integrating with the Matic Alpha-mainnet as we speak.
We have been hard at work on our Plasma MoreVP (More Viable Plasma) contracts, and we are happy to say that the implementation is now code complete, and we are moving to security audits now.
You can refer to https://ethresear.ch/t/account-based-plasma-morevp/5480 for an overview of our MoreVP implementation.
In short, we now have a better way to manage in-flight exits, and to ensure that users can never lose funds, even if the sidechain operators go rogue.
Security audits will be done by a reputable and well-known security company, specialized in smart contracts audit including audits of similar Plasma implementations.
A detailed overview of our account-based Plasma implementation can also be found here – https://blog.matic.network/finer-details-of-matics-plasma-implementation/.
The contracts can be found here – https://github.com/maticnetwork/contracts.
Plasma Group had previously released the excellent Predicates pattern – https://medium.com/plasma-group/plapps-and-predicates-understanding-the-generalized-plasma-architecture-fc171b25741 – for a generalized Plasma architecture. We absolutely adore these guys for the wonderful (and selfless!) work they do.
We thought it was a great addition to our architecture and we went ahead and implemented Predicates support in our implementation. See this article for more details regarding our implementation- https://plasma.build/t/predicates-in-matic-plasma/86.
Implementing Plasma predicates allows us to now deploy newer state transition support to our Plasma contracts, without having to re-deploy our existing root contracts.
What this means is if we need to add Plasma support for new functionalities, an asset swap, for example, the smart contract back on Ethereum needs to have a way of understanding these changes. Each new piece of functionality — or a new type of “state transition” — requires a change to the logic followed by the Plasma contract.
In previous Plasma specs, adding a feature like this meant that one would have to re-deploy the *entire* Plasma contract and migrate everyone’s assets from the old Plasma chain to the new one. This is not secure, scalable, or upgradeable.
Instead, we can have other smart contracts to implement a function that contains the logic for checking state transition validity. For developers, this means they can add new functionality by creating a new contract that implements the necessary logic for that functionality and then have our main contract reference the new one. These external contracts are called ‘predicates’.
So we now have “partial” support for supporting arbitrary smart contracts. Of course, the developer still needs to code the predicate. But this gives us the ability to add a lot more support to DApps that want Plasma security. Remember Plasma security piggybacks on Ethereum’s Proof of Work security if properly implemented. We want to be able to provide Ethereum DApps with this ability.
ERC20 & ERC721 predicates
The first predicates that we wrote were the ERC20 and ERC721 transfer predicates. We had already implemented asset transfer support (ERC20, ERC721) in our original implementation, but we decided to refactor the code from our root contract to the respective predicates.
The code for these predicates can be found here – https://github.com/maticnetwork/contracts/tree/master/contracts/root/predicates
Asset swap predicates
Next up on the roadmap was asset swap predicates. Once implemented, this would enable us to offer Plasma security guarantees to enable applications such as decentralized exchanges (DEXs), NFT marketplaces and instant swaps among others.
Note that you can still deploy a DEX on Matic Network with Proof-of-Stake guarantees without changing your code on Ethereum. However, this predicate implementation strengthens the security of asset swaps, which can now utilize the power of Plasma and can piggyback on Ethereum’s Proof-of-Work security.
See these links for the implementation details:
Staking Management contracts
Matic is a hybrid Plasma + Proof-of-Stake (PoS) platform. 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 as detailed above.
However, the architecture is such that developers can choose to make use of both in the same application based on their needs.
To enable the PoS mechanism on our platform, we employ a set of staking management contracts on Ethereum. 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.
You can see the contracts for these here – https://github.com/maticnetwork/contracts/commits/pos-contracts. Note these are still work-in-progress.
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 customizing the Tendermint client.
The main chain Stake Manager contract 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.
Ensuring sync of Heimdall with Ethereum smart contracts
We did a lot of re-engineering on this component. 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, 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 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 via a decentralized bridge 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 are working on embedding the Ethereum event relay bridge within the Heimdall node, which allows the trustless relaying of events from Ethereum to Heimdall and vice versa, based on validator consensus.
This is being implemented in the Heimdall node internals.
Design 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.
We are actively working on the Block Producer selection implementation, which is basically the sidechain operator. This will be done by way of a random, unverifiable, unbiasedly factor, which is still being designed. For now, we are using future Ethereum block hashes for the same purpose.
We are in the process of finalizing our staking economics. The major work in this area has revolved around: finding good incentive schemes for Validators in exchange for their services to support the network security; understanding the challenges that come with Layer 2 and simplifying it for the stakers; defining numbers to keep staking attractively profitable even in the case of high token amounts being staked and its gradual decoupling from being the dominant component until enough transactions catch up in the network.
We have allocated a definite amount of tokens from our total supply to be distributed as staking rewards over the course of 5 years. These rewards will be shared with all participants in the consensus mechanism. Token holders who do not wish to run their own node can delegate to a Validator of their choice, thereby strengthening the power of the chosen candidate. The Validator, in exchange for its efforts, charges a cut from the reward and the rest is to be proportionally distributed among all stakers. This covers not only the node running cost but also the checkpointing cost that is crucially important in securing the network by providing finality on the mainchain. Additionally, stakers are also eligible for receiving transaction fees.
We are in the process of designing our slashing mechanism. Our aim is twofold, one is, of course, to make malicious moves by operators punishable and the other is to not let honest mistakes affect one’s staking amount.
We are also working on an interactive program for people to come and participate in our network testing in which they will be rewarded with MATIC tokens in exchange for their support. The plan is to conduct testing in stages and focus on a certain part of the network at every stage in order to make it fully robust. A lot of work will be involved in this process: people working as teams and as opponents trying to break the network, trying to form cartels, bug bounties, designing of different challenges – all of it to be round sure before getting live.
The Matic Wallet app makes the transition for DApp end-users to switch between the Ethereum mainnet and Matic Network very simple, with just a few clicks. We just released the Matic Alpha-mainnet version of the app recently. See https://blog.matic.network/matic-wallet-moves-to-alpha-mainnet/ for more details.
With a browser wallet like MetaMask, you experience a degree of rigidity when you try accessing it on multiple browsers/devices. You are forced to re-enter your seed phrase to migrate your account from one device to another, which increases your vulnerability by having your private key on multiple devices. Our Wallet helps you manage your Ethereum & Matic accounts, wallets and contracts easily and securely.
We now support WalletConnect 1.0 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.
In the latest version of the Matic Wallet, we have introduced a PIN system for securing all your transactions. You can now create an easy to remember 4-digit PIN to safely make transactions using Matic Wallet. The PIN will be used to make any and all transactions with Matic Wallet, such as sending funds or performing any DApp actions.
The PIN was introduced in Matic Wallet as our initial feedback from many users had suggested that they weren’t able to use the app because their phone did not support Touch or Face ID. We listened to this feedback and decided to implement the PIN functionality. For now, we have removed TouchID/FaceID support, but we will be bringing Touch and Face ID back in future updates.
We are heavily focused on building the best UX and UI flow for our end-users. A small part of this focus is to help the user along when he/she is going through the app. As it stands currently, once the transaction happens, we navigate to the Transactions list screen.
We are adding a set of animations now after a transaction is processed, which will give better visual feedback to users. See these screenshots for a sneak preview:
We had chosen React Native (RN) as the technology to be used for the Wallet app. As a small team, we wanted to move fast on the implementation side and since React Native can be used to program once and have apps created for both iOS and Android at once, it presented the ideal solution at the time.
For the first iteration of the app, this was sufficient, but we ran into a lot of small problems – namely relating to the consistency of the app on both platforms. There were some quirks, especially on the UI, which would work well on iOS but not on Android. Since Android has such a vast array of supported devices, it was getting a little difficult to manage.
Also, since we have to do a fair bit of cryptographic work in the backend, we ended up writing Java and Swift bridges for these parts for the app regardless.
Furthermore, some libraries on RN are relatively less mature compared to those on native Android and iOS, especially those to do with animation.
Finally, we have made the decision, based on the above factors, that we now need to move to develop our app on native platforms directly – i.e. iOS and Android respectively. Since the backend components will not require too much of an overhaul, this won’t be a huge undertaking.
We already have Android competencies within our team and are welcoming a great Android engineer onboard shortly, and we are working on bringing in great iOS talent as we speak.
We will be utilizing Kotlin for Android and Swift for iOS. In case you have great iOS skills and are looking to work for an awesome company such as ours, please reach out to email@example.com to apply.
Since the Plasma contracts have undergone major changes in the interfaces and implementation, we are in the process of updating these as well.
Mostly, there will be no breaking changes in the implementation, and only the backend reference code will change. This will ensure DApp developers who use matic.js in their applications will not be affected. Any breaking changes will be communicated to developers before the update.
We have been secretly working on a scalable, modular and realtime Ethereum data processor. We utilize a lot of different backend components, which read data from Ethereum and places it into data stores, which can then be queried speedily. No trust assumptions have to be made since this data can easily be verified by querying Ethereum directly.
However, over time, we found that we have been repeating this process in different components.
It made sense for us to unify the data fetch part of the process, and create a single modularizable component, that all of the other backend components can query from.
This is Hermione, and we will be integrating it to our tech implementation soon.
We have been conducting some excellent conversations with a set of third-party security audit firms and teams, which are currently the best out there in terms of smart contract security. We need to make sure that the audit teams working on our project understand the intricacies of our implementation, and are rock-solid in finding vulnerabilities.
We have been devoting quite some time to evaluating these teams, and we are now ready to start with the audits. The details will be released in due course.
This is an especially niche space. Teams that can effectively conduct Plasma audits need to have done Plasma implementations themselves and/or need to know the subject in a fair bit of detail. This requires extremely high aptitude, and we were looking to find teams with past Plasma audit experience as well. We are looking forward to finding any chinks in our armor and fixing them! 🙂
We take the utmost care in ensuring our contracts are bulletproof, and a second or third pair of eyes will make this process much more robust.
The audit for the Wallet is more traditional, relatively, in terms of penetration testing and private key vulnerabilities. However, no task is an easy task. The Wallet will hold the user’s private keys, which control the funds that a user owns. We want to make sure that the security is water-tight, and that no funds are lost by way of code weaknesses.
Do note this is a non-custodial wallet and we do not control any funds.
Sorry, this was a long update but we have been working tirelessly on the development front and had so much to share. We promise to release updates more frequently to reduce information overload – we recognize that frequent communication is crucial in keeping our community up to speed along our journey!