메인 콘텐츠로 건너뛰기

​
슬래싱

​
보안 고려사항

Validator Set은 이중 서명 또는 기타 부정 행위에 대해 슬래싱되는 스테이크가 뒷받침하는 실제 키 세트입니다. 우리는 일반적으로 체인의 보안을 _Validator Set_의 보안으로 간주합니다. 이는 각 체인마다 다르지만 우리의 황금 표준입니다. IBC조차도 관련된 두 Validator Set의 최소값보다 더 많은 보안을 제공하지 않습니다. Eth bridge relayer는 검증자 세트에 의해 메인 injectived 데몬과 함께 실행되는 바이너리입니다. 이것은 순전히 코드 구성의 문제로 존재하며 Ethereum 트랜잭션에 서명하고, Ethereum의 이벤트를 관찰하여 Injective Chain 상태로 가져오는 역할을 합니다. Ethereum 키로 Ethereum에 바인딩된 트랜잭션에 서명하고, Injective Chain 계정 키로 Ethereum에서 오는 이벤트에 서명합니다. _Validator Set_이 실행하는 _Eth Signer_의 잘못 서명된 메시지에 슬래싱 조건을 추가하고 _Validator Set_과 동일한 보안을 제공할 수 있습니다. 단지 다른 모듈이 악의의 증거를 감지하고 얼마나 슬래싱할지 결정합니다. _Validator Set_의 _Eth Signer_가 서명한 트랜잭션이 불법이거나 악의적임을 증명할 수 있다면 Injective Chain 측에서 슬래싱하고 잠재적으로 _Validator Set_의 100% 보안을 제공할 수 있습니다. 이것은 또한 즉시 언본딩하더라도 증거를 슬래싱할 수 있는 3주 언본딩 기간에 접근할 수 있습니다. 아래는 Peggy에서 사용하는 다양한 슬래싱 조건입니다.

​
PEGGYSLASH-01: 가짜 검증자 세트 또는 tx 배치 증거 서명

이 슬래싱 조건은 검증자가 Injective Chain에 존재하지 않은 검증자 세트와 nonce에 서명하는 것을 막기 위한 것입니다. 이것은 증거 메커니즘을 통해 작동하며, 누구나 가짜 검증자 세트에 대한 검증자의 서명이 포함된 메시지를 제출할 수 있습니다. 이것은 가짜 검증자 세트를 제출하려는 검증자 카르텔이 형성되면 한 명의 이탈자가 모두를 슬래싱시킬 수 있는 효과를 만들기 위한 것입니다. 
// This call allows anyone to submit evidence that a
// validator has signed a valset, batch, or logic call that never
// existed. Subject contains the batch, valset, or logic call.
type MsgSubmitBadSignatureEvidence struct {
	Subject   *types1.Any 
	Signature string      
	Sender    string      
}
구현 고려사항: 이 슬래싱 조건의 가장 까다로운 부분은 검증자 세트가 Injective에 존재하지 않았음을 결정하는 것입니다. 공간을 절약하기 위해 오래된 검증자 세트를 정리해야 합니다. KV 저장소에 검증자 세트 해시를 true로 매핑하고 이를 사용하여 검증자 세트가 존재했는지 확인할 수 있습니다. 이것은 전체 검증자 세트를 저장하는 것보다 효율적이지만 성장은 여전히 무제한입니다. 이 매핑의 크기를 줄이기 위해 다른 암호화 방법을 사용할 수 있을 수 있습니다. 이 매핑에서 매우 오래된 항목을 정리하는 것이 괜찮을 수 있지만, 정리는 이 슬래싱 조건의 억제력을 줄입니다. 이 슬래싱 조건의 구현된 버전은 모든 과거 이벤트에 대한 해시 맵을 저장합니다. 이것은 전체 배치나 검증자 세트를 저장하는 것보다 작고 자주 액세스할 필요가 없습니다. 가능하지만 현재 구현되지 않은 효율성 최적화는 일정 기간 후에 이 목록에서 해시를 제거하는 것입니다. 그러나 이것은 각 해시에 대한 더 많은 메타데이터를 저장해야 합니다. 현재 relayer에는 자동 증거 제출이 구현되어 있지 않습니다. 서명이 Ethereum에서 보이는 시점에는 슬래싱이 브릿지 하이재킹이나 자금 도난을 방지하기에는 이미 너무 늦습니다. 또한 이 작업을 수행하려면 어쨌든 검증자 세트의 66%가 필요하므로 동일한 제어 다수가 단순히 증거를 거부할 수 있습니다. 이 슬래싱 조건에 대해 상정되는 가장 일반적인 경우는 브릿지를 장악하려는 검증자 카르텔을 해체하여 그들이 서로를 신뢰하고 실제로 그러한 도난을 조정하기 더 어렵게 만드는 것입니다. 도난에는 슬래싱 가능한 Ethereum 서명의 교환이 포함되며 그룹 내 이탈자에 의한 이 메시지의 수동 제출 가능성을 열어둡니다. 현재 이것은 상태에서 계속 증가하는 해시 배열로 구현되어 있습니다.

​
PEGGYSLASH-02: tx 배치 서명 실패

이 슬래싱 조건은 검증자가 Peggy 모듈에 의해 생성된 후 SignedBatchesWindow 내에 트랜잭션 배치에 서명하지 않을 때 트리거됩니다. 이것은 두 가지 나쁜 시나리오를 방지합니다-
  1. 검증자가 시스템에서 올바른 바이너리를 실행하는 것을 귀찮게하지 않음
  2. 1/3 이상의 검증자 카르텔이 언본딩한 다음 업데이트에 서명하기를 거부하여 Peggy Ethereum 컨트랙트에 제출할 충분한 서명을 얻지 못하도록 배치를 방지

​
PEGGYSLASH-03: 검증자 세트 업데이트 서명 실패

이 슬래싱 조건은 검증자가 Peggy 모듈에 의해 생성된 검증자 세트 업데이트에 서명하지 않을 때 트리거됩니다. 이것은 두 가지 나쁜 시나리오를 방지합니다-
  1. 검증자가 시스템에서 올바른 바이너리를 실행하는 것을 귀찮게하지 않음
  2. 1/3 이상의 검증자 카르텔이 언본딩한 다음 업데이트에 서명하기를 거부하여 Peggy Ethereum 컨트랙트에 제출할 충분한 서명을 얻지 못하도록 검증자 세트 업데이트를 방지. Injective Chain 언본딩 기간보다 오래 검증자 세트 업데이트를 방지하면 가짜 검증자 세트 업데이트와 tx 배치 제출에 대해 더 이상 처벌받을 수 없습니다 (PEGGYSLASH-01 및 PEGGYSLASH-03).
시나리오 2를 처리하기 위해 PEGGYSLASH-03은 더 이상 검증하지 않지만 최대 UnbondSlashingValsetsWindow 블록 동안 여전히 언본딩 기간에 있는 검증자도 슬래싱해야 합니다. 이것은 검증자가 검증자 세트를 떠날 때 최소 UnbondSlashingValsetsWindow 블록 동안 장비를 계속 실행해야 함을 의미합니다. 이것은 Injective Chain에서 흔하지 않으며 검증자에게 수용되지 않을 수 있습니다. UnbondSlashingValsetsWindow의 현재 값은 25,000 블록, 또는 약 12-14시간입니다. 다음 논리를 기반으로 이것을 안전한 값으로 결정했습니다. 검증자 세트를 떠나는 모든 검증자가 자신이 포함되지 않은 최소 하나의 검증자 세트 업데이트에 서명하는 한, relayer가 체인의 현재 상태를 현재 상태로 변환하기 위한 검증자 세트 업데이트 체인을 생성하는 것이 보장됩니다. PEGGYSLASH-02와 PEGGYSLASH-03 모두 컨센서스 코드 내에서 Ethereum 서명을 수행하는 것이 가능하다면 보안 손실 없이 제거될 수 있습니다. 이것은 Peggy를 슬래싱에 훨씬 덜 취약하게 만드는 Tendermint에 대한 상당히 제한적인 기능 추가입니다.

​
PEGGYSLASH-04: 잘못된 Eth oracle claim 제출 (현재 비활성화)

