이더리움 병합: 여러 클라이언트를 실행하는 데 따른 위험은 무엇입니까?

원래 번역: 블록 유니콘

원래 번역: 블록 유니콘

피드백과 검토를 해주신 Vitalik Buterin(V God), Hsiao-Wei Wang, Caspar Schwarz-Schilling에게 특별히 감사드립니다.

첫 번째 레벨 제목

여러 클라이언트가 필요한 이유는 무엇입니까?

단일 클라이언트 아키텍처가 선호되는 이유에 대한 논쟁이 있습니다. 그리고 여러 클라이언트를 개발하면 상당한 오버헤드가 발생하므로 다중 클라이언트 옵션을 진지하게 추구하는 다른 블록체인 네트워크를 볼 수 없습니다.

그렇다면 이더리움은 왜 다중 클라이언트를 목표로 하는 것일까요? 클라이언트는 버그를 포함할 가능성이 있는 매우 복잡한 코드 조각입니다. 이들 중 최악은 블록체인의 핵심에서 상태 전환 논리의 오류인 소위 "합의 버그"입니다. 자주 인용되는 예는 취약한 클라이언트가 임의의 양의 이더를 인쇄하는 거래를 수락하는 소위 "무한 자금 공급" 익스플로잇입니다. 누군가 그러한 버그를 발견했지만 출구에 도달하기 전에 중지되지 않은 경우(예: 믹서 또는 교환을 통해 자금을 악용) Ether의 가치가 극적으로 붕괴될 것입니다.

모든 사람이 동일한 클라이언트를 실행하는 경우 체인, 모든 스마트 계약 및 교환이 평소와 같이 계속 작동하므로 중지하려면 사람의 개입이 필요합니다. 단 몇 분이면 성공적인 공격을 실행하고 공격자의 트랜잭션을 롤백하는 것이 불가능할 정도로 자금을 충분히 분산시킬 수 있는 충분한 시간입니다. 인쇄된 ETH의 양에 따라 커뮤니티는 악용 이전(버그가 식별되고 수정된 후)으로 체인의 롤백을 조정할 수 있습니다.

이제 클라이언트가 여러 개인 경우 어떻게 되는지 살펴보겠습니다. 두 가지 가능한 시나리오가 있습니다.

1.취약한 클라이언트는 스테이킹의 50% 미만을 차지합니다., 클라이언트는 버그를 악용하는 트랜잭션으로 블록을 생성하고 ETH를 인쇄합니다. 이 체인을 호출하겠습니다.A。

그러나 결함이 없는 클라이언트를 실행하는 대부분의 스테이커는 이 블록이 유효하지 않기 때문에 이 블록을 무시합니다(그들에게는 인쇄 ETH 작업이 유효하지 않음). 그들은 지을 것이다

그러나 결함이 없는 클라이언트를 실행하는 대부분의 스테이커는 이 블록이 유효하지 않기 때문에 이 블록을 무시합니다(그들에게는 인쇄 ETH 작업이 유효하지 않음). 유효하지 않은 블록을 포함하지 않는 대체 체인 B를 구축합니다.

올바른 고객이 대다수이기 때문에 B-체인은 더 ​​많은 증명을 축적할 것입니다. 따라서 문제가 있는 고객도 체인 B에 투표하게 되고 결과적으로 체인 B는 득표율이 100%가 되고 체인 A는 죽게 됩니다. 오류가 발생하지 않은 것처럼 체인이 계속됩니다.

2.스테이킹된 주식의 대부분은 버그가 있는 클라이언트를 사용하고 있습니다., 이 경우 체인A다수의 투표가 누적됩니다. 그러나 ~로 인해B모든 증명의 50% 미만으로 문제가 있는 클라이언트는 슬레이브 체인을 볼 수 없습니다.A체인으로 전환B이유. 따라서 체인 분할이 표시됩니다.

