​

두 체인을 공유 분쟁 게임으로 병합하기

​

시작하기 전에

• 정확히 두 개의 체인(아래에서는 chainA와 chainB로 지칭)을 병합합니다.
• 두 체인 모두 아직 interop을 활성화하지 않았습니다.
• 두 체인 모두 현재 SUPER_CANNON_KONA(game type 9)를 respected game type으로 하여 permissionless 결함 증명(fault proof)을 실행하고 있습니다.
• 단일 체인 super-roots 업그레이드에서 구성한 체인별 op-proposer, op-challenger, op-dispute-mon 인스턴스가 두 체인 모두에서 실행 중입니다. 체인별 challenger와 모니터는 마이그레이션 전환과 이후의 drain 기간 동안 계속 실행됩니다.
• 별도의 op-supernode 인스턴스가 동기화되어 있으며, 하나의 프로세스에서 정확히 chainA와 chainB만(다른 체인 없이) derive합니다. 이 supernode는 마이그레이션 후 새로운 공유 op-proposer, op-challenger, op-dispute-mon이 가리키는 supernode이며, 다른 체인이나 interop 클러스터를 위한 멀티체인 supernode로 겸용해서는 안 됩니다.
• 두 체인 모두 Upgrade 21에 포함되고 OPContractsManagerV2.migrate를 제공하는 op-contracts/v9.0.0 이상으로 이미 업그레이드되었으며, SystemConfig에서 Features.ETH_LOCKBOX가 활성화되어 있습니다. ETH_LOCKBOX는 OPContractsManagerV2.upgrade()에 의해 자동으로 활성화되며, 이 사전 업그레이드는 이 런북의 전제 조건입니다. Features.INTEROP은 시작 시점에 반드시 비활성화 상태여야 하며, migrate()가 이를 활성화합니다.
• migrate를 호출하는 OPCM은 각 체인을 마지막으로 업그레이드한 OPCM이거나, 해당 OPCM과 major 버전이 같고 minor 버전이 같거나 더 높아야 합니다. 그렇지 않으면 migrate가 OPContractsManagerV2_InvalidUpgradeSequence로 revert됩니다.

​

필수 도구 설치

​

필수 입력값 수집

op-fetcher fetch \
  --l1-rpc-url $L1_RPC \
  --system-config <SystemConfigProxy> \
  --l1-standard-bridge <L1StandardBridgeProxy> \
  --output-file <chainX>.json

​

사전 조건 확인

• 두 체인의 ProxyAdmin owner가 같은지 확인합니다. 그렇지 않으면 migrate가 OPContractsManagerMigrator_ProxyAdminOwnerMismatch로 revert됩니다. owner Safe가 두 체인에서 동일하기만 하면 각 체인의 ProxyAdmin proxy는 달라도 됩니다.
  diff <(jq -r '.roles.OpChainProxyAdminOwner' <chainA>.json) <(jq -r '.roles.OpChainProxyAdminOwner' <chainB>.json)
  # Expect: no output (identical).
  
• 두 체인의 SuperchainConfig가 같은지 확인합니다. 그렇지 않으면 migrate가 OPContractsManagerMigrator_SuperchainConfigMismatch로 revert됩니다.
  diff <(jq -r '.addresses.SuperchainConfigProxy' <chainA>.json) <(jq -r '.addresses.SuperchainConfigProxy' <chainB>.json)
  # Expect: no output (identical).
  
• 두 체인의 finality delay와 DelayedWETH delay가 같은지 확인합니다. 그렇지 않으면 migrate가 OPContractsManagerMigrator_DisputeGameFinalityDelayMismatch 또는 OPContractsManagerMigrator_WithdrawalDelayMismatch로 revert됩니다.
  cast call <oldASR_chainA> 'disputeGameFinalityDelaySeconds()(uint256)' --rpc-url $L1_RPC
  cast call <oldASR_chainB> 'disputeGameFinalityDelaySeconds()(uint256)' --rpc-url $L1_RPC
  for SC in <SystemConfig_chainA> <SystemConfig_chainB>; do
      cast call "$(cast call $SC 'delayedWETH()(address)' --rpc-url $L1_RPC)" 'delay()(uint256)' --rpc-url $L1_RPC
  done
  # Expect: the two finality delays match, and the two DelayedWETH delays match.
  
