ChatGPT 이미지 2025년 4월 22일 오전 11시 26분 48초 1024×1536 148KB

소개

이더리움은 오랫동안 상태 비저장 검증(Stateless Validation) 이라는 목표를 추구해 왔습니다. 참여자들이 체인의 전체 상태를 저장할 필요 없이 블록을 검증할 수 있도록 하는 것입니다. 상태 비저장은 하드웨어 요구 사항을 줄이고, 검증 노드 간의 탈중앙화를 촉진하며, 모든 노드가 전체 상태를 복제할 필요 없이 더 큰 블록을 생성하고 검증할 수 있도록 함으로써 확장성을 극대화하는 것을 목표로 합니다.

이러한 비전을 위한 주요 제안 중 하나는 약한 무상태성(weak statelessness) 입니다. 약한 무상태성은 블록 생성자만 전체 상태를 유지하고 다른 노드는 작은 상태 증명을 사용하여 블록을 검증합니다. 약한 무상태성은 단순성과 효율성 측면에서 매력적이지만, 중요한 과제를 제기합니다. 대부분의 노드가 독립적으로 거래를 검증할 수 없는 환경에서 이더리움은 어떻게 검열 저항성(CR) 특성을 유지할 수 있을까요?

이 글에서는 약한 무상태성 (Validity-Only Partial Statelessness, VOPS) 이 이더리움의 검열 저항성을 저해하는 이유를 살펴보고, 실용적인 해결책을 제시합니다. VOPS 는 노드가 보류 중인 거래를 검증하는 데 필요한 만큼의 계정 데이터만 저장하도록 요구함으로써, 이더리움의 검열 저항성을 유지하면서 저장 공간을 25배 절감 합니다.

우리는 다음과 같이 주장합니다.

• 무국적 상태가 약하다는 것만으로는 강력한 검열 저항력을 보장할 수 없습니다.
• 향후 설계에서는 강력한 무국적성을 재검토하고 누가 이러한 증명을 생성하는지 , 어떤 유형의 증명이 가장 효율적인지, 대역폭과 증명 비용이 노드 요구 사항에 어떤 영향을 미치는지 등의 실질적인 문제를 해결해야 합니다.
• 그 사이, 유효성만 보장하는 부분적 무상태(VOPS)는 간단하고 효과적인 연결책을 제공합니다. 즉, 기능적이고 검열에 저항하는 공개 메모리 풀을 유지하는 동시에 로컬 저장소를 25배로 줄일 수 있습니다.
  AA-VOPS는 로컬 캐싱 및 증분 업데이트를 통해 증인 오버헤드를 최소화하여 강력한 무국적 상태를 구현하는 경로를 제공함으로써 전체 기본 계정 추상화를 지원하도록 VOPS를 확장합니다.

왜

FOCIL 과 같은 메커니즘을 통해 모든 거래에 강력한 검열 저항성을 보장하고자 할 때, 약한 무상태(즉, 블록 생성자에게만 상태 유지를 의존하는 방식)가 왜 효과적이지 않은지 설명하겠습니다. 더 자세히 살펴보기 전에, FOCIL이 상태 저장 환경에서 작동하는 데 필요한 주요 구성 요소를 간략하게 살펴보겠습니다. FOCIL의 현재 설계가 메모리 풀이 유효하지 않은 거래를 제거하면서 유효한 거래를 유지할 수 있다는 가정에 어떻게 의존하는지 살펴보겠습니다.

• 사용자는 유효한 경우(즉, nonce 및 잔액 확인을 통과한 경우) 거래를 보내고 이 거래는 노드 전체에 브로드캐스트되고 공개 메모리 풀에 보류 상태로 남습니다.
  참고: 이 게시물에서 "노드"라는 용어는 실행 계층 클라이언트를 통한 mempool 유지 관리자를 지칭하는 데 사용됩니다.
• 포함자 : 각 슬롯에서 16개의 포함자가 보류 중인 메모리풀 거래를 관찰하고 이를 포함 목록(IL)에 추가하고 이러한 IL을 CL P2P 네트워크 전체에 브로드캐스트합니다.
• 블록 생성자는 모든 IL에서 유효한 트랜잭션의 합집합을 블록에 포함해야 합니다. IL 트랜잭션은 유효하지 않거나 블록이 가득 찬 경우(즉, 조건부 속성)에만 블록에서 제외될 수 있습니다.
• 증명자는 모든 IL 거래가 블록에 포함되어 있는지 확인합니다. 포함되어 있으면 증명자는 해당 블록에 투표합니다. 포함되어 있지 않으면, 블록이 가득 찼는지 또는 누락된 거래가 유효한지 평가하여 제외가 정당한지 또는 블록이 검열되었는지 여부를 판단합니다.

