1苍鲜、fabric V1.x的架構(gòu)圖

HyperLedger Fabric

架構(gòu)主要包括幾個(gè)部分：

• 應(yīng)用sdk：用于和區(qū)塊鏈網(wǎng)絡(luò)進(jìn)行通信混滔，提供了包括安全認(rèn)證坯屿，交易申請(qǐng)等功能
• 節(jié)點(diǎn)：負(fù)責(zé)背書领跛，驗(yàn)證吠昭，提交交易等功能矢棚，每個(gè)節(jié)點(diǎn)都維護(hù)了一個(gè)或是多個(gè)賬本蒲肋，同時(shí)通過gossip網(wǎng)絡(luò)對(duì)其他節(jié)點(diǎn)保持通信兜粘。Fabric里每個(gè)節(jié)點(diǎn)都是無狀態(tài)的妹沙，
• order服務(wù)距糖，負(fù)責(zé)打包悍引，排序和分發(fā)交易

上圖也簡(jiǎn)要概括了fabric一個(gè)交易的完整周期趣斤。

1. 客戶端首先通過進(jìn)行身份認(rèn)證等安全操作浓领，進(jìn)入?yún)^(qū)塊鏈網(wǎng)絡(luò)
2. 客戶端之后創(chuàng)建一個(gè)交易申請(qǐng)联贩，發(fā)送給背書節(jié)點(diǎn)進(jìn)行背書操作漫仆。
3. 背書節(jié)點(diǎn)執(zhí)行對(duì)應(yīng)的鏈碼，基于應(yīng)用的key操作生成讀寫操作集泪幌，并把背書結(jié)果返回給客戶端
4. 客戶端收到背書返回后盲厌，把交易發(fā)送給節(jié)點(diǎn)，由節(jié)點(diǎn)轉(zhuǎn)發(fā)到order服務(wù)
5. order服務(wù)排序交易祸泪，把交易封裝到區(qū)塊里吗浩，并廣播給每個(gè)節(jié)點(diǎn)（或是說每個(gè)提交節(jié)點(diǎn)）
6. 節(jié)點(diǎn)對(duì)交易進(jìn)行背書策略驗(yàn)證，身份認(rèn)證懂扼，區(qū)塊中所有交易的有效性認(rèn)證。之后寫入賬本升略，并返回交易結(jié)果

2微王、節(jié)點(diǎn)內(nèi)交易流程

在Fabric中，為了方便共識(shí)模塊化和數(shù)據(jù)訪問權(quán)限的控制品嚣，引入了ordering服務(wù)和通道(Channel)的概念炕倘。所以Fabric中我們說的鏈路，其實(shí)包含了三部分：節(jié)點(diǎn)翰撑，通道和ordering服務(wù)罩旋，也就是說ordering服務(wù)和通道決定了哪些節(jié)點(diǎn)是在同一條鏈路上啊央。

鏈路

上圖包含的一條完整的鏈為：節(jié)點(diǎn)1.1，節(jié)點(diǎn)1.2涨醋，節(jié)點(diǎn)2.1瓜饥，節(jié)點(diǎn)2.3。而節(jié)點(diǎn)1.3 和節(jié)點(diǎn)2.2不在這條鏈上浴骂。在節(jié)點(diǎn) 1.1乓土，1.2，2.1溯警，2.3中趣苏，都維護(hù)了同一份賬本，這幾個(gè)節(jié)點(diǎn)由于處在同一個(gè)通道和ordering服務(wù)中梯轻，所以他們之間的所有數(shù)據(jù)和消息都是共享和透明的食磕，他們中的任何一個(gè)節(jié)點(diǎn)發(fā)送了狀態(tài)變化，其他三個(gè)節(jié)點(diǎn)都能知道喳挑，但是這些信息對(duì)于節(jié)點(diǎn)1.3彬伦，2.2來說就是完全不透明的。同樣的伊诵，節(jié)點(diǎn)1.3单绑，2.2的狀態(tài)變化或是賬本信息變化對(duì)于處于鏈路上的節(jié)點(diǎn)(節(jié)點(diǎn)1.1，節(jié)點(diǎn)1.2曹宴，節(jié)點(diǎn)2.1询张，節(jié)點(diǎn)2.3)也是完全獨(dú)立，不可見浙炼。比如，鏈路上有筆交易申請(qǐng)發(fā)生在節(jié)點(diǎn)1.1上唯袄，節(jié)點(diǎn)1.1會(huì)把這個(gè)交易申請(qǐng)發(fā)給ordering服務(wù)弯屈，ordering服務(wù)會(huì)根據(jù)發(fā)過來的請(qǐng)求判斷這個(gè)請(qǐng)求是發(fā)生在哪個(gè)通道上，之后會(huì)把封裝了這個(gè)交易的塊發(fā)給這個(gè)通道上的其他所有節(jié)點(diǎn)恋拷。這個(gè)特性能讓fabric在實(shí)際的應(yīng)用更好的方便數(shù)據(jù)的訪問控制资厉。

