이더리움 2.0 메인넷 사고 검토

출처 | 프리즈매틱 연구소

보조 제목

https://beaconcha.in/epoch/32302

에포크 32302 이후 비콘 체인은 많은 수의 블록 제안을 잃었습니다. Prysm이 가장 많이 사용되는 Eth2 클라이언트이므로 Prysm에서 문제가 발생할 가능성이 가장 높습니다. 얼마 후 로컬에서 오류를 재현했습니다. 이것은 실제로 eth1 데이터 투표 및 유효성 검사기 예금과 관련된 알려진 문제입니다. 이 문제는 이전에 우리에게 보고되었지만 이 버그를 재현할 수 없었고 이를 고립된 사건으로 간주했습니다. 그리고 이 문제는 어떤 테스트넷이나 메인넷에서도 널리 전파된 적이 없습니다. 이 문제로 인해 블록 제안 실패가 발생한 것은 이번이 처음입니다.

이 18 에포크 동안 거의 모든 Prysm 비컨 노드는 새로운 블록을 생성할 수 없었습니다. Epoch 32320은 사건이 끝났다고 널리 알려진 시점에 다시 정상적으로 작동하기 시작했습니다. 그러나 약 24시간 후 비슷한 상황에서 사고가 다시 발생했다.

영향

검토는 사건의 타임라인을 자세히 설명하고 근본 원인을 분석하고 Eth2 스테이커와 참가자가 알아야 할 문제를 제시합니다.

일부 예비 데이터에 따르면 영향을 받은 각 유효성 검사기는 첫 번째 사건에서 평균 122,950gwei(작성 당시 $0.3)를 잃었습니다. 사고 발생 후 24시간 이내에 두 번째 동일한 사고가 발생하여 영향을 받는 각 검증자에게 약 $0.22의 비용이 발생했습니다.

몇 가지 주요 사실:

➤ 검증자가 삭감되지 않음

➤ 비콘 체인 종료에 영향을 미치지 않음

➤ 참여율은 여전히 ​​매우 높음(최저점 84.8%)(편집자 주, 이 데이터는 Ben Edgington이 작성한 최신호와 일치함Eth2 진행 업데이트불일치가 있습니다. )

➤ 대부분의 유효성 검사기는 클라이언트 유형에 관계없이 2~3개의 증명을 잃습니다.

➤ 이번에는 악의적이거나 고의적인 공격으로 보이지 않습니다.

보조 제목

이번 사고로 Eth2에 대한 모든 사람들의 신뢰가 약해질까요?

습관. 이 사건은 합의 실패를 일으키지 않았으며 사건의 규모는 Eth2 메인넷의 크기에 비해 매우 작았습니다(첫 번째 사건에서 영향을 받은 각 유효성 검사기는 평균 ~$0.3 손실). 창세기 이후로 Eth2는 매 에포크마다 매우 높은 검증자 참여 및 최종화로 매우 강력했습니다. 우리의 관점에서, 결함이 해결된 후 완벽하게 작동하는 상태로 돌아가는 네트워크의 능력은 차례로 이더리움의 탄력성에 대한 커뮤니티의 신뢰를 강화했습니다.

이 사건에 대한 우리의 대응과 해결은 Eth2 테스트넷의 실패를 처리하려는 이전의 노력과 완전히 달랐습니다. 사건 직후 우리 팀은 잘못된 정보를 배제하고 영향을 정량화했으며 해결을 기다리는 동안 검증자를 위한 명확한 단계를 마련했습니다. 또한 솔루션을 완전히 결정한 후에는 모두에게 클라이언트 버전 업그레이드를 요청할 것입니다. Prysm 클라이언트는 Ethereum 2.0 네트워크에서 사용자가 가장 많은 소프트웨어이기 때문에 나타나는 버그는 더 심각한 문제를 일으킬 수 있습니다.

보조 제목

