피드백을 주신 Guillaume Ballet과 Tanish Jasoria에게 감사드리고, 이 주제에 관해 이전에 토론에 참여해 주신 Stateless Implementors Call 참가자들에게도 감사드립니다.

이 기사에서는 상태 트리 사전 이미지 생성 주제에 대해 자세히 살펴보겠습니다. 여기에는 다음이 포함됩니다.

• 이 주제가 프로토콜 발전에 어떻게 들어맞는지 이해할 수 있을 만큼 충분한 맥락을 설명하세요.
• 문제를 제대로 이해하려면 이더리움 개선 제안(EIP)-7612 및 이더리움 개선 제안(EIP)-7748에 대한 개략적인 설명이 필요합니다.
• 사전 이미지에 대한 잠재적인 파일 형식을 제안하고 더 복잡한 형식이 가치가 있는지 분석합니다.
• 비아카이브 reth를 사용하여 사전 이미지 파일을 생성하고 검증하고 이 문서에 사용된 데이터를 생성하여 재생산할 수 있도록 새로운 사전 이미지 도구를 제공합니다.

미래의 트리 변환을 위해 사전 이미지를 생성하는 것이 필요한 이유를 알고 있다면 컨텍스트 섹션을 건너뛰세요.

문맥

로드맵의 Verge 부분은 현재의 Merkle Patricia Trie(MPT)를 새로운 트리로 대체하는 것을 제안하는데, 이는 무국적 상태를 달성하고 L1을 더욱 SNARK화하는 데 더 효율적입니다.

오늘의 주요 트리 후보는 Verkle Trees( 이더리움 개선 제안(EIP)-6800 )와 Binary Tree( 이더리움 개선 제안(EIP)-7864 )입니다. 이 이분법에 대해 더 알고 싶다면 이더리움 개선 제안(EIP)-7864 토론 스레드를 읽어보세요. 이 기사의 주제는 이 결정과 무관 하므로 미래의 어떤 경로든 가정할 수 있습니다.

새로운 트리를 사용했기 때문에 기존 데이터를 MPT에서 새로운 트리로 옮기는 전략이 필요합니다. 오늘 제안하는 전략은 오버레이 트리( 이더리움 개선 제안(EIP)-7612 + 이더리움 개선 제안(EIP)-7748 )로 데이터를 변환하는 것입니다. 나중에 살펴보겠습니다.

계정의 데이터(논스, balance, code 해시)를 MPT에서 새 트리로 옮기고 싶다고 가정해 보겠습니다. MPT의 트리 키는 keccack(address) 이지만 새 트리에서는 new_key(address) 이고, 여기서 new_key 반드시 keccak 필요는 없습니다. EL 클라이언트는 트리의 각 키에 대한 기본 사전 이미지(이 경우 address )에 액세스할 수 있어야 합니다. keccack(address) 만 있는 경우 new_key(address) 계산하는 것이 불가능해집니다. 계정 상태 시도에도 동일하게 적용됩니다.

숏 말해서, MPT에서 새로운 대상 트리로 상태 변환을 거치는 네트워크의 모든 노드는 계정 및 저장 시도에 대한 모든 MPT 키 사전 이미지를 확인할 수 있어야 합니다.

EL 클라이언트가 트리 키 사전 이미지를 저장하지 않습니까?

불행히도, 그렇지 않습니다. EL 클라이언트의 현재 아키텍처와 데이터베이스 디자인에 따라 이러한 사전 이미지는 기존 데이터에서 계산될 수 있지만, 이는 소수의 클라이언트에만 적용됩니다.

트리 키 사전 이미지와 클라이언트 데이터베이스 간의 관계에 대한 몇 가지 예:

• Geth는 트리를 사용하는 것보다 더 빠르게 상태에 액세스하기 위한 flatdb를 가지고 있습니다. 이 데이터베이스의 키는 계정의 해시된 값이거나 계정 해시 와 스토리지 슬롯 해시의 연결입니다. 해시, 해시 기반 키입니다. 해시된 버전의 키를 사용하는 것은 동기화에 의미가 있으며, 사전 이미지를 저장하는 추가 스토리지를 정당화할 만한 실제적인 인센티브는 없었습니다.
• Erigon과 Reth도 flatdb를 가지고 있지만 이 데이터베이스의 키는 해시되지 않은 트리 키로 되어 있어 이 문제에 매우 편리합니다.
• Nethermind에는 아직 flatdb가 없으므로 상태 액세스를 위해 트리에 효율적으로 액세스해야 하지만, 곧 (키 해시된) flatdb를 도입할 계획입니다.

