以太坊之外的一批公链把出块顺序交给一张图而不是一条线，Sonic 是其中把「异步」写进共识定义的那一条。它的官方文档把共识机制拆成三个词：权益证明、有向无环图、异步拜占庭容错。这三个词各自解决一个不同的问题，合起来才构成 Sonic 的出块路径。本文按官方文档和技术论文的说法逐层拆开，并说明这种设计把代价移到了哪里。
从 PBFT 到 ABFT：换掉的是等待方式
Sonic 文档先交代了它创新的起点。实用拜占庭容错（PBFT）里，节点就同一个状态来回广播消息、彼此确认，最后在同一高度上达成一致。文档指出 PBFT 早年的致命弱点是女巫攻击——只要攻击者能廉价地开出足够多的节点，就能淹没投票，因此比特币用工作量证明给参与加了成本，后来的链用权益证明让参与者质押有价代币，Sonic 用的就是后者。
关键差别在于「同步」这两个字。Sonic 文档说明，异步拜占庭容错（ABFT）下节点可以各自独立地达成共识，不需要按顺序交换最终区块，也不需要按顺序把别人造的块并入自己的链；区块之间的交换本身就是异步进行的。文档把它和比特币的中本聪共识对照：后者区块顺序生产、最终性是概率性的、要多等几个确认才算数。换言之 ABFT 省掉的不是投票，而是「等所有人都到齐再往下走」这一轮的等待。
DAG 承担了什么
第二个词是有向无环图。Sonic 文档给出的定义很朴素：有向边只朝一个方向流，无环意味着沿着边走不回到起点，合起来即 DAG。在这个共识里，一个装着交易的事件被表示成图上的一个顶点，边表示事件之间的关系，可以读作「谁引用了谁」，因而隐含了加入次序。文档特别强调事件可以被并发地创建并加入 DAG，不需要按特定顺序排列，这正是它相对顺序出块链在吞吐上的来源。
落到工程形态，Sonic 采用每个验证者各自维护一份本地区块 DAG 的写法：验证者把收到的交易批量装进事件区块，作为顶点加进自己的 DAG。文档说明在创建新事件区块之前，验证者必须先完成当前事件区块里交易的验证，以及异步交换期间从别人那里收到的那部分事件区块里交易的验证；新事件区块造好之后再通过同一套异步事件通信发给其他节点。节点之间交换的不只是自己的事件，还包括自己刚收到的那些，信息因此像八卦一样在网格里扩散——这就是同一篇文档里的传播模型。
谁被点名：Atropos 与主链
异步八卦带来的问题是「什么时候算定了」。Sonic 文档给出的答案是把某些事件区块提升为主链的一部分：当足够多的节点都知道了某个事件区块，它就成为根事件区块；根事件区块在最终共识中变成 Atropos 区块；Atropos 区块构成一条主链，每个验证者都保存并更新这份主链副本，以便在处理新事件区块时快速回查历史。文档对这套机制的定位很清楚——DAG 负责让验证者异步地确认交易以获得速度，而一条最终区块链负责把已定序的交易不可篡改地存下去。
「谁知道了某件事」这个判断的具体算法来自 Fantom 时代的 Lachesis。Sonic 文档在技术页末尾直接指引读者去读 Lachesis 论文，说明它的设计是 Fantom Opera 共识的延续；论文（arXiv:2108.01900）里给出的构件包括用 Lamport 时间戳做事件区块的拓扑排序、把本地历史切成检查点（epoch）以优化 DAG 的存储与处理，以及用质押权重来限制参与权。需要提醒的是：论文描述的是协议族的机制，具体参数、权重口径和当前实现细节应以 Sonic 当时版本的官方文档为准，本文不复述任何性能数字，因为这类数值随版本变动很快。
这套设计把账记在哪儿
异步与并发换来的收益，同样带着两处必须看清的代价。其一是「确认」的含义：在 ABFT+DAG 的写法里，一笔交易被写进某个事件区块、被足够多节点知道、被 Atropos 盖章，是三件事，中间存在时间差。核对到账时应当问清自己看的是哪一档，而不是简单套用「几个确认」的习惯。其二是信任边界落在质押权重上：安全依赖三分之一以下验证权失效这一类假设，节点选择对等、质押分布和 Atropos 判定的实现都会影响实际表现。相关链的当前状态、参数和已知限制会随升级变化，本文只按官方文档描述机制，不构成对任何链安全性或性能的判断，也不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。