경우 1이 가장 이상적인 경우입니다. 이는 고아 블록이 될 가능성이 높기 때문에 대부분의 사용자는 눈치채지 못할 것입니다. 개발자는 클라이언트를 디버그하고 버그를 수정할 수 있으며 모든 것이 좋습니다. 대조적으로, 사례 2는 확실히 덜 이상적입니다. 그러나 여전히 하나의 클라이언트보다 낫습니다. 대부분은 매우 빠르게 체인 분할을 감지하고(여러 클라이언트를 실행하여 이를 자동화할 수 있음) 거래소는 예치금을 신속하게 중단하며 Defi 사용자는 분할이 해결될 때까지 기다릴 수 있습니다. 주의해서 진행하십시오. 기본적으로 이것은 여전히 ​​단일 클라이언트 아키텍처에 비해 최악의 결과에 대해 깜박이는 빨간색 경고등을 제공합니다.

사례 2는 결함이 있는 클라이언트가 지분의 2/3 이상으로 운영되는 경우 더 나쁠 것입니다. 이 경우 유효하지 않은 체인을 종료합니다. 이에 대해서는 나중에 자세히 설명합니다.

첫 번째 레벨 제목

클라이언트 다양성에 대한 인센티브 제공: 반관계 페널티

지분이 여러 클라이언트에 분산되어 있는 경우 최상의 시나리오는 각 클라이언트가 총 지분의 1/3 미만을 소유하는 것이며 이는 분명히 네트워크에 이익이 됩니다. 이렇게 하면 단일 클라이언트의 오류에 탄력적으로 대처할 수 있습니다. 하지만 스테이커들이 왜 신경을 쓰겠습니까? 네트워크에 인센티브가 없으면 소수 클라이언트로 전환하는 비용이 발생할 가능성이 적습니다.

안타깝게도 검증자가 실행 중인 클라이언트에 보상을 직접적으로 의존하게 할 수는 없습니다. 속일 수 없는 객관적인 측정 방법은 없습니다.

그러나 클라이언트에 오류가 있는 경우 숨길 수 없습니다. 여기에서 반상관성 페널티가 발생합니다. 유효성 검사기가 잘못된 작업을 수행하는 경우 거의 동시에 더 많은 유효성 검사기가 잘못되면 페널티가 더 높아질 것이라는 생각입니다. 즉, 관련 실패에 대해 페널티를 받게 됩니다.

에테르에서는 현재 두 가지 행동으로 인해 해킹을 당할 수 있습니다.

1. 같은 높이의 블록 두 개에 서명합니다.

2. 한 쌍의 가지치기 가능한 증명을 생성합니다(주변 투표 또는 이중 투표).

삭감되면 일반적으로 모든 자금을 잃지 않습니다. 작성 시점(Altair Fork)에서 기본 페널티는 실제로 매우 작습니다. 0.5ETH 또는 스테이크한 Ether의 1.5%만 잃게 됩니다(결국 1ETH 또는 3%로 증가).

그러나 주의 사항이 있습니다. 유효성 검사기가 삭감되기 전후 4096 에포크(18일) 내에 발생하는 다른 모든 삭감에 따라 추가 페널티가 있습니다. 추가로 처벌받는 금액은 이 기간 동안 삭감된 총 금액에 비례합니다.

첫 번째 레벨 제목

또 다른 반상관 페널티: 2차 비활성 누출

유효성 검사기가 실패하는 또 다른 방법은 오프라인입니다. 다시 말하지만 여기에는 페널티가 있지만 메커니즘은 매우 다릅니다. 우리는 이것을 슬래싱이라고 부르지 않으며 일반적으로 작습니다. 정상적인 작동에서 오프라인 상태인 유효성 검사기는 완전히 유효성을 검사하는 경우와 동일하게 페널티를 받습니다. 이 글을 쓰는 시점에서 연간 성장률은 4.8%입니다. 예를 들어 일시적인 인터넷 중단으로 인해 유효성 검사기가 몇 시간 또는 며칠 동안 오프라인 상태인 경우 식은땀을 흘릴 가치가 없을 것입니다.
유효성 검사기의 1/3 이상이 오프라인 상태이면 상황이 매우 달라집니다. 그런 다음 비콘 체인이 마무리되지 않아 합의 프로토콜의 기본 속성인 활성을 위협합니다.
이와 같은 상황에서 활력을 되찾기 위해 소위 "2차 비활성 누출"이 작용합니다. 체인이 불완전한 동안 유효성 검사기가 계속 오프라인 상태가 되면 총 페널티는 시간이 지남에 따라 2차적으로 증가합니다. 처음에는 매우 낮지만 약 4.5일 후에 오프라인 유효성 검사기는 지분의 1%를 잃게 됩니다. 그러나 ~10일 후 5%, ~21일 후 20%로 증가했습니다(이것이 알테어의 가치이며 향후 두 배가 될 것입니다).

