본문으로 이동
Financial Context Wiki

슬래싱

슬래싱는 속임수가 인정된 밸리데이터나 운영자의 위법 행위 이후에 규약에 의해 정의된 슬래시 가능한 스테이크 감소입니다. 모든 누락된 의무나 명시된 비율이 동일한 효과를 가지는 것으로 가정하지 말고, 정확한 위반 행위, 증거, 스테이크 기준, 벌칙 공식, 시기, 위임 및 인출 노출을 분석하십시오.

업데이트

교육 목적으로만 사용됩니다; 투자 조언이 아닙니다. 투자는 손실을 초래할 수 있습니다.

직접적인 답변

슬래싱은 검증자, 운영자 또는 그 밖의 담보된 참여자에게 귀속되는 규칙 위반이 발생한 뒤 프로토콜 정의에 따라 스테이크를 줄이는 조치입니다. 완전한 규칙은 슬래싱 대상 위반, 이를 입증하는 증거 또는 카운터, 노출된 스테이크, 페널티 계산식과 적용 가능 기간을 명시합니다. 일시 정지, 비활성화, 강제 퇴출, 보상 손실 또는 신고 보상이 함께 발생할 수 있지만, 프로토콜이 결합해 정의하지 않는 한 각각 별도의 상태 전환입니다.

보편적인 벌점 규칙은 없습니다. Ethereum는 상충되는 제안과 증언에는 벌점을 부과하지만, 일반적인 의무 미이행과 비활성 누수는 별도로 처리합니다. Cosmos SDK 체인은 이중 서명과 다운타임 벌점을 모두 구성할 수 있습니다. Polkadot는 위반, 벌점, 비활성화, 평판 변화를 구분합니다. 리스테이킹 서비스는 기본 체인과 다른 계약, 운영자 세트, 출금 창을 가지는 추가적인 벌점 가능한 약속을 추가할 수 있습니다. 정확한 네트워크, 포크, 런타임 또는 계약 배포에 대한 활성 규칙을 확인하세요.

슬래싱는 악의적인 의도가 아니라 프로토콜 술어를 증명합니다. 중복된 검증자 키, 분리 브레인 장애 조치, 복원된 백업, 원격 서명기 경쟁, 또는 손상된 슬래싱 보호 데이터베이스는 운영자가 공격을 의도하지 않았더라도 충돌하는 두 개의 유효한 서명을 생성할 수 있습니다. 반대로, 서비스 가동률 불량은 모든 네트워크에서 자동으로 슬래시 대상이 아니며, 정의된 위반 규칙을 충족하지 않는 한 유효하지 않거나 늦은 메시지는 슬래시 대상이 아닙니다.

이 개념들을 분리해 두세요:

  • 놓친 보상 또는 일반 벌칙: 의무가 없었거나, 늦었거나, 잘못되었지만 처벌 가능한 위반은 증명되지 않았다.
  • 비활성화 메커니즘: 장기적인 미완결 상태 동안 의 처벌이 증가하거나 투표 가중치가 변경됩니다; Ethereum의 비활동 누수 자체는 슬래싱이 아닙니다.
  • 슬래싱: 체인 상 또는 프로토콜에서 인식된 상태 전환은 입증된 위반에 첨부된 스테이크를 줄입니다.
  • 감금, 비활성화, 추방 또는 묘비 처리: 참여가 중단되거나 종료됩니다; 이 조치는 추가 지분 감소와 함께 또는 없이 발생할 수 있습니다.
  • 사회적 또는 계약상의 벌칙: 거버넌스, 서비스 계약, 보험 정책, 또는 조정된 포크는 자동 기본 프로토콜 슬래싱 기능 외부에서 결과를 부과합니다.

키를 운영하는 당사자가 반드시 손실을 부담하는 유일한 당사자는 아닙니다. 프로토콜 규칙과 서비스 계약은 자체 스테이크, 위임된 스테이크, 지명자 스테이크, 재스테이킹된 할당, 대기 중인 인출, 또는 풀된 청구를 노출할 수 있습니다. 보험 및 상환은 별도의 신용 약속으로, 프로토콜 이벤트의 취소가 아닙니다.

슬래싱을 분석하는 방법

1. 규칙 집합과 관찰 시점을 확정한다

