@區塊鏈小白，請多多指教！
聲明一下，如果你是剛接觸區塊鏈，希望好好讀一下比特幣[白皮書](https://bitcoin.org/bitcoin.pdf)。
區塊鏈
首選，我介紹一下區塊鏈的基礎架構，如下圖所示：
這是區塊鏈2.0結構，源於比特幣的區塊鏈技術構建了一個分布式的“全球賬本”，創造了區塊鏈1.0 時代；以智能合約為標志的區塊鏈2.0 實現了應用程序在區塊鏈上的上傳/下載和有效執行，將整個區塊鏈系統演進成一台“全球計算機”；區塊鏈3.0 的提出，使運行在企業操作系統（enterprise operation system，EOS）上的智能合約開發變得更加便捷。
區塊鏈的數據結構
以比特幣為例：每個區塊的由區塊頭(Header)和區塊體(Body)兩部分組成，其結構如圖所示：
Version：比特幣軟件當前版本號；Pre-block Hash：區塊鏈上前一個區塊的的哈希值；Merkle - root：由當前區塊中所有交易通過兩兩SHA256計算，最后得到的哈希值；Timestamp：當前區塊生成的時間；Bits：為生成當前區塊而設置的目標難度值；Nonce：工作量證明算法中用於動態改變哈希輸入值的整數。
由於我們對挖礦原理的了解，挖礦的過程中容易出現分叉，存在着“雙花”攻擊。比特幣的出塊速度大概10min左右，以太坊出塊時間為15s左右，因此出塊時間短，造成的分叉率過高。但是，以太坊引入了CHOST協議(大家可自行學習一下)來處理分叉。
共識機制
共識機制是分布式系統中實現去中心化信任的核心。這里主要了解具有代表性的共識機制和算法：PoW共識機制：依賴節點算力的工作量證明；PoS共識機制：節點所占有股權成反比的權益證明；DPoS共識機制：按既定時間段輪流產生區塊的授權股份證明機制；PBFT共識機制：基於拜占庭容錯機制。我們了解到的大部分比特幣攻擊都是從共識機制進行攻擊。
智能合約
智能合約的初衷是在沒有信任第三方可信權威參與和控制的情況下，借助計算機程序，編寫能夠自動執行合約條款的程序代碼，並將代碼嵌入到具有價值的信息化物理實體，將其作為合約各方共同信任的執行者代為履行合約規定的條款，並按合約約定創建相應的智能資產。根據所使用的編程語言和運行環境的不同，將比特幣中的智能合約稱為腳本型智能合約，將主要運行在以太坊和超級賬本中的智能合約稱為圖靈完備型智能合約，而將正在研發中的kadena 項目中的智能合約稱為可驗證合約型智能合約。
1. 腳本型智能合約：由於比特幣中的腳本僅包含指令和數據兩部分，其中涉及到的腳本指令（也稱為“操作碼”，Opcode）只需要完成有限的交易邏
輯，如編寫比特幣中UTXO 的鎖定腳本和解鎖腳本，不需要復雜的循環、條件判斷和跳轉操作，因此比特幣中的腳本型智能合約是一種基於堆棧的功能有限且編寫相對容易的簡單執行程序，支持的指令不到200 條；
2. 圖靈完備型智能合約：腳本語言被設計成為僅在有限范圍內執行有限功能的簡單執行語言，是非圖靈完備的語言。使用腳本語言編寫的交易指令雖然能夠滿足比特幣應用，但無法適應以太坊平台的開發需求。目前，以太坊主要使用Solidity和Serpent兩種智能合約開發語言。其中，Solidity 是一種語法上類似於JavaScript 的專門針對運行在以太坊虛擬機（environment virtual machine，EVM）上的智能合約開發而設計的高級編程語言，也是以太坊平台主推的智能合約開發語言；Serpent 語言的設計類似於Python，具有高效易用的編程風格，是專門針對智能合約的特征而開發的高級語言。在Hyperledger Fabric 中采用GO、Java 等通用語言編寫運行在Docker 容器中的智能合約，GO和Java 都是通用性較強的圖靈完備語言，能夠實現基於聯盟鏈智能合約開發中所需要的應用邏輯；
3. 可驗證合約型智能合約：可驗證語言Pact 的語法類似於LISP 語言，用於編寫運行在區塊鏈Kadena 上的智能合約，可實現合約的數據存儲和授
權驗證等功能。Pact 語言采用非圖靈完備設計，不支持循環和遞歸，以防止在復雜合約的編程過程中可能存在的安全漏洞以及因此而帶來的風險。用Pact語言編寫的智能合約代碼直接嵌入在區塊鏈上運行，不需要事先編譯成為運行在特定環境（如以太坊EVM）的機器代碼。
智能合約運行機制
Docker容器原理
參考其他博主: (https://blog.csdn.net/yc199505/article/details/72366982).
智能合約主要包括以下幾個階段:
1. 智能合約代碼的生成 ：在合約各方就傳統意義上的合同內容達成一致的基礎上，通過評估確定該合同是可以通過智能合約實現的（是可編程
的），然后由程序員利用合適的開發語言將以自然語言描述的合同內容編碼成為可執行的機器語言。
2. 編譯：利用開發語言編寫的智能合約代碼一般不能直接在區塊鏈上運行，而需要在特定的沙箱環境（以太坊為EVM，超級賬本為Docker 容器）中
執行，因此在將合約文件上傳到區塊鏈之前需要利用編譯器對原代碼進行編譯，生成符合沙箱環境運行要求的字節碼。
3. 提交：智能合約的提交和調用是通過“交易”（transaction，Txn）來完成。當用戶以交易形式發起提交合約文件后，通過P2P 網絡進行全網廣播，各節點在進行驗證后存儲在區塊中。
4. 確認：被驗證后的有效交易被打包進新區塊，經過共識機制，新區塊添加到區塊鏈的主鏈。根據交易生成智能合約的賬戶地址，之后可以利用該
賬戶地址通過發起交易來調用合約，節點對經驗證有效的交易進行處理，被調用的合約在沙箱中執行。
結構圖如下：
Hyperledger Fabric中智能合約實現技術
Docker 容器是一個使用廣泛的、開源的沙箱環境，Hyperledger Fabric 中的智能合約chaincode（鏈碼）就運行在輕量級的Docker 容器中，並通過gRPC協議與相應的Peer 節點（即存儲賬本、chaincode 等關鍵數據，並執行背書及chaincode 代碼等特定程序的物理節點）進行交互。基於Docker 容器具有的安全隔離功能，避免了區塊鏈宿主程序遭受容器中惡意合約的攻擊，同時防止運行在不同容器中的合約之間的相互干擾。chaincode 的運行過程主要包括：
1. 打包（package） ：將chaincode 安裝在Peer 節點，包括創建包和對包簽名。具體是指將用開發語言（多使用GO 語言）編寫的源代碼按照chaincode 部署規范（chaincode deployment spec，CDS）重新定義，並通過簽名來檢查和確認chaincode 的所有者。如果要讓chaincode 擁有多個所有者，首先需要創建一個被簽名的chaincode 包（SignedCDS 包），然后讓這個包依次被每個所有者進行簽名。
2. 安裝(install)：將CDS 規定格式的chaincode安裝在一個將要運行該合約的Peer節點上。chaincode只被安裝在合約所有者的背書節點上，安裝的實質是代碼的編譯過程。
3. 實例化(instantiate)：調用生命周期系統chaincode（lifecycle system chaincode，LSCC)，在channel（即基於交易規則將區塊鏈網絡划分后形成的邏輯單元）上啟動一個Docker 容器，實現合約與channel的綁定。實例化過程，會生成對應channel 的Docker鏡像和Docker 容器，可以指定背書策略。在成功進行了實例化后，處於激活狀態的chaincode 將監聽並接收交易請求。。
4. 更新(upgrade) ：更新是一個類似於實例化的交易，即將新版本的chaincode 與channel 綁定。更新后其他與舊版本綁定的channel 仍舊運行舊版本的chaincode。
5. 刪除(delete)：刪除chaincode 對應的Docker容器以及每個安裝合約的背書節點上的SignedCDS包。在正在開發的版本中，將用stop 和start 交易的指令來停止或重啟chaincode，而不需要直接將其刪除。
喜歡的請多多關注，多多收藏！共勉！
[1]: Nakamoto S. Bitcoin: a peer-to-peer electronic cash system[EB/OL]. (2018-06-10)[2020-03-10]. https://bitcoin.org/bitcoin.pdf.
[2]:王群, 李馥娟, 王振力, 等. 區塊鏈原理及關鍵技術[J]. 計算機科學與探索, 2020, 14(10): 1621-1643.