2026 년 2 월 27 일, Vitalik Buterin이 Ethereum Research에서 "새로운 형태의 상태를 생성하여 상태의 초 스케일링"이라는 제목의 긴 글을 발표했습니다.

이 글에서 Vitalik Buterin은 Ethereum의 확장 경로를 더 자세히 살펴보았습니다. 이 글은 기술적 측면에서만이 아니라 전체적인 아키텍처적인 측면에서 Ethereum의 확장에 대해 논의하며, Ethereum이 향후 몇 년간 지속적으로 네트워크 용량을 확장하기 위한 고도로 단계적으로 진행되는 확장 계획을 제시했습니다.

동시에 그는 X에서이 글의 설명을 더 넣은 트윗을 게시했습니다. 우리는 Vitalik의 이번 새로운 확장 제안이 정확히 무엇이며 왜 이렇게 하는지에 대해 깊이있게 이해하려고 노력했습니다.

실행 리소스 및 데이터 리소스의 단기 및 장기 확장

Vitalik은 긴 글의 시작에서 "앞으로 5 년 동안 Ethereum을 확장하기 위해 세 가지 리소스를 확장해야합니다"라고 지적했습니다:

- 실행 리소스: EVM 계산, 서명 검증 등

- 데이터 리소스: 거래 송신자, 수신자, 서명 등

- 상태 리소스: 계정 잔액, 코드, 스토리지

처음 두 가지는 단기 및 장기적인 확장 계획이 있습니다.

실행 리소스의 경우, 단기적으로는 블록 액세스 목록 (BAL), ePBS 및 Gas 요금 재설정을 통해 약 10-30 배 성장을 실현하고, 장기적으로는 ZK-EVM을 통해 약 1000 배 성장하며 특정 유형의 계산 (서명, SNARK/STARK)에 대해 오프 체인 집계는 성능을 약 10000 배 향상시킬 수 있습니다.

데이터 리소스의 경우, 단기적으로는 p2p 향상 및 멀티 디멘전셔널 Gas를 통해 약 10-20 배 성장을 실현하고, 장기적으로는 Blobs + PeerDAS를 통해 약 500 배 성장합니다.

단기적인 확장은 Ethereum을 더 빨리 실행하도록하는 데 초점을 맞춥니다. 현재 Ethereum이 느린 것은 현재의 검증 방식이 직렬이기 때문입니다. - 하나씩 거래를 확인합니다. 거래가 멈추면 전체 검증이 멈추게 됩니다.

따라서 다음으로 향하는 올해의 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번의 업데이트를 수행해야 한다는 것을 의미하며, 데이터베이스 수준에서는 한 번의 업데이트마다 한 번의 작업이 필요하며, 한 번의 업데이트마다 데이터베이스가 작동해야 합니다. 업데이트가 많을수록 작업이 더 많아지며, 기록이 폭발적으로 느려집니다.

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

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

- "강력한 상태 무상태성": 노드는 완전한 상태를 저장할 필요가 없으며 사용자가 Merkle 증명을 제공하면 됩니다. Vitalik은 이 계획에 상태 저장소의 중앙화, 동적 저장소 액세스로 인한 거래 실패 및 대역폭 비용 문제가 있다고 생각합니다.

- "상태 만료": 자주 액세스되지 않는 상태는 활성 상태에서 자동으로 제거됩니다. 노드는 최근 액세스한 상태만 저장하면서 저장 공간을 크게 줄일 수 있습니다. Vitalik은 기본적인 존재 문제가 있다고 생각합니다. 즉, 새로운 상태를 작성할 때 특정 상태의 "존재하지 않음"을 어떻게 증명할 수 있는지입니다. 새 계정을 작성한다고 가정해 보겠습니다. 그러면 새 계정 주소가 이더리움에서 이전에 생성된 적이 없음을 증명해야 합니다. 이는 모든 새 계정 생성 시 10년의 기록 데이터를 확인해야 하므로 새 계정 생성이 복잡하고 비용이 많이 들어갈 것입니다.

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

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

- 주기적 저장소: 임시 저장소와 유사하지만 더 긴 주기를 갖습니다. 예를 들어, 1년.

- 제한된 저장소: 특정 방식으로만 액세스할 수 있는 일부 저장소 형식. 예를 들어, ERC20 토큰 잔액 저장은 특정 인터페이스를 통해서만 액세스할 수 있을 수 있습니다. 이렇게 함으로써 시스템은 이러한 저장소를 최적화할 수 있습니다.

동시에 기존 상태 형식을 유지합니다. 이러면 실행 비용을 1000배 저렴하게 만들 수 있지만, 새로운 상태를 생성하는 비용은 더 많이 줄일 수 있습니다.

Vitalik은 새로운 상태 형식이 있으면 개발자가 선택권이 생기게 된다고 생각했습니다. 기존 상태 형식을 계속 사용하더라도 더 높은 수수료를 지불하거나 응용 프로그램을 재설계하여 새로운 상태 형식을 사용하여 더 낮은 비용을 얻을 수 있습니다. 흔한 사용 사례(예: ERC20 잔액, NFT)에는 표준화된 작업 흐름이 있을 것이지만, 더 복잡한 사용 사례(예: DeFi)에 대해서는 개발자가 개별적으로 최적화해야 합니다.

이러한 전략은 매우 흥미로우며, 개발자가 비용을 줄이기 위해 머리를 맞대고 생각하고, 광범위한 이더리움 사용자가 혜택을 입는 의미가 있습니다.

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia