主持人 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：不，这可能只是下限。

2、智能合约的创新发展

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，我会很高兴的。

3、智能合约编程的独特事物

主持人 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代码中的大量内联汇编时，这让我想起我们现在处于多么早期的阶段，因为这不是智能合约开发人员应该考虑的编程挑战，这不是一个成熟的开发生态系统的标志。但我们正在朝着这个方向发展。我同意我们要考虑极限情况。选择正确的算法、选择正确的数据结构、选择正确的一般方法，这是大多数软件工程的情况，都是很重要的。但关于准确计算每条指令的成本的琐碎问题可能太过繁琐了。