이전 Arbitrum 기술 대사가 해설하는 Arbitrum 구성 요소 구조 (상)

2023.12.26

이전 Arbitrum 기술 대사가 해설하는 Arbitrum 구성 요소 구조 (상)

Arbitrum 작동 원리를 한눈에 알아보기

2023.12.26 - 04:18:13

Web3 심층 보도에 집중하고 흐름을 통찰

Arbitrum 작동 원리를 한눈에 알아보기

글: 로벤벤, 전 Arbitrum 기술 대사, 웹3 기여자

본문은 전 Arbitrum 기술 대사이자 스마트 계약 자동 감사 회사 Goplus Security의 공동 설립자였던 로벤벤이 Arbitrum One의 기술을 해설한 글이다.

중국어권에서 Layer2 관련 글이나 자료는 Arbitrum 및 OP Rollup에 대한 전문적인 설명이 부족한 실정이다. 본문은 Arbitrum의 작동 원리를 과학적으로 소개함으로써 이 분야의 공백을 메우고자 한다. Arbitrum 자체 구조가 매우 복잡하기 때문에 최대한 단순화하려 했음에도 불구하고 전체 분량이 1만 자를 넘기므로 상·하편으로 나누어 소개하며, 참고용으로 저장 및 공유하는 것을 추천한다!

Rollup 정렬기 개요

Rollup 확장성의 원리는 두 가지로 요약할 수 있다:

비용 최적화: 대부분의 연산 및 저장 작업을 L1 체인 외부, 즉 L2에서 수행한다.L2는 일반적으로 단일 서버, 즉 정렬기(Sequencer/Operator) 위에서 실행되는 체인이다.

정렬기는 관점상 중심화된 서버와 유사하며, '블록체인 불가능 삼각형'에서 탈중앙화를 포기함으로써 TPS와 비용 측면에서 이점을 얻는다. 사용자는 이더리움보다 훨씬 저렴한 비용으로 L2를 통해 거래 지시를 처리받을 수 있다.

보안 보장: L2에서의 거래 내용과 거래 후 상태는 이더리움 L1에 동기화되며, 스마트 계약을 통해 상태 전환의 유효성을 검증한다. 동시에 이더리움은 L2의 역사 기록을 보관하므로 정렬기가 영구적으로 다운되더라도 누구나 이더리움의 기록을 통해 L2 전체 상태를 복원할 수 있다.

근본적으로 Rollup의 보안은 이더리움에 기반한다. 정렬기가 특정 계정의 개인키를 알지 못한다면 해당 계정 명의로 거래를 시작하거나 자산 잔액을 조작할 수 없으며, 설사 시도하더라도 금방 들통난다.

비록 정렬기가 시스템 핵심으로 중심화 특성을 띠고 있지만, 성숙한 Rollup 솔루션에서는 중심화된 정렬기는 거래 검열 등의 소프트한 악행 또는 고의 다운 정도만 가능하며, 이상적인 Rollup 솔루션에서는 이를 억제할 수단(예: 강제 인출 또는 정렬 증명 등 반검열 메커니즘)이 마련되어 있다.

(루퍼 프로토콜이 L1 컨트랙트 소스코드에 설정한 사용자 호출용 강제 인출 함수)

Rollup 정렬기의 악행을 방지하기 위한 상태 검증 방식은 사기 증명(Fraud Proof)과 유효성 증명(Validity Proof) 두 가지로 나뉜다. 사기 증명을 사용하는 Rollup 솔루션은 OP Rollup(Optimistic Rollup, OPR)이라 불리며, 일부 역사적 이유로 유효성 증명을 사용하는 Rollup은 종종 ZK Rollup(Zero-knowledge Proof Rollup, ZKR)이라 불리며 Validity Rollup이 아니다.

Arbitrum One은 전형적인 OPR로서, L1에 배포된 컨트랙트는 제출된 데이터를 능동적으로 검증하지 않고 문제가 없다고 낙관적으로 간주한다. 만약 제출된 데이터에 오류가 있다면 L2 검증 노드가 도전을 시작한다.

