07-18 一次指数价格更新，如何留下可审计的记录？
即使预言机网络已经产出价格，请求也成功返回，这次指数价格更新也未必最终生效，更不代表它已经可审计。运营方还需要说明：哪套策略决定了结果、哪些证据被采纳、谁授权了决策、此前是什么状态，以及新状态为什么能够最终生效。
为了验证这条边界，我们没有停留在架构描述，而是搭建了一套可运行的本地系统：四节点 Lyquor 委员会、可编程 HTTP 数据源、确定性判定内核、故障注入测试运行器、保存共享状态的 Lyquid，以及一套使用相同规则和场景输入的传统单进程协调器。
我们通过这次原型验证得到的核心结论是：这套工作流真正有用的输出，不是预言机数值或证书本身，而是一条把证据、授权主体、策略快照和最终状态转换绑定在一起的终态回执。
我们具体搭建了什么
这个原型只验证一种业务场景：更新 BTC/USD 指数价格。我们使用本地可编程数据源，没有接入真实交易所 API、公网或真实资产，也没有实现自动调度和生产级凭据管理。这样可以稳定复现不同输入和故障，把测试重点放在状态转换和权限边界上，而不是外部服务的不确定性。
为了把业务判定、Lyquor 执行、故障测试和对照实现分开，我们实现了四个相互配合的部分：
-
业务判定内核。 它根据策略和多节点观测结果决定是否接受价格更新，并生成终态回执。这部分不依赖 Lyquor，因此两种实现可以复用同一套规则。
-
Lyquor 实现。 每个节点从自己的数据源取得观测结果，委员会共同聚合并认证决定，最终把策略、轮次、价格和回执写入共享状态。
-
自动化测试环境。 可编程数据源负责模拟正常响应、超时、错误数据和连接故障；测试运行器负责发起轮次、执行重试、停止或重启节点，并比较各节点的最终状态。
-
单进程协调器。 它由一个运营方负责收集观测、执行相同的判定规则并让结果最终生效。我们用相同的测试场景对它进行验证，作为公平的对照，从而区分：哪些结果来自业务逻辑，哪些额外保证来自多方认证和共享状态。
下面这张图展示了 Lyquor 原型的执行路径和状态边界：
这套设计把节点本地信息与需要全网一致的状态分开。数据源端点、访问凭据、原始 HTTP 响应和诊断信息只保留在本地；会影响最终结果的策略、轮次、前序价格、最新价格和终态回执则写入共享网络状态，并在所有节点上保持一致。测试运行器只负责配置场景、发起操作和核对结果，不能决定哪一个结果最终生效。
一轮价格更新怎样最终生效
一轮价格更新要经过四步：收集数据、形成结果、由多个节点确认，再写入共享状态。
系统先开始一次新的价格更新，并记录当时适用的规则和更新前的价格。四个节点随后分别获取数据。无论请求成功、数据源不可用，还是返回格式有误，节点都会如实记录并签名，避免把缺失数据悄悄变成零或未经说明的缓存值。
接下来要通过两项检查：
| 检查 | 要回答的问题 | 规则 |
|---|---|---|
| 证据是否充分 | 现有数据是否足以决定价格？ | 至少 3 份有效结果，且来自至少 2 个不同的数据源 |
| 结果是否获得确认 | 这个结果是否可以修改共享状态？ | 四个节点中至少三个确认同一个结果 |
系统不会无限等待所有节点。只要首批已签名数据足以形成明确结果，就会进入确认阶段。为了验证数据到达顺序不会改变结果，我们测试了四个节点中任取三个的所有组合，以及不同的输入顺序。
即使三个节点已经确认，结果也不会立刻写入。系统还会检查这次更新是否仍然有效、规则有没有变化、更新前的价格是否匹配，以及这次更新是否已经结束。全部通过后，才能更新最新价格，并且只写入一份回执。一次调用返回成功只表示请求已经提交；测试运行器仍要从所有节点查询最新价格和回执，确认它们看到的状态一致。
终态回执实际记录什么
最终写入共享状态的回执包含决策上下文、规范化证据和两阶段授权信息：
ReceiptRecord
├─ 轮次与终态结果
│ ├─ Accepted | Rejected | Expired | Cancelled
│ └─ 前序价格、决定价格和终结原因
├─ 适用的快照
│ └─ 策略标识、版本、哈希和委员会配置世代
├─ 观测证据
│ ├─ 被采纳的节点、来源、数值、时间和响应哈希摘要
│ └─ 被排除的结果，以及排除原因：数据无效、来源不可用、数据过期或偏离过大
└─ 授权证据
├─ 提议签名节点 ID
└─ 证书签名节点 ID
四种终态具有不同含义：
| 终态 | 含义 | 对价格的影响 | 授权证据 |
|---|---|---|---|
Accepted | 业务规则接受候选结果 | 更新最新价格 | 提议签名节点和证书签名节点 |
Rejected | 已签名证据证明业务策略不能接受本次更新 | 保持前序价格 | 提议签名节点和证书签名节点 |
Expired | 在测试运行器的重试策略内无法形成证书 | 保持前序价格 | 获授权的运营方交易；没有预言机证书 |
Cancelled | 获授权的运营方操作或策略变更关闭本轮次 | 保持前序价格 | 获授权的运营方交易；没有预言机证书 |
这种区分避免把“节点不可用”误报成“市场数据不合格”，也避免把由运营方触发的过期或取消伪装成委员会认证的预言机判断。
我们如何执行故障矩阵
我们在四节点环境中运行了 17 个场景，随后又在协调器对照组中运行了同一批场景。
| 场景组 | 注入或重复的情况 | 测试运行器的通过条件 |
|---|---|---|
| H1 | 正常值 100、101、101 和 102 | 一条 Accepted 回执，决定价格为 101 |
| F1-F6 | 离群值、来源不可用、过期来源、业务门限不可达、节点缺失和价格跳变过大 | 进入正确的 Accepted、Rejected 或 Expired 分支，且不得错误修改价格 |
| F7-F9 | 重复认证调用、旧轮次回调和策略更新竞争 | 已有终态和回执保持不变 |
| F10-F11 | 初始提议节点故障，以及终结后重启节点 | 存活节点完成终结；重启节点追平且不重复生成回执 |
| F12 两种变体 | 非法 JSON 和整数溢出 | 非法证据被明确标记并排除，不污染轮次状态 |
| L1 | 四个节点都返回一致但错误的价格 120 | 系统仍会接受 120，并明确记录多节点一致无法识别共同错误 |
| C20 | 在同一次部署中连续执行 20 个正常轮次 | 轮次 ID 单调递增、前序价格链和回执有序，并在每轮后收敛 |
每个目标场景都检查预期终态及原因、预期最新价格、目标轮次恰好一条回执、符合预期的签名者证据，以及所有被观测或仍存活节点的权威状态哈希一致。这 17 个场景全部通过。
一些失败路径比正常路径更能说明设计边界。足够多已签名的 Unavailable 证据可以证明业务门限已不可达，因此形成经过认证的 Rejected。但停止两个节点只会造成证据不足，无法形成证书；该轮次会保持 Open，直到获授权的运营方将它终结为 Expired。重放同一个认证决策、提交旧轮次的决策，或使用过期策略再次执行，都不会造成第二次价格变化或生成第二条回执。节点重启后能够追平已接受状态，同时不会重复写入历史记录。
单进程协调器的对照结果
我们使用一个单进程协调器作为对照。它与 Lyquor 原型共用同一套判定规则、17 个测试场景和结果格式，也通过了相同的业务检查，包括判断价格更新、拒绝过期或重复操作、在重启后恢复状态并生成回执。这说明，这些能力并不依赖多节点认证。两者的主要差别是：协调器的数据收集、结果判定和状态写入都由一个运营方控制；Lyquor 则要经过至少三个节点确认才能写入结果。它们留下的审计记录也不同。
| 对比项 | Lyquor 原型 | 单进程协调器 |
|---|---|---|
| 判定规则 | 共享的确定性内核 | 相同的确定性内核 |
| 谁让结果最终生效 | 四个节点中至少三个确认后更新共享状态 | 一个受信任的进程写入本地状态 |
| 如何避免重复写入 | 根据共享状态检查 | 由进程根据本地状态检查 |
| 故障后如何恢复 | 切换提议节点；重启节点追平共享状态 | 重启进程并重新加载本地状态 |
| 审计记录 | 回执，以及提议签名节点和证书签名节点身份 | 回执，以及运营方控制的记录 |
| 需要运行的组件 | Lyquid 适配层、四个节点、排序后端和测试环境 | 一个进程和一个 JSON 文件 |
如果一项内部任务本来就由单一团队负责，单进程协调器通常更直接，配合存储访问控制、签名日志或只追加的审计服务可能已经足够。如果多个参与方必须共同决定哪些状态可以改变，或者不能允许任何一个运营方单独改写已接受的结果，Lyquor 的多节点确认和共享状态才可能带来额外价值。
不过，多节点确认不会让价格本身更真实。如果多个节点使用同一个错误来源、接受伪造的数据源身份，或者共同执行错误规则，它们仍可能确认错误结果。信任只是分散到了数据源、运营方、规则和证据记录上，并没有消失。
这个原型没有证明什么
在受控的本地环境中，这个原型表明，Lyquor 可以处理彼此不同的本地观测结果，形成认证决策和唯一终态回执，同时防止重放，并支持提议节点故障切换与多节点恢复。它没有验证价格策略在经济上是否合理。
我们没有接入真实交易所或生产基础设施，是为了排除外部数据波动、网络状况和运维配置的干扰，集中验证最核心的问题：多个节点能否对一次价格更新形成一致结果、只写入一份回执，并在故障或重启后保持状态一致。真实数据源的质量、公网运行、生产安全和市场采用情况，仍需要后续分别验证。
因此，更稳妥的结论是：
如果单一受信任写入方本来就是预期权威，使用传统协调器。
如果写入方本身需要受到约束，而且每个终态决策必须携带多方证据，
再考虑经过多方认证的共享状态设计。
下一步要回答的是：哪些真实的市场操作，既需要多方共同确认，又不能允许任何一方单独改写结果？ 只有找到这样的场景和参与者，才能判断这套设计是否值得继续投入。