이더리움 스토리지 폭발 문제 분석 및 최적화

特邀专栏作者

2021-12-28 11:22

이 기사는 약 3310자로, 전체를 읽는 데 약 5분이 소요됩니다

DeFi 및 GameFi와 같은 탈중앙화 애플리케이션의 활발한 개발로 인해 거래 수수료가 낮은 고성능 블록체인에 대한 수요가 크게 증가했습니다.

배경

DeFi 및 GameFi와 같은 탈중앙화 애플리케이션의 활발한 개발로 거래 수수료가 낮은 고성능 블록체인에 대한 수요가 크게 증가했습니다. 그러나 고성능 블록체인 구축의 핵심 과제는 스토리지 폭발입니다. 아래 이미지는 이더리움 풀노드(아카이브)의 블록체인 데이터 크기를 나타내는 Etherscan에서 가져온 그래프입니다.

보조 제목

스토리지 오버헤드 분석

스토리지 사용량을 추가로 분석하면 블록 데이터가 약 300GB의 데이터(블록 높이 0에서 13.6M까지)만 차지한다는 것을 알 수 있으며 이는 9TB보다 훨씬 적습니다. 그렇다면 나머지 8.7TB의 데이터는 어디에서 왔습니까?

차단하다

차단하다
상태
거래 영수증

그 중 상태는 8.7TB의 주요 구성 요소입니다. 그래서 때때로 스토리지 폭발을 "상태 폭발"이라고 합니다. 그런데 국가가 왜 그렇게 큰가요?

이더리움 상태란 무엇입니까?

Ethereum 상태는 Merkle Patrica 트리(MPT)입니다.

리프 노드는 주소(0x...) => 계정의 매핑입니다. 여기서 계정은 주소와 관련된 잔액, 논스 등을 저장합니다.
내부 노드는 전체 트리의 해시 루트를 빠르게 계산할 수 있도록 트리 구조를 유지합니다.

보조 제목

Geth 전체 노드

아카이브 노드 상태 폭발 문제를 해결하기 위해 Geth의 천재 엔지니어들은 MPT를 주기적으로만 저장하는 "prune" 모드라는 새로운 모드를 만들었습니다. 여기에서는 노드가 3개 블록마다 MPT만 저장하는 간단한 예를 제공합니다. (상태 블록을 포함하지 않는 상태를 얻으려면 노드가 해당 블록 이전의 가장 최근 상태를 가져와 후속 트랜잭션을 재생해야 합니다.)

보조 제목

빠른 동기화가 가능한 Geth용 전체 노드

제네시스 블록에서 모든 트랜잭션을 재생하여 노드를 실행하는 데 있어 한 가지 문제점은 모든 트랜잭션을 재생하는 데 시간이 오래 걸릴 수 있다는 것입니다. 일반적으로 제네시스 블록에서 네트워크의 최신 상태를 따라잡기 위해 그러한 노드를 설정하는 데 몇 주가 걸립니다. 노드의 시작 프로세스 속도를 높이기 위해 Geth는 빠른 동기화 모드를 추가로 제공합니다. 이 모드는 블록 이전의 히스토리 MPT를 재생 및 유지하지 않고 최신 안정 블록의 MPT를 다운로드할 수 있습니다. MPT를 다운로드한 후 전체 노드처럼 새 블록(주기적인 상태 저장 포함)을 재생합니다.

질문

현재 이더리움 스토리지 크기가 447GB이고 15TPS인 경우 1TB SSD가 있는 일반 구성 컴퓨터는 상당한 기간(예: 몇 년) 동안 이더리움 노드를 실행할 수 있어야 합니다. 그렇다면 실제로 스토리지 폭발이나 상태 폭발이 있습니까? 아마 이더리움은 앞으로 몇 년 안에 없을 것입니다. 하지만 이더리움의 가상 머신(EVM)을 수백 또는 수천 TPS로 확장할 수 있다면 어떨까요?

또 다른 EVM 기반 체인인 바이낸스 스마트 체인(BSC)에 대해 살펴보겠습니다. 2021년 12월 8일 현재 BSC는 다음과 같습니다.

약 984GB의 온체인 데이터, 그 중 블록은 약 550GB, 상태는 약 400GB를 차지합니다.
2조 6623억 트랜잭션, 100 TPS

트랜잭션 수로 데이터 크기를 추가로 예측하면 다음을 얻을 수 있습니다.