따라서 OPR은 임의의 시점에 적어도 하나의 성실한 L2 검증 노드가 존재한다는 신뢰 가정을 내포하고 있다. 반면 ZKR은 암호학적 계산을 통해 정렬기가 제출한 데이터를 능동적이면서도 저비용으로 검증한다.

(낙관적 롤업 작동 방식)

(ZK 롤업 작동 방식)

본문은 낙관적 Rollup의 선두 주자인 Arbitrum One을 심층적으로 소개하며, 전체 시스템의 모든 측면을 다룰 것이며, 꼼꼼히 읽으면 Arbitrum과 낙관적 Rollup/OPR에 대해 깊은 이해를 할 수 있을 것이다.

Arbitrum의 핵심 구성 요소와 작동 흐름

핵심 컨트랙트:

Arbitrum에서 가장 중요한 컨트랙트는 SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge 등이 있다. 이후 자세히 설명하겠다.

정렬기 Sequencer:

사용자의 거래를 수신하여 정렬하고 결과를 계산하며, 신속하게(보통 <1초) 사용자에게 영수증을 반환한다. 사용자는 몇 초 내에 자신의 거래가 L2에 올라간 것을 확인할 수 있으며, Web2 플랫폼과 유사한 경험을 느낀다.

또한 정렬기는 이더리움 체인 외부에서 즉시 최신 L2 블록을 방송하며, 어떤 Layer2 노드라도 비동기적으로 수신할 수 있다. 하지만 이때 이러한 L2 블록은 최종 결정성이 없으며, 정렬기에 의해 롤백될 수 있다.

몇 분마다 정렬기는 정렬된 L2 거래 데이터를 압축하여 일괄 처리(Batch) 형태로 집계해 Layer1의 수신함 컨트랙트 SequencerInbox에 제출하여 데이터 가용성과 Rollup 프로토콜의 정상 작동을 보장한다. 일반적으로 Layer1에 제출된 L2 데이터는 롤백할 수 없으며 최종 결정성을 갖는다.

위 과정을 통해 다음과 같은 결론을 도출할 수 있다: Layer2는 자체 노드 네트워크를 가지지만, 그 수가 적고 일반적인 공개 체인이 사용하는 합의 프로토콜이 거의 없으므로 보안성이 매우 취약하며, 반드시 이더리움에 의존해야 데이터 게재의 신뢰성과 상태 전환의 유효성을 보장받을 수 있다.

Arbitrum Rollup 프로토콜:

Rollup 체인의 블록 RBlock 구조, 체인 연장 방식, RBlock 발행, 도전 절차 등을 정의하는 일련의 컨트랙트이다. 여기서 말하는 Rollup 체인은 일반적으로 생각하는 Layer2 장부와는 다르며, Arbitrum One이 사기 증명 메커니즘을 구현하기 위해 독립적으로 설정한 추상화된 '체인 형태 데이터 구조'이다.

하나의 RBlock은 여러 개의 L2 블록 결과를 포함할 수 있으며, 데이터도 서로 다르며, 실제 데이터인 RBlock은 RollupCore의 일련의 컨트랙트에 저장된다. 만약 RBlock에 문제가 있다면 검증자는 해당 RBlock 제출자에게 도전을 걸게 된다.

검증자 Validator:

Arbitrum의 검증자 노드는 사실상 Layer2 풀노드의 특수한 하위 집합이며, 현재 화이트리스트 기반 접근이 적용되고 있다.

검증자는 정렬기가 SequencerInbox 컨트랙트에 제출한 거래 일괄 처리(batch)를 기반으로 새로운 RBlock(Rollup 블록, 또는 주장 assertion)을 생성하며, 현재 Rollup 체인의 상태를 모니터링하여 정렬기가 제출한 잘못된 데이터에 도전한다.

