顺序执行的区块链有一个尴尬的天花板：单核再快，也只是把一条交易流水线跑得更快。Sei 把希望押在多核 CPU 上——让一批交易真正同时在几个核心上执行，跑出来要和顺序执行逐字节一致。它的并行化引擎给出的答案是乐观并发控制：先猜每笔交易会碰哪些状态，猜对了大家一起跑，猜错了再重跑。本文按官方文档拆解这套估算、检测与重放的分工。
先估计，再执行：乐观并发控制的起点
传统数据库的乐观并发控制（OCC）与悲观方案的分界在于是否先锁资源。Sei 引擎选择不锁：执行前由访问控制模块和各类依赖生成器为每笔交易预测一份读写集，即”预计写集”。普通转账的预测可以很精确——A、B 两个账户的余额读写一目了然；复杂合约调用则只能给出更宽的估计，分析器会参考合约地址与存储布局、被调用的函数选择器、入参，甚至历史上相似调用的访问模式，附带置信度标注。这份估计是调度的输入，不是执行结果本身。
预处理阶段还负责把原始字节变成结构化的交易对象、跑签名与费用等前置校验、按消息类型分组，并把预言机喂价这类关键交易标记出来优先处理。
工作池、缓冲执行与真实轨迹
调度器按预计写集把互不冲突的交易编组，用图结构算法与前瞻减少冲突概率，再把它们分派给一组动态调整规模的工作协程。关键点在于缓冲执行：工作线程把全部状态写入临时缓冲而不是主状态库，中间结果在冲突判定完成前彼此隔离。执行过程中系统同时记录真实读过的和写过的键，这些运行时轨迹既用于冲突判定，也会回流给依赖估计系统改进下一轮预测。
冲突什么时候发生：RAW、WAR、WAW 与确定性重放
冲突的定义是标准的：一笔交易读了另一笔并发交易写过的键（RAW），写了对方读过的键（WAR），或多笔写同一个键（WAW）。检测器用哈希结构跟踪状态访问，用布隆过滤器做快速初筛，靠到达顺序的时间戳保证排序确定。检出冲突后，引擎把冲突组从临时缓冲里撤掉，按确定性顺序串行重执行——系统级交易优先级最高，预言机更新次之，普通交易回到区块内原始顺序。重执行组与已成功交易保持隔离，且重执行自己的读写集会被继续追踪，防止级联冲突。官方文档强调的结果是：并行执行收敛后的状态与从头顺序执行完全一致。
兜底与存储层的配合
并行不是必赢的赌局。当某个区块冲突率高到并行无法推进时，引擎丢弃这次并行尝试的全部状态改动，把整批交易退回顺序处理，保证链在任何最坏情况下都能出块。存储层 SeiDB 为这套机制提供了多版本并发控制、快照隔离与快速回滚——投机状态能被廉价丢弃，正是乐观执行敢先跑再查的底气。
对开发者的可观察推论是：状态越分散，并行收益越大。Sei 文档在 Giga 路线的描述里同样把”按地址隔离的状态”列为比共享全局状态更利于并行的写法。普通转账这类彼此无关的交易最容易吃到多核红利，官方文档给出的分类对比里，简单转账与 ERC-20 转账的吞吐提升幅度明显大于交互复杂的合约调用——后者估不准、冲突多，重执行把并行省下的时间又还了回去。运维视角下还有两个值得盯的信号：一是某笔交易结果不符预期时，先确认它是否与同块内热点键交易相撞后被安排了重执行，重执行的语义与顺序执行等价，不会改变结果只影响耗时；二是整块兜底触发时，该块处理时间会向顺序执行靠拢，监控上表现为延迟毛刺而不是错误。边界也要讲清楚：并行只是执行层的优化，共识与最终性规则不因它改变，任何节点复核时仍按确定顺序重放即可得到相同状态。本文内容为机制解释，不构成任何投资或技术选型建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。