ETC의 저렴한 51% 공격 퍼즐

편집자 주: 이 기사의 출처는골든 파이낸스, 승인을 받아 Odaily에서 재인쇄했습니다.

편집자 주: 이 기사의 출처는

골든 파이낸스

이 공격은 독립적인 채굴자 "0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e"에 의해 시작되었습니다. 채굴자는 3594개의 블록을 조용히 생산한 후 다른 채굴자들에게 전파하는데, 이러한 블록의 수가 많기 때문에 다른 채굴자들이 구축한 체인보다 블록의 순서가 더 무겁기 때문에 다른 채굴자들이 이 일련의 블록을 받아들이게 된다. 결국 공격자 블록은 원래 블록을 성공적으로 교체했고 블록 높이 10904146에서 블록 10907740으로 재구성이 발생했습니다.

, 승인을 받아 Odaily에서 재인쇄했습니다.

8월 3일, ETC의 공식 트위터는 ETC에 대한 51% 공격에 대한 블록체인 데이터 분석 회사인 Bitquery의 조사 보고서를 발표했습니다.

보고서에 따르면 8월 1일 0시 30분부터 8월 2일 11시 30분까지 ETC는 51%의 공격을 받았습니다.

이 공격은 독립적인 채굴자 "0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e"에 의해 시작되었습니다. 채굴자는 3594개의 블록을 조용히 생산한 후 다른 채굴자들에게 전파하는데, 이러한 블록의 수가 많기 때문에 다른 채굴자들이 구축한 체인보다 블록의 순서가 더 무겁기 때문에 다른 채굴자들이 이 일련의 블록을 받아들이게 된다. 결국 공격자 블록은 원래 블록을 성공적으로 교체했고 블록 높이 10904146에서 블록 10907740으로 재구성이 발생했습니다.

체인의 데이터를 보면 채굴자가 의도적으로 외부에서 해시파워를 구입해 공격을 시작했고, 채굴자의 주소는 7월 29일부터 활성화된 것으로만 표시돼 3일 연속 매일 30개의 블록을 생성하고 있다. 결국 공격자는 17.5 BTC(미화 약 17만 달러)를 들여 12시간 동안 전체 ETC 네트워크를 속이고 공격에 성공했다.

또한 노드와 채굴자가 실행하는 모든 소프트웨어가 ETC 네트워크에서 동일하게 작동하는 것은 아니기 때문에 노드 버전과 소프트웨어의 다양성으로 인해 이 공격이 더욱 심각해집니다.

Geth와 Hyperledger Besu의 두 클라이언트를 기반으로 하는 노드는 공격자의 블록을 수락하고 가장 긴 분기 체인을 선택합니다.

Open Ethereum 클라이언트를 기반으로 하는 노드는 여전히 이전 체인을 유지합니다. 이 모든 것이 일부 채굴자들이 구 체인을 기반으로 돈을 이체하게 만들었지만 메인 ETC 체인(포킹된 체인)에 반영되지 않고 다른 클라이언트 기반의 노드가 이중 지출에 직면할 수 있습니다.

관련 기관의 조사에 따르면 구체적인 절차는 다음과 같습니다.

1. 악성 채굴자(ETC 주소: 0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e)가 약 3000개의 블록을 채굴했습니다.

2. Multi-geth가 Ethereum 클래식에 대한 지원을 종료했기 때문에 2Miners 풀이 유지 관리를 위해 일시적으로 오프라인 상태였습니다.

3. 2Miners 마이닝 풀의 유지보수 기간 동안 2Miners 마이닝 풀은 새로운 블록을 생성하지 않았습니다. 2Miners 마이닝풀이 유지보수를 마치고 온라인으로 전환된 후 약 3,000개의 블록이 동시에 2Miners 마이닝풀에 삽입되었습니다.

4. Ethereum Classic의 Parity 또는 OpenEthereum 노드 중 어느 것도 Core-Geth 노드의 3693 블록을 처리할 수 없었기 때문에 체인 포크가 발생했습니다.

Parity 또는 OpenEthereum 노드의 모든 채굴자는 여전히 원래 메인 체인에서 채굴하고 있지만 Core-Geth 노드의 채굴자는 약 3000 블록에 대해 삽입된 새 체인에서 채굴하고 있습니다.