능동적인 검증자는 미리 이더리움 체인에 자산을 담보로 예치해야 하며, 때로는 Staker라고도 부른다. 담보를 예치하지 않은 Layer2 노드는 Rollup의 운영 동향을 모니터링하거나 사용자에게 이상 경보를 보내는 등의 역할은 할 수 있으나, 이더리움 체인에서 정렬기의 잘못된 데이터에 직접 간섭할 수는 없다.

도전:

기본 단계는 다단계 상호 세분화와 단일 단계 증명으로 요약할 수 있다. 세분화 단계에서 도전 당사자들은 문제 있는 거래 데이터를 여러 라운드에 걸쳐 세분화하여 결국 오류가 있는 단일 오퍼레이션 코드 명령어를 분리하고 검증한다. '다단계 세분화 - 단일 단계 증명'이라는 패턴은 Arbitrum 개발자들이 사기 증명에서 가장 가스를 절약하는 구현 방식이라고 여긴다. 모든 단계는 컨트랙트 제어 하에 있으며 어느 한쪽도 부정행위를 할 수 없다.

도전 기간:

OP Rollup의 낙관적(optimistic) 본질 때문에 각 RBlock이 체인에 제출된 후 컨트랙트는 능동적으로 검사하지 않고, 검증자가 이를 반증할 수 있는 시간 창을 제공한다. 이 시간 창이 바로 도전 기간이며, Arbitrum One 메인넷에서는 1주일이다. 도전 기간이 끝난 후에야 해당 RBlock이 최종 승인되며, 블록 내에서 L2에서 L1으로 전달된 메시지(예: 공식 브리지를 통한 출금 작업)가 허용된다.

ArbOS, Geth, WAVM:

Arbitrum가 사용하는 가상 머신은 AVM로, Geth와 ArbOS 두 부분으로 구성된다. Geth는 이더리움에서 가장 많이 사용하는 클라이언트 소프트웨어이며, Arbitrum는 이를 경량화하여 수정했다. ArbOS는 네트워크 리소스 관리, L2 블록 생성, EVM과의 협업 등 모든 L2 관련 특수 기능을 담당한다. 우리는 이 두 요소의 조합을 네이티브 AVM, 즉 Arbitrum가 사용하는 가상 머신으로 간주한다. WAVM은 AVM 코드를 Wasm으로 컴파일한 결과물이다. Arbitrum의 도전 절차에서 마지막 '단일 단계 증명'은 WAVM 명령어를 검증한다.

여기서 위 구성 요소들 사이의 관계와 작동 흐름을 아래 그림으로 표현할 수 있다:

L2 거래 생애주기

L2 거래 처리 과정은 다음과 같다:

1. 사용자가 정렬기에 거래 명령을 보낸다.

2. 정렬기는 우선 처리 대기 중인 거래에 대해 디지털 서명 등의 데이터 검증을 수행하고, 무효 거래를 제거한 후 정렬 및 연산을 진행한다.

3. 정렬기는 거래 영수증을 사용자에게 전송한다(보통 매우 빠르다). 하지만 이것은 이더리움 체인 외부에서 정렬기가 수행하는 '사전 처리'로, Soft Finality 상태이며 신뢰할 수 없다. 그러나 정렬기를 신뢰하는 사용자(대부분의 사용자)는 낙관적으로 거래가 완료되었으며 롤백되지 않을 것이라고 간주할 수 있다.

4. 정렬기는 사전 처리된 거래 원시 데이터를 고도로 압축하여 일괄 처리(Batch) 형태로 패키징한다.

5. 일정 시간 간격으로(데이터 양, ETH 혼잡도 등의 요인에 영향을 받음), 정렬기는 L1의 Sequencer Inbox 컨트랙트에 거래 Batch를 게시한다. 이 시점부터 거래는 Hard Finality를 획득했다고 간주할 수 있다.

Sequencer Inbox 컨트랙트

