앞으로 5년 동안 비탈릭은 이더리움을 이렇게 확장할 것입니다
3月 4, 2026 10:08:21
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가 될까요?
문제는 하드 드라이브에 저장할 수 없다는 것이 아니라:
데이터베이스 효율성에 영향을 미칩니다: 현대 데이터베이스는 트리 구조(예: Merkle 트리)를 사용하여 데이터를 조직합니다. 새로운 데이터를 작성할 때 전체 트리를 업데이트해야 합니다. 즉, X번 업데이트를 수행해야 한다면 데이터베이스 수준에서 X번의 작업이 필요하며, 한 번 업데이트하고 데이터베이스 작업을 한 번 수행하는 것이 아닙니다. 업데이트가 많아질수록 작업이 많아지고, 쓰기가 느려집니다.
동기화가 어렵습니다: 이더리움 네트워크에 새로 가입한 노드는 새로운 블록을 검증하기 위해 전체 상태를 다운로드해야 합니다. 데이터 규모가 8TB에 이르면, 대부분의 사람들은 현재의 인터넷 속도로 다운로드하는 데 오랜 시간이 걸릴 것입니다.
해결책은 있지만, Vitalik은 모두 문제가 있다고 생각합니다:
"강한 상태 비상태성": 노드는 전체 상태를 저장할 필요가 없으며, 사용자에게 Merkle 증명을 제공하면 됩니다. Vitalik은 이 솔루션이 상태 저장의 중앙화, 동적 저장소 접근으로 인한 거래 실패 및 대역폭 비용 문제를 초래한다고 생각합니다.
"상태 만료": 자주 접근하지 않는 상태는 자동으로 활성 상태에서 삭제됩니다. 노드는 최근에 접근한 상태만 저장하면 저장 공간을 크게 줄일 수 있습니다. 그러나 Vitalik은 새로운 상태를 생성할 때 "결코 존재하지 않았던" 상태를 어떻게 증명할 것인지에 대한 근본적인 "존재 문제"가 있다고 생각합니다. 새로운 계좌를 생성한다고 가정하면, 새로운 계좌 주소가 이더리움에서 결코 생성되지 않았음을 증명해야 합니다. 이는 각 새로운 계좌의 생성이 10년의 역사 데이터를 확인해야 함을 의미하며, 새로운 계좌 생성이 복잡하고 비쌀 수 있습니다.
Vitalik의 최종 방법은 이 두 가지 솔루션을 결합하여 몇 가지 새로운 상태 형태를 제안하는 것입니다. 이는 이더리움 상태 자원 아키텍처의 전체적인 변화를 의미합니다:
임시 저장소: 자동으로 만료되는 저장소입니다. 예를 들어, 매달 자동으로 초기화되는 새로운 트리를 생성할 수 있습니다. 이러한 저장소는 임시 데이터, 주문서, 유동성 풀, 임시 카운터 등과 같은 데이터에 사용될 수 있으며, 이러한 데이터는 일반적으로 영구 저장이 필요하지 않습니다. 한 달 후, 이전의 주문이 만료되고 새로운 유동성 풀이 생성됩니다.
주기적 저장소: 임시 저장소와 유사하지만 주기가 더 깁니다. 예를 들어 1년입니다.
제한된 저장소: 특정 방식으로만 접근할 수 있는 저장소입니다. 예를 들어, 특정 인터페이스를 통해서만 접근할 수 있는 ERC20 토큰의 잔액 저장소가 있을 수 있습니다. 이렇게 하면 시스템이 이러한 저장소를 최적화할 수 있습니다.
동시에 기존의 상태 형태를 유지합니다. 이렇게 하면 실행이 1000배 저렴해질 수 있지만( ZK-EVM을 통해), 새로운 상태 생성은 20배 저렴해질 수 있습니다.
Vitalik은 새로운 상태 형태가 생기면 개발자에게 선택권이 생긴다고 생각합니다. 기존의 상태 형태를 계속 사용하되 더 높은 비용을 지불하거나, 애플리케이션을 재설계하여 새로운 상태 형태를 사용하여 더 낮은 비용을 얻을 수 있습니다. 일반적인 사용 사례(예: ERC20 잔액, NFT)에 대해서는 표준화된 워크플로가 제공되지만, 더 복잡한 사용 사례(예: DeFi)에 대해서는 개발자가 스스로 최적화 방법을 찾아야 합니다.
이러한 전략은 상당히 흥미롭고, 개발자가 머리를 써서 비용을 줄이고, 많은 이더리움 사용자가 그 혜택을 누릴 수 있는 의미가 있습니다.
관련 프로젝트
최신 뉴스
ChainCatcher
3月 4, 2026 13:50:37
ChainCatcher
3月 4, 2026 13:42:02
ChainCatcher
3月 4, 2026 13:38:53
ChainCatcher
3月 4, 2026 13:25:10
ChainCatcher
3月 4, 2026 13:19:45












