Vitalik, 이더리움의 다음 5년을 설정하다: 실행 효율화, 데이터 샤딩, 상태 계층화

2026년 2월 27일, Vitalik Buterin은 Ethereum Research에 'Hyper-scaling state by creating new forms of state(새로운 형태의 상태를 생성하여 상태를 초확장하기)'라는 제목의 긴 글을 게시했습니다.

이 글에서 Vitalik Buterin은 이더리움의 확장 경로를 더욱 체계적으로 정리했습니다. 이 글은 단순히 기술적 관점에서 이더리움 확장을 논하는 것이 아니라, 전체적인 아키텍처 관점에서 단계적으로 추진할 수 있는 확장 방안을 제시하여, 향후 몇 년간 이더리움이 네트워크 용량을 지속적으로 확대할 수 있는 기반을 마련하는 데 목적을 두고 있습니다.

동시에 그는 X(구 트위터)에도 글을 올려 이 글에 대해 추가 설명을 했습니다. 우리는 Vitalik이 이번에 새롭게 제안한 확장 방안이 정확히 무엇이며, 왜 이렇게 해야 하는지 쉽게 이해해 보려고 합니다.

실행 자원과 데이터 자원의 단기 및 장기 확장

Vitalik은 글의 서두에서 "향후 5년 동안 이더리움을 확장하려면 세 가지 자원을 확장해야 한다"고 지적했습니다:

- 실행 자원: EVM 계산, 서명 검증 등

- 데이터 자원: 거래의 발신자, 수신자, 서명 등

- 상태 자원: 계정 잔액, 코드, 저장소

앞의 두 가지는 단기 및 장기 확장 방안을 가지고 있습니다.

실행 자원의 경우, 단기적으로는 블록 접근 목록(BAL), ePBS 및 가스 요금 재정의를 통해 약 10-30배의 성장을, 장기적으로는 ZK-EVM을 통해 약 1000배의 성장을 실현할 수 있으며, 특정 유형의 계산(서명, SNARK/STARK)의 경우 오프체인 집계를 통해 성능을 약 10000배까지 향상시킬 수 있습니다.

데이터 자원의 경우, 단기적으로는 P2P 개선 및 다차원 가스를 통해 약 10-20배의 성장을, 장기적으로는 Blobs + PeerDAS를 통해 약 500배의 성장을 실현할 수 있습니다.

단기 확장은 이더리움이 더 빠르게 실행되도록 하는 데 중점을 둡니다. 현재 이더리움이 느린 이유는 현재의 검증 방식이 직렬적이기 때문입니다. 즉, 거래를 하나씩 순차적으로 검사합니다. 만약 어떤 거래가 막히면 전체 검증 과정이 멈춥니다.

따라서 올해 예정된 Glamsterdam 업그레이드에서는 블록 접근 목록(BAL)과 ePBS가 도입될 것입니다.

블록 접근 목록은 블록 패커가 검증자에게 미리 알려주는 것입니다: "이 블록 내의 거래는 이러한 계정과 저장 위치에 접근할 것입니다." 이 정보를 통해 검증자는 미리 준비하여 이 데이터를 하드 디스크에서 메모리로 로드할 수 있습니다. 그런 다음 검증자는 거래를 하나씩 검사하는 대신 여러 거래를 병렬로 검사할 수 있습니다. 마치 공장의 조립 라인과 같습니다: 이전에는 한 명의 작업자가 전체 제품을 담당했다면, 지금은 여러 작업자가 서로 다른 부분을 동시에 처리하는 것입니다.

ePBS는 블록의 패킹과 검증 과정을 분리합니다. 블록 빌더는 거래 패킹을 담당하고, 제안자는 블록 제안을 담당하며, 검증자는 블록 검증을 담당합니다. 각 역할이 자신의 부분을 맡아 일을 잘 수행하면, 블록 빌더는 보안성 문제를 걱정하지 않고 더 적극적으로 더 많은 거래를 패킹할 수 있습니다. 왜냐하면 제안자와 검증자가 대신 검사해 주기 때문입니다.

가스 요금 재정의 + 다차원 가스는 '핵심 기술'이라고 할 수 있습니다. 현재 이더리움의 모든 작업은 동일한 가스 요금을 사용합니다. 하지만 Vitalik의 생각은 다른 작업에는 다른 가격이 적용되어야 한다는 것입니다.

