개요
개요
첫 번째 레벨 제목
사건과 배경
일반적으로 이더리움 PoS 합의 네트워크 상태는 2 Epochs에서 확정(Finalized)되지만 지난 주에는 2 Epochs 완료가 지연되었습니다.
첫 번째그것은 5월 11일에 일어났고, 에포크의 마무리는 3 에포크, 약 20분 지연되었습니다.
두 번째그것은 5월 12일에 일어났고, 에포크의 마무리는 8 에포크, 약 51분 지연되었습니다.
이벤트 기간 동안 이더리움 네트워크는 계속해서 블록을 생성하고 트랜잭션을 처리했습니다. 그러나 Validator(검증 노드)의 투표율이 부족하여 Epoch를 확정할 수 없었습니다(즉, Epoch는 Ethereum PoS 네트워크의 합의 수준 보안 보장을 받았습니다). Epoch의 마무리 실패는 대부분의 유효성 검사기가 악을 행하고 포크하는 경우 epcoh가 롤백되어 트랜잭션이 롤백될 수 있음을 의미합니다.
사실 사건 당시 이더리움 네트워크에는 포크가 없었고, 검증인은 악의적으로 투표하지 않았으며, 다수의 검증인이 오프라인 상태였기 때문에 투표율이 미흡하여 해당 기간 동안 에포크가 확정되지 못했습니다. 이벤트.
관찰 결과, 오프라인 Validator의 CPU 과부하 이상 상황은 오프라인 Validator의 직접적인 원인으로 판단됩니다.
두 번째 이벤트에서는 에포크 종료가 8 에포크 지연되었습니다.MIN_EpochS_TO_INACTIVITY_PENALTY(= 4) 따라서 이더리움 합의 알고리즘을 트리거합니다.Inactivity leak처리 메커니즘.
약정 자금을 삭감하여 오프라인 유효성 검사기에 불이익을 주고,약 28 ETH 압수。
증명 보상 취소, 결과약 50 ETH가 발행되지 않았습니다.。
이 메커니즘은 온라인 유효성 검사기가 최종적으로 이더리움의 총 약정 자금의 ⅔를 보유할 수 있도록 하여 네트워크 상태가 최종적으로 확정될 수 있도록 합니다.
아임토큰의 노드 서비스도 이 사건을 감지했는데, 이더리움 합의 레이어의 검증인의 투표 상태를 실시간으로 모니터링함으로써 에포크가 정상적으로 완결되지 않기 전에 이더리움 합의 네트워크의 이상을 조기에 경고할 수 있다. 아래 그림은 첫 번째 이벤트가 발생했을 때 노드의 상태입니다.
PoW 메커니즘에서 트랜잭션의 성공 여부는 일정 수의 연속 블록 이후 트랜잭션이 롤백되지 않는지 여부를 결정하는 것이며 PoS는 성공 여부의 결정으로 Safe Head가 반환하는 블록 높이를 기반으로 합니다. 거래. 현재 사양에서는 Justified Checkpoint를 Safe Head의 상태로 사용하므로 이전 Epoch의 상태로 판단할 때 6.4분의 지연이 발생할 수 있으며 이는 사용자에게 매우 좋지 않은 경험입니다.
imToken이 개발한 Safe Head 서비스는 실시간 이더리움 합의 계층 데이터를 기반으로 거래 확인을 위한 안전한 블록을 계산하고 사용자 거래의 보안을 보장한다는 전제하에 거래 확인 시간을 단축합니다. 정상적인 상황에서 imToken의 안전 헤드 알고리즘(위 그림의 노란색)이 반환한 블록 높이(위 그림의 노란색)는 최신 블록 높이(녹색)에 매우 가까워 사용자 경험을 향상시킵니다.
안전 헤드 메커니즘에 대한 추가 정보:
원인 분석
위 사건의 직접적인 원인은 특정 이더리움 컨센서스 레이어 클라이언트 노드의 부하가 너무 높아서 Validator가 오프라인 상태가 되어 컨센서스 투표가 정상적으로 수행되지 않는 것입니다. 분석 후 이러한 노드의 부하가 높은 이유는 다음과 같습니다.
오래된 블록을 가리키는 증명을 수신할 때 노드는 이러한 증명을 확인하기 위해 비콘 체인의 상태를 다시 계산해야 하며 이 프로세스는 많은 CPU 및 메모리 리소스를 소비합니다.
이전 블록을 가리키는 많은 수의 증인이 동시에 수신되면 노드의 CPU 및 메모리 리소스가 고갈되어 이러한 유효성 검사기가 오프라인 상태가 됩니다.
원래 이런 문제는 해당 블록을 가리키는 Witness를 기반으로 캐싱을 하면 해결할 수 있지만, Validator의 규모가 커지고 이러한 증명이 많이 등장하면서 문제가 있는 클라이언트가 구현한 캐시가 망가지게 됩니다. 비콘 체인 상태를 계산합니다.
컨센서스 계층 클라이언트인 Teku와 Prysm은 이 문제를 해결하기 위해 패치 버전을 출시했습니다. 특히 패치 버전의 클라이언트 구현은 이러한 부실 감시를 필터링합니다. 즉, 다음 조건이 충족되면 감시를 무시합니다.
증인이 오래된 슬롯을 가리킴
증인은 노드가 본 적이 없는 체크포인트를 가리킵니다.
그러나 패치의 유효성을 확인하기 위해서는 이더리움 메인넷의 최종화를 계속해서 관찰해야 합니다.
첫 번째 레벨 제목
Prysm：v 4.0.3-hotfix
Teku：v2 3.5.0
이더리움 디자인의 장점
이 사건에서 이더리움은 가용성을 보장하고 계속해서 블록을 생성하고 트랜잭션을 처리하며 Epoch의 마무리만 지연시키는 핵심은 두 가지에 있습니다.
1. 이더리움 클라이언트의 다양성
보조 제목
이더리움 클라이언트의 다양성
이번 사건에서 합의 계층 클라이언트인 Teku와 Prysm의 구현에 문제가 있었지만 다른 합의 계층 클라이언트의 정상적인 작동에는 영향을 미치지 않았습니다. 이번에는 Lighthouse 클라이언트처럼영향을받지 않았다클라이언트마다 구현 설계가 다르기 때문에 Validator는 여전히 정상적으로 작동합니다.
보조 제목
사용성을 위한 이더리움 Gasper 합의 알고리즘 설계
이더리움의 가용성을 보장하는 것은 이더리움 블록의 생성과 완성을 분리하는 이더리움 합의 알고리즘 Gasper의 설계 출발점 중 하나입니다. 따라서 블록의 완성이 차단되더라도 블록의 생성은 종료되지 않습니다. 대부분의 경우 블록 완결이 결국 재개된다는 점을 고려하면(생성된 블록은 계속 완결됨) 실제로 사용자에게 미치는 영향은 매우 낮을 것입니다. 다른 BFT 합의 알고리즘과 비교: 블록 완료가 실패하면 합의 노드는 다음 블록 생성을 중지합니다. 그 결과, 일반적으로 블록체인 중단으로 알려진 기간 동안 전체 블록체인을 사용할 수 없습니다.
첫 번째 레벨 제목
보조 제목
이더리움 다중 클라이언트 과제
이미지 설명
원천:https://clientdiversity.org/#distribution
이더리움 클라이언트의 다양성은 여전히 홍보 및 홍보가 필요함을 알 수 있습니다. 클라이언트 구현이 충분히 다양하여 Prysm과 Teku가 ⅓ 미만을 차지했다면 이 이벤트는 발생하지 않을 것입니다(⅔ 클라이언트가 Epoch를 완료할 수 있을 만큼 제대로 작동함). 또한 현재 Execution Layer의 클라이언트는 Geth에 집중되어 있어 무려 61%를 차지한다. 이것은 실제로 잠재적 위험입니다. Geth가 제대로 작동하지 않으면 Ethereum이 크게 영향을 받습니다.
이더리움 클라이언트의 다양성에 대한 추가 노력의 필요성 외에도 이더리움 클라이언트 전환은 이 사건으로 인해 노출된 문제점이기도 합니다. 특정 클라이언트 구현이 실패할 때 Validator는 어떻게 일반 클라이언트 구현으로 전환합니까? 이 프로세스에는 다음이 포함됩니다.
문제 클라이언트의 Validation key를 정상 클라이언트로 안전하게 이전
이더리움 합의에는 슬래시 규칙이 있기 때문에 이전 클라이언트와 새 클라이언트의 동작이 슬래시되지 않고 일관성이 있는지 확인해야 합니다. 예를 들어:
이전 클라이언트와 새 클라이언트는 포크 양쪽의 체크포인트에 투표하여 슬래시되었습니다.
보조 제목
이더리움 합의 모니터링
Safe Head와 같은 서비스는 Ethereum PoS 네트워크의 실시간 상태를 지속적으로 모니터링하고 이러한 이벤트를 미리 감지하고 경고하기 위해 필요합니다. 예상대로 Epoch가 완료되지 않을 때까지 기다리지 않고 네트워크 상태가 비정상임을 알 수 있습니다. 관련 최신 연구는 다음에서 찾을 수 있습니다.보조 제목。
Ethereum 합의 알고리즘의 대중 과학
보조 제목
이더리움 애플리케이션에 대한 시사점
이더리움 네트워크는 충분히 견고하지만 가끔 불안정하면 애플리케이션에 일정한 영향을 미칩니다. 동시에 애플리케이션은 이러한 불안정한 시나리오를 올바르게 처리해야 합니다.
Layer 1 ->레이어 2 입금 시간이 더 길어집니다. 레이어 2가 생성되면 중요한 전제 조건은 L1 예금 트랜잭션이 롤백되지 않도록 하는 것입니다. 따라서 이더리움 네트워크 Epoch의 확정이 지연되면 그에 따라 L1->L2의 입금 시간이 길어집니다.
마찬가지로 거래소는 체인의 재충전 트랜잭션이 롤백되는 것을 방지해야 하므로 재충전 시간이 그에 따라 길어집니다.
오라클 체인에 대한 견적은 롤백될 위험이 있으므로 이에 의존하는 고부가가치 서비스는 적절하게 중단해야 합니다.
요약하다
요약하다
참조 링크