Eth2와 Eth1 체인은 느슨하게 연결되어 있으며 Eth2는 유효성 검사기 입금 확인을 위해 Eth1만 필요합니다. 즉, 유효성 검사기가 가비지 데이터에 투표하더라도 Eth2 PoS 체인은 계속 작동할 수 있습니다. 중요한 것은 PoS 체인이 올바른 Eth1 데이터에 다시 투표할 때까지 새로운 유효성 검사기 예치금을 추가할 수 없다는 것입니다. 이 "투표"는 현재 메인넷에서 64 에포크(약 6.8시간)로 설정된 "투표 기간" 동안 이루어집니다.

투표 방법은 Eth2 유효성 검사기 사양에 설명된 간단한 "초다수" 원칙입니다. 불행하게도 Prysm은 이 원칙을 시행할 때 일부 검증을 잃습니다(대다수 투표). 이 사건에서 Prysm의 버그로 인해 블록 제안자는 완전히 유효하지 않은 Eth1 예금 트리 루트를 생성했고 다른 Prysm 노드는 블록 제안을 처음 발견했습니다. 그런 다음 그들은 Prysm 클라이언트가 명시적인 유효성 검사 없이 단순한 "대다수 투표"를 따르기 때문에 이에 대해 유효하게 투표했습니다.

그런 다음 모든 Prysm 노드는 유효하지 않은 정보에 대해 "눈덩이" 투표를 하여 블록 제안자가 예치금이 있는 블록을 체인에 포함할 수 없게 됩니다. 이는 이러한 예치금이 노드의 Eth1 예치금 트리 루트에 대해 확인되지 않았기 때문에 블록 제안이 실패할 것입니다. 투표 기간이 지나면 문제는 자동으로 해결되지만 버그가 수정되지 않으면 문제가 다시 발생합니다.

보조 제목

참고, 기술 세부 사항은 아래에 있습니다! 다음 섹션으로 건너뛰어 솔루션과 인시던트에서 얻은 교훈에 대해 읽을 수 있습니다.

Epoch 32302는 손실된 블록 제안에 문제가 발생하기 시작했습니다.

Nishant는 팀에 이를 알리고 전원 회의를 소집했습니다. 그런 다음 로컬 메인넷 비콘 노드를 통해 사건을 재현하고 조사를 시작했습니다.

텍스트

초기 의심은 Prysm이 유효성 검사기 제안 코드 경로에서 eth1 데이터 투표를 처리하는 방법에 대한 것이었습니다. 특히 다음과 같은 몇 가지 문제를 배제하려고 합니다.

1. 예치금을 블록에 패킹하는데 문제가 없나요?

2. 획득한 입금 로그 정보와 eth1 정보가 섞여있거나 확실하지 않은가요?

3. 예금 Merkle tree에 문제가 있습니까?

다음 16시간 정도 동안 우리는 근본적인 문제를 진단하기 위해 함께 작업하는 데 많은 시간을 보냈습니다. 코드 줄을 샅샅이 뒤지고 단위 테스트를 통해 실패 프로세스를 재현하려고 시도했으며 다양한 방법을 시도했습니다. 우리는 이미 잠재적인 솔루션을 가지고 있었지만 확신이 없었기 때문에 수정 사항을 발표하는 것에 대해 긴장했습니다.

우리는 근본 원인에 대한 확신을 갖는 것만으로는 충분하지 않다는 Eth2 테스트넷의 버그를 다루는 이전 경험에서 몇 가지 교훈을 배웠습니다. 고부담 상황에서는 솔루션을 사용자에게 공개하기 전에 솔루션을 100% 확신해야 합니다. 사고 28시간 후, 우리는 앉아서 스스로에게 "우리가 모르는 다른 것은 무엇입니까? 고장의 근본 원인에 더 가까이 다가가기 위해 어떤 질문을 할 수 있습니까?" 그리고 다음과 같은 사실을 알게 되었습니다.

