in order to dig the feasibility and advantage of Plasma generating framework (i.e. Plasma Generator), I roughly classified Plasma flavors. Feedback is much appreciated 
6 Likes
I think another interesting perspective is to have the three axes to be UX, scaling and security.
Or perhaps a radar chart.
Why do you think that the security level of the verification game isn’t equal with Ethereum?
Is “TinyRAM + Plasma Snapp” flavor discussed somewhere (never seen it being mentioned before)? Thanks!
This is just my gut feeling though, the budget what I need for attack Leap is much cheaper than the attack budget for ETH. And the attack budget of Plasma Cash is the same as ETH.
@nrryuya gave me that motif. But no one digging for now AFAIK.
The attributes and scores(especially Plasma Cash’s security guarantee is oddly undervalued lol) should be elaborated though, that visualization is quiet fair I think.
Red doesnt mean insecure, its just that it needs those pieces. Perhaps red/green is a bad color scheme
Yeah color scheme is gonna be also one of elaboration
Just for initiation, I made a issue to here
https://github.com/ethsociety/learn-plasma/issues/118
I think state transitions proved by SNARKs can include more than token transfers.
I found a issue made by @barryWhiteHat about general dapps in roll_up (https://github.com/barryWhiteHat/roll_up/issues/14) .
It’s said that a merkle tree which holds app specific data is added and only SNARKs can edit that.
TinyRAM wouldn’t comes in here. Although with TinyRAM more complicated programs can be converted to circuits but they would be really expensive to prove.
That was my understanding, too.
I think STARKs is definitely the way to go here. StarkWare is right now deciding what their MVP will be, contemplating between: a) shielded Ethereum transactions, b) grouped transactions (computations) on Ethereum and c) support for DEXs. It would be awesome if they decide to do b), they think they can release the MVP by the end of Q1 2019.
@johba Can you please help fill in the matrix for Leap?
@sg Can you help fill in for Gen?
Anyone know if Plasma prime author is on this forum?
1 Like
Leap works under the same assumptions of the MoreVM exit game.
But i disagree with the green/red table above. It has criteria that are not inherent to the designs itself. Arguably most tweaks that have earned the Gluon column a green field could be applied to the MVP and Cash flavors as well. Especially trowing PoS at data-availability is like trying to create security by obscurity.
Let’s avoid glorified feature lists here and get back to research.
5 Likes
I note still we need constructive approach given
-
Build fair attributes to make Plasma flavors easy to understand for beginners
-
Someone who is enough honest and sensible person fills these attribute as long as possible
-
Project owner of each flavor review that result
I’m sure we all wasting time to explain each flavors’ difference. I ask more help from community, or smarter alternative attitude for this mess.
The plasma flavor comparison table is a use-case fit discussion so that adopters can make an informed decision about whats best for them.
The UX aspect dictates if the product can even be built using a particular flavor of plasma. For example, fast withdrawals is essential for arbitrage and any projects that depend on arbitrage would prefer supporting flavors. Instant finality is a requirement for hedging and HFTs.
Scaling aspect dictates deployment frameworks needed for the project. For example, Light nodes allow running on a desktop or browser vs others that require running in a data center.
Security aspect dictates the size of finances someone should be ok with risking on the network. A product like tipping or memo.cash, where many users have a small amount of coins may be quite OK with a watchtower model since everyone has the same usage pattern. However, any financial model where there are hubs that participate in most of the transactions may find it impractical to watch and challenge a huge number of transactions.
I happen to think what you can do with it is more important than what it is built with. Things are not better simply because something uses a Merkle tree vs snarks if the capabilities and user experience overall is the same.