EIP-7870 노드 하드웨어·대역폭 권장 사양 (Hardware and Bandwidth Recommendations)

콜 결정 없음 · 네트워크·노드 · 원문 상태 Living · 2025-01-26 작성

이더리움 풀노드와 검증자(attester, 로컬 블록 빌더)가 갖추면 좋은 저장장치, 메모리, CPU, 인터넷 회선 속도를 역할별로 정리한 안내 문서입니다. 프로토콜을 바꾸지 않는 정보성(Informational) EIP입니다.

왜 필요한가

이더리움 노드는 실행 레이어(EL) 클라이언트와 합의 레이어(CL) 클라이언트를 한 컴퓨터에서 함께 돌리는 경우가 많습니다. 그런데 지금까지는 어떤 컴퓨터를 기준으로 성능을 재고 판단해야 하는지 공유된 기준이 없었습니다. 기준이 없으면 세 가지 문제가 생깁니다. 첫째, 클라이언트마다 다른 환경에서 성능을 재면 벤치마크 결과를 서로 비교할 수 없습니다. 둘째, 프로토콜 업그레이드가 노드 자원을 얼마나 더 쓰는지 판단하기 어렵습니다. 성능 특성이 하드웨어에 크게 좌우되기 때문입니다. 셋째, 노드 운영자는 어떤 장비에 투자해야 앞으로의 네트워크 요구에 맞는지 알 수 없습니다. 이 EIP는 역할별 권장 사양을 한 곳에 적어 이 세 문제를 함께 풀려고 합니다. 권장 사양보다 낮은 장비로도 클라이언트를 돌릴 수는 있지만 벤치마크와 의사 결정은 이 권장 사양을 기준으로 이루어진다고 원문은 밝힙니다.

무엇이 바뀌나

지금

EIP-7870 이후

누구에게 영향이 있나

심층 설명

노드 역할 세 가지

원문은 노드를 세 역할로 나눕니다. 풀노드(Full node)는 블록을 직접 제안하지 않아도 체인의 최신 지점(tip)을 따라가는 노드입니다. 검증자(Validator)는 다시 둘로 나뉩니다. Attester는 제안자가 만든 블록을 검증하고 증명(attest)하는 검증자이고 로컬 블록 빌더(Local block builder, Proposer)는 블록을 직접 만들어 네트워크에 전파하는 검증자입니다. 로컬 블록 빌더는 블록을 만드는 일과, attester가 시간 안에 검증할 수 있도록 필요한 데이터를 빠르게 뿌리는 일에 자원이 많이 듭니다. 원문은 권장 사양보다 낮은 장비로도 클라이언트를 돌릴 수 있을지 모르지만 벤치마크와 의사 결정은 이 권장 사양을 기준으로 한다고 못 박습니다.

역할별 권장 사양 표

노드 운영자는 보통 실행 레이어(EL) 클라이언트와 합의 레이어(CL) 클라이언트를 같은 컴퓨터에서 함께 돌리므로, 표의 수치는 둘을 합친 자원 사용량을 전제로 합니다. 풀노드는 4 TB NVMe, 32 GB 메모리, 4코어 8스레드(PassMark 약 1000 ST / 3000 MT), 다운로드 50 Mbps / 업로드 15 Mbps입니다. Attester는 4 TB NVMe, 64 GB 메모리, 8코어 16스레드(약 3500 ST / 25000 MT), 50 Mbps / 25 Mbps입니다. 로컬 블록 빌더는 attester와 저장장치, 메모리, CPU가 같고 대역폭만 100 Mbps / 50 Mbps로 높습니다. ST와 MT는 PassMark CPU 벤치마크의 싱글스레드와 멀티스레드 점수입니다. 원문은 ST 3500과 MT 25000 정도가 2024~2025년 무렵의 중상급 서버 CPU에 해당한다고 덧붙입니다.

저장장치: 4 TB NVMe와 IOPS 기준

권장은 4 TB NVMe M.2 드라이브입니다. 순차 읽기/쓰기 약 2000 MB/s 이상, 랜덤 4K 읽기 IOPS 약 50,000 이상, 랜덤 4K 쓰기 IOPS 약 15,000 이상을 요구합니다. 원문은 fio 명령으로 순차 성능(--bs=1M --rw=readwrite)과 랜덤 4K 성능(--bs=4k --readwrite=randrw --rwmixread=75)을 직접 재는 방법을 제시합니다. SATA 대신 NVMe를 고르는 이유는 처리량이 훨씬 높고 지연이 낮기 때문입니다. DRAM이 없는(DRAMless) 드라이브나 QLC 플래시는 내구성과 지속 성능이 낮을 수 있어 권하지 않습니다. 노드는 데이터베이스 갱신과 로그 등으로 쓰기가 잦으므로 SSD의 총 쓰기 가능 용량(TBW)이 여러 해 운영에 충분한지 확인하라고 합니다. 용량은 2025년 1월 기준 2 TB로도 아직 동작하지만 체인이 매일 커지므로 4 TB가 더 오래 버틴다고 봅니다. 과거 데이터 저장 부담을 줄이려는 히스토리 만료(history expiry)는 시점이 불확실하다고 적습니다.