5. 작업 증명(POW) 합의에 따르면, 새로운 체인의 작업량은 원래 메인 체인을 점차 초과할 것이며, 원래 메인 체인의 패리티 노드에 있는 일부 마이너는 "작업량이 더 많은 체인에서 채굴을 선택합니다." " 가이드라인, 마이닝을 위해 새로운 체인으로 이전.

마지막으로 블록 높이 10904146에서 재구성을 통해 총 3693개의 블록이 블록체인에 추가되었습니다.

두 조직의 조사 및 정보 공개를 통해 분명히 두 가지 이유가 있습니다. 하나는 최근 클라이언트 지원 문제 때문이고 다른 하나는 공격자가 이를 이용했기 때문입니다.

다른 클라이언트는 다른 액세스 역할을 나타냅니다.채굴자는 네트워크 관리자이자 데이터 생산자입니다.즉, 클라이언트가 잘못된 데이터를 제공하면 다른 노드에 의해 동기화되어 공격의 시작입니다.

위에서 언급한 공격자는 마이닝 풀 노드의 재온라인 타이밍을 이용하여 준비된 블록 데이터를 올바른 회계 데이터로 마이닝 풀로 오인하고 방송을 계속합니다. 그리고 Parity, OpenEthereum 및 Core-Geth 클라이언트 마이너의 "불일치"로 인해 서로 다른 데이터의 동기화가 일치하지 않아 포크로 이어집니다.

이 공격의 근원은 클라이언트의 혼란이며, 이 사건의 원인은 오랫동안 양조되어 왔습니다.

Jinse Finance의 이전 보고서에 따르면 2020년 1월 25일 ETC Cooperative의 전무 이사인 Bob Summerwill은 최근 ECIP-0001 제안에 대한 지원을 연장한다고 발표했습니다. 제안의 일부 변경 사항에는 Rust 개발자 Wei Tang의 제거가 포함됩니다.

Bob Summerwill은 ECIP 편집자이자 ECIP-1000 저자인 Wei Tang이 자신의 권한을 반복적으로 남용하고 소프트 포크를 위협하거나 ETC 생태계를 떠나겠다고 위협했다고 비난했습니다.

또한 ECIP-1000의 에디터 목록에 soc1c 대신 soc1c의 실명이 사용되었기 때문에, ETC 커뮤니티에서는 Wei Tang이 커뮤니티의 또 다른 ECIP 에디터인 soc1c에 대해 인육 검색을 했다는 비난의 목소리가 나오고 있습니다.

이와 관련해 Wei Tang은 자신의 블로그에서 사건의 원인을 설명하고 관련 제안에 대한 변경은 ETC의 과도한 중앙 집중화를 피하려는 고려 때문이라고 응답했습니다. 그러나 후반기에 논란은 사실상 자신에게로 옮겨갔다. 동시에 Wei Tang은 소위 인육 관련 사실이 없다고 말했습니다. 이전에 편집자 명단을 병합할 때 soc1c 자신이 동의했고, soc1c의 실명이 커뮤니티에 널리 알려져 있으며 종종 실명을 사용하기 때문입니다.

논란이 된 사건은 ECBP-1076 제안서에서 비롯된 것으로 전해졌다. Wei Tang은 더 많은 논의를 요청했지만 ECBP-1076 제안이 ETC 회의에서 처음으로 제안되고 수락되었으며 ECIP 편집자가 ECBP-1065 제안의 상태를 다음으로 변경했다고 느꼈기 때문에 soc1c에서 거부했습니다. 무분별하게 "활성화"(soc1c가 해지 검토를 수행함)한 후 soc1c는 ECIP 프로세스에서 Wei Tang을 제거하라는 요청을 제출했습니다. 그 이후로 Aztlan의 하드 포크 중에 ECIP-1061 및 ECIP-1072에 대한 분쟁이 있었습니다(이 분쟁에서 "해지" 작업도 나타남). Wei Tang은 제안 프로세스에서 soc1c의 "해지" 작업이 실제로 큰 중앙 집중화 위험이라고 믿고 "해지" 작업이 프로세스를 위반하며 표준으로 간주되어서는 안 된다고 주장하면서 새로운 요청을 생성했습니다.

Wei Tang과 커뮤니티는 ETC Aztlán 하드포크 연기에 대해 다른 견해를 가지고 있습니다. 그는 Aztlán 사양의 오류가 이미 Mordor 및 Kotti 테스트넷에 돌이킬 수 없는 피해를 입혔다고 생각합니다. 이제 그는 피해가 확산되지 않기를 바랄 뿐입니다. 메인넷에. Wei Tang은 "무책임한 하드포크는 네트워크 보안을 파괴할 것이며 매일 코드가 법이라고 외치는 것은 소용이 없습니다."라고 말했습니다.

