Qtum賬戶抽象層（AAL）實現簡析

Qtum設計上以比特幣UTXO為基礎賬戶模型，并實現了支持EVM規(guī)范的智能合約，這是通過賬戶抽象層（Account Abstract Layer， AAL）來完成的。AAL對UTXO賬戶和EVM合約賬戶之間進行了適配，這樣通過AAL可以使用UTXO交易輸出實現在鏈上創(chuàng)建智能合約，發(fā)送交易到合約賬戶用于觸發(fā)合約的執(zhí)行，完成執(zhí)行后AAL最終對執(zhí)行結果進行處理并適配至UTXO。由于采用了AAL，合約開發(fā)者不需關心對合約操作相關的UTXO轉換細節(jié)，即可使用EVM的特性進行開發(fā)而且兼容現有以太坊的智能合約。本文通過對從UTXO交易到智能合約執(zhí)行的實現代碼進行解讀，初略分析了AAL的工作過程。

1.UTXO交易新增的腳本操作碼

Qtum 針對UTXO交易腳本新增了三個操作碼OP_CREATE，OP_CALL和OP_SPEND，目的是用于為UTXO和EVM賬戶模型之間的轉換提供操作支持。這些操作碼定義在opcodetype枚舉類型中：

這個三個操作碼分別有以下作用：

OP_CREATE用于智能合約的創(chuàng)建；

OP_CALL用于合約的執(zhí)行；

OP_SPEND用于合約余額的花費。

為了在區(qū)塊生成過程中，識別并處理由這幾個操作碼控制的交易，在用于UTXO模型交易的類CTransaction中增加了HasCreateOrCall（）和HasOpSpend（）函數，用于新區(qū)塊中對mempool中的交易處理，并在腳本操作碼解析的EvalScript（）函數中增加了相應的處理。

2.UTXO交易到EVM模型交易的轉換

產生新的區(qū)塊時，除了對UTXO交易進行常規(guī)的參數合法性、共識規(guī)則、DDOS攻擊檢查等之外，還需要使用操作碼檢查函數HasCreateOrCall（）判斷交易輸出是否包含OP_CREATE或OP_CALL，分別對應著EVM需要執(zhí)行合約創(chuàng)建或合約調用。這部分有以下的處理過程：

2.1 進行EVM模型的賬號參數提取

合約在EVM的執(zhí)行用到了data、gasPrice、gasLimit、VM version這幾個參數，這些參數是通過RPC調用sendtocontract 發(fā)送的，sendtocontract會生成一個UTXO交易，并在交易輸出中使用了OP_CALL操作碼，之后交易會廣播到區(qū)塊鏈網絡上。AAL中從UTXO到EVM的適配是通過QtumTxConverter類實現的，在這一步中該類的成員函數extractionQtumTransactions（）和parseEthTXParams（）完成對所有此類UTXO交易輸出的參數提取。代碼片段如下：

以上代碼首先判斷如果opcode 為OP_CALL，則說明地址為vecAddr的合約已經創(chuàng)建，因此直接轉換成EVM格式的地址receiveAddress，否則為OP_CREATE，對應合約的創(chuàng)建，沒有該字段，所以不做提取。接下來依次完成了data、gasPrice、gasLimit、VM version的提取，這些都是EVM執(zhí)行bytecode時必不可少的參數。

2.2 進行EVM賬戶模型的交易轉換

交易轉換是通過QtumTxConverter類的函數 createEthTX（）完成，使用前面一步提取的參數和UTXO的交易輸出vout創(chuàng)建了QtumTransaction類型的交易。由于QtumTransaction派生自EVM中的dev：：eth：：Transaction類，因此和EVM執(zhí)行相關的操作QtumTransaction類都支持。

首先代碼etp.receiveAddress == dev：：Address（）判斷該合約是EVM狀態(tài)中沒有而需要新創(chuàng)建的還是EVM狀態(tài)已經包含的合約，差別只在于合約地址。然后，QtumTransaction（）構造函數完成了部分的交易參數構造，接下來的語句提取交易的發(fā)送者（sender），之后設置交易HASH。一個UTXO交易支持多個輸入和輸出，Qtum的AAL設計考慮到了這種情況，因此AAL支持一個交易輸出包含UTXO賬號和合約賬號，通過最后設置的nOut指示該交易的nOut輸出是發(fā)送到智能合約的，所以該輸出將觸發(fā)合約執(zhí)行。這樣就按照EVM的賬號模型完成了交易的轉換。

