보안 과제 개요

블록체인의 결정적인 특징 중 하나는 트랜잭션의 원자성입니다. 즉, 업데이트가 블록체인에 기록되면 개입이나 되돌릴 기회가 없습니다. 이는 일관성과 프로토콜 수준의 보안을 강력하게 보장하지만, 사용자들을 더 높은 운영 위험에 노출시킵니다. 단 한 번의 실수, 손상된 키 또는 성급한 승인은 되돌릴 수 없는 손실로 이어질 수 있습니다.

결과적으로 상당한 보안 부담이 사용자에게 있습니다. 이더리움을 안전하게 사용하기 위해 개인과 조직은 키를 안전하게 보유 및 관리하고, 온체인 애플리케이션과 상호 작용하며, 키를 사용하여 자산을 이전하거나 이더리움 상태를 업데이트하는 트랜잭션에 서명해야 합니다.

이러한 각 요구 사항은 키 손상이나 분실, 성급하거나 정보에 입각하지 않은 승인, 또는 사용자가 이더리움과 상호 작용하는 데 필요한 정보를 제공하고 안내하는 지갑 소프트웨어의 손상과 같은 위험을 초래합니다.

1.1 키 관리

많은 사용자가 암호화 키를 안전하게 관리할 준비가 되어 있지 않습니다.

가장 널리 사용되는 소프트웨어 지갑은 사용자가 기본 암호화 개인 키를 나타내는 시드 문구를 안전하게 저장하는 데 의존하며, 이로 인해 시드 문구를 일반 텍스트로, 클라우드 서비스에 저장하거나 종이에 적어두는 등 안전하지 않은 해결 방법을 사용하게 되는 경우가 많습니다.

하드웨어 지갑은 사용자가 특수 목적의 물리적 장치 내에 저장된 암호화 키를 관리할 수 있게 해주는 대안입니다. 하지만 하드웨어 지갑은 자체적인 결함과 공격 표면을 가지고 있습니다. 하드웨어 지갑은 분실, 손상 또는 도난당할 수 있습니다. 많은 하드웨어 지갑은 오픈 소스가 아니며 불투명한 공급망을 가질 수 있어 손상된 장치가 시장에 판매되는 공급망 공격의 위험을 높입니다.

키가 소프트웨어 또는 하드웨어 지갑에서 관리되든, 많은 사용자는 물리적 도난이나 폭행을 통해 손상될 수 있는 경우 셀프 커스터디에 대해 불안해하는 것이 당연합니다.

기업 및 기관 사용자는 키 관리에 추가적인 어려움에 직면합니다. 개별 직원이 키를 보유하는 경우(예: 다중 서명 지갑의 일부로), 조직은 시간 경과에 따른 인사 변경으로 인해 이를 교체하고 새로운 것을 생성할 수 있어야 합니다. 다양한 산업 및 관할권의 규정 준수 요구 사항은 기존 지갑 소프트웨어에서 지원되지 않는 사용자 지정 워크플로나 감사 추적을 요구할 수 있습니다. 경우에 따라 기업 사용자는 디지털 자산을 위해 타사 커스터디언을 이용하며, 이는 고려해야 할 또 다른 보안 위험 레이어를 도입할 수 있습니다.

1.2 블라인드 서명 및 트랜잭션 불확실성

사용자는 자신이 무엇을 하는지 이해하지 못한 채 일상적으로 "블라인드"로 트랜잭션을 승인합니다. 지갑은 종종 원시 16진수 데이터, 잘린 계약 주소 또는 사용자가 주어진 트랜잭션의 결과를 이해하기에 충분하지 않은 기타 정보를 제공합니다. 이로 인해 모든 종류의 사용자가 악의적인 스마트 계약, 피싱, 사기, 스푸핑된 인터페이스, 프런트엔드 손상 및 기본적인 사용자 오류에 취약해집니다.

1.3 승인 및 권한 관리

많은 이더리움 애플리케이션에서 사용자는 일반적인 사용의 일부로 기본 애플리케이션에 특정 권한을 부여하는 것이 일반적입니다. 예를 들어, 사용자는 ETH로 교환하기 위해 토큰을 이동할 수 있는 권한을 Uniswap과 같은 탈중앙화 거래소에 부여할 수 있습니다.