특히, 새로운 상태 생성(예: 새 계정 생성, 새 계약 배포)에는 특별한 '상태 생성 수수료'가 부과되어야 합니다. 왜냐하면 새로운 상태 생성은 가장 비용이 많이 드는 작업이기 때문입니다. 이는 계산 자원뿐만 아니라 저장 자원도 차지합니다. 게다가 이 비용은 영구적입니다. 일단 생성되면 이 상태는 계속 존재합니다.

따라서 Vitalik의 생각은 다음과 같습니다: 새로운 상태 생성을 더 비싸게 만들지만, 일반 거래는 더 저렴하게 만드는 것입니다.

구현 방법은 '저수지 메커니즘'입니다. 두 개의 통을 상상해 보세요. 하나는 '상태 생성 수수료'를 담고, 다른 하나는 '일반 가스 요금'을 담습니다. 계약이 서로 호출할 때 가스는 자동으로 두 통에서 차용되어 혼란이 발생하지 않도록 합니다.

일반 사용자의 거래는 더 저렴해질 것입니다. 왜냐하면 이러한 거래는 '상태 생성 수수료'를 내지 않아도 되기 때문입니다. 반면 새로운 상태를 생성하려는 개발자는 더 높은 수수료를 지불해야 합니다. 이렇게 하면 네트워크의 전체 용량은 급증하지만, 상태 증가는 통제되어 전체 노드의 하드 디스크가 폭발하는 일은 없을 것입니다.

장기 확장은 메인넷 자체를 크고 강하게 만들어 Layer 2에 대한 의존도를 줄이는 것입니다. 여기에는 Blobs + PeerDAS와 ZK-EVM의 단계적 롤아웃이 포함됩니다.

Blobs는 일시적인 대용량 파일 저장소로, 현재는 주로 Layer 2에서 사용됩니다. 나중에는 이더리움 메인넷 자체도 데이터 저장을 위해 Blobs를 사용할 것입니다. 하지만 문제가 생깁니다. 만약 모든 노드가 모든 Blobs를 다운로드해야 한다면 네트워크가 폭발할 것입니다.

여기서 PeerDAS가 필요합니다. 전체 데이터를 다운로드할 필요 없이, 일부만 다운로드하면 됩니다. 마치 표본 조사처럼, 모든 사람에게 물어볼 필요 없이 소수의 사람에게만 물어보면 전체 집단의 상황을 추론할 수 있는 것과 같습니다. ZK 증명과 결합하면 전체 데이터의 1/16만 다운로드하더라도 데이터 무결성을 확인할 수 있습니다.

다음은 ZK-EVM의 단계적 롤아웃입니다. 이는 블록 검증이 더 이상 블록 내의 모든 거래를 재실행할 필요가 없도록 합니다. 노드는 ZK 증명을 직접 신뢰하면 되며, 검증 비용은 '모든 거래 실행'에서 'ZK 증명 하나 검증'으로 낮아집니다.

Vitalik의 계획은 2026년에 일부 노드가 ZK 검증을 시험 사용하고, 2027년에는 더 많은 노드가 사용하도록 장려하는 것입니다. 마지막으로, 블록이 유효하려면 서로 다른 증명 시스템의 5가지 증명 유형 중 3가지가 포함되어야 합니다. 그는 모든 노드(인덱싱 노드 제외)가 결국 ZK-EVM 증명에 의존하게 될 것이라고 예상합니다.

'만능 해결책'이 없는 상태 확장

이제 단기 및 장기 확장에서 아직 논의되지 않은 '상태 자원'을 살펴보겠습니다. 단기적으로는 블록 접근 목록 동기화, P2P 개선 및 데이터베이스 최적화 등을 통해 약 5-30배 향상시킬 수 있지만, 장기적으로는 어떨까요?

Vitalik의 답은 '없다'입니다.

왜 상태 자원은 확장하기가 그렇게 어려울까요? 이더리움의 상태는 거대한 데이터베이스와 같습니다. 이 데이터베이스에는 모든 계정의 잔액, 모든 계약의 코드, 모든 저장 위치의 데이터가 저장되어 있습니다.

현재 이 데이터베이스는 약 100GB로 크지 않지만, 상태를 20배 확장하면 2TB가 됩니다. 시간이 더 지나면 어떨까요? 8TB?

문제는 하드 디스크에 저장할 수 없다는 것이 아닙니다. 문제는 다음과 같습니다:

