Sui：我们为什么需要另一条Layer 1？

主要收获

• 我们现在已经进入这样一个时代：Layer 1 区块链仅仅通过使用现有技术创造新的叙事来获得 PMF（产品市场契合度）极其困难。只有从根本上不同的技术才能证明新的 Layer 1 的存在是合理的。

• 在这方面，Sui Network 非常值得关注。它在共识、mempool，甚至在其编程语言中都具有创新功能。

• 特别是像 zkSend 和 zkLogin 这样的功能似乎展示了面向大众的区块链应该如何发展。Sui 通过在市场前沿引入这些技术，或许可以证明其作为一个新的 Layer 1 的存在是合理的。

区块链本质上建立在一个开源生态系统之上，并且由于开源的性质，产品可以很容易地被复制。这导致了一种情况，即如果某个行业或领域被认为是很有前途的，那么就会有很多人进入市场，推出类似的产品并进行竞争。这可能就是为什么我们在 2021 年和 2022 年见证了大量 Layer 1 区块链进入市场的原因。现在，这种现象已经转移到 Layer 2，出现了无数的 Layer 2 链。这是否意味着构建 Layer 1 区块链不再重要？当然，创建一个新的 Layer 1 区块链是非常具有挑战性和成本高昂的，而且我们不再处于大规模生产的 Layer 1 区块链能够像以前那样获得关注的时代。但是，我仍然相信 Layer 1 区块链在市场上存在机会，前提是它们提供技术差异化。

我感觉区块链基础设施领域现在正面临一个关键阶段。没有任何市场能够长期维持众多基础设施持续共存的局面。最终，区块链也可能会出现少数主要基础设施之间持续竞争的局面（尽管创新型基础设施可能会偶尔颠覆格局）。从这个角度来看，即将推出的 Layer 1 区块链必须不断证明它们与现有区块链的不同之处，以及它们为什么可以与其他 Layer 1 区块链共存。

作为一名相信 Layer 1 区块链，尤其是集成区块链，将在这个行业占据重要市场份额的人，我对本轮周期中具有技术差异化的 Layer 1 区块链特别感兴趣。有趣的是，其中许多都具有相当创新的设计。我想介绍的一个这样的区块链是 Sui Blockchain。

在本文中，我们将讨论 Sui Network，提供一个概述并探讨其作为 Layer 1 区块链的独特之处。

1. 一个老生常谈但重要的讨论：Sui 的起源

1.1 介绍 Sui (或 Mysten Labs)的联合创始人：一点也不老生常谈

众所周知，Sui 起源于 Meta (前身为 Facebook) 的区块链团队 Diem (前身为 Libra) 和 Novi 钱包。虽然这似乎是一个老生常谈的事实，但许多人并不知道这些人在 Diem 和 Novi 团队中所做的具体角色和贡献。让我们深入研究一下 Sui 联合创始人的背景，他们在 Meta 所做的事情，以及在此之前的经验。

来源: Mysten Labs

目前，Sui Network 分为两个实体：Sui 基金会和 Mysten Labs，Sui Network 的开发者。Sui Network 的所有创始人都隶属于 Mysten Labs。让我们仔细看看他们每个人，从左上角开始。Mysten Labs 的 CEO Evan Cheng 在加入 Meta 之前在 Apple 工作了十多年。在 Apple，他领导了 LLVM (底层虚拟机，一个由 Chris Lattner 在伊利诺伊大学发起，但在 Apple 进行了广泛开发和研究的模块化编译器项目) 后端团队。LLVM 以使 iOS 应用运行得更快而闻名。Evan 在 LLVM 上的工作为他赢得了 2013 年的 ACM 软件系统奖，他与 Chris Lattner 共同分享了该奖项。

CPO Adeniyi Abiodun 曾担任 J.P. Morgan 和 HSBC 的高级软件工程师，并参与了 Oracle 的区块链设计。在领导 Meta 的产品开发之前，他曾在 VMware 负责产品。

CTO Sam Blackshear 因在 Meta 担任首席工程师期间创建了 Sui 的编程语言 Move 而闻名。他还为 Diem 项目做出了重大贡献，包括参与 Libra Blockchain 白皮书。在 Sui，Sam 不仅在编程语言方面做出贡献，还在监督 区块链架构。

首席科学家 George Danezis 在英国著名的 UCL 担任安全和隐私工程教授十年，并且是 Alan Turing Institute 的研究员。我第一次注意到 George Danezis 是在 2022 年，当时他发表了 Narwhal and Tusk 共识论文。他还是另一种全新的共识算法 Mysticeti 的合著者，这让他成为我熟悉的人物，因为我对集成区块链的共识设计非常感兴趣。

首席密码学家 Konstantinos Kryptos Chalkias 在密码学领域享有盛誉。他领导了 Meta 和之前 R3 的密码学工作。他是 Sui 无缝 Onboarding 框架 zkLogin 的合著者。Konstantinos 还参与了 Sui 正在积极推广的 zkSend 等功能。当被问及 ZK 技术在集成区块链中的使用时，我经常会提到 Konstantinos 的论文和成果。

因此，Sui 的每位联合创始人都在各自的领域取得了显著的成果，并持续发表各种作品。作为一名对集成区块链感兴趣的研究人员，我正在密切关注他们周期性的成果。

