深度对话：从底层看 Sui 设计理念及网络规模扩展

您来自学术领域，能介绍一下您的研究重点吗？

我是伦敦大学学院（University College London，UCL）的教授，研究重点从广义上说叫安全和隐私。在 20 世纪早期，我在点对点系统和匿名系统方面进行了相当多的研究，这些系统许多都是以存储为重点的大型分布式系统。当整个区块链变得更加注重执行，尤其是以以太坊为代表的，我对分布式账本和区块链以及如何执行智能合约产生了兴趣。其中无需许可的特性，我在早期点对点系统的工作中就非常熟悉。于是，我在UCL的研究小组开始着手研究如何构建更高性能的系统。我们创办了Chainspace公司，将我们的一些想法商业化，后来团队被Facebook收购。然后，我们帮助Facebook提出了扩展区块链Libra/Diem的解决方案。但当方案没有取得进展时，我离开了，继续寻求其他机会来实现高性能区块链的理念。

你还是一个教授，那您觉得应用和研究之间有什么区别？

实际上并没有太大的区别。当我们进行研究时，我们会考虑实现特定目标的所有可能性，比如构建一个高性能的区块链或特定的功能。当然，在构建区块链或选择要在实际系统中使用的特定功能时，我们必须选择其中一个可能。我们必须不断地做出判断，在所有这些好的想法中，哪一个实际上对人们最有用？哪个是人们正在寻求的？区块链的采用存在哪些瓶颈？是什么阻止了人们实现他们想要做的事情？在构建系统时，您仍然会考虑所有可能性，并试图从学术文献中了解可能的情况，然后选择最相关的内容。这不仅仅是知识兴趣，而是为用户创造价值。

从理论到实际应用时，您是如何确定要解决哪些问题的？

我在研究中解决的主要问题是如何扩展区块链的不同功能。我专注于区块链的系统方面，比如，如何增加交易吞吐量并降低延迟。这方面的问题是显而易见的，每当我们看到以太坊上的某个合约变得非常流行时，以太坊平台就无法承受如此大的交易量，发生交易拥堵，费用暴涨。每当区块链取得成功的时候，我们都看到它可处理的交易量都超过了现有的能力。因此，很明显，问题在于没有足够的能力来满足人们在这些区块链上想要做的事情。这不仅仅是出于我们的想法，我们一次又一次地看到这种情况发生。在一段时间内，这被认为是一项有价值的挑战，不仅仅在我的团队，实际上整个学术界都在研究区块链，大家都在用不同的方式解决这个问题。现在，已经有相当多的技术被开发出来扩展区块链的能力，以解决这些挑战。但在当时，众所周知，很多人用不同的方式来解决它。

L2 网络是人们提出的解决扩展问题的一种方式，这与建立像 Sui 这样的新型 L1 网络，有什么区别和好处呢？

L2 是以太坊生态系统中扩展的解决方案。但是对于应用程序开发者来说，使用L2网络有点棘手。当一个L2网络尝试与以太坊进行交互时，必须进行桥接活动，虽然对于任何L2/L1的关系都是如此。在L1中代表coin、资产或其他内容的状态必须在L2中得到镜像，反之亦然。除此之外，L2还必须有一些机制，以便L1可以验证在其中发生的一切。但这仅仅是第一部分，即存在于L1上的任何资产需要转移到L2上，L2上必须发生一些活动，然后以某种方式将资产转回L1。这是很麻烦的。

对于 tokens 这种可替代的资产，这种桥接活动还算顺利，因为人们拥有两个帐户和一个桥接中间件。但是对于更一般的资产来说，效果并不好。要想在以太坊上实际使用 L2 网络开发比 tokens 更复杂的应用，您需要在两边都有智能合约，一个用于铸造（ mint ），另一个用于销毁（ burn ）。它们必须在两个不同的生态系统穿梭，这是每个合约的自定义活动。您不能简单地说，我会创建一个 L2 网络，然后把所有资产带走，然后按照自己的意愿进行操作，再将它们带回来，没有这种概念。这是一个手动的过程，非常容易出错。因此，这并不是一个很好的体验。想象一下，您在多个不同的 L2 网络上都有资产，而且在不同的 L2 网络上都有这些自定义智能合约。每次您想要对位于另一个 L2 网络上的某个状态进行操作时，您都必须一路桥接回到 L1 ，然后再回到 L2 。您不能轻松地说，我在这个区块链上刚刚做了一些事情，然后我要在另一个区块链上做另一些事情，我不需要考虑它是在哪个 L1 或 L2 上。一切都在这里，我现在就拿在手上，已经准备好在我想要访问的任何状态上进行更多交易。这就是为什么将状态分散在 L2 网络中的体验不好。在不同的链之间移动资产非常棘手，对用户来说也显而易见。这就是为什么 L2 网络从未真正引起我兴趣的原因。

还有一个例子是 Cosmos ，它拥有一个非常有趣的生态系统，采用了另一种方法，即通过为不同的 apps 使用不同的区块链来扩展。我们可以在不同的链上进行不同的交易速度，当需要在不同的 apps 之间进行操作时，可以在链之间桥接资产，但是它也面临同样的问题。每次您想要使用不同的 apps 时，您首先必须进行桥接操作，这对用户来说是微妙且显而易见的，然后您可以使用该 app 并桥接回来。您会发现自己花费更多的时间将资产从一条链转移到另一条链，而不是做您真正想做的事情。

在 Sui 上，我们的方案是建立一个大型数据库，实际上，它包含了所有被验证节点复制的状态。一旦您完成一笔交易，所有在同一个数据库中的状态都可以用于进行下一笔交易，而用户不必在 L1 和 L2 上之间不断地移动资产状态。

Sui Lutris 是 Sui 协议的基础，它的关键创新是什么，能使得 Sui 具有高吞吐量和低延迟的特性？

Sui Lutris 由两个关键理念组成：（1）对于区块链上的许多操作，实际上不需要进行共识；（2）当您确实需要进行共识时，有一种非常高吞吐量的方法，它将这两种方法结合在一起。Sui Lutris是Sui分布式系统的核心，确保在分布式网络上进行交易时，遵循协议的两个不同验证节点永远不会处于不一致的状态。从而不会出现一个验证节点认为您花了一个coin并将其发送给了Alice，而另一个验证节点认为同一个coin实际上发给了Bob的情况。

? Sui Lutris ：

https://tech.mystenlabs.com/sui-lutris-the-distributed-system-protocol-at-the-heart-of-sui

两条不同的路径，一条不需要共识（快速路径），另一条需要共识（共识路径）。当您要操作的对象仅属于您自己，例如您自己的NFT角色和您想要组合的帽子，以便您的角色可以戴上帽子，理论上其他人不应该对它们进行操作。在这些情况下，Sui使用了快速路径，它表示您可以操作自己的对象，您可以在没有等待共识的情况下获得交易的最终性，确保交易发生，帽子戴在了您的NFT头上。

但在某些情况下，交易不仅仅只涉及属于您自己的对象，它们由许多人共享。例如，如果有一个拍卖会出售小帽子，这种类型的拍卖会在 Sui 中表示为一个共享对象。人们可以竞标，出价最高的人赢得帽子。这种拍卖是一种不属于单个实体的对象，每个人都必须能够竞标、共享，并更新关于最新出价的状态，这些类型的操作需要额外的共识。 Sui Lutris 允许您拥有共享对象并在其上执行交易，从而您可以拥有其他对象，更改共享对象的状态，或创建新的共享对象。它允许两条路径共存，并且由特定个体拥有的独享对象或由多个人共享的共享对象之间相互作用。

这两条不同的路径具有不同的优势。独享对象的快速路径的延迟极低，需要的时间少于一秒，非常快，并且可以广泛地扩展。共识路径的延迟则较高，通常超过一秒，容量也相当高，但是，与第一条路径相比，它更难扩展。在 Sui 上，那些真正通过每天数百万次交易来推动链上 apps 的通常使用第一条路径，并且在很大程度上将其 app 结构化为主要在独享对象上进行最多的交易，而不是共享交易。另一方面，进行复杂工作的协议（例如 DeFi ）通常实行第二种类型的交易，因为它们必须将许多不同人的竞标或流动性结合在一起以执行操作。

Sui 上的 app 开发者是否可以设计他们的 app s以利用快速路径？

