PG: Fee Predicate

#1

Assuming that you use PG’s predicate architecture, what happens after an exit is finalized, is that the funds under the exit get sent to predicateAddress and then Predicate(predicateAddress).onExitFinalized gets called.

What if a predicate existed that sent X% of the funds to the user and the rest to the operator, as fees?

This should be able to abstract all the potential complexity involving fees.

To take this a step further, if you could do ‘nested’ predicates, you could make it so that the last predicate in the predicates-chain would apply the fee.

I do not have a concrete proposal/spec for this, just expressing the idea.

I’m also a fan of not making fees part of the protocol, since they can be part of the operator’s authentication logic with their users. The operator could check “has user paid $X this month?”. If so include payment, otherwise censor by default.

#2

To take this a step further, if you could do ‘nested’ predicates, you could make it so that the last predicate in the predicates-chain would apply the fee.

That’s sounds interesting to combine predicates.

What if a predicate existed that sent X% of the funds to the user and the rest to the operator, as fees?

Is it a different model from splitting stateUpdate into X% range and the rest range?

This is just my current understanding, so correct me if I’m wrong.I think when plapp developers wanna add fee feature to their predicate, an only requirement that the predicate should equip is atomicity. And the operator can accept only the transaction which has the corresponding fee transaction as you said.

#3

This is a neat idea–the main difference between splitting the range and doing it this way would be that you do not introduce fragmentation–the operator would not be allowed to make the withdrawal of the subrange, they would just know that part of the range will be given to them when eventually exited.

Ultimately, it seems like this is really similar to plasma debit, if you just imagine the operator allocation % as a payment channel balance.

#4

So if all type of predicates in plasma have X % in state(And ideally it is realized by nest), X balance can be inherited to next state. interesting!

#5

How do you prevent the DOS vector on the side chain?
User deposits 0.1 ETH in the plasma chain, with the promise that .01 ETH will be deducted when exiting. Now, the user creates a contract on the side chain which fills up block gas limit, and does that in every block. He can take full advantage of network for same amount as honest user.