[Cross-Layer Series] Fast Withdrawals in Optimistic Rollups-Part 1

CH Han
Decipher Media |디사이퍼 미디어
13 min readFeb 13, 2022

Author
엄정용, 한충현 of Decipher
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By 정재환

Note : 이 글은 Praveen Surendran의 Fast Withdrawals In Optimistic Rollups — Part 1의 번역본입니다. 오역 발견시 피드백 주시면 반영하겠습니다.

An Introduction to Cross Layer Transfer

Fast Withdrawals In Optimistic Rollups — Part 1

Fast Withdrawals In Optimistic Rollups — Part 2

Standardising Cross-Domain Asset Transfer

시리즈의 두번째 글은 Optimistic Rollups에서의 빠른 인출에 대한 내용입니다. 여기에서는 OR(Optimistic Rollups)에서 입출금이 작동하는 원리와 OR에서 인출이 지연되는 이유, OR에서 사용자가 즉시 출금을 수행할 수 있도록 하는 방법을 설명하고자 합니다.

1. 개요

이더리움 블록체인의 확장성 문제는 글로벌 블록체인 관계자들이 가장 활발히 그리고 장기간 연구한 주제 중 하나입니다. 확장성을 개선하려고 제안된 솔루션들의 공통점은 리소스 제한에도 불구하고 이더리움 네트워크에서 긴느린 처리속도와 낮은 처리량을 극복하는 것이 목표라는 점입니다. 그러면서도 가장 중요한 것은 확장성 솔루션이 네트워크의 신뢰나 중앙화 정도를 희생시키면 안 된다는 것입니다.

일반적으로 우리가 퍼블릭 블록체인의 확장에 대해 논의하면서 두가지 학파를 접하게 됩니다. 그 두가지는 다음과 같습니다.

  1. On-Chain Scaling

이 방법은 코어 블록체인 Layer의 용량을 샤딩(ETH 2.0)과 같은 다양한 기술로 높이는 것을 의미합니다.

2. Off-Chain Scaling

이 방법은 코어 블록체인 Layer를 신뢰 및 중재 Layer로 사용하는 것입니다. 사용자 활동의 대부분은 Layer 2에서 발생하는데, 이때 메인 체인 컨트랙트는 Layer 2에서 발생한 입출금 내역을 추적하고 모든 거래가 규칙에 따라 유효하게 발생하고 있는지 확인하기 위해 여러 증거를 확인합니다.

Layer 2 솔루션은 보안이 이더리움 Layer에 기반하고 있는 Off-chain scaling 솔루션입니다. 사이드체인과 달리, Layer 2 솔루션은 별도의 합의 메커니즘이 없이 기본 Layer의 보안에 주로 의존합니다.

이 게시물에서는 OR을 향한 주요 비판 중 하나인 긴 인출 시간을 살펴볼 것입니다. 그리고 이 시리즈의 두 번째 파트에서는 지연을 처리할 수 있는 방법을 소개합니다.

2. Optimistic Rollups

  1. Quick Overview

Rollup은 높은 가스비와 낮은 처리량 문제를 해결하기 위한 이더리움의 해결책으로 간주되고 있습니다. Rollup은 두 종류가 대표적입니다.

  • Optimistic Rollup
  • ZK Rollup

Optimistic Rollup에 대한 가장 좋은 비유는 실생활에서 수표 기반으로 이루어지는 거래입니다. 만약 은행이 수표 거래를 인정하면 모든 거래가 순조롭게 이루어지고, 은행은 수표에 적힌 금액에 해당하는 현금을 제공할 것입니다. 그러나 만약 은행이 수표를 다양한 이유로 받아들이지 않는다면 해당 금액의 현금은 받지 못하게 됩니다. 마찬가지로 Layer 2에서 발생하는 모든 트랜잭션은 Verifier가 이의를 제기하지 않는다면 그때까지 모든 트랜잭션과 그에 따른 상태 변화는 유효한 것으로 간주됩니다. 사기의 증거가 제출되면 Layer 1이 온체인 트랜잭션을 실행하고 상태변경이 유효한 것인지 여부를 확인합니다. 이때 유효하지 않다고 결론이 난다면 해당 상태를 제출한 노드는 처벌받게 됩니다.

Important Note : 간단한 설명을 위하여 아래 다이어그램은 단일 트랜잭션과 이에 따른 상태 변경으로 설명되며 이 모든 결과는 Layer 1 블록으로 롤업됩니다. 실제로는 단일 트랜잭션이 아니라 여러 트랜잭션의 배치와 해당 상태의 루트가 Layer 1에 롤업되는 것입니다. 보통 시퀀서는 일련의 Rollup 트랜잭션을 일괄 처리하여 Layer 1 블록에 게시합니다.

