波宝pro|Mysten Labs：从底层看Sui设计理念及网路规模扩容 | 动区动趋-最具影响力的区块链新闻媒体

Sui 的交易处理系统如何促成高效能网路？本文採访 Mysten Labs 共同创办人和首席科学家 George Danezis 。 （前情提要：Sui全链上储存如何革新NFT：带领DeFi走向大规模採用 ） （背景补充：深度分析 Sui 公链最新漏洞「仓鼠滚轮」为何被评为严重级？ ）

本文目录

• Q1 您来自学术领域，能介绍一下您的研究重点吗？
• Q2 你还是一个教授，那您觉得应用和研究之间有什么区别？
• Q3 从理论到实际应用时，您是如何确定要解决哪些问题的？
• Q4 L2 网路是人们提出的解决扩容问题的一种方式，这与建立像 Sui 这样的新型 L1 网路，有什么区别和好处呢？
• Q5 Sui Lutris 是 Sui 协议的基础，它的关键创新是什么，能使得 Sui 具有高吞吐量和低延迟的特性？
• Q6 Sui 上的 app 开发者是否可以设计他们的 apps 以利用快速路径？
• Q7 可程式设计交易区块在这其中如何发挥作用？
• Q8 主网上线了 100 多天，Sui 的表现有证实您假设的研究理论吗？有没有什么让您感到惊讶的？
• Q9 您能更详细地分享一下当前导致物件锁定的原因吗？
• Q10 您的很多研究都是围绕隐私展开的。您对公链如何最好地平衡透明度、可追溯性与隐私有何看法？
• Q11 在 Sui 上是否有更多的隐私原生支援？
• Q12 您认为在未来 6 到 12 个月内 Sui 会如何发展？

近日，我们 採访了 George Danezis 探讨 Sui 基础设施的複杂性和可扩容性，以及 Sui 的交易处理系统如何促成高效能网路。 George Danezis 是 Mysten Labs 的共同创办人和首席科学家（Sui 的最初贡献者），也是伦敦大学学院安全与隐私工程领域的教授。

以下为本次採访内容：

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

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

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

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

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

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

Q4 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 上之间不断地移动资产状态。

Q5 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）通常实行第二种型别的交易，因为它们必须将许多不同人的竞标或流动性结合在一起以执行操作。

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

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

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

Q7 可程式设计交易区块在这其中如何发挥作用？

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

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

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

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

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

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

当一个物件属于你时，它之所以不需要通过共识来告诉 Sui 发生的一系列操作的顺序，是因为没有其他人可以对你的物件进行操作。Sui 依赖于你告诉系统，动作 A 将首先发生，动作 B 将其次发生，动作 C 将最后发生。系统仍然必须检查 ABC 是否被所有人以相同的顺序看到。该系统通过一个分散式协议来实现，只检查我们是否都依次看到了 ABC。问题是，如果你犯了一个错误，或者你的软体犯了一个错误。例如，如果你的手机控制你的资产，你的电脑控制你的资产，你的手机表示首先发生的是 A，而你的电脑表示首先发生的是 B。你错误地对两件不同的事情进行了排序。这是一个矛盾。在这种情况下，Sui 会说：

「好吧，我委託告诉我顺序的人似乎给了我两个矛盾的事情，所以我不知道该怎么做。我不知道如何解决这个问题。」

因为 Sui 通常通过共识路径来解决这个问题。但在这里，你正试图使用快速路径。所以 Sui 举起了它的手说：

「好吧，在这里出现了一个错误。」

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

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

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

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

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

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

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

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

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

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