Optimism Documentation

이 가이드에서는 op-challenger의 구성 및 모니터링 옵션을 설정하는 단계별 방법을 안내합니다. challenger는 분쟁 게임(dispute game)을 모니터링하고 잘못된 주장(claim)에 이의를 제기하여 OP Stack 체인을 보호하는 핵심 결함 증명(fault proof) 구성 요소입니다. 이 결함 증명 기능에 대한 전반적인 개요는 op-challenger 설명을 참조하십시오. challenger는 다음을 담당합니다.

결함 증명 시스템이 생성한 분쟁 게임 모니터링
분쟁 게임에서 잘못된 주장에 이의 제기
유효한 상태 전환 방어
가능한 경우 게임 해결(resolve)

플래그, 환경 변수, 기본값의 전체 목록은 challenger 구성 레퍼런스를 참고하십시오.

Karst 업그레이드부터 op-program을 대체하여 cannon-kona가 공인된(respected) 결함 증명(fault proof) 게임 유형이 됩니다. op-challenger를 cannon-kona trace type과 kona-client absolute prestate로 구성하십시오. Karst 이후에도 cannon / op-program trace type으로 실행 중인 challenger는 체인을 방어하지 못합니다.

op-geth는 지원이 종료되었으며(2026-05-31) 현재 활성화된 Karst 하드포크를 지원하지 않으므로, op-geth node는 더 이상 정식(canonical) 체인을 따라갈 수 없습니다. 주요 지원 실행 클라이언트인 op-reth로 마이그레이션하십시오. 전체 마이그레이션 계획은 op-geth 지원 중단 공지를 참조하십시오.

사전 요구 사항

필수 요구 사항

challenger를 구성하기 전에 다음 단계를 완료하십시오.

결함 증명이 활성화된 OP Stack 체인 배포

dispute game factory와 함께 배포된 L1 컨트랙트
체인에서 활성화된 결함 증명 시스템
체인의 컨트랙트 주소에 대한 접근 권한
네트워크 버전에 맞는 absolute prestate 생성 - challenger는 일치하는 prestate가 없으면 게임과의 상호작용을 거부하므로 이 단계는 매우 중요합니다

필수 인프라 접근 설정

L1 RPC 엔드포인트(Ethereum, Sepolia 등)
L1 Beacon node 엔드포인트(blob 접근용)
debug API가 활성화된 L2 아카이브 node
과거 데이터를 보유한 rollup node(op-node)

구성 파일 준비

rollup.json - Rollup 구성 파일
genesis-l2.json - L2 genesis 파일
<prestate-hash>.bin.gz - 1단계에서 생성한 absolute prestate 파일(rust/kona/prestate-artifacts-cannon/<prestate-hash>.bin.gz)

소프트웨어 요구 사항

Git(저장소 복제용)
Go 1.21+(소스에서 빌드하는 경우)
Docker 및 Docker Compose(선택 사항이지만 권장)
challenger 운영을 위해 자금이 충전된 Ethereum 계정에 대한 접근 권한

현재 안정 릴리스 찾기

OP Stack 구성 요소의 최신 호환 버전을 사용하고 있는지 확인하려면 항상 공식 릴리스 페이지를 확인하십시오. OP Stack 릴리스 페이지 이 가이드는 다음 버전을 기준으로 검증되었습니다.

op-challenger — op-challenger/v1.9.4(최신 op-challenger/v*를 확인하십시오).
op-reth — v2.2.5(최신 op-reth 릴리스를 확인하십시오). op-reth는 sequencer의 실행 클라이언트이자 challenger가 출금 증명을 읽어 오는 아카이브 node입니다.
kona-client — absolute prestate는 태그가 지정된 kona-client/v* 릴리스(예: kona-client/v1.6.0-rc.1)로부터 빌드됩니다. 체인에 등록된 prestate와 일치하는 태그를 사용하십시오. 거버넌스에서 승인된 업그레이드의 경우 업그레이드 공지에 버전이 명시됩니다. kona-client prestate 튜토리얼을 참고하십시오.

체인 배포와 호환되는 버전을 사용하고 있는지 항상 릴리스 노트를 확인하십시오. 업그레이드 공지에 명시된 op-challenger 및 kona-client 버전(또는 이에 일치하는 최신 릴리스)을 사용하는 것이 지원되는 방법입니다.

소프트웨어 설치

challenger 배포 시에는 소스에서 빌드하거나(더 나은 제어와 디버깅을 위해 권장) Docker를 사용한 컨테이너 기반 설정을 사용할 수 있습니다.