컨트랙트는 정렬기가 제출한 거래 batch를 수신하여 데이터 가용성을 보장한다. 더 깊이 보면, SequencerInbox의 batch 데이터는 Layer2의 거래 입력 정보를 완전히 기록하며, 정렬기가 영구적으로 다운되더라도 누구든지 batch 기록을 바탕으로 Layer2의 현재 상태를 복원하고 고장/도망친 정렬기를 대체할 수 있다.

물리적인 방식으로 이해하면 우리가 보는 L2는 SequencerInbox의 batch의 투영이며, 광원은 STF이다. 광원 STF는 쉽게 변하지 않으므로 그림자의 형태는 물체 역할을 하는 batch에 의해 결정된다.

Sequencer Inbox 컨트랙트는 빠른 상자(fast inbox)라고도 불리며, 정렬기는 이미 사전 처리된 거래를 전용으로 제출하며, 오직 정렬기만이 여기에 데이터를 제출할 수 있다. 이에 대응하는 느린 상자(Delayer Inbox)는 이후 절차에서 설명할 기능을 가진다.

검증자는 항상 SequencerInbox 컨트랙트를 감시하며, 정렬기가 해당 컨트랙트에 Batch를 게시할 때마다 체인 상 이벤트가 발생하고, 검증자는 이 이벤트를 감지하면 batch 데이터를 다운로드하여 로컬에서 실행한 후 이더리움 체인의 Rollup 프로토콜 컨트랙트에 RBlock을 게시한다.

Arbitrum의 bridge 컨트랙트에는 누산기(accumulator)라는 매개변수가 있어 새로 제출된 L2 batch와 느린 Inbox가 새로 수신한 거래 수 및 정보를 기록한다.

(정렬기가 SequencerInbox에 계속해서 batch를 제출함)

(Batch의 구체적인 정보, data 필드는 Batch 데이터에 해당하며, 이 데이터 크기가 크므로 스크린샷에 모두 표시되지 않았음)

SequencerInbox 컨트랙트는 두 가지 주요 함수를 가진다:

addSequencerL2BatchFromOrigin(), 정렬기는 매번 이 함수를 호출하여 SequencerInbox 컨트랙트에 Batch 데이터를 제출한다.

forceInclusion(), 이 함수는 누구나 호출할 수 있으며, 검열 저항 거래를 구현하기 위한 것이다. 이 함수의 작동 방식은 이후 DelayedInbox 컨트랙트에서 자세히 설명한다.

위 두 함수는 모두 bridge.enqueueSequencerMessage()를 호출하여 bridge 컨트랙트 내의 누산기 파라미터 accumulator를 업데이트한다.

가스 가격 책정

분명히 L2 거래는 무료일 수 없다. DoS 공격을 유발할 수 있기 때문이며, 또한 정렬기 자체의 운영 비용과 L1에 데이터를 제출하는 데에도 비용이 들기 때문이다. 사용자가 Layer2 네트워크에서 거래를 시작할 때, 가스 요금 구조는 다음과 같다:

Layer1 리소스 사용으로 인한 데이터 게재 비용, 주로 정렬기가 제출한 batch(각 batch에는 많은 사용자의 거래가 포함됨)에서 발생하며, 비용은 궁극적으로 거래 발신자들이 분담한다. 데이터 게재로 인한 수수료는 동적 알고리즘에 따라 책정되며, 정렬기는 최근 손익 상황, batch 크기, 현재 이더리움 가스 가격 등을 기반으로 가격을 책정한다.

사용자가 Layer2 리소스 사용으로 인해 발생하는 비용, 시스템이 안정적으로 운영될 수 있도록 초당 처리 가능한 가스 상한선을 설정한다(Arbitrum One은 현재 700만). L1과 L2의 가스 지침 가격은 모두 ArbOS가 추적 및 조정하며, 공식은 여기서 언급하지 않는다.

비록 구체적인 가스 가격 계산 과정이 비교적 복잡하지만, 사용자는 이러한 세부사항을 인지할 필요 없이 Rollup 거래 수수료가 이더리움 메인넷보다 훨씬 저렴하다는 것을 명확히 느낄 수 있다.

낙관적 사기 증명