이 메커니즘은 많은 수의 유효성 검사기 작업이 실패하는 치명적인 이벤트가 발생하는 경우 체인이 결국 다시 완료될 수 있도록 설계되었습니다. 오프라인 검증자가 점점 더 많은 지분을 잃으면 전체 지분에서 차지하는 지분은 점점 줄어들고 지분이 1/3 아래로 떨어지면 나머지 온라인 검증인은 필요한 2/3 다수를 확보하여 최종 확정을 가능하게 합니다. 사슬.
첫 번째 레벨 제목

대다수 클라이언트를 실행하는 것이 얼마나 나쁜가요?

위험이 무엇인지 이해하기 위해 세 가지 실패 유형을 살펴보겠습니다.

1. 대량 삭감 이벤트: 대부분의 클라이언트 유효성 검사기는 버그로 인해 삭감 가능한 증명에 서명했습니다.

2. 다수의 오프라인 이벤트: 버그로 인해 대부분의 클라이언트 유효성 검사기가 모두 오프라인 상태가 되었습니다.

3. 유효하지 않은 블록 이벤트: 실수로 인해 대부분의 클라이언트 유효성 검사기는 유효하지 않은 블록이 있음을 증명했습니다.

첫 번째 레벨 제목

시나리오 1: 이중 서명

이것은 아마도 대부분의 유효성 검사기 운영자가 가장 두려워하는 시나리오일 것입니다. 유효성 검사기 클라이언트가 삭제 가능한 증명에 서명하게 하는 버그입니다. 예를 들어 동일한 대상 에포크에 대해 투표하지만 페이로드가 다른 두 명의 증명자가 있습니다. 이것은 클라이언트 버그이기 때문에 문제는 한 명의 스테이커가 아니라 이 특정 클라이언트를 실행하는 모든 스테이커입니다. 이러한 모호성이 발견되면 피바다가 될 것입니다. 관련된 모든 스테이커는 스테이킹한 자금의 100%를 잃게 됩니다. 이것은 우리가 여러 클라이언트를 고려하고 있기 때문입니다. 문제의 클라이언트가 지분의 10%만 지분을 가지고 있는 경우 지분의 "단지" 20%가 삭감됩니다(알테어에서는 30%, 최종 페널티 매개변수 설정).

이 경우 피해는 분명히 극심하지만 그럴 가능성도 매우 낮다고 생각합니다. 삭제 가능한 증명의 조건은 간단합니다. 이것이 이를 시행하기 위해 검증자 클라이언트(VC)가 구축된 이유입니다. 유효성 검사기 클라이언트는 작고 잘 검증된 소프트웨어이며 이 크기의 위반은 발생하지 않습니다.

첫 번째 레벨 제목

시나리오 2: 대규모 오프라인 활동

이 시나리오에서는 대부분의 클라이언트에 트리거될 때 클라이언트 충돌을 일으키는 버그가 있다고 가정합니다. 해당 블록은 이미 체인에 통합되어 있으며 클라이언트가 해당 블록을 만날 때마다 오프라인 상태가 되어 협상에 더 이상 참여할 수 없습니다. 대부분의 클라이언트는 현재 오프라인 상태이므로 비활성 누출이 나타나기 시작합니다.

클라이언트 개발자는 모든 것을 다시 결합하기 위해 분주히 움직일 것입니다. 현실적으로 몇 시간, 최대 며칠 내에 충돌을 제거하는 버그 수정을 릴리스할 것입니다.

