이더리움 아카이브 노드

아카이브 노드는 모든 과거 상태의 아카이브를 구축하도록 구성된 이더리움 클라이언트의 인스턴스입니다. 특정 사용 사례에 유용한 도구이지만 풀 노드보다 실행하기가 더 까다로울 수 있습니다.

전제 조건

이더리움 노드의 개념, 아키텍처, 동기화 전략, 그리고 노드를 실행하고 사용하는 방법에 대해 이해하고 있어야 합니다.

아카이브 노드란 무엇인가

아카이브 노드의 중요성을 파악하기 위해 "상태"의 개념을 명확히 해보겠습니다. 이더리움은 트랜잭션 기반 상태 머신(transaction-based state machine)이라고 할 수 있습니다. 이더리움은 트랜잭션을 실행하여 상태를 변경하는 계정과 애플리케이션으로 구성됩니다. 각 계정과 컨트랙트에 대한 정보가 포함된 전역 데이터는 상태라는 트라이(trie) 데이터베이스에 저장됩니다. 이는 실행 계층(EL) 클라이언트에서 처리하며 다음을 포함합니다:

계정 잔액 및 논스(nonce)
컨트랙트 코드 및 스토리지
합의 관련 데이터 (예: 스테이킹 예치금 컨트랙트)

네트워크와 상호작용하고 새로운 블록을 검증 및 생성하기 위해, 이더리움 클라이언트는 가장 최근의 변경 사항(체인의 끝)과 현재 상태를 계속 파악해야 합니다. 풀 노드로 구성된 실행 계층 클라이언트는 네트워크의 최신 상태를 검증하고 따르지만, 체인 재구성을 처리하고 최근 데이터에 빠르게 접근할 수 있도록 최근 몇 개의 상태(예: 마지막 128개 블록과 관련된 상태)만 캐시합니다. 최근 상태는 모든 클라이언트가 들어오는 트랜잭션을 검증하고 네트워크를 사용하는 데 필요한 것입니다.

상태를 특정 블록에서의 순간적인 네트워크 스냅샷으로, 아카이브를 과거 기록의 재생으로 생각할 수 있습니다.

과거 상태는 네트워크 작동에 필요하지 않으며 클라이언트가 모든 오래된 데이터를 보관하는 것은 불필요하게 중복되므로 안전하게 프루닝(pruning)할 수 있습니다. 최근 블록(예: 헤드에서 128개 블록 이전) 이전에 존재했던 상태는 사실상 버려집니다. 풀 노드는 과거 블록체인 데이터(블록 및 트랜잭션)와 요청 시 이전 상태를 재생성하는 데 사용할 수 있는 간헐적인 과거 스냅샷만 보관합니다. 풀 노드는 EVM에서 과거 트랜잭션을 재실행하여 이 작업을 수행하는데, 원하는 상태가 가장 가까운 스냅샷에서 멀리 떨어져 있을 경우 연산 요구량이 많아질 수 있습니다.

그러나 이는 풀 노드에서 과거 상태에 접근할 때 많은 연산이 소모된다는 것을 의미합니다. 클라이언트는 제네시스(genesis)부터 모든 과거 트랜잭션을 실행하고 하나의 과거 상태를 계산해야 할 수도 있습니다. 아카이브 노드는 가장 최근의 상태뿐만 아니라 각 블록 이후에 생성된 모든 과거 상태를 저장하여 이 문제를 해결합니다. 기본적으로 더 큰 디스크 공간을 요구하는 대신 성능을 얻는 트레이드오프(trade-off)를 합니다.

네트워크가 모든 과거 데이터를 보관하고 제공하기 위해 아카이브 노드에 의존하지 않는다는 점에 유의해야 합니다. 위에서 언급했듯이 모든 과거 중간 상태는 풀 노드에서 파생될 수 있습니다. 트랜잭션은 모든 풀 노드(현재 400GB 미만)에 저장되며 전체 아카이브를 구축하기 위해 재생될 수 있습니다.

사용 사례

트랜잭션 전송, 컨트랙트 배포, 합의 검증 등과 같은 이더리움의 일반적인 사용에는 과거 상태에 대한 접근이 필요하지 않습니다. 사용자는 네트워크와의 표준적인 상호작용을 위해 아카이브 노드가 전혀 필요하지 않습니다.

상태 아카이브의 주요 이점은 과거 상태에 대한 쿼리에 빠르게 접근할 수 있다는 것입니다. 예를 들어, 아카이브 노드는 다음과 같은 결과를 즉시 반환합니다:

블록 15537393에서 계정 0x1337...의 ETH 잔액은 얼마였는가?
블록 1920000에서 컨트랙트 0x에 있는 토큰 0x의 잔액은 얼마인가?

