Vitalik 최근 연설에서 자주 언급한 "무상태"란 무엇인가?

2023-09-17 10:14:22

수집

본 문서는 The Verge와 The Purge 두 가지 주요 경로와 몇 가지 새로운 아이디어 도전을 결합하여 Vitalik의 마음속 상태 해결 경로를 함께 되짚어보겠습니다.

Vitalik은 최근 한국 블록체인 주간, 싱가포르 연설, 심지어 이더리움 실행 계층 핵심 개발자 회의(ACDE)에서 상태(State)라는 주제를 언급했습니다. 그리고 그에 따라 무상태, 상태 만료(State Expiry), 역사 데이터 만료(History Expiry, EIP-4444), Verkle 트리, 심지어 주소 공간의 확장\압축(Address Space Expand\Compression)과 같은 다양한 해결책 개념이 논의되었습니다. 물론, 이는 새로운 로드맵 조정 계획이 아니며, Vitalik이 작년 11월에 발표한 이더리움의 최신 로드맵에서 이러한 내용은 The Verge와 The Purge의 주요 경로에 속합니다.

이 글에서는 이 두 가지 주요 경로와 몇 가지 새로운 아이디어 도전을 결합하여 Vitalik이 생각하는 상태 해결 경로를 되짚어 보겠습니다.

상태(State)

이더리움의 상태는 모든 외부 소유 계좌(EOAs), 그들의 잔액, 스마트 계약 배포 및 관련 저장소를 포함하는 종합 장부를 의미합니다. 이 상태는 정적이지 않으며, 새로운 사용자가 증가하고 새로운 스마트 계약이 배포됨에 따라 지속적으로 확장됩니다.

현재 전체 노드는 이 지속적으로 증가하는 데이터 세트를 저장해야 블록을 올바르게 검증하고 상태 전환이 정확한지 확인할 수 있습니다. 이로 인해 검증 과정은 본질적으로 유상태가 됩니다. 이러한 지속적인 저장 요구는 전체 노드를 운영하는 하드웨어 요구 사항을 증가시키며, 이는 검증자가 점점 더 중앙화되는 결과를 초래합니다.

etherscan.io/ 데이터에 따르면, 현재 빠른 동기화 전체 노드를 운영하려면 최소 1200 Gb가 필요합니다(예: Geth 클라이언트 기준). 이는 상태 다듬기가 이루어져 이전 상태 데이터를 삭제하고 최근 상태만 유지하는 전제 하에 이루어진 것입니다. 아카이브 노드, 즉 전체 노드가 모든 역사적 상태를 보존하는 경우, 필요한 용량은 약 15,400 Gb가 필요하며, 앞으로도 계속 증가할 것입니다. 이는 커뮤니티에서 흔히 말하는 "상태 폭발"입니다.

이것은 Vitalik이 한국 블록체인 주간에서 강조한 바와 같습니다: 노드의 중앙화는 이더리움 네트워크가 직면한 가장 큰 문제 중 하나이며, 노드 운영을 더 저렴하고 쉽게 만들어 해결해야 합니다.

이러한 일련의 도전에 대응하기 위해 이더리움 커뮤니티는 개선 및 최적화 방법을 찾기 위해 노력해 왔으며, 이는 우리가 처음에 언급한 다양한 해결책 개념입니다.

상태 해결책

무상태(Statelessness)

무상태(Stateless)의 핵심 개념은 상태 데이터를 외부화하여 각 노드가 전체 상태를 저장할 필요가 없도록 하는 것입니다. 이 모델에서는 노드가 블록 헤더와 관련 거래 정보를 유지하고, 상태 증명(State Proofs)을 통해 상태를 검증하고 재구성합니다.

무상태의 주요 역할과 의미는 노드의 저장 부담을 줄이고 네트워크 확장성을 높여 더 많은 노드가 쉽게 검증에 참여할 수 있도록 하며, 여전히 이더리움의 탈중앙화 특성을 유지하는 것입니다.

Verkle 트리

현재 이더리움은 Merkle-Patricia 트리를 사용하여 상태 데이터를 해시하고 압축합니다. 그러나 이 트리 구조에서 Merkle 증명의 크기가 너무 커질 수 있어 무상태 모델에 필요한 증명에 적합하지 않을 수 있습니다.

