Paradigm: 이더리움 상태 증가의 도전과 해결책
작성: Storm Slivkoff, Georgios Konstantopoulos
번역: Luffy, Foresight News
이더리움 상태 증가와 가스 한도(Gas limit) 간의 관계는 널리 오해되어 왔다. 일반적으로 사람들은 상태 증가를 이더리움 확장의 주요 병목 요인으로 생각한다. 그러나 상태 증가에 대한 논의는 종종 용어의 불명확성과 정량적 근거 부족으로 인해 어려움을 겪고 있다.
데이터 기반 접근법은 상태 증가 문제를 훨씬 더 명확하게 해줄 수 있다. 본문에서는 고해상도 데이터셋을 활용하여 상태 증가의 규모와 형태를 이해하고자 한다. 이 과정에서 우리는 놀라운 결론에 도달했다: 현대 소비자용 하드웨어는 현재의 상태 증가율을 최소한 10년간 유지할 수 있다는 것이다. 게다가 소프트웨어와 하드웨어의 지속적인 개선을 고려하면, 이 기간은 무기한 연장될 수도 있다.
우리는 이더리움이 명확한 로드맵을 가지고 있다고 믿는다. 첫째, 상태 증가를 확장 병목 요인으로서 완전히 제거하는 것; 둘째, 전 세계 규모의 탈중앙화 금융 시스템을 지원할 수 있는 수준까지 가스 한도를 끌어올리는 것이다. 본 시리즈의 목적은 이러한 확장 로드맵을 이해하고 설계하기 위한 과학적 방법론을 개발하는 것이다.
본 문서는 이더리움 확장을 다루는 시리즈의 1부로, 상태 증가에 초점을 맞춘다. 2부는 역사적 증가, 3부는 상태 접근, 4부는 가스 한도에 관한 내용이다.
상태 증가란 무엇인가?
"상태 증가(state growth)"라는 표현은 보통 이더리움 노드 하드웨어의 용량을 초과하는 데이터 크기를 의미하는 포괄적인 용어로 사용된다. 그러나 상태 증가는 단일 차원의 개념으로만 이해해서는 안 된다. 이더리움에는 여러 유형의 데이터가 존재하며, 각각은 노드의 하드웨어 구성 요소와 독특한 관계를 갖는다. 따라서 각각의 확장 병목 현상을 설명하기 위해서는 정확한 용어 사용이 필수적이다.
상태란 새로운 이더리움 블록을 생성하고 검증하는 데 필요한 일련의 데이터를 말한다. 상태는 컨트랙트 바이트코드, 컨트랙트 저장소, 계정 잔고 및 논스(nonce)로 구성된다. 역사(historical data)란 노드가 창세 블록(genesis block)부터 최신 블록까지 동기화하기 위해 필요한 데이터 세트이며, 블록과 트랜잭션으로 이루어진다. 상태와 역사 데이터는 서로 겹치지 않는다. 이러한 정의를 바탕으로, 노드의 하드웨어에 부담을 주는 적어도 세 가지 다른 현상이 존재한다:
-
상태 증가: 새로운 계정, 새로운 컨트랙트 바이트코드, 새로운 컨트랙트 저장소의 축적.
-
역사 증가: 새로운 블록과 새로운 트랜잭션의 축적.
-
상태 접근: 블록 생성 및 검증을 위해 수행되는 일련의 읽기/쓰기 작업.
각 병목 현상은 노드의 하드웨어 제약과 고유한 관계를 가진다. 가장 관련성이 높은 네 가지 하드웨어 제약은 다음과 같다:
-
네트워크 I/O: 노드가 피어(peer)들과 안정적인 합의를 이루기 위해 유지해야 하는 업로드 및 다운로드 속도.
-
저장 용량: 블록 생성, 검증 및 배포를 위해 영구 저장 장치에 보관해야 하는 데이터 양.
-
메모리 용량: 블록체인 최신 부분과 동기화를 유지하기 위해 메모리에 캐싱해야 하는 데이터 양.
-
저장 I/O: 블록체인 최신 부분과 동기화를 유지하기 위해 초당 수행해야 하는 읽기/쓰기 작업 수.
이러한 병목 현상과 하드웨어 제약 사이의 관계는 그림 1에 나타나 있다.
그림 1: 이더리움 확장 병목 요인
위쪽에서 시작하자면, 이더리움에서 트랜잭션이 실행될 때마다 해당 트랜잭션이 사용하는 모든 자원은 가스 단위로 가격이 책정된다. 따라서 이더리움의 가스 한도는 모든 형태의 체인 상 활동을 속도 제한하는 단일 차원의 값이다. 가스 한도의 결과로서 블록 크기와 블록당 연산 수가 결정된다. 블록당 바이트 수가 많을수록 역사 데이터는 더 빠르게 증가한다. 블록당 I/O 연산 수가 많을수록 상태 접근률이 높아지고(보통은) 상태 증가율도 커진다.
따라서 확장 병목 요인은 다음과 같이 노드의 하드웨어 제약과 관련된다:
-
상태 증가를 지원하려면 노드에 충분한 저장 공간과 메모리가 필요하다. 상태가 너무 커지면 저장 공간에 담을 수 없거나, 자주 접근하는 상태 부분이 메모리에 담기지 않아 성능 저하가 발생할 수 있다.
-
역사 증가를 지원하려면 노드에 큰 블록 데이터를 공유할 수 있는 충분한 네트워크 대역폭과 이를 저장할 수 있는 저장 용량이 필요하다.
-
상태 접근을 지원하려면 핫 상태(hot state)를 캐싱할 수 있는 많은 메모리와 충분한 읽기/쓰기 연산을 처리할 수 있는 높은 저장 I/O 성능이 필요하다.
특히 상태 증가의 경우, 주요 과제는 상태 규모의 성장 속도가 소비자용 하드웨어의 지속적인 개선 속도를 초과하지 않도록 보장하는 것이다. 노드의 메모리와 저장 공간은 제한된 자원이므로, 상태 증가가 멈추거나 하드웨어가 정기적으로 업그레이드되지 않는 한 결국 병목에 도달하게 된다. 다행히도 메모리와 저장 장치는 오랫동안 꾸준히 개선되어 왔다. 하지만 이러한 개선의 정확한 예측은 여전히 불확실하며, 무한정 빠른 성장을 기대할 수는 없다.
다가오는 EIP-4844는 이러한 확장 관계에 일부 변화를 가져올 것이다. EIP-4844 이후 디스크에 누적되는 역사 데이터는 훨씬 줄어들 것으로 예상되며, 대량의 Blob 데이터 전송 시 네트워크 I/O 부담이 크게 증가할 수 있다.
본문에서는 상태 크기와 상태 증가율에 집중하며, 메모리 크기나 상태 접근 패턴 등 다른 요소는 추후 연구 과제로 남긴다.
이더리움 상태의 구성
상태 증가를 이해하기 위한 다음 단계는 전체 상태 규모와 각 구성 요소의 비중을 분석하는 것이다. 현재 이더리움 상태 데이터는 약 245.5GB이다. 이 수치는 reth 노드에서 측정된 것이지만, 표에서 보듯 각 노드 클라이언트 간의 수치는 대략적으로 비교 가능하다. 계정, 컨트랙트 바이트코드, 컨트랙트 저장소는 각각 상태의 14.1%, 4.3%, 81.7%를 차지한다.
그림 2는 다양한 스마트 컨트랙트 프로토콜이 상태의 어느 정도를 차지하는지를 보여준다. 아래 그래프에서 각 컨트랙트 범주의 크기는 해당 컨트랙트의 스토리지 슬롯과 바이트코드가 차지하는 바이트 수를 의미한다.
그림 2: 이더리움 상태 분포
그림 2의 숫자는 노드 클라이언트가 디스크에 저장해야 하는 총 바이트 수를 나타낸다. 여기에는 인덱스용 데이터와 기타 저장 오버헤드도 포함된다. 각 계정과 각 스토리지 슬롯의 평균 저장 크기는 각각 133.6바이트와 191.3바이트이다.
그림 2에서 얻을 수 있는 중요한 정보는 다음과 같다:
-
토큰이 상태의 가장 큰 기여자이다. 이더리움 상태에서 가장 큰 부분을 차지하는 것은 ERC-20과 ERC-721 토큰으로, 각각 27.2%, 21.6%를 차지한다. 토큰이 이렇게 많은 상태를 차지하는 이유는 각 토큰의 사용자 잔고가 모두 별도의 32바이트 스토리지 슬롯에 저장되어야 하기 때문이다. 따라서 이더리움 상태의 절반은 사용자 수와 각 사용자가 보유한 토큰 수에 비례한다.
-
이더리움 상태의 적어도 7.4%는 비활성 상태이다. 상태에서 가장 큰 컨트랙트 중 일부는 더 이상 활성화되지 않는다. 당시 블록 공간과 상태 공간이 지금보다 훨씬 저렴했기에, 게임, 도박, 사기 프로토콜뿐 아니라 IDEX, Etherdelta, Oasis 등 더 이상 운영되지 않는 DEX들도 많다. 이러한 프로토콜들이 이더리움 상태의 최소 7.4%를 차지한다. 실제 비활성 상태의 비율은 더 높을 수 있으며, 이는 ERC-20, ERC-721 및 기타 카테고리의 장미효과(long tail) 항목도 포함되기 때문이다.
-
L2 크로스체인 브릿지(cross-chain bridge)는 이더리움 상태의 2% 미만을 차지한다. 압축, 제로지식 증명(ZK proof), 개선된 인코딩 등의 기술을 활용함으로써 L2 거래는 메인넷보다 훨씬 효율적으로 상태를 사용한다. L2가 메인넷 상태의 2%만 차지하지만, L2의 초당 총 트랜잭션 수는 메인넷보다 5배 이상 많다.
이더리움 상태 증가는 얼마나 빠른가?
상태 증가에서 가장 중요한 측면은 시간에 따른 상태 증가율의 변화이다. 이 비율은 상태 문제의 심각성과 그 변화 추세를 드러낸다.
그림 3은 2015년 이더리움 출범 이후 상태 증가율을 보여준다. 이 증가율은 각 컨트랙트 범주 내 컨트랙트 바이트코드와 저장소를 합산하여 계산되었다.
그림 3: 시간에 따른 이더리움 상태 증가
그림 3에서 얻을 수 있는 중요한 정보는 다음과 같다:
-
현재 상태는 매월 약 2.62GB 증가하고 있으며, 이는 월 5.99GB의 최고점보다 낮다. 이 수치를 기반으로 5년 후 상태 총량은 396GB에서 606GB 사이가 될 것으로 예측된다. 현재 증가율을 연간 12.8%라고 설명할 수 있지만, 상태는 계속 증가하고 있음에도 불구하고 절대 증가율은 감소하고 있으므로 단순한 지수 성장 모델은 적절하지 않을 수 있다.
-
최근 상태 증가의 감소는 주로 NFT 활동 감소 때문이었다. 다양한 네트워크 활동 간에는 어느 정도 상관관계가 있을 것으로 기대할 수 있지만, 각 상태 기여자들 간에는 놀랍도록 독립적인 경향이 있다. 예를 들어, 지난 몇 년간 총 상태 증가율은 감소했지만, ERC-20 상태 증가율은 2020년 이후 오히려 매년 증가하고 있다.
-
상태 증가는 2021년 이후 가장 낮은 수준에 도달했다. 이 감소는 다소 놀라운 일이지만, 상태가 주로 새 토큰 잔고와 비례한다는 점을 고려하면 이해할 수 있다. 만약 상태 증가율이 계속 감소한다면, 이더리움이 더 높은 가스 한도를 지원할 수 있다고 생각할 수 있다. 사실일 수 있지만, 다음 두 가지를 기억해야 한다: 1) 현재의 가스 가격 모델 하에서는 증가율이 다시 급등할 가능성은 언제든지 열려 있고, 2) 상태는 가스 한도 하류의 유일한 병목 요인이 아니다.
허용 가능한 상태 증가 수준은 얼마인가?
이제 우리는 이더리움 상태의 1) 규모, 2) 구성, 3) 증가율을 알게 되었다. 그렇다면 허용 가능한 상태 증가 수준의 범위는 어떻게 결정할 수 있을까? 이 질문은 매우 복잡하다. 왜냐하면 예측 불가능한 시장 역학뿐만 아니라 이더리움이 어떤 타협을 해야 할지에 대한 철학적 선택에도 달려 있기 때문이다.
가장 간단한 모델부터 시작해보자. 미래의 하드웨어 개선이 없다고 가정하고, 현재 상태 증가율이 일반적인 소비자용 하드웨어에서 얼마나 오래 지속될 수 있는지 살펴보자. 그림 3에서 보듯, 최근 몇 년간 상태의 연간 증가율은 31GB/년에서 72GB/년 사이였다. 현재 일반적인 소비자용 하드웨어의 최대 저장 용량은 약 4TB, 메모리는 약 64GB 정도이다. 이를 바탕으로 간단한 저장 및 메모리 수요 예측 모델을 만들 수 있다:
-
저장 공간: 노드는 현재 상태 데이터로 약 1TB를 저장해야 한다. 실제로는 많은 노드가 최소 2TB 이상의 디스크를 사용하고 있다. 단순화를 위해 역사 데이터 증가는 무시하자. 마치 우리가 이미 EIP-4444 이후의 세계에 있는 것처럼 말이다. 그러면 (남은 저장 용량) / (상태 증가율)로 미래 운영 가능 시간을 계산할 수 있으며, 표에 나와 있다. 따라서 현재 상태 증가율이라면 노드 저장 하드웨어는 2TB 공간이 소진되기 전까지 10년 이상 버틸 수 있다. 현재 증가율 기준으로 4TB는 거의 반세기 동안 충분하다.
-
메모리: Ethereum-on-arm 사용자들은 이더리움 노드를 실행하기 위한 최소한의 메모리가 약 16GB 정도라고 보고한다. 메모리 수요가 상태 크기와 비례한다고 가정하면, 연간 30GB~72GB의 상태 증가는 연간 2GB~4.7GB의 추가 메모리를 필요로 한다. 따라서 현재 가스 수준에서 32GB RAM은 3~8년, 64GB RAM은 10~23년간 충분하다.
이 모델은 많은 가정을 포함한 단순화된 것이다. 확장 가능한 조건으로는 1) 역사 증가, 2) 메모리 수요의 비선형적 증가, 3) 하드웨어 비용 감소, 4) 가스 한도 증가, 5) 오퍼코드 가스 재가격, 6) 미래의 이더리움 아키텍처 개선 등이 있다. 이러한 요소들은 서로 비선형적으로 상호작용하며 시간이 지남에 따라 변화할 수 있다. 이러한 모델 확장은 추후 연구에서 다룰 예정이다.
장기적 지속 가능성은 좋은 일이지만, 현대 하드웨어가 수년간 작동 가능하다고 해서 안심해서는 안 된다. 상태 증가를 가속화하는 모든 계획은 하드웨어나 소프트웨어 환경의 예측 불가능한 변화에 대비한 충분한 여유를 포함해야 한다.
상태 증가 문제는 어떻게 해결할 수 있는가?
상태 증가 문제를 해결하기 위해 여러 가지 방안이 제안되었다. 특히 이더리움 아키텍처의 세 가지 개선이 두드러진다: 롤업(Rollup), 베르클 트라이(verkle trie), 상태 만료(state expiry). 이 세 가지는 단기, 중기, 장기적인 상태 증가 문제를 해결하는 종합적 로드맵을 구성한다.
단기: 롤업은 상태 증가 문제 자체를 해결하지는 않지만, 네트워크 부담을 완화한다. 그림 2와 3에서 보듯, 롤업은 메인넷보다 훨씬 효율적으로 상태를 활용한다. L2로 활동을 이전하려면 메인넷에 사용자 출금을 지원하기 위한 일정량의 상태를 저장해야 한다. 그러나 L2 거래의 상태 발자국은 메인넷 거래보다 훨씬 작다. 따라서 롤업은 생태계의 총 활동량을 더 지속 가능하게 늘릴 수 있다. 곧 출시될 EIP-4844 덕분에 롤업 채택은 더욱 증가할 것이며, blob은 롤업을 더욱 저렴하게 만들 것이다.
중기: 베르클 트라이는 검증 노드의 상태 증가 문제를 해결하지만, 새 트랜잭션을 생성하는 노드의 문제는 해결하지 않는다. 베르클 트라이는 이더리움 상태를 위한 새로운 데이터 구조로, 더 효율적인 라이트 클라이언트와 '무상태(stateless)' 노드를 지원한다. 이러한 노드는 기존 상태 값을 알지 못하더라도 새로운 블록을 검증할 수 있게 된다. 이는 검증 노드의 상태 증가 문제를 제거한다. 새 트랜잭션 생성은 여전히 상태 저장과 접근을 필요로 하지만, 이 작업은 여러 머신에 쉽게 분산될 수 있기 때문에 오늘날보다 훨씬 지속 가능하다. 범위 측면에서 보면, 베르클 트라이는 수년이 걸릴 수 있는 대규모 엔지니어링 프로젝트이다.
장기: 상태 만료는 모든 노드의 상태 증가 문제를 해결하지만, 추가 인프라가 필요하다. 상태 만료는 노드가 비활성 상태 부분을 삭제할 수 있도록 한다(그림 2 참조). '상태 휴면(sleeping state)'이라는 용어가 더 적절할 수 있는데, 대부분의 기존 제안은 '만료된' 상태를 증명을 통해 복구할 수 있기 때문이다. 시간이 지남에 따라 만료된 상태가 소실될 우려가 있지만, 역사 데이터(블록 및 트랜잭션)가 유지된다면 상태는 재구성 가능하다. 따라서 EIP-4444의 역사 보존 문제를 해결하는 어떤 솔루션이든, 상태 보존 문제 또한 함께 해결할 것이다. 그러나 베르클 트라이가 목표를 달성한다면 상태 만료는 불필요해질 수 있다.
상태 증가 문제의 해결책은 더 많으며, 상태 임대(state rent)와 샤딩(sharding)도 포함된다. 그러나 역사적으로 이러한 방안은 사용자 경험 또는 시스템 건전성에 부정적 영향을 줄 수 있다. 먼 미래의 궁극적 해결책을 위해서는 이러한 방안들을 다른 방안들과 결합해야 할 수도 있다.
결론
상태 증가는 이더리움 확장의 핵심 과제이지만, 우리는 이를 해결할 수 있는 문제라고 믿는다. 우리의 데이터 해석에 따르면, 이더리움은 현재의 상태 증가율을 수년간 유지할 수 있으며, 아키텍처 업그레이드를 위한 충분한 여유를 제공한다.
가스 한도 설계와 이더리움의 궁극적 확장 해결책을 위한 가이드라인 설정에는 경험적 접근법이 중요하다고 믿는다. 본문은 그 목표를 향한 첫걸음일 뿐이다. 상태 외에도 이더리움 노드와 가스 한도에 부담을 주는 다른 유형의 데이터가 존재한다. 앞으로 이러한 다른 병목 요인들도 탐구하고자 한다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
Paradigm
