메달라 테스트넷의 "크래시" 이벤트의 전체 스토리를 이해하기 위한 기사
저자 | 벤 에징턴
소스 |저자 | 벤 에징턴
번역가의 메모: Prysm 클라이언트를 실행하는 사용자는 다음으로 업그레이드해야 합니다.
이번 이슈는 wnie2 계획 외 업데이트로, 주말 동안 Eth2 Medalla 테스트 네트워크에서 발생한 에피소드를 검토하고 분석하겠습니다.이전 기간。
우리는 거의 2주 전인 8월 4일에 Eth2 메인넷 사양을 실행하는 대규모 공개 다중 클라이언트 테스트넷으로 Medalla를 출시했습니다. Medalla 테스트넷에 대한 소개는 다음을 참조하십시오.
이전 기간
그러나 금요일 저녁에 검증인 참여율이 대시보드에서 절벽 아래로 떨어지는 것을 보았습니다. 몇 분 안에 활성 검증자는 22,000에서 약 5,000으로 떨어졌고 네트워크의 검증자 중 약 80%가 사라졌습니다.
따라서 이 기사에서는 그 여파 및 다음 단계를 포함하여 사건을 검토합니다.
첫 번째 레벨 제목
무슨 일이에요?우리는 네트워크에서 Prysm 클라이언트를 실행하는 모든 유효성 검사기가 갑자기 사라진 것을 발견했습니다. Prysm이 가장 많이 사용되는 클라이언트이므로 그 결과를 상상할 수 있습니다.Prysmatic 팀은
문서 보고서Roughtime, 인시던트 세부 정보 및 팀 대응이 지속적으로 업데이트됩니다. 다음은 내 메모와 함께 몇 가지 하이라이트입니다.
이벤트의 원인은 시계 동기화 문제입니다. Prysm 클라이언트는 Cloudflare의
시간을 계산합니다. 그 이유는 (제 생각에는) 그다지 명확하지 않지만 Roughtime이 시간을 미래로 4시간 이동시켰고 1시간 이상 지속된 것은 분명합니다. Prysm 클라이언트 유효성 검사기는 갑자기 시간이 4시간 더 빨라진 것을 발견하고 아직 존재하지 않는 블록체인에 대한 블록 및 증명을 계속 생성했습니다.
그 자체로는 재앙이 되기에 충분하지 않습니다. 많은 블록이 손실되고 미래의 많은 양의 증명에 직면하더라도 나머지 클라이언트는 여전히 원래 체인을 구축할 수 있습니다. 점차적으로 Prysm 노드의 시계가 다시 조정되면서 네트워크로 다시 돌아오기 시작했고 유효성 검사기 참여가 시작되었습니다. 네트워크가 정상으로 돌아가는 것 같습니다.
그러나 몇 시간 후 상황은 급격하게 악화되었습니다.
최초 시간으로부터 4시간 후에 두 가지 일이 더 발생했습니다. 첫째, 미래의 모든 Prysm 클라이언트가 생성한 증명은 유효성을 갖기 시작합니다. 둘째, 네트워크에 다시 합류하는 Prysm 노드는 모순되는 증명을 생성하지 못하도록 슬래시 보호 메커니즘이 트리거되었기 때문에 다시 사라지기 시작했습니다.
이 두 가지 일이 동시에 발생하여 네트워크를 혼란에 빠뜨렸습니다. 나머지 클라이언트는 받은 정보를 처리하는 데 여전히 어려움을 겪고 있었고 비콘 체인은 분기 정글이 되었습니다. (Prysmatic 팀의 Raul은 Prysm의 첫 번째 수정 사항에 있는 버그가 상황을 악화시켰다고 말했습니다.)
일정 기간 동안 네트워크의 정보는 여전히 통제됩니다. 그러나 다음 24시간 동안 점점 더 복잡해지고 혼란스러워지는 포크를 탐색하는 데 필요한 메모리와 CPU가 압도적이었습니다. 30GB의 메모리(일반적으로 메모리의 약 100배)를 사용하는 Lighthouse 클라이언트를 보았고 Teku 클라이언트의 경우 12GB Java 메모리 힙과 프로세서를 최대로 사용하더라도 문제가 있었습니다. Eth2Stats이 모든 작업은 주말에 이루어집니다. 최전선에서 싸우고 있는 모든 고객 팀 덕분에 노드가 혼란스러운 네트워크에 대처하기 위해서는 메모리와 효율성을 지속적으로 최적화해야 합니다.
지금까지 네트워크는 점차 회복되고 있습니다. 사용자 보고서가 혼합되어 있지만 최신 버전의 Prysm 및 Lighthouse는 올바른 체인 헤더를 찾고 계속해서 비콘 체인을 구축할 수 있었습니다.
현재 체인 헤드 또는 인근 Lighthouse, Prysm 및 Teku 노드를 표시하는 일부 노드. 동기화에 필요한 리소스를 줄이기 위해 Teku를 계속 최적화할 것입니다.
합의 실패가 발생하지 않았습니다.
한 가지 분명한 것은 클라이언트 간에 합의 실패가 없다는 것입니다. 즉, 네트워크가 복원되면 모든 클라이언트가 체인 헤드 상태에 대한 합의에 도달할 수 있으므로 비콘 체인이 근본적으로 실패하지 않습니다. , 실패하지 않습니다. 하드 포크가 필요합니다.
수업 경험
우리는 이 에피소드를 충분히 반영하고 요약하기 위해 더 많은 시간을 할애할 것입니다. 다음은 제 개인적인 의견입니다.시간 동기화의 중요성。
타사 시간 서비스에 대한 높은 의존도는 네트워크의 치명적인 지점입니다. 공교롭게도 ConsenSys TX/RX 연구팀의 Alex Vlasov는 이전에 Ethereum 2.0 네트워크에서 시간 동기화와 그 중요성을 설명하는 자세한 기사를 작성했습니다. 그의 작업은 빠르게 진행되고 있으며 아마도 이것은 모두가 이러한 측면에 주목하는 기회이기도 합니다. 여기 그의
관련 기사 및 ethresear.ch 게시물
클라이언트 다양성의 중요성
이상적으로는 각 클라이언트 노드가 네트워크의 30% 이하를 차지하는 4개 이상의 독립 클라이언트가 있어야 합니다. 그렇게 하면 한 고객에게 문제가 있더라도 우리의 관심을 끌기에 충분한 영향을 미치지 않을 것입니다.
이 이상을 달성할 수 없더라도 개별 클라이언트의 극단적인 사용을 줄이면 네트워크가 더욱 견고해집니다. 검증자 중 80%가 아닌 이번에는 50%만 오프라인 상태가 된다고 가정하면 네트워크가 더 쉽게 복구됩니다. 이는 클라이언트에 문제가 있을 경우 네트워크의 블록 생성, 증명 패키징, 브로드캐스트 효율성, 점대점 통신 및 동기화에 영향을 미치고 이러한 요소가 나머지에도 영향을 미치기 때문입니다. 유효성 검사기.
백업 계획의 효율성일부 스테이커는 서명 키를 다른 클라이언트의 핫 백업 노드로 전환할 수 있습니다. 삭감(slashing)을 피하기 위해 주의가 필요하지만 이것은 확실히 훌륭한 보안 네트워크를 만듭니다.앞으로 우리가 한 번
새로운 API
, 키뿐만 아니라 다른 비콘 노드 간에 유효성 검사기 클라이언트를 전환하는 기능을 활성화해야 합니다. 예를 들어 Prysm 유효성 검사기는 Prysm 비콘 노드에서 쉽게 분리하고 Teku 비콘 노드에 다시 연결할 수 있습니다. 이것은 위에서 언급한 슬래싱 문제를 해결할 수 있습니다.
이해관계자의 책임의식
현재 Eth2에 참여하는 것은 "한 번만 하면 끝나는" 것이 아닙니다. 스테이커는 일정 수준의 관심을 유지하고 포럼 사이를 돌아다니며 개발자에게 피드백을 제공하고 짧은 시간에 클라이언트를 업데이트할 수 있어야 합니다. 저는 자신의 개인 유효성 검사기를 실행하는 사람들을 매우 지지하지만 그들이 자신의 책임을 알고 있는 경우에만 가능합니다.
급할수록 돌아 가라금요일 저녁에는 왜 항상 일이 잘못됩니까?이때에도 Prysmatic 팀의 반응은 놀라웠습니다. 자세한 내용은 팀의
사고 보고서
. 내가 아래에서 말하는 것은 정말 잘한 Prysmatic 팀에 부정적인 빛을 비추는 것이 아니라 비슷한 상황에 직면했을 때 Teku 팀에 경험을 제공하기 위한 것입니다.
너무 많은 사용자가 자산을 잃고(단지 테스트 코인일지라도) 네트워크가 높은 압력을 받고 있을 때 신속하게 대응하고 싶은 것은 당연하지만 서두름은 때때로 역효과를 낳을 수 있습니다.
이 사건에서 피할 수 있었던 것은 두 가지였다. 첫째, 초기 수정 릴리스 Alpha.21에는 사용자가 17시간 후에 롤백해야 하는 버그가 있었습니다.
Prysmatic 팀의 Raul에 따르면 이 결함이 뒤이은 네트워크 혼돈의 원인이었습니다. 둘째, 팀은 상황을 처리하는 동안 1024명의 유효성 검사기의 슬래시 방지 레코드 데이터베이스를 실수로 삭제하여 대부분의 유효성 검사기가 삭감되었습니다.
비슷한 상황이 모든 고객에게 발생할 수 있습니다. 따라서 높은 압박 속에서도 개발자든 사용자든 우리 모두는 냉정하게 대처해야 하며 맹목적으로 속도를 추구해서는 안 됩니다. 그래서 우리는 네트워크를 복원하려고 할 때 느리고 신중한 접근 방식을 따랐습니다.
미래의 문제를 피하기 위해 문제 노출
결국 이 에피소드는 정말 필요했다. 아무것도 테스트하지 않는다면 테스트넷의 요점은 무엇입니까? 항상 원활하게 실행하는 것은 분명히 비현실적입니다.이번에는 훌륭한 테스트입니다! 이것은 아마도 네트워크가 겪을 수 있는 최악의 유형의 충격일 것이며, 우리가 직접 설계한다면 그러한 테스트를 설계할 수 없을 것입니다. 테스트넷을 이러한 수준의 영향에 노출시키는 것이 바로 클라이언트를 강화하는 데 필요한 것입니다.지난주
기사의 블록
내 진술 인용:
이메일에서 PegaSys 엔지니어 Ben Edgington은 Medalla가 "메인넷의 규모와 구성을 갖춘 최초의 테스트넷"이라고 썼습니다.솔직히 말하자면,。
무엇 향후 계획?
너는 무엇을 기대하니?
무엇 향후 계획?
홈페이지: ethereum.cn
이더리움에 대한 자세한 내용은 다음을 참조하십시오.
공개 계정: ETH 중국 웹사이트
홈페이지: ethereum.cn
고지 사항: ECN의 번역 작업은 중국 이더리움 커뮤니티에 고품질 정보 및 학습 리소스를 제공하는 것을 목표로 합니다.기사의 저작권은 원저자에게 있습니다.재인쇄는 원문의 출처와 ethereum.cn을 표시해야 합니다.장기적으로 재인쇄, 연락주세요ethereumcn@gmail.com승인합니다.
