이더리움 2.0 스테이킹 베테랑 드라이버 가이드: 스테이킹을 피하는 세 가지 팁
편집자 주: 이 기사의 출처는배빗 정보 (ID: bitcoin8btc)편집자 주: 이 기사의 출처는
배빗 정보 (ID: bitcoin8btc)
배빗 정보 (ID: bitcoin8btc)
, 저자: Raul Jordan, 번역: 무료 및 간편함, 허가 하에 게시됨.
이 글은 이더리움 2.0 네트워크의 슬래싱 메커니즘에 대해 설명합니다.Staking 참여자(특히 직접 참여하는 사람들)의 경우 어떤 상황에서 슬래싱이 발생하고 슬래싱을 피하는 방법을 이해해야 합니다. 이 문서에 제시된 대부분의 정보는 클라이언트 선택에 구애받지 않습니다. 즉, Prysm, Lighthouse, Teku, Nimbus 또는 다른 Ethereum 2.0 클라이언트를 실행하는지 여부에 관계없이 모든 사용자에게 적용됩니다.
원작자는 Prysmatic Labs의 공동 설립자인 Raul Jordan입니다.
*중요 면책 조항*
Prysmatic Labs는 클라이언트 버그 또는 문서 오류를 포함하여 원인에 관계없이 사용자 자금 손실에 대해 책임을 지지 않으며 이러한 책임 배제는 삭감 프로세스까지 확장됩니다. 모든 이더리움 2.0 클라이언트는 다른 개발 프로젝트와 마찬가지로 코드베이스가 안전한지 확인하기 위해 최선을 다하지만 항상 오류 가능성이 있습니다. 이더리움 2.0에 참여하는 것은 위험한 활동이며 참여자들이 자신이 짊어질 위험과 책임을 조사하고 이해하는 것이 중요합니다.
슬래싱이란 무엇입니까?
검증인이 이더리움 네트워크와 경쟁하는 행동을 보일 때 슬래싱이 발생합니다. 슬래싱은 반드시 악의적인 의도로 인한 것은 아니며 잘못된 구성으로 인한 것일 수도 있습니다. 검증자의 행동은 시스템에 혼란을 일으키거나 무결성을 파괴할 수 있으므로 네트워크에 피해를 주는 검증자는 약속한 ETH에 대해 돌이킬 수 없는 불이익을 받게 됩니다.
삭감과 비활성 페널티를 혼동하지 않기 위해 삭감의 목표는 이더리움 2.0 네트워크에 해를 입히려는 사람들을 억제하고 계획대로 이더리움 2.0 네트워크를 유지, 관리 및 운영하는 사람들에게 보상하는 것입니다. 슬래싱의 주요 목적은 이더리움 2.0 네트워크에서 수행되는 공격을 완화하는 것입니다. 예를 들어 서로 다른 체크포인트 기록 보기에서 충돌하는 유효성 검사기 포크를 생성하는 것입니다.
프로토콜을 올바르게 따르는 유효성 검사기는 정상적인 작동에서 절대 삭감 가능한 투표를 발행하지 않으며 유효성 검사기는 오프라인 상태로 인해 삭감되지 않습니다.
슬래싱 작동 방식
삭감 행위는 이더리움 네트워크에 피해를 주는 검증인의 스테이킹 자금을 파괴하여 강제로 네트워크를 떠나게 하고 선량한 행위자를 홍보하여 블록체인의 보안을 강화합니다.
삭감은 처벌의 한 형태이지만 검증자가 잘못 구성되면 일반 사용자도 삭감될 수 있습니다. 따라서 인증자 클라이언트 및 운영 체제를 올바르게 설정하고 관리하는 방법을 아는 것이 중요하며 사용자는 전체 기능을 이해하지 않고 고급 지침을 사용하려고 시도하지 않아야 합니다.
유효성 검사기는 서로 다른 루트(본질적으로 내부 데이터의 해시)를 가진 동일한 슬롯에서 두 개의 충돌하는 블록을 제안합니다. 이러한 행동이 처벌되지 않으면 검증인이 불필요한 포크를 만들거나 혼란을 일으키기 쉽습니다. 참고: 단순히 동일한 블록을 두 번 제안하는 것은 삭감되지 않습니다.
유효성 검사기는 동일한 슬롯에서 충돌하는 두 블록을 증명합니다. 이것은 이중 투표로 알려져 있으며 유효성 검사기가 체인의 충돌 포크를 생성하려고 시도할 수 있음을 의미합니다. 참고: 동일한 블록에 대해 단순히 두 번 투표하는 것은 삭감되지 않습니다.https://github.com/protolambda/eth2-surround
유효성 검사기가 던진 투표는 이전 투표에 의해 "둘러싸여" 있거나 "둘러싸여" 있습니다.
이미지 설명
Ethereum 2.0 주변 투표,1、2몰수된 후에는 어떻게 됩니까?
슬래싱을 방지하기 위한 여러 메커니즘이 있지만 각 유효성 검사기 키 쌍이 하나의 유효성 검사기에서만 사용되는 것이 중요합니다. 이것은 쉬운 것처럼 들리지만 여러 유효성 검사기가 구성된 경우 실수로 유효성 검사기를 복원하고 이미 실행 중인 유효성 검사기를 복제하기 쉽습니다. 변경할 때 올바른 유효성 검사기 키가 사용/복원/설정되고 있는지 항상 확인하십시오.
여기에서 찾을 수 있습니다(
) 추가 리소스를 찾습니다.유효성 검사기가 슬래시되면 여러 가지 일이 발생할 수 있습니다.）；
삭감된 검증인은 36일 이내에 비콘 체인에서 철수해야 합니다.
삭감된 유효성 검사기는 세 가지 유형의 페널티에 직면합니다(
원천
페널티는 유효성 검사기가 종료 대기열을 떠날 때까지 각 에포크에서 시작됩니다.여기。
블록에 포함된 보고 메시지와 삭감된 유효성 검사기 종료 사이의 중간에 이 기간 동안 얼마나 많은 다른 유효성 검사기가 삭감되었는지에 비례하여 특별 페널티가 부과됩니다. 해당 슬래시 개체의 모든 유효 잔액까지 적용 가능한 최대값입니다.
즉, 검증인이 삭감되면 즉시 페널티를 받고 나갈 수 있을 때까지 약 36일 동안 계속 페널티를 받게 되며, 18~36일 이내에 일회성 페널티를 받게 되며, 삭감된 금액도 영향을 받습니다. 동일한 에포크 동안 삭감된 유효성 검사기의 수만큼(즉, 이것이 공동 공격인지 별도의 공격인지 결정하기 위해). 자세한 지침은 다음을 방문하십시오.
여기
마지막으로 슬래시된 검증인은 검증인 세트에 다시 들어갈 수 없다는 점에 주목할 가치가 있습니다. 검증자가 검증을 계속하려면 새로운 서약을 하고 새로운 키를 생성해야 하며 페널티는 돌이킬 수 없습니다!
일반적으로 삭감되면 스테이킹된 ETH가 점점 줄어들고 그 과정에서 상당한 손실이 발생합니다. 36일 후에는 비콘 체인을 종료하고 남은 ETH를 모두 인출할 수 있으며 이 36일 기간 동안 ETH의 상당 부분을 잃게 됩니다.
삭감으로 이어지는 일반적인 사용자 오류
위에서 언급한 삭감 시나리오는 일반 사용자에게는 불가능해 보이지만 잘못된 구성으로 인해 정직한 검증자도 삭감될 수 있습니다! 다음은 이러한 상황이 발생할 수 있는 몇 가지 시나리오입니다.
1. 동일한 인증 키가 두 서버에서 동시에 실행되며 첫 번째 서버가 실패할 경우 그 중 하나를 장애 조치로 사용할 수 있습니다.
참고: 이것은 슬래시되는 가장 쉬운 방법이며 장애 조치 시스템이 첫 번째 노드가 다운되었다고 잘못 보고하는 경우 슬래시 상황에 처할 수 있습니다.
동시에 두 곳에서 확인 키를 실행하지 마십시오!
2. 압수된 보호 기록을 마이그레이션하지 않고 키를 다른 컴퓨터 또는 다른 Ethereum 2.0 클라이언트로 마이그레이션했습니다.
설명: 다른 노드에 잘못 동기화된 시계가 있을 수 있습니다. 이로 인해 슬래시가 발생할 수 있으며 슬래시 보호 기록을 마이그레이션하면 쉽게 우회할 수 있습니다.
3. 유효성 검사기 클라이언트에서 슬래시 보호 기록을 삭제하거나 분실했습니다.
설명: 슬래시 보호 기록을 잃으면 슬래시될 블록이나 투표를 생성하기 위해 시계가 엉망이 되는 것과 같은 문제가 발생할 수 있습니다.
4. 영구 볼륨(PV) 없이 컨테이너화된 환경을 사용하여 검증
5. 슬래싱 오류로 이어질 수 있는 프로토콜 버그(가능성은 낮지만 최악의 경우임)여기검증인을 선택할 때 설치된 소프트웨어를 설정, 구성, 업그레이드 및 문제 해결하는 방법을 아는 것이 중요합니다. 존재하다여기여기
(ethereumprice.org) 이더리움 2.0 스테이킹 참여의 위험을 더 잘 이해할 수 있는 좋은 리소스는 다음에서 찾을 수 있습니다.
여기
슬래싱 조건을 감지하는 방법을 설명하는 다른 리소스가 있습니다.
몰수를 수행하는 사람은 누구입니까?
슬래셔
슬래셔는 슬래시 가능한 이벤트를 감지하는 것이 주 목적인 별도의 소프트웨어를 말합니다. 슬래셔(Slashers)는 이더리움 2.0 네트워크의 "경찰"로 생각할 수 있습니다.악성 메시지를 감지하는 데 필요한 추가 데이터 및 처리로 인해 이러한 슬래셔는 일반적으로 비콘 노드와 독립적으로 실행됩니다. slashable 메시지를 감지하기 위해 slasher는 네트워크에 있는 모든 유효성 검사기의 증명 및 제안 기록을 기록하고 브로드캐스트 콘텐츠와 해당 기록을 상호 참조하여 이중 블록 또는 주변 투표와 같은 slashable 메시지를 찾습니다.
네트워크에 필요한 것은 네트워크를 모니터링하는 정직한 슬래셔 클라이언트입니다. 발견된 모든 슬래시는 가능한 한 빨리 블록에 포함되도록 네트워크 전체에 전파됩니다.
내부 고발자 보상
슬래시 감지를 장려하기 위해 유효성 검사기는 유효한 슬래시가 포함된 블록을 제출한 비콘 체인에 대한 보상인 "고발자 보상"을 받게 됩니다. 이러한 보상은 슬래시에 참여하는 검증인에게 주어지며, 보통 검증인당 0.1 ETH 정도의 보상을 받습니다.
인센티브 감지는 가치가 있지만 Prysm에서 슬래싱을 발견한 경우 슬래셔 클라이언트를 실행하는 것만으로는 내부 고발자 보상을 받을 수 없습니다. 기본적으로 발견된 모든 슬래시는 가능한 한 빨리 블록에 포함되도록 네트워크에 브로드캐스팅되므로 일반적으로 보상은 슬래셔를 실행하는 검증자가 아닌 슬래시가 감지된 직후 제안자에게 전송됩니다.
슬래셔를 운영한다고 해서 수익성이 있는 것은 아닙니다. 몰수는 드물고 내부 고발자에 대한 보상은 낮게 설정되어 있습니다. 본질적으로 슬래셔를 운영하는 것은 이타적인 행동이며, 다시 말하지만 정직하고 작동하는 슬래셔만 네트워크에서 활성화되어 위반 사항을 포착해야 합니다. 다행스럽게도 이것은 진입 장벽이 낮으며 상당수의 사용자와 엔티티가 네트워크를 보호하기 위해 슬래셔를 실행할 것으로 예상합니다.
압수된 예방접종
좋은 소식이 있습니다. 몰수는 예방할 수 있습니다! 삭감되지 않도록 하는 많은 모범 사례가 있지만 이를 이해하는 것이 중요합니다.
1. 지역 몰수 방지 데이터베이스
여러 클라이언트에서 구현하는 슬래싱 보호 방법 중 하나는 로컬 서명 기록 데이터베이스입니다. 이 기능은 Prysm의 유효성 검사기 클라이언트에서 기본적으로 활성화됩니다. 이 데이터베이스는 유효성 검사기가 자체 기록을 기반으로 슬래시 가능한 메시지로 간주되는 메시지에 서명하지 않도록 합니다. 더 간단히 말해서 유효성 검사기는 메시지 서명 여부를 결정할 때 데이터베이스를 유일한 정보 소스로 간주합니다. 이 접근 방식은 단일 유효성 검사기가 중복 작업을 수행하지 않도록 합니다.
로컬 슬래싱 보호는 동일한 유효성 검사기 키를 사용하여 여러 유효성 검사기 인스턴스를 실행하는 것을 방지하지 않습니다.
데이터베이스는 해당 로컬 인스턴스의 유효성 검사기에 대한 서명 이벤트만 추적합니다. 이것은 또한 사용자가 유효성 검사기를 다른 클라이언트로 변경하거나(예: Lighthouse에서 Nimbus로 마이그레이션) 새 하드웨어 설정으로 이동(새 Linux 시스템에 설치, 호스팅된 솔루션으로 마이그레이션)하면 서명이 기록 데이터베이스도 마이그레이션해야 합니다. 이렇게 하면 새 클라이언트에서 과거 작업의 기록이 보존됩니다.
2. 원격 베기 보호
슬래싱을 방지하기 위한 또 다른 대안 구현은 슬래셔를 사용하는 것입니다. 슬래셔는 수신한 모든 증명과 블록을 기록하며 유효성 검사기는 서명 메시지에 동의하기 전에 인용합니다. 이 접근 방식은 로컬 서명 기록 데이터베이스보다 강력한 형태의 슬래싱 보호이지만 데이터베이스와 마찬가지로 동일한 유효성 검사기의 여러 인스턴스를 실행하는 것을 방지하지 않습니다.
슬래싱을 방지하기 위한 또 다른 구현은 슬래셔 자체를 비콘 노드와 유효성 검사기 클라이언트 사이의 미들웨어로 사용하는 것입니다. 유효성 검사기 클라이언트가 블록 또는 증명을 제출하기 전에 먼저 슬래셔에게 슬래시 가능한지 묻습니다.
검사를 통과하면 데이터가 비콘 노드를 통과합니다. 이상적으로는 슬래셔가 네트워크에서 일어나는 모든 일에 대해 알고 각 유효성 검사기의 블록 및 증명 기록을 기록하기 때문에 이것은 슬래시 보호의 가장 발전된 형태입니다. 그러나 한 가지 주목해야 할 점은 Prysm에서 원격 슬래싱 보호가 아직 최적화되지 않았다는 것입니다. 슬래셔는 여전히 리소스를 많이 잡아먹기 때문입니다. 슬래셔의 리소스 소비가 높기 때문에 유효성 검사기가 증명이나 블록을 놓칠 수 있습니다. 원격 슬래싱 보호는 로컬 슬래싱 보호 위에 추가 레이어로 작동하도록 설계되었습니다. 보안상의 이유로 사용자는 Prysm에서 로컬 슬래싱 보호를 비활성화할 수 없습니다.
3. 몰수 보호 내역 마이그레이션
때때로 스테이킹 머신을 전환하거나 자신에게 적합한 다른 Ethereum 2.0 클라이언트로 마이그레이션할 수 있습니다. 어떠한 경우에도 몰수 보호 기록을 항상 휴대해야 합니다.이더 리움몰수 보호 표준: EIP-3076EIP-3076현재 마이그레이션에 대한 공식 표준이 있습니다.
이더 리움
2.0 슬래시로 보호된 클라이언트 간의 기록, 이를 호출합니다.
. 이 표준은 유효성 검사기의 슬래시 보호 기록을 JSON 파일로 표현하도록 제안합니다. 이 파일에는 다음이 포함됩니다.
검증 이력의 체인 초기 상태에 대한 정보(테스트넷과 메인넷을 구분하는 데 사용됨)
사용자의 실행 중인 유효성 검사기 공개 키에 대한 모든 서명된 블록 및 서명 증명 정보
이 파일을 내보내고 다른 컴퓨터나 Ethereum 2.0 클라이언트로 마이그레이션할 때 가져오면 많은 이점을 얻을 수 있으며 이 로컬 기록을 저장하지 않는 단순한 삭감 조건을 피할 수 있습니다.
기존 인증 키를 Prysm으로 가져오기
보도 시간 현재 Prysm v1.0.1에서 Prysm은 사용자가 EIP-3076 슬래시 보호 JSON 파일을 유효성 검사기 클라이언트로 가져오는 것을 허용하지 않습니다. 이것은 Ethereum 2.0 메인넷이 가동된 후 다음 버전에서 구현될 수 있는 Prysm 팀의 최우선 과제입니다.
Prysm에서 슬래시 보호 기록 내보내기
보도 시간 현재 Prysm v1.0.1에서 Prysm은 사용자가 슬래시 보호 기록을 EIP-3076 슬래시 보호 JSON 파일로 내보내는 것을 허용하지 않으며, 다시 한 번 Prysm 팀은 이 목표를 달성하기 위해 열심히 노력하고 있습니다.
머신을 마이그레이션하려는 경우 Prysm이 슬래시 보호 기록 내보내기를 지원할 때까지 기다리는 것이 좋습니다. 정말로 기다릴 수 없다면 명심해야 할 몇 가지 중요한 사항이 있습니다.
머신 1에서 비콘 노드와 유효성 검사기를 종료하고 시스템 프로세스로 실행되고 있지 않은지 확인합니다. 운영 체제의 프로세스 모니터 도구 또는 top 또는 htop과 같은 명령줄 도구를 사용하여 "prysm", "validator" 또는 "beacon"이라는 이름이 포함되어 있는지 확인할 수 있습니다.
지갑 디렉토리 위치를 기록하십시오. 기본값으로 Prysm을 시작한 경우 "Authenticator Account List" 출력 상단에서 운영 체제에 따라 다른 경로를 볼 수 있습니다.
전체 카탈로그를 가져와 다음 컴퓨터로 마이그레이션하십시오.
