목차

  1. OP Stack 개요
  2. OP Stack 구성 요소
  3. Governance
  4. 슈퍼체인에 체인을 만드는것과 그냥 체인을 만드는것의 차이

1. OP Stack 개요

op-stack

Optimism 을 이야기 할 때 꼭 OP Stack 을 이야기한다. OP Stack 을 설치한 노드를 여러개 켜서 만든 체인이 Optimism 이다. 반대로 말하여 OP Stack 의 genesis 블록 파일만 바꾸면 다른 체인으로 동작시킬 수 있다. 사실 이는 새롭지 않다. geth 로 새로운 체인을 만드는것과 같다.

OP Stack 을 개발하는 철학이 있다고 한다. 단순하게, 실용적이게(개발자 편의), 지속 가능하게, 낙관주의 라고한다. 어떻게 하면 서버가 아프지 않을 수 있을까 를 고민하는 백엔드 개발자같아서 연민이 느껴졌다..

정리: OP Stack 은 L2 체인을 만드는 도구라고 볼 수 있다.

2. OP Stack 구성 요소

OP Stack 은 여러 레이어로 나누어 구성하는것을 원칙으로 한다. 서버 개발할 때 컨트롤러와 서비스 등 을 나누고 그 사이를 DTO, VO 로 연결하는것과 비슷한 맥락이다. 언제든 새로 개발하여 교체할 수 있고, 인터페이스를 신뢰하며, 별도로 테스트를 가능케 한다.

2.1 Data Avaliability

DataAvailability(DA)는 데이터를 보장하는 레이어다. 이더리움 DA 모듈을 사용할 수 있으며, 이 모듈은 더 확장될 수 있다.

DA 를 Polygon 이나 ZkEra같은 L2로 설정하면 L3 체인을 만들 수 있겠다는 생각

2.2 Sequencing Layer

sequencing

Sequencing Layer(시퀀싱)은 거래 처리 및 기록의 책임을 가진다. 시퀀싱은 L2 에서 트랜잭션이 어떻게 수집되어 DA에 게시되는지 결정한다.

사용자들의 트랜잭션을 수집, 정렬, L1 에 기록한다.

OP Stack 은 일반적으로 단일 시퀀서로 구성된다. 단순함과 실용주의 철학에 기반했기 때문이다.

  • 분산된 시퀀서보다 단일 시퀀서가 네트워크 구축이 쉽다.
  • 코드가 단순할수록 버그가 줄어든다는 철학 아래에 코드가 단순한 단일 시퀀서를 사용한다.
  • 단일 시퀀서는 영구적이지 않다. 실제 환경에서의 피드백을 통해 개선해 나가기 위해 체인을 올리는것이 중요했으며, 단일 시퀀서가 더 실용적이라고 판단했다.
  • 결국 OP Stack 은 탈중앙화를 목표로 하기 때문에 분산시퀀서로 갈 것이다.
  • 사용자는 L1에 직접 트랜젝션을 제출해서 시퀀서를 우회할 수 있다. 사용자가 시퀀서에 전적으로 의존하지 않아 유연함을 가진다고 해석할 수 있다.

2.2.1 Single Sequencer

OP Stack 에서 사용하는 기본 시퀀서인 Single Sequencer(단일 시퀀서)는 네트워크 전체에 단 하나의 지정된 주체만이 시퀀서 역할을 수행할 수 있다.

이 단일 시퀀서가 누가 될지는 거버넌스 메커니즘에 의해 결정된다. 예를 들어 DAO 투표나 특정 팀의 결정에 의해 “지금부터가 A가 시퀀서다” 라고 정한다.

쉬운 비유

  • 반 학생들이 여러 발표내용을 내면
  • 선생님이 지정한 반장 이 그 내용을 모아서, 순서대로 쌓고, 요약한다
  • 반장은 학교 게시판에 요약한 내용을 게시한다

2.2.2 Multiple Sequencer

단일 시퀀서의 중앙화 문제를 완화하기 위한 방식이다. 미리 정해진 시퀀서 후보 그룹 안에서 특정 시점에 활동할 시퀀서를 선택하는 방식이다.

이 모델의 핵심은 두가지 메커니즘을 각 체인이 자율적으로 결정할 수 있다는 점이다.

  1. 후보 그룹을 정의하는 방식: 어떤 기준으로 시퀀서 후보가 될 수 있는지를 정한다. 예) 일정량 이상의 토큰을 스테이킹한 노드, 투표로 선출된 노드 등
  2. 후보중에 시퀀서를 선택하는 방식: 후보 그룹 안에서 현재 블록을 생성할 시퀀서 노드를 어떻게 뽑을지 정한다 예) 라운드 로빈, 무작위 추첨 등

2.3 Derivation

Derivation Layer (파생 레이어) 는 L1(DA)에 있는 원시 데이터를 처리, 이더리움 API를 통해 Execution Layer 로 전달되는 ‘처리된 입력값’을 만드는 방식을 정의한다.

실행 계층에서 정의된 현재 시스템 상태를 활용하여 파싱된 원시 데이터 입력을 얻을 수 있다. 파생 레이어는 원시 입력 데이터의 파싱 방법을 알아야 하기 때문에 L1(DA)와 밀접하다고 볼 수 있다.