接下來我們簡(jiǎn)單了解下鏈碼(CC -- ChainCode)。鏈碼是Fabric中的智能合約蔬顾，相比于以太坊上用solidity寫智能合約，鏈碼可以直接采用java，go語言來編寫券腔，更容易上手阱驾。鏈碼分為兩種

• 系統(tǒng)鏈碼(SCC)
• 用戶鏈碼

系統(tǒng)鏈碼

用來實(shí)現(xiàn)系統(tǒng)層面的功能，包括系統(tǒng)的配置舷胜，用戶鏈碼的部署娩践、升級(jí)，用戶交易的簽名和驗(yàn)證策略等，運(yùn)行在節(jié)點(diǎn)進(jìn)程中翻伺。Fabric里有很多的系統(tǒng)鏈碼材泄，比如，用于背書的背書系統(tǒng)鏈碼（ESCC）吨岭，驗(yàn)證交易合法性的驗(yàn)證系統(tǒng)鏈碼（VSCC）

用戶鏈碼

用于實(shí)現(xiàn)用戶的應(yīng)用功能拉宗。開發(fā)者編寫鏈碼應(yīng)用程序并將其部署到網(wǎng)絡(luò)上。終端用戶通過與網(wǎng)絡(luò)節(jié)點(diǎn)交互的客戶端應(yīng)用程序調(diào)用鏈碼辣辫，運(yùn)行在獨(dú)立的Docker容器中旦事。

下面是一個(gè)節(jié)點(diǎn)內(nèi)的交易流程圖

image

這里的交易提交規(guī)則為：
1.如果一個(gè)節(jié)點(diǎn)收到的2f（f為可容忍的拜占庭節(jié)點(diǎn)數(shù)）個(gè)其它節(jié)點(diǎn)發(fā)來的摘要都和自己相等，就向全網(wǎng)廣播一條提交消息络它。
2.如果一個(gè)節(jié)點(diǎn)收到2f+1條提交消息族檬，即可提交新區(qū)塊及其交易到本地的區(qū)塊鏈和狀態(tài)數(shù)據(jù)庫(kù)。

3化戳、交易背書

什么是背書
背書可以理解為一種簽名单料，簽署行為。在fabric的意思是：告訴其他節(jié)點(diǎn)或是客戶端点楼，我這個(gè)節(jié)點(diǎn)模擬執(zhí)行這個(gè)交易后的結(jié)果是什么扫尖，并附上自己的簽名÷永客戶端拿到到這個(gè)背書簽名换怖，就知道哪個(gè)節(jié)點(diǎn)執(zhí)行了這個(gè)交易后的結(jié)果是什么。

不要把fabric里的背書行為當(dāng)成是共識(shí)算法蟀瞧。這是錯(cuò)誤的沉颂。

本文將詳細(xì)闡述交易背書的三個(gè)流程。
1.客戶端創(chuàng)建一個(gè)交易背書申請(qǐng)并發(fā)送給背書節(jié)點(diǎn)

