Paradigm: 이더리움의 역사적 성장 문제와 그 해결책을 자세히 설명
저자: Storm Slivkoff, Georgios Konstantopoulos
번역: Luffy, Foresight News
히스토리 증가는 현재 이더리움 확장성의 가장 큰 병목 현상이다. 놀랍게도 히스토리 증가는 상태 증가보다 더 큰 문제가 되었다. 몇 년 안에 히스토리 데이터는 많은 이더리움 노드의 저장 용량을 초과하게 될 것이다.
좋은 소식은 다음과 같다:
-
히스토리 증가는 상태 증가보다 해결하기 더 쉬운 문제다.
-
해결책이 이미 활발히 개발 중이다.
-
히스토리 증가 문제를 해결하면 상태 증가 문제도 완화된다.
이 글에서는 제1부에서 다룬 이더리움 확장성 문제를 계속 다루며, 이제 관심을 상태 증가에서 히스토리 증가로 옮긴다. 정교한 데이터셋을 사용하여 우리의 목표는 1) 기술적으로 이더리움의 확장성 병목 현상을 이해하고, 2) 이더리움 Gas 한도의 최적값을 둘러싼 논의를 돕는 것이다.
히스토리 증가는 무엇인가?
히스토리는 이더리움이 출범 이후 전 생애 동안 실행한 모든 블록과 트랜잭션의 집합이며, 창세 블록부터 현재 블록까지의 모든 데이터를 의미한다. 히스토리 증가는 시간이 지남에 따라 새로운 블록과 트랜잭션이 누적되는 과정이다.
그림 1은 히스토리 증가와 다양한 프로토콜 지표 및 이더리움 노드 하드웨어 제약 간의 관계를 보여준다. 상태 증가와 비교할 때, 히스토리 증가는 다른 일련의 하드웨어 제약에 의해 제한된다. 히스토리 증가는 네트워크 전체에 새 블록과 트랜잭션을 전파해야 하므로 네트워크 I/O에 부담을 준다. 또한 각 이더리움 노드가 전체 히스토리 사본을 저장하므로 노드의 저장 공간에도 부담을 준다. 히스토리 증가 속도가 이러한 하드웨어 제약을 초과할 정도로 빠르면 노드는 더 이상 피어들과 안정적인 합의를 달성할 수 없게 된다. 상태 증가 및 기타 확장성 병목 현상에 대한 개요는 본 시리즈의제1부를 참조하라.
그림 1: 이더리움 확장성 병목 현상
최근까지 각 노드의 대부분의 네트워크 처리량은 히스토리(예: 새 블록 및 트랜잭션) 전송에 사용되었다. 덴쿤(Dencun) 하드포크에서 도입된 blob으로 상황이 바뀌었다. blob은 이제 노드의 네트워크 활동에서 상당한 부분을 차지한다. 그러나 blob은 다음 두 가지 이유로 히스토리의 일부로 간주되지 않는다. 1) 노드가 오직 2주간만 저장한 후 폐기하며, 2) 이더리움 창세 이후의 데이터를 반복할 필요가 없다. (1) 때문에 blob은 각 이더리움 노드의 저장 부담을 크게 늘리지 않는다. 우리는 이 글 후반부에서 blob에 대해 논의할 것이다.
이 글에서는 히스토리 증가에 초점을 맞추고 히스토리와 상태 사이의 관계를 논의할 것이다. 상태 증가와 히스토리 증가는 일부 중복되는 하드웨어 제약을 공유하므로 관련된 문제이며, 하나의 문제를 해결하면 다른 문제도 도움이 된다.
히스토리 증가는 얼마나 빠른가?
그림 2는 이더리움 창세 이후 히스토리 성장률을 보여준다. 각 수직선은 한 달의 증가분을 나타낸다. y축은 해당 월의 히스토리 증가량을 기가바이트 단위로 표시한다. 트랜잭션은 '대상 주소'에 따라 분류되며 RLP 바이트 표현으로 크기를 측정한다. 쉽게 식별할 수 없는 계약은 '미지'로 분류된다. '기타' 범주는 인프라 및 게임 등 여러 소규모 카테고리를 포함한다.
그림 2: 시간에 따른 이더리움 히스토리 성장률 변화
위 차트에서 얻을 수 있는 주요 포인트들:
-
히스토리 증가 속도는 상태 증가보다 6~8배 빠르다: 최근 히스토리 증가 속도는 최고 36.0GiB/월에 달했으며, 현재는 19.3GiB/월이다. 상태 증가 속도는 약 6.0GiB/월의 최고치를 기록했으며 현재는 2.5GiB/월이다. 히스토리와 상태의 성장 및 누적 크기 비교는 이 글 후반부에서 다룰 것이다.
-
덴쿤 이전까지 히스토리 성장률은 가속화되고 있었다: 상태는 수년간 대체로 선형 증가 추세를 보였지만(제1부 참조), 히스토리는 비선형적으로 증가했다. 선형 증가율은 전체 규모를 제곱 함수적으로 증가시키므로, 비선형 증가율은 제곱 이상의 속도로 전체 규모를 증가시킨다. 이러한 가속화는 덴쿤 이후 갑작스럽게 멈췄다. 이는 이더리움이 히스토리 성장률의 급격한 감소를 경험한 첫 번째 사례다.
-
최근 히스토리 증가의 대부분은 롤업에서 발생했다: 각 L2는 자신의 트랜잭션 사본을 메인넷에 다시 게시한다. 이는 방대한 양의 히스토리를 생성하며, 지난 1년간 롤업이 히스토리 증가의 가장 중요한 기여자가 되게 했다. 그러나 덴쿤은 L2가 히스토리가 아닌 blob을 이용해 트랜잭션 데이터를 게시할 수 있도록 했으므로, 롤업은 더 이상 이더리움 히스토리의 대부분을 생성하지 않게 되었다. 롤업에 대해서는 이 글 후반부에서 자세히 설명하겠다.
이더리움 히스토리 증가에 가장 크게 기여하는 것은 무엇인가?
다양한 계약 유형이 생성하는 히스토리의 양은 시간이 지남에 따라 이더리움 사용 패턴이 어떻게 진화해왔는지를 드러낸다. 그림 3은 다양한 계약 유형의 상대적 기여도를 보여준다. 이것은 그림 2와 동일한 데이터를 표준화한 것이다.
그림 3: 다양한 계약 유형의 히스토리 증가 기여도
이 데이터는 이더리움 사용 패턴의 네 가지 서로 다른 시기를 보여준다:
-
초기(보라색): 이더리움 초기 몇 년간은 거의 체인 상의 활동이 없었다. 이 초기 계약 대부분은 현재 식별하기 어려우며 그래프에서는 '미지'로 표시된다.
-
ERC-20 시대(녹색): ERC-20 표준은 2015년 말에 마무리되었지만, 2017년과 2018년에야 비로소 눈에 띄게 발전했다. ERC-20 계약은 2019년 히스토리 증가의 가장 큰 원천이 되었다.
-
DEX / DeFi 시대(갈색): DEX 및 DeFi 계약은 2016년부터 체인 상에 등장했으며 2017년부터 관심을 받기 시작했다. 하지만 2020년 DeFi 여름이 되어서야 히스토리 증가의 가장 큰 범주가 되었다. DeFi 및 DEX 계약은 2021년과 2022년 일부 기간 동안 히스토리 증가의 50% 이상을 차지했다.
-
롤업 시대(회색): 2023년 초, L2 롤업은 메인넷보다 더 많은 트랜잭션을 처리하기 시작했다. 덴쿤 이전 몇 달 동안 롤업은 이더리움 히스토리의 약 2/3을 생성했다.
각 시기는 이전보다 더 복잡한 이더리움 사용 패턴을 나타낸다. 시간이 지남에 따라 복잡성은 초당 트랜잭션 수 같은 단순 지표로는 측정할 수 없는 이더리움 확장의 한 형태로 볼 수 있다.
최근 데이터 월(2024년 4월)에는 롤업이 더 이상 대부분의 히스토리를 생성하지 않는다. 앞으로의 히스토리가 DEX 및 DeFi에서 비롯될지, 아니면 새로운 사용 패턴이 등장할지는 아직 불확실하다.
그럼 blob은 어떠한가?
덴쿤 하드포크는 blob을 도입함으로써 히스토리 증가 역학을 크게 변화시켰다. 이를 통해 롤업은 히스토리가 아닌 저렴한 blob을 사용해 데이터를 게시할 수 있게 되었다. 그림 4는 덴쿤 업그레이드 전후의 히스토리 성장률을 확대해서 보여준다. 이 그래프는 그림 2와 유사하지만 각 수직선이 한 달이 아니라 하루를 나타낸다는 점이 다르다.
그림 4: 덴쿤이 히스토리 증가에 미친 영향
이 차트로부터 다음과 같은 주요 결론을 도출할 수 있다:
-
덴쿤 이후 롤업의 히스토리 증가량은 약 2/3 감소했다: 대부분의 롤업이 call data에서 blob으로 전환함에 따라 생성하는 히스토리 양이 크게 줄었다. 그러나 2024년 4월 기준으로 일부 롤업은 아직 call data에서 blob으로 전환하지 않았다.
-
덴쿤 이후 총 히스토리 증가량은 약 1/3 감소했다: 덴쿤은 롤업의 히스토리 증가만 낮췄다. 다른 계약 유형의 히스토리 증가는 약간 증가했다. 덴쿤 이후에도 히스토리 증가는 상태 증가의 8배에 달한다(자세한 내용은 다음 섹션 참조).
blob이 히스토리 증가 속도를 낮췄음에도 불구하고, 이는 이더리움의 새로운 기능이다. blob이 존재하는 상황에서 히스토리 증가 속도가 어떤 수준에서 안정화될지는 아직 불확실하다.
얼마나 빠른 히스토리 증가가 허용 가능한가?
Gas 한도를 올리면 히스토리 증가율이 증가한다. 따라서 Gas 한도 증가 제안(예: Pump the Gas)은 히스토리 증가와 각 노드의 하드웨어 병목 사이의 관계를 고려해야 한다.
수용 가능한 히스토리 증가율을 결정하기 위해 먼저 현재 노드 하드웨어가 네트워크와 저장 면에서 얼마나 오래 버틸 수 있는지 이해해야 한다. 연결 하드웨어는 Gas 한도를 늘리기 전까지는 히스토리 증가율이 덴쿤 이전의 최고치로 돌아가기 어려우므로 무기한 유지 가능할 수 있다. 그러나 히스토리의 저장 부담은 시간이 지남에 따라 계속 증가한다. 현재의 저장 전략 하에서는 각 노드의 저장 디스크가 결국 히스토리로 가득 차게 되며, 이는 불가피하다.
그림 5는 시간이 지남에 따라 이더리움 노드의 저장 부담을 보여주며, 미래 3년간의 저장 부담 증가를 예측한다. 예측은 2024년 4월의 증가율을 기준으로 한다. 향후 사용 패턴이나 Gas 한도의 변화에 따라 이 증가율은 상승하거나 하락할 수 있다.
그림 5: 히스토리, 상태 및 전체 노드 저장 부담의 크기
이 그래프에서 다음과 같은 주요 결론을 도출할 수 있다:
-
히스토리는 상태의 약 3배 저장 공간을 차지한다. 히스토리 증가 속도가 상태의 약 8배이므로 이 차이는 시간이 지남에 따라 더욱 커질 것이다.
-
1.8TiB는 임계값으로, 많은 노드가 저장 디스크를 업그레이드해야 하는 지점이다. 2TB는 일반적인 저장 디스크 크기지만 실제로는 1.8TiB의 사용 가능한 공간만 제공한다. TB(1조 바이트)와 TiB(=1024^4 바이트)는 서로 다른 단위임을 주의하라. 합의 클라이언트를 실행 클라이언트와 함께 실행해야 하는 검증인의 경우 '실제' 임계값은 훨씬 더 낮을 수 있다.
-
임계값은 2~3년 내에 도달할 것이다. Gas 한도를 어느 정도 증가시키든 그 도달 시점을 앞당길 것이다. 이 임계값에 도달하면 노드 운영자에게 상당한 유지 보수 부담이 발생하며 추가 하드웨어(예: 300달러짜리 NVMe 드라이브) 구매가 필요하다.
상태 데이터와 달리 히스토리 데이터는 추가 전용이며 접근 빈도가 훨씬 낮다. 따라서 이론적으로 히스토리 데이터를 상태 데이터와 분리하여 더 저렴한 저장 매체에 보관할 수 있다. 이는 Geth 등의 일부 클라이언트를 통해 가능하다.
저장 용량 외에도 네트워크 I/O는 히스토리 증가의 또 다른 주요 제약이다. 저장 용량과 달리 네트워크 I/O 제약은 단기간 내에 노드에 문제를 일으키지 않지만, 향후 Gas 한도 증가에는 중요해진다.
표준 이더리움 노드의 네트워크 용량이 얼마나 많은 히스토리 증가를 감당할 수 있는지 이해하려면 히스토리 증가와 재구성률, 슬롯 누락, 최종 누락, 증명 누락, 동기화 위원회 누락, 블록 제출 지연 등의 다양한 네트워크 건강 지표 사이의 관계를 알아야 한다. 이러한 지표의 분석은 본 문서의 범위를 넘어서지만, 이전의 컨센서스 레이어 건강 조사에서 더 많은 정보를 찾을 수 있다. 또한 이더리움 재단의 Xatu 프로젝트는 그러한 분석을 가속화하기 위해 공개 데이터 세트를 지속적으로 구축하고 있다.
히스토리 증가 문제는 어떻게 해결할 수 있는가?
히스토리 증가는 상태 증가보다 훨씬 쉽게 해결할 수 있는 문제다. 사실상 후보 제안 EIP-4444로 거의 완전히 해결할 수 있다. 이 EIP는 각 노드가 전체 이더리움 히스토리를 저장하는 것에서 1년 치 히스토리만 저장하도록 변경한다. EIP-4444 시행 후 저장은 더 이상 이더리움 확장의 병목이 되지 않으며, 장기적으로 Gas 한도 증가도 더 이상 제약받지 않는다. EIP-4444는 네트워크의 장기적 지속 가능성에 필수적이며, 그렇지 않으면 히스토리 증가 속도가 너무 빨라 네트워크 노드의 하드웨어를 정기적으로 업데이트해야 하기 때문이다.
그림 6은 향후 3년 동안 EIP-4444가 각 노드의 저장 부담에 미치는 영향을 보여준다. 그림 4와 동일하지만, EIP-4444 시행 후 저장 부담을 나타내는 더 연한 선이 추가되었다.
그림 6: EIP-4444가 이더리움 노드 저장 부담에 미치는 영향
이 그래프에서 다음과 같은 주요 결론을 도출할 수 있다:
-
EIP-4444는 현재 저장 부담을 절반으로 줄인다. 저장 부담은 1.2TiB에서 633GiB로 감소한다.
-
EIP-4444는 히스토리 저장 부담을 안정화시킨다. 히스토리 증가율이 일정하다고 가정하면, 히스토리 데이터는 생성되는 속도로 폐기된다.
-
EIP-4444 이후 노드 저장 부담은 오늘날의 수준에 도달하기까지 수년이 걸릴 것이다. 상태 증가가 저장 부담 증가의 유일한 요인이 되고, 상태 증가 속도는 히스토리 증가보다 느리기 때문이다.
EIP-4444 시행 후에도 히스토리 증가는 여전히 일정 수준의 저장 부담을 남긴다. 노드는 1년 치 히스토리를 저장하기 때문이다. 그러나 이더리움이 세계 규모에 도달하더라도 이 부담은 해결하기 어렵지 않다. 일단 히스토리 보존 방법이 신뢰할 수 있음이 입증되면, EIP-4444의 1년 만료 기간은 수개월, 수주 또는 그보다 더 짧게 단축될 수 있다.
이더리움 히스토리는 어떻게 보존해야 하는가?
EIP-4444는 히스토리를 이더리움 노드 자체가 보관하지 않는다면 어떻게 보관해야 하는가라는 질문을 제기한다. 히스토리는 이더리움의 검증, 회계 및 분석에서 핵심적인 역할을 하므로 히스토리 보존은 매우 중요하다. 다행히 히스토리 보존은 단순한 문제이며, 단지 1/n의 정직한 데이터 제공자만 필요하다. 이는 1/3~2/3의 참여자가 정직해야 하는 상태 합의 문제와 극명하게 대비된다. 노드 운영자는 1) 창세 블록 이후 모든 트랜잭션을 재실행하고 2) 이 트랜잭션들이 현재 블록체인 끝과 동일한 상태 루트를 재현하는지 확인함으로써 히스토리 데이터 세트의 진위를 검증할 수 있다.
히스토리를 보존하는 방법은 다양하다.
-
Torrents/P2P: Torrent는 가장 간단하고 신뢰할 수 있는 방법이다. 이더리움 노드는 정기적으로 일부 히스토리를 묶어 공개 Torrent 파일로 공유할 수 있다. 예를 들어, 노드는 10만 블록마다 새로운 히스토리 Torrent 파일을 만들 수 있다. erigon과 같은 노드 클라이언트는 이미 비표준적인 방식으로 이 과정을 부분적으로 수행하고 있다. 이 과정을 표준화하기 위해 모든 노드 클라이언트는 동일한 데이터 형식, 동일한 매개변수, 동일한 P2P 네트워크를 사용해야 한다. 노드는 저장 및 대역폭 능력에 따라 이 네트워크에 참여할지 여부를 선택할 수 있다. Torrent의 장점은 이미 방대한 데이터 도구가 지원하는 고도로 검증된(open standard) 표준을 사용한다는 점이다.
-
Portal Network: Portal Network는 이더리움 데이터 호스팅을 위해 설계된 새로운 네트워크다. 이는 Torrent와 유사한 접근법이지만 데이터 검증을 더 쉽게 만드는 추가 기능을 제공한다. Portal Network의 장점은 이러한 추가 검증 계층이 경량 클라이언트에게 유틸리티를 제공하여 공유 데이터 세트를 효과적으로 검증하고 조회할 수 있다는 점이다.
-
클라우드 호스팅: AWS S3 또는 Cloudflare R2와 같은 클라우드 저장 서비스는 히스토리 보존을 위한 저렴하고 고성능의 선택지를 제공한다. 그러나 이러한 클라우드 서비스가 항상 암호화폐 데이터를 호스팅할 의향과 능력을 가질 것이라는 보장이 없으므로 이 방법은 더 많은 법적 리스크와 사업 운영 리스크를 수반한다.
나머지 구현 과제들은 더 기술적이라기보다 사회적 도전이다. 이더리움 커뮤니티는 각 노드 클라이언트에 직접 통합할 수 있도록 구체적인 구현 세부사항을 조율해야 한다. 특히 창세 블록부터 완전 동기화(스냅샷 동기화가 아님)를 수행하려면 이더리움 노드가 아닌 히스토리 제공자로부터 히스토리를 검색해야 한다. 이러한 변경은 기술적으로 하드포크를 필요로 하지 않으므로 이더리움의 다음 하드포크인 Pectra보다 먼저 구현될 수 있다.
이러한 모든 히스토리 보존 방법은 L2가 메인넷에 게시한 blob 데이터를 보존하는 데에도 활용할 수 있다. 히스토리 보존과 비교할 때 blob 보존은 1) 총 데이터량이 훨씬 많아 더 어렵고, 2) 메인넷 히스토리 재생에 필수적이지 않아 중요성이 낮다. 그러나 각 L2가 자신의 히스토리를 재생하려면 blob 보존이 여전히 필요하다. 따라서 어떤 형태의 blob 보존은 전체 이더리움 생태계에 중요하다. 또한 L2가 강력한 blob 저장 인프라를 개발한다면, L1 히스토리 데이터 저장도 쉽게 할 수 있을 것이다.
EIP-4444 시행 전후 다양한 노드 구성이 저장하는 데이터 세트를 직접 비교하는 것이 도움이 될 것이다. 그림 7은 다양한 이더리움 노드 유형의 저장 부담을 보여준다. 상태 데이터는 계정과 계약이며, 히스토리 데이터는 블록과 트랜잭션이고, 아카이브 데이터는 선택적 데이터 인덱스 집합이다. 이 표의 바이트 수는 최근 reth 스냅샷을 기반으로 하지만 다른 노드 클라이언트의 숫자도 대략적으로 유사할 것이다.
그림 7: 다양한 이더리움 노드 유형의 저장 부담
즉,
-
아카이브 노드는 상태 데이터, 히스토리 데이터 및 아카이브 데이터를 모두 저장한다. 역사적 체인 상태를 쉽게 조회할 수 있어야 할 때 아카이브 노드를 사용할 수 있다.
-
풀 노드는 히스토리 데이터와 상태 데이터만 저장한다. 오늘날 대부분의 노드가 풀 노드다. 풀 노드의 저장 부담은 아카이브 노드의 약 절반이다.
-
EIP-4444 이후 풀 노드는 상태 데이터와 최근 1년간의 히스토리 데이터만 저장한다. 이는 노드의 저장 부담을 1.2TiB에서 633GiB로 줄이며 히스토리 저장 공간을 안정된 상태 값으로 유지한다.
-
스테이트리스 노드(stateless node), 즉 '경량 노드(light node)'는 어떤 데이터 세트도 저장하지 않고 체인 끝에서 즉시 검증할 수 있다. Verkle 트라이 또는 기타 상태 커밋 방식이 이더리움에 추가되면 이러한 노드 유형이 가능해진다.
마지막으로, 현재 증가율에 적응하는 것뿐 아니라 히스토리 증가율 자체를 제한할 수 있는 추가 EIP들이 있다. 이는 단기적으로 네트워크 I/O 제약 내에 머무르는 데 도움이 되며, 장기적으로는 저장 제약 내에 머무르는 데 도움이 된다. 비록 EIP-4444가 네트워크의 장기적 지속 가능성에 여전히 필수적이지만, 이러한 다른 EIP들은 이더리움이 미래에 더 효율적으로 확장하는 데 도움이 될 것이다:
-
EIP-7623: call data 재정가. 일부 call data를 과도하게 사용하는 트랜잭션을 더 비싸게 만든다. 이러한 사용 패턴을 더 비싸게 만들어 일부를 call data에서 blob으로 전환하도록 강제한다. 이는 히스토리 증가율을 낮춘다.
-
EIP-4488: 각 블록에 포함될 수 있는 call data 총량에 제한을 둔다. 이는 히스토리 증가 속도에 더 엄격한 제한을 가한다.
이러한 EIP는 EIP-4444보다 구현하기 더 쉬우므로 EIP-4444가 본격 적용되기 전까지 단기적인 임시 조치로 채택될 수 있다.
맺음말
이 글의 목적은 데이터를 통해 1) 히스토리 증가가 어떻게 작동하는지와 2) 이 문제를 해결하는 방법을 이해하는 것이다. 이 글에 포함된 많은 데이터는 전통적인 방법으로는 얻기 어려우므로, 이러한 데이터를 공개함으로써 히스토리 증가 문제에 대한 새로운 통찰을 제공하고자 한다.
히스토리 증가는 이더리움 확장성의 병목 현상으로서 아직 충분히 주목받지 못했다. Gas 한도를 늘리지 않더라도, 이더리움이 현재 히스토리를 보존하는 관행은 몇 년 안에 많은 노드가 하드웨어를 업그레이드하도록 강요할 것이다. 다행히 이는 해결하기 어려운 문제가 아니다. EIP-4444에 이미 명확한 해결책이 있다. 우리는 이 EIP의 시행을 가속화하여 향후 Gas 한도 증가를 위한 여지를 마련해야 한다고 생각한다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
Paradigm