1. 우리의 스파스 머클 트리 구현은 Lighthouse 및 Protolambda의 Eth2 zrnt 구현과 일치하는 메인넷 및 Prater 테스트넷 예금을 사용하기 때문에 심각하게 버그가 없습니다.

2. Eth1 노드에서 Eth1 데이터를 검색하는 데 사용하는 코드 경로는 버그가 있거나 잘못된 데이터를 반환하지 않습니다.

우리가 모르는 것은 다음과 같습니다.

1. 유효하지 않은 예금 나무 뿌리가 생성되는 방식

2. 이 문제가 일부 노드에서는 재현되지만 다른 노드에서는 재현되지 않는 이유

3. Prysm 노드가 블록에 입금액을 결정할 때 "off-by-one" 오류가 발생한 이유

이러한 질문에 답하기 위해 예금 트리를 초기화하는 코드 경로를 살펴보았습니다. 스테이커가 노드를 부팅할 때마다 모든 유효성 검사기 예치 기록을 다운로드할 필요가 없도록 캐싱 레이어가 초기에 추가된 것으로 나타났습니다. 또한 클라이언트 내부에 내장된 기원 상태에서 Prysm을 시작하는 기능인 새로운 기능을 추가했습니다. 보증금 트리의 잘못된 기본값으로 인해 캐시를 채울 때 정보가 손상되었습니다.

문제의 근원

예금 트리가 비어 있으면 len(items) 함수가 항상 1을 반환한다는 것이 밝혀졌습니다. 즉, lastReceivedMerkleIndex의 값을 실제로는 -1로 설정했어야 하는데 0으로 설정했습니다. 위의 코드는 코드 경로의 일부 Prysm 노드가 보증금 0을 트리에 포함하지 않도록 합니다. 코드베이스의 나머지 부분은 모두 이 코드 경로가 아니라 예금 트리 구현의 이 이상한 부분을 문제로 지적했습니다.

보조 제목

➤ Prysm은 디스크에 eth1 데이터를 유지하여 사용자가 프로세스가 다시 시작될 때마다 유효성 검사기 예치 계약 로그에 요청하지 않아도 되도록 합니다.

➤ 노드가 재부팅되고 디스크에 eth1 데이터가 지속되는 경우 이 데이터에서 보증금 캐시를 초기화하지만 당사의 SMT(sparse merkle tree) 헬퍼 방식으로 인해 이 캐시를 초기화하는 코드 경로가 위의 데이터와 다릅니다. 예치금 트리에 0번째 예치금을 삽입하는 것을 건너뛰어 유효하지 않은 예치금 트리 루트가 됩니다. 이 코드 경로는 초기부터 아직 데이터베이스가 없었고 나중에 수정된 노드에만 영향을 미쳤습니다.

➤ 공식 사양에서 Prysm 노드는 eth1 데이터 투표 알고리즘을 구현하기 위해 "절대 다수"의 원칙을 따르지만 Prysm은 알고리즘의 일부 유효한 조건을 완전히 구현하지 않습니다. Prysm 노드는 기존 블록 루트를 참조하는 절대다수 eth1 데이터 투표로 투표합니다. 이로 인해 Prysm 노드는 이러한 예치금이 확인되지 않았기 때문에 문제가 있는 예치금 트리에서 생성된 예치금 트리 해시에 투표할 수 있습니다.

➤ 네트워크의 대부분의 노드가 Prysm 노드이기 때문에 Prysm 노드가 이후 일정 기간 동안 메인넷에서 블록을 생성할 수 없었기 때문에 압도적 다수 규칙으로 결함이 있는 예금 스텁에 투표하는 눈덩이 효과가 심각한 문제로 발전했습니다.

해결책

4월 25일 일요일 베이징 시간 13:00에 여러 시간 동안의 불확실성 끝에 이 문제에 대한 수정 사항을 발표했습니다. 우리는 이 솔루션을 절대적으로 확신하며 이 문제가 노드 업그레이드 후 Eth2에서 재발하지 않을 것이라고 확신합니다.

