专访Move语言之父｜带你领略Sui Move的不同风采-Toy模板网

这篇具有很好参考价值的文章主要介绍了专访Move语言之父｜带你领略Sui Move的不同风采。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

近日，我们与Mysten Labs的首席技术官、Move编程语言创作者Sam Blackshear进行了交谈，讨论了他为什么开发Sui Move这种新的智能合约编程语言、Sui能够扩展的功能以及去中心化技术对构建者的好处。

首先，您能概述一下编程语言是什么，开发者在选择编程语言时最关注的品质是什么，以及是什么推动您开发自己的编程语言吗？

编程语言只是一种与计算机进行友好、安全、高效和明确的交互工具，对于计算机来说，这一点尤为重要。我们不能用自然语言与计算机交流，因为自然语言的整个意义是具有丰富性和表达能力的。当你用稍微不同的语气或选择细微不同的方式来表达词汇时，你的句子或段落意思就会完全不同。而在编程语言中，最重要的就是具备精确定义的语义。当你编写一个程序时，你清楚它将要做什么。如果你对它进行微小的调整，你知道这个变化会产生什么结果。这一点在多个层面上都得要保持，比如你可以用一种源语言编写代码，它有一种含义，然后被转换为其他形式表示，那它也应该具有相同的含义，直到触达机器的处理模块也是这样。

我认为，与自然语言不同，编程语言的本质是针对特定领域或特定任务的。否则只用一种编程语言，就可以完成所有任务。但之所以存在多种编程语言，是因为你不可能在所有领域都表现得很好。它们正在努力针对特定的问题领域进行目标定位，并且专注于解决这些问题。举个例子，如果你看看我们用来编写Sui区块链和在Mysten进行的大部分其他系统工作的Rust编程语言，它专注于编写既快速又高性能的代码，同时保证安全性。它让你能够接触到内存、线程结构或并发等底层细节，但不会像之前的语言（如C或C++）那样让你在其中犯错。

因此，Move的故事与此非常类似。当我创造它时，并不是为了创造一种新的语言。你之前提到开发者在一种语言中寻找什么。他们会问，“这个语言对我想要完成的任务是否适用？”但我认为可能更重要的是，“这种语言是否有一个庞大的社区？是否有很多可用的数据库？是否有很多程序员在使用？是否有良好的教育资源？”这些都非常重要，因此创造一种新语言的门槛必须非常高，即使这种语言本身更好，但是如果它没有这些因素，那么它的优势就没有意义。从零开始建立一个庞大而充满活力的社区是非常困难的。

您能分享更多关于Move的开发情况吗？

Move起源于Facebook的Libra项目。我当时的任务不是创建一种新的语言，而是“Libra需要有智能合约，所以找出我们应该做什么。”我看了各种各样的东西。我们能在EVM中使用Solidity吗？我们是否应该使用常规的通用语言，比如WASM或JVM，并将其用于Libra？还是应该创建我们自己的东西？决定创建我们自己的东西是基于对现有智能合约的研究，了解程序员试图做什么，以及某些语言在帮助他们的地方和让他们失望的地方。我的结论是，在很多情况下，现有的智能合约语言确实让他们失望。

这一点可以从Solidity糟糕的安全记录中清楚地看出，但更基本的是，这些智能合约不是非常传统的程序类型。Solidity并不是为现在人们所做的事情而构建的语言。我不是要批评它，因为它是第一种智能合约语言，它还不知道人们想用它做什么。一旦你看到人们试图用它做什么，我认为很明显，你需要一组不同的抽象和编程工具，而Solidity语言提供不了。

所以这些智能合约非常简单。它们基本上做两件事情。它们定义了资产的类型，包括何时可以转移资产、你可以用它们做什么、谁可以读取它们、谁可以写入它们的规则。并且检查访问控制策略，确定谁拥有该资产，谁被允许使用它，谁被允许对其进行操作。一切都围绕着资产，你希望这些资产具有与物理资产相同的属性。如果我把东西交给你，那么你应该拥有它，我就不再拥有它了。