• 두 체인 모두에서 Features.INTEROP이 비활성화되어 있고 Features.ETH_LOCKBOX가 활성화되어 있는지 확인합니다. L1에서 INTEROP을 설정하는 것은 migrate()뿐이므로, 이미 INTEROP이 켜져 있는 체인은 이미 interop 세트에 속해 있는 것입니다. _validateChainSystemConfigs는 INTEROP이 이미 켜져 있으면 OPContractsManagerMigrator_ChainAlreadyMigrated로 revert되므로, SystemConfig.setFeature를 통해 직접 INTEROP을 활성화하지 마십시오. 그렇게 하면 마이그레이션이 영구적으로 차단됩니다. ETH_LOCKBOX는 전제 조건인 OPCMv2.upgrade() 중에 자동으로 켜집니다. 아래 ETH_LOCKBOX 검사 중 하나라도 false를 반환하면 먼저 해당 사전 업그레이드를 실행하십시오. Features 상수는 short-string bytes32 값이므로 cast format-bytes32-string을 거쳐 전달합니다.
  for SC in <SystemConfig_chainA> <SystemConfig_chainB>; do
      for F in INTEROP ETH_LOCKBOX; do
          echo "$SC $F = $(cast call $SC 'isFeatureEnabled(bytes32)(bool)' "$(cast format-bytes32-string $F)" --rpc-url $L1_RPC)"
      done
  done
  # Expect: both INTEROP lines end in false, both ETH_LOCKBOX lines end in true.
  
• 사전 업그레이드 전에 scoped pause를 해제합니다. OPCMv2.upgrade()는 ETH_LOCKBOX를 켜는데, SystemConfig.setFeature는 portal이 scoped pause 상태인 동안에는 이를 거부합니다. lockbox를 활성화하면 pause 검사 대상이 portal 주소에서 lockbox 주소로 옮겨지므로, 이 보호 장치가 없으면 체인이 업그레이드 후 pause가 해제된 상태가 됩니다. 어느 한 portal이라도 pause 상태라면 Guardian이 먼저 이를 해제해야 합니다.
• 두 체인 모두 Custom Gas Token 모드로 실행되지 않는지 확인합니다. _migratePortal은 CGT 체인에 대해 OPContractsManagerMigrator_CustomGasTokenNotSupported로 revert됩니다.
  cast call <SystemConfig_chainA> 'isCustomGasToken()(bool)' --rpc-url $L1_RPC
  cast call <SystemConfig_chainB> 'isCustomGasToken()(bool)' --rpc-url $L1_RPC
  # Expect: both false.
  
• 두 체인의 현재 respected game type이 SUPER_CANNON_KONA(9)인지 확인합니다.
  cast call <oldASR_chainA> 'respectedGameType()(uint32)' --rpc-url $L1_RPC
  cast call <oldASR_chainB> 'respectedGameType()(uint32)' --rpc-url $L1_RPC
  # Expect: 9 for both.
  
• 공유 supernode가 병합할 두 체인만 정확히 derive하는지 확인합니다. $SUPERNODE_RPC 뒤의 인스턴스가 dependency set에 chainA와 chainB를 포함하고 다른 체인은 포함하지 않는지 인프라 팀과 함께 확인하십시오. 관련 없는 체인(또는 그런 체인을 포함하는 interop 클러스터)도 추적하는 supernode는 더 넓은 세트에 대해 super root를 계산하며, 그 root는 공유 SUPER_CANNON_KONA 및 SUPER_PERMISSIONED 게임이 검증하는 값과 일치하지 않습니다.
• 공유 supernode가 동기화되어 있는지 확인합니다. 두 체인의 예상 finality 기간 내에 있는 finalized L2 head를 보고해야 합니다.
  cast rpc supernode_syncStatus --rpc-url $SUPERNODE_RPC | jq -r '.finalized_timestamp'
  
  supernode가 어느 한 체인보다 크게 뒤처져 있다면 마이그레이션을 연기하십시오.
• prestate 서버가 SUPER_CANNON_KONA prestate를 제공하는지 확인합니다.
  curl -fI "$PRESTATE_URL/$SUPER_CANNON_KONA_PRESTATE.bin.gz"
  
