체인을 Output Root에서 Super Root로 업그레이드하기

이 가이드는 아직 개발 중인 interop 기능에 의존합니다. 프로덕션 체인에서는 이 가이드를 따르지 마십시오.

이 런북은 단일 OP Stack 체인을 output-root 분쟁 게임(dispute game)(PERMISSIONED_CANNON, CANNON 또는 CANNON_KONA)에서 super-root 분쟁 게임(SUPER_PERMISSIONED 또는 SUPER_CANNON_KONA)으로 업그레이드하는 과정을 안내합니다. 이 작업은 체인의 기존 체인별 AnchorStateRegistry와 DisputeGameFactory를 대상으로 하는 단일 opcm.upgrade 호출로 실행됩니다. 체인의 권한 모델은 그대로 유지됩니다. permissioned 체인은 SUPER_PERMISSIONED만 사용하는 permissioned 상태를 유지하고, permissionless 체인은 두 super game type을 모두 실행하며 SUPER_CANNON_KONA를 respected game type으로 사용합니다. 둘 사이의 차이점은 본문 중에 별도로 언급합니다. 이 런북을 마치면 체인은 단일 체인 super-root RPC 엔드포인트를 사용하는 op-proposer를 통해 super-root 클레임을 제안하고, op-dispute-mon으로 이를 모니터링하게 됩니다. permissionless 체인에서는 op-challenger가 SUPER_CANNON_KONA 클레임을 방어합니다. permissioned 체인에서는 op-dispute-mon이 잘못된 SUPER_PERMISSIONED 클레임을 감지하고, 게임이 최종 확정되면 op-challenger가 AnchorStateRegistry를 업데이트합니다. 이미 진행 중인 모든 마이그레이션 이전 분쟁 게임은 계속 resolve되며, 증명된 출금은 무효화되지 않습니다.

이 작업은 opcm.migrate가 아니라 opcm.upgrade입니다. 체인은 자체 체인별 AnchorStateRegistry와 DisputeGameFactory를 그대로 유지합니다.

permissioned 결함 증명(fault proof)에서 permissionless 결함 증명으로 전환하려는 경우에는 permissionless 결함 증명으로 마이그레이션하기를 참조하십시오. 이 런북은 이미 결함 증명을 실행 중이며 output-root 게임에서 super-root 게임으로 옮겨야 하는 체인을 위한 것입니다.

시작하기 전에

필수 도구

아래 버전은 optimism 저장소의 mise.toml에 고정된 버전입니다. 특히 이전 버전의 cast는 이 런북에서 사용하는 function-selector 구문을 파싱하지 못할 수 있습니다.

도구	최소 버전
`foundry` (`cast`, `forge`)	`1.8.3`
`just`	`1.46.0`
`jq`	`1.7.1`
`go`	`1.26.10`
`curl`	모든 버전

op-fetcher(다음 단계에서 사용)를 실행하려면 optimism monorepo의 checkout도 필요합니다.

필수 입력값 수집

시작하기 전에 아래 항목을 모두 수집하십시오. 체인 식별 정보. 체인의 체인별 주소는 superchain-registry 저장소의 superchain/configs/<network>/<chain-name>.toml에 있습니다. 해당 파일을 열어 chain_id, addresses.SystemConfigProxy, addresses.L1StandardBridgeProxy를 확인합니다. 체인 주소와 역할. op-fetcher를 사용하면 명령 하나로 나머지 온체인 구성을 도출할 수 있습니다. 이 도구는 $L1_RPC를 통해 L1 컨트랙트를 읽고, SystemConfig와 L1StandardBridge에서 모든 체인별 proxy, 역할, 현재 결함 증명 상태를 조회합니다.

cd <optimism-monorepo>/op-fetcher
go run ./cmd fetch \
  --l1-rpc-url "$L1_RPC" \
  --system-config "<SystemConfigProxy>" \
  --l1-standard-bridge "<L1StandardBridgeProxy>" \
  --output-file chain.json

chain.json에서 필요한 값을 읽습니다.