즉, Erigon 또는 Reth 노드가 아니면 트리 키의 실제 사전 이미지가 없습니다. ethernodes.org 에 따르면 Erigon+Reth가 아닌 노드가 네트워크의 80% 이상을 차지하므로 네트워크 대부분이 이 사전 이미지 문제를 가지고 있습니다. Erigon 또는 Reth 노드의 경우에도 사전 이미지를 얻을 수 있다고 해서 오늘날 효율적으로 해결할 수 있는 방법이 있는 것은 아닙니다. 이를 더 잘 이해하기 위해 그 이유를 더 자세히 살펴보겠습니다.

트리 변환에 프리이미지는 어떻게 사용되나요?

오버레이 트리 와 상태 변환 EIP가 함께 작동하는 방식을 이해하면 이 질문에 더 잘 답할 수 있습니다. 이더리움 개선 제안(EIP) 읽을 수 있지만, 사전 이미지 논의를 계속하기 위해 압축된 요약이 있습니다.

이더리움 개선 제안(EIP)-7612 요약

참고: 이 이더리움 개선 제안(EIP) Verkle을 참조하지만, 아이디어는 대상 트리에 독립적이므로 이진 트리에서도 작동합니다.

이더리움 개선 제안(EIP)-7612는 프로토콜에 새로운 트리가 도입되는 방식을 설명합니다.

• MPT는 포크(Fork) 블록 에서 읽기 전용(즉, 동결)이 됩니다.
• 새로운 빈 트리가 생성됩니다(예: Verkle 또는 Binary).
• 블록 실행으로 인한 상태 업데이트는 새 트리에만 기록됩니다.
• 부작용으로, 트리만 사용하여 상태를 읽는 것은 새로운 트리를 읽고, 항목을 찾을 수 없으면 MPT를 확인하는 것을 의미합니다.

요약하자면, 베이스 트리(MPT)가 동결되고, 최상위 트리(Verkle 또는 Binary)가 새로 시작되어 쓰기를 수신하는 2단계(즉, 오버레이 ) 트리입니다. 마지막 글머리 기호와 관련하여 EL 클라이언트는 상태에 액세스하기 위한 flatdb를 가지고 있으므로 반드시 더블 트리 조회를 해야 한다는 의미는 아닙니다.

이더리움 개선 제안(EIP)-7748 요약

이제 이더리움 개선 제안(EIP)-7612를 이해했으므로 이더리움 개선 제안(EIP)-7748이 적용됩니다.

• 정의된 블록 타임스탬프( CONVERSION_START_TIMESTAMP )에서 변환 프로세스가 시작됩니다. 이더리움 개선 제안(EIP)-7612 활성화와 CONVERSION_START_TIMESTAMP 사이에 충분한 시간이 있어야 MPT가 동결되었음을 보장할 수 있습니다(즉, 체인 마무리가 있어서 reorg가 사실을 변경할 수 없음)
• 다음 블록 에서는 거래가 실행되기 전에:
  • MPT에서 CONVERSION_STRIDE 트리 항목을 결정적으로 가져옵니다.
    • 트리 항목 의 개념은 이더리움 개선 제안(EIP) 에서 더 정확하게 정의되어 있습니다(즉, 변환 단위 라는 이름이 지정됨). 여기서는 비트(Bit) 단순화하고 있습니다.
    • CONVERSION_STRIDE 값은 블록 실행 상태 변환 오버헤드와 전체 변환 기간 간의 균형이기 때문에 아직 TBD입니다. 적절한 값은 대상 트리가 어느 것인지에 따라 달라지는데, Verkle은 Binary보다 재해싱 비용이 더 많이 들기 때문입니다.
  • 이더리움 개선 제안(EIP)-7612가 ​​활성화되었기 때문에 블록 실행이 이 MPT 키에 대해 이미 새 값을 썼을 수 있으며, 이 값은 재정의되어서는 안 됩니다. 값이 오래된 것이 아니면 최상위 트리에 복사합니다.
