Plasma EVM with Continuous Rebase

Authors: Carl Park, Aiden Park, Kevin Jeong

Plasma EVM 페이퍼가 업데이트 되었습니다. link

이번 업데이트는 PDF로 퍼블리시하고 설명 및 다이어그램을 다시 작성하는 것을 포함합니다. 이전 버전과 다른 주목할만한 변경 내역과 근거는 다음과 같습니다.

  • 혼동을 피하기위해 “user-activated fork” 대신 "rebase"를 사용합니다.

    사실 포크는 "fork and rebase"를 내포하지만, 많은 분들이 왜 플라즈마에서 포크를 허용해야하는지 의문을 가졌습니다. 기존의 PoW 블록체인에서 사용된 포크라는 용어는 일반적으로 마이너들의 고의로 혹은 기타 외부 요인으로 동시 다발적으로 발생하는 것을 의미하지만, Plasma EVM에서는 포크가 동시 다발적으로 발생하지 않습니다.

  • “rebase” 가 주기적으로 발생합니다. 유저가 특정 비용을 지불해야만 발생하지 않습니다.

    이전 구조에서는 UAF를 발생시킨 유저에게 여러 파라미터에 따라 높은 비용을 부과했습니다. Rebas는 예외적인 경우로 간주되었습니다. 하지만 이러한 경제적인 접근 방식은 두가지 단점을 가집니다. 1) 비용 모델을 명확히 정의할 수 없습니다. 어떤 파라미터가 고려되어야 하는지(exit을 원하는 유저 수, exit의 전체 경제 비용, 오퍼레이터의 체인 디파짓 등), 비용 함수가 어떤 곡선을 그려야하는지 결정하기 매우 어렵습니다. 2) 높은 비용을 감당하기만 한다면 플라즈마 체인의 트랜잭션을 취소할 수 있습니다.

    Continuous Rebase는 Plasma EVM의 새로운 기본 동작으로 오퍼레이터가 주기적으로 Rebase를 수행하도록 강제합니다. 따라서 오퍼레이터가 rebase를 수행하지 않는 등 예외적인 경우를 다루기 위하여 plasma sanpp의 slashing condition과 같은 halting condition이 필요합니다. 이전 구조에서는 유저가 언제든 포크를 생성할 수 있었다는 점에서 halting condition이 필요하지 않았습니다.

    이러한 방식은 첫번째 문제를 해결하고 두번째 문제를 UAF 비용을 부담하지 못하는 유저들 모두에게 열어둘 수 있습니다. 유저들은 이더리움 트랜잭션 수수료만 부담한다면 누구나 트랜잭션을 취소할 수 있지만, 이는 어디까지나 트랜잭션의 finality 문제입니다.

Request

사용자는 requestable contract가 정의한 request에 따라 상태를 enter 혹은 exit 할 수 있습니다. 만약 request가 루트 체인에서 생성된다면, 자식 체인에는 request transaction의 형태로 반영되며, 해당 트랜잭션의 sender는 0x00, nonce는 0 이며, data 필드는 request 파라미터에 따라 이와 같은 형태로 변형됩니다. 양 체인에 배포퇸 두 requestable contracts 는 컨트랙트에 정의된 규칙에 따라 상태를 상호 교환할 수 있습니다. (RequestableSimpleToken)

3 Types of Block and Epoch

  • 비요청블록(Non-Request Block , NRB): 사용자가 트랜잭션을 보내는 일반 블록. Ethereum, Bitcoin 등 다른 블록체인의 블록과 동일합니다.
  • 요청블록(Request Block, RB): 자식 체인에 요청를 적용하는 블록입니다. 사용자는 request을 생성하고 오퍼레이터는 요청 블록을 생성하여 자식 체인에 요청을 적용합니다. RootChain 컨트랙트에서 트랜잭션 루트를 계산하여 요청 블록에 포함해야 하는 트랜잭션을 강제합니다.
  • 탈출블록(Escape Block, EB): 사용자에게 운영자에 의한 block withholding 공격을 처리하기 위한 요청 블록의 일종입니다. 탈출 블록을 통해 사용자들은 security를 보장받을 수 있습니다.

에폭은 블록들의 주기입니다. 블록 타입별로 에폭 또한 non-request epoch(NRE), request epoch(RE) 및 escape epoch(EE)이 있습니다. 운영자는 반드시 에폭과 같은 유형의 블록을 채굴하고 커밋해야 합니다. 요청 블록과 탈출 블록의 txRoot는 RootChain 컨트랙트에 의해 강제되며, NRB에 요청 트랜잭션이 포함되어 있으면 운영자는 처벌받습니다.

에폭의 길이는 에폭의 블록 수입니다. NRE의 길이는 일정하지만 RE와 EE의 길이는 요청 수에 따라 달라진다.

2 Step Commit and Rebase