1.2 为什么 Sui 推出自己的 Layer 1 区块链？

Sui 团队的大部分成员都是 Meta 的前区块链开发者。本文不会深入探讨他们为什么离开 Meta 建立 Mysten Labs，因为其他地方已经对此进行了广泛的报道。相反，我将专注于技术方面的理由。Sui 是一种集成区块链，如 Solana、Sei、Aptos 和 Monad。正如前面提到的，市场对新的 Layer 1 区块链感到厌倦（而且可能仍然如此）。尽管如此，为什么 Sui Network 还要推出自己的 Layer 1 区块链呢？

“智能合约平台的效用与运行在该平台上的程序可以原子访问的有趣共享状态的数量成正比。”

• Sam Blackshear(Mysten Labs 的 CTO)

Sam 认为区块链的可用性，尤其是智能合约平台的可用性，取决于不同的应用程序可以多么无缝地进行交互。Layer 2 rollups 和基于多链系统的生态系统具有孤立和独立的状态，牺牲了 Sam 所指的“可用性”的某些方面。当各种应用程序有机且无缝地通信时，智能合约平台的可用性会增加，从而带来有趣的结果。

本质上，Sui 旨在实现应用程序之间的无缝交互，同时具有成本效益、可扩展性和安全性。虽然说起来容易做起来难，但如果实现这一点，将验证 Sui 作为一个独立区块链的存在。Sui 已经证明了这一点吗？我认为还需要更多的时间，但作为开发独立 Layer 1 区块链的理由，这是令人信服的。真正对他们的技术充满信心，他们独立设计所有方面，而不是依赖现有的生态系统或链，这样效率更高，价值也更大。

在一个对新的 Layer 1 普遍持怀疑态度的市场中，技术差异化是获得关注的关键。Sui 可能会利用 Meta 的声誉及其著名的投资者来获得一些市场知名度，但关键因素是通过技术差异化来证明其可持续性。那么，Sui 的技术是否具有足够与众不同的地方来证明其可持续性呢？我相信是的。让我们更详细地探讨 Sui 的技术。

2. Sui 的基础设施和设计

Sui 是一条不断发展的 Layer 1 链。例如，它目前使用 Narwhal 和 Bullshark 作为其 mempool 协议和共识引擎，但计划很快推出一种新的共识机制 Mysticeti。因此，我将解释现有的和未来的共识引擎，以涵盖 Sui 的现在和未来。

2.1 从共识开始有所不同：Mempool 和共识的分离

Sui 的共识和 mempool 协议并非完全由 Mysten Labs 开发；相反，它们的遗产可以追溯到这些构建者在 Meta 设计 Diem 区块链的时候。Narwhal (Sui 中应用的 mempool 协议) 和 Bullshark (共识引擎) 都经过了精心的开发，每个都有自己的学术论文。为了帮助理解，让我们解释一下这些协议。

2.1.1 高效 Mempool 协议: Narwhal

首先，让我们讨论一下 Narwhal。Narwhal 是一种 mempool 协议，它极大地提高了区块链网络中验证者之间共享 mempool 中交易的效率。重要的是要注意 Narwhal 本身不是共识引擎，不能独立运行；相反，它旨在与现有的共识引擎结合使用。从 Narwhal 首次推出时，它不仅关于 Narwhal，而且关于 Tusk (一种与 Narwhal 协同作用的共识引擎) 这一事实可以明显看出这一点。那么，像 Narwhal 这样的独立 mempool 协议的目的是什么，它旨在解决什么问题？

传统 Mempool 的问题

要理解 Narwhal，首先必须理解什么是 mempool。mempool，是 memory pool 的缩写，是节点上未验证的交易的集合。然而，关键的一点是，虽然区块链在数据库中共享状态，但 mempool 是验证者本地的，这意味着 mempool 中的数据也需要被共享和验证，然后才能包含在区块中以达成最终共识。传统的区块链面临双重传输问题，验证者将所有交易广播给其他验证者进行验证，然后将已验证的交易打包到区块中以进行进一步传播。问题不在于双重传输本身，而是它给共识过程带来的额外负担。如果验证者本地 mempool 中的数据是正确的，则无需在验证者之间交换每个交易数据。

Narwhal 如何简化这一点

如果我们简化这个过程，不在验证者之间交换所有交易数据，而只是确保每个验证者本地 mempool 中的数据是一致的呢？换句话说，不像传统的区块链那样将交易数据包含在共识过程中，而是独立地处理 mempool，并将共识建立在元数据(区块头和哈希)之上。这是对 Narwhal 所做工作的简要解释。但是，要详细了解 Narwhal 简化传统 mempool 数据传播过程的方法，我们需要深入研究。

Workers 和 Primaries

要理解 Narwhal 的结构，首先必须理解两个关键实体的角色：workers 和 primaries。在一个验证者中，可以有多个 worker 机器(目前，在 Sui 中，无法运行多个 worker 机器，但由于将来可能会运行多个 worker，因此我将基于多个 worker 机器的前提进行解释。)，这些 worker 中的每一个都传播不同的交易数据，允许并行处理交易传播过程。另一方面，每个验证者只有一个 primary。

