Solana에 슬래싱 도입하기

소개

슬래싱은 악의적이거나 부주의한 검증인 행동에 페널티를 부과해 네트워크 보안을 유지하는 메커니즘입니다. 위반 행위가 확인되면 해당 검증인에게 위임된 스테이킹 지분 일부를 소각합니다.

이는 Solana와 같은 지분증명(Proof of Stake, PoS) 네트워크의 고유한 기능이며, 작업증명(Proof of Work, PoW)에는 이에 상응하는 기능이 없습니다. 스테이킹된 자산을 소각해 프로토콜이 직접 금전적 페널티를 집행할 수 있어야 하기 때문입니다. PoW에서는 블록체인이 부정 행위자의 물리적 채굴 하드웨어를 압수하거나 파괴할 수 없으므로 이와 유사한 메커니즘이 없습니다.

슬래싱은 몇 가지 주요 이점을 제공합니다.

• 악의적 활동을 직접 억제하는 경제적 장치로 작동합니다
• 스테이커가 평판이 좋은 여러 검증인에게 지분을 분산하도록 유도해 탈중앙화를 개선합니다
• 대규모 운영자가 공통 장애 위험을 줄이는 이기종 인프라를 구축하도록 유도합니다(예: Firedancer와 Agave 클라이언트에 지분 분산).
• 검증인이 슬래싱 위반을 피하고 다른 참여자의 악의적 활동을 탐지함으로써 차별화하고 평판을 쌓을 수 있는 또 하나의 지표를 제공합니다.

Solana는 역사적으로 소셜 슬래싱이라 불리는 수동적이고 커뮤니티 주도적인 합의 방식에 의존해 왔습니다. 이 모델에서는 검증인이 네트워크의 활성 상태나 안전성을 훼손하는 등 악의적으로 행동할 경우, 정직한 참여자들이 오프체인에서 협력해 하드 포크를 시작하고 네트워크를 재가동하면서 위반자의 지분을 슬래싱할 수 있습니다. 이 방식은 사안별로 유연하게 판단할 수 있지만, 조율 비용이 크고 본질적으로 사후 대응에 그칩니다.

현재까지 Solana에서 슬래싱된 검증인은 없습니다. Solana에서 슬래싱과 가장 유사한 사건은 메인넷 출시 2개월 후인 2020년 5월에 발생했습니다. 당시 Solana Foundation은 마켓 메이커에 공개하지 않은 토큰 대여가 있었다는 커뮤니티의 우려에 대응해 자체 할당량에서 1,136만 SOL을 자발적으로 소각했습니다. 이에 따라 총 토큰 공급량은 5억 SOL에서 4억 8,864만 SOL로 2.3% 감소했습니다. 공식적인 슬래싱 사건은 아니었지만, 이 소각은 신뢰를 회복하고 초기 커뮤니티가 제기한 투명성 문제를 해소하기 위한 자발적 페널티로 기능했습니다.

수년간 Solana가 더 공식적인 슬래싱 메커니즘을 도입해야 한다는 요구가 이어졌습니다. 흔히 프로그래밍 방식 슬래싱이라고 하며, 프로토콜에 내장된 프로그램을 통해 온체인에서 직접 집행하는 방식입니다. 이 시스템에서는 검증인이 특정 프로토콜 규칙을 위반하면 위반 사실을 입증하는 암호학적 증명을 생성해 전용 프로그램에 제출할 수 있으며, 프로그램이 자동으로 슬래싱을 실행합니다. 이 모델은 사람 간 조율에 대한 의존도를 낮추고 네트워크 운영을 중단하지 않고도 경미한 위반을 제재할 수 있어, 확장 가능하고 탈중앙화된 책임 체계의 기반을 마련합니다.

곧 예정된 SIMD-0204: 슬래싱 가능 이벤트 검증 기능 게이트 활성화는 메인넷에 공식적인 프로그래밍 방식 슬래싱을 구현하기 위한 Solana의 첫 번째 중대한 단계입니다. 이 보고서의 뒷부분에서 살펴보겠지만, 블록체인 네트워크에서 프로그래밍 방식 슬래싱은 다행히도 드물며 페널티도 대체로 경미합니다. 하지만 검증인의 지분이 프로토콜에 의해 자동으로 소각될 수 있다는 가능성만으로도 모든 이해관계자가 신중하게 평가해야 할 새로운 위험이 생깁니다. Solana가 프로그래밍 방식 슬래싱을 집행하는 최적의 방법에는 아직 많은 미해결 문제가 있습니다. 모든 경제적 변경과 마찬가지로 슬래싱 관련 매개변수와 페널티는 커뮤니티에서 폭넓게 논의해야 하며, 최종적으로 공식 거버넌스 투표를 통해 승인되어야 합니다.