network, chain ID, 활성 fork version 또는 런타임, 블록 또는 에포크, 클라이언트/사양 릴리스 및 관련 계약 주소를 기록하세요. 합의 규칙을 스테이킹 제공자의 조건 및 사용자 인터페이스와 구분하세요. 현재 매개변수 조회와 최종 상태가 날짜가 없는 도움말 페이지보다 더 강력한 증거입니다.

2. 정확한 위반 조건을 작성한다

실행 가능한 용어로 규칙 이름 지정: 한 검증자가 동일한 슬롯에 대해 제안한 두 개의 구분된 제안, double vote, surround vote, 프로토콜에서 인식한 잘못된 투표, 또는 liveness 창 내의 missed > max_missed. ‘나쁜 행동’, ‘오프라인’, 또는 ’공격’과 같은 레이블로 술어를 대체하지 마십시오.

3. 귀속과 증거를 검증한다

검증자 또는 운영자 신원, 서명, signing root, 도메인 분리, 포크 컨텍스트, 높이 또는 에포크, 증거 연령을 확인하십시오. 상충되는 메시지 위반의 경우, 서명된 두 객체를 모두 보존하십시오. 생존성 규칙의 경우, 프로토콜의 카운터와 윈도우를 재현하십시오. 증거 포함은 위반 후에도 발생할 수 있으므로 infraction time, detection time 및 application time을 구분하십시오.

4. 위험에 노출된 모든 잔액을 확인한다

기초가 effective balance인지, 위반 높이에서 연결된 스테이크인지, 현재 스테이크인지, 자체 스테이크인지, 위임된 스테이크인지, 검증자 슬롯 할당인지, 또는 operator set에 할당된 스테이크인지 결정하십시오. 상한, 하한, 반올림 단위, 단위, 이전 벌금, 재위임, 그리고 대기 중인 출금이 아직 벌금 대상인지 확인하십시오.

5. 각 페널티 요소를 재계산한다

결과를 initial penalty, correlation penalty, 계속되는 의무 벌금, 포기된 보상, 강제 퇴장 효과, 보고 또는 내부 고발자 보상으로 나누십시오. 간단한 고정 규칙은 slash_amount = slashable_stake * slash_fraction를 사용할 수 있으며, 많은 실시간 프로토콜은 대신 상태에 따라 달라지는 함수를 사용합니다. 기준을 확인하지 않고 지갑 잔액에 헤드라인 비율을 적용하지 마십시오.

6. 전체 타임라인과 손실 부담자를 정리한다

위반 추적, 증거 전파, 포함, 벌점 회계, 감금 또는 비활성 기간, 항소 또는 취소 창, 종료, 언본딩, 및 인출 완료. 그런 다음 프로토콜 및 서비스 계약에 따라 운영자, 위임자, 지명자, 풀 토큰 보유자 및 재스테이커 간 손실을 할당합니다. 소각된 단위와 별도로 토큰 가격 및 유동성 영향을 포함합니다.

7. 통제 수단을 점검하고 상태를 대사한다

주요 보관, 서명자 독점성, slashing protection database 내구성, 장애 조치 펜싱, 백업 복구, 시계 및 네트워크 모니터링, 클라이언트 다양성, 사건 절차를 검토하십시오. 최종 상태, 매개변수, 증거 및 잔액 변동에서 이벤트를 재계산하고, 이를 탐색기 라벨, 제공자 진술, 회계 항목 및 보험금 지급과 조정하되, 어느 한 출처를 결정적인 것으로 간주하지 마십시오.

실제 예제

Ethereum 스타일의 충돌 서명

검증자 V가 블록 헤더 A와 서로 다른 헤더 B를 slot = 8에 대해 서명했고, 두 서명이 같은 적용 가능 포크 컨텍스트에서 유효하다고 가정합니다. 이 쌍은 Ethereum 제안자 이중서명 형태를 만족하지만 슬롯 9에서 제안을 놓친 것은 그렇지 않습니다. 증명(attestations)의 경우, A = (source = 120, target = 125)와 B = (source = 118, target = 127)라고 합시다. B가 A를 둘러싸므로 이 쌍은 surround-vote 형태를 갖습니다. 라벨만으로는 충분하지 않으며, 실제 서명 데이터, 도메인, 검증자 인덱스와 슬래싱 가능 기간 검사가 활성 사양을 통과해야 합니다.

이 예시는 또한 의도가 입력이 아닌 이유를 보여줍니다. 같은 키를 사용하는 두 기계가 증거를 만들 수 있습니다. ’이중 서명’이라고 말하는 스크린샷은 만들 수 없습니다. 프로토콜에는 유효한 상충 서명 객체가 필요합니다.