我們這里說的客戶端是指上鏈后的客戶端悦污，也就是說這個(gè)客戶端一定連接到區(qū)塊鏈的某個(gè)節(jié)點(diǎn)上的铸屉。為了發(fā)起一個(gè)交易，客戶端需要給一組背書節(jié)點(diǎn)(客戶端自己選擇哪些背書節(jié)點(diǎn))發(fā)送PROPOSE消息切端。那客戶端是怎么知道背書節(jié)點(diǎn)的呢彻坛？在一條鏈路上，每個(gè)背書節(jié)點(diǎn)都會(huì)對(duì)外暴露部署在自己節(jié)點(diǎn)上的鏈碼ID(chaincodeID), 這樣通過交易中指明的chaincodeID踏枣，就可以找到所有部署了這個(gè)chaincodeID的背書節(jié)點(diǎn)昌屉。

PROPOSE消息格式為<PROPOSE,tx,[anchor]>,tx 是必須有的，anchor是可選茵瀑。
tx=<clientID,chaincodeID,txPayload,timestamp,clientSig>

其中clientID 是發(fā)起交易的客戶端ID间驮。chaincodeID這個(gè)交易所用到的鏈碼ID。txPayload 交易申請(qǐng)的payload马昨。timestamp 單調(diào)遞增的整形數(shù)值蜻牢，由客戶端維護(hù)烤咧，一個(gè)交易對(duì)應(yīng)一個(gè)。clientSig 對(duì)上述字段值的簽名

anchor 版本相關(guān)信息抢呆，包含了讀集合煮嫌，更明確的是說一組key-version對(duì)(version是有序的版本號(hào))。該KV對(duì)必須是KVS(key/value 存儲(chǔ)抱虐，用于表示狀態(tài)的一種數(shù)據(jù)結(jié)構(gòu))中的值昌阿。

在fabric中，有兩種交易：部署交易和調(diào)用交易恳邀。部署交易是用于部署一個(gè)新的鏈碼到一個(gè)區(qū)塊鏈上懦冰。而調(diào)用交易是對(duì)已經(jīng)部署在區(qū)塊鏈上的鏈碼的一個(gè)操作或是鏈碼上一個(gè)方法調(diào)用。不同類型的交易谣沸，上面的payload也不同刷钢。

對(duì)于調(diào)用交易：
txpayload = <operation,metadata>
其中operation 值鏈碼上的方法和參數(shù)。metadata 調(diào)用的相關(guān)屬性乳附。

對(duì)于部署交易：
txpayload = <source,metadata,policies>
其中source 鏈碼的代碼内地。metadata 鏈碼和應(yīng)用的相關(guān)屬性。policies 包含了這個(gè)鏈碼的相關(guān)功能赋除，比如背書策略阱缓，當(dāng)然txpayload里不會(huì)包含背書策略，而是指包含背書策略的ID和所需要參數(shù)举农。

每個(gè)交易都有tid,是全局唯一的荆针，通過對(duì)tx進(jìn)行加密hash計(jì)算得到航背±饷玻客戶端會(huì)把tid存儲(chǔ)在內(nèi)存中，等待背書簽名的返回。

由于PROPOSE消息格式中anchor是可選的起惕，所以有兩種方式發(fā)送PROPOSE消息給背書節(jié)點(diǎn)惹想。一種是先發(fā)送<PROPOSE,tx> 到單個(gè)背書節(jié)點(diǎn)督函，這個(gè)背書節(jié)點(diǎn)會(huì)產(chǎn)生一個(gè)anchor，客戶端拿到anchor后锋叨，之后可以發(fā)送<PROPOSE,tx,anchor>消息到其他的背書節(jié)點(diǎn)上娃磺。還有一種是直接發(fā)送<PROPOSE,tx>到所有的背書節(jié)點(diǎn)上。具體用哪種豺瘤，由客戶端自己選擇听诸。

