Delphi Digital：我们为什么看好Sei Network

原文标题：《Delphi Digital：我们为什么看好 Sei Network》

原文作者：Delphi Digital

原文编译：Babywhale，Foresight News

1 月 4 日，加密货币交易平台 MEXC 宣布启动 2000 万美元专项基金，用于支持 Sei Network 重点项目发展。而早在 8 月 31 日，Sei Labs 宣布已完成 500 万美元种子轮融资，Multicoin Capital 领投，参投方包括了 Coinbase Ventures、GSR、Flow Traders、Hudson River Trading、Delphi Digital、Tangent 等。在官宣完成融资后的一个月，Sei Network 推出 5000 万美元生态基金，以支持在其上开发的 DeFi 应用。

作为 Sei Network 的投资方之一，Delphi Digital 撰写了一份报告来解释其为何看好 Sei Network，笔者在此将报告中的重点内容进行总结梳理，供大家共同探讨。

专为 DeFi 而设计的网络

在构建区块链时，我们通常试图将其归入两个不同的种类：通用链或应用链。通用链用于无需许可的创新，而应用链则用于需要许可的特定用例。但「应用链」并不是非黑即白的，而是由链自身来决定。Sei 是一个即将推出的 Coos 生态链，旨在成为一个「专为 DeFi 为设计」的 Layer 1 区块链。

「专为 DeFi 为设计」意味着对基础层进行根本性的改变（和权衡），使得 DeFi 应用能够蓬勃发展。Sei 拥有一个内置的订单匹配引擎，亚秒级的结算速度，订单的并行化处理，单区块订单执行等。所有这些定制化的功能都是在基础层完成的。要知道的是，Sei 不是一个 DEX，它是一个为 DeFi 优化的 Layer 1 区块链。同时 Sei 不是一个单纯的应用链，不像 THORChain 那样只关注跨链交换的「纯」应用链，而是一个为诸如 DEX、合约、期货等产品的特点开发的区块链。

为了理解为什么会想在底层网络上做这些改变，我们可以看看 Serum 和 Solana。Solana 是一个通用的 Layer 1 区块链，被宣传为「链上纳斯达克」，目标是 400 毫秒的区块确认时间和极高的吞吐量。Solana 的主要观点是，订单簿交易平台最终将接管 AMM，而 Solana 上的指标也支持了这个观点。Serum 是建立在 Solana 之上的订单簿应用，是 Solana 生态被使用最多的应用，占 Solana 上交易的的约 1/3。

Serum 是 Solana 上的「订单簿层」，供 Mango Markets、Zeta、Atrix、Bonfida、Jupiter 等项目使用。当人们想到 Solana 时，他们通常会想到 Serum。

然而这种架构也有一些缺点，最值得注意的是，由于 Solana 是一个通用链，Serum（以及建立在上面的应用）不断地与其他应用竞争资源。与 Serum 无关的活动，如游戏和铸造 NFT，会导致链上的拥堵，正如我们此前经历过的 Solana 的几次「停机」。Sei 则是选择「削足适履」，将所有非 DeFi 活动从他们的链上剥离出来。一个简单的解释是，Sei 就相当于是 Serum 推出了自己的 Layer 1 区块链：做出具体的权衡，使基础层为 DeFi 优化，并给建立在其上的 DeFi 应用拥有较非 DeFi 的应用「不公平的优势」。

这里主要的权衡是，Sei 不会像 Solana 那样无需许可，因为想要在其上开发应用需要通过治理来获得白名单。虽然你失去了一些无需许可的创新带来的优势，但你可以创造一个更优化的环境。原生的订单匹配引擎、价格预言机、并行订单执行和单区块订单执行是 Sei 在基础设施层面建立的一些东西。Sei 是一个应用链，但 Sei 的链上订单簿创建了一个可组合的架构，允许 Sei 上的 CoWa 应用之间有同步的可组合性，并通过原生订单匹配引擎分享流动性。作为一个支持 IBC 的 Coos 链，其本身就具有异步可组合性。

Sei 通过 ABCI++ 实现了他们的一些优化，ABCI++ 是即将对 Coos 的 ABCI 进行的升级，使得共识的每个步骤都是可编程的。Sei 一直在尝试用 ABCI++ 进行三项改进 ：优化区块生产、智能区块广播和订单并行执行。

用 ABCI++ 优化 Sei

对于专注于订单簿交易来说，区块生产时间、交易结算和延迟对做市商来说是最重要的。做市商需要在每个区块中更新他们的价格，因此较短的区块时间意味着区块之间的价格差距较小，价差较小，做市商需要承担的风险就较小。任何超过几百毫秒的时间都是难以接受的的（而且从长远来看几百毫秒可能还是太高了）。一个标准的 Coos 链有约 6 秒的区块确认时间，这使得订单簿并非**解。然而，Coos 的魅力在于它的可定制性，Sei 一直专注于做出改变以优化共识，并使其尽可能快（目标为约 300-600ms）。Sei 的三个主要的重点领域是：

优化区块生产、智能区块广播和订单并行执行。

Sei 通过利用 ABCI++ 来做到这一点。ABCI 是应用和共识之间的接口，它的主要作用是执行由共识决定的区块。有了 ABCI，应用只用在决策时与共识交互，并且对从 mempool 中挑选哪些交易几乎没有控制权。ABCI++ 为共识的每一步都增加了可编程性，允许应用重新排序、修改、放弃、延迟或增加交易，以及通过引入优化产生区块的能力来缩短区块生产时间。