소스에서 빌드
docker 사용

빌드 및 구성

소스에서 빌드하면 바이너리를 완전히 제어할 수 있으며, 프로덕션 배포에 권장되는 방법입니다.op-challenger 복제 및 빌드

# Clone the optimism monorepo
git clone https://github.com/ethereum-optimism/optimism.git
cd optimism

# Check out the latest release of op-challenger
git checkout op-challenger/v1.9.4

# Generate the embedded superchain config bundle (initializes the
# superchain-registry submodule; op-challenger embeds this file at compile time)
just build-superchain-go

# Install dependencies and build
just op-challenger

# Build the Cannon VM binary used to run dispute traces
just cannon

# Binaries will be available at ./op-challenger/bin/op-challenger
# and ./cannon/bin/cannon

kona-host 빌드challenger에는 cannon-kona 게임 유형을 위한 pre-image oracle 서버인 kona-host도 필요합니다. 서버가 체인에 커밋된 kona-client 빌드와 일치하도록, 체인에 등록된 absolute prestate와 일치하는 kona-client 릴리스 태그에서 빌드하십시오(현재 안정 릴리스 찾기 참고).

# In a checkout of the tag your prestate was built from
cd rust
cargo build --release --bin kona-host

# Binary will be available at ./rust/target/release/kona-host

설치 확인

challenger 구성 요소가 올바르게 설치되었는지 확인합니다.

# Make sure you're in the optimism directory
./op-challenger/bin/op-challenger --help

# You should see the challenger help output with available commands and flags

구성 설정

작업 공간 정리

바이너리를 빌드한 후 challenger 작업 디렉터리를 생성합니다.

# Create challenger directory (this should be at the same level as optimism directory)
mkdir challenger-node
cd challenger-node

# Create necessary subdirectories
mkdir scripts
mkdir challenger-data

# Verify the optimism directory is accessible
# Directory structure should look like:
# /optimism/                 (contains the built binaries)
# /challenger-node/          (your working directory)

구성 파일 복사

# Copy configuration files to your challenger directory
# Adjust paths based on your deployment setup
cp /path/to/your/rollup.json .
cp /path/to/your/genesis-l2.json .

환경 변수 설정

구성을 생성하기 전에 여러 정보를 수집해야 합니다. 각 값을 얻을 수 있는 위치는 다음과 같습니다.L1 네트워크 접근:

L1 RPC URL: L1 node 엔드포인트(Infura, Alchemy 또는 자체 호스팅)
L1 Beacon URL: blob 접근을 위한 Beacon chain API 엔드포인트

L2 네트워크 접근:

L2 RPC URL: op-reth 아카이브 node 엔드포인트
Rollup RPC URL: 과거 데이터를 보유한 op-node 엔드포인트

Challenger 지갑:

challenger 운영을 위한 개인 키(자금이 충전되어 있어야 함)

네트워크 구성:

컨트랙트 배포에서 얻은 game factory 주소
네트워크 식별자(예: op-sepolia, op-mainnet 또는 커스텀)

터미널에 복사하여 붙여넣어 env 파일을 생성합니다.

# Create .env file with your actual values
cat > .env << 'EOF'
# L1 Configuration - Replace with your actual RPC URLs
L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY

# L2 Configuration - Replace with your actual node endpoints  
L2_RPC_URL=http://localhost:8545
ROLLUP_RPC_URL=http://localhost:8547
L1_BEACON=http://sepolia-cl-1:5051

# Wallet configuration - Choose either mnemonic + HD path OR private key
MNEMONIC="test test test test test test test test test test test junk"
HD_PATH="m/44'/60'/0'/0/0"
# PRIVATE_KEY=0xYOUR_ACTUAL_PRIVATE_KEY  # Alternative to mnemonic

# Network configuration
NETWORK=op-sepolia
GAME_FACTORY_ADDRESS=0xYOUR_GAME_FACTORY_ADDRESS

# Trace configuration (cannon-kona is the respected game type from the Karst upgrade)
TRACE_TYPE=permissioned,cannon-kona

# Data directory
DATADIR=./challenger-data

# Cannon VM binary (shared by cannon and cannon-kona; built from the optimism repo)
CANNON_BIN=<PATH_TO_OPTIMISM_REPO>/cannon/bin/cannon

