跳到正文
Financial Context Wiki

历史证明：记录顺序、Tick、Slot 与共识边界

历史证明是 Solana 的顺序哈希链时钟：它使生产者记录的顺序和计算计数可验证，但不能独立证明挂钟时间、公平交易到达顺序、分叉选择或最终性。

更新于

仅供协议分析教育参考，不构成投资、验证者运营、性能或安全建议。历史证明参数、客户端行为、领导者调度、投票、分叉选择和确认规则可能因网络和软件版本而变化。

直接回答

历史证明，或 PoH，是 Solana 的加密时钟和账本排序数据结构。生产者重复应用哈希函数，以便每个输出都依赖于之前的输出，定期记录计数和状态，并将交易衍生的数据混合到链中。验证者可以重新计算这些转换并确认该特定链记录的顺序。

PoH 不是独立的共识算法。它不会选择规范分叉、形成质押加权共识、最终确定区块，也不能证明交易在特定现实时间到达网络。Solana 将这套时钟与领导者排程、交易执行、验证者投票、分叉选择及 Tower BFT 式锁定结合。两个分叉都可能包含内部有效的 PoH 序列；共识规则决定网络采用哪段历史。

这项保证的范围有限。如果条目在状态 h2 之后承诺数据 d，那么缺少该承诺就无法计算后续状态 h3 = H(h2 || d)。这表明生成者在计算 h3 前已知 d，并固定了它相对于后续输出的位置。它并不说明每个验证者何时收到 d、领导者是否按到达顺序纳入交易、d 是否描述真实的外部事件，或该条目是否成为规范历史的一部分。

生成是连续的，因为直到前一个哈希存在才知道下一个输入。已发布的边界状态允许验证者并行重播单独的有界段，但聚合哈希工作仍然存在。因此，PoH 经常与可验证的延迟函数进行比较，而 Solana 自己的 Tower BFT 解释称其为对该术语的宽松使用；正式的 VDF 通常具有评估和验证接口，其验证相对于顺序评估来说是高效的。

如何分析历史证明

  1. 明确网络与软件环境。 记录网络、创世哈希、槽位、纪元、Agave 或其他客户端版本以及观察时间。读取 hashes_per_tick、ticks_per_slot、ns_per_slot 等实际生效的值；不要沿用旧文章或其他集群的常量。
  2. 重建哈希链。 从受信任的前驱状态开始，验证每个条目的 num_hashes，生成的哈希值和交易列表。在 Agave 的条目实现中，条目标识符取决于前一个条目，并且当存在交易时，还取决于从其签名派生的哈希值。
  3. 验证 Tick 与 Slot 位置。 按 Bank 和 Recorder 规则检查 Tick 条目、预期哈希计数、Tick 高度及最大 Tick 高度。Recorder 使用配置的 ticks_per_slot 将 Tick 高度映射到 Slot；Slot 是协议区间，不是来自外部时钟的独立证据。
  4. 区分纳入与到达。 承诺只能证明生成者最迟在把输入纳入该序列时已经知道它。若要主张时间下界，应识别指向先前 PoH 状态的签名回引。两种界限都不能证明全网首次看到的顺序、内存池公平性或可信 UTC 时间戳。
  5. 将生成与验证分开。 测量一个依赖链上的顺序生产，然后使用经过身份验证的段边界和可用核心测量重放。报告总哈希值、关键路径延迟、聚合验证器工作和边界数据假设，而不是仅仅说验证“快”。
  6. 追踪共识路径。 识别排定的领导者、Bank 状态、投票、锁定、分叉选择规则、已生根或最终确定的状态及承诺级别。一条有效的 PoH 链仍可能属于落败分叉；仅凭看似更长的计数器不能构成共识证书。
  7. 检验对抗与运营场景。 测试领导者双重出块、交易遗漏与重排、跳过 Slot、网络分区、更快或校准错误的硬件、无效 Tick 计数、延迟重放、账本不可用、客户端分歧，以及运营者或基础设施的关联控制。

审查输出应区分四个声明：序列有效性、配置的协议时间、共识状态和外部时间。说明哪些起始哈希值和账本数据是可信的，哪些哈希值被重新计算，哪些投票或承诺证据被检查，哪些观察结果来自本地时钟或第三方服务。

示例

1. 数据插入固定记录位置

考虑 h1 = H(h0)，然后考虑 h2 = H(h1)。生产者插入交易衍生的承诺 d 并计算 h3 = H(h2 || d)，然后是 h4 = H(h3)。任何重放相同操作的人都可以验证记录的链是否在 h2 和 h3 之间提交了 d，并且 h4 取决于结果。

上限声明很窄：生产者在计算 h3 之前就知道 d。如果签名的交易本身引用了 h1，则验证者还可以表明它是在了解早期状态后形成的，并接受签名和来源检查。如果没有这样的反向引用，PoH 单独不提供下限。这两种情况都无法证明另一个节点首次收到交易的时间。

