역전: 이더리움의 상황

ECN以太坊中国

特邀专栏作者

2021-05-21 17:56 (UTC+8)

이 기사는 약 3978자로, 전체를 읽는 데 약 6분이 소요됩니다

이 블로그 게시물의 목적은 베를린 하드포크 이전의 이더리움 플랫폼의 심각하고 명백한 문제를 공식적으로 폭로하는 것입니다.

AI 요약

펼치기

이 블로그 게시물의 목적은 베를린 하드포크 이전의 이더리움 플랫폼의 심각하고 명백한 문제를 공식적으로 폭로하는 것입니다.

출처 | 이더리움 블로그

이 블로그 게시물의 목적은 베를린 하드포크 이전의 이더리움 플랫폼의 심각하고 명백한 문제를 공식적으로 폭로하는 것입니다.

보조 제목

상태

Ethereum의 배경과 "상태"부터 시작하겠습니다.

이더리움의 상태는 접두사 트리의 일종인 patricia-merkle trie로 구성됩니다. 이 기사에서는 기술적인 세부 사항에 대해 설명하지 않습니다. 간단히 말해서 상태가 성장함에 따라 트리의 가지가 점점 더 조밀해집니다. 가입하는 각 계정은 새 잎사귀입니다. 트리의 뿌리 사이와 잎 사이에는 많은 수의 "중간" 노드가 있습니다.

이 거대한 트리에서 특정 계정 또는 "리프"를 찾으려면 트리의 루트에서 중간 노드를 통해 우리가 찾고 있는 데이터를 최종적으로 해시하기 위해 6-9개의 해시를 풀어야 합니다. .

즉, 계정을 조회하는 모든 시도 쿼리에 대해 8-9개의 구문 분석 작업이 수행됩니다. 각 구문 분석 작업은 데이터베이스 쿼리이며 각 데이터베이스 쿼리는 여러 실제 디스크 작업이 될 수 있습니다. 디스크 작업의 수는 예측하기 어렵지만 트라이 키는 암호학적으로 해시(충돌 방지)되기 때문에 키는 "무작위"이며 이는 모든 데이터베이스에서 최악의 시나리오입니다.

Ethereum이 성장함에 따라 항상 트리 액세스 작업의 가스 비용을 높이는 것이 필요했습니다. 2016년 10월 "상하이 공격" 시기를 경험한 후 이더리움 네트워크는 EIP 150을 포함하는 블록 높이 2,463,000에서 Tangerine Whistle 하드 포크를 겪었습니다. DoS 공격에 대해.

가스 요금의 또 다른 인상은 EIP 1884를 활성화한 2019년 12월 이스탄불 업그레이드에서였습니다.

EIP-1884는 가스 요금에 다음과 같은 변경 사항을 도입합니다.

➤SLOAD가 200에서 800 가스로 증가했습니다.

➤EXTCODEHASH가 400에서 700 가스로 증가했습니다.

보조 제목

문제

2019년 3월 Martin Swende는 일부 EVM opcode 성능 측정을 수행했습니다. 후속 EIP-1884는 이 조사를 기반으로 했습니다. Broken Meter는 EIP-1884가 활성화되기 몇 달 전에 이 논문(2019/9)을 발표했습니다.

두 명의 이더리움 보안 연구원인 Hubert Ritzdorf와 Matthias Egli와 논문 저자 중 한 명인 Daniel Perez는 취약점을 "무기화"하여 이더리움의 버그 바운티 프로그램에 제출했습니다. 2019년 10월 4일입니다.

모든 사람이 자신이 제출한 전체 문서를 읽을 것을 권장합니다. 이는 매우 상세합니다.

같은 날 Geth, Parity 및 Aleth의 개발자는 클라이언트 간 보안 전용 채널에서 문서에 대해 알게 되었습니다.

이 취약점의 본질은 무작위 시도 쿼리를 트리거하는 것입니다. 다음은 간단한 예입니다.

그들의 보고서에서 연구원들은 eth_call을 사용하여 메인 네트워크를 동기화한 노드에서 이 페이로드를 실행했습니다.다음은 실행 중 데이터이며 천만 가스 비용입니다.

Parity: ~90s
Geth: ~70s

➤ 1,000만 가스를 소비하는 EXTCODEHASH(400가스)

Parity : ~50s
Geth : ~38s

➤ 천만 가스를 소비하는 EXTCODEHASH(700가스)

분명히 EIP-1884의 변경 사항은 이 공격의 영향을 줄이는 데 도움이 되었지만 충분하지는 않았습니다.

오사카에서 개발자 회의가 다가오고 있었습니다. 개발자 컨퍼런스에서는 이 문제에 대한 정보를 메인넷의 클라이언트 개발자들과 공유했습니다. 우리는 또한 Hubert, Mathias 및 Greg Markou(Chainsafe 출신으로 당시 일부 ETC 작업도 수행 중)를 만났습니다. ETC 개발자도 이 보고서를 받았습니다.

2019년이 끝나감에 따라 우리는 문제가 이전에 예상했던 것보다 더 심각하다는 것을 알고 있습니다. 악의적인 트랜잭션으로 인해 잠재적으로 블록 시간이 분 범위로 밀려날 수 있습니다. 설상가상으로 개발자 커뮤니티는 EIP-1884에 불만을 품고 있습니다. EIP-1884가 일부 계약 프로세스를 위반하고 사용자와 채굴자가 블록의 가스 한도를 늘리고 싶어하기 때문입니다.

보조 제목

해결책

두 번째 방법은 클라이언트에서 데이터 모델과 구조를 수정하여 소프트웨어 엔지니어링을 통해 해결하는 것입니다.

보조 제목

프로토콜 계층의 작업

