_{이미지 출처: 영화 <추격자>}

목차

1. 들어가며

2. 이더리움 샤딩의 역사와 변화 과정

2-1. 초기 이더리움의 샤딩 계획: Hypercubes, Hub and Spoke Chains, Super Quadratic Sharding, Quadratic Sharding

2-2. 간소화와 실용주의의 추구: Full Execution Sharding → Data Sharding

3. 댕크샤딩(Danksharding)

3-1. 댕크샤딩은 데이터 샤딩을 위한 신규 블록체인 아키텍쳐

3-2. 중앙화 현상을 최소화하기 위해 PBS(Proposer Builder Separation)와 CrList를 활용할 예정

3-3. 그 외에도 체인의 확장성과 신뢰를 확보하기 위해 DAS, Erasure coding, KZG commitment 등을 도입할 것

4. EIP4844, 프로토-댕크샤딩(Proto-danksharding)

4-1. EIP4844는 댕크샤딩의 초석

4-2. 단순히 콜데이터 사용료를 줄이면 블록 크기 문제가 발생

4-3. 블롭 트랜잭션의 구조와 생성 과정

5. EIP4844는 롤업 비용을 과연 얼마나 절감할 수 있을까?

5-1. 현재 DA(L1 publication) 비용은 전체 롤업 비용의 90% 이상을 차지

5-2. 현 시점에서 EIP4844 도입 시 롤업의 DA 비용은 무료에 가까울 것으로 예상되며, 블롭 사용료가 유의미하게 증가하려면 롤업 수요가 10배 이상 증가해야 할 것

5-4. 이더리움 커뮤니티내에서는 블롭의 비용 구조를 변경하는 것도 적극적으로 논의 중

6. 맺으며

주석. 이더리움 데이터 저장 공간 종류

1. EVM내 주요 저장 공간은 스토리지(Storage), 메모리(Memory), 스택(Stack), 콜데이터(Calldata)로 분류됨

2. 그 중 롤업이 사용하는 공간은 콜데이터(Calldata)

1. 들어가며

알파는 EIP에 숨어있다. EIP1559(런던), EIP3675(더 머지), EIP4895(상하이) 업그레이드 1달 전후로 ETH 가격은 10%~80% 상승했다. 차기 업그레이드는 올해 말 적용 예정인 데네브(Deneb)와 칸쿤(Cancun)을 합친 덴쿤(Dencun) 하드포크다. 덴쿤에서 가장 주목을 많이 받고 있는 업그레이드 사항은 프로토-댕크샤딩(Proto-danksharding)으로 불리는 EIP4844로, 이더리움의 샤딩 로드맵을 구현하기 위한 첫 단추이자 롤업의 운영 비용을 획기적으로 절감해줄 제안이다.

본 리포트는 2부로 구성되어 있다. 전반부에서는 이더리움 샤딩의 발자취를 따라가면서 샤딩의 역사가 어떻게 변화했고 이더리움의 장기적인 비전인 댕크샤딩(Danksharding)이 무엇인지 살펴본다. 후반부에서는 프로토-댕크샤딩의 구조와 의의를 들여다보고 EIP4844 적용 이후 롤업의 경제 구조가 어떤 식으로 바뀌게 될지 그려본다.

2. 이더리움 샤딩의 역사와 변화 과정

2-1. 초기 이더리움의 샤딩 계획: Hypercubes, Hub and Spoke Chains, Super Quadratic Sharding, ETH2 Sharding

돌이켜보면 초창기 이더리움 커뮤니티에서 확장성 문제를 해결하기 위해 논의되었던 모델들은 대담하고 미래지향적이었다. 당시 등장했던 대표적인 모델들로는 hypercubes, super quadratic sharding, hub and spoke chains 등이 있었는데, 이 중에서도 하이퍼큐브(hypercube)와 허브 앤 스포크 체인 (hub and spoke chain)은 비탈릭이 이더리움 메인넷이 출시하기도 전인 2014년 말에 제안한 구조였다 (Scalability, Part 2: Hypercubes 글 참고). 허브 앤 스포크 체인은 오늘날 폴카닷의 Relay chain-Parachain 구조의 초기 형태라고 볼 수 있다. 한편, 하이퍼큐브는 허브 앤 스포크 체인의 단점을 보완하기 위해 등장한 모델로서, 허브(보라색)를 통하지 않고도 서브스테이트(substate)간 상호 작용이 가능하게 하여 메시징 속도를 개선했다는 장점이 있다. 안타깝게도 해당 모델은 공격 벡터가 많고 구현이 복잡하여 채택되지는 않았지만, 훗날 이러한 아이디어들이 ETH2 로드맵에 등장하는 quadratic sharding* 모델의 형성에 기여하는데 중요한 역할을 하였다. 이더리움의 샤딩은 이후 크게 세 가지 큰 변곡점을 맞이하게 되며, 이러한 변화 끝에 오늘날 샤딩 모델이 탄생하게 되었다.

*Quadratic sharding: 블록체인을 하나의 비콘 체인과 64개의 샤드 체인으로 분리하고 각각의 샤드들이 트랜잭션을 동시에 병렬적으로 처리한 뒤 헤더를 비콘 블록에 쏴주는 구조다. 비콘 블록마다 64개의 샤드에 대한 트랜잭션을 포함하고 있으며 각 샤드 블록에 대한 검증은 이더리움의 밸리데이터들로 구성된 64개의 위원회(committee)가 진행한다. 위원회는 랜덤 샘플링(random sampling) 과정을 통해 임의로 구성된다 (샤딩(Sharding): 이더리움 블록체인의 미래 참고).

첫 번째 변곡점은 흔히 ETH2로 불리는 세레니티(Serenity) 업그레이드의 로드맵이 점차 구체화되기 시작한 2017년 말~2018년 초 사이에 맞이했는데, 골자는 super quadratic sharding, exponential sharding과 같은 복잡한 개념들에 대한 연구를 중단하고 quadratic sharding부터 구현하자는 선택이었다. Super Quadratic Sharding은 샤드 위에 샤드를 추가하는 구조로, 스타크웨어(Starkware)가 제안한 L2 위에 L3체인들을 쌓아 올리는 개념인 fractal scaling과 유사하다. 이러한 결정 덕분에 이더리움은 quadratic sharding에 R&D 리소스를 전적으로 집중할 수 있게 되었다. 실제로 저스틴 드레이크(Justin Drake)가 2018년 3월에 작성한 Sharding phase1 spec을 보면 super quadratic sharding이 가장 마지막 단계인 phase 6에 배치된 것을 확인할 수 있다.

