> ## Documentation Index
> Fetch the complete documentation index at: https://docs.optimism.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 체인의 challenger 구성 방법

> OP Stack 체인의 challenger를 구성하는 방법을 알아봅니다.

이 가이드에서는 `op-challenger`의 구성 및 모니터링 옵션을 설정하는 단계별 방법을 안내합니다.

challenger는 분쟁 게임(dispute game)을 모니터링하고 잘못된 주장(claim)에 이의를 제기하여 OP Stack 체인을 보호하는 핵심 결함 증명(fault proof) 구성 요소입니다. 이 결함 증명 기능에 대한 전반적인 개요는 [op-challenger 설명](https://docs.optimism.io/ko/op-stack/fault-proofs/challenger.md)을 참조하십시오.

challenger는 다음을 담당합니다.

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

플래그, 환경 변수, 기본값의 전체 목록은
[challenger 구성 레퍼런스](https://docs.optimism.io/ko/chain-operators/reference/challenger-configuration.md)를 참고하십시오.

> [!WARNING]
>
> **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는 체인을 방어하지 못합니다.

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

## 사전 요구 사항

### 필수 요구 사항

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

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

* dispute game factory와 함께 배포된 L1 컨트랙트
* 체인에서 활성화된 결함 증명 시스템
* 체인의 컨트랙트 주소에 대한 접근 권한
* 네트워크 버전에 맞는 [absolute prestate 생성](https://docs.optimism.io/ko/chain-operators/tutorials/absolute-prestate.md#generating-the-absolute-prestate) - challenger는 일치하는 prestate가 없으면 게임과의 상호작용을 거부하므로 이 단계는 매우 중요합니다

**2. 필수 인프라 접근 설정**

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

**3. 구성 파일 준비**

* `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 릴리스 페이지](https://github.com/ethereum-optimism/optimism/releases)

이 가이드는 다음 버전을 기준으로 검증되었습니다.

* **op-challenger** — `op-challenger/v1.9.4`(최신 `op-challenger/v*`를 확인하십시오).
* **op-reth** — `v2.2.5`(최신 [op-reth 릴리스](https://github.com/ethereum-optimism/optimism/releases?q=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 튜토리얼](https://docs.optimism.io/ko/chain-operators/tutorials/kona-custom-prestate.md)을 참고하십시오.

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

## 소프트웨어 설치

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

> [tab] 소스에서 빌드
>
> ### 빌드 및 구성
>
> 소스에서 빌드하면 바이너리를 완전히 제어할 수 있으며, 프로덕션 배포에 권장되는 방법입니다.
>
> **op-challenger 복제 및 빌드**
>
> ```bash theme={null}
> # 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 릴리스 태그에서 빌드하십시오([현재 안정 릴리스 찾기](#현재-안정-릴리스-찾기) 참고).
>
> ```bash theme={null}
> # 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 구성 요소가 올바르게 설치되었는지 확인합니다.
>
> ```bash theme={null}
> # 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
> ```
>
> ## 구성 설정
>
> **1. 작업 공간 정리**
>
> 바이너리를 빌드한 후 challenger 작업 디렉터리를 생성합니다.
>
> ```bash theme={null}
> # 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)
> ```
>
> **2. 구성 파일 복사**
>
> ```bash theme={null}
> # 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 .
> ```
>
> **3. 환경 변수 설정**
>
> 구성을 생성하기 전에 여러 정보를 수집해야 합니다. 각 값을 얻을 수 있는 위치는 다음과 같습니다.
>
> **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 파일을 생성합니다.
>
> ```bash theme={null}
> # 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_*`)을 실제 구성 값으로 바꾸십시오.
>
> **4. 주요 구성 플래그 이해하기**
>
> > [accordion] --l1-eth-rpc
> >
> > * 표준 L1 node의 HTTP provider URL이며, full node일 수 있습니다. `op-challenger`는 많은 요청을 보내므로, 체인 운영자는 신뢰할 수 있고 많은 트랜잭션을 쉽게 처리할 수 있는 node가 필요합니다.
> > * 참고: Challenger는 많은 자금을 보유하며, 게임과 상호작용해야 하는 경우 이를 사용합니다. 이로 인해 게임을 올바르게 방어하거나 이의를 제기하지 못할 위험이 있으므로, 체인 운영자는 Challenger가 가리키는 node를 확실히 신뢰할 수 있어야 합니다.
>
> > [accordion] --l1-beacon
> >
> > * blob을 가져오는 용도로만 필요합니다.
> > * 경우에 따라 체인 운영자는 blob archiver 또는 blob을 정리(prune)하지 않도록 구성된 L1 합의 node가 필요할 수 있습니다.
> >   * 체인이 정기적으로 제안하는 경우 blob archiver는 필요하지 않습니다. blob 보존 기간 내에서 게임이 진행될 수 있는 기간은 짧습니다.
> >   * 체인이 18일 동안 유효한 output root를 게시하지 않으면, challenge 게임을 실행하는 blob archiver가 필요합니다. 행위자가 게임의 최하단까지 밀려나는 경우, 체인을 보호하는 유일한 주체라면 게임에서 패배할 수 있습니다.
>
> > [accordion] --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 실행하기](https://docs.optimism.io/ko/node-operators/tutorials/reth-historical-proofs.md)를 참고하십시오.
> > * **`--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 형식을 사용합니다.
>
> > [accordion] --rollup-rpc
> >
> > * challenger는 게임이 시작된 시점의 output root에 접근해야 하므로 `op-node` 아카이브 node여야 합니다. 중요한 구성 세부 사항은 아래를 참고하십시오.
> >
> > 1. op-node의 Safe Head Database(SafeDB) 구성:
> >
> >    * `op-conductor` 뒤에 있는 `op-node`는 stateless 상태가 되지 않도록 SafeDB가 활성화되어 있어야 합니다.
> >
> >    * SafeDB를 활성화하려면 구성에서 `--safedb.path` 값을 설정하십시오. 이는 safe head 업데이트 데이터를 영구 저장하는 데 사용되는 파일 경로를 지정합니다.
> >
> >    * 구성 예시:
> >
> >      ```bash theme={null}
> >      --safedb.path <path-to-safe-head-db>   # Replace <path-to-safe-head-db> with your actual path
> >      ```
> >
> >      > [!NOTE]
> >      >
> >      > 이 경로가 설정되지 않으면 SafeDB 기능이 비활성화됩니다.
> >
> >    > [!WARNING]
> >    >
> >    > **SafeDB를 절대 스냅샷에서 복원하지 마십시오.** SafeDB는 L1에서 도출(derive)된 safe head를 기록하며, 스냅샷은 실제 온체인 도출 상태를 반영하지 않을 수 있습니다. SafeDB가 L1과 동기화되지 않으면 `op-challenger`는 잘못된 safe head를 기반으로 동작하여 유효한 output을 잘못 공격할 수 있습니다. `op-challenger`는 이 상황을 감지할 수 없습니다. 수신하는 데이터가 정상으로 보이기 때문입니다. SafeDB가 스냅샷에서 복원되었거나 다른 이유로 손상되었다고 의심되는 경우, 이를 삭제하고 최소 30일 이상 된 스냅샷에서 다시 동기화하십시오. `op-node`는 SafeDB를 소급하여 채우지(backfill) 않으므로 그 시점 이후부터만 채웁니다. 30일 된 스냅샷은 28일의 분쟁 게임 기간을 포괄하기에 충분한 기록을 제공합니다.
> >
> > 2. 과거 데이터 가용성 보장:
> >
> >    * 네트워크 일관성을 유지하고 node가 과거 상태와 트랜잭션을 참조할 수 있도록, `op-node`와 `op-reth` 모두 게임 시작 시점부터의 데이터를 보유해야 합니다.
> >
> >    * `op-node`의 경우: 충분한 블록체인 데이터 기록을 로컬에 유지하도록 구성하거나 아카이브 node를 사용하십시오.
> >
> >    * `op-reth`의 경우: 마찬가지로 과거 데이터를 저장하거나 접근할 수 있도록 구성하십시오.
> >
> >    * 구성 예시:
> >
> >      ```bash theme={null}
> >      op-node \
> >      --rollup-rpc <op-node-archive-node-url> \
> >      --safedb.path <path-to-safe-head-db>
> >      ```
> >
> >    > [!NOTE]
> >    >
> >    > `<op-node-archive-node-url>`을 아카이브 node의 URL로, `<path-to-safe-head-db>`를 SafeDB 데이터를 저장할 경로로 바꾸십시오.
>
> > [accordion] --private-key
> >
> > * 체인 운영자는 개인 키를 지정하거나 다른 방법(예: `op-signer`)을 사용해야 합니다.
> > * 이는 `op-node`, batcher, proposer와 동일한 트랜잭션 매니저 인자를 사용하므로, 체인 운영자는 다음 옵션 중 하나를 선택할 수 있습니다.
> >   * 니모닉(mnemonic)
> >   * 개인 키
> >   * `op-signer` 엔드포인트
>
> > [accordion] --network
> >
> > * `op-challenger`가 실행되는 대상 L2 네트워크를 식별합니다(예: `op-sepolia` 또는 `op-mainnet`).
> >
> > * `--network` 플래그를 사용하면 `--game-factory-address`가 [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json)에서 자동으로 가져와집니다.
> >
> > * trace를 생성할 때 challenger에는 rollup config와 L2 genesis 파일이 필요합니다. registry의 `--network`를 사용하면 두 파일 모두 자동으로 로드되지만, 커스텀 네트워크는 L2 genesis와 rollup config를 모두 지정해야 합니다.
> >
> > * [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json)에 없는 커스텀 네트워크의 경우, 다음과 같이 `--game-factory-address`와 rollup을 지정해야 합니다.
> >
> >   ```bash theme={null}
> >   --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
> >   ```
> >
> > > [!NOTE]
> > >
> > > 이 옵션들은 지정된 `--network`에 따라 달라집니다. 체인 운영자는 항상 prestate를 로드하는 방법을 지정해야 하며, docker 이미지를 사용하지 않는 경우에는 `--cannon-kona-server`도 지정해야 합니다.
>
> > [accordion] --datadir
> >
> > * `op-challenger`가 쓰기 작업을 하고 필요한 데이터를 저장할 수 있는 디렉터리입니다. `op-challenger`는 이 디렉터리를 관리하며 필요에 따라 그 아래에 데이터를 추가하거나 제거합니다.
> > * docker에서 실행하는 경우, 재시작할 때마다 데이터가 손실되지 않도록 docker 볼륨 또는 마운트 지점을 가리켜야 합니다. 필요하면 데이터를 다시 생성할 수 있지만, 특히 challenger가 게임에 대응하는 과정에서 cannon을 실행한 경우에는 상당한 추가 처리가 필요할 수 있습니다.
>
> > [accordion] --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](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.bin.gz)
> >
> >   * 이 파일에는 cannon 메모리 상태가 포함되어 있습니다.
> >
> > > [!NOTE]
> > >
> > > Challenger는 일치하는 prestate가 없으면 어떤 게임과도 상호작용을 거부합니다.
> > > absolute prestate를 생성하는 방법은 이 [가이드](https://docs.optimism.io/ko/chain-operators/tutorials/absolute-prestate.md#generating-the-absolute-prestate)를 확인하십시오.
>
> ### challenger 시작 스크립트 생성
>
> `scripts/start-challenger.sh`를 생성합니다.
>
> ```bash theme={null}
> #!/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 시작
>
> ```bash theme={null}
> # 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가 올바르게 동작하는지 로그를 모니터링하여 확인합니다.
>
> ```bash theme={null}
> # Check challenger logs
> tail -f challenger-data/challenger.log
>
> # Or if running in foreground, monitor the output
> ```
>
> challenger 로그에는 다음 내용이 표시되어야 합니다.
>
> * L1 및 L2 node에 대한 성공적인 연결
> * prestate 및 구성 로드
> * 분쟁 게임 모니터링

> [tab] docker 사용
>
> ### Docker 설정
>
> Docker 설정은 challenger를 실행하기 위한 컨테이너화된 환경을 제공합니다. 이 방법은 내장된 `kona` 서버와 Cannon 실행 파일이 포함된 공식 Docker 이미지를 사용합니다.
>
> **1. 환경 파일 생성**
>
> 먼저 구성 값을 담은 `.env` 파일을 생성합니다. 이 파일은 Docker Compose가 환경 변수를 설정하는 데 사용됩니다.
>
> ```bash theme={null}
> # 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_*`)을 실제 구성 값으로 바꾸십시오.
>
> **2. 구성 플래그 이해하기**
>
> 각 환경 변수는 특정 challenger 구성 플래그에 대응합니다. 각각의 역할은 다음과 같습니다.
>
> > [accordion] --l1-eth-rpc
> >
> > * 표준 L1 node의 HTTP provider URL이며, full node일 수 있습니다. `op-challenger`는 많은 요청을 보내므로, 체인 운영자는 신뢰할 수 있고 많은 트랜잭션을 쉽게 처리할 수 있는 node가 필요합니다.
> > * 참고: Challenger는 많은 자금을 보유하며, 게임과 상호작용해야 하는 경우 이를 사용합니다. 이로 인해 게임을 올바르게 방어하거나 이의를 제기하지 못할 위험이 있으므로, 체인 운영자는 Challenger가 가리키는 node를 확실히 신뢰할 수 있어야 합니다.
>
> > [accordion] --l1-beacon
> >
> > * blob을 가져오는 용도로만 필요합니다.
> > * 경우에 따라 체인 운영자는 blob archiver 또는 blob을 정리(prune)하지 않도록 구성된 L1 합의 node가 필요할 수 있습니다.
> >   * 체인이 정기적으로 제안하는 경우 blob archiver는 필요하지 않습니다. blob 보존 기간 내에서 게임이 진행될 수 있는 기간은 짧습니다.
> >   * 체인이 18일 동안 유효한 output root를 게시하지 않으면, challenge 게임을 실행하는 blob archiver가 필요합니다. 행위자가 게임의 최하단까지 밀려나는 경우, 체인을 보호하는 유일한 주체라면 게임에서 패배할 수 있습니다.
>
> > [accordion] --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 실행하기](https://docs.optimism.io/ko/node-operators/tutorials/reth-historical-proofs.md)를 참고하십시오.
> > * **`--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 형식을 사용합니다.
>
> > [accordion] --rollup-rpc
> >
> > * challenger는 게임이 시작된 시점의 output root에 접근해야 하므로 `op-node` 아카이브 node여야 합니다. 중요한 구성 세부 사항은 아래를 참고하십시오.
> >
> > 1. op-node의 Safe Head Database(SafeDB) 구성:
> >
> >    * `op-conductor` 뒤에 있는 `op-node`는 stateless 상태가 되지 않도록 SafeDB가 활성화되어 있어야 합니다.
> >
> >    * SafeDB를 활성화하려면 구성에서 `--safedb.path` 값을 설정하십시오. 이는 safe head 업데이트 데이터를 영구 저장하는 데 사용되는 파일 경로를 지정합니다.
> >
> >    * 구성 예시:
> >
> >      ```bash theme={null}
> >      --safedb.path <path-to-safe-head-db>   # Replace <path-to-safe-head-db> with your actual path
> >      ```
> >
> >      > [!NOTE]
> >      >
> >      > 이 경로가 설정되지 않으면 SafeDB 기능이 비활성화됩니다.
> >
> >    > [!WARNING]
> >    >
> >    > **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일의 분쟁 게임 기간을 포괄하기에 충분한 기록을 제공합니다.
> >
> > 2. 과거 데이터 가용성 보장:
> >
> >    * 네트워크 일관성을 유지하고 node가 과거 상태와 트랜잭션을 참조할 수 있도록, `op-node`와 `op-reth` 모두 게임 시작 시점부터의 데이터를 보유해야 합니다.
> >
> >    * `op-node`의 경우: 충분한 블록체인 데이터 기록을 로컬에 유지하도록 구성하거나 아카이브 node를 사용하십시오.
> >
> >    * `op-reth`의 경우: 마찬가지로 과거 데이터를 저장하거나 접근할 수 있도록 구성하십시오.
> >
> >    * 구성 예시:
> >
> >      ```bash theme={null}
> >      op-node \
> >      --rollup-rpc <op-node-archive-node-url> \
> >      --safedb.path <path-to-safe-head-db>
> >      ```
> >
> >    > [!NOTE]
> >    >
> >    > `<op-node-archive-node-url>`을 아카이브 node의 URL로, `<path-to-safe-head-db>`를 SafeDB 데이터를 저장할 경로로 바꾸십시오.
>
> > [accordion] --private-key
> >
> > * 체인 운영자는 개인 키를 지정하거나 다른 방법(예: `op-signer`)을 사용해야 합니다.
> > * 이는 `op-node`, batcher, proposer와 동일한 트랜잭션 매니저 인자를 사용하므로, 체인 운영자는 다음 옵션 중 하나를 선택할 수 있습니다.
> >   * 니모닉(mnemonic)
> >   * 개인 키
> >   * `op-signer` 엔드포인트
>
> > [accordion] --network
> >
> > * `op-challenger`가 실행되는 대상 L2 네트워크를 식별합니다(예: `op-sepolia` 또는 `op-mainnet`).
> >
> > * `--network` 플래그를 사용하면 `--game-factory-address`가 [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json)에서 자동으로 가져와집니다.
> >
> > * trace를 생성할 때 challenger에는 rollup config와 L2 genesis 파일이 필요합니다. registry의 `--network`를 사용하면 두 파일 모두 자동으로 로드되지만, 커스텀 네트워크는 L2 genesis와 rollup config를 모두 지정해야 합니다.
> >
> > * [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json)에 없는 커스텀 네트워크의 경우, 다음과 같이 `--game-factory-address`와 rollup을 지정해야 합니다.
> >
> >   ```bash theme={null}
> >   --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
> >   ```
> >
> > > [!NOTE]
> > >
> > > 이 옵션들은 지정된 `--network`에 따라 달라집니다. 체인 운영자는 항상 prestate를 로드하는 방법을 지정해야 하며, docker 이미지를 사용하지 않는 경우에는 `--cannon-kona-server`도 지정해야 합니다.
>
> > [accordion] --datadir
> >
> > * `op-challenger`가 쓰기 작업을 하고 필요한 데이터를 저장할 수 있는 디렉터리입니다. `op-challenger`는 이 디렉터리를 관리하며 필요에 따라 그 아래에 데이터를 추가하거나 제거합니다.
> > * docker에서 실행하는 경우, 재시작할 때마다 데이터가 손실되지 않도록 docker 볼륨 또는 마운트 지점을 가리켜야 합니다. 필요하면 데이터를 다시 생성할 수 있지만, 특히 challenger가 게임에 대응하는 과정에서 cannon을 실행한 경우에는 상당한 추가 처리가 필요할 수 있습니다.
>
> > [accordion] --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](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.bin.gz)
> >
> >   * 이 파일에는 cannon 메모리 상태가 포함되어 있습니다.
> >
> > > [!NOTE]
> > >
> > > Challenger는 일치하는 prestate가 없으면 어떤 게임과도 상호작용을 거부합니다.
> > > absolute prestate를 생성하는 방법은 이 [가이드](https://docs.optimism.io/ko/chain-operators/tutorials/absolute-prestate.md#generating-the-absolute-prestate)를 확인하십시오.
>
> **3. Docker Compose 설정**
>
> challenger 서비스를 정의하는 `docker-compose.yml` 파일을 생성합니다.
>
> ```yaml theme={null}
> 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
> ```
>
> **4. challenger 실행**
>
> challenger 서비스를 시작하고 로그를 모니터링합니다.
>
> ```bash theme={null}
> # Start the challenger service
> docker-compose up -d
>
> # View logs
> docker-compose logs -f challenger
> ```

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

보안 모니터링을 강화하려면 [`op-dispute-mon`](https://docs.optimism.io/ko/chain-operators/tools/chain-monitoring#dispute-mon)을 함께 실행하는 것을 고려하십시오.

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

## 다음 단계

* 추가 배경 지식과 FAQ는 [OP-Challenger 설명서](https://docs.optimism.io/ko/op-stack/fault-proofs/challenger.md)를 읽어 보십시오
* 구현 세부 사항은 상세한 [challenger 명세](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html)를 검토하십시오
* 문제가 발생하면 [개발자 지원](https://github.com/ethereum-optimism/developers/discussions)에 문의하십시오