原文作者：Sui World DAO
去年 a16z 等一众机构力捧以 Sui 为代表的 Move 公链，让 Move 语言在 Meta Diem 的废墟上大热归来；与此同时，从 Sui Move 出现那一刻起，不看好的声音也一直存在：
如果仅仅是因为 Move 语言有可能比 Solidity 或其它开发语言更优秀，我们就一定需要一个新的智能合约语言，并乐此不疲地从头开始搭建一个新 Layer 1 吗？
近日，a16z Crypto 团队与 MystenLabs 的联合创始人兼 CTO、Move 语言之父 Sam Blackshear 进行了一次主题为《Programming Languages Crypto》的播客对话，探讨了为何 Move 是未来智能合约的重要方向。
在该次播客中，a16z Crypto 与 Sam Blackshear 从传统编程语言与智能合约编程之间的差异和相似之处到辩论区块链的独特限制和机遇，展开讨论了 Move 语言的设计思想、面向对象和资产的编程、安全性，以及分享了形式化验证、治理和社区工具、跨平台适应性等话题。
主要分享内容包括：
1、编程语言与智能合约历史
从传统编程、到智能合约编程，再到 Move 编程。Move 是最早的关于如何设计语言以适应类型系统、静态类型和编译时检查等问题的语言。
2、Move 智能合约的创新
EVM 过度适配了平台的实现细节，这些实现细节是为以太坊设计的。开发者最终不得不继承以太坊做出的许多设计决策，包括一些让以太坊难以扩展的错误。Move 在设计时，没有将任何区块链特有的东西加入到核心语言中。源代码语言层面的创新将会相当重要，Move 最终能够提供的是代码验证器和 VM 级别的保护，以免受其他程序员的攻击。
3、Sui Move 的设计思想
Move 是一种可执行的字节码语言，用于执行用户交易和智能合约。在 Sui Move 中，验证者可以更有效地进行并行化，这使得存储、执行都变得更容易，而不必将这些东西编码到协议级别，并让用户和程序员来考虑。
4、安全性
在智能合约世界中，我们处于一个约束状态。我们编写非常少量的代码，而且必须完美无缺，安全性必须是最首先要考虑的事情。Move 安全性是既要防止程序员自我脚踏，还要尽可能为他们提供正确的原语，以便他们能够防御攻击。
5、面向对象和资产
Move 被设计为一种面向对象和资产的智能合约编程语言，之所以被设计成这样，是因为大多数 Web2 面向对象的编程语言就是这样。在 Sui Move 中，将事物的中心点放在对象上，高度激励能够尽可能精确地表示细粒度访问。Sui Move 全局存储的结构是一个从对象 ID 到对象 ID 的映射。
6、安全性对比
Move 通过构造消除了重入和智能合约编程中缺失的权限检查问题。Move 中，对象所有权信息实际上存储在对象元数据中，这不是程序员可以控制的东西。Move Prover 就是为了防止语言编写智能合约的错误而设计，可以避免开发者犯很多基本的错误。
7、智能合约语言的治理
最初，Move 是在 Facebook 开发的，没有真正的治理。我们非常谨慎地扩展语言。简洁性是最主要的东西，但我们会积极地扩展它。Sam Blackshear 有一个非常具体的愿望，比如 Move 被设计为一种跨平台语言，其中一些链 EDM 的基本功能仍应适用，并且覆盖了智能合约开发能手和 Web2 新人，极具灵活性。
8、给开发者的学习建议
阅读大量代码，这是了解语言的最佳方式。乐意分享和深入探讨，并找到那些真正喜欢和他人分享你的代码，一起构建开源社区的人们。任何可以让你的工作变得更轻松的工具，你都应该学习它的工作原理。
以下为播客全文，全文约 25000 字，阅读时间约 30 分钟。
主持人 Sonal Chokshi 介绍
欢迎来到 Web 3.0 ，这里是 a16z Crypto 团队制作的关于建立下一代互联网的节目。我是您的主持人 Sonal Chokshi。
本节目旨在为寻求了解和深入探讨加密和 Web 3.0 相关事物的任何人提供帮助，无论是开发人员、创作者、建筑师、企业领袖还是政策制定者。我们现在开始全新一季的节目。今天的节目主要讨论编程语言和加密货币，既适用于现有的智能合约程序员，也适用于其他寻求进入这个领域的开发人员。对于那些对编程语言的演变和出现感到好奇的人来说，这也是一个不错的选择。
我们今天的特别嘉宾是 MystenLabs 的联合创始人兼 CTO Sam Blackshear ，该公司正在为 Web 3.0 的去中心化未来打下基础。Sam 在编程语言方面有着资深的历史，从他的博士学位到在 Facebook 工作，再到创建并成为 Move 和开源编程语言的作者，用于构建智能合约。我们将更多地谈论这个话题。
在整个节目中，我们还邀请到 a16z Crypto 的智能合约研究工程师 Noah，他和另一位伙伴最近为以太坊开发了名为 Helios 的轻量级客户端并赢得了具有挑战性的 gas 优化。
我们还邀请到 a16z Crypto 的工程师负责人 Eddy Lazzarin ，在此之前，Eddy 在 Netflix 从事软件工程，在 Facebook 从事数据工程和数据科学。需要提醒的是，以下内容均不构成投资、商业、法律或税务建议。
编程与智能合约的历史
主持人 Sonal Chokshi：
我们将从传统编程的历史开始，第一个发言的是 Noah，接着是 Sam Blackshear 和 Eddy。
a16z Crypto Noah：
我们想了解编程历史如何影响智能合约编程的历史，因为我觉得有三个东西，传统编程、智能合约编程，还有 Move 语言。这三件事都有它们自己的历史，对吧？
Sui CTO Sam Blackshear：
没错，我喜欢这种框架。人们用语言来设计语法或让人感到开心，这是对的，但它不仅仅是这些。所以我很喜欢这种大局观的框架。
a16z Crypto Eddy Lazzarin：
就在这个基础上，传统编程有着过去二三十年来的各种趋势。传统编程语言已经发生了变化，有一些热门话题来来去去。曾经有很长一段时间，动态编程语言和非常宽松的类型检查是非常受欢迎的。通常认为，跳进去，忘记类型，忘记所有技术细节，只是编写代码是更符合人体工程学的方式。
Sui CTO Sam Blackshear：
但最近，人们开始更深入地思考类型系统、静态类型和编译时检查等问题，以便在程序运行之前尽可能了解程序的所有细节。这些趋势不断变化。然而，对于智能合约编程来说，由于它是如此新颖，我们还没有看到智能合约编程中这种类型的历史，这是非常不同的。
我认为 Move 语言是我们所看到的最早的关于如何设计语言以适应这一点（类型系统、静态类型和编译时检查等问题）的证据。我很想了解我们期望会发生哪些变化，例如静态和动态类型等智能合约编程中可能出现的话题？这些话题可能还没有出现，因为目前只有一种语言，即 Solidity。
主持人 Sonal Chokshi：
那么，这又与转向智能合约编程有什么联系呢？再次请 Sam 回答？
Sui CTO Sam Blackshear：
在这个智能合约空间中，随着 EVM 作为智能合约语言的第一批进入者，存在着不同的趋势。人们不知道想用智能合约做什么？我们如何编写它们或任何这些类型的事情因此，我认为灵活性更加重要，以尝试了解需要发现使用情况的专家的类型。我感觉现在我们已经知道了，或者至少我们对构建块有一些了解。
智能合约的趋势是极其领域特定的，你为资产定义模板，定义转移资产的策略，检查访问控制和权限。
这就是基本的，你不会用智能合约语言编写编译器或操作系统或任何这些类型的事情。因此，它们非常非常好，它们与通用编程语言相比的优势。
我认为人们低估了即使 ERC-20 标准发生在 EVM 可以编程的很久之后，EVM 甚至被认为是编写以太坊程序的基本构建块之一。我只是没有看到任何显而易见的证据，证明最基本的东西在此之前是明确的。
所以你是对的，现在你可以把类型当作理所当然的事情。我认为类型和这些东西的绕过，是可以承受一定技术债务的。如果规模很小，你只想快速移动，而且代码可以扔掉，那么这种技术债务是完全可以接受的。但有趣的是，你把它用公司或创业公司的规模来描述，小公司在快速成长，每个人都能理解整个代码库，这种技术债务是可以容忍的。
但是，当它非常非常大时，有大量的人更改代码，他们不知道正在构建的新对象和系统的后果。将其放入类型系统中，使您以明确、直接的方式编写代码时遇到障碍，而不是意外地创建后来有人会撞上的玻璃围栏。
例如，就像你们谈到的，能够防止复制，能够设置资产的最大供应量。这些约束非常重要，无论项目的规模如何，都需要保持。它们是维护项目的健全和安全非常重要的约束条件。了解这些界限意味着您现在可以创建编程语言，以允许您强制执行它们。这就是我如何看待 Move 语言的方式。
随着我们了解到需要做正确的事情所需的约束类型，我们现在有能力将它们包含在语言本身中。因此，我确实认为它与类型有些相似，就像你所说的那样。
你提到类型对于程序的健全性和安全性非常重要。你们说动态类型可能适用于小型项目，但随着项目的增长，应该使用静态类型。我有点不同意，我认为完全静态的类型可能更适合。这可能是一个新颖的看法。它是为了程序员的健全性。我见过最可怕的事情是，当我按下我的快捷键「control k」时，它会告诉我函数签名是什么。当我写 Python 时，这让我感到恐惧。我看着函数签名，只看到参数的名称。我就像，你到底想要我做什么呢？
a16z Noah：
我不敢相信人们会接受那种写出代码后就永远不会再看一眼的写法。
a16z Eddy Lazzarin：
他们接受的是默认假设，即他们可以在心中记住系统的要求。
a16z Noah：
但是即使是 100 行的程序，我也觉得无法默认这一点。
Sam Blackshear ：
它可以运行，但它并不完美。
a16z Eddy Lazzarin：
我认为你们说的对。而且我认为这种心态已经演变了。以前，类型系统是用来保护程序员免受同事伤害的。当你的创业公司变得太大时，它就很有用了。但现在它更像是在保护我自己。
在智能合约的环境下，它是在保护我免受攻击者的攻击。这是真正的不同之处，因为在普通程序中，你不会在攻击者受到类型系统的约束时部署程序。攻击者可以使用其他语言编写机器代码。你只需要保护你自己的防火墙就行了。但在这里，我编写这个很好的类型对象，它将流入攻击者的代码并保持其完整性。类型系统必须保证我的安全。
就像你说的那样，这是一个很棒的工具，它给你带来了不同的需求，你需要强制执行它们，比如防止复制。这不是你在普通类型系统中需要考虑的问题，或者防止删除或确保你按某种方式使用或销毁某个值。这些都是因为我们正在研究智能合约并试图为这些用例提供有意义的类型系统，因此我们最终会将这些东西加入 move 中，也可能会加入未来的智能合约语言中。
主持人 Sonal Chokshi：
实际上，伙计们，让我们更多地谈谈传统编程和智能合约编程之间的其他差异。但在我们进一步讨论之前，你们能不能快速介绍一下智能合约程序员可以使用的语言呢？我认为我们需要了解一下大局，因为我想了解一下现状，比如 Solidity、Viper 等。知道哪些内容能够让我们更快地入门。
Sui CTO Sam Blackshear ：
是的，我想基本的情况是，如果你想编写智能合约，你几乎总是会使用 solidity。除非你恰好在几个其他较小的生态系统之一。
如果你在 Polkadot 生态系统中，你会使用 ink!（Sui World 注：ink! 是由 Parity 开发的智能合约语言，用于在 Rust 中编写智能合约并编译为 Wasm 代码），它是一个现有的编程语言。如果你在 StarkNet 生态系统中，你使用 Cairo（Sui World 注：Cairo 是 STARK 证明系统的其中一个编程语言）。
但是大部分情况下，如果我要给出建议，让你学习如何编写智能合约，我会建议你学习一些 Solidity，然后学习 EVM。你可能还想使用 Viper，唯一的缺点是 Viper 是较新的，可能更容易出现漏洞。我记得几年前，在验证存款合约时，他们发现了 Viper 编译器中的一堆漏洞。发现这些漏洞的人现在在 16 z 工作，他是 Day June，他是一个形式验证专家。
因为 Day June 是形式验证专家，所以现在在 a16z 工作。而现实情况是，你需要学习一些内容，你需要学习一些语言。
你甚至需要深入了解 EVM，如果你想成为一个真正优秀的智能合约工程师，你需要了解 EVM 到一个荒谬的程度，以至于你可以说出每个操作的 gas 成本，他们能够告诉你确切的与 gas 成本有关的代码。这就是我们目前生活的世界。
a16z Eddy Lazzarin：
也许有一点值得一提的是，作为一名软件工程师，你总可以了解你正在运行代码的机器。有很多需要了解的关于编程环境的知识。但是在智能合约编程中，环境非常丰富、非常复杂。有很多上下文需要了解，这几乎与语言本身无关。这就是在你周围发生的事情，周围有哪些对象，不同的代码如何被调用。这是一件非常奇怪的事。
主持人 Sonal Chokshi：
那么，最接近学习 Solidity 的人是懂 JavaScript 的人，这是真的吗？
Sui CTO Sam Blackshear ：
大家都说是 JavaScript，因为它使用「function」这个关键词，就像 JavaScript 也用到了。但不幸的是，它们并不是非常相似。
a16z Eddy Lazzarin：
从语法上看，Solidity 确实继承了很多 JavaScript 的特性。如果你眯着眼睛或情绪不好，可能会觉得相似，但实际上完全不同。虚拟机环境差异巨大，所以共同点很少。
主持人 Sonal Chokshi：
有什么相似的编程语言吗？
a16z Noah：
是的，我认为没有直接相似的编程语言。如果你熟悉 Was（Sui World 注：WebAssembly Studio，一款在线工具，用于将 C/C++ 和 Rust 代码编译为 WASM 格式。 ），并试图在一个需要高度隔离的环境中写代码（比如 Surplus），这可能是最接近的了，这些代码要独立执行，但又需要一定程度的通信。但它仍然不是很相似，思维方式完全不同，表面上的相似可能会有危险。
a16z Eddy Lazzarin：
也许相关的是编程语言历史上的一些重大错误。我不知道在区块链方面是否有一些走下了错误道路的恶劣历史。我们是否走了一些可怕的道路？
主持人 Sonal Chokshi：
这是个好问题。
Sui CTO Sam Blackshear ：
这是个好问题。1977 年，C 语言发布，也是 Standard ML 发布的年份。Standard ML 具有极大的影响力。现在，有 OCaml 语言、Rust 语言都受到其极大的影响，Move 语言也受到其影响。但这些思想已经存在了很长时间。我想很多人都在思考一个替代的未来，在那个未来中，C 语言没有成为主流，而是 Standard ML 的思想被广泛接受，如强类型、内置安全性。
主持人 Sonal Chokshi：
那么，这种计算机技术的发展趋势是什么呢？我并不是说这是一个错误，但是我认为像 Standard ML 这样的语言即使在今天看起来也非常现代化。想象一下那个另类的宇宙是一个有趣的事情，当我第一次发现时就被震撼了。
a16z Eddy Lazzarin：
好奇心作祟，为什么你认为像 C 语言以及类似的语言，它们如此直白、如此命令式？它们在相对较低层次上思考计算机，作为编程语言它们并没有做很多事情，这就是我对 C 语言的看法，为什么我们走了这条路？
Sui CTO Sam Blackshear ：
我认为当时的硬件限制迫使你使用 C 语言，如果你想要编写高效的程序，或者推动计算机的边界，我认为如果你向前推进硬件，你会选择另一条道路。但是我认为，函数式编程很难，它在很多方面都是反直觉的。我不是说 C 语言不难，但我觉得它更容易入门。然后你意识到，我已经做了非常复杂的事情，或者说很难推理，但是为时已晚。这是个好点子，函数式语言确实有更陡峭的学习曲线，但是一旦你掌握了，你会意识到，我可以很好地独立地思考我的代码，事情很好地解决了。
a16z Eddy Lazzarin：
我认为如果你很多地思考计算机是如何在硬件层面上工作的，那么像 C 语言这样的语言就更直接了。但如果你对编程语言不是很了解，那么 C 语言就更容易入门。但是如果你非常了解编程语言，那么我认为 ML 和函数式编程这些类型的语言有更多的东西值得去探索。
Sui CTO Sam Blackshear ：
这是一个大局观的答案。但我想说的是有关小规模的「计算机语言错误」的问题。
a16z Noah：
所以，我对此有些犹豫，因为我一直听说函数式编程有多棒，但是我发现有点难以理解。但我一直想知道的问题是，如果函数式编程真的那么好，为什么它从未能够克服当前编程语言的网络效应呢？它的这种局面令我惊讶。
但我想补充的一点，我认为函数式编程给我们带来的巨大贡献是，我们使用的所有命令式语言都是借用的。但最好的是，就像你刚才说的，Rust 受标准电子邮件的影响很大，但 Rust 基本上是一种命令式语言，对吧？但它拥有所有从凝视他们而来的奇妙的仙尘。
Sui CTO Sam Blackshear ：
总的来说，我认为真正的问题是，从 1977 年开始，命令式语言的影响力太大了。然后是 PRFP，正如你所说，它不是最伟大的，它有自己的伟大想法，孤立地看，每个人都有自己的问题。我们现在只看到像 Rust 这样的真正的混血儿漂亮地嫁给他们。它真的改变了景观。
所我想提的一件事是，就是 Tony Hoare 称之为节点引用的十亿美元错误。虽然他当时可能是想夸张一下，但显然这个错误带来的代价比不犯这个错误更加昂贵。
a16z Eddy Lazzarin：
不，这可能只是下限。
智能合约的创新发展
a16z Noah：
我其实很好奇你没怎么谈虚拟机层和编程语言层的创新，以及它们如何影响智能合约的发展。
Sui CTO Sam Blackshear ：
这是个很好的问题。我认为人们没有充分考虑这些区别，比如虚拟机层和编程语言层的区别。实际上，除了 EVM 和新的虚拟机层，还有很多创新，比如 Viper 等源代码语言。这些东西在很多方面都比 Solidity 更好，也很有趣。
我认为，如果 Move 能够成为我们期望的 Web 3.0 的法律标准，那么虚拟机层的创新将会是缓慢而渐进的。因为核心是固定的，我们只会添加新的东西，而不会彻底重新设计。
但是，我认为源代码语言层面的创新将会相当重要。现在，我们只有一种源代码语言，但它与字节码格式紧密相连。但是，随着越来越多的客户使用智能合约，并强调安全性，我可以想象将会有很多不同的源代码语言需要尝试，这是一个有趣的研究领域。也许你可以先写下你之前的事实，然后在程序中为你综合他们的信息，或者对限制的建议。
也许你可以从编写你的 Move 以前的事实开始，然后通过合成程序为你填充程序，或提出限制的建议。
比如，你可能在一个非常特定的游戏上下文中编写 Move，这个游戏看起来像场景层次结构。也许它是用 Python 库编写的，但是编译成 Move 的字节码。也许你像 Solana 或其他平台一样，正在考虑整合 Move，但不想整合虚拟机，而是通过将 Move 的字节码编译为 Salina 的字节码格式，然后在开发者级别使用 Move 源代码语言。
我认为有很多不同的方法，就像 JVM（Java Virtual Machine）一样。JVM 是一个美妙的通用虚拟机，最初只支持 Java。但它经过了时间的考验，并且现在你有 Scala、Groovy 和其他一些有趣的方式来使用这些原语来设计不同的编程体验，非常符合人们想做的事情。
所以，我有一种偏见的看法，认为 Viper 可以给你很多在源代码语言层面进行实验的空间。
a16z Eddy Lazzarin：
你对所有替代 EVM 字节码语言的看法如何？比如有 FE、Iron 和 Viper 等，这些有趣的努力旨在为 EVM 构建更智能、更复杂的语言，你对此持乐观态度吗？
Sui CTO Sam Blackshear ：
所以这些都是编译成 EVM 字节码的不同源代码语言。
a16z Eddy Lazzarin：
对，编译成 EVM 字节码。
Sui CTO Sam Blackshear ：
我们在 Facebook 开始设计 Move 时，看到其他源代码语言构建 EVM 的情况时，我们研究了 Solidity 和 Viper，这是在我们开始构建 EVM 的时候。我们最终得出的结论是，让人们编写安全的智能合约最困难的问题是 EVM 的底层性质，以及如何让类型化的值在可信边界上流动，以及动态决策等等这些问题，这些都是 EVM 的特性。
如果你构建一个更好的源代码语言，你可以让开发者更难搞砸。也许他们可以进行更高级的验证，但最终，Move 能够提供的，而且我们认为很重要的是，代码验证器和 VM 级别的保护，以免受其他程序员的攻击。
源代码语言不能给你这个，必须将其内置到 VM 中，无论你在 EVM 上迭代完美源代码语言多少次，我认为 Solidity 很棒，我们也可以做得更好，但我认为，如果你没有这些基本的保护措施内置到 VM 中，你得到的结果最终会不如一些其他路径。我不是因为我认为 Half 很酷而感到尴尬，而是因为我认为最终状态不如其他路径那么吸引人。
我认为早期智能合约语言，特别是 EVM，过度适配了平台的实现细节，这些实现细节是为以太坊设计的，内部包括了关于交易结构的指令，账户结构的指令，使用特定类型的密码学等等。
我认为这使得在一个不像以太坊那样的链上使用 EVM 变得非常困难，你最终不得不继承以太坊做出的许多设计决策，也许在某些情况下，还要继承一些让以太坊难以扩展的错误。
在设计 Move 时，我们非常清醒地意识到不要将任何区块链特有的东西加入到核心语言中，尽可能地让它与具体的区块链无关。
这样你就可以拿着 Move，在一个具有疯狂交易结构的工作量证明链上使用它，这个链可能是在瑞典这样做，而另一个链在澳大利亚是这样做的。这样，你就不必押注在某个特定的链上成为一个 Move 开发者。你可以将你的技能跨越各种不同的链使用，包括未来的链。我们认为这对于一个智能合约语言的生存至关重要，因为一个语言最大的资产就是它的社区。而通过使你的技能跨平台，而不是过度适配于一种语言，你可以扩大社区的规模，从而更好地实现成功。然后，一个大的社区是使得在工具上投入大量资金、在公共库上投入大量资金以及所有你真正需要一个语言成为大牌并取得成功的东西变得可能。
这是我们从一开始就尝试做的事情，现在看到了多个真正不同的 Move 链，它们在如何整合语言方面非常不同。
a16z Eddy Lazzarin：
在我看来，这是 node.js 底层的主题，对吧？
主持人 Sonal Chokshi：
是的。
a16z Eddy Lazzarin：
有很多人知道 JavaScript，他们想做很多事情。他们想共享各种库。现有的代码可以启动服务器端的 JavaScript 实例，这使得 node 变得有用。这意味着有各种各样的开发者可能不做后端编程，但可以开始进入并将其作为自己的领域。
Sui CTO Sam Blackshear ：
我认为这个对比很好。另外，我们想要谈谈关于编程语言治理的问题，因为 Node 显然有一些非常引人注目的治理分歧和分裂，每个编程语言社区都有许多引人注目的治理分歧和发展方向。我曾经报道过 Node，它是我最喜欢的之一。但我想确保我们完成这个主题。还有别的要说的吗？我觉得你是我们广播节目中的居民老古板，我很喜欢。
a16z Noah：
所以我有一个反面观点，或者说我有一个很酷的想法。我一直在想，为什么没有人建立一个 Move 的 OP Rollup，那将会非常酷，考虑到 OP 的 Rollup 人们是在以太坊上实现的，他们使用 MetaMask 和 ECDSA 签名，但似乎并没有使用与我们相同的签名格式，比如 Move 似乎没有使用 ECDSA。
Sui CTO Sam Blackshear ：
是的，我们支持以太坊的 EdDSA 和 ECDSA 签名格式。
a16z Noah：
很完美，但我的观点是，你可以构建一些非常有趣的东西。但是，当我试图学习 Move 时，我一直在盯着甜点和演员狗。我很困惑。
Sui CTO Sam Blackshear ：
确实是一个问题，对吧？当有人开始学习 Move 时，他们可能会很困惑：我正在学习智能合约语言，但区块链在哪里？如果你试图为两个平台编写代码，它们之间的差异也会产生问题。所以我认为我们仍在努力解决的挑战是，选择一个平台，选择一个甜点，选择一个 Optus，深入学习它，然后你会发现你的技能和代码可以很容易地转移到另一个平台上。我认为这里存在一些固有的问题，还有一些文档问题需要解决，以使这一切更加容易。
a16z Eddy Lazzarin：
也许类比一下，取决于你是否认为 SQL 是一种可移植的技能。有很多 SQL 方言。有一个反 SQL，没人真正知道它是什么，但他们能学会 SQL，如果你稍微眯眼睛，你可以使用任何数据库，可能会对特定的函数名称或特定的类型有些困惑，但大致是相同的形状。我认为这使得 SQL 很强大和耐用。这就是为什么它仍然是数据的共通语的一部分的原因。也许这就是 Move 的未来。我认为我们可以做得更好一些。
Sui CTO Sam Blackshear ：
我认为在跨平台方面，这是一个很好的目标，非常应用程序特定。这就是正确的语言来谈论表格和谈论数据库。这是一个无可争议的事实，这就是为什么每个人都使用它。所以，如果 Move 能成为区块链中的 SQL，我会很高兴的。
智能合约编程的独特事物
主持人 Sonal Chokshi：
我们已经围绕着传统与智能合约编程、特定约束和差异以及甚至一些 Tread 和智能合约编程之间的相似之处来回讨论了。有没有关于智能合约编程的独特事物，我们没有涵盖？
a16z Eddy Lazzarin：
在智能合约上下文中，另一个非常重要的事情是资源使用，如 Solidity 中的 Gas Metering。虽然在很多情况下，计算资源是相对丰富的，计算成本也是非常重要的。但是在智能合约上下文之外或区块链上下文之外，这意味着它仅被涉及和考虑得更少。我认为在语言中有关你消耗的资源的概念可能是智能合约编程的一个有趣的资源。
Sui CTO Sam Blackshear ：
这是我们非常关注的事情，我们在 EVM 中构建了 Gas Metering，正如你所说，这与传统编程语言非常不同。
我认为今后的趋势是 Gas Meeting 会变得越来越粗粒度，更多地防止如资源滥用之类的严重问题，而不是真正地为每个指令精打细算。
我实际上认为像 Gas Golfing（Sui World 注：Gas Golfing 指的是在一系列智能合约的跳转交互中，开发者编写最节省 gas 代码的挑战）这样的东西虽然非常有趣，但实际上对编码风格和安全性都有很大的伤害。
讽刺的是，我们之所以只知道按指令收费的模型，可能是因为如果你有一个庞大的虚拟机，运行 10 万条指令和运行 50 万条指令的差别在实际测量运行时间时微不足道。
所以，我们为什么要按指令收费呢？因此，我认为我们会看到一种趋势，就是如何使这更加粗粒度。
每当我看到所有这些不安全的块和 Solidity 代码中的大量内联汇编时，这让我想起我们现在处于多么早期的阶段，因为这不是智能合约开发人员应该考虑的编程挑战，这不是一个成熟的开发生态系统的标志。但我们正在朝着这个方向发展。我同意我们要考虑极限情况。选择正确的算法、选择正确的数据结构、选择正确的一般方法，这是大多数软件工程的情况，都是很重要的。但关于准确计算每条指令的成本的琐碎问题可能太过繁琐了。
主持人 Sonal Chokshi：
我们谈到了优化 gas，类型、资产和安全性。还有哪些限制是需要考虑的？
Sui CTO Sam Blackshear ：
这是一个类似于 gas 的线程，但我想到的具体子集是状态。这对我来说是一个大问题。当我考虑 gas 操作时，我喜欢进行极端的 gas 优化。
但是，当我们处理持有真实资金的实际智能合约时，我的一般建议是，除非你可以费尽心思地使用略少于之前使用的状态，否则你应该做出合理的组织。那是唯一一次我会使用大型汇编块的情况，如果你可以做出一些愚蠢的事情来使用更少的状态，因为这就像一个永远的资源，我们应该将它放在仅高于执行或调用数据的位置。
a16z Eddy Lazzarin：
我完全同意这个观点，因为我认为这是根本性的昂贵的问题。如果一个平台允许每个合约都触及任何一块状态，那么它将很难实现并行化。而像 Squeeze 以及其他一些新的区块链平台所采用的方法是，显式地限定交易可以访问的状态，至少让我知道一些。这样在高层面上平台就能够更容易地将交易实现并行化，包括执行和共识。因此，这是一些程序员必须思考的问题：在访问状态时尽可能地快，不要触及不需要的状态，这样验证者才能更有效地实现并行化，实现更多的区块空间。
a16z Noah：
这是否会打开一种世界，即即使在非角色扮演的情况下，不是所有验证者都需要下载全部状态？如果你能很容易地将状态分离开来，让验证者仅服务于它能处理的事务，这是否可以实现？
Sui CTO Sam Blackshear ：
我认为这确实有可能实现这样的世界。这也为不同的方法开辟了一条道路。
让我回顾一下，从程序员的角度来看，能够跨不同的交易触及整个世界是非常有价值的。但是，我们不能过于强调这个优点，以至于必须通过 Rollup 或者跨多个交易来实现，因为这会降低安全性，让用户注意到。
我认为区块链的价值来自于这样的抽象：有一个账本，所有有价值的状态都在这个账本上，我可以一次性触及它们。从程序员的角度来看，这是区块链的价值所在。问题在于：如何在幕后让事情更有效地进行？如何让它变得更加稀疏，使得验证者可以更有效地进行并行化？在 Sui 中，一个验证者可以有多个工作人员，每个工作人员负责一部分状态。但从程序员的角度、甚至从其他验证者的角度来看，它看起来就像是一个逻辑实体，它可以完成一切工作。
这使得存储、执行都变得更容易，而不必将这些东西编码到协议级别，并让用户和程序员来考虑。
智能合约编程思维方式上的改变
主持人 Sonal Chokshi：
我们刚才讨论了一些与智能合约编程相关的独特之处。还有哪些思维方式上的改变？我们已经谈到了一些，像 Eddie 提到的，一个巨大的转变是，在编程的世界中，至少自从计算机的早期，我们处于丰富的世界，但在这个世界中，我们处于限制的世界。那是一个思维方式的例子。还有哪些思维方式的转变？特别是对于你们每个人来说，作为你们接触智能合约编程的程序员，有什么让你们感到惊讶，或者教会了你们，或者让你们对某些事情有了不同的看法？
a16z Eddy Lazzarin：
也许一个有点傻的例子是，我还记得几年前我第一次学到 ERC-20 Token 的余额不是你的账户拥有的东西。你的地址没有 Token 余额。代替它的是，有一个 Token 合约，记录着哪个地址有多少余额。当你想要向某人转移 Token 时，你不是发送给他们一些 Token。相反，你需要到合约中进行所有这些低级别的操作，改变你的地址和他们的地址所持有的余额。你有权限操作和改变那个合约。这是一种非常反直觉的方式，在 EVM 和 Slippery 中这是第一次让我注意到的关于 Move 的一个有趣的思维方式转变。这是有趣的思维方式转变，因为我们经常听到的英文单词不一定与编程模型相对应。
Sui CTO Sam Blackshear ：
我想要补充一点，这与你在实际操作时有关。在正常的世界中，我们非常关注开发人员的生产力，因为工程师的工作是编写大量代码，让这些代码只有几个错误，并且这些错误不会太严重。而在智能合约世界中，你的工作是编写非常少量的代码，而且必须完美无缺。它必须在所有可能的方面都是完美的。否则，你将失去数亿其他人的钱。这是一种完全不同的思维方式的转变。花费两个月的时间盯着 1000 行代码，并尝试想出如何使其更好、更重要的是，如何使其完美，然后审核人员也要做同样的工作，判断它是否完美。
主持人 Sonal Chokshi：
这是一个大的思维转变。在编程的世界里，至少自计算机的早期以来，我们一直处于丰富的世界，但在这个世界中，我们处于一个约束的世界。
a16z Eddy Lazzarin：
另一个思维转变是，在 ERC 20 Token 的世界里，你的地址没有代 Token 余额。你不能发送 Token，你必须去访问 Token 合约，在 Token 合约中查找地址对应的 Token 余额，然后通过修改地址和余额来完成 Token 转移。这是一种比较反直觉的思考方式，但在 EVM 和 Move 中，这是非常重要的思维转变。
Sui CTO Sam Blackshear ：
在智能合约编程中，你的工作是编写一小段代码，并且必须是完美的，因为这个代码可能涉及到数亿人的资金安全。你必须仔细审查代码，确保代码的正确性。
另外，升级智能合约的难度比升级移动应用或网站更高，因为在智能合约中，代码是不可变的。在智能合约编程中，你必须考虑如何支持安全的升级和信任，使其看起来更像传统生态系统。
但是智能合约编程中，你需要拥有一个对抗性的思维方式，这对于来自其他领域的人可能很陌生。这是因为在智能合约中的部署模型，你不仅需要考虑你的应用的预期使用情况，还要考虑非预期的使用情况。因为在传统编程中，有方法可以隐藏自己，限制为一个小型 API，或使用防火墙来限制攻击者的操作等。
但智能合约的整个意义在于，你所做的可以与你从未想象过的代码进行交互，并且可以安全地实现。因此，你需要考虑这种情况下的优点和缺点。这绝对是相对于传统编程的一个思维方式的转变。
主持人 Sonal Chokshi：
这是一个非常重要的问题，也是我们讨论如何编写智能合约和使用智能合约编程语言时应该优先考虑的问题吗？
Sui CTO Sam Blackshear ：
是的，绝对是。这实际上是我最喜欢谈论的事情。这让我非常害怕，智能合约语言设计者需要考虑的问题是安全性。这是主要焦点，甚至可能是唯一的焦点，直到我们解决了这个问题。
我认为，智能合约安全对于更广泛的加密货币采用来说是一种存在性威胁。我这么说的原因是，您可以看一下以太坊和 solidity，以及最流行的平台 EVM 和 Solidity。您可以看看编写此代码的早期程序员，他们非常高素质，真正理解底层区块链，非常注重安全。他们知道自己在做什么。我认为，他们非常认真地编写管理数亿美元和数十亿美元的代码的责任。
但是，如果您看一下任何地方的智能合约安全记录，都非常糟糕，这不是这些人的错。我认为这是一个非常困难的问题。并且我认为语言使其更加困难。所以，如果您看看我最喜欢的网站 rakt.news，您可以查看排行榜或查看价值数千万或数亿美元的这十个黑客，这些黑客非常惯常，每周或每月发生一次，具体取决于规模。同时，智能合约开发者社区非常小，只有约 5000 名全职 EVM 程序员，这与传统开发者社区相比非常非常小。
因此，如果您相信我们拥有的人是最硬核且最注重安全的人员，但开发实践和安全记录是不可持续的，那么我认为您的结论是，没有任何方式可以使这个空间在没有使安全问题变得更糟的情况下继续增长，这可能意味着它根本不会增长，或者像那些想进入 Web3 的大型金融机构或公司一样，他们正在看着自己是否必须雇用智能合约开发者？我会被黑客攻击数千万美元并感到紧张。随着时间的推移，这种情况只会变得更糟。他们可能会保持观望。因此，作为试图设计新智能合约语言的人，安全性必须是您首先要考虑的事情。
主持人 Sonal Chokshi：
你们其实已经在不失去资产的背景下暗示了这一点，但是你们更具体地是什么意思呢，因为它非常重要？
Sui CTO Sam Blackshear ：
我所说的安全性是指我们既要防止程序员自我脚踏，还要尽可能为他们提供正确的原语，以便他们能够防御攻击，因为智能合约是一个设置，您的代码部署在一个攻击者旁边，攻击者可以直接调用您的代码，可以直接与其链接。您的代码是开源的，或者至少字节码是开源的。
这是目前我们所见过的最具对抗性的编程环境，出错的代价也是最高的。因此，我认为如果你在讨论智能合约编程设计，那么安全性必须始终放在首位。一旦我们解决了安全问题，我们可以考虑其他更具表现力的因素，但这是我的有些乏味，但我认为非常重要的答案。
a16z Eddy Lazzarin：
哪些特性能够影响安全性？有什么例子能够体现这一点呢？
Sui CTO Sam Blackshear ：
我认为最重要的是封装，具体来说，是封装的各个子特性。当您编写代码时，您无法预测攻击者会尝试什么，因此需要能够在没有预见到攻击者会做什么的情况下进行推理。所以，您需要一个强大的类型系统，不仅在源代码级别，而且在字节码级别都需要，这样您在编写源代码时获得的保证将在您将代码发布到区块链上、其他人依赖它并与它进行交互时继续保持。
我们观察到，在其他领域中流行的某些特性在智能合约编程中本质上是不适合的，比如动态分派。
在传统的编程中，像接口和动态分派这样的东西是关键的抽象机制，是无处不在的。您可以定义一个接口，然后其他人使用不同的逻辑重写该接口，然后您可以针对该接口进行编程，一切都非常好。但是我们有一个俏皮的说法：「在代码是法律的世界里，接口是犯罪行为。」
a16z Noah：
这是个玩笑话，让我们停下来一分钟。在代码是法律的世界里，接口是犯罪行为。
主持人 Sonal Chokshi：
在您继续之前，您能否再解释一下这句话？我不想太快地跳过它。
Sui CTO Sam Blackshear ：
是的，完全正确。这里的想法是，接口不定义行为，它定义了预期行为。比如，当你阅读接口的规范、参数名称甚至类型时，它告诉你想要完成什么。但是并不能保证它就一定会发生。
所以，如果你编写的代码是用来保护某些东西的，但实际上你留下了一个空白支票供攻击者、其他人填写。这在契约法中似乎是一种犯罪。这是一个未明确规定的合同。我非常喜欢这个特性，它在传统的编程语言中很受欢迎。但我们认为，在智能合约中，这导致了许多不同的问题。例如，重新进入需要动态调度。例如，如果您取消了动态调度，则根本没有重新进入。像以太坊中的毒药 Token 这样的事情发生了，因为您重写了转移函数，而每个人都知道直观地说，它只是用来转移资金，也许不会做其他任何事情。但现在你让它做一些超出预期的事情，比如窃取钱财。这就是一个特性的例子，如果将其删除，那么对代码进行推理并进行适当的封装就变得更加容易了，因为每次看到一个调用点时，您都知道它将确切地做什么，您不必担心其他人以后会做出令您惊讶的事情。
a16z Eddy Lazzarin：
确切地说，我认为这个类比就像如果你定义一个关于椅子的接口，它有四条腿和一个座位，你描述的是它的具体层面，而不是行为层面，你没有描述可能是隐含或默认的关于椅子的其他事情，比如它具有某种结构完整性，它有特定的材料，它是以某种方式放置的。
a16z Eddy Lazzarin：
可能被规避，这意味着接口只是一组任意的描述，不能捕捉您想要强制执行的安全约束。
a16z Noah：
这正是定义。
a16z Eddy Lazzarin：
在错误的层面定义事物。我很好奇。
Sui CTO Sam Blackshear ：
但是，您如何在接口之外很好地进行模块化？如果接口是一种犯罪，我可能是一个罪犯，因为我的最喜欢构建复杂的智能合约的方式之一是喜欢有不同的合约，具有不同的目的。而且，特别是在非常复杂的系统中，您有一个基于模块的基础，其中模块遵守某种接口，然后主要合同可以知道如何调用不同的模块。这些模块通常通过治理方式获得许可，如何获得超级表达的即插即用的模块性？没有标准化接口？如何获得继承？
a16z Eddy Lazzarin：
这些与接口有关的所有事情都喜欢吗？
Sui CTO Sam Blackshear ：
这正是要问的正确问题。他们可以整天反对这一点，但是如何提供一些使您编写有用代码的东西？就像如果不允许您走出房子之类的事情一样，没有犯罪。但是我们做到这一点的方式是，接口和继承并不是唯一的方式，我倾向于以组合为思考方式。我们提供了几种组合原语，不需要动态调度程序接口。
其中之一是泛型。我们有运行时遗传，看起来很像您所拥有的。Clr（Sui World 注：common language runtime, 公共语言运行库）让我给出一个非常具体的例子，否则这很快就会变得抽象。
像您的 ERC-20 之类的东西, 这显然是一项根本重要的加密标准。如果您的平台，您的语言无法做到这一点，那么它将没有什么用处。在像 Move 这样的语言中，您定义了一个称为 t 的类型点，其中 t 是一个泛型类型参数，然后实现了 coin 的函数，例如有一个函数用于将 2 个点连接在一起。这适用于所有 coin 类型。这不是某个人想要覆盖的东西。您定义拆分。
当你想让某人定制 Token 的行为时，使用所谓的能力模式，例如对于 Token，你可能想要定制的一件事情是总供应量是多少，或者更根本的是它的政策是什么？你可以这样表达：好的，你有类型为「t」的点结构体，然后有不同的 t 的实例化，例如美元、英镑或其他的货币类型。对于你想要定制的东西，你在能力层面上提供它，创建一个 Token 的函数。你说，这是我的 Token 的类型参数，然后它会给你一个叫做「资金宝库能力」的东西。然后有其他的逻辑确保只有持有 t 的宝库能力的人才能铸造和销毁 t 类型的 Token。你可以拿到这个宝库能力，将它锁定在一个不同的合约中，强制执行总供应量的限制。你可以将它放在某个地方，比如说只在周二评论，但不在周四评论。你倒置了控制流，这就允许你进行任意的组合。这是一个技巧的例子，但这个技巧可以在几乎所有地方使用，如果你想要让行为以某种方式工作，你需要硬编码。这听起来不好，但你实现特定的两种方法，然后你为你想允许的东西定义这些能力。
a16z Eddy Lazzarin：
你认为能力是你可以添加到一个看起来像是传统程序员的接口的约束吗？
Sui CTO Sam Blackshear ：
是的，我认为大多数这些接口模式可以非常直接地变体。这有点难以编译，但是你可以说，这是这个接口想要做的事情的等效能力模式。
主持人 Sonal Chokshi：
顺便问一下，Sam，你觉得这样满意吗？请随意表示异议，有点冲突感是好事。
Sui CTO Sam Blackshear ：
我觉得这样还算满意，因为我认为如果你可以有具有内在能力的模块或者结构体，而这些模块可以被喂入具有非常预定义行为的模块中，你最终可以得到完全相同的行为，就像模块可以做到的那样。模块接受抽象的结构体，那个结构体在那个模块中被定义，然后这个结构体里面有一个内在的能力。这实际上非常好用，因为你可以得到非常好的权限样式注册表，它们几乎自然地从这里产生，就像什么叫做 DS-Off 注册表就是这样，是吧？
a16z Noah：
完全正确。这些能力是可以扩展表示你被允许做的事情。因此这有很多其他的好处。比如说，你想知道我的账户能做什么，你看看我有哪些能力就行了。然后，你可以做程序分析，看看如果我有一个宝库能力，那么我可以调用哪些函数，还有其他一些类似的东西。
面向对象和面向资产的编程
a16z Eddy Lazzarin：
所以我可能有点提前谈到证明器，但是这些能力对类型系统可见吗？在对程序进行静态分析的时候，这些能力在程序的哪个时候是可见的？如果我写了一些特定实例化的代码，其中有能力，那么在我运行它之前，能够很早地发现我违反了能力吗？
a16z Noah：
是的，这些能力是对类型系统可见的，并且在程序的静态分析阶段就可见了。如果我写了一个具有能力的特定实例化的类型的代码，那么非常早就可以发现我是否违反了能力，不需要在虚拟机上运行它。
Sui CTO Sam Blackshear ：
让我简单回答一下这个问题，然后再提供一些背景信息，它们对编译器可见，并且是类型系统的一部分。这是我们非常重要的一个利用点。但我想稍微讲一下 Move 可移动性系统中的结构体，以及它如何卷入到类似于审计的能力等级中。如果这不会分散注意力的话。
在 Move 中，你有结构体类型和类似于其他语言的结构体，它们可以有字段，可以是基本类型的字段，也可以是其他结构体。而更加有趣，也许更加不同的是，这些结构体具有能力。如果你熟悉 Rust，那么能力有点像标记交易。它们声明了你在结构体上允许进行的内置操作。
同样重要的是，如果你没有能力，你就不能做那些事情。比较简单的一个能力是非常重要的，那就是复制的能力。如果你有一个 Token 类型或者非同质化 Token 之类的东西，在计算机中，它只是一些比特，但你不希望允许别人随意复制这个东西。
在 Move 中，如果你没有声明你的结构体具有复制的能力，那么你就不能使用我们相当于「man copy」的操作。
所以像整数和字符串这样的东西都有复制。但如果你不想让你的类型具有复制的能力，那么你就不给它。然后还有其他的能力，比如丢弃，这被称为 drop 能力。这就涉及到了有趣的线性类型的东西，如果你想要丢弃某些东西，比如把它放到作用域之外，或者覆盖掉它，那么你就给它 drop 能力。但如果你不给 drop，那么消除它的唯一方法就是定义该类型的模块所期望的任何策略。
公共语言运行库 (common language runtime, CLR) 举个具体的例子，如果你想为你的 Token 保持一个总供应量，你就不给你的 Token drop 能力。然后除了在声明它的模块中定义的 burn 函数，没有其他方式可以摆脱它，这个函数可以更新总供应量。这些都是你可以使用的技巧。还有几个与存储有关的能力，比如它是否可以存储在全局存储中，我不会详细讲述，因为它们对这个问题不太相关。但基本上，能力已经融入到审计程序中，审计程序了解类型系统，知道如何利用类型系统来解决问题。如果我编写一个说明，说只有一个这样的东西，那么审计程序可以利用这个来证明这个属性。因此，能力和类型系统的保证是相辅相成的。
a16z Noah：
当你提到 drop 时，我就想谈谈我最喜欢的东西。你能不能谈一下热土豆模式是什么？如果还有其他类似的酷东西，它是我最喜欢的奇怪事情之一，是从 Move 中产生的。
Sui CTO Sam Blackshear ：
这确实是一个奇怪的东西。这与能力非常密切相关。通常在编程语言中，你对于何时可以消除你的值没有太多的控制，可能你有一个析构函数来说明你的值何时会消失。但是有时析构函数的保证比较弱，或者你不能简单地说类似于「你不能删除我的类型」。这听起来像是一个奇怪的限制，但它实际上非常有力，特别是在没有动态分派的情况下。
我先举一个热土豆的例子，然后我们可以深入了解闪电贷之类的东西。如果你在以太坊上进行闪电贷，这是一个标准，你可以重载它，基本上你公开一个回调函数，就像一个闪电贷合约，你给我钱，我的回调函数然后取回钱之类的，而在 Move 中，你这样做的方式是有人去闪电贷合约，他们说，「嘿，给我 53 块，但他们也给你所谓的热土豆对象。
热土豆对象是一个结构体，它没有能力。它没有复制，所以你不能复制它。它没有全局存储的能力，你不能像将它放在一个合约中一样将其藏起来。它也没有 drop 能力，所以你无法将其丢弃。因此，唯一的摆脱它的方法是将它传回闪电贷合约。让你传回它的闪电贷合约的代码，强制你还款。如果你不还，它的程序将在运行时失败，甚至不会通过类型检查。因此，这是利用有趣的能力控制你的值的破坏，作为一个程序员，可以在任何时候强加任意的不变量，以决定何时可以销毁这些对象。这些看起来很像 API 调用模式非常明确。另一个非常明显的例子是，如果你想要强制某人在调用 unlock 之后调用 lock，但在两者之间可以做任何想做的事情，你也可以用这种方法实现。
a16z Eddy Lazzarin：
当我第一次听到「烫手山芋」模式时，我想到了像「mute texas」这样的锁的有趣用途，这些锁仅出于人体工程学目的，利用了类型系统，以强制特定对象的使用方式，几乎是商业逻辑级别的要求。我认为这是非常聪明的，感觉非常现代化，是编程语言中人体工程学的高质量使用方式，而这种方式在传统的编程语言中甚至还不是很常见，但在智能合约环境中显然非常有价值，因为在这里有更多的逻辑要求，要考虑可能涉及的价值和安全性。
Sui CTO Sam Blackshear ：
在我们讨论任何具体的例子之前，您能否快速概述一下我们的对象系统的高级概述？对象是什么，谁拥有它们？对象如何拥有其他对象，模块如何与它们一起工作？
a16z Noah：
是的，完全正确。这是关于 Move 语言的一个方言，特别是 Sui Move。这个东西的基础是全局存储的不同结构，而不是我们曾经使用的原始 Move 方言的全局存储方案。原始的 Move 全局存储方案非常类似于以太坊使用的公司模型。
在 Sui Move 中，我们希望将事物的中心点放在对象上，高度激励能够尽可能精确地表示细粒度访问。这有助于你做很多事情，我们不会在这个播客上详细介绍，比如更有效地处理事务，告诉钱包用户事务将要做什么等等。
所以在 Sui Move 中，全局存储的结构是一个从对象 ID 到对象 ID 的映射。然后对象只是具有一个称为键（key）的能力的 Move 结构。它说：「嘿，我可以作为键。」它可以出现在全局对象池中。然后每个对象必须具有一个全局唯一的 ID。然后你可以为你的模块编写入口点函数，它们可以直接将对象作为输入。如果你在写一个事务，这个 WeRunTime 就会有对象 ID。如果你写的是事务，WeRunTime 就能够使用这些 ID 来将 ID 解析为对象，并将其插入函数中。
这种面向对象和面向资产的编程体验非常棒。它比我们在原始 Move 版本中的做法直接得多。你还提到了父对象和子对象以及对象层次结构。这非常有用，但你仍然希望能够像表示大型集合这样的东西。
比如，我正在构建一个类似于 DNS 的注册表，我希望有数百万个条目。我们有一个对象大小限制，一个对象可以是几兆字节，但不能更大。但是如果你有像 DNS 这样的东西，它应该是任意大的。我们表示它的方式是使用父子对象关系，我们基本上有一种方式将一个对象视为异构映射。然后你可以添加具有动态选择字段的键。这在某种程度上非常类似于 JavaScript。我们可以说，这个对象有一个映射在里面，然后我可以在这个映射里放一些东西。或者你可以说，当我定义这个对象时，它有十个字段，但我实际上想在后来添加一个新字段，我将升级我的合同。我想在事后添加一个新字段。
我们表示它的方式是使用这些父对象和子对象关系，每个子对象都与一个键值相关联，可以是任意的 Move 值，例如字符串或 u 64 ，或任何你想要的其他值。
a16z Noah：
是的，与父对象的概念有关，我认为让它真正成为我的「灵光一闪」的事情实际上是几个月前我花时间深入研究 Sui Move，并从写一个只有一个对象的程序一直到重新实现了大部分 Uniswap V2 风格的卡牌组合。我做的一个小项目真正让我意识到拥有对象的对象是如此有价值。这个项目只有三个对象，锁、金子和一个空的障碍物。有一个很基本的模块，你可以想象它可以创建由钥匙对象拥有的金子。然后唯一的取出金子的方法是有一个函数，它需要锁和钥匙，并显然销毁锁，把金子给你，然后销毁你的钥匙。这种方式非常有趣，通过这种方式，你可以描述对象之间的关系，并以非常细粒度的方式描述权限。
Sui CTO Sam Blackshear ：
这也正是我们所考虑的。我喜欢你描述三个不同对象的嵌套方式，因为这种方式在深入到更深层次时变得更加强大。这使得作为程序员更容易结构化，以确保我可以到达第二层，然后可以触及第三层，但我不能直接从第一层到达第三层。我认为这也使得对于从智能合约空间之外的程序员来说更容易理解，比如这些人非常熟悉编写对象树、DOM 对象树，如果你是游戏程序员，一切都是场景层次结构，其中有一个角色，他们有一个库存，然后库存里可能有一些小东西。你可以非常直接地在 Move 中编码这些内容，然后类型系统允许你以非常直接和安全的方式设置这种访问控制。我认为这是一种非常实际的编程体验，它真正反映了关于现实世界的直觉，或者如何描述某些东西，然后直接转化为相关的代码。
Move 与 Solidity 的安全性对比
主持人 Sonal Chokshi：
顺便说一下，在来到 Wired 杂志之前，我曾经在施乐公园呆了 6 天，这让我想起了一点关于面向对象编程的历史。你刚才说的超级有趣，因为他们发明了 Smalltalk，这是许多今天面向对象框架的早期前身。无论如何，有没有其他的话题想讨论？
a16z Noah：
我只有一个普遍性的问题，但实际上，有没有在 EVM 世界中发生的黑客事件等等，你认为如果使用 Move，由于类型系统的缘故，这些事件就不会发生在第一次。
Sui CTO Sam Blackshear ：
在 EVM 世界中，我们已经提到了动态分配和重入，Move 通过构造消除了重入，任何与重入相关的问题都会消失，我认为人们做得很好。现在，我认为它避免了反应和查看。
a16z Eddy Lazzarin：
但是你能解释一下，为什么 Move 会让这些问题不可能发生吗？
Sui CTO Sam Blackshear ：
重入，对吧？发生了什么？你写了一些代码，调用了某个函数。问题在于，有人提供了一个你最初没有预料到的函数实现。为了实现这一点，函数调用必须是动态的。它必须调用代码，这基本上是由调用者提供的函数指针，可能是攻击者。如果你没有任何动态函数调用，如果你总是知道一个函数调用的目标，那么这根本就不可能发生，就像你调用的任何东西，你可能不知道代码做了什么，但是你知道它是什么，你可以测试它，你可以验证它，所有的东西都在那里。所以从根本上说，别人不可能提供让你的模块行为变得出乎你意料的代码，因为这只是一个静态的函数调用。太酷了。
a16z Eddy Lazzarin：
因此，这就消除了可重入攻击，这在 Solidity 开发中一直是一个永恒的问题。
Sui CTO Sam Blackshear ：
是的，我认为 Move 基本上消除了智能合约编程中缺失的权限检查问题。有很多时候你在写一些代码时需要显式地传递所有的账户，并且你必须说，我是否有权做这件事。你写了一个简单的代码，但是却忘记了检查发送者是否是某个人，或者是否这个人可以访问它。我认为这些问题经常发生。
所以在 Move 中，对象所有权信息实际上存储在对象元数据中。这不是程序员可以控制的东西。
当你查看这些对象时，它们会说：「我由这个地址拥有」，或者「我由这个其他对象拥有」，或者「我是共享对象」或者「我是不可变对象」。程序员不能忘记检查它的所有者，因为运行时会在执行传入这个 Sui 对象的代码之前进行检查。运行时会说：「我看到了这个交易中心，我看到了他们想要使用的所有对象。我正在检查他们是否实际拥有这些对象，或者它们拥有一个可以中转拥有它们的对象，以便他们有权使用它们。
我们要求程序员进行的许多权限检查最终都在 We Run Time 中发生，这些检查是不可能忘记的。我认为这非常重要，因为最难保护的是程序员没有告诉你的规范。这些规范很容易被忘记，使用静态分析或其他方法很难捕捉到它们，因为你总是需要一些人来确定哪些规范很重要。
主持人 Sonal Chokshi：
顺便说一句，在远期或近期的长期规划方面，当人们以这种方式更多地合作时，企业规模会发生什么，我认为这将非常有趣，因为它显然是分布式的，不仅仅是一个公司，有时人们会合作。但我的意思是，当你考虑现在的老旧方式，你有像开发人员和所有这些最佳实践和所有这些方法。然后你有这些非常不同的思维方式来做事情，我们还没有完全在这个世界中将所有这些正式化，这还为时过早，但我非常好奇这种事情会是什么样子。
a16z Noah：
现在 EVM 的工具很好用，那么 Move 的工具怎么样呢？还需要进行哪些重大改变吗？
Sui CTO Sam Blackshear ：
我认为我们的工具还处于很早期的阶段。我们正在开发一个包管理器，可以跨链使用，像 Create.io 或 npm 一样。Move 的模型系统非常适合这种事情，我们正在努力实现这个目标。这个包管理器可以让开发者轻松分享他们的代码，这在 Solidity 中很难做到，因为在 Solidity 中，只能通过复制粘贴的方式来分享代码。
我们还在最初的时候就专注于正确性工具的研发，我们有很多这样的工具，但我认为我们还有很多事情要做，使它们更易用。我们有一个单元测试框架，我们可以直接在 Move 中编写测试。我们也开发了 Move prover，用来辅助我们做形式化验证。
Move Prover 的重要性
主持人 Sonal Chokshi：
能否简单谈一下形式化验证以及为什么 Move Prover 很重要？
Sui CTO Sam Blackshear ：
形式化验证很具有挑战性，通常需要专家或者博士来使用。我们正在努力将它推广到每一个日常开发者，而不需要专业知识。
目前还不清楚这个目标能否实现，但我们看到了一些很有前途的项目。比如，最近有人将一个智能合约的所有规范提交到了一张文件中，之后只需要为新函数写规范，这就使得形式化验证变得非常容易。不过，形式化验证还有很多需要改进的地方，包括提高易用性和功能强大程度。
还有像 fuzzer 这样的工具，虽然不如形式化验证好用，但对于一些重要的正确性检查非常有帮助，特别是当你需要写一些非常复杂的代码时。我们也有一些学术界的库在研发这些工具。除此之外，我们也正在研究如何让编写程序变得更容易，比如支持更多集成开发环境、程序合成和人工智能等。
主持人 Sonal Chokshi：
如何使用 Move Prover？如果我想试试它怎么办？
Sui CTO Sam Blackshear ：
首先你需要拿到你已经测试过的程序。验证不是测试的补充。然后你可以编写一些很难测试或很难检查的内容。这可能是一些简单的函数前后条件。比如说，如果我的函数输入满足这个条件，那么输出应该满足那个条件。你还可以编写数据不变量，比如你有一个计数器，你想证明它总是在增加，你可以编写一个规范，将其附加到计数器结构中，以检查它是否成立。
然后它会查看所有的函数，并确保这些规范都成立。还有更高级的用法，比如全局存储和变量。你可能想说，这个对象始终只有一个，或者这个对象有两个，然后有三个。以及这个对象的字段和那个对象的字段之间的关系。这些规范很大程度上取决于应用程序。
Move 语言可以避免很多基本的错误，但对于你作为程序员来说，总会有一些特定于你的应用程序的正确性条件。规范语言使编写这些条件变得容易，可以在编写代码之后或某些情况下甚至在编写代码之前编写它们，并确保它们在所有可能的程序执行和所有可能的函数调用中都成立。
因此，现在，规范语言与编译器集成，因此您可以在任何这些模式下提取它并尝试使用它。它还与构建系统集成。您只需要执行 move build -prove，它就会检查这些规范。
a16z Noah：
酷！Prover 能理解 Sui 对象模型和 Sui 交易系统吗？比如，我能否证明关于跨交易的一些可能修改全局状态的内容？
Sui CTO Sam Blackshear ：
它还没有完全理解，但它并不需要完全理解。例如，如果你想证明计数器始终在增加，这是一个 Sui 对象，但是它不需要完全理解 Sui 就可以证明。即使在核心 Move 的 prover 中，它也真正考虑对象和全局存储的层面，而不是像交易这样的概念。因此，今天它确实只能考虑函数和事务的层面，这也能够正常工作。但我想我们将来可能会在 Sui 方面做更多的事情，特别是关于父子关系和异构对象映射。
编程语言的治理
主持人 Sonal Chokshi：
我们可以谈谈编程语言的治理吗？编程语言的演进有着悠久的历史，但是在区块链和加密货币的背景下，治理话题显然更加重要，因为有许多其他方面需要考虑，如分权、开源、分布式社区、令牌和经济学资产等，这有时作为激励计划的一部分参与其中。
a16z Eddy Lazzarin：
特别是因为它们是开源的，能在许多不同的上下文中使用，它们被视为公共物品，但它们不同，需要设计和细节的关注。编程语言应该如何发展？今天有很多编程语言似乎都有不同的治理方式，如我所想到的前两个是 C++委员会和 WG 21 委员会，还有一些非常复杂的名称。
然后像 Python，Guido 是它的生命之恩人，拥有 benevolent dictator for life。那么，您认为什么是现代化的编程语言治理方式？特别是在加密货币领域，这是一种独特的情况，因为这些编程语言可能与层一相连，这是一种依赖于编程语言的不同类型的东西，它是一种公共物品，但是它有利益相关者，它有大量的资本附加值，有许多价值正在传递。也许有一些编程语言的治理模式更适合区块链。我对思考编程语言应该如何治理或更好地说，移动如何发展，考虑到所有巨大的利益相关者和设计语言保护其安全性质的重要性非常感兴趣。
Sui CTO Sam Blackshear ：
嗯，我不会认为我的见解适用于其他编程语言。但对于 Move 来说，我有一个非常具体的看法，就是这种跨平台的愿望。Move 被设计为一种跨平台语言，其中一些链 EDM 的基本功能仍应适用，并且覆盖了智能合约开发能手和 Web2 新人，极具灵活性。
除了对程序员和平台设计者的好处外，治理是另一个原因，几乎所有区块链语言中的有争议的决定，例如：我们应该增加这个限制吗？或者我们应该支持这种签名方案吗？或者我们是否应该拥有这个库？我们试图将其设置在适配器层，即构建在语言形式之上的平台，而核心语言非常简洁。简洁性是我们语言的关键设计原则之一，非常不依赖于区块链。
因此，如果我们要与社区的利益相关者进行辩论，它不会像「我们应该增加 gas 限制」这样的问题。而是像「我们应该拥有电子邮件」这样的问题，这是一个更纯粹的设计问题，可以受到来自一个或多个 Move 平台的问题或用例的影响，但不太可能朝着对某个利益相关者有利而对其他人不利的方向发展。到目前为止，这种模式一直运作得很好，但我们还需要看看未来会发生什么。
基本上，Move 语言的治理方式是，最初，Move 是在 Facebook 开发的，没有真正的治理。它只是我们使用它的方式，虽然我们有这些设计原则。
现在，团队分散了一些，我们有很多来自不同机构的成员。有些人在我们这里，有些人在其它地方。有一些来自学术界、安全社区的第三方贡献者，还有一些 Move 链的星际币等其他机构。我们每个星期四都会开会。
我们会讨论 Move 的设计问题，我们非常谨慎地扩展语言。简洁性是主要的东西，但我们会积极地扩展它。
比如，添加这个东西会使在 Move 之上的这些层次的实验更容易进行。一旦我们看到这些实验的结果，或者每个人似乎都在做同样的事情，那么我们就会将其移到核心语言中。因此，我们对治理的答案是：尽可能避免治理，通过让有争议的事情发生在 Move 之上的层次，以及将简洁性作为核心原则之一，使我们在仅当每个程序员都需要某个东西时，才添加新的内容。
主持人 Sonal Chokshi：
你们作为程序员，对于另一面的事情，比如 Noah，你们真的在乎吗？比如说你选择使用什么工具，怎样参与？你们在意社区或者编程语言的治理吗？还是只在乎你们获取所需的工具？
a16z Noah：
我认为在一定程度上是有关系的，比如你想使用一个被很多人使用的语言，这样你就可以得到更多的贡献者，对吧？你也想要一个不会被抛弃的语言，对吧？那些应该是主要的考虑因素。
但是，我并不在意 Python 是由独裁统治还是委员会治理，只要能够达成目标就好。尽管我认为很多人不在意，但是有很多争论表明由委员会治理已经破坏了很多编程语言，我想。
主持人 Sonal Chokshi：
是啊，我一直觉得很有趣。
Sui CTO Sam Blackshear ：
我认为这很重要。我有一些技术上的设想，比如跨平台的程序和资源，以及这些东西应该有的大致想法。但是这是一个社区项目。很多贡献者为设计的很多方面做出了贡献，我并不是 Move 或任何其他东西的独裁者。但是，我认为我的角色是策展人，确保每个人都在同一页面，并确保在想法涌现时，我们根据这些原则进行评估，这些想法可以来自任何人。
但是最重要的是我们有共同的愿景。每种语言都略有不同。我认为它们固有地反映了它们的用途、创建者和社区的个性等等因素。所以肯定不会有一种适用于所有的规则。
主持人 Sonal Chokshi：
对，完全没问题，这很有道理。
Sam 怎么进入 Move 的
所以在我们结束前的最后几个问题里，我突然意识到我们从来没有听过 Sam 怎么来到 Move 的。我主要感兴趣的不仅仅是因为我想听你的故事，我相信它很棒，但我更感兴趣的是你是如何通过思考去解决问题的。所以你能快速分享一下这个过程吗？当然可以。
Sui CTO Sam Blackshear ：
我开始作为一名编程语言研究员来进行职业生涯。我从事静态分析和程序验证的工作，这意味着我花了很多时间看真实的程序，寻找漏洞，并尝试弄清楚程序员经常犯的错误类型是什么，以及导致这些错误的原因是什么。是语言的基本问题使得某些类型的错误过于容易？是他们使用的框架的问题？还是仅仅是有关人类心理学，使得某些类型的错误比其他错误更容易被发现？
基本上，在我的博士期间，我花了很多时间研究真实的程序，查找漏洞，然后构建这些工具，试图在不运行代码的情况下查看代码并尝试在之前捕捉这些错误。而这种事情在一般情况下是无法解决的。你在进行静态分析时，总是在与停机问题作斗争，但在实践中，你可以无限地接近完美的结果，而不是在理论中得出平均结果。所以我花了很多时间做这件事，看了所有经典类型的漏洞，如空引用、缓冲区溢出、安全问题等等。我真的很享受这个工作，但是很难找到这些例子和很多人真正关心的数据集。
但是在我博士的最后阶段，我在 Facebook 实习。这是在 2013 年到 2014 年左右，他们正在从 Web 世界向移动世界过渡，并且发现当我将漏洞发布到移动应用中时，它会在那里存在两周，而在 Web 中，我可以立即修复它。当我加入后，Android 上的分裂问题是造成问题最严重的问题，因为这会导致无法修复的漏洞。他们在静态分析技术上进行了大量投资。他们从我的领域收购了一个研究小组，我有机会与他们一起工作，并继续我真正喜欢的工作。但是，与其结束于单个程序的漏洞修复，我开始思考如何设计一种语言来使这种漏洞更难以产生。我对语言设计和程序安全方面的兴趣越来越大，开始产生一些关于如何构建更安全的语言的想法。后来，我在 2018 年加入了 Libra 项目，这是一个构建基于区块链的全球支付网络的项目，我被征用为编程语言方面的专家。这个项目需要一个新的编程语言，因此我开始着手构建 Move 语言，并使用我之前的经验来解决一些语言设计上的挑战，例如如何确保 Move 智能合约的安全性和正确性。
主持人 Sonal Chokshi：
所以 Libra 也被重命名为 diem，这是今天很多人可能知道的。还有一个快速的提醒，你的博士论文的实际主题是什么？
Sui CTO Sam Blackshear ：
我的博士论文主要研究目标导向的静态分析。通常，在进行静态分析时，你会查看整个程序并构建有关程序的事实数据库，然后通过获取该事实数据库来查找漏洞。这种方法很有效，但对于非常大的程序而言，不太容易扩展，因为你必须查看整个程序并做所有事情。而你可能有一个非常具体的问题，只关注程序中的一个特定部分。例如，如果你正在运行分析器，并且在 CI 中报告漏洞，你真的想要报告在该 pull request 中发生的漏洞。对程序中的其余部分不是很关心。
在我的博士论文中，我研究了目标导向的静态分析。这意味着我希望静态分析的效率可以随着我关心的特定属性的复杂性而扩展，而不是随着输入程序的大小而扩展。如果这个属性非常简单，只需要进行简单的推理就可以确定其安全性或漏洞性，我希望它非常快。或者如果这需要查看整个程序进行推理，则相应地会更慢。这是一件有用的事情，因为静态分析的一个主要问题就是非常慢，特别是当你在运行像巨大的几百万行程序时。我在这个静态分析子领域中研究了一个新的理论，称为抽象解释，旨在使抽象解释更具目标导向性和属性导向性，从而提高效率和精度。
主持人 Sonal Chokshi：
非常有趣。你提到你在背景中也对心理学很感兴趣，当你设计你的博士研究以及现在的工作时，你可以快速介绍一下程序员的心理学吗？因为你没有满足我的好奇心。
Sui CTO Sam Blackshear ：
当我在 2018 年来到 Libra 时，我们基本上需要在 Libra 中建立智能合约，你需要想出这意味着什么。你不能在真空中进行推理，就像语言基本上是问题解决工具一样。所以我看了很多 Solidity 和智能合约代码。我想知道程序员用这些东西做什么？语言在哪里帮助了他们？在哪里妨碍了他们？这个问题的主要结论是基本上所有这些程序都在试图做同一件事。
他们试图谈论资产，试图转移它们，试图定义它们。但是代码编写的方式总是如此间接。这就像一种粗暴的设计练习，你试图谈论这件事，但是没有词汇来表达它。这就是心理学的元素，我可以阅读程序并思考，这个人在想什么？在他们的头脑中，相对于他们实际编写的代码？这个翻译层中的障碍是什么？语言如何通过提供正确的抽象来帮助他们？这些问题没有客观的答案。这就像我也是程序员，我会怎样编写这段代码？或者我会发现什么直观而什么困惑？
所以基本上，决定创建 Move 而不是在 EVM 上构建或使用现有语言是因为，正如我们之前所说，这种智能合约需求与其他任何东西都非常不同，使用现有语言没有所需的抽象或特征是没有意义的。
如果你在 EVM 中使用 Solidity 之类的东西，这是这个领域的第一次尝试。因此，它没有合理地预测出人们将要尝试做什么。所以我认为我们有所有这些第二移动者的优势。我们了解人们想做什么，什么效果好，什么效果不好。我们应该利用这一点来打造一个新的语言。说服人们需要构建一个新的编程语言是一个有趣的旅程，我们可以在另一个时间讨论，但是有人告诉你你应该说不。很多人对 Facebook 是否有这种尝试的愿景持有合理的怀疑态度。
主持人 Sonal Chokshi：
有趣的是，感觉这几乎是你能够回应的唯一地方，而且甚至更好的是，你们现在可以将其带离 Facebook 并继续前进。实际上，对于它的诞生和发展来说，这几乎是理想的条件。事实上，这对于它们两者都是一个很好的机会。
Sui CTO Sam Blackshear ：
完全是意外之喜。
主持人 Sonal Chokshi：
那就很好了解了。
给智能合约编程语言开发者的建议
最后一个小问题，如果你们有一个建议想要给那些想要了解智能合约编程语言或已经在这个领域的人，如果你们可以用两秒钟的时间给一个建议，你们会说什么？
Sui CTO Sam Blackshear ：
阅读大量代码，了解代码的目的以及底层代码实际上是如何做到这一点，它做得好和不好在哪里。
主持人 Sonal Chokshi：
为什么？简单地说？
Sui CTO Sam Blackshear ：
我认为这是了解语言的最佳方式，它是一个很抽象的东西。但是，如果你从某个东西开始，只是试图弄清楚如何做到这一点，我认为这是一条更具体的路线，也很容易从中进行概括。好的。
主持人 Sonal Chokshi：
艾迪，你有什么建议吗？
a16z Eddy Lazzarin：
这是个好问题。我完全同意 Sam 说的。我还想补充一点，因为我们还处在早期阶段，人们都喜欢分享一些有趣的东西，比如在区块链上编程有多么疯狂。有很多人非常乐意分享，乐意深入探讨。每次我在任何一个大型的社交群或者任何一个论坛上有问题的时候，人们总是乐于和我分享。所以我会建议大家找到那些你真正喜欢和他人分享你的代码，一起构建开源社区的人们。
a16z Noah：
我的建议是，如果你有任何工作流程中经常使用的工具，无论是编译器、测试工具还是其他任何可以让你的工作变得更轻松的工具，你都应该学习它的工作原理。并且，每当你发现一个 bug，就去修复它。成为开源软件的好管理员。
主持人 Sonal Chokshi：
你们说得非常好。再次感谢 Sam、Noah 和 Eddie 参加本期 Web3@ACM 的节目。非常感谢你们。不管怎样，祝你们有美好的一天，再见。