슬래싱 관련 SIMD

여러 SIMD가 Solana의 프로그래밍 방식 슬래싱 출시에 관련되어 있으며, 그중 SIMD-180과 SIMD-204가 앞으로 몇 달 안에 메인넷에 먼저 적용될 예정입니다.

첫 번째 전제 조건은 SIMD-0180: 리더 스케줄 키로 투표 계정 주소 사용입니다. 이 SIMD는 리더 스케줄에 사용되는 키를 검증인의 신원 주소에서 투표 계정 주소로 변경합니다. 검증인의 블록 생성 의무와 위임된 지분을 직접적이고 명확하게 연결하므로 정확한 슬래싱 귀속에 필수적인 변경입니다.

SIMD-0204: 슬래싱 가능 이벤트 검증은 새로운 슬래싱 프로그램을 제시합니다. 누구나 슬래싱 대상 행동의 증거를 제출하고 기록할 수 있는 온체인 메커니즘을 도입해 검증인 위반 행위에 대한 검증 가능하고 변경 불가능한 기록을 생성합니다.

마지막으로 SIMD-0212: 슬래싱은 Solana 프로토콜 내 슬래싱 구현 방안을 제시합니다. SIMD-0204가 마련한 기반 위에서 검증된 위반에 페널티를 적용합니다. 이 제안은 아직 열려 있으며 활발하게 논의되고 있습니다.

장애 탐지와 귀속

슬래싱 프로그램은 순수한 관찰 계층으로 설계되었습니다. 지분이나 보상을 변경하지 않으며, 유일한 기능은 위반을 검증하고 기록하는 것입니다. 초기 프로토타입은 이미 Testnet에서 운영 중이며, 샘플 제출 내역(예: DuplicateBlockProof 트랜잭션)에서 위반이 어떻게 기록되는지 확인할 수 있습니다.

중복 블록 생성

초기 출시 단계에서 프로그램은 한 가지 악의적 행동, 즉 중복 블록 생성 사례 탐지에 집중합니다. 리더가 동일한 슬롯에 서로 다른 버전의 블록을 두 개 이상 제출하는 행위로, 명백하고 객관적인 합의 위반입니다. 

과거 2022년 9월에는 검증인이 같은 블록 높이에서 중복 블록을 잘못 생성해 네트워크 중단이 발생했습니다. 검증인의 기본 노드와 예비 노드가 동시에 활성화되어 동일한 노드 신원을 사용하면서 서로 다른 블록을 제안했기 때문입니다.

이 문제는 이후 패치되었습니다. 현재는 운영자가 핫 스페어를 실행하더라도 여러 인스턴스가 감지되면 검증인 클라이언트가 종료되도록 보호 장치가 마련되어 있습니다. 따라서 검증인 소프트웨어를 의도적이고 악의적으로 수정하지 않는 한 중복 블록을 생성할 가능성은 극히 낮습니다.

중복 블록 생성은 실시간 탐지는 어렵지만 사후 검증은 간단한 프로토콜 위반의 예입니다. 네트워크를 중단하고 중복 블록을 모두가 관찰했는지 확인하는 동기식 대응을 조율하려면 상당한 복잡성이 추가됩니다. 대신 탐지와 슬래싱을 사후에 처리하는 편이 훨씬 실용적입니다.

제출되는 중복 블록 증명에는 같은 검증인이 서명한 동일 슬롯의 상충하는 샤드 두 개가 포함됩니다. 슬래싱 프로그램은 샤드가 유효한 중복 블록 증명을 구성하는지 확인하고, 같은 슬롯에 속하며 위반 검증인이 올바르게 서명했는지 검증합니다. 이 로직은 Solana의 gossip 프로토콜이 포크 선택 과정에서 중복 블록 증명을 처리하는 방식과 동일합니다.

