메인 콘텐츠로 건너뛰기

페이지가 마지막으로 업데이트됨: 2026년 2월 23일

무상태성, 상태 만료, 기록 만료

보통 사양의 하드웨어에서 이더리움 노드를 실행하는 기능은 진정한 탈중앙화를 위해 매우 중요합니다. 노드를 실행하면 사용자가 제3자가 제공하는 데이터를 신뢰하는 대신 독립적으로 암호화 검사를 수행하여 정보를 검증할 수 있기 때문입니다. 노드를 실행하면 사용자는 중개자를 신뢰할 필요 없이 이더리움 P2P 네트워크에 직접 트랜잭션을 제출할 수 있습니다. 이러한 혜택이 고가의 하드웨어를 가진 사용자에게만 제공된다면 탈중앙화는 불가능합니다. 대신, 노드는 휴대폰, 마이크로컴퓨터 또는 가정용 컴퓨터에서 눈에 띄지 않게 실행할 수 있도록 매우 낮은 처리 및 메모리 요구사항으로 실행할 수 있어야 합니다.

오늘날 높은 디스크 공간 요구사항은 노드에 대한 보편적인 접근을 막는 주요 장벽입니다. 이는 주로 이더리움 상태 데이터의 큰 덩어리를 저장해야 하기 때문입니다. 이 상태 데이터에는 새로운 블록과 트랜잭션을 올바르게 처리하는 데 필요한 중요한 정보가 포함되어 있습니다. 이 글을 쓰는 시점에서 전체 이더리움 노드를 실행하려면 빠른 2TB SSD가 권장됩니다. 이전 데이터를 정리하지 않는 노드의 경우 저장 공간 요구사항은 주당 약 14GB씩 증가하며, 제네시스 이후의 모든 데이터를 저장하는 아카이브 노드는 12TB에 육박하고 있습니다(2023년 2월 기준).

더 저렴한 하드 드라이브를 사용하여 이전 데이터를 저장할 수 있지만, 들어오는 블록을 따라잡기에는 너무 느립니다. 이더리움의 상태 증가는 '무한'하기 때문에 데이터를 더 저렴하고 쉽게 저장하면서 클라이언트를 위한 현재 저장 공간 모델을 유지하는 것은 문제에 대한 일시적이고 부분적인 해결책일 뿐입니다. 즉, 저장 공간 요구사항은 계속 증가할 수밖에 없으며 기술 발전은 항상 지속적인 상태 증가와 보조를 맞춰야 합니다. 대신, 클라이언트는 로컬 데이터베이스에서 데이터를 조회하는 데 의존하지 않는 블록 및 트랜잭션 검증을 위한 새로운 방법을 찾아야 합니다.

노드의 저장 공간 줄이기

각 노드가 저장해야 하는 데이터의 양을 줄이는 몇 가지 방법이 있으며, 각 방법은 이더리움 코어 프로토콜을 서로 다른 정도로 업그레이드해야 합니다.

  • 기록 만료: 노드가 X 블록보다 오래된 상태 데이터를 폐기할 수 있도록 하지만, 이더리움 클라이언트가 상태 데이터를 처리하는 방식은 변경하지 않습니다.
  • 상태 만료: 자주 사용되지 않는 상태 데이터가 비활성화되도록 허용합니다. 비활성 데이터는 부활할 때까지 클라이언트에 의해 무시될 수 있습니다.
  • 약한 무상태성: 블록 생산자만 전체 상태 데이터에 접근할 필요가 있으며, 다른 노드는 로컬 상태 데이터베이스 없이 블록을 검증할 수 있습니다.
  • 강한 무상태성: 어떤 노드도 전체 상태 데이터에 접근할 필요가 없습니다.

데이터 만료

기록 만료