Workers 负责从客户端接收交易数据，批处理和哈希数据，并将它们广播到其他验证者的 worker。此外，worker 将其批处理的哈希值转发给本地 primary，后者创建一个批处理列表，并将其包含在一个区块中。

以这种方式创建的区块随后通过领导者验证者传输到其他验证者，领导者验证者也管理验证者签署区块的过程。如果签名达到 2f+1 的仲裁(其中 f 表示网络容忍的最大数量的错误或恶意节点)，则颁发证书。虽然 Narwhal 与共识引擎分离，但重要的是要注意仲裁标准取决于与 Narwhal 一起使用的共识引擎。然后，领导者将此证书传播给其他验证者，允许他们将其包含在下一轮的区块中。一旦领导者验证了 2f+1 个验证者已经积累了证书，他们就会进入下一轮。下一轮的区块包括关于区块生产者、签名、交易列表和证书列表的信息。区块的结构表明证书列表引用了来自前几轮的证书。

这些证书本质上证明了验证者拥有相同的数据，允许他们同步他们持有的数据。Narwhal 通过以下两种方式提高了区块链的速度：1) 不像传统的 mempool 协议那样按交易的方式进行交易通信，Narwhal 是在包含批量交易的区块级别上进行交易通信的，这使其效率更高。2) 由于交易排序与 Narwhal 完全分离，因此共识引擎(如 Bullshark、Tusk 或 HotStuff，将在后面解释)可以在 Narwhal 传播和保证交易数据时对交易进行排序并达成共识。这种分工导致比传统系统更快的共识。

2.1.2 共识怎么样？: Bullshark 的介绍

虽然 Narwhal 处理交易数据的传播，但 Bullshark 负责对交易进行排序。与 Narwhal 一样，Bullshark 也基于 DAG (有向无环图) 结构。要理解 Bullshark，必须掌握 DAG 的概念。

DAG 是一个有方向且没有环的图。它由顶点和连接这些顶点的边组成，形成一个每个顶点间接或直接验证其他顶点的结构。这些顶点和边具有特定的顺序，称为因果顺序。如果参与共识的所有验证者都有一个具有相同方向和值的 DAG，则表示它们已达成相同的总顺序。本质上，Bullshark 是一种(诚实的)验证者如何有效地达成这种总顺序的方法。然而，这并非易事。验证者各自持有一个本地 DAG，并且通常这些 DAG 并不相同(因为 Bullshark 本质上是一种异步 DAG 方法)。那么，Bullshark 如何确保验证者达成相同的总顺序呢？

Bullshark 是一种基于轮次的 DAG BFT (拜占庭容错) 共识协议。在这个系统中，DAG 中的每个顶点对应于一轮，并且由领导者拥有的称为“锚”的顶点存在于每个偶数轮中。在奇数轮中，对偶数轮的锚进行投票(因此，奇数轮涉及锚，偶数轮涉及对这些锚进行投票)。在如图所示的结构中，锚由绿色着色的顶点(A1 和 A2)表示，而具有绿色边框的顶点表示形成锚的因果顺序的顶点(例如，A2 锚引用来自第 1 轮的参与方 1、参与方 2、参与方 3 的顶点)。

锚本质上是领导者的顶点，并且为了确认一个锚，仅仅是一个锚顶点是不够的。根据 Bullshark 的 Commit Rule，锚必须收到来自后续轮次的至少 f+1 票，其中 f 表示错误或恶意节点的数量，如前文在 Narwhal 的上下文中解释的那样。

在给定的示例中，有 4 个参与节点 (N=4) 并且假设有 1 个故障节点 (f=1)，根据 Bullshark 的提交规则，一个锚通过收到至少 f+1 票来确认，这意味着需要 2 票才能确认。收到 3 票的锚 A2 已经确认(因此被加冕)，而只有 1 票的锚 A1 仍未确认。人们可能想知道是否可以跳过放置 A1 以支持 A2。答案是 否。正如前面提到的，Bullshark 本质上是在 异步 DAG 上运行的，因此从另一个节点的角度来看，A1 可能收到了超过 2 票。所以，即使一个特定的节点看到 A1 没有收到 f+1 票，但在 DAG 中最初将 A1 放在 A2 之前并继续构建它是仍然正确的。

这是否意味着只要锚存在，Bullshark 就应该放置所有锚？答案也是 否。对于一个锚来说，优先放置不仅要看它是否收到投票，还要看下一轮的锚是否通过至少一条路径连接到它。如果在我们的例子中，A2 和 A1 之间没有保证的路径，那么跳过 A1 是可以接受的。

总之，Bullshark 是一个基于轮次的 DAG，偶数轮有锚顶点，奇数轮有对这些锚的投票。一个锚必须被“确认”才能包含在 DAG 中，这需要在奇数轮中收到超过 f+1 的投票。但是，即使一个锚没有立即收到 f+1 票，它仍然被放置在 DAG 中，因为从其他人的角度来看，它可能已经收到了足够的投票。但是如果一个锚与其他锚没有连接，它将被排除在 DAG 之外。这确保了所有诚实的验证者最终都具有相同的 DAG 值(称为可靠广播)。