이러한 승인은 금액에 제한을 둘 수 있지만, 많은 지갑은 만료일 없이 무제한 승인을 부여하는 것을 기본으로 합니다. 대부분의 지갑 내에서 사용자가 미결제 승인을 관리하거나 검토할 방법이 없습니다.

이는 많은 사용자의 기본 패턴이 자금을 고갈시키는 데 사용될 수 있는 무제한 승인을 부여하는 것이기 때문에 사용자를 악의적인 앱이나 손상된 프런트엔드에 노출시킬 수 있습니다. 사용자가 합법적인 스마트 계약에 승인을 부여하더라도, 승인이 유지되는 동안 해당 계약이 나중에 손상되면 손상된 계약이 사용자의 자금을 고갈시킬 수 있습니다.

이는 조직 사용자에게도 마찬가지로 위험합니다. 예를 들어, 조직은 운영 편의를 위해 DEX 라우터에 무제한 USDC 허용량을 부여하도록 선택할 수 있으며, 이 경우 라우터 계약이 업그레이드되면 위험에 노출됩니다.

1.4 손상된 웹 인터페이스

대부분의 사용자는 스마트 계약과 직접 상호 작용하지 않고 모바일 장치나 웹 브라우저를 통해 웹 인터페이스를 통해 상호 작용합니다.

이러한 프런트엔드는 DNS 하이재킹, 악의적인 자바스크립트 삽입, 안전하지 않은 호스팅 또는 다양한 타사 종속성과 같은 익숙한 수단을 통해 공격에 취약할 수 있습니다. 손상된 앱 UX는 모든 종류의 사용자를 악의적인 스마트 계약으로 리디렉션하거나 오해의 소지가 있는 트랜잭션에 서명하도록 유도할 수 있습니다.

1.5 개인 정보 보호

개인 정보 보호는 모든 종류의 사용자에 대한 보안 위험을 완화하거나 확대할 수 있습니다.

취약한 개인 정보 보호는 개인 사용자를 피싱, 착취, 사기 또는 물리적 공격과 같은 다양한 표적 위협에 노출시킵니다. 주소 재사용, KYC 데이터 및 기타 메타데이터 유출과 같은 많은 일반적인 UX 패턴은 사용자를 노출시킵니다.

기관 및 기업의 경우, 개인 정보 보호는 규정 준수 또는 특정 사용 사례에 대한 기본적인 비즈니스 요구 사항인 경우가 많습니다. 이러한 문제 외에도 특정 보안 위험에 노출될 수 있습니다. 예를 들어, 이더리움에 구축된 공급망 시스템의 사용자는 시스템이 투명한 경우 손상될 수 있는 지적 재산 자산을 보호하기 위해 강력한 개인 정보 보호 보장이 필요할 수 있습니다.

1.6 파편화

다른 지갑이 트랜잭션 표시, 승인 처리 또는 계약 라벨링과 같은 핵심 동작을 처리하는 방식에 일관성이 부족합니다. 이러한 사용자 경험의 파편화는 사용자가 지갑을 안전하게 사용하는 방법을 배우는 능력에 마찰을 더하고 위험을 증가시킵니다.

예를 들어, 사용자는 지갑마다 다르기 때문에 피싱과 스푸핑으로부터 자신을 보호하기 위해 일관된 UX 신호에 의존할 수 없습니다. 각 도구가 다르게 작동하면 사용자는 이더리움이 어떻게 작동하는지에 대한 신뢰할 수 있는 기대를 형성할 수 없습니다.

스마트 계약 보안은 이더리움의 역사에 걸쳐 급진적으로 개선되었습니다. DAO 해킹과 같은 초기 보안 사고는 생태계가 코드가 온체인에 배포되는 소프트웨어 수명 주기 전반에 걸쳐 안전 장치를 전문화하고 개선하도록 동기를 부여했습니다. 주요 발전 사항은 다음과 같습니다.

• 보안 감사는 표준 관행이 되었고, 여러 보안 회사가 생태계에 진입하여 전문성을 개발했습니다.
• 툴링, 테스트 및 정적 분석 시스템이 성숙해지고 표준 관행이 되었습니다.
• 사전 감사된 공통 구성 요소 라이브러리는 개발자에게 기본적으로 안전한 빌딩 블록을 제공했습니다.
• 정형 검증 기술이 채택되었으며, 특히 브리지, 스테이킹 시스템 및 고가치 계약에 사용되었습니다.
• 생태계의 보안 문화와 모범 사례가 개선되었습니다.
• 앱 레이어를 강화한 중요한 현상금 프로그램의 생성.

