為何Qtum量子鏈要設計X86虛擬機器？

以下內容內容僅代表Qtum量子鏈全球首席技術官Jordan Earls

Qtum量子鏈全球首席技術官Jordan Earls原創：

原文連結：http://earlz.net/view/2017/10/02/0801/thoughts-and-goals-on-qtums-x86-vm

Qtum量子鏈x86虛擬機器的設計理念和設計目標此前， 我們一直沒有透露太多關於x86 虛擬機器在Qtum量子鏈中的應用， 只是一直提到它能夠支持更多種主流的開發語言。 這主要是因為僅僅是在設計的過程中， 很容易生成一個平庸的版本， 但是要真正構建一個優化的、高效的、易於使用的版本卻是較難實現。 所以， 本文中我不打算細講設計的細節， 而是闡明其設計目標。 支援多種程式設計語言毫無疑問， 能支援多種程式設計語言是設計x86虛擬機器的一個重要原因。

就我個人而言， 我希望在2018年能實現用Rust編寫智慧合約。 Rust是非常高效、羽量級的程式設計語言， 最重要的是， 它的安全性較高， 能夠有效避免可能存在的避免程式師在程式設計中出現的錯誤。 當然， 不僅僅是Rust， 支持c#或Go這樣的主流程式設計語言也是我們的目標。 x86 虛擬機器的基本原理是， 你可以使用任何現有的編譯器或程式設計語言， 並進行一些簡單修改， 就可以在Qtum量子鏈的作業系統上運行。 目前幾乎所有的編譯器都支援x86架構指令集， 所以實際的位元組碼和架構支援已經非常完備。 標準庫對於乙太坊虛擬機器， 最常見的吐槽是缺乏標準程式庫。 這不僅是開發者的煩惱， 也佔據了寶貴的區塊鏈存儲空間。 提供標準程式庫不僅可以使Qtum量子鏈的區塊鏈變“瘦”， 更有效率， 而且它還能為這些標準程式庫函數提供特殊的內部代碼， 類似於乙太坊的預編譯合約。 這種功能可以不需要為新的預編譯合約添加特殊支援， 即可使用。 相反的， 合約可以使用相同的未優化代碼， 當他們調用它時， 可以根據需要進行優化， 且不會對共識造成任何影響。 然而， 隨著生態系統變得越來越高效， 這些庫函數對應的gas模型可能需要進行調整， 從而能夠反映其真實的資源成本。 此外， 在Qtum區塊鏈上， 標準庫也不需要硬分叉來進行擴展。 通用函數可以輕鬆地通過使用分佈自治協議（DGP）訪問專門的標準程式庫記憶體空間。 這種機制也允許在標準庫中修補bug， 但由於智慧合約的本函數可能會依賴于這種bug行為， 故該功能必須被嚴格管控。 所以， 對標準庫函數的潛在升級可能只是通過opt-in函數， 或者根本不存在。 我們堅持使用DGP的目標是始終保持保守， 確保即使在完全妥協的情況下， 智慧合約的邏輯也不受影響， 從而保證用戶的資金安全。 優化的Gas模型這部分相當有難度的， 需要事先聲明的是， 我們很可能在最初使用一個非常簡單的gas模型(類似於乙太坊虛擬機器)啟動x86 虛擬機器。 然而， 由於x86的ISA和特性更加強大， 還有一些非常簡單的方法來推進。 其中一個相對簡單而有效的解決方案是：不僅僅提供一個包含智慧合約所需的常用函數的標準庫， 同時也為這些標準庫人為設定一個成本， 而不是要求這些函數按照所包含的通用運算指令的gas模型進行運行成本計算。 例如， 在簡單的gas模型中， strlen可能需要在每個字元上需消耗90個gas。 然而， 在開發人員檢查時， 發現實際上在Qtum量子鏈的x86虛擬機器上執行strlen卻是經濟性非常高的。 因此， Qtum量子鏈的DGP被用來為這個函數提出一個特殊的gas消耗規則。 最終， 調用這個函數的代價初始成本可能只是10個gas， 加上每個字元1個gas。 要建立一個完全精確無誤的gas模型是幾乎不可能的， 所以我們想要盡可能利用DGP， 使整個gas模型盡可能達到最優。 解鎖ALL的全部功能如今， 帳戶抽象層AAL僅僅被認為是“使乙太坊虛擬機器（EVM）在Qtum區塊鏈上正常工作”的必要條件。 然而除了讓乙太坊虛擬機器在Qtum量子鏈網路上運轉之外， AAL還有其他更多的隱藏屬性。 Qtum量子鏈設計的初衷是能夠支援多種虛擬機器， 乙太坊虛擬機器是第一個， 換句話說， 目前AAL的功能受到EVM的極大限制。 而我們正在設計的x86虛擬機器就不會面臨這些限制， 我們想要公佈關於AAL更多的強大功能如下：