我们已经了解了 Bullshark 如何通过 DAG 的轮次进展。Bullshark 如何确保可扩展性？与 Narwhal 一样，Bullshark 在共识过程中分离了数据传播和 DAG 进展(事实上，Bullshark 是基于 Narwhal 的开源代码库开发的)。这意味着虽然 DAG 构建自行进行，但数据传播遵循网络的速度。即使 DAG 构建速度很慢，DAG 中的每个顶点也可以包含更多元数据来推进轮次，从而确保网络的可扩展性不会受到影响。

Bullshark 的方法增强了共识机制的可扩展性。验证者不需要进行广泛的通信即可达成总顺序，从而使他们能够有效地达成共识。

2.1.3 Narwhal & Bullshark 流程摘要

为了总结我们所讨论的内容，让我们分解一下网络实现 Narwhal/Bullshark 时的交易生命周期：

1. 交易由 workers 收集，workers 对交易进行批处理、哈希并广播

2. 然后将批处理的哈希值发送到 primary

3. primary 将这些哈希值放在一个区块中，并将该区块提议给其他 primaries

4. Primaries 检查他们是否收到了这些批处理并签名

5. 源 primary 收集 2f+1 个签名并生成一个证书

6. 当一轮中存在 2f+1 个证书(不同的 primaries)时，我们前进一轮

7. 在那一点上，网络可能会达成共识(并非总是发生)

8. 如果我们成功，那么这些批处理中的所有交易都将完全排序。这是网络获得结算终结性的时刻

9. 排序后，将交易转发以进行本地执行(这是验证者的内部操作)

10. 执行后，验证者向客户端发送一条执行结果消息。当 2f+1 个验证者这样做时，客户端会见证结算终结性

11. 与 9 和 10 并行，验证者还会检查他们执行的内容以供后代使用。目前大多数应用程序都等待检查点而不是步骤 10，因为它更容易处理

通过这种高效的共识方法 (Bullshark) 和 mempool 策略 (Narwhal)，Sui 已经实现了大约 125,000 TPS，尽管对于 50 个实体来说，延迟大约为 2 秒。

2.1.4 不满足于 Bullshark，进入 Mysticeti

我之前介绍的 Bullshark 和 Narwhal 的组合一直是 Sui Network 到目前为止能够有效处理大量交易的主要原因。但是，总是有更好的选择。目前，Sui 正在准备使用一个名为 Mysticeti 的新引擎进行共识升级。与 Bullshark 一样，Mysticeti 也基于 DAG 共识，但它与 Bullshark 有几个不同之处，我今天将重点介绍这些不同之处。

显著降低延迟

正如我之前简要提到的，尽管 Bullshark 具有快速的共识，但它也经历了显著的延迟。根据 Mysticeti 论文，Bullshark 记录的平均 TPS 为 60-80k，但也存在延迟问题，范围从 8 到 10 秒。虽然实现了可扩展性，但延迟仍然是一个问题。Mysticeti 可以被看作是减少这种延迟的尝试。事实上，使用 Mysticeti，实现了显著的改进，达到 50,000 TPS，同时将延迟降低到 0.5 秒。

签名区块代替认证区块

与 Bullshark 和其他通过认证区块(由超过 2f+1 个验证者签名的区块)创建共识的基于 DAG 的系统不同，Mysticeti 通过签名区块(仅由单个验证者(即区块的创建者)签名的区块)达成共识。这是可能的，因为 Mysticeti 使用通用提交规则。简而言之，网络不仅仅让验证者逐个签署每个区块，而是仅根据签名区块来决定是否提交或跳过区块。与 Bullshark 相比，这使得 Sui Network 能够显著降低延迟，并且由于这种效率，还可以最大限度地减少操作所需的 CPU 使用率。

隐式证书

很多人可能会在这里表达担忧。尽管 DAG 基础共识模型使用认证区块来实现共识有明确的原因，但 Mysticeti 仅使用签名区块来提交操作。使用签名区块安全地达成网络共识并非易事。虽然这种方法可能会降低网络延迟，但与使用认证区块实现共识的网络(如 Bulshark)相比，签名区块被认为具有较低级别的区块验证，这不可避免地会引发安全问题。

那么，Sui 是否在考虑到这些担忧的情况下采用 Mysticeti？答案是“否”。网络如何才能在没有安全问题的情况下仅使用签名区块安全地达成共识呢？要理解这一点，必须掌握隐式证书的概念。什么是隐式证书，它与 Bulshark 中使用的证书有何不同？

在 Bulshark 中，系统本身就具有需要创建和传播的证书。相反，在 Mysticeti 中，如果共识设置的许多验证者同意(签名)，则该交易本身被认为是“认证的”，并且达成共识。

这意味着在 Mysticeti 中，即使每个交易都没有证书，只要区块获得预定数量的验证者的支持(并且区块包含对这些验证者持有的先前轮次的区块的引用)，它就可以提交到网络。由于逻辑时钟，可以确保区块以正确的顺序提交，这极大地有助于维护协议的完整性。

Wen Mysticeti

预计 Mysticeti 将在 今年上半年某个时候 升级 Sui 共识引擎。看看 Sui 能否通过引入 Mysticeti 在大幅降低网络延迟的同时保持稳定性，这将是一件有趣的事情。