2.背書節(jié)點(diǎn)模擬一個(gè)交易并產(chǎn)生一個(gè)背書簽名
當(dāng)背書節(jié)點(diǎn)(id為epID)接收到從客戶端發(fā)來的一條背書請(qǐng)求消息(<PROPOSE,tx,[anchor]>)晌梨，會(huì)先驗(yàn)證客戶端的簽名(clientSig)，然后模擬一個(gè)交易砸逊。所謂模擬一個(gè)交易就是利用交易上的鏈碼ID(chaincodeID)調(diào)用相關(guān)鏈碼掌逛，并且拷貝背書節(jié)點(diǎn)本地的狀態(tài)信息豆混。通過這種方式嘗試的執(zhí)行一個(gè)交易(txPayload).模擬交易執(zhí)行的結(jié)果就是 背書節(jié)點(diǎn)計(jì)算得到 readset 和 writeset 兩個(gè)集合。

狀態(tài)信息包含鍵值對(duì)员辩，并且所有的鍵值對(duì)都有版本控制奠滑。也就是說妒穴，每個(gè)鍵值對(duì)都包含了一個(gè)有序的版本信息讼油，每當(dāng)鍵值對(duì)的值發(fā)生變化時(shí)候，版本信息都會(huì)自動(dòng)增加乏屯。背書節(jié)點(diǎn)通過鏈碼把這個(gè)交易轉(zhuǎn)換成所有的鍵值對(duì)辰晕，不管是讀或是寫，但是節(jié)點(diǎn)的狀態(tài)信息在這個(gè)時(shí)候是沒有更新的忘苛。更詳細(xì)的為：

假定背書節(jié)點(diǎn)執(zhí)行交易前的狀態(tài)為s唱较，對(duì)于交易的每個(gè)鍵k,讀取這個(gè)鍵對(duì)應(yīng)的值s(k).value南缓，把 (k,s(k).value) 存于讀集合(readset)中汉形。

對(duì)每個(gè)被該交易更改后的鍵k所對(duì)應(yīng)的新值v’, (k,v’)被加入到寫集合(writeset). 當(dāng)然也可以存儲(chǔ)原來舊的值和當(dāng)前新值的差值。

通過上述描述逗威，我們知道背書節(jié)點(diǎn)會(huì)自己默默的計(jì)算并保存這個(gè)交易前后的狀態(tài)集合變化凯旭，通過這種方式來模擬一次交易使套。這些操作對(duì)外是不可見的侦高。

之后，節(jié)點(diǎn)會(huì)把內(nèi)部交易請(qǐng)求(tran-proposal)轉(zhuǎn)發(fā)到節(jié)點(diǎn)的背書邏輯计螺，實(shí)現(xiàn)對(duì)交易的背書簽名操作登馒，默認(rèn)情況下馁痴，節(jié)點(diǎn)的背書邏輯接收到交易請(qǐng)求后罗晕，只是簡(jiǎn)單的對(duì)這個(gè)交易請(qǐng)求進(jìn)行簽名小渊。當(dāng)然背書邏輯有可以進(jìn)行額外的一些操作，比如半等，通過交易請(qǐng)求和tx 作為輸入來判斷是否要對(duì)這個(gè)交易進(jìn)行背書杀饵。

如果背書邏輯決定了要對(duì)交易進(jìn)行背書簽名操作谬擦，背書邏輯會(huì)發(fā)送
<TANSACTION-ENDORSED,tid,tran-proposal,epSig>

消息到對(duì)應(yīng)的客戶端(tx.clientID)：
tran-proposal =<epID,tid,chaincodeID,txContentBlob,readset,writeset>
epID節(jié)點(diǎn)ID惨远。tid 交易ID北秽。txContentBlob 指鏈碼或是交易信息贺氓，txContentBlob =tx.txPayload。readset, writeset 模擬交易后的讀寫集合缅叠。 epSig 對(duì)tran-proposal 的背書節(jié)點(diǎn)簽名肤粱。

如果背書節(jié)點(diǎn)拒絕對(duì)一個(gè)交易進(jìn)行背書簽名领曼，背書節(jié)點(diǎn)會(huì)發(fā)送<TRANSACTION-INVALID,tid,REJECTED>到客戶端庶骄。