在共识的提案步骤之后，应用能够开始优化处理区块，与预投票（pre-vote）和预委托（ pre-commit）阶段并行。然后，Sei 将开始「通过优化」将状态变更到一个临时的候选状态，直到被共识接受。如果不被接受（很罕见），区块就会被放弃。在这个步骤中，有大量的数据需要处理，它可能相当缓慢。但通过经过优化状态变化处理，我们可以缩短出块的时间，并显著减少延迟（减少约 300ms）。

除了优化区块生产外，Sei 也在对区块信息广播进行改进。在 Tendermint 中，当一个验证者提出一个区块时，这个区块会包括所有的交易细节，数据量会非常大，但是验证者已经通过他们本地 mempool 中获得了这些交易的约 99.9%，因此不需要等待再次从区块提出者那里接收这些数据。与其发送所有细节，提议者现在只需发送区块中每笔交易的哈希值，验证者将能够通过使用他们自己的本地 mempool 来快速重建区块。

Sei 将这两项优化命名为「Twin-Turbo Consensus」，并表示通过实施这两项优化（优化区块生产和智能区块广播），吞吐量提高了 83%。 

对区块生产过程的第三个优化是围绕交易执行的。使用 ABCI 的 Coos 链的交易处理是按照先后顺序执行的，该过程中，不管在哪个市场中交易都是挨个儿进行处理，这大大阻碍了吞吐量。并且随着负载增加，延迟也将成倍增加。使用并行处理，不重叠的独立市场可以同时处理。与其在市场 A 的交易后再处理市场 B 的第一笔交易，不如同时处理它们。特定市场内的交易仍然需要按顺序处理，以避免不确定性，当两个不同的验证器对同一状态得到不同的结果时，就会发生不确定性（例如，一个验证器在用户 B 之前处理用户 A 的订单，但另一个验证器在 A 之前处理用户 B 的订单，导致用户的结算价格冲突）。 

Sei 围绕并行化进行了一些负载测试（同时也对验证器进行了主机托管），以观察在出块时间、延迟和吞吐量方面能得到什么样的改进。一般来说，通过并行化的执行，可以将区块时间比按顺序处理减少 75-90%，并行的延迟为 40- 120ms，顺序的延迟为 200-1370ms。在拥有 1 万个订单 / 区块和 20 个不同合约（市场）的情况下，并行能够将出块时间从 1.33s 减少到 0.81s，延迟从 371ms 减少到 48ms，吞吐量从 7500 个订单 /s 到 12200 个订单 /s。在所有的负载水平（订单 / 块）上都可以看到明显的改进，随着负载量的增加，边际优化程度更大。 

除了上述三项主要改进，Sei 还在基础层中增加了其他功能，例如：

原生的价格预言机。在基础层中建立预言机；验证者在生产一个区块时需要就价格达成一致。在验证者就价格达成一致之前，区块不会被建立。允许其他模块从链上市场获取可靠的价格信息。

单区块订单执行。允许在单个区块中进行下单和执行（在 Serum 中需要多个区块）。

订单捆绑。做市商可以在一次交易中更新多个市场的价格。

频繁的批量拍卖。可以在区块结束时汇总市场订单，以单一价格进行清算；目的是尝试并**限度地减少抢先交易。

除了软件方面的改进，Sei 也一直在测试更小的验证器结构以及更高的硬件要求。虽然在去中心化方面有所取舍，但这些都伴随着显著的性能提升，并再次突出了 Coos 的独特之处：可定制性。 

使用高性能硬件配置验证器

在 Sei 项目文档的第一个版本中，推荐的规格与标准的 Coos 链相似。之后硬件的要求被提高了，并且在特定的负载测试中，要求甚至被进一步提高。订单簿模型对硬件的要求很高，低性能的机器会降低网络的整体性能。虽然不是 Solana 级别的要求，但 Sei 已经明确表示，他们希望他们的验证器能够超过常见的区块链。此外，他们正在推动验证器地理位置的集中化，以进一步减少延迟。

为什么要进行主机托管？如果验证器在地理位置上分散，信息的传输就需要更长的时间，也就导致在达成共识和产生区块时会有更高的延迟。订单簿交易平台需要尽可能地减少延迟。Sei 再次公布了他们围绕主机托管的一些测试结果：

1. 与地理分散相比，主机托管可减少约 46% 的延迟。

2. 50 个验证器是可承受延迟的极限。

让所有的验证者都在同一个地理区域内有着明显的利弊权衡，但性能的提高是难以忽视的。当 Sei 推出主网时，他们很可能会朝着这种集中的、较小的验证器集的方向发展。在下面的图表中，p50/p75/p95 指的是 x% 的请求将快于一个特定值的概率。例如，p50 意味着 50% 的请求将快于该测试的 p50 值。所以 p95 意味着 95% 的请求会比 p95 值快。

总结

Delphi Digital 的报告中还包括了生态、Token 等方面的内容，本文暂时将其略过，仅仅展示了 Sei Network 在技术方面和机制方面的创新。可以看到的是，Sei 在并行处理和区块广播等方面做出了创新，提高了网络交易确认速度；但另一方面，Sei 需要高性能硬件配置的验证器，同时需要这些验证器地理位置相对集中来进一步满足其对订单簿模型交易平台支持程度，Delphi 在报告中也承认了该方案的中心化问题，但表示其对性能的提升仍是不容忽视的。

笔者认为，正如文中所说，Coos 生态应用链的可定制性极强，而 Web3 对于区块链应以一种怎样的意识形态呈现应该已经足够包容，我们可以支持去中心化程度高的项目，也可以接纳为了高效而牺牲了部分去中心化程度的项目。不过，Sei Network 是否能有其所说的那么「快」，还需要主网上线之后用真实数据来给出答案。