Data Availability Solution for Plasma EVM without Confirmation


#1

This is a solution for Data availability problem of Plasma EVM designed by Onther Inc. And I believe this can solve most of the problems. I’m looking forward to get lots of feedback from you.

This is very simplified version. I highly recommend to read this full version.
A proposal for Data availability Solution of Plasma EVM
(Korean)A proposal for Data availability Solution of Plasma EVM

Abstract

This article proposes a model to address the most problematic Data Availability (DA) in Plasma EVM. This model has a new ‘User Request Block’, which is a way for ensuring vaild Exit for users in case of data withholding, while leaving the judgment on DA entirely to the individual user. It also introduces a dynamic fee model to prevent infinite loop attacks by malicious users pretending to behave as if there were DA problems.

New Exit model : User Request Block

Glossary

Non-Request Block(NRB) : Same as nonRequestBlock in Plasma EVM
User Request Block(URB) : Request Block submitted by a user. Unlike the existing Request Block, it contains only transactions that reflect the Exit Request for URB of submitter or other user.
Operator Request Block(ORB) : Request Block submitted by the Operator. It is same as the requestBlock in Plasma EVM.
Exit Request for ORB(ERO) : Exit Request using ORB
Exit Request for URB(ERU) : Exit Request using URB
Rebase : If the URB is submitted based on the most recent finalized block, all child blocks that are submitted but not finalized will be located behind the corresponding URB and transactions that conflict with the URB will be reverted. This is called a Rebase .

Confirmation does not exist anymore in the new model. In addition, whether DA problem occurs or not, is not judged at all in the process of mining and submitting the block. Instead, users who noticed that there was DA problem in child chain can safely exit by committing an URB based on the most recent defined block including their own and other user’s ERUs. Once the URB is committed, then the operator should Rebase the unfinalized blocks to reflect the contents of the URB. If it is judged that there are no problems with the user’s perspective, users can wait until the operator includes one’s Exit request, using ERO instead of ERU like the previous model.

(If you want to fully understand the Rebase, please check this.)

Fee model against Infinite loop attack

Infinite loop attack

The new model left the judgment of ‘block withholding’ to the individual users, and in case of a problem, URB can be submitted for safe Exit at any time. However, there is a fatal vulnerability issue in this model. It is a kind of infinite loop attack using Rebase.

Fee model

We have introduced a model to charge fees for URB and ERU to prevent such attacks.

The design objectives of the fee model are as follows.

1. If the submission of URB is close to the probability that it is an attack by malicious users, the fee should be charged high. And if it is close to the probability that it is an escape from a problem, the fee should be set low.
2. The number of URB commits that generate Rebase should be as low as possible.

DA probability

If an independent individual makes one’s own judgment on DA matters, it is the individual’s judgment that is most relevant to the probability of DA problems. That is, the greater the number of users who believe that there is the DA problem, the greater the likelihood of DA occurrence. On the contrary, if there are fewer users who believe there is DA problem, chances are high that there were no problems with the Child Chain. Therefore, we will design a model that estimates the probability of a DA issue and adjusts the fees for the URB and ERU accordingly through user’s judgments about DA problems, i.e. the number of ERUs .

Cost function

To satisfy the first principle, the higher the number of ERUs in the URB, the lower the URB’s submission costs and the cost of the ERB. In addition, to meet the second principle, it would be desirable to increase the extent of the decreasing cost as the number of ERUs increases.

C_{URB} : Cost for submitting URB
C_{ERU} : Cost for Exit by ERU
N_{ERU} : The number of ERUs in URB

As defined above, a cost function meeting the above conditions may be like below.

Cost of submitting the URB

Cost of ERU


Plasma EVM 2.0: state-enforceable construction
Data Unavailability Unconference @Devcon4
#2

What happens if the URB is withheld by the user or is invalid?


#3

First, the URB cannot be withheld. Because the URB will be submitted based on most recently finalized block. And we all know what that is. That means everyone has the pre-state of URB. Also, we can know all transactions included in the URB as well. Since those transactions are based on ERUs submitted on root chain contract.

Second, the URB could be invalid by a malicious user. That is why we need the challenge period for the URB as well. And during this period, anyone can easily challenge it since the URB is not withheld.

Thank you for the good question @kfichter.


#4

Can these ERUs be challenged as well?


#5


We don’t need to have challenge system for ERUs. Because they are reverted in the process of applying transaction in the URB.


#6

Does every user need to submit their own URB if there’s data availability?


#7


No. they can do, but don’t need to do. If there is DA problem, many users would submit ERU(Exit Request for URB) on root chain contract. Only a few of users would submit URB including these ERUs. And It is very important to handle users’ Exit with minimum number of URBs as it could be DOS attack against the plasma chain. That’s why we set the cost functions of URB and ERU like in the article.


#8

Thanks for taking the time to answer my questions, much appreciated.

So if I understand correctly, users submit ERUs and other users submit URBs that include these ERUs. This has the effect of moving the transactions “back in time” to before the “bad” (withheld) block (?).


#9

Right. Users can make a fork to change canonical chain whenever they think that some blocks are withheld by the operator.

Thanks for your interest. What do you think about this model? Any opinion would be appreciated.