본문으로 이동
Financial Context Wiki

풀 노드

검증을 중심으로 풀 노드, 이더리움 실행·합의 클라이언트, 동기화 체크포인트, 현재·과거 상태, 프루닝, RPC 프라이버시, 최종성과 운영 용량을 설명합니다.

업데이트

교육 참고용이며 투자 또는 보안 조언이 아닙니다. 풀 노드도 올바른 소프트웨어, 체인·체크포인트 설정, 정상적인 피어, 적시 업그레이드, 로컬 보안, 저장장치 및 네트워크 가용성에 의존합니다.

직접 답변

풀 노드는 프로토콜에 필요한 데이터를 내려받아 로컬 합의 규칙과 실행 규칙에 따라 블록과 상태 전이를 검증하고, 이 규칙이 선택한 체인을 따릅니다. RPC 제공자에게 판단을 맡기지 않고 피어의 유효하지 않은 데이터를 거부할 수 있습니다. 여기서 ’풀’은 검증 책임을 뜻하며, 모든 과거 상태의 영구 보관, 블록 생성, 스테이킹, 공개 API 제공 또는 소프트웨어·설정 오류에 대한 면역을 뜻하지 않습니다.

지분증명 이더리움에서 정상적인 풀 노드는 실행 클라이언트와 합의 클라이언트를 함께 운영합니다. 실행 클라이언트는 트랜잭션과 실행 페이로드를 검증하고 현재 실행 상태를 유지하며 JSON-RPC를 제공합니다. 합의 클라이언트는 합의 객체를 검증하고 포크 선택을 적용하며 정당화와 최종 확정을 추적합니다. 검증자 클라이언트는 선택 사항이며, 스테이킹 검증자가 제안과 증명을 수행할 때만 필요합니다.

작동 방식

  1. 검증 목표와 네트워크 스냅샷을 정의합니다. 프로토콜, 체인과 제네시스 식별자, 포크 일정, 예상 chainId, 현재 및 최종 확정 블록 해시, 클라이언트 버전, 동기화 방식, 체크포인트 출처, 프루닝 방식, RPC 메서드, 과거 상태 범위, 필요한 가용성을 기록합니다. 풀 노드의 요건은 체인마다 다릅니다.
  2. 독립된 경로에서 받아 검증한 클라이언트 릴리스를 설치하고 필요한 구성요소를 연결합니다. 현재 이더리움에서는 인증된 로컬 Engine API로 실행 클라이언트 하나와 합의 클라이언트 하나를 연결하고, 스테이킹할 때만 검증자를 추가합니다. 데이터 디렉터리, P2P 포트, RPC 노출 범위, 서명자 또는 검증자 키를 분리합니다.
  3. 의도한 신뢰 기준점에서 부트스트랩합니다. 제네시스 전체 동기화는 제네시스부터 순방향으로 검증합니다. 실행 계층의 snap sync는 비교적 최근의 인증된 상태에서 상태를 구축·복구하고, 합의 계층의 체크포인트 동기화는 약한 주관성 체크포인트에서 시작해 이후 블록을 검증합니다. 데이터베이스를 신뢰하기 전에 제네시스 정보, 체크포인트 루트, 체인 ID, 포크 다이제스트와 최종 확정 헤드를 독립된 경로로 교차 확인합니다.
  4. 두 처리 경로를 모두 감시합니다. 실행·합의 피어, 헤드 및 최종 확정 지연, Engine API 상태, 상태 루트 일치, 시각 동기화, 디스크 증가량, 입출력, 메모리, CPU, 데이터베이스 오류와 포크 준비 상태를 확인합니다. ’동기화 완료’는 필요한 클라이언트가 의도한 체인에 합의하고 유효한 데이터를 계속 가져오는 상태여야 합니다.
  5. 보존 정책을 조회 요건에 맞춥니다. 프루닝 풀 노드는 현재 상태와 검증에 충분한 블록·영수증·스냅샷 데이터를 보관하지만, 오래된 상태를 재생성해야 하거나 과거 상태 조회를 거부할 수 있습니다. 아카이브 설정은 과거 상태를 구체화해 특정 시점 조회를 빠르게 합니다. 상태 프루닝, 블록·영수증 이력, 합의 데이터베이스, blob 보존 기간, 오프체인 인덱스는 각각 독립적이고 클라이언트·설정에 따라 달라지는 범위입니다. 라이트 클라이언트는 더 제한된 커밋 경로를 검증하고 추가 데이터를 요청하므로 단순히 작은 풀 노드가 아닙니다.
  6. 필요한 RPC 표면만 공개합니다. 관리 API와 Engine API는 로컬에 바인딩하고 클라이언트를 인증하며, 호스트 방화벽과 애플리케이션 RPC 속도 제한을 설정합니다. 통제 장치 없이 debug, trace, 계정 또는 트랜잭션 풀 메서드를 공개하지 않습니다. 대상 노드에서 latest, safe, finalized 태그, 과거 호출, 로그와 트랜잭션 제출을 시험하고, 독립적으로 확인한 엔드포인트만 장애 조치 대상으로 사용합니다.
  7. 대조하고 복구를 연습합니다. 다른 구현의 클라이언트 또는 독립 노드와 블록 해시, 상태 루트, 최종 확정 체크포인트를 비교합니다. 정상 종료, 스냅샷과 복원, 데이터베이스 재구축, 클라이언트 업그레이드, 포크 활성화, 디스크 교체, 피어 단절, RPC 장애 조치를 연습합니다. 로그와 설정을 보존하고, 노드가 검증한 출력과 프런트엔드·오라클·브리지·애플리케이션의 주장을 구분합니다.

