원본 편집: GaryMa Wu Shuo 블록체인
Vitalik은 최근 Korean Blockchain Week, 싱가포르 연설, 심지어 Ethereum Executive Core Developer Conference(ACDE)에서 상태라는 주제를 공동으로 언급했으며, 이에 관련된 내용은 다음과 같습니다. ), 기록 데이터 만료(EIP-4444), Verkle 트리, 주소 공간 확장\압축(주소 공간 확장\압축)까지 포함합니다. 물론 이는 실제로 새로운 로드맵 조정 계획은 아니며, 지난해 11월 비탈릭이 발표한 이더리움 최신 로드맵에서는 주로 더 버지(The Verge)와 더 퍼지(The Purge)의 핵심 루트에 속한다.

이 기사에서는 Vitalik의 상태 솔루션 경로를 검토하기 위해 이 두 가지 주요 경로와 몇 가지 새로운 사고 과제를 결합합니다.
상태
이더리움의 상태는 모든 외부 소유 계정(EOA), 잔액, 스마트 계약 배포 및 관련 저장소를 포함하는 포괄적인 원장을 나타냅니다. 이 상태는 정적이 아니며, 새로운 사용자가 추가되고 새로운 스마트 계약이 배포됨에 따라 계속해서 확장됩니다.
현재 전체 노드는 블록을 적절하게 검증하고 올바른 상태 전환을 보장하기 위해 끊임없이 증가하는 이 데이터 세트를 저장해야 하며 검증 프로세스가 본질적으로 상태 저장되도록 해야 합니다. 이러한 증가하는 스토리지 요구 사항으로 인해 전체 노드를 실행하기 위한 하드웨어 요구 사항이 증가함에 따라 점점 더 중앙 집중화된 유효성 검사기로 이어질 것입니다.
etherscan.io/ 데이터에 따르면 현재 빠른 동기화 전체 노드를 실행하려면 최소 1200Gb가 필요합니다(Geth 클라이언트를 예로 들어). 이는 상태 정리가 수행된 후 이전 상태 데이터가 삭제되고 가장 많은 상태 데이터만 삭제됩니다. 최근 상태가 유지된다는 전제. 아카이브 노드, 즉 풀노드가 각 블록의 상태를 포함한 모든 과거 상태를 유지하게 된다면 필요한 용량은 약 15,400Gb 정도가 되며 앞으로도 계속해서 증가할 것이라는 점이다. 커뮤니티에서는 종종 상태 폭발이라고 부릅니다.

