이더리움 검증자 슬래싱 완벽 정리: 벌금·원인·예방 방법

이더리움 검증자를 운영하면 작은 공공 인프라를 24시간 관리하는 기분이 들 수 있어요. 대부분의 날은 조용하지만, 키 관리 실수 한 번은 평범한 다운타임과 전혀 다른 결과를 만들 수 있습니다. 디파이와 이더리움 스테이킹을 알아보는 분이라면 “벌금을 받을 수 있나?”보다 “어떤 실수는 보상만 놓치고, 어떤 실수는 강제 퇴출로 이어지나?”를 먼저 구분해야 해요.

잠시 오프라인이 되면 일반적으로 소액의 비활성 페널티(Inactivity Penalty)가 발생합니다. 반면 **슬래싱(Slashing)**은 서로 모순되는 합의 메시지에 서명했을 때 적용돼요. 검증자는 강제로 나가게 되고 예치한 ETH 일부가 소각됩니다. 오프라인 검증자는 불편을 만들지만, 충돌하는 두 역사에 동시에 서명한 검증자는 합의 안전성을 위협하기 때문에 프로토콜이 다르게 처리하는 거예요.

이더리움 검증자 슬래싱이란?

검증자를 경기 기록지에 서명하는 심판이라고 생각해 보세요. 심판이 늦으면 수당을 놓칩니다. 하지만 같은 경기의 서로 다른 점수표 두 장에 동시에 서명하면 단순 지각으로 볼 수 없어요. 리그는 심판을 퇴출하고 보증금 일부를 가져갑니다.

이더리움도 비슷해요. 검증자는 ETH를 경제적 담보로 맡기고 블록과 체크포인트(Checkpoint)에 관한 메시지에 서명합니다. 한 검증자가 동시에 참일 수 없는 메시지에 서명했다는 암호학적 증거가 체인에 제출되면 슬래싱이 처리돼요. 해당 검증자는 slashed 상태로 표시되고 강제 종료 절차에 들어갑니다. 같은 검증자 신분으로 다시 복귀할 수도 없어요.

슬래싱은 회사가 임의로 부과하는 위약금이 아닙니다. 조건과 상태 변경 방식은 이더리움 지분증명(Proof of Stake) 프로토콜에 정의되어 있어요. 현재 이더리움 합의 사양에는 슬래싱 가능한 블록 제안과 어테스테이션(Attestation)을 판별하고 페널티를 적용하는 로직이 공개돼 있습니다.

슬래싱과 다운타임 페널티의 차이

두 용어가 자주 섞이지만 서로 다른 사건이에요.

사건	대표 원인	프로토콜 처리	강제 퇴출
보상 누락	임무 지연·누락	받을 보상을 받지 못함	아니요
비활성 페널티	소스·타깃 투표 누락	잔액 감소	아니요
비활성 누수	여러 에포크 동안 최종성 중단	최종성 회복까지 비활성 잔액이 더 빠르게 감소	그 자체로는 아니요
슬래싱	모순되는 블록 제안·투표	즉시 페널티, 지속 페널티, 상관관계 페널티	예

ethereum.org의 공식 설명에 따르면 블록 제안 임무를 놓쳤다고 별도 벌금을 내는 것은 아니며, 받을 수 있었던 제안 보상을 놓칩니다. 필수 어테스테이션을 빠뜨리면 잔액이 줄 수 있지만, 다운타임 자체는 세 가지 슬래싱 조건에 포함되지 않아요.

홈 스테이커에게는 중요한 차이예요. 공유기가 재부팅되거나 잠깐 정전됐다고 즉시 치명적인 슬래싱이 발생하지는 않습니다. 가용성도 중요하지만, 같은 키의 중복 서명이 더 날카로운 운영 리스크예요.

슬래싱이 발생하는 세 가지 조건

이더리움은 블록 제안 관련 위반 한 가지와 어테스테이션 관련 위반 두 가지를 정의합니다.

1. 이중 제안(Double Proposal)

한 검증자가 같은 슬롯(Slot)에 서로 다른 비콘 블록 두 개를 제안하고 서명하면 안 됩니다. 동일한 검증자 키가 두 서버에서 동시에 활성화되고, 양쪽 모두 자신이 블록을 제안해야 한다고 판단할 때 발생할 수 있어요.

2. 이중 투표(Double Vote)

같은 타깃 에포크(Target Epoch)를 대상으로 서로 다른 두 어테스테이션을 제출하면 안 됩니다. 쉽게 말해, 같은 체크포인트 투표 라운드에서 충돌하는 후보 두 곳에 동시에 표를 주는 행위예요.

3. 서라운드 투표(Surround Vote)

새 어테스테이션의 소스·타깃 체크포인트 범위가 이전 어테스테이션을 감싸거나, 반대로 이전 범위 안에 들어가면 안 됩니다. 이 규칙은 서로 양립할 수 없는 최종화 역사에 동시에 힘을 싣는 일을 막아요.

