작성자: 비탈릭, 이더리움(ETH) 창시자; 번역: 진써차이징(Jinse) 샤오저우
L1 가스 상한선 향상에 대한 가장 흔한 비판은 네트워크 보안 우려 외에도 전체 노드 운영을 더욱 어렵게 만든다는 것입니다. 특히 "전체 노드 해제"를 핵심으로 하는 로드맵 배경에서 이 문제를 해결하려면 먼저 전체 노드의 존재 의미를 이해해야 합니다.
전통적인 관점에서 전체 노드는 온체인 데이터를 검증하는 데 사용됩니다. 이것이 유일한 문제라면 ZK-EVM은 L1 확장을 해제할 수 있습니다: 유일한 제한은 블록 구축 및 증명 비용을 충분히 낮게 유지하여 둘 다 1 of n의 검열 저항성을 유지하면서 경쟁적 시장을 형성할 수 있도록 하는 것입니다.
하지만 현실에서 이것이 유일한 고려 사항은 아닙니다. 또 다른 중요한 요인은 다음과 같습니다: 전체 노드를 운영하면 로컬 RPC 서버를 가질 수 있어 신뢰 없이, 검열 저항적이며 개인정보를 보호하는 방식으로 온체인 데이터를 읽을 수 있습니다. 본 글에서는 이 목표를 달성하기 위해 현재 L1 확장 로드맵을 어떻게 조정할 수 있는지 논의하겠습니다.
1. ZK-EVM+PIR로 구현된 신뢰 해제 및 개인정보 보호에 만족하지 않는 이유
제가 지난달 발표한 개인정보 보호 로드맵은 단기적으로 TEEs+ORAM 방식을 채택하고 장기적으로 PIR 기술로 전환할 것을 주장했습니다. Helios와 ZK-EVM 검증을 결합하면 사용자는 외부 RPC에 연결할 때 완전히 확신할 수 있습니다: (i) 얻은 체인 데이터가 정확하고, (ii) 데이터 개인정보가 보호됩니다. 이는 다음과 같은 질문을 제기합니다: 왜 여기서 멈추지 않는가? 이러한 고급 암호학 방안이 자체 호스팅 노드를 시대에 뒤떨어진 것으로 만들지 않을까요?
이에 대해 몇 가지 답변이 있습니다:
--완전히 신뢰 해제된 암호학 방안(예: 단일 서버 PIR)의 비용이 높습니다. 현재 비용이 너무 높아 비현실적이며, 여러 번의 효율성 최적화 후에도 여전히 높은 가격을 유지할 수 있습니다.
--메타데이터 개인정보 보호 문제. IP 주소의 요청 시간, 요청 패턴 등의 메타데이터 자체가 많은 사용자 정보를 노출할 수 있습니다.
--검열 취약성: 소수의 RPC 공급자가 주도하는 시장 구조는 강력한 사용자 차단 또는 검열 압력에 직면할 것입니다. 많은 RPC 제공업체가 이미 특정 국가를 완전히 차단하기 시작했습니다.
따라서 개인 노드 운영의 편의성을 계속 보장하는 것은 여전히 가치가 있습니다.
2. 단기 우선순위
EIP-4444의 전면 배포를 우선시하여 최종적으로 각 노드가 약 36일의 데이터만 저장하도록 합니다. 이는 하드 디스크 공간 요구 사항을 크게 줄일 것입니다 - 현재 사람들이 노드 운영을 방해하는 주요 장애물입니다. 이후 노드 저장 요구 사항에는 다음만 포함됩니다: (i) 상태 데이터, (ii) 상태 머클 브랜치, (iii) 36일의 기록 데이터.
분산 기록 저장 솔루션을 구축하여 각 노드가 적은 양의 만료된 기록 데이터를 저장하도록 합니다. 삭제 코드 기술을 통해 신뢰성을 최대화합니다. 이렇게 하면 "블록체인 영구 보존" 특성을 보장하면서 중앙화된 공급자에 의존하거나 노드 운영자에게 무거운 부담을 주지 않을 수 있습니다.
가스 가격 책정 전략을 조정하여 저장 비용을 높이고 실행 비용을 낮춥니다. 다음 작업의 가스 비용을 높이는 데 중점을 둡니다: (i) 새 저장소 슬롯에 대한 SSTORE 실행, (ii) 계약 코드 생성, (iii) 제로 잔액/제로 논스 계정으로 이더리움(ETH) 전송.
3. 중기 목표: 무상태 검증
무상태 검증을 구현한 후, RPC를 지원하는 노드(즉, 상태를 저장하는 노드)는 상태 머클 브랜치를 저장할 필요가 없습니다. 이를 통해 저장 요구 사항을 약 50% 더 줄일 수 있습니다.
4. 새로운 노드 유형: 부분 무상태 노드
이 혁신적인 개념은 L1 가스 상한선이 10-100배 향상된 후에도 개인 노드 운영을 유지하는 핵심이 될 것입니다.
우리는 새로운 노드 유형을 추가합니다: 무상태 방식으로 블록을 검증하고, 무상태 검증 또는 ZK-EVM 검증을 통해 전체 체인을 검증하지만 부분 상태 데이터만 유지합니다. RPC 요청에 필요한 데이터가 해당 상태 하위 집합 내에 있는 경우 노드는 응답할 수 있습니다. 다른 요청은 실패하거나(또는 외부 호스팅된 암호학적 솔루션으로 대체해야 함 - 대체 여부는 사용자가 선택) 합니다.
구체적으로 어떤 상태를 유지할지는 사용자 구성에 따라 달라집니다. 예를 들어:
--알려진 쓰레기 계약을 제외한 모든 상태.
--모든 EOA, SCW 계정 및 일반적인 ERC20/ERC721 토큰 및 애플리케이션과 관련된 상태.
--최근 2년 내 활성화된 EOA/SCW 계정 상태 + 일부 일반적인 ERC20 토큰 상태 + 엄선된 스왑/디파이/개인정보 보호 애플리케이션 상태.
구성은 온체인 계약을 통해 관리할 수 있습니다: 사용자가 노드를 실행할 때 "--save_state_by_config 0x12345...67890" 매개변수를 사용하며, 해당 주소는 노드가 저장하고 실시간으로 업데이트해야 하는 주소 목록, 저장소 슬롯 또는 상태 필터 규칙을 특정 언어로 정의합니다. 사용자는 머클 브랜치를 저장할 필요가 없으며 원시 값만 저장하면 됩니다.
이러한 노드는 핵심 상태에 대한 로컬 직접 액세스의 이점을 제공하면서도 완전한 액세스 개인정보 보호를 보장할 수 있습니다.