• 모든 MPT 키 탐색을 마칠 때까지 위의 작업을 계속합니다.

트랜잭션이 실행되기 전에 상태 변환 단계가 수행된다는 설계 결정은 EL 클라이언트가 다음 블록 이 도착하기 전에 상태 변환 단계를 수행할 수 있기 때문에 유익합니다.

이 프로세스에 대한 사전 이미지 파일과 관련된 주요 사실은 MPT 항목에서 반복하는 순서입니다. 현재 제안된 순서는 MPT(s)에서 전체 깊이 우선 워크(DFW)를 수행하는 것입니다. 계정 트라이에서 DFW를 수행하고 리프에 도달하면 계정 트라이에서 워크를 계속하기 전에 계정 저장소 트라이에서 DFW를 수행합니다. 먼저 계정 저장소 슬롯을 마이그레이션한 다음 계정의 데이터를 마이그레이션합니다.

더 잘 이해하기 위해 예를 살펴보겠습니다. CONVERSION_STRIDE 가 5이고 상태 변환의 첫 번째 블록 에 있다고 가정해 보겠습니다. 다음은 워크에서 볼 수 있는 MPT 항목입니다.

1. 계정 trie 키 0x000000abc... 는 keccak(address_A) 와 같습니다. address_A 에는 두 개의 스토리지 슬롯이 있는 스토리지 trie가 있으므로 DFW로 들어갑니다.
   1. 1단계: 키 0x0000131... 을 갖는 계정 address_A 스토리지 트리는 keccack(storage_slot_A) 와 같습니다. 즉, address_A 의 storage_slot_A 값을 새 트리로 마이그레이션합니다.
   2. 2단계: 키 0x0003012... 를 갖는 계정 address_A 스토리지 트리는 keccack(storage_slot_B) 와 같습니다. 즉, address_A 의 storage_slot_B 값을 새 트리로 마이그레이션합니다.
   3. 3단계: 모든 저장 슬롯을 마이그레이션했으므로 이제 address_A 계정 논스, balance, code를 마이그레이션합니다.
2. 계정 트리 키 0x000000ffa... keccak(address_B) 와 같습니다. address_B 는 EOA입니다.
   1. 4단계: 스토리지 슬롯이 없으므로 스토리지 트리에서 DFW가 수행되지 않습니다. address_B 계정 논스, balance 및 code를 마이그레이션합니다.
3. 계정 trie 키 0x000005630... 는 keccak(address_C) 와 같습니다. address_C 에는 1000개의 스토리지 슬롯이 있는 스토리지 trie가 있으므로 DFW합니다.
   1. 5단계: 키 0x0000021... 을 갖는 계정 address_C 스토리지 트리는 keccack(storage_slot_A) 와 같습니다. 즉, address_C 의 storage_slot_A 값을 새 트리로 마이그레이션합니다.

다음 사항에 유의하세요.

• 계정 트라이와 잠재적 트라이의 워킹 순서는 주소나 일반 스토리지 슬롯 값이 아닌 해시 기반입니다. 이는 키가 주소나 스토리지 슬롯의 해시이기 때문에 트라이의 DFW의 결과입니다.
• address_A 와 address_C 의 storage_slot_A 는 다른 숫자(예: 각각 10과 24)입니다. 이는 스토리지 시도에서 DFW를 걷는 동안 발견된 첫 번째 스토리지 슬롯을 의미합니다. 이전 글머리 기호에서 언급했듯이 스토리지 슬롯 워킹 순서는 해시 기반이며 "자연스러운" 순서가 아니므로 storage_slot_A storage_slot_B 보다 클 수 있습니다.
• 위에서 언급한 사항은 또한 사전 이미지가 필요한 이유입니다. 첫 번째 키는 값 0x000000abb 를 가지고 있으며, 이 값이 주소 address_A 에 해당한다는 것을 알아야 새 트리에 어떤 키가 있는지 확인하기 위해 다시 해시할 수 있습니다.
• 마지막으로 마이그레이션된 항목은 account_C 의 첫 번째 스토리지 슬롯일 뿐이지만, 여전히 99개의 슬롯이 남았습니다. CONVERSION_STRIDE 제한에 이미 도달했기 때문에 다음 블록 에서 계속 마이그레이션할 것입니다!