# Configuration files
CANNON_ROLLUP_CONFIG=<PATH_TO_YOUR_ROLLUP_CONFIG>
CANNON_L2_GENESIS=<PATH_TO_YOUR_L2_GENESIS>
# kona executable used as the pre-image oracle server, and the kona-client absolute prestate
CANNON_KONA_SERVER=<PATH_TO_KONA_EXECUTABLE>
CANNON_KONA_PRESTATE=<PATH_TO_YOUR_KONA_PRESTATE_FILE>
EOF

중요: 모든 플레이스홀더 값(YOUR_ACTUAL_*)을 실제 구성 값으로 바꾸십시오.

주요 구성 플래그 이해하기

--l1-eth-rpc

표준 L1 node의 HTTP provider URL이며, full node일 수 있습니다. op-challenger는 많은 요청을 보내므로, 체인 운영자는 신뢰할 수 있고 많은 트랜잭션을 쉽게 처리할 수 있는 node가 필요합니다.
참고: Challenger는 많은 자금을 보유하며, 게임과 상호작용해야 하는 경우 이를 사용합니다. 이로 인해 게임을 올바르게 방어하거나 이의를 제기하지 못할 위험이 있으므로, 체인 운영자는 Challenger가 가리키는 node를 확실히 신뢰할 수 있어야 합니다.

--l1-beacon

blob을 가져오는 용도로만 필요합니다.
경우에 따라 체인 운영자는 blob archiver 또는 blob을 정리(prune)하지 않도록 구성된 L1 합의 node가 필요할 수 있습니다.
- 체인이 정기적으로 제안하는 경우 blob archiver는 필요하지 않습니다. blob 보존 기간 내에서 게임이 진행될 수 있는 기간은 짧습니다.
- 체인이 18일 동안 유효한 output root를 게시하지 않으면, challenge 게임을 실행하는 blob archiver가 필요합니다. 행위자가 게임의 최하단까지 밀려나는 경우, 체인을 보호하는 유일한 주체라면 게임에서 패배할 수 있습니다.

--l2-eth-rpc

debug가 활성화된 op-reth 아카이브 node여야 합니다.
기술적으로 bedrock까지 거슬러 올라갈 필요는 없지만, 아직 진행 중인 모든 게임의 시작 시점에 접근할 수 있어야 합니다.
challenger가 eth_getProof를 통해 읽는 출금 증명 데이터는 op-reth의 historical-proofs 저장소에서 제공됩니다. --proofs-history로 이를 활성화하고, 영구적인 --proofs-history.storage-path를 설정하며, --proofs-history.window를 분쟁 게임(dispute game) 기간(≥ 28일)을 포괄하도록 설정하십시오. 권한형(permissioned) 체인에서는 --rpc.eth-proof-window가 eth_getProof가 제공하는 과거 범위를 제한합니다. historical proofs와 함께 op-reth 실행하기를 참고하십시오.
--proofs-history로 node를 시작하기 전에 proofs 저장소를 한 번 초기화(seed)하십시오. 그렇지 않으면 op-reth가 시작을 거부합니다(proofs-history ExEx가 Proofs storage not initialized와 함께 panic 발생). node를 중지한 상태에서 op-reth proofs init --chain <chain-or-genesis> --datadir <reth-datadir> --proofs-history.storage-path <proofs-db-path>를 실행하십시오. 이 명령은 체인의 현재 상태를 스냅샷하여 sidecar를 초기화하며, 이후 node가 동기화되면서 ExEx가 앞으로 인덱싱합니다. 결함 증명 기간 전체가 포괄되도록 genesis 시점(또는 그 근처)에서 초기화하십시오. 현재 tip에서 초기화된 node는 그 시점 이후 블록에 대한 증명만 제공합니다.
op-reth v2.6.x 이하에서는 op-reth node와 op-reth proofs init 모두에 --proofs-history.storage-version v2도 전달하십시오. 해당 릴리스는 기본적으로 지원 중단된(deprecated) v1 형식을 사용합니다.

--rollup-rpc

challenger는 게임이 시작된 시점의 output root에 접근해야 하므로 op-node 아카이브 node여야 합니다. 중요한 구성 세부 사항은 아래를 참고하십시오.

op-node의 Safe Head Database(SafeDB) 구성:
- op-conductor 뒤에 있는 op-node는 stateless 상태가 되지 않도록 SafeDB가 활성화되어 있어야 합니다.
- SafeDB를 활성화하려면 구성에서 --safedb.path 값을 설정하십시오. 이는 safe head 업데이트 데이터를 영구 저장하는 데 사용되는 파일 경로를 지정합니다.
- 구성 예시:
  --safedb.path <path-to-safe-head-db> # Replace <path-to-safe-head-db> with your actual path
  이 경로가 설정되지 않으면 SafeDB 기능이 비활성화됩니다.
