Fast Finality
Problem to Solve by Fast Finality
Finality on Plasma is calculated as the root chain finality + block time on Plasma chain. It is about a few minutes. With Fast Finality function, we are aiming for the finality on Plasma chain to be within 2s.
Bandwidth of Fast Finality
Operator needs collateral to guarantee the fast finality for end-users.
The size of collateral should be equivalent to a size that a merchant receives per normal confirmation time.
Operator needs collateral for each merchant.
Each merchant should check whether they don't receive txs more than the collateral prepared for them.
Fast Finality contract mints special NFT called "Fast Finality Token," and it presents the right to use Fast Finality Contract for merchants. Merchants, hence, can buy bandwidth with Fast Finality token and dispute Operator if they have Fast Finality Token.
Fast Finality Contract
Alice (consumer) sends 1 ETH to Bob (merchant) under the Plasma off-chain network managed by Operator.
- Alice signs the tx and sends 1ETH to Bob. (The tx has the max block number.)
- Bob sends the tx to Operator, and Operator signs the tx
- Operator sends the tx back to Bob.
We call this tx "FF Tx".
Dispute Scenario
First Dispute
If double spend happens (or transaction didn't get included into a Plasma chain block in a certain period), Bob can send "FF Tx" with operator's signature to Fast Finality Contract. Here, Bob wants to claim that "Operator promised to include my transaction in a Plasma chain block soon, but they didn't" This assertion is called 'Dispute' in Vyper code. Bob can finalize this assertion after 2 weeks.
Challenge Dispute
Operator can challenge Bob's First Dispute by showing inclusion-proof of the "FF Tx," claiming that "Bob's tx was in fact included in Plasma chain block, as I promised." In this case, Bob can exit "FF Tx" admitting that his "FF Tx" was actually included in Plasma chain block, giving up on stealing Operator's collateral. Here, there would not be any problem if Bob successfully exits without getting challenged, but when Bob's "FF Tx" gets challenged here, Bob can go to next step called "Second Dispute".
Second Dispute
In the previous section, Bob was challenged by "Double Spend Challenge". However, Bob, in fact, might never have been a malicious actor here. That case, Bob can go carry out "Second Dispute," showing the double spending transaction of "FF Tx". It should neither be an Invalid History Challenge nor Spent Challenge because Bob has checked his coin history before the input of "FF Tx." Also, Bob never used "FF Tx" until he confirms the history before "FF Tx." In this case, Operator and Alice were malicious. After this "Second Dispute" was validated, Bob can withdraw the amount of fund transacted in "FF Tx" from Fast Finality Contract.
- Source code of Fast Finality Contract is here.