注意单刁，在整個(gè)背書過程羔飞，背書節(jié)點(diǎn)都是沒有改變狀態(tài)

3.客戶端收到背書結(jié)果并通過****ordering****服務(wù)廣播給其他節(jié)點(diǎn)
客戶端發(fā)送背書請(qǐng)求后逻淌，一直等待卡儒，直到客戶端接收到了足夠多的消息和在(TRANSACTION-ENDORSED,tid,,)狀態(tài)上的簽名之后，才認(rèn)為交易已經(jīng)經(jīng)過背書簽名操作骨望∮脖客戶端具體需要多少消息才是足夠多的消息呢？ 這個(gè)數(shù)字取決于鏈碼的背書策略锦募。如果收到的消息滿足了背書策略摆屯，那么就認(rèn)為交易進(jìn)行過背書簽名操作。注意廷没，這里只是說交易被背書簽名颠黎，而不是說交易被提交。從背書節(jié)點(diǎn)發(fā)過來的并且滿足背書策略的簽名 TRANSACTION-ENDORSED集合,就是 背書簽名文判。如果客戶端在這個(gè)過程中沒有收到節(jié)點(diǎn)返回的有效背書簽名戏仓，重試一定次數(shù)后還是失敗就終止當(dāng)前交易敷待。

當(dāng)收到節(jié)點(diǎn)返回的背書簽名后榜揖，我們就開始使用ordering服務(wù)了举哟。客戶端通過使用broadcast(blob)的方式（blob為背書簽名）來調(diào)用ordering服務(wù)诬乞。如果客戶端沒有直接調(diào)用ordering服務(wù)的能力，可以通過所連接的節(jié)點(diǎn)來代理廣播背書簽名給ordering服務(wù)森瘪。這個(gè)代理節(jié)點(diǎn)對(duì)于客戶端來說是可信的，默認(rèn)這個(gè)節(jié)點(diǎn)不會(huì)篡改背書簽名或是偽造背書簽名窗宇。否則這個(gè)交易就無效了。
當(dāng)事件deliver(seqno,prevhash,blob)發(fā)生，節(jié)點(diǎn)已經(jīng)對(duì)所有低于seqno信息已經(jīng)處理完成(seqno是有序遞增的)镰官，節(jié)點(diǎn)接下來：

• 根據(jù)該交易相關(guān)的鏈碼(blob.tran-proposal.chaincodeID)上的背書策略泳唠，檢查該交易背書簽名(blob.endorsement)是否有效
• 同時(shí)驗(yàn)證背書簽名相關(guān)性(blob.endordement.tran-proposal.readset)是否有被篡改害淤。更復(fù)雜的驗(yàn)證方式也可以通過背書策略來驗(yàn)證 tran-proposal的字段是否有效
• 同時(shí)驗(yàn)證背書簽名相關(guān)性(blob.endordement.tran-proposal.readset)是否有被篡改窥摄。更復(fù)雜的驗(yàn)證方式也可以通過背書策略來驗(yàn)證 tran-proposal的字段是否有效

驗(yàn)證背書簽名相關(guān)性有多種實(shí)現(xiàn)方式鸽凶，通過一致性或是狀態(tài)更新的隔離保證都可以玻侥。串行化是默認(rèn)的一種隔離保證方式，鏈碼上的背書策略也可以指明了另外一種隔離保證方式姑食。串行化可以通過要求在readset中每個(gè)key的版本號(hào)必須要等于狀態(tài)中（KVS）的key的版本號(hào)來實(shí)現(xiàn)。如果不滿足這個(gè)條件曹鸠，就直接拒絕該交易。

需要注意叛薯，背書驗(yàn)證失敗后省容，雖然會(huì)更新賬本中失敗交易的bitmask,但是不會(huì)更新區(qū)塊鏈狀態(tài)阿宅。