그 동안 주문자는 단순히 다른 클라이언트로 전환하도록 선택할 수도 있습니다. 유효성 검사기의 2/3 이상이 온라인 상태가 되도록 충분히 완료되면 2차 비활성 누출이 중지됩니다. 버그가 있는 클라이언트가 수정될 때까지 이런 일이 발생하는 것은 불가능하지 않습니다.

첫 번째 레벨 제목

시나리오 3: 잘못된 데이터 블록

이 시나리오에서 우리는 대부분의 클라이언트가 유효하지 않은 블록을 생성하는 버그를 가지고 있고 또한 유효한 것으로 받아들이는 상황을 고려합니다. 즉, 동일한 클라이언트를 사용하는 다른 검증자가 유효하지 않은 블록을 볼 때 유효한 것으로 간주하여 그것.
유효하지 않은 블록체인 A를 포함하는 체인을 호출해 보겠습니다. 유효하지 않은 블록이 생성되면 두 가지 일이 발생합니다.

1. 모든 작업 클라이언트는 유효하지 않은 블록을 무시하고 대신 별도의 체인 B를 생성하는 최신 유효 헤드를 기반으로 빌드합니다. 모든 작업 클라이언트는 체인 B에서 투표하고 빌드합니다.

2. 결함이 있는 클라이언트는 체인 A와 B가 모두 유효하다고 생각하므로 현재 가장 무겁다고 생각하는 두 체인에 투표합니다.

세 가지 경우를 구분해야 합니다.

1. 취약한 고객은 전체 지분의 절반 미만을 보유했습니다. 이 경우 모든 올바른 클라이언트는 B 체인에 투표하고 빌드합니다., 결국 그것을 가장 무거운 사슬로 만듭니다. 이 시점에서 결함이 있는 클라이언트도 체인 B로 전환됩니다. 하나 또는 몇 개의 고아 블록을 제외하고 나쁜 일이 발생하지 않습니다. 이것은 위안이 되는 상황이며, 대다수의 사용자만 있는 것이 좋은 이유입니다.

2. 취약한 고객은 지분의 절반 이상 2/3 미만을 보유했습니다.이 예에서 우리는 두 개의 체인이 구축되는 것을 볼 수 있습니다. A는 버그가 있는 클라이언트에 의해, B는 다른 모든 클라이언트에 의해 생성됩니다. 두 체인 모두 3분의 2의 다수를 차지하지 않으므로 확정할 수 없습니다. 이런 일이 발생하면 개발자는 두 개의 체인이 있는 이유를 이해하기 위해 안간힘을 쓸 것입니다. 체인 A에 유효하지 않은 블록이 있음을 발견하면 버그가 있는 클라이언트를 수정할 수 있습니다. 수정되면 체인 A를 유효하지 않은 것으로 인식합니다. 따라서 B 체인에서 구축을 시작하여 완료할 수 있습니다. 이는 사용자에게 매우 지장을 줍니다. 어떤 체인이 유효한지에 대한 혼란이 1시간 미만으로 단명하기를 바라지만 체인은 몇 시간 또는 하루 동안 완료되지 않을 수 있습니다. 그러나 제작자, 심지어 문제의 클라이언트를 실행하는 제작자의 경우에도 처벌은 상대적으로 가볍습니다. 유효하지 않은 체인 A를 구축하는 동안 체인 B에 참여하지 않은 경우 "비활성 누출"로 불이익을 받습니다. 그러나 이것은 하루 미만일 수 있기 때문에 우리는 스테이크의 1% 미만의 페널티에 대해 이야기하고 있습니다.