SafeDB를 절대 스냅샷에서 복원하지 마십시오. SafeDB는 L1에서 도출(derive)된 safe head를 기록하며, 스냅샷은 실제 온체인 도출 상태를 반영하지 않을 수 있습니다. SafeDB가 L1과 동기화되지 않으면 op-challenger는 잘못된 safe head를 기반으로 동작하여 유효한 output을 잘못 공격할 수 있습니다. op-challenger는 이 상황을 감지할 수 없습니다. 수신하는 데이터가 정상으로 보이기 때문입니다. SafeDB가 스냅샷에서 복원되었거나 다른 이유로 손상되었다고 의심되는 경우, 이를 삭제하고 최소 30일 이상 된 스냅샷에서 다시 동기화하십시오. op-node는 SafeDB를 소급하여 채우지(backfill) 않으므로 그 시점 이후부터만 채웁니다. 30일 된 스냅샷은 28일의 분쟁 게임 기간을 포괄하기에 충분한 기록을 제공합니다.
과거 데이터 가용성 보장:
- 네트워크 일관성을 유지하고 node가 과거 상태와 트랜잭션을 참조할 수 있도록, op-node와 op-reth 모두 게임 시작 시점부터의 데이터를 보유해야 합니다.
- op-node의 경우: 충분한 블록체인 데이터 기록을 로컬에 유지하도록 구성하거나 아카이브 node를 사용하십시오.
- op-reth의 경우: 마찬가지로 과거 데이터를 저장하거나 접근할 수 있도록 구성하십시오.
- 구성 예시:
  op-node \ --rollup-rpc <op-node-archive-node-url> \ --safedb.path <path-to-safe-head-db>
<op-node-archive-node-url>을 아카이브 node의 URL로, <path-to-safe-head-db>를 SafeDB 데이터를 저장할 경로로 바꾸십시오.

--private-key

체인 운영자는 개인 키를 지정하거나 다른 방법(예: op-signer)을 사용해야 합니다.
이는 op-node, batcher, proposer와 동일한 트랜잭션 매니저 인자를 사용하므로, 체인 운영자는 다음 옵션 중 하나를 선택할 수 있습니다.
- 니모닉(mnemonic)
- 개인 키
- op-signer 엔드포인트

--network

op-challenger가 실행되는 대상 L2 네트워크를 식별합니다(예: op-sepolia 또는 op-mainnet).
--network 플래그를 사용하면 --game-factory-address가 superchain-registry에서 자동으로 가져와집니다.
trace를 생성할 때 challenger에는 rollup config와 L2 genesis 파일이 필요합니다. registry의 --network를 사용하면 두 파일 모두 자동으로 로드되지만, 커스텀 네트워크는 L2 genesis와 rollup config를 모두 지정해야 합니다.

superchain-registry에 없는 커스텀 네트워크의 경우, 다음과 같이 --game-factory-address와 rollup을 지정해야 합니다.

--cannon-kona-rollup-config rollup.json  \
--cannon-kona-l2-genesis genesis-l2.json \
# use this if running challenger outside of the docker image
--cannon-kona-server ./kona \
# version of kona-client deployed on chain
# if you use the wrong one, you will lose the game
# if you deploy your own contracts, you specify the hash (the .pre field of prestate-proof.json)
# OP Mainnet uses tagged versions of kona-client
# build with: just reproducible-prestate-kona
# challenger verifies that onchain
 --cannon-kona-prestate ./<prestate-hash>.bin.gz \
# load the game factory address from system config or superchain registry
# point the game factory address at the dispute game factory proxy
 --game-factory-address

이 옵션들은 지정된 --network에 따라 달라집니다. 체인 운영자는 항상 prestate를 로드하는 방법을 지정해야 하며, docker 이미지를 사용하지 않는 경우에는 --cannon-kona-server도 지정해야 합니다.

--datadir

op-challenger가 쓰기 작업을 하고 필요한 데이터를 저장할 수 있는 디렉터리입니다. op-challenger는 이 디렉터리를 관리하며 필요에 따라 그 아래에 데이터를 추가하거나 제거합니다.
docker에서 실행하는 경우, 재시작할 때마다 데이터가 손실되지 않도록 docker 볼륨 또는 마운트 지점을 가리켜야 합니다. 필요하면 데이터를 다시 생성할 수 있지만, 특히 challenger가 게임에 대응하는 과정에서 cannon을 실행한 경우에는 상당한 추가 처리가 필요할 수 있습니다.

