一文快速搞懂 Sei Network v2 有什么亮点

专为交易而生的平行处理公链 Sei Network 于今年八月发行代币并启动主网，引起市场一阵热潮后，Sei Labs 创办人 Jayendra Jog 于近日宣布将推出 Sei v2，将整合 EVM、优化平行处理机制与帐本储存结构。

Sei Network 是什么？

Sei 为交易而生

Sei Network 有明确的市场定位，提供虚拟资产交易的高效环境，虚拟资产除了常见的代币之外，也包含 NFT、社交图谱、游戏道具，借由提供专门交易的底层环境打造最佳的用户体验。

交易不限于加密货币，因此虚拟资产的交易是网络世界最广泛的需求，团队认为最成功的 Web3 应用程式都涉及交易属性：

• 间接交易：大多数链上用户借由使用 Uniswap、OpenSea 进行虚拟资产交易。
• 直接交易：直接受到交易的项目，大多是游戏或 NFT项目，例如 Axie Infinity 或是 BAYC。

因此交易的需求从不消失，是未来 Web3 重要的环节，而要完成最佳交易网络的定位，需要提供高效率的环境，而 Sei 利用平行链处理设计与共识机制做到此目标。

Sei 平行处理机制

Sei Network 主网现已上线 3 个多月，根据官方资料显示，目前网络平均可以达到 20,000 的 TPS 与 390 毫秒的最终确认性，目前团队表示都是业界最有效率的网络，这都有赖于其创新的平行处理机制。

当 Sei 区块链上的交易没有涉及相同的资源 (地址) 时，可以将把所有交易同时并行处理，而不需要排序交易顺序，借此可以提高网络运作效率。

Sei v2 更新方向

看待一个区块链项目，主要有三个评估重点：帐本结构、共识机制、虚拟机。再加上 Sei 特有的平行处理机制，就可以清楚理解 Sei v2 本次的更新内容有什么差异。

创办人 Jayendra 表示 Sei v2 仅是附加新功能，对于现有功能并不会受到影响，用户与开发者无需为此更新执行任何额外操作。

Sei v2 提案主要包含三项更新：

• 支持 EVM
• 优化平行处理机制
• 优化帐本储存结构

本次更新预计将于 2024 年第一季完成。

虚拟机：支持 EVM

原有设计：Sei v1 使用 CosmWasm 虚拟机

Sei 是利用 Cosmos SDK 所建构的，并使用后者提供的组件 CosmWasm 虚拟机。CosmWasm 是专为 Cosmos 生态系统打造的虚拟机组件，底层是 WebAssembly (Wasm) 而得名。使用 Cosmos SDK 所建立的区块链都可以将 CosmWasm 添加到其链中，而无需调整现有逻辑。

WebAssembly 可以支持多种常见的程式语言，包含 Rust、C、C++等等，因此如果是 Rust 开发人员，则可以在 CosmWasm 上轻松编写智能合约，因此 Sei 吸引的是圈外的开发者。

更新重点：Sei v2 将支持 EVM 整合

不过 Sei Labs 团队发现虽然开发人员的参与度高，却失去以太坊虚拟机 (EVM) 生态。EVM 是现有大多产业应用与产品所使用的虚拟机，失去此生态将对于 Sei 现阶段的快速发展造成阻碍，例如现有以太坊项目无法分叉到 Sei 生态。

团队为此更新了专用的代码库 Core Sei Binary，导入了 EVM RPC 与 Geth 节点的专用介面，让 EVM 的交易可以无缝上链到 Sei网络与互动。

选用 Geth 是因为其相对稳定，Jayendra Jog 表示目前有 80% 的以太坊节点使用 Geth，而且支持完整的 EVM 字节码兼容性，代表开发人员可以完全复制其他 EVM 的合约至其上运行。

Sei v2 还将使用 EVM RPC，让用户可以轻松使用 Metamask 等钱包操作，而开发人员则可以继续使用 Foundry、Remix 和 Hardhat 等工具。

因此，Sei v2 将可以让 EVM 和 Cosmwasm 交易之间的产生可组合性。 Sei 的 Geth 有一个预编译器，允许调用 Cosmwasm 合约，而 Sei 的 wasmd 模组也能够反向调用 EVM 合约，将可以让 Sei 的生态内的资产更有价值。

优化 Sei 平行处理机制

原有设计：Sei v1 合约需定义资源范畴

在原本 Sei Network 为了让交易可以平行处理，需要开发人员学习如何「标记合约的资源使用」。