Vitalik이 Korea Blockchain Week에서 강조한 내용은 다음과 같습니다. 노드의 중앙화는 이더리움 네트워크가 직면한 가장 큰 문제 중 하나이며 노드를 더 저렴하고 실행하기 쉽게 만들어 해결해야 합니다.
이러한 일련의 과제를 해결하기 위해 이더리움 커뮤니티는 우리가 처음에 예시한 다양한 솔루션 개념을 개선하고 최적화할 수 있는 방법을 찾기 위해 열심히 노력해 왔습니다.
상태 솔루션
무국적
무상태의 핵심 개념은 상태 데이터를 외부화하여 각 노드가 완전한 상태를 저장할 필요를 없애는 것입니다. 이 모드에서 노드는 블록 헤더 및 관련 트랜잭션 정보만 유지하고 상태 증명(State Proofs)을 통해 상태를 검증하고 재구성하기만 하면 됩니다.
무상태의 주요 역할과 의미는 이더리움의 분산 특성을 유지하면서 노드의 저장 부담을 줄이고, 네트워크 확장성을 개선하며, 더 많은 노드가 쉽게 검증에 참여할 수 있도록 하는 것입니다.
버클 트리
현재 이더리움은 상태 데이터를 해시하고 압축하기 위해 Merkle-Patricia 트리를 사용합니다. 그러나 이러한 트리 구조의 머클 증명 크기는 너무 커져서 상태 비저장 모델에 필요한 증인에 적합하지 않게 될 수 있습니다.
이 문제를 해결하기 위해 이더리움은 보다 효율적인 데이터 구조인 Verkle 트리로 전환할 계획입니다. Merkle-Patricia 트리와 Verkle 트리는 둘 다 증인을 생성하는 중요한 기능을 공유합니다. 이는 누구든지 상태 루트에 있는 특정 정보의 존재와 공개 가용성을 쉽게 확인할 수 있는 암호화 증명입니다.
Verkle 트리의 장점은 더 작은 증거 크기를 생성하는 데 더 효율적이라는 것입니다.
히스토리 만료, EIP-4444
EIP-4444는 노드가 P2P 네트워크에서 1년이 넘은 과거 블록 호스팅을 중지하도록 요구하는 업그레이드인 과거 데이터 만료를 구현하는 것을 목표로 합니다. 기록 데이터를 제거하면 노드 운영자의 디스크 공간 요구 사항이 크게 줄어듭니다. 동시에, 다양한 버전의 기록 블록에 맞게 코드를 조정할 필요가 없어 클라이언트 소프트웨어도 단순화됩니다. 또한 EIP-4444와 PDS(Proto-danksharding)의 조합은 정기적인 데이터 정리를 보장합니다. EIP-4444는 1년에 한 번 정리하고 PDS는 한 달에 한 번 데이터 블록을 정리합니다. 이는 노드의 데이터 저장 요구 사항을 줄이는 데 도움이 되지만 기록 데이터의 보존 및 복구에 대한 우려도 제기합니다.
주 만료
무상태를 사용하면 블록을 검증할 때 검증자가 완전한 상태를 유지할 필요가 없습니다. 그러나 상태는 사라지지 않으며 지속적인 성장은 웹에 대한 장기적인 과제로 남아 있습니다.
이러한 근본적인 문제를 해결하기 위해 커뮤니티에서는 State Expiry 솔루션을 제안했습니다.
상태 만료는 1년 동안 변경되지 않은 상태로 유지되는 상태 부분을 자동으로 정리하여 별도의 트리 구조로 이동하고 기본 Ethereum 프로토콜에서 제거합니다.
상태 만료는 Verkle 트리로 마이그레이션한 후에만 가능하다는 점을 언급할 가치가 있습니다. 또한 Vitalik은 Korean Blockchain Week KBW 2023에서 다음과 같이 말했습니다. 무국적 및 PBS가 있는 경우 상태 만료의 우선순위가 낮을 수 있습니다.
왜냐하면 그때까지 제안자-빌더 분리(PBS)가 구현된다면, 무상태 상태에서 블록 빌더가 블록을 생성하기 위해 여전히 상태에 접근해야 하지만, 그 시점의 블록 빌더는 이미 예상했던 일이기 때문입니다. 이 영역은 어느 정도 중앙 집중화를 허용하기 때문에 상태 증가를 처리하므로 빌더의 노드 성능이 자연스럽게 요구를 충족할 수 있습니다.
프로토콜 수준 PBS는 아직 이더리움 메인 네트워크에 포함되지 않았지만, Mev-Boost PBS의 현재 시장 분포를 이해하면 메인 네트워크의 향후 추세를 대략적으로 이해할 수 있습니다. mevboost.pic의 데이터 통계는 다음과 같습니다.

또한 상태 만료 구현에는 이더리움 주소 형식 변경이 포함됩니다. 현재 주소 공간 확장과 주소 공간 압축이라는 두 가지 솔루션이 있습니다. 전자는 주소 길이를 32바이트(현재 주소 형식은 20바이트)로 늘리지만, 이전 버전과의 호환성을 위해 복잡한 논리가 필요하고 기존 계약도 업데이트해야 합니다. 후자는 20바이트 형식을 유지하지만 이전 계약을 변경합니다. 6바이트는 프리픽스와 주소주기를 식별하는데 사용되는데, 이는 호환성 문제를 크게 줄여주지만 또 다른 문제를 야기합니다.주소 길이는 14바이트에 불과하고 더 이상 충돌에 저항하는 기능이 없으므로 일부 주소가 도입됩니다. 생성된 잠재적인 보안 문제는 현재 커뮤니티가 직면한 주요 과제이기도 합니다.
요약하다
이제 위 기술 솔루션의 구현 문제와 우선순위를 기반으로 전면 및 후면 우선순위(2 \3 \4가 동일할 수 있음)를 대략적으로 제거할 수 있습니다.
1. 버클 트리
2. PBS
3. 무국적
4. 과거 데이터 만료(EIP-4444)
5. 이더리움 주소 형식 변경(압축/확장)
6. 상태 만료
요약하면, 노드 작동 임계값을 낮추고, 노드 분산화 및 잠재적인 상태 폭발 문제를 유지할 수 있으며, 상태 증가를 줄여 네트워크 통신 부하를 최적화할 수 있습니다.
물론 아직 갈 길이 멀다.
참조 링크:
https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356
https://public.bnbstatic.com/static/files/research/ethereum-beyond-the-merge-.pdf
https://www.fx168news.com/article/295525


