이더리움 검증자와 슬래싱: 의무·패널티·키 관리

이더리움 검증자는 슬롯·에포크마다 블록 제안이나 증명 등 배정된 합의 의무를 수행합니다. 단순 오프라인은 일반 패널티를 낳을 수 있지만, 같은 슬롯의 이중 제안·이중 투표·surround vote 같은 모순 서명은 슬래싱과 강제 퇴출 대상입니다. 중복 실행과 서명 이력 이전이 핵심 운영 위험입니다.

검증자는 단순히 거래를 확인하는 서버가 아니다

활성 검증자는 합의 계층에서 블록 제안, 블록에 대한 증명, sync committee 참여 같은 의무를 배정받는다. 실행 클라이언트가 거래 결과를 처리하고 합의 클라이언트가 체인 선택과 최종성 투표를 담당하며 validator client가 키로 메시지에 서명한다.

정상 보상은 정확하고 제때인 증명, 블록 제안, 위원회 참여에서 나온다. 기본 보상은 유효 잔액과 전체 활성 지분 등에 따라 달라져 고정 수익률이 아니다. 운영자는 합의·실행 클라이언트 연결과 시스템 시간을 유지해야 한다.

Ethereum rewards and penalties는 보상·일반 패널티·슬래싱·inactivity leak을 구분한다. 홍보 APY보다 각 의무와 실패 비용을 먼저 이해해야 한다.

슬래싱은 실수 전체가 아니라 특정 모순 서명이다

같은 슬롯에 서로 다른 블록 두 개를 제안하거나 같은 target epoch에 서로 다른 증명을 하는 이중 투표, 다른 투표를 둘러싸는 surround vote가 대표 조건이다. 이런 메시지는 두 체인을 동시에 지지해 최종성 안전성을 해칠 수 있다.

슬래싱되면 일부 지분이 즉시 손실되고 강제 퇴출 절차가 시작되며, 비슷한 시기에 많은 검증자가 함께 슬래싱되면 상관 패널티가 커진다. 정확한 금액과 기간은 프로토콜 업그레이드로 바뀔 수 있어 최신 사양을 확인한다.

고가용성 복제가 오히려 이중 서명을 만들 수 있다

웹 서버처럼 같은 검증자 키를 두 장비에서 동시에 능동 실행하면 두 노드가 서로 다른 헤드나 슬롯 정보에 서명할 수 있다. 단순 active-active 복제는 슬래싱 위험이다. 장애 조치는 한 인스턴스가 완전히 멈춘 것을 확인하고 안전한 인계 절차를 따라야 한다.

키 원본과 서명기는 최소화하고, 원격 서명기·slashing protection DB의 일관성을 유지한다. 클라우드 자동 복구가 이전 인스턴스를 종료하지 않은 채 새 인스턴스를 띄우지 않는지 점검한다.

클라이언트 이전에는 서명 이력을 함께 옮긴다

키스토어만 복사하면 새 클라이언트가 과거에 어떤 블록과 증명에 서명했는지 모를 수 있다. EIP-3076은 검증자 클라이언트 사이에 slashing protection 서명 이력을 옮길 JSON 형식을 정의한다.

이전 전 원본 검증자를 정상 종료하고 데이터베이스를 export하며, 대상에서 import 성공과 검증자 pubkey 범위를 확인한다. 네트워크와 genesis validators root가 맞는지 확인한 뒤 충분한 중단 간격과 모니터링을 두고 시작한다.

• 동일 validator key의 실행 인스턴스 목록 확인
• 합의·실행 클라이언트 동기화와 시간 확인
• slashing protection DB 백업·export 검증
• 이전 전 원본 프로세스 완전 종료
• fee recipient와 withdrawal credentials 구분

서명 키와 출금 자격증명은 역할이 다르다

검증자 서명 키는 일상 합의 의무에 쓰여 온라인 노출이 필요하다. 출금 자격증명은 보상과 출금이 향하는 실행 주소 등을 정한다. 서명 키 침해는 슬래싱·운영 방해를 만들 수 있지만 출금 주소 제어와 동일한 권한이라고 단정할 수 없다.

반대로 출금 주소를 잘못 설정하거나 통제하지 못하면 검증자 종료 후 자산 회수가 어렵다. 예치 데이터 생성 단계에서 네트워크, 검증자 pubkey, withdrawal credentials, 입금 금액과 공식 deposit contract 주소를 오프라인으로 재확인한다.

상관 위험을 줄이는 운영 선택

많은 검증자가 같은 클라이언트, 클라우드 지역, 전원, 원격 서명 인프라를 공유하면 하나의 버그나 장애가 동시 패널티로 확대될 수 있다. 상관 패널티 설계는 동시 실패를 더 심각하게 취급한다.

클라이언트 다양성은 단순 설치 수가 아니라 실제 지분 분포와 운영 독립성이 중요하다. 소수 클라이언트를 선택할 때는 버전 지원과 운영 역량을 고려하고, 검증하지 않은 급한 전환으로 새 위험을 만들지 않는다.

검증자 운영의 가장 위험한 복구는 멈춘 키를 두 곳에서 동시에 되살리는 것이다.

JOBCOIN 해설

운영 점검을 증거로 남기는 방법

모니터링에는 head·finalized epoch, peer 수, execution endpoint 상태, duty 수행과 누락, validator balance, 클라이언트 버전을 포함한다. 외부 대시보드와 로컬 로그를 대조하되 외부 API 지연을 실제 오프라인으로 단정하지 않는다.

업데이트 전 릴리스 노트와 하드포크 지원을 확인하고 서명기·DB 백업을 검증한다. 재시작 후 이전 프로세스 PID가 남지 않았는지, 같은 pubkey가 다른 호스트에서 활성화되지 않았는지 확인한다.

장애 보고는 ‘슬래싱됨’과 ‘패널티 발생 가능’을 구분한다. 실제 슬래싱은 온체인 slashing 이벤트와 강제 퇴출 상태로 확인하고, 단순 missed attestation은 별도 집계한다.

자주 묻는 질문