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