두 번째 변화는 2019년 하반기에 발생했는데, 이는 크로스링크(Crosslinks)* 개발을 포기하고 샤드 블록을 일방적으로 비콘 체인으로 전달하는 구조로 전환하는 것이었다 (깃헙 리포 참고). 기존에는 아래 그림과 같이 크로스링크를 통해 비콘 체인과 샤드 체인이 연결되여 서로 소통할 수 있도록 하는 것을 목표로 하였으나 (아래 그림에서 M은 Main Chain (Beacon Chain), S는 Shard Chain을 뜻한다), 이를 포기한 결과 샤드 체인 → 비콘체인 트랜잭션 플로우에만 신경 써도 된 것이다. 즉, 이전 모델에서는 메인 체인과 샤드 체인이 크로스링크를 통해 연결되어 있었지만, 새로운 구조에서는 이런 연결이 필요 없게 되었다.

*Crosslink:샤드 체인 블록을 검증한 비콘 체인 밸리데이터들 혹은 위원회(committee)의 서명(signature)으로, 비콘 체인이 샤드 체인의 최신 state을 확인하거나 샤드 체인간 상호작용할 때 사용되는 장치

Chain cross-linking, 출처: Vitalik Buterin

마지막은 비탈릭이 2020년 Rollup centric ethereum roadmap을 발표했을 때 도래했다. ‘롤업 중심의 로드맵’이라는 표현에서 유추할 수 있듯 해당 시기를 기점으로 롤업의 역할이 이더리움 생태계내에서 크게 확대되었다. 핵심은 트랜잭션 실행(execution)을 롤업에 위임하고, 샤드는 오직 데이터 가용성(Data Availability) 레이어로만 활용하자는 것이다. 즉, 샤드는 데이터를 기록하는 역할만 수행하고 사용자들의 트랜잭션 데이터를 실제로 실행하는 역할은 롤업이 담당하게 된 것이다. 이더리움이 execution sharding에서 data sharding으로 피벗하게 된 순간이기도 하다.

이더리움 로드맵, 출처: 비탈릭 부테린

2-2. 간소화와 실용주의의 추구: Full Execution Sharding → Data Sharding

이더리움 샤딩의 역사는 본질적으로 '줄이고 간소화하는 과정'의 반복이다. 샤딩은 이더리움이 최초로 설계되었을 때부터 확장성 문제를 개선하기 위한 해결책으로 꾸준히 제시되었다. 그러나 예상보다 기술적으로 구현하기가 복잡하고 어려운 덕에 샤딩은 점차 단순성과 실용성을 추구하는 방향으로 전환하였고, 최종적으로 각 샤드가 트랜잭션을 모두 실행하는 full execution sharding에서 롤업이 실행한 트랜잭션 데이터만 저장하는 data sharding로 발전하였다.

개편된 로드맵의 핵심은 샤드 체인을 롤업 데이터를 보관하는 데이터 가용성 레이어로만 활용하고, 트랜잭션 실행은 롤업에게 위임하는 것이다. 여기서 컨센서스 레이어의 역할은 샤드 데이터의 가용성을 보장한다. 이를 구현하기 위해 이더리움 재단 리서처 Dankrad Feist는 2021년 12월 ‘New sharding design with tight beacon and shard block integration’라는 글에서 한 명의 블록 빌더가 각 샤드의 트랜잭션을 모두 포함하는 비콘 블록을 생성하되, 블록 생성 과정에서 중앙화 현상을 최소화하기 위해 프로포저와 빌더를 분리하는 PBS(Proposer Builder Separation) 구조를 활용하자고 제안하였다. 결과적으로 해당 아이디어는 이더리움 커뮤니티에서 긍정적인 반응을 얻어 공식 이더리움 로드맵에 채택되었고, 이로써 댕크샤딩이 탄생하게 되었다.

3: 댕크샤딩(Danksharding)

3-1. 댕크샤딩은 데이터 샤딩을 위한 신규 블록체인 아키텍쳐

ETH2 샤딩 방식에서는 이더리움 밸리데이터들이 랜덤 샘플링(random sampling)되어 위원회를 구성하고, 이들이 번갈아가면서 64개의 샤드 블록들을 동시에 생성하고 검증한다. 그러나, 데이터 가용성 샘플링(DAS, Data Availability Sampling) 기능이 없기 때문에 밸리데이터들은 직접 샤드 데이터를 100% 저장하고 그 데이터의 가용성을 증명해야 한다. 그러나 특정 밸리데이터가 고의적으로 데이터를 제공하지 않을 경우, 이를 검증하는 방법이 없기 때문에 이 시스템은 모든 노드가 정직하다는 가정 하에만 정상적으로 작동할 수 있다. 게다가, 위원회는 샤드 블록에 대한 각 노드의 투표 결과를 일일이 집계해야 하는데 이 과정에서 시간이 지연돼 샤드 블록이 비콘 블록에 제때 포함되지 못하는 가능성도 있다. 따라서, 기존 샤딩 방식은 구현이 상당히 복잡하며, 이와 더불어 많은 위험 요소도 내포하고 있었다.

반면, 댕크샤딩에서는 단일 노드가 샤드 블롭(blob)*들을 모두 포함하는 하나의 거대한 블록을 구성하고 위원회가 이를 검증 및 투표하게 된다. 이런 방식은 앞서 언급한 샤드 블록이 비콘 블록 안에 제때 포함되지 못하는 문제를 효과적으로 해결한다. 그러나 댕크샤딩의 구조상 블록 생성 과정이 중앙화될 수밖에 없는 문제가 있는데, 이는 Proposer Builder Separation(PBS)를 도입함으로써 최소화할 수 있다. PBS는 비탈릭이 Endgame에서 제시한 ‘중앙화된 블록 생성, 탈중앙화된 블록 검증’ 원칙을 코드화하여 실제로 구현하는 방법이다.

*Blob: 비콘 체인에만 저장되는 새로운 형태의 데이터 타입으로, Binary Large Objects의 약자다. 블롭의 개념은 댕크샤딩이 등장하면서 처음 제시되었으며, 주로 롤업 데이터를 위한 저장 공간으로 사용될 것으로 예상한다.

3-2. 중앙화 현상을 최소화하기 위해 PBS(Proposer Builder Separation)와 CrList를 활용할 예정

본래 PBS는 ‘Proposer/block builder separation-friendly fee market designs’에서도 나와있듯 MEV를 탈중앙화하기 위해 고안된 개념이지만, 댕크샤딩 구조와 잘 맞아 아키텍쳐에 포함되었다.