하지만 이 영역에는 여전히 약점과 개선의 여지가 있습니다.

2.1 계약 취약점

스마트 계약 보안의 발전에도 불구하고, 다음과 같은 중대한 보안 문제로 이어질 수 있는 취약점이 여전히 존재합니다.

• 계약 업그레이드 위험. 일부 계약은 배포 후 수정 가능하도록 설계되어 개발팀이 애플리케이션을 계속 업데이트하고 개선할 수 있도록 합니다. 그러나 이는 위험을 초래합니다. 업그레이드는 새로운 취약점을 초래하거나 악의적인 업그레이드의 경우 사용자 자금의 완전한 손실을 초래할 수 있습니다.
• 재진입, 계약 A가 자체 내부 상태를 업데이트하기 전에 외부 계약 B를 호출하고, 첫 번째 호출이 끝나기 전에 계약 B가 원래 계약 A를 다시 호출하는 경우입니다.
• 외부 라이브러리의 안전하지 않은 사용, 계약이 감사되지 않았거나, 악의적이거나, 업그레이드 가능한 외부 라이브러리를 호출하는 경우입니다.
• 감사되지 않은 구성 요소. 감사 및 표준 라이브러리 사용이 개선되었지만, 개발자는 때때로 애플리케이션에서 감사되지 않은 구성 요소에 의존합니다.
• 액세스 제어 실패, 권한이 잘못 구성되었거나 너무 광범위하게 정의되어 공격자가 악의적인 행동을 취할 수 있는 경우입니다.
• 무단 액세스, 계약을 제어할 수 있는 개인 키를 악의적인 행위자가 획득하는 경우입니다.
• 브리지 및 크로스체인 상호 작용. 브리지 및 크로스체인 프로토콜은 추가적인 복잡성을 도입하며, 공격자는 크로스체인 메시지가 전달되거나 검증되는 방식의 약점을 악용할 수 있습니다.
• 외부 소유 계정(EOA) 위임 또는 서명 오용. 악의적인 애플리케이션은 사용자를 속여 계정의 전체 위임을 다른 당사자에게 서명하도록 유도하여 절도를 가능하게 할 수 있습니다. 악의적인 애플리케이션은 또한 사용자로부터 서명된 메시지를 예기치 않은 방식으로 사용할 수 있습니다. 예를 들어, 재생 공격에서입니다.
• AI 코드 생성 또는 자동화된 리팩터링 도구에 의해 도입되는 버그의 새로운 위험.

2.2 개발자 경험, 툴링 및 프로그래밍 언어

취약점은 개발자 오류의 결과로 배포된 코드에 남게 됩니다. 개선된 개발자 툴링은 안전한 스마트 계약을 배포하는 것을 훨씬 쉽게 만들었습니다. 그러나 문제는 여전히 남아 있습니다.

• 인기 있는 프레임워크에서 안전한 기본값 부족. 일부 도구는 안전보다 유연성이나 속도를 우선시하여 approve() 함수에서 무제한 토큰 승인과 같은 안전하지 않은 기본값을 설정하거나 기본적으로 액세스 제어 패턴을 포함하지 못합니다.
• 고급 운영 제어를 위한 사용자 지정 코드. 복잡한 운영 요구 사항을 가진 기관 사용자는 종종 필요한 기능을 처음부터 구축해야 하므로 취약점의 위험이 증가합니다. 고급 보안 워크플로를 위한 표준화된 보안 구성 요소나 프레임워크가 부족합니다.
• 일관되지 않은 테스트 범위 툴링 스택 전반에 걸쳐 퍼징이나 불변 검사와 같은 입증된 기술을 사용하는 것에 대한 규범이 부족합니다.
• 정형 검증 방법의 낮은 채택률. 정형 검증 기술은 강력하지만 복잡하고 비용이 많이 들며 전문 분야 전문 지식이 필요하며 표준 개발자 워크플로에 잘 통합되어 있지 않아 사양 단계에서 안전성을 검증하기 위해 소프트웨어 생산 초기에 사용할 수 있습니다.
• 계약 검증 관련 문제. 사용자와 개발자는 배포된 계약의 신뢰성, 보안 검증 범위(예: 코드 감사) 또는 잠재적 위험의 존재를 쉽게 평가할 수 없습니다. 이 목적을 위한 해결책이 존재하지만 많은 문제가 남아 있습니다. 이러한 문제를 해결하는 툴링은 널리 채택되지 않았고, 접근 방식을 통합할 표준은 여전히 단편적이며, 기존 서비스 중 일부는 그 자체가 중앙 집중식 종속성입니다.
• 컴파일러 위험. 컴파일러(Solidity와 같은 사람이 읽을 수 있는 코드를 EVM 자체에서 사용하는 바이트코드로 변환하는 소프트웨어)에는 배포되기 전에 스마트 계약에 오류를 도입하는 결함이 있을 수 있습니다. 오늘날 이더리움 생태계는 대부분 solc 컴파일러에 의존하므로 버그가 광범위한 영향을 미칠 수 있습니다.
• 프로그래밍 언어 다양성 및 깊이. Solidity는 깊이 있는 툴링 생태계를 기반으로 하지만, 일부 개발자는 메모리 안전성과 같이 다른 프로그래밍 언어에서 볼 수 있는 더 현대적인 안전 기능을 원합니다.