3. 해당 고객이 지분의 2/3 이상을 보유하고 있습니다.이 경우 버그가 있는 클라이언트는 단순히 체인 A를 구축하는 것이 아니라 실제로 체인 A를 "마무리"하기에 충분한 지분을 갖게 됩니다. 체인 A가 완료된 것으로 간주하는 유일한 클라이언트가 됩니다. 종료 조건 중 하나는 체인이 유효하고 올바르게 작동하는 다른 모든 클라이언트의 경우 체인 A가 유효하지 않다는 것입니다. 그러나 Casper FFG 프로토콜의 작동 방식으로 인해 유효성 검사기가 체인 A를 마무리할 때 해당 체인이 마무리되지 않는 한 A와 충돌하는 다른 체인에 해킹되지 않고는 절대 참여할 수 없습니다(자세한 내용은 관심 있는 사람은 부록 참조). 2). 따라서 체인 A가 완료되면 버그가 있는 클라이언트를 실행하는 유효성 검사기는 심각한 상황에 처하게 됩니다. 체인 A에 커밋했지만 체인 A는 유효하지 않습니다. 아직 확정되지 않았기 때문에 B에 기여할 수 없습니다. 유효성 검사기 소프트웨어에 대한 버그 수정도 도움이 되지 않습니다. 그들은 이미 잘못된 투표 용지를 보냈습니다. 지금 일어날 일은 매우 고통스럽습니다. 아직 완료되지 않은 B 체인은 2차 비활성 누출에 들어갈 것입니다. 몇 주 동안 문제가 있는 유효성 검사기는 B가 다시 완료할 수 있을 만큼 충분한 지분을 잃을 때까지 지분을 유출합니다. 그들이 70%의 스테이킹으로 시작한다고 가정해 보겠습니다. 그러면 총 스테이킹의 1/3 미만을 나타내기 위해 잃을 필요가 있는 금액인 79%의 스테이킹을 잃게 됩니다. 이 시점에서 체인 B가 다시 확정되고 모든 스테이커가 체인 B로 전환할 수 있습니다. 체인은 다시 건강해지지만 중단은 몇 주 동안 지속되며 그 과정에서 수백만 ETH가 파괴됩니다.

첫 번째 레벨 제목

위험도 분석

그렇다면 이러한 시나리오를 어떻게 평가할까요? 일반적인 위험 분석 전략은 사건 발생 가능성(1-매우 낮음, 5-매우 높음) 및 영향(1-매우 낮음, 5-재앙)을 평가하는 것입니다. 집중해야 할 가장 중요한 위험은 영향과 가능성의 곱으로 표시되는 두 지표 모두에서 높은 점수를 받는 위험입니다.

이를 염두에 두고 시나리오 3이 최우선 순위입니다. 고객이 3분의 2의 절대 다수에 속할 때 그 영향은 상당히 파국적이며 이는 상대적으로 가능성이 높은 시나리오이기도 합니다. 이러한 취약점이 얼마나 쉬운지 강조하기 위해 최근 Kiln Testnet에서 이러한 버그가 발생했습니다(Kiln Testnet Blocking Proposal Failed 참조). 이 경우 Prysm은 브릭이 제시된 후 결함이 있음을 감지했지만 이를 증명하지 않았습니다. Prysm이 차단이 유효하다고 생각하고 이것이 메인넷에서 발생한다면 시나리오 3의 사례 3에서 설명한 재앙적인 상황에 처하게 됩니다. 현재 Prysm이 메인넷에서 2/3의 다수를 차지하고 있기 때문입니다. 따라서 현재 Prysm을 운영하고 있다면 모든 자금을 잃을 수 있는 매우 실질적인 위험이 있으므로 클라이언트 전환을 고려해야 합니다.

아마도 가장 두려운 시나리오 1은 상대적으로 낮은 평가를 받았습니다. 그 이유는 유효성 검사기 클라이언트 소프트웨어가 모든 클라이언트에 잘 구현되어 있고 왜곡 가능한 증명이나 블록을 생성할 가능성이 낮기 때문에 이런 일이 발생할 가능성이 상당히 낮다고 생각하기 때문입니다.

현재 여러 클라이언트를 실행 중이고 전환이 걱정되는 경우 어떤 옵션이 있습니까?

클라이언트를 교체하는 것은 약간의 위험을 수반하는 중요한 작업이 될 수 있습니다. 마이터 데이터베이스가 새 설정으로 제대로 마이그레이션되지 않으면 어떻게 해야 합니까? 목적을 완전히 상실하는 해킹의 위험이 있을 수 있습니다.