기록 만료는 클라이언트가 필요하지 않을 것 같은 오래된 데이터를 제거하여 소량의 기록 데이터만 저장하고 새 데이터가 도착하면 오래된 데이터를 삭제하는 것을 의미합니다. 클라이언트가 기록 데이터를 요구하는 데는 동기화와 데이터 요청 처리라는 두 가지 이유가 있습니다. 원래 클라이언트는 제네시스 블록부터 동기화하여 체인의 헤드까지 각 후속 블록이 올바른지 확인해야 했습니다. 오늘날 클라이언트는 "약한 주관성 체크포인트"를 사용하여 체인의 헤드까지 부트스트랩합니다. 이러한 체크포인트는 이더리움의 맨 처음이 아닌 현재에 가까운 제네시스 블록을 갖는 것과 같은 신뢰할 수 있는 시작점입니다. 이는 클라이언트가 체인의 헤드와 동기화하는 기능을 잃지 않고 가장 최근의 약한 주관성 체크포인트 이전의 모든 정보를 삭제할 수 있음을 의미합니다. 클라이언트는 현재 로컬 데이터베이스에서 기록 데이터를 가져와 (JSON-RPC를 통해 도착하는) 요청을 처리합니다. 그러나 기록 만료가 적용되면 요청된 데이터가 정리된 경우 이는 불가능합니다. 이러한 기록 데이터를 제공하는 데 몇 가지 혁신적인 솔루션이 필요합니다.

한 가지 옵션은 클라이언트가 Portal Network와 같은 솔루션을 사용하여 피어로부터 기록 데이터를 요청하는 것입니다. Portal Network는 기록 데이터를 제공하기 위해 개발 중인 P2P 네트워크로, 각 노드는 이더리움 기록의 작은 부분을 저장하여 전체 기록이 네트워크에 분산되어 존재하도록 합니다. 관련 데이터를 저장하는 피어를 찾아 요청하는 방식으로 요청이 처리됩니다. 또는, 일반적으로 기록 데이터에 대한 접근이 필요한 것은 앱이므로, 이를 저장하는 것이 앱의 책임이 될 수 있습니다. 이더리움 공간에는 기꺼이 기록 아카이브를 유지하려는 이타적인 행위자가 충분히 있을 수도 있습니다. 기록 데이터 저장 공간을 관리하기 위해 DAO가 만들어질 수도 있고, 이상적으로는 이 모든 옵션의 조합이 될 것입니다. 이러한 공급자는 토렌트, FTP, Filecoin 또는 IPFS와 같은 여러 가지 방법으로 데이터를 제공할 수 있습니다.

지금까지 이더리움은 항상 모든 기록 데이터의 가용성을 암묵적으로 보장해왔기 때문에 기록 만료는 다소 논란의 여지가 있습니다. 스냅샷에서 일부 오래된 데이터를 재구성하는 데 의존하더라도 제네시스로부터의 전체 동기화는 항상 표준으로 가능했습니다. 기록 만료는 이 보증을 제공할 책임을 이더리움 코어 프로토콜 외부로 옮깁니다. 만약 중앙화된 조직이 결국 기록 데이터를 제공하게 된다면, 이는 새로운 검열 위험을 초래할 수 있습니다.

EIP-4444는 아직 배포 준비가 되지 않았지만, 활발하게 논의 중입니다. 흥미롭게도 EIP-4444의 과제는 기술적인 것보다 주로 커뮤니티 관리에 있습니다. 이를 배포하려면 합의뿐만 아니라 신뢰할 수 있는 주체로부터 기록 데이터를 저장하고 제공하겠다는 약속을 포함하는 커뮤니티의 동의가 필요합니다.

이 업그레이드는 이더리움 노드가 상태 데이터를 처리하는 방식을 근본적으로 바꾸지 않고, 기록 데이터에 접근하는 방식만 변경합니다.

상태 만료

상태 만료는 최근에 접근하지 않은 경우 개별 노드에서 상태를 제거하는 것을 의미합니다. 이를 구현할 수 있는 몇 가지 방법은 다음과 같습니다.

  • 렌트료에 의한 만료: 계정에 "렌트료"를 부과하고 렌트료가 0이 되면 만료시킵니다.
  • 시간에 의한 만료: 일정 시간 동안 해당 계정에 대한 읽기/쓰기가 없는 경우 계정을 비활성으로 만듭니다.

