Optimism Opstack의 Bedrock 버전 아키텍쳐 살펴보기

요즘 다양한 Layer2 SDK가 출시되고 있지만, Optimism가 가장 많이 사용되는 것같다. 코인베이스의 BASE부터 샘알트만의 Worldcoin, BNB의 L2인 opBNB까지.. 이미 Optimistic 롤업의 표준인 만큼 롤업에 관심있는 사람들이라면 Opstack의 아키텍처를 살펴보는 것은 중요하다.

(Four Pillars 미디움 글을 참고했으며, 더 이해하기 쉽게 내용을 재구성했습니다. 틀린 부분이 있다면 지적해주시길 바랍니다.)

Opstack Architecture

four plillars 자료

Opstack 아키텍처는 위와 같이 4가지의 요소로 나뉜다. op-node, op-geth는 Layer2에서 노드의 역할을, op-batcher, op-proposer는 Layer1에 데이터를 전송하는 시퀀서 노드 역할을 수행한다.

op-node

이더리움 API를 통해 이더리움의 원시 데이터를 받아, Layer2의 op-geth가 실행을 위해 변환하여 op-geth에 전달한다. op-node는 이더리움 Layer 1의 블록데이터와 시퀀서 트랜잭션 배치, Deposit되는 트랜잭션 이벤트 데이터를 입력받는다. 

op-node에 의해서 가공된 데이터는 L1 → L2 입출금 트랜잭션, 실패 트랜잭션의 retry, L2 트랜잭션의 상태 업데이트, 최신 Tip에 기반한 Layer1 가스 가격 계산이 있다.

op-geth

트랜잭션 프로세스에서 실행과 처리를 담당하며, user의 트랜잭션을 전달받아 네트워크 상의 트랜잭션 처리를 보장한다. 처리한 트랜잭션에 의해서 L2의 새 상태를 op-geth가 생성한다.

op-batcher

이더리움 L2에서 발생한 트랜잭션들을 압축하여 이더리움 L1에 전송하는 역할을 담당한다.

op-proposer

상태전환을 마무리하는 역할을 한다. op-geth가 상태를 수정하면, op-proposer는 상태에 대한 커밋을 L1에 작성하여 수정한 상태를 L1에 전송한다. 여기서 머클루트를 활용하여 L1에 전송되는 데이터 사이즈를 최소화시켜 비용을 절감한다.

여기서 상태루트는 L1에 배포된 컨트랙트인 L2OutputOracle에 저장된다. 이 루트의 제안은 승인을 얻기 전에 7일 간의 결함 이의 제기 기간을 거쳐야만 한다.

---

Transaction Flow

롤업 트랜잭션 플로우를 확인하면 아키텍처의 프로세스에 대해서 더욱 이해하기 쉽다.

https://community.optimism.io/docs/protocol/txn-flow/#

옵티미스틱 롤업의 프로세스는 두가지 요구 조건이 잇다. 

1) L1에서 기록된 트랜잭션이어야 한다.

일반적으로 op-batcher가 L1에 트랜잭션을 기록하지만, 유저가 op-batcher를 건너뛰고 직접 L1에 L2 트랜잭션 전송도 가능하다.

2) 트랜잭션은 op-geth에 의해서 실행되어야 하고, 실행된 상태에 대한 커밋을 op-proposer가 L1에 기록한다. 

1 - Compression

L2에서 발생한 트랜잭션을 압축하여 Batch로 만들어 L1에 전송하는 역할은 op-batcher가 담당한다. 여기서 L2의 batch에 포함될 트랜잭션을 결정하는 채널의 최대 시간은 L1의 블록 시간 단위로 지정된다.

Batch 사이즈와 post 시간 간격은 rollup 네트워크의 비용과 tx 처리에 있어 많은 영향을 받는다. 채널과 batch에 관련된 변수들은 다음과 같다. 

• OP_BATCHER_MAX_CHANNEL_DURATION : L2 트랜잭션을 batch로 묶는 최대 시간 간격이다. 위에서 언급한 것과 같이 최대 시간은 L1 블록 시간 단위로 결정한다. 만약 이 값을 0으로 한다면 batch 사이즈가 커지고 비용이 많이 들 수 있다.
• OP_BATCHER_TARGET_L1_TX_SIZE_BYTES : Batch가 전송되는 L1 트랜잭션 사이즈를 의미한다.
• OP_BATCHER_APPROX_COMPR_RATIO : 예상 압축 비율로, decimal 값으로 정의된다. 

