저자: 웨이 한 응, 카를로스 페레스, 무국가 합의 연구팀; 번역: 진써차이징(Jinse)
이더 작고 실험적인 네트워크에서 시작하여 이제는 글로벌 인프라의 핵심 구성 요소로 성장했습니다. 매일 수십억 달러 규모의 거래를 처리하고, 수천 개의 애플리케이션을 통합하며, 전체 레이어 2(L2) 네트워크 생태계의 기반이 됩니다.
궁극적으로 이 모든 것은 핵심적인 기본 요소인 상태 에 달려 있습니다.
1. " 국가 " 란 무엇이며, 그 중요성은 무엇인가?
사용자의 잔액 지갑에 저장되는 것이 아니라 이더 상태에 저장됩니다. 상태는 대략적으로 "이더 현재 알고 있는 모든 것"으로 이해할 수 있습니다. 여기에는 계정, 컨트랙트 저장소(컨트랙트에 기록된 모든 데이터), 바이트코드(스마트 컨트랙트 사용 시 실행되는 로직) 등이 포함됩니다.
상태는 거의 모든 기능의 기반입니다.
지갑은 이를 통해 잔액 과 과거 거래 내역을 표시합니다.
탈중앙화 애플리케이션(DApps)은 보유 포지션, 주문 또는 메시지를 파악하기 위해 해당 시스템에 쿼리를 보냅니다.
인프라(블록체인 익스플로러, 크로스체인 브리지, 인덱서 등)는 상태를 지속적으로 읽어 그 위에 서비스를 제공합니다.
국가가 지나치게 커지거나, 지나치게 중앙집권화되거나, 서비스를 제공할 수 없게 되면, 위의 모든 계층이 더욱 취약해지고, 비용이 많이 들며, 탈중앙화 더욱 어려워질 것입니다.
2. L1 확장은 그에 따른 결과를 초래할 것입니다.
이더 수년간 네트워크 확장을 위해 노력해 왔습니다. 레이어 2 네트워크, EIP-4844, 가스 한도 증액, 가스 수수료 재조정, 그리고 제안자와 빌더 분리 메커니즘 도입 등이 그 예입니다. 이러한 각 단계는 네트워크 처리 용량을 향상시켰지만, 동시에 새로운 과제도 야기했습니다.
과제 1: 운동량의 지속적인 확장
이더 의 상태 크기는 증가만 하며 절대 감소하지 않습니다. 모든 새로운 계정 생성, 스토리지 작업 및 바이트코드 쓰기는 네트워크가 보존해야 하는 데이터에 영구적으로 추가됩니다.
이로 인해 다음과 같은 구체적인 비용이 발생합니다.
검증자 및 전체 노드는 더 많은 데이터를 저장해야 합니다. 상태 크기가 증가함에 따라 데이터베이스는 추가적인 작업 부하를 처리해야 하므로 효율성이 그에 따라 감소합니다.
RPC 서비스 제공업체는 완전한 접근성을 유지해야 하며, 언제든지 모든 계정이나 저장된 데이터를 조회할 수 있도록 보장해야 합니다.
상태 증가로 인해 노드 동기화 속도가 느려지고 안정성이 저하됩니다.
가스 한도를 늘리면 각 블록이 더 많은 쓰기 작업을 수용할 수 있게 되어 상태 크기가 더욱 커집니다. 다른 퍼블릭 블록체인들도 이미 이러한 문제를 경험했습니다. 상태 크기가 커질수록 일반 사용자가 풀 노드를 운영하기 어려워지고, 결과적으로 상태 데이터가 소수의 대형 서비스 제공업체에 집중되는 현상이 발생합니다.
이더 에서는 대부분의 블록이 이미 전문 블록 생성자에 의해 생성됩니다. 핵심적인 문제는 중요한 순간에 얼마나 많은 독립적인 주체가 처음부터 끝까지 블록 생성을 완료할 수 있느냐는 것입니다. 만약 극소수의 참여자만이 완전한 상태를 저장하고 제공할 수 있다면, 검열 저항성과 신뢰 중립성이 훼손될 것입니다. 왜냐하면 검열된 거래를 포함하는 블록을 생성할 수 있는 주체가 줄어들기 때문입니다.
긍정적인 측면 중 하나는 FOCIL 및 VOPS와 같은 메커니즘이 전문 개발자 생태계 내에서 검열 저항성을 확보하는 것을 목표로 한다는 점입니다. 그러나 이러한 메커니즘의 효과는 노드들이 합리적인 비용으로 상태 데이터에 접근, 저장 및 제공할 수 있는 건전한 노드 생태계에 달려 있습니다. 따라서 상태 증가를 제어하는 것은 선택 사항이 아니라 필수 전제 조건입니다.
문제의 핵심 지점을 파악하기 위해 현재 스트레스 테스트를 적극적으로 진행하고 있습니다.
국가 성장세가 언제 규모 확장의 병목 현상이 되는가?
상태 크기가 너무 커서 노드가 체인 헤드를 따라가기 어려워지는 경우는 언제입니까?
클라이언트 구현은 상태 규모가 극단적으로 커질 때 언제 실패합니까?
과제 2: 상태 비저장 아키텍처에서 상태를 저장하고 제공하는 책임은 누구에게 있습니까?
이더 현재의 가스 한도를 영구적으로 유지하더라도 결국에는 상태 비대화 문제에 직면하게 될 것입니다. 한편, 커뮤니티는 분명히 더 높은 처리량을 기대하고 있습니다.
상태 비저장 방식은 주요 제약 조건을 해결합니다. 검증자는 블록 검증을 위해 전체 상태를 보유할 필요 없이 증명만 보유하면 됩니다. 이는 확장성 측면에서 획기적인 발전이며, 더 높은 처리량에 대한 커뮤니티의 요구를 충족하는 동시에, 상태 저장이 각 검증자에 종속되는 것이 아니라 독립적이고 전문화된 기능으로 발전할 수 있다는 기존의 암묵적인 사실을 드러냅니다.
그 당시에는 대부분의 상태 정보가 다음과 같은 주체들에 의해서만 저장될 수 있었습니다.
블록 쌓기;
RPC 서비스 제공업체;
기타 전문 운영자(예: MEV 검색기 및 블록체인 익스플로러).
다시 말해, 국가는 더욱 중앙집권화될 것이다.
이는 여러 가지 결과를 초래할 것입니다.
동기화가 더욱 어려워집니다. 중앙 집중식 서비스 제공업체가 상태 정보 접근을 제한하기 시작하면 새로운 서비스 제공업체가 사업을 시작하기 어려워질 수 있습니다.
검열에 대한 저항력 약화: 검열 대상의 현황 데이터를 확보할 수 없는 경우, FOCIL과 같은 검열 방지 메커니즘이 무력화될 수 있다.
시스템 복원력 리스크: 소수의 구성 요소만이 완전한 상태 정보를 저장하고 제공하는 경우, 서비스 중단이나 외부 스트레스로 인해 생태계의 대부분 구성 요소에 대한 접근이 빠르게 차단될 수 있습니다.
많은 주체들이 상태를 저장하고 있지만, 실제로 서비스를 제공하고 있는지 검증할 효과적인 방법이 부족하고, 기존의 인센티브도 불충분합니다. 스냅샷 동기화는 기본적으로 널리 지원되지만, RPC 서비스의 경우는 그렇지 않습니다. 상태 서비스의 비용이 절감되고 그 활용도가 높아지지 않는 한, 네트워크가 자체 상태에 접근할 수 있는 능력은 소수의 서비스 제공업체에만 국한될 것입니다.
이 문제는 레이어 2 네트워크에도 영향을 미칩니다. 사용자가 트랜잭션 패키징을 강제할 수 있는 기능은 레이어 1의 롤업 컨트랙트 상태에 대한 안정적인 접근에 달려 있습니다. 레이어 1 상태 접근이 불안정해지거나 고도로 중앙 집중화되면 이러한 안전장치 메커니즘을 실제로 작동시키기 어려워집니다.
3. 우리가 보는 세 가지 주요 방향
(1) 상태 유효 기간
모든 상태 데이터가 영구적으로 똑같이 중요한 것은 아닙니다. 최근 분석에 따르면 상태 데이터의 약 80%는 1년 이상 접근되지 않았습니다. 하지만 노드는 이러한 상태 데이터를 영구적으로 저장하는 데 여전히 비용을 부담해야 합니다.
상태 만료 메커니즘의 핵심 아이디어는 비활성 상태를 "활성 집합"에서 일시적으로 제거하고 필요할 때 어떤 형태의 증명을 통해 복원하는 것입니다. 일반적으로 이러한 메커니즘은 크게 두 가지 범주로 나눌 수 있습니다.
카테고리 1: 태그, 만료, 부활
이 프로토콜은 더 이상 모든 상태를 영구적으로 활성 상태로 취급하지 않습니다. 대신, 사용 빈도가 낮은 상태 태그 각 노드가 관리하는 활성 상태 목록에서 제외하고, 과거 존재 증명을 통해 향후 복원할 수 있도록 합니다. 실질적으로, 자주 사용되는 계약과 잔액 낮은 접근 비용으로 활성 상태를 유지하는 반면, 오랫동안 잊혀진 상태는 각 노드가 지속적으로 관리할 필요 없이 필요할 때 언제든 불러올 수 있습니다.
범주 2: 다중 주기 고장 메커니즘
다중 주기 설계에서는 개별 항목을 무효화하는 대신 상태를 주기적으로 주기(예: 1주기 = 1년)로 나눕니다. 현재 주기는 작고 완전히 활성화되어 있으며, 이전 주기는 실시간 실행 관점에서 동결 되고 새로운 상태가 현재 주기에 기록됩니다. 이전 상태는 이전 주기에 존재했음을 증명해야만 복구할 수 있습니다.
태그-무효화-복구 메커니즘은 일반적으로 더 정교하고 복구 프로세스는 더 직접적이지만, 태그 프로세스에는 추가 메타데이터 저장이 필요합니다. 다중 주기 무효화는 개념적으로 더 간단하고 아카이빙 메커니즘과 더 자연스럽게 통합되지만, 복구 증명은 종종 더 복잡하고 용량이 더 큽니다.
궁극적으로 두 접근 방식 모두 활성 구성 요소를 간소화하기 위해 비활성 부분을 일시적으로 제거하고 필요할 때 다시 활성화할 수 있는 방법을 제공한다는 동일한 목표를 공유하지만, 복잡성, 사용자 경험, 클라이언트 및 인프라에 대한 작업 부하 할당 측면에서 서로 다른 절충점을 찾습니다.
(2) 상태 아카이빙
상태 아카이빙은 상태를 콜드 상태와 핫 상태로 분류합니다.
핫 상태란 네트워크에서 자주 접근해야 하는 부분을 말합니다.
콜드 상태란 기록 및 검증 가능성의 일부로서 여전히 중요하지만 거의 건드리지 않는 부분을 의미합니다.
상태 아카이빙 설계에서 노드는 자주 사용되는 핫 상태를 과거 데이터와 별도로 명시적으로 저장합니다. 전체 상태의 크기가 계속 커지더라도 빠른 접근이 필요한 부분(핫 데이터셋)은 크기가 일정하게 유지됩니다. 실제로 이는 노드의 실행 성능, 특히 상태 접근에 필요한 I/O 비용이 시간이 지나도 비교적 안정적으로 유지되며 체인 수명에 따라 저하되지 않음을 의미합니다.
(3) 국가 저장 및 서비스 진입 장벽을 낮춘다
당연히 제기되는 질문은 다음과 같습니다. 더 적은 데이터를 보유하면서 목표를 달성할 수 있을까요? 다시 말해, 전체 상태를 영구적으로 저장하지 않고도 효과적인 참여자로서 기능할 수 있는 노드와 지갑을 설계할 수 있을까요?
한 가지 유망한 방향은 부분적으로 상태를 저장하지 않는 솔루션입니다.
노드는 부분적인 상태(예: 특정 사용자 또는 애플리케이션과 관련된 데이터)만 저장하고 제공합니다.
지갑과 라이트 클라이언트는 소수의 대형 RPC 서비스 제공업체에 전적으로 의존하는 대신, 필요한 상태 조각을 저장하고 캐싱하는 데 더욱 적극적인 역할을 수행합니다. 지갑과 전문 노드에 저장 공간을 안전하게 분산함으로써 개별 운영자의 부담이 줄어들고 상태 보유자 커뮤니티가 더욱 다양해질 것입니다.
또 다른 접근 방식은 유용한 인프라 운영에 대한 진입 장벽을 낮추는 것입니다.
상태의 일부만 처리하는 RPC 노드 배포 프로세스를 간소화합니다.
지갑과 애플리케이션이 단일의 완전한 RPC 엔드포인트에 의존하는 대신 여러 로컬 데이터 소스를 검색하고 통합할 수 있도록 하는 프로토콜과 도구를 설계합니다.
4. 향후 방향
이더 의 현재 상황은 프로토콜의 미래를 결정짓는 몇 가지 핵심 문제에 조용히 중요한 영향을 미치고 있습니다.
어느 시점에서 국가의 규모가 참여에 대한 장벽이 되는가?
검증자가 상태 정보 없이도 블록을 안전하게 검증할 수 있다면, 누가 상태를 저장하는가?
누가 사용자에게 상태 정보를 제공할까요? 어떤 인센티브가 제공될까요?
아직 해결되지 않은 문제가 몇 가지 있지만, 방향은 분명합니다. 즉, 상태가 성능에 미치는 영향을 줄이고, 저장 비용을 절감하며, 서비스 접근성을 개선하는 것입니다.
현재 저희는 리스크 적고 수익률이 높은 사업을 추진하는 데 집중하고 있습니다.
아카이빙 계획
저희는 과거 데이터를 저장하는 아카이빙 체계를 활용하면서 활성 상태의 규모를 제어하는 오프 프로토콜 솔루션을 모색하고 있습니다. 이를 통해 성능, 사용자 경험 및 운영 복잡성에 대한 실제 데이터를 얻을 수 있습니다. 효과가 입증되면 필요에 따라 프로토콜 내 업그레이드로 추진할 수 있습니다.
일부 스테이트리스 노드 및 RPC 개선 사항
대부분의 사용자와 애플리케이션은 중앙 집중식 RPC 서비스 제공업체를 통해 이더 과 상호 작용합니다. 저희는 다음과 같은 개선 작업을 진행하고 있습니다.
노드가 모든 상태를 저장하지 않더라도 노드 실행의 어려움과 비용을 줄입니다.
여러 노드가 협력하여 완전한 상태 서비스를 제공할 수 있도록 합니다.
단일 지점 병목 현상을 방지하기 위해 RPC 서비스 제공업체의 다양성을 높이십시오.
이 프로젝트들은 즉각적인 실용성과 미래 지향적인 호환성을 모두 갖추고 있기 때문에 신중하게 선정되었습니다. 즉, 이 프로젝트들은 이더 의 현재 상태를 개선하는 동시에 향후 더 심층적인 프로토콜 업그레이드를 위한 기반을 마련할 수 있습니다.
