RDX Works 首席协议架构师 Josh Primero 的评论文章。 在 Babylon 网络上启动 Radix Engine V2 后，我仔细观察了 DeFi 场景中出现的新一波虚拟机。其中最引人注目的一个是 Sui 的 MoveVM，它是对 Diem 原始 MoveVM 的改进。 我对 Sui 的架构感到兴奋已经有一段时间了，因为它与 Radix 共享一些关键技术理念： 使用移动语义来实现面向资产的编程。 利用状态依赖性知识通过部分排序来扩展共识（而不是过度抽象并将可扩展性移至更高层，这是当今的时尚） 从技术上讲，我发现他们如何利用一种语言和编译的字节代码来静态捕获执行某些逻辑所需的最小状态依赖关系，这非常酷。 这不仅可以实现快速执行，还可以提供安全优势，因为事务的状态依赖性和状态写入是有界限的。 但这一成就是有代价的。 DeFi 程序员必须管理一个更困难、有时甚至不直观的模型，甚至重复 EVM 的众所周知的问题。 现在让我们看看我发现的 Sui VM 中的四个缺陷中的这些问题。  1. 对象原语过于通用 Sui的MoveVM（或一般的MoveVM）最大的创新是在字节码层使用移动/借用语义。这意味着他们的低级机器可以理解对象的所有权和移动；很酷！  Sui 的 VM 中的每个对象因此 ，具有关联逻辑的类型化值，可以被拥有、移动和共享。  就像 NFT 一样 不幸的是，由于对象在该模型中可以执行许多更通用的操作，因此 DeFi 程序员需要定义和管理复杂的对象生命周期状态机。  具体来说，在 Sui 中，在定义新结构时，程序员必须指定 4 种能力的组合（“复制”、“删除”、“密钥”和“存储”），每种能力都以不同的方式影响状态机。此外，程序员必须管理在实例化时是否应共享、传输、作为值返回或冻结对象。 其中任何一个的配置错误都可能导致细微的错误，从而导致资金损失。 例如，在下面的代码中，我们使用 Sui 的 实施简单的闪电贷款。问题？我们不小心在收据中添加了掉落功能。  烫手山芋图案 这个小错误使得借款人可以通过丢下收据而逃走贷款，而无需偿还贷款。 （FlashLoan 和 Receipt 关系还有一个 bug，看看你能不能找到它！） 因此，虽然围绕具有一组功能的单个对象抽象来组织 VM 在概念上是优雅且简单的，但从程序员的角度来看，很难理解每个功能的影响，因为有太多的低级状态需要处理。管理。 这与旧语言的内存管理问题并没有太大不同，这也是垃圾收集虚拟机取得巨大成功的原因。应用程序程序员不关心管理低级状态，例如何时可以释放内存；他们关心对象以及这些对象之间的关系。 同样，DeFi 程序员从根本上关心资产以及这些资产的流动和所有权的逻辑。资产本身没有内在的逻辑，管理这些资产的逻辑不需要“移动”，也不需要“拥有”。  Sui 的 MoveVM 将这两种截然不同的事物合并为一个通用对象抽象，这导致了一种困难的 DeFi 编程思维模型。  2. 无动态调度 MoveVM 的一个决定性功能是它使用静态调度，这意味着运行时函数调用与其执行之间没有间接层。函数调用及其底层逻辑在发布新包时静态链接。这使得虚拟机变得快速且可预测，但代价是灵活性较低且编程环境更难使用。 让我们看一下缺乏动态调度的三个影响。  2a) 无函数组合 因为VM必须在代码发布时知道要调用的确切函数，所以不可能将不同的函数组合在一起；常规编程中非常常见的模式（例如，OO 语言中的接口或 Rust 中的特征）。 让我们看一下一个简单的流动性池激励机制。如果我要编写一个激励程序，为你在 Rust 中的贡献增加 10%，它看起来会是这样的：  这样，我的 LiquidityEnhancer 就可以与任何实现 Pool 特征的池一起使用（是的，对于 Rust 挑剔者来说，这个特征也是静态链接的。这只是函数组合的一个示例）。 这在 Sui 中是不可能的，因为“贡献”必须是一个已经定义的函数。相反，必须为任何新的池实现发布链接到确切池实现的新包。  2b) 没有动态回调或函数指针 相关地，能够通过一些通用接口运行任意逻辑是一个非常有用的结构，尤其是在 DeFi 设置中。 想象一个受激励的未来执行者，激励未来的调用者调用一些任意逻辑（例如，使用延迟付款）。在 Rust 中，这看起来像：  然而，由于缺乏动态调度，这在隋是不可能的。相反，必须为每个想要使用此类功能的方法发布一个新的 IncentivizedFutureExecution 包。  2c) 尴尬的可升级性 隋支持 。不幸的是，由于静态调度不变性，管理包升级比预期的更尴尬且更不安全。 包升级和版本控制 首先，无缝和透明的代码更新是不可能的。如果我有一个程序包调用另一个程序包，并且另一个程序包具有所需的错误修复更新，那么如果我想要修复，我必须自己发布一个新程序包。  随着越来越多的包依赖性，即使是对常用包进行简单的错误修复，也很容易导致包升级爆炸。  其次，所有旧代码将始终存在（这是必要的，因为依赖它的任何其他代码都需要能够调用它），即使该代码可能存在错误和/或恶意代码。为了解决这个问题，应用程序层需要在其对象状态下维护合理的版本控制模式。  3. 尴尬的邮箱模式 隋最近发布了 最好将其描述为一种在另一个对象不知道的情况下将一个对象发送到另一个对象的方法（以前，这只能通过地址实现）。为了能够访问该对象，必须执行了解此传输的单独事务。  转移到对象模式 这样的构造对于消除对接收对象状态的依赖很有用；与将 UTXO 发送到 UTXO 模型中的另一个地址没有什么不同（接收部分也类似于通过 UTXO 见证脚本证明所有权）。 Sui 的共识能够利用这种缺乏争用的优势，更好地并行化此类交易。 然而，这样的性能提升并非没有安全性权衡。事实上，在没有有关接收对象的信息（包括它是否存在！）的情况下接收对象可能会导致永远失去对这些发送对象的访问的可能性。 如果接收对象不支持正在发送的对象，则这是可能的。这种缺陷类似于将 ERC-20 代币错误地发送到不支持该代币的智能合约（这是造成资金损失的一个 常见的原因）。 非常 此外，事实上存在两种类型的父子关系，一种是父级了解其子级，另一种是子级了解其父级，这使得模型比传统编程中的典型模型更加复杂。  有没有一种方法可以保留性能优势，而无需在这种尴尬的结构上进行编程？我相信有。它需要使用不可变指针以及其他 CRDT 方法，但我将在以后的文章中介绍这一点。  4. 尴尬的共享状态编程 Sui 的虚拟机经过优化，可以在非争用状态下进行编程和执行。当实际需要处理共享状态时，这导致了一些相当尴尬的编程机制。让我们看一下其中的一些。  4a) 没有存储参考 Sui 的 VM 没有存储引用的概念。如果存在，它将失去静态分析函数状态依赖性的能力，从而失去并行化的能力。这样做的结果是管理存储引用的负担现在落在了程序员/用户身上。 例如，假设我有一个对象，需要在其功能之一中从特定 Oracle 获取价格。在 Rust 中，这可能看起来像这样：  在 Sui 中，由于无法存储引用，因此必须以更函数式的方式来描述 MyDefi 和 Oracle 之间的这种关系：  可是等等！现在可以传入任意的预言机。为了确保使用正确的预言机， 必须使用：    ID 指针模式 与常规引用相比，此模式更加脆弱，必须小心实现正确的关系。随着对象之间的关系图增长并变得更加复杂，很难想象这种编程负担能够很好地扩展（例如，如果 Oracle get_price 调用也有其自己的依赖项会怎样）。 此外，无论是事务还是包代码，调用者总是有传递正确引用的负担。如果该引用可能发生变化，这会给调用者带来另一个额外的负担，以确保该引用已更新为最新状态。  4b) 相关实例的非动态类型安全 与传统编程不同，在 DeFi 编程中，能够类型检查一个实例是否与另一个实例属于同一“实例组”是非常有用的。 例如，最好检查两个硬币的连接是否具有相同的硬币标识符：  使用传统泛型语义实现这一点的问题在于，泛型用于表示类型，而不是“一组相关实例”。  Sui 以一种相当聪明的方式通过他们的方法解决了这个问题 。在这个系统支持的模式中，他们基本上说，如果您想要一组新的相关实例，请创建这个特殊的新类型来表示该组的标识符。 一次性见证人模式 这样做的一个巨大好处是，语言层根本不需要改变，只需使用众所周知的通用语义即可实现这种类型的安全性。 最大的缺陷是每次创建一组新的相关事物时都必须部署一个新类型（因此，一个新包）。例如，我们不能在不部署新包的情况下动态创建一个新的 Coin<T> 。 结论 Sui 的 MoveVM 是按照系统工程师的标准构建的：基于概念上简单的低级原语的虚拟机，静态执行。 不幸的是，简单并不意味着容易，他们坚持避免正常的共享对象模式导致他们的应用程序层非常复杂并且编程不直观。  DeFi 是一个混乱的、共享的对象世界：任何人都可以访问的具有大量流动性的池，任何人都可以借贷的借贷协议，任何人都可以调用的预言机，以及所有这些对象同时发生的组合和交互。 并行化这样一个生态系统是 DLT 的圣杯，Sui 的尝试做得很好，只是它将太多的混乱推到了应用层。 尽管确实有些问题可以通过更好的工具和语言支持来解决（  ），但有些问题在没有大的虚拟机更改的情况下是无法修复的（  ）。 1 对象原语太通用，4 尴尬的共享状态编程 2 没有动态调度，3 尴尬）邮箱模式

Buy XRD with card or bank transfer via Switchere.

該音頻是用故事的原始語言製作的！

Sui 的 MoveVM：全面回顾

About Author

註釋

標籤

这篇文章刊登在

Related Stories

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

释放人工智能的力量。前沿技术的系统评价：摘要与介绍

比特币 UTXO 模型，为独特的生态系统提供动力

Floki 的 Valhalla 成为印度环斯里兰卡赛事联合赞助商

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

释放人工智能的力量。前沿技术的系统评价：摘要与介绍

比特币 UTXO 模型，为独特的生态系统提供动力

Floki 的 Valhalla 成为印度环斯里兰卡赛事联合赞助商

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps