비콘 체인 유효성 검사기: 중복 위험 및 장애 조치

편집자 주: 이 기사의 출처는이더리움 애호가(ID: ethfans)이더리움 애호가(ID: ethfans)

이더리움 애호가(ID: ethfans)

, 저자: Aditya Asgaonkar, 번역: A Jian, 승인을 받아 Odaily에서 재인쇄함.

첫 번째 레벨 제목

유효성 검사기 및 유효성 검사기 클라이언트

검증자는 비콘체인과 관련된 개념으로, 검증자는 비콘체인의 합의 과정에 참여하는 주체이다. 검증자는 공개 키로 식별되며 각 검증자는 서로 다른 시간에 비콘 체인을 검증하는 작업을 할당받습니다. 이 일을 성공적으로 완수하면 포상을 받고, 반대로 본분을 소홀히 하면 포상을 받지 못할 뿐만 아니라 가혹한 처벌을 받게 됩니다. 0단계에서 이러한 비난은 블록을 제안하고 비콘 체인에 대한 증명을 제출하는 것으로 제한됩니다.

검증인은 임무를 수행하기 위해 검증인 클라이언트(VC)라는 소프트웨어를 사용해야 합니다1. 모든 비콘 체인 클라이언트 팀은 VC를 클라이언트 소프트웨어 패키지 중 하나로 사용합니다.

• 말할 필요도 없이 유효성 검사기는 고객이 최대의 이익을 얻고 모든 페널티를 피할 수 있도록 고객이 연중무휴 24시간 온라인 상태를 유지하기를 원합니다. 고가용성을 달성하는 일반적인 방법은 중복 및 장애 조치 메커니즘을 설정하는 것입니다. 이 기사는 검증자에 대한 중복의 위험을 설명하고 비콘 체인의 VC에 대한 합리적인 장애 조치를 제안합니다.
• 손실/위약금 유형
• 유효성 검사기는 심각도의 오름차순으로 세 가지 유형의 손실에 직면합니다.

Reward Frustration: 검증자가 작업에 할당되었을 때 수행하지 못하면 TA는 작업에 해당하는 보상을 받을 수 없습니다. 검증인의 자산(원금)은 줄어들지 않고 보상을 받을 기회를 잃을 뿐입니다.느린 작업 페널티: 검증자가 증인 메시지를 보내지 않고 비콘 체인이 그 때 블록 2를 완료하지 못하면 검증자의 자산이 소폭 감소합니다(물론 해당 보상은 얻지 못함).삭감 페널티: 검증인이 Casper FFG 규칙을 위반하는 증인 메시지를 보낸 경우 검증인은 즉시 삭감됩니다. 검증인의 자산은 일정 비율 3만큼 감소하고 검증인은 추방되며 다시 사용할 수 없습니다. 컨센서스(따라서 향후 보상에서도 제외됨). 또한 비콘체인은 약속한 ETH를 양도하거나 회수할 수 없기 때문에 검증자의 남은 돈은 모두 비콘체인에 잠기고 사용할 수 없습니다(비콘체인이 관련 기능을 활성화할 때까지).

(번역자 주: 저자는 여기서 손실을 놓쳤습니다. 비콘 체인이 최종성을 얻을 수 없을 때 증인 메시지를 보내지 않은 검증자는 속도 저하로 인해 처벌을 받을 뿐만 아니라 메시지를 보낸 증인도 손실을 입게 됩니다. , 그러나 손실은 전자보다 적지만 저자는 이 글에서 검증자의 오프라인과 관련된 손실을 주로 다루었기 때문에 그 또한 이해할 수 있다.)

처음 두 가지 손실 유형은 VC가 오프라인인 검증자가 경험할 가능성이 높지만, 세 번째 손실 유형은 VC를 잘못 설정한(또는 비콘 체인이 명시적으로 공격을 받은 경우) 검증자만 경험합니다.중복 VC 시설의 위험

일부 스테이커는 중복 VC를 실행하는 것이 하나의 VC가 오프라인 상태가 되는 것에 대한 보험이라고 생각할 수 있습니다. 그러나 실제로 중복 VC 시설은 안전하지 않으며 검증인이 결국 벌금을 물게 될 가능성이 매우 높습니다!