2.2 Sui 独特的 Tokenomics

Sui 以其非常独特的 tokenomics 在区块链中而闻名。在深入研究 Sui 的 tokenomics 的细节之前，让我们首先探索一些 Sui 经济模型独有的概念。

2.2.1 存储基金

存储基金是我在研究 Sui 的 tokenomics 时遇到的最有趣的功能之一。我相信这种模型将来可以作为其他 Layer 1 区块链的参考。首先，随着时间的推移，区块链中节点所需的存储量会显著增加。这是给定的，因为完整节点需要维护从创世区块到当前区块的所有区块，这意味着它们所需的存储容量将随着时间的推移不可避免地增长。因此，为了使区块链能够长期可持续地维护，需要一种经济激励，能够处理大量的存储需求，即使随着时间的推移也是如此。Sui 创建了存储基金，旨在在未来的任何给定时间为参与网络的节点提供适当的存储奖励。

来源：Sui Document

那么，存储基金中的资金从哪里来？可以认为它来自目前在 Sui 上支付交易费用的用户。当用户支付交易费用时，成本分为执行成本和存储成本。然后，存储成本被发送到存储基金。此外，在计算 Sui 的权益证明 (PoS) 机制中的总权益数量时，还会包括存储基金中的 Sui 代币，并获得相应的权益奖励。随着时间的推移，这会增加存储基金的规模(直到将来将其分配给验证者)，从而实现可持续的存储管理。

我在研究存储基金时发现的一个特别有趣的功能是“删除选项”。此功能会在用户删除某些链上数据时，从存储基金中退还一部分最初用于创建数据的存储交易费用。这非常有趣，因为它激励用户自愿删除无用的数据。但是，重要的是要澄清，删除选项并不与区块链的核心价值(即不变性)相矛盾。该选项不是用于删除过去的交易，而是用于删除不再有意义的数据(如 NFT 元数据、已使用的票证或与已结束的拍卖相关的数据)。换句话说，区块链不变性的核心价值不受删除选项的影响。

2.2.2 交易费用计算方法

Sui 网络中的交易费用是如何确定的？令人惊讶的是，答案是“它们在不断变化”。逐 epoch，Sui 验证者会进行一种调查。在此期间，验证者会单独设置他们愿意接受处理交易的最低金额。然后，参考成本基于这些最低值中较低的 66.67% 分位数值。重要的是，这不仅仅是一个简单的 66.67% 分位数，而是按每个验证者上质押的 Sui 代币数量进行加权。使用 66.67% 标记的原因是将其基于大多数验证者认为可以接受的价格。

另一个有趣的方面是，在每个 epoch 结束时，验证者会监视网络中其他验证者的性能。性能是根据各种指标(如响应时间)进行评估的，并且会相应地调整奖励(提交较高最低交易费用或未能处理交易的验证者获得的奖励较少，反之亦然)。然后，验证者在每个 epoch 结束时提交他们对其他验证者性能的意见，这会影响权益奖励的分配。Sui 中这种计算交易费用的方法非常人性化，因为它鼓励验证者提供较低的交易费用。

2.3 Sui 上的 Move

资源：Sui

在探索 Sui 与其他区块链的不同之处时，不可能忽视它的编程语言。我所说的是 Move，尤其是 Sui 上的 Move。Sui 因其对 Move 的改编而著称。Mysten Labs & Sui 的联合创始人兼 CTO Sam Blackshear 因在 Meta 工作期间创建这种编程语言而闻名。 Move 是一种专门为区块链设计的编程语言，专注于安全性和网络稳定性。Sui 对 Move 进行了修改，因此在讨论 Sui 上的 Move(Sui 中使用的 Move 版本)之前，让我们首先看一下 Move 本身。

2.3.1 面向资源的编程语言(我也将它措辞为面向资源，因为我想将 Sui 上的 Move 与原始的 Move(基于帐户)区分开来，但如果你仍然认为面向对象是更好的说法，我很乐意更改它)

在 Move 中，资源被视为一等公民值(一等公民对象是一个实体，它支持通常可用于该语言中其他对象的所有操作，表明编程语言中最高的灵活性)。在 Move 语言中，资源可以以各种形式存储和发送，但严格的规则可以防止这些资源在存储中被复制、处置或未经授权的移动。从本质上讲，资源可以在与稳定性相关的约束内自由使用。Move 中的资源示例包括加密资产、智能合约状态值、NFT 和链上投票权(Solidity 中没有的功能)。

2.3.2 数据抽象

简而言之，数据抽象是隐藏事物运行方式的复杂细节，从而无需用户了解其内部工作原理即可实现其功能。数据抽象是 Move 中的一项关键功能，其中资源和其他数据类型封装在模块中，从而抽象出与管理这些资源相关的复杂任务(例如如何存储、修改或管理它们)。从用户和开发人员的角度来看，这种抽象都是一个显着的优势。

数据抽象还允许控制对资源的访问。它指定允许对什么资源执行什么操作，以及在什么条件下执行。此功能对于应用程序构建者来说非常有用，尤其是在安全性方面。

2.3.3 静态验证

静态验证包括在程序执行代码之前检测代码中的错误或漏洞。这是因为 Move 将类型分配给表达式、函数和变量，并定义了关于如何使用和组合这些类型的明确规则。

