Plasma is dead? Developers criticized Coindesk for being naive

Four days ago, Coindesk, a blockchain media outlet, published an article claiming that Progress on Plasma’s expansion solution had “stalled.” Plasma developer FourthState Labs has written this post to counter Coindesk’s claims from a developer’s perspective.

What is Plasma?

Since there are so many versions of Plasma in the Ethereum ecosystem today that it’s confusing to us, we thought it would be important to redefine plasma for the uninformed first.

Root chain (e.g. Ethereum) → Infrastructure → PlasmaPlasma is a scale-up solution that allows decentralized applications to move transactions from the root chain to other blockchains, which we can call “side chains” or “plasma chains” that are run by individuals or small sets of validators rather than the entire network layer.

Plasma architecture is unique in that it allows safe operation of the side chain, even in the case of malicious activity. This is done through the use of a unique exit mechanism and cryptographic economy protocol. Users can transfer money securely even if the carrier censors or tampers with the transaction.

2. Misconceptions about Plasma

2-1: Plasma chains are centralized (subject to supervision)

The first misconception most people have about Plasma is that these independently managed side chains are referred to as “centralized entities”.

As Gnosis CTO Stefan George wrote on Coindesk:

“You have an operator that is not trustworthy, that is not decentralized. It’s quite centralised, vulnerable to regulation and so on.”

It is true that most Plasma schemes provide only a single operator; however, we have shown that there are several ways to introduce multiple validators into a single Plasma chain.

Using the Cosmos SDK, we were able to implement a decentralized validation process on Plasma chains, rather than creating proof-of-stake (PoS) -based side chains run by the validator network. These verifiers can use any equity consensus mechanism and reward verifiers according to predefined criteria.

2-2: No one is building the infrastructure for such a scheme

In CoinDesk’s article, the authors claim:

“In multiple iterations of Plasma, there is evidence that research has not gone as well as the original developers had hoped, and very little operational code has been proposed since the concept of Plasma was first proposed.”

This means that versions of Plasma code and progress are directly related to each other. This is naive, and any missing attack vector in Plasma implementation could have disastrous financial consequences. The right focus should not be on releasing production-ready code quickly or getting it to market first, but on delivering a well-designed and secure solution.

Here are some useful references to show that there are many people who continue to study and think about safe Plasma implementations.

Ch /t/plasma-vu…

2. Coordinate financial incentives and defend against DDoS attacks with “watch tower” services and exit bonds: ethresear.ch/t/how-to-pr…

3. Safe deposit of plasma contract to avoid competition with operators: github.com/FourthState…

4. Use the old UTXO on the plasma chain to prevent withdrawal delay attacks: github.com/FourthState…

5. Using decentralized plasma chain to deal with the completion of ethereum blockchain: github.com/FourthState… FourthState Labs and Kyokan (Plasma implementor) are also working together to standardize the Plasma smart contract interface, which can be used for different Plasma side chain implementations. The contract is expected to be audited and go into production in January 2019.

3. Current problems of Plasma

3-1. Large-scale exit scenario

In the case of malicious activity, we need to pay attention to the transaction associated with Plasma chain to prevent the risk of excessive transaction. While no foolproof solution has been proposed to date, there are several ways to reduce this risk:

1) Multi-verifier set for a decentralized Plasma chain, which can reduce the possibility of submitting malicious blocks. At least two-thirds of the verifier set must sign a malicious block in order for the submission to be approved on the main chain.

2) With the right financial incentives, users can delegate the ability to opt out on their behalf to the verifier in order to receive some reward in the event of malicious activity. By modifying the smart contract specification slightly, the verifier can batch these exit transactions into one transaction.

3) Constantly merge UTXOs of the same address, which can greatly reduce the number of UTXOs that each user must exit in case of malicious authentication.

4) Expand the layer 1 basic blockchain. Ethereum developers are working on technologies such as sharding and Casper, and with the release of Ethereum 2.0, the increased capacity of the Layer 1 base blockchain, combined with this expansion plan, should be sufficient to handle a successful mass exit scenario.

3-2. “Plasma’s terminology is confusing”

This is a real problem, and the community is not doing a good job of it. Instead of coordinating studies, developers are debating which Plasma solution is best.

That said, none of the Plasma solutions stands out.

Plasma MVP and Plasma Cash have their own use cases. The only thing these Plasma schemes have in common is the core definition of Plasma.

DApp developers should take the time to understand both implementations and how these solutions solve the problem they are trying to solve.

SNARKs as an alternative

In fact, Plasma isn’t (and shouldn’t be) the only solution to the blockchain scale-up problem.

As described in CoinDesk’s article, it pays to explore the use of tools such as SNARKs and STARKs, technical solutions that offer scalable advantages for verifiable off-chain computing.

In the future, SNARKs technology could be well combined with Plasma MVP to minimize side-chain storage requirements and allow fast synchronization, as well as improving the infrastructure of light clients (providing security advantages for side-chain users).

Having said that, it’s important to note that both technologies are still experimental right now, and should be treated as such.

This means we need to see proof of effectiveness before submitting any solution.

In addition, it is unclear whether the high cost of generation and on-chain proof verification would make the SNARK solution unfeasible.

Do your own technical research and work collaboratively, rather than dissing other people’s solutions

conclusion

As we continue to advance Plasma side chains, we believe that more applications will begin to leverage this infrastructure on decentralized networks.

This discussion can serve as a starting point for a more in-depth discussion of Plasma solutions, and as plasma is better defined and implemented, it will move into the mainstream and be modified. At FourthState, we’ve thought a lot about the business model that supports Plasma and have a lot of ideas for decentralized applications to create new opportunities.

If you’re working on plasma, you can check out Hamdi and Wesley’s Medium blog post and FourthState’s Twitter page.

Original: https://blockchainatberkeley.blog/plasma-isnt-dead-7d0b8c16ad2e author: Hamdi Allam and Wesley Graham translation: free and easy like articles (translated) : Babbitt information (http://www.8btc.com/plasma-isnt-dead)