MEV는 기본적으로 멤풀을 빠르게 업데이트할 수 있는 뛰어난 HW를 갖추고 고도화된 MEV 추출 알고리즘을 개발할 수 있는 리소스를 갖춘 소수의 강력한 노드들이 독식할 수 밖에 없는 구조다. PBS는 기본적으로 블록 생성자의 역할을 프로포저(proposer)와 빌더(builder)로 분리하는 아이디어로, 이를 통해 상대적으로 컴퓨팅 파워가 낮고 리소스가 부족한 노드들도 MEV를 얻을 수 있는 기회를 제공한다. 여기서 빌더는 고도화된 MEV 추출 알고리즘을 개발할 수 있는 강력한 검증자들로, 트랜잭션의 순서 결정 및 블록 생성을 담당한다. 반면 프로포저는 빌더들이 제안한 블록 중 어떤 블록을 체인에 기록할지 결정하는 권한을 갖는다.

이로써, 기존에는 한 명의 검증자가 트랜잭션 구성 및 블록 생성을 독점하던 구조가 PBS 도입 후에는, 아무리 컴퓨팅 능력이 강력한 노드라도 프로포저와 MEV를 공유하게 된다. 이 과정에서 프로포저는 입찰 금액을, 빌더는 트랜잭션 수수료와 입찰 금액을 제외한 MEV를 수익으로 얻게 된다.

여기서 주목할 점은, 입찰 과정에서 빌더들이 전체 블록 데이터 대신 블록 헤더와 희망 입찰 가격만 먼저 공개한다는 것이다. 이는 전체 블록 데이터를 공개할 경우, 다른 빌더들이 트랜잭션 내용을 복사하여 MEV를 가져갈 수 있기 때문이다. 그래서 전체 블록 데이터는 프로포저가 블록을 선택한 이후에 비로소 공개되게 된다.

Two-slot PBS 아키텍쳐, 출처: Two-slot proposer/builder separation

PBS는 블록 구성 권한을 빌더에게 전임한다는 측면에서 블록체인의 검열 저항성이 상대적으로 약화될 수 있다는 문제가 있다. 이에 대해 이더리움 커뮤니티는 Censorship Resistance List (CrList)를 도입하여 이 문제를 해결하려고 계획하고 있다. CrList를 도입한 후의 트랜잭션 흐름은 다음과 같이 예상된다:

1. 프로포저가 자신의 멤풀에 있는 유효한 트랜잭션을 모두 포함한 crList를 빌더에게 공개한다.
2. 빌더가 crList에 있는 트랜잭션을 기반으로 블록을 구성하고 프로포저에게 제출한다. 이 과정에서 빌더는 crList에 기록된 모든 트랜잭션을 포함했다는 것을 증명하는 트랜잭션 해시를 블록 바디(block body)에 포함시킨다.
3. 프로포저는 입찰 금액이 가장 높은 블록을 선택하고 블록 헤더를 구성한 뒤 노드들에게 알린다.
4. 블록이 체인에 추가된다. 빌더가 증명을 제출하지 않을 경우, 해당 블록은 포크선택 규칙(fork choice rule에 의해 거부된다.

3-3. 그 외에도 체인의 확장성과 신뢰를 확보하기 위한 수단으로 DAS, Erasure coding, KZG commitment 등을 도입할 것

댕크샤딩을 안전하고 효율적으로 구현하기 위해선 PBS와 crList 외에도 몇 가지 기술이 선제적으로 도입되어야 하는데, 대표적으로 1) 데이터 가용성 샘플링(DAS, Data Availability Sampling) 2) Erasure Coding, 그리고 3) KZG Commitment가 그것이다.

먼저, DAS는 댕크샤딩 도입 시 잠재적으로 생기게 될 노드의 중앙화 및 네트워크 확장성 문제를 해결하기 위한 기술이다. 향후 이더리움이 대중화되면서 롤업 개수 뿐만 아니라 롤업이 처리하는 데이터 크기가 증가하게 되면 노드들이 보관해야 하는 데이터의 크기도 기하급수적으로 증가할 것이다. 이는 확장성을 저해할 뿐만 아니라 시간이 지날수록 급증하는 데이터 용량을 감당할 수 있는 노드들만 남게 만들어 중앙화 현상을 야기하는데 (데이터 가용성 문제로도 불린다), DAS는 DA를 보장하는 동시에 데이터 크기에 대한 노드들의 부담을 덜어줘 보다 많은 노드들이 네트워크에 참여할 수 있게끔 유도할 수 있다. 비트토렌트, IPFS와 같은 기타 탈중앙화 파일 시스템 대비 안전하고 신뢰성이 높은 이유이기도 하다 (비트토렌트나 IPFS는 데이터를 업로드하기 용이한 파일 시스템이기는 하나, DA를 보장하지는 않는다).

DAS는 노드들로 하여금 블록체인 데이터를 모두 다운로드하는 것이 아니라 블롭내 데이터가 50% 이상 가용 가능한지만 검증한다. 가용 가능한 데이터가 50% 이상이면 DA가 보장되는데, 그 비결은 Reed-Solomon 코드를 이용한 erasure coding에 있다. erasure coding의 핵심은 원본 데이터를 기반으로 데이터 크기를 특정한 방식으로 2배 불린다면 원본 데이터가 50% 손실되어도 누구나 남은 50%의 데이터를 이용하여 전체 데이터를 복구할 수 있다는 것이다. 비탈릭의 An explanation of the sharding + DAS proposal에 따르면, Erasure coding의 원리를 이해하는 가장 간단한 수학적 비유는 "두 개의 점만 있으면 선을 복구할 수 있다"를 떠올리는 것이다. 예를 들어, 어떠한 파일을 하나의 선 위에 있는 네 개의 점 (1, 4), (2, 7), (3, 10), (4, 13)으로 구성하면, 이러한 점 중 임의의 두 점만 있어도 선을 재구성하고 나머지 두 점을 계산할 수 있다. 여기서 x 좌표 1, 2, 3, 4는 시스템의 고정된 매개변수로, 파일 생성자의 선택이 아니라고 가정한다. 이 아이디어를 확장하여 더 높은 차수의 다항식(poynomial)을 사용하면 3/6 파일, 4/8 파일, 그리고 일반적으로 임의의 n에 대해 n/2n 파일을 생성할 수 있다. 이러한 파일은 임의의 n점이 있어도 2n개 중 누락된 나머지 점들을 계산할 수 있다는 특성을 가지고 있어 erasure coding된 데이터 중 50%만 남아있어도 전체 데이터를 재구성할 수 있다. 다만, erasure coding이 제대로 진행되었는지 확인할 수 있는 안전장치가 반드시 마련되어야 한다. 원본 데이터가 아닌 쓰레기 데이터를 블롭에 채워 넣었을 경우 블록을 원상 복구할 수 없기 때문이다. KZG commitment가 필요한 이유이기도 하다.

