plasma-contracts: [Process Exit Bounty] Design decisions

Issue Type

[ ] bug report
[x] feature request

Overview

Based on https://github.com/omgnetwork/plasma-contracts/issues/607 This not only removes an extra step while reclaiming exiting funds but also enforces the idea of everyone paying their part for processing their exits rather than passing on the responsibility.

Flow with process exit bounty

1. User starts exit with providing exit bond + process exit bounty 1.a. Providing the bounty is a compulsion( providing bounty should be more economical ) but the user could process their own exits to get the bounty back
2. Ignoring path (1.a), Someone periodically checks for the exit queue size
3. When there is/are new finalized exits in the queue, he processes the exit
4. He receives exit bounty for each exits he has processed

Design Decisions

• What happens to bounty when exit is challenged?

  The bounty could either be added to the bond and given to the challenger (or) The bounty is burnt

• What value of Bounty ensures there is enough incentives always?

  The value of the bounty should be approximately equal to the the gas cost of processing an exit.

  A proposed way to calculate the value of the bounty from the issue earlier-

  process_exit_bounty = const_gas_cost_process_exit * const_ratio% * gas_price_start_exit

  since gas price specified while processing exit is not known, it will be safe to assume the gas price specified while starting the exit ( change from one week)

  So the bounty ≈ gas_usage_process_exits * gas_price_start_exit

  process_exit_bounty = ( K * gas_usage_process_exit * gas_price_start_exit) / 100
  

  which brings us to the question

• What should the value of K be? Should the value of K be updatable?

  K >= 100, K ensures there is appropriate overhead

• What path should be suitable for in-flight exits?

Alternate approach

Since the exit bond is only returned for successful exits, we could combine the bond and bounty and take in value of whichever is higher and refer it to be the bond.

When exits are challenged → the bond is given to the challenger

When exits are finalized → if bounty >= bond, return nothing if bond > bounty, return bond - bounty

But this could increase the complexity, so having separate exit and bounty is the preferred way.

Out of Scope

Having a fixed actor for processing exits is out of scope for now. Allowing anyone to process exits and claim bounty should be good for a start