이제 프로토콜이 블록 생성자 만 상태를 유지하도록 한다고 가정해 보겠습니다. 이는 사용자 , 메모리 풀을 유지하는 노드 , 포함자 , 그리고 증명자가 preStateRoot 에 대한 트랜잭션의 유효성을 스스로 판단할 수 없음을 의미합니다. 실제로, 이들은 발신자의 balance 충분한지, 트랜잭션의 논 nonce 정확한지 확인하는 등 중요한 유효성 검사에 필요한 완전하고 최신 상태 정보에 접근할 수 없습니다. 스마트 계약 조건이나 상태 의존적인 로직(예: Uniswap 풀의 현재 상태)은 현재 dApp에서 사용자가 되돌리기를 방지할 수 있도록 이미 제공되고 있습니다.

따라서 무국적 상태가 약한 세계에서는:

• 실제로 증명자에게는 모든 것이 잘 작동합니다. 블록 생성자가 블록 수준 증인을 생성하기 때문에 아무것도 저장할 필요가 없습니다. 이러한 증인은 집계된 Merkle/Verkle 증명 (예: IPA 다중 증명 ) 또는 SNARK(이에 대한 자세한 내용은 이후 섹션에서 설명)의 형태를 취할 수 있으며, 이는 블록에 포함된 트랜잭션의 모든 상태 접근이 preStateRoot 에 대해 유효함을 보여줍니다. 즉, 블록 실행을 위해 제공된 데이터가 이전 블록 상태 루트에 존재함을 증명합니다. 중요한 점은 블록 생성자가 제외하는 모든 IL 트랜잭션에 대한 증인도 첨부해야 한다는 것입니다(IL과 함께 제출된 증인을 사용하거나 IL을 재구성하여). 이를 통해 증명자가 블록을 다시 실행하고 각 누락이 정당한지 확인할 수 있습니다.
• mempool과 includer를 유지하는 노드 의 경우, 상태 비저장(stateless)을 구현하려면 근본적인 문제가 있습니다. 사용자 가 공개 mempool로 트랜잭션을 전송하면 노드는 해당 트랜잭션이 preStateRoot 에 유효한지 확인할 방법이 없습니다. 트랜잭션을 재브로드캐스트할지 아니면 로컬 mempool에서 삭제할지 결정하기 위해 일반적인 nonce 및 balance 확인을 수행할 수 없기 때문입니다.
  • 이를 악용하면 잘못된 거래로 mempool 과 IL 이 범람하여 FOCIL의 이점이 사실상 무효화 되고 IL에 포함되면 이점이 있었을 거래가 검열될 수 있습니다.
  • nonce balance 확인이라는 1차 방어선이 부재하면 새로운 서비스 거부 공격(DoS) 벡터가 생성됩니다. 누구든 유효하지 않은 거래를 멤풀이나 IL에 제출할 수 있게 되어 멤풀의 품질이 저하되고 유효한 거래가 드러나기 어려워집니다. 이는 포함자가 적대적인 행동을 하며 IL을 가비지로 채웠을 때 발생할 수 있는 것과 동일한 종류의 혼란을 야기합니다. 주요 차이점은 현재 검증자(32 ETH 보유)만 포함자가 될 수 있다는 점입니다. 반면, 기본적인 필터링 기능이 없다면 모든 참여자가 멤풀의 품질을 저하시키고 포함 목록의 효율성을 저해할 수 있습니다. 이는 공격에 대한 방어력을 약화시키고 검열 저항성을 실질적으로 약화시킵니다.

어떻게 해야 하나요?

다음 섹션에서는 약한 무국적 접근 방식이 제기하는 과제를 극복하기 위한 잠재적 옵션을 살펴보겠습니다.

옵션 1: 강력한 무국적