2. 分段重放可减少延迟，而不是聚合工作

假设记录的间隔包含 1,000,000 个哈希值，经过身份验证的检查点将其分为 10 个段，每段包含 100,000 个哈希值。如果有足够的内核，可以同时重放十个段，因此挂钟验证延迟可能接近一个段的持续时间加上开销。

验证者总共仍然执行 1,000,000 次哈希；检查点暴露了独立的起始状态，但不会将链变成简洁的证明。性能取决于硬件、调度、内存移动和边界置信度。这就是为什么并行 PoH 重放不应自动描述为每个正式 VDF 构造的有效验证算法。

3. Tick 与 Slot 算术取决于配置

假设一个示例配置为 hashes_per_tick = 100,000、ticks_per_slot = 8。完成全部哈希计算的 Slot 包含 100,000 * 8 = 800,000 次哈希，每个配置区间末尾都有 Tick 边界。任一参数变化都会改变映射；这些数值不是当前主网常量。

Agave 还支持不能用这项简化乘法概括的哈希计数配置。审核者应读取 Bank 的实际字段，并按客户端规则验证条目。把 Slot 或计数换算为秒还依赖目标时长校准和实际执行情况，而不只是密码学验证。

4. 记录顺序不等于到达顺序或最终性

假设事务 A 在事务 B 之前到达领导者，但领导者记录 B 接近计数 300,000，A 接近计数 450,000。有效的 PoH 证明 B 在生成的序列中先于 A。它并不能证明 B 先到达、排序是公平的或者另一个领导者遵守相同的顺序。

现在假设网络分区产生分叉 X 和分叉 Y，两者都有有效序列。PoH 验证可以拒绝任一分叉上的格式错误条目，却不会选择 X 或 Y。领导者排程、质押加权投票、锁定、分叉选择及所要求的承诺级别决定共识结果；应用程序不得用 PoH 计数替代确认或最终性证据。

风险和审查失败

密码和计时错误

  • 将 PoH 称为可信挂钟或独立声明哈希计数可以证明 UTC 时间戳。
  • 说交易包含证明了全网接收时间、首见顺序或外部数据的真实性。
  • 假设顺序生成可以防止生产者保留、省略或选择何时插入已知数据。
  • 把抗碰撞性单独视为对硬件速度、校准漂移或实现差异的完整约束。
  • 将并行段重放描述为零工作或作为不计算聚合哈希的简洁证明。
  • 将 PoH 称为正式的 VDF，而不说明要比较的构造、证明接口和验证假设。
  • 信任检查点边界、前驱哈希或下载的账本片段，而不验证其来源。

共识和协议错误

  • 将 PoH、权益证明、Tower BFT、领导者选举、分叉选择和最终性混为同一种机制。
  • 假设具有最高计数的有效序列必须是规范的，而不检查投票和分叉选择状态。
  • 将本地重放的条目视为已确认、已确定或最终确定，而不检查所请求的承诺语义。
  • 把历史 hashes_per_tick、ticks_per_slot 或 Slot 时长当作普遍适用的当前常数。
  • 重建顺序时忽略跳过的槽、领导轮换、分区、模棱两可和客户端版本差异。
  • 比较来自不相关分叉或起始状态的计数，就好像它们属于一个经过身份验证的序列一样。
  • 假设交易的最近区块哈希只是一个挂钟时间戳而不是协议有效性上下文。

操作、性能和控制错误

  • 仅对哈希生成进行基准测试，而忽略执行、签名验证、重放、带宽和存储。
  • 将理论段并行性与 CPU、I/O 和内存争用下观察到的验证器追赶等同起来。
  • 忽略滴答验证失败、记录器停顿、银行延迟、账本间隙、快照信任和损坏的状态。
  • 当客户端、托管、网络、领导者基础设施或控制共享时，将验证者身份视为独立的。
  • 假设更快的硬件可以消除网络延迟、数据包丢失、审查、拒绝服务或权益集中风险。
  • 提供目标时隙持续时间、吞吐量估计或旧基准作为服务水平保证。

常见的误解

  • PoH 是 Solana 的完整共识算法。 PoH 提供可验证的记录序列；验证者投票、锁定、分叉选择和其他共识规则决定网络采用的历史。
  • PoH 证明每笔交易的准确真实时间。 证明经过验证的序列内的依赖性和计数；将该序列映射到民用时间需要配置和外部观察。
  • PoH 保证交易排序公平。 领导者可以在协议和资源约束内选择、延迟、重排或省略输入；PoH 只让最终记录的顺序可审计。
  • PoH是工作量证明挖矿的另一个名字。 都使用哈希，但 PoH 的核心作用是顺序时钟，而不是获胜作品选择链的开放并行竞赛。
  • 任何有效的 PoH 序列都是最终序列。 竞争的分叉可能各自在内部有效；确认和最终确定需要网络的共识证据。

相关主题

来源

导航

搜索知识库...