비례 지분 손실 계산

slashable_stake = 12,500 토큰과 고정된 slash_fraction = 0.015를 가진 예시 프로토콜을 고려해보자. 프로토콜 손실은 다음과 같다:

12,500 * 0.015 = 187.5 tokens.

규칙이 모든 지원 지분을 비례적으로 부과하는 경우, 운영자의 자체 지분 2,500 토큰은 37.5를 잃게 되며, 10,000 위임된 토큰은 150를 잃게 됩니다. 서비스 계약이 위임자에게는 보상하지만 운영자에게는 보상하지 않는 경우, 그 지급은 별도의 미수금 및 신용 위험이 됩니다. 이는 온체인 슬래시를 변경하지 않으며, 이러한 배분은 위임자를 보호하거나 다른 지분 기반을 사용하는 프로토콜로 이전되어서는 안 됩니다.

코스모스 스타일 라이브니스 창

Cosmos SDK 기반 체인이 window = 1,000 및 min_signed = 0.95 매개변수를 조회했다고 가정합니다. 허용되는 최대 누락 횟수는 다음과 같습니다:

max_missed = 1,000 - (0.95 * 1,000) = 50.

만약 활성 규칙이 missed > max_missed에서 작동하고, 정확히 50에서는 임계값을 넘지 않지만 51에서는 넘는다면, 결과적인 슬래시 비율, 정지 기간, 카운터 초기화 및 정지 해제 가능 여부은 해당 체인의 활성 매개변수와 모듈 버전에서 나옵니다. 이것은 구성된 체인의 예시일 뿐, 보편적인 지분 증명 규칙이 아니며 Ethereum의 다운타임 처리도 아닙니다.

상관된 위반 공식

Polkadot의 검토된 문서는 min((3 * x / n)^2, 1)의 등가 분수를 제공하며, 여기서 x는 범죄자 수이고 n는 활성 검증자 수입니다. x = 5 및 n = 100와 함께:

min((3 * 5 / 100)^2, 1) = 0.0225 = 2.25%.

검증자 슬롯의 스테이크 40,000 단위에 적용하면, 즉 900 단위입니다. x = 20에서는 같은 공식이 36%를 주며, 2.25%의 네 배가 되지는 않습니다. 이는 상관관계 위험을 보여줍니다; 현재 규칙을 확인하지 않고 Ethereum, 코스모스 체인, 파라체인, 또는 다른 Polkadot 런타임에 그 공식을 사용하는 것을 허용하지 않습니다.

위험과 검토 실패

  • 잘못된 규칙 집합: 다른 체인, 포크, 런타임, 테스트넷 또는 계약 배포는 다른 위반과 처벌을 가질 수 있습니다.
  • 위반-처벌 혼동: 의 보상 누락, 비활동 페널티, 감금, 비활성화, 추방, 슬래싱은 서로 교환 가능한 용어가 아닙니다.
  • 오래된 매개변수: 거버넌스 및 업그레이드는 윈도우, 분수, 상한, 지연 및 보호된 잔액을 변경할 수 있습니다.
  • 도메인 혼동: 다른 포크 또는 도메인 컨텍스트에서의 서명은 절단 가능한 증거를 형성하지 않을 수 있습니다.
  • 잘못된 증거: 손상되었거나, 중복되었거나, 만료되었거나, 잘못 색인되었거나, 인증되지 않은 증거는 거부될 수 있습니다.
  • 지연된 발견: 증거는 재위임 또는 종료 시작 후에 도착할 수 있으므로, 위반 및 신청 상태가 다릅니다.
  • 잘못된 스테이크 스냅샷: 현재 잔액은 규칙에서 사용하는 잔액, 투표 권한 또는 유효 지분이 아닐 수 있습니다.
  • 상관관계 증폭: 공유된 클라이언트, 클라우드, 서명자 또는 절차는 하나의 결함을 상태에 따라 달라지는 대규모 벌칙으로 바꿀 수 있습니다.
  • 중복된 키: 는 키스토어를 복사하고 동시에 활성 백업을 수행하면 충돌하는 서명을 생성할 수 있습니다.
  • 원격 서명자 실패: 재시도, 오래된 잠금, 일관되지 않은 데이터베이스 또는 모호한 승인으로 인해 이중 서명이 발생할 수 있습니다.
  • 스플릿 브레인 장애 전환: 두 사이트는 장애 조치가 암호화로 격리되지 않는 한 둘 다 자신이 주(primary)라고 생각할 수 있습니다.
  • 보호 데이터베이스 손실: 은 전체 서명 기록 없이 키를 복원하면 겉보기에는 정상적인 검증기도 안전하지 않을 수 있습니다.
  • 운영자 집중: 하나의 제어 평면 아래 여러 검증자는 운영 및 상관 노출을 공유합니다.
  • 위임 전달: 위임자나 지명자는 자신이 직접 통제할 수 없는 운영자로 인해 발생한 손실을 부담할 수 있습니다.
  • 재스테이킹 겹침: 하나의 자산은 서로 다른 벌칙 권한과 배분 규칙을 가진 여러 약속을 지원할 수 있습니다.
  • 철회 노출: 의 언본딩 또는 대기 중인 출금은 이전 또는 새로 발생한 위반 사항에 대해 여전히 벌점 대상이 될 수 있습니다.
  • 거버넌스 불확실성: 항소, 취소 기간, 업그레이드 또는 사회적 복구는 시기를 변경할 수 있지만 보장된 해결책은 아닙니다.
  • 회계 및 반올림: 유효 잔액 증가, 토큰 변환, 한도 및 토큰 소수점은 지갑 잔액 곱셈을 무력화할 수 있습니다.
  • 관찰 가능성 격차: 탐색기 레이블은 증거 쌍, 매개변수 스냅샷, 영향받은 위임 또는 이후 페널티를 생략할 수 있습니다.
  • 계약 및 거래 상대방 위험: 풀, 보관, 보험 및 상환 약속은 합의의 정확성과 관계없이 독립적으로 실패할 수 있습니다.