겉보기에 간단해 보이는 한 가지 접근법은 사용자 트랜잭션이 preStateRoot 대한 완전한 상태 접근(예: Merkle 또는 Verkle 증명)과 함께 번들로 제공되도록 요구하는 것인데, 이를 종종 강력한 무상태성(strong statelessness)이라고 합니다. 이전 블록 생성자가 모든 트랜잭션에 상태 증인(state witness)을 첨부하도록 요구함으로써 강력한 무상태성에 대한 엄격한 정의를 완화할 수도 있습니다. 이렇게 하면 노드가 필요에 따라 상태 증인을 가져올 수 있습니다. 이론적으로 이를 통해 포함자 와 증명자를 포함한 모든 노드가 전체 현재 상태에 접근하지 않고도 트랜잭션의 상태 접근이 preStateRoot 와 일치하는지 독립적으로 검증할 수 있습니다. 이러한 메커니즘은 메모리 풀을 효과적으로 관리하는 데 유용합니다. 모든 슬롯에서 트랜잭션을 제외했다가 다시 포함하는 대신, 노드는 후속 블록의 영향을 받지 않는 트랜잭션을 유지하고 논스 또는 잔액이 변경된 트랜잭션은 제거할 수 있습니다.

하지만 실제로는 노드와 현재 블록 생산자 사이에 실시간 전달 채널이 필요하며, 이는 강력한 신뢰 가정과 새로운 검열 벡터를 도입합니다. 블록 생산자는 대상 거래를 모든 멤풀 및 포함 목록에서 제외하기 위해 거래 수준 증명을 지연시키거나 선택적으로 보류하고, 겉보기에 유효한 블록을 생성하면서도 조용히 제외할 수 있습니다. 더욱이, 새로운 거래의 경우 이전 블록의 상태에만 의존하는 것은 충분하지 않습니다. 사용자는 거래가 실제로 영향을 받은 계정과 스토리지 슬롯, 그리고 트라이 구조가 상태를 연결하는 방식 때문에 해당 항목으로의 경로를 재구성하는 데 필요한 상태 트라이의 추가 부분을 포함하는 업데이트된 실시간 상태 증인에 접근해야 합니다. 이러한 증명을 지속적으로 가져오는 것은 대역폭 사용량과 지연 시간을 증가시켜 UX를 저하시킬 뿐만 아니라, 다음과 같은 중요한 질문을 제기합니다. 누가 증명 제공 노드 역할을 해야 할까요? 지갑? dApp? 포털 네트워크? 슈퍼노드(즉, 2048 ETH 스테이킹하는 검증자)? 이 모든 것?

증명자 및 포함자 노드가 완전히 무상태로 스마트워치에서 실행되도록 하려면 강력한 무상태화가 최종 목표가 될 수 있지만, 이 질문에 답하고 (1) 전체 상태를 저장하고 (2) 사용자 거래와 관련된 증인 및 증명을 생성하고 브로드캐스트하는 데 필요한 비용과 하드웨어 요구 사항을 평가하여 어떤 행위자가 이 임무를 수행하는 데 가장 적합한지 결정하기 위해서는 추가 연구가 필수적입니다. 이 접근 방식은 N 중 1의 정직성 가정만 필요로 한다는 점에 유의해야 합니다. 이론적으로는 유효한 증명을 생성할 수 있는 정직한 행위자 한 명만으로도 충분합니다. 그러나 실제로는 하나 또는 극소수의 행위자에게만 의존할 경우 렌트 추출(예: 커밋 공격, 검열, 독점 가격 책정)과 같은 문제가 발생할 수 있습니다.

옵션 2: 유효성만 있는 부분적 무상태

실용적이고 단기적인 접근 방식은 부분적인 무상태(stateless)에 의존하고 거래 유효성 검증에 필요한 최소한의 데이터만 저장하는 것입니다. VOPS에서는 각 노드가 EOA당 전체 상태 대신 address (20바이트), nonce (8바이트), balance (12바이트), 그리고 1비트 codeFlag 의 네 필드만 유지합니다.

거래가 도착하면 노드는 codeFlag 확인합니다.

• codeFlag = 0 (순수 EOA, 위임 지정자 없음 - 즉, 계정이 사용자 정의 코드에 실행을 위임할 수 없음):
  • 서명, 논스, 잔액 대 수수료, 가스 한도를 확인하세요.
  • 주소당 여러 건의 거래가 가능합니다.
• codeFlag = 1 (23바이트 EIP‑7702 위임 지정자를 사용하여 코드를 실행할 수 있는 모든 주소):
  • 주소당 최대 1개의 보류 중인 거래를 시행합니다 .
  • 위임된 코드가 상태를 예측할 수 없게 변경할 수 있으므로 nonce/balance 충돌을 방지합니다.

