Sealevel 怎么决定谁能同时跑？Solana 并行执行的账户读写集规则

并行的前提不是算力，是一条约定

以太坊的 EVM 逐笔执行交易，同一区块里的交易有严格的先后语义；这是它串行性能天花板的技术根源。Solana 官方技术博客介绍其运行时 Sealevel 时把对比点放在这里：EVM 等单线程运行时的执行引擎一次只让一个合约改状态，而 Sealevel 要把大量互不相干的事务调度到多个 CPU 核上同时跑。博客的原话是，能不能并行，取决于一件比算力更基本的事——执行之前是否已经知道每笔交易会读哪些状态、写哪些状态。

这个前提在 Solana 的交易格式里被制度化：每笔交易由若干指令组成，每条指令必须提前声明它要访问的全部账户，并标明每个账户是可写还是只读。官方开发者文档把这层关系说得非常直接：只要两笔交易不写同一个账户，它们就可以同时执行；多笔交易只读同一个账户也不算冲突。调度器因此不需要猜测、不需要回滚，拿到一个区块先按账户读写集排一次序，不重叠的交易并行下发，同一程序对大量账户的重复调用还能借向量化指令批量推进。这套接口被官方博客比作操作系统里 readv 这类分散聚合式驱动接口：先声明全部读写缓冲，内核才能预取和并发。

约定的代价：把冲突摊到交易构造里

声明越静态，构造交易的约束越硬。官方交易文档列出的限制相当具体：一笔交易总大小上限 1232 字节，可引用的账户数量执行层限制 64 个（放宽到 128 的特性开关默认不启用），顶层指令加嵌套调用合计最多执行 64 条指令，每个签名收 5000 lamports 基础费。想访问的对象越多、程序间嵌套调用越深，交易结构就越受这些静态声明的挤压，批量账户通常要靠地址查找表压成索引引用，细节见 Solana地址查找表ALT怎么读？；这也解释了 Solana 交易是怎么组装的？签名、消息与指令表的 1232 字节 强调”先画账户清单、再拼指令”的原因：清单就是调度器的全部情报，漏声明一个账户，程序连碰它的资格都没有。

并行的另一面是热点问题：并行度来自读写集的不重叠，当大量交易同时写同一个账户——热门兑换池、活跃市场账户——这部分交易的写集彼此冲突，只能排队串行，运行时并行度再高也消不掉账户级的冲突点。同一账户允许无数只读并发，却只容得下依次执行的写，这是 Solana 性能叙事里最容易被忽略的结构性细节：链的吞吐上限不是常数，而是全体交易读写集重叠程度的函数。

观察者视角：链上怎么验证”并行”这件事

其他生态解决同一问题的路线不同：以太坊在推进块级访问清单这类提案，希望在执行前收集每笔交易的读集与写集来解锁并行，思路拆解见 区块级访问清单 BAL 是什么？以太坊并行执行靠哪张地图；Move 系公链要么走对象模型分流所有权，要么走乐观推测执行重试冲突。Solana 的特点是把声明放在协议最前端，交易签名时读写集已经锁死，程序执行中途不允许临时触碰声明之外的账户。

从可观察证据看，这种设计与串行链的差别体现在两处。其一，同一区块内并行交易之间不存在可观察的执行顺序语义，账户最终余额是确定的，但谁先谁后对结果没有影响，链上数据服务展示的先后只是打包顺序，分析时要谨慎解读交易在区块内的位置含义。其二，冲突会留下可检索的失败痕迹：调度器挤不下的交易可能因资源占用而失败，客户端表现为需要重试的错误类别，链上统计里这类失败与程序逻辑报错是两类信号，费用规则上两者都收基础费。把这两类信号混在一起，就会高估网络的拥堵程度。本文为机制说明，不构成任何投资建议。