Move 还引入了一个借用检查器，以确保数据不会被意外地变异，并防止对数据的引用超出数据本身的生命周期。

最后，执行形式验证以验证合约逻辑的能力是另一个显著的优势。

2.4.4 Sui 上的 Move：有什么区别？(如果团队想指出更多差异，我非常乐意向你学习！)

虽然 Move 本身是一种强大的编程语言，但基于帐户模型的原始 Move 对 Sui 团队来说存在局限性。最初是为许可区块链 Diem 设计的，因此需要为无需许可的区块链 Sui 重新构想它，从而导致了 Sui 上 Move 的开发。Sui 上的 Move 在以下几个方面与原始 Move 不同：

面向对象的模型

与原始 Move(数据按地址或类型名称全局存储)不同，Sui 上的 Move 按对象的 ID 存储数据。在 Sui 上的 Move 中，每个对象都被分配一个唯一的 ID，该 ID 独立于区块链地址。例如，对象“CoolAsset”将具有一个唯一的 ID，如“AssetID123”，并且该 ID 存储在全局存储中，引用该对象。这意味着开发人员不必编写复杂的逻辑来转移资产，因为全局存储包含对象 ID，而不是所有者的数据。

交易并行化

在原始 Move 中，由于其基于帐户的模型(其中更改状态值的交易与帐户相关数据紧密相关，增加了问题的可能性)，交易并行化不是默认的。但是，在 Sui 上的 Move 的面向对象模型中，每个对象都会受到独立影响，因此对一个对象的更改不会影响另一个对象。例如，更改不同对象的两个交易可以并行处理而不会出现问题。

3. Sui 上的杀手级功能：为什么选择 Sui？

到目前为止，我们已经了解了 Sui 的设计和结构差异。但是，用户体验到的真正区别性特征在于我接下来将介绍的功能。如果 Sui 以自托管方式支持原生社交登录怎么办？或者如果用户可以通过二维码或链接发送资产怎么办？最后，如果 Sui 本身就具有为没有 Sui 代币的用户赞助交易的能力呢？令人惊讶的是，Sui 拥有所有这三个功能。让我们探索每个功能，并了解为什么 Sui 在功能上与其他 Layer 1 区块链不同。

3.1 zkLogin

zkLogin 本质上是一个 onboarding 框架，它提供了与 Web 2.0 服务的登录或注册过程相当的用户界面 (UI) 体验。但是，与传统的 Web 2.0 不同，在传统的 Web 2.0 中，第三方管理用户数据，而 zkLogin 允许用户完全拥有自己的数据。Sui 如何实现这种便利性和数据自托管 (Self Custodial) 的平衡？要理解 zkLogin 的方法，必须初步了解 OAuth 2.0 和零知识证明。因此，让我们简要地探讨这两个概念。

3.1.1 OAuth 2.0

你们中的许多人可能会发现这个术语不熟悉，但那些阅读本文的人可能在登录 Four Pillars 网站时使用了 OAuth 2.0 方法。OAuth 2.0 是 Open Authorization 2.0 的缩写，是一种用于身份验证的开放标准协议。简单来说，它是一种 允许资源所有者(用户)将对其资源的访问权限委托给第三方 的协议。毫不夸张地说，我们今天使用的大多数便捷的登录功能都基于 OAuth 2.0 协议。OAuth 的参与者如下：

• 资源服务器：可以将其视为持有资源的服务器。像 Facebook、Google、Twitter 这样的公司，我们用它们来进行便捷登录，主要属于这一类。

• 资源所有者：资源的所有者，本质上是使用服务的用户。

• 授权服务器：此服务器管理对资源的访问权限，并且还负责创建访问Token。

• 业务客户端：想要访问资源服务器信息的实体。Four Pillars 也可以被视为一个客户端。

为了进一步详细说明，客户端需要经过大约三个步骤才能收到资源：首先，它必须获得 资源所有者(用户) 的身份验证批准，然后将此批准提交给 授权服务器，后者反过来提供一个 访问Token。然后，将此访问Token提供给 资源服务器 以获得资源。

Sui 的 zkLogin 作为“便捷登录”的一项核心功能，也使用了 OAuth 2.0。因此，任何与 OAuth 2.0 兼容的资源服务器都有可能支持 zkLogin。

3.1.2 零知识证明

但是，如果 zkLogin 仅使用 OAuth 2.0，则它不会具有前缀“zk”。Sui 的 zkLogin 与标准便捷登录功能相比，其独特之处在于它使用了零知识证明(ZKP)。ZKP 是一种加密协议，它允许证明者向验证者证明对特定信息的了解，而无需透露信息本身。换句话说，使用 ZKP，你可以证明你知道某件事，而无需实际披露该信息。

ZKP 的工作原理是允许证明者向验证者证明对特定信息的了解，而无需披露该信息本身。因此，它在身份验证、身份验证和隐私保护方面都有应用。Sui 的 zkLogin 就是使用 ZKP 的一个恰当的应用程序示例。它利用 ZKP 来防止第三方将 Sui 地址与其 OAuth 标识符链接起来，提供了一种便捷的登录方法，同时将数据完全置于用户的控制之下(使用 ZKP 技术，即使是像 Google 或 Facebook 这样的信息提供商也无法知道他们提供的信息与特定的 Sui 地址相关联)。