이 이더리움 개선 제안(EIP) 에 대한 자세한 내용은 여기에서 확인할 수 있으며, 설명을 보완하는 몇 가지 시각적 자료도 제공됩니다.

리캡

위의 내용을 통해 다음과 같은 사실이 명확해졌기를 바랍니다.

• 사전 이미지 파일에는 고정된 MPT 계정 트리에 있는 모든 기존 address_X 포함되어야 합니다.
• 사전 이미지 파일에는 모든 동결된 MPT 스토리지 시도에 있는 모든 기존 storage_slot_X 포함되어야 합니다.
• MPT가 고정되어 있고 워크가 결정적이므로 사전 이미지가 필요한 순서는 미리 완전히 결정됩니다.

프리이미지 파일

이제 이 사전 이미지 파일의 다양한 차원을 살펴보겠습니다.

• 분포
• 검증 가능성
• 생성 및 인코딩
• 용법

이 글의 주요 초점은 생성 및 인코딩 이지만, 완전성을 위해 다른 차원에 대해서도 언급합니다. 생성 섹션에 도달할 때까지 이 파일이 마법처럼 생성되고 인코딩되었다고 가정하세요.

분포

사전 이미지 파일이 어떻게 생성되었는지를 감안할 때, 이 파일은 어떻게 네트워크의 모든 노드에 도달합니까? 이 주제는 Stateless Implementers Calls(SIC) , L1 이벤트 워크숍 및 비공식 토론에서 여러 번 탐구되었습니다.

많은 (하지만 전체적으로는 샘플이 작음) 핵심 개발자들과 이야기를 나눈 결과, 현재는 클라이언트가 여러 잠재적 CDN을 통해 파일을 다운로드하는 것이 괜찮을 것이라는 합의 많습니다. 이는 포털 네트워크, 프로토콜 내 배포 또는 블록 사전 이미지 포함에 의존하는 것과 비교됩니다.

논의된 다른 옵션은 다음과 같습니다.

• 프로토콜 내 배포 메커니즘을 갖추고 있습니다.
• 필요한 사전 이미지를 각 블록 에 포장하여 배포합니다.

이 주제는 이러한 옵션이 복잡성, 프로토콜 핫패스에서 필요한 대역폭, 압축 기회와 관련하여 서로 다른 상충 관계를 가지고 있기 때문에 매우 논란이 많습니다. 많은 핵심 개발자와 이야기를 나누었음에도 불구하고 ACD가 동일한 결론에 도달할 것이라고 결론 내릴 만큼 대표성이 충분하지 않습니다.

이 문서에서는 파일이 어떻게 배포되는지와 상관없이 반드시 수행해야 하는 사전 이미지 생성 및 인코딩 형식에 대해 중점적으로 설명합니다.

검증 가능성

위에서 언급했듯이, 전체 노드는 잠재적으로 신뢰할 수 없는 당사자 또는 해킹된 공급망일 수 있는 어딘가에서 이 파일을 수신합니다. 파일이 손상되었거나 유효하지 않은 경우 전체 노드는 변환 프로세스의 어느 시점에서 차단됩니다.

이 파일은 설명된 트리 워크를 수행하고, 예상되는 프리이미지를 읽고, 케칵 해시 계산하고, 클라이언트의 기대치와 일치하는지 확인하여 쉽게 검증할 수 있습니다. 이 파일이 검증되면 변환이 시작될 때마다 안전하게 사용할 수 있으며, 클라이언트가 프리이미지를 해결하여 차단되지 않는다는 보장이 있습니다. 이 보장은 변환 기간 동안 네트워크의 안정성에 중요합니다. 이 검증 시간은 이더리움 개선 제안(EIP)-7612 활성화와 이더리움 개선 제안(EIP)-7748 CONVERSION_START_TIMESTAMP 타임스탬프*.* 사이의 시간 지연에서 고려해야 합니다.