2.3 온체인 코드의 위험 평가

기관과 기업은 의존하는 기술 및 시스템의 보안을 평가하기 위한 기존 프로세스, 표준 및 요구 사항을 가지고 있습니다. 그러나 기존 프레임워크는 종종 스마트 계약에 깔끔하게 매핑되지 않으며, 일반적으로 변경 가능한 코드, 중앙 집중식 변경 제어, 명확한 책임 또는 법적 책임 라인을 가정합니다. 스마트 계약에 구축된 시스템은 때때로 이러한 가정을 깨뜨려 조직이 이더리움을 채택하고 위험을 적절하게 관리하기 어렵게 만듭니다.

이러한 시스템은 지갑 및 애플리케이션 레이어(예: 지갑용 RPC 엔드포인트)와 이더리움 프로토콜 자체(예: 많은 검증자가 클라우드 인프라에서 호스팅됨) 모두에 대한 공격 표면입니다. 개인 키 손상, 피싱 및 세분화된 액세스 제어 부족은 기본 블록체인 프로토콜이 안전하게 유지되더라도 대규모 정전, 도난 또는 무단 변경으로 이어질 수 있습니다.

3.1 레이어 2 체인

레이어 2 체인(L2)은 이더리움의 확장 역할을 하며, 이더리움 메인넷의 특징적인 보안 보장 중 일부를 유지하면서(특정 설계에 따라 다름) 더 빠르고 저렴한 수수료 환경을 가능하게 합니다. 그러나 다음과 같은 고유한 공격 표면도 있습니다.

• 다중 홉 브리지된 자산 복잡성. 자산이 L1과 여러 L2 사이를 이동할 때, 모두 안전해야 하는 여러 계약 세트에 노출됩니다. L2 체인의 회계 불일치 또는 중단은 공격자가 악용할 수 있는 취약점을 도입할 수 있습니다.
• 롤업 L2는 증명 시스템에 의존하여 상태 업데이트의 정확성을 강제합니다.. 이러한 시스템의 버그나 잘못된 구성은 최종화를 지연시키거나 방해할 수 있으며, 또는 잘못된 상태 업데이트의 최종화를 허용하여 사용자 자금 손실로 이어질 수 있습니다.
• 보안 위원회는 L2 소프트웨어를 업그레이드하거나 특정 비상 사태에 대응하기 위한 "백업" 메커니즘 역할을 하는 키 보유자 그룹입니다.. 보안 위원회 자체도 위험을 초래하며, 구성원 간의 손상이나 공모는 사용자 자금을 위험에 빠뜨리거나 자산을 동결시킬 수 있습니다.

L2 성능과 보안을 평가하고 비교하는 자세한 프레임워크 및 모니터링 대시보드는 L2Beat (opens in a new tab)를 참조하십시오.

3.2 RPC 및 노드 인프라

이더리움 애플리케이션은 RPC 액세스, API 및 노드 서비스를 위해 소수의 인프라 공급자에 의존합니다. 여기에는 암호화폐 관련 인프라 공급자뿐만 아니라 노드를 호스팅하는 데 일반적으로 사용되는 기존 클라우드 서비스(예: AWS, Cloudflare, Hetzner)도 포함됩니다.