이러한 유형의 공격을 처리하는 방법에 대한 첫 번째 릴리스가 여기에 있습니다. 2020년 2월에 EIP 2583으로 정식 출시되었습니다. 트라이 룩업 결과가 실패할 때마다 페널티를 부과하는 것이 아이디어입니다.

그러나 Peter는 이 페널티의 상한(약 800)을 효과적으로 제한하는 "실드 릴레이" 공격이라는 대책을 찾았습니다.

미스 쿼리에 페널티를 부여하는 문제는 페널티를 부과할지 여부를 결정하기 위해 조회가 먼저 필요하다는 것입니다. 그러나 남은 가스가 페널티를 지불하기에 충분하지 않은 경우 미납 소비가 수행되었습니다. 예외가 발생하더라도 이러한 상태 읽기를 중첩된 호출로 래핑하여 외부 호출자가 (전체) 페널티를 지불하지 않고 반복 공격을 계속할 수 있습니다.

이러한 이유로 이 EIP는 폐기되었으며 더 나은 대안을 찾고 있습니다.

➤ Alexey Akhunov는 두 번째 가스 공급원인 Oil의 개념을 제안했지만 실행 계층에 보이지 않고 전역적으로 트랜잭션이 롤백될 수 있기 때문에 본질적으로 가스와 동일하지 않습니다.

➤ Martin은 2020년 5월에도 유사한 제안을 작성했습니다(Gas And Karma).

이러한 다양한 메커니즘을 반복하는 동안 Vitalik Buterin은 가스 비용을 직접 늘리고 액세스 목록을 유지할 것을 제안했습니다. 2020년 8월 Martin과 Vitalik은 EIP-2929와 그 동반자인 EIP-2930을 정제하기 시작했습니다.

EIP-2929는 이전의 많은 문제를 효과적으로 해결합니다.

➤ 무조건 가스비를 높이는 EIP-1884에 비해 EIP-2929는 방문하지 않는 부분의 가스비만 증가시킨다. 그 결과 순 비용 증가율은 1% 포인트 미만이었습니다.

➤ EIP-2930 추가로 계약 프로세스 중단 없음

2021년 4월 15일에 베를린 업그레이드에서 두 EIP가 모두 활성화되었습니다.

보조 제목

개발 작업

Peter가 2019년 10월에 제안한 솔루션은 "동적 상태 스냅샷"입니다.

스냅샷은 이더리움 상태를 플랫 형식으로 저장하는 데 사용되는 보조 데이터 구조로, Geth 노드의 라이브 작동 중에 완전히 온라인으로 구성할 수 있습니다. 스냅샷의 이점은 상태 액세스를 위한 가속화된 구조로 작동한다는 것입니다.

➤ 계정 또는 스토리지 슬롯에 액세스하기 위한 O(log N) 디스크 읽기(x LevelDB 오버헤드) 대신 스냅샷이 직접 O(1) 액세스 시간(x LevelDB 오버헤드)을 제공할 수 있습니다.

➤ 스냅샷은 항목당 O(1) 복잡성으로 계정 및 스토리지에 대한 반복을 지원하므로 원격 노드가 이전보다 훨씬 저렴하게 순차적 상태 데이터를 검색할 수 있습니다.

➤ 또한 스냅샷은 가지치기 상태 시도 오프라인 또는 다른 데이터 형식으로의 마이그레이션과 같은 보다 특이한 사용 사례를 가능하게 합니다.

스냅샷의 단점은 원래 계정과 스토리지 데이터가 효과적으로 복제된다는 것입니다. 메인넷의 경우 이는 25GB의 추가 SSD 공간을 의미합니다.

동적 스냅샷의 개념은 2019년 중반부터 시작되었으며 원래 목적은 주로 스냅샷 동기화의 실현을 촉진하는 것이었습니다. 당시 Geth 팀은 많은 "큰 프로젝트"로 바빴습니다.

➤ 오프라인 다듬기

➤ 동적 스냅샷 + 스냅샷 동기화

➤ 샤딩 상태를 통한 LES(Light Ethereum Subprotocol) 상태 분배 실현

보조 제목

요약하다

2021년 3월-4월에 geth 클라이언트에 snap/1 프로토콜이 구현되어 새로운 스냅샷 기반 알고리즘을 통해 동기화가 가능해졌습니다. 여전히 기본 동기화 모드는 아니지만 이것은 스냅샷을 공격 방어로 유용할 뿐만 아니라 사용자를 위한 중요한 최적화로 만드는 중요한 단계입니다.

합의에 따라 베를린의 업그레이드는 2021년 4월에 완료될 예정입니다.

다음은 AWS 모니터링 환경에서 개발된 몇 가지 벤치마크입니다.

➤ 베를린 업그레이드 전, 스냅샷 없음, 25M 가스: 14.3초

➤ 베를린 업그레이드 이전에 스냅샷이 있었습니다. 25M 가스: 1.5초

➤ 베를린 업그레이드 후, 스냅샷 없음, 25M 가스: ~3.1초

➤ 베를린 업그레이드 후, 스냅샷 포함, 25M 가스: ~0.3초

대략적인 수치는 Perlin 업그레이드가 공격의 효율성을 5배로, 스냅샷을 10배로 줄여 전체 영향을 50배로 줄일 수 있음을 보여줍니다.

현재 메인넷(15M 가스)에서 스냅샷을 사용하지 않는 geth 노드의 경우 실행 시간이 2.5~3초인 블록 생성이 가능하다고 추정합니다. 스냅샷이 아닌 노드의 경우 이 수치는 상태가 커짐에 따라 계속 악화됩니다.

이 공격의 실행 가능성에 대해 공격자가 전체 블록을 구입하는 데 드는 비용은 약 몇 ETH입니다(15M 가스는 100Gwei에 대해 1.5ETH입니다).