이더리움의 클라이언트 다양성을 이해하는 것이 왜 그렇게 중요한가요?

저자: 조셉 쿡

편집 원본: Nanfeng, Unitimes

Ethereum에는 서로 다른 언어로 된 독립적인 팀이 개발하고 유지 관리하는 상호 운용 가능한 여러 클라이언트가 있습니다. 이는 위반 또는 공격의 영향을 영향을 받는 클라이언트를 실행하는 네트워크 부분으로 제한하여 네트워크에 복원력을 제공하는 중요한 성과입니다. 그러나 이 이점은 모든 사용자가 사용 가능한 클라이언트에 대략적으로 균등하게 분산되어 있는 경우에만 실현될 수 있습니다. 현재 대부분의 이더리움 노드는 단일 클라이언트를 실행하여 네트워크에 불필요한 위험을 초래합니다.

비콘 체인

비콘 체인

비콘 체인은 PoS 블록체인입니다. 현재는 이더리움 메인넷과 병렬로 실행되지만 곧 두 개가 함께 "병합"될 것입니다. 합병 후, 기존 이더리움 메인넷 클라이언트("실행 클라이언트")는 계속해서 이더리움 가상 머신(EVM)을 호스팅하고 트랜잭션을 확인하고 브로드캐스트하지만 작업 증명(PoW) 마이닝 참여를 중단하고 합의에 대한 책임을 포기합니다. 블록체인 헤드(상단 블록)에.

대신, 이 합의는 합의에 필요한 정보와 함께 "실행 클라이언트"의 트랜잭션을 "비콘 블록"으로 패키징하는 책임이 있는 "컨센서스 클라이언트"의 책임이 될 것입니다. 블록은 비콘 체인을 형성합니다. "채굴자"는 이더리움 스마트 계약("스테이킹"이라고 하는 프로세스)에 ETH를 예치해야 하는 "검증자"로 대체됩니다. 검증인이 스테이킹한 ETH는 검증 작업을 올바르게 완료하도록 장려하기 위한 담보로 사용됩니다. 검증 작업을 수행하지 않거나(예: 오프라인 상태이기 때문에) 악의적인 행동을 수행하는 검증인은 약속한 ETH의 일부를 파괴하게 됩니다. 반면 검증자가 잘 행동하면 ETH로 보상을 받습니다.

1. 검증인의 책임

검증자에게 좋은 행동이란 다른 검증자로부터 받은 비콘 블록의 검증에 참여하고 블록체인 헤드에 투표하는 것을 의미합니다. 검증자가 받은 블록이 유효하면 검증자는 블록을 "증명"하여 블록체인에 추가할 블록에 효과적으로 투표합니다. 때때로 노드는 다른 유효성 검사기가 "증명"할 새 블록을 제안하도록 요청받습니다. 블록체인에 여러 포크가 있는 경우 역사상 가장 많은 "증명"을 축적한 포크만이 올바른 포크입니다.

검증자는 때때로 동기화 위원회에 참여합니다. 동기화 위원회는 무작위로 선택된 512명의 검증자 그룹입니다. 무작위로 선택된 검증자는 블록 헤더를 확인합니다. 라이트 클라이언트가 전체에 액세스하지 않고 이러한 검증된 블록을 검색할 수 있도록 서명합니다. 히스토리 체인 또는 전체 유효성 검사기 세트.

2. 합리화 및 확정

비콘 체인은 네트워크의 속도를 설정합니다. 이 리듬은 슬롯과 에포크의 두 가지 시간 단위로 구성됩니다. 슬롯은 비콘 체인에 블록을 추가할 수 있는 기회이며 12초마다 발생합니다. 슬롯에 블록이 없을 수 있지만 시스템이 최적의 성능을 발휘하면 사용 가능한 모든 슬롯에 블록이 추가됩니다. 에포크의 단위는 32슬롯(약 6.4분)입니다. 슬롯과 시대는 이더리움 블록체인의 리듬을 설정합니다.

