개요
archive node는 블록체인의 전체 상태 기록을 유지하므로, 모든 블록 높이에서 과거 상태를 조회할 수 있습니다. 이는 다음과 같은 경우에 유용합니다.- 과거 데이터를 제공해야 하는 블록 탐색기
- 분석 및 데이터 분석 애플리케이션
- 과거 상태를 조회해야 하는 서비스
- 디버깅 및 감사 목적
과거 블록에서 암호학적 상태 증명(
eth_getProof)만 필요한 경우, 과거 증명(historical proofs)은 전체 archive node보다 가벼운 대안입니다. 일반적인 사례는 출금 증명 및 결함 증명(fault proof) 워크로드입니다. 과거 실행(eth_call, debug_trace*)이나 임의의 과거 상태 조회가 필요한 경우에는 여전히 전체 archive node가 필요합니다. 과거 증명 구성을 참조하십시오.요구 사항
- OP Mainnet: bedrock datadir가 필요합니다
- 기타 OP Stack 네트워크: datadir가 필요하지 않습니다
- 스토리지: archive node는 일반 node보다 훨씬 많은 디스크 공간이 필요합니다(OP Mainnet의 경우 수 테라바이트)
- 동기화 시간: 실행 레이어 모드를 사용한 archive 동기화는 블록 단위로 전체를 실행하는 방식보다 빠릅니다
구성
아래 각 섹션은 archive node로 실행하기 위해op-node와 선택한 실행 클라이언트 모두에 필요한 전체 플래그를 보여 줍니다. op-node 플래그 --syncmode=execution-layer는 모든 경우에 필수이며 기본값이 아니므로 반드시 명시적으로 구성해야 합니다.
op-reth
op-reth는 프루닝 플래그 없이 실행하면 전체 상태를 보존하므로, 표준 op-node + op-reth 구성만으로도 archive node가 됩니다.op-node에 설정합니다.
--prune.* 플래그를 전달하지 마십시오. 전체 기록이 필요하지 않고 디스크 공간을 확보하려면 아래의 op-reth 프루닝을 참조하십시오.
Nethermind
op-node에 설정합니다.
op-mainnet_archive를 네트워크에 맞는 archive 구성으로 바꾸십시오(예: OP Sepolia의 경우 op-sepolia_archive).op-geth
op-node에 설정합니다.
op-geth에 설정합니다.
두 플래그 모두 기본 설정이 아니므로 명시적으로 구성해야 합니다.
--syncmode=full 플래그는 모든 블록이 실행되도록 보장하며, --gcmode=archive는 상태 프루닝을 비활성화합니다.Pruning op-reth
완전한 archive node가 필요하지 않다면 op-reth를 프루닝하여 디스크 공간을 확보할 수 있습니다. 권장 방식은 모든 블록 본문을 유지하면서 state와 receipt를 프루닝하는 것입니다.권장: state와 receipt를 프루닝하고 블록 본문은 유지
state 및 receipt 세그먼트를 프루닝하고 블록 본문은 그대로 유지합니다. 각 항목에 동일한 깊이를 설정하십시오.<depth>(블록 단위)는 다음과 같습니다.
- sequencer 측 node의 경우
22000— 12시간의 시퀀싱 윈도우(2초 블록 시간 기준 약 21,600 블록)를 포함합니다. - 더 많은 기록이 필요한 node의 경우
1296000(2초 기준 약 30일).
블록 본문 프루닝(지원되지 않음)
op-node의 safe 도출(derivation)은 tip에서--syncmode.offset-el-safe만큼 뒤에 위치한 head의 블록 본문에서 L1-info 입금(디파짓) 트랜잭션(모든 블록의 첫 번째 트랜잭션)을 읽으며, safedb를 복원하는 경우에는 그보다 더 뒤에서 읽을 수도 있습니다. 해당 본문이 프루닝된 경우 EL 동기화는 l2 block is missing L1 info deposit tx 오류와 함께 실패합니다.
따라서 본문 프루닝은 지원되지 않으며, 사용하지 않을 것을 권고합니다. 사용할 경우 보장 없이 본인의 책임하에 실행하게 됩니다. 무엇을 하는지 잘 알고 있다면 작동하게 만들 수 있지만, 한 가지 엄격한 요구 사항이 있습니다. 보존되는 본문 윈도우가 항상 --syncmode.offset-el-safe 범위를 포함해야 합니다. 구체적으로, --prune.bodies.distance(블록 단위)를 블록으로 환산한 offset(기본값 12h는 2초 블록 시간 기준 약 21,600)보다 충분히 크게 설정하고, 실제로 사용하는 블록 시간과 offset에 맞게 여유를 두십시오. 또한 safedb를 복원하는 경우 해당 head까지의 최대 거리도 고려해야 합니다.
op-reth는 시작 시 --minimal을 거부합니다. 이 옵션은 본문을 고정된 10,064 블록 윈도우로 프루닝하는데, 이는 기본 offset보다 작으며 독립적으로 늘릴 수 없습니다.
archive 동기화의 작동 방식
실행 레이어 동기화 모드가 활성화되면 다음과 같이 동작합니다.- 초기 동기화: node가 P2P 네트워크를 통해 블록 헤더와 데이터를 다운로드합니다
- 블록 실행: node가 체인의 모든 블록을 실행하여 전체 상태 기록을 구축합니다
- 상태 보존: 일반 node와 달리 archive node는 과거 상태 데이터를 절대 프루닝하지 않습니다
- 레거시보다 빠름: 여전히 모든 블록을 실행하지만, 블록 데이터를 L1에서 도출하는 대신 P2P를 통해 가져오므로 레거시 합의 레이어 동기화보다 빠릅니다
스토리지 고려 사항
archive node에는 상당한 스토리지가 필요합니다.- OP Mainnet: 수 테라바이트이며 계속 증가합니다
- 기타 네트워크: 네트워크의 운영 기간과 활동량에 따라 다릅니다
- 증가율: 새 블록이 추가됨에 따라 스토리지 요구량이 지속적으로 증가합니다
- 권장 사항: 최적의 성능을 위해 빠른 SSD 스토리지를 사용하십시오
다음 단계
- archive가 아닌 node의 동기화 구성은 동기화 모드 레퍼런스를 참조하십시오
- 추가 설명이나 사용자 지정은 합의 클라이언트 구성 및 실행 클라이언트 구성 가이드를 참조하십시오
- bedrock datadir 다운로드에 대한 정보는 스냅샷 가이드를 참조하십시오
- 이 과정의 어느 단계에서든 어려움이 있으면 개발자 지원에 문의하십시오