Data unavailability is addressed the same way as MVP/plasma classic. There is a mass exit. This is made practical by halting the chain first to avoid gas pressure/network congestion.
Thank you very much for this. Great breakdown of the different plasma proposals it’d be great to add in which ones are actuvely being worked on too as I would imagine some of them reached POC and moved on.
Originally, I designed this as a map of numerous theoretical researches so that anyone can draw a big picture of them. This is the reason why I focused on connecting related researches and wrote short summary about theoretical implication of each. For this reason, I think it is unnecessary to discuss about status of development in here. It would be more proper to make another post about the status of development for each plasma model.
By the full paper, if the data is withheld by the operator and is unavailable, then users vote to halt the chain or not, based on the governance token. But the voting mechanism assumes security based on honest majority and the token distribution. Let’s say a minimum percentage of number of votes needed to halt the chain is N%. If an attacker has N% of governance token or more, then one can always rob those users very easily using data unavailability.
The key point in Plasma is that only valid state transition is enforced in plasma chain by the root chain. If you can’t, at least you should ensure that users can safely exit from that chain. But in your model, if an attacker has those tokens equal or more than N%, invalid state transition can be done and users cannot safely exit anymore.
So the voting mechanism in your model is not a solid solution for data unavailability.
This would be true if N > 50. The recommended value for N is 10. This would require the attacker to control more than 90% of the entire supply to perform the attack you suggest. It would require a huge amount of money to obtain these many tokens from the market (assuming that 90% would even sell). The price would pump so high that it may not even be possible to buy them all. The tokens would be immediately worthless after a successful attack.
This balances the cost of the attack to the theft incentive and makes such an attack impractical. Compare with getting a supermajority hashrate on a POW coin.
Let me explain more precisely. Let’s say total number of tokens is N, and for halting the chain, M tokens should be voted for yes. Then for preventing honest users from halting the chain in the data unavailability, an attacker must have at least N-M+1 tokens (DA attack). And if an attacker has number of tokens equal or more than M, one can always halt the chain forever (DoS attack).
What is interesting in here is, If you set the M low to prevent the data unavailability, the probability of DA attack would be low, but on the contrary, it becomes vulnerable to DoS attack.
Let’s take a look at the table below.
|Total(N)||M(cost of DoS)||N-M+1(cost of DA)|
As you can see, when you set M lower to protect the chain from DA attack, the chain becomes more vulnerable to DoS attack. And the opposite is same as well.
You said that the recommended value of M is 10. Then the chain will be very vulnerable to DoS attack, because an attacker needs only 10% of total tokens. There’s a dilemma here. How can you set the M? And how can you assure that it is not vulnerable to both attacks?
The problem is that this is not the end. There is one more thing you should consider for setting M. The thing is when the benefits of the attack outweigh the costs, there is always an incentive to attack. Let’s say M is 10 and the cost for buying N-M+1 tokens is 100000ETH. Then if the total deposit amount of the chain is bigger than this cost, the attacker would be glad to attack.
Therefore, the amount of total deposit must always be less than the cost of acquiring this N-M+1 tokens to be safe from DA attack. And that is not so good.
If the price of the token crashed like the cryptocurrency market right now, well… you can easily expect what will happen.
The cost of buying even 10% of the supply will be extremely prohibitive. As supply dries up, price would skyrocket. Even if someone did manage to capture 10% and halt the chain, they would have to sacrifice a portion of their tokens as part of voting to halt. The disruption would be a few hours to a couple of days but they cannot steal any funds.
The cost of being a nuisance for a few hours is still very high and not attractive.
Regardless, POS with tendermint consensus is an attractive alternative that eliminates issues with token voting. Your analysis on that piece would also be most appreciated.
Does that mean someone who voted for halting the chain will lose one’s tokens after voting?
There seems to be a misunderstanding among some plasma researchers(like what I did at first). A plasma model should not be dependent on the consensus algorithm(ex. Tendermint, Casper or whatever else). Because that is what the plasma is. Plasma is dependent on the root chain(Ethereum), not the consensus of child chain. Plasma model must ensure that only valid state transition is enforced by the root chain, even if the child chain is byzantine.
In plasma white paper, the authors did recommend to use PoS based consensus in child chain. But it is just recommendation. A solid plasma model should work in even PoA which only has a single node. With repeated emphasis, it doesn’t matter which consensus algorithm is used in the plasma model.
You can definitely build your chain with PoS like Tendermint. But if you did not solve these problems like DA attack, you cannot say that you did design plasma model. It would be more proper to call it a sidechain.
Yes. This disincentives careless or malicious voting to halt
You cannot judge whether a vote is malicious or not in a decentralized way unless you use the slashing conditions like casper. But it means that the security is dependent on the consensus in plasma, not root chain.
BTW, also you cannot use high quorum ratio like 90% because attacker can prevent the halt by occupying 10% of tokens. and the lowest quorum ratio you can use would be 50%.
The root contract slashes some percent of voters tokens. Root contract does not care if the vote is malicious or not, you get slashed if you vote. The idea is that you are willing to sacrifice a portion of tokens whose worth is going to drop in case of a real attack.
Also correct. 10% is recommended but it is counterproductive to go above 50%. The actual parameters depend on the supply, price and distribution characteristics.
Even with a POS consensus on the child chain, slashing bad validators or halting bad exchanges would be enforced by the root chain.
Can you describe why this should be so? My understanding is that the only requirement is that users are able to withdraw funds if the consensus system’s operators/validators fail. The plasma chain itself could have any rules it wants, including POW, POS, POA or any combination thereof.
That is exactly what I mean. This is the reason why the POS with tendermint consensus is not an attractive alternative. You need another way to ensure user’s exit when the consensus system fails like more than 2/3 nodes are byzantine. And the voting mechanism that you mentioned is not a solid solution for this as I said before.
You are suggesting that POS is ok for root chains such as Ethereum or Cosmos but not ok for plasma chains. Do you have any technical reasons or quantitative measures as to why this is so?
I also don’t understand why you think token voting POS is an unsuitable fallback. For the purposes of the Gluon Plasma chain – trading exchanges, it is very effective due to the Pareto distribution of assets.
Your point regarding resistance to both DoS and DA attack have been addressed: The economic cost of mounting such an attack is likely to be higher than any benefits. Just like POW, all consensus mechanisms dissuade the rational attacker.
No, What I said is that you can use POS or whatever consensus in your plasma chains, but you should have additional mechanism for safety like exit-game in Plasma-MVP. That is the reason why I told you using Tendermint is not an attractive alternative.
I can’t understand how you can assure for this. If the total deposit amount of plasma chain that an attacker can take is bigger than the cost, the attacker will always gladly do DA attack. This model will definitely be vulnerable when the total deposit grows or the price of governance token crashed. Do you have any mathematical model or analysis for these cases?
I think this is not so good idea. You can prevent DOS attack definitely, but the operator can withhold data and attack users so that one can make them burn their tokens.
And there is also an issue of the tragedy of the commons. Users have no reason to be active in voting because all the tokens voted to halting the chain in data unavailability. They will always want other users to vote. This is because, if the quorum is filled, they can escape without spending any money. That is why I call it the tragedy of the commons.
Also, users with few assets in the plasma chain are likely not to vote, even if they have the tokens. That is because the cost of voting is likely to be higher than the assets that they can be exit with. I think a more accurate analysis of these various cases is necessary if you want to prove that your solution is solid.
Since you havent described why there needs to be an additional mechanism, let me try to guess: The safety exit mechanism exists to ensure that the security level of the plasma chain is equal to the security level of the rootchain.
The ethereum level security equivalence of mass exits is an illusion. The MVP/Cash (and others) exit constructions are of lower security since they can be spammed with millions of dust deposits and/or fake exits that need to be challenged. Sufficient amount of spam will render many users unable to exit. Every mass exit mechanism right now is of lower security than ethereum. The only exceptions are ZKP and other chains that do not have DA issues. I haven’t yet created a quantification model for the mass exit, but my current guess is Gluon is as secure or more than MVP/Cash.
The cost of the governance tokens will rise as the value locked in the plasma contract increases. This is due to several reasons:
- The people who move tokens to plasma will buy governance tokens to subsidize their trading since higher asset values are followed by higher activity, resulting in higher staking rewards.
- An attacker buying 10% or 90% is similar to a hostile takeover. When a large hard percentage limit of the assets needs to be acquired, the price paid will be the marginal price that any user is willing to pay. An increase in price will bring in even more buyers competing with the attacker. This is a well-known effect in markets.
- Due to the fact that it takes time for books to fill, you have a window of a few days before the crowd rushes in. You can try this yourself by trying to acquire a large percentage of any asset. Try buying 10% of the entire supply of even the cheapest shitcoin and you’ll see how expensive it gets even in a terrible bear market. At 90% it becomes improbable. The only requirement is that the coins are not held by a small (<300) group of people. This is one of the reasons why in stock takeovers, tender offers are used to buy from the public instead of buying it all from the market.
An intuitive way to understand this is a demand supply chart.
Due to the fixed supply, the green line cannot move. Imagine the purple “New Demand” line goes all the way to the top. The new price P2 will be the highest it can be.
Once the operator withholds the data, the chain will halt and the operator is effectively terminated. This is a serious disincentive for forced loss of users tokens at no gain to operator.
Users want to protect their assets on the plasma chain. This is a good reason to vote. Filling the quorum or not is irrelevant. There is no economic incentive to withhold voting since if the operator is compromised, governance tokens are likely to be worthless.
This is only true when the voter is malicious (or plain careless). In the event of a real compromise, all parties detect it simultaneously and everyone knows that tokens will be worthless in a few minutes.
The nature of the tokens to retain value when the operator is honest but lose value when compromised is a key aspect that you may have overlooked.
Tendermint consensus removes the need to halt the chain and associated bad effects. It allows multiple validators instead of a single operator. If a validator is compromised, only that operator’s deposit needs to be slashed. The rest of the system continues to run unaffected
This is not true in general. Assuming a plasma cash chain which only supports single-input transactions as well as single-beneficiary exits, it is possible to require exits to put up a bond. We can analyze the possible attacks against someone in this design and the only one that shows its security level to be below that of the root chain is a direct attack on root chain liveness.
my current guess is Gluon is as secure or more than MVP/Cash.
I think you already understand this from your analysis, but it is worth pointing out that comparison of security of these systems is multidimensional, e.g. one way of breaking it down is to consider
- assuming the child chain mechanism does not get compromised, how can users be attacked?
- assuming the child chain mechanism is compromised, how can users be attacked?
- how likely is it that the child chain mechanism is compromised?
It seems like the answer to (2) is that in the case that the child chain mechanism is compromised, i.e. the PoS block producers withhold data and the 10% token vote threshold is not reached, you do not attempt to provide any guarantees for users?
This is trivial to spam attack with a modest budget:
- Create a few coins.
- Send them around to other addresses that you own creating a long history
- Exit intermediate states simultaneously and fill the gas limit. ie, say 80 exits / eth block assuming 100K gas per exit.
- Keep exiting for the next 10,000 blocks. Some challenges will block exits but many wont.
The original Plasma Cash spec does not specify who deposits bonds, Im guessing its both the exiter and the challenger, in which case challengers can run out of money fast tied up in challenges, while the exiter can re-funnel the money he stole back into the attack.
Ultimately, the cost of the attack should be much higher than the profits. Gluon Plasma is far from perfect, but tries to accomplish this by creating a voting token that needs to be acquired at high cost but loses value on successful attack.
- Ideally, #1 shouldn’t even be possible. Yet, most plasma constructions can be easily spam attacked, overloaded with large proof histories that need to be verified, challenge wallets can be depleted. This is why we dont rely on challenges or allow creation of entry blocks from plasma contract and use compact proofs of validity instead of long tx histories.
- If the child chain is compromised, the chain should halt immediately in a POA model This is the safest way to protect user funds. In a POS model, the bad validator can be eliminated. Many plasma constructions are POA and rely on the individual users to be responsible to exit by themselves. This is a very high bar for people who can barely manage their own private keys. Many people WILL lose a lot of money if such a chain ever attracts people with expertise level below that of members of this forum.
- A POA model is like a centralized exchange. It’s a matter of when, not if it will get compromised. Obviously POS makes it a lot more decentralized and safer because the bad actors will now have to compromise (say) more than 2/3 of the validators.
Why would the plasma contract allow the same coin / range of coins to be successfully withdraw multiple times? The whole point of the plasma cash design is to segregate deposits in such a way that this cannot happen.
in which case challengers can run out of money fast tied up in challenges
If the plasma chain is functioning correctly (only valid and available blocks are committed), there is no need to make challenges that do not immediately succeed (proof: the only invalid exits possible are exits of spent coins, and those can be challenged and cancelled by showing the spend of the coin). Hence
- assuming the child chain mechanism does not get compromised, there are no serious attacks possible against users (the “tie money up in challenges” attack is not possible) in plasma cash; this is no worse than in gluon
- assuming the child chain mechanism does get compromised, a “tie up money in challenges” attack is possible, but this is no worse than in gluon, wherein users will lose money
If the child chain is compromised, the chain should halt immediately in a POA model
When I say the “child chain mechanism” I mean all things not enforced by the plasma contract, including the blocks committed and the outcome of the token vote. Hence the hypothesis of this case analysis is that the PoS block producers maliciously commit invalid/unavailable blocks and also that the token vote to stop them does not happen or does not pass the 10% threshold.
The general point I made was about an inherent weakness of all reactive security models: If the security of the system depends on someone monitoring exits and having to react within a few blocks, then it can be spam attacked. The details would be different for each flavor. In Plasma Cash for example, they may create, transfer and exit huge amount of spent coins simultaneously. The key point is that if challenges are they key to security, a spam/congestion attack is possible and the security cannot be assumed to be equivalent to root chain.