세 조건은 운영자의 의도가 아니라 서명된 데이터를 기준으로 판단합니다. “실수로 키를 두 번 실행했다”는 설명이 모순된 두 서명을 없애주지는 않아요. 그래서 예방의 핵심은 키 이전 절차와 슬래싱 보호 데이터베이스(Slashing Protection Database)에 있습니다.

슬래싱 이후에는 무슨 일이 생길까요?

슬래싱은 고정 벌금 한 번으로 끝나는 사건이 아니라 여러 단계의 절차예요.

1. 증거가 온체인에 포함됩니다. 블록 제안자가 유효한 proposer-slashing 또는 attester-slashing 객체를 포함해요.
2. 초기 페널티가 적용됩니다. 현재 포크(Fork)의 페널티 매개변수에 따라 검증자 잔액이 줄어요.
3. 강제 종료가 시작됩니다. 검증자는 퇴출 대상으로 예약되고, 출금 지연 기간에도 페널티를 받을 수 있어요.
4. 상관관계 페널티(Correlation Penalty)가 계산됩니다. 같은 기간에 많은 검증자가 함께 슬래싱될수록 손실이 커집니다.
5. 남은 잔액이 최종적으로 출금 가능해집니다.

상관관계 페널티는 의도된 설계예요. 검증자 한 명의 고립된 실수와, 단일 사업자가 관리하는 수천 개 검증자의 동시 충돌은 네트워크에 주는 위험이 다릅니다. 하나의 클라이언트 버그, 잘못된 중복 배포, 원격 서명기(Remote Signer) 장애가 여러 키를 동시에 건드리면 상관 슬래싱 리스크가 커져요.

특정 ETH 손실 수치를 영구적인 값처럼 외우면 안 됩니다. 이더리움은 업그레이드를 거치며 검증자 잔액 회계와 페널티 매개변수를 바꿔 왔어요. 최종 기준은 프로토콜 사양이며, 대시보드와 블로그는 요약 자료입니다.

비활성 누수(Inactivity Leak)는 슬래싱이 아니에요

이더리움은 일반적으로 활성 스테이크의 3분의 2 이상이 투표해야 체크포인트를 최종화할 수 있어요. 네 에포크 넘게 최종성이 멈추면 프로토콜은 비활성 누수를 활성화합니다. 오프라인 검증자의 잔액을 점진적으로 줄여 온라인 검증자의 비중이 다시 3분의 2를 넘게 만들고 최종성을 회복하는 장치예요.

이 과정은 슬래싱이 아닙니다. 모순되는 서명 증거가 필요하지 않고, 오프라인 검증자가 슬래싱 위반으로 자동 강제 퇴출되는 것도 아니에요. 다만 네트워크 전체의 최종성 장애가 길어지면 페널티가 커질 수 있습니다.

실전에서는 두 가지 집중도를 살펴야 해요.

• 서명 집중도: 많은 검증자가 하나의 키 관리·서명 장애를 공유하면 함께 슬래싱될 수 있어요.
• 가용성 집중도: 많은 검증자가 같은 클라우드 리전, 클라이언트, 네트워크에 의존하면 함께 오프라인이 될 수 있어요.

클라이언트 다양성과 인프라 분산은 두 위험을 낮추지만 완전히 없애지는 못합니다.

실수로 슬래싱되는 대표 상황

대부분의 운영자는 합의를 공격하려고 하지 않아요. 위험한 사건은 주로 배포 과정에서 발생합니다.

같은 키를 두 서버에서 실행

새 서버로 이전한 뒤 새 검증자가 작동하는 것을 보고 기존 프로세스도 멈췄다고 착각할 수 있어요. 두 인스턴스가 같은 임무에 서명하면 네트워크에 슬래싱 가능한 메시지가 제출될 수 있습니다.

오래된 보호 데이터베이스 복원

합의 클라이언트는 과거 서명 기록을 로컬 슬래싱 보호 데이터베이스에 저장합니다. 최신 기록 없이 검증자 키만 복원하면 새 설치가 과거 서명과 충돌하는 메시지에 서명할 수 있어요.

위험한 자동 장애조치

일반 서버에서는 액티브-액티브(Active-Active) 구성이 가용성을 높여줘요. 하지만 검증자 서명에는 위험합니다. 네트워크가 분리돼 양쪽이 모두 자신을 주 서버라고 판단하면 둘 다 서명할 수 있어요. 검증자 이중화는 독립적인 핫 카피 두 개가 아니라 단일 권위 서명기를 중심으로 설계해야 합니다.

공통 운영자·클라이언트 장애

스테이킹을 위임해도 슬래싱이 사라지지는 않아요. 사업자가 많은 검증자를 같은 운영 스택으로 관리할 수 있습니다. 리퀴드 스테이킹(Liquid Staking)과 풀 스테이킹은 책임을 다르게 분배하지만, 사용자는 여전히 프로토콜·사업자·스마트 컨트랙트 위험을 부담해요. 이더리움 스테이킹 방식 가이드에서 각 구조를 비교할 수 있습니다.

슬래싱 예방 체크리스트

