作者：Sui Foundation 编译：Cointime.com 237

最近，我们与Mysten Labs的首席技术官兼Move编程语言创作者Sam Blackshear进行了交谈，讨论他为什么开发了一种新的智能合约编程语言、Sui如何实现可扩展性以及去中心化技术对开发者的好处。

首先，您能概述一下什么是编程语言，在开发者选择编程语言时最重要的品质是什么，以及是什么促使您开发自己的编程语言？

编程语言只是一种与计算机进行友好和安全交互的工具，特别重要的是它对计算机来说要高效且明确无歧义。我们无法使用自然语言与计算机交流，因为自然语言的整个目的在于其丰富性和表达力。比如，你稍微改变一下语调或词语选择，就会使你的句子或段落完全不同。而在编程语言中，最重要的是你有精确定义的语义。当你编写一个程序时，你清楚它将会做什么。如果对其进行小小的修改，你也知道这个变化是什么。而且这种精确定义是保持在多个层次上的，比如你可以用源语言编写代码，它有一个含义，然后它被转换成中间表示，这两者应该具有相同的含义，一直到机器的硅片。

我认为编程语言与自然语言不同，它们本质上是领域特定或任务特定的。否则就只会有一种编程语言可以做所有事情。但多种编程语言存在的原因是因为你不可能擅长所有领域。它们真的在试图针对特定的问题领域进行目标化，并且非常专注于此。因此，如果看看我们用来编写Sui区块链和Mysten其他系统工作的Rust编程语言，它专注于编写非常快速和高性能的代码，同时也要安全。它让你接触到底层的内存、线程结构或并发性，但不会让你像以前的C或C++语言那样给自己惹麻烦。

Move的故事非常类似。当我创造它时，并不是为了创建一种新的语言。你问的另一个问题是开发者在一个语言中寻找什么。他们会问：“这对我想做的任务是否合适？”但我认为甚至更重要的是，“这种语言是否有一个庞大的社区？是否有很多可用的库？是否有很多程序员在使用？是否有良好的教育资源？”因为这一点非常重要，创建一种新语言的门槛必须非常高，即使语言本身更好，如果没有这方面的支持，它的优势就无关紧要。而且从零到拥有一个庞大而充满活力的社区是非常困难的。

您能分享一下Move的发展情况吗？

Move的起源可以追溯到Facebook的Libra项目。我当时的任务并不是要创建一种新的语言，而是“Libra需要具备智能合约功能，所以找出我们应该做些什么。”我研究了各种可能性。我们能否在以太坊虚拟机上使用Solidity？是否应该使用像WASM或JVM这样的常规通用语言，并将其用于Libra？还是应该创建我们自己的东西？决定创建自己的东西是基于对现有智能合约的研究，以及理解程序员试图做什么、语言在哪些方面帮助他们、在哪些方面让他们失望。我的结论是，在很多情况下，它确实让他们失望。

这一点可以从Solidity安全记录不佳看出来，但更重要的是，这些智能合约是非常非传统的程序类型。Solidity并不是一种为满足当今人们的需求而构建的语言。我并不是说这是批评，因为他们是第一个智能合约语言，他们不知道人们想用它做什么。一旦你看到人们想用它做什么，我认为就非常清楚，你需要一套与Solidity提供的语言不同的抽象和编程工具。

因此，这些智能合约非常简单。它们主要做两件事情。首先，它们定义了资产的形态，包括可以何时转移、可以做什么、谁可以读取和写入等规则。其次，它们检查访问控制策略，确定谁拥有该资产、谁被允许将其消费、谁被允许对其进行操作。一切都围绕着资产展开，而你希望这些资产具有与实物资产相同的属性。如果我把某物交给你，那么你应该拥有它，而我就不能再拥有它了。

在计算机上，一切只是比特和字节，可以自由复制。你知道，这些概念在计算机中并不存在。所以你希望有一种语言，为你提供关于所有权和可替代性的良好抽象。就像在现实世界中一样，但又不强迫程序员重新发明轮子。你希望拥有这些基本的安全保证。

这就是Move的作用，也是我们最终决定创建一种新语言的原因。智能合约编程中存在着这些基础任务，很难在其他语言中重现，包括现有的智能合约语言。我们希望设计整个语言以提供这些基本元素，使程序员能够安全高效地编写代码，而不必每次想要编写一些代码时都重新发明轮子。

Sui使用的是Move的一个变体，称为Sui Move。是什么促使了这些变化？而Sui Move的哪些特性特别适合在Web3中构建产品？

有几个因素促使了这些变化。其中一个是原始Libra项目的目标是构建符合规定的支付网络。因此，我们试图将Move设计为一种通用语言。但我们也有意识地做了一些事情，以满足Libra要求的限制条件。其中一个重要的问题是，他们不希望人们能够随意转移某些资产。他们希望人们明确地创建一个账户，并对账户创建设置一些规则，比如账户的所有者必须通过KYC认证，或者创建账户需要支付费用，或者只能由具有创建账户权限的一小部分人来创建。由于整个目的是Libra想要进行符合规定的支付和符合规定的智能合约，因此存在这些限制。但在更通用的Web3空间中，情况恰恰相反。你不希望在底层有符合规定的概念，那是智能合约的概念。你希望事物尽可能自由，完全可以将某物发送到任何地址。然后你不应该进行显式的账户创建，因为那样会阻碍各种用例。这是一个重要的因素。

另一个因素是，尽管我们在Move中专注于资产，但当时在Libra项目中并没有考虑如何将这种资产关注点引入到交易本身中。所以说，在Move中编写代码很好，但是当你到达交易层面时，你仍然只有这个API，你需要输入数字、布尔值等非资产内容，然后在Move中，你使用这些数字来从账户中获取资产并执行一系列操作。结果发现，你运行的大部分代码都是这种糟糕的簿记工作，比如取出这个东西，取出那个东西，取出其他东西，好了，我已经获得了所有想要的资产。它们就在这里，现在我可以开始做一些有意义的事情了。然后在这之后，你会说，好的，把这些资产放回这个账户，放回那个账户，重新组织它们。

在Sui中，我们思考了很多问题，如果每个程序都是以这种方式开始和结束，我们能不能将其抽象出来？因此，处理交易的逻辑将为程序员执行此操作，并且从程序员的角度看，他们只需准备好所需的资产，立即开始进行有趣的工作。这就是Sui中存在的以对象为中心的数据模型的基础。在原始的Move中，我们有一个基于账户的数据模型，资产存放在账户下面，程序员必须显式地获取它们。而在Sui中，它们通过Sui运行时已经被提取到交易的Move部分。这对程序员来说更加友好，因为他们不需要做所有这些前后簿记工作，而且这也是我们能够在不实际执行交易的情况下判断是否可以将一个事务与另一个事务并行运行、将Sui水平扩展以及更高效地执行其他操作的秘诀。

我们还做了其他几件非常有趣的事情，比如利用基于对象的数据模型的可编程交易块。这是一个稍微技术性一些的话题，我很乐意尝试解释一下。但这两个因素是导致与原始Move的分歧的主要动力。

如果您愿意，我可以分享更多关于可编程交易块及其功能的信息。

我喜欢在这里使用一个类比，其他区块链就像一个商场的美食广场。你想吃冰淇淋，你去冰淇淋摊位，拿出信用卡付款。但是如果你决定也要吃个汉堡，然后你去汉堡摊位再付款。我并不是一个暴食狂，但如果我想吃八样东西，我必须进行八次单独的交易。而Sui更像是无限自助餐。每个交易不仅仅是一个物品。一旦你支付了自助餐费用，你可以做很多事情而无需额外费用。你可以拿一份冰淇淋，你可以拿一个汉堡，你可以将它们合在一起。

为了让这个概念更具体一些，在发送100个交易以铸造100个NFT的简单情况下，你可以发送一个交易来铸造100个NFT。这样的成本大约与铸造一个NFT的成本相当。你还可以进行异构打包的交易，比如一个区块中的第一个交易从你的多签钱包中取出一个马里奥角色，而第二个交易则请求一个马里奥，然后让你玩游戏。如果你赢得了游戏并获得了一个奖杯，也许第三个交易会将奖杯放入一个与朋友分享的奖杯柜中。这其中很酷的一点是，可编程交易块允许程序员以这样的方式编写代码，使得游戏无需关注多签钱包或马里奥的存储方式。它也不需要了解你的奖杯柜或其实现方式。

可编程交易块由具有输入和输出对象的交易组成。如果一个交易需要一个输入对象，它可以获得这个东西而不用关心它来自哪里，然后将其输出传递给需要它的地方，也不用关心它要去哪里。在其他区块链中，耦合度更高，所以游戏必须与多签钱包和奖杯柜进行集成，或者它们都必须实现一些共同的接口并具有更高的耦合度。Sui使得我所说的即兴组合变得更加容易。就像是，如果管道匹配，我们可以在一个交易中完成一切。

