Minimal Viable Plasma

This is probably also an interesting link

https://www.youtube.com/channel/UCG2MeKuKDJRK4gFNk-dQuZQ

not sure why nobody posted this here.

1 Like

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 :slight_smile:

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 :slight_smile:

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 …

3 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?

1 Like

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?

When I said Plasma above I meant Minimal Viable Plasma, sorry :slight_smile: . 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?

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.

2 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?

1 Like

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.

1 Like

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.

1 Like

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

1 Like

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?

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 …

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.

Kinda late but wanted to address your comments.

Running a validator-based chain is in fact vastly more complex than running a Plasma chain. The beauty of Plasma is that it assumes very little about how the child chain functions. In the simplest form, the child chain can even be a proof-of-authority chain with one single block producer. And yet even in this simple and very much centralized form, Plasma still guarantees that the users can safely exit regardless of how the block producer behaves.

To put it another way: Plasma vastly relieves the burden of the person/company operating the Plasma chain, because they can be the most incompetent programmers writing the most buggy code, and yet as long as the smart contract on the root chain is correct (I would imagine there will be OpenZeppelin-like standard implementations), the users won’t lose money.

On the other hand, a naive validator-based sidechain can lose a user’s fund in a million different ways, unless one of the following conditions is true:

  • You make strong assumptions such as “>50% validators are always honest”, which puts great burden on the chain operator since they now have to worry about buggy code, hacks, etc.
  • You design the bridge contract running on the root chain so that it properly handles exiting, fraud proofs, etc., even when validators go rogue. But at that point you are just reinventing Plasma :slight_smile:

I think this problem is avoided if you require a per-exit deposit, rather than a “per-user” deposit.

3 Likes