나는 이것에 대해 걱정하는 사람에게 다른 옵션을 제안합니다. 유효성 검사기 설정을 그대로 두고(키 등을 꺼낼 필요 없음) 비콘 노드만 전환하는 것도 가능합니다. 유효성 검사기 클라이언트가 예상대로 작동하는 한 다시 서명하지 않으므로 해킹할 수 없기 때문에 위험이 매우 낮습니다. 특히 유효성 검사기 클라이언트(또는 원격 서명자) 인프라를 변경하는 데 비용이 많이 들고 감사 대상이 될 수 있는 대규모 작업이 있는 경우 이 옵션이 좋은 옵션이 될 수 있습니다. 설정이 예상대로 수행되지 않는 경우 원래 클라이언트로 다시 전환하거나 소수의 다른 클라이언트를 시도하는 것도 쉽습니다.

첫 번째 레벨 제목

처벌받은 고객은 어떻습니까?

위에서 쓴 내용은 컨센서스 클라이언트(Prysm, LightTower, Nimbus, Loestar 및 Teku)에 적용되며, 이 글을 쓰는 시점에서 Prysm은 아마도 네트워크에서 2/3의 다수를 보유하고 있을 것입니다.
이 모든 것은 클라이언트 실행에 동일한 방식으로 적용됩니다. Go-Etherum은 병합 후 대부분의 실행 클라이언트가 될 가능성이 높으며 유효하지 않은 블록을 생성하는 경우 종료되어 시나리오 3에서 설명한 치명적인 오류로 이어질 수 있습니다.
보조 제목

부록

부록 1: 유효하지 않은 블록이 삭제되지 않는 이유는 무엇입니까?

시나리오 3에서는 유효하지 않은 블록을 제안하고 투표하는 검증자에게 페널티를 주기 위해 2차 비활성 누출에 의존해야 합니다. 이상하네요. 그냥 처벌하면 안되나요? 이렇게 하면 더 빠르고 덜 고통스러워 보일 것입니다.

사실, 우리가 그렇게 하지 않는 데는 두 가지 이유가 있습니다. 하나는 현재 우리가 할 수 없지만 할 수 있다 하더라도 아마 하지 않을 것입니다.

1. 현재 유효하지 않은 데이터 블록에 대한 벌칙("슬래시")을 도입하는 것은 거의 불가능합니다. 이는 비콘 체인이나 실행 체인이 현재 "상태 비저장" 상태가 아니기 때문입니다. 즉, 블록이 유효한지 확인하려면 컨텍스트("상태" )가 필요합니다. 이는 블록이 유효하지 않다는 "간결한 증거"가 없음을 의미합니다. 검증자를 삭제하려면 이러한 증거가 필요합니다. 검증자를 "삭제"하는 블록에는 검증자가 법을 위반했다는 증거가 포함되어야 합니다. 상태 비저장 합의가 없는 경우 이 문제를 해결할 수 있는 방법이 있지만 Arbitrum이 현재 집계에 사용하는 것과 같은 다단계 사기 증명과 같은 더 복잡한 구조가 필요합니다.

2. 우리가 이러한 유형의 슬래싱을 도입할 수 있더라도 덜 열성적일 수 있는 두 번째 이유는 유효하지 않은 블록 생성을 방지하기가 현재 슬래싱 조건보다 더 어렵기 때문입니다. 현재 조건은 매우 간단하여 유효성 검사기 클라이언트가 몇 줄의 코드만으로 쉽게 확인할 수 있습니다. 이것이 제가 위의 시나리오 1이 있을 가능성이 낮다고 생각하는 이유입니다. 지금까지 말소 가능한 메시지는 운영자 오류에 의해서만 생성되었으며 이것이 계속될 가능성이 있다고 생각합니다. 유효하지 않은 블록을 생성(또는 증명)하기 위해 슬래시를 추가하면 코인 보유자의 위험이 증가합니다. 이제 소수 고객을 운영하는 사람들도 심각한 처벌을 받을 수 있습니다.

보조 제목

부록 2: 결함이 있는 클라이언트가 체인 A를 완료한 후 체인 B로 전환할 수 없는 이유는 무엇입니까?

이 섹션은 왜 버그가 있는 클라이언트가 단순히 다시 전환할 수 없고 두려운 비활성 누출을 겪어야 하는지 더 자세히 이해하려는 사람들을 위한 것입니다. 이를 위해 Casper FFG 종료가 어떻게 작동하는지 살펴봐야 합니다.