항목	출처
L2 chain ID	체인 registry TOML의 `chain_id`
`SystemConfig` proxy	체인 registry TOML의 `addresses.SystemConfigProxy`
`OptimismPortal2` proxy	`.addresses.OptimismPortalProxy`
`AnchorStateRegistry` proxy (아래에서 `<ASR>`로 지칭)	`.addresses.AnchorStateRegistryProxy`
`DisputeGameFactory` proxy (아래에서 `<DGF>`로 지칭)	`.addresses.DisputeGameFactoryProxy`
`SuperchainConfig` proxy	`.addresses.SuperchainConfigProxy`

체인 유형. 업그레이드는 체인의 기존 권한 모델을 유지합니다. chain.json은 현재 respected game type을 .faultProofs.respectedGameType에 표시합니다.

1 (PERMISSIONED_CANNON) — 체인이 permissioned입니다. 새 respected game type은 5 (SUPER_PERMISSIONED)입니다.
0 (CANNON) 또는 8 (CANNON_KONA) — 체인이 permissionless입니다. 새 respected game type은 9 (SUPER_CANNON_KONA)입니다.

초기 본드(init bond). SUPER_PERMISSIONED(game type 5)는 본드가 없으며 initBond로 0을 사용해야 합니다. SUPER_CANNON_KONA(game type 9)는 기존 체인에서 사용하는 표준 값인 0.08 ether(80000000000000000 wei)를 사용합니다. 릴리스 아티팩트와 인프라.

항목	출처
대상 네트워크의 `OPCM` 주소	superchain-registry의 `validation/standard/standard-versions-<network>.toml`. `OPCMUpgradeV800` 템플릿이 고정한 `op-contracts/v8.x.y` 릴리스를 찾아 `op_contracts_manager.address`를 읽습니다.
Kona-interop prestate 해시	OPCM 릴리스 매니페스트. 체인에 interop이 예정되어 있지 않더라도 `-interop` kona 변형을 사용합니다.
Prestate 아티팩트 URL	업그레이드 전에 kona-interop prestate가 업로드된, 체인의 기존 `cannon-kona-prestates-url` 서버
단일 체인 super-root RPC 엔드포인트 (`$SUPER_ROOT_RPC`)	인프라 팀에 문의하십시오. 체인의 op-node RPC 엔드포인트 또는 op-supernode `/<chainID>/` 엔드포인트를 사용합니다. op-node는 `--safedb.path`가 활성화되고 데이터가 채워진 상태로 실행되어야 합니다. 네임스페이스가 지정된 엔드포인트는 op-supernode가 다른 체인을 추적하더라도 이 체인만 포함하는 super root를 반환합니다.

사전 조건 확인

구성을 변경하기 전에 다음을 확인하십시오.