struct DuplicateBlockProofData {
  shred1_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred1: &[u8]           // `shred1_length` bytes representing a shred,
  shred2_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred2: &[u8]           // `shred2_length` bytes representing a shred,
}

신고자는 증명을 구성해 온체인 버퍼 계정에 저장한 다음, 해당 버퍼 계정을 참조하는 트랜잭션을 주소 `S1ashing11111111111111111111111111111111111`의 슬래싱 프로그램에 제출합니다. 증명이 성공적으로 검증되면 결과는 향후 참조할 수 있도록 슬래싱 프로그램이 소유한 `report_account` Program Derived Address(PDA)에 저장됩니다. 따라서 슬래싱 프로그램에서 getProgramAccounts 호출만 실행하면 슬래싱 관련 데이터를 보여주는 대시보드를 쉽게 구축할 수 있습니다. 검증인은 이를 사용해 위반 신고 여부를 확인하고 필요에 따라 시정 조치를 취할 수 있습니다.

Anza는 이러한 이벤트 관찰, 증명 생성, 온체인 증명 제출을 지원하는 도구를 출시할 것으로 예상됩니다. 검증인 소프트웨어에 내장된 버전을 포함해 여러 구현이 나올 가능성이 큽니다. 고유한 위반자와 슬롯 조합은 한 번만 신고할 수 있으므로, 한 에포크 내에 정직한 참여자 한 명만 위반을 신고하면 됩니다. 프로그램은 동일한 슬롯과 위반자에 대한 신고가 이미 존재하는지 확인합니다. 일치하는 신고가 있으면 새 제출은 거부됩니다. 신고는 위반이 발생한 슬롯을 기준으로 위반 후 최대 한 에포크까지 제출할 수 있습니다. 즉, `Clock` sysvar로 추적되는 최대 432,000개 슬롯 이후까지 가능합니다.

내부고발자 보상

슬래싱 설계에서 자주 나오는 질문은 위반 신고자, 즉 내부고발자에게 보상해야 하는지입니다. 내부고발자 보상은 간단한 인센티브 메커니즘처럼 보이지만 상당한 문제가 따릅니다.

리더가 트랜잭션 포함 여부를 통제하는 Solana에서는 내부고발자 보상으로 인해 프런트러닝 위험이 발생합니다. 검증인이 현재 블록 리더에게 유효한 슬래싱 증명을 제출한다고 가정해 보겠습니다. 그러면 리더는 증명을 복사해 직접 제출하고 원래 트랜잭션을 검열함으로써 아무런 수고 없이 보상을 차지할 수 있습니다. 이는 인센티브 모델을 훼손하고 악용 가능성을 만듭니다.

Ethereum은 소액의 내부고발자 보상을 제공합니다. 슬래싱된 검증인의 유효 잔액 중 1/512입니다. 32 ETH 전액을 보유한 검증인의 경우 0.0625 ETH에 해당합니다. 보상은 새로운 ETH로 발행되지만, 슬래싱된 검증인의 지분에서 더 많은 금액이 소각되므로 상쇄됩니다. 보상액이 낮은 것은 의도된 설계입니다. 수익을 노린 기회주의적 행동보다 무결성과 정직한 참여를 장려하기 위한 것입니다.

투표 위반

향후 버전의 슬래싱 프로그램은 록아웃 위반, 전환 증명 위반 등 다양한 투표 위반에 대한 지원을 확대할 것으로 예상됩니다.

록아웃 위반은 검증인이 타워 록아웃이 만료될 때까지 적절한 시간을 기다리지 않고 서로 다른 두 포크에 투표할 때 발생합니다. Solana의 현재 합의 알고리즘인 TowerBFT에서는 검증인이 특정 슬롯에서 특정 포크에 투표하면 일정 기간 경쟁 포크에 투표할 수 없도록 "록아웃"됩니다. 이 검증인이 록아웃 기간이 끝나기 전에 다른 포크에 투표하면 록아웃 규칙을 위반합니다.

Solana 공동 창립자 Michael Vines가 개발한 Votalizer 봇은 현재 Solana Tech Discord에서 운영되며 네트워크 전반의 록아웃 위반을 실시간으로 추적합니다. 실제로 검증인이 의도치 않게 이러한 위반을 저지르는 경우는 드뭅니다. 일반적으로 검증인 클라이언트를 의도적으로 수정해야 가능하기 때문입니다. 내장된 보호 장치는 클라이언트가 가장 최근의 온체인 투표를 가져오도록 하고 록아웃 위반으로 이어질 행동을 방지합니다.