각 증명은 소스 체크포인트와 대상 체크포인트로 구성됩니다. 체크포인트는 에포크의 첫 번째 블록입니다. 한 에포크에서 다른 에포크로 연결되는 링크가 있는 경우 전체 투표의 2/3 이상이 걸린 경우(즉, 첫 번째 체크포인트가 "소스"이고 두 번째 체크포인트가 "타깃"인 많은 증명), 우리는 다음을 호출합니다. 그것들은 "대다수 링크"입니다.

시대는 "합리적"이거나 "정확"할 수 있으며 다음과 같이 정의됩니다.

1. Epoch 0이 정렬됩니다.

2. 합리적인 에포크에 압도적으로 많은 연결이 있는 경우 에포크는 적법합니다.

3. (1) 에포크 X가 정렬되고 (2) 다음 에포크도 정렬되고 대다수 링크의 소스가 에포크 X인 경우 에포크 X가 완료됩니다.

규칙 3은 약간 단순화되었습니다(시대를 마무리하는 데 더 많은 조건이 있지만 이 논의에서는 중요하지 않습니다). 이제 본격적인 인하 조건을 살펴보자. 증명을 삭감하는 데는 두 가지 규칙이 있습니다. 둘 다 한 쌍의 증명 V와 W를 비교합니다.

1. V와 W는 동일한 에포크(즉, 동일한 높이)를 대상으로 하지만 동일한 체크포인트(이중 투표)에 투표하지 않는 경우 해킹 가능합니다.

2. 이는 (1) V의 소스가 W의 소스보다 빠르며 (2) V의 타깃이 W의 타깃보다 늦다는 것을 의미합니다(서라운드 보팅).

첫 번째 조건은 명백합니다. 동일한 높이의 서로 다른 두 체인에 단순히 투표하는 것을 방지합니다. 그러나 두 번째 조건은 무엇을 합니까?

그 기능은 두 개의 충돌하는 체인을 마무리하는 데 관련된 모든 유효성 검사기를 삭감하는 것입니다(절대 발생해서는 안 됨). 그 이유를 알아보기 위해 시나리오 3을 다시 살펴보겠습니다. 최악의 경우 절대 다수의 버그가 있는 클라이언트(지분의 2/3 이상)가 있습니다. 결함이 있는 체인에 계속 투표하면서 다음과 같이 유효하지 않은 블록으로 에포크를 마무리합니다.

이 이미지의 둥근 상자는 블록이 아니라 시대를 나타냅니다. 녹색 화살표는 모든 유효성 검사기가 생성한 마지막 압도적 다수 링크입니다. 빨간색 화살표는 버그가 있는 클라이언트에서만 지원되는 압도적 다수 링크입니다. 작업 중인 클라이언트는 유효하지 않은 블록(빨간색)이 있는 에포크를 무시합니다. 첫 번째 빨간색 화살표는 유효하지 않은 에포크를 정당화하고 두 번째 화살표는 유효하지 않은 에포크를 식별합니다.
이제 버그가 수정되었고 유효하지 않은 에포크를 최종적으로 결정한 유효성 검사기가 올바른 체인 B에 다시 합류하기를 원한다고 가정해 보겠습니다. 체인을 종료할 수 있으려면 첫 번째 단계는 에포크 X를 조정하는 것입니다.

그러나 에포크 X 조정(점선 녹색 화살표로 표시된 압도적 다수 링크 필요)에 참여하려면 두 번째 빨간색 화살표(궁극적으로 유효하지 않은 에포크를 결정하는 화살표)를 "건너뛰어야" 합니다. 이 두 링크를 업보팅하는 것은 자르는 행위입니다.

이것은 이후의 모든 시대에도 계속해서 적용될 것입니다. 문제를 해결하는 유일한 방법은 2차 비활성 누출을 통해서입니다. 체인 B가 성장함에 따라 잠긴 유효성 검사기는 작업 클라이언트가 체인 B를 정당화하고 완료할 수 있을 때까지 자금을 누출합니다.