각 에포크 동안 첫 번째 슬롯의 블록이 체크포인트입니다. 체크포인트는 블록체인 원장의 기록을 영구적이고 되돌릴 수 없도록 만드는 데 사용되기 때문에 체크포인트가 중요합니다. 2단계 프로세스: 첫째, 모든 활성 검증자가 ETH를 스테이킹한 경우 잔액의 2/3 이상(즉, "대다수")이 증명하는 경우 마지막 2개의 체크포인트(현재 체크포인트를 "타겟 체크포인트"라고 하고 이전 체크포인트를 "소스 체크포인트"라고 함)로 이동한 다음 두 체크포인트 사이의 블록이 "정당화"됩니다.

"합리화"는 이더리움의 권위 있는 체인에서 영구적인 기록이 되기 위한 첫 번째 단계입니다. "합리화된" 체크포인트 다음에 또 다른 "합리화된" 체크포인트가 나타나면 이전 체크포인트는 "최종화"됩니다. 즉, 영구적이고 되돌릴 수 없습니다.

이 "합리화" 및 "종료" 프로세스는 위에서 설명한 것보다 실제로 더 복잡한 "증명"을 수행하기 위해 검증자가 필요합니다. 두 가지 유형의 증명이 있습니다: 하나는 블록체인의 체인 헤드를 증명하는 데 사용되는 LMD GHOST 투표(LMD GHOST는 포크 선택 알고리즘입니다), 두 번째는 두 체크포인트를 증명하는 데 사용되는 FFG 투표(FFG는 블록체인을 합리화하고 마무리하는 "최종 가제트"). 모든 유효성 검사기는 각 체크포인트에 대해 FFG에 투표하는 반면 무작위로 선택된 유효성 검사기 하위 집합만 슬롯당 LMD GHOST에 투표합니다.

상

상

앞서 언급했듯이 검증자가 약속한 ETH는 검증자의 정직한 행동을 장려하기 위해 "담보"로 사용됩니다. 이 스테이킹된 ETH는 유효성 검사기가 네트워크 보안에 참여한 것에 대한 보상으로 시간이 지남에 따라 증가할 것입니다. 검증자가 만든 LMD-GHOST 투표와 FFG 투표가 대부분의 다른 검증자와 일치하면 검증자는 증거 보상을 받게 됩니다. 검증자가 "블록 제안자"로 선정되면 제안한 블록이 "완성"되면 검증자도 보상을 받습니다. 블록 제안자는 제안된 블록에 다른 유효성 검사기의 오작동에 대한 증거를 포함하여 자신의 보상을 높일 수도 있습니다. 이러한 보상은 검증자가 정직하게 행동하도록 장려하는 "보상"입니다.

벌하다

검증자가 받을 수 있는 "처벌"은 다양한 메커니즘의 형태로 검증자가 약속한 ETH의 일부를 파괴하는 것입니다. 검증자가 FFG 투표를 제출하지 않거나, 늦게 제출하거나, 잘못된 FFG 투표를 제출하면 증명 페널티가 부과됩니다. 그러나 검증자가 LMD-GHOST 투표를 놓치면 처벌받지 않지만 체인 헤드에 투표하여 얻을 수 있었던 보상을 놓치게 됩니다. 유효성 검사기 잔액은 올바른 증명을 제출했을 때 받았을 보상과 동일한 금액만큼 삭감됩니다.

즉, 증명을 누락한 정직하지만 "게으른" 검증자에 대한 최대 벌칙은 그가 완벽한 방식으로 증명을 수행했더라면 받았을 보상 금액의 3/4을 잃는다는 것입니다. 또한 검증인이 "동기화 위원회"에 배정될 때 검증인이 블록에 서명하지 못하면 블록에 성공적으로 서명했을 때 받았을 ETH 가치와 동일한 페널티를 받게 됩니다.

전반적으로 이러한 페널티는 경미하며 유효성 검사기의 지속적인 비활성으로 인해 스테이킹된 ETH가 상당히 느리게 삭감됩니다.

압수