這些節(jié)點(diǎn)處理好一個(gè)給定序列號(hào)的廣播事件后，結(jié)果是這些節(jié)點(diǎn)都擁有一樣的狀態(tài)滨砍。也就是說领追，通過ordering服務(wù)的保證棕孙，所有正確的節(jié)點(diǎn)都會(huì)接受到來自ordering服務(wù)轉(zhuǎn)發(fā)的同一個(gè)序列號(hào)事件(deliver(deqno,prevhash,blob))傀蓉。由于背書策略和readset中的版本相關(guān)性驗(yàn)證都是確定的缚甩，所有的節(jié)點(diǎn)對(duì)于同一個(gè)交易處理結(jié)果也是一樣的，不管這個(gè)交易是否有效郊丛。因此揍瑟，所有的節(jié)點(diǎn)提交交易和更新狀態(tài)的行為是一致的滤馍。
下面用圖來表示上面描述的一種通用交易流程纯续。

image

說明：背書節(jié)點(diǎn)是提交節(jié)點(diǎn)的一個(gè)子集倦炒，這里為了表示有提交功能鳖藕，所以圖示上顯示了一個(gè)提交節(jié)點(diǎn)。其實(shí)所有的背書節(jié)點(diǎn)也都是提交節(jié)點(diǎn)喉誊，具有提交功能邀摆。但是如果一個(gè)節(jié)點(diǎn)不部署背書鏈碼，那么它就不具有背書功能伍茄。

4栋盹、賬本

賬本提供了一個(gè)可證實(shí)的歷史記錄，它記錄了對(duì)系統(tǒng)操作期間發(fā)生的所有成功交易和所有失敗交易敷矫。賬本由ordering服務(wù)生成例获，是一個(gè)完全排序的交易塊（失敗交易和成功交易）的哈希鏈。鏈上的每個(gè)節(jié)點(diǎn)都持有一份賬本曹仗，部分ordering服務(wù)也可以持有賬本躏敢。如果是ordering服務(wù)持有的賬本，我們稱為這種賬本為orderer服務(wù)賬本整葡，而節(jié)點(diǎn)持有的賬本稱為節(jié)點(diǎn)賬本件余，節(jié)點(diǎn)賬號(hào)和orderer賬號(hào)的區(qū)別在于節(jié)點(diǎn)賬本上維持了一個(gè)位掩碼來區(qū)分哪些交易是有效的，哪些是無效的遭居。同時(shí)賬本也允許節(jié)點(diǎn)回放所有的交易并且重新構(gòu)造狀態(tài)啼器。

隨著系統(tǒng)運(yùn)行時(shí)間越來越長(zhǎng)，無效交易也會(huì)隨之變多俱萍，導(dǎo)致節(jié)點(diǎn)賬本上存放了一堆無效交易端壳，額外的增加了存儲(chǔ)空間，如果這個(gè)時(shí)間點(diǎn)有新的節(jié)點(diǎn)加入到系統(tǒng)枪蘑，在同步有效交易的同時(shí)损谦，也會(huì)同步一大堆無效的交易岖免，這也會(huì)導(dǎo)致新節(jié)點(diǎn)的同步時(shí)間增長(zhǎng)，同時(shí)也會(huì)導(dǎo)致驗(yàn)證這些交易時(shí)間變長(zhǎng)照捡。于是颅湘，為了減少存儲(chǔ)空間和新節(jié)點(diǎn)加入系統(tǒng)的時(shí)間和成本，fabric引入了有效賬本的概念栗精。

所謂的有效賬本是指除了狀態(tài)和賬本外闯参，節(jié)點(diǎn)持有一個(gè)邏輯賬本，只包含有有效并且是已提交的交易悲立。這個(gè)哈希鏈?zhǔn)峭ㄟ^過濾賬本上的所有有效交易得到鹿寨。
生成一個(gè)有效賬本上的有效交易塊的過程如下：

image

