1. The document describes Continuous Rebase, a data availability solution for fully generalized plasma chains. It allows users to safely escape a plasma chain by submitting Escape Requests if block data is withheld. 2. Blocks submitted to the plasma chain are periodically rebased against Escape Requests to revert invalid transactions. The plasma chain operates in continuous cycles of pre-commit, data availability check, commit, and challenge stages to finalize blocks while guaranteeing users can exit. 3. While Continuous Rebase solves the data unavailability problem, it does not guarantee instant finality as malicious users can cancel transactions by challenging blocks. It also increases block submission costs for operators.

1. Data availability solution in fully generalized
plasma
: Continuous Rebase
박정원(Aiden Park)
aiden.p@onther.io

2. Prerequisite
2
1. Plasma primitives
2. Plasma EVM primitives(ex. Computation Challenge)
Computation Challenge?
Invalid state transition can be challenged by computation challenge using truebit-like
verification game.

3. Tokamak Network: Fully generalized plasma
3
Identical
Root chain(Ethereum) Plasma chain(Tokamak Network)
Tokamak Network is fully generalized plasma chain framework
based on plasma EVM

4. Continuous Rebase
4
Plasma EVM sets Rebase(It is named after git's rebase) as default behavior. It makes the
Plasma chain apply continuously and periodically Escape Request. It allows users to safely
escape based on the last finalized block by submitting an Escape Request if the block data
is withheld.
Keyword: Rebase, Escape Request
What is Escape Request?
Emergency escape request.
Its structure is same as exit request of Plasma EVM.

5. Rebase
5
Re-mining original blocks based on another block.
As a result, stateRoot and receiptsRoot of the block could be changed but
the transactionsRoot should be same as before.
transactionsRoots are same

6. Rebase - simple example
6
#1 Block
A: 100 PETH, B: 0 PETH
#2 Block
tx1: send 100 PETH from A to B (Success)
A: 0 PETH, B: 100 PETH
#1 Block
A: 100 PETH, B: 0 PETH
Escape Block
escape req: exit 100 PETH from A
A: 0 PETH, B: 0 PETH
#2 Block’
tx1: send 100 PETH from A to B (Revert)
A: 0 PETH, B: 0 PETH
Rebase!!!

7. Continuous Rebase: 1 Cycle - 4 stages
7
1. Pre-commit: Operator submits blocks after mining them in plasma chain.
2. DA check: Users check data availability of blocks submitted in Pre-commit. In case of
unavailability, submit Escape Request
3. Commit:
3-1. Operator mine and submit Escape Block which includes Escape Request
3-2. Operator rebase pre-committed blocks based on Escape Block
4. Challenge: Users submit challenge on blocks submitted in Commit

8. Continuous Rebase: 1 Cycle - 4 stages
8
Stage Length
Pre-commit: Epoch Length
Commit: Epoch Length
There is halting condition based on stage period. If it is fulfilled, operator
could lose one’s deposit or the chain could be shutdown. But it always
guarantees that all users can safely exit from the chain.
Stage Period
All stages: Time

9. Q) Why only transactionsRoot?
1. Blocks submitted in Pre-commit will be rebased later, so the stateRoot, receiptsRoot can
be changed.
2. If we know the block body(list of transactions), can easily know valid stateRoot and
receiptsRoot. By comparing transactionsRoot and block data sent from operator, users can
easily check data availability.
Stage 1: Pre-Commit
9
1. Operator mine blocks and submit transactionsRoot of them.
2. Broadcast blocks to users.

10. Stage 2: DA-check
10
1. Users check DA of blocks submitted in Pre-commit.
2. If the data is unavailable, users can submit Escape Request.
- DA-check period should be long enough so that all users can check DA.

11. Stage 3: Commit - Process Escape
11
1. Operator mines and submits Escape Block which includes Escape Request.
- Parent block of Escape Block is last committed block of pre-cycle.
- Escape Request should be valid based on the parent block.
2. Operator rebases pre-committed blocks based on Escape Block.
- transactionsRoot should be same as before.
- But, result of each transaction execution could be different.

12. 1. If block submitted in Commit is invalid, users can challenge this by computation challenge.
- This step is only for submitting challenge. Specific challenge process can proceed after
challenge period.
- If a cycle is on challenge, all subsequent cycles including it cannot be finalized.
Stage 4: Challenge
12

13. Overlap of Cycle
13
1. Pre-commit of next cycle can be initiated after Pre-commit of current cycle is completed.
- Parent block of first block of Pre-commit is last block of pre-committed block of pre-cycle.
2. Commit of current cycle cannot be started before Commit of pre-cycle is completed.

14. Attack scenario: data withholding attack
14
1. Users submit Escape Request in Pre-commit, DA-check.
2. Users can safely exit based on last block of pre-cycle.

15. Attack scenario: invalid block
15
1. Users can challenge in Challenge period.
2. All subsequent blocks including challenge cycle will be canceled in root chain.

16. Continuous Rebase: Dis/Advantages
16
- Advantages
1. Data unavailability is solved in fully generalized plasma.
- Disadvantages
1. Due to the Rebase, cannot guarantee instant finality => malicious users
can cancel their transactions.
2. Block submission cost has increased about twice.

17. Plasma EVM
17
https://github.com/Onther-Tech/plasma-evm
https://github.com/Onther-Tech/plasma-evm-contracts
http://tokamak.network/tech-paper_en.pdf
GitHub Link
Technical paper