더 심각한 조치는 삭감으로, 검증인이 네트워크에서 강제로 제거되고 관련 ETH 예치금이 손실됩니다. 유효성 검사기가 삭감될 수 있는 세 가지 방법이 있으며, 모두 부정직한 블록 제안 또는 블록 증명을 만드는 유효성 검사기와 동일합니다.

- 동일한 슬롯에서 두 개의 다른 블록을 제안하고 서명합니다.

- 블록을 "둘러싸는" 다른 블록에 대한 증명(실제로 블록체인 기록 변경)

- 동일한 블록의 두 후보 블록에 대한 "이중 투표".

이러한 행동이 감지되면 유효성 검사기가 슬래시됩니다. 이는 스테이킹된 ETH의 1/64(최대 0.5 ETH)가 즉시 소각되고 36일의 종료 기간이 시작됨을 의미합니다. (18일차) 삭감 이벤트 전 36일 동안 검증인은 삭감된 모든 검증인이 약정한 총 ETH 금액에 비례하여 추가 페널티를 받게 됩니다.

이는 더 많은 검증인이 삭감될수록 삭감의 규모가 커진다는 것을 의미합니다. 최대 삭감은 삭감된 모든 유효성 검사기의 전체 유효 잔액입니다(즉, 많은 수의 유효성 검사기가 삭감되면 전체 지분을 잃을 수 있음). 반면에 단일 독립 슬래싱 이벤트는 검증인 지분의 작은 부분만 파괴합니다. 삭감된 유효성 검사기의 수에 따라 달라지는 이 중간 페널티를 "상관 페널티"라고 합니다.

비활성 누출 메커니즘

비콘 체인이 4 에포크 이상 완료되지 않으면 "비활성 누출"이라는 경제 메커니즘이 활성화됩니다. 비활성 유출의 궁극적인 목적은 블록체인이 최종화를 재개할 수 있는 조건을 만드는 것입니다. 위에서 설명한 것처럼 "최종성"은 "소스 체크포인트"와 "목적지 체크포인트"에 대한 합의에 도달하기 위해 총 ETH 예치금의 2/3가 필요합니다. 유효성 검사기의 1/3 이상이 오프라인 상태이거나 증명 증명을 제출하지 못하면 2/3의 압도적 다수의 유효성 검사기가 체크포인트를 완료하는 것이 불가능합니다.

이 시점에서 비활성 누출 메커니즘은 이러한 검증자에 의해 제어되는 예금이 네트워크의 총 예금의 1/3 미만이 될 때까지 이러한 비활성 검증자에 속하는 ETH 예금을 점진적으로 줄여 나머지 활성 검증자가 블록체인을 완료할 수 있도록 합니다. 이러한 비활성 유효성 검사기의 수에 관계없이 나머지 유효성 검사기는 결국 총 스테이크의 2/3 이상을 제어합니다. 이 스테이킹 컷은 비활성 검증인이 가능한 한 빨리 재활성화할 수 있는 강력한 인센티브가 될 것입니다!

Beacon Chain 디자인의 보상, 페널티 및 삭감은 개별 검증자가 올바른 일을 하도록 장려합니다. 그러나 이러한 설계 선택에서 여러 클라이언트 간에 검증인의 균등한 분배를 강력하게 장려하고 단일 클라이언트에 의한 이러한 지배력을 강력하게 약화시키는 시스템이 나타납니다. 이것은 "절대 다수 시스템"이 비콘 체인에 매우 중요하기 때문입니다. 단일 악성 검증자는 네트워크에 상당히 무해하지만 다수의 악성 검증자는 심각한 피해를 유발할 수 있습니다. 몇 가지 가능한 시나리오를 살펴보겠습니다...

위험 시나리오

이 자산 인센티브 합의 클라이언트 다양성은 위험합니다. 유효성 검사기를 여러 클라이언트에 고르게 분산하면 클라이언트별 공격 또는 취약성의 영향을 크게 줄일 수 있는 반면 단일 클라이언트 우위는 위험을 증가시킵니다. 이 위험 승수 효과는 단일 지배 클라이언트가 차지하는 네트워크 점유율에 따라 다릅니다.

