Minimal Viable Plasma

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

Two Questions:

  1. is there a specific reason we don’t put deposits in a queue and mint corresponding balance on plasma chain in batch? instead of 1 exact transaction per block.
  1. may I ask about the latest solution/proposal on the expensive cost incurred by the periodical commits to the root chain, if there are?

1 exact transaction per block.

Simplifies verification

the expensive cost incurred by the periodical commits

Whats the expense here? One unit stored every so many eth blocks is not that high.

One thing that Plasma spec does not specify exactly is who stores which signatures. May be one can edit the description at the beginning of this thread to specify this.

Lets consider an example where

  1. Alice deposits 1000 dollars and creates a 100,000 transactions each time paying 1 cent to herself.

2, In process of doing so Alice generates 100,000 confirmation signatures (several megabytes of data). The question is

a) are these signatures stored longterm by any party except Alice?
It seems that unrelated people will have little incentive to store these signatures.

b) If no-one stores these intermediate signatures, then it seems like Alice can exit all the intermediate UTXOs without a challenge (since to maintain a challenge it seems that one is required to present the signature? The challenge function does require a signature as one of its arguments. If Alice was dealing with herself to create a chain of self-dealing UTXOs, I am not sure who the party will be that will possess the signatures …

3 Likes

The original Plasma paper required these signatures to be broadcast onto the Plasma chain, so you’d avoid (2) at a large data cost to everyone. In your example (off-chain conf sigs), Alice must reveal the one conf sig to spend the next, but this is also broken if Alice is coordinating with the operator, unless these conf sigs must be published on-chain to spend, but then we’re basically back at what the original paper called for.

Basically, you’re right, it’s why I’m trying to get rid of confirmation signatures entirely.

1 Like

Kelvin - I see, so in the original spec the signatures are part of the chain, so everything is fine unless the operator starts witholding them since the operator is the only entity that stores them …

I am not sure if it has been proposed already, but I would like to propose a simple Proof-Of-Burn modification to plasma MVP

Before a user exits a UTXO, the user burns (marks as invalid) this UTXO. A proof of burn is then used to exit the UTXO on the main chain. Plasma operator enforces the rule that burnt UTXOs can not be used.

This seems to solve a significant number of exit problems - in particular, users can not do bad things unless the Plasma operator becomes malicious.

What happens if the operator doesn’t let you burn the coin?

Then you can submit the burn request as a complaint directly to the Plasma smart contract,

Once the request is accepted by the Plasma smart contract, the Plasma smart contract will not accept further Merkle roots from the operator, unless the operator

  • submits a burn proof

or

  • submits a proof that the UTXO has been spent.
1 Like

If the Plasma operator is enforcing this rule, then there doesn’t seem to be a difference between this and having the Plasma operator refuse to include double spends - users already can’t do anything bad unless the operator is malicious.

submits a burn proof

We call this retiring an utxo, but “burn” is better

smart contract will not accept further Merkle roots from the operator

We call this “chain halt” and is used to address all provable byzantine behavior by the operator

1 Like

I think “chain halt” should mean that if someone submits a complaint, the Plasma operator should answer the complaint before the next root is accepted.

If the Plasma operator is not answering the complaint for say 1000, the operator should be marked as tainted and everyone should be allowed to exit according to the holdings based on the last accepted root.

This looks like a pretty reasonable procedure to me and one can extend it to include more complaint types.

Is this a mechanism that you guys are using ?

Putting aside the denial-of-service concerns this raises, what happens if the Plasma operator has already created unavailable blocks? The proof-of-burn will be placed after the unavailable blocks, so it will not be safe to exit from it, right?