우리는 Eth2 Medalla 테스트넷 사고를 겪었을 때 좋은 커뮤니케이션의 가치에 대한 중요한 교훈을 배웠습니다. 모든 대중의 의견과 언어의 정확한 표현은 사건의 결과에 심각한 영향을 미칠 수 있습니다. 테스트넷의 경우 즉각적인 해결책은 공개 채널을 통해 모든 사람에게 "노드를 다시 시작하라"고 알리는 것이라고 생각했습니다. 이 성급한 결정으로 인해 네트워크의 대부분의 노드가 오프라인 상태가 된 다음 블록체인과 동기화하기 위해 많은 나쁜 피어 중에서 좋은 피어를 찾기 위해 출격합니다. 또한 문제를 해결할 것이라고 100% 확신할 수 없었던 소프트웨어 업그레이드 핫패치를 신속하게 출시했습니다. 이로 인해 시스템에 더 많은 혼란이 발생하고 솔루션에 대한 노드 운영자 사이에 의심이 생깁니다.

이에 반해 메인넷 신규 사고의 전 과정에 걸쳐 항상 세심하고 정확한 소통에 주의를 기울였습니다. 또한 문제의 원인과 해결 방법에 대해 100% 확신할 때까지 핫픽스를 릴리스하지 않습니다.

➤ 인내와 침착함이 문제 해결에 도움이 될 수 있습니다.

우리 팀은 지난 몇 년 동안 Eth2를 구축했으며 역경에 직면했을 때 침착함을 유지하는 방법을 배웠습니다. 우리는 침착함을 유지하고 상태 보고서를 자주 전달하며 문제 해결 과정에서 팀이 지원을 받고 긍정적인 피드백이 중요하다고 느끼는 것이 중요하다고 생각합니다. 시간을 들여 가능한 한 많은 증거를 수집하고 사용자와 꼼꼼하게 작업할 수 있었고 이 문제를 성공적으로 해결할 것입니다. 더 중요한 것은 스테이커와 정보 불안을 줄이기 위해 처음부터 이벤트 영향을 정량화하는 데 시간을 들였습니다. 이 수업은 높은 스트레스와 수면 부족 상황에서 작업하는 데 매우 중요합니다. 속도를 늦추고 적절한 수단으로 문제를 해결하고 어떤 대가를 치르더라도 문제를 악화시키지 마십시오.

➤ Eth2 테스트 네트워크가 메인 네트워크와 같지 않음

Prysm 클라이언트의 경우 공개 Eth2 테스트넷에서 Prysm 사전 프로덕션 릴리스 후보를 광범위하게 테스트하고 들었습니다. Prater 및 Pyrmont 테스트넷은 모두 사용자가 Eth2 메인넷에 참여하기 전에 설정을 테스트할 수 있는 훌륭한 도구입니다. 그러나 이러한 테스트넷은 4개의 프로덕션 등급 Eth2 클라이언트의 비율이 평균 점수에 가깝다고 가정합니다. 불행히도 이것은 대부분의 사람들이 특정 클라이언트를 사용할 때만 발생하는 취약점을 고려하지 않은 것일 수 있습니다. 앞으로 Prysmatic Labs는 메인넷 환경에 더 가까운 환경 또는 Prysm 네트워크 노드의 50%가 있는 환경에서 내부 테스트넷에서 테스트할 것입니다.

보조 제목

https://launchpad.ethereum.org

사람들은 처음부터 우리 팀이 Ethereum 스테이킹 경험을 더 쉽게 만드는 데 집중했기 때문에 Prysm을 실행하기로 선택합니다. 사용자들과 여러 번 이야기를 나눴는데 많은 사람들이 하나의 클라이언트를 선택하는 이유는 미시적 최적화나 다른 클라이언트에 비해 상대적으로 작은 수율 차이 때문이 아니라 경험을 더 간단하게 만들기 때문입니다. 좋은 문서 정보는 모든 커뮤니티 구성원. 초보자에게 Eth2는 무섭고 스테이킹은 불확실성과 위험으로 가득 차 있습니다. 우리 팀의 임무는 사용자에게 문제가 아무리 작더라도 우리가 그들을 위해 있고 우리의 지원을 받는다는 것을 사용자에게 알리는 것입니다. 특히 명령줄이나 UNIX 운영 체제에 익숙하지 않은 일반 스테이커를 주시하고 있습니다.