첫 실행, 서버 이전, 복구, 장애조치 전에 확인하세요.

• 검증자 키마다 활성 서명기는 정확히 하나만 둔다.
• 새 검증자를 시작하기 전 기존 검증자를 중지하고 더 이상 서명하지 않는지 확인한다.
• 기존 합의 클라이언트에서 슬래싱 보호 기록을 내보내고 새 클라이언트로 가져온다.
• 이전·새 클라이언트 양쪽의 공식 내보내기·가져오기 절차를 따른다.
• 검증자 키스토어와 출금 자격증명(Withdrawal Credentials)을 분리해 통제된 방식으로 백업한다.
• 운영 검증자를 옮기기 전 테스트넷 또는 비운영 키로 이전 절차를 시험한다.
• 임의로 만든 액티브-액티브 구성을 피한다.
• 임무 누락, 클라이언트 상태, 시간 동기화, 디스크 공간, 피어 수를 모니터링한다.
• 실행·합의 클라이언트의 보안 공지를 구독한다.
• 다른 운영자도 기존 서명기를 안전하게 끌 수 있도록 중지 절차를 문서화한다.

스테이킹 사업자를 평가하는 질문

직접 검증자를 운영하지 않는다면 상관 리스크를 드러내는 질문을 해보세요.

1. 원격 서명기 또는 분산 검증자 기술(DVT)을 사용하나요?
2. 같은 키를 두 인스턴스가 사용하는 일을 어떻게 막나요?
3. 어떤 실행·합의 클라이언트를 사용하나요?
4. 검증자를 여러 리전과 인프라 사업자에 분산했나요?
5. 슬래싱 손실은 운영자, 보험 풀, 예치자 중 누가 부담하나요?
6. 보상 조건은 계약상 의무인가요, 재량인가요? 한도와 제외 조건은 무엇인가요?
7. 검증자 성과와 슬래싱 사건을 온체인에서 확인할 수 있나요?

“보호됨”, “보험 적용” 같은 문구만 믿으면 안 돼요. 제외 조건을 읽고, 보상 주체가 지급 능력을 유지해야만 보상되는 구조인지 확인하세요.

자주 묻는 질문

검증자가 오프라인이기만 해도 슬래싱되나요?

아니요. 오프라인 검증자는 보상을 놓치고 비활성 페널티를 받을 수 있지만, 일반 다운타임 자체는 슬래싱 조건이 아닙니다. 다만 체인이 최종화되지 않아 비활성 누수가 작동하면 손실 속도가 빨라질 수 있어요.

슬래싱을 되돌릴 수 있나요?

프로토콜 슬래싱은 유효한 암호학적 증거를 바탕으로 처리되며 고객센터 요청으로 되돌릴 수 없어요. 사업자가 별도 약관에 따라 사용자에게 보상할 수는 있지만, 온체인 사건 자체가 취소되는 것은 아닙니다.

슬래싱되면 32 ETH를 전부 잃나요?

반드시 그렇지는 않아요. 총손실은 현재 프로토콜 매개변수, 이후 누적 페널티, 상관관계 기간에 함께 슬래싱된 스테이크 규모에 따라 달라집니다. 대규모 동시 사건은 고립된 실수보다 훨씬 심각할 수 있어요. 고정된 과거 수치 대신 최신 프로토콜 문서를 확인하세요.

리퀴드 스테이킹에는 슬래싱 리스크가 없나요?

아니요. LST 보유자가 검증자를 직접 돌리지는 않지만, 기초 검증자 집합은 여전히 슬래싱될 수 있습니다. 손실을 노드 운영자, 토큰 보유자, 준비금, 보험 장치 중 누가 부담하는지는 각 프로토콜 설계에 따라 달라요.

리스테이킹 슬래싱과 이더리움 슬래싱은 같은가요?

아니요. 이더리움 합의 슬래싱은 이더리움 자체 규칙을 보호합니다. 리스테이킹 시스템은 다른 서비스와 연결된 별도 조건을 추가할 수 있어요. 보상이 겹치는 만큼 손실 경로도 늘어날 수 있으니 함께 평가해야 합니다.

핵심 정리

이더리움 슬래싱은 적용 범위가 좁지만 결과는 무겁습니다. 오프라인은 일반적으로 성능 문제이고, 서로 모순되는 합의 메시지 서명은 검증자를 강제 퇴출시키는 안전성 위반이에요. 솔로 스테이커에게 가장 중요한 통제 원칙은 단순합니다. 키 하나, 권위 있는 서명기 하나, 최신 슬래싱 보호 기록 하나를 유지하세요.

서버를 이전할 때마다 최신 클라이언트 문서를 확인하고, 가능한 범위에서 의존성을 분산하며, 사업자의 손실 책임을 약관으로 검증하세요. 스테이킹 보상은 변하고 ETH 가격은 크게 움직일 수 있으며 운영 실패는 원금도 줄일 수 있습니다. 잃어도 감당할 수 있는 자금만 사용하고 스스로 조사하세요(DYOR). NFA.