이 글에서는 이더리움의 역사를 분산 저장하는 비교적 간단하고 잘 통합된 접근 방식과 상태 저장을 위한 확장 방법을 설명합니다.
1단계: 블록 내용을 blob에 넣기
이더리움의 히스토리를 블롭(blob)에 담았습니다. 자연스러운 방법은 블록 본문을 직렬화하고 블롭으로 분할하는 get_blobs(block_body) -> List[Blob] 함수를 사용하는 것입니다. 그런 다음 블록 헤더의 블롭 버전 해시 목록에서 첫 번째 블롭 버전 해시가 [get_versioned_hash(blob) for blob in get_blobs(block.body)] 와 같아야 합니다.
편의상 CL 본문의 블롭과 EL 본문의 블롭(예: ExecutionPayload )을 분리할 수 있습니다. 그러면 ZK-EVM 증명에 버전이 지정된 블록 만 공개 증인으로 포함할 수 있습니다. 이렇게 하면 (i) 헤더 다운로드, (ii) 블롭에 대한 DAS 검사, (iii) CL 부분만 다운로드하여 직접 검증, (iv) ZK-EVM 증명 검증을 통해 블록을 검증할 수 있습니다. 완전한 린 합의 기능이 도입되면 CL 부분도 ZK 증명을 받게 되고, 완전한 "헤더, DAS 및 증명" 체인을 갖게 됩니다.
페이로드 청킹을 수행하고 몇 가지 상수를 조정하면 위의 내용을 더 깔끔하게 만들 수 있습니다. 특히, (i) 이더리움 개선 제안(EIP)-7976을 적용하고 0바이트와 0이 아닌 바이트에 대해 동일한 가스 가격을 적용하고, (ii) 블롭을 양자 저항(혹은 그 이전 버전)으로 업그레이드할 때 블롭 크기를 늘리면 각 페이로드 청크가 하나의 블롭에 들어갈 수 있다는 보장을 얻을 수 있습니다(!!). 예를 들어, calldata 비용을 바이트당 64가스로 설정하면 이더리움 개선 제안(EIP)-7825 덕분에 직렬화된 tx가 256kB 미만으로 제한됩니다. 따라서 블롭 크기를 256kB로 설정하면 이 보장을 얻을 수 있습니다.
블록 수준 액세스 목록에도 동일한 작업을 수행해야 하며, 여기에는 각 구성 요소와 조합에 대해 "바이트당 64가스" 불변성이 반영되도록 하는 작업이 포함됩니다.
2단계: 무작위 블롭 기록 저장
각 클라이언트가 자신이 보는 각 블롭의 무작위로 선택된 샘플 하나를 저장해야 한다는 규칙을 추가합니다. 만약 다음과 같은 경우:
- PeerDAS 대역폭을 최대화하기 위해 샘플 크기를 512바이트(현재 2048바이트에서 축소)로 설정합니다.
- 슬롯당 평균 64,256kB 크기의 블롭(16MB)을 공격적으로 가정합니다. 이는 현 상태와 비교하여 L2 블롭 공간이 약 20배 증가하거나 현재 가스 제한의 약 128배 또는 두 가지를 혼합하기에 충분합니다.
그러면 우리는 다음을 얻습니다:
- 각 클라이언트는 각 블롭의 1/512를 저장하므로 모든 블롭을 복구하려면 블롭의 50% 이상을 저장하려면 약 710개의 정직한 노드(중복으로 인해 512개 이상)가 필요합니다.
- 각 클라이언트의 부하는 (슬롯당 128개의 블롭으로 공격적으로)
512 * 62 * 31556926 / 12바이트 = 연간 80GB가 되며 이는 합의 노드에 부과하는 합리적인 추가 부하와 거의 일치합니다.
블롭에 대한 쿼리는 기존 DAS 메커니즘을 재활용하거나 동기화 프로세스에 더 최적화된 전용 프로토콜을 만드는 방식으로 수행할 수 있습니다.
3단계: 저장 공간 추가
실제로 이 작업에는 아무런 작업이 필요하지 않습니다. 블록 수준 액세스 목록이 블롭에 포함되어 있다면, 이미 알고 있는 최신 상태(필요한 경우 병합 시점 스냅샷)에서 블롭을 동기화하고 업데이트를 재생하여 현재 상태를 계산할 수 있습니다. 필요한 경우 "왼쪽에서 오른쪽으로 트리를 반복적으로 탐색"하는 메커니즘을 추가할 수도 있지만, 복잡성을 감수할 만한 가치가 있는지는 불분명합니다.