렌트료에 의한 만료는 계정을 활성 상태 데이터베이스에 유지하기 위해 계정에 부과되는 직접적인 렌트료일 수 있습니다. 시간에 의한 만료는 마지막 계정 상호 작용으로부터의 카운트다운에 의하거나, 모든 계정의 주기적인 만료일 수 있습니다. 시간 기반 및 렌트료 기반 모델의 요소를 결합하는 메커니즘도 있을 수 있습니다. 예를 들어, 개별 계정은 시간 기반 만료 전에 소액의 수수료를 지불하면 활성 상태로 유지됩니다. 상태 만료의 경우 비활성 상태는 삭제되지 않고 활성 상태와 별도로 저장된다는 점에 유의하는 것이 중요합니다. 비활성 상태는 활성 상태로 부활될 수 있습니다.

이것이 작동하는 방식은 아마도 특정 기간(아마도 1년 정도) 동안의 상태 트리를 갖는 것일 겁니다. 새로운 기간이 시작될 때마다 완전히 새로운 상태 트리도 시작됩니다. 현재 상태 트리만 수정할 수 있으며 다른 모든 트리는 불변입니다. 이더리움 노드는 현재 상태 트리와 바로 이전의 상태 트리만 보유할 것으로 예상됩니다. 이를 위해서는 주소가 존재하는 기간으로 주소에 타임스탬프를 찍는 방법이 필요합니다. 이를 수행하는 몇 가지 가능한 방법 (opens in a new tab)이 있지만, 주된 옵션은 추가 정보를 수용하기 위해 주소 길이를 확장 (opens in a new tab)해야 하며, 주소가 길어지면 보안이 훨씬 강화된다는 이점이 있습니다. 이를 수행하는 로드맵 항목은 주소 공간 확장 (opens in a new tab)이라고 합니다.

기록 만료와 유사하게, 상태 만료 하에서는 오래된 상태 데이터를 저장할 책임이 개별 사용자에게서 제거되어 중앙화된 제공업체, 이타적인 커뮤니티 구성원 또는 Portal Network와 같은 더 미래적인 탈중앙화 솔루션과 같은 다른 주체에게로 넘어갑니다.

상태 만료는 아직 연구 단계이며 배포 준비가 되지 않았습니다. 상태 만료는 무상태 클라이언트 및 기록 만료보다 늦게 이루어질 수 있는데, 이는 해당 업그레이드를 통해 대부분의 검증자가 대규모 상태 크기를 쉽게 관리할 수 있기 때문입니다.

무상태성

무상태성은 "상태"라는 개념이 제거된다는 의미가 아니기 때문에 다소 부적절한 명칭이지만, 이더리움 노드가 상태 데이터를 처리하는 방식의 변경을 포함합니다. 무상태성 자체는 약한 무상태성과 강한 무상태성의 두 가지 종류가 있습니다. 약한 무상태성은 상태 저장 공간에 대한 책임을 소수에게 부여함으로써 대부분의 노드가 무상태가 될 수 있도록 합니다. 강한 무상태성은 어떤 노드도 전체 상태 데이터를 저장할 필요를 완전히 제거합니다. 약한 무상태성과 강한 무상태성 모두 일반 검증자에게 다음과 같은 이점을 제공합니다.

  • 거의 즉각적인 동기화
  • 순서에 상관없이 블록을 검증하는 기능
  • 매우 낮은 하드웨어 요구사항(예: 휴대폰)으로 실행 가능한 노드
  • 디스크 읽기/쓰기가 필요하지 않기 때문에 저렴한 하드 드라이브에서 노드를 실행할 수 있습니다.
  • 이더리움 암호학의 향후 업그레이드와 호환 가능

약한 무상태성