새로운 블록마다 노드는 수정된 모든 4중체로 테이블을 업데이트하고, 오래된 nonce나 잔액 부족으로 인해 무효화된 모든 거래를 제거하고, 계정의 codeFlag 0 에서 1 로 바뀔 때마다 가장 높은 우선순위의 보류 중인 거래만 남기고 나머지는 모두 삭제하고, 플래그가 1 에서 0 으로 바뀔 때 nonce가 일치하는 대기 중인 모든 EOA 거래를 승격합니다.

각 계정 항목은 20 + 8 + 12 + 0.125 ≈ 40.125 bytes 에 불과하므로 약 2억 4,100만 개의 계정을 유지하려면 다음이 필요합니다.

이는 현재 ~233 GiB 전체 상태 크기(Guillaume 제공)에 비해 25배 이상 감소한 수치이지만, VOPS 노드는 여전히 메모리 풀을 효과적으로 유지할 수 있습니다. 8.4 GiB 라는 수치는 압축되지 않은 상태이므로, VOPS가 제공할 수 있는 저장 공간 절감 효과에 대한 비관적인 추정치입니다.

Verkle용 VOPS

VOPS 아이디어를 구체화하기 위해 먼저 Verkle 설정 에 제안을 고정하겠습니다.

블록 헤더 필드

해당 시나리오에서 누가 무엇을 하는지 다시 살펴보겠습니다.

• 사용자는 공개 메모리 풀에 트랜잭션을 브로드캐스트합니다. VOPS에서 부분 상태 비저장 노드는 계정당 네 개의 필드 address , nonce , balance , codeFlag 만 유지하며, 이는 보류 중인 각 트랜잭션을 유지할지 또는 삭제할지 결정하는 데 필요한 만큼만 유지합니다.

• 포함자 : 각 슬롯에서 16개의 포함자가 보류 중인 멤풀 트랜잭션을 관찰하고, 이를 포함 목록(IL)에 추가하며, CL P2P 네트워크를 통해 이러한 IL을 브로드캐스트합니다. 현재처럼 포함자가 멤풀을 유지하는 경우, IL에 트랜잭션을 포함하기 전에 추가 검사가 필요하지 않습니다. preStateRoot (예: nonce , balance , codeFlag )에 대한 유효성 검사가 멤풀 유지 관리의 일환으로 수행되기 때문입니다. 그러나 향후 포함자가 독립형 역할(예: 가벼운 "스마트워치" 포함자 )로 분리되는 경우, IL에 트랜잭션을 포함하기 전에 각 포함자가 트랜잭션 유효성 검사를 독립적으로 수행해야 합니다.

• 블록 생성자는 전체 이더리움 상태를 보유합니다. 모든 IL에서 유효한 모든 트랜잭션의 합집합을 제안된 블록에 포함해야 합니다. IL 트랜잭션은 유효하지 않거나 블록이 가득 찬 경우(즉, 조건부 속성이 충족되는 경우)에만 제외될 수 있습니다.

  Verkle 세계의 VOPS 에서 블록 생산자는 다음을 생성하고 커밋할 책임이 있습니다.

  • 블록 수준 증인 (예: Verkle 트리에 대한 IPA 다중 증명 ): 이는 블록 실행을 위해 제공된 데이터가 이전 블록 상태 루트에 존재한다는 것을 증명합니다.
  • 포스트 스테이트 루트 : 모든 트랜잭션을 실행한 후, 블록 프로듀서는 결과인 postStateRoot 를 계산하여 블록 헤더에 커밋합니다. 이는 실행 결과이며, 증명자가 검증해야 합니다. 이는 현재 블록 프로듀서들이 이미 수행하고 있는 작업이며, VOPS 환경에서는 새로운 요구 사항이 아닙니다.

• 증명자는 다음 단계를 수행하여 블록을 검증합니다.

  1. 블록 수준 증인 확인 : 제공된 모든 상태(IPA 다중 증명을 통해 입증됨)가 preStateRoot 에 대해 유효한지 확인합니다.

  2. 블록을 로컬로 다시 실행합니다 . 제공된 트랜잭션을 사용하여 증명자는 증인으로부터 재구성된 사전 상태부터 블록을 독립적으로 다시 실행하여 postStateRoot 를 다시 계산합니다.

  3. postStateRoot 확인하세요 : 로컬에서 다시 계산된 postStateRoot 가 블록에 커밋된 것과 일치하는지 확인하세요.

  4. IL 조건 검증

  • IL 거래 포함
    • 재구성된 사전 상태에서 로컬 재실행하는 동안 블록에 존재하는 IL 거래에 해당하는 모든 상태 변경 사항을 관찰할 수 있습니다.
  • 제외된 IL 거래
    • 블록에 포함된 모든 트랜잭션을 실행한 후 제외된 각 IL 트랜잭션을 실행해 보세요.
      • 거래가 nonce 또는 잔액 확인에 실패하거나 블록이 가득 찬 경우 제외는 정당화됩니다.
      • 그렇지 않으면 블록 생산자가 검열을 하고 블록은 투표를 받아서는 안 됩니다.

  모든 검사(상태 접근 유효성, 실행 정확성, IL 조건 충족)를 통과하면 증명자는 블록에 투표합니다 . 2단계 에서 블록을 재실행하고 3단계 에서 로컬 쿼드러플릿 테이블을 동시에 업데이트함으로써, VOPS 노드는 전체 Verkle 트리를 저장하지 않고도 부분 상태를 완벽하게 동기화합니다.

zkVM용 VOPS

VOPS의 Verkle 기능을 기반으로, 블록 단위 상태 증명과 로컬 재실행을 영지식 가상 머신( zkVM) 으로 대체할 수 있습니다. 각 블록에는 SNARK가 포함되어 모든 검증자가 단일 밀리초 단위 검증을 실행하여 전체 전환과 모든 IL 조건을 확인할 수 있습니다.

• 블록 생산자가 증명해야 하는 사항:
  • 상태 유효성: 트랜잭션에서 읽은 모든 키/값은 preStateRoot 에 대해 입증됩니다.
  • 실행 정확성: 재구성된 사전 상태에 대해 정렬된 트랜잭션을 실행하면 커밋된 postStateRoot 생성됩니다.
  • diff 정확성: preStateRoot 에 정확한 전체 상태 diff를 적용하면 postStateRoot 생성되고, 이 diff는 헤더에 내장된 diff와 일치합니다.

블록 헤더 필드

두 가지 참고 사항:

• VOPS 및 AA‑VOPS 환경에서 노드는 블록당 전체 stateDiff 수신하여 로컬 상태를 패치합니다. EIP-7928 블록 수준 액세스 목록(BAL)은 수정된 모든 계정, 스토리지 키, 잔액 및 논스를 검증 가능하고 강제로 게시하는 기능을 제공합니다.
• IL 규정 준수 여부는 VOPS 노드에서 업데이트된 4중 테이블과 수신된 stateDiff 사용하여 로컬로 검사합니다. 여기에는 추가 증명 의무가 없습니다(계정별 증명이 포함 목록 규칙과 연결되는 부분은 AA-VOPS 참조).

VOPS 노드를 위한 블록별 루틴

1. execProof 확인하세요 . 국가 유효성, 실행 정확성 및 diff 정확성.
2. 네 쌍을 추출합니다. 검증된 전체 stateDiff 에서 수정된 각 계정의 (address, nonce, balance, codeFlag) 추출하여 로컬 테이블을 업데이트합니다.
3. IL 규칙을 적용합니다. 새로 고친 쿼드러플릿 테이블을 사용하여 로컬에서 포함 목록 조건을 다시 확인합니다. 저장된 VOPS 쿼드러플릿 필드에 대한 로컬 검사를 통해 IL 규칙을 즉시 적용할 수 있습니다.
4. 메모리 풀을 정리합니다. 새로운 쿼드러플릿 값으로 인해 무효화된 보류 중인 트랜잭션을 삭제합니다.

리소스 프로필

결론은 다음과 같습니다.

약 8.4GiB의 로컬 상태, 변경되지 않은 mempool 규칙, 블록당 단일 간결 증명을 통해 zkVM VOPS는 소비자 등급 한도 내에서 검증기 하드웨어 요구 사항을 유지하면서도 Ethereum의 검열 저항성을 유지합니다.

VOPS 동기화

중요한 사항부터 시작해 보겠습니다. 오늘날의 Verkle 및 Binary 트리 제안에서는 계정과 스토리지 슬롯이 명시적인 구분 없이 인터리빙됩니다. 계정이 별도의 하위 트리를 형성하는 현재의 Merkle Patricia 트리와 달리, 이는 VOPS 노드가 로컬 계정 테이블을 재구성하기 위해 스냅샷을 다운로드할 수 없음을 의미합니다. 대신, 제네시스의 모든 블록을 다시 실행해야 합니다. 향후 통합 트리 설계에서는 계정과 스토리지를 구분하기 위해 최소한의 의미(예: 비트필드)를 추가하여 효율적인 스냅 동기화를 구현할 수 있습니다.

현재 계정 트리는 전체 상태 크기의 약 1/6 차지합니다. 스냅 동기화 방식을 가정할 경우, 계정 트리만 다운로드하면 복구 단계를 포함하여 전체 상태를 다운로드하는 것보다 동기화 속도가 약 5~6배 빨라집니다. 복구 단계는 여전히 현재와 동일한 시간이 소요되며, 다운로드된 데이터의 대부분은 결국 삭제되지만, 동기화는 현재와 마찬가지로 모든 전체 노드에서 수행될 수 있습니다.

VOPS 노드를 부트스트래핑하려면 일반적인 블록 헤더와 함께 계정 상태만 필요합니다(저장 시도나 코드 블롭 없음):

1. 헤더 다운로드 및 검증

   • 제네시스(또는 신뢰할 수 있는 체크포인트)에서 최신 헤드까지 블록 헤더를 가져와서 검증합니다.

2. 블록별 업데이트

   새로운 블록마다:

   • 검색하다:
     • Verkle-tree: 헤더 + IPA 다중 증명 + 전체 거래 목록
     • zkVM: 헤더 + SNARK execProof + compact stateDiff 사이드카
   • 확인 및 추출:
     • Verkle-tree: 다중 증명을 확인하고, 수정된 모든 계정 항목을 추출한 다음, 재구성된 이전 상태를 기준으로 모든 트랜잭션을 순서대로 다시 실행합니다. 변경된 각 항목 (address, nonce, balance, codeFlag) 을 기록합니다.
     • zkVM: SNARK(상태 읽기, 실행 및 IL 규칙)를 검증하고 업데이트된 4중체의 stateDiff 사이드카 목록을 구문 분석합니다.
   • 적용: 수정된 계정 항목마다 로컬 테이블을 업데이트합니다.

3. 멤풀 가지치기

   • 각 테이블이 업데이트될 때마다 보낸 사람의 nonce가 오래되었거나, 잔액이 부족하거나, codeFlag 0에서 1로 바뀐 보류 중인 모든 거래를 삭제합니다(해당 주소에 대해 가장 우선순위가 높은 보류 중인 tx만 유지합니다).
   • 모든 블록을 헤드까지 처리한 후, 테이블은 완전히 최신 상태가 되고, mempool은 라이브 운영과 마찬가지로 유효한 것만 받아들이고 정리합니다.

VOPS 및 기본 계정 추상화(AA‑VOPS)

네이티브 계정 추상화(AA, EIP-7701 참조)는 중대한 패러다임 전환을 가져옵니다. 계정은 더 이상 고정된 검증 규칙을 가진 단순한 객체가 아니라, 임의의 코드를 실행할 수 있는 프로그래밍 가능한 개체입니다. 이러한 유연성은 nonce , balance , codeFlag 만 확인하면 거래 검증에 충분하다는 가정을 깨뜨립니다. 따라서 VOPS는 AA-VOPS 로 업그레이드되어야 합니다.

AA-VOPS는 전체 글로벌 상태 복제를 방지하여 노드를 가볍게 유지하면서 네이티브 AA를 지원하도록 VOPS를 확장합니다. 모든 노드가 모든 계정을 추적하도록 요구하는 대신, 각 노드는 적극적으로 관심 있는 계정(자신의 EOA 또는 상호 작용하는 EOA)만 추적하며, 시간이 지남에 따라 점진적으로 업데이트되는 작은 로컬 캐시를 유지합니다.

네이티브 AA는 강력한 새로운 기능을 제공하지만, 동시에 생태계를 강력한 무상태 설계에 더욱 가깝게 만들어 거래에 명시적인 증인(witness)을 포함해야 합니다. VOPS를 확장하여 AA-VOPS를 지원함에 따라, 완전한 네이티브 AA의 이점이 이러한 복잡성 증가를 정당화하는지, 아니면 더 단순한 VOPS 모델을 고수하는 것이 분산화와 효율성을 더 잘 유지하는 데 도움이 되는지 신중하게 고려해야 합니다.

AA-VOPS vs 강력한 무국적

강력한 무국적 상태를 위해서는 사용자가 모든 거래에 완전한 상태 증인을 첨부하여 모든 관련 계정과 저장 슬롯을 포괄해야 합니다.

