상태 만료: 프로토콜 내 vs. 프로토콜 외

상태 증가는 여전히 주요 성능 및 탈중앙화 병목 현상입니다. 이는 노드 동기화 시간을 늘려 블록 실행 성능을 저하시키고 저장 공간 요구량을 증가시킵니다. 이는 이더리움 개선 제안(EIP)-4444에 따라 클라이언트가 제거할 수 있는 히스토리 증가(이전 블록/수신)와는 다릅니다. 상태 접근 패턴에 대한 최근 실증 분석에 따르면 상태 사용은 매우 편향되어 있습니다. 대부분의 거래는 핫 상태의 일부에 영향을 받기 때문에, 콜드 상태를 제거하면 노드 부담을 크게 줄일 수 있습니다.

상태 만료는 주로 상태 증가 속도를 늦추거나 (심지어 일정하게 유지하는 것을 목표로 합니다.) 활성 집합에서 콜드 상태를 제거 하고 다시 접근할 때 부활 증명을 요구합니다. 지금까지 상태 만료 기능 도입을 지연시킨 두 가지 장애물은 다음과 같습니다.

1. 사용자 경험: 사용자가 부활 증거를 검색하는 방법.
2. 만료된 국가 객체에 대한 저렴하고 견고한 라벨링 .

실시간 증명과 무상태(stateless) 환경으로 전환됨에 따라, 상태 만료가 정확히 어떻게 적용되어야 하는지는 불분명합니다. 따라서 이 글에서는 두 가지를 다룹니다.

• 실제로 국가가 필요한 사람이 누구인지, 그리고 국가 만료가 오늘날과 미래의 로드맵에 어떻게 도움이 되는지에 대한 지도입니다.
• 프로토콜 내 만료와 프로토콜 외 만료 상태를 구체적인 상충 관계와 비교하여 설명합니다.

국가를 쥐고 있는 사람은 누구인가?

오늘(2025년)

요약: 대부분의 노드는 상태를 유지해야 합니다.

1. 검증자 : 활성 상태에 대해 블록을 빌드, 실행 및 검증합니다. 실제 동작은 여전히 ​​전체 상태를 전제로 합니다.
2. 빌더: 프로토콜 외. 소수의 엔티티가 대부분의 블록을 구축합니다( 블록 구축 경매에서 누가 이길까요? 참조). 이들은 블록을 시뮬레이션하고 구축하기 위해 상태를 유지합니다.
3. RPC 노드 : 일반적으로 전체 노드로 실행됩니다. 일부는 팔로워 패턴(예: Besu의 플릿 모드 )을 사용하여 가벼운 노드가 신뢰할 수 있는 전체 노드에서 상태 델타를 검색하는 방식을 사용할 수 있습니다.

지금 프로토콜 내 상태 만료를 적용하면 모두가 혜택을 볼 수 있습니다. 실행을 위한 활성 상태가 작아지고, 동기화가 빨라지고, 상태 읽기/쓰기 지연 시간이 짧아지고, 가스 한도를 늘릴 때 위험이 줄어듭니다.

장기(ePBS + 무상태)

요약: 빌더만 상태를 유지해야 하며 다른 빌더는 상태를 유지할 수 없습니다.

(a) 블록의 Verkle/Binary 트라이 증인 또는 (b) 블록 실행 ZK 증명을 포함한 무국적 상태와 검열 저항 메커니즘(예: FOCIL )이 포함된 PBS( 이더리움 개선 제안(EIP) -7732 )를 가정합니다.

1. 제안자/증명자 - 증인 또는 증명을 통해 검증합니다. 전역 상태는 필요하지 않습니다. 공용 메모리 풀을 건강하게 유지하기 위해 유효성만 보장하는 부분 무상태(VOPS)가 이상적입니다.
2. 빌더 : 블록을 빌드하려면 상태가 필요합니다. FOCIL(증인 운반 tx 없음)을 사용하면 빌더는 전체 상태에 접근할 수 있어야 합니다.
3. 증명자 : 증명 생성에 사용된 증인을 검색하려면 상태 접근 권한이 필요합니다.
4. RPC 노드 : 각 노드가 관심 있는 상태만 저장하는 부분적 무상태( 로컬 노드 선호 )로의 추세이지만 이상적으로는 여전히 VOPS입니다.

이 세상에서 상태 만료는 주로 상태 성장 비용의 대부분을 부담하는 건설업체에게 유리합니다. 만료가 없으면 건설업체는 점점 더 많은 하드웨어를 공급해야 하므로 건설업체의 중앙 집중화가 더욱 심화됩니다 .

증명자가 작성자와 다르다면 상태 비저장(stateless)이 될 수 있습니다. 하지만 상태 비저장 증명자는 여전히 전체 상태를 보유한 노드에서 상태 증인(state witness)을 검색해야 하므로, 상태 만료는 실시간 증명 환경에서 비용과 효율성을 향상시킵니다.

안으로 들어가거나 밖으로 나가거나?

프로토콜 내 상태 만료

"인프로토콜"은 만료 규칙이 합의 에 따라 유지됨을 의미합니다. 상태 객체는 상태 접근(읽기, 쓰기 또는 둘 다) 시 업데이트되는 최소한의 메타데이터를 포함합니다. 객체가 접근 시점에 만료되면 연결된 증인(witness)과 함께 (일반적으로 tx를 통해) 부활 해야 합니다. 한 가지 예로 이더리움 개선 제안(EIP)-7736 (Verkle/Binary 트라이의 리프 수준 만료)이 있습니다.

왜 좋은가

1. 명확한 책임 경계
주(State)가 만료된 경우, 증빙 자료를 찾아 제출 해야 합니다. "누가 내 이전 주(State)를 호스팅하나요?"라는 모호한 문제는 더 이상 발생하지 않습니다.

2. 지역적 건축이 가능함
무국적 세계에서는 소규모의 활동적인 국가가 지역 빌더들의 생존을 유지하고 빌더 집중을 억제합니다. 그러나 현재 상황에서는 소수의 빌더가 이더리움 블록의 대부분을 생산한다는 것은 부인할 수 없는 사실입니다.

3. 남은 상태 노드의 이점
상태 비저장 증명자가 있는 환경에서는 대부분의 참여자가 상태 비저장 상태인 경우 전체 상태를 동기화하는 것이 어렵거나 불가능합니다. 따라서 일부 노드는 여전히 전체 상태를 유지하고 이타적으로(즉, 스냅 동기화) 제공할 것으로 예상됩니다. 프로토콜 내 만료 규칙을 적용하면 이러한 부담을 줄일 수 있습니다. 그러나 이러한 이타주의 의존성은 포털 네트워크 와 같은 분산 상태 네트워크를 통해 완화될 수 있습니다. 포털 네트워크는 이타적인 상태 저장 노드에 의존하지 않고 상태를 보존하고 제공할 수 있습니다. 포털 자체는 이타적인 시스템이지만 말입니다.

4. 예측 가능한 UX 표면
지갑은 빌더 정책의 패치워크가 아닌 단일 만료 규칙을 대상으로 할 수 있습니다.

왜 어려운가

1. 부활 UX
지갑은 상태 복원을 위한 여러 홉을 피하기 위해 다중 객체 복원 (예: 일괄 증명)에 대한 강력한 흐름이 필요합니다. 체계가 더 세분화될수록(슬롯 수준 대 계정 수준) UX가 더 어려워집니다.

2. 만료된 주를 호스팅하는 사람은 누구입니까?
상태 만료가 상태 객체를 영원히 사라지게 하는 것은 아닙니다. 상태 제공 인프라 , 이상적으로는 분산된 인프라가 여전히 필요합니다. 신뢰할 수 있는 증명 제공자에 대한 의존은 해당 체계가 약 99.99%의 사용자에게 쓸모없는 상태를 진정으로 제거하는 경우에만 숏 으로 허용될 수 있습니다. 그러나 콜드 상태가 적을수록 제거되는 경향이 있다는 단점이 있습니다.

3. 복잡성 및 DoS 표면
만료 메타데이터를 저장해야 하므로 저장 오버헤드가 증가합니다. 만료 체계가 세분화될수록 오버헤드가 커집니다. 부활의 복잡성 또한 체계에 따라 달라집니다. 예를 들어, 다중 트리 만료 방식 에서 부활은 이더리움 개선 제안(EIP)-7736 과 같은 리프 수준 설계보다 더 복잡합니다. 또한 사용자는 만료된 상태를 부활시키는 데 추가 비용을 부담하게 됩니다.

프로토콜 외부 상태 만료

프로토콜 외(Out-of-protocol)는 합의 변경이 없음을 의미합니다. 노드는 사회적으로 조정된 만료 정책(예: 온체인 또는 오프체인 레지스트리)을 채택할 수 있습니다. 노드는 상태를 삭제하고 사용자가 자체 증명을 가져올 것을 기대할 수 있지만 , 체인이 이를 강제하지는 않습니다.