앞서 언급했듯이, L2는 실제로는 빠른 상자에 정렬기가 제출한 거래 입력 batch의 투영에 불과하다. 즉:

거래 입력 -> STF -> 상태 출력. 입력이 확정되고 STF가 불변이라면 출력 결과도 확정된다. 사기 증명과 Arbitrum Rollup 프로토콜 시스템은 출력 상태 루트를 RBlock(또는 주장) 형태로 L1에 게시하고 이를 낙관적으로 증명하는 시스템이다.

L1에는 정렬기가 게시한 입력 데이터와 검증자가 게시한 출력 상태가 있다. 다시 한번 자세히 살펴보자. L1에 Layer2의 상태를 게시할 필요가 있을까?

입력이 출력을 완전히 결정하며, 입력 데이터는 공개적으로 확인 가능하므로 출력 결과-상태를 추가로 제출하는 것은 중복처럼 보일 수 있다. 그러나 이 생각은 L1-L2 두 시스템 사이에 실제로 상태 결제, 즉 L2에서 L1 방향으로의 인출 행위가 상태 증명을 필요로 한다는 점을 간과한다.

Rollup을 구축할 때 가장 핵심적인 아이디어는 대부분의 연산과 저장을 L2로 옮겨 L1의 고비용을 피하는 것이다. 이는 L1이 L2의 상태를 알지 못한다는 의미이며, L2 정렬기가 전체 거래의 입력 데이터를 게시하도록 도울 뿐, L2의 상태를 계산하는 책임은 없다.

인출 행위는 본질적으로 L2가 제공하는 크로스체인 메시지를 기반으로 L1 컨트랙트에서 해당 자금을 해제하여 사용자의 L1 계정으로 이체하거나 다른 작업을 완료하는 것이다.

이때 Layer1의 컨트랙트는 묻는다: 너의 Layer2 상태는 무엇이며, 어떻게 너가 주장한 자산을 실제로 가지고 있다는 것을 증명할 수 있느냐? 이때 사용자는 해당 Merkle Proof 등을 제시해야 한다.

따라서 인출 기능이 없는 Rollup을 구축한다면 이론적으로 L1에 상태 동기화를 하지 않는 것도 가능하며, 사기 증명 등의 상태 증명 시스템도 필요 없다(비록 다른 문제가 발생할 수는 있음). 그러나 현실 적용에서는 이것이 불가능하다.

所謂 낙관적 증명이란 컨트랙트가 L1에 제출된 출력 상태가 올바른지 검사하지 않고, 모두 정확하다고 낙관적으로 간주하는 것이다. 낙관적 증명 시스템은 임의의 순간에 적어도 한 명의 성실한 검증자가 존재한다고 가정하며, 오류 상태가 발생하면 사기 증명을 통해 도전한다.

이러한 설계의 이점은 각 L1에 게시된 RBlock을 능동적으로 검증하지 않아 가스 낭비를 피할 수 있다는 점이다. 실제로 OPR의 경우 각 주장(assertion)을 검증하는 것은 불가능하다. 각 Rblock은 하나 이상의 L2 블록을 포함하며, L1에서 각 거래를 재실행하려면 L1에서 L2 거래를 직접 실행하는 것과 차이가 없어 Layer2 확장성의 의미를 잃게 되기 때문이다.

ZKR은 이 문제를 겪지 않는다. ZK Proof는 간결성을 가지므로 많은 거래에 해당하는 Proof를 실제로 실행하지 않고도 아주 작은 Proof만 검증하면 된다. 따라서 ZKR은 낙관적으로 작동하지 않으며, 매번 상태 게시 시 Verifier 컨트랙트가 수학적으로 검증한다.

사기 증명은 제로지식 증명만큼의 높은 간결성을 가지지 못하지만, Arbitrum은 '다단계 분할 - 단일 단계 증명'이라는 순차적 상호 작용 프로세스를 사용하여 결국 증명해야 하는 것은 단일 가상 머신 오퍼레이션 코드만이며, 비용이 비교적 낮다.