Bob Summerwill은 커뮤니티가 이전에 선택한 하드 포크의 블록 번호를 변경하는 것이 아니라 예측할 수 없는 블록 시간 요인으로 인해 포크 지연이 발생했다고 응답했습니다. 블록 시간 예측의 오류는 일반적입니다. 커뮤니티가 건강하지 않다는 비난에 대해 Bob Summerwill은 ETC 커뮤니티가 매우 건강하다고 응답했습니다.

대립은 반복되지만 통일성은 확인할 수 없다.

6월 14일 Wei Tang은 Phoenix 하드포크 이후 ETC 네트워크가 특히 불변성 측면에서 이더리움 일관성 논리를 깨뜨렸기 때문에 개인적으로 ETC 지원을 중단하겠다고 발표했습니다.

한 달 후, ETC의 두 주요 클라이언트인 OpenEthereum과 MultiGeth는 ETC 지원을 중단하겠다고 발표했습니다. 그리고 이 두 클라이언트는 여전히 ETC 네트워크의 총 노드 수의 70%를 공유하므로 ETC 사용자가 적절한 조치를 취하도록 하는 공익 광고입니다. 나중에 Wei Tang이 발표한 기사에 따르면 두 주요 클라이언트가 ETC 지원을 중단한 이유는 Wei Tang이 ETC 지원을 중단한 이유와 동일합니다.

이것이 공격의 발원지로, 네트워크 노드 클라이언트가 절반 이상을 차지하고 서비스가 갑자기 중단되면 이후 컴퓨팅 파워 마이그레이션 과정에서 네트워크가 위험할 수밖에 없다.

OpenEthereum과 MultiGeth가 ETC 지원을 중단한다고 발표한 소식에 대해 ETC Asia-Pacific 커뮤니티 관리자인 Christian은 OpenEthereum의 메인테이너인 Gnosis가 ETC 지원을 중단한 이유가 제한된 에너지를 개발에 쏟기 위함이라는 공식 성명을 발표했다고 말했습니다. Wei Tang이 아닌 Ethereum 메인넷의 이유를 말했습니다.

Phoenix 이후 MultiGeth의 실제 개발자는 Wei Tang 자신뿐이며 약간의 차이로 인해 Wei Tang은 MultiGeth가 ETC를 지원하지 않도록 선택했습니다.

ETC는 작년부터 세 번의 하드 포크 업그레이드를 완료하여 ETC 네트워크가 ETH와 완전히 일치하도록 만들었습니다. 그 중 ETC Core 팀이 많은 기여를 했습니다. ETC Core 팀은 이르면 상반기에 보다 안전한 Go 언어 클라이언트인 CoreGeth를 개발했으며 CoreGeth는 Phoenix 하드 포크를 완벽하게 지원하며 지금까지 그대로 실행되고 있습니다. Gnosis에 대한 답변에서 OpenEthereum 및 MultiGeth가 종료된 후에도 ETC Core에서 유지 관리하는 공식 클라이언트인 CoreGeth가 완전히 신뢰할 수 있으며 계속해서 ETC 네트워크에 서비스를 제공하고 있음을 알 수 있습니다.

그런 다음 Wei Tang은 사실 OpenEthereum과 MultiGeth가 ETC를 가장 오랫동안 지원하는 두 클라이언트라고 응답했습니다. 그 중 OpenEthereum은 4년, MultiGeth는 2년입니다. 다른 클라이언트는 1년 이상 ETC를 지원하지 않았습니다. 그 중 Hyperledger Besu는 작년 9월부터 ETC를 지원했고, CoreGeth는 ETC를 지원하기 위해 올 봄 MultiGeth에서 분리되었으며 OpenETC는 이제 막 ETC를 지원하기 시작했습니다.

Tang Wei의 견해로는 ETC 네트워크가 불변성 원칙을 포기하는 것 외에도 ETC에 대한 지원을 중단하는 것도 합리적이고 필요한 대응입니다. 왜냐하면 지난 6개월 동안 우리는 ETC 커뮤니티의 매우 나쁜 면을 보았기 때문입니다.

이것은 ETC에 대한 가장 강렬한 댓글입니다. 클라이언트 문제, 커뮤니티 불화, 갑작스러운 공격에 직면합니다.