回顾 6/30Sui AMA：与 Sam Blackshear 讨论Move 编程语言
本回顾涵盖与 Sam Blackshear 就Sui Move 编程语言进行的 AMA。
珍
无论你在世界的哪个角落：早上好，下午好，晚上好。非常高兴能与我们的首席技术官兼 Mysten Labs 联合创始人一起开始我们的Move 编程语言 AMA。萨姆，请你自我介绍一下。
山姆
当然可以我叫山姆。我是 Mysten 的联合创始人兼首席技术官，也是Move 语言的创造者。
请允许我向大家介绍一下我的 Mysten 和 Crypto 之旅。我的职业生涯是从编程语言研究员开始的；我研究静态分析和自动错误查找工具。我整天都在做有趣而深奥的数学题，以构建和实现这些工具，并在开源软件上运行它们，这样我就能找到一些漏洞，报告给开源开发者，看他们是否愿意修复它们。有时他们会这样做，这让我非常兴奋。但大多数时候，这只是有趣的数学，并不是特别实用的东西。
博士快毕业时，我有机会在 Facebook 实习。在那里，他们正试图将我们在学术界使用的技术用于生产中。那是在 2014 年，Facebook 正在从网络向移动转型。他们发现，我们必须不惜一切代价防止移动应用出现漏洞。因此，他们投资了各种技术，以便提前捕捉漏洞，而不是在事后再做。我当时正在开发这些自动查找错误的工具，并做着和以前一样的研究工作，只不过现在，我可以把这些工具放在数以万计的 Facebook 开发人员面前，实时了解他们在做什么。
总之，这是一次完全令人上瘾的体验。
对我来说，我非常喜欢在研究与生产的交叉点上工作。实习结束后，我加入了 Facebook，并在这方面工作了很多年。我做了一个关于技术的博客，研究各种各样的东西，比如缓冲区溢出数据、竞赛、节点引用，以及一些安全方面的内容分析。在这里，我形成了很多关于语言设计的观点，因为我们整天都在做静态分析，努力寻找漏洞。
从语言的角度来看，很难对自动化工具的代码进行推理，比如我正在为最终用户准备的工具。Move 的故事就是将这些关于安全性、错误和避免不良行为的想法融入到构造中，并思考从零开始设计的语言应该是什么样的？
我加入了 Facebook 的 Diem 项目，并创建了Move 。在这里，我做了大量的协议设计工作，并结识了 Mysten 的联合创始人。去年，我们跳槽加入了这家公司，我开始着手将Move 与Sui 进行新的整合。
. . .
问题 1：项目下一阶段的发展重点是什么？
山姆
今天晚些时候有一个发布公告的好机会。我认为这将在 AMA 结束后正式发布，但我们可以提前向在座的各位提供一些信息。今天，我们将宣布即将举行的激励测试网的日期。为了配合Sui 基于水的主题，我们将组织一系列浪潮。每个波浪都有两个部分：一部分是我们称之为 "水槽"（Sink）的部分，是关于网络某些部分的操作挑战--可能是验证器的重新配置，也可能是关于所有核心内容的定桩，这些都是需要解决的问题；另一部分我们称之为 "游泳"（Swim）的部分，是Move 开发人员面临的挑战。
首先，我们还没有准备好公布一些细节。但有一个暗语，你们将来会听到更多，那就是 Capybara，因为这将是第一个Move 相关挑战的主题。我们的一大重点是让网络为这个激励测试网做好准备，确保稳定性功能齐备，开发者工具链为这些新挑战做好准备，然后通过一系列浪潮积累操作经验。
在运行网络的人员中，我们正在确保做好事件响应的准备，同时确保一切安全，并为主网做好准备，我们希望在年底前实现主网。这就是我们现在的重点。我们正处于紧要关头，努力进入激励测试网。
问题 2：Move 的历史如何，它与 Solidity 等其他编程语言的区别是什么？
山姆
是的，让我分别介绍一下这些内容，尽管它们密切相关。当我在 2018 年加入 Libra 项目时，它被赋予了非常广泛的任务。任务中说，Libra 应该是一个由区块链驱动的全球支付网络，然后它应该运行任意的智能合约。
我们都是 Facebook 人，对加密货币略知一二，但主要还是计算机科学家。因此，我们的任务是探索智能合约的细节，比如人们对哪类程序感兴趣，以及编写这些程序的理想方式是什么。我们是否应该采用现有的智能合约语言，并尝试对其进行改造，使其更安全、更好？我们是否应该尝试使用一种主流语言并将其转化为智能合约语言？还是应该尝试从头开始设计？
因此，我们研究了所有这三种方案。我们真正关注的第一件事是试图为任何语言改造主流语言。这其中最重要的因素是社区，拥有大量的库，有大量的程序员了解它，有大量的工具，有 Stack Overflow 和所有这些东西。如果你能利用现有的语言社区，那就再好不过了。然而，我们发现，对于这些智能合约语言，由于种种原因，你无法使用主流语言。有一些基本要求是几乎所有主流语言都无法满足的。
其中之一就是确定性。当你使用智能合约语言时，你需要运行这些由多个验证者执行的交易，并且需要得到相同的答案。如果你的竞争对手不是确定性的，他们就无法做到这一点。因此，大量传统编程语言都被淘汰出局，因为它们没有内置确定性，而且很难改造一种语言来取消确定性。
你可以想象，在 HashMap 上迭代是非确定性的，因为这取决于 HashMap 中的地址，而你不知道在你正在使用的某个代码库的深处是否有他们使用的 HashMap。这个故事的寓意是：你不能使用这些程序，因为这些语言并不安全。还有一点，智能合约程序看起来与主流程序非常不同。它们在很大程度上以资产为中心。典型的交易会将一些资产作为输入，读取它们，写入它们，然后可能会转移它们。
在主流语言中，这些东西根本不存在，因为主流语言的层次要低得多。没有任何东西可以代表资产。没有任何关于权限的东西。没有持久性。没有账户，也没有类似交易的东西。所有这些东西，你可能都不需要。因此，我们认为，虽然使用主流语言是件好事，但基本上你必须使用这种语言的一个大的子集，并构建执行它的工具。这将会复杂得多。
我们研究了 solidity 和 EVM，看看有什么可以搭配使用。我们发现，主流语言都有一个主要问题，那就是这些程序都是关于资产的。它们是关于硬币的。它们是关于 NFT 的。它们是关于钱的。然而，在这些语言中，并没有真正代表资产的类型或值。资产的数据模型是在某个地方有一个哈希表，用户地址是哈希表中的键，资产的字节是哈希表中的值。如果你想编写一个程序，试图将资产从一个用户传递给另一个用户，你不会调用一个函数，然后将资产传递给程序，而是进入哈希表，然后在一些比特位上做手脚，试图将资产转移到其他地方。
因此，你很难在使用资产的代码中做一些最基本的事情：比如将资产作为输入传递给存储过程，从存储过程中返回资产，将资产放入数据结构中，以及将资产封装在另一个资产中。在 Solidity 和以太坊中，你无法做这些事情，因为没有资产表示法。这种语言没有类型；在底层，一切都只是字节。你不可能有这些概念。
因此，在Move 中，我们要做的主要事情是为资产编程提供正确的抽象概念，并将其融入最底层的语言中。我们有一个资源类型的概念，在这个概念中，你可以找到一些在普通编程语言中看起来像结构体的东西，但它有这些很好的保护措施，这些保护措施是你希望从物理世界中的资产中获得的。例如，你不能从头开始创建这个结构，因为那是有权限的操作。你也不能有意或无意地复制它。通常，当你在编程语言中写下 "let x equals y "时，你实际上是在复制 "y"。当然，如果 "y "是一枚在现实世界中具有某种价值的硬币，你就不会想复制它。重要的是，"y "的旧值不能再被使用，而且 "y "在同一时间只能出现在一个地方。
我们关注的另一项保护措施是防止用户通过在程序中传递硬币而忘记返回硬币，从而意外破坏资产。因此，我们拥有这些资源类型，你可以通过字节码级别的类型系统获得所有这些保证。因此，它们不会被恶意程序员或错误所颠覆，这些只是Move 程序员权利法案的一部分。
我们还试图改进许多其他方面。EVM 程序过去和现在都存在很多安全问题，比如重入性。在我们设计Move 时，DAO 黑客事件是每个人都关心的问题，它与重入性有关，因为它试图以不安全的方式重新实现稀缺资产。在Move 中，每个函数的调用都是静态的，你清楚地知道何时调用函数，在编译时清楚地知道哪些代码将被直接调用，你永远不会被试图在调用框架中间注入恶意代码的攻击者吓一跳。这样一来，编写安全代码就容易多了。对于那些试图查看代码并确定其是否安全的人来说，比如审计人员，他们可以更快地完成工作。此外，还可以构建高级工具，如Move Prover，它可以对代码进行推理。
我和Move 团队的成员都有静态分析和程序验证方面的背景，因此我们在共同设计语言时使用了一种名为Move Prover 的工具，这是一种非常先进的形式化验证工具，你可以在其中编写对程序正确性至关重要的属性。也许只有这个人才能访问这个资源或调用这个函数。系统中这些对象的总数应为 10 个。这个东西应该存在到这个时间，然后就应该被销毁。无论攻击者或其他人做了什么，Move Prover 都会为你检查这些属性在所有可能的事务、所有可能的程序执行中是否成立。
这是非常非常强大的。它就像是卓越性和正确性的最高标准。它与编译器以及整个Move 工具链融为一体。这使得编写安全代码变得更加容易。这也让审计人员更容易理解，因为他们不需要查看代码，只需查看规范并运行证明器即可。运行验证器可以确保您指定了正确的内容，并且工具链工作正常。我们认为，这将使程序员更容易专注于编写代码，而不必担心重入性等深奥的安全问题。
因此，这就是我们在创建Move 时要做的事情，也是我们一直在努力的事情，更是我们在 Diem 和 Novi 所做的事情。
问题 3：为什么使用Move 的自定义变体？与核心的Move 编程语言相比有很大区别吗？
山姆
因此，我们实际上并没有使用Move 的自定义变体。Move 的本质是一种有趣的语言。我们有意将其设计为一种跨平台语言，其核心语言并不针对任何区块链。它有字符串、布尔、整数和地址，但没有账户、交易、特定平台使用的加密技术或特定平台使用的共识等概念--所有这些东西都被抽象掉了。
实际上，它只是一种小型的核心语言，根本不涉及区块链。实际上，你可以用它来做很多不同的事情。当你想在一个特定的区块链中使用Move 时，无论是Sui 、Star Coin、Aptos 还是 0L（这些都是使用Move 的平台），你都可以用一些行为实例化Move ，针对你的区块链和它要做的事情对它进行某种专门化。
我们认为，与其他一些智能合约语言相比，这是该语言的一个非常重要的部分，因为如果你使用 EVM 这样的语言，它就会超出以太坊工作方式的许多实现细节。因此，我刚才提到的所有东西，比如地址、账户结构，甚至共识，都会在某种程度上被嵌入到 EVM 中。
如果要构建下一代区块链，就必须解决以太坊的一些局限性。如果 EVM 过度适应这些特性，你就必须继承它们。这样就很难构建比以太坊扩展性更好的新区块链，也很难采用以太坊不使用的新加密技术，也很难拥有以不同方式运行的账户，或者只是试图进行创新。
对我们来说，非常重要的一点是，我们不会将Move 与一个平台绑定，使你永远受制于该平台的设计决策。我们希望为新平台的创作者提供更多尝试不同事物的余地，从而推动整个空间的发展。但与此同时，你不必在每个平台上都学习一个新的区块链，这也是目前的技术水平。
要知道，Solana 有自己的一套。以太坊有自己的东西，如果你去 Polkadot，他们也有自己的东西。如果每个平台只有一种语言，这对于创建一个充满活力的开发者社区、可重复使用的工具或可在各地使用的库来说，并不是一个好方法。我们必须在很多很多不同的平台上工作，这些平台在引擎盖下看起来非常不同，否则，我们永远无法建立起这些充满活力的社区。我们从一开始就非常谨慎地考虑核心Move ，不过度适应平台的细节。
要回到最初的问题，还有一个绕来绕去的办法，那就是我们实际上并没有默认的Move ，但Sui 使用了一个不同的 。默认的Move 不能在任何平台上使用。在最初的 Diem 中使用的是一种特殊化，而在Sui 中使用的是一种截然不同的特殊化。
最初，Diem 本应是一个受监管的支付网络，它采用任意的智能合约，对哪些账户可以存在、这些账户中可以存在的物品种类以及账户间移动物品的规则都有非常严格的限制。有一些决定是这样做出的：你不能向另一个地址发送对象，除非那个人事先说："我想得到我的许可来接收这种特定类型的对象"。这样做是适当的，因为存在资本管制等问题；如果某个账户在某个司法管辖区，就不能接收美元。因此，未经许可不能向他人发送美元是非常重要的。
在开放的 Web3 世界中，这种情况非常不幸。您希望能够向某人空投 NFT 或向其发送代币或赠送物品，而无需他们事先明确选择加入。在Sui 中，我们允许您这样做。对象具有传输的内置功能。当你创建一个对象、一个 NFT 或任何东西时，Sui 中的转移功能并不是你必须自己实现的。它只是作为平台的一项功能内置其中，而且性能非常高。
如果你有一个 NFT，你希望有一个限制性的转让政策，你只能在某个日期之后转让它，以避免投机，或者你可能希望在转让时支付版税，那么有一种方法可以将其编码。但默认情况下，所有东西都可以自由转让，这使得建立一个开放平台要比使用 Diem 和其他使用 Diem 式实例的平台容易得多。
另一件事是，我们一直在谈论以对象为中心，以及资产对Move 的重要性。在与 Diem 集成的过程中，我们从编程的角度真正实现了这一点。从最终用户的角度来看，就交易在用户眼中的样子而言，它还没有完全实现。事务的函数签名仍然只接受一个字符串、一个地址或一个布尔值。要想知道这个事务会对对象做什么，会接触到什么是非常困难的。
Sui 交易模型是以资产为中心的；当你因为在链上发布了一个特定函数而进行交易时，该函数将结构化对象作为输入。如果你要转移一只无聊猿，这个函数就会被称为转移，然后它就会在函数中拥有一个被称为无聊猿的类型。如果你要把一只无聊猿放到某种 NFT 市场上，那么该市场也将是交易的一个显式签名。交易只能接触这些作为输入的对象。因此，作为最终用户或工具开发人员，当你查看一个事务时，就会很明显地发现该事务会接触到哪些对象，然后通过 "移动"（Moves）类型的权限，知道它要对这些对象做什么。是要突变？是否要传输？还是只能读取？
这样就能更容易地利用Move 的优势，并将其推向堆栈的更深处，让最终用户看到这些优势，而不是像 Diem 那样只是运行代码，看看会发生什么。
我们还做了一个重要的改变，我认为这对 NFT 非常重要，因为它在更广泛的加密领域得到了发展，这就是你需要创建异构集合的能力。这些集合包含不同类型的元素。当你拥有像 NFT 集合或市场这样的东西时，并不是下面的每个 NFT 都有相同的Move 类型。这样做会很不方便，因为您希望有一个收藏集，里面有一幅画，或一张唱片或其他东西。这些都是不同的Move 类型，有不同的字段可以区分。
在我们将Move 集成到 Diem 和核心Move 语言的过程中，所有的集合都必须是同质的；也就是说，它们都必须有相同类型的对象。在Move 中，我们通过明确的对象层次结构解决了这一问题。每个对象都有一个所有者，可以是最终用户的地址，但一个对象的所有者也可以是另一个对象的 ID。这样，您就可以在对象之间创建父对象和子对象的关系，并将 NFT 集合表示为一个代表集合的父对象，而该集合中的每个事物都是该对象的子对象。
例如，录音 NFT 可能是一个子集，然后绘画 NFT 可能是另一个子集，然后其他东西可能是另一个子集。使用该功能，您可以拥有大型集合，而无需每次访问集合中的每个元素都要付费，这是旧实例化的工作方式。
Sui 这些就是我们在Move 上所做的一些重点工作，我们认为这些工作已经超越了移至 Diem 的最初实例。但我们还有很多其他的想法和有趣的事情要做。我也非常期待看到其他用户在创建新的Move 供电平台时将如何使用Move 。我们为您提供了使用对象和资产进行编程的安全抽象基础，但我们也希望人们在创建新的Move 支持的平台时发挥真正的创造力，这也是我们语言的精神之一。
问题 4：Move 如何以不同格式向用户展示对象？
山姆
我认为这个问题指的是资源管理器中的显示方式。你有很多关于每笔交易的信息，你有每个对象的概念，你有正在调用的函数，你有哪个对象是付费使用的，你有用来支付汽油的费用，以及诸如此类的信息。我听说你提出的问题是，对于最终用户来说，这些信息似乎太多了。我同意这个观点。资源管理器是一个为建筑商提供的平台，而建筑商确实需要所有这些信息，这样他们才能决定使用哪种硬币来支付成本、调试出错的地方，同时还能掌握全部细节。
在资源管理器中，我们重点关注的功能是让用户能够轻松完成所有这些工作。展望未来，我认为资源管理器可能更适合区块链的高级用户，而不是最终用户。对于像钱包这样的东西，你可以抽象出很多东西，你只显示用户关心的相关细节，比如正在进入的代币或他们将要互动的牌组。
我们在Sui 钱包中做了很多这方面的工作。我想你会对用户体验感到非常满意，也会对Sui 的交易行为感到更温和、更抽象。关于钱包功能，让我感到兴奋的一件事是，我们正在开发一种叫做人类可读签名请求的东西。在以太坊、Solana 和我所知道的其他区块链中，一个很大的问题是，当你查看一个交易时，你可以看到它在做什么，函数被调用了什么，但你并不能真正获得更多关于函数做了什么的信息。这使得创建安全钱包变得非常困难，因为不可能要求最终用户查找该函数的代码，并确保它所做的事情是正确的。
这对于不懂技术的最终用户来说总是太难了。这就导致人们陷入许多骗局。基本上，人们签名是因为签名请求来自可信来源，而不是因为他们真的知道签名请求的作用。最近，在 Bored Apes 社区就发生了一起黑客攻击事件，当时他们的 Discord 被黑客攻击了，黑客说："嘿，这里正在进行一场赠送活动。点击将你的钱包连接到此交易并签名，我们会给你一个限量版的东西"。很多人都这么做了，因为他们相信消息的来源。但结果发现，这个 Discord 被黑了，然后很多人的 Apes、钱和其他东西都被盗了。
在Sui 上，我们真正希望的是，不必依赖签名请求源来保证安全。从工具的角度来看，我们希望签名请求是人类可读的，并能为你提供权限，就像你在 Android 或 iOS 上看到的那样，它会说："嘿，这里有一个签名请求"。这将允许读取你的 "无聊猿"，而 "无聊猿 "是无害的，因为它不会被转移或窃取。而如果有人的 discord 被黑客入侵，他们给你发了一条带有签名请求的信息，但工具却说 "这应该是在做促销赠品"，并允许转移你的 "无聊猿"。这时你可能会说："嘿，等一下，我觉得这样不安全。我只需要读一下这个，就可以得到我的促销品，但它却要求转让，我想我可能不会签这个字"。
因此，我们将在Sui 钱包中加入这样的功能。我们认为，这将大大降低 web3 钱包对用户的威慑力和不安全性，因为他们不必担心所有这些骗局和可能出现的令人讨厌的东西。该工具将通过向用户提供移动平台上的正常权限来保护用户，比如安卓应用会询问用户是否可以访问电话簿、麦克风和位置等。这是用户能够理解的词汇类型。
这就是为什么我们希望在Sui 上使用这种漂亮的Move 结构化表示，在对象层面提供信息，以便我们可以向用户提供这些信息。长话短说，我想你说得没错，资源管理器并没有试图提供我们想要的精心策划的终端用户体验，但我们肯定会在钱包上做到这一点，我们很高兴能展示这一点。我们拥有平台功能，可以真正实现比其他地方更好的体验。
问题 5：Sui的标准库是否也会提供随机发生器？
山姆
我想最终是的。如果你是个书呆子，并且关注Sui'共识'，你就会知道我们使用的是独角鲸图斯克。如果你读过独角鲸图斯克的论文，就会知道图斯克有一个变种，它使用所谓的通用硬币来生成共识过程中的随机性。我们还没有实现这个功能。但一旦我们实现了，我们就能将随机性作为一种平台功能，通过Move 公开。这将是一件大事，因为目前还没有另一种链具有安全的随机性。对于智能合约程序员来说，不安全是另外一回事，我想指出的是这是一个平台功能。
与此同时，尽管随机性不能成为平台功能，但仍有很多其他方法可以获得随机性。我们一直在研究一些 CryptoKitties 风格的遗传编程类型的东西，其中需要随机性作为等式的一部分。我们可以做一些有趣的事情：
- 有了交易，就有了哈希值。哈希值本身并不能作为随机性的来源，因为用户可以控制进入交易的内容，然后转移哈希值。
- 相反，你可以设置随机性，将交易 ID 和链上的一个字段结合起来，这样很多人都可以访问这个字段。
- 这样就很难预测随机数是多少、链上值的哈希结果是多少以及交易哈希值是多少。
- 归根结底，这让随机性游戏变得非常困难。
如果没有代码中的图表，很难详细解释这一点，但我们有一些在某些情况下有效的随机性方法。从长远来看，我们很高兴能将其作为平台功能提供。
问题 6：我们是否提供教程？有没有适合初学者学习这种语言的简单方法？
山姆
根据我们最近从合作伙伴那里得到的反馈，如果你来自 Solidity 世界，学习Move 非常容易。我们得到的估计是，与花费数月学习 Solana 的智能合约编程框架相比，你可以在 4 或 5 天内掌握它。
智能合约编程有一些特殊性，从根本上说是很难的。我认为最理想的背景是其他领域的智能合约程序员。Move 有强大的类型系统，编译器也很有主见，会指导你做正确的事情。一开始让你的代码编译起来可能有点困难，但工具链的设计是为了引导你获得能正常工作的代码。一旦代码能正常运行，它就会是安全的。如果从 Solidity 开始，你就不必再为重入或其他安全问题而苦恼了。
我认为，如果您使用过 Rust 语言，Move 很快就能上手。如果你是 Rust 的粉丝，或者你用 Rust 写过代码，你就会在Move 上看到很多语法上的相似之处。当Move 上的功能与相同的 Rust 功能非常相似或相当时，我们就会故意这样做。当Move 中的某些功能与 Rust 中的功能非常不同时，我们会故意在语法上加以区别，以提醒人们他们身处Move 世界。不要以为你是在 Rust 中，就认为它的行为会是一样的，因为事实并非如此。尤其是在引用类型系统方面，我们称之为借用检查器（borrow checker），Move 有一个更简单的 Rust 借用检查器版本，Rust 程序员会很熟悉，但希望也更容易学习。
我们非常关注如何让Move 变得简单易学，无论您来自哪里。我们正在开发各种教程和教育内容，以满足这些需求。现在我们已经推出了一个系列，名为 使用对象编程该系列由Move 团队的一名成员撰写，通过该变体的特殊视角，逐步介绍了如何进入Move 。我认为这可能是我所知道的最好的入门读物，然后还可以参考Move 这本书。
Move 一书由Move 的贡献者创建，托管在Move GitHub repo 上。我们的 Sui 文档.还有 Move Book是由我们的一位团队成员撰写的。这本书从头到尾介绍了Move 的所有功能。
对我来说，我总是喜欢从教程或示例开始。GitHub 上有一个名为 Sui可编程性/示例目录下有可替换代币、不可替换代币、NFT、市场和游戏的示例代码。如果你喜欢通过观察代码然后尝试模仿或修改它来学习，那么这个目录也非常不错。我认为我们有很多很好的资源，但要建立一个充满活力的社区，我们还有很多事情想做、需要做。
珍
好消息是，我们自己的内部工程团队非常热衷于发布这些信息。在接下来的几周里，我们将与他们密切合作，研究如何提供不同类型的学习材料，例如屏幕录制的逐步演示。我们还在考虑将它们制作成 GIF 格式，并通过博客文章来概述实际操作过程。就我们在这里的聊天而言，我们很乐意听取你们作为社区成员希望如何学习的建议和意见。因为这也有助于我们设计学习材料的结构，确保我们分享信息的方式对你们来说也易于消化和理解。
山姆
是的，谢谢你提出这个问题，珍。我们制作了我们认为最适合学习Move 的资源，但作为该语言的创造者，我们的出发点也很奇怪，我们既有从事设计工作的人员，也有深入研究该语言的人员。因此，我们非常希望您能就现有文档教程的优点、您希望看到的内容以及对您最有帮助的内容提供反馈意见。我们非常需要您的帮助，并对此深表感谢。
问题7：目前有什么社区发展计划？特别是因为我们知道在Sui项目上不断发展的社区对于我们的项目至关重要。
山姆
在Sui 上，我们采取了多管齐下的方法。这有点像我们的营销策略，也与社区有关。我们对Sui 上的用例最感兴趣，因为这些用例可以满足数千万用户的庞大用户群的需求，而这些需求在现有区块链上是无法以低成本高效益的方式实现的，甚至在某些情况下根本无法实现。
我们非常兴奋的事情之一就是游戏。如果你看看我们的许多早期合作伙伴，看看我们撰写和讨论的许多早期内容，你就会发现游戏已经是一种主要围绕数字资产建立的业务。与 NFTs 以及将其中一些转化为游戏资产和链上资产，以获得更广泛的流动性，从而实现同一发行商的不同游戏之间的互操作性，与品牌和其他类似有趣的事情进行交叉促销，这些都是非常自然的协同效应。
我们正在与大大小小的游戏工作室合作，研究如何利用Sui 的独特功能，将包括 NFT 在内的 web3 功能和其他有趣的想法（如链式反作弊检查或创作者货币化等）引入他们的游戏，并使所有这些功能发挥作用。
我们和构建社区的关键支柱是，你需要大量的用户，你需要大量的大玩家，比如你平台上的这些游戏公司，理想情况下，这些公司拥有大量的终端用户，你拉来几款大型游戏，你平台上的用户可能比所有 web3 的总和还要多，然后你就能展示出真正可扩展的区块链能为这些受众提供什么。
与此同时，我们也非常关注游戏之外的其他东西，有很多东西使得 web3 的经济引擎将更多地来自于智能合约开发者受众，比如构建索引、构建 NFT 市场，我们希望让那些知道如何在其他平台上构建这些东西的人能够继续在Sui 上构建这些东西。然后，利用Sui的高性能和独特功能，以及我们拥有的移动编程模型，构建这些东西的下一代版本。
然后，还有一类实体，我们都是生态系统的推动者，这就是拥有良好的读取 API，开发人员可以用它来为自己的应用程序提供服务，或查询链上发生的事件，并进行链上分析，将流动性和 NF T 从其他平台连接到Sui 。这些也是我们在合作伙伴关系和社区建设方面正在努力的方向。
当然，他们不一定是构建者，也不一定是合作伙伴，但他们对成为一名 mod 感到兴奋，而Sui 社区正在宣传Sui 用例，或Sui's token，或一起工作，或在社交媒体上关注Sui ，或撰写关于Sui 的文章并教育用户，或教育人们事情是如何运作的。所有这些对我们来说都非常有价值，所以社区并不只是一件事，我们需要考虑Sui 的需求，然后满足人们的需求，他们对什么感到兴奋？他们能如何帮助我们？我是首席技术官和技术人员，我对此有自己的看法。但我想我也想听听珍对此的看法，因为她参与了所有这些事情，而且在这些问题上经验丰富，表达能力强。
珍
这绝对出乎我的意料，感谢你们的努力。就社区而言，我想说，到目前为止，大家都非常坦诚地表达了自己的看法，我非常感谢大家私下里向我反映需要修复的问题，或者是我们反应不够迅速的问题：很显然，当我们的产品上线时，确实会出现故障或需要修复的问题，因此，虽然大家对我们存在的问题也非常坦诚，但我也想指出，当我们试图解决这些问题时，大家都表现得非常耐心。
关于我们的社区计划，我很高兴地告诉大家，我们最近请来了一位可爱的开发者关系负责人布莱恩，他将帮助我们完成很多编程工作；他还将参加即将举行的 AMA。通过他，我们还将建立适当的程序。我知道，MOD 计划本身进展有些缓慢，我们仍在处理申请，我想强调的是，我们收到了 500 多份申请，在这么短的时间内，这个数字是非常惊人的。因此，我们希望能尊重每一位申请者，并尽可能提供反馈意见。
因此，我们的项目不仅仅是基于 MOD，我们也在研究如何在未来引入那些拥有出色视觉效果的创作者。我知道你们很多人在平面设计方面都很有天赋。
最后但并非最不重要的一点是，我们如何引入地区市场？那些在当地市场拥有专业知识的人，可以帮助我们确保我们的翻译和信息能够被那些不以英语为主要语言的人所获取。因此，我们正在研究所有这些，以确保我们不仅发布我们自己的频道，而且还能确保那些可能想在他们各自的社区中分享这些资料的人也能获取这些资料，因为你们中的很多人也通过 Telegram、Twitter 或你们自己特定的 Discord 服务器建立了很多信誉。因此，我们不想让这趟列车停滞不前，当然我们也希望确保材料都在那里，这样你们就能把信息传播出去。
希望这已经回答了一些关于我们社区倡议的问题，以及我们在多大程度上努力确保我们不被封锁，并与你们携手合作。谢谢你的反驳。
问题 8：Sui 的优势是什么？是什么让我们与众不同？
山姆
是的，当然。如果让我只说一件事，那就是Sui 的设计从一开始就是为了能够应对不断增长的需求，并保持费用稳定和网络稳定。基本上，我们的创始团队，就像我们中的很多人一样，来自 Diem 和 Novi，我们花了很多年时间在那里建立了一个不错的区块链，但在区块链中，以及我们正在建立的东西中，这个区块链被设计成一个银行间结算层，它有数百个 vasps，主要是在链外进行交易以保护隐私，但最终会在链上进行一些支付，并进行一些合规性检查。我们设计的区块链有一些优点，但它的设计并不能扩展到处理任意的智能合约，也没有验证软件可以超越多台机器并使用分片，也不能实现真正的高吞吐量，超过每秒 1000 笔交易。因此，我们认为这些都是支付用例所需要的。
当我们开始开发 Mysten 时，我们当然考虑过在 DEM 平台之上进行构建，但我们知道它的这些局限性，因为我们曾在该系统上工作过，我们知道它的设计目标是什么，它不能做什么，我们研究了如何扩展它以应对运行高吞吐量 L1 的所有这些严峻挑战，我们如何处理状态膨胀？如何进行分片？如何实现水平可扩展性？我们如何实现它？如何让开发人员获得更好的体验？我们只是在想，这并不是为此而设计的，而且有一些非常基本的决定，如果我们以不同的方式来做，就会让很多事情变得更容易，并能实现我们在Sui 方面所希望的很多事情，而且我们知道我们需要这样做，因为我们当时正在与很多合作伙伴交谈，尤其是游戏方面的合作伙伴，他们说，嘿，我有 1000 万用户，我希望他们所有人每天都能进行 1000 多笔交易，我们就说，好吧，你来算算看。有一个这样的合作伙伴，就会有另一个合作伙伴加入，我们不想在容量不够时就开始拒人于千里之外，我们希望欢迎所有人加入平台，无论流量有多大，都能保持一定的规模。
Sui 如果你是一个验证者，你可以运行一台机器，获得一定的吞吐量和一定的存储量，但如果需求激增，你可以再增加一台机器，再配置一台机器，现在你已经获得了更大的吞吐量和更多的存储量，整个网络可以根据需要不断增长，以满足社区的需求。
重要的是，我们希望通过分布式系统扩展技术来实现这一点，我们不想采用一些花哨的去中心化分片协议，让验证者必须知道其他验证者运行的是哪个分片，让用户不得不担心跨分片交易等细节，以及他们刚想做某事却发现自己的数据碰巧存在于不同的分片中，从而产生不同的安全模型或成本模型的成本。用户应该这样想：好吧，这就是全局利益，我把我的事务扔进池塘，然后结果就会返回给我，仅此而已。架构可以让你做到这一点，然后为你提供横向可扩展性。
这才是我们真正关注的重点。我认为这是它区别于其他所有项目的地方，我们不以特定的 TPS 数量或类似的东西来考虑可扩展性，我们考虑的是每台机器能获得的 TPS 是多少，以及我们如何设置系统，以便我们能在需要时尽可能提高这个数字、否则，web3 的规模只能与单台机器或单个系统所能处理的最大 TPS 数量相当。
这更像是一种哲学立场，但它深入到系统设计中，深入到我们为什么要这样做，我们的目标是什么，甚至是开发者社区这样的东西，我们的人会说，哦，你知道，EVM 现在已经有了效果，就像你应该在 EVM 和Sui 中做 solidity，然后我们会看看数字，看看有 4000 名开发者正在 EVM 上构建、如果你想建立一个庞大的开发者社区来构建下一代的绝对世界，你需要的开发者远远不止 4000 人。因此，我们需要一个收购开发者的策略，既能吸引主流开发者，又能壮大智能合约开发者队伍，而不仅仅是说服开发者转行。
因此，我们所做的一切，都是为了下一个数以百万计、数以亿计的用户，以及如何让加密货币成为一件大事，而不是小众的东西。
珍
这些是我们审查过的表格中的最后几个问题，但还有不少问题是通过艺术午餐提出来的。这是一个有趣的问题，也是第一个出现的问题。观众写道，他正在写一本关于情绪模式的书，他想知道 "热土豆 "是谁想出来的？他应该把它放在哪里？
山姆
我们很久以前在 Facebook 讨论过这个问题，我努力回忆了一下，很多这样的想法都是不同的Move 团队成员同时想到的，然后反复推敲，最后我们找出了它的工作原理。我可能有一个广泛的想法，我确实有一个烫手山芋，但它与 Moves 能力系统的使用有特定的方式，而能力系统是由托德-诺瓦基（Todd Nowacki）设计的，他也是构建Move 编译器的人，你可能在之前的 AMA 中听过他的演讲。
我想把热土豆的功劳归功于托德，让你被迫使用某种东西的想法很好，但就像 "轰 "的一声，让你做到这一点的类型系统功能真的很灵活，而且可扩展的方式完全是能力的体现，所以我认为托德才是那个应该得到赞扬的人。此外，Move 的所有工作都是团队合作完成的，我们会互相交流想法，然后提出最好的版本。
问题 9：您如何看待Move 在Sui 上进行测试的前景？是更多地使用Move 编写程序？或者，人们是否会开发类似于 "硬帽子 "的框架，以便使用Move 之外的语言进行编写？
山姆
我们已经有了一个单元测试框架，您可以在Move 中编写测试，我认为这将继续成为测试Move 代码的最常用方式。
在社区中，人们一开始就像提问者提到的那样，使用硬帽子之类的东西，在 JavaScript 或其他地方编写测试。但是，当我们真的希望能够直接在 solidity 中编写测试时，你会发现有一些较新的框架，如 foundry，可以让你这样做，而且这些框架越来越受欢迎，我认为这些都是人们更喜欢的体验。
在Move 中，我们明白了这一点，并立即启动了一个测试框架，让您可以在Move 中编写测试。因此，我认为这将继续成为最受欢迎的东西，我们正在努力添加一些功能，比如符号参数，这样你就可以直接在Move 中编写模糊测试，当然，我们还有Move Prover，它可以让你超越测试或查看合约是否适用于特定输入或输入集。但是，当你使用证明器时，它可以测试所有可能的输入、所有可能的事务、所有可能的编程。因此，你可以从开发和测试工作中获得比编写测试更多的好处。
当然，这并不能取代对测试的需求，两者都应该有，但它可以让你检查那些很难通过测试来检查的东西，尤其是当你担心对抗行为或他们没有预料到的事情时。因此，我认为Move 中测试的未来是发展良好的单元测试框架，它们已经支持了花哨的新东西，比如我们的测试，但任何形式化验证工具的证明器都是一个永无止境的研究问题，你试图解决停止问题，但你永远无法具体做到这一点，但你可以渐进地接近完美，它处于一个非常好的位置。但我认为，让它运行得越来越好，让你指定更丰富的属性集，而不是运行得更快。这些都是我们一直在努力的方向，也是我们乐于去做的事情。
问题 #10：Move Prover 如何与Sui 上的Move 配合使用？有什么变化吗？
山姆
是的，它可以工作，而且我们正在努力将它集成到我们的Sui 框架构建流程中，这是一套标准模块，基本上就像所有智能合约作者都需要编写的Sui 标准库。Move 与Sui 的主要区别在于，提供商所做的很多花哨的事情都与核心Move 的存储模型有关。在Sui 中，我们去掉了整个功能和相关的复杂性，所以你不需要在Sui 中编写这些事实。
在Sui 中，您可以编写数据不变式、计数器等内容，也可以编写一个说明，指出该计数器的值始终在增加，然后您可以编写一个函数，并编写证明器检查的前置和后置条件。Sui 还会有一些特定的证明扩展，比如父子对象功能，这可能会很有趣。你可能希望能对对象间的父子关系进行改进或规范，例如，这个对象总是这个父对象的子对象，或者这个父对象有三个子对象，或者类似的情况。我们还没有添加这些内容，也不需要批准扩展，但它将真正由我们Move 程序员需要编写什么样的规范来驱动，我们将确保我们拥有合适的表达规范语言、证明器以及检查这些属性的后端支持。
这也是我们今后需要进一步研究的内容，即验证工具。Move 校验器比较容易上手，但其高级用法需要更多的学习和实践。
问题 #11：Move 与 Rust 的主要区别是什么？
山姆
为什么不使用 Rust 而用Move 开发智能合约？这是我经常被问到的一个问题，我的回答是 Rust 并不是一种智能合约语言。这里要认识到的关键是，对于智能合约语言来说，你需要在链上实际发布一些东西，然后验证器就会运行这些东西，因此对于 EVM 来说，这就是 EVM 字节码。对于我们来说，这就是Move by code，但 Rust 并不等同于Move by code，它是一种源语言，要实际运行它，你必须运行编译器，通过 LLVM，然后你就可以得到机器码，或者 wasum，或者其他类似的东西，所以你不能使用我之前说过的 In addition、Rust 没有账户，Rust 没有硬币，Rust 没有内置的持久存储模型。因此，如果你想使用 Rust 进行智能合约开发，就像 Solana 所做的那样，你实际上是在使用 Rust 作为智能合约语言，你所拥有的是一个 SDK 或智能合约语言的 API，而这个 API 恰好嵌入在 Rust 中，但它也可以是 Python 或 Java 或其他语言的 API。
有时，你会使用 Rust 的哈希映射等非确定性迭代功能，但这些功能无法在智能合约语言中使用，这就涉及到我之前提到的问题：如果能使用一种通用语言作为智能合约语言就好了。有趣的是，在创建Move 之前，我们实际上已经考虑过使用 Rust 语言，我们权衡了其中的差异，并评估了这种语言需要哪些属性才能成为智能合约语言，而 Rust 语言恰恰不具备这些属性。
因此，我们热爱 Rust，所有Sui 都是用 Rust 编写的，而且Move 的很多方面都深受 Rust 的影响。我们试图做的基本上是把人们真正喜欢的 Rust 开发和体验的东西，在语言的语法和语义上呈现出来。同时，我们还努力简化 Rust 复杂的地方，因为它需要成为一种低级系统语言，让你可以编写高效的编译器和操作系统，而Move 永远不会用于此，Move 是用于智能合约的。
因此，基本上，我们会尽量吸取罗斯的优点，然后进行积极的简化，使Move 更加平易近人。
问题 12：当链的规模呈指数级增长时，您对可扩展性有何看法，尤其是在吞吐量和验证时间方面？
山姆
我刚才谈了一点，下面我再详细谈谈这个问题，然后再谈谈验证时间，这也是一个非常相关的问题。
关于吞吐量，让我更详细地介绍一下它是如何工作的。在Sui 中，事务的工作方式是：它声明要操作的对象，然后运行时唯一需要的不是事务，而是这些对象的值，然后运行Move 代码，读取这些对象、写入它们、更新它们，等等，然后产生一些需要再次应用到数据库的效果。因此，当你需要更高的吞吐量时，你需要做的就是一旦你的数据库超过了单台机器，或者你的执行器超过了单台机器，你就把对象分割到这些机器上，然后当一个新的事务进来时，你可以说，好的，这个事务是由 Sam 发送的、然后，Jen 的事务就会到来，我们会把它发送到 Jen 对象所在的分区，事务可以完全在那里执行，不需要跨分区读取。
对于验证者来说，能够增加更多的机器并获得更高的吞吐量是件好事，但对于想要检查验证者工作的最终用户来说，如果我现在需要运行一个微型集群，那就不太理想了，这对于去中心化来说并不是件好事，很多构建高吞吐量链的人并没有考虑到这个问题，他们会想，是啊，运行验证者和全节点会很昂贵，我们认为这没什么。事实上，对于验证器来说，不增加计算能力就无法获得更高的吞吐量，但对于去中心化来说，你真的需要一个庞大的生态系统，这些人可以有效地检查链中发生的事情，以确保验证器不会做任何恶意的事情。
因此，我们解决这个问题的方法是，在Sui 中，我们有一个稀疏节点的概念，它利用了Sui 交易模型，有了稀疏节点，你可以说有一组特定的地址或对象，我们称之为因果路由，它们可以是我要跟踪的那些东西，我会跟踪所有交易，跟踪并重新执行和验证状态中与这些对象相关的所有交易。例如，每个钱包都是一个稀疏节点，负责跟踪该钱包所拥有的对象，以及该钱包碰巧关心的其他任何东西；或者，如果你是一个运行游戏服务器的游戏开发者，你可能会有一个稀疏注记，负责跟踪所有玩家的状态、游戏中的对象和游戏状态，但不会跟踪其他游戏的状态、攻击状态或其他一些与你无关的东西。因此，每个人都可以共同验证与他们的用例相关的状态中的事务，而无需支付验证所有事务的费用，因为系统中可能存在数千万个事务，这是扩展验证的一种非常好的方式，因为从根本上说，你的验证费用将与你所关心的状态数量成正比，而对于大多数最终用户来说，这可能是很小的一部分，而对于用例来说，比如一个游戏，基本上取决于他们的游戏有多大，因此他们为此付费是合适的。
这一点非常重要，公牛节点和网络只有在 TPS 非常非常低的情况下才能真正扩展。因此，任何运行高吞吐量链的人都需要找到解决这个问题的好办法，让你能够扩展验证，否则，随着吞吐量的增加，你的去中心化会受到很大影响，这是你不希望看到的。
问题 13：对于Sui ，您个人认为有哪些东西是无法或不应该在 Solidity 上实现的？
山姆
我对没有标准的下一代 NFT 感到非常兴奋，我的意思是，当你拥有像 ERC 721 或 1155 这样的标准时，我们认为它迎合了每个 NFT 都必须满足这些规则的最小公分母。因此，如果你想做一些类似的事情，比如我有一个带有一些元数据的 NFT，它可以被修改，这必须是社区聚集在一起并达成一致的另一个标准，然后它只能以满足最小公分母的方式修改，无论它想做什么，在Sui 中，一种思考方式是每个对象都是一个 NFT，每个对象都有一个唯一的 ID、你可以在 NFT 中添加新的字段，并将其设置为具有更新逻辑，你可以将 NFT 和其他 NFT 打包，你可以做父代子代对象的事情，这样就可以真正摆脱数字对象的束缚，安全快速地完成任务。
一旦创作者们摆脱了试图遵守这些限制性标准的束缚，只想做一些大家都想做的有限的事情，我很期待看到他们会怎么做。从 NFT 和数字资产的角度出发，将他们的注意力转移到他们想要创造的东西上。
我认为这将非常有趣，尤其是当你将其与Sui 的低成本和扩展能力以及我们在Move 中拥有的良好开发人员体验结合起来时。
珍
这也是Sui的产品线 "建筑无边界 "的原因所在。我们非常期待看到人们在我们即将推出的平台上创造出什么，以及他们创造的过程。我很清楚时间紧迫。非常感谢萨姆抽出宝贵的时间，带领我们了解Move 编程语言。
下周的主题仍在确定中，但不会与Move 相关。请注意，下周我们将在论坛上发布与此相关的内容。
如果您还有其他问题，请继续与我们的活动聊天室和 Twitter 账户分享。我们也一定会在下一个 AMA 系列中提出这个问题。还有什么遗言吗，萨姆？
山姆
对我来说不是。非常感谢你们，也感谢社区提出的精彩问题。这对我来说非常有趣。
珍
我们很快会再推出一个系列。谢谢大家。祝大家今天上午、下午、晚上愉快，无论你在哪里。
. . .