반면, AA-VOPS는 노드가 자신의 EOA에 연결된 특정 계정에 대해서만 최신 증명을 유지할 수 있도록 합니다. 이러한 증명은 계정이 변경되지 않는 한 여러 블록에서 유효하며, 각 블록에 포함된 가벼운 stateDiffs 사용하여 갱신됩니다.

이를 통해 모든 거래에 많은 증인이 필요하지 않아 대역폭과 저장 공간 요구 사항을 최소화하는 동시에 검열 저항성과 거래 유효성을 유지할 수 있습니다.

AA-VOPS 작동 방식

로컬 캐시 및 증인 유지 관리

노드(또는 노드를 대신하여 작동하는 지갑이나 dApp 백엔드)는 다음을 유지합니다.

• 자체 계정 리프: nonce , balance , storageRoot , codeHash .
• 계정의 AA 논리에 필요한 추가 저장 슬롯입니다.
• 최근의 stateRoot 에 대해 이러한 필드를 인증하는 Merkle 또는 Verkle 경로 증인입니다.

증인은 이후 블록이 해당 필드를 수정할 때까지 유효합니다.

증인 부트스트래핑:

• 노드는 전체 노드나 RPC 제공자로부터 eth_getProof 사용하여 초기 리프와 경로를 한 번 가져옵니다(Reth에서는 이제 단일 RPC 호출로 모든 증인을 가져올 수 있습니다).

증분 업데이트:

모든 블록은 다음을 제공합니다

1. 간결하고 완전한 stateDiff (VOPS-with-zkVM과 같음).
2. IL 커밋 (예: 16개 IL 서명의 집계). 이 커밋을 통해 증명자는 블록 생산자가 로컬에서 관찰한 모든 IL을 커밋했는지 확인할 수 있습니다.
3. transactions , stateDiff 및 IL 준수 규칙을 함께 묶는 블록 수준 증명 (예: SNARK)입니다.

블록이 도착하면 노드는:

1. 블록 수준 증명을 검증하여 다음을 보장합니다.

   • stateDiff preStateRoot 에서 postStateRoot 로의 전환을 올바르게 인코딩합니다.
   • 포함된 모든 거래가 올바르게 실행되었습니다.
   • IL 세트의 각 거래는 포함되었거나 유효하게 제외되었습니다(블록이 가득 찼거나 거래가 이전 실행 후 무효화되었기 때문).

   (선택적 최적화: 블록 생산자는 제외된 각 IL 트랜잭션에 대해 "실패 힌트"를 첨부하여 실행 중 실패한 인덱스를 표시하고 증명자 작업 부하를 줄일 수 있습니다.)

2. 필요한 경우 증인에게 패치를 적용합니다.

   VOPS 노드(또는 자체 EOA를 추적하는 지갑/dapp)는 해당 계정 중 stateDiff 에 나타나는 것이 있는지 확인합니다.

   • 존재하는 경우 , 캐시된 리프를 업데이트하고 영향을 받은 Merkle/Verkle 경로를 다시 계산합니다.
   • 없는 경우 캐시된 증인은 새 stateRoot 에 대해 유효한 상태로 유지됩니다.

노드가 온라인 상태를 유지하고 모든 블록을 처리하면 부트스트래핑 후 아카이브 쿼리가 더 이상 필요하지 않습니다. 지연되는 경우, eth_getProof 통해 누락된 diff를 재생하거나 Witness 노드를 다시 시드할 수 있습니다.

거래 패키징

거래를 제출할 때:

• EOA 및 EIP-7702 계정의 경우 추가 증인이 필요하지 않습니다. 최소 계정 필드는 로컬에서 사용 가능합니다.
• EIP-7701 스마트 계정의 경우 간결한 단일 계정 유효성 증명(예: SNARK)이 첨부되어 계정 리프 포함과 올바른 VALIDATE 논리 실행을 모두 보여줍니다.

향후 AA 호환성

향후 AA 표준에서 VALIDATE 계정 외부에서 읽을 수 있도록 허용하면, 발신자는 연결된 증인의 폭을 넓혀 추가 저장 슬롯을 확보할 수 있습니다. 이 모델은 자연스럽게 확장됩니다.

멤풀 입장료

수신 노드는 캐시된 stateDiffs 사용하여 업데이트를 확인하여 참조된 stateRoot 에 대해 증인 또는 증명을 검증합니다.

• 차이 결과 계정이 변경되지 않은 경우 거래가 승인됩니다.
• diff가 계정이 변경 되었음을 나타내는 경우 증인은 오래되었으며 노드는 업데이트된 증명을 요청합니다.