실제 예를 살펴보겠습니다.

이미지 설명

- 중복 VC는 슬래싱으로 이어집니다! -VC의 장애 조치 프로토콜

참고: "장애 조치"란 VC가 중지된 후 새 VC 인스턴스를 수동 또는 자동으로 다시 시작하는 것을 의미하지만 자동화된 장애 조치 메커니즘을 사용하지 않는 것이 좋습니다. 제대로 구현되지 않으면 오류가 발생할 수 있기 때문입니다. 줄에 매달려!

이전 섹션에서 얻은 교훈은 유효성 검사기가 한 번에 하나의 라이브 VC 인스턴스만 배포해야 한다는 것입니다. 그러나 VC는 항상 실수를 합니다. 이 위험을 어떻게 처리해야 할까요? 스테이커는 이 상황을 처리하기 전에 자체 장애 조치 프로토콜을 정의해야 합니다(새로운 유효성 검사기 클라이언트 인스턴스를 다시 시작해야 하는 용도 결정). 안전하고 신뢰할 수 있는 장애 조치 프로토콜을 개발하기 전에 먼저 유효성 검사기 클라이언트에 내장된 보안 기능인 슬래싱 보호를 살펴보겠습니다.이미지 설명

• - 슬래시 보호 메커니즘 -
• 슬래시 보호 메커니즘: 비콘 체인 클라이언트 팀이 개발한 모든 VC 소프트웨어에는 예기치 않은 이벤트에 대한 자동 페일 세이프 장치로 슬래시 보호 메커니즘이 있습니다. 슬래싱 규칙에 따라 증명 메시지 쌍만 슬래싱이 발생하므로 이 메시지 쌍만 확인하면 결과를 판단할 수 있습니다. 그런 다음 VC는 자체적으로 서명한 모든 메시지와 블록을 로컬 슬래시 보호 데이터베이스에 저장할 수 있습니다. 새 증명 메시지/블록에 서명할 때 VC는 새 메시지가 데이터베이스의 이전 메시지와 충돌하는지 여부(슬래시 메시지 쌍을 형성하는지 여부)만 확인하고 충돌하지 않는 새 메시지에만 서명하면 됩니다.
• 따라서 VC는 올바르고 안전한 작동을 보장하기 위해 세 가지 메커니즘이 필요합니다.

비콘 체인에 대한 정보를 얻기 위해 완전히 동기화된 비콘 체인 노드(BN)검증자는 실제로 메시지에 서명하기 위해 개인 키에 서명합니다.시기 적절한 슬래싱은 데이터베이스를 안전 장치로 보호합니다.

좋은 장애 조치 프로토콜은 두 메커니즘의 오류를 고려해야 합니다. 처음 두 가지는 보장하기 쉽습니다. 새 VC 연결을 위해 중복 BN을 유지할 수 있고 서명 키를 백업 폴더에서 읽기 전용 파일로 복사할 수도 있습니다.

참고: SD 카드는 신뢰할 수 있는 저장 장치가 아니므로 Raspberry Pi에서 VC를 실행하는 스테이커는 슬래시로 보호된 데이터베이스 손실에 특히 취약합니다!

내가 제안한 장애 조치 솔루션

간단하지만 유용한 솔루션은 중복 BN을 유지하고 중복 검증 키에 쉽게 액세스할 수 있도록 하는 것입니다.

• 이미지 설명
• - 초기 VC 설정 및 다중 시나리오 장애 조치 프로토콜 -
• 이 설정에서 다양한 오류는 처리 체계에 해당하는 분포를 갖습니다.

BN 오류 - 그런 다음 중복 BN으로 마이그레이션

유효성 검사기 키 파일 누락 - 콜드 스토리지 백업 키 파일에서 복사됨슬래시로 보호된 데이터베이스 손실 - 데이터베이스 재구축 또는 라이브 백업에서 복원https://youtu.be/awBX1SrXOhk。키 분할 검증기(예: 탄력적인 유효성 검사기 시설을 구현하는 올바른 방법)최적의 탄력성 인프라에는 키 분할 기술이 필요합니다. 이는 또 다른 기사입니다. 자세한 내용은 이 토크 비디오에서 확인할 수 있습니다.