이러한 인프라 공급자가 오프라인 상태가 되거나 액세스를 검열하거나 제한하려고 시도하면 많은 사용자가 새 RPC 또는 다른 인프라 공급자로 마이그레이션할 수 있을 때까지 지갑이나 애플리케이션을 통해 이더리움에 액세스하지 못할 수 있습니다. 이러한 공급자 중 일부는 이전에 블록체인 활동과 관련된 계정을 정지하거나 폐쇄한 적이 있어 탈중앙화 애플리케이션에 대한 장기적인 신뢰성에 대한 우려를 제기합니다.

3.3 DNS 수준 취약점

도메인 이름 시스템(DNS)은 인터넷의 기본 레이어이지만 중앙 집중화되어 있으며 손상될 수 있습니다. 많은 사용자가 웹 도메인을 통해 앱에 액세스하며, 이는 다음에 취약합니다.

• 공격자가 악의적인 가짜 프런트엔드를 삽입하는 DNS 하이재킹.
• 정부나 등록 기관이 도메인을 압류할 수 있는 도메인 압류.
• 공격자가 사용자를 혼란시키기 위해 거의 동일한 이름을 등록하는 유사 도메인을 통한 피싱.

3.4 소프트웨어 공급망 및 라이브러리

이더리움 개발자는 종종 npm, crates.io 또는 GitHub과 같은 서비스에서 직접 가져온 오픈 소스 라이브러리에 의존합니다. 이러한 라이브러리가 손상되면 다음과 같은 공격의 벡터가 될 수 있습니다.

• 악성 패키지 주입, 공격자가 널리 사용되는 패키지를 손상시키거나 비슷한 이름으로 게시하는 경우
• 탈취된 종속성, 유지 관리자가 프로젝트에 대한 통제력을 잃고 악의적인 행위자가 유해한 코드를 도입하는 경우
• 개발자 손상, 설치된 패키지에 공격자가 개발자의 컴퓨터를 제어할 수 있는 코드가 포함된 경우.

3.5 프런트엔드 제공 서비스 및 관련 위험

많은 이더리움 애플리케이션은 콘텐츠 전송 네트워크(CDN) 또는 클라우드 기반 호스팅 플랫폼(예: Vercel, Netlify, Cloudflare)을 통해 프런트엔드를 제공합니다. 이러한 서비스가 손상되면 공격자가 사용자에게 변경된 프런트엔드를 제공하는 악의적인 자바스크립트 주입과 같은 공격의 벡터가 될 수 있습니다.

3.6 인터넷 서비스 공급자 수준 검열

인터넷 서비스 공급자(ISP) 또는 국가들은 기본 인터넷 인프라에 대한 통제권을 사용하여 이더리움에 대한 액세스를 검열할 수 있습니다. 예를 들어 이러한 공격에는 다음이 포함될 수 있습니다.

• 일반적인 이더리움 포트로의 트래픽 차단 또는 제한
• 이더리움 관련 서비스로 확인되는 DNS 요청 필터링
• 알려진 이더리움 노드에 대한 지오펜싱 또는 IP 차단
• 이더리움 프로토콜 관련 트래픽을 식별하고 검열하기 위한 심층 패킷 검사

이러한 기본적인 기술 중 다수는 이미 전 세계의 권위주의 정부가 정보, 시위 도구 또는 암호화폐에 대한 접근을 억압하는 데 사용되고 있습니다.

이더리움의 합의 프로토콜은 2015년 처음 출시된 이후 여러 업그레이드를 거치면서 다운타임 없이 실제로 견고함을 입증했습니다. 그러나 시스템을 더 탄력 있고 안전하게 만들기 위한 장기적인 개선 영역이 남아 있습니다.

4.1 합의 취약성 및 복구 위험

이더리움의 포크 선택 및 최종성 규칙은 복원력이 있지만 무적은 아닙니다. 장기간의 검증자 불일치, 클라이언트 버그 또는 네트워크 파티션과 같은 특정 엣지 케이스 조건에서는 합의가 중단되거나 일시적으로 분기될 수 있습니다. 극단적인 조건에서는 비활성 누출 또는 슬래싱을 통해 연쇄적인 검증자 페널티로 이어질 수 있으며, 이는 검증자로부터의 자본 유출로 이어질 수 있습니다.

4.2 클라이언트 다양성

이더리움의 업계 최고의 클라이언트 다양성은 단일 클라이언트의 버그로부터 네트워크를 보호합니다. 그러나 이러한 위험을 더욱 줄이기 위해 소수 클라이언트의 채택을 늘려 클라이언트 다양성을 더욱 개선할 수 있습니다.