--cannon-kona-prestate / --cannon-kona-prestates-url

prestate는 사실상 온체인에 배포된 kona-client의 버전입니다(cannon-kona 게임 유형으로 Cannon VM 내부에서 실행됨). 체인 운영자는 반드시 올바른 버전을 사용해야 합니다. op-challenger는 잘못된 주장(claim)을 하지 않도록 absolute prestate 해시가 다른 게임과의 상호작용을 거부합니다. 자체 컨트랙트를 배포하는 경우, 체인 운영자는 컨트랙트 배포 시 just reproducible-prestate-kona 명령으로 얻은 absolute prestate 해시를 지정해야 하며, 이 명령은 필요한 prestate 파일도 함께 빌드합니다.거버넌스에서 승인된 모든 릴리스는 태그가 지정된 kona-client 버전을 사용합니다. 버전 태그를 체크아웃하고 just reproducible-prestate-kona를 실행하여 다시 빌드할 수 있습니다.

사용할 prestate를 지정하는 방법은 두 가지입니다.
- --cannon-kona-prestate: 단일 kona-client absolute-prestate 파일의 경로를 지정합니다.
- --cannon-kona-prestates-url: prestate를 로드할 URL을 지정합니다. 이를 통해 네트워크 업그레이드 등으로 서로 다른 prestate를 사용하는 게임에 참여할 수 있습니다. prestate는 이 디렉터리에 해시 이름으로 저장됩니다.
prestate의 최종 URL 예시:
- https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.bin.gz
- 이 파일에는 cannon 메모리 상태가 포함되어 있습니다.

Challenger는 일치하는 prestate가 없으면 어떤 게임과도 상호작용을 거부합니다. absolute prestate를 생성하는 방법은 이 가이드를 확인하십시오.

challenger 시작 스크립트 생성

scripts/start-challenger.sh를 생성합니다.

#!/bin/bash
source .env

# Path to the challenger binary
../optimism/op-challenger/bin/op-challenger \
  --trace-type permissioned,cannon-kona \
  --l1-eth-rpc=$L1_RPC_URL \
  --l2-eth-rpc=$L2_RPC_URL \
  --l1-beacon=$L1_BEACON \
  --rollup-rpc=$ROLLUP_RPC_URL \
  --game-factory-address $GAME_FACTORY_ADDRESS \
  --datadir=$DATADIR \
  --cannon-bin=$CANNON_BIN \
  --cannon-kona-rollup-config=$CANNON_ROLLUP_CONFIG \
  --cannon-kona-l2-genesis=$CANNON_L2_GENESIS \
  --cannon-kona-server=$CANNON_KONA_SERVER \
  --cannon-kona-prestate=$CANNON_KONA_PRESTATE \
  --mnemonic "$MNEMONIC" \
  --hd-path "$HD_PATH"

challenger 초기화 및 시작

challenger 시작

# Make sure you're in the challenger-node directory
cd challenger-node

# Make script executable
chmod +x scripts/start-challenger.sh

# Start challenger
./scripts/start-challenger.sh

challenger 실행 확인

challenger가 올바르게 동작하는지 로그를 모니터링하여 확인합니다.

# Check challenger logs
tail -f challenger-data/challenger.log

# Or if running in foreground, monitor the output

challenger 로그에는 다음 내용이 표시되어야 합니다.

L1 및 L2 node에 대한 성공적인 연결
prestate 및 구성 로드
분쟁 게임 모니터링

Docker 설정

Docker 설정은 challenger를 실행하기 위한 컨테이너화된 환경을 제공합니다. 이 방법은 내장된 kona 서버와 Cannon 실행 파일이 포함된 공식 Docker 이미지를 사용합니다.

환경 파일 생성

먼저 구성 값을 담은 .env 파일을 생성합니다. 이 파일은 Docker Compose가 환경 변수를 설정하는 데 사용됩니다.

# Create .env file with your actual values
cat > .env << 'EOF'
# L1 Configuration - Replace with your actual RPC URLs
L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY
L1_BEACON=http://sepolia-cl-1:5051

# L2 Configuration - Replace with your actual node endpoints  
L2_RPC_URL=http://localhost:8545
ROLLUP_RPC_URL=http://localhost:8547

# Wallet configuration - Choose either mnemonic + HD path OR private key
MNEMONIC="test test test test test test test test test test test junk"
HD_PATH="m/44'/60'/0'/0/0"

