先有先后，再谈投票
多数区块链的同步单位是区块：攒够一批交易、打包、广播、确认，交易最快也要等一个区块周期才可能被处理。工作量证明链还得把区块时间拉得很长，好降低两名矿工同时出块的概率。Solana 官方文档把自家路线描述成另一种思路：出块的领导节点先给区块盖上一个”时间到了”的证明，验证者核对证明本身，而不用靠区块间距去猜时间。这个机制叫 Proof of History，缩写 PoH。
一条串起来的哈希链
https://assets.skjop.cn/articles/202609021033/content-1.jpg
它的外壳非常朴素：一个持续自串的 SHA-256 哈希链。上一条哈希喂进去，吐出一条新哈希，如此往复。因为每一步都必须等上一步算完，串行地”敲”出 N 次哈希所花的时间就是时间流逝的证据，任何人都不能跳着算出来。记账的最小单位是条目，每个条目带着三项信息：距上一个条目做了多少次哈希、这些哈希叠出来的结果值、以及观测到的一批交易。官方源码注释写得很直白：把哈希次数乘以单次哈希耗时，就得到距上一个条目过去多久的一份估计。验证侧同样是重算一遍哈希链，确认次数对得上、交易确实混进了对应的哈希——算得快的人验证快，这也是它能被并行核对的原因。
把数据混进时钟里
纯计时器只要哈希链就好，为什么要把交易混进去？官方文档的解释是，这正是”证明历史”与单纯”可验证延迟函数”的分工差异：PoH 的哈希链把应用观测到的数据也吸了进去，于是某条数据与某个哈希的先后关系被密码学地钉死——数据必然出现在它之后的哈希之前。混入数据是双刃剑：链的形态因此不再和全局时钟软件绑定，但每个节点都得按同样的规则把交易塞进条目里，塞法本身要保持确定。文档还坦率承认，PoH 与学界一般定义的可验证延迟函数仍有出入，在相关争论尘埃落定前，Solana 会继续把它当作应用专用的可验证延迟函数来称呼。
条目本身还有一层容易忽略的规则：同一个条目里的交易受读写锁约束——同一个账户要么被一条交易写、要么被多条交易读，不能既读又写。排序上的不确定性也在这里被掐掉：偶尔有交易被刻意推后到下一个条目，只为让整本账的解读保持确定。对普通读者，这意味着”谁和谁能并进同一个条目”不是打包者的自由裁量，而是账户冲突表说了算。
它不是共识，也不裁决谁出块
https://assets.skjop.cn/articles/202609021033/content-2.jpg
常见误读是把 PoH 当成一种共识算法。按官方文档的框架，它回答的是”事情按什么顺序发生、中间过了多久”，而”谁有资格出块、哪些区块被确认”由权益加权投票环节决定；时钟给全网一个共同的先后刻度，共识在这把刻度上完成确认。文档同时强调乐观处理：验证者可以边收条目边执行，共识未达成时回滚状态。既然推进不再依赖”攒满一个区块”，交易也就绕开了传统链”必须等一个区块周期”的节拍——这是它区别于靠拉长区块时间规避冲突的工作量证明链的根本原因。对读者的实际意义有两层：读链上数据时，条目里的哈希链是一份可独立重算的时间证据，不必依赖任何节点的口头时间戳；评估安全风险时，则要把计时与共识分开归因——排序类问题该问领导节点调度与投票规则，而不是问哈希链本身。节点长期离线后重新追块时，还需要从可信来源拿到近期检查点，检查点同步是什么？以太坊节点为什么不从创世块开始追链 讨论过同类信任问题。本文为机制说明，参数与状态以官方文档为准，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。