op-node와 kona-node, execution
레이어의 op-reth, 그리고 특수 목적의 op-supernode와 레거시 Geth입니다.
지원 상태는 시간이 지나면서 변경됩니다. 이 페이지의 정보는 위의
last-reviewed 날짜 기준이며, 각 외부 링크에서 이를 다시 확인할 수 있습니다.
이 가이드가 적합한 대상
다음과 같은 경우 이 가이드를 사용하십시오.- OP Stack 체인(OP Mainnet, 다른 OP Stack 체인 또는 자체 체인)의 새 node에 사용할 소프트웨어를 선택하거나, op-geth 지원 종료 이후 기존 node를 재평가하는 경우.
- 설정 명령보다는 선택 근거를 알고 싶은 경우.
시작하기 전에
다음 사항을 미리 알고 있어야 합니다.- node가 서비스하는 네트워크와 그 네트워크가 superchain-registry에 등록되어 있는지 여부(레지스트리 체인은 두 consensus 클라이언트 모두에서 이름으로 선택할 수 있으며, 사용자 지정 체인은 자체 구성을 제공합니다).
- node가 수행하는 역할: 공개 RPC, 개인 검증자(verifier), sequencer, 결함 증명(fault proof) 인프라 또는 아카이브/분석. 5단계는 이를 기준으로 합니다.
- 하드웨어 사양 범위. 시스템 요구 사항을 읽고, OP Mainnet의 기본 사양이 16 GB RAM이라는 점과 아카이브 node는 수 테라바이트의 NVMe가 필요하며 full node보다 훨씬 빠르게 증가한다는 점을 파악하십시오.
1단계: 구조 확정: consensus 클라이언트 하나, execution 클라이언트 하나
모든 OP Stack node는 두 개의 프로세스로 구성됩니다. 정식 체인을 파생하고 전달하는 consensus 클라이언트(rollup node)와 EVM을 실행하고 상태를 보관하는 execution 클라이언트이며, 이 둘은 인증된 Engine API를 통해 1:1로 연결됩니다. node 아키텍처 개요를 읽고 다음을 파악하십시오.- 두 클라이언트의 분리 구조와 각 RPC가 어느 쪽에 있는지. 여러분은 하나가 아니라 두 가지 클라이언트를 선택해야 합니다.
- 1:1 규칙: 하나의 consensus 클라이언트 뒤에 여러 execution 클라이언트를 두거나 그 반대로 구성해서는 절대 안 됩니다. 두 클라이언트 구성 가이드(3단계와 4단계에서 읽을 문서) 모두 이 경고로 시작합니다.
2단계: 지원이 종료된 소프트웨어 배제
지원 종료 공지를 읽고 2026-07-21 기준으로 다음을 파악하십시오.- op-geth는 어떤 새 node에도 후보가 될 수 없습니다. 위의 경고를 참조하십시오.
- op-program 역시 지원이 종료되었으며, 결함 증명에서는 kona-client로 대체되었습니다. 이는 일반적인 node 선택이 아니라 5단계의 결함 증명 행에 영향을 줍니다.
- op-node는 지원 중단(deprecated)되지 않았으며, kona-node는 어떤 용도에도 필수가 아닙니다. kona-client로의 결함 증명 마이그레이션은 일반 op-node와 함께 작동합니다.
3단계: execution 클라이언트 선택
execution 클라이언트 구성 가이드를 읽고 각 클라이언트의 최소 구성과 전체 레퍼런스의 위치를 파악하십시오. 선택 로직은 다음과 같습니다.
Nethermind처럼 Optimism 외부에서 유지 관리되는 서드파티 execution 클라이언트도
있습니다. 이러한 클라이언트는 이 문서가 아니라 각자의 문서를 통해 구성되고
지원됩니다.
동기화 이후가 아니라 지금 결정해야 할 op-reth 후속 사항이 두 가지 있습니다.
- 아카이브 또는 full: op-reth는 기본적으로 아카이브 node입니다. pruning된 full node를
원하면
--full을 전달하십시오. body pruning은 지원되지 않습니다. op-reth pruning을 참조하십시오. - 과거 증명(historical proofs): 무허가형(permissionless) 결함 증명 체인에서 출금 증명을 제공하는 인프라에는 historical-proofs 저장소가 필요합니다 (op-reth v2.2.3 이상). 과거 증명 튜토리얼을 따르십시오. 이 저장소는 활성화한 시점부터 앞으로만 채워지므로, 늦게 활성화한 node는 그만큼의 기간 동안 실행될 때까지 전체 보존 기간을 제공할 수 없습니다. 5단계에서 node 역할별로 결정하십시오.
4단계: consensus 클라이언트 선택
consensus 클라이언트 구성 가이드를 읽고 각 클라이언트의 최소 플래그와 sequencer용 추가 설정을 파악하십시오. 선택 로직은 다음과 같습니다.
조합에 관한 참고 사항: op-node의
--l2.enginekind 플래그는 Engine API 동작을
execution 클라이언트에 맞게 조정하며, 기본값이 reth이므로 3단계의 기본값에는
추가 플래그가 필요하지 않습니다. 다른 값은
consensus 클라이언트 가이드에서
다룹니다.
5단계: 조합을 node의 역할에 맞추기
node 역할별로 두 선택을 연결하는 로직은 다음과 같습니다.6단계: 배포 및 선택 검증
Docker node 튜토리얼(op-reth + op-node를 하나의 compose 파일로 구성) 또는 소스 빌드 튜토리얼로 조합을 구동한 다음, 선택한 행에 맞게 동작하는지 확인하십시오.- 버전: 실행 중인 버전이 릴리스 페이지의 최신 안정 릴리스와 일치하는지 확인합니다. 이 페이지는 릴리스 피드에서 다시 생성되므로, 이 가이드의 날짜가 명시된 내용이 최신인지 확인하는 기준이 됩니다.
- 동기화: consensus 클라이언트의
optimism_syncStatus( op-node JSON-RPC 레퍼런스 참조)가 공개 익스플로러에서 보이는 체인 헤드를 unsafe head가 따라가고 있음을 보여 주고, execution 클라이언트가 동기화 완료를 보고하는지 확인합니다. - 디스크 사용 형태: 아카이브 node의 디스크는 아카이브 node답게 증가합니다. full node로 실행하려 했는데 datadir가 테라바이트 규모로 커지고 있다면, 디스크가 가득 차기 전에 3단계의 pruning 플래그를 다시 검토하십시오.
- 역할 확인: 5단계에서 어떤 행을 선택했든, 그 핵심 기능을 한 번 실행해
보십시오. 아카이브 node에서는 과거 상태 조회, challenger 인프라에서는
debug네임스페이스 증명 호출, supernode에서는 크로스체인 메시지 확인입니다.
다음 단계
- op-node 구성 레퍼런스: 페이지에 명시된 릴리스 태그의 op-node 플래그 정의에서 생성된 전체 플래그 목록이며, 새로운 최종 릴리스가 게시되면 다시 생성됩니다.
- op-reth 구성 레퍼런스: 가져온 op-reth CLI 레퍼런스(op-reth 소스 트리와 함께 버전 관리됨)와 historical-proofs 구성 페이지로 안내합니다.
- kona-node 문서: 이 문서의 노드 운영자 섹션에 있는 Rust consensus 클라이언트의 설치 및 실행 가이드입니다.
- consensus 레이어 동기화: 두 클라이언트의 동기화 방식을 조정할 때, execution 레이어(snap) 동기화가 권장 모드인 이유와 consensus 레이어 동기화의 용도를 설명합니다.
- reth.rs OP Stack 챕터: 업스트림 op-reth 운영 문서입니다. reth 릴리스와 함께 유지 관리되는 외부 문서이며, 2026-07-21 기준입니다.