Ethereum oracle 코드(현재 주로 attestation.go에 포함됨)는 Peggy의 핵심 부분입니다. 이것은 Peggy 모듈이 입금 및 실행된 배치와 같이 Ethereum에서 발생한 이벤트에 대한 지식을 가질 수 있게 합니다. PEGGYSLASH-03은 Ethereum에서 절대 발생하지 않은 이벤트에 대한 claim을 제출하는 검증자를 처벌하기 위한 것입니다. 구현 고려사항 이벤트가 Ethereum에서 발생했는지 여부를 아는 유일한 방법은 Ethereum 이벤트 oracle 자체를 통해서입니다. 따라서 이 슬래싱 조건을 구현하기 위해 2/3 이상의 검증자가 관찰한 이벤트와 동일한 nonce에서 다른 이벤트에 대한 claim을 제출한 검증자를 슬래싱합니다. 선의이지만 이 슬래싱 조건은 대부분의 Peggy 애플리케이션에 권장되지 않을 가능성이 높습니다. 이것은 설치된 Injective Chain의 기능을 Ethereum 체인의 올바른 기능에 연결하기 때문입니다. Ethereum 체인의 심각한 포크가 있는 경우 정직하게 행동하는 다른 검증자가 동일한 이벤트 nonce에서 다른 이벤트를 보고 자신의 잘못 없이 슬래싱될 수 있습니다. 광범위한 불공정 슬래싱은 Injective Chain의 사회적 구조에 매우 파괴적일 것입니다. 어쩌면 PEGGYSLASH-04는 전혀 필요하지 않을 수 있습니다: 이 슬래싱 조건의 실제 유용성은 2/3 이상의 검증자가 특정 nonce에서 가짜 이벤트를 모두 제출하기 위해 카르텔을 형성하면 그 중 일부가 카르텔에서 이탈하여 해당 nonce에서 실제 이벤트를 제출할 수 있도록 하는 것입니다. 실제 이벤트가 관찰될 만큼 충분한 카르텔 멤버가 이탈하면 나머지 카르텔 멤버는 이 조건에 의해 슬래싱됩니다. 그러나 이것은 대부분의 조건에서 카르텔 멤버의 1/2 이상이 이탈해야 합니다. 충분한 카르텔이 이탈하지 않으면 어느 이벤트도 관찰되지 않고 Ethereum oracle은 단순히 중단됩니다. 이것은 PEGGYSLASH-04가 실제로 트리거되는 것보다 훨씬 더 가능성이 높은 시나리오입니다. 또한 PEGGYSLASH-04는 성공적인 카르텔의 경우 정직한 검증자에게 트리거됩니다. 이것은 형성 중인 카르텔이 합류하기를 원하지 않는 검증자를 위협하기 쉽게 만드는 역할을 할 수 있습니다.

​
PEGGYSLASH-05: Eth oracle claim 제출 실패 (현재 비활성화)

이것은 PEGGYSLASH-04와 유사하지만 관찰된 oracle claim을 제출하지 않는 검증자에게 트리거됩니다. PEGGYSLASH-04와 달리 PEGGYSLASH-05는 oracle에 완전히 참여를 중단한 검증자를 처벌하기 위한 것입니다. 구현 고려사항 안타깝게도 PEGGYSLASH-05는 Injective Chain의 올바른 운영을 Ethereum 체인에 연결한다는 점에서 PEGGYSLASH-04와 동일한 단점이 있습니다. 또한 올바른 행동을 많이 장려하지 않을 가능성이 높습니다. PEGGYSLASH-05 트리거를 피하기 위해 검증자는 관찰되기 직전의 claim을 단순히 복사하면 됩니다. 이 claim 복사는 commit-reveal 체계로 방지할 수 있지만 “게으른 검증자”가 단순히 공개 Ethereum 전체 노드나 블록 익스플로러를 사용하면 보안에 비슷한 영향을 미칩니다. 따라서 PEGGYSLASH-05의 실제 유용성은 미미할 가능성이 높습니다 PEGGYSLASH-05는 또한 상당한 위험을 도입합니다. 주로 Ethereum 체인의 포크와 관련이 있습니다. 예를 들어 최근 OpenEthereum은 Berlin 하드포크를 제대로 처리하지 못했습니다. 결과적인 노드 ‘실패’는 자동화 도구로 완전히 감지할 수 없었습니다. 충돌하지 않아서 수행할 재시작이 없었고, 매우 느리긴 했지만 블록이 여전히 생산되고 있었습니다. PEGGYSLASH-05가 활성화된 상태에서 Peggy가 실행 중일 때 이것이 발생했다면 해당 검증자가 세트에서 제거되었을 것입니다. 자신의 잘못이 거의 없이 수십 명의 검증자가 제거되면서 체인에 매우 혼란스러운 순간이 발생할 수 있습니다. PEGGYSLASH-04 및 PEGGYSLASH-05 없이 Ethereum 이벤트 oracle은 2/3 이상의 검증자가 자발적으로 올바른 claim을 제출하는 경우에만 계속 작동합니다. PEGGYSLASH-04 및 PEGGYSLASH-05에 대한 주장이 설득력이 있지만, 이 사실에 만족하는지 결정해야 합니다. 또는 Ethereum에서 생성된 요인으로 인해 잠재적으로 Injective Chain이 완전히 중단되는 것에 만족해야 합니다.