위에서 설명한 바와 같이, 풀 노드는 CPU를 사용하고 시간이 걸리는 EVM 실행을 통해 이 데이터를 생성해야 합니다. 아카이브 노드는 디스크에서 이 데이터에 접근하여 즉시 응답을 제공합니다. 이는 인프라의 특정 부분에서 유용한 기능입니다. 예를 들면 다음과 같습니다:

블록 탐색기와 같은 서비스 제공자
연구원
보안 분석가
탈중앙화 애플리케이션 (dapp) 개발자
감사 및 규정 준수

과거 데이터에 접근할 수 있는 다양한 무료 서비스도 있습니다. 아카이브 노드를 실행하는 것은 요구 사항이 더 많기 때문에 이러한 접근은 대부분 제한적이며 간헐적인 접근에만 작동합니다. 프로젝트에서 과거 데이터에 지속적으로 접근해야 하는 경우 직접 아카이브 노드를 실행하는 것을 고려해야 합니다.

구현 및 사용

이 문맥에서 아카이브 노드는 상태 데이터베이스를 처리하고 JSON-RPC 엔드포인트를 제공하는 사용자 대면 실행 계층 클라이언트가 제공하는 데이터를 의미합니다. 구성 옵션, 동기화 시간 및 데이터베이스 크기는 클라이언트에 따라 다를 수 있습니다. 자세한 내용은 클라이언트에서 제공하는 문서를 참조하세요.

자체 아카이브 노드를 시작하기 전에 클라이언트 간의 차이점, 특히 다양한 하드웨어 요구 사항에 대해 알아보세요. 대부분의 클라이언트는 이 기능에 최적화되어 있지 않으며 아카이브에 12TB 이상의 공간이 필요합니다. 반면, 에리곤(Erigon)과 같은 구현은 동일한 데이터를 3TB 미만으로 저장할 수 있어 아카이브 노드를 실행하는 가장 효과적인 방법입니다.

권장 사례

노드 실행에 대한 일반적인 권장 사항 외에도 아카이브 노드는 하드웨어 및 유지 관리에 더 많은 요구 사항이 있을 수 있습니다. 에리곤의 주요 기능 (opens in a new tab)을 고려할 때 가장 실용적인 접근 방식은 에리곤 클라이언트 구현을 사용하는 것입니다.

하드웨어

항상 클라이언트 문서에서 특정 모드에 대한 하드웨어 요구 사항을 확인하세요. 아카이브 노드의 가장 큰 요구 사항은 디스크 공간입니다. 클라이언트에 따라 3TB에서 12TB까지 다양합니다. 대용량 데이터의 경우 HDD가 더 나은 솔루션으로 간주될 수 있지만, 동기화하고 체인의 헤드를 지속적으로 업데이트하려면 SSD 드라이브가 필요합니다. SATA (opens in a new tab) 드라이브로도 충분하지만 최소한 TLC (opens in a new tab) 이상의 신뢰할 수 있는 품질이어야 합니다. 디스크는 데스크톱 컴퓨터나 슬롯이 충분한 서버에 장착할 수 있습니다. 이러한 전용 장치는 높은 가동 시간(uptime)을 유지하는 노드를 실행하는 데 이상적입니다. 노트북에서도 실행할 수 있지만 휴대성으로 인해 추가 비용이 발생합니다.

모든 데이터는 하나의 볼륨에 들어가야 하므로 디스크를 RAID0 (opens in a new tab) 또는 LVM 등으로 결합해야 합니다. 또한 하위 수준의 오류 없이 데이터가 디스크에 올바르게 기록되도록 보장하는 "기록 중 복사(Copy-on-write)"를 지원하는 ZFS (opens in a new tab) 사용을 고려해 볼 가치가 있습니다.

특히 전문적인 설정에서 우발적인 데이터베이스 손상을 방지하여 안정성과 보안을 높이려면 시스템이 지원하는 경우 ECC 메모리 (opens in a new tab) 사용을 고려하세요. RAM 크기는 일반적으로 풀 노드와 동일하게 권장되지만 RAM이 많을수록 동기화 속도를 높이는 데 도움이 될 수 있습니다.

초기 동기화 중에 아카이브 모드의 클라이언트는 제네시스 이후의 모든 트랜잭션을 실행합니다. 실행 속도는 대부분 CPU에 의해 제한되므로 더 빠른 CPU는 초기 동기화 시간에 도움이 될 수 있습니다. 일반적인 소비자용 컴퓨터의 경우 초기 동기화에 최대 한 달이 걸릴 수 있습니다.