DoS on off-Chain transactions

[krlosMata]

Assuming one operator or several allies operators controls most of the stake in Proof-of-Stake:

• start censoring all off-chain transactions from users by not including them
• users are forced to use on-chain withdraw to exit rollup
• operators get high reward since users are paying high fees for using on-Chain transactions

To summarize, high fees on on-Chain transactions could incentive operators to censor off-Chain transactions

[invocamanman]

Instead of giving more reward to the operators we could burn a high % of the fees in the on-chain transactions, so the users are incentivized to use off-chain Tx and the Operators gets less reward on-chain than off-chain Tx (everyone loses but it should be an edge case right?).
Also, In the transactions on-chain that are mandatory for the users, as Deposit and Withdraw I think that we could lower the fees avoiding burning ether.

[barryWhiteHat]

This seems like a difficult problem to solve. Because you can never tell in the EVM what the actual gas price of a transaction is. Its also difficult to predict how the gas price can evolve over time.

For example if you set the withdraw fee to 1 eth and you burn 0.9 of that eth and use the remaining 0.1 eth to pay the miner. In the sort term 0.1 eth is much higher than an internal rollup transaction so the coordinator is incentivized to censor withdraws. In the long term if the evm gas costs go up its possible that 0.1 eth would not be enough to pay the forced withdraw so this would lead to a trivial dos attack but you have to burn 0.9 eth to get it. However a malicious coordinator who knows this can use it to charge exorbitant withdraw feels.

I think one solution is to replace POS with POB (proof of burn) and then remove the on chain withdarw functionality. POB provies strong anti censorship guarentees so it should be enough to allow only the on chain withdraw.

[krlosMata]

Also, In the transactions on-chain that are mandatory for the users, as Deposit and Withdraw I think that we could lower the fees avoiding burning et

We can specify individually fees depending on on-Chain type transactions:

• Deposit: users must enter the rollup through this function. Operator needs incentives to add them into the rollup, so high fees are required, no need to burn.

• Withdraw: high fee to incentive users to use off-Chain withdraw. Total burn of the fee to avoid DoS from the operator. Operator is incentivized to keep users on rollup.

• Transfer: high fee to incentive users to use off-chain transactions. Fees are paid entirely to operators.

If an operator censor a specific user, the user just will leave the rollup giving no benefit to the operator.

I think one solution is to replace POS with POB (proof of burn) and then remove the on chain withdarw functionality. POB provies strong anti censorship guarentees so it should be enough to allow only the on chain withdraw.

If we remove on-Chain withdraw functionality, how we can avoid that allies operators censor one specific user and then, all operators just burn coins without taking into account that specific user ?
I think user should have the option to force withdraw through on-Chain method.

[barryWhiteHat]

Withdraw: high fee to incentive users to use off-Chain withdraw. Total burn of the fee to avoid DoS from the operator. Operator is incentivized to keep users on rollup.

The question for me is how to prevent the proof of stake coordintaors from requireing users to use the on chain exit in order to gain more fees. They can do this by censoring the offchain withdraw.

If we remove on-Chain withdraw functionality, how we can avoid that allies operators censor one specific user and then, all operators just burn coins without taking into account that specific user ?

In that case they need to burn the users fee for every block that they want to censor that user and the user can just wait until this attack becomes probiaivly expensive.

For example lets say that I want to exit my 1 eth but you won't let me but invocamanman will. I create a transaction that pays a fee of 0.1 eth. I am the only user for invocamanman bids to burn 0.1 eth. You need to bid higher than this to prevent invocamanman from withdrawing me so you bid 0.11 eth. You win and this money gets burned. but then the next block you need to burn 0.11 eth. In order to keep me locked up for 1 day you need to spend

>>> 4 * 60 * 24 *.11
633.6

633.6 eth per day to keep me from withdrawing.

[barryWhiteHat]

Transfer: high fee to incentive users to use off-chain transactions. Fees are paid entirely to operators.

Ah i see what you mean. The coordintors are incentivized to just charge a really high fee for offchain withdraw as they get to keep it all. But the problem is you need to decide upon on onchain_withdraw_fee in a way that is more than the off-chain cost always and with a gas market that chages i think this is difficult.