4.3 스테이킹 중앙화 및 풀 지배력

상당한 양의 검증자 가중치가 유동 스테이킹 프로토콜, 커스터디 서비스 및 대규모 노드 운영자에 집중되어 있습니다. 이러한 집중은 다음과 같은 위험으로 이어질 수 있습니다.

• 거버넌스 장악 또는 영향력. 대량의 지분을 통제하는 주체(또는 해당 주체에 영향을 미칠 법적 권한이 있는 주체)가 함께 협력하면 제안되고 증명되는 블록에 과도한 영향을 미칠 수 있으며, 잠재적으로 사용자를 검열하거나 프로토콜 업그레이드에 영향을 미칠 수 있습니다.
• 클라이언트 선택 및 인프라 설정의 동질성으로, 이는 상호 관련된 실패 위험을 증가시킬 수 있습니다.

4.4 정의되지 않은 소셜 슬래싱 및 조정 격차

일부 극단적인 실패 모드에서 이더리움은 네트워크를 공격하기 위해 악의적으로 행동한 검증자를 처벌하기 위해 "소셜 슬래싱"에 의존할 것입니다(섹션 6.1 참조). 그러나 이러한 종류의 슬래싱을 위한 인프라, 규범 및 예상 프로세스는 미개발 상태입니다. 커뮤니티가 이 프로세스에 참여하기 위해 사용할 수 있는 확립된 메커니즘이 없습니다.

4.5 경제 및 게임 이론적 공격 벡터

많은 잠재적인 경제적 공격 벡터가 아직 연구되지 않았으며, 여기에는 다음이 포함됩니다.

• 그리핑 공격 또는 슬래시 그리핑. 검증자는 자신의 잘못이 아니라 공격자에게 순비용을 발생시키면서 다른 사람에게 해를 끼치려는 적대적인 행동으로 인해 비용이나 슬래싱 페널티를 받을 수 있습니다.
• 전략적 퇴장 또는 시간제 비활성. 검증자는 이익을 극대화하거나 최소한의 페널티로 합의를 방해하기 위해 중요한 시점에 의도적으로 오프라인 상태가 되거나 퇴장할 수 있습니다.
• 검증자 또는 릴레이 간의 공모. 검증자 간 또는 릴레이와 검증자 간의 조정된 행동은 탈중앙화를 감소시키거나 MEV를 추출할 수 있습니다.
• MEV, 제안자-빌더 분리 또는 유동 스테이킹 설계의 엣지 케이스 인센티브 악용. 행위자는 희귀한 프로토콜 조건을 조작하여 엄청난 보상을 얻을 수 있습니다.

4.6 양자 위험

이더리움의 핵심 암호학(예: secp256k1과 같은 타원 곡선 서명)은 언젠가 양자 컴퓨터에 의해 깨질 수 있습니다. 이것이 임박한 위험은 아니지만, 신뢰할 수 있는 위협은 기존 지갑, 계약 및 스테이킹 키를 즉시 취약하게 만들 수 있습니다. 이 미래의 과제는 사용자에 대한 이더리움의 장기적인 보장을 약화시킵니다.

양자 내성 암호화(예: 양자 후 서명 체계를 통해)로의 마이그레이션 경로는 필요하기 몇 년 전에 설계, 테스트 및 프로토콜에 포함되어야 합니다. 이더리움 재단을 포함한 이더리움 생태계 전반의 조직들은 이러한 옵션을 적극적으로 탐색하고 위험을 모니터링하고 있습니다.

이상적인 블록체인 생태계라도 위험, 공격 및 취약점이 있을 것입니다. 문제가 발생하면 완화, 탐지 및 대응하기 위한 효과적인 시스템이 있어야 합니다. 여기에는 다음과 같은 과제가 포함됩니다.