Rollup 프로토콜

먼저 도전을 시작하고 증명을 발동하는 진입점, 즉 Rollup 프로토콜이 어떻게 작동하는지 살펴보자.

Rollup 프로토콜의 핵심 컨트랙트는 RollupProxy.sol이며, 데이터 구조 일치를 보장하는 조건에서 드물게 이중 프록시 구조를 사용한다. 하나의 프록시가 두 개의 구현체 RollupUserLogic.sol과 RollupAdminLogic.sol에 대응하며, Scan 등의 도구에서도 아직 잘 해석되지 않는다.

또한 ChallengeManager.sol 컨트랙트가 도전을 관리하고, OneStepProver 시리즈 컨트랙트가 사기 증명을 판정한다.

RollupProxy에서 다양한 검증자가 제출한 일련의 RBlock(또는 주장)을 기록하며, 아래 그림의 사각형: 녹색 - 확인됨, 파란색 - 미확인, 노란색 - 반증됨.

RBlock에는 이전 RBlock 이후 하나 이상의 L2 블록 실행 후 최종 상태가 포함된다. 이러한 RBlock은 형식적으로 Rollup Chain을 구성한다(주의: L2 장부 자체와 구별됨). 낙관적인 경우 이 Rollup Chain은 포크가 없어야 하며, 포크가 있다는 것은 검증자가 서로 충돌하는 Rollup Block을 제출했다는 의미이다.

주장을 제출하거나 동의하려면 검증자가 먼저 해당 주장에 대해 일정량의 ETH를 담보로 예치하여 Staker가 되어야 한다. 이렇게 함으로써 도전/사기 증명 발생 시 패배자의 담보가 몰수되며, 이는 검증자의 성실한 행동을 보장하는 경제적 기반이다.

그림 우측 하단의 111번 파란색 블록은 결국 반증될 것이다. 왜냐하면 그 부모 블록인 104번 블록이 잘못되었기 때문이다(노란색).

또한 검증자 A는 106번 Rollup Block을 제출하였고, B는 이에 동의하지 않아 도전을 걸었다.

B가 도전을 시작한 후 ChallengeManager 컨트랙트는 도전 절차의 세분화 과정을 검증한다:

1. 세분화는 양측이 번갈아 상호 작용하는 과정으로, 한쪽이 특정 Rollup Block에 포함된 역사 데이터를 분할하고, 다른 쪽이 어느 부분의 데이터 조각에 문제가 있는지 지적한다. 이진법(N/K 방식)과 유사하게 범위를 점진적으로 좁혀가는 과정이다.

2. 이후 어느 거래와 결과에 문제가 있는지 위치를 정확히 하고, 더 나아가 해당 거래에서 논쟁이 되는 특정 머신 명령어까지 세분화할 수 있다.

3. ChallengeManager 컨트랙트는 원시 데이터를 세분화한 후 생성된 '데이터 조각'이 유효한지만 검사한다.

4. 도전자와 도전 대상자가 논쟁의 대상이 되는 머신 명령어까지 위치를 찾은 후, 도전자는 oneStepProveExecution()을 호출하여 단일 단계 사기 증명을 보내고, 이 명령어의 실행 결과에 문제가 있음을 입증한다.

단일 단계 증명

단일 단계 증명은 Arbitrum의 사기 증명의 핵심이다. 이제 단일 단계 증명이 구체적으로 무엇을 증명하는지 살펴보자.

이를 이해하려면 먼저 WAVM을 알아야 한다. Wasm Arbitrum Virtual Machine은 ArbOS 모듈과 Geth(이더리움 클라이언트) 코어 모듈이 함께 컴파일된 가상 머신이다. L2와 L1은 많은 차이점이 있으므로 원래의 Geth 코어는 경량 수정을 거쳐야 하며 ArbOS와 함께 작동해야 한다.

따라서 L2의 상태 전환은 사실 ArbOS+Geth Core가 공동으로 수행한 것이다.