2 - Posting to L1

L1으로 전송될 채널이 가득 차게되면 L2 트랜잭션들은 op-batcher에 의해서 위와 같은 압축을 거쳐 단일 트랜잭션 혹은 여러 트랜잭션으로 L1에 전송된다. (op-batcher의 publishStateToL1 메소드를 통해 수행) 여기서 처리되는 L2 트랜잭션은 3가지 상태를 가진다.

• unsafe : 트랜잭션은 이미 처리되었지만 L1에 기록되지 않은 상태다. 이는 op-batcher가 트랜잭션을 L1에 기록하지 않아서 발생한 상태다.
• safe : 트랜잭션이 처리되고 이미 L1에도 기록이 된 상태다. 그러나 L1에서 reorganization에 의해 드랍될 수 도 있다.
• finalized : 트랜잭션이 처리됨과 동시에 L1에도 기록되었으며 충분한 시간이 흘러 finalized도 된상태다. 이 트랜잭션은 L1에 영원히 기록된다.

3 - State processing

상태처리는 두 단계로 진행된다.

1)  op-geth가 기존 상태에서 트랜잭션을 처리하여 새 상태를 생성한다. 

2)  op-proposer가 새 상태의 머클루트를 L1에 기록한다.

4 - State changes

op-geth에 의해서 상태가 저장되고 수정된다. state root proposal은 op-proposer에 의해서 L1의 L2OutputOracle에 전송된다. 그러나 fault 챌린지 기간인 7일이 초과해야만 최종적으로 기록된다.

---

주요 스마트 컨트랙트

1. L1에 배포되는 Contracts

[OptimismPortal]

L1과 L2간의 통신을 담당하는 컨트랙트로 옵티미즘 시스템 내에서 크로스 체인 메시징을 위한 기본 게이트 역할을 담당한다. 주요 기능으로는 다음과 같다.

1. L2에서 실행될 L1 트랜잭션을 예치하여 L2의 실행을 보장
2. L2 인출을 확인하고 L1에서 자금을 인출.
3. 가디언(입출금을 일시 중지할 수 있는 주소)에서 관리하는 크로스 체인 메시징을 일시 중지
4. 컨펌된 출금과 L2 전송자를 추적하여 출금 완료 용이

L2의 상태를 기록하는 컨트랙트인 L2OutputOracle과 SystemConfig 컨트랙트는 OptimismPortal과 상호작용을 한다. L2OutputOracle은 L2 상태의 유효성을 검사하는데 도움을 주고, SystemConfig는 시스탬 매개 변수를 설정하는데 활용한다.

[L2OutputOracle]

op-proposer가 제출한 L2의 상태 루트를 보관하는 컨트랙트다. 이 컨트랙트를 통해 다른 L1 컨트랙트는 L2 상태와 관련된 정보를 인증할 수 있다.

op-proposer는 제출 간격에 따라서 새 L2 상태를 제출가능하며, 챌린저를 통해서 유효하지 않은 L2 상태를 제거할 수 있다. 또한, 다른 컨트랙트가 L2 상태를 확인하여 정보를 검증할 수 있도록 허용되어 있다.

L2OutputOracle은 L1 컨트랙트에서 L2 체인 상태에 대한 정보를 제공하는 역할을 하여 L2 트랜잭션들을 이용하여 상태가 유효한지 검증이 가능하다.

2. L2에 배포되는 Contracts

[L1Block]

가장 최근에 생성된 L1 블록에 대한 정보를 보관하는 컨트랙트다. 이 컨트랙트는 L2 컨트랙트에게 최신 L1 블록 정보를 제공한다.

이 데이터를 L2에 보관하여 L2 컨트랙트는 크로스 체인 호출이 없어도 L1에 대한 정보를 확인할 수 있다. 이 정보를 사용하는 목적은 다음과 같다.

• L2 트랜잭션에 대한 L1 가스 가격을 계산
• 시퀀서가 제출한 L1 블록 데이터를 검증
• L2 컨트랙트가 특정 L1 트랜잭션이 성공적으로 채굴되었는지 확인

시퀀서는 새 L1 블록이 finalized 상태가 되면 컨트랙트의 값을 새로 고치는 deposit 주소를 관리한다.

참고자료 : https://medium.com/fourpillars/op-stack-블록체인을-구축하기-위한-가장-간편한-프레임워크-5e86cc18768a

OP-Stack: 블록체인을 구축하기 위한 가장 간편한 프레임워크