우리는 몇 가지 가상의(그러나 실제일 가능성이 높은) 시나리오를 통해 더 많은 직관을 얻을 수 있습니다. 컨센서스 클라이언트에 실수로 버그가 도입되어 클라이언트가 잘못된 증명을 직접 만들거나 악의적인 공격자가 클라이언트가 잘못된 증명을 하도록 하는 취약점을 노출한다고 가정해 보겠습니다. 그렇다면 클라이언트 다양성이 이 버그의 결과에 어떤 영향을 미칠까요?

시나리오 1: 영향을 받은 클라이언트가 전체 ETH 예치금의 1/3 미만을 관리합니다.

이 상황은 스테이킹된 ETH의 2/3가 여전히 올바르게 증명되고 있어 비콘 체인이 정상적으로 완료될 수 있기 때문에 비콘 체인에 가장 큰 탄력성을 제공합니다. 따라서 네트워크 관점에서 이 시나리오의 결과는 무시할 수 있습니다. 영향을 받는 유효성 검사기는 잘못된 증명을 제출했기 때문에 게으르다는 이유로 불이익을 받습니다. 이러한 손실은 상대적으로 작으며 영향을 받는 유효성 검사기는 클라이언트가 수정될 때까지 기다리거나 다른 클라이언트로 전환할 수 있습니다. 어느 쪽이든 유효성 검사기는 최소한의 경제적 결과와 비콘 체인을 끊지 않고 정확성을 증명할 수 있습니다.

시나리오 2: 영향을 받은 클라이언트가 모든 ETH 예치금의 1/3 이상을 제어합니다.

이 경우는 ETH 지분의 2/3 미만이 올바르게 증명하도록 남겨져 있기 때문에 훨씬 더 문제가 됩니다. 이는 비콘 체인을 완료할 수 없고 비활성 누출 메커니즘이 활성화됨을 의미합니다. 이 시점에서 버그는 전체 네트워크에 영향을 미쳤습니다. Ethereum에 구축된 거래소 및 Dapps(탈중앙화 애플리케이션)의 경우 블록체인의 완결성이 매우 중요합니다.

이 영향을 받은 클라이언트를 사용하는 개별 유효성 검사기의 경우 관련 처벌이 훨씬 더 가혹합니다. 비활성 누출 메커니즘의 활성화는 개별 유효성 검사기가 약속한 ETH가 버그 제어의 1/3 미만으로 영향을 받을 때까지 점진적으로 소멸됨을 의미하기 때문입니다. 총 ETH 스테이크, 그리고 나서 비콘 체인이 마무리를 재개합니다. 이 ETH 소각은 비콘 체인이 복원된 후에도 실제로 얼마 동안 계속되어 유효성 검사기 수의 작은 변화에 대한 버퍼를 제공할 수 있습니다. 비콘 체인의 마무리는 영향을 받는 단일 클라이언트가 전체 ETH 스테이크의 1/3 이상을 제어하는 ​​경우에만 위험에 처합니다.

이 시나리오에서 다른 대체 클라이언트를 실행하는 유효성 검사기는 비활성 누출 메커니즘이 활성화되어 있는 동안 보상을 받지 못합니다. 이것은 공격자가 제어하는 ​​다른 올바르게 행동하는 유효성 검사기에 대한 총 보상을 증가시키는 비활성 누출 메커니즘을 공격자가 의도적으로 시작하는 것을 방지하는 안전 메커니즘입니다. 이것은 작은 벌칙이지만 요점은 클라이언트가 스테이킹된 총 ETH의 1/3 이상을 제어하는 ​​합의 버그의 부정적인 결과를 피할 수 없다는 것입니다.

시나리오 3: 영향을 받는 고객이 ETH 예치금의 1/2을 관리합니다.