이는 도큐먼트에 써있는 내용인데, 내가 해석한 내용은 아래와 같다.

시퀀서 내용 중 L1에 직접 상태 쓰기가 가능하다고 하였다. 그럼 L1의 상태를 L2에 반영하는, 즉 시퀀서와는 반대되는 행위를 하는 무언가가 필요하다. 그게 파생 레이어에서 하는 일이다. (이게 없다면 네트워크의 무결성이 깨질것이다)

파생 레이어는 시퀀서에 장애가 발생한 경우 네트워크를 유지시키기 위한 작업을 하기도 한다. 시퀀서가 L2 트랜젝션을 L1에 게시해야하는 제한 시간으로 Sequencer Window 라는 개념이 존재한다. Optimism 의 경우 12시간으로 정해져있다. 만약 시퀀서가 12시간 내에 응답하지 않으면 추상 레이어는 복구 모드에 들어간다. 이 기간 동안 생성된 Unsafe 블록들은 폐기되고, 대신 L1에 직접 제출된 예금 트렌젝션만을 포함하는 새로운 L2 블록을 생성하여 체인을 이어나간다.

이 메커니즘으로 하여금 시퀀서의 독점적인 역할에 의존하지 않고 사용자들이 강제로 트랜젝션을 포함할 수 있게 하여 네트워크 복원력을 보장한다.

2.4 Execution

Execution Layer (실행 레이어)는 상태 구조와 상태를 변화시키는 상태 전의 함수를 정의한다. 라는 말을 하지만 간단하게는 약간 변형된 EVM을 말한다

실행 레이어의 추상화는 EVM의 수정이나 다른 가상 머신을 사용하는 가능성을 열어준다. WASM 기대해보겠다..

2.5 Sattlement

Sattlement(정산 레이어)는 외부 체인에서 OP Stack 체인의 상태를 확립하기 위한 메커니즘이다. Sattlement 레이어는 단순히 제3의 체인이 OpStack 체인의 상태를 신뢰할 수 있도록 하는것이 목적이다.

정산 이라 말하는 이유는 이 메커니즘이 주로 ETH 와 같은 토큰들을 출금하는 과정에 사용되기 때문이다.

트랜잭션은 L1 에 게시되고, finalize 되면 그 트랜젝션은 OP Stack 체인에서도 최종 확정이다.

2.5.1 Attestation-based fault proof

Attestation-based fault proof (인증 기반 오류 증명)은 L2에 발생한 거래내역을 L1에 제출할 때 일단 그 내용이 올바르다고 가정한다.

하지만 누군가 L1에 거짓된 정보를 제출할 수 있고, 결함 증명은 누구나 반박하고 증명할 수 있는 시스템을 만드는것이다.

Proposer(제안자)는 자신이 현재 유효하다고 믿는 L2 체인의 상태를 제안한다. 이 제안이 일정 기간 (도전 기간, Challenge period) 내에 무효화 되지 않는다면 제안이 올바른것으로 처리된다.

미리 정의된 당사자들 중 일정 기준에 도달하는 수가 제안된 상태와 다른 상태에 대한 인증을 제공하면 해당 제안은 무효화 될 수 있다.

이는 사전에 정의된 참가자들 중 최소 기준 수 만큼은 정직할 것이라는 신뢰 가정에 의존하는것이다.

  1. 주장 제출 (출금 요청): 개새끼가 L2 자산을 L1으로 출금한다. “L2에서 10이더를 소각했으니 L1에 10 이더를 달라” 라는 주장을 L1(DA)에 제출한다
  2. 챌린저의 등장: 엄근진 이 L2 체인을 보다가 개새끼의 주장이 거짓된것임을 발견한다 (실제로 1이더만 소각함). 엄근진은 이 주장에 이이를 제기하여 챌린저가 된다.
  3. 신뢰할 수 있는 증인들(Chain Attestors)에게 확인 요청: 엄근진은 미리 정해져있는 신뢰할 수 있는 증인 그룹에게 가서 개새끼의 행위를 꼰지른다. 이때 증인들은 L2의 상태를 모두 알고있다.
  4. 증명(Attestation) 수집: 증인 그룹 중 다수가 “개새끼가 구라친게 맞다” 라고 동의하며 서명해준다.
  5. 증명서 제출: 엄근진은 이 서명들을 모아 증명 증거(Attestation Proof) 라는 하나의 문서를 만들어 L1에 제출한다. L1 컨트렉트는 이 증명서를 보고 개새끼의 거짓 주장을 무효로 처리한다.

이 방식은 가용성보다 안전성에 집중한 결과다. 만약 증인 그룹이 악의적으로 행동하더라도, 그들이 할 수 있는 최악의 행동은 시스템을 일시적으로 멈추게 하는 것 뿐이다. 사용자의 자금을 춤지는것은 불가능하다. 이는 복잡하고 새로운 기술인 결함 증명 시스템에 버그가 있을 가능성에 대비한 안전장치다.