앞으로 우리 팀에서 다음을 기대할 수 있습니다.

➤ 코드를 작성하기 전에 미리 설정된 유효한 조건을 완전히 검토하고 도전하도록 보장하여 사양 조건 구현의 정확성을 개선합니다.

➤ 우리는 이 경험을 개선하기 위해 더 많은 노력을 기울일 것입니다. Prysm을 현재보다 몇 배나 더 좋게 만들고 클라이언트를 사용하는 스테이커가 웹 인터페이스 개선을 포함하여 네트워크에 더 쉽게 참여할 수 있도록 합니다.

➤ Prysm은 R&D에 두 배로 투자할 것입니다.<>eth2의 사전 병합은 주요 기능과 개선 사항을 제공합니다.

➤ 모든 클라이언트 팀이 지속적으로 소프트웨어를 개선함에 따라 건전한 경쟁이 ETH의 지분 증명을 더 많이 참여시키고 더 안전하게 만드는 강력한 인센티브를 생성한다고 믿습니다.

➤ 우리 팀은 스테이커가 직면할 수 있는 문제를 최고의 전문 표준으로 해결하기 위해 최선을 다하고 있습니다. 우리는 우리에게 오는 모든 문제를 처리할 준비가 되어 있으며 스테이커 경험을 최우선 순위로 삼을 커뮤니티를 보장합니다.

➤ 마지막으로 우리는 Prysm을 Eth2에 참여하기 위한 더 매력적인 소프트웨어로 만들 수 있는 많은 중요한 기능이 있다고 믿으며 이 목표를 향해 계속 반복할 것입니다.

보조 제목

Eth2가 시작된 이래 우리가 들어왔던 공통된 주제는 클라이언트 다양성입니다. Eth2는 전 세계 사람들이 검증자로 참여하는 분산 시스템입니다. 서로 다른 사람들이 서로 다른 소프트웨어를 사용하여 블록체인 합의에 참여하는데 특정 소프트웨어에 심각한 문제가 있는 경우 네트워크를 실행하는 클라이언트가 균형 있게 분산되면 영향이 더 적습니다.

Leonardo Bautista-Gomez는 빠르면 1월에 데이터 분석을 발표했으며 그 결과 Prysm 노드가 네트워크의 65%를 차지하는 것으로 나타났습니다.

https://github.com/leobago/BSC-ETH2/tree/master/armiarma

소프트웨어, 커뮤니티, 탄력성 등 각 클라이언트를 객관적으로 살펴보고 요구 사항에 가장 적합한 소프트웨어와 팀을 결정하는 것이 좋습니다. Eth2 클라이언트에 중요한 사항이 없거나 클라이언트를 선택하지 않은 이유가 있는 경우 기능 요청을 제출할 것을 강력히 권장합니다. Prysmatic Labs는 계속해서 여러분이 이더리움 네트워크에 참여할 수 있도록 돕고 블록체인 소프트웨어의 경계를 넓히는 데 집중하고 있습니다.

인용하다

• 인시던트 커뮤니케이션 https://www.reddit.com/r/ethstaker/comments/mxpz57/regarding_the_recent_beacon_chain_incident/

• 사후 보고서 https://docs.google.com/document/d/1nJr6_bd-UnLBxvhT8lcRYdAZr69QdVQ3zJNUr3LgW-0/edit?usp=sharing

• 메달라 테스트넷 사건 https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a

https://medium.com/prysmatic-labs/tagged/blockchain)

원본 링크: https://medium.com/prysmatic-labs/eth2-mainnet-incident-retrospective-f0338814340c