이 상황은 비콘 체인에서 복구할 수 없는 포크로 이어질 수 있습니다. 컨센서스 버그가 있는 클라이언트가 자체 체인으로 포크하는 경우 기존 체인과 새 체인 모두 유효성 검사기의 약 절반이 누락되고 둘 다 비활성 누출 메커니즘을 활성화하기 때문에 원래 체인과 새 포크 체인 모두 종료를 달성할 수 없습니다. 이때, 두 체인에서 누락된 검증자의 ETH 예치금은 그들이 관리하는 예치금이 전체 네트워크 ETH 예치금의 1/3 미만이 될 때까지 점진적으로 소멸되며, Finalization이 다시 시작될 수 있습니다. 완료를 복원하려면 동일한 양의 ETH를 소각해야 하므로 이 프로세스는 두 체인에서 동일한 시간이 걸립니다.

두 체인은 서로 다른 체크포인트를 사용하여 독립적으로 완결을 완료합니다. 이 두 체인은 단일 "권한 체인"으로 병합되지 않을 수 있습니다. 솔루션은 이더리움 커뮤니티가 어떤 체인이 "권한 있는 체인"인지에 대한 합의에 도달해야 합니다. 이 프로세스는 확실히 정치적으로 어렵고 불일치를 유발하여 블록체인 전환으로 인해 커뮤니티 절반의 경제적 손실을 초래합니다(이는 여전히 ETH의 감가 상각 가능성 제외). 더 나쁜 것은 커뮤니티가 계속해서 분열될 수 있다는 것입니다(Ethereum Classic으로 이어지는 The DAO 사건과 유사).

비콘 체인의 영구적인 분할을 피하기 위해 영향을 받는 클라이언트를 사용하는 유효성 검사기는 클라이언트를 전환하기 위해 비활성 누출과 경쟁하거나 블록체인이 완료되기 전에 클라이언트를 수정해야 합니다. 개발자가 Ethereum을 저장하기 위해 출격하는 동안 3-4주가 소요될 수 있습니다. 이 시나리오에서는 다수의 검증자에게 상당한 경제적 손실을 피할 수 없습니다.

시나리오 4: 영향을 받은 클라이언트가 모든 ETH 예치금의 2/3 이상을 제어합니다.

영향을 받는 클라이언트가 대다수의 검증자를 제어하고 자신의 체인을 마무리할 수 있기 때문에 이것은 비콘 체인의 악몽 같은 상황입니다. 이런 식으로 잘못된 정보는 이더리움의 역사에서 영구적으로 수정될 가능성이 높습니다. 블록체인이 불법 블록을 마무리하기 전에 클라이언트 팀은 약 13분 동안 합의 버그를 식별하고 수정하고 영향을 받는 검증자에게 클라이언트 업데이트를 브로드캐스트합니다.

이 상황에서 실행 가능한 유일한 완화 방법은 영향을 받는 유효성 검사자가 스테이크한 ETH를 인출하고 블록체인에서 인출하는 것입니다. 버그가 수정된 후 영향을 받는 유효성 검사기가 올바른 블록체인에 다시 가입하려고 하면 이전에 증명한 것과 동일한 체크포인트를 이제 증명하기 때문에 "담합 페널티"로 인해 삭감됩니다. . 비활성 누출 메커니즘은 많은 수의 유효성 검사기가 떠나기 때문에 활성화될 것입니다. 즉, 영향을 받는 유효성 검사기는 출금(종료)을 기다리는 동안 ETH 예치금을 계속 잃게 됩니다. 많은 수의 유효성 검사기가 종료되면 대기 줄이 길고 느리며 비용이 많이 듭니다.

유일한 다른 옵션은 영향을 받지 않은 나머지 클라이언트가 버그를 수락하고 새 체인에 가입하고 버그가 지금부터 이더리움 합의 계층의 의도된 동작이라는 데 동의하는 것입니다. 이것은 스테이킹 커뮤니티의 핵심 원칙에 위배되며 극도로 분열될 것입니다. 이러한 소수 클라이언트는 제대로 작동하더라도 새 체인에서 게으른 것에 대해 불이익을 받습니다.

다른 위험

다른 위험

역 최종성