當(dāng)一個(gè)交易在變成有效交易塊之前會(huì)判斷該交易是否有效，如果是無效交易薪夕，就被剔除脚草，如果是有效交易則加入進(jìn)一個(gè)有效塊(vBlock)中。所有的節(jié)點(diǎn)都會(huì)在本地進(jìn)行這樣的操作原献，比如通過使用節(jié)點(diǎn)賬本的位掩碼來過濾馏慨。一個(gè)有效交易塊中不能包含無效交易塊，所有無效交易都已經(jīng)被剔除嚼贡。這種有效交易塊(vBlock)的長(zhǎng)度是不固定的。每個(gè)節(jié)點(diǎn)上的有效交易塊(vBlock)被連接起來成為一個(gè)哈希鏈同诫，也就成了一個(gè)有效賬本粤策。有效賬本的每個(gè)塊包含：

• 前一個(gè)有效塊的哈希
• 有效塊的編號(hào)
• 從上一個(gè)有效交易塊生成后到現(xiàn)在該節(jié)點(diǎn)提交的所有有效交易的有序列表
• 在該節(jié)點(diǎn)賬本中，派生出當(dāng)前有效交易塊的交易塊的哈希
  所有上述信息都被節(jié)點(diǎn)進(jìn)行哈希索引
  賬本包含有無效交易误窖，雖然這些交易沒有記錄的必要叮盘，但是節(jié)點(diǎn)不會(huì)簡(jiǎn)單的就丟棄節(jié)點(diǎn)賬本上的這些交易塊。因此一旦節(jié)點(diǎn)賬本生成了相關(guān)有效節(jié)點(diǎn)霹俺，就會(huì)對(duì)節(jié)點(diǎn)賬本進(jìn)行刪減柔吼。也就是說，在這種情況下丙唧，如果有一個(gè)新節(jié)點(diǎn)計(jì)入到這個(gè)網(wǎng)絡(luò)愈魏，其他節(jié)點(diǎn)就不會(huì)發(fā)送那些被剔除的交易塊到這個(gè)新的節(jié)點(diǎn)上，也不需要新加入的節(jié)點(diǎn)去驗(yàn)證他們的有效交易塊想际。那么節(jié)點(diǎn)什么時(shí)候生成有效賬本呢培漏？于是有了檢查點(diǎn)機(jī)制，檢查點(diǎn)機(jī)制通過檢查點(diǎn)協(xié)議讓節(jié)點(diǎn)知道什么時(shí)候生成有效交易塊并去剔除無效的交易塊胡本。

檢查點(diǎn)協(xié)議如下：
節(jié)點(diǎn)對(duì)每個(gè)CHK塊周期性地執(zhí)行檢查點(diǎn)牌柄，CHK是一個(gè)可配置參數(shù)。為了初始化一個(gè)檢查點(diǎn)侧甫，節(jié)點(diǎn)通過gossip網(wǎng)絡(luò)廣播檢查點(diǎn)消息到其他節(jié)點(diǎn)珊佣，檢查點(diǎn)消息為：
<CHECKPOINT,blocknohash,blockno,stateHash,peerSig>
其中blockno 是當(dāng)前交易塊號(hào)蹋宦，blocknohash為當(dāng)前交易塊的哈希，stateHash 為最近狀態(tài)的哈希咒锻，peerSig 節(jié)點(diǎn)對(duì)檢查點(diǎn)消息中其他字段的簽名冷冗。

節(jié)點(diǎn)不停的接收檢查點(diǎn)消息，直到有足夠多的正確簽名信息虫碉，可以通過這些信息中的blockno贾惦，blocknohash和stateHash建立一個(gè)有效的檢查點(diǎn)。

對(duì)塊號(hào)為blockno ,帶有blocknohash的塊創(chuàng)建了一個(gè)有效檢查點(diǎn)后敦捧，節(jié)點(diǎn)首先檢查blockno是否大于最新有效檢查點(diǎn)的blockno,如果是须板，就把最新有效檢查點(diǎn)的blockno改成blockno. 之后，存儲(chǔ)由各自節(jié)點(diǎn)的簽名組成了一個(gè)有效的檢查點(diǎn)到latestValidCheckpointProof兢卵。同時(shí)存儲(chǔ)stateHash響應(yīng)的狀態(tài)到latestValidCheckpointProof习瑰。最后可選的是否需要修剪節(jié)點(diǎn)賬本。