Erasure Coding 원리, 출처: An explanation of the sharding + DAS proposal

Erasure coding을 검증할 수 있는 방법은 롤업의 증명 시스템과 마찬가지로 사기 증명와 영지식 증명으로 나뉜다. 코스모스 기반 DA 레이어인 셀레스티아는 erasure coding된 데이터의 무결성(integrity)을 보장하기 위해 사기 증명을 사용할 예정이나, 이더리움 커뮤니티는 영지식 증명 시스템인 2D KZG commitment를 사용하기로 결정했다. 2D KZG commitment를 사용할 경우 DAS를 75번 반복하면 1의 확률로 전체 데이터를 복구할 수 있다고 한다. 단, SNARK와 마찬가지로 초기에 trusted setup 과정을 필요로 하여 완벽한 솔루션이라고 볼 수는 없다. KZG commitment는 CRS(Common Reference String)라고 불리는 랜덤값에 의존하는데, 해당 값은 최초 셋업 단계에서 정해지는 값으로 이 값을 프루버(prover) 혹은 증명 생성자가 임의로 지정하면 자신이 실제로 값을 가지고 있지 않더라도 참(true)의 결과값을 나타내는 가짜 증명을 생성할 수 있기 때문이다. 따라서, 이더리움 커뮤니티에서 우선 2D KZG commitment를 사용하되 향후에는 STARK를 전환하자는 의견도 나오고 있다. 관련하여 구체적인 설명은 Dankrad Feist가 작성한 KZG Polynomial Commitments를 참고하길 바란다.

4. EIP4844: 프로토-댕크샤딩(Proto-danksharding)

댕크샤딩의 구체적인 스펙이 아직 논의되고 있고 이를 실제로 도입하기까지 수년은 걸릴 것으로 예상되는 가운데, 이더리움 커뮤니티는 다가오는 덴쿤 업그레이드에 EIP4844를 포함하여 댕크샤딩의 일부 파라미터들을 프로토콜에 선제적으로 적용하기로 결정하였다.

4-1. EIP4844는 댕크샤딩의 초석

프로토-댕크샤딩이라는 이름과 달리 EIP4844는 실제로 이더리움 데이터베이스를 샤딩하지 않는다. 대신, EIP4844는 1) 향후 프로토콜 아키텍쳐를 댕크샤딩으로 매끄럽게 전환하기 위해 필요한 일부 로직들을 미리 도입하고 2) 블롭 트랜잭션(blob carrying transaction)을 출시하는 것이 목표다.

EIP4844의 꽃이라 불리는 블롭은 Binary Large Objects의 약자로, 단순하게 설명하면 트랜잭션에 붙어 있는 데이터 덩어리다. 일반적인 트랜잭션과 달리 블롭 데이터는 비콘 체인에서만 저장되며 사용료(가스비)가 매우 저렴하다. 블롭의 목적은 블록스페이스와 별개로 순수하게 데이터 가용성을 위한 저장 공간을 구축하여 롤업의 DA(L1 publication) 비용을 획기적으로 절감하는 것이다. 현재 모든 롤업들은 자체 데이터를 이더리움에 기록할 때 콜데이터(calldata) 공간을 사용하고 있는데, 블롭 도입 시 콜데이터의 대체할 수 있을 것으로 기대한다. 이더리움의 데이터 저장 공간과 롤업이 현재 콜데이터를 사용하고 있는 이유가 궁금하다면 주석을 참고하길 바란다.

4-2. 단순히 콜데이터 사용료를 줄이면 블록 크기 문제가 발생

사실 롤업의 DA 비용을 줄이기 위한 담론들은 EIP4844 이전부터 꾸준히 이어져 왔다. 최초로 제시되었던 아이디어는 단순무식하게 콜데이터 사용료(가스비)를 줄이자는 것이었는데, 이는 블록 크기 이슈로 인해 얼마 가지 않아 기각되었다. 블록 크기 이슈를 예시로 설명하겠다. 콜데이터 가스비를 10배 줄인다고 가정해보자. 오늘날 이더리움의 평균 블록 크기는 120kb, 이론상 최대 사이즈는 약 1.8mb다 (30M gas가 모두 콜데이터에 사용된다고 가정). 콜데이터 비용을 10배 줄이게 되면 평균 블록 크기는 여전히 감당 가능한 수준으로 유지되는 반면, 최대 블록 크기는 18mb로 네트워크가 처리할 수 있는 수준을 아득히 넘어서게 된다. 즉, 단순히 콜데이터 가스비를 줄이면 네트워크가 비상식적으로 비대해지는 결과를 낳을 수 있다.

출처: etherscan

위 아이디어를 개선하여 등장한 것이 2021년 11월에 제시되었던 EIP4488이다. EIP4488은 콜데이터 가스비를 16gas/byte에서 3gas/byte로 줄이되, 최대 블록 크기를 1.4mb로 강제하자는 제안이다. 콜데이터 비용이 5.3배로 줄어드니 롤업 사용량이 증가하는 동시에 최대 블록 크기에 하드캡을 씌우기 때문에 블록 크기가 겉잡을 수 없이 커지는 것도 방지할 수 있다는 것이 EIP4488의 핵심이다.

반면, EIP4844는 블롭이라는 새로운 데이터 타입을 만들고 이를 위한 자체 수수료 시장을 구축하여 롤업의 DA (l1 publication) 비용을 절감할 수 있게 해준다. 로직이 직관적이고 간단하여 배포 속도가 빠른 EIP4488과 달리 EIP4844는 구현하는데 비교적 시간이 오래 걸리나, 댕크샤딩에 필요한 업데이트 사항들을 미리 도입한다는 측면에서 장점이 있다. EIP4844가 통과되면 실행 레이어 클라이언트단에서 댕크샤딩을 위한 준비는 완료되며, 향후 컨센서스 클라이언트단에서만 업그레이드가 이루어지면 된다. EIP4844가 채택된 이유이기도 하다.

4-3. 블롭 트랜잭션의 구조와 생성 과정

