因此，我们一直对x86虚拟机在Qtum中将允许的内容表现出色，除了更多的编程语言支持。 这基本上是因为设计过程很容易使一个平庸的版本，但很难建立一个优化，高效，易于使用的版本。 所以在这里我不会深入了解设计的细节，但是我想宣布我们想要的目标。

编程语言支持

当然，编程语言支持是构建这个x86虚拟机的重要原因。 我个人想让2018年在鲁斯特写的智能合约年。 Rust非常高效，重量轻，而且最重要的是注重安全性并避免程序员的错误。 当然，除了Rust之外，还有很多。 带来易用的语言，如C＃或Go也是一个目标。

x86 VM功能的基本要点是你可以使用几乎任何现有的编译器或编程语言，只需进行一些修改，以便它可以在Qtum的操作系统（如环境）上运行。 几乎所有的编译器都支持x86，因此实际的字节码和体系结构支持已经存在。

标准库

关于EVM的常见抱怨之一是缺乏标准库。 这不仅是开发商的烦恼，而且也是珍贵的区块链空间的直接消费者。 提供标准库不仅可以使Qtum的区块链变得更加轻薄和高效，而且它还允许这些标准库函数具有特殊的内部代码，类似于以太坊的预编译合同。 无需为新的预编译合同添加特殊支持，然后依靠合同开始使用此特殊功能，即可发生此功能。 相反，契约可以使用相同的未经优化的代码，当他们调用它时，代码是不透明的，可以随意优化，而不需要对共识做出任何改变。 像这样的标准库的优化是一个实现细节。 然而，随着生态系统的实施变得高效，气体模型可以被调整用于这些功能，以使其气体成本反映其真实的资源成本。

另外，标准库不需要fork来扩展。 通过使用分散治理协议，通用功能可以轻松地进入专用标准库存储空间。 这种机制还允许修补标准库中的错误，但必须特别审核这种权力，因为智能合约可能依赖于错误的行为来实现正确的功能。 因此，对标准库函数的潜在升级可能只能通过选入功能，或者根本不存在。 我们与DGP的目标始终保持保守，并确保即使在完全折衷的情况下，智能合同逻辑也不会受到影响，并且用户的资金安全。

优化的气体模型

这一部分非常复杂，就像预警一样，我们很可能最初会用类似于EVM的简单气体模型来启动x86 VM。 但是，由于x86和ISA的功能有多强大，因此有一些相当直接的方法可以推进这一领域。

其中一个简单但功能强大的解决方案不仅将提供一个标准库，其中包含智能合约和程序通常使用的常用功能。 但是也有一条相当直接的途径可以使这些标准库函数具有人为成本，而不是要求这些函数依赖于用于一般计算的简单和普通的气体模型。 因此，例如，简单气体模型中的strlen可能需要串中每个字符90个气体。 但是，经过开发人员的检查，发现strlen在Qtum虚拟机上实际执行起来非常便宜。 所以，Qtum的分散治理协议被用来为这个功能提出一个特殊的气体规则。 所以，现在调用这个函数的成本可能是10个气体的平坦初始成本，加上每个角色1个气体。 要制作一个完美的气体模型是不可能的，因此，我们希望利用Qtum中的DGP机制来使这种近似尽可能优化和高效。

释放AAL的全部力量

现在，我们倾向于将帐户抽象层作为“使EVM工作所必需的”。 然而，AAL的隐藏功能远远超出了Qtum之上的EVM工作所需的功能。 Qtum从一开始就设计为支持多个虚拟机，而EVM只是第一个支持的虚拟机。 也就是说，账户抽象层目前受限于可以通过EVM轻松暴露的内容。 我们正在设计的x86 VM不会遇到这种限制。 我们想要公开的一些有力的东西是因为这个：

• P2SH（比特币风格）多信用卡作为一级公民，用于发送和接收来自智能合同的付款
• 原始交易脚本支持发送自定义事务以充分利用Qtum中的脚本功能
• 允许segwit交易包含并执行智能合约

智能合约的新可能性

使用x86，我们获得了Von Neumman计算架构。 这意味着代码是数据，反之亦然。 此功能以及诸如硬件/软件中断等功能允许将潜在操作系统（如构造和功能）与多个半可信参与者集成到单个智能合约中。 这包括合作多任务处理，暂停和恢复执行（即在稍后的事务中恢复执行）以及看门狗定时器（尽管不是“时间”，它可以用于天然气）。 这当然还包括更新合同字节码的直接机制，而不需要将资金和数据转移到新合同。