록아웃 위반은 Slashing SIMD와 초기 문서에서 슬래싱 프로그램이 처리할 수 있는 투표 위반의 예로 명시되어 있습니다. 그러나 예정된 Alpenglow 합의 업데이트는 Tower BFT를 제거해 록아웃 개념 자체를 없앨 예정입니다. 따라서 투표 위반은 Alpenglow 출시 이후에야 도입될 것으로 예상됩니다.

슬래싱 프로그램이 탐지하도록 설계할 수 있는 새로운 Alpenglow 투표 위반에는 동일한 슬롯에 상충하는 투표를 제출하는 행위가 포함될 수 있습니다. 예를 들어 `NotarVote`와 `SkipVote`를 모두 제출하는 경우입니다.

향후 위반 유형

프로그래밍 방식 슬래싱은 검증 가능하고 명확한 위반 사례에 연결되어야 합니다. 이 때문에 의도적인 블록 생성 지연이나 유해한 형태의 MEV 추출처럼 주관적이거나 시스템적인 문제를 제재하기는 훨씬 어렵습니다.

유사 블록체인 네트워크에서 슬래싱으로 이어지는 행동 유형은 프로토콜마다 다릅니다. 일반적인 예는 다음과 같습니다.

• 이중 서명: 동일한 높이 또는 슬롯에서 서로 상충하는 두 블록을 생성합니다.
• 다운타임: 오프라인 상태가 되어 합의에 참여하지 못합니다.
• 서라운드 투표: 네트워크를 조작하거나 불안정하게 만들기 위해 이전 투표와 상충하는 투표를 제출합니다.

지난해 Helius의 0xIchigo가 제안한 새로운 슬래싱 방안은 공식 거버넌스 투표에 참여하지 않은 초과다수 검증인에게 페널티를 부과해 참여 확대를 유도하자는 내용이었습니다. 객관적으로 검증 가능해야 한다는 요건은 충족하지만, 여러 의견 제시자가 우려를 표했습니다. 일부는 법적 제약으로 특정 검증인이 투표하지 못할 수 있다고 지적했습니다. 또 다른 이들은 슬래싱을 네트워크의 보안이나 무결성에 직접적인 위협을 가하는 행동으로 엄격히 제한해야 한다고 주장했습니다.

페널티 집행

Solana가 슬래싱 대상 위반을 신고하고 검증하는 신뢰할 수 있는 온체인 메커니즘을 갖추면, 다음 우선순위는 슬래싱을 경제적으로 집행하는 것입니다. 즉, 위반 유형별로 정확한 매개변수와 페널티 공식을 정의해야 합니다.

지침은 여전히 활발하게 논의되고 있습니다. 이 섹션의 내용은 정보를 제공하고 대화를 촉진하며 커뮤니티 피드백에 따라 발전하기 위한 현재 제안을 반영합니다. 이러한 결정은 Solana 검증인 운영의 경제성에 직접 영향을 미치므로, 모든 변경 사항은 공개적인 커뮤니티 토론을 거쳐 공식 거버넌스 절차로 승인되어야 합니다.

슬래싱 페널티를 결정할 때의 핵심 원칙은 드물게 발생하는 일회성 운영자 실수에 지나치게 가혹한 처벌을 내리지 않는 것입니다. 이상적으로는 정직한 실수에 중대한 페널티를 부과하기보다, 적절한 보호 장치 아래 합의에 영향을 주지 않는 경미한 사고를 허용하는 완충 구간이 있어야 합니다.

현재 이 완충 구간의 기준으로 고려되는 것은 Nakamoto Coefficient(NC) 선입니다. 초소수 집단에서 지분이 가장 적은 검증인의 지분 수준, 즉 전체 지분의 약 1%로 설정됩니다. 

투표 계정별 각 위임 지분의 슬래싱 규모를 결정하는 제안 함수에 따르면, 위반에 가담한 총지분이 NC 선보다 적을 경우 지분을 슬래싱하지 않습니다. 반대로 전체 지분의 3분의 1 이상이 위반에 연루되어 합의가 위험해지면 프로토콜은 위반 지분의 100%를 슬래싱하는 단호한 조치를 취해야 합니다.