블롭의 구조를 조금 더 구체적으로 살펴보자. 블롭은 32byte로 구성된 4,096개의 필드로 이루어져 있어 블롭 한 개당 크기는 125kb*다. 업데이트된 EIP4844 문서를 보면 블록당 평균 3개, 최대 6개의 블롭을 추가할 예정이라 하니 블록당 블롭 크기는 375kb ~ 750kb이다. 향후 댕크샤딩이 도입되면 목표/최대 블롭 개수가 각각 128개, 256개까지 증가할 예정이라 16mb~32mb의 블롭 공간이 확보되겠다.

*사실 125kb도 결코 적은 용량이 아니다. 문자당 1byte, 단어당 평균 6개의 문자로 구성되어 있다고 가정하면 125kb는 약 21,000개의 영어 단어를 포함할 수 있는 크기다. ChatGPT한테 물어보니 영어 단어 21,845개면 A4 용지 대략 77장 정도 채울 수 있다고 한다 (font Arial, size 10, line spacing 2).

출처: Deep in to EIP4844, hackmd(@Yicheng-Chris)

블롭 트랜잭션(blob carrying transaction)의 데이터를 담은 BlobTransactionNetworkWrapper를 살펴보면 크게 1) 메시지와 서명을 포함하고 있는 SignedBlobTransaction, 2) 블롭 커밋값이 담긴 blob_kzg, 그리고 3) 블롭 데이터가 담긴 blob으로 구성되어 있다.

Signedblobtransaction내 메시지란을 보면 일반적인 EIP1559 트랜잭션에 blob_versioned_hashes라는 필드가 하나 추가되었다는 것을 확인할 수 있다. blob_versioned_hashes는 0x01(버전을 나타내는 1byte 값)에 블롭 데이터의 KZG commitment를 SHA256 해시 함수로 변환한 32byte의 마지막 31byte를 합친 값이다. KZG commitment는 블롭 데이터의 요약본이라고 할 수 있는데, 48byte로 구성된 해당 KZG commitment를 굳이 한 번 더 해시하여 32byte로 변환하는 이유는 EVM과의 상위 호환성(forward compatibility)* 때문이다.

*상위 호환성: EVM은 스택 기반의 아키텍처를 사용하는데, 스택의 데이터 요소 크기인 워드 사이즈가 32byte(256bits)다.

출처: miror.xyz(@yicheng.eth)

그렇다면 애초에 blob_versioned_hashes가 트랜잭션에 포함되어 있는 이유는 무엇일까? 이는 블롭 트랜잭션의 생성 과정을 보면 알 수 있으며, blob_kzg와 blob이 Signedblobtransaction과 떨어져 있는 이유와도 연관성이 있다 (아래 그림 참고).

블롭 트랜잭션의 생성 과정을 살펴보면, 먼저 롤업 사용자들이 트랜잭션을 제출하면 시퀀서가 이를 모아 L1 트랜잭션 멤풀로 전송한다. 이후 이더리움 프로포저는 멤풀에 있는 블록 트랜잭션을 두 부분으로 나누어 노드들에게 전파하는데, 이때 Signedblobtransaction는 Execution Payload, blob_kzg와 blob는 Sidecar의 형태로 전달된다. 실제 트랜잭션 정보가 담겨있는 Execution Payload는 실행 클라이언트(L1 실행 엔진), Sidecar는 컨센서스 클라이언트에서 다운로드할 수 있다. 즉, 블롭 데이터는 비콘 체인에만 저장된다. 따라서, EVM에서는 블롭 데이터가 담긴 사이드카에 접근할 수 없는데, 이는 blob_versioned_hashes가 트랜잭션에 포함되어 있는 이유이자 KZG commitment가 필요한 이유이기도 하다.

기존에는 롤업이 콜데이터를 사용했기 때문에 EVM이 콜데이터에 접근하여 롤업 트랜잭션을 직접 실행해보고 유효성을 증명할 수 있었다. 그러나, 블롭이 도입되고 롤업이 블롭을 사용하기 시작하면 EVM은 더 이상 롤업 데이터에 접근할 수가 없기 때문에 Signedblobtransaction에 블롭 데이터의 요약본과 마찬가지인 blob_versioned_hashes을 포함하였고, 덕분에 노드들은 EVM 실행 레이어에서 접근 가능한 blob_versioned_hashes와 컨센서스 레이어에 있는 blob_KZG 커밋값과 매칭하는지 교차 검증(cross-checking)하면 된다.

그 외 주목할 만한 포인트는 볼롭 데이터가 담겨있는 Sidecar 정보가 30일 뒤 비콘 체인에서 삭제된다는 것이다. 컨센서스 노드가 블롭의 DA를 검증할 수 있는 시간이 한 달이라는 뜻인데, 이와 관련하여 비탈릭은 컨센서스 프로토콜의 역할은 신뢰할 수 있는 실시간 게시판(’a highly secure real-time bulletin board’)을 제공하는 것이지 데이터를 영구 저장하는 것이 아니라고 밝혔다. 블롭 데이터가 체인에 영구 저장된다면 매년 +2.5TB 이상의 데이터가 쌓이게 되는데, 이는 이더리움 네트워크에게는 부담스러운 수준이기 때문이다. 반면, 개인이 저장하는데 큰 무리는 없는 크기이기도 하다 (HDD 기준 1TB당 약 $20). 따라서, 블롭 데이터의 영구 저장은 롤업, API 제공자, 탈중앙화 스토리지 시스템 (예: 비트토렌트), 익스플로러 (이더스캔), 인덱싱 프로토콜 (예: 더그래프) 등과 같이 대규모 데이터 저장이 비교적 용이한 프로토콜들이 담당하는 식으로 역할 분담을 하는 것이 이상적일 수 있겠다. 추가적으로, blob_versioned_hashes 데이터가 담긴 Execution Payload 데이터는 여전히 블록체인에 저장되어 있기 때문에, 원본의 KZG commitment와 비교하여 30일이 지난 데이터의 유효성을 증명하는 것도 가능할 것으로 보인다.

5. EIP4844는 롤업 비용을 과연 얼마나 절감할 수 있을까?

5-1. 현재 DA(L1 publication) 비용은 전체 롤업 비용의 90% 이상을 차지

EIP4844가 롤업 경제 모델에 끼치게 될 영향을 살펴보기에 앞서 롤업의 수익 구조부터 간단하게 살펴보자. 먼저 롤업이 벌어들이는 매출은 네트워크 수수료와 MEV 두 가지로 나뉜다. 여기서 매출이라 하면 오퍼레이터/시퀀서 매출인데, 현재 모든 롤업은 단일 오퍼레이터 체제로 운영되고 있어 프로젝트 운영 법인이 독식하고 있는 상황이다.