일반적인 오해

모든 오프라인 검증자가 슬래시되나요?

아니요. Ethereum는 미이행 및 비활동 벌칙을 적용하지만 일반적인 다운타임을 처벌 가능한 위반으로 분류하지 않습니다. Cosmos SDK 체인은 다운타임 슬래싱을 구성할 수 있습니다. 다른 프로토콜은 비활성화, 일시 정지, 보상 감소 또는 아무 조치도 취하지 않을 수 있습니다. 한 네트워크로 일반화하지 말고 정확한 규칙을 문의하십시오.

슬래싱에는 악의적인 의도를 입증해야 합니까?

보통 자동 규칙은 서명된 메시지, 증거, 카운터, 상태를 평가하며, 동기는 평가하지 않습니다. 운용상의 사고는 의도적인 혼선과 동일한 술어를 만족시킬 수 있습니다. 의도는 거버넌스, 보험, 소송, 또는 서비스 계약에는 중요할 수 있지만, 결정론적 상태 전환에는 중요하지 않습니다.

최대 손실은 공시된 슬래싱 비율인가요?

반드시 그렇지는 않습니다. 퍼센트는 유효, 연결, 할당, 위임된, 또는 과거 지분에 적용될 수 있으며; 상관관계와 지속적인 벌금은 손실을 추가할 수 있습니다; 강제 퇴출은 미래 보상을 몰수할 수 있습니다; 그리고 토큰 가격이나 유동 스테이킹 할인은 경제적 가치를 변경할 수 있습니다. 반대로, 상한선이나 보호된 잔액은 부과 기준을 줄일 수 있습니다.

출구를 시작하면 슬래싱 노출이 즉시 종료되나요?

보편적인 규칙이 그렇게 말하는 것은 없습니다. 증거는 지연될 수 있으며, 언바운딩은 부분적으로 책임을 유지하기 위해 존재하고, 일부 리스테이킹 출금은 대기 중에도 여전히 슬래시될 수 있습니다. 단순히 출금을 요청한 트랜잭션이 아니라 각 커밋먼트의 마지막 슬래시 가능 시간을 확인하세요.

위임, 보험, 또는 사회적 회수가 슬래싱 위험을 제거합니까?

아니요. 그들은 추가 규칙에 따라 손실을 재분배하거나 상환을 약속합니다. 보장은 상관된 결함을 제외하거나, 만료되거나, 청구 한도를 설정하거나, 거버넌스에 따라 달라지거나, 상대방 위험을 초래할 수 있습니다. 프로토콜 벌점은 독립적으로 조정되어야 하는 별도의 사건으로 남아 있습니다.

관련 주제

출처

탐색

위키 검색...