Sonic区块链技术调研

 

Sonic 是由 Fantom 团队孵化和主导开发的新一代高性能 Layer1 区块链，是对 Fantom Opera 网络的继承与重构。

Sonic区块链（原Fantom Opera升级版）通过多项核心技术革新实现了“最快EVM兼容链”的目标，其高性能源于以下四层架构的创新设计：

一、共识机制革新： DAG结构与异步拜占庭容错（aBFT）

1.  Lachesis共识算法（SonicCS 2.0）

1.1 并行Event事件处理

Sonic 网络采用基于有向无环图（DAG）的Lachesis共识机制，支持验证节点并行生成并广播事件（Event），每个事件可以包含多个交易（Transaction）。与传统区块链严格线性区块结构不同，Sonic通过事件图（Event DAG）来表达各节点生成事件的因果顺序和依赖关系，使交易执行与事件生成可以在多个节点间并发进行，显著提高系统吞吐量与响应能力。

每个节点独立地将自身生成的事件（包含本地用户提交的交易）链接至其已知的前序事件，通过结构性引用构建局部DAG。在事件被广播并被其他节点接收后，各节点通过Lachesis共识协议异步地对事件进行排序与确认。通过这种方式，网络无需依赖严格同步的出块过程即可实现共识，降低了共识延迟。

 

 

1.2 每个事件的 Lamport 时间戳

在 Lachesis 中，每个事件有一个 Lamport Clock 值，用来表示它在整个 DAG 中的“逻辑时间”。

✅ 核心规则如下：

1.  每个节点维护一个本地计数器（初始为0）。

2.  本地事件发生时：计数器 +1。

3.  发送消息时：把当前计数器值一同发送出去。

4.  接收消息时：接收者将自己本地计数器设为 max(本地计数器, 收到的计数器) + 1。

这样，每个事件都被赋予一个递增的逻辑时钟值，从而我们可以建立事件之间的“happened-before”关系（→）。

1.3 Root 的产生

每个验证节点持续创建自己的 Event，并将最近收到的其他节点 Event 的 hash 引用进来，构成一个 DAG。

当一个新 Event 能够通过其引用路径“看到”（i.e. 通过引用链可达）超过 2/3 的验证节点的最新 Event 时，它就被标记为一个 Root Event。

● ✅ 无需额外投票；

● ✅ 是基于本地信息和引用关系自动判断出来的；

● ✅ 所有 honest 节点最终会选出一致的一组 Root。

1.4 Clotho 的选取

Clotho 是一组候选的最终共识 Event，它从 Root 中选出。

● 某个 Root 被后面的一些 Root “看到”，当这个 Root 被2/3 的 Root 引用时（即“被看到”），它就成为一个 Clotho 候选；

● 这实际上也不需要发起专门的 P2P 投票消息，而是通过 DAG 中的引用信息（事件之间的连线）隐含完成。

● ✅ 所以 Clotho 的产生也是“隐式投票”，不依赖额外通信；

● ✅ 是节点本地根据 DAG 分析得出；

● ✅ 每个节点都会得到相同的一组 Clotho（最终收敛）。

 

1.5 为 Clotho 分配共识时间戳，变为 Atropos

一旦一个 Clotho 候选在多个节点中都被确认：

1.  各个 honest 节点 都会试图为该 Clotho 事件选出一个“时间戳”

a.  👉 这个时间戳不能随便选，而是通过一种确定性的方法得出：观察引用了该 Clotho 的 Root 所处的时间；

b.  从这些 Root 所报告的时间中取中位数作为该 Clotho 的时间戳；

c.  这个中位数时间就是该 Clotho 事件的 Atropos 时间。

2.  如果多个 honest 节点都为该 Clotho 事件分配了相同的中位时间戳，那么它就变成了 Atropos。

3.  所有节点会最终对这些时间戳收敛，因此每个 Clotho 最终确定是否晋升为 Atropos，以及其确定的共识时间。

1.6 SCC（Sonic Certification Chain）区块打包

一旦某个事件单元（event）在 DAG 中被选为 Atropos，意味着它在整个 DAG 中的相对顺序已经确定，可以用于驱动全局有序链（SCC）的构建。

在 DAG 共识中，事件是异步并发生成的，而 SCC 出块的目的是将这些 DAG 事件线性化，生成一个全序的区块链序列，以供 EVM 执行和状态转换使用。出块流程如下：

步骤一：事件排序

● 节点根据 DAG 共识确定的 Atropos 序列，按全局时间戳或 DAG 层级进行排序。

