Yeah, that was my thought as well.
I was referring to:
1 Like
One can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …
What do you mean by “the corresponding chain”? The plasma chain, or the ethereum chain? It can’t be the plasma chain, because it must be possible to exit even if the plasma chain goes completely offline, and if it’s on the ethereum chain then you could have a mechanism where third parties allow an exit to go through instantly in exchange for putting up a deposit, but that’s basically just buying someone else’s exit slot, which I do expect to be a perfectly normal way for people to quickly cash out.
1 Like
This is probably also an interesting link
https://www.youtube.com/channel/UCG2MeKuKDJRK4gFNk-dQuZQ
not sure why nobody posted this here.
2 Likes
Some people would say that assuming the entire plasma chain to go offline may be a bit of an overkill. If a plasma chain has validators, and if the entire chain goes down, then arguably all users of the chain will have the incentive to bring at least the validators back working, otherwise none of the users will get their money back to the main chain.
What I am saying is that you could have made it a requirement for each Plasma chain operator to maintain a set of validators for her chain 
Plasma is a very interesting idea, but frankly feels like a bit of a risky enterprise, it will be an interesting experiment to see what happens once it is actually released
Cryptocurrencies started as very simple systems run by enthusiasts , and now lit ooks like everything gets complex, I hope these new complex systems will be able to run in the wild and sustain zillions of possible threats and vulnerabilities. It is known that security troubles grow exponentially with complexity … It may be that people try complex things, the complex things crash and people get back to simple things …
4 Likes
Heads up: this might be a naive question, and might have been discussed somehere else.
One great thing with dapps running on the blockchain is interoperability. If I call a smart contract, that contract can in turn call some other contract. Now, in Plasma, I don’t see how my dapp A, deployed on it’s own chain P_A, can contact dapp B, deployed on it’s chain P_B.
Am I wrong? Or is the solution to deploy B to P_A if this is needed?
If this is in fact true, is interoperability something we are sacrificing for scalability here? Or is my understanding just limited at this point?
2 Likes
Minimal Viable Plasma is minimal viable, so the only interaction here is a Plasma chain operating with a parent chain. And Minimal Viable Plasma is about one specific application of transferring ETH.
Nothing is being sacrificed because other more complicated designs can be deployed in addition to this one. Useful ones will get popular and others will be deserted.
Your question triggered this: what if chain B might look like a Plasma from chain A, and chain A might look like a Plasma from chain B?
1 Like
When I said Plasma above I meant Minimal Viable Plasma, sorry . And what you’re saying is that under MVPlasma this is indeed something we sacrifice, or don’t care about.
In theory you could deploy dapp A’s plasma contract on both main chain and chain B, and submit block headers to both?
1 Like
under MVPlasma this is indeed something we sacrifice, or don’t care about.
Yes. Moreover, I doubt anybody is going to implement Minimal Viable Plasma. See Plasma Cash.
3 Likes
What do you mean by a dapp’s plasma contract? On which chain does this dapp reside? What does this dapp do with Plasma?
2 Likes
Sorry I was under the above conditions where we had one dapp per chain. So what I meant is that Chain A can be settled to both main chain and chain B. Not sure how that would work, but I guess nothing stopping you from doing it.
2 Likes
Chain A can be settled to both main chain and chain B.
That sounds like either two parents, or a parent and a grand parent.
Two parent chains sharing one child chain would cause some complications. I don’t know why that would be wanted, except that it sounds fun.
A parent and a grandparent will appear in the Plasma story, but Minimal Viable Plasma is minimal, and it doesn’t have a grandchildren chains because the child chain does not contain code.
In more complicated versions of Plasma with a grandchild chain, users should be able to exit to the grandparent chain, in case the parent chain is not working.
2 Likes
I think the current version of Plasma is not meant to be running dapps … It is a bitcoin-like UTXO chain and it is not so easy to run Turing-complete statefull smart contracts on UTXO
2 Likes
Makes sense, I guess my point is just that it’s hard to imagine cross-chain smart contract calls and I just wonder how that will play out in the future. Any thoughts?
1 Like
One can do crosschain smartcontract calls using threshold signatures. This is what we are developing in our network … Nodes in one chain threshold-sign a message, which is first posted on the ledger of the source chain and is then delivered to nodes in the destination chain, and posted on the ledger of the destination chain. Smart contract programming becomes a bit more involved since cross-chain calls are done using asynchronous messaging (actor model). We have a precompiled smart contract that you call from Solidity if you want to send a message to a contract on another chain …
1 Like
What threshold signature scheme are you using?
We are using a scheme based on BLS / Weil pairing (iBoneh-Lynn-Franklin-Boldyreva threshold signatures). Dfinity is using a similar scheme.
A good thing about this scheme is that it allows for distributed key generation without a trusted party.
Vitalik here has suggested a scheme based on Merkle tree, which is also interesting, we are looking into it too.
I’m wondering if we can use this to halt the chain in case of operator compromise. Currently, we are voting on-root-chain and because we use an account model, the load on the root chain is a lot less than for plasma mvp. A threshold signature scheme may reduce this to a single call on the rootchain and solve the rush to exit issue.
Are you counting votes weighted by % funds held in the contract or something similar?
Yes. Voting by stake was the simplest sybil resistance
The problem is that in some situations the required deposit may be infinite.
Consider an example where Eve deposits $10, spends it in increments of 1 cent by paying to herself, and then exits all intermediate 1000 UTXOs potentially making $5,000
In this example, isn’t it true that 1000 separate fraud proofs would need to be submitted? If $1 gas fee is paid for each fraud proof, the total is $1000 of fees. So you would need to require a deposit of $1000 for each user to compensate for this. But then Eve could pay to herself in increments of 0.1 cent, which would lead to the potential gain of $50,000 for Eve and $10,000 in gas fees for people to stop her. So in general, it seems that the deposit should be infinite.