네트워크 수수료 매출은 쉽게 말해 롤업 사용자들이 트랜잭션을 남길 때 오퍼레이터에게 지불하는 가스비로, 롤업을 운영하는데 드는 비용에 +a 수수료를 합한 액수다. 사용자들에게 +a 수수료를 청구하는 이유는 여느 사업과 마찬가지로 이익을 남기기 위함도 있지만 베이스 레이어의 가스비가 급증하는 경우에 대비하여 손해를 보지 않기 위함이다 (오퍼레이터는 사용자들에게 먼저 가스비를 걷고 나서 배치를 베이스 레이어에 제출한다). 7월 13일 기준 옵티미즘의 30일 평균 일일 매출과 이익은 각각 41.4ETH, 11.5ETH로 집계되었다 (이익률 27%).

아비트럼을 비롯한 수많은 롤업 프로젝트들은 FCFS(First Come First Serve) 방식으로 운영되고 있어 MEV이익은 사실상 없는 것이나 다름없다 (실제로 FCFS 방식으로 운영되고 있다는 것을 확인할 수 있는 방법은 없으나, 적어도 롤업의 공식 입장은 FCFS다). 앞서 언급했듯, 롤업은 현재 단일 오퍼레이터 체제로 운영되고 있어 블록 생성 경쟁이 없는 상황에서 MEV를 독식한다면 자칫 중앙화 논란에 휩싸일 수 있기 때문이다. 따라서 이러한 롤업들은 오퍼레이터가 탈중앙화된 이후에나 MEV이익이 발생할 가능성이 높다 (공유 시퀀서 네트워크: 롤업의 탈중앙화를 위한 미들웨어 블록체인 리포트 참고). 흥미롭게도, 옵티미즘은 priority fee가 집계되고 있는 것으로 봐서 MEV이익이 있는 것으로 보인다 (6월을 기점으로 priority fee가 전체 트랜잭션 수수료의 10~20%를 차지하고 있는 중).

롤업 비용은 고정비와 변동비로 구분할 수 있다. 고정비는 1) 트랜잭션 연산 과정에서 바뀐 스테이트 루트값을 롤업 스마트 컨트랙트에 제출할 때 지불하는 state write 비용 2) 유효성 증명 (ZK롤업에 해당) 3) 이더리움 기본 트랜잭션 수수료 (21,000gas)으로 분류할 수 있고, 변동비는 1) 트랜잭션 연산에 드는 L2 가스비와 2) 배치 데이터를 이더리움 블록에 저장할 때 필요한 L1 publication 수수료로 나뉜다.

현재 비용 측면에서 압도적으로 높은 비중을 차지하고 있는 것은 변동비의 2번 작업이다. 롤업은 배치 데이터를 이더리움 블록에 저장하는 과정에서 콜데이터를 사용하는데, 콜데이터 사용료는 zero bytes 0x00의 경우 4gas/byte, non-zero bytes의 경우 16 gas/byte다 (롤업이 콜데이터를 사용하는 이유는 주석에서 설명한 바 있다). 16 gas/byte면 스토리지를 이용하는 것 대비 매우 저렴한 편이기는 하나 애초에 배치 데이터의 크기가 작지 않음을 명심해야 한다. 올해 옵티미스틱 롤업에 대한 수요가 매우 높았던 2~3월 기준 아비트럼과 옵티미즘은 블록당 각각 14.6kb, 13kb의 데이터의 데이터를 저장했다. 이러한 이유로 현재 콜데이터 비용은 전체 롤업 비용의 약 99% 정도를 차지하고 있는 상황이다.

5-2. 현 시점에서 EIP4844 도입 시 롤업의 DA 비용은 무료에 가까울 것으로 예상되며, 블롭 사용료가 유의미하게 증가하려면 롤업 수요가 10배 이상 증가해야 할 것

EIP4844 파라미터에 따르면 블롭 사용료(가스비)는 블록스페이스 수요에 영향을 받지 않는 자체 데이터 가스(data gas) 수수료 시장을 기반으로 블롭 수요/공급에 따라 동적으로 결정된다. 따라서 이더리움은 EIP4844 이후 1) 일반적인 트랜잭션을 위한 EIP1559 기반 수수료 시장과 2) 오로지 블롭의 수요와 공급에 따라 사용료가 정해지는 블롭 수수료 시장으로 구성된 2차원 수수료 마켓(two dimensional EIP1559 fee market)이 형성될 예정이다.

EIP4844에 명시되어 있는 data gas 수수료 시장의 작동 방식은 EIP1559 매커니즘과 유사하다. 블롭 트랜잭션은 max_fee, max_priority_fee, gas_used 등 EIP1559 매커니즘에서 요구하는 필드값이 모두 존재하며 사용자들의 priority fee를 나타내는 max_fee_per_data_gas 필드가 새롭게 추가되었다. Data gas 구조도 EIP1559와 동일하게 basefee와 priority fee로 구분할 수 있다. 다만, basefee의 소각 여부는 여전히 논의 중이기는 하다.

또한, EIP1559의 블록당 gas target이 15M gas, max gas가 30M gas라면, 블롭의 TARGET_DATA_GAS_PER_BLOCK은 375kb, MAX_DATA_GAS_PER_BLOCK은 750kb다. 기본적으로 블롭 데이터는 byte당 1 data gas로 설정되어 있으며 최소 data gas price는 1wei다. 다만, EIP1559와 마찬가지로 목표하고 있는 data gas (TARGET_DATA_GAS_PER_BLOCK)에 비해 실제로 얼마나 사용되는 지에 따라 basefee가 최대 -12.5~12.5% 증감할 수 있다. 네트워크 활성도가 높더라도 EIP4844 도입 초반에는 블롭 사용량이 낮아 블롭의 비용 자체는 저렴할 가능성이 높다.

EIP4844 가스비 매커니즘은 EIP1559와 매우 유사, 출처: EIP4844, Vitalik Buterin

그렇다면 EIP4844는 롤업의 운영 비용을 구체적으로 얼마나 절감할 수 있을까? 이와 관련하여 dcrapis의 “EIP4844 fee market analysis”라는 리서치 리포트를 소개하고자 한다. 그는 해당 글에서 올해 아비트럼과 옵티미즘의 1~2월 배치 데이터를 기반으로 EIP4844가 롤업 경제 모델에 어떠한 영향을 끼치게 되는지 분석해보았으며 다음과 같은 결론에 이르렀다 (아비트럼과 옵티미즘 데이터를 사용한 이유는 둘의 콜데이터 사용량이 L2 전체 콜데이터 사용량의 98%를 차지하기 때문이다):