단일 클라이언트가 스테이킹된 총 ETH의 2/3 이상을 제어하는 ​​경우 해당 클라이언트의 개발자는 올바른 블록체인 기록 버전을 선택할 수 있습니다. 예를 들어, 이 클라이언트의 개발자가 악의적이면 일부 ETH를 사용할 수 있습니다(예: 교환을 통해 현금화하거나 다른 블록체인 네트워크에 브리징). 지출 트랜잭션의 체인 버전이 현재 완료된 체인을 대체합니다.

이는 클라이언트가 대부분의 유효성 검사기를 제어하여 최종성을 역전시키고 기록을 다시 작성할 수 있도록 하기 때문에 "이중 지출"입니다. 동시에 정직한 소수의 유효성 검사자는 일관성 없는 증명으로 인해 불이익을 받습니다. 총 ETH 예금의 절대 다수를 통제하는 악의적인 공격자는 그렇게 하겠다고 위협하고 네트워크를 장악하여 몸값을 요구할 수 있습니다. 총 ETH 예치금의 1/3을 제어하는 ​​악의적인 당사자조차도 체인 종료를 중지하고 비활성 누출 메커니즘을 활성화하겠다고 위협할 수 있습니다.

공유 책임

집중화

집중화

클라이언트 개발 팀이 순전히 선의의 개발자로 구성되어 있더라도 스테이킹된 ETH의 대부분을 제어할 때 여전히 이더리움 작동에 대한 과도한 권한을 보유합니다. 탈중앙화는 이더리움의 핵심 원칙이며 여기에는 개발자, 사용자 및 관리인의 탈중앙화가 포함되어야 합니다. ETH 예치금을 균등하게 분배함으로써 여러 클라이언트에 걸친 개발 팀의 분산화를 통해 개별 클라이언트 팀이 무엇을 언제 포크할지와 같은 중요한 결정을 내리지 못하도록 제한함으로써 Ethereum의 철학적 방향에 미치는 영향을 제한합니다. 클라이언트 다양성은 개발자 수준에서 분산된 의사 결정을 보장합니다.

정치

정직한 체인의 사회적 회복은 정치적으로 어려운 문제입니다. 이더리움의 합의 메커니즘은 클라이언트에 인코딩된 규칙을 기반으로 결정되어야 합니다. 이것이 주요 목표입니다. 이 프로세스를 방해하면 이더리움 커뮤니티가 분열되어 여러 사용자가 주요 클라이언트에 대한 합의된 버그/공격을 완화하는 데 다양한 철학적, 윤리적, 기술적 관점을 갖게 될 수 있습니다. 거버넌스 결정은 다루기 힘들고 파괴적이며 효율성을 극대화하기에는 너무 느릴 수 있습니다.

실제 예

위의 시나리오가 발생할 확률은 상대적으로 낮습니다. 개발자는 소프트웨어에 대한 모든 업데이트를 세심하게 연구하고 테스트하며 클라이언트 팀의 전문적인 무결성을 의심할 이유가 없습니다. 그러나 이러한 시나리오도 순전히 가설이 아닙니다. 클라이언트 다양성이 이더리움 메인넷이 영구적으로 손상되는 것을 막은 실제 사례가 있었고 일부 합의 버그도 이더리움 테스트넷을 망가뜨렸습니다. 이에 대한 몇 가지 예가 아래에 설명되어 있습니다.

상하이 공격

2016년 9월 상하이에서 열린 DevCon 컨퍼런스에서 해커가 이더리움을 공격하여 클라이언트 소프트웨어의 여러 취약점을 악용하여 네트워크 속도를 크게 저하시켰습니다. 공격자는 인내심을 갖고 새롭고 유사한 공격을 신속하게 배포하는 반면 클라이언트 개발자는 이러한 공격을 리버스 엔지니어링하고 패치하기 위해 경쟁합니다. 궁극적으로 공격자는 Geth 클라이언트에서 패치할 수 없는 취약점을 발견하여 하드포크를 불가피하게 만들었습니다. 하드 포크 업그레이드 이후에도 공격자는 이전 공격으로 인해 부풀려진 상태를 악용하여 클라이언트가 블록당 수만 개의 느린 디스크 I/O 작업을 수행하도록 하는 서비스 거부 취약점을 발견했습니다. 개발자가 Geth의 취약점을 수정하기 위해 노력하는 동안 Ethereum은 동일한 취약점을 겪지 않는 대체 패리티 클라이언트로 이동할 수 있었기 때문에 클라이언트 다양성이 승리했습니다.