# Network configuration
NETWORK=op-sepolia
GAME_FACTORY_ADDRESS=0xYOUR_GAME_FACTORY_ADDRESS
EOF

중요: 모든 플레이스홀더 값(YOUR_ACTUAL_*)을 실제 구성 값으로 바꾸십시오.

구성 플래그 이해하기

각 환경 변수는 특정 challenger 구성 플래그에 대응합니다. 각각의 역할은 다음과 같습니다.

--l1-eth-rpc

표준 L1 node의 HTTP provider URL이며, full node일 수 있습니다. op-challenger는 많은 요청을 보내므로, 체인 운영자는 신뢰할 수 있고 많은 트랜잭션을 쉽게 처리할 수 있는 node가 필요합니다.
참고: Challenger는 많은 자금을 보유하며, 게임과 상호작용해야 하는 경우 이를 사용합니다. 이로 인해 게임을 올바르게 방어하거나 이의를 제기하지 못할 위험이 있으므로, 체인 운영자는 Challenger가 가리키는 node를 확실히 신뢰할 수 있어야 합니다.

--l1-beacon

blob을 가져오는 용도로만 필요합니다.
경우에 따라 체인 운영자는 blob archiver 또는 blob을 정리(prune)하지 않도록 구성된 L1 합의 node가 필요할 수 있습니다.
- 체인이 정기적으로 제안하는 경우 blob archiver는 필요하지 않습니다. blob 보존 기간 내에서 게임이 진행될 수 있는 기간은 짧습니다.
- 체인이 18일 동안 유효한 output root를 게시하지 않으면, challenge 게임을 실행하는 blob archiver가 필요합니다. 행위자가 게임의 최하단까지 밀려나는 경우, 체인을 보호하는 유일한 주체라면 게임에서 패배할 수 있습니다.

--l2-eth-rpc

debug가 활성화된 op-reth 아카이브 node여야 합니다.
기술적으로 bedrock까지 거슬러 올라갈 필요는 없지만, 아직 진행 중인 모든 게임의 시작 시점에 접근할 수 있어야 합니다.
challenger가 eth_getProof를 통해 읽는 출금 증명 데이터는 op-reth의 historical-proofs 저장소에서 제공됩니다. --proofs-history로 이를 활성화하고, 영구적인 --proofs-history.storage-path를 설정하며, --proofs-history.window를 분쟁 게임 기간(≥ 28일)을 포괄하도록 설정하십시오. 권한형(permissioned) 체인에서는 --rpc.eth-proof-window가 eth_getProof가 제공하는 과거 범위를 제한합니다. historical proofs와 함께 op-reth 실행하기를 참고하십시오.
--proofs-history로 node를 시작하기 전에 proofs 저장소를 한 번 초기화(seed)하십시오. 그렇지 않으면 op-reth가 시작을 거부합니다(proofs-history ExEx가 Proofs storage not initialized와 함께 panic 발생). node를 중지한 상태에서 op-reth proofs init --chain <chain-or-genesis> --datadir <reth-datadir> --proofs-history.storage-path <proofs-db-path>를 실행하십시오. 이 명령은 체인의 현재 상태를 스냅샷하여 sidecar를 초기화하며, 이후 node가 동기화되면서 ExEx가 앞으로 인덱싱합니다. 결함 증명 기간 전체가 포괄되도록 genesis 시점(또는 그 근처)에서 초기화하십시오. 현재 tip에서 초기화된 node는 그 시점 이후 블록에 대한 증명만 제공합니다.
op-reth v2.6.x 이하에서는 op-reth node와 op-reth proofs init 모두에 --proofs-history.storage-version v2도 전달하십시오. 해당 릴리스는 기본적으로 지원 중단된(deprecated) v1 형식을 사용합니다.

--rollup-rpc

challenger는 게임이 시작된 시점의 output root에 접근해야 하므로 op-node 아카이브 node여야 합니다. 중요한 구성 세부 사항은 아래를 참고하십시오.

op-node의 Safe Head Database(SafeDB) 구성:
- op-conductor 뒤에 있는 op-node는 stateless 상태가 되지 않도록 SafeDB가 활성화되어 있어야 합니다.
- SafeDB를 활성화하려면 구성에서 --safedb.path 값을 설정하십시오. 이는 safe head 업데이트 데이터를 영구 저장하는 데 사용되는 파일 경로를 지정합니다.
- 구성 예시:
  --safedb.path <path-to-safe-head-db> # Replace <path-to-safe-head-db> with your actual path
  이 경로가 설정되지 않으면 SafeDB 기능이 비활성화됩니다.
