특별히 Micah Zoltu, Toni Wahrstätter, Justin Traglia, pcaversaccio와의 토론에 감사드립니다
L1 가스 한도를 높이는 것에 대한 가장 일반적인 비판은, 네트워크 안전에 대한 우려를 넘어서, 풀 노드를 실행하기 어렵게 만든다는 것입니다.
특히 풀 노드의 분리에 초점을 맞춘 로드맵의 맥락에서, 이를 해결하려면 풀 노드의 목적을 이해해야 합니다.
역사적으로 풀 노드는 체인을 검증하기 위한 것이라고 생각되어 왔습니다. 일반 사용자가 검증할 수 없는 경우 발생할 수 있는 상황에 대해서는 여기를 참조하세요. 이것이 유일한 문제라면, L1 확장은 ZK-EVM에 의해 열립니다: 유일한 제한은 블록 빌딩 및 증명 비용을 낮게 유지하여 둘 다 검열 저항성을 유지하고 경쟁 시장을 유지하는 것입니다.
하지만 실제로 이것이 유일한 우려사항은 아닙니다. 다른 주요 우려사항은 다음과 같습니다: 체인을 무신뢰성, 검열 저항성 및 개인정보 보호 친화적인 방식으로 읽을 수 있는 로컬 RPC 서버를 가질 수 있도록 풀 노드를 유지하는 것이 중요합니다. 이 문서는 이를 가능하게 하는 현재 L1 확장 로드맵의 조정에 대해 논의할 것입니다.
ZK-EVM + PIR를 통한 무신뢰성과 개인정보 보호로 충분하지 않은 이유
지난달에 발표한 개인정보 보호 로드맵은 단기 패치로 TEEs + ORAM, 장기 솔루션으로 PIR에 중점을 둡니다. 이는 Helios 및 ZK-EVM 검증과 함께 모든 사용자가 외부 RPC에 연결하여 (i) 받고 있는 체인이 정확하고, (ii) 데이터 개인정보 보호가 보장된다는 확신을 가질 수 있게 합니다. 따라서 여기서 멈추면 안 되는 이유가 무엇인지 묻는 것이 가치가 있습니다. 이러한 고급 암호화 솔루션이 자체 호스팅 노드를 시대에 뒤떨어진 유물로 만들지 않을까요?
여기에 대해 몇 가지 답변을 드릴 수 있습니다:
- 완전히 무신뢰성인 암호화 솔루션(즉, 1-서버 PIR)은 비용이 많이 듭니다. 현재 오버헤드가 실용적이지 않으며, 많은 효율성 개선 후에도 여전히 비용이 많이 들 가능성이 높습니다.
- 메타데이터 개인정보 보호. 어떤 IP 주소가 언제 요청을 하는지, 그리고 요청 패턴 자체가 사용자에 대한 많은 정보를 드러내기에 충분합니다.
- 검열 취약성: 소수의 RPC 제공업체가 지배하는 시장 구조는 사용자를 퇴출하거나 검열할 강한 압박을 받게 됩니다. 많은 RPC 제공업체가 이미 전체 국가를 제외하고 있습니다.
이러한 이유로 개인 노드 실행의 용이성을 계속 보장하는 것에 가치가 있습니다.
단기 우선순위
- EIP-4444의 완전한 롤아웃을 우선시하여 각 노드가 약 36일 동안만 데이터를 저장하는 최종 상태까지 진행합니다. 이는 더 많은 사람들이 노드를 실행하는 것을 방해하는 주요 문제인 디스크 공간 요구 사항을 크게 줄입니다. 이후 노드의 디스크 공간 요구 사항은 (i) 상태 크기, (ii) 상태 머클 브랜치, (iii) 36일 분량의 이력이 됩니다.
- 분산 이력 저장 솔루션을 구축하여 각 노드가 삭제 시점보다 오래된 이력 데이터의 작은 비율을 저장할 수 있도록 합니다. 소거 코딩을 사용하여 강건성을 최대화합니다. 이를 통해 중앙집중식 제공업체에 의존하지 않고 또는 노드 운영자에게 큰 부담을 주지 않고도 "블록체인은 영원하다"는 특성을 보장할 수 있습니다.
- 저장소를 더 비싸게 하고 실행을 덜 비싸게 만들도록 가스 가격을 조정합니다. 특히 우선순위가 높은 것은 새로운 상태 생성 가스 비용을 높이는 것입니다: (i) 새로운 저장소 슬롯에 대한 SSTORE, (ii) 계약 코드 생성, (iii) 아직 잔액이나 논스가 없는 계정에 ETH 전송.
중기 우선순위: 상태 없는 검증
상태 없는 검증을 가능하게 하면 상태 머클 브랜치를 저장하지 않고도 RPC 기능을 갖춘 노드(즉, 상태를 저장하는 노드)를 실행할 수 있게 됩니다. 이는 저장소 요구 사항을 추가로 약 2배 감소시킵니다.
새로운 유형의 노드: 부분적으로 상태 없는 노드
이것이 새로운 아이디어이며, L1 가스 한도가 10-100배 성장하는 상황에서도 개인 노드 운영을 허용하는 핵심이 될 것입니다.
블록을 상태 없이 검증하고 전체 체인을 검증하는(상태 없는 검증 또는 ZK-EVM을 통해) 노드 유형을 추가하고 상태의 일부를 최신 상태로 유지합니다. 노드는 필요한 데이터가 해당 상태 하위 집합 내에 있는 한 RPC 요청에 응답할 수 있습니다. 다른 요청은 실패하거나(또는 외부에서 호스팅되는 암호화 솔루션으로 대체되며, 이를 수행할지 여부는 사용자의 선택에 따라 달라집니다).
사용자가 선택한 구성에 따라 저장할 상태의 정확한 부분이 달라집니다. 몇 가지 예는 다음과 같습니다:
- 스팸으로 알려진 계약을 제외한 모든 상태
- 모든 EOA 및 SCW와 일반적으로 사용되는 ERC20 및 ERC721 토큰 및 애플리케이션과 관련된 상태
- 지난 2년 동안 액세스된 모든 EOA 및 SCW와 관련된 상태, 일부 일반적으로 사용되는 ERC20 토큰, 그리고 제한된 큐레이션된 스왑, DeFi 및 개인정보 보호 애플리케이션
구성은 온체인 계약에 의해 관리될 수 있습니다: 사용자는 --save_state_by_config 0x12345...67890로 노드를 실행하며, 주소는 노드가 저장하고 최신 상태로 유지할 주소, 저장소 슬롯 또는 기타 필터링된 상태 영역 목록을 일종의 언어로 지정합니다. 사용자가 머클 브랜치를 저장할 필요는 없으며 원시 값만 저장하면 됩니다.
이 유형의 노드는 사용자가 신경 쓰는 상태에 대한 직접적인 로컬 액세스의 이점과 해당 상태에 대한 최대한의 완전한 개인정보 보호 액세스를 제공할 것입니다.