물론, 이 파일을 검증하는 다른 방법은 더 빠르지만 더 많은 가정이 필요합니다. 예를 들어, 파일을 생성하는 모든 사람이 동일한 출력을 얻을 것이므로 클라이언트 팀은 스스로 생성하여 파일의 해시/체크섬을 하드코딩할 수 있습니다. 파일이 다운로드/가져오면 검증은 파일의 해시 를 하드코딩된 해시와 비교할 수 있습니다.

생성 및 인코딩

이제 파일에 어떤 정보가 포함되어야 하는지, 그리고 어떤 순서로 이 정보에 액세스해야 하는지 알았으므로, 이 데이터를 파일에 인코딩하는 방법을 고려할 수 있습니다. 이상적으로는 다음 속성을 만족하는 인코딩이 필요합니다.

• 예상되는 읽기 패턴에 맞게 최적화합니다. 상태 변환은 메인 체인이 실행되는 동안 백그라운드에서 수행되는 작업이므로, 필요한 정보를 읽는 것이 효율적일 것입니다.
• 크기에 맞게 최적화: 앞서 언급했듯이, 파일은 어떻게든 분산되어야 합니다. 대역폭은 귀중한 자원입니다. 적게 사용하는 것이 더 좋습니다.
• 낮은 복잡성: 이 파일은 한 번만 사용되므로 간단한 인코딩 형식이 좋습니다. 사양을 정하고 테스트하는 데 시간이 오래 걸리는 반면 뛰어난 이점을 제공하지 않는 한, 새로운 복잡한 형식을 만들어 바퀴를 다시 발명하는 것은 의미가 없습니다.

이전에 살펴본 예를 따라 다음과 같이 설명할 수 있는 매우 간단하고 명확한 후보 인코딩이 있습니다. [address_A][storage_slot_A][storage_slot_B][address_B][address_C][storage_slot_A]... . 우리는 예상되는 워킹 순서로 서로 옆에 있는 원시 사전 이미지를 직접 연결합니다.

이 인코딩에는 다음과 같은 이점이 있습니다.

• 인코딩 형식은 접두사 바이트가 필요하지 않으므로 오버헤드가 없습니다. 사전 이미지 항목의 크기가 다르지만(주소의 경우 20바이트, 스토리지 슬롯의 경우 32바이트), EL 클라이언트는 트리 워크에서 주소 또는 스토리지 슬롯을 해결해야 하는지 여부에 따라 다음에 읽을 바이트 수를 알 수 있습니다.
• EL 클라이언트는 항상 파일의 forward-linear read를 수행하므로 임의 액세스가 없습니다. 다가올 Usage 섹션에서 이에 대해 자세히 설명합니다.

이 인코딩의 효율성을 더 자세히 살펴보기 전에, 메인넷을 위해 이 파일을 생성하고 크기를 파악해 보겠습니다. 이를 위해, 우리는 동기화된 reth 전체 노드(즉, 반드시 아카이브가 아님)를 사용하여 생성, 검증 및 나중에 제시될 다른 분석을 수행하는 도구를 만들었습니다 . 얼마 전에 geth 도구를 만들었지만, --cache.preimages 플래그가 활성화된 genesis에서 동기화되는 노드가 필요합니다.

preimages generate --datadir <...> --eip7748 실행하여 사전 이미지 파일을 만들 수 있습니다. 중간급 머신에서 생성된 파일에 대한 몇 가지 사실은 다음과 같습니다.

• 생성 시간: ~1시간
• 압축되지 않은 파일 크기: 42GiB
• 압축된 파일 크기(zstd): 36GiB

Reth(또는 잠재적으로 Erigon) 노드를 실행하는 네트워크에서 누구나 파일을 생성할 수 있으며, 고정된 MPT가 주어지면 사전 이미지가 고정되므로 출력은 항상 동일합니다.

인코딩 효율성에 대해 더 자세히 알아보기

인코딩 포맷의 인코딩 오버헤드가 0임에도 불구하고, 압축 및 비압축 크기 차이는 압축 기회를 나타냅니다. 그 이유를 살펴보겠습니다.