智能合约中有所有权和所有权转让的概念，但在计算机上，一切都只是数位和字节，并且可以自由复制。而且，你知道，这些概念在现实世界并不存在。因此，你希望有一种语言能够为你提供有关所有权和同质化的良好抽象。就像在现实世界中一样，但无需强迫程序员重新发明它。你希望获得基本的安全保证。

这就是Move的作用以及为什么我们最终创建了这种新的语言。这些任务对于智能合约编程来说是基本的。它们很难在其他语言中重新创建，包括现有的智能合约语言，我们希望围绕提供这些基本功能的整个语言进行设计，以便程序员可以安全高效地编写代码，而不必每次想编写一些代码时都重新发明轮子。

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

以下几个因素促使了这些变化，其中一个是最初的Libra项目的目标是构建一个合规的支付网络。因此，我们试图设计Move作为一种通用的语言。但我们还有意识地做了一些事情，因为Libra希望具备的限制条件。其中一个重要的事情是，他们不希望人们能够将某些资产发送到任何地方。他们希望人们明确地创建一个账户，并在账户创建时设置一些规则，比如账户的所有者必须进行KYC认证。或者可能需要支付费用来创建账户，或者只能由拥有创建账户权限的一小部分人来创建账户。由于整个目的是Libra希望进行合规支付和合规智能合约，所以存在这些限制。但在更通用的Web3领域，情况恰恰相反。你不希望在基础层面上进行合规，这是智能合约的概念。你希望事物尽可能自由，完全可以将某物发送到任何地址。然后你不应该进行显式的账户创建，因为这将阻塞各种用例。这是一个重要的因素。

另一个因素是，尽管我们在Move中专注于资产，但当时在Libra中我们并没有考虑如何将资产的关注点引入交易本身。因此，当你到达交易层级时，你仍然只有这个API，其中你输入数字和布尔值等不是资产的东西，然后在Move中，你使用这些数字来从账户中提取资产并进行其他操作。事实证明，你运行的大部分代码都是这种令人讨厌的记簿工作，其中包括取出这个东西，取出那个东西，取出其他东西，好的，我拥有了所有我想要的资产。它们在这里，在我的工作室里，现在我可以开始做一些有意义的事情了。然后在此过程的末尾，你可能会说：“好的，将这些资产放回这个账户，将它们放回那个账户，重新组织它们。

在Sui中，我们经过深思熟虑，如果每个程序都以这种方式开始和结束，我们是否可以将其抽象出来？因此，用于处理交易的逻辑将为程序员完成此操作，从程序员的角度来看，他们只需准备好所需的资产，立即开始进行有趣的工作。这就是存在于Sui中的以对象为中心的数据模型。在原始的Move中，我们拥有基于账户的数据模型，资产存储在账户下，并且程序员必须明确地提取它们。而在Sui中，它们在进入交易的Move部分时，已经被Sui运行时获取到资产。这对程序员来说更方便，因为他们不需要进行所有这些之前和之后的记簿工作，而且这也是允许我们在不实际执行的情况下确定是否可以将一个交易与另一个交易并行运行、将Sui进行水平扩展以及更高效地进行其他一些操作的秘密武器。

我们还进行了其他一些非常有趣的工作，比如利用基于对象的数据模型进行可编程的交易块。这是一个偏技术性的话题，我很乐意深入讨论。但这两个因素是导致与原始Move的分歧的主要动力。

能请您能分享更多关于可编程交易区块及其功能的信息吗？

我喜欢使用一个类比来解释，其他区块链就像一个购物中心的美食广场。你想吃一份冰淇淋，你去冰淇淋摊位，拿出你的信用卡付款。但是如果你决定还想吃一个汉堡，然后你去汉堡摊位，再次付款。我不是个贪吃的人，但是如果我想吃八样东西，我就必须进行八次单独的交易。而Sui更像是一个自助餐，每个交易不只是一件事。一旦你支付了自助餐的费用，你可以做很多事情而无需额外花费。你可以吃冰淇淋，你可以吃汉堡，你可以将它们混在一起。

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