결론1. 현재 블롭 수요는 목표치(블록당 250kb 기준)보다 약 10배 낮으며, 목표 수준까지 도달하는데 약 1~2년 정도 걸릴 것으로 예상

• 2023년 1~2월 기준 아비트럼은 6.78 블록마다 ~99kb 크기의 배치를 1,055개 생성했다 (일일 100mb, 블록당 14.6kb). 같은 기간 옵티미즘은 2.37 블록마다 ~31kb 크기의 배치를 2,981개 생성했다 (일일 93mb, 블록당 13kb). 두 롤업이 생성해내는 데이터를 더하면 블록당 27.6kb 수준인데, 이는 현재 롤업에 대한 수요가 블롭 목표치인 250kb(블록당 블롭 2개 기준)에 비해 1/10 밖에 도달하지 못한 셈이다.
• 잠재 수요가 블롭 목표치보다 높으면 EIP4844의 가격 발견(price discovery) 매커니즘에 의해 data gas 가격이 상승하고, 지불 의향(willingness to pay)이 가장 낮은 블롭 트랜잭션이 삭제되어 가격 균형이 유지된다. 2022년 1월부터 2022년 12월까지 이더리움 롤업의 총 데이터 수요는 약 4.4배 증가했는데, 이 속도라면 가격 발견 메커니즘이 작동하고 데이터 가격이 1 이상으로 상승하는데 무려 1.5년이 소요된다.

롤업 수요에 따른 data gas 가격 예상 추이, 출처: EIP-4844 Fee Market Analysis

결론2. 블롭 수요가 목표 수준에 근접하기 전까지 사용료는 실질적으로 0원에 가까울 것

• 아비트럼 배치 하나를 이더리움에 기록하는데 약 1.89M gas가 소요된다. 평균 가스 가격이 29gwei, $ETH 가격이 $1500임을 가정하면 배치당 DA비용은 약 $85, 콜데이터 비용은 약 $70이다. 이를 블롭으로 변환하면 precompile하는데 드는 비용은 약 $2.2 (50k gas), DA 비용은 $2e-10(125k data gas)로 사실상 무료인 셈이다. 이렇게 낮은 비용은 잠재적으로 스패밍(spamming) 혹은 ddos 문제로 이어질 수도 있다.

결론3. 블롭 수요가 목표 수준을 초과하면 data gas 비용은 몇 시간 만에 10배 이상 증가하는 등 기하급수적인 속도로 증가하게 될 것

• 블롭 수요가 목표 가격에 도달하면 지불 의향이 낮은 트랜잭션이 삭제되고 수요가 감소하기 전까지 12초마다 data gas 가격이 기하급수적으로 상승한다. 롤업 수요가 구조적으로 비탄력적(inelastic)이고 꾸준히 발생한다는 점을 고려한다면 몇 시간 만에 비용이 10배 이상 상승할 수 있다는 뜻이다. 블롭 소비자들은 치솟는 가격에 대응하기가 매우 어려울 것으로 예상된다.

5-3. 이더리움 커뮤니티내에서는 블롭의 비용 구조를 변경하는 것도 적극적으로 논의 중

위와 같이 잠재적으로 발생할 수 있는 문제점들로 인해 이더리움 커뮤니티내에서는 블롭의 비용 구조를 변경하는 것도 적극적으로 논의하고 있다. 예로, Dankrad Feist는 EIP PR-5862서 data gas의 최소 가격을 1wei/byte에서 1gwei/byte로 변경하자고 제안한 바 있다. 다만, Micah Zoltu를 포함하여 일부 집단에서는 이처럼 최소 가격을 올릴 경우 향후 $ETH 가격이 100~1,000배 올라가면 롤업의 DA(L1 publication) 비용이 또다시 너무 비싸질 것이라는 우려의 목소리도 나오고 있다 (필자는 개인적으로 현 시점에서 ETH 가격이 1,000배 올라가는 것을 걱정할 필요가 있을까 싶기는 하다). 두 번째 대안은 블록당 data gas 목표치를 블롭 3개에서 1.5개로 낮추는 것이다. 해당 방법은 스패밍을 방지할 수는 없으나 목표 도달하는데 걸리는 시간을 반으로 단축시킬 수 있다는 장점이 있다.

6. 맺으며

정리하면, EIP4844는 블롭으로 롤업의 DA 비용을 절감하고 풀 댕크샤딩을 구현하는데 필요한 일부 업그레이드 사항들을 미리 도입하는데 목적이 있다. EIP4844 이후 PBS 혹은 DAS 등 컨센서스 레이어에서 업그레이드가 완료되면 풀 댕크샤딩을 구현할 수 있을 것이다. 다만, 댕크샤딩은 아직 연구 초기 단계일 뿐더러 이더리움 커뮤니티내에서도 구체적인 스펙에 대한 뚜렷한 윤곽이 나오지 않은 상황인 만큼 댕크샤딩을 도입하기까지 수년은 걸릴 것으로 예상한다.

프로토-댕크샤딩은 블록마다 125kb 크기의 블롭을 3~6개 추가하는 것을 목표로 한다. 현재 이더리움의 평균 블록 크기가 약 120kb인 것을 감안하면 블록당 약 3~6배의 DA전용 저장 공간이 추가적으로 확보되는 셈이다 (풀 댕크샤딩 이후엔 블롭 개수가 128~256개까지 증가하여 블록당 16~32mb의 공간이 확보된다).

블롭 사용료는 콜데이터 대비 매우 저렴할 것으로 예상되며 현재 EIP4844의 스펙과 롤업 수요를 고려하면 블롭 사용료는 사실상 무료에 가까울 것으로 판단한다. 지난해 롤업 수요 증가 추세를 고려하면 블롭 가격이 가격 발견(price discovery) 구간에 도달하기까지 약 1~2년 정도 걸릴 것으로 보고 있다. EIP4844 도입 이후 중단기적으로 롤업이 현존하는 블록체인 중 트랜잭션 수수료가 가장 저렴할 수도 있겠다. 일각에서는 이에 따른 잠재적인 부작용을 우려하여 1) 블롭 사용료를 올리거나 2) 목표 블롭 개수를 낮춰 가격 발견 구간까지 걸리는 시간을 단축하자는 반응도 나오고 있다. 다만, 확실한 것은 EIP4844가 롤업을 대중화하는데 크게 기여할 것이라는 점이다. 최근 XRP 판결과 블랙록, 피델리티 등 대형 금융기관들의 비트코인 현물ETF 신청 등으로 인해 크립토 업계에 훈풍이 불고 가운데 EIP4844가 ‘rollup summer’을 이끌어낼 수 있을 지 기대해본다.

