Optimism op-challenger 深度指南：争议游戏挑战者代理的运行机制、配置与子命令实战

Optimism op-challenger 深度指南争议游戏挑战者代理的运行机制、配置与子命令实战【免费下载链接】optimismOptimism is Ethereum, scaled.项目地址: https://gitcode.com/GitHub_Trending/op/optimismop-challenger是 Optimism(op-stack) 生态中负责“维护 L2 输出正确性”的核心节点组件它持续监听 L1 上的争议游戏(dispute games)对任何无效声明用本地计算出的正确轨迹(trace)发起反声明(counter-claim)并管理保证金(bond)的申领。本文以 op-challenger 官方 README 为主体结合 challenger.go、config/config.go、flags/flags.go、game/service.go 等源码完整讲解其构建方式、全量配置参数、本地 devnet 实战流程以及create-game、move、resolve、run-trace等子命令的用法与底层实现。读完本文你将能够独立构建并部署一个 challenger 节点并掌握对链上争议游戏进行手动测试与调试的完整命令集。1. op-challenger 是什么op-challenger是一个模块化的 op-stack 挑战者代理(challenge agent)用 Go 编写支持 attestation games、fault games、validity games 等多种争议游戏协议层面的背景可参考仓库内的 fault-proofs 文档。其核心职责有三监控订阅 L1 新块发现DisputeGameFactory下创建的新游戏博弈对无效声明执行本地轨迹计算通过 Cannon / Kona 等虚拟机执行器提交攻击或防御动作结算与申保在游戏结束时解析结果(resolve claim)并在 WETH 撤回延迟期过后申领保证金。1.1 游戏类型(game type)总览所有游戏类型集中定义在 game/types/game_type.go这是理解全部配置项的钥匙类型名编号op-challenger 是否支持说明cannon0支持(可玩)基于 Cannon(MIPS 虚拟机)的故障证明游戏permissioned1支持(仅生命周期)仅受信参与者在输出根层面解决永远到不了step()super-permissioned5支持(仅生命周期)Super 链上的许可制游戏cannon-kona8支持(可玩)使用 Rust 版 Kona 作为 preimage oracle 服务器的 Cannon 变体super-cannon-kona9支持(可玩)Interop 下的 Kona Super 游戏zk10支持(可玩)ZK 争议游戏fast254支持(可玩)快速游戏(测试用)alphabet255支持(可玩)字母表游戏(测试用)asterisc/asterisc-kona/op-succinct/super-asterisc-kona/kailua2/3/6/7/1337不支持由其他 challenger 实现源码中PlayableGameTypes是允许被--game-types选择的集合SupportedLifecycleGameTypes在此之上额外包含super-permissioned——即这类游戏 challenger 只处理“生命周期”(关闭、申保)不参与实际博弈。GameType.IsPermissioned()方法明确说明许可制游戏“resolve at the proposal level without ever reaching step(), so they never run the fault proof VM or load its absolute prestate”这一点对配置校验有直接影响(见第 3.3 节)。2. 快速开始(Quickstart)构建与基本入口对应 README “Quickstart”# 构建 just op-challenger # 查看全部命令与选项 ./bin/op-challenger --help程序入口在 cmd/main.gomain()先建立信号感知的 context然后调用 challenger.Main后者先执行cfg.Check()配置校验再构建game.NewService返回生命周期对象。CLI 默认 Action 走cliapp.LifecycleCmd即“长驻服务模式”——直接运行./bin/op-challenger flags就是启动 challenger 服务带子命令时才进入手动测试模式。3. 配置体系CLI 参数与环境变量op-challenger完全通过命令行 flag 和环境变量配置环境变量统一使用OP_CHALLENGER前缀见 flags/flags.go 中的EnvVarPrefix OP_CHALLENGER例如OP_CHALLENGER_L1_ETH_RPC。所有 flag 可通过--help查看。3.1 必选参数从flags.go的requiredFlags与CheckRequired可确认长驻模式下的硬性必选项为参数环境变量说明--l1-eth-rpcOP_CHALLENGER_L1_ETH_RPCL1 RPC 端点(如http://localhost:8545)--l1-beaconOP_CHALLENGER_L1_BEACONL1 Beacon API 端点(如http://localhost:5100)--datadirOP_CHALLENGER_DATADIR游戏运行数据(快照、状态)存储目录--l2-eth-rpcOP_CHALLENGER_L2_ETH_RPCL2 JSON-RPC 端点(可多个)需要 eth 与 debug 命名空间--game-factory-address或--network—争议游戏工厂合约地址已知网络可改用--network见下文关于--networkFactoryAddress()的实现flags/flags.go L498-L532表明若显式给了--game-factory-address则优先使用否则从--network指定的已知网络(来自 op-node/chaincfg 的AvailableNetworks()底层数据在 op-core/superchain)解析出DisputeGameFactoryProxy地址。多个网络必须指向同一个工厂否则报错要求显式指定。3.2 核心运行参数来自 config/config.go 与 flags/flags.go重点参数及其默认值参数默认值说明--game-typescannon-kona支持的游戏类型列表(兼容别名--trace-type)--max-concurrencyCPU 核数推进游戏时的最大并发线程数不能为 0--game-window28 天向后回看多久的游戏。源码注释解释游戏最坏 16 天(时钟延期) WETH 7 天撤回延迟28 天留了 5 天缓冲以确保保证金可申领--max-pending-tx10在途交易上限0 表示不限--http-poll-interval12sHTTP RPC 模式下最新块订阅的轮询间隔--min-update-interval0L1 头块时间至少前进多久才调度新一轮更新用于限速--rollup-rpc—op-node Rollup RPC 端点cannon 系游戏与fast/alphabet类型必需--superroot-rpc—Super 根 RPC 源(Interop 用 op-supernode单链用 op-node)super-cannon-kona与zk类型必需必须覆盖完整依赖集否则会出现“过度挑战”--game-allowlist空只允许参与指定游戏合约地址为空则参与所有游戏--additional-bond-claimants空除交易发送者外额外为其申领保证金的地址列表--selective-claim-resolutionfalse只为配置的 claimants 解析声明并申领非零信用同时关闭“仅生命周期”的关局/锚点更新交易--response-delay0响应每次游戏动作前的延迟用于拖慢博弈节奏。源码注释强调只在“不会导致游戏超时、不处于时钟延期期、延期后仍能赶在延期期内响应”时才真正生效--response-delay-after0第 N 次响应之后才开始施加延迟(0 从第一次起)3.3 按游戏类型分组的虚拟机参数(--cannon-*/--cannon-kona-*)虚拟机相关 flag 通过 flags/vm_flag.go 的NewVMFlag机制按游戏类型展开(例如--cannon-rollup-config、--cannon-kona-rollup-config、--cannon-prestates-url、--cannon-kona-prestates-url)参数(cannon 前缀)说明--cannon-rollup-configrollup 链参数(可多个)--cannon-l2-genesisop-geth L2 创世文件路径(可多个)--cannon-l1-genesisL1 创世文件仅当 L1 不是 mainnet/sepolia/holesky/hoodi 时需要--cannon-depset-configInterop 依赖集配置文件--cannon-prestates-url/--cannon-prestate绝对 prestate 下载基址 / 本地文件二选一目录中 prestate 命名为commitment.bin.gz、commitment.json.gz或commitment.json--cannon-bin生成 trace 数据用的 cannon 可执行文件(cannon 游戏类型)--cannon-server/--cannon-kona-serverpreimage oracle 服务器可执行文件前者为 op-program 服务器后者为 kona-host--cannon-snapshot-freq/--cannon-info-freq每 N 个 VM step 生成一次快照 / 一条 info 日志默认分别为1_000_000_000与10_000_000(见 config/config.go 常量定义)--cannon-l2-custom隐藏的危险测试开关告知 host 该 L2 使用自定义配置经 preimage oracle 加载与链上测试不兼容权限豁免逻辑CheckCannonBaseFlags(flags/flags.go L337-L362) 会先计算canReachStep——只有启用的 cannon 系游戏里存在“非 permissioned”类型时才强制要求--cannon-server和 prestate(文件或 URL)。这与 README 的说明完全一致若只配置permissioned游戏类型--cannon-kona-server、--cannon-kona-prestate/--prestates-url均可省略因为 challenger 永远不会为它加载 prestate、执行故障证明程序甚至链上 prestate 是占位值也能正常 resolve。配置在 config.Config.Check() 中做最终校验缺L1EthRpc、L1Beacon、L2Rpcs、工厂地址、Datadir、游戏类型为空等均返回明确错误super-cannon-kona类型额外要求SuperRootRPC且 cannon-kona 必须提供网络或 depset 配置。3.4 交易管理与运维设施Config还内嵌三组子配置config/config.go L92-L94TxMgrConfig、MetricsConfig、PprofConfig。因此--help中会看到 txmgr 系列(私钥、发送重试、超时等)、--metrics-enable、--metrics.addr、--pprof-enable等通用参数——签名用的SIGNER_ARGS即 txmgr 的--private-key等参数。4. 本地 devnet 实战Cannon Kona 全流程这是 README 的核心实操部分完整保留并补充解释。4.1 前置启动 devnet先启动一个暴露simple-devnetenclave 的本地 devnet(基于 kurtosis)再构建 challengerjust op-challenger4.2 启动命令DISPUTE_GAME_FACTORY$(jq -r .DisputeGameFactoryProxy .devnet/addresses.json) ./op-challenger/bin/op-challenger \ --game-types cannon-kona \ --l1-eth-rpc http://localhost:8545 \ --rollup-rpc http://localhost:9546 \ --game-factory-address $DISPUTE_GAME_FACTORY \ --datadir temp/challenger-data \ --cannon-kona-rollup-config .devnet/rollup.json \ --cannon-kona-l2-genesis .devnet/genesis-l2.json \ --cannon-bin ./cannon/bin/cannon \ --cannon-kona-server ./rust/target/release/kona-host \ --cannon-kona-prestate ./rust/kona/prestate-artifacts-cannon/prestate.bin.gz \ --l2-eth-rpc http://localhost:9545 \ --mnemonic test test test test test test test test test test test junk \ --hd-path m/44/60/0/0/8 \ --num-confirmations 1逐项解释DISPUTE_GAME_FACTORY从 devnet 部署地址文件中取DisputeGameFactoryProxy等价于手动指定工厂地址(与第 3.1 节的--network路径呼应)--game-types cannon-kona声明只参与 Kona 版 Cannon 游戏--l1-eth-rpc/--l2-eth-rpc/--rollup-rpcL1 执行客户端、L2 执行客户端、op-node 三个 RPC 入口(端口 8545/9545/9546 为 devnet 约定)--cannon-kona-rollup-config与--cannon-kona-l2-genesis因为 devnet 不是预定义网络所以不能用--network必须显式提供 rollup 配置与 L2 创世--cannon-binMIPS 虚拟机执行器(即使游戏类型是cannon-konacannon 二进制仍是必需项——CheckCannonKonaBaseFlags强制要求--cannon-bin)--cannon-kona-serverkona-host 二进制作为 preimage oracle 服务器生成故障证明--cannon-kona-prestate绝对 prestate 文件cannon-kona可玩游戏必需(可用--cannon-kona-prestates-url代替)--mnemonic--hd-path m/44/60/0/0/8--num-confirmations 1devnet 预充值账户的签名配置本地出块快1 个确认数即可。启动后challenger 会持续监控争议游戏对任何无效声明以本地计算的 trace 作为反声明提交。README 同时说明--cannon-kona-server仅在可玩(cannon-kona)游戏需要若只配permissioned游戏类型服务器二进制、prestate 相关参数(--cannon-prestate/--prestates-url/--cannon-kona-*)均可省略。4.3 devnet 管理命令(kurtosis)# 查看状态 kurtosis enclave ls kurtosis enclave inspect simple-devnet # 查看特定服务日志(名称按实际调整) kurtosis service logs simple-devnet op-challenger-challenger-2151908 kurtosis service logs simple-devnet op-node-2151908-node0 # 结束后停止并清理 kurtosis enclave stop simple-devnet kurtosis enclave rm simple-devnet5. 运行时的内部架构(源码视角)理解下面这些组件能解释“为什么 README 让你这样配参数”。5.1 服务装配game.Servicegame/service.go 的NewService→initFromConfig按序装配initTxManager创建SimpleTxManager与TxSender后者带MaxPendingTx限流initL1Clients拨号 L1构建带PollInterval的轮询客户端与L1ClientinitPProf/initMetricsServer性能剖析与 Prometheus 指标(指标开启时还会启动余额监控)initFactoryContract绑定DisputeGameFactory合约作为游戏来源registerGameTypes调用 fault/register.go 与 zk/register.go 把各游戏类型注册进GameTypeRegistry/OracleRegistryinitBondClaimsBondClaimerBondClaimScheduler负责解析后申领保证金initScheduler按MaxConcurrency创建并发调度器与磁盘管理器(快照存于Datadir)initLargePreimagesKeccak 大 preimage 挑战器(验证 preimage oracle 中被拆分的大数据块)initMonitor组装gameMonitor。Start()依次启动 scheduler、claimer、preimages 调度器与 L1 头监控。5.2 监控循环gameMonitorgame/monitor.go 展示了核心工作流通过newHeads订阅 L1 头(10 秒自动重订阅)每次新头回调onNewL1HeadonNewL1Head先把内部 L1 时钟对齐到块时间再检查MinUpdateInterval限速progressGames以GameWindow计算最早时间戳向工厂合约查询“该时间戳之后创建的所有游戏”然后按规则分流不支持生命周期的类型 → 跳过并告警不在GameAllowlist内的 → 跳过所有通过者进入gamesToClaimOrClose(交给 claimer 做申保/关局)属于PlayableGameTypes且已配置的才进入gamesToPlay交给 scheduler 实际博弈每个 L1 头还会触发preimages.Schedule持续验证大 preimage 承诺。这就是为什么--game-window默认 28 天、且源码注释把它和“16 天游戏时长 7 天 WETH 延迟 5 天缓冲”绑定——窗口太小会漏掉待申领的保证金。5.3 轨迹与 VM 执行游戏内的 trace 计算位于 game/fault/tracecannon、cannon-kona、super-cannon-kona分别由 outputs/provider.go 等按游戏类型路由game/fault/trace/vm 目录下的executor.go、op_program_server_executor.go、kona_server_executor.go对应--cannon-server/--cannon-kona-server启动的外部进程prestate 由prestates.go按承诺哈希解析。--cannon-snapshot-freq/--cannon-info-freq则直接作用于 VM 执行时的快照与日志频率。6. 子命令全集(手动测试工具)README 明确提示子命令“should not be used in production and are intended to provide convenient manual testing”。cmd/main.go 实际注册了 9 个子命令list-games、list-claims、list-credits、game-proposal-outputs、create-game、move、resolve、resolve-claim、run-trace(后两个在 README 之外属于源码中额外提供的工具)。6.1 create-game创建争议游戏./bin/op-challenger create-game \ --l1-eth-rpc L1_ETH_RPC \ --game-factory-address GAME_FACTORY_ADDRESS \ --output-root OUTPUT_ROOT \ --l2-block-num L2_BLOCK_NUM \ SIGNER_ARGS在 L2 输出预言机(L2 output oracle)的最新输出提案上发起一场新的故障争议游戏。L1_ETH_RPCL1 RPC 端点(如http://localhost:8545)GAME_FACTORY_ADDRESSL1 上的争议游戏工厂合约地址OUTPUT_ROOT作为拟议输出根的 32 字节十六进制哈希L2_BLOCK_NUM拟议输出根对应的 L2 块号SIGNER_ARGS交易签名参数(如--private-key)。可选项可用--game-types覆盖游戏类型。对已知网络--game-factory-address可替换为--network(预定义网络列表见--help)。源码补充(cmd/create_game.go)实际实现还支持--game-type(数字值)、--l2-chain-id(super 游戏用于 super root 证明)并在创建成功后打印Fetched Game Address: addr。6.2 move攻击或防御move必须指定--attack或--defend之一二者互斥./bin/op-challenger move \ --l1-eth-rpc L1_ETH_RPC \ --game-address GAME_ADDRESS \ --attack \ --parent-index PARENT_INDEX \ --claim CLAIM \ SIGNER_ARGS在指定游戏中对最新声明发起攻击或防御动作GAME_ADDRESS目标争议游戏地址attack/defend动作类型。attack表示你本地 trace 中的状态哈希与最新声明包含的哈希不同defend表示相同PARENT_INDEX被本次反声明针对的父声明索引CLAIM写入新声明的状态哈希SIGNER_ARGS签名参数。README 提到latest特殊值可用于指代最新声明而当前仓库的 cmd/move.go 将--parent-index按uint64解析(L66)从源码结构看实际操作时应传显式数字索引(索引可先用list-claims查询)。实现细节上createMoveTx会先调用contracts.DetectGameType探测游戏类型再分派ZK 游戏只支持attack(内部生成ChallengeTx)故障游戏则取父声明后生成AttackTx或DefendTx并经 txmgr 发送。6.3 resolve-claim解析单个声明./bin/op-challenger resolve-claim \ --l1-eth-rpc L1_ETH_RPC \ --game-address GAME_ADDRESS \ --claim CLAIM_INDEX \ SIGNER_ARGS解析游戏中的某个声明。若声明已解析或尚不可解析则会失败成功时打印解析结果。参数GAME_ADDRESS为游戏地址CLAIM_INDEX为声明索引。6.4 resolve解析整场游戏./bin/op-challenger resolve \ --l1-eth-rpc L1_ETH_RPC \ --game-address GAME_ADDRESS \ SIGNER_ARGS解析整场争议游戏。若游戏已解析、或时钟未到期且仍可能有后续动作则失败成功时打印结果。6.5 list-games列出游戏./bin/op-challenger list-games \ --l1-eth-rpc L1_ETH_RPC \ --game-factory-address GAME_FACTORY_ADDRESS打印游戏工厂创建的所有游戏及其当前状态。已知网络可改用--network。6.6 list-claims列出声明./bin/op-challenger list-claims \ --l1-eth-rpc L1_ETH_RPC \ --game-address GAME_ADDRESS打印指定游戏中当前的声明列表——它是手动执行move/resolve-claim前获取PARENT_INDEX/CLAIM_INDEX的配套工具。6.7 run-trace轨迹回归测试工具./bin/op-challenger run-trace \ --networkNETWORK_NAME \ --l1-eth-rpcL1_ETH_RPC \ --l1-beaconL1_BEACON \ --l2-eth-rpcL2_ETH_RPC \ --rollup-rpcROLLUP_RPC \ --datadirDATA_DIR \ --prestates-urlPRESTATES_URL \ --runRUN_CONFIGNETWORK_NAME预定义 L2 网络名L1_ETH_RPCL1 RPC 端点L1_BEACONL1 Beacon REST 端点L2_ETH_RPCL2 执行客户端 RPCROLLUP_RPCL2 共识客户端(op-node) RPCDATA_DIR数据目录PRESTATES_URL所需 prestate 的下载基址RUN_CONFIG要运行的 trace provider 与 prestate例如cannon,cannon-kona/kona-0.1.0-alpha.5/0x03c50fbef46a05f93ea7665fa89015c2108e10c1b4501799c0663774bd35a9c5。这是一个测试工具持续对真实链数据运行指定的 trace provider可为其配置多种 prestate从而同时验证“当前与未来候选”的绝对 prestate 与故障证明 VM 的兼容性。参数解析细节(见 cmd/run_trace.go)--run可重复传入每项格式gameType/name/prestateHashgameType决定 prestate 用哪个 VM(如cannon或cannon-kona)name是指标上报用的任意名称省略时取游戏类型名prestateHash省略时采用链上新游戏使用的绝对 prestate。也可传入0x前缀的哈希或本地文件名(runner/game_inputs.go 参与输入构造)完全省略--run时默认对每个已启用游戏类型跑链上版本除自身 CLI 选项外还支持op-challenger主程序的全部配置选项额外提供--vm-timeout(每次 VM 执行的最长时长默认 3 小时0 为禁用)与--age-game-inputs(把游戏 L1 头保持在链头之前约 16 天、并从再早约 7 天的 L1 块推导被争议的 L2 块用于模拟“老游戏”场景)。例如同时运行生产 cannon prestate 与一个自定义 prestate--run cannon,cannon/next-prestate/0x03c1f0d45248190f80430a4c31e24f8108f05f80ff8b16ecb82d20df6b1b43f37. 生产部署要点小结最小可玩配置--l1-eth-rpc--l1-beacon--l2-eth-rpc--datadir 工厂地址(或--network) 与所选--game-types匹配的 VM 参数(rollup-config/l2-genesis/server/prestate)。对cannon-kona还要--rollup-rpc对super-cannon-kona/zk还要--superroot-rpc只用许可制游戏server 与 prestate 类参数可全省(见第 3.3 节的canReachStep逻辑)成本控制--max-pending-tx(默认 10)限制在途交易--min-update-interval限制 L1 头触发频率--response-delay/--response-delay-after控制响应节奏以限制资源消耗(注意其注释中的三个生效前提)安全开关--unsafe-allow-invalid-prestate是隐藏的测试专用开关生产环境绝不应开启--cannon-l2-custom/--cannon-kona-l2-custom同样仅测试用途可观测性--metrics-enable开启后除常规指标外还会监控发送账户余额(game/service.go 的StartBalanceMetrics)便于及时发现 gas 不足--pprof-enable可用于性能剖析验证工具上线新 prestate 或升级 VM 前用run-trace对真实链数据做回归是 README 给出的官方工作流。8. 延伸阅读(仓库内路径)模块总览与上述全部实操op-challenger/README.md配置结构与校验op-challenger/config/config.go、op-challenger/flags/flags.go服务装配与生命周期op-challenger/game/service.go监控循环op-challenger/game/monitor.go游戏类型定义op-challenger/game/types/game_type.go子命令实现op-challenger/cmd/main.go、op-challenger/cmd/create_game.go、op-challenger/cmd/move.go、op-challenger/cmd/run_trace.go故障证明协议背景docs/ai/fault-proofs.md构建入口根目录 justfile【免费下载链接】optimismOptimism is Ethereum, scaled.项目地址: https://gitcode.com/GitHub_Trending/op/optimism创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考