可编程交易区块由具有输入和输出对象的交易组成。如果你需要一个输入对象，可以获得该对象，而无需关心它来自哪里，然后将其输出传递给需要它的对象，同样也无需关心它将传递给哪里。在其他区块链中，耦合性更强，因此游戏必须与多签钱包和奖杯柜进行集成，或者它们都必须实现一些共同的接口并具有更强的耦合性。Sui使得所谓的临时组合变得更加容易。就像，如果管道匹配，我们可以在一个交易中完成。

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

对于用户来说，可编程交易区块的好处包括更低的gas费用，因为你可以将所有操作打包到一个交易中，而不是进行单独的交易。此外，需要批准的次数也会减少。如果你使用的系统需要交易批准，你只需要进行一次批准，然后它就会一次性完成所有操作。另外一个好处是原子性，如果你想做三件不同的事情，并且希望只有在前两个操作成功后第三个操作才能成功，如果这些操作必须是独立的交易，那么你无法实现这一点。但是，如果你可以将它们都放在一个交易中，那么你就可以轻松实现这一点。

我听过您和其他人谈论，在Sui上进行开发对于程序员来说是一次很棒的体验，而且这很重要。对于有经验的和新的Web3程序员开始使用Sui Move时，您有什么轶事可以分享吗？

对于那些来自其他Web3编程语言的开发者来说，他们在Move和Sui Move上的开发体验确实更加高效，而且更安全。我刚刚参加了一个关于Bucket Protocol的播客节目，他们正在Sui上构建一个非常酷的DeFi项目。他们在展示系统架构时，讲述了不同组件如何协同工作。他们说，如果他们用Solidity来编写这个项目，可能需要八个月的时间，但是用Sui Move只用了两个月，而且他们对其安全性非常有信心。这门语言的工作方式非常贴近他们头脑中项目组合的想法。而在Solidity领域，这种联系就没那么直接。

这只是一个例子，但我们听到了很多类似的情况，人们说他们在这门语言上的开发速度更快，完成后更有信心。听到这些让我感到高兴。但在某种程度上，这并不令人意外，我们研究了Solidity并了解了其中的问题。我们明确地设计了围绕如何使其更安全、更快速的方案。我们审视了使用这门语言的开发者们试图做什么，以及如何设计符合他们需求的语言，而不是迎合已有的情况。这门语言就是为人们遇到的问题而设计的，所以当他们进行切换时，他们真的会非常欣赏这门语言。

在您提到Sui Move和Sui整体的面向对象的特性时，您已经谈到了这一点。但您能更明确地阐述Sui Move的设计与Sui能够实现Web3的大规模采用、低延迟、低成本和可扩展性之间的联系吗？

我们在为Sui做出贡献时非常警惕的一点，也是其他平台所面临的问题，就是如果你的容量有限，无论是像以太坊的每秒15个交易（TPS）还是100或1,000个交易，如果是一个固定的数字，那么当平台过于成功时，它将达到容量的上限。此时，每个使用平台的人的体验都会下降。如果只有1,000个空位，你必须选择最重要的1,000个，可以通过gas竞价或其他方式进行选择。对于所有人来说，gas价格都会上涨，延迟会增加，或者两者兼有。许多使用案例被排除在外，因为只有能够支付最高费用的使用案例才会成功，而其他人不得不转向其他地方或等待更长时间。这不是一个好的情况。

Sui的目标是水平可扩展性。如果分配了一定数量的硬件，就可以实现一定数量的吞吐量。如果需要更多的吞吐量，验证节点可以引入更多的硬件设施，没有上限。这就是每个Web2服务的工作方式。我的意思是，你必须解决一些工程上的约束，这并不是一件确定或简单的事情，但是每个人在设计可扩展的Web服务时都希望实现水平可扩展性。

如果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程序员都易于理解。