區塊鏈peer命令
❶ 如何用JavaScript實現區塊鏈
<span style="font-family:Arial, Helvetica, sans-serif;">'use strict';</span>var CryptoJS = require("crypto-js");var express = require("express");var bodyParser = require('body-parser');var WebSocket = require("ws");var http_port = process.env.HTTP_PORT || 3001;var p2p_port = process.env.P2P_PORT || 6001;var initialPeers = process.env.PEERS ? process.env.PEERS.split(',') : [];class Block { constructor(index, previousHash, timestamp, data, hash) { this.index = index; this.previousHash = previousHash.toString(); this.timestamp = timestamp; this.data = data; this.hash = hash.toString(); }}var sockets = [];var MessageType = { QUERY_LATEST: 0, QUERY_ALL: 1, RESPONSE_BLOCKCHAIN: 2};var getGenesisBlock = () => { return new Block(0, "0", 1465154705, "my genesis block!!", "");};var blockchain = [getGenesisBlock()];var initHttpServer = () => { var app = express(); app.use(bodyParser.json()); app.get('/blocks', (req, res) => res.send(JSON.stringify(blockchain))); app.post('/mineBlock', (req, res) => { var newBlock = generateNextBlock(req.body.data); addBlock(newBlock); broadcast(responseLatestMsg()); console.log('block added: ' + JSON.stringify(newBlock)); res.send(); }); app.get('/peers', (req, res) => { res.send(sockets.map(s => s._socket.remoteAddress + ':' + s._socket.remotePort)); }); app.post('/addPeer', (req, res) => { connectToPeers([req.body.peer]); res.send(); }); app.listen(http_port, () => console.log('Listening http on port: ' + http_port));};var initP2PServer = () => { var server = new WebSocket.Server({port: p2p_port}); server.on('connection', ws => initConnection(ws)); console.log('listening websocket p2p port on: ' + p2p_port);};var initConnection = (ws) => { sockets.push(ws); initMessageHandler(ws); initErrorHandler(ws); write(ws, queryChainLengthMsg());};var initMessageHandler = (ws) => { ws.on('message', (data) => { var message = JSON.parse(data); console.log('Received message' + JSON.stringify(message)); switch (message.type) { case MessageType.QUERY_LATEST: write(ws, responseLatestMsg()); break; case MessageType.QUERY_ALL: write(ws, responseChainMsg()); break; case MessageType.RESPONSE_BLOCKCHAIN: handleBlockchainResponse(message); break; } });};var initErrorHandler = (ws) => { var closeConnection = (ws) => { console.log('connection failed to peer: ' + ws.url); sockets.splice(sockets.indexOf(ws), 1); }; ws.on('close', () => closeConnection(ws)); ws.on('error', () => closeConnection(ws));};var generateNextBlock = (blockData) => { var previousBlock = getLatestBlock(); var nextIndex = previousBlock.index + 1; var nextTimestamp = new Date().getTime() / 1000; var nextHash = calculateHash(nextIndex, previousBlock.hash, nextTimestamp, blockData); return new Block(nextIndex, previousBlock.hash, nextTimestamp, blockData, nextHash);};var calculateHashForBlock = (block) => { return calculateHash(block.index, block.previousHash, block.timestamp, block.data);};var calculateHash = (index, previousHash, timestamp, data) => { return CryptoJS.SHA256(index + previousHash + timestamp + data).toString();};var addBlock = (newBlock) => { if (isValidNewBlock(newBlock, getLatestBlock())) { blockchain.push(newBlock); }};var isValidNewBlock = (newBlock, previousBlock) => { if (previousBlock.index + 1 !== newBlock.index) { console.log('invalid index'); return false; } else if (previousBlock.hash !== newBlock.previousHash) { console.log('invalid previoushash'); return false; } else if (calculateHashForBlock(newBlock) !== newBlock.hash) { console.log(typeof (newBlock.hash) + ' ' + typeof calculateHashForBlock(newBlock)); console.log('invalid hash: ' + calculateHashForBlock(newBlock) + ' ' + newBlock.hash); return false; } return true;};var connectToPeers = (newPeers) => { newPeers.forEach((peer) => { var ws = new WebSocket(peer); ws.on('open', () => initConnection(ws)); ws.on('error', () => { console.log('connection failed') }); });};var handleBlockchainResponse = (message) => { var receivedBlocks = JSON.parse(message.data).sort((b1, b2) => (b1.index - b2.index)); var latestBlockReceived = receivedBlocks[receivedBlocks.length - 1]; var latestBlockHeld = getLatestBlock(); if (latestBlockReceived.index > latestBlockHeld.index) { console.log('blockchain possibly behind. We got: ' + latestBlockHeld.index + ' Peer got: ' + latestBlockReceived.index); if (latestBlockHeld.hash === latestBlockReceived.previousHash) { console.log("We can append the received block to our chain"); blockchain.push(latestBlockReceived); broadcast(responseLatestMsg()); } else if (receivedBlocks.length === 1) { console.log("We have to query the chain from our peer"); broadcast(queryAllMsg()); } else { console.log("Received blockchain is longer than current blockchain"); replaceChain(receivedBlocks); } } else { console.log('received blockchain is not longer than received blockchain. Do nothing'); }};var replaceChain = (newBlocks) => { if (isValidChain(newBlocks) && newBlocks.length > blockchain.length) { console.log('Received blockchain is valid. Replacing current blockchain with received blockchain'); blockchain = newBlocks; broadcast(responseLatestMsg()); } else { console.log('Received blockchain invalid'); }};var isValidChain = (blockchainToValidate) => { if (JSON.stringify(blockchainToValidate[0]) !== JSON.stringify(getGenesisBlock())) { return false; } var tempBlocks = [blockchainToValidate[0]]; for (var i = 1; i < blockchainToValidate.length; i++) { if (isValidNewBlock(blockchainToValidate[i], tempBlocks[i - 1])) { tempBlocks.push(blockchainToValidate[i]); } else { return false; } } return true;};var getLatestBlock = () => blockchain[blockchain.length - 1];var queryChainLengthMsg = () => ({'type': MessageType.QUERY_LATEST});var queryAllMsg = () => ({'type': MessageType.QUERY_ALL});var responseChainMsg = () =>({ 'type': MessageType.RESPONSE_BLOCKCHAIN, 'data': JSON.stringify(blockchain)});var responseLatestMsg = () => ({ 'type': MessageType.RESPONSE_BLOCKCHAIN, 'data': JSON.stringify([getLatestBlock()])});var write = (ws, message) => ws.send(JSON.stringify(message));var broadcast = (message) => sockets.forEach(socket => write(socket, message));connectToPeers(initialPeers);initHttpServer();initP2PServer();
❷ 區塊鏈技術框架有哪些
當前主流的區塊鏈架構包含六個層級：網路層、數據層、共識層、激勵層、合約層和應用層。圖中將數據層和網路層的位置進行了對調，主要用途將在下一節中詳述。
網路層：區塊鏈網路本質是一個P2P（Peer-to-peer點對點）的網路，網路中的資源和服務分散在所有節點上，信息的傳輸和服務的實現都直接在節點之間進行，可以無需中間環節和伺服器的介入。每一個節點既接收信息，也產生信息，節點之間通過維護一個共同的區塊鏈來同步信息，當一個節點創造出新的區塊後便以廣播的形式通知其他節點，其他節點收到信息後對該區塊進行驗證，並在該區塊的基礎上去創建新的區塊，從而達到全網共同維護一個底層賬本的作用。所以網路層會涉及到P2P網路，傳播機制，驗證機制等的設計，顯而易見，這些設計都能影響到區塊信息的確認速度，網路層可以作為區塊鏈技術可擴展方案中的一個研究方向；
數據層：區塊鏈的底層數據是一個區塊+鏈表的數據結構，它包括數據區塊、鏈式結構、時間戳、哈希函數、Merkle樹、非對稱加密等設計。其中數據區塊、鏈式結構都可作為區塊鏈技術可擴展方案對數據層研究時的改進方向。
共識層：它是讓高度分散的節點對區塊數據的有效性達到快速共識的基礎，主要的共識機制有POW（Proof Of Work工作量證明機制），POS（Proof of Stake權益證明機制），DPOS（Delegated Proof of Stake委託權益證明機制）和PBFT（Practical Byzantine Fault Tolerance實用拜占庭容錯）等，它們一直是區塊鏈技術可擴展方案中的重頭戲。
激勵層：它是大家常說的挖礦機制，用來設計一定的經濟激勵模型，鼓勵節點來參與區塊鏈的安全驗證工作，包括發行機制，分配機制的設計等。這個層級的改進貌似與區塊鏈可擴展並無直接聯系。
合約層：主要是指各種腳本代碼、演算法機制以及智能合約等。第一代區塊鏈嚴格講這一層是缺失的，所以它們只能進行交易，而無法用於其他的領域或是進行其他的邏輯處理，合約層的出現，使得在其他領域使用區塊鏈成為了現實，以太坊中這部分包括了EVM(以太坊虛擬機)和智能合約兩部分。這個層級的改進貌似給區塊鏈可擴展提供了潛在的新方向，但結構上來看貌似並無直接聯系
應用層：它是區塊鏈的展示層，包括各種應用場景和案例。如以太坊使用的是truffle和web3-js.區塊鏈的應用層可以是移動端，web端，或是是融合進現有的伺服器，把當前的業務伺服器當成應用層。這個層級的改進貌似也給區塊鏈可擴展提供了潛在的新方向，但結構上來看貌似並無直接聯系。
鏈喬教育在線旗下學碩創新區塊鏈技術工作站是中國教育部學校規劃建設發展中心開展的「智慧學習工場2020-學碩創新工作站 」唯一獲準的「區塊鏈技術專業」試點工作站。專業站立足為學生提供多樣化成長路徑，推進專業學位研究生產學研結合培養模式改革，構建應用型、復合型人才培養體系。
❸ 區塊鏈的核心技術是什麼
簡單來說，區塊鏈是一個提供了拜占庭容錯、並保證了最終一致性的分布式資料庫；從數據結構上看，它是基於時間序列的鏈式數據塊結構；從節點拓撲上看，它所有的節點互為冗餘備份；從操作上看，它提供了基於密碼學的公私鑰管理體系來管理賬戶。
或許以上概念過於抽象，我來舉個例子，你就好理解了。
你可以想像有 100 台計算機分布在世界各地，這 100 台機器之間的網路是廣域網，並且，這 100 台機器的擁有者互相不信任。
那麼，我們採用什麼樣的演算法（共識機制）才能夠為它提供一個可信任的環境，並且使得：
節點之間的數據交換過程不可篡改，並且已生成的歷史記錄不可被篡改；
每個節點的數據會同步到最新數據，並且會驗證最新數據的有效性；
基於少數服從多數的原則，整體節點維護的數據可以客觀反映交換歷史。
區塊鏈就是為了解決上述問題而產生的技術方案。
二、區塊鏈的核心技術組成
無論是公鏈還是聯盟鏈，至少需要四個模塊組成：P2P 網路協議、分布式一致性演算法（共識機制）、加密簽名演算法、賬戶與存儲模型。
1、P2P 網路協議
P2P 網路協議是所有區塊鏈的最底層模塊，負責交易數據的網路傳輸和廣播、節點發現和維護。
通常我們所用的都是比特幣 P2P 網路協議模塊，它遵循一定的交互原則。比如：初次連接到其他節點會被要求按照握手協議來確認狀態，在握手之後開始請求 Peer 節點的地址數據以及區塊數據。
這套 P2P 交互協議也具有自己的指令集合，指令體現在在消息頭（Message Header) 的 命令（command）域中，這些命令為上層提供了節點發現、節點獲取、區塊頭獲取、區塊獲取等功能，這些功能都是非常底層、非常基礎的功能。如果你想要深入了解，可以參考比特幣開發者指南中的 Peer Discovery 的章節。
2、分布式一致性演算法
在經典分布式計算領域，我們有 Raft 和 Paxos 演算法家族代表的非拜占庭容錯演算法，以及具有拜占庭容錯特性的 PBFT 共識演算法。
如果從技術演化的角度來看，我們可以得出一個圖，其中，區塊鏈技術把原來的分布式演算法進行了經濟學上的拓展。
在圖中我們可以看到，計算機應用在最開始多為單點應用，高可用方便採用的是冷災備，後來發展到異地多活，這些異地多活可能採用的是負載均衡和路由技術，隨著分布式系統技術的發展，我們過渡到了 Paxos 和 Raft 為主的分布式系統。
而在區塊鏈領域，多採用 PoW 工作量證明演算法、PoS 權益證明演算法，以及 DPoS 代理權益證明演算法，以上三種是業界主流的共識演算法，這些演算法與經典分布式一致性演算法不同的是，它們融入了經濟學博弈的概念，下面我分別簡單介紹這三種共識演算法。
PoW： 通常是指在給定的約束下，求解一個特定難度的數學問題，誰解的速度快，誰就能獲得記賬權（出塊）權利。這個求解過程往往會轉換成計算問題，所以在比拼速度的情況下，也就變成了誰的計算方法更優，以及誰的設備性能更好。
PoS： 這是一種股權證明機制，它的基本概念是你產生區塊的難度應該與你在網路里所佔的股權（所有權佔比）成比例，它實現的核心思路是：使用你所鎖定代幣的幣齡（CoinAge）以及一個小的工作量證明，去計算一個目標值，當滿足目標值時，你將可能獲取記賬權。
DPoS： 簡單來理解就是將 PoS 共識演算法中的記賬者轉換為指定節點數組成的小圈子，而不是所有人都可以參與記賬。這個圈子可能是 21 個節點，也有可能是 101 個節點，這一點取決於設計，只有這個圈子中的節點才能獲得記賬權。這將會極大地提高系統的吞吐量，因為更少的節點也就意味著網路和節點的可控。
3、加密簽名演算法
在區塊鏈領域，應用得最多的是哈希演算法。哈希演算法具有抗碰撞性、原像不可逆、難題友好性等特徵。
其中，難題友好性正是眾多 PoW 幣種賴以存在的基礎，在比特幣中，SHA256 演算法被用作工作量證明的計算方法，也就是我們所說的挖礦演算法。
而在萊特幣身上，我們也會看到 Scrypt 演算法，該演算法與 SHA256 不同的是，需要大內存支持。而在其他一些幣種身上，我們也能看到基於 SHA3 演算法的挖礦演算法。以太坊使用了 Dagger-Hashimoto 演算法的改良版本，並命名為 Ethash，這是一個 IO 難解性的演算法。
當然，除了挖礦演算法，我們還會使用到 RIPEMD160 演算法，主要用於生成地址，眾多的比特幣衍生代碼中，絕大部分都採用了比特幣的地址設計。
除了地址，我們還會使用到最核心的，也是區塊鏈 Token 系統的基石：公私鑰密碼演算法。
在比特幣大類的代碼中，基本上使用的都是 ECDSA。ECDSA 是 ECC 與 DSA 的結合，整個簽名過程與 DSA 類似，所不一樣的是簽名中採取的演算法為 ECC（橢圓曲線函數）。
從技術上看，我們先從生成私鑰開始，其次從私鑰生成公鑰，最後從公鑰生成地址，以上每一步都是不可逆過程，也就是說無法從地址推導出公鑰，從公鑰推導到私鑰。
4、賬戶與交易模型
從一開始的定義我們知道，僅從技術角度可以認為區塊鏈是一種分布式資料庫，那麼，多數區塊鏈到底使用了什麼類型的資料庫呢？
我在設計元界區塊鏈時，參考了多種資料庫，有 NoSQL 的 BerkelyDB、LevelDB，也有一些幣種採用基於 SQL 的 SQLite。這些作為底層的存儲設施，多以輕量級嵌入式資料庫為主，由於並不涉及區塊鏈的賬本特性，這些存儲技術與其他場合下的使用並沒有什麼不同。
區塊鏈的賬本特性，通常分為 UTXO 結構以及基於 Accout-Balance 結構的賬本結構，我們也稱為賬本模型。UTXO 是「unspent transaction input/output」的縮寫，翻譯過來就是指「未花費的交易輸入輸出」。
這個區塊鏈中 Token 轉移的一種記賬模式，每次轉移均以輸入輸出的形式出現；而在 Balance 結構中，是沒有這個模式的。
❹ 區塊鏈科普
區塊鏈的概念這么火，竟然沒有人能很好的解釋基本概念。
到找了一個網站，用圖示的方法解釋了一些基本概念。 blockchian demo
以下是涉及到的概念。
data hash block nouce mine
prev distributed peer token coinbase
理解如下：
1 hash和data的關系。
不同的data對應不同的hash，輸入相同的data，會出現相同的hash，但是你無法從hash反推出data是什麼。這是由數學演算法決定的。
沒有數據或者海量數據，hash依舊是那麼多位數。
2 block。
區塊。簡易版的組成：block序號。nonce。data。hash。mine。
3 nonce。mine。
nonce與hash的關系。nonce是一組數字，不同的nonce對應不同的hash,而且是一一對應。也就是說，hash改變，nonce也必須改變。
當你在block裡面改變你的data時，你的hash改變了，hash是自動改變的。但是同時，你的nonce並沒有改變，於是它與hash不匹配。這個時候，你的這個block就會被判定無效（invalidate）。
這個時候，通過挖礦（mine），運行演算法，來給當前的hash匹配到相應的nonce，使這個block生效。mine需要耗費計算資源。
nonce被翻譯成碰撞數，也是生動。
4 blockchain
blockchain就是block的鏈條。他們通過prev，也就是記錄前一個block的hash鏈接起來。因此，第一個block沒有prvious hash。
在blockchain中，跟block一樣，如果你改變任意一個節點的data，其hash值改變後，為了讓它validate，你需要mine，以匹配到nonce。我試著mine了後，發現改變data後的hash變化後，mine後的hash還會繼續改變，跟nonce都變化了，這樣才validate了。這里並不明白為什麼。
同時，由於其後一個block繼承到了新的prev hash，整個block變得invalidate，需要mine。也就是說，被改變後的block連同其後的每一個block都需要mine，才能validate。
5 distributed 分布式
一條區塊鏈會有n個peer，是其完全相同的復製品。我的理解是：每個人都有一個完整的、與其他人相同的記錄在區塊鏈的賬本。當一個blockchain里的數據改變時，它需要使用mine的方式重新使得整個blockchain有效，但與此同時，系統會發現它與其他的blockchain是不一會的（比對最後一個block的hash等就可以了），這時會判定其他多數的blockchain是有效的，用少數服從多數原則判定賬本，也就是說，這個blockchain的改變會視為無效。
6 token（代幣）
token的英英解釋是這樣的：
A token is a round flat piece of metal or plastic that is sometimes used instead of money。
翻譯成代幣也算是准確。
token就是記錄在block中data裡面的交易數據，包括金額，以及from 和to。
每個block里的token記錄的都是所有的轉賬記錄。（目前的理解）也就是說，當你進行了一筆交易時，這個交易記錄會被廣播到所有peer的block中的token記錄里。
7 coinbase
可以理解為幣池，就是流通的貨幣總量。就是這個blockchain裡面的token總額或者叫做coin有多少。
❺ 初識Hyperledger Fabric
Fabric是聯盟鏈，Peer代表一系列組織，Peers是整個區塊鏈網路的基礎，因為它是賬本和智能合約的載體。通過智能合約，賬本通過不可篡改的方式記錄了交易的全過程。
對於不能的公司來說，是有不同的業務的，不同的業務又與不同的公司相關聯，需要創建多個聯盟鏈，因此就需要創建多個channel，channel是多個特定成員之間以機密交易為目的建立的私網，一個peer可以加入多個channel，每個channel維護自己的賬本，賬本和賬本之間是隔離的，每個channel可以維護一個或多個賬本。所以為了滿足復雜的交易需求，每個peer上可以安裝不同的智能合約，當peer交易完成時，會發送事件通知Client。peer上還有一個Local MSP（成員服務提供器）服務，提供身份認證和加密簽名等功能。
WorldState 以key-value的形式，維護著當前賬本的當前信息。
智能合約（Smart Contract）是區塊鏈的核心，定義了各個不同組織間的業務規范，創建交易並記錄在賬本里。多個智能合約可以打包到一個鏈碼中。只有鏈碼（Chaincode）部署之後，智能合約才能被應用使用。
不同於一般的鏈碼運行在一個獨立的容器，系統鏈碼運行在peer進程上，實現了一些系統行為。
Fabric為了優化網路性能，提高安全性和可擴展性，將每個交易分到 Endorsing Peer 、 Ording-Service 和 Committting Peer 三個部分，這就需要一種安全的，可信的和可擴展的數據傳輸協議——Gossip Protocol。 Gossip 傳輸協議以隨機的方式將信息散播到網路中，主要執行三個功能：
❻ 區塊鏈節點上線的時候是怎麼找到它的peer節點
本人淺見：應該是有個公共地址，大家（包括新加入的）訪問這個地址，即可獲取所有節點的地址信息。類似的，迅雷下載，bt下載等 p2p 傳輸，也離不開一個公共地址來存放所有節點的地址信息。
❼ 區塊鏈 --- 共識演算法
PoW演算法是一種防止分布式服務資源被濫用、拒絕服務攻擊的機制。它要求節點進行適量消耗時間和資源的復雜運算，並且其運算結果能被其他節點快速驗算，以耗用時間、能源做擔保，以確保服務與資源被真正的需求所使用。
PoW演算法中最基本的技術原理是使用哈希演算法。假設求哈希值Hash(r)，若原始數據為r（raw），則運算結果為R（Result）。
R = Hash(r)
哈希函數Hash()的特性是，對於任意輸入值r，得出結果R，並且無法從R反推回r。當輸入的原始數據r變動1比特時，其結果R值完全改變。在比特幣的PoW演算法中，引入演算法難度d和隨機值n，得到以下公式：
Rd = Hash(r+n)
該公式要求在填入隨機值n的情況下，計算結果Rd的前d位元組必須為0。由於哈希函數結果的未知性，每個礦工都要做大量運算之後，才能得出正確結果，而算出結果廣播給全網之後，其他節點只需要進行一次哈希運算即可校驗。PoW演算法就是採用這種方式讓計算消耗資源，而校驗僅需一次。
PoS演算法要求節點驗證者必須質押一定的資金才有挖礦打包資格，並且區域鏈系統在選定打包節點時使用隨機的方式，當節點質押的資金越多時，其被選定打包區塊的概率越大。
POS模式下，每個幣每天產生1幣齡，比如你持有100個幣，總共持有了30天，那麼，此時你的幣齡就為3000。這個時候，如果你驗證了一個POS區塊，你的幣齡就會被清空為0，同時從區塊中獲得相對應的數字貨幣利息。
節點通過PoS演算法出塊的過程如下：普通的節點要成為出塊節點，首先要進行資產的質押，當輪到自己出塊時，打包區塊，然後向全網廣播，其他驗證節點將會校驗區塊的合法性。
DPoS演算法和PoS演算法相似，也採用股份和權益質押。
但不同的是，DPoS演算法採用委託質押的方式，類似於用全民選舉代表的方式選出N個超級節點記賬出塊。
選民把自己的選票投給某個節點，如果某個節點當選記賬節點，那麼該記賬節點往往在獲取出塊獎勵後，可以採用任意方式來回報自己的選民。
這N個記賬節點將輪流出塊，並且節點之間相互監督，如果其作惡，那麼會被扣除質押金。
通過信任少量的誠信節點，可以去除區塊簽名過程中不必要的步驟，提高了交易的速度。
拜占庭問題：
拜占庭是古代東羅馬帝國的首都，為了防禦在每塊封地都駐扎一支由單個將軍帶領的軍隊，將軍之間只能靠信差傳遞消息。在戰爭時，所有將軍必須達成共識，決定是否共同開戰。
但是，在軍隊內可能有叛徒，這些人將影響將軍們達成共識。拜占庭將軍問題是指在已知有將軍是叛徒的情況下，剩餘的將軍如何達成一致決策的問題。
BFT：
BFT即拜占庭容錯，拜占庭容錯技術是一類分布式計算領域的容錯技術。拜占庭假設是對現實世界的模型化，由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊等原因，計算機和網路可能出現不可預料的行為。拜占庭容錯技術被設計用來處理這些異常行為，並滿足所要解決的問題的規范要求。
拜占庭容錯系統 ：
發生故障的節點被稱為 拜占庭節點 ，而正常的節點即為 非拜占庭節點 。
假設分布式系統擁有n台節點，並假設整個系統拜占庭節點不超過m台（n ≥ 3m + 1），拜占庭容錯系統需要滿足如下兩個條件：
另外，拜占庭容錯系統需要達成如下兩個指標：
PBFT即實用拜占庭容錯演算法，解決了原始拜占庭容錯演算法效率不高的問題，演算法的時間復雜度是O(n^2)，使得在實際系統應用中可以解決拜占庭容錯問題
PBFT是一種狀態機副本復制演算法，所有的副本在一個視圖（view）輪換的過程中操作，主節點通過視圖編號以及節點數集合來確定，即：主節點 p = v mod |R|。v：視圖編號，|R|節點個數，p：主節點編號。
PBFT演算法的共識過程如下：客戶端（Client）發起消息請求（request），並廣播轉發至每一個副本節點（Replica），由其中一個主節點（Leader）發起提案消息pre-prepare，並廣播。其他節點獲取原始消息，在校驗完成後發送prepare消息。每個節點收到2f+1個prepare消息，即認為已經准備完畢，並發送commit消息。當節點收到2f+1個commit消息，客戶端收到f+1個相同的reply消息時，說明客戶端發起的請求已經達成全網共識。
具體流程如下 ：
客戶端c向主節點p發送<REQUEST, o, t, c>請求。o: 請求的具體操作，t: 請求時客戶端追加的時間戳，c：客戶端標識。REQUEST: 包含消息內容m，以及消息摘要d(m)。客戶端對請求進行簽名。
主節點收到客戶端的請求，需要進行以下交驗：
a. 客戶端請求消息簽名是否正確。
非法請求丟棄。正確請求，分配一個編號n，編號n主要用於對客戶端的請求進行排序。然後廣播一條<<PRE-PREPARE, v, n, d>, m>消息給其他副本節點。v：視圖編號，d客戶端消息摘要，m消息內容。<PRE-PREPARE, v, n, d>進行主節點簽名。n是要在某一個范圍區間內的[h, H]，具體原因參見 垃圾回收 章節。
副本節點i收到主節點的PRE-PREPARE消息，需要進行以下交驗：
a. 主節點PRE-PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了一條在同一v下並且編號也是n，但是簽名不同的PRE-PREPARE信息。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。正確請求，副本節點i向其他節點包括主節點發送一條<PREPARE, v, n, d, i>消息, v, n, d, m與上述PRE-PREPARE消息內容相同，i是當前副本節點編號。<PREPARE, v, n, d, i>進行副本節點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中，用於View Change過程中恢復未完成的請求操作。
主節點和副本節點收到PREPARE消息，需要進行以下交驗：
a. 副本節點PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. n是否在區間[h, H]內。
d. d是否和當前已收到PRE-PPREPARE中的d相同
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的PREPARE消息，則向其他節點包括主節點發送一條<COMMIT, v, n, d, i>消息，v, n, d, i與上述PREPARE消息內容相同。<COMMIT, v, n, d, i>進行副本節點i的簽名。記錄COMMIT消息到日誌中，用於View Change過程中恢復未完成的請求操作。記錄其他副本節點發送的PREPARE消息到log中。
主節點和副本節點收到COMMIT消息，需要進行以下交驗：
a. 副本節點COMMIT消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的COMMIT消息，說明當前網路中的大部分節點已經達成共識，運行客戶端的請求操作o，並返回<REPLY, v, t, c, i, r>給客戶端，r：是請求操作結果，客戶端如果收到f+1個相同的REPLY消息，說明客戶端發起的請求已經達成全網共識，否則客戶端需要判斷是否重新發送請求給主節點。記錄其他副本節點發送的COMMIT消息到log中。
如果主節點作惡，它可能會給不同的請求編上相同的序號，或者不去分配序號，或者讓相鄰的序號不連續。備份節點應當有職責來主動檢查這些序號的合法性。
如果主節點掉線或者作惡不廣播客戶端的請求，客戶端設置超時機制，超時的話，向所有副本節點廣播請求消息。副本節點檢測出主節點作惡或者下線，發起View Change協議。
View Change協議 ：
副本節點向其他節點廣播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的編號， C 是 2f+1驗證過的CheckPoint消息集合， P 是當前副本節點未完成的請求的PRE-PREPARE和PREPARE消息集合。
當主節點p = v + 1 mod |R|收到 2f 個有效的VIEW-CHANGE消息後，向其他節點廣播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主節點重新發起的未經完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規則：
副本節點收到主節點的NEW-VIEW消息，驗證有效性，有效的話，進入v+1狀態，並且開始 O 中的PRE-PREPARE消息處理流程。
在上述演算法流程中，為了確保在View Change的過程中，能夠恢復先前的請求，每一個副本節點都記錄一些消息到本地的log中，當執行請求後副本節點需要把之前該請求的記錄消息清除掉。
最簡單的做法是在Reply消息後，再執行一次當前狀態的共識同步，這樣做的成本比較高，因此可以在執行完多條請求K（例如：100條）後執行一次狀態同步。這個狀態同步消息就是CheckPoint消息。
副本節點i發送<CheckPoint, n, d, i>給其他節點，n是當前節點所保留的最後一個視圖請求編號，d是對當前狀態的一個摘要，該CheckPoint消息記錄到log中。如果副本節點i收到了2f+1個驗證過的CheckPoint消息，則清除先前日誌中的消息，並以n作為當前一個stable checkpoint。
這是理想情況，實際上當副本節點i向其他節點發出CheckPoint消息後，其他節點還沒有完成K條請求，所以不會立即對i的請求作出響應，它還會按照自己的節奏，向前行進，但此時發出的CheckPoint並未形成stable。
為了防止i的處理請求過快，設置一個上文提到的 高低水位區間[h, H] 來解決這個問題。低水位h等於上一個stable checkpoint的編號，高水位H = h + L，其中L是我們指定的數值，等於checkpoint周期處理請求數K的整數倍，可以設置為L = 2K。當副本節點i處理請求超過高水位H時，此時就會停止腳步，等待stable checkpoint發生變化，再繼續前進。
在區塊鏈場景中，一般適合於對強一致性有要求的私有鏈和聯盟鏈場景。例如，在IBM主導的區塊鏈超級賬本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識演算法。
Raft基於領導者驅動的共識模型，其中將選舉一位傑出的領導者(Leader)，而該Leader將完全負責管理集群，Leader負責管理Raft集群的所有節點之間的復制日誌。
下圖中，將在啟動過程中選擇集群的Leader（S1），並為來自客戶端的所有命令/請求提供服務。 Raft集群中的所有節點都維護一個分布式日誌（復制日誌）以存儲和提交由客戶端發出的命令（日誌條目）。 Leader接受來自客戶端的日誌條目，並在Raft集群中的所有關注者（S2，S3，S4，S5）之間復制它們。
在Raft集群中，需要滿足最少數量的節點才能提供預期的級別共識保證， 這也稱為法定人數。 在Raft集群中執行操作所需的最少投票數為 (N / 2 +1) ，其中N是組中成員總數，即 投票至少超過一半 ，這也就是為什麼集群節點通常為奇數的原因。 因此，在上面的示例中，我們至少需要3個節點才能具有共識保證。
如果法定仲裁節點由於任何原因不可用，也就是投票沒有超過半數，則此次協商沒有達成一致，並且無法提交新日誌。
數據存儲：Tidb/TiKV
日誌：阿里巴巴的 DLedger
服務發現：Consul& etcd
集群調度：HashiCorp Nomad
只能容納故障節點(CFT)，不容納作惡節點
順序投票，只能串列apply，因此高並發場景下性能差
Raft通過解決圍繞Leader選舉的三個主要子問題，管理分布式日誌和演算法的安全性功能來解決分布式共識問題。
當我們啟動一個新的Raft集群或某個領導者不可用時，將通過集群中所有成員節點之間協商來選舉一個新的領導者。 因此，在給定的實例中，Raft集群的節點可以處於以下任何狀態: 追隨者(Follower)，候選人(Candidate)或領導者(Leader)。
系統剛開始啟動的時候，所有節點都是follower，在一段時間內如果它們沒有收到Leader的心跳信號，follower就會轉化為Candidate；
如果某個Candidate節點收到大多數節點的票，則這個Candidate就可以轉化為Leader，其餘的Candidate節點都會回到Follower狀態；
一旦一個Leader發現系統中存在一個Leader節點比自己擁有更高的任期(Term)，它就會轉換為Follower。
Raft使用基於心跳的RPC機制來檢測何時開始新的選舉。 在正常期間， Leader 會定期向所有可用的 Follower 發送心跳消息（實際中可能把日誌和心跳一起發過去）。 因此，其他節點以 Follower 狀態啟動，只要它從當前 Leader 那裡收到周期性的心跳，就一直保持在 Follower 狀態。
當 Follower 達到其超時時間時，它將通過以下方式啟動選舉程序：
根據 Candidate 從集群中其他節點收到的響應，可以得出選舉的三個結果。
共識演算法的實現一般是基於復制狀態機（Replicated state machines），何為 復制狀態機 ：
簡單來說： 相同的初識狀態 + 相同的輸入 = 相同的結束狀態 。不同節點要以相同且確定性的函數來處理輸入，而不要引入一下不確定的值，比如本地時間等。使用replicated log是一個很不錯的注意，log具有持久化、保序的特點，是大多數分布式系統的基石。
有了Leader之後，客戶端所有並發的請求可以在Leader這邊形成一個有序的日誌（狀態）序列，以此來表示這些請求的先後處理順序。Leader然後將自己的日誌序列發送Follower，保持整個系統的全局一致性。注意並不是強一致性，而是 最終一致性 。
日誌由有序編號（log index）的日誌條目組成。每個日誌條目包含它被創建時的任期號（term），和日誌中包含的數據組成，日誌包含的數據可以為任何類型，從簡單類型到區塊鏈的區塊。每個日誌條目可以用[ term, index, data]序列對表示，其中term表示任期， index表示索引號，data表示日誌數據。
Leader 嘗試在集群中的大多數節點上執行復制命令。 如果復製成功，則將命令提交給集群，並將響應發送回客戶端。類似兩階段提交(2PC)，不過與2PC的區別在於，leader只需要超過一半節點同意（處於工作狀態）即可。
leader 、 follower 都可能crash，那麼 follower 維護的日誌與 leader 相比可能出現以下情況
當出現了leader與follower不一致的情況，leader強制follower復制自己的log， Leader會從後往前試 ，每次AppendEntries失敗後嘗試前一個日誌條目（遞減nextIndex值）， 直到成功找到每個Follower的日誌一致位置點（基於上述的兩條保證），然後向後逐條覆蓋Followers在該位置之後的條目 。所以丟失的或者多出來的條目可能會持續多個任期。
要求候選人的日誌至少與其他節點一樣最新。如果不是，則跟隨者節點將不投票給候選者。
意味著每個提交的條目都必須存在於這些伺服器中的至少一個中。如果候選人的日誌至少與該多數日誌中的其他日誌一樣最新，則它將保存所有已提交的條目，避免了日誌回滾事件的發生。
即任一任期內最多一個leader被選出。這一點非常重要，在一個復制集中任何時刻只能有一個leader。系統中同時有多餘一個leader，被稱之為腦裂（brain split），這是非常嚴重的問題，會導致數據的覆蓋丟失。在raft中，兩點保證了這個屬性：
因此， 某一任期內一定只有一個leader 。
當集群中節點的狀態發生變化（集群配置發生變化）時，系統容易受到系統故障。 因此，為防止這種情況，Raft使用了一種稱為兩階段的方法來更改集群成員身份。 因此，在這種方法中，集群在實現新的成員身份配置之前首先更改為中間狀態（稱為聯合共識）。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求，它的主要目的是提升分布式系統的可用性。
❽ (譯)超級賬本官方文檔 基本概念(三) - 節點(Peer)
超級賬本是Linux基金會發起的項目，意在提供一套企業級區塊鏈應用框架，便於大家開發基於區塊鏈技術的應用。
Fabric的基本概念
最開始，應用程序會選出一組peer來生成賬本更新提議。哪些peer會被選出來是依據的背書策略，這個背書策略決定了哪些組織需要在廣播賬本更新提議前對更新提議進行背書。這會影響到共識方式，任何一個關心更新提議是否背書的組織都會在廣播給peer更新提議並被peer接受前確認提議是否有背書。
peer對一個提議響應進行背書，就是把自己的數字簽名加入到響應中，並用自己的私鑰對整個響應簽名。背書內容隨後可以被用於證明這個響應是某個組織的peer生成的。在我們的例子中，如果peer P1屬於組織1(Org1)，那麼背書E1就相當於可以證明L1上的交易T1和響應R1是由Org1的peer P1提供的。
當應用程序得到了足夠多的簽名的提議響應時，第一階段就結束了。
我們注意到peer可能返回不同的信息，因此同一筆交易可能有不一致的返回信息。這可能由於響應是在不同時間，不同peer，在不同賬本狀態下生成的，大多數情況下應用程序可以多次請求更新的提議響應。另外更嚴重，但概率很小的原因是因為鏈碼的不確定性導致的響應不一致。不確定性是鏈碼和賬本的大敵，如果這種情況發生了，對提議交易來說是很嚴重的，不一致的提議響應肯定不能提交到賬本中。一個獨立的節點是不可能知道交易結果是非確定性的交易，在檢測到非確定性交易前，必須將交易匯總比較(嚴格地說，即使這還不夠，但我們將此討論推遲到交易部分，其中詳細討論了非確定性)。
在第一階段結束時，如果應用程序希望如此的話，可以放心丟棄不一致的響應以提前結束交易流程。後面我們會看到如果應用程序使用不一致的響應提交到賬本時，會被拒絕。
過程2 打包
第二個交易流程是打包。Orderer節點這個過程關鍵的點，它接收來自很多應用傳來的背書過的提議交易響應。Orderer對交易進行排序，並將大量的交易打包進區塊，並准備將區塊分發到所有連接到Orderer的peer，包括背書peer。
orderer的第一個角色就是打包賬本更新提議。在上圖的例子中，應用A1發送給Orderer O1一個被E1和E2背書的交易T1。同時，應用A2發送給Orderer O1一個被E1背書的交易T2。O1將A1傳來的交易和A2傳來的交易以及其它交易共同打包進區塊B2。我們可以看到區塊B2里的交易排序是T1，T2，T3，T4，T6，T5，並不一定是按照到達orderer節點的順序(這個例子展示了一個非常簡單的orderer配置)。
Orderer節點會同時收到網路Channel中不同應用程序發送的賬本更新提議。Orderer節點的任務就是按照事先定義好的順序整理這些更新提議，並把它們打包進區塊，為下一步的分發做准備。這些區塊將構成區塊鏈。一旦Orderer節點生成了期望大小的區塊，或者超過最大等待時間，Orderer會向連接到它特定Channel的Peer發送區塊。第三個過程會詳述這個流程。
區塊中的交易排列順序和交易到達Orderer節點的順序沒有直接關系。交易在區塊中可以是任意的排列順序，這個次序就是交易執行的順序。重點是有一個嚴格的交易排序，但具體是怎樣的排序並不重要。
區塊中的嚴格交易順序排列使得Fabric與公鏈中一筆交易可以被打包進多個不同區塊的情況不同。在Fabric中，這不可能發生，由多個Orderer生成的區塊就是最終的區塊，因為交易被寫入區塊後，交易的位置順序就確定了。這意味著Fabric不會存在分叉。一旦交易被寫入區塊，以後就不能再重寫了。
我們可以看到，peer是存儲賬本和鏈碼的，orderer完全不會存儲這些。每一筆交易到達orderer時，orderer只是機械的將交易打包進區塊，而不會理會交易的價值，額度等。這是Fabric的一個重要特性，所有交易都會按照一個嚴格的順序進行整理，沒有交易會被拋棄掉。
到第二階段結束時，我們可以了解到orderer的責任就是進行必要的，簡單的收集交易更新提議，將他們排序，打包進區塊，准備分發出去。
過程3 認證
最後一個交易工作流程是分發和驗證從orderer到peer的區塊，如果驗證成功，將會被提交到賬本中。
特別的，在每個peer中，在區塊中的每一筆交易在更新到賬本之前都是驗證過的，以保證所有交易都是由相關的組織背書過的。失敗的交易會保留，作為日後審查用，並不會更新到賬本中。
Orderer除了在過程2中的打包角色外，在過程3中還負責分發區塊到peer節點。在這個例子中，O1分發區塊到P1和P2。P1處理區塊2，然後將區塊2添加到P1的賬本L1中。同時，P2處理區塊2，然後將區塊2添加到P2的賬本L1中。一旦操作完成，賬本L1在P1和P2中都被更新了，每個Peer都可以向連接到他們的應用程序發送處理結果。
Orderer向連接到他的Peer分發區塊是過程3的開始。連接到orderer節點的某個渠道的peer，會收到orderer生成的新區塊的一份拷貝。每個peer節點都會獨立的處理收到的區塊，但所有peer處理區塊的方式都是相同的。採用這種方式，不同peer中的賬本可以達成共識。並不是所有的peer都必須連接到orderer節點，peer和peer之間可以通過gossip協議來傳遞區塊，這樣peer也可以獨立的處理相同區塊。
收到一個區塊後，peer會按照交易在區塊中出現的順序依次處理。對於每一筆交易，peer會按照生成這筆交易的鏈碼背書策略檢查交易是否被與之相關組織的背書。例如，某些交易可能只需要一個組織背書，而另一些交易需要多個組織同時背書才有效。這個驗證過程驗證了所有相關組織產生的結果或者輸出是否一致。同時請注意，第三階段的驗證和第一階段不同，階段一隻是應用程序收到背書節點的響應，判斷是否需要發送交易提議。如果應用程序發送錯誤的交易，違反了背書策略，在第三階段的驗證過程中peer還是可以拒絕本次交易。
如果交易背書正確，peer將嘗試把交易提交到賬本中。為了能寫賬本，peer必須進行賬本一致性檢查，保證當前賬本的狀態與賬本更新後的狀態一致。這個狀態並不總會是一致的，即使交易擁有完整的背書。舉個栗子，另外一筆交易可能已經更新了賬本中的同一個資產，以至於我們正要更新的交易將永遠不會被寫入賬本。這樣的話，每個節點中的賬本必須通過網路保持共識，每個節點的驗證方式是一樣的。
在peer驗證完每筆獨立交易後，將更新賬本。失敗的交易會保存下來作為審查資料。這意味著peer中的區塊和從orderer中收到的區塊一致，除了區塊中指示交易成功或失敗的標志。
我們也要注意到，第三階段並沒有執行鏈碼，這一步只會在第一階段完成，這很重要。這意味著鏈碼只在背書節點可用，而不是整個網路中都可用，這保證了鏈碼在背書組織中的安全及私密。這和收到鏈碼的執行結果不同，執行結果會分享到所有在Channel里的peer，不論他是否能背書交易。背書節點的這種設計方式是為了方便擴展。
最後，每次區塊被提交到peer的賬本中時，這個peer會生成對應的事件。區塊事件包含區塊的所有內容，而區塊交易事件只包含簡要信息，比如每筆區塊中的交易是否有效。由鏈碼的執行而產生的鏈碼事件也可以在這個時候發布。應用程序可以注冊這些事件，當這些事件發生時，可以收到通知。這些通知在交易工作流程的第三階段和最後階段完成。
總的來說，我們可以知道第三階段由orderer產生的區塊被不斷地同步到賬本中。區塊中交易的嚴格排序能讓每個peer在區塊鏈網路中始終如一地驗證交易並提交到賬本中。
Orderer和共識
整個交易工作流程被稱為共識，因為所有peer都認同交易的排序和內容，在執行過程中由orderer節點來協調。共識是多步驟的過程，應用程序只會在共識過程結束時收到通知，但通知的時間在不同的peer上可能不同。
我們將會在後面更多的探討orderer，現在，把orderer僅僅當做從應用程序收集、分發賬本更新提議到peer，由peer進行驗證及更新賬本的過程。
❾ 淺析 Fabric Peer 節點
Hyperledger Fabric，也稱之為超級賬本，是由 IBM 發起，後成為 Linux 基金會 Hyperledger 中的區塊鏈項目之一。
Fabric 是一個提供分布式賬本解決方案的平台，底層的賬本數據存儲使用了區塊鏈。區塊鏈平台通常可以分為公有鏈、聯盟鏈和私有鏈。公有鏈典型的代表是比特幣這些公開的區塊鏈網路，誰都可以加入到這個網路中。聯盟鏈則有準入機制，無法隨意加入到網路中，聯盟鏈的典型例子就是 Fabric。
Fabric 不需要發幣來激勵參與方，也不需要挖礦來防止有人作惡，所以 Fabric 有著更好的性能。在Fabric 網路中，也有著諸多不同類型的節點來組成網路。其中 Peer 節點承載著賬本和智能合約，是整個區塊鏈網路的基礎。在這篇文章中，會詳細分析 Peer 的結構及其運行方式。
在本文中，假設讀者已經了解區塊鏈、智能合約等概念。
本文基於 Fabric1.4 LTS。
區塊鏈網路是一個分布式的網路，Fabric 也是如此，由於 Fabric 是聯盟鏈，需要准入機制，所以在網路結構上會復雜很多，下面是一個簡化的 Fabric 網路：
各個元素的含義如下：
對於 Fabric 網路，外部的用戶需要通過客戶端應用，也就是圖中的 A1、A2 或者 A3 來訪問網路，客戶端應用需要通過 CA 證書表明自己的身份，這樣才能訪問到 Fabric 網路中有許可權訪問的部分。
在上面的網路中，共有四個組織，R1、R2、R3 和 R4。其中 R4 是整個 Fabric 網路的創建者，網路是根據 NC4 配置的。
在 Fabric 網路中，不同的組織可以組成聯盟，不同的聯盟之間數據通過 Channel 來隔離。Channel 中的數據只有該聯盟中的組織才能訪問，每一個新的 Channel 都可以認為是一條新的鏈。與其他的區塊鏈網路中通常只有一條鏈不一樣，Fabric 可以通過 Channel 在網路中快速的搭建出一個新的區塊鏈。
上面 R1 和 R2 組成了一個聯盟，在 C1 上交易。R2 同時又和 R3 組成了另外一個聯盟，在 C2 上交易。R1 和 R2 在 C1 上交易時，對 R3 是不可見的，R2 和 R3 在 C2 上交易時，對 R1 是不可見的。Channel 機制提供了很好的隱私保護能力。
Orderer 節點是整個 Fabric 網路共有的，用來為所有的交易排序、打包。比如上面網路中 O4 節點。本文不會對 Orderer 節點進行詳細說明，可以把這個功能理解為比特幣網路中的挖礦過程。
Peer 節點表示網路中的節點，通常一個 Peer 就表示一個組織，Peer 是整個區塊鏈網路的基礎，是智能合約和賬本的載體，Peer 也是本文討論的重點。
一個 Peer 節點可以承載多套賬本和智能合約，比如 P2 節點，既維護了 C1 的賬本和智能合約，也維護了 C2 的賬本和智能合約。
為了可以更深入了解 Peer 節點的作用，先了解一下 Fabric 整體的交易流程。整體的交易流程圖如下：
Peer 節點按照功能來分可以分為 背書節點 和 記賬節點 。
客戶端會提交交易請求到背書節點，背書節點開始模擬執行交易，在模擬執行之後，背書節點並不會去更新賬本數據，而是把這個交易進行加密和簽名，然後返回給客戶端。
客戶端收到這個響應之後就會把響應提交到 Orderer 節點，Orderer 節點會對這些交易進行排序，並打包成區塊，然後分發到記賬節點，記賬節點就會對交易進行驗證，驗證結束之後，就會把交易記錄到賬本裡面。
一筆交易是否能成功是根據背書策略來指定的，每一個智能合約都會指定一個背書策略。
Peer 節點代表著聯盟鏈中的各個組織，區塊鏈網路也是由 Peer 節點來組成的，而且也是賬本和智能合約的載體。
通過對上面交易過程的了解可以知道，Peer 節點是主要的參與方。如果用戶想要訪問賬本資源，都必須要和 peer 節點進行交互。在一個 Peer 節點中，可以同時維護多個賬本，這些賬本屬於不同的 Channel 。每個 Peer 節點都會維護一套冗餘賬本，這樣就避免了單點故障。
Peer 節點根據在交易中的不同角色，可以分成背書節點（Endorser）和記賬節點（Committer），背書節點會對交易進行模擬執行，記賬節點才會真正將數據存儲到賬本中。
賬本可以分成兩個部分，一部分是區塊鏈，另一部分是 Current State，也被稱之為 World State。
區塊鏈上只能追加，不能對過去的數據進行修改，鏈上也包含兩部分信息，一部分是通道的配置信息，另一部分是不可修改，序列化的記錄。每一個區塊記錄前一個區塊的信息，然後連成鏈，如下圖所示：
第一個區塊被稱之為 genesis block，其中不存儲交易信息。每個區塊可以被分為 區塊頭 、 區塊數據 和 區塊元數據 。區塊頭中存儲著當前區塊的區塊號、當前區塊的 hash 值和上一個區塊的 hash 值，這樣才能把所有的區塊連接起來。區塊數據中包含了交易數據。區塊元數據中則包括了區塊寫入的時間、寫入人及簽名。
其中每一筆交易的結構如下，在 Header 中，包含了 ChainCode 的名稱、版本信息。Signature 就是交易發起用戶的簽名。Proposal 中主要是一些參數。Response 中是智能合約執行的結果。Endorsements 中是背書結果返回的結果。
WorldState中維護了賬本的當前狀態，數據以 Key-Value 的形式存儲，可以快速查詢和修改，每一次對 WorldState 的修改都會被記錄到區塊鏈中。WorldState 中的數據需要依賴外部的存儲，通常使用 LevelDB 或者 CouchDB。
區塊鏈和 WorldState 組成了一個完整的賬本，World State 保證的業務數據的靈活變化，而區塊鏈則保證了所有的修改是可追溯和不可篡改的。
在交易完成之後，數據已經寫入賬本，就需要將這些數據同步到其他的 Peer，Fabric 中使用的是 Gossip 協議。Gossip 也是 Channel 隔離的，只會在 Channel 中的 Peer 中廣播和同步賬本數據。
智能合約需要安裝到 Peer 節點上，智能合約是訪問賬本的唯一方式。智能合約可以通過 Go、Java 等變成語言進行編寫。
智能合約編寫完成之後，需要打包到 ChainCode 中，每個 ChainCode 中可以包含多個智能合約。ChainCode 需要安裝，ChainCode 需要安裝到 Peer 節點上。安裝好了之後，ChainCode 需要在 Channel 上實例化，實例化的時候需要指定背書策略。
智能合約在實例化之後就可以用來與賬本進行交互了，流程圖如下：
用戶編寫並部署實例化智能合約之後，就可以通過客戶端應用程序來向智能合約提交請求，智能合約會對 WorldState 中數據進行 get、put 或者 delete。其中 get 操作直接從 WorldState 中讀取交易對象當前的狀態信息，不會去區塊鏈上寫入信息，但 put 和 delete 操作除了修改 WorldState，還會去區塊鏈中寫入一條交易信息，且交易信息不能修改。
區塊鏈上的信息可以通過智能合約訪問，也可以在客戶端應用通過 API 直接訪問。
Event 是客戶端應用和 Fabric 網路交互的一種方式，客戶端應用可以訂閱 Event，當 Event 發生時，客戶端應用就會接受到消息。
事件源可以兩類，一類是智能合約發出的 Event，另一類是賬本變更觸發的 Event。用戶可以從 Event 中獲取到交易的信息，比如區塊高度等信息。
在這篇文章中，首先介紹了 Fabric 整體的網路架構，通過對 Fabric 交易流程的分析，討論了 peer 節點在交易中的作用，然後詳細分析了 peer 節點所維護的賬本和智能合約，並分析了 peer 節點維護賬本以及 peer 節點執行智能合約的流程。
文 / Rayjun
[1] https://hyperledger-fabric.readthedocs.io/zh_CN/release-1.4/whatis.html
[2] https://developer.ibm.com/zh/technologies/blockchain/series/os-academy-hyperledger-fabric/
[3] https://en.wikipedia.org/wiki/Gossip_protocol
❿ 區塊鏈中點對點分布式技術是指什麼
「一種基於網路的計算機處理技術，與集中式相對應。由於個人計算機的性能得到極大的提高及其使用的普及，使處理能力分布到網路上的所有計算機成為可能。分布式計算是和集中式計算相對立的概念，分布式計算的數據可以分布在很大區域。」