是的，绝对可以。我认为这是一个扩展 app s 设计者的核心工作。智能合约开发者完全可以控制他们在合约中操作的对象在任何特定时间内是单个实体的独享对象还是共享对象。在 Sui 中扩展 app 的一个诀窍是确保大部分操作基本上是在独享对象上进行的，因为 Sui 可以在非常低的延迟下管理您想要的许多操作，这是一种很好的体验。对于游戏所必需的操作应该在这个类别中进行，与需要通过共享状态和共享对象进行调解的操作相比，它们的延迟非常低。一旦点击，交易就可在网络上立刻完成。

智能合约设计者对此有完全的控制权，他们基本上可以准确的指定每个类别中的交易是什么。当然，合约的第一个版本可以将所有内容都视为共享状态，而所有内容都会通过较高延迟的共识路径进行，但随着需要进行扩展，开发者需要考虑在多大程度上可以做到不需要这些部分。

可编程交易区块在这其中如何发挥作用？

可编程交易区块可以在快速路径或共识路径上发挥作用。如果一个可编程交易区块只涉及您的独享对象，这意味着您可以在一个链上操作中执行多项操作。举个例子，假设您是一个CEX app，许多人在这里买卖不同的coins，您可以在链上进行一次交易，概念上对应于人们所买卖的内容。但因为您是交易所，它们都属于您，因此可以同时结算一千个交易，这是快速路径。另一方面，如果在可编程交易区块内的一些对象是共享的，那就进入了共识路径，这时延迟会稍高一些，不是不到一秒钟而是要几秒钟。

主网上线了 100 多天， Sui 的表现有证实您假设的研究理论吗？有没有什么让您感到惊讶的？

有几件事情证实了Sui的设计，但也有一些事情令人深思。一个是在交易量特别多的时候，甚至是在一个特别的时刻，每天的交易量甚至超过6000万笔，其中大部分交易是处于快速路径。 Sui Lutris 非常可扩展且具有非常低的延迟。在那之前，尚不清楚是否会有人使用这条路径，但当需要大量交易和低延迟时，它被使用了，而且非常有效！这很容易看到，就是这个方法。在那些日子里，Sui的交易量超过了所有其他区块链的总和。这是一个有趣的验证，证明了 Sui 的设计是合理的。

与此同时， Sui 社区发现这个快速路径有点微妙。因为对象的所有者在某种程度上必须管理他们自己对象上的操作顺序，有时可能会出错。有时他们甚至可能使用无法帮助他们的库，而库本身出错，因此有时对象被锁定。通常它们会在一天结束时，即一个 epoch 结束时解锁，但这并不是一个很好的体验。设计智能合约的人对此可能会感到害怕，担心这种情况可能会发生错误，这阻止了他们充分利用低延迟和可扩展性的设施。一整套技术正在被开发，允许那些被错误地锁定对象的人在几秒钟内快速解锁它们。因此，如果您尝试使用快速路径，发生错误，您的对象被锁定，那么您可以立即使用共识路径将其解锁，而无需等到一个 epoch 结束。

而且，奇怪的是，这不仅仅是为了避免错误，它还允许开发人员通过快速路径来表达更多的事情，存在一些潜在的技术，其中一些对象不仅仅是由一个当事方拥有。也许有一个对象是你和我共同拥有的，因为它是共享的，通常在该对象上的交易必须通过共识路径进行。然而，如果 Sui 有一种快速解锁对象的方法，开发人员实际上可以尝试通过快速路径进行交易。在你和我恰好在同一时间对同一对象进行交易的情况下，系统将被锁定，无法决定哪个交易发生在下一个，然后 Sui 可以解锁它，并使其经过共识路径，使其变为共享并解决它。但除非人们故意试图竞争，否则这种情况是不可能发生的。一旦 Sui 具备了允许解锁对象的功能，它应该能够让属于多个人的对象通过快速路径。这是一种试图通过快速路径尽可能多地传递交易量的游戏，这是正在开发以帮助构建者社区的一种类型的事情。

您能更详细地分享一下当前导致对象锁定的原因吗？

