메인 콘텐츠로 건너뛰기
이 페이지에서는 op-reth 명령줄 인터페이스(CLI)가 어떻게 구성되어 있는지 설명합니다. 이를 통해 적절한 명령을 찾고 해당 명령의 구성이 어디에서 오는지 이해할 수 있습니다. node를 설치하고 시작하려면 실행 클라이언트 구성을 따르십시오. 모든 명령의 전체 플래그 목록은 생성된 CLI 레퍼런스를 참조하십시오.

하나의 바이너리, 여러 명령

op-reth는 단일 바이너리로 제공됩니다. 일상적으로 실행하는 명령은 실행 클라이언트 자체를 시작하는 op-reth node입니다. 나머지 하위 명령은 운영 도구입니다. 대부분은 동일한 데이터 디렉터리를 대상으로 초기화, 히스토리 가져오기, 검사, 복구 작업을 수행하므로 node가 실행 중일 때 사용하는 경우는 드뭅니다. 일부(config 및 dump-genesis)는 단순히 정보를 stdout으로 출력합니다. CLI 레퍼런스도 이 구조를 그대로 따릅니다. 각 페이지는 op-reth <command> --help의 출력을 보여 주며, 중첩된 하위 명령(예: op-reth db stats)은 별도의 중첩 페이지를 가집니다.

node 실행

node는 체인을 동기화하고 제공하는 장기 실행 명령입니다. 플래그가 가장 많은 명령이며, 플래그는 Metrics, Datadir, Networking, RPC, TxPool, Builder, Debug, Dev testnet, Pruning, Engine, Rollup 등의 기능 그룹으로 구성되어 있습니다. 관련 플래그는 점으로 구분된 접두사를 공유합니다(예: --txpool.*, --prune.*, --rollup.*, RPC 그룹의 --http.*). Rollup 그룹은 OP Stack 전용입니다. --rollup.sequencer (트랜잭션이 전달되는 sequencer 엔드포인트)나 --rollup.disable-tx-pool-gossip 같은 플래그는 OP Stack 체인에만 존재하는 동작을 구성합니다. 이에 대한 예시는 실행 클라이언트 구성에서 다룹니다.

초기화 및 가져오기

init와 init-state는 네트워크에서 동기화하는 대신 각각 genesis 파일 또는 상태 덤프 파일로 새 데이터베이스를 생성합니다. import-op와 import-receipts-op는 OP Stack 전용 작업 하나를 위해 존재합니다. 바로 Bedrock 마이그레이션 이전의 OP Mainnet 히스토리를 불러오는 작업입니다. 이 히스토리는 재실행할 수 없으므로 파일에서 가져옵니다. OP Mainnet 동기화에서 이 명령이 필요한 경우를 설명합니다. 대부분의 운영자는 init-state를 사용하는 최소 부트스트랩 방식을 사용하며 Bedrock 이전 데이터 가져오기는 완전히 건너뜁니다.

검사 및 유지 관리

나머지 명령은 진단 및 유지 관리 도구입니다.
  • db는 데이터베이스를 검사하고 복구합니다. 테이블 통계, 체크섬, 데이터베이스 간 차이, 스토리지 설정 등을 다룹니다.
  • stage는 reth의 단계별 동기화(staged-sync) 파이프라인에 있는 개별 stage(execution, account hashing, merkle 등)를 실행, 삭제, 덤프 또는 unwind합니다. 처음부터 다시 시작하지 않고 동기화의 일부를 디버깅하거나 재실행할 때 유용합니다.
  • p2p는 네트워킹 계층을 디버깅합니다. peer로부터 단일 헤더 또는 바디 다운로드, RLPx 유틸리티, bootnode 실행 등을 지원합니다.
  • config와 dump-genesis는 실제 적용되는 구성과 체인의 genesis JSON을 stdout으로 출력합니다.
  • prune과 re-execute는 무거운 유지 관리 작업입니다. 각각 구성에 따라 과거 데이터를 프루닝하고, 블록을 병렬로 재실행하여 과거 동기화가 올바른 결과를 생성했는지 검증합니다.

체인 선택과 Superchain Registry

체인 데이터를 다루는 모든 명령은 --chain <CHAIN_OR_PATH>를 받습니다. 이 값에는 내장 체인 이름 또는 체인 사양 파일의 경로를 지정할 수 있습니다. 기본값은 optimism(OP Mainnet)입니다. 내장 이름은 Superchain Registry에서 가져옵니다. op-reth는 빌드 시점에 레지스트리의 체인 구성을 바이너리에 포함합니다. 따라서 base, unichain, ink, mode, zora 및 이들의 Sepolia 대응 체인(예: unichain-sepolia)은 추가 구성 파일 없이 이름만으로 사용할 수 있습니다. 내장 체인의 전체 목록은 node 레퍼런스의 --chain 항목에 있습니다. 레지스트리에 없는 체인의 경우 해당 체인 사양 파일의 경로를 대신 전달하십시오.

구성의 출처

op-reth는 주로 CLI 플래그를 통해 구성됩니다. 도움말 텍스트 (및 생성된 레퍼런스)의 세 가지 규칙으로 플래그의 동작을 알 수 있습니다.
  • 기본값 — 기본값이 있는 모든 플래그는 이를 [default: ...]로 표시합니다. 예를 들어 --datadir의 기본값은 OS별 데이터 디렉터리(Linux의 경우 $HOME/.local/share/reth/ 또는 $XDG_DATA_HOME/reth/)입니다.
  • 환경 변수 — 환경 변수로도 설정할 수 있는 플래그는 이를 [env: ...]로 표시합니다. OpenTelemetry 내보내기 플래그(--logs-otlp, --tracing-otlp)가 그 예입니다.
  • 공유 그룹 — 모든 하위 명령은 동일한 Logging, Display, Tracing 옵션을 받습니다. 따라서 -vvv나 --log.file.directory는 op-reth db stats에서도 op-reth node에서와 동일하게 동작합니다.
구성 파일은 플래그를 보완합니다. op-reth node --config <FILE>로 node가 구성 파일을 사용하도록 지정할 수 있으며, op-reth config는 최종 구성을 stdout으로 출력합니다(op-reth config --default는 기본값을 표시합니다). 이는 파일을 통해 무엇을 구성할 수 있는지 확인하는 가장 빠른 방법입니다.

다음 단계