那么对于用户来说，可编程交易块有什么好处呢？

从用户的角度来看，我认为好处有以下几点：较低的燃气费，因为你可以将所有操作打包到一个交易中，而不是分开进行多个交易。此外，减少了审批次数。如果你使用的系统需要进行交易审批，那么你只需进行一次审批，然后一次性完成所有操作。另外，我认为还有一点是原子性。如果你想做三件不同的事情，并且希望第三件事情只有在前两个成功时才成功，如果这些事情必须是分开的交易，那么就无法实现。但是如果你可以将它们都放在一个交易中，那么就没有问题。

我听说你和其他人谈到，对于程序员来说，Sui上的开发体验非常重要。你有没有任何趣闻轶事可以分享，关于经验丰富和新手Web3程序员开始使用Sui Move的情况？

对于那些使用其他Web3编程语言的开发者来说，他们在Move和Sui Move中感觉自己更加高效。同时，这种方式也更加安全。我曾经参加过一个关于Bucket Protocol的播客节目，他们正在Sui上构建一个非常酷的DeFi项目。他们在展示系统架构时，说明了不同的组件是如何协同工作的。他们说，如果他们用Solidity来编写这个项目，可能需要八个月的时间，但是通过Sui Move，他们只用了两个月，并且对其安全性非常有信心。Sui Move的编程模型与他们关于项目如何组合的想法非常接近。而在Solidity领域，这种联系会间接得多。

这只是一个例子，我们听到了很多类似的情况，人们表示他们在这种语言中进展更快，完成后对结果更有信心。这让我感到很高兴。但在某种程度上，这并不令人意外。我们研究了Solidity，并看到了其中存在的问题。我们的设计明确围绕着如何使其更安全、更快速。我们考虑了使用该语言的人们试图解决的问题，以及如何设计满足他们需求的语言，而不仅仅局限于现有的情况。这个语言是为人们所面临的问题设计的，所以当他们切换到这种语言时，他们真的能够感受到其中的好处。

他们说“先占者有优势”，但我想在这种情况下，可以说是“后来者有优势”。

没错，确实如此。

当你提到Sui Move和Sui普遍的面向对象性质时，你其实已经在谈论这个问题了。但是你能否更明确地阐述Sui Move的设计与Sui实现Web3大规模采用的能力之间的联系，特别是在低延迟、低成本和可扩展性方面？

我们在为Sui做贡献时非常谨慎，我认为这也是其他平台所面临的问题。如果你的容量有限，无论是像以太坊上的15 TPS（每秒交易数）还是100或1,000，如果是一个固定的数字，那么当平台过于成功时，它会达到容量的极限。此时，每个使用该平台的人的体验都会下降。如果只有1,000个插槽，你必须选择哪1,000个最重要，可能通过燃气拍卖或其他方式来进行选择。价格对所有人都会上涨，或者延迟对所有人都会增加，或两者兼而有之。很多用例被排除在外，因为只有支付最高费用的用例才能获胜，其他人不得不去其他地方或等待更长时间。这并不理想。

Sui的目标是水平扩展性。如果分配了一定数量的硬件，就可以实现一定数量的吞吐量。如果需要更多吞吐量，验证者可以引入更多硬件。这没有上限。这就是每个Web2服务的工作方式。当然，你必须解决一些工程上的限制和问题，这并不是一件确定或容易的事情，但是在设计可扩展的网络服务时，每个人都希望实现水平扩展性。

如果Sui获得更多客户或用户，目标是让Sui能够继续增长，并且一切应该正常运行。当然，还要保持非常低的延迟。你不希望在获得更高吞吐量的同时，却不得不牺牲延迟。

在Libra系统中，我们并没有考虑到这些属性。它是一个小规模的支付系统，每天可能有几百个支付运营商，可能有数千或数百万笔支付，但不会超过这个数量。因此，我们采用了单一框架的架构，因为这更简单且足够使用。但是对于Sui来说，我们知道Libra系统行不通，因为它缺乏水平扩展性的特性。所以我们思考，如何从头开始设计一个能够实现这一目标的系统。这就是面向对象的数据模型产生的原因。我们基本上摒弃了旧的基于账户的数据模型，因为那是导致很难实现水平扩展性的原因。而如果你将所有东西都组织成对象，你的全局状态只是一个从对象ID到对象的大型映射。这就是一个键值存储，而我们知道如何扩展一个键值存储。这是一个简单的工程问题。

