보안 과제 개요

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

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

이러한 각 요구 사항은 키 손상 또는 분실, 성급하거나 정보가 부족한 승인, 또는 사용자가 이더리움과 상호 작용할 때 정보를 얻고 안내를 받기 위해 의존하는 지갑 소프트웨어의 손상과 같은 위험을 초래합니다.

1.1 키 관리

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

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

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

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

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

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

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

1.3 승인 및 권한 관리

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

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

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

이는 조직 사용자에게도 동일한 위험입니다. 예를 들어, 조직은 운영상의 편의를 위해 DEX 라우터에 무제한 USDC 허용량을 부여하기로 선택할 수 있으며, 이는 라우터 컨트랙트가 업그레이드될 경우 위험에 노출됩니다.

1.4 손상된 웹 인터페이스

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

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

1.5 프라이버시

프라이버시는 모든 유형의 사용자에 대한 보안 위험을 완화하거나 확대할 수 있습니다.

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

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

1.6 파편화

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

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

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

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

그러나 이 영역에는 여전히 약점과 개선해야 할 부분이 남아 있습니다.

2.1 컨트랙트 취약점

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

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

2.2 개발자 경험, 도구 및 프로그래밍 언어

취약점은 개발자의 실수로 인해 배포된 코드에 남게 됩니다. 개선된 개발자 도구 덕분에 안전한 스마트 컨트랙트를 배포하는 것이 훨씬 쉬워졌습니다. 그러나 문제는 여전히 남아 있습니다.

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

2.3 온체인 코드의 위험 평가

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

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

3.1 레이어 2 (l2) 체인

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

• 다중 홉 브리지 자산의 복잡성. 자산이 레이어 1 (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)을 통해 프런트엔드를 제공합니다. 이러한 서비스가 손상되면 공격자가 사용자에게 변경된 프런트엔드를 제공하는 악성 JavaScript 주입과 같은 공격의 매개체가 될 수 있습니다.

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

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

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

이러한 기본 기술 중 상당수는 오늘날 전 세계의 권위주의 정부에서 정보, 시위 도구 또는 암호화폐에 대한 접근을 억압하기 위해 이미 사용하고 있습니다.

이더리움의 합의 프로토콜은 2015년 처음 출시된 이후 여러 차례의 업그레이드를 거치면서 가동 중지 시간이 전혀 없이 실제로 견고함이 입증되었습니다. 그러나 시스템을 더욱 탄력적이고 안전하게 만들기 위해 장기적으로 개선해야 할 영역이 남아 있습니다.

4.1 합의 취약성 및 복구 위험

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

4.2 클라이언트 다양성

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

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

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

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

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

일부 극단적인 실패 모드에서 이더리움은 네트워크를 공격하기 위해 악의적으로 행동한 검증자에게 페널티를 주기 위해 "소셜 슬래싱"에 의존하게 됩니다(6.1절 참조). 그러나 이러한 종류의 슬래싱에 대한 인프라, 규범 및 예상 프로세스는 아직 개발되지 않았습니다. 커뮤니티가 이 프로세스에 참여하는 데 사용할 확립된 메커니즘이 없습니다.

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

다양한 잠재적 경제적 공격 벡터에 대한 연구가 아직 부족합니다. 여기에는 다음이 포함됩니다.

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

4.6 양자 위험

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

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

이상적인 블록체인 생태계에도 위험, 공격 및 취약점은 존재합니다. 문제가 발생했을 때 이를 완화, 감지 및 대응할 수 있는 효과적인 시스템이 있어야 합니다. 여기에는 다음과 같은 과제가 포함됩니다.

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

이러한 위험은 개별 사용자나 애플리케이션의 보안보다는 이더리움 전체와 관련된 장기적인 성격을 띠는 경향이 있습니다.

6.1 스테이크 중앙화

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

• 포크를 조정하거나 저항합니다.
• 특정 트랜잭션이나 컨트랙트를 검열합니다.
• 종료 또는 반대를 위협하여 커뮤니티 합의를 훼손합니다.

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

6.2 오프체인 자산 중앙화

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

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

6.3 규제 공격 또는 압력

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

6.4 거버넌스의 조직적 장악

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

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