P2SH：智慧合約的發送和接收使用多重簽名作為第一類公民（First class citizen）。

支援自訂原生script腳本

允許segwit交易來創建和執行合約

智慧合約的全新發展潛力x86虛擬機器採用VonNeumman電腦架構， 意味著代碼即是資料， 反之亦然。 這個特性以及諸如硬體/軟體插斷等可以帶來很多潛在的作業系統， 比如構造和特性集成到由多方參與的單個智慧合約中。 這包括類似於協作多工、暫停和恢復執行(即在後續交易中合約恢復執行)和watchdog計時器(雖然實際不是“計時”， 而是計gas)。當然，還可以實現直接更新智慧合約位元組碼的機制，而不需要將資金和資料轉移到新的智慧合約上。x86指令集還包括許多特定的函數，用於控制某些代碼空間、分頁和記憶體映射等特定的許可權，以及系統調用。Qtum量子鏈並不希望實現上述這些特定的系統級指令。它們會使gas模型的設計變得更加複雜，使一切都變得更加難以優化。

然而，儘管如此，在這一系列特定指令中，與智慧合同相關的東西相對較少。在公有鏈實現單獨的ring0特權代碼和ring3 並沒有必要。這些特性在私有鏈或聯盟鏈中或許會有用，所以在未來我們專注於Qtum企業端應用時，我們會重新評估考慮是否實現。

第一類Oracles在x86虛擬機器的交易中，如果你知道所需的合約資料，可以無須調用該合約，而是直接從外部智慧合約的存儲空間載入資料。這實際就是第一類Oracle，智慧合約可以建立他們自己的ABI和API機制來標準化其存儲空間。然後,智慧合約可以直接載入存儲資料,不需要載入整個合約位元組碼,創建一個新的虛擬機器環境等昂貴的操縱。這最終將使預言機成為區塊鏈的第一類公民，不再受限於智慧合約。 區塊鏈動態分析x86的大記憶體空間，以及它高效的操作代碼集，可以實現完整的區塊鏈資料進行智慧合約分析，這在乙太坊虛擬機器上是無法實現的。在未來有可能支持基於ai的智慧合約自動監控區塊鏈，成為潛在的oracle，允許智慧合約對自身進行動態調整，以便在當前的網路條件下盡可能高效地運行。這些區塊鏈資料可以包括完整交易資料以及節點的統計資料（共識相關）。由於這些資料都是常量，且只需要佔用極少的記憶體空間，所以公開這些資料沒有什麼弊端。 選擇性資料存儲目前，乙太坊虛擬機器強制每個使用者都使用指向32-bytekey指向32-byte資料。管理起來可能會相當痛苦，尤其是考慮到存儲空間碎片化和維護的問題。因此，在x86虛擬機器上，我們打算給智慧合約添加一個通用的key-value存儲。這樣以來，使用者就可以使用任何從1位元組到更長位元組的key，並將其指向相同長度的變數值。目前，我們提出的gas模型首先對讀/寫該資料庫的操作收取固定費用，之後再根據實際操作的位元組數進行按字計價收費。當然，這個功能也會被計入stateRootHash中，這樣SPV錢包就可以使用這個資料庫與智慧合約進行交互。 清晰的相依樹狀結構另一個設計目標是使智慧合約的依賴關係變得明確且不可變。這僅僅是一種opt-in功能，所以仍然可以允許調用未知合約。對於那些確切知道它們依賴關係的智慧合約，可以在某些特定情況下並存執行，有助於降低的gas成本，同時還有其他一些好處。這將是基於x86的智慧合約的一個主要的擴展優勢。 為什麼是x86，而不是ARM？關於這個問題，我已經聽到不止一個人問到了，這是個很好的問題。我認為x86是人們研究地最透徹的虛擬機器和模擬平臺。在基於x86構建更高效安全的虛擬機器方面，開發者們已經花了幾十年的時間集思廣益。只需看看Stackoverflow上關於提高Android模擬器性能的許多問題，你會發現大部分解決方案就是用x86代替ARM。著名的英特爾x86手冊被普遍認為是關於CPU架構提供的最出色、最清晰的文檔。甚至還有一些高中的孩子會寫x86模擬器來取樂（筆者自己就是一個例子），編譯器對ARM的支持一直在提高，但它仍然沒有達到與x86所能支持的水準。儘管如此，x86也絕不是簡單的ISA。它從70年代就有了8008，並且在8088 /8086之後一直前向相容。這確實對它的設計造成了影響，這就是為什麼有大量的op代碼（包括一些根本沒用的），實際上在它在硬體上的執行速度比你編寫代碼來避免這些指令的速度要慢。

