저자: 비탈릭, 이더리움 창립자, 번역: 골든 파이낸스 샤오저우
네트워크 보안에 대한 우려를 제외하고 L1 가스 캡을 올리는 것에 대한 가장 일반적인 비판 중 하나는 풀 노드의 운영이 더 어려워질 것이라는 점입니다. 더 어려워집니다. 특히 '전체 노드의 번들 해제'를 중심으로 하는 로드맵의 맥락에서 이 문제를 해결하려면 전체 노드가 무엇을 의미하는지에 대한 이해가 필요합니다.
일반적인 통념은 플레넘이 온체인 데이터의 유효성을 검사하는 데 사용된다는 것입니다. 이것이 유일한 문제라면, ZK-EVM은 L1 확장을 가능하게 합니다. 유일한 제한은 블록 구성과 증명 비용을 낮게 유지하여 검열 저항을 1로 유지하면서도 경쟁 시장을 형성할 수 있을 만큼 낮게 유지하는 것입니다.
그러나 실제로는 이것이 유일한 고려 사항은 아닙니다. 또 다른 중요한 요소는 풀 노드를 운영하면 신뢰할 수 없고 검열에 저항하며 프라이버시를 보호하는 방식으로 온체인 데이터를 읽을 수 있는 로컬 RPC 서버를 보유할 수 있다는 것입니다. 이 글에서는 이 목표를 달성하기 위해 현재 L1 확장 로드맵을 어떻게 조정할 수 있는지에 대해 설명합니다.
1. ZK-EVM+PIR이 제공하는 탈신뢰 및 개인정보 보호에 만족하지 않는 이유는 무엇인가요?
지난달에 발표한 개인정보 보호 로드맵에서는 단기적으로 TEEs+ORAM 솔루션을 채택하고 장기적으로는 PIR 기술로 전환할 것을 권고했습니다. 헬리오스 및 ZK-EVM 검증과 결합하면 외부 RPC에 연결하는 사용자는 (i) 획득한 체인 데이터가 정확하고 (ii) 데이터 개인정보가 보호된다는 것을 완전히 확신할 수 있습니다. 그렇다면 여기서 멈추지 않는 이유는 무엇일까요? 이러한 고급 암호화 체계가 자체 호스팅 노드를 쓸모없게 만들까요?
이에 대한 몇 가지 답변이 있습니다.
- 완전히 탈신뢰화된 암호화 체계(예: 단일 서버 PIR)는 비용이 많이 듭니다. 현재 오버헤드는 비현실적으로 높으며 많은 효율성 최적화 후에도 여전히 높을 수 있습니다.
-- 메타데이터 개인정보 보호 문제. 요청 시간, 요청 패턴, IP 주소에 대한 기타 메타데이터와 같은 메타데이터는 본질적으로 많은 사용자 정보를 노출합니다.
--검열 취약성: 소수의 RPC 제공업체가 지배하는 시장 구조에서는 강력한 사용자 차단 또는 검열 압력에 직면하게 됩니다. 많은 RPC 제공업체가 특정 국가를 완전히 차단하기 시작했습니다.
따라서 개별 노드의 운영 편의성을 계속 보호할 가치가 여전히 있습니다.
2. 단기 우선순위
EIP-4444의 전체 배포를 우선시하여 궁극적으로 각 노드가 다음과 같은 목표만 약 36일 분량의 데이터만 저장합니다. 이렇게 되면 현재 노드 운영을 방해하는 가장 큰 장애물인 하드 드라이브 공간 요구 사항이 크게 줄어들 것입니다. 이후 노드 스토리지 요구사항에는 (i) 상태 데이터, (ii) 상태 머클 브랜치, (iii) 36일간의 과거 데이터만 포함될 것입니다.
각 노드가 소량의 오래된 기록 데이터를 저장할 수 있는 분산 기록 저장 체계를 구축합니다. 코드 수정 기술을 통해 안정성을 극대화합니다. 이를 통해 중앙화된 공급자에 의존하거나 노드 운영자에게 큰 부담을 주지 않고도 '블록체인 불멸성'을 보장할 수 있습니다.
가스 가격 책정 전략을 조정하여 저장 비용을 늘리고 실행 비용을 줄입니다. (i) 새 스토리지 슬롯을 위한 SSTORE 실행, (ii) 컨트랙트 코드 생성, (iii) 제로 밸런스/제로 논스 계정으로 이더를 전송하는 데 드는 가스 비용을 높이는 데 집중합니다.
3 중간 목표: 상태 비저장 인증
상태 비저장 인증이 구현되면 RPC 지원 노드(즉, 상태를 저장하는 노드)는 상태 머클 브랜치를 저장할 필요가 없습니다. 이렇게 하면 스토리지 요구 사항을 최대 50%까지 줄일 수 있습니다.
4. 새로운 유형의 노드: 부분적으로 상태가 없는 노드
이 혁신적인 아이디어는 L1 가스 캡이 10-100배 증가한 후에도 개별 노드를 계속 실행할 수 있도록 하는 것입니다. 키입니다.
새로운 노드 유형이 추가되었습니다. 블록을 검증하는 스테이트리스 방식, 즉 스테이트리스 검증 또는 ZK-EVM으로 전체 체인을 검증하지만 상태 데이터의 일부만 유지하는 방식입니다. 노드는 필요한 데이터가 해당 상태의 하위 집합 내에 있는 한 RPC 요청에 응답할 수 있으며, 다른 요청은 실패하거나 외부에서 호스팅되는 암호화 솔루션으로 되돌아가야 합니다(되돌아갈지 여부는 사용자가 선택해야 함).

특히 유지되는 상태는 다음과 같이 사용자의 구성에 따라 달라집니다.
-- 알려진 정크 컨트랙트를 제외한 모든 상태를 제외합니다.
-- 모든 EOA, SCW 계정 및 일반적으로 사용되는 ERC20/ERC721 토큰 및 애플리케이션과 관련된 상태.
-- 지난 2년 동안 활성화된 EOA/SCW 계정 상태 + 일부 일반 ERC20 토큰 상태 + 선택한 스왑/DeFi/프라이버시 앱 상태.
온체인 컨트랙트를 통해 구성 관리 가능: 사용자는 노드를 실행할 때 "--save_state_by_config 0x12345...67890". .67890" 매개변수를 사용하여 노드를 실행하면 노드가 실시간으로 저장하고 업데이트해야 하는 주소, 스토리지 슬롯 또는 상태 필터 목록을 특정 언어로 정의할 수 있습니다. 사용자는 Merkle 브랜치를 저장할 필요 없이 원래 값만 저장하면 됩니다.
이 유형의 노드는 중요한 상태에 직접 로컬로 액세스할 수 있는 이점을 제공하는 동시에 완벽한 액세스 프라이버시를 보장합니다.