템플릿의 추가 instruction을 확인합니다. superchain-ops/src/template/OPCMUpgradeV800.sol을 열어 _buildExtraInstructions를 확인합니다. 작성 시점 기준으로 이 함수는 overrides.cfg.startingRespectedGameType과 PermittedProxyDeployment를 주입합니다. 진행하기 전에 두 가지 모두 조치가 필요합니다. PermittedProxyDeployment는 제거해야 합니다. 통합 DelayedWETH가 7.x OPCM과 함께 배포되었기 때문에 OPCM 8.0.0은 업그레이드 중 proxy 배포를 허용하지 않으며, 따라서 이 instruction은 이제 OPContractsManagerV2_InvalidUpgradeInstruction으로 revert됩니다. overrides.cfg.startingAnchorRoot override는 추가해야 합니다. 이것이 없으면 OPCM은 기존 온체인 startingAnchorRoot로 대체하는데, 업그레이드 이전 체인에서 이 값은 블록 번호 형태의 l2SequenceNumber를 가진 output-root 형태의 값이므로 유효한 super-root 앵커가 아닙니다. 템플릿을 확장하여 TOML에서 시작 super-root 앵커를 읽고 이를 추가 instruction으로 추가해야 합니다. 진행하기 전에 템플릿을 수정하십시오.
RPC 엔드포인트가 단일 체인 super root를 반환하는지 확인합니다. 체인의 op-node RPC 엔드포인트 또는 op-supernode /<chainID>/ 엔드포인트 중 하나를 사용할 수 있습니다. 멀티체인 op-supernode 루트 엔드포인트는 사용하지 마십시오. 이 엔드포인트는 전체 dependency set에 걸쳐 root를 계산합니다.
단일 체인 RPC 엔드포인트가 정상인지 확인합니다. op-node 또는 네임스페이스가 지정된 op-supernode 엔드포인트의 경우, 최근 finalized L2 head를 보고하고 그에 대응하는 super root를 생성할 수 있는지 확인합니다.
TS=$(cast rpc optimism_syncStatus --rpc-url $SUPER_ROOT_RPC | jq -r '.finalized_l2.timestamp') cast rpc superroot_atTimestamp "$(cast 2h $TS)" \ --rpc-url $SUPER_ROOT_RPC | jq -r '.data.super_root'
op-node가 SafeDB 오류를 반환하면 --safedb.path를 구성하고, node가 derivation을 통해 레코드를 채우도록 한 다음 다시 시도하십시오. SafeDB가 비활성화되어 있어도 optimism_syncStatus는 성공할 수 있지만, SafeDB 없이는 superroot_atTimestamp가 genesis가 아닌 timestamp를 제공할 수 없습니다.
prestate 서버가 새 해시를 제공하는지 확인합니다.
curl -fI "$PRESTATE_URL/$SUPER_PRESTATE_HASH.bin.gz"

오프체인 구성 준비

온체인 업그레이드를 제출하기 전에 이 변경 사항을 적용하십시오. 변경 사항이 배포된 후에도 구성 요소는 기존 마이그레이션 이전 게임에 대해 계속 동작하며, 업그레이드가 적용되면 super-root 게임을 자동으로 인식합니다.

op-challenger 업데이트

체인에서 실행 중인 op-challenger를 업데이트합니다. 기존 게임을 계속 방어할 수 있도록 --rollup-rpc와 기존 --game-types는 유지하십시오. super-root trace type은 SUPER_CANNON_KONA가 활성화되는 permissionless 체인에만 추가합니다.

작업	플래그 (환경 변수)	값
추가	`--superroot-rpc` (`OP_CHALLENGER_SUPERROOT_RPC`)	`$SUPER_ROOT_RPC`
값 덧붙이기	`--game-types` (`OP_CHALLENGER_GAME_TYPES`)	`super-cannon-kona`. `super-permissioned`는 추가하지 마십시오. 단순화된 `SUPER_PERMISSIONED` 게임은 클레임 게시가 필요하지 않습니다.
설정 확인	`--cannon-kona-prestates-url` (`OP_CHALLENGER_CANNON_KONA_PRESTATES_URL`)	사전 조건에서 검증한 prestate 서버 URL
설정 확인	`--cannon-kona-network` (`OP_CHALLENGER_CANNON_KONA_NETWORK`) 또는 `--cannon-kona-depset-config` (`OP_CHALLENGER_CANNON_KONA_DEPSET_CONFIG`)	kona가 `SUPER_CANNON_KONA`의 dependency set을 확인할 수 있도록 둘 중 하나를 설정해야 합니다.

permissionless 체인에서는 시작 로그에 super-cannon-kona가 등록된 것으로 표시되고, 단일 체인 super-root RPC 엔드포인트에 대한 연결 오류가 없는지 확인합니다. permissioned 체인에서는 기존 trace type이 계속 등록되어 있는지 확인하고, SUPER_PERMISSIONED trace type은 구성하지 마십시오. permissioned 체인에서도 SUPER_PERMISSIONED 게임이 최종 확정될 때 AnchorStateRegistry를 업데이트하기 위해 op-challenger가 여전히 필요합니다.

op-dispute-mon 업데이트

체인에서 실행 중인 op-dispute-mon을 업데이트합니다.