● 每个 Atropos 事件背后可能包含多个普通事件（event block），这些事件也被排序。

步骤二：构造区块

● 节点从排序后的事件中提取交易（transactions）。

● 将交易按顺序打包进一个 SCC 区块，形成与传统区块链类似的数据结构（包含 transactionsRoot, receiptsRoot, stateRoot 等）。

步骤三：执行交易

● 使用 SonicVM 对区块中的交易进行顺序执行，计算新的世界状态（state）和状态根（stateRoot）。

● 如果存在并行执行机会，也可能在 VM 内部启用局部并发（详见 SonicVM 的 optimistic exec 模式）。

步骤四：广播新区块

● 构造好的 SCC 区块通过 gossip 协议或定向传播向其他节点广播。

● 区块中包含 Atropos 编号（epoch+index）用于索引与验证。

1.7 共识流程梳理

通过Lamport时间戳与中位时间计算实现事件的全局排序，确保异步环境下的强一致性，交易确认时间压缩至 0.7秒 。

以下是事件在 DAG 中从普通 Event 成为 Atropos 的过程（这是 Lachesis 的核心共识流程）：

1.  所有节点不断生成事件并加入 DAG；

2.  每个事件广播后会被其他节点的事件引用，当被超过⅔节点引用，它就晋升为 Root；

3.  一些 Root 事件被判定为 Clotho 候选（通过观察引用关系和 Frame 层）；

4.  多数节点投票确认 Clotho；

5.  被投票确认的 Clotho 最终晋升为 Atropos；

6.  所有节点根据 Atropos 的时间戳对所有已确认事件排序，形成一个全局一致的顺序（并打包为 Block）。

2 为什么 Atropos 能加快交易确认速度？

1.  异步确认、并发推进：

a.  不像 PBFT、HotStuff 等共识算法需要几轮广播和同步锁，Lachesis 是 异步推进的，事件只需被足够多节点引用，就可以被选为共识基础；

b.  因此没有「共识回合」，确认速度更快。

2.  局部达成共识后即刻确认：

a.  某个 Event 一旦成为 Atropos，其祖先事件也就被视为“已共识”；

b.  节点无需等待所有事件同步完成，只要 DAG 的一部分稳定即可快速确认。

3.  逻辑时间戳（Lamport Clock）+ DAG 结构：

a.  节点无需强制同步“谁先谁后”，而是通过事件引用关系 + Lamport 时间进行排序；

b.  确保交易顺序唯一确定，避免因链重组或分叉导致确认回滚。

4.  Finality 是 deterministic 的（非概率）：

a.  一旦 Atropos 事件被选中，其祖先交易就不可逆了，无需额外等待“6个区块”或“重组窗口”。

 

 

二、存储引擎优化： Carmen数据库（SonicDB）

Sonic 的存储引擎 CarmenDB 采取了扁平化、非 Merkle 化的设计方式，有几个关键特性：

1. 取消传统 Merkle 状态树

● 不再维护类似以太坊中的 Patricia Merkle Trie，这种树状结构的最大特点是便于验证状态哈希（即根哈希）用于共识或轻节点验证（SPV）。

● Sonic 认为在一个并行异步的 DAG 架构下，这种传统的「全局状态快照」成本高、延迟大，反而拖慢吞吐量，因此摒弃它。

2. 不支持轻节点（SPV）

● 正因为没有了全局状态树，也就没有可验证的根哈希，因此无法像比特币或以太坊那样支持 SPV（简化支付验证）节点。

● Sonic 设计更偏向于“全节点+高性能”，而非轻节点或移动端友好。

状态快照 + 标签化数据定位

✳️ LiveDB（当前状态数据库）

● 只保留最新状态数据，不保留历史。

● 每当交易改变了某账户的状态，其旧状态会被「修剪掉」而不是保留（Live Pruning）。

● 这样可以大幅压缩数据库体积（官方宣称从 2TB → 300GB）。

✳️ ArchiveDB（历史归档数据库）

● 如果有节点或外部需求（比如审计、区块浏览器），可以选择将历史数据持久化在 ArchiveDB 中。

● 这部分数据是“冷存储”，对实时共识无影响。

✳️ 标签化 + 扁平数据

● 不用路径散列树状结构定位数据（如 keccak256(keccak256(key))）。

● 而是用类似「标签/命名空间」直接映射，例如 account:0xABC123.balance → 100。

● 这种方式检索速度更快，减少无谓路径遍历，提高交易执行效率。

 

