Plasma Predicates — one step towards generalized Plasma
--
We have been working to introduce more generalized scaling techniques, while still ensuring the highest levels of security possible.
One of the promising techniques in the area of Plasma research is Plasma Predicates. We are proud to announce that we are arguably the first team to release support for this in the wild in our upcoming beta-mainnet.
Plasma Group had released the excellent Predicates pattern earlier this year 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 —
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 defined in the Plasma contract via fraud proofs or “state transition checkers”.
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 Plasma functionality by creating a new contract that implements the necessary logic for that feature 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:
Asset swap predicates
Next up on the roadmap was asset swap predicates. This would enable us to offer Plasma security guarantees to enable applications such as decentralized exchanges (DEXs), NFT marketplaces and instant swaps among others. We are happy to say that we have successfully implemented this!
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:
DApp predicates / arbitrary state predicates
Any third-party developer who wants to make use of Plasma guarantees in their DApp can now create predicates of their own.
They just need to make sure to implement the correct interfaces. Examples and interfaces can be found here:
Tutorials
We will be releasing tutorials for developers to start writing predicates on their own soon. These will be added to our documentation here: https://docs.matic.network
Originally published at https://blog.matic.network on September 27, 2019.