- 데이터베이스 효율성 저하: 현대 데이터베이스는 데이터를 구성하기 위해 트리 구조(예: 머클 트리)를 사용합니다. 새로운 데이터를 쓸 때는 전체 트리를 업데이트해야 합니다. 이는 X번 업데이트를 하면 데이터베이스 수준에서도 X번의 작업이 필요하다는 것을 의미합니다. 즉, 한 번 업데이트하고 데이터베이스 작업을 한 번만 하는 것이 아닙니다. 업데이트가 많을수록 작업도 많아지며, 쓰기 속도가 폭발적으로 느려질 것입니다.

- 동기화 어려움: 이더리움 네트워크에 새로 참여하는 노드는 새로운 블록을 검증하기 위해 전체 상태를 다운로드해야 합니다. 데이터 규모가 8TB에 이르면 대부분의 사람들의 현재 인터넷 속도로는 오랜 시간이 걸릴 것입니다.

해결책은 있지만, Vitalik은 모두 문제가 있다고 생각합니다:

- '강력한 상태 비상태성': 노드는 완전한 상태를 저장할 필요 없이, 사용자가 머클 증명만 제공하면 됩니다. Vitalik은 이 방안이 상태 저장의 중앙화, 동적 저장소 접근으로 인한 거래 실패 및 대역폭 비용 문제가 있다고 생각합니다.

- '상태 만료': 자주 접근하지 않는 상태는 활성 상태에서 자동으로 삭제됩니다. 노드는 최근에 접근한 상태만 저장해도 저장 공간을 크게 줄일 수 있습니다. Vitalik은 근본적인 '존재 문제'가 있다고 생각합니다. 즉, 새로운 상태를 생성할 때, 특정 상태가 '존재한 적이 없다'는 것을 어떻게 증명할 것인가 하는 문제입니다. 새 계정을 생성한다고 가정하면, 새 계정 주소가 이더리움에서 한 번도 생성된 적이 없다는 것을 증명해야 합니다. 이는 각 새 계정 생성마다 10년간의 역사 데이터를 검사해야 한다는 것을 의미하며, 새 계정 생성이 복잡하고 비싸질 것입니다.

Vitalik의 최종 방법은 이 두 가지 방안을 결합하여 몇 가지 새로운 상태 형태를 제안하는 것입니다. 이는 이더리움 상태 자원 아키텍처의 전체적인 변경입니다:

- 임시 저장소: 자동으로 만료되는 저장소입니다. 예를 들어, 매월 자동으로 초기화되는 새로운 트리를 생성할 수 있습니다. 이러한 저장소는 임시 데이터, 주문장, 유동성 풀, 임시 카운터 등에 사용될 수 있습니다. 이러한 데이터는 일반적으로 영구 저장이 필요하지 않으며, 한 달 후에는 오래된 주문이 만료되고 새로운 유동성 풀이 다시 생성됩니다.

- 주기적 저장소: 임시 저장소와 유사하지만 주기가 더 깁니다(예: 1년).

- 제한된 저장소: 특정 저장소는 특정 방식으로만 접근할 수 있습니다. 예를 들어, ERC20 토큰의 잔액 저장소는 특정 인터페이스를 통해서만 접근할 수 있습니다. 이렇게 하면 시스템이 이러한 저장소를 최적화할 수 있습니다.

동시에 기존 상태 형태는 유지됩니다. 이렇게 하면 실행은 1000배 저렴해질 수 있지만( ZK-EVM을 통해), 새로운 상태 생성은 20배만 저렴해질 수 있습니다.

Vitalik은 새로운 상태 형태가 있으면 개발자에게 선택권이 생긴다고 생각합니다. 기존 상태 형태를 계속 사용하되 더 높은 수수료를 지불하거나, 애플리케이션을 재설계하여 새로운 상태 형태를 사용하고 더 낮은 수수료를 얻는 것입니다. 일반적인 사용 사례(예: ERC20 잔액, NFT)의 경우 표준화된 워크플로가 있을 것이며, 더 복잡한 사용 사례(예: DeFi)의 경우 개발자는 최적화 방법을 직접 고안해야 합니다.

이 전략은 상당히 흥미롭습니다. 개발자가 머리를 써서 비용을 낮추면, 광범위한 이더리움 사용자가 혜택을 보는 느낌입니다.