Chainlink Mercury 低延迟数据源部署指南Feed 配置、OCR 任务与节点参数全解析【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink导读本文基于仓库中的 Mercury 文档系统讲解 Chainlink 节点上 Mercury基于 LLO 低延迟预言机协议构建的数据源从零部署所需的全部配置包括 Verifier 合约上的 Feed 配置 JSON 结构、节点上的 Bootstrap 与 OCR2 两类 Job 定义以及支撑高吞吐场景的节点级 TOML 参数调优。读完本文你将能够独立填写一份可运行的 Mercury Feed 配置、写出正确的 Bootstrap/OCR2 任务规范并理解节点侧数据库连接数、P2P、遥测入口等关键参数为何必须按文档要求调整。文中所有关键字段均结合仓库源码core/services/llo/、core/services/job/models.go、core/config/docs/core.toml等给出实现层面的依据与默认值。Mercury 与 LLO先理解这套体系在 Chainlink 中的位置Mercury 是 Chainlink 面向高频数据消费场景例如 DeFi 衍生品定价推出的低延迟数据源解决方案。在 当前仓库 中Mercury 的实现依托于core/services/llo目录下的 LLOLow Latency Oracle协议LLO delegate 实现 是 LLO 任务的执行入口它基于 libocr 的offchainreporting2plus构建 oracle 实例并同时支持OCR3.0v30与 OCR3.1v31两套协议版本——这也解释了为什么文档示例中offchainConfigVersion取值为30。delegate 会为每个 LLO 任务创建1 或 2 个 ContractConfigTracker对应代码中的 Blue/Green 双实例命名后者服务于 LLO 的平滑退役/切换机制ShouldRetireCache、RetirementReportCache是 Mercury 实现无感升级的基础设施。报告编解码器 集中注册了所有支持的链上报告格式JSON、EVMPremiumLegacy、EVMABIEncodeUnpacked、EVMABIEncodeUnpackedExpr、EVMStreamlined 与 HistoryBackfill。Feed 的offchainConfig正是决定使用哪一套编码与协议行为的核心输入。LLO 遥测服务 负责在观察Observation、报告Report与 EA 调用等环节采集遥测数据并通过 TelemetryIngress 上报。在 LLO 集成测试 中可以直观看到 Mercury 数据源涉及的全部链上组件Configurator、DestinationVerifier与DestinationVerifierProxy、ChannelConfigStore、Verifier与VerifierProxy、FeeManager、RewardManager以及LinkToken。其中Verifier 合约就是文档 Feed 配置中的contractAddress即数据报告的链上校验者。Feed 配置Verifier 合约上的数据源定义Mercury 的每个数据源Feed都对应 Verifier 合约上的一份配置。文档给出了完整的 JSON 示例这是所有后续 Job 配置的前提——节点的 Bootstrap/OCR2 任务都会引用这里定义的feedId。{ feedId: 0x14e044f932bb959cc2aa8dc1ba110c09224e639aae00264c1ffc2a0830904a3c, chainId: 42161, // source chain id contractAddress: 0x14e044f932bb959cc2aa8dc1ba110c09224e639a, // verifier contract address configCount: 1, // the index of this config signers: [ 0x000....01, 0x000....02, 0x000....03, 0x000....04 ], // NOP signing addresses transmitters: [ 0x000....11, 0x000....12, 0x000....13, 0x000....14 ], // NOP transmitter addresses offchainConfig: { baseUSDFee: 0.1, // 10c base fee to verify the report deltaCertifiedCommitRequest: 1s, deltaGrace: 0s, deltaInitial: 600ms, deltaProgress: 2s, deltaResend: 10s, deltaRound: 250ms, deltaStage: 0s, expirationWindow: 86400, // window in which a report can be verified in seconds f: 3, maxDurationObservation: 250ms, maxDurationQuery: 50ms, maxDurationShouldAcceptAttestedReport: 50ms, maxDurationShouldTransmitAcceptedReport: 50ms, rMax: 25, s: [ 4 ] }, offchainConfigVersion: 30, onchainConfig: { max: 99999999999999999999999999999, min: 1 } }顶层字段说明字段含义说明feedId数据源唯一标识32 字节哈希后续 Job 中必须用feedID与之对应否则任务无法工作chainId源链 ID即产生区块数据的链文档注释 source chain id示例为 Arbitrum One 的 42161contractAddressVerifier 合约地址链上报告校验者地址configCount配置索引同一 Feed 配置的版本序号用于区分新旧配置signers签名者地址列表参与报告签名的 NOP 地址须与节点 OCR2 密钥中的 OnchainSigning 地址一一对应transmitters传输者地址列表负责把已签名报告提交到链上的 NOP 地址offchainConfigVersion离链配置版本示例为30对应 LLO delegate 中 v30OCR3.0实现升级到 OCR3.1 时使用 v31onchainConfig链上配置报告值的合法性上下界见下文onchainConfig报告值的价格边界onchainConfig中只有max与min两个字段它们界定了报告值价格等的合法区间超出该区间的报告会被拒绝校验。示例给出了一个极大值上界99999999999999999999999999999与下界1实际部署时应按业务合理收窄以抵御异常或恶意观测值。offchainConfigOCR 轮次时序与容错参数offchainConfig由 libocr 的 OCR3 配置ocr3config驱动控制着每个轮次round的调度节奏与容错阈值直接决定 Mercury 的延迟表现deltaRound250ms目标轮次间隔是低延迟的核心参数。示例中每 250ms 就期望产出一轮报告这要求节点间的 P2P 网络与数据库都要能承受相应吞吐。deltaInitial600ms启动或配置变更后第一轮报告的启动延迟。deltaProgress2s协议级进度超时超过该时间未见进展则触发重传/重新调度。deltaResend10s对长时间未确认的消息进行重发的间隔。deltaGrace0s容忍时钟漂移的宽限时间。deltaStage0s阶段间如轮次缓存的附加延迟0 表示不引入额外等待。deltaCertifiedCommitRequest1s发起 certified commit已认证提交请求的间隔。expirationWindow86400报告可在链上被验证的有效窗口秒。示例为 86400 秒24 小时需与链上校验逻辑、最终性确认时间匹配。f3容错节点数最多可容忍 f 个节点作恶或故障。示例 4 个 signers/transmitters 配合f3意味着需2f1个签名。rMax25报告传输的最大轮次限制用于约束传输延迟与频率。s[4]各阶段传输规则配置schedule 数组示例为单阶段。maxDurationObservation250ms单次观察拉取数据源的最大耗时预算。maxDurationQuery50msQuery 阶段v31 协议的最大耗时预算。maxDurationShouldAcceptAttestedReport50ms判定是否接受已认证报告的最大耗时。maxDurationShouldTransmitAcceptedReport50ms判定是否传输已接受报告的最大耗时。baseUSDFee0.1验证一份报告的基础费用美元示例为 10 美分。这是 Mercury 商业化收费模型的链下部分与链上FeeManager配合使用见 LLO 集成测试 中的 FeeManager 部署。提示上述时长类参数均需与maxDurationObservation等预算相协调——轮次越密集deltaRound越小留给观察与查询的预算就越紧数据源bridge/EA的延迟必须足够低才能避免每轮超时。Jobs让节点真正跑起来Feed 配置发布到 Verifier 合约后需要在每个 Chainlink 节点上创建两类任务一个Bootstrap任务负责 P2P 引导和至少一个OCR2 Mercury任务负责实际参与报告轮次。Bootstrap 任务Bootstrap 节点是 LLO/OCR3 网络的引导入口负责向新加入的 oracle 节点通告网络拓扑。type bootstrap relay evm schemaVersion 1 name $feed_name contractID $verifier_contract_address feedID $feed_id # IMPORTANT - DONT FORGET THIS OR IT WONT WORK contractConfigTrackerPollInterval 15s [relayConfig] chainID $evm_chain_id fromBlock $from_block文档特别强调两个关键字段relayConfig.chainID目标链 ID即我们从哪个链拉取区块号文档原文 the chain we pull block numbers from。它决定 LogPoller 从哪条链扫描 Verifier 合约的配置变更事件必须与 Feed 配置中的chainId一致。contractIDVerifier 合约地址。feedIDFeed 的唯一标识。文档用红色警告级别标注DONT FORGET THIS OR IT WONT WORK忘了它任务就不会工作。这一字段在 OCR2 任务规范定义 中对应FeedID *common.Hash32 字节哈希类型不匹配时任务校验会失败。contractConfigTrackerPollInterval 15s控制节点轮询链上配置的间隔在 任务运行器集成测试 中同样使用了15s作为标准取值。relayConfig.fromBlock指定 LogPoller 从哪个区块开始回溯扫描。OCR2 Mercury 任务OCR2 任务是节点真正参与观测、签名与传输报告的载体。pluginType mercury表明这是 Mercury 数据源类型的 OCR2 任务其字段同样定义在 OCR2OracleSpec。type offchainreporting2 schemaVersion 1 name $feed_name forwardingAllowed false maxTaskDuration 1s contractID $verifier_contract_address feedID $feed_id contractConfigTrackerPollInterval 15s ocrKeyBundleID $key_bundle_id p2pv2Bootstrappers [ $bootstrapper_address ] relay evm pluginType mercury transmitterID $csa_public_key observationSource // ncfx ds1_payload [typebridge namencfx timeout50ms requestData{\data\:{\endpoint\:\crypto-lwba\,\from\:\ETH\,\to\:\USD\}}]; ds1_median [typejsonparse pathdata,mid]; ds1_bid [typejsonparse pathdata,bid]; ds1_ask [typejsonparse pathdata,ask]; ds1_median_multiply [typemultiply times100000000]; ds1_bid_multiply [typemultiply times100000000]; ds1_ask_multiply [typemultiply times100000000]; // tiingo ds2_payload [typebridge nametiingo timeout50ms requestData{\data\:{\endpoint\:\crypto-lwba\,\from\:\ETH\,\to\:\USD\}}]; ds2_median [typejsonparse pathdata,mid]; ds2_bid [typejsonparse pathdata,bid]; ds2_ask [typejsonparse pathdata,ask]; ds2_median_multiply [typemultiply times100000000]; ds2_bid_multiply [typemultiply times100000000]; ds2_ask_multiply [typemultiply times100000000]; // coinmetrics ds3_payload [typebridge namecoinmetrics timeout50ms requestData{\data\:{\endpoint\:\crypto-lwba\,\from\:\ETH\,\to\:\USD\}}]; ds3_median [typejsonparse pathdata,mid]; ds3_bid [typejsonparse pathdata,bid]; ds3_ask [typejsonparse pathdata,ask]; ds3_median_multiply [typemultiply times100000000]; ds3_bid_multiply [typemultiply times100000000]; ds3_ask_multiply [typemultiply times100000000]; ds1_payload - ds1_median - ds1_median_multiply - benchmark_price; ds2_payload - ds2_median - ds2_median_multiply - benchmark_price; ds3_payload - ds3_median - ds3_median_multiply - benchmark_price; benchmark_price [typemedian allowedFaults2 index0]; ds1_payload - ds1_bid - ds1_bid_multiply - bid_price; ds2_payload - ds2_bid - ds2_bid_multiply - bid_price; ds3_payload - ds3_bid - ds3_bid_multiply - bid_price; bid_price [typemedian allowedFaults2 index1]; ds1_payload - ds1_ask - ds1_ask_multiply - ask_price; ds2_payload - ds2_ask - ds2_ask_multiply - ask_price; ds3_payload - ds3_ask - ds3_ask_multiply - ask_price; ask_price [typemedian allowedFaults2 index2]; [pluginConfig] serverURL $mercury_server_url serverPubKey $mercury_server_public_key [relayConfig] chainID $evm_chain_id fromBlock $from_block字段解读type offchainreporting2pluginType mercury声明这是一个 OCR2 Mercury 插件任务。pluginType在 models.go 中对应PluginType枚举mercury是 LLO 在 OCR2 任务层的外显类型LLO delegate 在任务注册时通过该字段被选中见 job/orm.go 中case types.LLO的分派逻辑。contractIDVerifier 合约地址与 Bootstrap 任务、Feed 配置保持一致。feedID与 Feed 配置中的feedId相同的 32 字节哈希——这里是唯一能把任务与特定数据源绑定起来的字段。ocrKeyBundleIDOCR2 密钥包 ID对应节点的 Offchain 签名密钥与 Feed 配置中signers对应。p2pv2BootstrappersBootstrap 节点的 P2P v2 地址列表格式为host:port/peerID。transmitterID传输者身份通常为节点的CSA 公钥$csa_public_key与 Feed 配置中transmitters对应。maxTaskDuration 1s单次 pipeline 任务执行的最大时长须与 Feed 配置中maxDurationObservation的预算匹配。observationSource观测阶段执行的数据管道。示例聚合了ncfx、tiingo、coinmetrics三个外部数据源通过bridge任务调用 EA分别解析mid/bid/ask价格经multiply×10⁸ 将小数价格转为链上整数精度后再由median取中位数allowedFaults2允许两个数据源故障。最终的三个输出benchmark_priceindex0、bid_priceindex1、ask_priceindex2即是报告中的三条数据流。[pluginConfig]serverURL与serverPubKey指向 Mercury 服务端数据消费方的聚合/分发端点用于对接 Mercury 服务层。节点级配置高吞吐下的关键参数Mercury 的轮次频率如每 250ms 一轮会产生远超常规预言机任务的网络与数据库负载因此文档要求对节点配置文件做专门调整并明确标注了必须开启的开关OCR2.Enabled必须为true——Mercury 走的是 OCR2 任务框架。P2P.V2.Enabled必须为true——OCR2 依赖 P2P v2 网络。Feature.LogPoller必须为true——不设置会直接报致命错误fatal errors。LogPoller 负责扫描链上配置变更Verifier 合约的 feed 配置、配置更新等是 LLO delegate 中ContractConfigTracker的数据来源。JobPipeline.MaxSuccessfulRuns建议设为0——关闭成功运行的持久化大幅降低数据库写入压力代价是在 UI 中看不到历史成功运行记录。TelemetryIngress.SendInterval——Mercury 遥测数据量大文档给出经测试的250mssingle feed with 5 nodes 场景实测可行多 Feed 时需监控并按需调整。Database——必须把连接数上限提高到远超默认值。以下是文档给出的完整节点 TOML 示例RootDir $ROOT_DIR [JobPipeline] MaxSuccessfulRuns 0 # you may set to some small value like 10 or similar if you like looking at job runs in the UI [Feature] UICSAKeys true # required LogPoller true # required [Log] Level info # this should be debug for chainlink internal deployments, nops may use info to reduce log volume [Log.File] standard values [WebServer] standard values [WebServer.TLS] standard values [[EVM]] ChainID 42161 # change as needed based on target chain [OCR] Enabled false # turn off OCR 1 [P2P] TraceLogging false # this should be true for chainlink internal deployments, we may ask nops to set this to true for debugging PeerID $PEERID [P2P.V2] Enabled true # required DefaultBootstrappers mercury bootstrap nodes # Note that this should ideally be set in the job spec, this is just a fallback # Make sure these IPs are properly configured in the firewall. May not be necessary for internal nodes AnnounceAddresses [$EXTERNAL_IP:$EXTERNAL_PORT] # Use whichever port you like, pls randomize, MAKE SURE ITS CONFIGURED IN THE FIREWALL ListenAddresses [0.0.0.0:$INTERNAL_PORT] # Use whichever port you like, pls randomize, MAKE SURE ITS CONFIGURED IN THE FIREWALL [OCR2] Enabled true # required KeyBundleID $KEY_BUNDLE_ID # Note that this should ideally be set in the job spec, this is just a fallback CaptureEATelemetry true [TelemetryIngress] UniConn false SendInterval 250ms BufferSize 300 MaxBatchSize 100 [[TelemetryIngress.Endpoints]] Network EVM ChainID 42161 # change as needed based on target chain URL $TELEMETRY_ENDPOINT_URL # Provided by Chainlink Labs RSTP team ServerPubKey $TELEMETRY_PUB_KEY # Provided by Chainlink Labs RSTP team [Database] MaxIdleConns 100 # should equal or greater than total number of mercury jobs MaxOpenConns 400 # caution! ensure postgres is configured to support this [[EVM.Nodes]] put RPC nodes here 与仓库默认值的对比为什么要改对照 节点默认配置文档 与 TelemetryIngress 配置接口可以看到 Mercury 场景相对默认值的变化参数仓库默认值Mercury 推荐值原因Database.MaxIdleConns10100每个 Mercury 任务都会占用连接应 ≥ 任务总数Database.MaxOpenConns100400高频轮次并发读写压力大注意 Postgres 端也要同步调大 max_connectionsTelemetryIngress.SendInterval500ms250msMercury 遥测产生量大需要更快的批处理上报节奏TelemetryIngress.BufferSize100300增大缓冲避免高吞吐时丢遥测消息TelemetryIngress.MaxBatchSize50100更大的批量提升上报效率OCR2.CaptureEATelemetryfalsetrue采集外部适配器bridge/EA调用遥测便于诊断数据源延迟其余需要重点核对的节点参数[P2P.V2]网络AnnounceAddresses使用外部 IP/端口公网可达ListenAddresses使用0.0.0.0:$INTERNAL_PORT监听内网端口且文档强调端口要随机化并确保在防火墙上正确放行。[[EVM]]ChainID与 Feed 配置、任务relayConfig.chainID保持一致示例 42161。[OCR] Enabled false关闭传统的 OCR 1避免与 OCR2 抢占资源。[P2P] PeerID与[OCR2] KeyBundleID文档注释指出这两个值**“ideally should be set in the job spec”**——优先在 Job 规范中指定节点级配置仅作兜底。[[TelemetryIngress.Endpoints]]URL与ServerPubKey由 Chainlink Labs RSTP 团队提供用于把遥测数据上报到中央遥测入口。报告校验与遥测从观测到链上验证的完整链路将上述配置串起来Mercury 的一条数据通路如下观测ObservationOCR2 任务按deltaRound250ms节奏执行observationSourcepipeline从 ncfx/tiingo/coinmetrics 拉取 ETH/USD 价格经multiply与median聚合出benchmark_price、bid_price、ask_price三条数据流。LLO 数据源模块 与 observation_context.go 负责管理这些观测值遥测采样 会在这一阶段采集观测与 EA 遥测受CaptureEATelemetry控制。共识与签名Consensus Attestation节点通过 P2P v2 网络交换观测达成一致后由 signers 对报告签名对应 Feed 配置中的signers轮次调度受deltaInitial、deltaProgress、deltaResend、f等 offchainConfig 参数约束。传输与验证Transmission Verificationtransmitters 把签名报告提交到源链chainId指定链由contractAddressVerifier在expirationWindow86400 秒窗口内校验onchainConfig的max/min则作为报告值的边界检查。报告编码report_codecs.go 中注册的多种编解码器决定了最终提交给链上的报告字节格式示例offchainConfigVersion30对应 v30 插件及其默认编码路径。遥测上报整个流程的遥测经 telemetry.go 汇入 TelemetryIngressSendInterval、BufferSize、MaxBatchSize控制批处理节奏供运营方NOP与 RSTP 团队监控节点健康。部署检查清单与常见坑综合文档的警告与源码约束部署前请逐项核对Feed 配置与 Job 的feedID必须一致——Bootstrap 与 OCR2 任务中的feedID漏填或填错是最常见的不工作原因文档明确警告。relayConfig.chainID指向源链且节点[[EVM]]、Feed 配置chainId三者保持一致。Feature.LogPoller true必须开启否则节点启动报致命错误OCR2.Enabled true、P2P.V2.Enabled true同样为必需。数据库连接数MaxIdleConns/MaxOpenConns上调后务必同步调整 Postgres 的max_connections否则连接会被 Postgres 侧拒绝。P2P 端口随机选择、防火墙上放行AnnounceAddresses对应的公网端口。遥测SendInterval等参数按吞吐调优多 Feed 部署时需监控BufferSize是否被写满导致丢遥测。费用与窗口baseUSDFee、expirationWindow需与链上FeeManager/Verifier 的链上参数保持一致否则验证可能被拒绝。按照本文的配置清单结合 Mercury 原始文档、LLO 实现 与 集成测试即可在 Chainlink 节点上完整落地一套 Mercury 低延迟数据源。【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Chainlink Mercury 低延迟数据源部署指南：Feed 配置、OCR 任务与节点参数全解析
Chainlink Mercury 低延迟数据源部署指南Feed 配置、OCR 任务与节点参数全解析【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink导读本文基于仓库中的 Mercury 文档系统讲解 Chainlink 节点上 Mercury基于 LLO 低延迟预言机协议构建的数据源从零部署所需的全部配置包括 Verifier 合约上的 Feed 配置 JSON 结构、节点上的 Bootstrap 与 OCR2 两类 Job 定义以及支撑高吞吐场景的节点级 TOML 参数调优。读完本文你将能够独立填写一份可运行的 Mercury Feed 配置、写出正确的 Bootstrap/OCR2 任务规范并理解节点侧数据库连接数、P2P、遥测入口等关键参数为何必须按文档要求调整。文中所有关键字段均结合仓库源码core/services/llo/、core/services/job/models.go、core/config/docs/core.toml等给出实现层面的依据与默认值。Mercury 与 LLO先理解这套体系在 Chainlink 中的位置Mercury 是 Chainlink 面向高频数据消费场景例如 DeFi 衍生品定价推出的低延迟数据源解决方案。在 当前仓库 中Mercury 的实现依托于core/services/llo目录下的 LLOLow Latency Oracle协议LLO delegate 实现 是 LLO 任务的执行入口它基于 libocr 的offchainreporting2plus构建 oracle 实例并同时支持OCR3.0v30与 OCR3.1v31两套协议版本——这也解释了为什么文档示例中offchainConfigVersion取值为30。delegate 会为每个 LLO 任务创建1 或 2 个 ContractConfigTracker对应代码中的 Blue/Green 双实例命名后者服务于 LLO 的平滑退役/切换机制ShouldRetireCache、RetirementReportCache是 Mercury 实现无感升级的基础设施。报告编解码器 集中注册了所有支持的链上报告格式JSON、EVMPremiumLegacy、EVMABIEncodeUnpacked、EVMABIEncodeUnpackedExpr、EVMStreamlined 与 HistoryBackfill。Feed 的offchainConfig正是决定使用哪一套编码与协议行为的核心输入。LLO 遥测服务 负责在观察Observation、报告Report与 EA 调用等环节采集遥测数据并通过 TelemetryIngress 上报。在 LLO 集成测试 中可以直观看到 Mercury 数据源涉及的全部链上组件Configurator、DestinationVerifier与DestinationVerifierProxy、ChannelConfigStore、Verifier与VerifierProxy、FeeManager、RewardManager以及LinkToken。其中Verifier 合约就是文档 Feed 配置中的contractAddress即数据报告的链上校验者。Feed 配置Verifier 合约上的数据源定义Mercury 的每个数据源Feed都对应 Verifier 合约上的一份配置。文档给出了完整的 JSON 示例这是所有后续 Job 配置的前提——节点的 Bootstrap/OCR2 任务都会引用这里定义的feedId。{ feedId: 0x14e044f932bb959cc2aa8dc1ba110c09224e639aae00264c1ffc2a0830904a3c, chainId: 42161, // source chain id contractAddress: 0x14e044f932bb959cc2aa8dc1ba110c09224e639a, // verifier contract address configCount: 1, // the index of this config signers: [ 0x000....01, 0x000....02, 0x000....03, 0x000....04 ], // NOP signing addresses transmitters: [ 0x000....11, 0x000....12, 0x000....13, 0x000....14 ], // NOP transmitter addresses offchainConfig: { baseUSDFee: 0.1, // 10c base fee to verify the report deltaCertifiedCommitRequest: 1s, deltaGrace: 0s, deltaInitial: 600ms, deltaProgress: 2s, deltaResend: 10s, deltaRound: 250ms, deltaStage: 0s, expirationWindow: 86400, // window in which a report can be verified in seconds f: 3, maxDurationObservation: 250ms, maxDurationQuery: 50ms, maxDurationShouldAcceptAttestedReport: 50ms, maxDurationShouldTransmitAcceptedReport: 50ms, rMax: 25, s: [ 4 ] }, offchainConfigVersion: 30, onchainConfig: { max: 99999999999999999999999999999, min: 1 } }顶层字段说明字段含义说明feedId数据源唯一标识32 字节哈希后续 Job 中必须用feedID与之对应否则任务无法工作chainId源链 ID即产生区块数据的链文档注释 source chain id示例为 Arbitrum One 的 42161contractAddressVerifier 合约地址链上报告校验者地址configCount配置索引同一 Feed 配置的版本序号用于区分新旧配置signers签名者地址列表参与报告签名的 NOP 地址须与节点 OCR2 密钥中的 OnchainSigning 地址一一对应transmitters传输者地址列表负责把已签名报告提交到链上的 NOP 地址offchainConfigVersion离链配置版本示例为30对应 LLO delegate 中 v30OCR3.0实现升级到 OCR3.1 时使用 v31onchainConfig链上配置报告值的合法性上下界见下文onchainConfig报告值的价格边界onchainConfig中只有max与min两个字段它们界定了报告值价格等的合法区间超出该区间的报告会被拒绝校验。示例给出了一个极大值上界99999999999999999999999999999与下界1实际部署时应按业务合理收窄以抵御异常或恶意观测值。offchainConfigOCR 轮次时序与容错参数offchainConfig由 libocr 的 OCR3 配置ocr3config驱动控制着每个轮次round的调度节奏与容错阈值直接决定 Mercury 的延迟表现deltaRound250ms目标轮次间隔是低延迟的核心参数。示例中每 250ms 就期望产出一轮报告这要求节点间的 P2P 网络与数据库都要能承受相应吞吐。deltaInitial600ms启动或配置变更后第一轮报告的启动延迟。deltaProgress2s协议级进度超时超过该时间未见进展则触发重传/重新调度。deltaResend10s对长时间未确认的消息进行重发的间隔。deltaGrace0s容忍时钟漂移的宽限时间。deltaStage0s阶段间如轮次缓存的附加延迟0 表示不引入额外等待。deltaCertifiedCommitRequest1s发起 certified commit已认证提交请求的间隔。expirationWindow86400报告可在链上被验证的有效窗口秒。示例为 86400 秒24 小时需与链上校验逻辑、最终性确认时间匹配。f3容错节点数最多可容忍 f 个节点作恶或故障。示例 4 个 signers/transmitters 配合f3意味着需2f1个签名。rMax25报告传输的最大轮次限制用于约束传输延迟与频率。s[4]各阶段传输规则配置schedule 数组示例为单阶段。maxDurationObservation250ms单次观察拉取数据源的最大耗时预算。maxDurationQuery50msQuery 阶段v31 协议的最大耗时预算。maxDurationShouldAcceptAttestedReport50ms判定是否接受已认证报告的最大耗时。maxDurationShouldTransmitAcceptedReport50ms判定是否传输已接受报告的最大耗时。baseUSDFee0.1验证一份报告的基础费用美元示例为 10 美分。这是 Mercury 商业化收费模型的链下部分与链上FeeManager配合使用见 LLO 集成测试 中的 FeeManager 部署。提示上述时长类参数均需与maxDurationObservation等预算相协调——轮次越密集deltaRound越小留给观察与查询的预算就越紧数据源bridge/EA的延迟必须足够低才能避免每轮超时。Jobs让节点真正跑起来Feed 配置发布到 Verifier 合约后需要在每个 Chainlink 节点上创建两类任务一个Bootstrap任务负责 P2P 引导和至少一个OCR2 Mercury任务负责实际参与报告轮次。Bootstrap 任务Bootstrap 节点是 LLO/OCR3 网络的引导入口负责向新加入的 oracle 节点通告网络拓扑。type bootstrap relay evm schemaVersion 1 name $feed_name contractID $verifier_contract_address feedID $feed_id # IMPORTANT - DONT FORGET THIS OR IT WONT WORK contractConfigTrackerPollInterval 15s [relayConfig] chainID $evm_chain_id fromBlock $from_block文档特别强调两个关键字段relayConfig.chainID目标链 ID即我们从哪个链拉取区块号文档原文 the chain we pull block numbers from。它决定 LogPoller 从哪条链扫描 Verifier 合约的配置变更事件必须与 Feed 配置中的chainId一致。contractIDVerifier 合约地址。feedIDFeed 的唯一标识。文档用红色警告级别标注DONT FORGET THIS OR IT WONT WORK忘了它任务就不会工作。这一字段在 OCR2 任务规范定义 中对应FeedID *common.Hash32 字节哈希类型不匹配时任务校验会失败。contractConfigTrackerPollInterval 15s控制节点轮询链上配置的间隔在 任务运行器集成测试 中同样使用了15s作为标准取值。relayConfig.fromBlock指定 LogPoller 从哪个区块开始回溯扫描。OCR2 Mercury 任务OCR2 任务是节点真正参与观测、签名与传输报告的载体。pluginType mercury表明这是 Mercury 数据源类型的 OCR2 任务其字段同样定义在 OCR2OracleSpec。type offchainreporting2 schemaVersion 1 name $feed_name forwardingAllowed false maxTaskDuration 1s contractID $verifier_contract_address feedID $feed_id contractConfigTrackerPollInterval 15s ocrKeyBundleID $key_bundle_id p2pv2Bootstrappers [ $bootstrapper_address ] relay evm pluginType mercury transmitterID $csa_public_key observationSource // ncfx ds1_payload [typebridge namencfx timeout50ms requestData{\data\:{\endpoint\:\crypto-lwba\,\from\:\ETH\,\to\:\USD\}}]; ds1_median [typejsonparse pathdata,mid]; ds1_bid [typejsonparse pathdata,bid]; ds1_ask [typejsonparse pathdata,ask]; ds1_median_multiply [typemultiply times100000000]; ds1_bid_multiply [typemultiply times100000000]; ds1_ask_multiply [typemultiply times100000000]; // tiingo ds2_payload [typebridge nametiingo timeout50ms requestData{\data\:{\endpoint\:\crypto-lwba\,\from\:\ETH\,\to\:\USD\}}]; ds2_median [typejsonparse pathdata,mid]; ds2_bid [typejsonparse pathdata,bid]; ds2_ask [typejsonparse pathdata,ask]; ds2_median_multiply [typemultiply times100000000]; ds2_bid_multiply [typemultiply times100000000]; ds2_ask_multiply [typemultiply times100000000]; // coinmetrics ds3_payload [typebridge namecoinmetrics timeout50ms requestData{\data\:{\endpoint\:\crypto-lwba\,\from\:\ETH\,\to\:\USD\}}]; ds3_median [typejsonparse pathdata,mid]; ds3_bid [typejsonparse pathdata,bid]; ds3_ask [typejsonparse pathdata,ask]; ds3_median_multiply [typemultiply times100000000]; ds3_bid_multiply [typemultiply times100000000]; ds3_ask_multiply [typemultiply times100000000]; ds1_payload - ds1_median - ds1_median_multiply - benchmark_price; ds2_payload - ds2_median - ds2_median_multiply - benchmark_price; ds3_payload - ds3_median - ds3_median_multiply - benchmark_price; benchmark_price [typemedian allowedFaults2 index0]; ds1_payload - ds1_bid - ds1_bid_multiply - bid_price; ds2_payload - ds2_bid - ds2_bid_multiply - bid_price; ds3_payload - ds3_bid - ds3_bid_multiply - bid_price; bid_price [typemedian allowedFaults2 index1]; ds1_payload - ds1_ask - ds1_ask_multiply - ask_price; ds2_payload - ds2_ask - ds2_ask_multiply - ask_price; ds3_payload - ds3_ask - ds3_ask_multiply - ask_price; ask_price [typemedian allowedFaults2 index2]; [pluginConfig] serverURL $mercury_server_url serverPubKey $mercury_server_public_key [relayConfig] chainID $evm_chain_id fromBlock $from_block字段解读type offchainreporting2pluginType mercury声明这是一个 OCR2 Mercury 插件任务。pluginType在 models.go 中对应PluginType枚举mercury是 LLO 在 OCR2 任务层的外显类型LLO delegate 在任务注册时通过该字段被选中见 job/orm.go 中case types.LLO的分派逻辑。contractIDVerifier 合约地址与 Bootstrap 任务、Feed 配置保持一致。feedID与 Feed 配置中的feedId相同的 32 字节哈希——这里是唯一能把任务与特定数据源绑定起来的字段。ocrKeyBundleIDOCR2 密钥包 ID对应节点的 Offchain 签名密钥与 Feed 配置中signers对应。p2pv2BootstrappersBootstrap 节点的 P2P v2 地址列表格式为host:port/peerID。transmitterID传输者身份通常为节点的CSA 公钥$csa_public_key与 Feed 配置中transmitters对应。maxTaskDuration 1s单次 pipeline 任务执行的最大时长须与 Feed 配置中maxDurationObservation的预算匹配。observationSource观测阶段执行的数据管道。示例聚合了ncfx、tiingo、coinmetrics三个外部数据源通过bridge任务调用 EA分别解析mid/bid/ask价格经multiply×10⁸ 将小数价格转为链上整数精度后再由median取中位数allowedFaults2允许两个数据源故障。最终的三个输出benchmark_priceindex0、bid_priceindex1、ask_priceindex2即是报告中的三条数据流。[pluginConfig]serverURL与serverPubKey指向 Mercury 服务端数据消费方的聚合/分发端点用于对接 Mercury 服务层。节点级配置高吞吐下的关键参数Mercury 的轮次频率如每 250ms 一轮会产生远超常规预言机任务的网络与数据库负载因此文档要求对节点配置文件做专门调整并明确标注了必须开启的开关OCR2.Enabled必须为true——Mercury 走的是 OCR2 任务框架。P2P.V2.Enabled必须为true——OCR2 依赖 P2P v2 网络。Feature.LogPoller必须为true——不设置会直接报致命错误fatal errors。LogPoller 负责扫描链上配置变更Verifier 合约的 feed 配置、配置更新等是 LLO delegate 中ContractConfigTracker的数据来源。JobPipeline.MaxSuccessfulRuns建议设为0——关闭成功运行的持久化大幅降低数据库写入压力代价是在 UI 中看不到历史成功运行记录。TelemetryIngress.SendInterval——Mercury 遥测数据量大文档给出经测试的250mssingle feed with 5 nodes 场景实测可行多 Feed 时需监控并按需调整。Database——必须把连接数上限提高到远超默认值。以下是文档给出的完整节点 TOML 示例RootDir $ROOT_DIR [JobPipeline] MaxSuccessfulRuns 0 # you may set to some small value like 10 or similar if you like looking at job runs in the UI [Feature] UICSAKeys true # required LogPoller true # required [Log] Level info # this should be debug for chainlink internal deployments, nops may use info to reduce log volume [Log.File] standard values [WebServer] standard values [WebServer.TLS] standard values [[EVM]] ChainID 42161 # change as needed based on target chain [OCR] Enabled false # turn off OCR 1 [P2P] TraceLogging false # this should be true for chainlink internal deployments, we may ask nops to set this to true for debugging PeerID $PEERID [P2P.V2] Enabled true # required DefaultBootstrappers mercury bootstrap nodes # Note that this should ideally be set in the job spec, this is just a fallback # Make sure these IPs are properly configured in the firewall. May not be necessary for internal nodes AnnounceAddresses [$EXTERNAL_IP:$EXTERNAL_PORT] # Use whichever port you like, pls randomize, MAKE SURE ITS CONFIGURED IN THE FIREWALL ListenAddresses [0.0.0.0:$INTERNAL_PORT] # Use whichever port you like, pls randomize, MAKE SURE ITS CONFIGURED IN THE FIREWALL [OCR2] Enabled true # required KeyBundleID $KEY_BUNDLE_ID # Note that this should ideally be set in the job spec, this is just a fallback CaptureEATelemetry true [TelemetryIngress] UniConn false SendInterval 250ms BufferSize 300 MaxBatchSize 100 [[TelemetryIngress.Endpoints]] Network EVM ChainID 42161 # change as needed based on target chain URL $TELEMETRY_ENDPOINT_URL # Provided by Chainlink Labs RSTP team ServerPubKey $TELEMETRY_PUB_KEY # Provided by Chainlink Labs RSTP team [Database] MaxIdleConns 100 # should equal or greater than total number of mercury jobs MaxOpenConns 400 # caution! ensure postgres is configured to support this [[EVM.Nodes]] put RPC nodes here 与仓库默认值的对比为什么要改对照 节点默认配置文档 与 TelemetryIngress 配置接口可以看到 Mercury 场景相对默认值的变化参数仓库默认值Mercury 推荐值原因Database.MaxIdleConns10100每个 Mercury 任务都会占用连接应 ≥ 任务总数Database.MaxOpenConns100400高频轮次并发读写压力大注意 Postgres 端也要同步调大 max_connectionsTelemetryIngress.SendInterval500ms250msMercury 遥测产生量大需要更快的批处理上报节奏TelemetryIngress.BufferSize100300增大缓冲避免高吞吐时丢遥测消息TelemetryIngress.MaxBatchSize50100更大的批量提升上报效率OCR2.CaptureEATelemetryfalsetrue采集外部适配器bridge/EA调用遥测便于诊断数据源延迟其余需要重点核对的节点参数[P2P.V2]网络AnnounceAddresses使用外部 IP/端口公网可达ListenAddresses使用0.0.0.0:$INTERNAL_PORT监听内网端口且文档强调端口要随机化并确保在防火墙上正确放行。[[EVM]]ChainID与 Feed 配置、任务relayConfig.chainID保持一致示例 42161。[OCR] Enabled false关闭传统的 OCR 1避免与 OCR2 抢占资源。[P2P] PeerID与[OCR2] KeyBundleID文档注释指出这两个值**“ideally should be set in the job spec”**——优先在 Job 规范中指定节点级配置仅作兜底。[[TelemetryIngress.Endpoints]]URL与ServerPubKey由 Chainlink Labs RSTP 团队提供用于把遥测数据上报到中央遥测入口。报告校验与遥测从观测到链上验证的完整链路将上述配置串起来Mercury 的一条数据通路如下观测ObservationOCR2 任务按deltaRound250ms节奏执行observationSourcepipeline从 ncfx/tiingo/coinmetrics 拉取 ETH/USD 价格经multiply与median聚合出benchmark_price、bid_price、ask_price三条数据流。LLO 数据源模块 与 observation_context.go 负责管理这些观测值遥测采样 会在这一阶段采集观测与 EA 遥测受CaptureEATelemetry控制。共识与签名Consensus Attestation节点通过 P2P v2 网络交换观测达成一致后由 signers 对报告签名对应 Feed 配置中的signers轮次调度受deltaInitial、deltaProgress、deltaResend、f等 offchainConfig 参数约束。传输与验证Transmission Verificationtransmitters 把签名报告提交到源链chainId指定链由contractAddressVerifier在expirationWindow86400 秒窗口内校验onchainConfig的max/min则作为报告值的边界检查。报告编码report_codecs.go 中注册的多种编解码器决定了最终提交给链上的报告字节格式示例offchainConfigVersion30对应 v30 插件及其默认编码路径。遥测上报整个流程的遥测经 telemetry.go 汇入 TelemetryIngressSendInterval、BufferSize、MaxBatchSize控制批处理节奏供运营方NOP与 RSTP 团队监控节点健康。部署检查清单与常见坑综合文档的警告与源码约束部署前请逐项核对Feed 配置与 Job 的feedID必须一致——Bootstrap 与 OCR2 任务中的feedID漏填或填错是最常见的不工作原因文档明确警告。relayConfig.chainID指向源链且节点[[EVM]]、Feed 配置chainId三者保持一致。Feature.LogPoller true必须开启否则节点启动报致命错误OCR2.Enabled true、P2P.V2.Enabled true同样为必需。数据库连接数MaxIdleConns/MaxOpenConns上调后务必同步调整 Postgres 的max_connections否则连接会被 Postgres 侧拒绝。P2P 端口随机选择、防火墙上放行AnnounceAddresses对应的公网端口。遥测SendInterval等参数按吞吐调优多 Feed 部署时需监控BufferSize是否被写满导致丢遥测。费用与窗口baseUSDFee、expirationWindow需与链上FeeManager/Verifier 的链上参数保持一致否则验证可能被拒绝。按照本文的配置清单结合 Mercury 原始文档、LLO 实现 与 集成测试即可在 Chainlink 节点上完整落地一套 Mercury 低延迟数据源。【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考