본문으로 건너뛰기

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

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

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

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

노드 저장 공간 줄이기

각 노드가 저장해야 하는 데이터의 양을 줄이는 방법에는 여러 가지가 있으며, 각각 이더리움의 핵심 프로토콜을 다른 수준으로 업데이트해야 합니다.

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

데이터 만료

기록 만료

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

한 가지 옵션은 클라이언트가 포털 네트워크와 같은 솔루션을 사용하여 피어에게 과거 데이터를 요청하는 것입니다. 포털 네트워크는 과거 데이터를 제공하기 위해 개발 중인 피어 투 피어 네트워크로, 각 노드가 이더리움 기록의 작은 부분을 저장하여 전체 기록이 네트워크 전체에 분산되어 존재하도록 합니다. 관련 데이터를 저장하고 있는 피어를 찾아 데이터를 요청함으로써 요청이 처리됩니다. 대안으로, 과거 데이터에 대한 접근을 필요로 하는 것은 일반적으로 앱이므로 이를 저장하는 것이 앱의 책임이 될 수 있습니다. 이더리움 생태계에는 과거 아카이브를 기꺼이 유지하려는 이타적인 참여자가 충분히 있을 수도 있습니다. 과거 데이터 저장을 관리하기 위해 구성된 DAO일 수도 있으며, 이상적으로는 이 모든 옵션의 조합이 될 것입니다. 이러한 제공자는 토렌트, FTP, 파일코인 또는 IPFS와 같은 다양한 방식으로 데이터를 제공할 수 있습니다.

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

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

이 업그레이드는 이더리움 노드가 상태 데이터를 처리하는 방식을 근본적으로 변경하지 않으며, 단지 과거 데이터에 접근하는 방식을 변경할 뿐입니다.

상태 만료

상태 만료는 최근에 접근되지 않은 상태를 개별 노드에서 제거하는 것을 의미합니다. 이를 구현하는 방법에는 다음을 포함하여 여러 가지가 있습니다.

  • 임대료에 의한 만료: 계정에 "임대료"를 청구하고 임대료가 0이 되면 만료시킵니다.
  • 시간에 의한 만료: 일정 시간 동안 해당 계정에 대한 읽기/쓰기가 없으면 계정을 비활성화합니다.

임대료에 의한 만료는 계정을 활성 상태 데이터베이스에 유지하기 위해 계정에 직접 임대료를 청구하는 방식일 수 있습니다. 시간에 의한 만료는 마지막 계정 상호작용부터 카운트다운을 하거나 모든 계정을 주기적으로 만료시키는 방식일 수 있습니다. 시간 기반 모델과 임대료 기반 모델의 요소를 결합한 메커니즘도 있을 수 있습니다. 예를 들어, 개별 계정이 시간 기반 만료 전에 소액의 수수료를 지불하면 활성 상태를 유지하는 방식입니다. 상태 만료와 관련하여 중요한 점은 비활성 상태가 삭제되는 것이 아니라 활성 상태와 분리되어 저장된다는 것입니다. 비활성 상태는 활성 상태로 부활할 수 있습니다.

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

기록 만료와 마찬가지로 상태 만료 하에서는 오래된 상태 데이터를 저장할 책임이 개별 사용자에게서 제거되고 중앙화된 제공자, 이타적인 커뮤니티 구성원 또는 포털 네트워크와 같은 보다 미래지향적인 탈중앙화된 솔루션 등 다른 주체에게 전가됩니다.

상태 만료는 아직 연구 단계에 있으며 출시될 준비가 되지 않았습니다. 무상태 클라이언트와 기록 만료 업그레이드가 대다수의 검증자가 큰 상태 크기를 쉽게 관리할 수 있게 해주기 때문에, 상태 만료는 이러한 업그레이드보다 나중에 이루어질 가능성이 높습니다.

무상태성

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

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

약한 무상태성

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

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

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

무상태성은 블록 빌더가 블록을 검증하는 데 사용할 수 있는 증거를 생성할 수 있도록 전체 상태 데이터의 복사본을 유지하는 것에 의존합니다. 다른 노드는 상태 데이터에 접근할 필요가 없으며, 블록을 검증하는 데 필요한 모든 정보는 증거에서 얻을 수 있습니다. 이로 인해 블록을 제안하는 것은 비용이 많이 들지만 블록을 검증하는 것은 저렴해지는 상황이 발생하며, 이는 블록 제안 노드를 운영하는 운영자가 줄어들 것임을 암시합니다. 그러나 가능한 한 많은 참여자가 제안된 블록이 유효한지 독립적으로 검증할 수 있는 한 블록 제안자의 탈중앙화는 중요하지 않습니다.

Dankrad의 노트에서 자세히 알아보기 (opens in a new tab)

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

약한 무상태성은 연구가 상당히 진전된 상태이지만, 작은 증거가 피어 간에 전달될 수 있도록 제안자-빌더 분리 (PBS)와 버클 트리가 구현되어 있어야 합니다. 이는 약한 무상태성이 이더리움 메인넷에 도입되기까지 아마도 몇 년이 더 걸릴 것임을 의미합니다.

레이어 1 (l1) 검증을 위한 zkEVM은 무상태 검증을 더욱 향상시킬 수 있는 보완 기술입니다. 검증자는 단순히 증거를 확인하는 대신 전체 블록이 올바르게 실행되었다는 영지식 증명을 검증하여 트랜잭션을 다시 실행하지 않고도 암호학적 확실성을 제공할 수 있습니다.

강한 무상태성

강한 무상태성은 어떤 노드도 상태 데이터를 저장할 필요성을 제거합니다. 대신, 트랜잭션은 블록 생성자가 집계할 수 있는 증거와 함께 전송됩니다. 그런 다음 블록 생성자는 관련 계정에 대한 증거를 생성하는 데 필요한 상태만 저장할 책임이 있습니다. 사용자가 상호작용하는 계정과 저장소 키를 선언하기 위해 증거와 '접근 목록(access lists)'을 전송함에 따라 상태에 대한 책임은 거의 전적으로 사용자에게 이동합니다. 이를 통해 매우 가벼운 노드가 가능해지지만, 스마트 컨트랙트와 트랜잭션을 수행하기가 더 어려워지는 등의 절충안(tradeoffs)이 있습니다.

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

현재 진행 상황

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

더 읽어보기