Optimism은 이 방식이 탈중앙화 되지 않았기 때문에 영구적인 해결책이라고 생각하지 않는다. 증명을 탈중앙화 하기 위해 Cannon 이라는 것이 등장하는데, 이는 증인 그룹 없이 L1 온체인에서 분쟁 게임 (dispute game)을 통해 잘못 계산된 악의적으로 변경된 명령어를 찾아 검증한다.

2.5.2 Fault Proof Optimistic Settlement

Fault Proof Optimistic Settlement (오류 증명 기반 낙관적 정산)은 열심히 개발중인 매커니즘이다.

오류 증명 기반 낙관적 정산 매커니즘은 MultiSig 챌린저를 Permissionless 오류 증명 과정으로 대체하는것이 목적이다.

이 방식은 오류 증명 자체가 올바르게 만들어져서 버그가 전혀 없다는 신뢰 가정에 의존한다.

L2의 상태가 L1에 제출되면 정해진 챌린지 기간(예, 7일)동안 누구나 이의를 제기할 수 있다. 만약 기간 내에 이의를 제기한다면 ‘결함 증명 (Fault Proof)’ 또는 ‘분쟁 게임(Dispute Game)‘과 같은 절차가 시작되어 해당 주장의 유효성을 검증한다. 이 과정은 누구나 참여할 수 있기 때문에 무허가(Permissionless) 라고 한다.

2.5.3 Validity Proof Settlement

Validity Proof Settlement (유효성 증명 정산)은 수학적 증명을 통해 상태의 올바름을 보증하는 매커니즘이다.

주로 ZK(영지식)을 사용하며, L2의 상태 전환이 유효하다는것을 사전에 증명하는 방식이다.

결함 증명과 달리 챌린지 기간이 없어 즉시 출금 (L2 -> L1)이 가능하다.

하지만 영지식 증명은 현재로써 비용이 많이 들고 (GPU 연산이 필요할 수 있음), 버그 가능성이 있어 상용화되기까지는 시간이 더 필요하다.

OP Stack 의 모듈식 설계에서 향후 유효성 증명을 통합할 수 있는 기반을 마련중이라고 한다.

구분 증명 기반 결함 증명 결함 증명 낙관적 정산 유효성 증명 정산
핵심 원리 증명자 그룹이 분쟁 해결 일단 믿고, 틀리면 이의 제기 모든 거래를 사전에 증명
챌린지 기간 필요 (결함 증명 시스템의 일부) 필수 (약 7일) 필요 없음
출금 속도 느림 (챌린지 기간) 느림 (챌린지 기간) 즉시 가능
보안 가정 지정된 증명자들이 정직하게 행동한다 최소 한 명의 정직한 검증자가 존재할 것 암호학적 증명의 유효성
현재 상태 초기 단계의 대안으로 고려 OP 스택의 현재 표준 방식 미래에 도입될 가능성이 있는 기술

3. Governance

시스템의 config, upgrade 방법, 설계 결정 등 을 관리하기 위해 사용되는 도구와 프로세스의 집합을 Governance(거버넌스)라고 한다.

3.1 MultiSig Contracts

멀티시크 컨트렉트는 미리 정의된 참가자 집합으로부터 임계값의 서명을 받으면 동작하는 컨트렉트다.

보통 OP Stack 의 시스템 업그레이드에 사용된다. Optimism Mainnet 에서는 브릿지 컨트렉트 업그레이드에 사용중이다.

3.2 Governance Tokens

거버넌스 토큰은 의사 결정을 분산화하기 위해 사용된다.

가장 흔한 방식으로는 프로젝트가 내려야하는 결정에 대해 투표권을 가지도록 한다.

4. 슈퍼체인에 체인을 만드는것과 그냥 체인을 만드는것의 차이

superchain

OP Stack 을 사용하여 체인을 만들 때 가장 크게 나눌 수 있는 분기는 ‘슈퍼체인의 사용 여부’ 라고 할 수 있다.

슈퍼체인은 OP 메인넷과 다른 체인들을 ‘OP 체인’ 이라는 단일 네트워크로 통합하는것이다. OP 체인은 슈퍼체인 내 개별 체인을 의미하며, OP Stack 을 기반으로 구축된 네트워크다. 여러 체인이 브리징, 분산 거버넌스, 업그레이드, 통신 계층 프로토콜 등 을 공유하게 된다.

슈퍼체인을 사용하여 체인을 만드는 경우 브리지와 보안 모델을 공유받아 이미 검증되고 실시간으로 업데이트받아 안전하다고 볼 수 있다. 옵티미즘의 거버넌스를 통해 업그레이드가 관리되어 일관적이며 관리가 편하다. 또 체인간 메시지, 자산 이동이 같은 프로토콜을 사용하기 때문에 더 쉽고 원활하다.

슈퍼체인을 사용하지 않고 독립적인 OP Stack 체인을 구성한다면 체인의 업그레이드, 보안, 거버넌스를 모두 직접 책임져야한다. 이는 반대로 말해 커스터마이징이 가능하다는 말과도 같다. 다만 커스터마이징을 하게되면 OP 체인들과 호환성이 떨어져 메시지, 자산 이동에 어려움이 발생할 수 있다.