왜 좋은가

1. 이더리움 프로토콜 복잡성 감소
빌더는 만료 규칙을 유연하게 결정하고 빠르게 반복할 수 있습니다. 정책은 소셜 네트워크 또는 온체인 구성을 통해 조정할 수 있습니다. 이는 포크(Fork) 적용하는 것보다 더 쉬울 수 있습니다.

2. 더 빠른 반복 및 가역성
빌더는 다양한 가지치기 방식을 더욱 창의적으로 테스트할 수 있습니다. 정책이 역효과를 내더라도 롤백은 즉각적이고 지역적으로 이루어집니다. 잘못된 만료 설정은 글로벌 합의 위험이나 체인 전체 서비스 거부(DoS)를 야기하기보다는 오히려 빌더의 서비스 품질을 저하시킵니다(예: MEV 누락, 지연 시간 증가).

3. 생태계 퇴비화성
분산형 상태 네트워크와 상업적 증인 서비스에 대한 명확한 수요를 창출합니다. 두 서비스 모두 프로토콜 결합 없이 지연 시간, 커버리지, 가격 측면에서 경쟁할 수 있습니다. 유효한 증인 제공에 대한 프로토콜 외 수수료는 사이드카 마켓으로 시험 운영될 수 있습니다.

4. 프로토콜 내로의 전환
실제 사용 경험을 통해 프로토콜 내 만료 시점(필요한 경우)을 예측할 수 있습니다. 또한 처음부터 프로토콜 내 만료를 적용하는 것보다 쉽습니다.

5. 균일 액세스 계층(DA가 강한 경우)
빠르고 비허가형(Permissionless) 상태 네트워크가 존재한다면, 프로토콜 외 접근 방식은 필수적입니다. 상태 비저장 또는 부분 상태 저장 노드는 필요에 따라 증인을 가져올 수 있습니다. 노드는 포크(Fork) 없이도 대부분의 만료 이점을 얻을 수 있으며, 지갑은 간단하고 증명 중심적인 접근 경로를 사용합니다.

왜 어려운가

1. 일관되지 않은 UX 및 데이터 가용성
특정 상태를 유지하지 않는 빌더는 사용자에게 증인(witness)을 제공하도록 요구합니다. 이는 프로토콜 내 UX 부담을 반영하지만, 모든 빌더가 상태를 유지한다는 보장은 없습니다 . 정책이 사회적 합의 에 기반하는 경우, 앱 툴링은 여러 규칙을 추적해야 하며, 이는 UX를 더욱 복잡하게 만듭니다.

2. 만료된 주를 호스팅하는 사람은 누구입니까?
프로토콜 내 상태 만료와 동일한 문제입니다. 그러나 프로토콜 내 상태의 경우 소유권이 명확하게 정의되어 있습니다(즉, 상태는 사용자의 책임입니다). 프로토콜 외 상태의 경우 소유권이 명확하지 않아 데이터가 영구적으로 손실될 가능성이 더 높습니다.

3. 검열 벡터
"우리는 당신의 국가를 억압하지 않는다"는 정책이 허용 가능하다면, 외부의 압력이 이를 무기화하여 특정 계약을 배제할 수 있으며, 이는 사실상 검열 공격으로 바뀔 수 있습니다.

4. 빌더스 + FOCIL 뉘앙스
포함 목록에 있는 거래 내역에 증인이 없으면 건설업체는 사실상 전체 주에 접근해야 하므로, 프로토콜 외 만료에 대한 인센티브가 감소합니다. 건설업체는 성과가 더 우수하다는 것이 입증되면 핫-콜드 주 분리 방식을 채택할 수 있습니다.

포함 목록의 tx가 증인을 포함하는 경우 빌더는 부분적으로 무상태가 될 수 있지만, 이는 모든 tx가 증인을 포함해야 하므로(즉, 강력한 무상태) 사용자 경험을 악화시키는 또 다른 프로토콜 내 규칙이 됩니다.

5. 상태 동기화
운영자가 프로토콜 외부에서 데이터를 정리할 때 피어 간에 상태 가용성이 균일하지 않습니다. 전체 상태를 동기화하는 것이 더 어렵거나 불가능할 수도 있습니다.

국가 부활의 과제

일반적으로 모든 형태의 상태 만료(상태 만료 또는 상태 만료)는 부활을 고려해야 합니다. 다음은 몇 가지 과제입니다.

부활 호핑