상하이 공격은 여러 클라이언트로 인해 복구할 수 있지만 유사한 버그가 다수의 컨센서스 클라이언트에 영향을 미쳤다면 상황은 매우 다를 수 있습니다. "합의 클라이언트"가 Geth가 공격을 받았을 때와 동일한 우세한 위치에 있었다면 대부분의 유효성 검사기가 현재 블록을 증명할 수 없기 때문에 이더리움 금액이 확정되지 않을 것입니다. 비활성 누출은 ETH 스테이크의 1/3 미만이 증명에 사용할 수 있기 때문에 활성화됩니다.

안전하지 않은 체인

"원격 공격"의 가능성은 최근 Pyrmont 테스트넷에서 시연되었습니다. 아이디어는 대체 블록체인 기록을 증명하기 위해 일련의 유효성 검사기를 구축하는 것입니다. 그런 다음 이러한 유효성 검사기는 새로운 유효성 검사기를 속여 이 부정직한 "Insecura" 체인에 참여하도록 속이고 영향을 받는 유효성 검사기의 수를 점차적으로 늘리며 결국 블록체인 최종화를 방해하고 비활성 누출을 활성화하며 정직성을 고갈시키는 지점에 도달합니다. 대부분의 유효성 검사기. 궁극적으로 이로 인해 영향을 받는 고객이 자신의 블록체인 버전을 마무리할 수 있습니다. 필요한 시간과 비용 투자로 인해 이 동작은 가능성이 낮은 공격 벡터가 되지만 유사한 역학으로 인해 지배적인 합의 클라이언트의 버그가 네트워크의 많은 부분을 감염시킬 수 있습니다.

메달라 테스트넷

이전에는 Prysm 클라이언트의 시계 문제로 인해 Medalla 테스트넷의 활성 유효성 검사기 수가 갑자기 떨어졌습니다. 너무 많은 유효성 검사기가 네트워크에서 떨어져서 대부분의 스테이킹된 ETH의 2/3가 더 이상 증명할 수 없기 때문에 체인을 마무리할 수 없습니다. 클라이언트를 Prysm에서 소수의 다른 클라이언트로 전환하는 유효성 검사기에 의존하기 때문에 복구는 점진적입니다. 그러면 Prysm 클라이언트의 잘못된 시계 시간으로 실시간이 잡히고 이전에 유효하지 않은 증명이 갑자기 유효해집니다.

이로 인해 Prysm 클라이언트가 중단되었고 Teku 및 Lighthouse 클라이언트도 갑자기 많은 수의 증명을 처리하여 엄청난 상태 팽창을 경험했습니다. Prysm이 Medalla 테스트넷의 유일한 클라이언트였다면 전체 네트워크가 중단되었을 것입니다.

프리즘 보증금 루트 버그

2021년 초, Prysm 클라이언트는 Eth1 예금 루트 확인과 관련된 버그를 발견했습니다. 당시 Prysm 클라이언트는 유효하지 않은 보증금 루트를 생성하여 다른 Prysm 노드에 전달할 수 있었습니다. Prysm은 매우 큰 검증자 점유율을 가지고 있기 때문에 이러한 유효하지 않은 스텁은 네트워크 전체에 빠르게 확산되고 Prysm은 매 블록마다 스텁을 명시적으로 검증하는 대신 다수결 메커니즘을 따르기 때문에 확산이 가속화됩니다.