3.1.3 zkLogin 的工作原理是什么？

要了解 zkLogin，务必了解几个关键术语：

1. JWT Token：代表 JSON Web Token，分为标头、有效负载和签名。它是一种用于在客户端和服务器之间的通信中授予授权的Token。

2. Salt：在密码学中，salt 是在进行哈希处理之前添加到数据、密码或密码短语中的随机字符串。它确保即使使用相同的密码，生成的哈希值也会不同，常用于存储中的密码保护。

3. OpenID Provider (OP)：这些实体在 OAuth 2.0 中充当资源服务器。目前，Facebook、Google、Twitch、Slack 和 Apple 是支持 zkLogin 的提供商。

4. Application Frontend：指支持 zkLogin 的应用程序或服务，如钱包。

5. Salt Backup Service：一个后端服务，用于向用户返回 salt 值。

6. ZK Proving Service：基于 JWT Token、JWT 随机数、用户 salt 值和 max-epoch，此服务创建一个零知识证明 (ZKP)。创建 ZKP 需要大量资源，因此 Mysten Labs 也可以代表用户生成 ZK 证明。

7. eph_sk, eph_pk: 这些是生成临时签名所需的密钥对（私钥和公钥）。 签名机制类似于标准交易签名，但由于它们随着 OAuth 会话过期，因此是临时的。

   1. zkLogin 使用这些临时密钥对，允许用户在丢失密钥时生成新密钥，从而保护他们的资产。

8. iss (issuer): 表示颁发 JWT Token的实体。

9. aud (audience): 标识 JWT Token的接收实体。

10. sub (subject): 标识 JWT 的用户主体。

了解了这些关键术语后，让我们来探索 zkLogin 的流程以及它如何让用户访问 Sui 区块链：

1. 用户首先登录到 OP，获取包含 nonce 值的 JWT Token。 他们生成一个临时密钥对 (eph_sk, eph_pk)，将公钥以及过期时间和 Jwt_randomness 添加到 nonce。 完成 OAuth 登录后，用户可以在应用程序的重定向链接中找到 JWT Token。

2. JWT Token随后由 Application Frontend 发送到 Salt Backup Service。 Salt Service 验证 JWT Token，并根据 iss、aud 和 sub，将用户的唯一 salt 值返回给 Application Frontend。

3. 用户将 JWT Token、salt 值、临时公钥、jwt randomness 和字符串（iss、aud、sub）发送到 ZK Proving Service，然后该服务基于此信息生成 ZKP。

4. 应用程序基于这些字符串计算用户的地址（与 JWT Token是否有效无关）。

5. 交易使用临时私钥进行签名，从而创建一个临时签名。

6. 最后，用户将临时签名、ZKP 和其他输入值提交到 Sui 区块链。

重要的是要强调 zkLogin 的一个特定方面，即它为每个应用程序和 zkLogin 兼容的钱包创建单独的 OAuth 凭据。 简而言之，当你使用 zkLogin 加入 Sui 区块链以使用特定应用程序时，会为每个应用程序分配一个单独的地址和帐户（这包括钱包。例如，即使你使用同一个 Google 帐户登录到不同的钱包，也会分配不同的帐户）。 采用这种方法是为了为每个应用程序提供独立的用户体验。 让我们用一个例子来说明：

• steve@4pillars.io + Sui 钱包 = 帐户 1

• steve@4pillars.io + 另一个 Sui 钱包但 zkLogin 兼容 = 帐户 2

• steve@4pillars.io + 游戏或 DeFi 应用程序 = 帐户 3

现在的问题是，如果有人使用 Google 帐户 steve@4pillars.io 通过 zkLogin 登录并使用 Sui 钱包访问游戏或 DeFi 应用程序，是否会为每个游戏和 DeFi 应用程序分配不同的帐户？ 答案是“否”。 正如我刚才解释的，在这种情况下，钱包也被视为应用程序。 因此，如果你使用 zkLogin 登录 Sui 钱包并在 Sui 上使用各种应用程序，那么就 OAuth 凭据而言，它仍然被视为一个应用程序。 但是，如果你不通过其他钱包直接访问游戏或 DeFi 应用程序，那么确实会为每个应用程序分配单独的帐户。

本文的读者可能会认为 zkLogin 是一项过于复杂的功能，但自然地，我上面提到的过程都在用户端省略了，并由应用程序处理，因此无需担心。 我解释 zkLogin 流程的原因是为了展示它如何安全地保护用户数据，并以非托管的方式轻松加入 Synergy 网络。 由于它与钱包有关，钱包是区块链中最重要的功能之一，因此有必要进行详细说明，以便人们可以放心地使用它。

3.1.4 zkLogin 与其他社交登录的区别

虽然其他社交登录（将 Web2 身份验证引入 Web3）可能看起来与 zkLogin 相似，但它们的区别在于：1) 依赖第三方（用于 Web2 身份验证或管理私钥）并且 2) 需要披露个人信息以进行 JWT Token验证或进行昂贵的链上 ZKP 验证。

