BTC
ETH
HTX
SOL
BNB
查看行情
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

【虛擬機專欄】智能合約執行引擎的前世今生

趣链科技 QTech
特邀专栏作者
本文約3279字,閱讀全文需要約5分鐘
Solidity作為最早提出的智能合約語言,它的出現為區塊鏈的應用場景打開了新的大門。
AI總結
展開
Solidity作為最早提出的智能合約語言,它的出現為區塊鏈的應用場景打開了新的大門。

Solidity作為最早提出的智能合約語言,它的出現為區塊鏈的應用場景打開了新的大門。

Solidity作為最早提出的智能合約語言,它的出現為區塊鏈的應用場景打開了新的大門。

Solidity作為最早提出的智能合約語言,它的出現為區塊鏈的應用場景打開了新的大門。

Solidity作為最早提出的智能合約語言,它的出現為區塊鏈的應用場景打開了新的大門。

—— 緣起——

智能合約(Smart Contract)這個術語最早於1994年由跨領域法律學者尼克·薩博(NickSzabo)⾸次提出。他對智能合約的定義如下:

“一個智能合約是一套以數字形式定義的承諾(commitment),包括合約參與方可以在上面執行這些承諾的協議。”

所以簡單來看,尼克·薩博認為智能合約是⼀套承諾。所謂承諾就是參與⽅同意的相互之間的權利和義務。因此智能合約的本質和⽬的即是承諾本身。 ⽐如⼀個簡單的買賣事件,賣家承諾供貨,買家承諾⽀付,這兩個承諾就可以形成⼀個智能合約。注意尼克·薩博對智能合約定義中提到的關鍵詞:數字形式和協議。這兩個關鍵詞決定了智能合約不同於傳統意義上的承諾,它在形式和功能上有著決定性的特徵。

「智能合約」最開始由以太坊引入區塊鏈。據以太坊白皮書,引入智能合約主要為了解決如下問題:

對於腳本語言,腳本是非圖靈完備(後文會介紹)的,難以實現複雜的功能,比如橢圓曲線簽名算法

腳本無法對可以提取的金額進行細粒度控制

腳本缺乏狀態保存,無法實現更為複雜的有狀態合約

執行時能獲取的數據不夠豐富,例如隨機數、時間戳和前一個區塊哈希的獲取

總之,腳本語言無法滿足更為豐富的應用操作,所以以太坊設計了獨特的智能合約語言Solidity,同時,執行智能合約的智能合約執行引擎EVM也誕生了。

自此,區塊鏈技術的應用場景, 從單一基於UTXO 的數字貨幣交易,延伸到圖靈完備的通用計算領域。用戶不再受限於僅能使用比特幣腳本所支持的簡單邏輯,而是可以自行設計任意複雜的合約邏輯。

—— 總述——

以太坊設計智能合約有著如下設計特點:

▲ 執行的確定性

確定性是指程序對於給定的輸入,不管在何時何地,執行多少次都有相同的輸出。由於區塊鏈維護的是同一份賬本,智能合約執行的確定性可以理解為不同的節點執行相同的合約,必須有相同的結果。

以太坊智能合約語言被設計的足夠簡單,為了保證執行的確定性,其不會實現隨機數,不確定的(系統)調用等功能,同時,智能合約的執行在一個環境被限制的虛擬機中進行,這樣能夠在底層更加保證其結果的確定性。

▲ 圖靈完備性

圖靈完備的語言,比較官方的解釋是“可以計算一切可以用一個算法計算的問題”的語言,包括無限循環。以太坊引入智能合約的目的就是為了實現圖靈完備,來支持更為豐富的應用形式。

引入圖靈完備之後需要解決的一個問題就是停機問題:在一般情況下,沒有辦法判斷給定的程序是否會停機。

為了避免圖靈完備帶來的停機問題,以太坊引入Gas機制,來對相關的執行過程進行耗費計算。通過將各種操作費用以gas(每個操作會對應特定的gas消耗即有一個gas消耗的對應表)為單位計算,並且設置每次執行的gas消耗上限,即gasLimit,在合約執行耗費累計操作gasLimit上限後強制停止執行,從而達到停機的效果。 Gas機制的引入,使得用戶對使用應用的複雜程度取決於其願意為其付出的代價,而不是平台物理上的限制。

當然,Gas機制的引入也還有其他好處,不在此處過多介紹。

▲ 安全性

安全性作為以太坊的設計前提,也是智能合約需要保證的。以太坊智能合約的安全性在設計上主要體現在兩個方面:

1)相對簡單的智能合約語言