작업	플래그 (환경 변수)	값
추가	`--superroot-rpc` (`OP_DISPUTE_MON_SUPERROOT_RPC`)	`$SUPER_ROOT_RPC`

--rollup-rpc는 유지하십시오. op-dispute-mon은 기존 DisputeGameFactory에서 게임을 탐색하므로 game type 필터를 변경할 필요가 없습니다. 재시작 후 기존 게임 metric이 계속 채워지는지 확인하십시오.

op-proposer는 당분간 변경하지 않기

전환 전까지 op-proposer는 건너뜁니다. 구성 변경은 op-proposer를 Super Root로 전환에서 진행합니다.

시작 앵커 Super Root 생성

업그레이드는 super-root 형태의 시작 앵커로 <ASR>를 다시 초기화해야 합니다. 기존 온체인 startingAnchorRoot는 output-root 형식(l2SequenceNumber가 L2 블록 번호)이므로, 템플릿은 extraInstructions의 overrides.cfg.startingAnchorRoot를 통해 새로운 super-root 값을 주입해야 합니다. 위의 사전 조건에서 템플릿이 이 값을 TOML에서 읽어 전달하도록 확장되었는지 확인하십시오. superroot_atTimestamp를 사용하여 값을 계산합니다. 현재 finalized timestamp(또는 최근의 아무 finalized timestamp)를 선택한 다음, 단일 체인 RPC 엔드포인트에 해당 timestamp의 super root를 요청합니다.

# .finalized_l2.timestamp is a JSON number (decimal Unix seconds).
TS=$(cast rpc optimism_syncStatus --rpc-url $SUPER_ROOT_RPC | jq -r '.finalized_l2.timestamp')
# superroot_atTimestamp expects a hex-encoded JSON string (hexutil.Uint64); cast 2h handles the conversion.
cast rpc superroot_atTimestamp "$(cast 2h $TS)" --rpc-url $SUPER_ROOT_RPC | jq -r '.data.super_root'
echo "timestamp=$TS"

두 값을 확보합니다.

super_root(.data.super_root의 bytes32 해시) — overrides.cfg.startingAnchorRoot의 Proposal.root로 전달됩니다.
timestamp(전달한 uint64 값) — Proposal.l2SequenceNumber로 전달됩니다. 이 필드는 블록 번호나 시퀀스 인덱스가 아니라 timestamp 자체입니다.

superchain-ops task 작성

OPCMUpgradeV800 템플릿을 사용하여 superchain-ops/src/tasks/<network>/<NNN-name>/ 아래에 새 task 디렉터리를 작성합니다. 아래 스키마는 템플릿이 (위의 사전 조건에 따라) 시작 super-root 앵커도 읽고 이를 overrides.cfg.startingAnchorRoot로 주입하도록 확장되었다고 가정합니다.

config.toml 구성

l2chains = [
    {name = "<chain name>", chainId = <chain id>},
]

templateName = "OPCMUpgradeV800"

[[opcmUpgrades]]
chainId = <chain id>
# Kona-interop super prestate, used by SUPER_CANNON_KONA. The `-interop` variant
# supports super roots and works whether
# or not interop is enabled or scheduled on the chain.
cannonKonaPrestate = "0x<kona-interop super prestate>"
expectedValidationErrors = ""   # fill in after the dry run
initBond = 80000000000000000    # 0.08 ether, applied to `SUPER_CANNON_KONA` games; the template always forces SUPER_PERMISSIONED to 0
startingRespectedGameType = <9 or 5>   # 9 permissionless, 5 permissioned

# Pending template extension — see the "Generate the Starting Anchor Super Root" section.
startingAnchorRoot = { root = "0x<super root hash>", l2SequenceNumber = <timestamp> }

[addresses]
OPCM = "0x<OPCM v8.x.y address>"

템플릿이 나머지(game type별 구성, SuperchainConfig, validator 등)를 모두 자동으로 도출하므로 TOML을 더 작성할 필요가 없습니다.

expectedValidationErrors 확보