SafeDB를 절대 스냅샷에서 복원하지 마십시오. SafeDB는 L1에서 도출(derive)된 safe head를 기록하며, 스냅샷은 실제 온체인 도출 상태를 반영하지 않을 수 있습니다. SafeDB가 L1과 동기화되지 않으면 op-challenger는 잘못된 safe head를 기반으로 동작하여 유효한 output을 잘못 공격할 수 있습니다. op-challenger는 이 상황을 감지할 수 없습니다. 수신하는 데이터가 정상으로 보이기 때문입니다. SafeDB가 스냅샷에서 복원되었거나 다른 이유로 손상되었다고 의심되는 경우, 이를 삭제하고 최소 30일 이상 된 스냅샷에서 합의 동기화(consensus sync)를 통해 다시 동기화하십시오. op-node는 SafeDB를 소급하여 채우지(backfill) 않으므로 그 시점 이후부터만 채웁니다. 30일 된 스냅샷은 28일의 분쟁 게임 기간을 포괄하기에 충분한 기록을 제공합니다.
과거 데이터 가용성 보장:
- 네트워크 일관성을 유지하고 node가 과거 상태와 트랜잭션을 참조할 수 있도록, op-node와 op-reth 모두 게임 시작 시점부터의 데이터를 보유해야 합니다.
- op-node의 경우: 충분한 블록체인 데이터 기록을 로컬에 유지하도록 구성하거나 아카이브 node를 사용하십시오.
- op-reth의 경우: 마찬가지로 과거 데이터를 저장하거나 접근할 수 있도록 구성하십시오.
- 구성 예시:
  op-node \ --rollup-rpc <op-node-archive-node-url> \ --safedb.path <path-to-safe-head-db>
<op-node-archive-node-url>을 아카이브 node의 URL로, <path-to-safe-head-db>를 SafeDB 데이터를 저장할 경로로 바꾸십시오.

--private-key

체인 운영자는 개인 키를 지정하거나 다른 방법(예: op-signer)을 사용해야 합니다.
이는 op-node, batcher, proposer와 동일한 트랜잭션 매니저 인자를 사용하므로, 체인 운영자는 다음 옵션 중 하나를 선택할 수 있습니다.
- 니모닉(mnemonic)
- 개인 키
- op-signer 엔드포인트

--network

op-challenger가 실행되는 대상 L2 네트워크를 식별합니다(예: op-sepolia 또는 op-mainnet).
--network 플래그를 사용하면 --game-factory-address가 superchain-registry에서 자동으로 가져와집니다.
trace를 생성할 때 challenger에는 rollup config와 L2 genesis 파일이 필요합니다. registry의 --network를 사용하면 두 파일 모두 자동으로 로드되지만, 커스텀 네트워크는 L2 genesis와 rollup config를 모두 지정해야 합니다.

superchain-registry에 없는 커스텀 네트워크의 경우, 다음과 같이 --game-factory-address와 rollup을 지정해야 합니다.

--cannon-kona-rollup-config rollup.json  \
--cannon-kona-l2-genesis genesis-l2.json \
# use this if running challenger outside of the docker image
--cannon-kona-server ./kona \
# version of kona-client deployed on chain
# if you use the wrong one, you will lose the game
# if you deploy your own contracts, you specify the hash (the .pre field of prestate-proof.json)
# OP Mainnet uses tagged versions of kona-client
# build with: just reproducible-prestate-kona
# challenger verifies that onchain
 --cannon-kona-prestate ./<prestate-hash>.bin.gz \
# load the game factory address from system config or superchain registry
# point the game factory address at the dispute game factory proxy
 --game-factory-address

--datadir

op-challenger가 쓰기 작업을 하고 필요한 데이터를 저장할 수 있는 디렉터리입니다. op-challenger는 이 디렉터리를 관리하며 필요에 따라 그 아래에 데이터를 추가하거나 제거합니다.
docker에서 실행하는 경우, 재시작할 때마다 데이터가 손실되지 않도록 docker 볼륨 또는 마운트 지점을 가리켜야 합니다. 필요하면 데이터를 다시 생성할 수 있지만, 특히 challenger가 게임에 대응하는 과정에서 cannon을 실행한 경우에는 상당한 추가 처리가 필요할 수 있습니다.

--cannon-kona-prestate / --cannon-kona-prestates-url

