一笔支付与一笔并行合约调用都先进入 Solana 账户模型，但能否并行执行取决于实际读写账户集合，而不是“所有交易天然并行”。PoH 提供可验证的顺序/时间参考，历史 Tower BFT 与 PoS 投票共同处理共识；PoH 不独立决定合法历史和最终性。区块链（41）：Ethereum 从 PoW/EVM 到分离执行、权益共识与 blob中 EL/CL 的分工不能原样套在 Solana 的验证者流水线上。

flowchart LR
  T[交易/账户读写声明] --> P[传播与调度: 等待顺序]
  P --> H[PoH: 可核验顺序构件]
  H --> X[账户锁与执行: 冲突时串行]
  X --> V[PoS 权重 + 历史 Tower 类投票]
  V --> S[状态/区块数据/同步]
  V --> A[Alpenglow 路线: Votor/Rotor 状态待核]

早期设计着力减少排序和执行等待，但账户声明错误或过度共享的热点状态仍会阻止并行；这是一种应用数据结构约束，不可用网络宣称的 TPS 跳过。客户端多样性可降低单实现故障相关性，但多实现必须共享交易/状态共识语义，且实际部署份额需核验。Alpenglow 的 Votor 和数据传播路线 Rotor 是不同角色；工程发布、测试网使用和主网激活不能互相代替。由于目前拿不到官方状态页与 release 交叉证据，不把 Alpenglow 写成已在主网启用，也不把 Mysticeti 等其他链的机制混入。

订单热点如何穿过并行执行

把每个订单放在可独立写入的状态账户时，两个不相交订单可以在运行时各自检查读写集合；把所有订单余额和序号塞进一个全局可写账户，则每次结算都争用这个状态。即便网络传播和 PoH 顺序都更快，写写冲突仍使实际更新排队。观察性能时应同时测“独立账户”和“单热点账户”的失败/重试与最终确认，不把宣传吞吐当订单并行吞吐。交易是否完整声明依赖哪些账户，也必须由冻结版本的运行时规则判断。

先只推导冲突关系：用 R(T)、W(T) 表示交易 T 声明的只读和可写账户。两个交易的写集合分别不能与对方的读或写集合相交，即 W(A) ∩ (R(B) ∪ W(B)) = ∅ 且 W(B) ∩ (R(A) ∪ W(A)) = ∅，才允许模型判为“无账户访问冲突”。这只是必要的访问分析，不保证真实执行一定并发成功，尤其不决定网络调度、交易有效性或成交顺序。

examples/blockchain/models/account_conflicts.py 用这个谓词比较三组合成交易：共享一个只读程序账户、分别改写订单 A/B 时，谓词允许并行；两笔都改写 global-counter 时，谓词拒绝；读同一订单可并行，但与写该订单的操作冲突。运行 python3 examples/blockchain/run_account_conflicts_evidence.py，两项测试及源码 SHA 见 examples/blockchain/evidence/42/20261005T132559Z-3c09548e/。这个程序既不会执行 Solana 指令，也不处理账户锁、地址查找、费用或投票；没有真实客户端吞吐测量。与此相关的迁移代价是：为减少热点把状态拆成独立订单账户，必须重新核对原先由全局序号维护的唯一性和读取一致性，不能为了并行放弃业务不变量。

架构变化还要问迁移后的故障归属：如果换了投票或传播算法，验证者如何根据旧历史同步状态，新旧客户端是否会对同一有效块给出不同解释，钱包何时能将支付风险从观察降为已满足其策略。Alpenglow 的传播设计与投票设计需要分别读取规范、测试网记录和主网激活证据；未取到这些资料，本篇不能给它们当前完成状态。

练习一：交易 A 只读 program、写 order-a，交易 B 只读 program、写 order-b；若 B 还要写 A 的订单，冲突关系怎样改变？答案：最初两个写集不相交，模型允许重叠；改动后 B 的写集命中 A 的写集，必须协调顺序。练习二：证明两笔事件有 PoH 顺序后，能证明提议者没有签错区块吗？答案：不能，仍需共识投票、合法性与攻击预算。实际交易账户锁、客户端多样性与 Alpenglow 激活状态 NOT_VERIFIED / NOT_RUN。

可迁移原则：将时间序列、数据并行和共识三种优化分别画图。参考：Solana 官方架构、Alpenglow 升级页（需按访问日期重新查测试网/主网状态与客户端 SHA）；导航：区块链（41）：Ethereum 从 PoW/EVM 到分离执行、权益共识与 blob · 42 · 区块链（43）：Cosmos 与 Avalanche 是两条不同的应用链路线。