Snapps For A Fully Verified Plasma Chain!

In recent months, Plasma research has come a long way from Plasma MVP. Developers have released specs for a More Minimal Plasma, a More Viable Plasma, a Plasma EVM, a proposed stop guard for dishonest Plasma MVP exits, and more.

Most recently, perhaps, is the development of a specification for Plasma snapp chains – a new iteration of Plasma that uses SNARKs (succinct non-interactive arguments of knowledge) to prove the validity of Plasma chain transactions. To be clear, this is not a complete specification or proof of concept; this is essentially the brainstorming stage. It’s also true that it’s not the only project out there attempting to combine SNARKs and Plasma. However, this effort has been receiving a lot of attention in the Ethereum community and marks a significant stride toward a viable Plasma solution.

A little bit of background: Plasma MVP specifies a “child chain” rooted on the main chain but which has a unique proof-of-authority (PoA) validator, called a Plasma operator. The Plasma operator has the authority to create blocks, which are then sent to and mined on the main chain. There is also a whole system of checks and balances to help ensure the validity of any given transaction, including the requirement that each party provide a confirmation after sending and receiving a payment. This need for confirmation signatures is eliminated with Plasma snapp.

Additionally, under Plasma MVP there is a system in place for challenging so-called dishonest Plasma exits. In other words, when a transacting party attempts to leave the Plasma chain and claims to have more Peth (Plasma ETH) than they truly possess, there is a system for that. This system is the other way in which the new SNARK-utilizing Plasma specification differs from MVP or other versions. Plasma MVP makes a sort of game out of it: Every transacting party attempting to leave the Plasma chain is required to put down a deposit, which is then issued as a bounty to all other parties on the Plasma chain. If anyone can prove that the exit is dishonest, they receive the bounty. If no one can prove dishonesty, the deposit is returned to the exiting party.

Plasma snapp eliminates this exit gaming system and need for confirmation signatures with SNARKs. A summary of the specification describes its usefulness:

“Removing the exit games and confirmation signatures allow us to remove much of the complexity of plasma, which is currently hindering the implementation of more sophisticated protocols beyond simple token-transfers.”

Philippe Castonguay, a developer working on the project, told ETHNews:

“With SNARKs, it’s actually impossible for the operator to even commit an invalid state transition, since this would lead to an invalid snark proof, which the smart contract would reject. Hence, the users don’t need to monitor the operator in case they do something illegal; they know the operator cannot.”

In the introduction to the new specification on the Ethereum Research page, the authors point to recently created signature and hashing mechanisms that reduce proving times and enable the use of SNARKs to prove valid state transitions. These developments have led to the creation of the first proof of concept (PoC) for SNARK-dapps.

The specification for Plasma snapp expands on this existing research. In short, what Plasma snapp offers is a way to prove the validity of a state transition through an EDCC (or smart contract) alone, rather than through incentivizing participation. This is possible because the same research allowing for SNARK-dapps also allows for the entire state of a Plasma chain to be stored in an Ethereum contract. Alongside the entire state of the Plasma chain, the verification keys for transfer, deposit, and exit state changes are also stored in the EDCC stored on the main chain. The specification explains that “these verification keys allow the Plasma contract verifying that the state changes for a new block are actually valid ones.”

In this way, there’s no need for transacting parties to verify each transaction made, or for a whole system to incentivize users to police each other upon exits. This method does require the reliance on an operator for exits, though – the operator must set the withdrawal balance for the exiting party because only the operator has this information. However, as Castonguay stated, it would be impossible for the operator to lie.

There are a couple of complications though. For one, there is the problem of data unavailability, an issue common to many sharding and Plasma projects. The specification outlines, “It could always happen that the operator would publish a StateRootHash and nobody knows the content of this new state.” An attacker could create a block but not publish all of the data – SNARKs do not prevent this, and the results can create major problems because no one can then make blocks that interact with the unavailable block.

The specification provides a strategy for dealing with this, though it is not ideal. If the Plasma operator does not publish a valid block for three days, then the root contract would allow for a swap. If no one can build on the most recent block because they don’t know the contents of the new state, then the specification details an unwinding of the chain until a data-available block is reached.

Castonguay said of the method:

“The data availability solution works, but seems quite inefficient. If we ever get to a point where data is unavailable, reverting to an old state and finding a new operator could take days, which is far too long for most applications to accept. That being said, the data availability problem is complex and an efficient and secure solution is not trivial to find. A lot of people are working on this (not just for Plasma) and I am confident we will find a more efficient scheme to tackle this.”

Waiting three days after block creation has ceased before a new operator can be installed is a difficult enough challenge, but it’s more than that. Because SNARKs still allow for the creation of valid data-unavailable blocks, it could happen that the operator continues creating new, valid blocks that are missing necessary data. The specification does not outline how to address this problem.

It should be emphasized that this is not a complete specification, and any developer working on the project would be quick to tell you this. It’s not an oversight – it’s incompleteness. There’s still a long way to go before the specification is complete, let alone any kind of solid proof of concept or implementation. That being said, the Plasma snapp Gitter channel is host to some discussion around this issue. Some suggest that in this case, as is the case with Plasma MVP, that participants in the Plasma chain simply leave the child chain upon noticing a dishonest operator.

However, for now the issue seems to be on pause:

Castonguay pointed to a number of teams working toward similar goals, including this one. However, through the open-source nature of Plasma snapps, folks from across the Etherverse are capable of collaborating – and, indeed, already are.

Alison is an editor and occasional writer for ETHNews. She has a master’s in English from the University of Wyoming. She lives in Reno with her pooch and a cat she half likes. Her favorite things to do include binge listening to podcasts, getting her chuckles via dog memes, and spending as much time outside as possible.

ETHNews is committed to its Editorial Policy

Like what you read? Follow us on Twitter @ETHNews_ to receive the latest Plasma, Ethereum or other Ethereum ecosystem news.