来源与回退
每一次成交、每一次回撤检查、每一个排行榜排名以及每一笔 USDC 支付,都可追溯到 Dexter 在某个具体时间戳接受的一个价格。单个发布者宕机不能等同于市场冻结或支付被拒——来源层经过精心设计,使主源故障可在同一个 tick 内切换到经过预先审核的冗余路径,只有当任何路径都无法通过偏离、新鲜度与深度门控时,才将市场降级为 reduced 或 close-only。下面是完整的来源阶梯、mux 如何提升某一路径为激活、将市场翻转为降级姿态的精确条件,以及这种情况下你的持仓与 30 天挑战赛时钟会发生什么。
每个 Dexter 市场的常态运行同时需要两条健康路径:主 Hermes/Pyth 推送流,以及一个独立的 HTTP oracle mux,运行时在每一个 tick 轮询它并与主源交叉核验。单一来源运行不是稳态——它是一种明确的可用性覆盖,仅在运行时已记录故障、记录策略例外并在整段时间将市场降级为降级姿态时启用。因此下面的阶梯是一个有序的故障切换计划,而不是 mux 任意挑选的自助菜单。
| 来源路径 | 在平台中的角色 |
|---|---|
| Hermes / Pyth(主源) | 每个受支持市场的低延迟推送参考锚点;聚合 Pyth 在链上验证的发布者集合 |
| HTTP oracle mux(交叉核验) | 独立的拉取路径,必须在每一个 tick 与 Hermes 在偏离区间内一致,标记才会被提升 |
| 单路径可用性覆盖 | 仅当某一族宕机且运行时接受降低法定人数时启用;市场同时降级为 reduced 或 close-only |
| 最后已知受控保持 | 若任何路径都不可接受,引擎保持最后经过校验的标记,暂停新执行,并向运营与已发布状态发出降级事件 |
#来源如何变为激活
存在回退路径并不等同于被信任。来源 mux 对每个市场的每一个 tick 做出一项决策:哪一组可用路径能通过新鲜度窗口、在偏离范围内一致、通过该市场的延迟上限,并满足深度/价差守卫。该决策是策略而非启发——相同输入总是产生相同结果,所选来源集合记录在运行时日志中,并被戳入下一个结算根。
保守是明确的默认。当主源变弱时,mux 首先尝试在配置上限内拓宽延迟容忍以保持两条路径都激活。若交叉核验仍然无法通过偏离区间,运行时倾向于降级市场——降为 reduced,然后 close-only,然后 halted——而不是将更精简的来源集提升到正常姿态。便利与漂亮的可用率数字,不是在策略其余部分不支持的路径上继续交易的有效理由。
当回退被启用时,会同时发生两件事。第一,撮合引擎继续以剩余路径成交 reduce-only 订单,使用户能管理已开风险。第二,市场状态被发布为降级,使每个已连接客户端、规则引擎与出纳看到同一姿态。日后审阅运行时日志的审阅者可以毫无歧义地回答一个问题:每一个 tick 上哪条路径处于激活、原因是什么、市场在什么姿态下交易?
tick T 到达
-> mux 读取 Hermes 主源 + HTTP 交叉核验
-> 评估新鲜度、偏离、延迟、深度门控
-> 若两者通过:标记被提升,市场保持 live
-> 若一者失败:mux 在延迟上限内重试
-> 若仍失败:市场姿态降级
reduced -> close-only -> halted
-> 所选来源集与姿态哈希
提交到下一个状态根中#为什么来源选择对结算至关重要
激活的来源集不是操作脚注——它是链上结算记录的一部分。运行时将来源姿态元数据(活跃发布者、回退启用情况、观察到的偏离、新鲜度余量、市场姿态)进行哈希,并将该哈希提交到金库合约接受的每一个状态根内。因此,基于根 R 最终化的提款绑定于产生 R 内余额的精确预言机配置。
这正是"平台声称使用了 Hermes"与"合约可证明每笔支付依赖了哪份数据源姿态"之间的区别。这也是价格层在与余额账本相同意义上可审计的原因:日后在 Base 上读取状态根的事件后审阅者,不仅能回答某账户在根 R 上价值多少,还能回答该快照被封存时哪些来源路径处于 live、哪些处于降级,以及撮合引擎运行在何种姿态下。标记构建细节继续在 标记价格构建 中阐述;会话与降级状态过渡记录于 会话与降级状态。