Solidity語言相對於主流的圖靈完備語言而言,由於其專注於區塊鏈場景,所以很多語言特性其沒有必要去實現比如多線程,系統調用,這就使得其可以設計得盡可能簡化。不過這也是其早期比較難用的原因之一,雖然隨著語言的逐漸發展,其功能也在不斷的增加與完善。

以太坊智能合約運行在以太坊虛擬機EVM中,EVM中的運行不僅被沙盒化,而且實際上是完全隔離的,這意味著在EVM 中運行的代碼無法訪問網絡、文件系統或其他進程。甚至智能合約中對其他智能合約的訪問也很有限。通過運行的隔離很大程度上保證了其可控安全。

下面,讓我們深入Solidity合約的執行引擎— EVM。

正文

正文

正文

EVM被定義為一種棧式虛擬機,其使用一個字節作為指令。棧式虛擬機的特點是執行運算時都是依靠與操作數棧(operand stack)進行交互。

Solidity合約源碼經過編譯後是用一種低級的、基於堆棧的字節碼,所以我們真正部署在以太坊上並且在EVM中執行的其實是一串字節碼。代碼由一系列字節組成,其中每個字節代表一個操作。字節碼執行時從第一個字節碼開始根據字節碼的操作含義依次執行,直到到達代碼末尾或出現錯誤(如遇到REVERT 、STOP或RETURN 操作碼)。這些操作可以訪問三種類型的空間來存儲數據:

棧: 後進先出容器,其值可以被壓入和彈出;

Memory: 一個無限可擴展的字節數組;

Storage: 合約的長期存儲,為鍵/值對存儲。與計算結束後重置的堆棧和Memory不同,存儲會長期存在,這部分也就是常說的“世界狀態”的一部分。

智能合約的執行過程其實就是依據操作碼定義的行為對三種類型存儲空間的操作過程,我們以下面的例子進行簡單的展示:

下圖展示部分合約片段:左邊是合約字節碼, 右邊是字節碼代表的操作含義

各個操作碼的簡單含義如下:

PUSH1:字節碼16進制為60 ,操作含義是將緊跟著的一個字節推入棧中

ADD:字節碼16進制為01 ,操作含義是將棧上的兩個元素彈出相加,然後將結果放回棧中


MSTORE:字節碼16進制為52 ,操作含義是將棧中彈出的第二個值存入Memory中,存入的索引值為棧中彈出的第一個元素

RET:字節碼16進制為f3 ,操作含義是執行結束,返回結果,結果在Memory中,起始索引為棧中彈出的第一個值,長度為棧中彈出的第二個值

將這段字節碼放入EVM中執行,其執行過程如下所示:

其中,PC代表當前執行操作碼的位置,合約片段執行的最後(即:RET操作碼)會從Memory中的60起始處,取出5個字節的數據出來,由此,合約片段執行完畢,最終的結果會被返回給調用者!

細心的同學會發現,圖中相關的指令沒有和Storage 相關的操作,其實是因為為了簡化沒有在示例代碼中選取相關的指令如SStore ,其執行原理和上述的表述類似。

“那麼,為什麼EVM會被設計成這個樣子?為什麼通過這些棧的進進出出,內存的複制來複製去,以及對Storage的操作,就能夠解決計算問題,完成對合約狀態的獲取以及修改呢? ”

這就涉及到編程語言的設計了。理論上,在計算理論體系中,指令集架構是一個計算機的抽像模型,指令集包含的指令類型豐富程度直接影響著程序表達的豐富程度。比如,指令集中可以包含算數和邏輯運算類指令如加減乘除,控制類指令如跳轉,數據處理指令如讀取內存等。而作為虛擬機,可以根據需要選取或者添加指令構建一個指令集,來表達自己期望的功能。比如EVM中沒有針對與浮點數的相關操作,增加了Storage相關的指令,所以這就從指令層面解釋了Solidity語言不支持浮點數的運算。而在指令確定之後藉助現代程序設計的一些工具,即可設計出特定的語言。所以,在某種程度上,如果需要,我們也可以實現自己的語言以及對應的執行引擎。

—— 發展——

EVM的本質是通過可編程的語言來操作“世界狀態”,也就是我們所說得區塊鏈賬本,因此,如何更好、更快的來操作是智能合約虛擬機的一大追求。

隨著不斷的發展,行業內已擁有多種智能合約執行引擎,同時也不乏新的探索。

EVM:兼容以太坊EVM,並進行了性能優化與功能豐富

正文

作者簡介

作者簡介

正文

參考文獻

參考文獻

參考文獻

參考文獻


智能合約
歡迎加入Odaily官方社群