TPS가 100이면 ~3,153M TPY입니다.

1년 후 총 TX ~5,219M, 블록 ~1.375TB, 상태 ~1.085TB
3년 후 총 TX ~11,525M, 블록 ~3.025TB, 상태 ~2.387TB

TPS가 150(관측된 최대 TPS)인 경우 ~4,730M TPY입니다.

1년 후 총 TX ~6,796M, 블록 ~1.809TB, 상태 ~1.427TB
3년 후 총 TX ~16,256M, 블록 ~4.327TB, 상태 ~3.414TB

정리하자면, BSC의 경우 현재 속도가 유지되거나 그 이상이면 곧 이더리움 아카이브 노드와 동일한 스토리지 크기에 도달할 것이며 이는 일반 컴퓨터가 실행하기 거의 불가능합니다.

TPS가 매우 높은 블록체인의 스토리지 폭발 문제

매우 높은 TPS(QuarkChain이 할 수 있는 것과 같은)를 가진 블록체인에 대해 더 대담한 가정을 하면 이 숫자는 어떻게 될까요? TPS가 1000인 블록체인을 고려하고 블록 및 상태 크기를 분석해 보겠습니다.

tx 크기가 약 100바이트라고 가정하면 각 블록에 필요한 스토리지는 1000(TPS) * 100(bytes per tx) * 365 * 24 * 3600 = 2.86TB입니다.
MPT가 100억 개의 계정(세계 인구보다 많음!)을 가지고 있다고 가정하면 상태 크기는 150G(Ethereum 상태 크기) / 0.18B(Ethereum 고유 주소) * 10B = 8.3TB가 될 것으로 예상합니다.

이러한 수치를 종합하면 일반적인 구성을 가진 대부분의 컴퓨터가 처리할 수 없는 요구 사항이라는 결론에 쉽게 도달할 수 있습니다!

최적화

보조 제목

상태 저장 최적화

우리가 제안하는 첫 번째 최적화는 MPT 대신 일반 KV를 사용하는 것입니다. MPT가 크면 MPT의 모든 내부 노드가 매우 비쌀 수 있습니다. 그리고 최적화는 MPT의 모든 내부 노드를 제거합니다. 각 계정의 데이터가 약 50바이트(20개의 주소 + 2개의 논스 + 12개의 계정 + 기타)라고 가정하면 다음 100억 개의 계정 데이터를 다음과 같이 저장할 수 있습니다.

~ 10B * 50 + 100GB(코드) = 600GB, MPT 버전의 약 1/10!

일반 KV를 사용하면 큰 이점이 있지만 주요 문제는 짧은 블록 간격에서 각 블록의 해시 후 상태를 계산할 수 없다는 것입니다. 즉, 이더리움의 다음과 같은 이점을 잃게 됩니다.

빠른 동기화: 모든 블록의 상태를 다운로드하고 나머지 블록을 재생하여 네트워크를 빠르게 동기화
포크 감지(또는 비잔틴 감지): 피어에서 새로 생성된 블록이 로컬에서 실행된 블록과 다른 상태가 되는지 여부.

빠른 동기화를 활성화하기 위해 주기적인 스냅샷 블록이 있습니다(스냅샷 간격 = 에포크 = 예: 14주). 스냅샷 블록은 이전 스냅샷 블록의 사후 상태 해시(트랜잭션 실행 후 상태 해시)인 사전 상태 해시의 추가 정보를 포함합니다.

스냅샷이 아닌 블록은 상태 해시를 유지하지 않고 대신 해당 블록에 대한 모든 트랜잭션의 원래 데이터베이스 작업(삭제, 업데이트)의 해시를 포함하는 증분 해시를 가집니다. 이렇게 하면 포크 감지가 가능합니다!
우리는 Ethereum의 블록에 대해 트랜잭션 후 상태 해시 대신 트랜잭션 전 상태 해시를 사용합니다. 그 이유는 노드가 트랜잭션 후 상태 해시를 즉시 계산할 수는 없지만 트랜잭션 전 상태 해시를 사용함으로써 노드는 전체 epoch 간격을 사용하여 해시를 계산할 수 있기 때문입니다. 예를 들어 상태 해시 계산이 초당 10M 상태 데이터를 처리한다고 가정하면 600GB의 전체 상태를 계산하는 데 600GB/10M ~ 16.67시간이 소요됩니다(vs. epoch = 14주).