약한 무상태성은 이더리움 노드가 상태 변경을 확인하는 방식의 변경을 포함하지만 네트워크의 모든 노드에서 상태 저장 공간의 필요성을 완전히 제거하지는 않습니다. 대신, 약한 무상태성은 상태 저장 공간에 대한 책임을 블록 제안자에게 부여하고, 네트워크의 다른 모든 노드는 전체 상태 데이터를 저장하지 않고 블록을 검증합니다.

약한 무상태성에서는 블록을 제안하려면 전체 상태 데이터에 대한 접근이 필요하지만 블록을 검증하는 데는 상태 데이터가 필요하지 않습니다.

이를 위해서는 이더리움 클라이언트에 버클 트리가 이미 구현되어 있어야 합니다. 버클 트리는 이더리움 상태 데이터를 저장하기 위한 대체 데이터 구조로, 로컬 데이터베이스에 대해 블록을 검증하는 대신 피어 간에 데이터에 대한 작고 고정된 크기의 "증인"을 전달하고 블록을 검증하는 데 사용할 수 있도록 합니다. 제안자-빌더 분리도 필요합니다. 이를 통해 블록 빌더가 더 강력한 하드웨어를 갖춘 특수 노드가 될 수 있으며, 이들이 전체 상태 데이터에 대한 접근이 필요한 노드이기 때문입니다.

블록 제안자는 상태 데이터를 사용하여 블록의 트랜잭션에 의해 변경되는 상태의 값을 증명하는 최소한의 데이터 세트인 "증인"을 생성합니다. 다른 검증자는 상태를 보유하지 않고 상태 루트(전체 상태의 해시)만 저장합니다. 그들은 블록과 증인을 받아 상태 루트를 업데이트하는 데 사용합니다. 이는 검증 노드를 매우 가볍게 만듭니다.

약한 무상태성은 고급 연구 단계에 있지만, 작은 증인이 피어 간에 전달될 수 있도록 제안자-빌더 분리 및 버클 트리가 구현되는 것에 의존합니다. 이는 약한 무상태성이 이더리움 메인넷에 적용되기까지 아마 몇 년이 걸릴 것임을 의미합니다.

강한 무상태성

강한 무상태성은 어떤 노드도 상태 데이터를 저장할 필요를 제거합니다. 대신, 트랜잭션은 블록 생산자가 집계할 수 있는 증인과 함께 전송됩니다. 그런 다음 블록 생산자는 관련 계정에 대한 증인을 생성하는 데 필요한 상태만 저장할 책임이 있습니다. 상태에 대한 책임은 거의 전적으로 사용자에게 이전됩니다. 사용자는 증인과 '액세스 목록'을 보내 상호 작용하는 계정 및 저장 공간 키를 선언합니다. 이는 매우 가벼운 노드를 가능하게 하지만, 스마트 계약과의 거래를 더 어렵게 만드는 것을 포함한 장단점이 있습니다.

강한 무상태성은 연구자들이 조사했지만 현재 이더리움 로드맵의 일부가 될 것으로 예상되지는 않습니다. 약한 무상태성이 이더리움의 확장 요구사항에 충분할 가능성이 더 높습니다.

현재 진행 상황

약한 무상태성, 기록 만료 및 상태 만료는 모두 연구 단계에 있으며 지금으로부터 몇 년 후에 배포될 것으로 예상됩니다. 이 모든 제안이 구현될 것이라는 보장은 없습니다. 예를 들어, 상태 만료가 먼저 구현되면 기록 만료를 함께 구현할 필요가 없을 수도 있습니다. 또한 버클 트리 및 제안자-빌더 분리와 같이 먼저 완료해야 할 다른 로드맵 항목도 있습니다.

더 읽어보기

페이지 마지막 업데이트됨: 2026년 2월 23일

mnelsonBTm (opens in a new tab)
pete-vielhaberp (opens in a new tab)
corwintinesc (opens in a new tab)
+10

이 문서가 도움이 되셨나요?