사용할 prestate를 지정하는 방법은 두 가지입니다.
- --cannon-kona-prestate: 단일 kona-client absolute-prestate 파일의 경로를 지정합니다.
- --cannon-kona-prestates-url: prestate를 로드할 URL을 지정합니다. 이를 통해 네트워크 업그레이드 등으로 서로 다른 prestate를 사용하는 게임에 참여할 수 있습니다. prestate는 이 디렉터리에 해시 이름으로 저장됩니다.
prestate의 최종 URL 예시:
- https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.bin.gz
- 이 파일에는 cannon 메모리 상태가 포함되어 있습니다.

Challenger는 일치하는 prestate가 없으면 어떤 게임과도 상호작용을 거부합니다. absolute prestate를 생성하는 방법은 이 가이드를 확인하십시오.

Docker Compose 설정

challenger 서비스를 정의하는 docker-compose.yml 파일을 생성합니다.

version: '3.8'

services:
  challenger:
    image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger:v1.9.4
    user: "1000"
    volumes:
      - ./challenger-data:/data
      - ./rollup.json:/workspace/rollup.json:ro
      - ./genesis-l2.json:/workspace/genesis-l2.json:ro
      - ./<prestate-hash>.bin.gz:/workspace/<prestate-hash>.bin.gz:ro
    environment:
      - L1_RPC_URL=${L1_RPC_URL}
      - L1_BEACON=${L1_BEACON}
      - L2_RPC_URL=${L2_RPC_URL}
      - ROLLUP_RPC_URL=${ROLLUP_RPC_URL}
      - MNEMONIC=${MNEMONIC}
      - HD_PATH=${HD_PATH}
      - NETWORK=${NETWORK}
      - GAME_FACTORY_ADDRESS=${GAME_FACTORY_ADDRESS}
    command:
      - "op-challenger"
      - "--l1-eth-rpc=${L1_RPC_URL}"
      - "--l1-beacon=${L1_BEACON}"
      - "--l2-eth-rpc=${L2_RPC_URL}"
      - "--rollup-rpc=${ROLLUP_RPC_URL}"
      - "--selective-claim-resolution"
      - "--mnemonic=${MNEMONIC}"
      - "--hd-path=${HD_PATH}"
      - "--network=${NETWORK}"
      - "--game-factory-address=${GAME_FACTORY_ADDRESS}"
      - "--datadir=/data"
      - "--trace-type=cannon-kona"
      - "--cannon-kona-prestate=/workspace/<prestate-hash>.bin.gz"
    restart: unless-stopped
    ports:
      - "8548:8548"  # If challenger exposes metrics endpoint

challenger 실행

challenger 서비스를 시작하고 로그를 모니터링합니다.

# Start the challenger service
docker-compose up -d

# View logs
docker-compose logs -f challenger

op-dispute-mon으로 모니터링하기

보안 모니터링을 강화하려면 op-dispute-mon을 함께 실행하는 것을 고려하십시오.

최근 28일 동안의 모든 게임 상태에 대한 가시성을 제공합니다
프로덕션 challenger 배포에 필수적입니다

다음 단계

추가 배경 지식과 FAQ는 OP-Challenger 설명서를 읽어 보십시오
구현 세부 사항은 상세한 challenger 명세를 검토하십시오
문제가 발생하면 개발자 지원에 문의하십시오

체인 출시

가이드

튜토리얼

도구

참조

아카이브

체인의 challenger 구성 방법

사전 요구 사항

필수 요구 사항

소프트웨어 요구 사항

현재 안정 릴리스 찾기

소프트웨어 설치

빌드 및 구성

설치 확인

구성 설정

challenger 시작 스크립트 생성

challenger 초기화 및 시작

challenger 시작

challenger 실행 확인

Docker 설정

op-dispute-mon으로 모니터링하기

다음 단계

​사전 요구 사항

​필수 요구 사항

​소프트웨어 요구 사항

​현재 안정 릴리스 찾기

​소프트웨어 설치

​빌드 및 구성

​설치 확인

​구성 설정

​challenger 시작 스크립트 생성

​challenger 초기화 및 시작

​challenger 시작

​challenger 실행 확인

​Docker 설정

​op-dispute-mon으로 모니터링하기

​다음 단계

사전 요구 사항

필수 요구 사항

소프트웨어 요구 사항

현재 안정 릴리스 찾기

소프트웨어 설치

빌드 및 구성

설치 확인

구성 설정

challenger 시작 스크립트 생성

challenger 초기화 및 시작

challenger 시작

challenger 실행 확인

Docker 설정

op-dispute-mon으로 모니터링하기

다음 단계