Data availability solution in plasma

for global state

: Continuous Rebase

박정원(Aiden)

aiden.p@onther.io�19/03/28

<외부자료 활용 시 출처 명시 부탁드립니다.>

Prerequisite

2

• 이더리움의 확장성 솔루션인 플라즈마에 대한 기본적인 이해

​

• Plasma EVM에 대한 기본적인 개념(ex. ORB, NRB, Computation challenge, UAF)

Tokamak Network: Plasma for global state

3

Tokamak Network

​

이더리움과 완전히 동일한 기능 및 구조

​

Why is EVM-on-Plasma hard?

​

• It’s not always clear who gets to move a contract from the Plasma chain to the root chain.
• If anyone can modify the state of the contract, then anyone can block an exit.
• Validating EVM state changes inside the EVM is hard.

​

4

https://medium.com/@kelvinfichter/why-is-evm-on-plasma-hard-bf2d99c48df7

​

Why is EVM-on-Plasma hard?

5

Data availability!

Old idea: UAF(User Activated Fork)

6

• Last Finalized Block을 기준으로 Fork(UAF)를 생성하여 Exit할 수 있게 한다.

​

• 기존의 Not Finalized Block을 Fork 블록을 기준으로 마이닝한다. (Rebase)

UAF: Critical Drawback

7

Cost!!!

• 사용자들이 UAF를 통해 Exit 하기 위해서는 추가적인 비용이 필요

New solution: Continuous Rebase

8

Continuous Rebase 모델은 플라즈마 체인의 정상적인 작동과정에 Rebase를 포함시킨다. 따라서 지속적이고 주기적인 Rebase를 통해 사용자들의 Escape Request를 반영할 수 있게 한다.

​

이를 통해 사용자들은 DA문제가 있을 경우 Escape Request를 제출하여 안전하게 탈출할 수 있다. 또한 제출된 블록이 올바르지 않을 경우 Computation Challenge를 통해 해당 블록들이 Finalize 되는 것을 막을 수 있다.

Keyword: Rebase, Escape Request

What is Escape Request?

플라즈마 체인의 Data availability에 문제가 생겼을 경우에 사용자가 제출하는 긴급탈출 요청

*구조적으로 Exit Request와 동일하다.

What is Rebase?

9

Rebase란?

​

기존 블록을 다른 블록을 기준으로 마이닝하는 것

그 결과 stateRoot와 receiptRoot는 변경되지만 transactionRoot는 변경되지 않음

Rebase - simple example

10

#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!!!

Continuous Rebase: 1 Cycle - 4 steps

11

• Pre-commit: 오퍼레이터가 플라즈마 체인의 블록을 마이닝한 후 각 블록의 txRoot 제출
• DA check: 사용자가 Pre-commit 과정의 DA check, 문제시 Escape Request 제출
• Commit: Process Escape, Rebase의 과정을 수행

3-1. Process Escape: 1,2 에서 제출된 Escape Request를 포함한 Escape Block 마이닝 후 제출

3-2. Rebase: Escape Block을 기준으로 Pre-commit된 블록 Rebase

• Challenge: Commit 된 블록에 대한 챌린지 제출

Continuous Rebase: 1 Cycle - 4 steps

12

Step period

Pre-commit: Epoch Length

DA check, Commit, Challenge: Time

​

Step 1: Pre-Commit

13

• NRB, ORB 마이닝 후 txRoot 루트체인에 제출
• 사용자들에게 마이닝한 블록 전파

Q) 왜 txRoot만을 제출하나요?

​

Pre-commit 에서 제출된 블록들은 Rebase로 인해 StateRoot와 ReceiptRoot가 변경될 수 있기 때문. 또한 해당 블록 안에 포함될 트랜잭션이 무엇인지만 알면 해당 블록의 StateRoot와 ReceiptRoot가 어떻게 연산될지에 대해서 알 수 있음(DA 해결)

Step 2: DA check

14

• 사용자는 Pre-commit 단계의 DA에 문제가 없는지 확인
• 문제가 있을 경우 Escape Request를 제출

​

​

• DA check의 목적은 DA문제 인지 및 대처 기간을 주는데 있다.
• Escape Request 제출시 Pre-commit 블록에서 처리된 ExitRequest가 있다면 반드시 취소 요청을 해야 한다.

Step 3: Commit - Process Escape

15

• Pre-commit, DA check단계에서 제출된 Escape Request를 포함한 Escape Block 제출

​

• Escape Block의 부모블록은 이전 Cycle의 Rebase된 마지막 블록이다.
• 따라서 Escape Request 또한 부모블록 상태에서 올바른 Request 여야 한다.

(If not, 챌린지)

Step 3: Commit - Rebase

16

• Escape Block을 기준으로 Pre-commit된 블록들을 Rebase한다.

​

