EOS代碼架構及分析（四）

什麼是智能合約

在解釋智能合約前，我們先來看看傳統合約的形態。合約的本質是由一系列條款組成，每個條款由若干條規則組成，通過向條款中輸入固定的參數，會輸出固定的結果。傳統合約需要由雙方共同參與簽署確認，同時需要第三方見證人公證後，才具有法律效應，確保合約按照既定的規則執行。這裡的第三方通常是具有法律效力的公證方，同時必須是能夠精準理解合約條款的專業機構，可以避免雙方產生糾紛。比如，在租賃合同中，需要由房東和租客雙方共同簽署，而中介則扮演了第三方見證人。

隨著信息技術的發展，紙質的合約逐漸被電子合約替代。電子合約是用程序代碼來實現合約條款，當外部條件滿足後，自動執行相應的規則，避免人工參與，提高合約執行效率。比如，信用卡自動還款、股票委託交易等，都採用了電子合約方式。

雖然電子合約實現了合約的自動化執行，但是仍然需要一個第三方仲裁機構參與，比如銀行、股票交易所。這些機構相互獨立，而且需要協作處理大量的清算、交割任務。這導致了中心化的仲裁模式產生了瓶頸。

智能合約 = 電子合約 + 去中心化仲裁 + 合約間交互

智能合約是對電子合約的進一步優化，去除了中心化的第三方仲裁機構，由區塊鏈上所有節點產生的共識，作為合約執行依據。大大減少人工參與工作，進一步提升了合約的執行效率。智能合約本質就是部署在區塊鏈上的一段可執行代碼，可以被查詢或者調用。智能合約可以與人進行交互，也可以和其它智能合約交互，合約的執行過程完全不需要額外的人工參與。

EOS智能合約分析

EOS智能合約是由一系列action組成，每個action代表一條合約條款，實現了條款中的具體規則。智能合約的執行基於C/S通信架構，分為製作智能合約、部署智能合約和調用智能合約三部分。

1.製作智能合約

智能合約的代碼放在eos/contracts/目錄下，每個智能合約對應一個獨立目錄，主要包含cpp文件、hpp文件、abi文件，例如，token合約目錄結構如下：

其中，hpp頭文件主要包含類定義、全局變數、宏定義等等；cpp源文件主要包含合約函數的實現細節；abi文件全名叫做「Application Binary Interface」（應用程序二進位介面），通過abi介面轉換層，用戶可以通過JSON格式直接調用智能合約裡面的action函數。

2.部署智能合約

用戶需要將智能合約C++代碼編譯成WASM格式（一種面向web的二進位格式，也是區塊鏈唯一能夠識別的格式），例如，編寫一個用來列印hello world的智能合約：

hello/hello.cpp：

其中，每個智能合約必須實現一個apply()函數，用來將action請求映射到具體的處理函數，具體的實現細節封裝在EOSIO_ABI宏裡面。這樣，開發者只需要專註合約業務邏輯的開發，而不必關注底層技術細節，簡化了智能合約開發的工作。

將合約代碼變成WASM格式，用於存儲在區塊鏈上：

#

生成abi文件，為其它用戶提供一個友好的action調用介面：

#

abi文件內容：

通過客戶端工具cleos，將智能合約發送給伺服器，由伺服器持久化部署在區塊鏈上，隨後可以被其它用戶調用執行該合約：

3.調用智能合約

由客戶端通過cleos命令發送action請求給伺服器。伺服器會根據action請求信息，去區塊鏈上找到對應的智能合約代碼，並將代碼載入到內存中執行，最後將執行結果返回給客戶端，下面的命令調用了hello.code智能合約的hi函數，並將「user」作為參數傳入：

#

Action處理流程

cleos會將一組action封裝成一個transaction數據包發送給伺服器。這裡借用了資料庫事務的概念，一個transaction代表一個事務，在事務內的action要麼全部執行，要麼都不執行，必須保證事務的原子性。Transaction可以包含一個action，也可以包含多個action，用json格式表示，例如：

伺服器接收到大量的action請求，然後將action派發到對應的智能合約。每個智能合約都會實現一個apply()函數，用來處理各個action請求。apply()函數包含3個參數，receiver表示處理請求的賬號，code表示合約名稱，action表示action名稱，例如：

action在運行之前，EOSIO會為action創建一個運行環境，也叫做Action 「Apply」 Context，提供程序運行所需的CPU和內存資源，具體的資源申請量取決與賬戶持有的股權比例，也就是EOS代幣。

每個伺服器都有一個action處理函數集合副本，當客戶端發起action請求後，所有伺服器會在本地運行action處理函數，並相互校驗結果，最後將確認結果返回給客戶端，具體流程如下：

智能合約的通信模型

智能合約中所謂的智能概念，就是智能合約不但可以和人交互通信，而且可以和其它智能合約進行交互通信。例如，當本次智能合約的transaction中可以調用其它智能合約的action來完成一些工作，或者在未來某個時刻觸發其它智能合約的transaction。

EOSIO支持兩種基本的通信模型，inline和deferred。其中，inline模型是指在當前的transaction中完成對其它智能合約action的調用，可以簡單的認為是transaction的嵌套調用，內部的action失敗會導致transaction整體做回退。Deferred模型是指延遲一段時間，或者滿足一定條件後才執行，也就是說不能保證一定被執行到。

EOS代碼架構及分析（一）

EOS代碼架構及分析（二）

EOS代碼架構及分析（三）

本文由作者「極簡主義」首發於巴比特資訊，未經允許不得轉載。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！