Pyth 的拉取模式预言机是怎么工作的

结论先说

Pyth 代表”拉取式”（pull）预言机：价格不由网络主动写入合约，而是由”第一方数据源”（做市商/交易所/交易公司）实时签名，DApp 的调用者在每笔交易里把签名证明提交给合约，合约验证签名与新鲜度后使用。与推送（push）模式相比，pull 模式的价格永远是”调用时刻”的（实时性拉满），代价是”每次使用都要带证明”（调用方成本 + 复杂度）。它特别适合高实时性场景（高频交易、衍生品、跨链），也改变了 DApp 与预言机的关系——从”订阅存储值”变成”验证签名”。

第一方数据：与”聚合网络”的根本差异

推送式网络（如 Chainlink）：价格 = 独立节点从市场采集 + 聚合——数据源是”节点看到的行情”。Pyth：价格 = 做市商/交易所直接报价并签名——数据源是”做市商的报价本身”（第一方，first-party）。含义：一，数据质量上限高（报价方对自己报的价格负责，不是”采集二手行情”）；二，信任结构不同——你信任的是”报价方集合”（它们的报价诚实 + 系统在线），不是”采集节点集合”（它们的采集管道健康）；三，覆盖特点——第一方源在主流交易对上报价密集，长尾资产的报价方可能少（源数量本身是质量信号：同一 feed 的报价方数越多，单源问题被稀释越强）。

拉取流程：一笔交易里的价格使用

调用者（用户或合约）要执行一个读价格的 DApp 操作 → 从 Pyth 的发布端点获取”目标资产 + 当前时刻”的签名价格证明（attestation：报价方集合的签名 + 价格 + 时间戳 + 序列号）→ 把证明附在自己的交易里提交 → DApp 合约调用 Pyth 的更新/读取函数：验证签名（报价方公钥/聚合签名有效）、检查新鲜度（时间戳在允许的窗口内，如 90 秒）、更新合约内的”最新采用值”（或直接用证明里的值）→ DApp 逻辑按该价格执行。关键：价格是”随交易携带”的——同一个 DApp 合约，不同用户同一秒提交的价格可以不同（各自的证明时刻不同），这是 pull 模式的”逐交易实时性”。

新鲜度窗口：实时与可验证的平衡

证明里带时间戳，合约校验”现在 - 时间戳 ≤ 窗口”。窗口短（秒级）：价格极新鲜，但网络延迟/链拥堵时证明可能”过期”（交易提交时证明已超窗 → 回滚）——高延迟时段成功率下降。窗口长（分钟级）：成功率高，但”新鲜”打折（证明可能是几十秒前的价）。实际取值：Pyth 各部署的窗口参数不同（文档可查），DApp 可以在合约层加自己的新鲜度检查（比网络默认更严）。用户感知：pull 模式 DApp 在链拥堵时可能因”价格过期”回滚（错误信息指向 feed 新鲜度）——这是机制行为不是故障，重试（带新证明）即可。

push vs pull：怎么选

推送：合约存”最新聚合值”，读取免费（本地存储读）、调用方零配合——适合”价格使用频率高、单次使用价值低”的场景（大量小额的清算检查、余额估值）；滞后 = 更新间隔（秒级）。拉取：每次使用带证明、调用方承担证明获取 + gas（证明本身占交易体积）——适合”价格使用频率低、单次使用价值高”的场景（大额借贷操作、衍生品结算、跨链兑换）；实时 = 调用时刻。注意”跨链”维度：pull 模式天然跨链友好（证明是签名数据，任何能验证该签名的链都能用——同一 feed 的多链使用不需要”跨链喂价管道”），push 模式的跨链需要”更新跨链传播”机制（额外的同步环节 = 额外的时延/故障面）。

DApp 设计的连带影响

pull 模式改变了 DApp 的”价格责任”分布：合约不再”拥有”一个持续更新的价格存储（每个调用者自带价格），所以：一，“价格卡住”的形态变了——不是”存储值停更”，而是”新证明获取失败/过期”（用户侧可感，重试解决）；二，防御参数多一层——DApp 要在合约里自己实现/校验新鲜度窗口（网络给证明，DApp 定窗口）；三，审计面变化——“价格验证逻辑”进入合约审计范围（push 模式下这段逻辑在网络合约里，DApp 只读存储）。评估 pull 模式 DApp 时，把”合约内的 feed 校验逻辑”列入必审项。

用户的检查项

一，所用 DApp 的 feed 类型（push/pull/混合——文档”价格来源”章节）；二，pull 模式下：新鲜度窗口（多长）、报价方数量（该 feed 的源数）、以及”证明过期时的行为”（回滚 + 提示 vs 静默失败）；三，push 模式对照项：更新频率、节点/源参数（见相关专题）。两类模式的”健康检查”清单不同，别混用。波动期的特别注意：pull 模式的价格”跟手”（实时反映急变），你的操作（借贷/清算判断）面对的价比 push 模式 DApp 显示的更”当下”——跨 DApp 操作时意识到”两个 App 的价格是不同机制的产物”。

常见误读

“pull 模式更新”——pull 没有”更新频率”（不是定时推送），只有”调用时取最新证明”；“更新间隔”参数不适用于 pull，用”新鲜度窗口”描述它。“第一方源 = 绝对真实”——报价是”报价方的报价”（它的做市库存/风险偏好也影响报价），多报价方聚合稀释单源偏差，但不存在”市场真值” oracle（所有预言机都是”对真实值的结构化近似”）。“Pyth 便宜所以适合所有场景”——证明占 gas（交易体积大），高频小额场景 pull 的每次成本不划算——成本结构决定场景适配。

风险提示

本文描述 pull 模式预言机的通用机制，以 Pyth 为代表说明；具体 feed 参数（窗口、报价方集合、部署链）随版本变化，引用以官方文档当前版本为准。第一方数据源的”报价方独立性”（多少家独立机构、辖区分布）是质量维度——公开信息有限时按”源数量”下限理解。不构成对任何预言机网络/DApp 的推荐；DeFi 用户的价格风险以所用协议文档为准。

小结

一句话记忆：pull 模式 = 第一方源实时签名 + 调用者携带证明 + 合约验新鲜度；实时性拉满、跨链天然友好，代价是每次使用带证明（gas + 过期回滚可能）。评估 pull 模式 DApp：feed 窗口、报价方数、合约内校验逻辑三项必查——“价格卡住”在 pull 世界里叫”证明过期”，机制不同应对不同。