zkLogin 是 Sui 原生的，这意味着通过 zkLogin 创建的交易很容易与 Sui 区块链上的其他交易兼容（例如即将推出的 Sponsored Transaction 功能）。

此外，使用临时密钥意味着第三方无需持续管理私钥（这些密钥会随着 ZKP 过期）。 最后，只需要在链上提交 ZKP 和临时签名，这意味着不需要披露其他信息。 这标志着与传统社交登录的明显区别。 有关 zkLogin 的更详细说明，请参阅 Four Pillars 的关于 zkLogin 的文章。

3.2 zkSend

来源：Mysten Labs Blog

zkSend 是一种简单的技术，可以轻松转移 Sui 代币。 通常，向某人发送代币涉及 1) 确定代币数量和 2) 输入收件人的地址。 即使使用域名，记住或携带地址也很不方便。 错误的输入可能意味着永久丢失资产。 如果你无需输入收件人的地址即可发送资产，那不是很好吗？

这就是 zkSend 的用武之地。 发送者只需要输入要发送的资产金额，然后生成一个链接或二维码发送给收件人。 收件人在收到后，可以使用前面解释的 zkLogin 轻松登录并接收资产。

3.2.1 zkLogin + zkSend = 提升到另一个级别的 UI/UX

正如我上面解释的，结合 zkLogin 和 zkSend，创造了一种体验，其中“即使没有 Sui 钱包的人也可以在短短 10 秒内创建一个钱包，并通过二维码或链接接收 Sui。” 首先，收件人通过 zkSend 获得一个链接或二维码，然后通过 zkLogin 使用他们的 Google 或 Twitch 帐户立即创建一个 Sui 钱包，并立即收到 Sui 代币。 想象一下，一个人在没有钱包的情况下创建一个钱包，并在短短 10 秒内在一个自托管钱包而不是中心化交易所接收 Sui。 Sui 已经实现了所有这些功能。 从应用程序构建者的角度来看，这种基础设施非常通用，我撰写这篇关于 Sui 的文章的主要原因就是 zkLogin 和 zkSend 的创新。 有兴趣尝试 zkSend 的人可以通过此链接直接体验发送和接收 Sui 代币。

3.3 Sponsored Transaction

来源：Sui Blog

我们深入研究了 Sui 的 zkLogin 和 zkSend，这些创新功能解决了传统区块链钱包的不便之处。 然而，另一个主要挑战依然存在：交易费用。 Sui 简化交易费用的方法很有趣。

核心思想是消除问题的根源。 如果交易费用是一个用户界面问题，为什么不启用无费用交易？ 这个概念催生了 Sponsored Transactions。 使用 Sui 的编程语言 Move，应用程序开发人员现在可以部分或全部承担用户的交易费用。 Sponsored Transactions 在以下几种情况下发挥作用：

1. 补贴用户发起的交易：用户生成一个 GasLessTransactionData Object 以供开发者批准。 然后，开发者签署一个带有费用的 TransactionData Object，用户也签署该 Object，从而允许交易进行。

2. 直接从开发者向用户转移费用：开发者预先授权并承担交易成本，向用户发送一个随时可用的 TransactionData Object。 这种方法非常适合促销或吸引新用户。 值得注意的是，即使那些没有 Sui 代币或区块链专业知识的人也可以参与，这要归功于 zkLogin。

3. 向用户提供 GasData：GasData 类似于一张空白支票，定义了交易成本预算。 用户可以在此限制内自由交易，由开发者处理签名和处理。

Sui 的创新结构允许用户参与区块链交易而无需担心成本。 如果这些功能 - zkLogin、zkSend 和 Sponsored Transactions - 获得关注，它们可以将许多人无缝集成到 Web3 世界中。 设想这样一种场景：用户可以在不知道地址或拥有钱包的情况下免费发送和接收资产。 这与应用程序开发人员一直努力实现的目标完全一致。

4. 展望未来

我们已经探讨了 Sui 的各个方面。 在我对不同区块链的研究中，很少有像我为 Sui 所做的那样引用如此多论文的文章。 这突显了 Sui 区块链在技术上的密集性和创新性。 正如我前面提到的，要创建一个新的 Layer 1，它真的需要是新颖的。 仅仅是 Fork 现有的链并添加新的叙述可能不足以保持竞争力。 Sui 正在各个领域不断尝试新事物并不断发展。 这不仅仅是关于共识设计或架构，还关于改进用户界面和培养对开发者友好的环境。

即使对于像我这样研究区块链很长时间的人来说，像 zkLogin 和 zkSend 这样的技术也非常令人震惊。 它们发出了关于区块链大规模采用的重要信息：要真正让公众使用区块链，不仅需要在速度和低费用方面进行创新，还需要在钱包的运行方式、资产的转移方式以及简化交易成本方面进行创新。

我预见将来会在 Four Pillars 上频繁报道 Sui。 即使在我撰写本文时，Sui 团队也在进行令人难以置信的尝试，例如在没有互联网连接的情况下发送交易，作为一名研究人员，我有责任深入研究这些壮举是如何实现的。 Sui 接下来会推出哪些新功能？ 让我们一起密切关注 Sui 的发展。

感谢 Kate 为本文设计了图形。

• 原文链接： 4pillars.io/en/articles/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～