이 두 극단 사이에 해당하는 경우, 현재 제안은 증가율이 완만한 이차 페널티 함수를 적용합니다. 각 투표 계정에서 슬래싱할 지분 비율을 계산하는 공식은 다음과 같습니다.

v = 슬래싱 가능한 투표 계정

TSS = 슬래싱 가능한 총지분

TS = 총지분

NC 선 = Nakamoto Coefficient 선

이 공식에 따라 위반 검증인에게서 슬래싱할 지분 비율은 다음과 같이 계산할 수 있습니다.

• 지분의 4.66%가 위반한 경우 1.2%(즉, (3 * (0.0466 - 0.01) / 1)²)
• 지분의 10%가 위반한 경우 7.3%(즉, (3 * (0.1 - 0.01) / 1)²)

아래 차트는 제안된 곡선과 두 가지 대안(공격적 방식과 선형 방식)을 보여줍니다.

슬래싱 가능한 총지분(TSS)은 위반 유형에 따른 가중치로 계산합니다. 투표 위반은 상대적으로 덜 심각하므로 가중치 1을 적용합니다. 중복 블록 위반은 더 심각한 것으로 간주해 가중치 10을 적용합니다.

현재 제안된 방식처럼 상관관계를 반영한 이차 슬래싱 페널티의 핵심 장점은 거래소나 서비스형 스테이킹 제공업체처럼 여러 검증인을 운영하는 주체가 광범위하고 상관된 장애 위험을 최소화하도록 고품질의 독립적인 인프라를 유지하게 유도한다는 점입니다.

전통적인 슬래싱의 대안

위임된 지분을 슬래싱하면 공정성과 책임 소재에 관한 중요한 문제가 생깁니다. 현재 스테이킹 모델에서 대부분의 비공개 검증인 지분은 전부 또는 거의 전부가 위임된 지분입니다. 따라서 슬래싱이 발생하면 위반한 검증인 운영자가 아니라 위임자가 페널티의 대부분을 부담하게 됩니다. 평판이 좋은 검증인을 신중하게 선택한 스테이커도 검증인이 악의적으로 행동하거나 노드를 잘못 구성하면 본인 잘못 없이 슬래싱될 수 있습니다.

이러한 불균형을 해소하기 위해 여러 대안적 슬래싱 설계가 제안되었습니다. 한 가지 방법은 모든 검증인에게 최소 자기 지분을 유지하도록 요구하는 것입니다. 이를 통해 운영자도 직접 위험을 부담하게 하며, 슬래싱 비용 전부를 위임자에게 전가하지 못하게 합니다. 더 엄격한 방식은 자기 지분만 슬래싱하고, 슬래싱된 검증인과 연결된 모든 위임자의 스테이킹을 자동으로 해제하는 것입니다. 위임자는 보상을 받지 못하지만 원금은 유지하므로 장기적인 영향을 최소화하면서 다른 검증인에게 지분을 재할당할 수 있습니다.

또 다른 방법은 정해진 기간 계정을 동결해 보상 획득, 소유권 변경, 자금 인출을 제한하는 것입니다. 동결 기간은 위반의 심각도에 따라 늘어납니다. 또는 프로토콜이 원금 지분은 건드리지 않고 향후 보상을 슬래싱해 일정 기간 검증인과 위임자의 수익을 줄일 수 있습니다.

일부에서는 슬래싱된 지분을 소각하는 대신 정직한 검증인에게 재분배해 긍정적 강화를 제공하자고 제안했습니다. 하지만 SOL 소각도 총공급량을 줄여 모든 보유자의 상대적 네트워크 소유 비중을 높이므로 사실상 비슷한 효과를 냅니다.

고려 사항

Solana에 슬래싱을 도입하면 여러 중요한 영향이 발생합니다. 이 섹션에서는 두 가지 핵심 영역을 살펴봅니다. 쿨다운 기간과 그에 따른 생태계 참여자의 위험, 보험, 운영 부담입니다.

쿨다운 기간

현재 스테이킹 모델의 핵심 취약점은 검증인이 슬래싱 대상 위반을 저지른 후 위반이 관찰되고 신고되기 전에 언스테이킹할 수 있다는 점입니다. 인출을 지연하는 메커니즘이 없으면 악의적 행위자가 이 시간차를 악용해 처벌을 피할 수 있습니다.