[barryWhiteHat]

If we remove on-Chain withdraw functionality, how we can avoid that allies operators censor one specific user and then, all operators just burn coins without taking into account that specific user ?

In this case they have to burn extra coins in order to censor. For example imagine that I try to sensor your withdraw. There are two operators me and invocamanman. I don't want you to withdraw invocamanman does not care they just want to make money.

So you create an exit tx with fee 0.1 eth. Since you are the only transaction in the pool invocamanman bids 0.1 eth for the right to make the blcok. Knowing they will get your tx fee and get paid back. I can't let invocamanman win because i know they will include you so i bid 0.11 eth. I have to bid this much for every block. So after 1 day i have to burn

.11 * 4 * 60 * 24 =~ 600 eth

Such a censorship attack costs proportional to how much your fee to withdraw. So users can fight back.

We can specify individually fees depending on on-Chain type transactions:

The problem is that the onchain withdraw has to be set so that a user can withdraw if they have to. But it does not become a dos vector against the coordinator.

When you set the on_chain_withdraw_fee you need to pay for the coordinator to withdraw that user this costs = burn + gas_cost + coordinator_profit

The problem is that the gas_cost portion of the on_chain_withdraw_fee is changeable. If this goes up it can make it not worth it for the coordintaor to withdraw ppl. Which could pause the system and opens them up to dos attacks.

[invocamanman]

The problem is that the gas_cost portion of the on_chain_withdraw_fee is changeable. If this goes up it can make it not worth it for the coordintaor to withdraw ppl. Which could pause the system and opens them up to dos attacks.

But the operators must include the on-chain transactions, in case they are not doing it they will be slashed. So if we burn all the fee from the on_chain_force_withdraw operators just have to mine a Tx for free, but for a certain cost for the user.

[barryWhiteHat]

But the operators must include the on-chain transactions, in case they are not doing it they will be slashed.

They can make empty blcoks and not get slashed.

So if we burn all the fee from the on_chain_force_withdraw operators just have to mine a Tx for free, but for a certain cost for the user.

Then the coordinator has not incentive to process these transactions and we run the risk of everything pausing.

[invocamanman]

They can make empty blcoks and not get slashed.

The operators are forced to include the on-chain transactions that are done in the previous slot.

. There are two operators me and invocamanman. I don't want you to withdraw invocamanman does not care they just want to make money.

But in case the all operators want to censor you, you can't fight back, only have 2 options: get the infrastructure and hardware necessary in order to be an operator and compete with the current ones or waster a lot of ether. The force-withdraw-onchain provides protection for this cases. since operators must include your transactions on-chain.

[barryWhiteHat]

The operators are forced to include the on-chain transactions that are done in the previous slot.

Yes this is true. I misread as off-chain transactions ;)

But in case the all operators want to censor you, you can't fight back, only have 2 options: get the infrastructure and hardware necessary in order to be an operator and compete with the current ones or waster a lot of ether. The force-withdraw-onchain provides protection for this cases. since operators must include your transactions on-chain.

If 100 % are malicious then there is nothing you can do. In proof of stake a 99% majority stake holder can censor off chain transactions 99% of the time. With proof of burn a single honest / rational batcher means censorship attackers have to burn money proportional to that transactions fee.

[krlosMata]

I agree that PoB provides better censorship resistant features in terms of which is the cost for a malicious operator to censor a user off-chain-transaction.

However, taking the worst scenario into account where 100 % operators are malicious users are able to exit rollup through on-chain-withdraw since operators are forced to include those transactions, otherwise they get slashed (PoS) or they just will not bid to forge that specific batch on PoB and the user can become the forger for that concrete batch and process the on-chain-transaction

[barryWhiteHat]

I think its better to split this issue into 2.

1. Should we have an On-chain withdraw
2. Should we use proof of burn or proof of stake. I will create another issue for this.

The problem with having the onchain wihtdraw is that it has a different cost for the coordinator and thus must have a difference price for the user. However a malicious coordinator may censor off chain transactions in order to try and extract more fees from the users and force them to use the on-chain withdraw. This problem gets exaserbated by using proof of stake rather than proof of burn but i will discuss that in the other issue.