– 왜 롤업(L2) 수수료를 싸게 만드는지, 진짜 쉽게 풀어쓴 설명
1. 블롭은 한 줄로 뭐냐?
블롭(blob) 은 이더리움이 레이어2(L2)들을 위해 따로 만들어준 ‘임시 데이터 저장 공간’입니다.
- 원래 L2는 자기 트랜잭션 데이터를 calldata로 L1(이더리움 메인넷)에 올렸음 → 영구 저장 + 비쌈
- Dencun 업그레이드(EIP-4844, proto-danksharding)에서
“블롭(blob)”이라는 새로운 데이터 영역이 추가됨 - 블롭은 크고 싸고, 대신 일정 기간(약 18일)만 보관되는 데이터 공간입니다.
쉽게 말하면,
원래는 롤업 데이터도 “영구 창고”에 보관해서 비쌌는데,
이제는 “18일짜리 임시 창고(블롭 창고)”에 넣고 크게 싸게 쓰는 구조
라고 이해하면 됩니다.
2. 왜 굳이 블롭이 필요했을까?
2-1. 이전 구조의 문제: calldata 지옥
L2 롤업(아비트럼, 옵티미즘, 베이스, zkSync 등)은
- 유저들의 트랜잭션을 모아서
- 증명(proof) 과 함께 이더리움 메인넷에 올립니다.
여기서 “데이터를 어디에, 어떻게 올리느냐”가 비용의 핵심인데,
Dencun 이전에는 대부분 calldata에 올렸습니다.
문제는:
- calldata는 영구 저장
- 이 데이터도 풀노드가 영원히 들고 있어야 함
- 그래서 가격(가스비)이 비쌀 수밖에 없음
실제로 롤업 비용의 90% 이상이 calldata 비용이라는 분석도 있었어요.
→ L2 수수료가 많이 싸졌다 해도,
여전히 “L1에 올리는 데이터 비용”이 발목을 잡고 있던 상황이었죠.
2-2. “영원히 안 남겨도 되는 데이터”라는 통찰
여기서 나온 질문이 하나 있습니다.
“롤업 데이터, 진짜 영원히 L1에 남아야 할까?
아니면 검증에 필요한 기간 동안만 제대로 존재하면 될까?”
롤업이 필요로 하는 건,
- “우리가 이런 트랜잭션들을 처리했고,
누구든 이 데이터를 보고 검증할 수 있다”는 사실이지, - 10년 뒤까지 이 데이터를 L1이 직접 들고 있어야 할 필요는 없습니다.
그래서 나온 해법이 “단기 데이터 가용성(DA) 전용 저장소”,
그게 바로 블롭(blob) 입니다.
3. 블롭의 정체: 기술적으로는 이렇게 생겼다
3-1. 블롭 = 큰 데이터 덩어리 + 별도 트랜잭션 타입
EIP-4844는 이더리움에 새로운 트랜잭션 타입(type-3) 을 추가합니다.
이 타입은 평범한 트랜잭션에 “블롭이라는 데이터 덩어리”를 달아서 보내는 것이에요.
블롭의 기본 스펙은 대략 이렇습니다.
- 한 블롭 크기: 최대 약 128KB
- 한 블록당 목표 블롭 수: 3개 (상황에 따라 더 들어갈 수 있음)
- 저장 위치: 실행 레이어(EVM)가 아니라, 컨센서스 레이어(비콘체인) 에 저장
3-2. 18일만 보관되는 이유
블롭 데이터는 4096 epoch ≒ 약 18일 동안만
컨센서스 레이어 노드들이 들고 있다가, 그 이후에는 지울 수 있습니다.
이 18일은:
- 롤업이
- 상태를 동기화하고
- 증명을 만들고
- 문제가 있을 경우 이의제기까지 할 수 있는
충분한 기간으로 설계된 숫자입니다.
그 이후에는 데이터 전체가 아니라, 그 데이터에 대한 약속(커밋먼트) 만 L1에 남습니다.
3-3. EVM은 블롭을 “직접 읽을 수 없다”
여기서 중요한 포인트 하나:
이더리움 스마트컨트랙트(EVM)는
블롭 데이터 자체를 직접 읽지 못합니다.
대신,
- 블롭에 대한 KZG 커밋먼트가 블록에 포함되고
- 이 커밋먼트를 통해
“이 데이터가 진짜로 그 때 제출된 그대로다”
라는 것을 암호학적으로 증명합니다.
그래서 블롭은
- “EVM이 직접 사용하는 데이터”가 아니라,
- “L2가 자기 일을 하기 위해 L1에 맡겨두는 데이터”
라고 보는 게 정확해요.
4. 블롭 vs calldata: 뭐가 어떻게 다른가?
비교 표 형식으로 한 번 정리해 볼게요.
| 구분 | calldata | blob |
|---|---|---|
| 저장 위치 | 실행 레이어(EVM 상태와 함께) | 컨센서스 레이어(비콘체인) |
| 저장 기간 | 사실상 영구 | 약 18일 후 삭제 가능 |
| 스마트컨트랙트에서 직접 읽기 | 가능 | 불가능 (커밋먼트만 사용) |
| 비용 구조 | 일반 가스 (비쌈) | 블롭 가스라는 별도 시장 (훨씬 저렴) |
| 쓰임새 | 일반 트랜잭션, 컨트랙트 로직 | L2 롤업 데이터, 단기 DA용 등 |
핵심 요약:
- calldata:
“영구 보관 + 직접 사용해야 하는 중요한 데이터” - blob:
“잠깐만 보관하면 되는, 롤업용 ‘영수증 묶음’”
5. 블롭이 L2 수수료를 어떻게 낮추는가?
5-1. “영구 창고 → 임시 창고”로 옮겼기 때문에
Dencun 이후, 많은 롤업이
“이제 calldata 대신 blob을 메인으로 쓰자”
라는 전략으로 이동했습니다.
그 결과:
- L2가 L1에 올리는 데이터의 단가가 크게 떨어지고
- 이 비용 절감이 L2 사용자 수수료 인하로 바로 이어졌습니다.
예를 들어, 한 분석에서는
- Dencun 이후 몇 달 사이에
평균 가스 가격이 150 gwei 수준 → 1 gwei 수준까지 떨어진 시기도 있었다고 합니다.
물론 시장 상황·수요에 따라 오르내리지만,
“블롭 덕분에 L2가 구조적으로 싸졌다”는 점은 부인하기 어렵습니다.
5-2. 블롭 가스 시장: EIP-1559의 동생
블롭에는 별도의 가스 시장이 있습니다.
- 일반 트랜잭션 가스와는 독립된 “blob gas”를 사용
- 여기에도 EIP-1559 스타일의 base fee + priority fee 구조 적용
- 목표 블롭 수(예: 3개/블록)보다 많이 쓰이면
→ blob base fee ↑
적게 쓰이면
→ blob base fee ↓
이 구조 덕분에,
- L1의 일반 가스 폭등과는 조금 분리된 시장이 생겼고,
- L2들이 상대적으로 안정적인 비용으로 데이터를 올릴 수 있는 환경이 마련됐습니다.
6. 유저 입장에서 “블롭”은 어떻게 체감되나?
솔직히 말해, 일반 유저는 지갑 화면에서
“이 트랜잭션은 블롭을 썼습니다” 같은 걸 크게 신경 쓸 필요 없습니다.
대신 이렇게 체감됩니다.
- 아비트럼·옵티미즘·베이스 등 L2 수수료가 눈에 띄게 싸짐
- 브리지 수수료, 스왑 수수료 등이
“이 정도면 그냥 써볼 만한 수준”으로 내려감 - NFT 민팅·온체인 게임·소액 실험 같은 것들이
“몇 천 원씩 깨지는 일이 덜해짐”
정리하면:
사용자는 “블롭”이라는 단어를 몰라도 되지만,
“L2가 싸지고 빨라진 이유” 뒤에는 항상 블롭이 있다
정도만 이해하면 충분합니다.
7. 블롭은 어디까지이고, 그 다음은 무엇인가?
블롭은 여기서 끝이 아니라, 다음 스텝으로 가기 위한 징검다리입니다.
- EIP-4844 = Proto-Danksharding(프토-당크샤딩)
→ “완전한 샤딩으로 가기 전, 블롭을 먼저 도입하는 중간 단계” - 앞으로는
- 블롭 개수 확대
- PeerDAS(데이터 가용성 샘플링) 도입
등으로, L2가 올릴 수 있는 데이터 규모가 훨씬 더 커질 예정입니다.
이전에 봤던 푸사카 업그레이드가 바로 이 다음 단계죠.
블롭으로 시작된 이 “데이터 확장”이
→ PeerDAS, Verkle Tree, 더 많은 블롭 타깃으로 이어지면서
이더리움 전체 처리량을 몇 배로 키우는 그림입니다.
8. 자주 나오는 오해 Q&A
Q1. “블롭은 18일 후 삭제된다는데, 그럼 내 자산 정보도 사라지는 거 아냐?”
아니요.
- 자산·잔고·스마트컨트랙트 상태는
여전히 각 체인의 상태(state) 로 관리됩니다. - 블롭은 “그때 이런 트랜잭션들이 있었다”는 데이터 묶음이지,
자산 그 자체가 아닙니다.
18일이 지나 블롭이 지워져도,
- 이미 롤업은 그 데이터를 기반으로
상태를 업데이트했고, - 그 상태는 롤업 체인·브리지·증명 시스템에서
계속 유지됩니다.
Q2. “블롭이 생기면 메인넷(L1) 수수료도 같이 싸지나요?”
직접적으로는 아닙니다.
- 블롭은 L2 데이터 비용을 줄이는 것에 초점이 맞춰져 있고,
- 이더리움 L1에서 그냥 토큰 전송·스왑하는 가스비는
여전히 L1 수요·공급에 의해 결정됩니다.
다만, 더 많은 활동이 L2로 이동하면
장기적으로 L1 혼잡이 줄어
간접적인 완화 효과는 기대할 수 있죠.
9. 마무리: 블롭을 한 문장으로 정리하면
“블롭은 이더리움이 롤업에게 내준
싸고 큰 18일짜리 임시 창고”입니다.
이 한 줄만 기억해도 충분합니다.
- L2는 더 싸고 빠르게 움직일 수 있고,
- 이더리움은 디스크·대역폭 부담을 통제하면서
스케일링 로드맵을 한 단계 더 진전시켰습니다.
About the Author