오랫동안 휴면 상태였던 계좌로 1 이더리움(ETH) 와 다이(Dai) 보내고 싶다고 가정해 보겠습니다. 먼저, 계좌 조회 결과 계좌가 만료되어 거래가 실패합니다. 증명을 가져와서 계좌를 부활시킵니다. 다음으로, 다이(Dai) 전송이 토큰 저장소에 영향을 미치는데, 이 저장소 역시 만료되었습니다. 추가 증명을 가져와서 해당 슬롯을 부활시켜야 합니다. 이러한 상호 작용이 "복귀 호핑(resurrection hopping)" 문제입니다.

프로토콜 내 만료의 경우 이러한 문제가 더욱 심각합니다. 각 부활에는 일반적으로 트랜잭션 제출이 필요하기 때문입니다. 트랜잭션이 만료된 객체를 더 많이 다룰수록 홉과 수수료도 늘어납니다. 프로토콜 외 만료도 동일한 검색/페치 루프에 직면하지만, 홉은 오프체인 (추가 트랜잭션 없음)으로 처리되지만 여전히 지연 시간이 증가합니다.

가능한 완화책

1. 사용자 거래를 제출하기 전에 부활해야 하는 모든 계정과 저장 슬롯을 열거하기 위해 전체 상태 오라클에 대해 거래를 사전 시뮬레이션합니다 .
2. 만료의 세분성(예: 계정 또는 계약 수준 대 슬롯 수준)을 줄여서 부활이 필요한 개별 객체의 수를 제거합니다.
3. 일괄 부활 : 여러 계정/슬롯을 원자적으로 부활시키는 단일 번들 증명을 지원하며, 명시적인 바이트 제한을 통해 DoS 위험을 제어합니다. 블롭은 거래 내역을 저렴하게 유지할 수 있지만, 일시적이기 때문에 부활 페이로드는 다른 곳에 영구적으로 저장하고 모든 사람이 사용할 수 있도록 해야 합니다.

국가 정보는 어디서 얻을 수 있나요?

1. RPC 제공자
   국가에 증거를 제공하는 제3자 인프라(상업적 또는 공공적).

   • 장점
     • 오늘날 널리 이용 가능
     • 데이터 가용성을 보장하는 서비스 수준 계약(SLA)을 제공할 수 있습니다.
     • 만료된 상태에 대한 액세스를 "판매"하기 위해 전체 상태를 유지하려는 자연스러운 인센티브
   • 단점
     • 신뢰 및 검열 위험: RPC 제공자는 특정 상태를 검열하거나 검열하도록 강요받을 수 있으며, 이는 상태 부활을 거부합니다.
     • 사용자는 상태를 검색하기 위해 비용을 지불합니다(프로토콜 내 상태 만료에 대한 부활 tx 외에도).

2. 클라이언트 호스팅 제공자
   EL 클라이언트 팀은 정의된 만료 기간 동안 만료된 상태에 대한 정적 파일/스냅샷을 호스팅할 수 있습니다. 이는 블록 데이터의 Era 파일과 유사합니다. 이러한 파일은 표준 체인이 새로운 만료 기간에 진입하면 새로 고쳐집니다. Erigon과 Reth는 상태 동기화 아키텍처에서 유사한 스냅샷 메커니즘을 사용합니다.

   • 장점
     • 더 큰 커뮤니티 신뢰와 투명성
     • 상태 파일과 응답 형식을 조정하여 부활 지연 시간을 최소화할 수 있습니다.
   • 단점
     • EL 클라이언트 팀의 추가 인프라 및 유지 관리 부담
     • 팀이 만료된 상태를 모두 보관하고 있다는 것을 신뢰하는 것이 여전히 중요합니다. 상태를 사용할 수 없는 경우, 사용자는 RPC 공급자를 이용하거나 다른 곳에서 찾아야 합니다.

3. 이타적인 스냅 동기화 피어
   상태 청크(스냅 동기화)를 제공하는 피어를 통해 증명에 필요한 계정/슬롯을 구성합니다. 이는 상태 만료 시에도 스냅 요청을 이타적으로 처리할 전체 상태를 가진 노드가 여전히 존재한다는 가정을 기반으로 합니다.

   • 장점
     • 오늘 이미 작동 중입니다
     • 특정 신뢰할 수 있는 공급자에 대한 의존을 피합니다.
   • 단점
     • 더 많은 노드가 만료된 상태를 정리함에 따라 가정이 실패할 수 있습니다. 즉, 새로 생성된 노드는 더 이상 스냅 동기화를 수행할 수 없습니다.
     • 전체 상태 피어 수가 감소함에 따라 Resurrection UX가 저하됩니다. 최악의 경우, 사용자는 신뢰할 수 있는 제공업체로 돌아가야 합니다.