이 문제를 해결하기 위해 이더리움은 Verkle 트리로 전환할 계획입니다. 이는 더 효율적인 데이터 구조입니다. Merkle-Patricia 트리와 Verkle 트리는 모두 특정 정보의 존재를 쉽게 확인할 수 있도록 하는 암호학적 증명인 증명을 생성하는 중요한 능력을 공유합니다.

Verkle 트리의 장점은 더 작은 증명 크기를 생성하는 데 있어 효율성이 더 높다는 것입니다.

역사 데이터 만료(History Expiry, EIP-4444)

EIP-4444는 역사 데이터 만료를 구현하는 것을 목표로 하며, 이는 노드가 1년 이상 된 역사 블록을 피어 투 피어 네트워크에서 호스팅하는 것을 중단하도록 요구하는 업그레이드입니다. 역사 데이터를 삭제하면 노드 운영자의 디스크 공간 요구가 크게 줄어듭니다. 또한, 역사 블록의 다양한 버전에 적응하기 위한 코드의 필요성을 제거하여 클라이언트 소프트웨어를 단순화합니다. 게다가 EIP-4444는 PDS(Proto-danksharding)와 결합되어 정기적인 데이터 다듬기를 보장합니다; EIP-4444는 매년 다듬기를 수행하고 PDS는 매월 데이터 블록을 다듬습니다. 이는 노드의 데이터 저장 요구를 줄이는 데 도움이 되지만, 역사 데이터의 저장 및 복구에 대한 우려를 불러일으킵니다.

상태 만료(State Expiry)

무상태성은 검증자가 블록을 검증할 때 전체 상태를 유지할 필요성을 없앱니다. 그러나 상태는 사라지지 않으며, 그 지속적인 증가는 여전히 네트워크의 장기적인 도전 과제입니다.

이 근본적인 문제를 해결하기 위해 커뮤니티는 상태 만료(State Expiry) 솔루션을 제안했습니다.

상태 만료는 변하지 않는 상태 부분을 자동으로 다듬어 1년 후 별도의 트리 구조로 이동시키고, 이를 이더리움의 주요 프로토콜에서 삭제합니다.

특히, 상태 만료는 Verkle 트리로 이동한 후에만 가능해집니다. 또한, Vitalik은 한국 블록체인 주간 KBW2023에서 무상태와 PBS가 있다면 상태 만료는 낮은 우선순위가 될 수 있다고 언급했습니다.

왜냐하면 그때 블록 제안자와 구축자가 분리(Proposer-Builder Separation, PBS)가 구현되면, 무상태 하에서도 블록 구축자는 블록을 생성하기 위해 상태에 접근해야 하지만, 당시 블록 구축자는 상태의 증가를 효과적으로 처리할 수 있을 것으로 예상되기 때문입니다. 이 분야는 어느 정도의 중앙화를 허용하므로, 구축자들의 노드 성능은 자연스럽게 요구를 충족할 수 있습니다.

현재 프로토콜 수준의 PBS는 이더리움 메인넷에 포함되지 않았지만, Mev-Boost PBS의 현재 시장 분포를 통해 미래 메인넷의 경향을 대략적으로 이해할 수 있습니다. mevboost.pics의 데이터 통계는 다음과 같습니다:

또한, 상태 만료(State Expiry)의 구현은 이더리움 주소 형식의 변경을 포함하며, 현재 두 가지 솔루션이 있습니다: 주소 공간 확장(address space extension) vs 주소 공간 압축(address space compression). 전자는 주소 길이를 32바이트로 늘리지만(현재 주소 형식은 20바이트), 복잡한 논리가 필요하여 기존 계약도 업데이트해야 합니다. 후자는 20바이트 형식을 유지하지만, 처음 6바이트를 접두사 및 주소 주기의 식별자로 사용합니다. 이는 호환성 문제를 크게 줄이지만, 주소 길이가 14바이트로 줄어들어 충돌 저항 능력을 잃게 되어 주소 생성의 잠재적 보안 문제를 초래합니다. 이는 현재 커뮤니티가 직면한 중대한 도전입니다.