비활성화 후에도 일정 기간 지분을 슬래싱할 수 있도록 하는 쿨다운 기간을 두면 이 문제를 완화할 수 있습니다. 이 기간은 검증인이나 외부 관찰자가 슬래싱 대응을 탐지하고 조율하는 데 필요한 최악의 시간을 초과해야 합니다. 특히 네트워크 수준의 DDoS 공격이나 악의적 검증인 간 공모 같은 적대적 조건을 고려해야 합니다. 실무적으로는 쿨다운 기간이 여러 날 지속되어야 합니다.

Solana가 미리 계산된 지분 스냅샷에 의존한다는 점은 이 문제를 악화합니다. 리더 스케줄과 포크 선택 규칙을 포함한 여러 핵심 프로토콜 구성 요소는 사전에 계산된 지분 값을 사용합니다. 따라서 비활성화되었거나 완전히 인출된 지분도 여전히 합의에 영향을 줄 수 있습니다.

예를 들어 리더 스케줄은 에포크 경계에서 한 에포크 전에 촬영한 지분 스냅샷을 기반으로 생성됩니다. 이로 인해 검증인이 이전 에포크에서 이미 지분을 비활성화하고 현재 에포크 시작 시 인출한 상태에서 슬래싱 대상 위반을 저지를 수 있는 시간적 공백이 생깁니다. 위반이 밝혀질 때는 이미 페널티를 부과할 활성 지분이 남아 있지 않습니다.

해결책은 지분이 프로토콜의 지분 가중치에는 더 이상 반영되지 않지만 계속 슬래싱 대상이 되는 추가 쿨다운 기간을 도입하는 것입니다. 에포크 N에서 지분을 비활성화하는 스테이커는 에포크 N+3이 시작될 때만 지분을 인출할 수 있습니다. 보안은 강화되지만, 스테이커가 지분을 완전히 인출하기까지 ~2~4일을 더 기다려야 하므로 사용자 경험이 나빠집니다. 이를 해결하는 한 가지 방법은 에포크를 단축해 현재 기준과 비슷한 실제 언스테이킹 대기 시간을 유지하는 것입니다. 하지만 에포크 기간 단축은 예상치 못한 프로토콜 영향을 줄 수 있으므로 신중하게 평가해야 합니다.

위험, 보험 및 운영 부담

Solana의 슬래싱 도입은 다양한 생태계 참여자, 특히 스테이킹된 SOL을 수탁 또는 관리하거나 이를 기반으로 금융 상품을 구축하는 주체에 영향을 줍니다. 슬래싱 가능성만으로도 재정적 위험, 운영 복잡성, 평판 우려가 생길 수 있으며, 특히 수탁자 의무나 규제 제약 아래 운영되는 기관에는 더 큰 부담이 됩니다. 보험이나 보증 같은 보호 장치로 이러한 위험에 대응할 수 있습니다.

영향을 받을 수 있는 이해관계자는 다음과 같습니다.

• 유동성 스테이킹 프로토콜
• 스테이킹 풀
• 수탁형 스테이킹 제공업체
• 리스테이킹 프로토콜
• DeFi 프로토콜
• 스테이킹 ETF

일부 주체에는 슬래싱 사건이 연쇄적인 결과를 초래할 수 있습니다. 예를 들어 유동성 스테이킹 토큰(LST)은 기반 검증인이 안전하게 운영된다는 가정을 바탕으로 합니다. 검증인이 슬래싱되면 해당 LST 가격이 급격히 재조정될 수 있습니다. 기반 SOL이 스테이킹된 검증인에 대한 신뢰가 무너지면 극단적인 경우 페깅이 붕괴할 수도 있습니다. LST가 대출 프로토콜의 담보로 사용되고 있다면 청산으로 이어질 수 있습니다.

다른 생태계의 스테이킹 제공업체는 이러한 위험을 줄이기 위해 슬래싱 보험을 제공하는 경우가 많습니다. 예를 들어 Ethereum에서는 많은 제공업체가 슬래싱 손실을 보장하는 저렴한 보험을 제공하며, 보장 수준은 플랜에 따라 다릅니다.

