원작자: parithosh

원본 출처: notes.ethereum.org

요약

요약

요약하다

요약하다

병합된 테스트넷 Kintsugi는 운영 첫 몇 주 동안 일련의 문제에 직면하여 여러 클라이언트에서 여러 취약점을 노출했습니다. 문제는 주로 흥미로운 블록을 생성하고 네트워크에서 블록을 브로드캐스트하는 것을 목표로 하는 개발자 Marius가 개발한 fuzzer에 의해 발생합니다.

이와 같은 블록blockHash(블록 해시)는parentHash(상위 블록 해시).engine_executePayload모든 빌딩 블록과 빌딩 블록이 있습니다blockHash모든 매개변수가 필요합니다. EL(실행 계층) 클라이언트는 이러한 매개변수를 기반으로 블록을 구축해야 하며blockHash인증. 이 특정 블록은 Geth의 검사를 제대로 통과하지 못했지만 Nethermind와 Besu의 검사는 통과했습니다. 캐싱 문제로 인해 블록이 Nethermind에서 잘못 검증되었지만 Besu는 그러한 검사가 전혀 없습니다. 결과적으로 이 블록은 Lighthouse-Besu 노드에 의해 제안되었고 블록체인이 두 개로 분기되어 하나의 포크에서는 실행 수준에서 Nethermind 또는 Besu에 연결된 유효성 검사기와 다른 포크에서는 Geth에 연결된 유효성 검사기가 사용되었습니다. .

현재 블록의blockHash병합에 대한 새로운 요구 사항이므로 일부 클라이언트에서 유효성 검사가 누락되거나 정확하지 않을 수 있습니다.

Geth의 문제는 잘못된 페이로드를 실행할 때 대신 JSON-RPC 오류를 반환한다는 것입니다.INVALID(작동하지 않음) Teku의 문제(고정되었지만 현재 배포되지 않음)는 이러한 버그가 낙관적 동기화 모드에서 통과할 수 있다는 것입니다. 따라서 Teku-Geth 노드는 유효하지 않은 로드가 발생할 때 여전히 낙관적 동기화 모드로 들어갑니다. 블록 자체가 유효하기 때문에 연결된 Geth 노드는 engineAPI가 아닌 네트워크에서 데이터를 가져오므로 Teku-Geth 노드는 이제 유효하지 않은 포크에 있습니다. Teku 노드는 여전히 많은 버그가 있는 이전 버전에 있기 때문에 Teku-Geth 노드는 낙관적 동기화 모드를 유지하고 블록체인이 완료되지 않는 기간 동안 블록 제안을 거부합니다. 우리는 현재 합의 계층 클라이언트(lighthouse, prysm, nimbus 및 lodestar) - Geth(약 46%)와 합의 계층 클라이언트 - Nethermind/Besu(약 19%)가 서로 다른 포크에 있고 나머지 검증자는 실행 중인 상황에 있습니다. Teku-Geth(약 35%)는 낙관적 동기화 모드에 있습니다.

Nethermind 및 Besu 노드에 대한 수정 사항을 찾아 배포한 후 올바른 체인에 다시 가져올 수 있었습니다. Teku-Geth 노드에 대한 업데이트로 블록 순서 유효성 검사와 관련된 Geth의 문제로 인해 잘못된 메모리 액세스와 관련된 또 다른 문제가 발생했습니다. 이 특정 취약점은 또한 Marius의 fuzzer에 의해 촉발되었습니다.parentRoot유효하고block_number=1차단하다. Geth는 블록을 실행하기 전에 상위 블록을 확인하여 동기화가 필요한지 확인해야 합니다. 이를 수행하는 한 가지 방법은 캐시를 체크인하는 것입니다.parentHash그리고parentHash그리고blockNumber. Teku는 모든 포크의 모든 로드를 동시에 실행하므로 캐시에 더 이상parentHash. 따라서 Geth는 parentHash를 전달하려고 시도하고blockNumber부모 블록을 찾습니다. 그러나 데이터베이스에는 이 blockNumber의 해시가 없습니다(이 블록은 fuzzer에 의해 구성됨). Geth는 부모 블록이 없기 때문에 동기화가 켜져 있어야 한다고 추론합니다. 그러나 이렇게 트리거된 동기화는 권한 있는 체인보다 짧은 체인을 동기화하려고 시도하므로 Geth 프로세스 오류, 노드 종료 및 Teku-Geth 노드가 항상 비정상 상태에 있는 Geth의 특정 조건을 위반합니다.

위 문제를 디버깅하는 동안 Geth 팀은 병합된 코드 베이스에서 오류를 발생시킨 경쟁 조건도 발견했습니다. 또한 다른 문제도 있었습니다. Nimbus에는 실행 계층 재연결과 관련된 버그가 있었고 Lodestar는 블록 생성을 거부한 피어의 점수를 낮췄습니다.

첫 번째 레벨 제목

FAQ

