【譯】Thoughts and Goals on Qtum's x86 VM

是以，我們一直對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