Solana 怎么决定哪些交易并行执行？写锁冲突与单账户限速拆解

同一时刻的 Solana 上，有人觉得网络堵得发不出交易，有人秒级落块，差异往往不在”整条链满没满”，而在你的交易锁住了哪个账户。这篇把这条判定链拆干净：从交易怎么声明账户，到调度器怎么排并行，再到费用为什么按账户分区——最后给出核对字段的方法，数据侧的费率市场可以接着看Solana 费用市场的分区逻辑。

交易先声明”我要动谁”

官方文档对交易结构的描述很直白：一笔交易包含一条或多条指令、授权这些变动的账户签名，以及一个近期区块哈希；所有指令作为整体执行，任何一条失败，整笔交易回滚。关键在于消息部分会列出全部被触及的账户，并给每个账户标注两个属性：是否签名者、是否可写。版本化交易还能通过查找表压缩这份清单，但本质不变——执行之前，节点已经知道你要读哪些账户、写哪些账户。

调度器按写冲突排车道

调度器的规则建立在这份声明上：区块内的交易可以并行执行，但”只基于被写入的账户”决定谁能并行。两个交易没有任何共同的可写账户，就各走各的车道；哪怕只是共同读一个行情账户，也不妨碍并行；一旦都要写同一个账户，就必须排队。官方文档的例子说得很直白：一个热闹的市场账户不会拖住与之无关的交易，因为那些交易根本不动它的可写状态。换句话说，Solana 的拥堵天然是局部的——拥堵属于被反复写入的那个账户，而不是整条链。

单账户限速与本地费用市场

车道齐了还要防止一个账户把路吃光。官方文档同时描述了这个约束：对单个账户在一个区块内被写锁定的次数设有上限，以避免本地费用市场被某一个账户挤爆。配合按账户分区的优先费，效果是每个热点账户自己形成一个小型拍卖场：想挤进同一账户的交易用优先费竞争，挤不进别的账户的交易不受它涨价的波及。基础费一侧的规则见基础费一半销毁、优先费全归出块者那篇，这里不重复。

消息的另一半：区块哈希与过期窗口

写锁之外，官方文档的约束清单里还有一条常被混进”拥堵”的：交易的近期区块哈希有 150 个槽位的有效窗口，超出后节点不再接受重发。也就是说，一笔没落块的交易不是永远躺在池子里等位，它在时间轴上是有寿命的——排查”发出去没动静”时，先分清是写锁排队导致长期排不进去，还是干脆已经出了有效窗口需要带新区块哈希重签，两类问题的处置完全不同。官方文档对广播策略的口径也印证了这一点：在有效窗口内反复重发、直到落块或过期为止，本就是客户端的正常动作，而不是网络异常的信号。

作为使用者怎么核对

按字段核对，而不是按”网络卡不卡”的感觉核对。第一步看交易消息里的可写账户清单：它是否包含了某个热点平台的状态账户，比如高频兑换都在写的那一个池。第二步用文档提到的 getFeeForMessage 这类接口对消息本身询价，比较”同样的指令、换一个冷门状态账户”和”挤在热门账户”两种情形的费用差。第三步看失败原因：写冲突导致的排队与计算预算超限是两类问题，前者的解法是错开账户或提高优先级，后者是压缩计算量。版本化与开关类变更如何在全网生效，可以按功能开关与 SIMD 投票门控的方法核验集群状态。

边界与风险

账户声明只覆盖交易执行期内的锁定；交易之间在更长时间尺度上仍会通过计算预算、账户租金等维度互相竞争资源，“不共享写账户”不等于”完全互不影响”。动态参数以官方文档与链上核验为准。本文为机制说明，不构成投资建议。