Q: 이 테스트넷은 죽었나요?

A:아니요. 수정 사항을 배포하고 일부 정체된 노드를 다시 동기화한 후 체인이 마침내 다시 마무리되기 시작했습니다. 체인 복구가 완료되면 정상적으로 작동할 수 있습니다. 현재 Kintsugi의 참여율은 약 99%로 모든 클라이언트가 패치되었으며 네트워크가 잘 작동하고 있음을 나타냅니다. 트랜잭션 및 스마트 계약 상호 작용은 평소와 같이 계속 작동합니다.

Q: 이 체인이 오랫동안 마무리되지 않은 이유는 무엇입니까?

A:초기에 근본 원인을 찾았지만 체인을 확정되지 않은 상태로 유지하고 클라이언트 팀이 코드를 디버그할 수 있도록 하고 싶었습니다. 또한 최종화되지 않은 기간 동안 클라이언트 성능 데이터를 수집하기를 원했습니다.

Q: 포크 체인의 검증인이 삭감되나요?

A:습관. 각 검증자는 슬래싱될 수 있는 메시지에 검증자가 서명하지 않도록 보장하는 슬래싱 보호 데이터베이스를 포함합니다. "잘못된" 포크의 유효성 검사기는 "올바른" 포크에서만 비활성화된 것으로 간주됩니다. 그들이 "올바른" 포크에서 재편성되면 슬래싱 데이터베이스는 그들이 슬래시 가능한 메시지에 서명하는 것을 방지합니다.

Q: 이것이 메인넷 출시에 어떤 영향을 미칩니까? 새로운 지연이 있습니까?

A:우리는 이 문제가 메인넷 출시 계획에 영향을 미치지 않을 것이라고 생각합니다. 사양 자체에서는 심각한 문제가 발견되지 않았습니다. 테스트넷의 목적은 버그를 찾는 것이며 Kintsugi는 클라이언트 구현에서 엣지 케이스를 잘 찾는다고 생각합니다. 이 이벤트는 여러 클라이언트 조합에 대한 좋은 스트레스 테스트입니다. 우리는 메인넷에서 병합할 준비가 되었을 때 우리를 안내할 공개 체크리스트를 가지고 있습니다.

Q: 이것이 테스트 계획에 어떤 영향을 미칩니까?

A:우리는 완료되지 않은 상태에 있어야 하는 여러 테스트넷을 생성하는 방법을 살펴볼 것입니다. 이러한 최종화되지 않은 테스트넷에 대한 지속적인 테스트를 통해 더 많은 엣지 케이스를 트리거하고 도구를 개선할 수 있습니다. 이 사건에서 발견된 취약점은 회귀 테스트를 통과할 수 있도록 정적 테스트 사례로 추가됩니다.

유효성 검사기, 인프라 제공자 및 도구 개발자에게 중요한 영향:

테스트넷의 비확정 기간은 최악의 하드웨어 요구 사항에 대한 몇 가지 가정을 강화합니다. 최종화되지 않은 기간 동안 유효성 검사기는 다음을 예상해야 합니다.

• 여러 분기 선택 규칙을 평가해야 하기 때문에 CPU 부하 증가(때때로 최대 100%)

• 가지치기가 없기 때문에 종료되지 않은 기간 동안 HDD 사용량이 증가합니다.

• RAM 사용량이 약간 증가합니다.

즉, 동일한 시스템에서 실행되는 추가 도구 또는 모니터링이 리소스 경합에 빠집니다. Kintsugi 테스트넷의 도구(블록 탐색기, 수도꼭지, RPC)는 3개의 노드가 있는 Kubernetes 클러스터에서 실행됩니다. 이 클러스터는 여러 도구에서 사용하는 비콘 노드도 실행합니다. 비콘 노드는 프로비저닝된 것보다 훨씬 더 많은 리소스를 사용하기 때문에 리소스 부족으로 인해 도구가 저하된 방식으로 실행되는 경우가 많습니다. 인프라 제공자가 합의 및 실행 계층을 별도의 시스템에서 실행하거나 엄격한 리소스 사용 정의를 갖는 것이 현명합니다.

병합이란 각 합의 계층 클라이언트가 자체 실행 계층 클라이언트를 실행해야 함을 의미합니다. 실행 계층 클라이언트(메인넷의)는 이제 많은 디스크 용량을 필요로 합니다. CL의 디스크 사용량은 종료되지 않은 기간 동안에도 급증할 수 있으며, 이는 디스크 공간 부족으로 인한 충돌로 이어질 수 있습니다. 모든 유효성 검사기는 이러한 종류의 문제를 처리하기에 충분한 버퍼 디스크 공간이 있는지 확인해야 합니다.

완결성에 의존하는 도구 개발자는 완결되지 않은 기간을 추가로 고려해야 합니다. 가능한 한 가지 방법은 표시하는 것입니다.optimistic정보는 사용자 인터페이스에서 해당 정보를 전달하면서 변경됩니다.