Solana 同步机制解析Proof of History 如何驱动 Entry 实时流与 800ms 区块确认【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana本文围绕 Solana 文档中的同步机制Synchronization展开讲清 Solana 为什么能以远小于分钟级的“区块时间”实现高吞吐核心在于用 Proof of HistoryPoH历史证明为数据流做密码学时间戳把区块拆成 entry 实时流式下发给验证者并在共识达成前乐观地处理交易。读完本文你将理解 PoH 哈希链、tick 与 entry 的生成流程、乐观处理与回滚机制并能对照仓库中 entry/src/poh.rs 与 poh/src/poh_service.rs 的源码验证这套设计的具体实现。为什么传统区块同步是吞吐瓶颈传统区块链同步的基本单位是“区块”一批交易打包成块交易必须等一个称为 “block time” 的时间段走完才能被处理。不同共识机制对这个时长有不同的约束PoW 系统block time 必须很大典型值约 10 分钟否则多个矿工同时挖出新合法区块的概率会显著上升导致分叉。PoS 系统没有 PoW 那样的结构性约束但缺少可靠时间戳时验证者无法判断区块到达的先后顺序。通行做法是给每个区块打上墙钟时间戳wallclock timestamp。然而由于时钟漂移和网络延迟抖动时间戳精度只有“一两个小时”的量级为了让“每个区块的中位时间戳单调递增”这一假设成立这些系统只能进一步拉长 block time。也就是说无论是 PoW 的出块竞争还是 PoS 的墙钟时间戳最终都把同步单位拖向了“大区块 长时间间隔”交易确认被整体推迟。Solana 的出发点就是打破这个约束。Proof of History用密码学证明“时间已过去”Solana 采用了截然不同的方案即Proof of HistoryPoH领导者节点leader用密码学证明给区块打时间戳该证明表明“自上一个证明以来已过去某段时长”。所有被哈希进证明的数据确定性地发生在该证明生成之前——这就是“历史”的含义。节点随后把新区块广播给验证者验证者可以独立核验这些证明。关键性质区块到达验证者的顺序可以是任意的甚至可以在多年后被重放同步保证依然成立。正是这种可靠的时间同步保证让 Solana 可以把“区块”进一步拆分成更小的交易批次称为entry。entry 在“区块共识”形成之前就实时流式地发给验证者。需要特别说明的是术语口径从源码实现看Solana 在技术上从不发送一个整体的block对象文档使用该词只是为了描述“验证者投票以达成确认confirmation所针对的 entry 序列”。这样定义后Solana 的确认时间才能与基于区块的系统做同口径比较。当前实现把 block time 设定为 800ms这正是上述拆分与实时流式下发的直接收益。Entry 实时流与乐观处理在底层entry 的生成速度取决于领导者能多快地把一批有效交易封装成一个 entry领导者将有效交易批次实时流式推送给验证者验证者远早于投票时间点就开始处理这些 entry——即乐观处理optimistic processing由于处理早已完成从“收到最后一个 entry”到“节点可以投票”之间实际上没有延迟若最终共识未达成节点直接回滚自身状态。文档明确指出这种乐观处理技术在 1981 年就被提出称为乐观并发控制Optimistic Concurrency Control。它同样可以映射到区块链架构集群对某个代表“截至某区块高度的整本账本”的哈希进行投票在 Solana 中这个哈希的实现非常直接——就是最后一个 entry 的 PoH 哈希。换言之投票对象与同步对象是同一个哈希链的末端值验证与投票共享同一条数据路径。源码印证PoH 哈希链如何生成哈希链核心Poh结构PoH 哈希链的核心实现位于 entry/src/poh.rs。Poh结构维护当前哈希、已消耗哈希数、每 tick 哈希数hashes_per_tick以及 tick 计数等状态对外提供三个基本操作// entry/src/poh.rs节选 pub fn hash(mut self, max_num_hashes: u64) - bool { // 串行自哈希直到达到本 tick 的预算返回 true 表示需要 tick() for _ in 0..num_hashes { self.hash hash(self.hash.as_ref()); } ... } pub fn record(mut self, mixin: Hash) - OptionPohEntry { // 将应用数据mixin混入哈希链产出带 num_hashes 的 entry self.hash hashv([self.hash.as_ref(), mixin.as_ref()]); ... } pub fn tick(mut self) - OptionPohEntry { // 完成最后一次哈希产出空 entrytick推进 tick_number self.hash hash(self.hash.as_ref()); ... }三个操作恰好对应文档描述的两类对象record(mixin)生成携带数据的 entry——任何应用观察到的数据都被哈希进链因此能“证明历史”这些数据确定性地存在于其后哈希之前tick()生成空 entrytick——纯时间流逝度量不含交易。值得注意的约束当本 tick 的哈希预算只剩最后 1 个哈希时remaining_hashes 1record()会返回None拒绝写入必须先tick()。这条规则保证了每 tick 的哈希数严格等于配置值hashes_per_tick使 tick 时长与哈希次数之间的换算关系精确可验测试test_poh_record_not_permitted_at_final_hash见 entry/src/poh.rs 测试模块专门覆盖了这一边界。此外该文件还提供两个用于标定时间参数的工具函数// 测量机器上产生 N 次哈希的耗时 pub fn compute_hash_time_ns(hashes_sample_size: u64) - u64 // 按目标 tick 时长反推该机器应设置的 hashes_per_tick pub fn compute_hashes_per_tick(duration: Duration, hashes_sample_size: u64) - u64这解释了“时间”在 PoH 中的真实语义它不来自墙钟而是来自可验证的串行哈希次数。不同算力机器通过compute_hashes_per_tick按本机哈希速率换算出等价的每 tick 哈希数从而让 tick 在时间轴上对齐。生产循环PohService的 tick 生产者tick 与 entry 的持续生产由 poh/src/poh_service.rs 中的PohService驱动它在名为solPohTickProd的独立线程中运行并根据PohConfig定义于 sdk/src/poh_config.rs选择两种模式全速模式hashes_per_tick已配置主网默认路径线程进入紧循环tick_producer尽可能快地自哈希。为保证缓存友好会用core_affinity把该线程固定到专用 CPU 核默认核 0见DEFAULT_PINNED_CPU_CORE。核心调度逻辑在record_or_hash中若收到记录请求交易批次持锁期间背靠背连续 record把已排队的交易一次性打进链中否则按hashes_per_batch默认DEFAULT_HASHES_PER_BATCH 64为一批地自哈希每批检查一次记录通道每批哈希后用Poh::target_poh_time(target_ns_per_tick)计算“理论理想时刻”若落后于该时刻则继续哈希追赶若超前则释放锁后忙等到理想时刻再恢复哈希——这就是把哈希速率“节流”到目标 tick 时长的实现批大小取 64 的注释解释了权衡过小会拖累 PoH 哈希速率过大则因与哈希循环的锁竞争降低记录交易的速度。低功耗模式hashes_per_tick未配置常见于本地测试集群low_power_tick_producer不再自哈希而是在target_tick_duration到期时调用poh_recorder.tick()产出 tick若还配置了target_tick_count则产满指定 tick 数后自动退出short_lived_low_power_tick_producer。目标时长的计算还包含一项工程修正target_ns_per_tick会在 tick 时长基础上减去TARGET_SLOT_ADJUSTMENT_NS50ms按每 slot tick 数均摊的调整量用于吸收 PoH 生成之外写锁、entry 分发等的处理开销避免 slot 实际时长持续漂移。上述结构印证了文档的关键论断entry 的下发节奏只受“领导者多快能把一批有效交易打包进 entry”的限制——哈希线程与记录通道解耦交易到达即被连续record入链并产出 entry 下发而 tick 只在哈希预算耗尽时发生。PoH 与可验证延迟函数VDF的关系文档对 PoH 与 VDFVerifiable Delay Function可验证延迟函数的差异有明确的历史与技术表述时间线PoH 于 2017 年 11 月首次由 Solana 提出用于区块链场景次年 6 月斯坦福出现了描述类似技术的 VDF 工作。验证速度VDF 的期望性质是验证极快而 Solana 对延迟函数的验证耗时与生成耗时成正比验证需要重放同等长度的哈希链。文档坦承即便分摊到 4000 核 GPU 上这对 Solana 来说只是“足够快”从算法复杂度角度看并不快VDF 原作者也指出 Solana 的方案不应被称为严格意义的 VDF。Solana 的立场是VDF 一词应代表“可验证延迟函数”这一类别而非仅指具备特定性能特征的子集在争议解决前Solana 继续称自己的应用特化延迟函数为 PoH。数据混入带来的双面性VDF 只用于度量时长而 PoH 的哈希链会混入应用观察到的任意数据。这一方面让数据“证明了历史”数据确定性地先于其后哈希存在另一方面也意味着应用可以通过改变数据何时被哈希来操纵哈希链。因此 PoH 链不适合做随机性来源——不含数据的 VDF 则可以。一个具体体现Solana 的领导者轮换算法见 docs/src/consensus/leader-rotation.md只从 VDF 的高度tick 高度一个单调递增计数器派生种子而不使用该高度处的哈希值本身从而规避了数据操纵对随机性的影响。PoH 与共识机制的关系文档给出了一个重要的边界声明Proof of History 本身不是共识机制。它的作用有两层提升 Solana 的 Proof of Stake 共识的性能提升数据平面协议如 entry 的流式传输与验证的性能。也就是说PoH 解决的是“时间戳可信 顺序可验证”这一同步问题真正的选择权哪个分叉胜出、何时达成确认由 PoS 投票机制完成。entry 上的乐观处理 未达成共识则回滚正是把“共识裁决”与“交易执行”解耦的桥梁。若想进一步理解投票与分叉如何在 PoH 之上形成确认可结合同目录文档 docs/src/consensus/commitments.md 与 docs/src/consensus/leader-rotation.md 阅读leader 轮换文档定义了 slot 由 T 个 tick 组成、epoch 为 leader schedule 的生命周期而 slot 时长正是 800ms block time 的组成部分。小结Solana 的同步单位不是大区块而是带 PoH 密码学时间戳的entry区块只是验证者投票确认的 entry 序列当前实现 block time 为800ms。PoH 的时间语义来自串行哈希次数而非墙钟Poh::hash / record / tickentry/src/poh.rs构成哈希链hashes_per_tick按机器哈希速率标定PohServicepoh/src/poh_service.rs以独立线程持续生产 tick交易到达即被连续 record 成 entry 实时下发。验证者通过乐观处理1981 年提出的乐观并发控制思想在投票前完成交易执行未达成共识则回滚从而把“收完最后 entry”到“可投票”之间的延迟压到近似为零。PoH 是应用特化的 VDF验证耗时与生成耗时成正比且因混入应用数据而不能作为随机性来源领导者轮换只取 VDF 高度而不取其哈希。PoH 不是共识机制而是提升 PoS 共识与数据平面性能的同步基础设施。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