Block withholding 공격을 알아차린 사용자에게 탈출구를 제공하기 위해 블록을 루트 체인에 두 번 커밋합니다.

  • Pre-commit 단계에서는 운영자가 블록을 채굴하고 txRoot만 사전 커밋합니다. 사용자들은 루트 체인에 기록된 txRoot에 대한 데이터가 있는지 알 수 있습니다.

  • Pre-commit 또는 DA check 단계에서 사용자는 데이터 가용성에 따라 탈출 요청을 할 수 있습니다. DA 체크 단계는 마지막으로 pre-commit된 블록을 확인할 수 있는 추가 시간을 제공합니다.

  • Commit 단계에서 운영자는 탈출 블록을 채굴하여 pre-commit된 블록 앞에 배치합니다. (Git의 rebase와 같으며 커밋을 다른 브랜치에 적용하는 것과 같습니다. 충돌이 발생할 수 있습니다. 이 경우에는 트랜잭션 취소입니다.) 탈출 에폭은 이전 사이클의 커밋 블록 뒤에 위치합니다. 오퍼레이터가 rebase된 블록의 stateRootreceiptsRoot를 루트 체인에 commit 합니다.

      CommitEpochs[0] = rootchian.EscapeEpochs(cycleNumber)
      CommitEpochs[i] = PreCommitEpochs[i - 1]
    

    Pre-commit 및 commit 단계의 길이는 에폭의 수입니다. commit 단계의 길이는 pre-commit 단계의 길이 + 1입니다.

  • Commit 단계 후, challenge 단계에서 commit된 블록에 대한 챌린지 기간이 시작됩니다. 여기서 사용자는 블록을 검증할 수 있습니다. 왜냐하면, 만약 그럴 수 없다면, DA check 단계에서 자식 체인을 탈출했을 것이기 때문입니다.

운영자가 특정 시간(예: 1일) 동안 pre-commit 또는 commit에 실패한 경우 halting condition이 충족되고 자식 체인이 종료되어 향후 NRB 또는 RB가 커밋되지 않도록 방지합니다. 이 경우 DA check 및 commit 단계만 반복되며 누구나 탈출 블록을 커밋할 수 있습니다.

Cycle

이러한 4단계는 하나의 사이클에 포함됩니다. challenge 단계에서 성공적인 challenge가 없을 경우 사이클과 commit된 블록이 finalize됩니다. Plasma EVM 클라이언트는 commit 단계가 완료되었는지 또는 현재 사이클이 완료되었는지 여부에 관계없이 현재 pre-commit 단계가 완료되기만 한다면 다음 pre-commit 단계를 진행할 수 있습니다.

Block difficulty는 commit 단계에 cycle number보다 높은 우선순위를 부여하기 위하여 1 bit(1 if rebased, otherwise 0) + 127 bits(cycle number) + 128 bits(block number)로 계산됩니다.

Computation Challenge

오퍼레이터가 잘못된 계산으로 블록을 commit하는 경우 사용자는 Truebit와 같은 검증 게임을 통해 챌린지할 수 있습니다. 이 검증 게임에는 도전자와 연산자 간의 두 계층의 상호 작용이 포함됩니다.

첫번째는 잘못된 트랜잭션을 찾는 것입니다. 챌린저는 txIndex로 쿼리하고 오퍼레이터는 [0, ..., txIndex] 트랜잭션들이 계산된 post transactional state와 numSteps로 응답합니다. txIndex == len(txs)일 경우 block sealing(예: 블록 보상)을 확인합니다. txIndex > len(txs)인 경우 오퍼레이터는 [0x00, 0]로 응답하여 transactions out of range에 챌린지합니다. 이 경우, 도전자는 txIndex 트랜잭션의 머클 증거으로 대응해야 합니다.

다음은 잘못된 opcode 단계를 찾는 것입니다. 챌린저가 트랜잭션의 EVM 계산 단계(step)로 쿼리하면 오퍼레이터는 [0, ..., step] opcode가 계산된 이후의 상태로 응답합니다. step == numSteps인 경우 트랜잭션 수수료 공제를 확인합니다.

이러한 챌린지는 데이터 가용성이 보장된 경우에만 가능합니다. 그러나 블록 보류 공격의 경우, 사용자는 DA check 단계(또는 pre-commit 단계)에서 자식 체인을 탈출했을 것입니다.

Limitations

현재 fork and rebase 방식은 트랜잭션 취소 문제를 해결할 수 없습니다. 모든 사이클이 충분히 짧은 경우 이를 완화할 수 있지만, DA check 단계는 모든 사용자가 데이터 가용성을 확인할 수 있을 정도로 충분해야 합니다.

자세한 내용은 페이퍼를 참조하세요.

1 Like

혹시 공개된 소스코드가 있나요? 공개된 소스코드가 있으면 동작과정을 이해하는 것에 더 도움이 될 것 같습니다:+1:

구현 진척도는 다음과 같습니다.

v - Make enter / exit requests
v - Submit NRBs / ORBs
v - Finalize block and requests
o - Challenge on Null Address Transaction in NRBs

1 Like