주석. 이더리움 데이터 저장 공간 종류

스마트 컨트랙트는 블록체인에서 실행되는 컴퓨터 프로그램으로, 함수(function)와 변수(variables) 또는 매개변수(parameters)로 불리는 데이터로 구성되어 있다. 해당 함수들이 사용하는 데이터는 컴퓨터(EVM) 메모리에 저장되어 있는데, EVM의 프로그래밍 언어인 솔리디티는 스토리지(storage), 메모리(memory), 스택(stack), 콜데이터(calldata) 등 크게 총 네 가지 유형의 메모리가 존재한다.

1. EVM내 주요 저장 공간은 스토리지(Storage), 메모리(Memory), 스택(Stack), 콜데이터(Calldata)로 분류됨

먼저, 스토리지는 컴퓨터의 파일 시스템(HDD/SDD)과 같이 데이터를 EVM에 영구적으로 저장할 때 사용하는 공간으로, 트랜잭션이 실행되는 동안에만 존재하는 메모리와 달리 이곳에 저장되는 변수들은 계속해서 읽기/쓰기가 가능하다. 컨트랙트마다 고유 스토리지 공간이 존재하며, 컨트랙트는 자체 스토리지 내에서만 읽고 쓰는 것이 가능하다. 스토리지 데이터는 블록체인에 영구적으로 저장되는 만큼 비용이 가장 높은 편에 속한다. 따라서, 대부분의 경우 스토리지는 어카운트 잔액(account balance), 컨트랙트 소유자 혹은 컨트랙트를 실행하는데 필요한 기타 정보 등 컨트랙트의 state을 저장할 때 사용된다. 스토리지는 32바이트의 2²⁵⁶개 슬롯으로 이루어져 있고, 모든 슬롯은 0의 값에서 시작한다. EVM은 스토리지와 상호 작용하기 위해 SLOAD(워드를 스토리지에서 스택으로 불러오기)와 SSTORE(워드를 스토리지에 저장) 두 가지 opcode를 제공한다 (OPCODE 앞에 S가 붙으면 스토리지, M이 붙으면 메모리다).

다음으로, 메모리는 컴퓨터의 RAM처럼 함수를 호출하는 동안에만 존재하는 임시 저장 공간이다. 메모리는 읽기 쓰기가 가능한 바이트 배열 데이터(byte-array data)로 구성되어 있으며 휘발성이기 때문에 메시지 호출을 할 때에는 항상 메모리를 비운 상태에서 시작한다. 메모리는 블록체인에 영구적으로 기록되지 않으므로 당연히 가스비가 스토리지보다 훨씬 저렴한 편이다. 이러한 특성 덕분에 메모리는 주로 함수 인수(function argument), 로컬 변수(local variables) 또는 함수 실행 도중 동적으로 생성되는 배열(array)과 같이 일시적으로 필요한 변수를 저장하는데 사용된다. EVM은 메모리와 상호 작용하기 위해 MLOAD(워드를 메모리에서 스택으로 불러오기), MSTORE(워드를 메모리에 저장), MSTORE8(바이트를 메모리에 저장) 총 세가지 opcode를 제공한다.

스택은 즉각적인 연산 과정에서 사용되는 초단기 저장 공간으로, 작은 로컬 변수(local variable)를 저장한다. 스택은 비용(가스비)이 가장 저렴하지만 동시에 크기 제한도 가장 작은 편이다 (최대 크기는 1,024 * 256 비트 = 262,144비트). 스택은 명령에 대한 매개 변수 및 연산 결과와 같이 연산 과정에서 작은 양의 데이터를 저장하는 데 사용된다. 사실 스택은 EVM 어셈블리(assembly)를 쓰지 않는 이상 솔리디티 컴파일러가 알아서 처리해주기 때문에 개발자 입장에서는 크게 신경 쓸 필요는 없다. 다만, EVM에서 POP, PUSH, DUP, SWAP과 같이 스택을 직접 수정할 수 있는 opcode들을 옵션으로 제공하고 있기는 하다.

참고로, 대부분의 경우 솔리디티는 변수들을 어디에 저장할지 알아서 결정한다. 개발자들이 스스로 저장 공간을 저장해야 하는 경우는 구조체(struct) 혹은 동적 배열(dynamic array)과 같이 데이터 타입이 복잡한 경우를 제외하고는 거의 없다.

2. 그 중 롤업이 사용하고 있는 공간은 콜데이터(Calldata)

마지막으로, EVM 데이터 저장 공간 중 EIP4844를 이해하는데 있어 가장 중요한 콜데이터다. 원래 콜데이터는 함수 인수, 그 중에서도 특히 view 혹은 pure 함수와 같이 state 변경을 요구하지 않는 함수들을 저장하는 공간이다. 콜데이터는 읽기 전용(read only)이며, 일적으로 함수 호출에 필요한 function selector와 인코딩된 매개변수(encoded parameters)를 포함하는 바이트 배열(byte array)이다. 따라서, 콜데이터는 주로 컨트랙트 간 외부 함수 호출을 수행할 때 사용된다.

콜데이터는 메모리와 유사하게 일시적이고 트랜잭션을 실행하는 동안에만 저장된다. 그렇다고 콜데이터내 모든 데이터가 삭제되는 것은 아니다. 콜데이터가 EVM에서 삭제되는 것은 맞지만 콜데이터를 포함하고 있는 트랜잭션 자체는 이더리움 블록에 포함되기 때문에 사실상 영구 저장이 된다. 다시 말해, 트랜잭션이 실행된 이후에는 EVM에서 롤업 데이터를 접근할 수는 없지만, 여전히 이더리움 블록체인에 기록되기 때문에 누구나 언제든 해당 데이터를 열람할 수 있다.

이렇듯 콜데이터는 1) 읽기 전용 특성으로 인해 사용료가 저렴하고 (zero byte는 4 gas/byte, non-zero byte는 16 gas/byte) 2) 데이터 크기 제한이 없어 큰 데이터 세트를 처리할 때 매우 유리하다. 롤업이 자체 블록 데이터를 이더리움에 저장할 때 콜데이터를 사용하고 있는 이유이기도 하다.

출처: 이더리움 황서