메모리: 검증자에 64 GB를 권하는 이유

검증자(attester와 로컬 블록 빌더)에 64 GB를 권하는 근거는 네 가지입니다. 첫째, EL과 CL 클라이언트를 함께 돌리면 메모리를 많이 쓰며 상태 캐시(state cache)가 RAM 사용량의 대부분을 차지합니다. 둘째, 메모리를 많이 쓰는 일부 클라이언트 조합은 16 GB에서 실제로 실패한 이력이 있습니다. 클라이언트별로 캐시 크기를 조정하면 돌릴 수는 있지만 원문은 평균적인 사용자가 그렇게 조정한다고 가정하지 않습니다. 셋째, zk-STARK 메모리 사용량을 다룬 예비 벤치마크에 따르면 암호학 연산이 상당한 RAM을 요구할 수 있습니다. 넷째, 전체 장비 비용에 비해 32 GB에서 64 GB로 올리는 비용은 작지만 안정성이 좋아지고 zk-STARK에 대비하기에도 유리합니다. 풀노드는 32 GB로 둡니다.

CPU: 싱글스레드와 멀티스레드 모두

원문의 CPU 항목은 짧습니다. Attester와 로컬 블록 빌더는 싱글스레드 성능과 멀티스레드 성능이 둘 다 높을 때 이득을 본다고 적습니다. 표에서는 두 역할 모두 8코어 16스레드에 PassMark 약 3500 ST / 25000 MT를, 풀노드는 4코어 8스레드에 약 1000 ST / 3000 MT를 권장합니다. 코어와 스레드 수만 적지 않고 PassMark 싱글스레드(ST)와 멀티스레드(MT) 점수를 함께 적어 기준을 잡습니다. 원문 각주는 ST 3500, MT 25000이 2024~2025년 무렵 중상급 서버 CPU 수준이라고 설명합니다.

대역폭: 역할별 근거와 MEV-Boost 사용 시

로컬 블록 빌더는 다운로드 100 Mbps, 업로드 50 Mbps입니다. 블록 배포는 대역폭을 많이 씁니다. 속도가 모자라면 전파가 늦어져 늦은 블록(late block)을 만들 위험이 있습니다. 극단적인 경우 대역폭이 낮은 노드는 느린 전파를 피하려고 블록을 덜 채우거나 블롭(blob)을 적게 넣어 제안할 수도 있습니다. Attester는 50 Mbps / 25 Mbps입니다. ethPandaOps 시뮬레이션에서 네트워크의 40%가 기가비트, 60%가 업로드 15 Mbps인 조건으로 15 Mbps까지 시험했지만 실제 성능은 피어 네트워크 구조에 좌우되므로 예측하기 어려운 요인에 대한 여유분으로 25 Mbps를 택했습니다. MEV-Boost를 쓰는 검증자도 50 Mbps / 25 Mbps인데, 릴레이와의 통신은 번들과 블록 헤더를 받는 정도이고 릴레이도 블록을 함께 전파하기 때문입니다. 다만 릴레이가 응답하지 않거나 MEV 보상이 MEV-Boost에 설정한 최소값보다 낮으면 로컬 블록을 직접 만들게 되므로 그때는 로컬 블록 빌더 권장치가 적용됩니다. 풀노드는 50 Mbps / 15 Mbps로, 샘플링에 참여하고 체인 tip을 따라가지만 지연에 덜 민감합니다. 대역폭이 심하게 부족하면 한 슬롯 이상 뒤처질 수 있습니다.

프로토콜 변경 없음, 이후 EIP에 대한 권고

이 EIP는 정보성(Informational) 유형이라 프로토콜을 바꾸지 않으며 호환성 문제도 없습니다. 대신 앞으로 나오는 EIP가 이 하드웨어 권장 사양에 어떤 영향을 주는지 평가를 포함하도록 권고합니다. 새 제안이 저장장치, 메모리, CPU, 대역폭 중 어느 것을 더 요구하는지 제안 단계에서 따져 보라는 뜻입니다. 보안 고려 사항은 해당 없음(N/A)으로 적혀 있습니다. 저작권은 CC0로 포기했습니다.

상태: 살아있는 문서로 유지, 포크마다 갱신

원문 상태는 Living입니다. 한 번 확정되고 끝나는 문서가 아니라 계속 갱신되는 문서라는 뜻이므로 표의 수치는 앞으로 바뀔 수 있습니다. 콜 기록을 보면 08.29 AMA #14와 09.21 ACDT #97에서 논의가 있었지만 결정은 없었습니다. 10.12 ACDT #100에서는 하드웨어 권장 사양 EIP-7870을 포크마다 새 EIP로 쪼개지 않고 하나의 살아있는 문서(living document)로 유지하며 포크별 이력을 덧붙여 갱신하기로 확정했습니다. 사용자가 사양을 찾을 때 혼란을 줄이려는 결정입니다. 이 페이지의 수치는 2025년 1월 작성 시점의 원문을 옮긴 것이므로, 이후 갱신된 내용은 원문을 확인하는 것이 좋습니다.

EIP 원문 · ← EIPs