실제로 노드는 트랜잭션 검증을 위해 다시 쿼리하지 않고도 최근의 stateDiff(예: 마지막 ~N 블록)의 슬라이딩 윈도우를 유지할 수도 있습니다.

AA-VOPS가 매력적인 이유

• 글로벌 복제 없음:

  각 노드는 8GiB(VOPS) 또는 ~233GiB(전체 상태)가 아닌, 몇 킬로바이트만 저장합니다. 블록 프로듀서와 RPC 제공자는 여전히 전체 상태를 필요로 합니다.

• AA 호환성:

  현재 EIP-7701 과 호환되며, 나중에 검증 로직이 외부 저장소를 읽는 경우 조정할 수 있습니다.

• 주문형 부트스트래핑:

  새로운 EOA를 추적하려면 노드가 단일 eth_getProof 한 번 가져와서 diff를 적용하여 최신 상태로 유지합니다.

상충관계

1. 더 높은 P2P 대역폭:

   모든 거래에는 자체적인 증인 또는 간결한 증명이 포함되며, 이로 인해 평균 거래 크기가 증가합니다(Verkle의 경우 약 736바이트, 이진 트리의 경우 약 1024바이트).

2. 사용자 측 증명 또는 가져오기:

   노드는 diff를 추적하거나 전체 노드에 쿼리를 보내 증명을 최신 상태로 유지해야 하는데, 이는 중앙 집중화 벡터의 영향을 받기 쉽습니다.

3. 부트스트래핑을 위한 전체 노드에 대한 종속성:

   VOPS와 달리 AA-VOPS는 계정 증명을 처음에 가져오기 위해 전체 노드 또는 RPC 제공자에 의존합니다. diff가 누락된 경우 노드는 eth_getProof 통해 다시 시드해야 하며, 소수의 제공자가 독점할 경우 중앙화 위험이 발생할 수 있습니다.

결론 및 주요 내용

유효성만 보장하는 부분 무상태 ( VOPS )는 노드의 로컬 스토리지 요구량을 압축 해제 시 약 8.4GiB (address, nonce, balance, codeFlag) 네 개로 줄이는 동시에 이더리움의 검열 저항 특성을 유지합니다. 이 접근 방식은 계정과 스토리지 슬롯 증가 간의 비대칭성을 활용합니다. 스토리지가 새로운 상태 항목의 증가를 계속 주도하는 한, 절감 효과는 상당합니다. 하지만 계정 생성 속도가 스토리지 증가 속도를 앞지르게 되면 상대적인 이점은 그에 따라 감소합니다.

VOPS는 원래 버전에서 두 가지 주요 장점을 가지고 있습니다. 첫째, 증인이 없는(witness-free) 메모리 풀입니다. 모든 노드가 각 EOA (address, nonce, balance, codeFlag) 의 쿼드러플릿을 저장하기 때문에 메모리 풀은 트랜잭션당 Merkle 또는 Verkle 증명을 필요로 하지 않습니다. 블록 단위 증명(예: zkEVM의 SNARK)은 각 블록의 전파에 수백 바이트만 추가하면서 완전한 정확성을 보장합니다. 둘째, 진정한 P2P 동기화입니다. 모든 노드가 모든 EOA에 대해 최소한의 상태를 유지하므로 추가 증명이나 개별 계정 데이터 없이 모든 피어에서 부트스트랩하거나 복원할 수 있어 전체 노드 또는 아카이브 노드에 대한 의존성을 제거합니다.

하지만 네이티브 AA를 지원하면 다른 상충 관계가 발생합니다. AA-VOPS는 각 거래에 최신 소형 증명을 첨부하여 로컬 스토리지 용량을 몇 킬로바이트로 줄입니다. 하지만 단점은 P2P 페이로드가 증가하고 새 계정 추적, 노드 부트스트랩, 오프라인 후 온라인 상태로 돌아올 때마다 전체 노드 또는 전용 서비스에 대한 호출이 간헐적으로 발생한다는 것입니다. 증명 기술과 SNARK가 지속적으로 개선됨에 따라 AA-VOPS는 완전한 무상태(stateless)로 가는 장기적이고 미래 지향적인 경로가 될 수 있습니다. 반면, 기존 VOPS는 거래 수준의 증인(witness)을 생략하여 원활한 사용자 경험을 유지하는 실용적인 단기 솔루션으로 돋보입니다.