우리는 파일의 각 사전 이미지 항목을 두 개의 버킷에 넣을 수 있습니다.

• 주소 사전 이미지
  • 중복 제거
    • 계정 트리에는 각 계정에 대한 고유 정보가 포함되어 있으므로 모든 [address_X] 항목은 파일에서 고유하며, 따라서 중복 제거 기회가 없습니다.
  • 압축:
    • 주소는 해시이므로 압축할 수 없습니다.
• 저장 슬롯 사전 이미지
  • 중복 제거
    • 여러 계약이 저장 슬롯 사용에서 겹칠 수 있기 때문에(실제로 겹치기도 함) 파일에서 이러한 내용이 반복됩니다. 예를 들어, 여러 계약이 저장 슬롯 0, 1, 2를 사용합니다.
    • 반복되는 저장 슬롯의 가장 큰 그룹은 0x00000... 접두사를 공유하므로 최상위 슬롯입니다(예: 이전에 언급한 슬롯).
    • 계약에 배열이나 해시맵이 있는 경우 해싱이 변수를 저장 슬롯에 매핑하는 방식의 특성으로 인해 저장 슬롯 공간에서 저장 슬롯이 더 분산됩니다.
  • 압축
    • 스토리지 슬롯의 압축 기회는 다양합니다. 예를 들어, 0x00000.. 접두사가 있는 스토리지 슬롯(즉, 최상위 계약 변수)은 많은 0바이트가 있으므로 매우 압축 가능합니다. 다른 스토리지 슬롯은 주로 해시의 결과이며, 그렇게 압축 가능하지는 않습니다(하지만 "중복 제거 가능").

요약하자면, 주소는 중복 제거나 압축이 불가능하지만 스토리지 슬롯은 중복 제거/압축될 수 있는 기회가 있습니다. 그러나 영향이 얼마나 클지, 그리고 그럴 가치가 있는지 알기는 어렵습니다.

더 심층적인 분석을 하려면 preimage storage-slot-freq 분석 도구를 실행할 수 있습니다. 먼저 출력을 살펴보겠습니다.

 Database block number: 21662206 Top 1000 storage slot 29 -byte prefix repetitions: 0000000000000000000000000000000000000000000000000000000000 : 57150357 ( 4.65 %) ~1580MiB (cumm 1580MiB)f3f7a9fe364faab93b216da50a3214154f22a0a2b415b23a84c8169e8b: 13671109 ( 1.11 %) ~378MiB (cumm 1958MiB)8a35acfbc15ff81a39ae7d344fd709f28e8600b4aa8c65c6b64bfe7fe3: 9429136 ( 0.77 %) ~260MiB (cumm 2219MiB)f652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f37: 8580073 ( 0.70 %) ~237MiB (cumm 2456MiB)405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3: 7750842 ( 0.63 %) ~214MiB (cumm 2671MiB)a66cc928b5edb82af9bd49922954155ab7b0942694bea4ce44661d9a87: 3545488 ( 0.29 %) ~98MiB (cumm 2769MiB)c2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f: 2663837 ( 0.22 %) ~73MiB (cumm 2842MiB)...

(전체 출력은 더 길며 여기에서 확인할 수 있습니다)

이 프로그램은 예를 들어 00000....00 과 같은 접두사가 있는 동일한 29바이트 접두사를 가진 저장 슬롯의 수를 계산합니다.

• 저장 슬롯은 약 5,700만 개로 전체의 4.65%를 차지합니다.
• 이는 사전 이미지 파일 크기의 약 1580MiB에 매핑됩니다.
• cumm 값은 현재 행까지의 크기의 합계입니다. 예를 들어, 상위 3개 스토리지 슬롯 사전 이미지 접두사는 사전 이미지 파일의 2219MiB를 차지합니다.

두 번째, 세 번째, 그 다음 행의 값은 무엇인지 궁금할 것입니다.

• f3f7... 은 keccak(0x000000..08) 입니다
• 8a35... 는 keccak(0x000000..04) 입니다

