중요 발표 | Reference 88 및 최근 Moonbeam 블록 생산 중단에 대한 근본 원인 분석

2023년 4월 5일, Moonbeam 네트워크는 승인된 국민투표 88의 예상치 못한 결과인 짧은 블록 생산 중단을 경험했습니다. 문제는 체인에 대한 국민 투표의 승인 결과가 런타임 업그레이드 전에 공개되지만, 이 국민 투표에 대한 호출 시퀀스는 런타임 업그레이드 후 블록에 배열되어 있다는 점에서 발생합니다. 이 문서에서는 사고에 대한 자세한 사후 분석을 제공하고 정전을 초래한 일련의 이벤트와 문제를 해결하고 재발을 방지하기 위해 취한 다음 단계를 설명합니다.

이벤트 요약

system.remark 호출과 관련된 국민투표 88이 블록 3276000 에서 커뮤니티 거버넌스에 의해 승인 되었으며 블록 3291300 에서 실행될 예정입니다 .

주민투표 88(블록 3290853) 구현 이전의 일부 블록이 런타임 2201 업그레이드에 성공적으로 적용되었습니다. 새로운 런타임 에는 Substrate의 저수준 변경 사항이 포함되어 있습니다 . 즉, system.remark의 호출 인덱스를 변경하여 system.setHeapPages의 호출 인덱스와 일치하도록 합니다.

이 변경으로 인해 계획된 system.remark 호출이 실수로 system.setHeapPages 호출로 전환되었습니다. 새 호출에 유효하지 않은 값이 있어 조합자가 블록을 생성하지 못하고 결국 네트워크가 중단됩니다.

네트워크가 종료되기 전 마지막 블록(예: 블록 3291299 )은 2023년 4월 5일 14:43:24 UTC에 생성되었습니다. 후속 블록(예: 블록 3291300)은 매개변수가 잘못 구성된 새 HEAP_PAGES에 대한 계획된 호출을 포함했기 때문에 생성할 수 없습니다.

Moonbeam 개발 기여자와 패리티는 즉시 조사에 착수하여 모든 노드에서 사용할 수 있는 새 클라이언트를 신속하게 릴리스했으며 거의 ​​4시간 동안 중단된 후 네트워크가 블록 생산을 재개했습니다.

근본 원인

Runtime 2201 에는 Substrate의 기본 변경 사항이 포함되어 있습니다 . system.remark의 호출 인덱스가 system.setHeapPages의 호출 인덱스와 일치하도록 변경되었습니다. 일반적으로 새 런타임 업그레이드를 기반으로 하는 호출에 다른 새 호출 인덱스를 할당할 수 있으므로 이는 문제가 되지 않습니다.

주민투표 88에는 Runtime2100에서 시작했어야 하는 system.remark 호출이 포함되어 있습니다. 이 런타임의 경우 호출 인덱스 1이 할당됩니다. 국민투표가 승인된 후, 네트워크는 실행을 위해 블록 3291300에 대한 국민투표 호출을 자동으로 발송할 계획입니다 . 그러나 이 블록은 Runtime2201 의 일부입니다 .

블록 3291300의 생성이 시작되었을 때 새로 매핑된 system.setHeapPages의 실행은 collator가 블록을 생성할 수 없도록 중요한 온체인 구성 값이 변경되었음을 의미했습니다. 결국 2023년 4월 5일 14:43:24 UTC에 네트워크는 블록 생산을 중단했습니다.

런타임 업그레이드는 여러 테스트 네트워크를 거치며 Moonbeam 메인넷 업그레이드 전에 전체 테스트를 통과합니다. 이 사건은 런타임 업그레이드 자체와는 아무런 관련이 없지만 다른 런타임 업그레이드에서 호출이 일치하지 않아 실행 관계가 변경되고 둘 사이의 호출 인덱스가 변경되어 이 문제가 발생했습니다.

해결책

Moonbeam 팀은 이 문제를 해결하기 위해 새로운 클라이언트 버전 0.30.3을 출시했습니다 . 최신 클라이언트는 체인에 저장된 잘못된 HEAP_PAGES 값을 무시할 수 있으므로 조합자가 블록을 계속 생성할 수 있습니다.