이 버그의 영향은 미미했지만 비콘 체인의 마무리를 방해하지 않았고 검증자에게 상당한 재정적 불이익을 주지는 않았지만 이 사건은 두 가지 측면에서 클라이언트 다양성의 중요성을 입증했습니다. 유효성 검사기 공유가 적으면 네트워크 전체에 버그의 확산을 제한하고 그 영향을 줄일 수 있습니다. 분명히 이것은 활발하게 유지 관리되는 여러 클라이언트 없이는 불가능합니다.

이미지 설명

위의 그림은 현재 Ethereum 클라이언트의 다양성을 보여줍니다. 실행 클라이언트의 비율은 왼쪽에 있고 합의 클라이언트의 비율은 오른쪽에 있습니다.

위의 두 파이 차트는 이더리움의 실행 및 합의 레이어의 현재 클라이언트 다양성에 대한 스냅샷을 보여줍니다(이 글을 쓰는 시점, 2022년 1월): 실행 레이어는 Geth 클라이언트가 지배하고 있으며, OpenEthereum 클라이언트는 그 다음입니다. 두 번째는 Erigon입니다. 클라이언트는 3위, Nethermind는 4위, 기타 클라이언트는 네트워크의 1% 미만을 차지합니다. 합의 계층에서 가장 많이 사용되는 클라이언트인 Prysm은 실행 계층에서 Geth 클라이언트만큼 지배적이지는 않지만 여전히 네트워크의 60% 이상을 소유하고 있으며 Lighthouse와 Teku는 각각 20%와 14%를 차지하고 있으며 다른 사용자는 거의 사용하지 않습니다.

2022년 1월 23일 Ethernodes 웹사이트(ethernodes.org/)의 실행 계층 데이터, Michael Sproul(github.com/sigp/blockprint)의 컨센서스 클라이언트 데이터. 컨센서스 클라이언트 데이터는 비콘 체인 클라이언트가 식별하는 데 사용할 수 있는 명확한 흔적이 항상 있는 것은 아니기 때문에 얻기가 더 어렵습니다. 데이터는 때때로 소수의 클라이언트를 오도하는 분류 알고리즘을 사용하여 생성됩니다. 그러나 컨센서스 레이어에 있는 대부분의 네트워크 노드가 Prysm을 실행하고 있다는 것은 분명합니다. Prysm의 지배력은 때때로 더 높아서 68%를 초과했습니다. 스냅샷에 불과하지만 그래프의 백분율은 클라이언트 다양성의 현재 상태에 대한 전반적인 이해를 제공합니다.

실행 레이어의 클라이언트 다양성은 위 그림에 포함되어 있습니다. 실행 클라이언트에 영향을 미치는 버그가 합의 레이어에도 전파될 수 있기 때문입니다. 합병 후 합의 레이어와 실행 레이어가 함께 결합되고 실행이 생성되기 때문입니다. 실행 클라이언트 실행 페이로드는 비콘 블록의 핵심 구성 요소입니다.

개인 스테이킹 및 스테이킹 풀

불균형한 클라이언트 할당 문제를 해결하려면 주요 거래소 및 스테이킹 풀의 조치가 필요합니다. 그러나 개별 스테이커는 비Geth/Prysm 클라이언트 조합을 실행하도록 선택하여 역할을 수행할 수도 있습니다. 소수의 클라이언트 구축에 대한 지침은 여기에서 찾을 수 있습니다.clientdiversity.org페이지를 찾았습니다.

32 ETH 미만을 보유하고 있거나 검증자 운영 책임을 맡고 싶지 않은 스테이커를 위해 일부 스테이킹 서비스 제공업체를 이용할 수 있습니다. 일부 주요 중앙 집중식 거래소는 ETH 스테이킹 서비스를 제공하지만 스테이킹 풀의 고객 분포는 일반적으로 숨겨져 있으며 이러한 거래소에서 제공하는 ETH 스테이킹 토큰의 거래 가능성은 제한적입니다. 이러한 이유로 이러한 중앙 집중식 공급자를 사용하는 것은 권장되지 않습니다.

요약하다

요약하다

원본 링크

원본 링크