三、执行层创新： SonicVM虚拟机与即时编译（JIT）

为了突破传统解释型虚拟机的性能瓶颈，SonicVM 引入了多项执行层级优化手段：

1. 即时编译（JIT, Just-In-Time Compilation）：

○ 在合约执行过程中，SonicVM 会将智能合约的 EVM 字节码实时编译为宿主机器架构下的机器码（如 x86_64、ARM）。

○ 避免逐条解释执行带来的指令解析与上下文切换开销，大幅提升执行效率。

○ 执行速度比传统 EVM 提升数倍，为支持高并发高 TPS 奠定基础。

2. 超级指令（Super Instructions）：

○ 将常见操作序列（如：SHA3 哈希计算、字符串拼接、内存复制等）合并为原子级“超级指令”。

○ 这些 Super Instructions 预先编译为本地高效指令，减少指令跳转与堆栈操作，极大提升 CPU 执行效率。

○ 对于热点合约代码块，支持动态优化路径，进一步压缩执行延迟。

○ 目标系统吞吐可达 10,000 TPS（当前），未来目标 400,000 TPS。

3. Gas Power 反垃圾机制

为了防止低成本滥发交易对网络造成拥塞，Sonic 引入一种新的资源计费模型：

● Gas Power（气力值）：

○ 每个验证者拥有一个随时间自动恢复的 Gas Power 值，表示其可用的网络操作“能量”。

○ 创建事件（事件是 Sonic DAG 中的核心结构，相当于区块）时需要消耗 Gas Power。

○ 若频繁创建事件，Gas Power 会迅速下降，从而抑制滥用行为。

● 抗 DDoS 机制：

○ 恶意节点无法以极高频率广播事件或发起交易攻击，因为其 Gas Power 会被迅速耗尽。

○ 无需依赖交易手续费（如传统 Gas）来完成反垃圾功能，系统抗压能力更强。

 

 

四、BLS 签名与 SCC

BLS 签名在 Sonic 共识中的应用：SCC（Sonic Certification Chain）

✅ 背景

Sonic 的核心共识机制基于 DAG 拓扑结构，其中事件（event）之间存在因果关系。但最终要落地为区块，需要在 SCC（Sonic Certification Chain） 中进行投票认证，这一过程类似于「Checkpoint」或「Finality Gadget」。

✅ BLS 聚合签名的用法

在 SCC 中，多个验证者节点需对某个候选区块或事件投票，传统方式下需分别广播每个验证者的签名，带来巨大带宽与计算开销。而 Sonic 采用了：

● BLS 聚合签名机制：将多个验证者对某事件的签名压缩为一个签名

● 验证时只需对该聚合签名进行一次验证（而非每个单独签名）

✅ 效果与优势

● 签名聚合效率：原本需要验证 n 次签名，聚合后仅需验证 1 次

● 带宽优化：一个聚合签名仅为 96 字节，远小于传统多签广播

● 节点同步提速：新节点同步 SCC 时验证工作大幅减少

● 性能提升估算：

○ 签名验证性能提升高达 5 倍以上

○ 节点消息体大小下降至原来的 10%～20%

○ 大幅降低高 TPS 情况下的共识延迟和网络拥塞

 

 

💎 性能对比（实测数据）

指标	Sonic	以太坊	Solana
TPS峰值	10,000+	30	2,000-3,000
确认时间	0.7秒	6分钟	2-5秒
单笔Gas费	≈$0.0001	1−10	≈$0.00025
存储效率	提升90%	低	中等

 

💎 结语

Sonic的高性能源于 架构级协同优化 ：

👉 共识层 （DAG并行）→ 存储层 （扁平化压缩）→ 执行层 （JIT编译）→ 跨链层 （安全批处理）

这一技术栈在保持EVM兼容的同时，解决了“不可能三角”中的效率瓶颈，为DeFi高频交易与链游实时交互提供了新范式。不过任然存在如下挑战：

● 节点间拓扑同步压力仍高：DAG 的并行性意味着节点必须高速接收并存储多方事件，且每个事件都需解析、排序、更新状态，I/O 压力巨大。

● 高频并发下状态一致性难度：尤其是 EVM 的全局状态模型会成为瓶颈，如果未来引入并行执行（Parallel EVM），需要重新定义冲突检测与状态隔离策略。

● 轻节点缺失会限制部分场景：如移动端钱包、跨链桥验证等。

● 目标 400,000 TPS 仍未实证，当前 10,000+ TPS 成绩是在受控环境下跑出的，不代表公链开放运行下的持续性性能。