계산 예시

  • 대역폭 모델. 어떤 체인이 12 seconds마다 블록 하나를 만들고, 내려받는 평균 블록 본문과 필요한 부가 데이터가 150 kB라고 가정합니다. 노드는 하루에 86,400 / 12 = 7,200 blocks/day를 처리하고 십진 단위로 7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day를 내려받습니다. P2P 오버헤드, 재시도, 합의 트래픽, 스냅샷과 업로드는 제외했습니다. 이는 용량 계획 가정이지 이더리움의 실시간 상수가 아닙니다.
  • 디스크 여유 공간. 프루닝 노드가 1.20 TB에서 시작하고 측정된 데이터베이스 증가율이 18 GB/month라고 가정합니다. 30 months 후 모델 사용량은 1,200 + 18 * 30 = 1,740 GB입니다. 예측치보다 25%의 여유를 두면 필요한 용량은 1,740 * 1.25 = 2,175 GB, 즉 십진 단위 2.175 TB입니다. 클라이언트 변경, 프루닝과 포크는 선형 모델을 무효화할 수 있습니다.
  • 운영 가용성. 30 days = 720 hours 동안 실행 클라이언트 유지보수에 2 hours, 합의 클라이언트 장애에 3 hours, 서로 겹치지 않는 공통 정전에 1 hour가 들었다고 가정합니다. 중단 시간은 총 6 hours, 관측 가용성은 (720 - 6) / 720 = 99.1666666667%입니다. 프로세스가 실행 중이어도 오래된 상태이거나 네트워크에서 분리되거나 잘못된 체인에 있을 수 있으므로 프로세스 가동 시간만으로는 부족합니다.
  • 과거 상태 재생성. 프루닝 클라이언트에 블록 18,000,000의 사용 가능한 스냅샷이 있고 블록 18,250,000의 상태가 필요하다고 가정합니다. 250,000 blocks를 재실행해야 합니다. 측정 속도가 500 blocks/second라면 이상적 계산 시간은 250,000 / 500 = 500 seconds = 8.3333333333 minutes입니다. 상태 읽기, 영수증, 재구성 처리와 캐시 미스는 제외했습니다. 아카이브 노드는 더 많은 저장 공간과 과거 상태의 빠른 직접 접근을 맞바꿉니다.

위험

  • 잘못된 체인, 제네시스, 포크 일정 또는 chainId에 연결합니다.
  • 악의적이거나 오래되었거나 충분히 교차 확인하지 않은 동기화 체크포인트를 신뢰합니다.
  • 네트워크 업그레이드 시점에 오래된 클라이언트를 실행합니다.
  • 합의·실행 클라이언트가 불일치하거나 Engine API 연결을 잃습니다.
  • 클라이언트 구현 오류로 잘못된 데이터를 수락·거부·제공합니다.
  • 클라이언트 단일화로 노드와 네트워크가 상관된 장애에 노출됩니다.
  • 피어가 너무 적거나 이클립스 공격, 악성 또는 편중된 피어에 노출됩니다.
  • 시계 오차가 합의 임무, 타임스탬프 또는 피어 동작을 훼손합니다.
  • 디스크 고갈, 느린 저장장치, 파일시스템 장애 또는 데이터베이스 손상이 발생합니다.
  • 프로세스 가동 시간을 동기화·정규 체인 추적·최종 확정 상태로 오인합니다.
  • 재구성 중 헤드, safe, finalized 상태를 혼동합니다.
  • 프루닝 풀 노드가 모든 과거 상태 조회에 즉시 답할 수 있다고 가정합니다.
  • 아카이브 노드가 모든 오프체인 인덱스, 추적 데이터, 애플리케이션 레이블을 저장한다고 가정합니다.
  • 인증되지 않은 Engine, admin, debug, trace 또는 트랜잭션 풀 API를 노출합니다.
  • RPC 로그로 지갑 주소, 조회, 메타데이터 또는 트랜잭션 의도가 유출됩니다.
  • RPC 과부하, 무제한 조회 또는 서비스 거부가 블록 검증 자원을 빼앗습니다.
  • 백업 또는 스냅샷 복원으로 오래되거나 내부적으로 불일치한 데이터가 생깁니다.
  • 검증자 또는 서명 키를 노드 서비스와 부주의하게 함께 배치해 잃습니다.
  • 로컬에서 검증한 체인 데이터를 프런트엔드, 오라클 또는 브리지의 정직성 증명으로 취급합니다.
  • 이더리움의 이중 클라이언트, 프루닝 또는 약한 주관성 모델을 다른 체인에 적용합니다.

흔한 오해

  • 모든 풀 노드는 모든 과거 상태를 영구 보관하는 아카이브 노드입니다.
  • 풀 노드를 운영하면 자동으로 검증자나 블록 제안자가 됩니다.
  • 노드가 ’동기화 완료’라고 표시하면 의도한 정규·최종 확정 체인에 반드시 있습니다.
  • RPC를 자체 호스팅하면 모든 신뢰, 프라이버시, 소프트웨어와 운영 위험이 사라집니다.
  • 디스크, 피어 또는 가동 시간만 늘리면 올바른 검증과 네트워크 보안이 입증됩니다.

관련 주제

출처

탐색

위키 검색...