x86指令集还包括许多专门的功能来控制某些代码空间的专用权限，分页和内存映射以及系统调用等。 Qtum预计不会公开大多数这些专门的系统级指令。 它们使气体模型设计变得非常复杂，并且使得一切难以优化。

尽管如此，尽管这些指令中有关智能合约的东西相对较少。 在单个智能合约代码中拥有单独的ring-0特权代码和ring-3非特权代码的公共区块链几乎没有实际需要。 如果这些功能倾向于真正流行的用例是在特权和半特权区块链中。 所以，当我们开始关注Qtum的企业方面时，我们当然会重新审视这一点。

一流的神谕

在用于事务的x86 VM模型中，如果您知道该合同所需的数据，则无需调用合同。 可以直接从外部合同的存储空间加载数据。 这允许一流的ORACLE，合同可以建立自己的ABI和API机制来标准化他们的存储空间。 然后，合同可以直接加载存储数据，不需要进行昂贵的调用，需要加载整个合约字节码，创建新的虚拟机环境等。这将最终使Oracles成为区块链上的一等公民而不是受智能合约功能的限制。 小号

区块链分析

x86可用的大内存空间以及用于一般计算的高效操作码集使得区块链分析的潜力成为EVM的一个梦想。 可以公开完整的区块链数据进行合同分析。 这可能允许基于人工智能的智能合约自动监控区块链，可能作为预言者，以便允许智能合同调整自己的行为，以便在当前网络条件下尽可能高效地运行。 这种区块链数据可能包括完整的交易数据或由区块链节点计算出的统计数据（以共识关键的方式）。 暴露这些数据没有什么坏处，因为它是完全不变的，只会导致几Mb的额外内存使用量。

替代数据存储

目前，EVM强制每个人使用指向32字节数据的32字节密钥。 这可能会非常痛苦，特别是在考虑分割和维护该空间时。 而且，这没有什么重要的理由。 因此，在x86机器中，我们打算给智能合约一个通用的键值存储。 因此，您可以存储从1到大量字节的任何内容作为关键字，并指向相同的变量值。 到目前为止，针对此功能的建议气体模型基本上涉及用于向该数据库写入/读取的固定费用，然后每个字节的每字节费率需要被触及。 当然，这个功能仍然会被stateRootHash所涵盖，以便SPV钱包可以使用这个数据库与智能合约进行交互。

显式依赖树

另一个有点崇高的目标是允许智能合约的依赖树被明确地声明和执行。 这将仅仅是一个选择功能，以便接触未知智能合约的合同仍然是可能的。 但是，对于确切知道他们依赖哪些依赖关系的合同，这允许在某些情况下并行执行这些合同，因此他们可能会获得降低的天然气成本等优点。 对于选择加入此功能的基于x86的智能合约，这将是主要的扩展优势。

为什么x86？ 为什么不是ARM？

我听到很多人问“为什么x86？为什么不是ARM？”。 这个问题问得好。 我们认为x86是虚拟机和仿真器最为人熟知的平台。 数十年来一直致力于为x86创建高效安全的虚拟机。 如果你想真正研究这一点，看看没有比Stackoverflow的许多问题关于使Android模拟器在合理的性能水平上运行。 基本上，大多数情况下，解决方案是使用x86虚拟机而不是ARM虚拟机。 当然还有一些项目用于那些不被视为可怕的ARM虚拟机，比如Qemu，我确信其他人不知道。 但关键是x86仿真是一个相当直接的解决方案的已知问题。 着名的“英特尔手册”被认为是这类CPU架构中最好的书面清晰文档。 甚至还有一些高中的孩子为了好玩而编写x86模拟器（哈哈，就是我！）。 ARM的编译器支持总是在不断改进，但它仍然没有达到与x86支持相当的地步。

现在，尽管如此，x86绝不是简单的ISA。 它自70年代以来一直存在于8008之后，自8088/8086以来一直保持向后兼容。 这确实会对设计产生影响，也就是为什么只有大量的操作码可用，其中包括一些可能无用的操作码，并且实际上在硬件上执行速度要慢于编写代码以避免这些操作。 我最喜欢的例子是诅咒的二进制编码的十进制指令集，自80年代以来一直没有受到欢迎。 然而，这是一个额外的复杂工作，需要几个小时的额外工作。 使用x86的好处远远超过成本。

尽管如此，ARM仍然处于我们的视线之内，尤其是对于通常在ARM处理器上本地运行的物联网用例。 现在我们专注于x86，但之后，谁知道，特别是对于企业和许可的区块链。

http://earlz.net/view/2017/10/02/0801/thoughts-and-goals-on-qtums-x86-vm