작성자: imToken Labs
개요
5월 11일과 12일 이틀 연속으로 이더리움 합의 레이어에 잠시 이상 현상이 발생했는데, 아임토큰은 이러한 이상 현상이 주로 특정 유형의 이더리움 합의 레이어 클라이언트 노드에 과도한 부하를 가해 검증기가 오프라인 상태가 되었기 때문에 발생한 것으로 분석했습니다. Epoch 투표는 2/3에 도달하지 못했습니다. 합의 레이어는 최종성을 확인할 수 없었지만 짧은 시간 후에 이더리움 네트워크가 정상으로 돌아왔습니다. imToken은 이것이 이더리움 PoS 합의 알고리즘이 탄력성과 자체성을 가지고 있음을 보여준다고 믿습니다. -치유능력.
사건과 배경
일반적으로 이더리움 PoS 합의 네트워크 상태는 2번의 Epoch에 확정(Finalized)되는데, 지난주에 2번의 Epoch 확정 지연이 있었습니다.
첫 번째 발생일은 5월 11일이며, 에포크 확정이 3 에포크(약 20분) 지연됐다.
두 번째는 5월 12일에 발생했는데, 에포크 확정이 8 에포크(약 51분) 지연됐다.
사건이 발생한 동안 이더리움 네트워크는 계속해서 블록을 생성하고 거래를 처리했습니다. 그러나 검증자(검증 노드)의 투표율이 부족하여 Epoch를 확정하지 못했습니다(즉, Epoch는 이더리움 PoS 네트워크 합의 수준의 보안 보장을 받았습니다). Epoch가 완료되지 못한다는 것은 대다수의 Validator가 악의적인 행위를 하고 포크가 발생하는 경우 epcoh가 롤백되어 트랜잭션이 롤백될 수 있음을 의미합니다.
실제로 사건 발생 당시 이더리움 네트워크에는 포크가 없었고, 검증인이 악의적인 투표를 진행한 적도 없었는데, 단지 다수의 검증인이 오프라인 상태였기 때문에 투표율이 부족해 투표율이 부족했기 때문이다. 해당 기간 동안 에포크가 확정되지 않습니다.
관찰 결과, 오프라인 검증인은 비정상적인 CPU 과부하를 겪고 있으며, 이는 검증인이 오프라인이 되는 직접적인 원인으로 간주됩니다.
두 번째 사건에서는 Epoch 마무리가 8 Epoch 지연되었는데, 마무리 지연이 MIN_EpochS_TO_INACTIVITY_PENALTY (=4)보다 컸기 때문에 이더리움 합의 알고리즘 비활성 누수 처리 메커니즘이 작동되었습니다.
- 오프라인 검증인은 처벌을 받았고 약속된 자금이 줄어들었으며 약 28 ETH의 벌금이 부과되었습니다 .
- 증명 보상을 취소하면 약 50ETH가 발행되지 않습니다 .
- 이 메커니즘은 온라인 유효성 검사기가 최종적으로 이더리움 총 약속 자금의 2/3를 마스터할 수 있도록 보장하여 네트워크 상태가 최종적으로 마무리될 수 있도록 합니다.
아임토큰의 노드 서비스도 이 이벤트를 감지했고, 이더리움 합의 레이어의 검증인(Validator) 투표 상황을 실시간으로 모니터링해 에포크(Epoch)가 정상적으로 마무리되지 못하기 전에 이더리움 합의 네트워크의 이상 징후를 조기에 경고할 수 있었다. 아래 그림은 첫 번째 이벤트가 발생했을 때의 노드 상태입니다.
PoW 메커니즘에서 트랜잭션의 성공 여부는 일정 수의 연속 블록 이후 트랜잭션이 롤백되지 않을 확률에 따라 결정됩니다. PoS에서는 세이프 헤드가 반환한 블록 높이를 사용하여 트랜잭션의 성공 여부를 결정합니다. 거래. 현재 사양에서는 Safe Head의 상태 판별로 Justified Checkpoint를 사용하므로 이전 Epoch의 상태로 볼 때 6.4분의 판별 지연이 있을 수 있으며 이는 사용자에게 매우 나쁜 경험입니다.
아임토큰이 자체 개발한 Safe Head 서비스는 실시간 이더리움 합의 계층 데이터를 기반으로 거래 확인을 위한 안전 블록을 계산하여 거래 확인 시간을 단축하는 동시에 사용자 거래 보안을 보장합니다. 일반적인 상황에서는 imToken의 Safe Head 알고리즘이 반환하는 블록 높이(위 그림의 노란색)가 최신 블록 높이(녹색)에 매우 가까워 사용자 경험이 향상됩니다.
세이프 헤드 메커니즘에 대한 추가 정보:
원인분석
위 사건의 직접적인 원인은 특정 이더리움 합의 계층 클라이언트 노드의 부하가 너무 높아서 검증기가 오프라인 상태가 되어 정상적인 합의 투표를 방해했기 때문입니다. 분석 후 이러한 노드에 부하가 높은 이유는 다음과 같습니다.
오래된 블록을 가리키는 증인( 증명 ) 을 수신하면 노드는 이러한 증인을 확인하기 위해 비콘 체인 상태를 다시 계산해야 하며 이 프로세스에는 많은 양의 CPU 및 메모리 리소스가 필요합니다.
오래된 블록을 가리키는 다수의 증인이 동시에 수신되면 노드의 CPU 및 메모리 리소스가 고갈되어 이러한 유효성 검사기가 충돌하고 오프라인 상태가 됩니다.
원래 이런 문제는 증인을 기반으로 블록을 캐싱함으로써 해결될 수 있었지만, Validator의 성장과 이러한 증명의 대량 출현으로 인해 문제가 있는 클라이언트가 구현한 캐시가 무너지고, 노드는 비콘체인 상태를 다시 계산하기 위해 많은 리소스를 소비해야 했습니다.
합의 계층 클라이언트 Teku와 Prysm은 현재 이 문제를 해결하기 위해 패치 버전을 출시했습니다. 특히 클라이언트 구현의 패치 버전은 이러한 오래된 감시를 필터링합니다. 즉, 다음 조건이 충족되면 감시를 무시합니다.
- 증인은 오래된 슬롯을 지적합니다.
- Witness는 노드가 이전에 본 적이 없는 체크포인트를 가리킵니다.
하지만 패치의 효과를 확인하기 위해서는 이더리움 메인넷이 마무리되는 과정을 계속 관찰해야 합니다.
합의 계층 클라이언트 Teku 및 Prysm 패치 버전:
- Prism: v4.0.3-핫픽스
- 테쿠: v23.5.0
이더리움 설계의 장점
이번 사건에서 이더리움은 가용성을 보장하고 계속해서 블록을 생성하고 트랜잭션을 처리하면서 Epoch만 지연시켰습니다. 최종화의 핵심은 두 가지에 있습니다.
- Ethereum 클라이언트의 다양성
- Gasper 알고리즘 설계
Ethereum 클라이언트의 다양성
이번 사건에서는 합의 레이어 클라이언트인 Teku와 Prysm의 구현에 문제가 있었지만 다른 합의 레이어 클라이언트의 정상적인 작동에는 영향을 미치지 않았습니다. 예를 들어 Lighthouse 클라이언트는 이번에 영향을 받지 않으며 클라이언트마다 구현 디자인이 다르기 때문에 Validator는 여전히 정상적으로 작동합니다.
Ethereum 클라이언트의 다양성은 일부 클라이언트에 문제가 발생하더라도(Epoch이 완료되지 못하더라도) 일반 클라이언트가 블록을 생성하고 트랜잭션을 처리하는 데 영향을 미치지 않으므로 Ethereum의 가용성이 유지됩니다.
Ethereum Gasper 합의 알고리즘의 사용성 설계
이더리움의 가용성을 보장하는 것은 이더리움 블록의 생산과 최종화를 분리하는 이더리움 합의 알고리즘 Gasper의 설계 출발점 중 하나입니다. 따라서 블록의 완결이 차단되더라도 블록 생성은 멈추지 않습니다. 대부분의 경우 블록 마무리가 결국 재개된다는 점을 고려하면(생성된 블록은 결국 여전히 마무리됨) 사용자에게 미치는 영향은 실제로 매우 낮습니다. 다른 BFT 합의 알고리즘과 비교: 블록이 확정되지 않으면 합의 노드는 다음 블록 생성을 중단합니다. 그 결과, 해당 기간 동안 블록체인 전체를 사용할 수 없게 되었는데, 이를 흔히 '블록체인 실패'라고 합니다.
또한, 두 번째 이벤트는 비활성 누출 메커니즘을 촉발시켰는데, 이는 주로 이더리움이 극단적인 상황(많은 수의 검증자가 오랫동안 오프라인 상태임)에서 블록을 다시 마무리할 수 있도록 보장하기 위한 것입니다.
경험과 깨달음
Ethereum 다중 클라이언트 문제
현재 이더리움 클라이언트 다양성의 현황은 아래 그림과 같습니다.
출처: https://clientdiversity.org/#distribution
Ethereum 클라이언트의 다양성은 여전히 계속 홍보되고 홍보되어야 함을 알 수 있습니다. Prysm과 Teku의 비율이 ⅓ 미만일 정도로 클라이언트 구현이 충분히 다양하다면 이 사건은 발생하지 않을 것이라고 생각할 수 있습니다(클라이언트의 ⅔ 정상적인 작동으로 Epoch를 마무리하기에 충분합니다). 또한 현재 실행 계층 클라이언트는 Geth에 집중되어 61%를 차지합니다. 이는 실제로 잠재적인 위험을 제시합니다. Geth가 부적절하게 작동하면 Ethereum이 큰 영향을 받게 됩니다.
이더리움 클라이언트 다양성을 위한 추가 노력의 필요성 외에도 이더리움 클라이언트 전환도 이 사건으로 인해 노출된 문제점입니다. 특정 클라이언트 구현에 문제가 있는 경우 유효성 검사기는 어떻게 일반 클라이언트 구현으로 전환합니까? 이 프로세스에는 다음이 포함됩니다.
- 문제가 있는 클라이언트의 인증키를 일반 클라이언트로 안전하게 마이그레이션
- 이더리움 합의에는 슬래시 규칙이 있으므로 기존 클라이언트와 새 클라이언트의 동작이 슬래시되지 않고 일관되도록 보장해야 합니다. 예를 들어:
- 이전 클라이언트와 새 클라이언트는 각각 포크 양쪽의 체크포인트에 투표하여 슬래시됩니다.
- 기존 클라이언트와 신규 클라이언트는 동일한 슬롯에서 서로 다른 블록을 생성하므로 슬래시됩니다.
이더리움 합의 모니터링
네트워크 상태가 비정상임을 알기 위해 Epoch가 완료될 수 없을 때까지 기다리기보다는 이더리움 PoS 네트워크의 실시간 상태를 지속적으로 모니터링하여 이러한 이벤트를 사전에 감지하고 경고하려면 Safe Head와 유사한 서비스가 필요합니다. 최신 관련 연구는 이 기사 에서 찾을 수 있습니다.
Ethereum 합의 알고리즘에 대한 대중 과학
이번 사건은 이더리움의 PoS 합의 메커니즘 대중화의 필요성을 드러냈습니다. 이번 사건으로 많은 이용자들이 '이더리움이 다운됐다'고 착각해 불필요한 패닉을 일으켰다. 그러나 실제로 이더리움 네트워크는 계속해서 블록을 생성하고 트랜잭션을 처리합니다. 이더리움 합의 레이어와 실행 레이어의 결합은 이더리움 거래 확인에 대해 이중 보장을 제공합니다.합의 레이어 Epoch가 완료되지 않을 때 실행 레이어의 블록 처리는 영향을 받지 않으며 Epoch 마무리의 비정상적인 상황도 이더리움에 있습니다. 합의 알고리즘에는 상응하는 처리 설계가 있습니다. 사용자 중심의 블록체인 지식 대중화는 여전히 실무자들이 계속 노력해야 할 방향이다.
Ethereum 애플리케이션에 대한 시사점
Ethereum 네트워크는 충분히 강력하지만 가끔 불안정하면 애플리케이션에 특정 영향을 미칠 수 있습니다. 동시에 애플리케이션은 이러한 불안정한 시나리오를 올바르게 처리해야 합니다.
- Layer1 -> Layer2의 증착 시간이 길어집니다. Layer2가 민트 상태일 때 중요한 전제 조건은 L1 예금 거래가 롤백되지 않도록 하는 것입니다. 따라서 이더리움 네트워크 Epoch가 확정되어 지연되면 L1->L2 입금 시간도 그에 따라 길어지게 됩니다.
- 마찬가지로, 거래소는 온체인 재충전 거래가 롤백되는 것을 방지해야 하므로 재충전 시간도 그에 따라 길어집니다.
- 오라클 온체인 견적이 롤백될 위험이 있으므로 이에 의존하는 고부가가치 서비스는 적절하게 중단되어야 합니다.
- 이번 사건에서 유니스왑은 잔액을 표시하지 않아 매수만 가능하고 매도는 불가능했고, dYdX는 예금을 중단했다.
요약하다
이번 사건에서 우리는 이더리움 PoS 합의 알고리즘의 회복력과 자가치유 능력을 확인할 수 있으며, 사고 발생 직후 클라이언트가 즉시 대응하고 오류를 수정한 모습도 볼 수 있다. 이더리움 생태계 전반에 걸쳐 클라이언트 다양성 증대, 네트워크 상태에 대한 실시간 모니터링 및 조기 경고 최적화, 심층적인 사용자 교육(일반 사용자뿐만 아니라 실무자 대상), 그리고 생태적 참여 네트워크에 이상이 있을 경우 비상계획을 준비합니다.
참고 링크