(출처 : https://medium.com/onther-tech/fast-withdrawals-in-optimistic-rollups-part-1-6fbb93abf1c3, 그림 1)

위의 그림에서 트랜재션 Tx0로 인해 S0에서 S1으로의 상태 변경이 발생하고 그 결과가 Layer 1으로 롤업되는 과정을 확인할 수 있습니다. 트랜잭션 데이터는 데이터 가용성을 보장하기 위해 기본 계층에 호출 데이터로 전달됩니다. OR이기 때문에 출금창에서 오류가 발생하지 않는다면 Layer 1에서 이 거래를 실행할 필요가 없습니다. Raw 트랜잭션 데이터를 체인에 저장하는 것이 체인에서 실행하는 것보다 훨씬 효율적입니다.

(출처 : https://medium.com/onther-tech/fast-withdrawals-in-optimistic-rollups-part-1-6fbb93abf1c3, 그림 2)

아래 그림은 유효하지 않은 상태 S3가 Layer 1으로 롤업되는 과정입니다. 이 상태 전환은 유효하지 않기 때문에 철회 기간 동안 Verifier는 이의를 제기해야 합니다.

(출처 : https://medium.com/onther-tech/fast-withdrawals-in-optimistic-rollups-part-1-6fbb93abf1c3, 그림 3)

Layer 1은 상태 전환 트랜잭션의 유효성을 확인하기 위해 체인에서 해당 트랜잭션을 실행합니다. 이때 사기의 증거가 확인되면 S3로의 상태 변경은 취소되고 원래 상태로 되돌아갑니다.

3. 핵심 구성요소

다음은 OR에서의 핵신 기술의 구성요소를 설명합니다. 다만, 이 아티클에서는 OR 구성요소 중 일부분만을 논의하며, 그 기준은 입출금의 흐름을 이해하는 데 필수적인 요소들입니다.

  1. Optimistic Virtual Machine : 런타임, 상태 전환을 수행

OVM은 L1과 L2 사이 결정적인 스마트 컨트랙트의 실행을 보장하는 샌드박스 환경을 제공합니다. OVM에 대한 자세한 설명은 다음의 글에서 확인할 수 있습니다.

2. Optimistic Geth : 단일 시퀀서를 가진 L2 클라이언트

시퀀서는 트랜잭션 배치를 요구하고 이를 메인 체인의 컨트랙트에 추가해야 합니다.

3. 체인 컨트랙트

OR은 이더리움 메인넷에서 실행되는 컨트랙트들의 세트로 구성됩니다. 이러한 컨트랙트들은 L2 상태를 적용하는 데 활용된 모든 트랜잭션의 목록을 저장합니다. 다음은 체인 컨트랙트 중 두 가지 사례입니다.

  • OVM_CanonicalTransactionChain(CTC)

이는 OVM 상태에 적용되는 컨트랙트로 추가 전용 트랜잭션 로그입니다. 시퀀서는 L2 트랜잭션의 일괄 처리를 CTC에 추가하는 과정을 통해 롤업 상태에 추가해야 하는 트랜잭션들을 대기열에 넣을 수 있습니다.

  • OVM_StateCommitmentChain (SCC)

이는 제안자가 CTC의 각 트랜잭션 결과라고 주장하는 상태 루트 목록을 저장합니다. 이에 해당하는 요소들은 CTC의 트랜잭션과 일대일로 대응된다는 특징이 있습니다.

아래 그림은 각 구성요소가 상호 작용하는 방식을 표현합니다.

(출처 : https://medium.com/onther-tech/fast-withdrawals-in-optimistic-rollups-part-1-6fbb93abf1c3, 그림 4)

이제 L1과 L2에서 입출금 거래가 어떤 과정을 거쳐 이루어지는지 확인해봅시다. 다만, 메신저 컨트랙트와 토큰 브리지에 대한 이해가 필요합니다.

  • 메신저 컨트랙트 : L1과 L2 간 통신은 메신저라고 불리는 두 개의 특별한 스마트 컨트랙트를 통해 가능합니다. OVM_L1CrossDomainMessengerOVM_L2CrossDomainMessenger는 네트워크에 사전적으로 배포됩니다.
  • 토큰 브리지 : 사용자는 자산을 L1에서 L2로 전송하거나 그 반대로 이동하려 할 수 있습니다. 토큰 브리지를 통해 사용자는 Layer간 토큰을 이동할 수 있으며 이러한 토큰 브리지는 위의 메신저 컨트랙트를 사용합니다.

이제 L1 토큰 브리지에 자산을 예치하고, L2 토큰 브리지를 사용해 L2 자산을 받는 과정을 이해하기 위한 설명입니다.

4. Deposit의 작동 원리

아래의 예에서는 Layer 1에서 Layer 2 롤업으로 50개의 ABC 토큰을 전송합니다. 아래 그림은 L1 토큰에 상응하는 L2 토큰을 릴리즈하는 단계를 표현합니다. 트랜잭션이 CTC에 의해 어떻게 대기열에 들어가는지를 확인하고 시퀀서는 롤업 상태에서 대기열에 있는 트랜잭션을 실행해야 합니다.

(출처 : https://medium.com/onther-tech/fast-withdrawals-in-optimistic-rollups-part-1-6fbb93abf1c3, 그림 5)
  • Steps
  1. 사용자는 50개의 ABC 토큰을 토큰 브리지로 전송하여 입금 절차를 시작합니다.
  2. 브리지 컨트랙트는 토큰을 escrow하고 메신저 컨트랙트에서 함수 sendMessage를 호출합니다. 이때 completeDeposit 요청과 함께 토큰을 L2의 해당 토큰 브리지로 전달합니다.
  3. 메신저 컨트랙트는 CRC 컨트랙트가 가진 대기열 기능을 사용하여 트랜잭션을 CTC에 삽입합니다.
  4. 시퀀서는 CTC에서 트랜잭션을 선택하여 L2 메신저 컨트랙트에서 relayMessage 기능을 실행합니다.
  5. 메신저 컨트랙트는 브리지에게 토큰을 릴리즈하여 입금을 마무리하도록 요청합니다.
  6. 새로운 토큰이 L2 주소로 릴리즈됩니다.

5. Withdrawl의 작동 원리

사용자가 L2에서 자산을 인출하기 위해서는 토큰이 L2에서 소각되고 L1 브리지 컨트랙트에 의해 escrow된 토큰이 사용자가 이용할 수 있도록 Lock이 해제됩니다. 아래 그림은 L2에서 L1으로의 50개의 ABC 토큰의 인출 단계를 설명합니다.

(출처 : https://medium.com/onther-tech/fast-withdrawals-in-optimistic-rollups-part-1-6fbb93abf1c3, 그림 6)
  • Steps
  1. 사용자는 L2 토큰 브리지를 사용하여 50ABC의 인출을 시작합니다.
  2. 토큰 브리지는 50ABC를 소각하고 sendMessage 함수를 통해 메신저 컨트랙트에 메시지를 전송합니다.
  3. L2 메신저 컨트랙트는 이 정보를 상태 트리인 L2 상태에 추가합니다.
  4. 시퀀서는 CTC를 새 트랜잭션 배치로 업데이트하고, 이 과정에서 initialWithdrawl 요청이 끝나게 됩니다.
  5. 시퀀서는 msg를 활용하여 상태를 SCC에 게시합니다. 이제 상태 변경에 챌린지할 수 있는 기간이 시작됩니다.
  6. 챌린지 기간이 끝나면 msg를 선택하여 L1 메신저 컨트랙트로 전송할 수 있습니다. 메신저 컨트랙트는 사기 증명 기간이 경과했는지 여부를 확인합니다.
  7. 메신저 컨트랙트는 사용자에게 50 ABC 토큰의 Lock을 해제하기 위해 토큰 브리지에 요청을 전송합니다.

상태 배치는 챌린지 기간(보통 1주일) 후에만 유효한 것으로 간주됩니다. 즉, 사용자는 브리지 컨트랙트에서 토큰이 해제될 때까지 일주일을 기다려야 한다는 것을 의미합니다. 이는 OR의 고유한 특징이며, 인출 시간을 지연시키는 단점이 있지만 롤업의 무결성을 유지할 수 있게 합니다. 그렇다면 챌린지 기간을 시간 지연을 인정하면서 어떻게 즉시 출금이 수행될 수 있을까요?

6. 출금 지연을 해결하기 위한 단서

현재의 챌린지 기간보다 짧은 기간을 선택하면 더 나은 사용자 경험을 제공하지만 보안성이 저하된다는 단점이 있습니다. 따라서 빠른 출금을 위해 분쟁 기간을 무제한으로 단축하는 것은 해결책이 될 수 없습니다.

충분한 챌린지 기간을 유지하면서 보안성을 유지하기 위한 단서는 Canonical Transaction Chain(CTC)에 있습니다. L2 풀노드를 실핸하는 사람은 CTC에서 트랜잭션 로그를 실행하고 출금 성공 여부를 확인할 수 있습니다. 검증은 시퀀서가 상태 루트를 게시하기 전에도 발생할 수 있습니다. 마켓 메이커들은 이 기회를 활용하여 수익을 창출할 수 있습니다. CTC를 확인하고 사용자에게 수수료를 부과하여 사용자에게 즉각적인 유동성을 제공하는 것입니다. 다음 글에서 해당 개념을 상세히 설명할 것입니다.

References

  1. https://research.paradigm.xyz/rollups
  2. https://research.paradigm.xyz/optimism
  3. https://community.optimism.io/docs/protocol/protocol.html
  4. https://starli.medium.com/l2-deep-dive-into-ovm-e2229052ed00
  5. https://ethereum.org/cs/developers/docs/scaling/layer-2-rollups/
  6. https://vitalik.ca/general/2021/01/05/rollup.html
  7. Layer 2 Won’t Save Ethereum. What no one’s talking about: the… | by Jimmy Chang | Coinmonks | Apr, 2021 | Medium
  8. https://www.reddit.com/r/ethereum/comments/lzqhm9/how_does_crossproject_composability_work_for_the/
  9. https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts/contracts/optimistic-ethereum/OVM
  10. https://medium.com/onther-tech/fast-withdrawals-in-optimistic-rollups-part-1-6fbb93abf1c3

--

--