이러한 접두사는 많은 계약이 각각 스토리지 슬롯 8과 4에 배열을 정의했기 때문에 나타납니다. 즉, 사전 이미지 파일의 값은 해당 슬롯 번호의 해시 입니다. 배열의 항목은 이 기본 값에서 연속적이므로 이러한 "최상위 수준 배열"은 사전 이미지 파일의 최상위 접두사입니다.

접두사에 29바이트를 선택하는 데 특별한 것은 없습니다. 아이디어는 최상위 변수와 배열을 그룹화하는 것입니다. 해시맵의 경우 항목이 스토리지 슬롯 공간 전체에 분산되므로 중복 제거 기회가 줄어듭니다. 계약 변수에서 더 많은 "중첩"이 발생하면 가능성이 더 낮아집니다. 그렇기 때문에 최상위 접두사가 최상위 배열이므로 의미가 있습니다.

전체 출력 링크(Chainlink) 를 보면, 상위 1000개 접두사는 ~4GiB를 차지하는데, 이는 zstd를 통해 얻은 ~6GiB 압축에 가깝습니다. 물론, 꼬리가 매우 길기 때문에 최적의 크기가 더 좋을 수 있습니다.

파일 형식의 일부로 중복 제거를 시도하면 파일 형식 사양의 복잡성이 증가합니다. RAM에 보관할 상위 N개의 사전 이미지를 분리하여 준선형 읽기를 보존하는 방법이 있을 수 있습니다. 그래도 크기를 약간 줄이는 간단한 형식+zstd와 비교했을 때 복잡성이 더 크다면 가치가 없을 수 있습니다. 이것은 한 번만 다운로드한다는 것을 기억하세요. 슬롯 기간의 중요하지 않은 부분에 다운로드하거나 별도의 인터넷 링크를 통해 다운로드할 수 있습니다(하지만 수동 작업이 필요합니다).

zstd가 많이 사용되는 압축 도구이기는 하지만 EL 클라이언트에 대한 새로운 종속성을 추가한다는 점에 유의하세요. 또한 파일을 압축 해제하는 데 추가 시간 공간이 필요할 수 있습니다(하지만 이를 피할 수 있는 방법이 있을 수 있음 ). 어떤 경우든 이 기사의 주요 목표는 스토리지 슬롯 크기의 꼬리가 어떻게 작동하는지에 대한 실제 측정을 제공하고 이 주제에 대한 더 많은 토론을 초대하는 것입니다.

용법

EL 클라이언트가 이 파일을 어떻게 사용할 수 있는지에 대한 몇 가지 사실을 언급하는 것이 좋습니다.

• 파일은 선형적으로 읽히므로, 다음 블록 의 시작 부분에서 읽기를 계속할 위치를 나타내는 커서를 유지하는 것이 유용합니다.
• 마지막 X 블록에 대한 커서 위치 목록을 유지하면 reorg를 처리하는 데 도움이 됩니다. reorg가 발생하면 해당 위치에서 다시 파일을 찾는 것이 매우 쉽습니다.
• 클라이언트는 슬롯에서 대부분 유휴 상태인 동안 다음 X 블록의 사전 이미지를 메모리에 미리 로드하여 블록 핫 경로 실행에서 추가 IO를 피할 수도 있습니다.
• 디스크에 전체 파일을 보관하는 것이 너무 성가시다면 체인 마무리 지점을 지난 오래된 값을 삭제할 수 있습니다. 이것이 추가적인 복잡성을 감수할 만한 가치가 있는지 의심스럽지만, EL 클라이언트 팀에 달려 있는 구현 세부 사항입니다.

결론

이 글에서는 트리 변환 프로토콜 진화의 맥락에서 사전 이미지 파일의 맥락, 문제, 솔루션 공간을 살펴보았습니다. 여기에 제시된 아이디어 중 어느 것도 최종적인 것이 아니며 ACD에서 명확한 합의 있을 것으로 기대되지 않습니다.

주된 목표는 커뮤니티에서 가능한 한 많은 사람들의 레벨을 높일 수 있을 만큼 충분히 심층적인 설명을 제공하고, 지속적으로 발전하며, 이 주제에 대한 향후 ACD 토론을 가속화하는 리소스로 활용되기를 바랍니다.