• chain B의 DelayedWETH 불일치에 유의합니다. migrate는 새 공유 super game에 chain A의 DelayedWETH를 재사용하며 chain B의 것은 건드리지 않습니다. 마이그레이션 후에도 chain B의 SystemConfig.delayedWETH()는 여전히 chain B의 이전 DelayedWETH를 참조하며, 이 컨트랙트는 더 이상 어떤 super game에도 연결되어 있지 않습니다. 따라서 이후 chain B를 대상으로 SystemConfig.delayedWETH()를 읽는 OPCMv2.upgrade() 호출은 공유 게임이 사용하는 것과 다른 컨트랙트를 참조하게 됩니다. 향후 업그레이드에서 예상치 못한 상황이 발생하지 않도록 운영 런북에 이를 기록해 두십시오. chain B의 진행 중인 마이그레이션 이전 게임이 게시한 본드는 계속 chain B의 이전 DelayedWETH에서 청구되므로, 이 불일치가 마이그레이션 이전 게임 drain 및 본드 회수에 설명된 drain을 막지는 않습니다.

​

오프체인 구성 준비

​

체인별 서비스가 공유 op-supernode를 가리키도록 설정

​

공유 op-challenger 구성

​

공유 op-dispute-mon 구성

​

나머지 op-proposer 설정은 당분간 유지

​

시작 앵커 Super Root 생성