슬래싱 위험은 스테이킹 가치 사슬 전반에 새로운 운영 책임도 부과합니다. 영향을 받는 주체는 다음과 같습니다.

• 검증인 행동을 모니터링하고 위험을 선제적으로 완화해야 하는 스테이킹 서비스 운영자
• 제3자 운영자에게 의존하며 검증인 구성을 심사하고 다각화해야 할 수 있는 수탁 플랫폼과 암호화폐 거래소
• 외부 운영자로 인한 슬래싱 손실에 대비해 자체 손실 보장을 원할 수 있는 기관 자산 관리자

유사 네트워크와의 비교

이 섹션에서는 Ethereum과 Cosmos 같은 유사 지분증명 네트워크가 슬래싱을 구현하는 방식을 살펴봅니다. 이들 네트워크는 수년 동안 프로그래밍 방식 슬래싱을 집행해 왔으며, 슬래싱 사건의 빈도와 네트워크 보안 및 검증인 행동에 미치는 영향에 관한 유용한 실제 데이터를 제공합니다.

Ethereum

2020년 12월 Beacon Chain 출시와 함께 도입된 Ethereum의 지분증명 프로토콜은 첫날부터 슬래싱을 핵심 집행 메커니즘으로 포함했습니다. Ethereum은 네 가지 구체적인 슬래싱 대상 위반을 정의하며, 모두 이중 행위와 관련됩니다.

• 동일한 슬롯에 여러 블록 제안
• 동일한 대상 체크포인트에 상충하는 증명 제출
• 출발 및 대상 체크포인트는 같지만 서로 다른 헤드 블록 증명
• 출발 및 대상 투표를 기준으로 하나가 다른 하나를 “둘러싸는” 두 개의 증명 생성

각 위반에는 동일한 페널티 구조가 적용됩니다. 검증인이 슬래싱되면 유효 잔액의 1/32을 즉시 페널티로 부과합니다. 최대 유효 잔액이 32 ETH이므로 페널티 상한은 1 ETH입니다. 이후 검증인은 활성 집합에서 강제로 퇴장하고 약 36일 동안 퇴장 대기열에 배치됩니다.

이 기간에 검증인은 비활성 상태이며 자금을 인출할 수 없습니다. 활성 상태였다면 얻었을 보상을 계속 잃으므로 지속적인 기회비용이 발생합니다. 18일 후에는 36일 동안 슬래싱된 검증인 수에 비례해 커지도록 설계된 추가 상관 페널티가 적용됩니다. 슬래싱된 검증인이 소수라면 페널티도 작습니다. 하지만 조직적인 위반이나 공통 인프라 장애로 대규모 슬래싱이 발생하면 페널티가 급격히 커지며, 최악의 경우 검증인이 스테이킹한 잔액을 거의 전부 잃을 수 있습니다.

슬래싱은 Ethereum 프로토콜의 핵심이지만 실제로는 극히 드뭅니다. 2025년 5월 기준 전체 검증인 집합의 0.05% 미만인 484개 검증인만 131건의 사건에서 슬래싱되었습니다. 이러한 사건은 하나의 오류가 여러 검증인에게 영향을 미쳐 발생한 경우가 많았으며, 대체로 악의적 의도가 아닌 운영자 실수나 소프트웨어 버그가 원인이었습니다.

가장 큰 슬래싱 사건은 2023년 11월에 발생했습니다. Bitcoin Suisse의 검증인 100개가 비활성 관련 위반으로 슬래싱되었고, 각각 1 ETH를 잃었습니다.

현재까지 Ethereum에서 발생한 슬래싱 사건 중 프로토콜의 전반적인 무결성을 위협한 사례는 없습니다. 이는 슬래싱이 필수적인 억제책이지만 실제 집행 빈도는 낮으며, 검증인 생태계가 이러한 페널티를 피하는 데 필요한 행동을 대체로 내재화했음을 보여줍니다.

Cosmos

Cosmos와 Cosmos Hub 같은 Cosmos SDK 기반 체인은 이중 서명과 장기 다운타임이라는 두 가지 주요 장애를 대상으로 하는 내장 보안 메커니즘으로 슬래싱을 구현합니다. 이러한 슬래싱 규칙은 프로토콜의 안전성과 활성 상태를 모두 보장합니다.