开发人员在 Sei 撰写合约时，需要定义合约可能需要存取的资源与独立性，以便未来当 Sei 执行合约可以快速分辨资源独立性，决定是否要并行交易或是排序交易。

为了并行执行合约，开发人员需要识别在执行过程中需要存取的资源 (包含查询合约)，并将资源范围写成 JSON 的格式上链，无形中对开发人员造成困扰，并增加进入门槛与安全性问题。

更新重点：Sei v2 简化合约平行运行机制

Sei v2 将优化并行处理机制，不再需要开发人员手动定义依赖关系，而是能够自行处理并行化机制，减少了开发人员的负担。

新的平行处理机制会将所有交易统一执行，若发现资源相冲突的情况，则网络会重新检视先后顺序，并再重新执行。

如果交易涉及不同的帐户，例如 Alice 转帐给 Bob，同时 Carol 转帐给 Dave，那么由于没有重叠的依赖关系，本交易将平行处理；如果交易涉及相同的帐户，例如 Alice 与 Bob 都转帐给 Carol，那么需要按顺序重新运行。

不过此设计可能有疑虑，若发生最坏的情况，所有交易都涉及相关性而都需要按顺序重新运行，重新运行这些交易将比原本就按照顺序运行的情况增加 30% 的执行时间。

所幸根据 Ethereum 历史资料，实际上只会有大约 15% 的交易会有资源重叠而需要按顺序重新处理，因此团队评估后认为 Sei 整体性能仍会显著提高。

优化帐本储存结构：SeiDB

原有设计：Sei v1 储存状态资料量大

但其实 Sei 还有另外一个问题，会将整个 IAVL 树永久储存到分散式帐本中，由于快速的最终性与平行处理设计，需要频繁纪录全局的状态变化，整体的网络帐本大小将会增长的很快。

平行处理的代价是会记录许多无效的中间状态资料，根据 Sei 团队提出的 RFC，以 atlantic-2 测试网节点为例，atlantic-2 节点储存 25 GB 的资料只有 10 GB 是真正有意义的交易资讯，节点磁碟空间运用效率低。

由于资料膨胀，Sei 节点磁碟使用量成长很快。atlantic-2 归档节点硬碟使用量每天增长超过 150 GB，每周超过 1TB。 随着链状态的不断增长，储存空间增长率也会不断增加 (会越来越快)。

将会导致许多问题：

• 节点的维护成本将变得越来越高
• 资料库操作会变得越来越慢
• 由于磁碟填满很快 RPC 节点不能长时间运行

加上未来 v2 来回处理重新验证的平行处理设计，网络整体状态改变会更高频，导致状态资料量大幅增加。

更新重点：Sei v2 分离帐本结构

Sei v2 为解决上述问题也有优化储存机制，以防止状态资料量膨胀，并提高全节点读取资料速度。

Sei v2 将状态储存帐本拆成两种，称为 SeiDB：

• 状态承诺帐本 (State Commitment, SC)：纪录 MemIAVL 树资讯
• 状态储存帐本 (State Store, SS)：纪录完整资讯

由于 SeiDB 的改进，验证节点仅需要纪录 SC 帐本资讯即可，而完整状态资讯则交由 SS 层纪录，且传输会先放在预写日志中而不需要即时传输，这允许状态储存非同步发生以提高了效能，因为不会影响区块生成。

借由 SeiDB 改良，Sei 性能各方面都有所增加。包含区块提交时间提升 100 倍、每天产生的资料量从 100 GB 压缩至 5 GB、全节点或需要同步资讯的节点的追赶时间提升 10 倍。

共识机制

Sei Network v2 并没有更改其原有的共识机制，仍保持 Twin Turbo 设计。借由改良 Cosmos 的共识接口 Tendermint ABCI，将区块确认时间大幅降低。

Sei 借由取舍进入一线竞争链行列

Sei v2 新增了 EVM 虚拟机，并改良了平行处理机制与分散式帐本储存机制，目的都是为了让开发者、节点、用户的使用体验提升，进而增加生态影响力。

不过也借由这三个月的营运，发现 Sei 平行交易提高 TPS 与快速的最终确认性，背后的代价是状态资料量会变大，导致节点所需要的硬体规格上升，团队做出妥协将帐本结构分开，某方面来说是牺牲去中心化以提升效率的取舍。

整体来说 Sei 相对于其他以太坊杀手，若上述更新可以确实落地，有机会进入一线的竞争链行列中，期待看到明年团队更新的成果。

Tags： SEI 

转载请注明出处：https://www.eoje.cn/qkljs/3455.html