Road to Web3 (14) L2 롤업 구조: 시퀀서, 소프트 확정 vs L1 하드 확정

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

 

 

Base 같은 롤업 환경에서 확정이 2층인 이유를 운영 감각으로 이해하는 게 목표입니다.

핵심 한 줄

• L2는 빠른 체감 확정을 주고, L1은 최종 정산 확정을 준다

 

제가 처음 접했던 L2의 인상은 이랬습니다.

• L2는 그냥 수수료가 싼 이더리움이다
• 블록에 들어갔으면 끝이다
• L2도 결국 이더리움이니 확정은 하나일 것이다

하지만 롤업은 구조적으로 확정이 2층입니다.

• L2 내부에서 먼저 포함과 체감 확정이 생기고
• 그 결과가 L1에 게시되어 정산 확정이 생긴다

이 차이를 이해 못 하면 제품 정책이 흔들립니다.

• 결제 완료를 언제로 볼지
• 출금이 왜 늦는지
• 장애가 났을 때 어디까지 신뢰할지

---

 

요약

질문	L2에서의 답	L1에서의 답
누가 순서를 정하나	시퀀서 sequencer	밸리데이터 합의
포함 included은 무엇인가	L2 블록에 포함	L1 블록에 배치 게시 포함
확정 finality은 무엇인가	소프트 확정 체감 확정	하드 확정 정산 확정
실패 모델	시퀀서 장애 지연, 재정렬 가능	reorg 확률 낮지만 존재
내 서비스가 믿어야 할 것	L2 included는 UX, 결제 승인에 가깝다	L1 게시 이후는 정산에 가깝다

---

 

1) 롤업이 뭔가: L1을 DB로, L2를 캐시로 보면 반은 맞다

롤업은 거래를 L2에서 실행하고, 결과를 L1에 게시하여 보안을 빌리는 구조입니다.

• 실행 execution은 L2가 담당
• 데이터 게시 data availability 또는 증명 proof는 L1이 담당

web2 비유로 보면

• L2는 빠른 실행 레이어
• L1은 전 세계가 합의하는 정산 장부

정확히는 캐시라기보다

• 전용 실행 엔진 + 주기적 커밋 로그 업로드

에 가깝습니다.

---

 

2) 시퀀서는 무엇을 하나: 빠른 순서 결정자

L2 사용자가 체감하는 속도는 대부분 시퀀서가 만듭니다.

시퀀서 역할

• 사용자 트랜잭션을 받는다
• L2 블록을 만들며 순서를 정한다
• 빠르게 포함 결과를 돌려준다

하지만 중요한 점

• 시퀀서의 포함은 L1 합의가 아니다
• 그러므로 이것은 소프트 확정에 가깝다

web2로 비유하면

• 결제 승인 응답
• 주문 접수 ACK

같은 느낌입니다.

---

 

3) 소프트 확정 vs 하드 확정: 승인과 정산의 2단계

롤업에서 확정은 2번 일어납니다.

3.1 소프트 확정 soft finality

• L2 시퀀서가 포함해 주었다
• 대부분의 경우 되돌아가지 않는다
• 하지만 시퀀서 장애, 재정렬, 롤업 내부 정책에 따라 흔들릴 여지가 있다

3.2 하드 확정 hard finality

• L2의 결과가 L1에 게시되었다
• L1에서 충분한 확정 깊이를 쌓았다
• 이제 사실상 정산이 끝난 상태다

web2에 매핑하면

• L2 소프트 확정은 승인
• L1 하드 확정은 정산

---

 

4) 트랜잭션은 어디에 기록되는가

대개는 이렇게 기록됩니다.

• 사용자가 서명한 트랜잭션은 L2 체인에 기록된다
• L1에는 L2 배치 데이터 또는 증명이 게시된다

즉 L1에 올라가는 것은

• L2 거래들을 한꺼번에 묶은 게시물

에 가깝습니다.

---

 

5) 제품 정책 가이드: 승인과 정산을 분리하자

레이어	상태	제품적 의미
L2	included	UX상 성공으로 보여줄 수 있다
L2	confirmed k	빠른 서비스 제공 기준으로 쓸 수 있다
L1	posted	정산 파이프라인에 태우는 기준
L1	finalized	최종 성공, 회계 확정 기준

---

 

결론

• Base 같은 롤업은 확정이 2층이다
• L2는 빠른 UX를, L1은 강한 최종성을 제공한다
• 제품 설계는 승인과 정산의 2단계를 전제로 해야 안정적이다