当一个对象属于你时，它之所以不需要通过共识来告诉 Sui 发生的一系列操作的顺序，是因为没有其他人可以对你的对象进行操作。 Sui 依赖于你告诉系统，动作 A 将首先发生，动作 B 将其次发生，动作 C 将最后发生。系统仍然必须检查 A B C 是否被所有人以相同的顺序看到。该系统通过一个分布式协议来实现，只检查我们是否都依次看到了 A B C 。问题是，如果你犯了一个错误，或者你的软件犯了一个错误。例如，如果你的手机控制你的资产，你的计算机控制你的资产，你的手机表示首先发生的是 A ，而你的计算机表示首先发生的是 B 。你错误地对两件不同的事情进行了排序。这是一个矛盾。在这种情况下， Sui 会说：“好吧，我委托告诉我顺序的人似乎给了我两个矛盾的事情，所以我不知道该怎么做。我不知道如何解决这个问题。”因为 Sui 通常通过共识路径来解决这个问题。但在这里，你正试图使用快速路径。所以 Sui 举起了它的手说：“好吧，在这里出现了一个错误。”

最初的假设是，这种情况不会经常出现，但事实证明它经常发生，因为人们使用不同的设备，或者试图在同一时间对相同的对象进行多次交易。目前，当这些对象被锁定时， Sui 会等到一个 epoch 结束才将它们解锁，这非常令人担忧。想象一下，如果你的资产在一天内无法使用，这实际上可能是一个严重的问题。

因此，现在 Sui 需要发展以在某物被锁定时采取正确的行动。如果被委托提供正确顺序的实体给出了一个不明确的顺序， Sui 将把整个情况通过共识来解决。这将在几秒钟内发生，而不是在一个 epoch 结束时发生。

您的很多研究都是围绕隐私展开的。您对公链如何最好地平衡透明度、可追溯性与隐私有何看法？

在公链中，如何平衡透明度、可追溯性和隐私，这是一个与应用非常相关的问题，而我在隐私方面的观点是，什么需要保持隐私在很大程度上取决于应用本身。例如，在Sui上，让应用开发者来开发合约以保护其用户的隐私是很合理的。因为有些人只想开发游戏，可能对隐私问题的关注不是那么大。有些人想在区块链上处理金融事务，隐私可能更令人担忧，但与此同时，还会涉及到其他种类的监管问题。所以Sui的态度是，我们会提供给你一个很好的平台，你需要在这个平台上构建隐私。

为了帮助人们构建隐私，Sui提供了一些加密原生支持，这些支持在设计智能合约时可能会对他们有用。其中最重要的一个是在Sui上验证零知识证明的能力。有一个本地函数可以验证最广泛使用和理解的方案之一，即由我的同事Jens Groth开发的 Groth16 方案。这意味着，实际上，apps的设计者可以在链下验证某些事件，而不需要透露这些事件是什么。这是构建一整类隐私友好型应用的基本构建模块，它们将一些状态保持在链外，但在链上，您可以验证链外发生的任何事情是正确的。

应用开发者决定了他们的应用需要什么样的隐私保护，并使用这些原生支持来组合链上、链下、链上加密等策略，以应对他们可能遇到的隐私问题。

在 Sui 上是否有更多的隐私原生支持？

社区正在思考开发者在更加隐私友好的情况下编写智能合约所需的支持，零知识证明就是其中之一，有些人可能会认为Sui需要更多通用的数学或密码学函数在链上。我们很愿意看到智能合约的设计者就缺失的部分提供反馈，还有其他一整类的技术可以用来保护隐私，比如多方计算或可信硬件。不同的区块链已经朝着这些方向发展，这些需要非常复杂的附加系统。社区中需要足够的证据表明人们想要这些技术，因为它们代表了对Sui架构的一些基本变化。但是如果社区想朝着这个方向发展，就会有一个提出添加隐私保护方式的流程。

您认为在未来 6 到12个月内 Sui 会如何发展？

这取决于人们在 Sui 上开发了什么样的应用，在短期内，很多改进将针对人们实际构建的应用。从非常长远的角度来看，在区块链标准下，6 到 12 个月可以被视为非常长的时间，我们将会改进 Sui Lutris 协议，以实现更低的延迟，更简单的协议，使 Sui 能够更好地扩展。此外，还会使经济更高效，使验证节点能够在更受限的硬件上运行，并将现有的硬件用于实际执行交易，而不是进行密码学或区块链的其他开销。这是我们预期将会看到的内容。