ARM如今仍普遍運用，特別是對於那些採用ARM處理器的物聯網設備。雖然目前我們比較關注x86，但未來或許我們也可能關注ARM，特別是對於企業級私有鏈而言。

而是計gas)。當然，還可以實現直接更新智慧合約位元組碼的機制，而不需要將資金和資料轉移到新的智慧合約上。x86指令集還包括許多特定的函數，用於控制某些代碼空間、分頁和記憶體映射等特定的許可權，以及系統調用。Qtum量子鏈並不希望實現上述這些特定的系統級指令。它們會使gas模型的設計變得更加複雜，使一切都變得更加難以優化。

然而，儘管如此，在這一系列特定指令中，與智慧合同相關的東西相對較少。在公有鏈實現單獨的ring0特權代碼和ring3 並沒有必要。這些特性在私有鏈或聯盟鏈中或許會有用，所以在未來我們專注於Qtum企業端應用時，我們會重新評估考慮是否實現。

第一類Oracles在x86虛擬機器的交易中，如果你知道所需的合約資料，可以無須調用該合約，而是直接從外部智慧合約的存儲空間載入資料。這實際就是第一類Oracle，智慧合約可以建立他們自己的ABI和API機制來標準化其存儲空間。然後,智慧合約可以直接載入存儲資料,不需要載入整個合約位元組碼,創建一個新的虛擬機器環境等昂貴的操縱。這最終將使預言機成為區塊鏈的第一類公民，不再受限於智慧合約。 區塊鏈動態分析x86的大記憶體空間，以及它高效的操作代碼集，可以實現完整的區塊鏈資料進行智慧合約分析，這在乙太坊虛擬機器上是無法實現的。在未來有可能支持基於ai的智慧合約自動監控區塊鏈，成為潛在的oracle，允許智慧合約對自身進行動態調整，以便在當前的網路條件下盡可能高效地運行。這些區塊鏈資料可以包括完整交易資料以及節點的統計資料（共識相關）。由於這些資料都是常量，且只需要佔用極少的記憶體空間，所以公開這些資料沒有什麼弊端。 選擇性資料存儲目前，乙太坊虛擬機器強制每個使用者都使用指向32-bytekey指向32-byte資料。管理起來可能會相當痛苦，尤其是考慮到存儲空間碎片化和維護的問題。因此，在x86虛擬機器上，我們打算給智慧合約添加一個通用的key-value存儲。這樣以來，使用者就可以使用任何從1位元組到更長位元組的key，並將其指向相同長度的變數值。目前，我們提出的gas模型首先對讀/寫該資料庫的操作收取固定費用，之後再根據實際操作的位元組數進行按字計價收費。當然，這個功能也會被計入stateRootHash中，這樣SPV錢包就可以使用這個資料庫與智慧合約進行交互。 清晰的相依樹狀結構另一個設計目標是使智慧合約的依賴關係變得明確且不可變。這僅僅是一種opt-in功能，所以仍然可以允許調用未知合約。對於那些確切知道它們依賴關係的智慧合約，可以在某些特定情況下並存執行，有助於降低的gas成本，同時還有其他一些好處。這將是基於x86的智慧合約的一個主要的擴展優勢。 為什麼是x86，而不是ARM？關於這個問題，我已經聽到不止一個人問到了，這是個很好的問題。我認為x86是人們研究地最透徹的虛擬機器和模擬平臺。在基於x86構建更高效安全的虛擬機器方面，開發者們已經花了幾十年的時間集思廣益。只需看看Stackoverflow上關於提高Android模擬器性能的許多問題，你會發現大部分解決方案就是用x86代替ARM。著名的英特爾x86手冊被普遍認為是關於CPU架構提供的最出色、最清晰的文檔。甚至還有一些高中的孩子會寫x86模擬器來取樂（筆者自己就是一個例子），編譯器對ARM的支持一直在提高，但它仍然沒有達到與x86所能支持的水準。儘管如此，x86也絕不是簡單的ISA。它從70年代就有了8008，並且在8088 /8086之後一直前向相容。這確實對它的設計造成了影響，這就是為什麼有大量的op代碼（包括一些根本沒用的），實際上在它在硬體上的執行速度比你編寫代碼來避免這些指令的速度要慢。

ARM如今仍普遍運用，特別是對於那些採用ARM處理器的物聯網設備。雖然目前我們比較關注x86，但未來或許我們也可能關注ARM，特別是對於企業級私有鏈而言。