task 디렉터리 안에서 L1 fork를 대상으로 시뮬레이션 모드로 task를 실행합니다.

cd superchain-ops/src/tasks/<network>/<NNN-name>
just simulate

validator의 출력이 TOML의 expectedValidationErrors와 일치하지 않으면 시뮬레이션은 Unexpected errors: <actual>; expected: <expectedValidationErrors> 형식의 메시지와 함께 revert됩니다. 해당 revert 메시지에서 실제 코드를 확인하십시오. 기본 기대값은 오류 없음, 즉 expectedValidationErrors = ""이며 시뮬레이션이 깔끔하게 통과하는 것입니다. 비어 있지 않은 오류 문자열은 그대로 복사해 붙여 넣지 말고 코드별로 검토해야 합니다. 각 코드에 대해 다음을 수행하십시오.

잘못된 주소, 잘못된 prestate, 템플릿 릴리스 불일치, 누락된 override, 업데이트가 필요한 registry 항목 등 수정 가능한 입력을 가리킨다면 해결합니다.
이 체인에서 구조적으로 예상되는 이유를 설명하는 인라인 주석을 TOML에 달아 정당성을 입증한 후에만 expectedValidationErrors에 추가합니다.

출력된 모든 코드가 해결되었거나 정당한 근거와 함께 의도적으로 추가되면 시뮬레이션이 통과합니다. 설명할 수 없는 코드가 있다면 반드시 작업을 중단하십시오.

업그레이드 실행

체인의 op-proposer를 중지합니다. 기존 게임은 계속 resolve되며, 새 제안만 중단됩니다.
op-challenger와 op-dispute-mon은 계속 실행합니다. 두 서비스 모두 앞에서 구성되었으며 super-root 게임을 자동으로 인식합니다.
팀의 표준 superchain-ops 서명 워크플로를 사용하여 task에 서명하고 브로드캐스트합니다.
L1 트랜잭션이 확정될 때까지 기다립니다.

온체인 효과는 다음과 같습니다.

<ASR>가 제공된 앵커와 respected game type으로 다시 초기화됩니다. retirement timestamp는 갱신되지 않으므로 기존 진행 중인 게임은 유효한 상태로 유지됩니다.
super 분쟁 게임 구현(하나 또는 여러 개)이 <DGF>에 설치됩니다.
enabled = false로 전달된 game type의 구현 포인터가 비워져, 해당 유형의 새 게임 생성이 차단됩니다.

온체인에서 업그레이드 검증

op-proposer를 전환하기 전에 아래 검사를 실행하십시오.

어느 검사라도 실패하면 중단하고, 새 proposer를 시작하지 말고, 표준 사고 대응 채널을 통해 에스컬레이션하십시오. proposer가 오작동하는 반쯤 전환된 상태에서 복구하는 것은 pause된 proposer 상태에서 복구하는 것보다 훨씬 어렵습니다.

공통 검사

# Respected game type
cast call <ASR> 'respectedGameType()(uint32)' --rpc-url $L1_RPC
# Expect: 9 (permissionless) or 5 (permissioned)

# Anchor root and timestamp
cast call <ASR> 'getAnchorRoot()(bytes32,uint256)' --rpc-url $L1_RPC
# Expect: (<super root hash>, <timestamp>) from the previous step

# Retirement timestamp unchanged
cast call <ASR> 'retirementTimestamp()(uint64)' --rpc-url $L1_RPC
# Expect: same value as before the upgrade

# Pre-migration impls cleared
cast call <DGF> 'gameImpls(uint32)(address)' 0 --rpc-url $L1_RPC   # CANNON
cast call <DGF> 'gameImpls(uint32)(address)' 1 --rpc-url $L1_RPC   # PERMISSIONED_CANNON
cast call <DGF> 'gameImpls(uint32)(address)' 8 --rpc-url $L1_RPC   # CANNON_KONA
# Expect each: 0x0000000000000000000000000000000000000000

Permissionless 체인 검사

cast call <DGF> 'gameImpls(uint32)(address)' 5 --rpc-url $L1_RPC   # SUPER_PERMISSIONED
cast call <DGF> 'gameImpls(uint32)(address)' 9 --rpc-url $L1_RPC   # SUPER_CANNON_KONA
# Expect both: non-zero

cast call <DGF> 'initBonds(uint32)(uint256)' 5 --rpc-url $L1_RPC
# Expect: 0
cast call <DGF> 'initBonds(uint32)(uint256)' 9 --rpc-url $L1_RPC
# Expect: 80000000000000000, or the configured SUPER_CANNON_KONA bond

Permissioned 체인 검사

cast call <DGF> 'gameImpls(uint32)(address)' 5 --rpc-url $L1_RPC   # SUPER_PERMISSIONED
# Expect: non-zero

cast call <DGF> 'initBonds(uint32)(uint256)' 5 --rpc-url $L1_RPC
# Expect: 0

cast call <DGF> 'gameImpls(uint32)(address)' 9 --rpc-url $L1_RPC   # SUPER_CANNON_KONA
# Expect: 0x0000000000000000000000000000000000000000

op-proposer를 Super Root로 전환

새 구성으로 op-proposer를 시작합니다.

플래그 (환경 변수)	이전	신규
`--rollup-rpc` (`OP_PROPOSER_ROLLUP_RPC`)	설정됨	제거
`--superroot-rpcs` (`OP_PROPOSER_SUPERROOT_RPCS`)	설정 안 됨	`$SUPER_ROOT_RPC`, 또는 각각 이 체인만 포함하는 super root를 반환하는 고가용성 엔드포인트 목록
`--game-type` (`OP_PROPOSER_GAME_TYPE`)	`0` 또는 `1`	숫자: permissionless는 `9`, permissioned는 `5`
`--game-factory-address` (`OP_PROPOSER_GAME_FACTORY_ADDRESS`)	변경 없음	변경 없음 (동일한 `<DGF>`)

--proposal-interval, --poll-interval 등 다른 플래그는 그대로 유지합니다. 시작 후 다음을 확인합니다.

로그에 proposer가 구성된 단일 체인 super-root RPC 엔드포인트를 폴링하는 내용이 표시되고, --rollup-rpc에 대한 참조가 없습니다.

--proposal-interval 한 번 이내에 proposer가 새 게임을 제출합니다. 이를 검사합니다.

COUNT=$(cast call <DGF> 'gameCount()(uint256)' --rpc-url $L1_RPC)
# Expect: increased by 1 since the upgrade
echo "gameCount=$COUNT"

read -r GAME_TYPE CREATED_AT GAME_PROXY < <(cast call <DGF> 'gameAtIndex(uint256)(uint32,uint64,address)' $((COUNT-1)) --rpc-url $L1_RPC)
# Expect: gameType matches the configured super type (5 or 9) and gameProxy is non-zero.
echo "gameType=$GAME_TYPE createdAt=$CREATED_AT gameProxy=$GAME_PROXY"

cast call $GAME_PROXY 'rootClaim()(bytes32)'        --rpc-url $L1_RPC
cast call $GAME_PROXY 'l2SequenceNumber()(uint256)' --rpc-url $L1_RPC

제안된 timestamp에 대한 super root를 다시 계산하여 제안과 일치하는지 확인합니다.
cast rpc superroot_atTimestamp "$(cast 2h <l2SequenceNumber from above>)" \ --rpc-url $SUPER_ROOT_RPC | jq -r '.data.super_root' # Expect: equals rootClaim from above
이를 통해 op-proposer가 올바르게 구성되어 유효한 super root를 전달하고 있음을 확인할 수 있습니다.

업그레이드 후 검증

proposer가 안정화되면 다음 검사를 실행하십시오.