4. 분산형 국가 네트워크
   전체 상태를 저장하고 증명을 통해 상태를 제공할 수 있는 비허가형(Permissionless) 네트워크입니다. 이러한 예 중 하나는 Portal 네트워크의 상태 네트워크 입니다.

   • 장점
     • 검열 방지
     • 내장된 복제 기능으로 상태 누락 위험 감소
   • 단점
     • 오늘 현재 프로덕션 등급 배포는 없습니다.
     • 참여는 인센티브 없이 주로 이타적이어서 부하 하에서 신뢰성을 제한할 수 있습니다.

5. 레인보우 스테이킹을 통해 노드가 상태의 하위 집합을 보유하도록 인센티브를 제공합니다.
   레인보우 스테이킹의 "분리된 역할"(헤비 vs 라이트) 내에서 상태 서비스를 가벼운 서비스로 취급합니다. 운영자는 상태의 하위 집합을 저장하고 검증 가능한 증인을 제공하는 데 전념하는 반면, 위임자는 이러한 운영자에게 가중치를 할당합니다.

   • 장점
     • 분산화
     • 인센티브를 정렬합니다. 상태를 사용 가능하게 유지하는 데 대한 지속적이고 프로토콜 기반 보상으로 이타주의에 대한 의존도를 줄입니다.
   • 단점
     • 현재는 연구 단계에 있으며 운영자 선택 및 보상 회계에 대한 구체적인 설계가 필요합니다.

옵션 5는 장기적인 관점에서 최선의 접근 방식이지만, 실행하는 데 시간이 걸릴 것입니다. 옵션 2는 단기적으로 더 현실적입니다.

다음은 무엇인가?

독립적인 개발자와 예측 가능한 UX를 중시한다면, 프로토콜 내 상태 만료는 더 안전한 장기적 앵커로 남을 것입니다. 오늘날의 세상에서 상태 만료는 분명 도움이 됩니다. 하지만 UX 부담과 복구 불가능한 데이터 위험 때문에 즉각적인 정착은 어려울 것입니다.

단기적으로는 프로토콜 외(out-of-protocol)를 실험 해야 합니다. 프로토콜 외(out-of-protocol )합의 위험 없이 동일한 문제를 해결하는 프로토타입으로 취급하면서, 실질적인 문제(예: 상태 가용성)를 표면화하고 해결책을 반복합니다. 프로토콜 외 만료가 안정적이고 사용자 친화적이라고 판단되면, 나중에 정말 필요한 경우에만 프로토콜 외 만료를 도입하는 것을 고려할 수 있습니다.

폐쇄

배송 상태 만료 시점을 앞당기면 즉각적인 이점을 얻을 수 있습니다. 활성 상태 감소, 동기화 속도 향상, 가스 헤드룸 확보 등이 그 예입니다. 상태 비저장 미래에서는 이러한 이점의 대부분이 빌더, 검증자, 그리고 소수의 상태 저장 제공자에게 돌아가는데, 바로 중앙 집중화 압력이 집중되는 바로 그 지점들입니다. 프로토콜 외 만료 시점을 사용하면 이점을 빠르게 확보하고, 위험(증명 가용성, 서비스 거부, 사용자 경험)을 노출하며, 합의 위험 없이 반복 작업을 수행할 수 있습니다.

무엇보다도 국가 지원 인프라가 필수적입니다. 무국적화와 국가 만료가 다가옴에 따라, 네트워크는 국가 정보와 증인 정보를 일관되게 검색할 수 있는 공개적이고 신뢰할 수 있으며 비허가형(Permissionless) 접근 가능한 방식이 필요합니다.

결론 : 네트워크는 상태의 영구적 손실을 허용해서는 안 됩니다.

추가 자료

• 이더리움 프로토콜의 가능한 미래, 5부: 퍼지
• 가스 한도를 높이는 방법, 1부: 주 성장
• 이더리움 개선 제안(EIP)-7732: 제안자-구축자 분리 확립
• 모든 주가 평등한 것은 아니다
• 무국적 상태에 대한 프로토콜 설계 관점
• 스케일링 로드맵에 대한 로컬 노드 선호 델타

감사의 말

이 기사를 검토해 주신 Guillaume, Carlos, Ignacio에게 특별히 감사드립니다.