• 이 때 반드시 Pre-commit된 블록과 Rebase된 블록의 txRoot는 동일해야 한다.
• 단, 각 트랜잭션의 실행결과는 달라질 수 있다.

Step 4: Challenge

17

• Commit 된 블록(Escape Block, Rebase Block)이 올바르지 않을 경우 챌린저는 Computation Challenge를 제출한다.

​

• 단, 올바르지 않은 Escape Request나 Exit Request에 대한 챌린지의 경우 위 과정에서 제출할 수 없다. Commit된 블록이 Finalized 된 후에 제출가능.

Don’t stop me now

18

• 현재 Cycle의 Pre-commit이 완료되면 다음 Cycle의 Pre-commit이 시작될 수 있다.
• 이전 Cycle의 Commit 과정이 완료되기 전에 현재 Cycle의 Commit 과정이 시작될 수 없다.

=> Pre-commit 의 period가 길수록 DA check~Commit period도 길어질 수 있다.

Scenario 1: Data unavailable in Pre-commit

19

• 사용자는 Pre-commit, DA check 단계에서 Escape Request를 제출한다.
• 해당 Escape Request는 이전 Cycle의 마지막 블록을 기준으로 반영되기 때문에 안전하게 Exit 가능하다.

Scenario 2: Operator doesn’t commit

20

- Cycle #2 의 Escape Block을 제출하지 않는 경우

​

- Cycle #3 의 Rebase 단계를 수행하지 않는 경우

​

​

Scenario 2: Operator doesn’t commit

21

- Escape Block을 T동안 제출하지 않는 경우

​

• Cycle #3 의 동작 일시 중단 (진행중인 Pre-commit 단계 중단)
• 사용자들이 Escape Block 제출 가능
• Escape Block 제출시 Cycle #2의 Rebase 단계 및 Cycle #3의 Pre-commit 단계 재개

​

- Rebase 단계를 T동안 수행하지 않는 경우

​

• Cycle #3의 동작 일시 중단 (진행중인 Pre-commit 단계 중단)
• Rebase 단계 재시작

2-1. 추가 Rebase 단계 수행할 경우, Cycle #2의 Challenge 단계 및 Cycle #3의 Pre-commit 단계 재개

2-2. 추가 Rebase 단계 N번 수행 X, Chain Shutdown

Q) Shutdown?

플라즈마 체인 폐쇄 절차. DA check - Process Escape - Challenge 단계를 통해 안전하게 모든 사용자 Exit

Scenario 3: Operator doesn’t pre-commit for T

22

- #2 Cycle에 대한 Commit 과정은 제대로 수행했을 경우

​

​

- #2 Cycle에 대한 Commit 과정 또한 제대로 수행하지 않은 경우

=> Scenario 2와 동일

Scenario 3: Operator doesn’t pre-commit for T

23

- Cycle #2에 대한 Commit 과정은 제대로 수행했을 경우

​

• #3 Cycle의 동작 일시 중단
• #3 Cycle의 Pre-commit 단계 재시작
• 2번 과정 N번 이상 미수행시 Chain Shutdown

Scenario 4: Pre-Cycle is on challenge

24

• #2 Cycle에 대한 챌린지가 진행중인 경우 #2 Cycle을 포함한 이후의 모든 Cycle은 Challenge단계까지 모두 완료되더라도 Fianlize될 수 없다.
• 단, #2 Cycle의 Finalize여부와 관계 없이 이후 Cycle의 진행은 문제 없이 지속될 수 있다.

Scenario 5: Challenge success

25

- 챌린지 대상이 Escape Block이었을 경우

- 챌린지 대상이 Rebase Block이었을 경우

​

​

Scenario 5: Challenge success

26

- 챌린지 대상이 Escape Block이었을 경우

*챌린저는 챌린지 시 본인이 마이닝한 Escape Block 또한 제출해야 한다.

• 해당 블록을 포함한 이후의 모든 블록 취소
• 챌린저가 제출한 Escape Block에 대한 챌린지 시작
• 2번 과정 완료시 Rebase 단계 재시작

- 챌린지 대상이 Rebase Block이었을 경우

• 해당 블록을 포함한 이후의 모든 블록 취소
• Rebase 단계 재시작
• 2번 과정 N번 미완료시 Chain Shutdown

​

Continuous Rebase: Dis/Advantages

27

- Advantages

​

• EVM-on-Plasma 에서 Data availability 해결

(EVM 사용가능, 현재 이더리움 구조 그대로 사용가능)

​

​

​

​

​

​

- Disadvantages

​

• Rebase로 인해 Instant Finality 보장 불가능 => 트랜잭션 취소 가능
• 기존 모델에 비해 블록 제출 비용 약 2배 가까이 상승

​

​

​

What’s next?

28

• Can we guarantee the instant finality?
• Can we minimize canceling tx issue?

​

• Can we support offline mode for users?

​

• Can we minimize gas cost to submit blocks?

Thank you

29