같은 높이에서 서로 다른 두 블록에 서명한 검증인은 즉시 처벌받습니다. 모든 참여자가 위반 증거를 온체인에 제출할 수 있으며, 검증되면 해당 검증인이 스테이킹한 토큰의 5%가 자동으로 슬래싱되고 툼스톤 상태가 됩니다. 즉, 활성 검증인 집합에서 영구적으로 제거되어 다시 진입할 수 없습니다. 툼스톤 상태가 되면 검증인과 위임자 모두 언본딩 기간이 끝날 때까지 기다려야 지분을 다시 위임할 수 있습니다. 툼스톤 상태가 된 검증인 운영자는 새 키로 다시 시작할 수 있지만, 평판과 위임 지분을 처음부터 다시 쌓아야 합니다.

Cosmos는 장기 다운타임에 대한 자동 슬래싱으로 활성 상태도 강제합니다. 검증인이 최근 10,000개 블록 중 5% 미만에 서명하면 비활성 상태로 간주되며 지분의 0.01%가 슬래싱됩니다. 상대적으로 경미하지만 엄격하고 예외 없이 적용되어 검증인이 가동 시간을 유지하고 합의에 안정적으로 참여하도록 합니다.

흥미롭게도 일부 검증인은 운영을 자발적으로 종료하는 비용으로 이 경미한 페널티를 감수하며, 손실을 미미한 것으로 봅니다.

Cosmos SDK 네트워크는 표준 기본 슬래싱 매개변수를 공유하지만, 각 체인은 자체 보안 가정과 위험 모델에 맞게 규칙을 수정하거나 확장할 수 있습니다. 이러한 유연성 덕분에 각 네트워크는 검증인 집합 규모, 탈중앙화 목표, 예상 장애 허용 범위에 따라 슬래싱 시스템을 조정할 수 있습니다. 57개 Cosmos SDK 기반 메인넷의 슬래싱 활동을 보면 생태계 전반의 집행 현황을 더 폭넓게 파악할 수 있습니다.

• 다운타임 관련 슬래싱 12,143건
• 이중 서명 슬래싱 111건
• 기타 위반 326건
• 총 슬래싱 사건 12,580건

이 수치는 이중 서명은 드물고 무거운 페널티를 받는 반면, 다운타임 슬래싱은 더 자주 발생하며 주로 일상적인 운영 비용으로 간주된다는 점을 보여줍니다. 

결론

슬래싱은 블록체인 업계에서 가장 많은 논쟁과 감정적 반응을 불러일으키는 주제 중 하나입니다. 새로운 형태의 검증인 위반이나 인센티브 불일치가 나타날 때마다 슬래싱 요구가 빠르게 뒤따릅니다. 그 이유는 쉽게 이해할 수 있습니다. 표면적으로 슬래싱은 악의적 행위자를 처벌하고 네트워크 무결성을 유지하는 직접적인 온체인 메커니즘을 제공하는 강력한 억제책처럼 보입니다.

하지만 이 글에서 살펴본 것처럼 프로그래밍 방식 슬래싱은 위반 행위를 해결하는 만능책과는 거리가 멉니다. 효과를 내려면 위반이 명확하고 입증 가능해야 하지만, 복잡한 현실에서는 이러한 조건을 충족하기가 항상 쉽지 않습니다. 증거가 불명확하거나 해석의 여지가 있는 사건을 슬래싱하면 정직한 참여자를 처벌하고 신뢰를 훼손하며, 막으려던 위반보다 더 큰 피해를 초래할 수 있습니다.

자동화된 슬래싱이 네트워크에 제공하는 가장 큰 가치는 이해관계자에게 미치는 심리적 영향이라고 볼 수 있습니다. 아무리 드문 위반이라도 경제적 손실이 발생할 수 있다는 가능성만으로 위험 회피 성향의 스테이커가 여러 검증인에게 위임을 분산하도록 유도하고, 운영자가 다양하고 독립적인 인프라에 투자하도록 동기를 부여할 수 있습니다.

추가 자료

• 슬래싱: 만병통치약인가, 판도라의 상자인가? - Tim Roughgarden, Accelerate Conference
• 무허가 합의의 경제적 한계 - Eric Budish, Andrew Lewis-Pye, Tim Roughgarden 
• 책임 있는 활성 상태 - Andrew Lewis-Pye, Joachim Neu, Tim Roughgarden, Luca Zanolini