• 영향을 받은 팀에 연락하기. 애플리케이션이 손상된 팀과 연락하기 어려울 수 있습니다. 이로 인해 몇 시간의 지연이 발생하여 대응자가 자금을 회수하는 능력이 제한될 수 있습니다.
• 관련 조직에서 문제 확대. 문제가 플랫폼(예: 소셜 네트워크 또는 중앙화 거래소)과 관련된 경우, 대응자가 기존 연락처가 없으면 문제를 확대하기 어려울 수 있습니다.
• 대응 조정. 영향을 받은 애플리케이션을 지원하는 사고 대응 팀이 몇 개인지 명확하지 않은 경우가 많아, 그룹 노력이 더 효과적이었을 수 있는 경우에도 의사소통 오류나 낭비된 노력을 초래할 수 있습니다.
• 모니터링 기능 부족. 온체인 및 오프체인 문제를 모니터링하기 어려울 수 있으며, 이는 조기 경고를 제공하고 위협에 대한 신속한 대응을 보장합니다.
• 보험 가입. 보험은 돈, 금융 시스템, 신원 및 기타 귀중한 정보를 다루는 대부분의 전통적인 시스템에서 손실을 완화하는 데 필수적인 도구입니다. 그러나 오늘날 암호화폐 생태계를 위해 전통적인 금융 서비스에서 사용할 수 있는 보험 옵션은 거의 없습니다.

이러한 위험은 장기적인 경향이 있으며, 개별 사용자나 애플리케이션의 보안보다는 이더리움 전체에 관한 것입니다.

6.1 지분 중앙화

대량의 지분 중앙화는 해당 지분을 통제하는 주체가 공모하기로 결정할 경우 이더리움 전체에 위험을 초래할 수 있습니다.
이러한 경제적 중앙화는 사회적 거버넌스 장악의 가능성을 만듭니다. 소수의 검증자 그룹이 지분의 과반수를 통제하면 다음과 같은 일을 할 수 있습니다.

• 포크에 대해 협력하거나 저항합니다.
• 특정 거래 또는 계약을 검열합니다.
• 퇴장이나 반대를 위협하여 커뮤니티 합의를 약화시킵니다.

이 극단적인 시나리오가 발생하면 이더리움 커뮤니티는 "소셜 슬래싱"이 답이 될 수 있다고 제안했습니다. 소셜 슬래싱은 잘못 행동하는 검증자를 슬래싱하기로 결정하기 위해 오프체인 사회적 합의를 사용하는 것으로, 그들의 권력에 대한 견제 역할을 합니다. 그러나 그러한 조치를 시행하기 위한 명확한 규범, 절차 또는 툴링은 존재하지 않습니다(섹션 4.4 참조).

6.2 오프체인 자산 중앙화

이더리움은 상당한 양의 실물 자산을 호스팅하며, 자산은 은행 계좌나 기타 예금에 오프체인으로 보관된 후 오프체인 자산에 대한 청구권을 나타내는 토큰을 통해 온체인에서 거래됩니다. 예를 들어, 많은 대형 스테이블코인이 이런 방식으로 작동합니다.

오프체인 예금을 보유한 기관은 이더리움 생태계에 영향력을 행사할 수 있습니다. 예를 들어, 논쟁적인 포크나 네트워크 업그레이드가 있는 극단적인 시나리오 동안, 대규모 예금자는 한 체인 또는 다른 체인의 토큰만 인정하기로 선택함으로써 어떤 체인이 널리 받아들여질지에 영향을 미칠 수 있습니다.

6.3 규제 공격 또는 압력

정부와 규제 기관은 이더리움 스택의 중요한 구성 요소를 통제하는 다양한 주체에게 이더리움 프로토콜을 검열하거나 다른 방식으로 간섭하도록 압력을 가할 수 있습니다. 이더리움의 기관 사용자도 이러한 압력의 영향을 받을 수 있으며, 이는 사용자에게 추가적인 결과를 초래할 수 있습니다(예: 규제 금지로 인해 특정 암호화폐 제품을 더 이상 제공할 수 없는 은행).

6.4 조직의 거버넌스 장악

이더리움의 오픈 소스 거버넌스 및 개발 프로세스는 핵심 클라이언트 소프트웨어, 인프라 및 툴링을 유지 관리하는 다양하고 글로벌한 팀과 회사에 의해 주도됩니다.

다양한 형태의 영향력(기업 인수, 자금 의존성, 핵심 기여자의 고용, 기존 조직 내의 이해 상충)은 이더리움 거버넌스의 문화와 우선순위를 점차적으로 변화시킬 수 있습니다. 이는 커뮤니티 중심의 정신과 확립된 로드맵에서 벗어난 특정 상업적 또는 외부적 이해관계와의 일치로 이어져 시간이 지남에 따라 이더리움의 중립성과 회복력을 약화시킬 수 있습니다.