3.合約執(zhí)行及執(zhí)行結果的UTXO轉換

合約的執(zhí)行會改變狀態(tài)（由QtumState類的實例化對象globalState統(tǒng)一管理），對于合約的狀態(tài)，Qtum沿用了EVM定義，所以能兼容所有的符合EVM規(guī)范的智能合約。但是賬戶金額的轉移（transfer），Qtum做了UTXO的轉換，這意味著智能合約和普通的UTXO模型賬號之間能完成交互，這是AAL實現UTXO支持智能合約的重要的一環(huán)。下面簡要介紹一下合約執(zhí)行和狀態(tài)結果的轉換過程。

3.1 合約執(zhí)行環(huán)境構建及合約執(zhí)行

合約的執(zhí)行是對合約處理中很關鍵的一步，直接對合約的狀態(tài)產生影響。通過ByteCodeExec類實現了EVM對合約bytecode的執(zhí)行，主要函數是performByteCode（）。這一步的主要流程是使用上面提取的交易參數，來進行虛擬機執(zhí)行環(huán)境的構建，之后完成合約的執(zhí)行，其代碼如下：

首先是構建合約執(zhí)行環(huán)境，由BuildEVMEnvironment（）完成?？梢钥吹竭@個執(zhí)行環(huán)境是針對每個獨立交易進行的，這樣就最大限度的把不同交易的合約執(zhí)行過程隔離開，避免合約執(zhí)行過程中的交叉影響。然后構建一個新的sealEngine類，該類是EVM執(zhí)行引擎，由createSealEngine（）函數具體完成。中間對出現的可能狀態(tài)異常進行檢查，之后globalState-》execute（）完成合約的執(zhí)行，這里使用到了構建的執(zhí)行環(huán)境envInfo和EVM執(zhí)行引擎se。

3.2 合約執(zhí)行結果的UTXO轉換

合約執(zhí)行完成后的結果保存在vector《ResultExecute》 result，vector向量理記錄了每個合約執(zhí)行產生的EVM賬戶間transfer關系，AAL通過把這些transfer轉換成UTXO交易，完成了從EVM賬戶模型到UTXO模型交易的轉換。這一處理是通過processingResults（）函數實現的，以下是代碼片段。

首先定義了ByteCodeExecResult類型的resultBCE變量，用于保存轉換的結果。使用操作碼OP_SPEND，用于實現交易的花費，這是因為比特幣的UTXO通過私鑰簽名在交易輸入解鎖后來實現余額花費的，而EVM執(zhí)行涉及不同賬戶之間的transfer，所以需要通過OP_SPEND實現這些transfer到UTXO模型交易的轉換。如果execRes.excepted不為None，即合約執(zhí)行異常，則將余額返還給合約調用者。否則，如果沒有異常，則將扣除消耗的gas之后的剩余gas返還給合約的調用者。對于合約執(zhí)行中出現的transfer其UTXO交易保存在result［i］.tx中。因此，經過這一步處理合約執(zhí)行產生的不同UTXO賬戶之間的交易就保存在valueTransfers向量中了，最終這些交易會包含進新的區(qū)塊中。至此AAL模塊就完成了從EVM交易到UTXO的轉換。

4.總結

AAL通過新增的UTXO腳本操作碼，協(xié)助完成合約的創(chuàng)建、執(zhí)行和花費。在合約創(chuàng)建和執(zhí)行前，需要進行UTXO交易到EVM模型交易的轉換，之后使用構建的EVM執(zhí)行環(huán)境和引擎，完成合約的執(zhí)行。AAL最終對合約的執(zhí)行結果進行處理并從EVM適配至UTXO，這樣就實現了基于UTXO的智能合約。AAL使得Qtum兼容符合EVM規(guī)范的智能合約，為Dapp提供一個新的基礎平臺，同時UTXO的優(yōu)點使得諸如并行處理、隱私性等優(yōu)點能得以保留。