같은 날 18:55:48 UTC(문제 발생 후 약 4시간 12분 24초)에 블록 3291300이 생성되면서 네트워크는 블록 생성을 재개했습니다.

Collator가 새 클라이언트(v0.30.3)로 업데이트된 후 네트워크는 일정한 속도로 블록을 생성하기 시작했고 점차 정상으로 돌아왔습니다. 신속한 대응 업그레이드는 새로운 클라이언트 정보에 대한 커뮤니티 수집가의 관심과 불가분의 관계이며 네트워크 블록 생산이 정상으로 돌아가도록 돕는 열쇠이기도 합니다.

향후 계획

국민투표 88의 비준과 system.remark 호출에서 system.setHeapPages 호출로의 예기치 않은 전환으로 인한 Moonbeam 네트워크 중단의 여파는 커뮤니티에 중요한 교훈이었습니다.

Moonbeam 개발 기여자는 안전하고 신뢰할 수 있는 네트워크를 유지하려는 Moonbeam의 약속을 반영하여 새로운 클라이언트를 신속하게 릴리스하고 문제를 정확하게 해결합니다. Parity 팀의 일원인 Basti는 Moonbeam 네트워크 복원에 중요한 역할을 했습니다. 이 사고는 포괄적인 테스트, 런타임 업그레이드 자체 및 다양한 시나리오를 기반으로 하는 온체인 거버넌스 솔루션의 중요성을 강조합니다.

향후 런타임 릴리스에서 호출 인덱싱과 관련된 유사한 문제를 방지하기 위해 해결 방법이 구현 및 제출되었습니다 . 미래를 위해 런타임 업그레이드 중에 두 가지 핵심 사항을 해결해야 합니다.

  • 모든 기술 팀이 클라이언트 또는 런타임을 업데이트하기 최소 하루 전에 확인해야 하는 릴리스 조건 체크리스트

  • 새로운 클라이언트 및 런타임으로 향후 국민투표 유효성 검사를 포함하여 향상된 테스트 도구

앞으로 Moonbeam 팀과 커뮤니티는 네트워크의 탄력성을 강화하고 강력한 성능을 보장하기 위해 계속 협력할 것입니다.

이벤트 노드

  • 88번째 국민투표가 통과되었습니다. system.remark 외부 기능이 계획되었으며 블록 3291300 에서 실행될 준비가 되었습니다.

  • 런타임 2201이 블록 3290853 에 성공적으로 적용 되었습니다.

  • 새 런타임에는 system.setHeapPages 의 호출 인덱스와 일치하도록 system.remark 의 호출 인덱스를 변경하는 Substrate의 하위 수준 변경이 포함됩니다. 계획된 system.remark 호출이 자동으로 system.setHeapPages 호출로 전환되도록 합니다.

  • 새 호출(system.setHeapPages)에 유효하지 않은 값이 있어 조합자가 블록을 생성하지 못하고 결국 네트워크가 중단되었습니다.

  • 네트워크가 종료되기 전 마지막 블록(예: 블록 3291299 )은 2023년 4월 5일 14:43:24 UTC에 생성되었습니다. 후속 블록(예: 블록 3291300)은 새로 잘못 구성된 HEAP_PAGES 매개변수를 포함하도록 예약된 호출을 전송했기 때문에 생성할 수 없습니다.

  • Moonbeam은 이 문제를 해결하기 위해 새로운 클라이언트(v0.30.3)를 출시했습니다. 최신 클라이언트는 체인에 저장된 잘못된 HEAP_PAGES 값을 무시할 수 있으므로 조합자가 블록을 계속 생성할 수 있습니다.

  • 같은 날 18:55:48 UTC(문제 발생 후 약 4시간 12분 24초)에 블록 3291300이 생성되었습니다.

  • Collator가 새로운 클라이언트(v0.30.3)로 업데이트된 후 네트워크는 고정된 속도로 블록을 생성하기 시작했고 점차 정상으로 돌아왔습니다.

Supongo que te gusta

Origin blog.csdn.net/Moonbuilder/article/details/130191681
Recomendado
Clasificación