> ## 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.

# Kona 증명으로 전환

> OP Stack 체인에서 Kona 기반 결함 증명(fault proof)을 respected game type으로 사용하도록 전환하는 방법을 알아봅니다.

> [!NOTE]
>
> [Upgrade 18](https://docs.optimism.io/ko/notices/archive/upgrade-18)(Optimism Governance 승인)은 `CANNON`(0)과 함께 사용할 수 있는 game type으로 `CANNON_KONA`(8)를 도입했습니다. [Upgrade 19](https://docs.optimism.io/ko/notices/archive/upgrade-19)는 Optimism Security Council이 관리하는 체인에서 `CANNON_KONA`를 **respected game type**으로 승격합니다. 즉, 온체인 업그레이드의 일부로 자동 적용됩니다. 관리 대상이 아닌 체인이 전환하려면 이 가이드를 따라야 합니다.

## 개요

| 파라미터 | 타입 | 현재 (일반적) | 전환 시 목표값 | 참고 |
| - | - | - | - | - |
| Respected game type | Enum | `CANNON` (0) | `CANNON_KONA` (8) | 출금에 사용되는 game type을 결정합니다 |
| `OP_PROPOSER_GAME_TYPE` | Number | 0 | 8 | proposer game type (respected game type과 일치해야 함) |
| `cannonPrestate` | Bytes32 | 설정됨 | 설정됨 | 유효한 `cannon64` prestate 해시여야 합니다 |
| `cannonKonaPrestate` | Bytes32 | 설정됨 | 설정됨 | 유효한 `cannon64-kona` prestate 해시여야 합니다 |

Kona 증명은 `kona-node`와 `op-reth`를 결합한 `kona-client` 결함 증명 프로그램을 사용합니다. 이는 지원이 종료되었고 Karst 하드포크를 지원하지 않는 `op-program`(`op-node`와 `op-geth`의 결합)을 대체합니다. [op-geth 및 op-program 지원 종료](https://docs.optimism.io/ko/notices/archive/op-geth-deprecation)를 참조하세요. 두 프로그램 모두 다음과 같습니다.

* Cannon을 FPVM으로 사용하며,
* 동일한 분쟁 게임(dispute game) 구현(`FaultDisputeGame.sol`)에서 사용됩니다.

cannon+kona 업그레이드가 배포되면 두 game type을 모두 사용할 수 있습니다.

* `CANNON` (0): `op-program` (지원 종료)
* `CANNON_KONA` (8): `kona-client`

전환하기 전까지 respected game type은 `CANNON`(0)으로 유지되며, 이는 해당 게임만 출금에 사용된다는 의미입니다. `op-program`은 Karst를 지원하지 않으므로 체인에서 Karst 하드포크를 활성화하기 전에 이 전환을 완료해야 합니다. 이 가이드는 Kona 증명(`CANNON_KONA`, 8)이 respected game type이 되도록 체인을 전환하는 방법을 설명합니다.

> [!WARNING]
>
> 이 가이드는 `OpChainConfig`에 `cannonPrestate`와 `cannonKonaPrestate`를 모두 설정하는 것을 포함하여 cannon+kona 업그레이드를 이미 완료했으며, 결함 증명 인프라가 정상 상태라고 가정합니다.

전체적인 흐름은 다음과 같습니다.

* cannon+kona 지원이 온체인에 올바르게 배포되었는지 확인합니다.
* 오프체인 인프라(특히 `op-challenger`)가 Kona를 지원할 준비가 되었는지 확인합니다.
* respected game type을 `CANNON_KONA`(8)로 전환합니다.
* Kona 게임을 게시하도록 `op-proposer`를 업데이트합니다.
* 시스템을 모니터링합니다.

***

## Kona 증명으로 전환하는 방법

**1. cannon+kona 지원 배포 확인**

respected game type을 변경하기 전에 체인이 `CANNON` 게임과 `CANNON_KONA` 게임을 모두 지원하도록 업그레이드되었는지 확인합니다.

> [!NOTE]
>
> 필요한 업그레이드는 `cannonPrestate`와 `cannonKonaPrestate`를 모두 설정한 `OpChainConfig`로 `OPCM.upgrade`를 통해 수행됩니다.

1. **`OpChainConfig` prestate 확인**

   가장 최근 업그레이드에 사용한 `OpChainConfig`에 다음이 포함되어 있는지 확인합니다.

   * 유효한 `cannon64` prestate를 가리키는 `cannonPrestate`.
   * 유효한 `cannon64-kona` prestate를 가리키는 `cannonKonaPrestate`.

   두 해시 모두 superchain registry의 표준 prestate에서 가져와야 하며, 체인에 대한 최신 chain config가 포함되어 있어야 합니다.

2. **`DisputeGameFactory` 구현 확인**

   cannon+kona 업그레이드 후 `DisputeGameFactory`에는 다음이 있어야 합니다.

   * `CANNON`(0)에 대한 0이 아닌 구현, 그리고
   * `CANNON_KONA`(8)에 대한 0이 아닌 구현.

   예시 ([cast](https://getfoundry.sh/cast/reference/cast/) 사용):

   ```bash title="cast" theme={null}
   # CANNON (0) implementation
   cast call <DISPUTE_GAME_FACTORY_ADDRESS> "gameImpl(uint8)" 0

   # CANNON_KONA (8) implementation
   cast call <DISPUTE_GAME_FACTORY_ADDRESS> "gameImpl(uint8)" 8
   ```

   두 호출 모두 0이 아닌 주소를 반환해야 합니다.

**2. op-challenger의 Kona 지원 준비 확인**

respected game type을 변경하기 전에 challenger가 cannon 게임과 kona 게임을 모두 플레이할 수 있어야 합니다.

1. **Trace type**

   trace type을 명시적으로 구성하는 경우 `cannon-kona`가 포함되어 있는지 확인합니다. 일반적인 설정은 다음과 같습니다.

   ```bash theme={null}
   OP_CHALLENGER_TRACE_TYPE="cannon,cannon-kona,permissioned"
   # or
   --trace-type=cannon,cannon-kona,permissioned
   ```

2. **Prestate URL**

   `op-challenger`가 cannon prestate와 cannon-kona prestate를 모두 가져올 수 있는지 확인합니다.

   * 둘이 같은 URL에 있는 경우 다음을 사용합니다.

     ```bash theme={null}
     --prestates-url=<PRESTATES_URL>
     ```

   * 서로 다른 위치에 있는 경우 다음을 사용합니다.

     ```bash theme={null}
     --cannon-prestates-url=<CANNON_PRESTATES_URL>
     --cannon-kona-prestates-url=<CANNON_KONA_PRESTATES_URL>
     ```

3. **Kona host 바이너리**

   표준 OP Labs `op-challenger` Docker 이미지를 사용하지 않는 운영자는 다음도 제공해야 합니다.

   ```bash theme={null}
   --cannon-kona-server=/path/to/kona-host
   # or
   OP_CHALLENGER_CANNON_KONA_SERVER=/path/to/kona-host
   ```

   `kona-host` 바이너리는 Kona 저장소(예: `bin/host` 아래)에서 구할 수 있습니다. 구성한 `cannon-kona` prestate와 동일한 릴리스에서 빌드하세요.

**3. respected game type을 CANNON\_KONA로 전환**

온체인과 오프체인 구성 요소가 모두 준비되면 respected game type을 전환하여 Kona 증명이 출금의 정식 경로가 되도록 할 수 있습니다.

> [!WARNING]
>
> respected game type을 변경하면 출금 증명에 사용할 수 있는 게임이 달라집니다. Kona 설정에 확신이 있을 때만 이 단계를 수행하세요.

respected game type은 `AnchorStateRegistry` 컨트랙트에서 구성됩니다.

1. **calldata 인코딩**

   `cast calldata`를 사용하여 game type `8`(`CANNON_KONA`에 해당)로 `setRespectedGameType(uint32)` 호출을 인코딩합니다.

   ```bash title="cast" theme={null}
   CALLDATA=$(cast calldata "setRespectedGameType(uint32)" 8)
   ```

2. **트랜잭션 전송**

   Guardian에서 `AnchorStateRegistry`로 트랜잭션을 전송합니다.

   ```bash title="cast" theme={null}
   cast send \
     --rpc-url <L1_RPC_URL> \
     --private-key <GUARDIAN_PRIVATE_KEY> \
     <ANCHOR_STATE_REGISTRY_ADDRESS> \
     "$CALLDATA"
   ```

3. **새 respected game type 확인**

   트랜잭션이 확인되면 respected game type이 이제 `8`인지 확인합니다.

   ```bash title="cast" theme={null}
   cast call \
     --rpc-url <L1_RPC_URL> \
     <ANCHOR_STATE_REGISTRY_ADDRESS> \
     "respectedGameType()(uint32)"
   ```

   반환 값은 `8`이어야 하며, 이는 `CANNON_KONA`가 이제 respected game type임을 나타냅니다.

**4. game type 8을 사용하도록 op-proposer 업데이트**

`CANNON_KONA`가 respected game type으로 설정되면 proposer가 Kona 게임을 생성해야 합니다.

1. **proposer game type 업데이트**

   `op-proposer` 구성을 game type 0에서 8로 변경합니다.

   ```bash theme={null}
   # Before
   OP_PROPOSER_GAME_TYPE=0
   # or
   --game-type=0

   # After switching to Kona
   OP_PROPOSER_GAME_TYPE=8
   # or
   --game-type=8
   ```

   이 변경은 최초 cannon+kona 업그레이드의 일부로 필요한 것이 아니며, 실제로 respected game type을 `CANNON_KONA`로 전환할 때만 필요합니다.

2. **proposer 재시작**

   새 구성이 적용되도록 proposer 프로세스를 재시작합니다. 로그와 메트릭에서 이제 game type 8을 사용하고 있는지 확인합니다.

**5. 모니터링 및 검증**

Kona 증명으로 전환한 후 모든 것이 예상대로 작동하는지 체인을 면밀히 모니터링합니다.

1. **테스트 출금 실행**

   * 소액 테스트 출금을 몇 차례 수행하고 다음을 확인합니다.
     * 새 결함 분쟁 게임이 game type `CANNON_KONA`(8)로 생성되는지.
     * challenger가 `kona-host`를 사용하여 올바르게 응답하는지.

2. **메트릭 및 로그 관찰**

   * `op-proposer` 및 `op-challenger` 로그에서 오류를 모니터링합니다.
   * 분쟁 게임 메트릭(예: 게임 수 및 step 소요 시간)에서 이상 징후를 관찰합니다.

***

## 참고 자료

* [OP Stack 결함 증명 설명](https://docs.optimism.io/op-stack/fault-proofs/explainer.md)
* [결함 증명 스펙](https://specs.optimism.io/fault-proof/index.html)