网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

为此 Qtum 开发账户抽象层（Account Abstraction Layer， AAL），实现 UTXO 模型与账户模型的适配。这种分层设计实现了底层账本和上层智能合约的完全解耦，也使 Qtum 后续兼容多种虚拟机（EVM，x86，WASM 等）成为可能。

AAL 要实现的工作其实很简单：UTXO 模型账户模型。

由于篇幅有限，本文只对其基本原理和遇到的问题做简要解释，感兴趣的读者可以进一步阅读《深度解析 Qtum 量子链账户抽象层》，文章从代码层面对 AAL 进行了详细剖析 。扩展比特币脚本 ― UTXO 模型 -》 账户模型比特币的 UTXO 模型采用了一套非图灵完备的脚本语言，该脚本自带的操作码并不支持合约交易。Qtum 在比特币脚本的基础上增加了 3 个操作码 ：

1. OP_CREATE ：创建智能合约

2. OP_CALL ：调用智能合约 （ 向合约发送 QTUM）

3. OP_SPEND ：花费智能合约中的 QTUM在产生新区块时，除了对交易脚本做常规的检查外，还需要检查是否包含上述的操作码。OP_CREATE 用于向 EVM 传递合约字节码。OP_CALL 将 data、gasPrice、gasLimit、VMversion 等运行智能合约所需的关键参数通过交易脚本发送，最终传递到 EVM 中。OP_SEND 则用于合约执行结果的 UTXO 转换，稍后解释。通过引入上述三个脚本，Qtum 的 UTXO 模型具备了识别和处理智能合约相关交易的能力。

02. 从 UTXO 获取的合约如何在 EVM 中运行？

合约的执行会引起状态改变，对于合约的状态，Qtum 沿用了 EVM 的定义，所以能兼容所有的符合 EVM 规范的智能合约。从上述 OP_CREATE 或 OP_CALL 提取出合约交易参数之后，即可构建运行环境。合约的运行过程基本采用了 EVM 的引擎，为使其与 Qtum 区块链进行正常交互，Qtum 完成了以下工作（这里只截取部分），供公链开发者参考 ：

1. 针对每个独立交易构建运行环境，最大限度的把不同交易的合约执行过程隔离开，避免合约执行过程中的交叉影响

2. 实现 EVM 的永久存储，当区块成为孤块或断开时，可以实现状态的回滚

3. 实 现 EVM 和 Qtum 区 块 链 间 的 接 口， 使 EVM 能够获取诸如 BLOCKHASH，COINBASE，DIFFICULTY，BLOCKNUMBER，GASLIMIT 等区块基本信息 4. 实现已部署在链上的合约间的相互调用

5. 实现合约地址获取自身余额的功能

6. 为 EVM 生成 debug 信息，方便调试智能合约

7. 重新设定各操作码的 gas 价格，因为 QTUM 和 ETH 的价格差异较大，且 EVM 的 gas模型设计略不合理，因此需要重新优化

8. 支持自毁操作码，使合约可以自毁

9. ……

感兴趣的读者可以阅读《Qtum 设计文档》获取更多设计方面的细节。在解决了上述问题之后，从 Qtum 交易传入的智能合约代码即可在 EVM 中成功运行了。该实现理论上适用于所有基于 UTXO 的项目。运行的结果会引起状态改变，这时需要使用上述的 OP_SPEND 用于花费合约中的余额，上面已经提到，无论是比特币还是 Qtum，都是通过私钥”解锁“ UTXO 脚本来花费 UTXO余额的，而 EVM 的执行涉及不同账户之间的转账，所以需要通过 OP_SPEND 实现这些转账到 UTXO 模型交易的转换，最终转化为 Qtum 标准交易脚本（对比特币交易脚本不熟悉的读者建议阅读《Mastering Bitcoin》）。

03、账户抽象层的安全性

上述的 UTXO 和账户模型的互相转换虽然实现了 Qtum 区块链与 EVM 的交互，但 AAL也引入了一个安全问题。由于合约地址本身也是一个 Qtum 的合法地址，并且底层都是UTXO 模型，这就意味着一个合约可以拥有多个 UTXO。这本身没有问题，但却给攻击者提供了 DoS 攻击的可能性。攻击者可以通过给合约发送多个小额的 UTXO，然后一次性用 OP_SPEND 花费大量 UTXO，从而导致区块大小超过限制，新区块无法被接收，使得网络无法产生新的区块。这是 UTXO 与 智能合约相结合所带来的必然问题。Qtum 的解决方案是在共识层面做优化，规定合约地址只能拥有一个 UTXO。每次合约运行结束时，都会将原来的 UTXO 和新加入的 UTXO 进行合并，从而保证合约地址始终只有一个 UTXO。