然后问题就是，我们如何设计一个事务结构，使其适应从键值存储中获取数据并进行更新的过程？我们如何分片键值存储？我们如何决定哪些事务应该被处理？所以基本上就是这样。就像说，这是我们知道如何扩展的东西。我们如何将其转化为具有区块链属性、进行认证读取和使用Move等特性的系统。然后，我们如何尽可能顺利地将它们结合在一起。

从更高层次上来说，您如何向对Web2开发人员持怀疑态度的人讲述去中心化技术的承诺？

我认为区块链和加密货币本质上是一种去除摩擦的技术。存在一些障碍，使得我们在金融交易、构建应用程序或设置信息方面变得非常困难，因为信息无法跨越这些障碍，或者如果跨越了这些障碍，就需要某些第三方的帮助，而他们会因此收取一定的费用。

一个经典的例子是，如果你购买一套房子，有一个买方和一个卖方，但实际进行付款时，必须有一个第三方担保代理人什么都不做，只是坐在那里保管钱，因为买方和卖方彼此之间不完全信任。这是生活的现实。我们要处理这个问题。但是，如果担保代理人可以是双方都能查看的代码，或者经过某些第三方的审查，那么它可以免费或者以更少的费用来完成这项工作。区块链的目的并不是消除房地产担保。那只是一个应用案例。但这是一般原则。

如果不是将应用程序A和应用程序B彼此之间无法互操作，而是构建在相同的基础平台上，所以你可以让东西从一个应用流动到另一个应用，无论是应用内物品、数据、交叉推广，还是基于两者之上构建的某些第三方功能。或者想想互联网，站点通过cookie共享数据，但这些cookie只是只读元数据。如果这些cookie可以成为货币呢？或者它们可以成为可花费的对象？如果这可以成为忠诚度计划和优惠券呢？一切都内置了这个功能。这是非常抽象的，但这是潜力所在。通常，正在构建的人会认为这些是我可以使用的新超能力，用来构建更具吸引力的东西。

对于终端用户来说，即使他们不是技术专家，当他们考虑到信任代码时，您是否感觉到一种犹豫，即使另一个选择是一个不透明的大型中央实体？

我不这么认为。因为我们每天都在做这个事情，对吧？当我登录我的电子邮件时，我并不担心代码会丢掉我的邮件，或者当我发送邮件时它实际上不会发送出去。如果发生这种情况，那么我可能会停止使用电子邮件，或者使用其他提供商。我认为这在这里也是非常相似的，当然，只有很多人才能真正阅读某些内容并检查其工作原理。而且你知道，如果我想检查电子邮件，我无法做到，因为代码不在那里。所以透明度是其中一个重要方面。事实上，并不是每个人都能做到，但有些人可以进行抽样检查。此外，还有重复使用和不可变性。这就是这里的关键。当我登录电子邮件时，我不知道自上次我做了什么以来代码是否发生了变化。对此没有透明度。即使在Web3中，您可以获得这部分信息，在其他地方也无法获得。

您对Sui Move的未来发展有什么期望？

我们目前关注的许多功能都是基于我们与发布其初始批次的Sui Move包的人们的经验，然后观察他们希望如何发展这些包，并且哪些内容容易发展，哪些内容困难。Sui Move是一种非常适合第一次发布包的语言，但是，如果我要更改类型、添加一些字段、添加一些函数，以及以一种协同一致的方式进行操作，同时又不违反使用初始包的用户的信任，那就成为一个非常具有挑战性的问题。我们做的很多工作就是研究这个问题，并找出我们可以添加的语言级别特性，既给程序员提供灵活性来扩展代码，同时又保持对使用原始代码的人的信任。

我们正在研究许多与此相关的功能，尤其是枚举。我们还在研究其他与将Move连接到前端代码的体验相关的事情。我们喜欢开玩笑说，一个典型的Sui应用程序中，5%是Move代码，95%是前端代码。因此，我们非常关心这95%。我们花费了很多时间来讨论Move，但我们也非常关心如何提高另一部分的生产力，并使连接更容易。总的来说，我们如何使应用程序更多地由Move组成，以提高安全性？同时，我们如何使这95%的代码对Move程序员和非Move程序员都更加可访问。