Qtum是一个开源的区块链平台，结合了比特币的核心技术UTXO模型，同时通过账户抽象层兼容包括以太坊虚拟机在内的多个虚拟机。Qtum使用PoS权益证明共识机制，同时使用了SPV的验证方法使得应用可以在移动设备上运行，尤其在移动设备及IOT行业有广泛应用。同时QTUM采用去中心化的治理协议（DGP），可以在不分叉主链或带来其他系统影响的情况下更改区块的底层参数。
QTUM X86虚拟机
今天希望能重点介绍一下我们正在搭建的虚拟机，预计2018年中旬或下旬能出原型或测试版。我们希望把主流的编程语言比如C++、Rust、Go、C#，Java引入进智能合约体系里。因为我们认为目前我们在智能合约生态里不是需要更多看起来很光鲜的工具，而是编程的稳定性和可预测。X86虚拟机支持i686指令集。基本上意思是编译器本来就可以用，唯一需要做的就是把类似C++、Rust等的编译器引入到QTUM的智能合约操作系统中。虚拟机也是运行在去中心化的分布在区块链上，所以也可以使用时间戳和其他功能。X86虚拟机最突出的有点就是会比以太坊虚拟机（EVM）在调用和引入智能合约时更快、gas price更低。因为需要调用节点的资源更少，所以gas price费用更低。
支持主流编程语言
X86虚拟机的首批主流语言包括C，C++和Rust。选择C和C++是因为总体来说相对简单，而选择Rust是因为相对轻便而且其设计理念特别重视安全，可以很好的防止bug。目前我们已经实现了一个GCC工具链原型，可以支持C，C++以及非常基础的libC库。接下来我们会针对Go和Python开发。在X86虚拟机环境开发基本上类似嵌入式开发。在开发的过程中我们需要尤其注意安全性，尽量去除安全隐患。
鼓励高效的智能合约
我们在开发过程中遇到的一个最头疼的问题就是所有的东西都是开放的，所以我们在设置gas price的时候需要假定开发者会适用我们提供给他们的所有功能。在这个假设下，X86虚拟机对那些设置了限制同时定义所需功能的智能合约给与gas price折扣。我们鼓励开发者优化和简化智能合约。假定一个Dapp每天有100笔交易，那我们所指定的这个奖励机制就会帮开发团队省下一笔可观的钱。具体包括依赖关系提示、仅适用于静态、不可重入、non-payable等等。
可以显示是用了哪种依赖，可能有一个智能合约需要查询这个主链上的某个智能合约，或者这个主链上的某个库。如果把这些依赖关系都明确出来，那主链在运行该合约的时候就会很清楚哪些能够并行运行，两者之间没有共享可变状态。仅适用静态，是指合约没有可以执行的状态，唯一的状态就是返回的任何状态。 我们将利用这些手段让所有的智能合约开发者和Dapps开发者在这个生态系统中自然而然地通过自由市场手段走到一起，确保开发环境的便洁。
全新的存储方法
对于EVM我们遇到另一个比较棘手的是存储，一切都是256位或32字节。 所以，即便你想存储的数据只是一位的flag，仍然需要256位数据。如果有多个flag，就得想办法封装或者用更复杂的操作。 我们提供的x86是一个新的数据库，你可以存储大量你想要的数据作为通用键值存储的地方。 键或值没有数据大小限制。
接下来，我想介绍更先进的Oracle。在以太坊，如果你写了一个提供柏林天气的预测的合约，然后有一个智能合约想要访问这些数据，那么它就必须加载整个字节码，然后启动一个完整的EVM实例，然后执行代码，找出它在代码中采用的方法，最后从数据库返回数据。我们的存储方法则去掉了中间部分，如果你有一个智能合约想要访问数据，你可以去Oracle合约，并告诉这个合约只给你数据，不需要执行合约。这样运行可以节省大量的gas price。
X86还拥有更快的内部存储设计，你可以]直接访问它。由于开发者可以享受更低的gas price，因此在区块链上节省了大量的资源。X86从内部设计上都更快，因为它是随机分布的，而且很难预测哪一部分数据在哪里，因为是由一个复杂的索引来访问的，因为必须通过随机分布在磁盘上的多个散列进行迭代。我们的设计有更完善的索引，以使其能够在较低的存储设备上工作并且整体上更快。
可信库
在以太坊生态系统中另一个常见的麻烦是delegate call系统。这实际上也是是Parity multi-sig亏损了一亿美元的原因。他们有一个delegate call系统，这意味着他们拥有一个核心智能合约，是其他智能合约的基础。而这个为数百个其他账户提供依赖的主合约自毁，不再存在。所以导致钱仍然在，但确定谁可以访问它自已的合约不存在，所以没有人可以访问它。这个问题的答案是可信库（Trusted Library)。一个可信库合约本身非常明确，可以预先给自己设定不同的限制。这样做的目的是一旦写完了，所有的东西都可以由节点甚至手工进行简单的预编译。Trusted Library不能被支付，因为没有必要；这个库不能存储状态，因为理想的情况是它只存储功能的结果，然后返回合约所需要的结果。可以执行非常简单的code，比如确定字符串名称，或者非常复杂的code比如加密算法。这背后的想法是，我们拥去中心化治理协议（DGP）来让某些功能更快，用更少的gas。我们把这个可信库特殊处理，它执行的是本地代码，速度非常快。通过DGP，在不用分叉或者任何强制性的节点升级或者导致任何生态系统终端的前提下，我们可以把执行该合约的gas设定在某个固定的值，而不是一些动态的。比如我们可以把某个合约的gas定为100个gas。智能合约开发人员可以浏览可信库的列表，这个可信库是被预先证明可信而且优化了的，因为我们可以预先编译或适用本机代码。然后，他们可以从这个可信库中选择，而不是自己实现或部署额外的代码，也不用位额外的代码付费。
错误处理
另外，X86虚拟机实际上可以处理错误。如果你在Solidity程序中有错误，那么基本上没有什么可以补救的。它会消耗掉所有gas，没法预先捕捉到错误，或从故障中恢复或恢复gas。相反，X86具有错误处理功能，可以预先捕捉错误并确定错误发生的位置，并确定要做什么，是保留所有的gas，还是可以恢复状态，将剩下的gas返还给执行合约的账户。这与“gas提示”类似。智能合约开发类似于实时操作系统开发。时间没有限制，但是gas有限。如果合约需要比预期更多的gas，那么你将最终用完，而且将无法恢复它。我们希望部署一个计时器系统，提醒gas消耗量，以及确定要做什么。这样如果合约运行完全出乎意料，或者gas不够，我可以回到某种紧急状态。这一块是我们目前重点研究的方向。
其他新功能
在QTUM里，一笔交易不仅仅是执行一个合约或者一笔汇款，也可以同时处理多个合约或者交易。理论上讲，你可以在一次交易中执行三份合约，并且把钱转给五个不同的人。这是UTXO系统本身的优势。在新的X86虚拟机，我们有一个新的概念叫做Tagging，你可以执行一个智能合约，不一定是转钱，但可以看到这个交易被执行并完成交易，这笔钱就会发送给这个人。所以，我要存储这个状态，并有可能从托管中释放资金。此外，我们将允许合约升级，无需迁移或转发合约。现在在以太坊，如果你想升级合约，你将不得不首先使用转发合约。总的来说，这不是很有效率。因为未知的依赖关系很难预编译或优化。所以我们允许保留合约，合约所有状态和所有可能持有的硬币，但可以升级用于执行的字节码，无论何时启动或调用。
关于可信库还有一点，如果社区开发者要为比如说压缩写一个可信库，他们写了一个非常好的实现或导入已经存在的东西，然后可信库可以来进行审计，证明它是安全的。假如这个可信库里有100个智能合约，我们可以可以通过DGP来降低gas price，因为我们已经实现了一些优化。一些节点有本地的实现，他们用合约字节代码替换。我们也可以通过DGP来让这份合约gas消耗更低。因为现在在Solidity上，所以会有潜在的预加载合约。你可以在合约中做一些反复的工作，你将不得不支付两个全价的合约调用，然后在内部重新加载合约代码。有了这个，你基本上会说：“好吧，我需要加载这个代码，但是我不需要调用它，稍后我会调用它”。加载与实际执行代码是分开的。gas price要便宜得多。有可能在未来我们可以拥有多线程的智能合约。它将允许你有独立的线程，不触及其他代码，可以像在孤立的沙盒中并行执行。
与以太坊使用WebAssembly的方法相比，我个人认为WebAssembley非常有趣，但是它非常年轻，而且在设计上并不完整，还是一个pre-alpha的预测试版本。在安全性能上写起来更加复杂，因为这是非传统方法。 我们从WebAssembly的核心开发团队也能看得出来，基本没有智能合约背景的开发人员。所以大致可以看出来它还是主要针对浏览器，而不是智能合约。
今天对X86虚拟机的介绍就到这里，如果对我们的技术感兴趣请关注我们的每周开发进度。谢谢！