# .finalized_timestamp is a JSON number (decimal unix seconds).
TS=$(cast rpc supernode_syncStatus --rpc-url $SUPERNODE_RPC | jq -r '.finalized_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 $SUPERNODE_RPC | jq -r '.data.super_root'
echo "timestamp=$TS"

• super_root(.data.super_root의 bytes32 해시) — startingAnchorRoot의 Proposal.root로 전달됩니다.
• timestamp(전달한 uint64 값) — Proposal.l2SequenceNumber로 전달됩니다. super game에서 이 필드는 블록 번호가 아니라 timestamp 자체입니다.

• 별도로 실행되는 op-supernode에 동일한 timestamp의 super root를 요청합니다. 이 supernode도 같은 두 체인을 derive해야 합니다.
• 이 OPCM 릴리스에 대한 SUPER_CANNON_KONA prestate를 standard-prestates.toml에서 조회합니다.
• 두 결과를 task의 config.toml에 있는 값과 비교합니다.

​

superchain-ops task 작성

​

config.toml 구성

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

templateName = "OPCMMigrateInterop"

[addresses]
OPCM = "0x<OPCM address>"

# One stanza per chain, both required.
[[migrateChains]]
chainId = <chainA id>
systemConfigProxy = "0x<SystemConfig_chainA>"

[[migrateChains]]
chainId = <chainB id>
systemConfigProxy = "0x<SystemConfig_chainB>"

# Starting anchor for the new shared AnchorStateRegistry, computed in the previous step.
[startingAnchorRoot]
root = "0x<super root hash>"
l2SequenceNumber = <timestamp>

# 9 = SUPER_CANNON_KONA. Required because both chains run permissionless fault proofs today.
startingRespectedGameType = 9

# Both super game types must be registered. The migration validator requires it.
# The template assembles the on-chain DisputeGameConfig.gameArgs bytes from these
# fields: abi.encode(absolutePrestate) for game type 9, and
# abi.encode(proposer) for game type 5.

[[disputeGameConfigs]]
gameType = 9                             # SUPER_CANNON_KONA
enabled = true
initBond = 80000000000000000             # match the value gathered in the inputs
absolutePrestate = "0x<super-cannon-kona prestate>"

[[disputeGameConfigs]]
gameType = 5                             # SUPER_PERMISSIONED
enabled = true
initBond = 0                             # SUPER_PERMISSIONED does not charge init bonds
proposer = "0x<privileged proposer>"

expectedValidationErrors = ""            # fill in after the dry run if any structurally expected codes appear

​

expectedValidationErrors 확보

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

​

마이그레이션 실행

1. 두 체인별 op-proposer 프로세스를 중지합니다. 마이그레이션이 브로드캐스트되면 체인별 factory에 더 이상 SUPER_CANNON_KONA가 등록되어 있지 않으므로 DisputeGameFactory.create가 revert됩니다. proposer를 먼저 중지하면 gas 낭비를 막을 수 있습니다.
2. 두 체인별 op-challenger 및 op-dispute-mon 인스턴스는 계속 실행합니다. 이 인스턴스들은 체인별 factory에서 진행 중인 마이그레이션 이전 게임을 계속 방어하고 관찰합니다.
3. 팀의 표준 superchain-ops 서명 워크플로를 사용하여 task에 서명하고 브로드캐스트합니다.
4. L1 트랜잭션이 확정될 때까지 기다립니다.

• OPCM이 새로운 ETHLockbox, DisputeGameFactory, AnchorStateRegistry proxy를 배포하고 초기화합니다. 새 AnchorStateRegistry는 새 factory에 바인딩되며, 초기화 시 retirementTimestamp를 block.timestamp로 설정합니다.
• OPCM이 각 체인에서 OptimismPortal2.migrateToSharedDisputeGame을 호출하여 portal이 새 lockbox와 새 AnchorStateRegistry를 가리키도록 합니다. 또한 각 체인의 기존 portal을 공유 lockbox에 승인하고, 각 체인의 기존 lockbox가 유동성을 전달할 수 있도록 승인한 뒤, 해당 유동성을 공유 lockbox로 마이그레이션합니다.
• OPCM이 각 체인의 기존 체인별 DisputeGameFactory에 있는 모든 구현 포인터를 0으로 설정합니다. 해당 factory에 이미 배포된 게임 proxy는 영향을 받지 않으며 계속 resolve됩니다.

op-fetcher fetch \
  --l1-rpc-url $L1_RPC \
  --system-config <SystemConfig_chainA> \
  --l1-standard-bridge <L1StandardBridge_chainA> \
  --output-file <chainA>-postmigrate.json

op-fetcher fetch \
  --l1-rpc-url $L1_RPC \
  --system-config <SystemConfig_chainB> \
  --l1-standard-bridge <L1StandardBridge_chainB> \
  --output-file <chainB>-postmigrate.json

SHARED_ASR=$(jq -r '.addresses.AnchorStateRegistryProxy' <chainA>-postmigrate.json)
SHARED_DGF=$(jq -r '.addresses.DisputeGameFactoryProxy' <chainA>-postmigrate.json)
SHARED_LOCKBOX=$(jq -r '.addresses.EthLockboxProxy' <chainA>-postmigrate.json)

diff <(jq -r '.addresses.AnchorStateRegistryProxy, .addresses.DisputeGameFactoryProxy, .addresses.EthLockboxProxy' <chainA>-postmigrate.json) \
     <(jq -r '.addresses.AnchorStateRegistryProxy, .addresses.DisputeGameFactoryProxy, .addresses.EthLockboxProxy' <chainB>-postmigrate.json)
# Expect: no output (identical).

​

온체인에서 마이그레이션 검증

​

공유 Registry와 Factory 검증

# Respected game type on the new ASR
cast call $SHARED_ASR 'respectedGameType()(uint32)' --rpc-url $L1_RPC
# Expect: 9 (SUPER_CANNON_KONA)

# Anchor root and timestamp on the new ASR
cast call $SHARED_ASR 'getAnchorRoot()(bytes32,uint256)' --rpc-url $L1_RPC
# Expect: (<super root hash>, <timestamp>) from "Generate the Starting Anchor Super Root"

# Retirement timestamp on the new ASR
cast call $SHARED_ASR 'retirementTimestamp()(uint64)' --rpc-url $L1_RPC
# Expect: equal to the migration block's timestamp

# Game implementations registered on the shared factory
cast call $SHARED_DGF 'gameImpls(uint32)(address)' 5 --rpc-url $L1_RPC   # SUPER_PERMISSIONED
cast call $SHARED_DGF 'gameImpls(uint32)(address)' 9 --rpc-url $L1_RPC   # SUPER_CANNON_KONA
# Expect both: non-zero

# Init bonds match each game type's configuration
cast call $SHARED_DGF 'initBonds(uint32)(uint256)' 5 --rpc-url $L1_RPC
# Expect: 0
cast call $SHARED_DGF 'initBonds(uint32)(uint256)' 9 --rpc-url $L1_RPC
# Expect: 80000000000000000

# No legacy implementations registered on the shared factory
cast call $SHARED_DGF 'gameImpls(uint32)(address)' 0 --rpc-url $L1_RPC   # CANNON
cast call $SHARED_DGF 'gameImpls(uint32)(address)' 1 --rpc-url $L1_RPC   # PERMISSIONED_CANNON
cast call $SHARED_DGF 'gameImpls(uint32)(address)' 8 --rpc-url $L1_RPC   # CANNON_KONA
# Expect each: 0x0000000000000000000000000000000000000000

​

체인별 Factory가 비워졌는지 확인

for OLD_DGF in <oldDGF_chainA> <oldDGF_chainB>; do
    for GT in 0 1 5 8 9; do
        echo "$OLD_DGF gameImpls($GT)= $(cast call $OLD_DGF 'gameImpls(uint32)(address)' $GT --rpc-url $L1_RPC)"
    done
done
# Expect every entry: 0x0000000000000000000000000000000000000000

​

공유 Lockbox 승인 확인

cast call $SHARED_LOCKBOX 'authorizedPortals(address)(bool)' <OptimismPortal2_chainA> --rpc-url $L1_RPC
cast call $SHARED_LOCKBOX 'authorizedPortals(address)(bool)' <OptimismPortal2_chainB> --rpc-url $L1_RPC
# Expect both: true

​

공유 op-challenger 및 op-dispute-mon 시작

1. 공유 op-challenger의 --game-factory-address(OP_CHALLENGER_GAME_FACTORY_ADDRESS)를 $SHARED_DGF로 설정하고 프로세스를 시작합니다. 시작 로그에 super-cannon-kona가 등록된 trace type으로 표시되고, 공유 supernode 루트 RPC 엔드포인트 연결 오류가 없는지 확인합니다.
2. 공유 op-dispute-mon의 --game-factory-address(OP_DISPUTE_MON_GAME_FACTORY_ADDRESS)를 $SHARED_DGF로 설정하고 프로세스를 시작합니다. supernode 루트 연결이 정상이고 metrics 엔드포인트가 제공되고 있는지 확인합니다.

​

단일 공유 op-proposer로 전환

• 로그에 proposer가 supernode를 폴링하고 공유 factory에 기록하는 내용이 표시됩니다.
• --proposal-interval 한 번 이내에 proposer가 공유 factory에 새 게임을 제출합니다. 이를 검사합니다.
  COUNT=$(cast call $SHARED_DGF 'gameCount()(uint256)' --rpc-url $L1_RPC)
  echo "gameCount=$COUNT"
  
  read -r GAME_TYPE CREATED_AT GAME_PROXY < <(cast call $SHARED_DGF 'gameAtIndex(uint256)(uint32,uint64,address)' $((COUNT-1)) --rpc-url $L1_RPC)
  # Expect: GAME_TYPE=9 and GAME_PROXY 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 $SUPERNODE_RPC | jq -r '.data.super_root'
  # Expect: equals rootClaim from above.
  

​

마이그레이션 이전 게임 drain 및 본드 회수

• 두 체인별 op-challenger 인스턴스는 퇴역한 게임을 DEFENDER_WINS 또는 CHALLENGER_WINS까지 계속 진행하고, 게임이 최종 확정되면 본드 청구를 예약합니다.
• 본드 청구는 운영자의 개입 없이 성공합니다. chain A의 퇴역한 게임은 chain A의 DelayedWETH(새로운 공유 게임이 사용하는 것과 같은 컨트랙트)를 통해 청구하고, chain B의 퇴역한 게임은 마이그레이션 후 달리 사용되지 않는 chain B의 DelayedWETH를 통해 청구합니다.
• 두 체인별 op-dispute-mon 인스턴스는 해당 게임을 계속 관찰합니다. game type별 metric인 op_dispute_mon_games{game_type="super-cannon-kona"}와 super-permissioned에 대한 동일한 metric은 drain 기간 동안 단조 감소하여 0에 가까워져야 합니다.
• op-challenger의 기본 --game-window는 28일로, 최대 16일의 게임 진행 기간, 7일의 DelayedWETH 출금 지연, 5일의 버퍼를 포괄하도록 설정되어 있습니다. 체인별 인스턴스에서 이를 줄이지 마십시오. 줄이면 본드를 청구할 수 있게 되기 전에 게임을 놓칠 위험이 있습니다.

cast call <gameProxy> 'status()(uint8)' --rpc-url $L1_RPC
# 0 = IN_PROGRESS, 1 = CHALLENGER_WINS, 2 = DEFENDER_WINS

cast call <gameProxy> 'resolvedAt()(uint64)' --rpc-url $L1_RPC
# Non-zero once the game has resolved.

​

마이그레이션 후 검증

• 공유 op-challenger가 super-root 게임을 방어하고 있는지 확인합니다. challenger는 game type별로 metric을 구분하지 않으므로, 시작 로그(super-cannon-kona와 super-permissioned를 포함한 구성된 모든 trace type이 등록된 것으로 표시되어야 함)와 지속적인 로그(공유 factory에 super game이 나타날 때 scheduler 또는 game-poll 오류가 없어야 함)로 확인하십시오. 집계 metric인 op_challenger_tracked_games{status="in_progress"}는 super game이 생성되면 0이 아닌 값이 되고, 게임이 진행 중인 동안 0이 아닌 값을 유지합니다.
• 공유 op-dispute-mon이 super-root 게임을 보고하는지 확인합니다. 공유 인스턴스에서 게임이 생성되면 op_dispute_mon_games{game_type="super-cannon-kona"}와 op_dispute_mon_games{game_type="super-permissioned"}가 0이 아닌 값이 됩니다. op_dispute_mon_failed_games는 0에 가깝게 유지되어야 합니다. 0이 아닌 값은 일반적으로 --supernode-rpc 누락 또는 supernode 사용 불가를 의미합니다.
• 새로운 마이그레이션 이전 게임을 생성할 수 없는지 확인합니다. 선택적으로, 어느 한 체인별 factory에서 비워진 game type 중 하나로 DisputeGameFactory.create를 호출하여 revert되는지 확인합니다.
• 첫 번째 super game 최종 확정을 지켜봅니다. 첫 번째 앵커 업데이트는 일반적으로 첫 번째 super-root 게임이 생성된 후 약 7일(게임 진행 기간 + disputeGameFinalityDelaySeconds()) 뒤에 이루어집니다. 이 때문에 롤아웃을 막지는 마십시오. 해당 기간 후 getAnchorRoot()를 다시 실행하여 시작 앵커 대신 새 게임의 클레임이 반환되는지 확인하는 후속 작업을 예약하십시오.

​

drain 후 정리

​

마이그레이션 후 운영상 주의 사항

​

공유 Lockbox를 통해 세트 전체를 pause

​

Guardian 작업은 두 체인 모두에 적용

​

migrateToSharedDisputeGame을 직접 호출하지 마십시오

​

두 체인을 함께 업그레이드

• 공유 factory에서 각 멤버의 disputeGameConfigs를 읽어 복사하십시오. 절대 체인별로 작성하지 마십시오.
• factory에 CANNON_KONA 구현이 있는지 확인하는 방식으로 SUPER_CANNON_KONA 활성화 여부를 결정하지 마십시오. 공유 factory에는 CANNON_KONA가 절대 없으므로, startingRespectedGameType = 5인 경우 그 검사는 두 체인 모두에 대해 세트의 permissionless 게임을 비활성화합니다.
• 두 체인을 모두 업그레이드한 후, task에 명시된 체인뿐 아니라 각 체인에 대해 StandardValidator를 실행하고 둘 다 통과하는지 확인하십시오.

​

INTEROP과 ProxyAdmin Owner는 고정된 것으로 취급

​

다음 단계

• 전체 interop 활성화 마일스톤을 계획하십시오. migrate는 체인들을 공유 분쟁 게임 아래로 통합하지만, 크로스체인 메시징을 활성화하는 것은 별도의 단계입니다. 준비가 되면 Interop 설명을 참조하십시오.
• 새 proposer의 첫 제안 후 약 7일 뒤, 첫 번째 super game 최종 확정 시 앵커가 전진하는지 확인하는 후속 작업을 예약하십시오. cast call $SHARED_ASR 'getAnchorRoot()(bytes32,uint256)' --rpc-url $L1_RPC를 다시 실행하여 새 게임의 클레임이 반환되는지 확인하십시오.