마이그레이션 이전 게임이 여전히 resolve되는지 확인합니다. 진행 중인 마이그레이션 이전 게임 하나를 골라(op-dispute-mon 대시보드나 gameAtIndex를 사용하여 찾음) resolve될 때까지 상태를 지켜봅니다.
cast call <gameProxy> 'status()(uint8)' --rpc-url $L1_RPC # 0 = IN_PROGRESS, 1 = CHALLENGER_WINS, 2 = DEFENDER_WINS
활성화된 경우 op-challenger가 SUPER_CANNON_KONA를 추적하는지 확인합니다. permissionless 체인에서는 시작 로그에 super-cannon-kona가 표시되고, type-9 게임이 나타날 때 지속적인 로그에 scheduler 또는 game-poll 오류가 없는지 확인합니다. permissioned 체인에서는 op-challenger가 SUPER_PERMISSIONED 게임이 최종 확정될 때 계속 AnchorStateRegistry를 업데이트하지만, 클레임을 게시할 필요는 없습니다.
op-dispute-mon이 super-root 게임을 보고하는지 확인합니다. op_dispute_mon_games가 활성화된 super game type을 보고하고 op_dispute_mon_failed_games가 0으로 유지되는지 확인합니다. permissioned 체인에서는 SUPER_PERMISSIONED에 대한 op_dispute_mon_games_agreement{status="disagree_defender_wins"} 및 Unexpected game result 로그에 대해 알림을 설정하십시오.
새로운 마이그레이션 이전 게임을 생성할 수 없는지 확인합니다. 선택적으로, 비활성화된 game type 중 하나로 DisputeGameFactory.create를 호출하여 revert되는지 확인합니다.
첫 번째 super game 최종 확정 시 앵커가 전진하는지 확인합니다. 첫 번째 앵커 업데이트는 일반적으로 첫 번째 super-root 게임이 생성된 후 약 7일(게임 진행 기간 + disputeGameFinalityDelaySeconds()) 뒤에 이루어집니다. 이 때문에 롤아웃을 막지는 마십시오. 해당 기간 후 getAnchorRoot()를 다시 실행하여 시작 root 대신 새 게임의 클레임이 반환되는지 확인하는 후속 작업을 예약하십시오. 기다리며 대기하기보다는 op-dispute-mon으로 추적하십시오.

체인 출시

가이드

튜토리얼

도구

참조

아카이브

체인을 Output Root에서 Super Root로 업그레이드하기

체인을 Output Root에서 Super Root로 업그레이드하기

시작하기 전에

필수 도구

필수 입력값 수집

사전 조건 확인

오프체인 구성 준비

op-challenger 업데이트

op-dispute-mon 업데이트

op-proposer는 당분간 변경하지 않기

시작 앵커 Super Root 생성

superchain-ops task 작성

config.toml 구성

expectedValidationErrors 확보

업그레이드 실행

온체인에서 업그레이드 검증

공통 검사

Permissionless 체인 검사

Permissioned 체인 검사

op-proposer를 Super Root로 전환

업그레이드 후 검증

​체인을 Output Root에서 Super Root로 업그레이드하기

​시작하기 전에

​필수 도구

​필수 입력값 수집

​사전 조건 확인

​오프체인 구성 준비

​op-challenger 업데이트

​op-dispute-mon 업데이트

​op-proposer는 당분간 변경하지 않기

​시작 앵커 Super Root 생성

​superchain-ops task 작성

​config.toml 구성

​expectedValidationErrors 확보

​업그레이드 실행

​온체인에서 업그레이드 검증

​공통 검사

​Permissionless 체인 검사

​Permissioned 체인 검사

​op-proposer를 Super Root로 전환

​업그레이드 후 검증

체인을 Output Root에서 Super Root로 업그레이드하기

시작하기 전에

필수 도구

필수 입력값 수집

사전 조건 확인

오프체인 구성 준비

op-challenger 업데이트

op-dispute-mon 업데이트

op-proposer는 당분간 변경하지 않기

시작 앵커 Super Root 생성

superchain-ops task 작성

config.toml 구성

expectedValidationErrors 확보

업그레이드 실행

온체인에서 업그레이드 검증

공통 검사

Permissionless 체인 검사

Permissioned 체인 검사

op-proposer를 Super Root로 전환

업그레이드 후 검증