介紹

此頁(yè)面記錄了區(qū)塊鏈基礎(chǔ)架構(gòu)的體系結(jié)構(gòu)，其中區(qū)塊鏈節(jié)點(diǎn)的角色分為對(duì)等(維護(hù)狀態(tài)/分類帳)和分類器(根據(jù)分類帳中包含的交易順序協(xié)議)。在通用區(qū)塊鏈體系結(jié)構(gòu)(包括Hyperledger結(jié)構(gòu)v0.6和更早版本)中，這些角色是統(tǒng)一的(請(qǐng)參見(jiàn)Hyperledger結(jié)構(gòu)v0.6中的身份驗(yàn)證對(duì)等方)。該體系結(jié)構(gòu)還引入了一個(gè)經(jīng)批準(zhǔn)的對(duì)等體(簽名者)，作為一種特殊類型的對(duì)等體，負(fù)責(zé)模擬執(zhí)行和批準(zhǔn)事務(wù)(大致對(duì)應(yīng)于HL Fabric 0.6中執(zhí)行的事務(wù))。

與對(duì)等/統(tǒng)計(jì)/簽名者統(tǒng)一設(shè)計(jì)(例如HL Fabric v0.6)相比，這種架構(gòu)具有以下優(yōu)勢(shì)。

鏈碼信任的靈活性。該架構(gòu)將鏈碼(區(qū)塊鏈應(yīng)用)的信任假設(shè)與信任假設(shè)進(jìn)行分類。換句話說(shuō)，訂閱服務(wù)可以由一組節(jié)點(diǎn)(訂購(gòu)者)提供，其中一些節(jié)點(diǎn)可以失敗或行為不正確，每個(gè)鏈代碼的支持者可能不同。

可擴(kuò)展性。因?yàn)樨?fù)責(zé)特定鏈碼的支持者節(jié)點(diǎn)與用戶正交，所以系統(tǒng)可以比同一節(jié)點(diǎn)更好地執(zhí)行這些功能。特別是，當(dāng)不同的鏈碼指定不相交的支持者時(shí)，會(huì)出現(xiàn)這種結(jié)果。該代碼引入了支持者之間鏈碼的劃分，允許并行鏈碼執(zhí)行(背書(shū))。此外，從代碼訂閱服務(wù)的關(guān)鍵路徑中刪除了代價(jià)高昂的鏈代碼執(zhí)行。

保密。該體系結(jié)構(gòu)有助于部署對(duì)交易內(nèi)容和狀態(tài)更新有保密要求的鏈碼。

共識(shí)模塊化。該架構(gòu)是模塊化的，允許實(shí)現(xiàn)可插拔一致性(即訂閱服務(wù))。

該架構(gòu)促進(jìn)了Hyper-v6.6的開(kāi)發(fā)。如下所述，Hyperledger Fabric v1將包含一些方面，而其他方面將推遲到Hyperledger Fabric的v1后版本。

目錄

第1部分:與Hyperledger結(jié)構(gòu)v1相關(guān)的模式元素

系統(tǒng)結(jié)構(gòu)

交易背書(shū)的基本工作流程

認(rèn)可政策

第二部分:后v1建筑元素

分類帳檢查點(diǎn)(修剪)

1.系統(tǒng)架構(gòu)(系統(tǒng)架構(gòu))

區(qū)塊鏈?zhǔn)且粋€(gè)由許多節(jié)點(diǎn)組成的分布式系統(tǒng)，這些節(jié)點(diǎn)相互通信。區(qū)塊鏈運(yùn)行一個(gè)名為chaincode的程序，保存狀態(tài)和分類賬數(shù)據(jù)，并執(zhí)行交易。鏈碼是中間元素，因?yàn)槭聞?wù)是對(duì)鏈碼進(jìn)行的操作。交易必須“已批準(zhǔn)”，只有已批準(zhǔn)的交易才能影響狀態(tài)?？赡苡幸粋€(gè)或多個(gè)用于管理功能和參數(shù)的特殊鏈碼，它們統(tǒng)稱為系統(tǒng)鏈碼。

1.1。貿(mào)易

可能有兩種類型的交易:

部署事務(wù)使用程序作為參數(shù)創(chuàng)建一個(gè)新的鏈代碼。當(dāng)部署事務(wù)成功執(zhí)行時(shí)，鏈代碼已經(jīng)安裝在塊上。

調(diào)用事務(wù)在先前部署的鏈代碼的上下文中執(zhí)行操作。調(diào)用事務(wù)指的是鏈碼和它提供的一個(gè)函數(shù)。當(dāng)成功時(shí)，鏈代碼執(zhí)行指定的功能——這可能涉及修改相應(yīng)的狀態(tài)并返回一個(gè)輸出。

如稍后將描述的，部署事務(wù)是調(diào)用事務(wù)的特殊情況，其中創(chuàng)建新鏈代碼的部署事務(wù)對(duì)應(yīng)于系統(tǒng)鏈代碼上的調(diào)用事務(wù)。

注意:本文檔當(dāng)前假設(shè)事務(wù)創(chuàng)建一個(gè)新的鏈代碼或調(diào)用一個(gè)由已部署的鏈代碼提供的操作。本文檔沒(méi)有描述:a)查詢(只讀)事務(wù)的優(yōu)化(包含在v1中)，b)交叉鏈接代碼事務(wù)的支持(后v1功能)。

1.2。區(qū)塊鏈數(shù)據(jù)結(jié)構(gòu)

1.2.1。條件

塊的最新?tīng)顟B(tài)(或簡(jiǎn)單狀態(tài))被建模為版本化的鍵/值存儲(chǔ)(KVS)，其中鍵是一個(gè)名稱，值是一個(gè)任意的blob。這些條目通過(guò)在區(qū)塊鏈運(yùn)行的鏈碼(應(yīng)用程序)進(jìn)行操作，并獲得KVS操作。狀態(tài)被持久存儲(chǔ)，并且狀態(tài)的更新被記錄。請(qǐng)注意，版本化的KVS被用作狀態(tài)模型，實(shí)現(xiàn)可能使用實(shí)際的KVS、關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)或任何其他解決方案。

更正式地說(shuō)，狀態(tài)被建模為映射k->:的元素，其中:

k是一組鍵

v是一組值

n是版本號(hào)的無(wú)限有序集。注入函數(shù)next: n->: N取N的元素，返回下一個(gè)版本號(hào)。

v和n都包含一個(gè)特殊的元素 bot，當(dāng)n是最低的元素時(shí)就是這種情況。最初，所有鍵都映射到( bot， bot)。對(duì)于s(k)=(v，ver)，我們用s(k)，vue表示v，s(k)表示v..

KVS的運(yùn)作模式如下:

訂戶形成訂閱服務(wù)，即提供交付保證的通信結(jié)構(gòu)。訂閱服務(wù)可以以不同的方式實(shí)現(xiàn):從集中式服務(wù)(例如，用于開(kāi)發(fā)和測(cè)試)到針對(duì)不同網(wǎng)絡(luò)和節(jié)點(diǎn)故障模型的分布式協(xié)議。

訂閱服務(wù)為客戶端和對(duì)等方提供共享的通信通道，并為包含事務(wù)的消息提供廣播服務(wù)。客戶端連接到一個(gè)通道，并可以在該通道上廣播消息，然后將消息傳輸?shù)剿袑?duì)等端。該通道支持所有消息的原子傳輸，即具有全面有序傳輸和可靠性的消息通信。換句話說(shuō)，信道向所有連接的對(duì)等體輸出相同的消息，并以相同的邏輯順序向所有對(duì)等體輸出它們。這種原子通信保障在分布式系統(tǒng)的上下文中也稱為通用命令廣播、原子廣播或共識(shí)。傳輸?shù)南⑹菈K狀態(tài)中包含的候選事務(wù)。

分區(qū)(訂閱服務(wù)通道)。訂閱服務(wù)可以支持多種渠道，類似于發(fā)布/訂閱(發(fā)布/訂閱)消息系統(tǒng)的主題?？蛻舳丝梢赃B接到給定的通道，然后他們可以發(fā)送消息并獲取到達(dá)的消息。通道可以被視為分區(qū)-連接到一個(gè)通道的客戶端不知道其他通道的存在，但是客戶端可以連接到多個(gè)通道。盡管Hyperledger Fabric v1中包含的一些訂閱服務(wù)實(shí)現(xiàn)將支持多個(gè)頻道，但為了簡(jiǎn)單起見(jiàn)，在本文的其余部分，我們假設(shè)訂閱服務(wù)由一個(gè)頻道/主題組成。

訂閱服務(wù)的對(duì)應(yīng)API通過(guò)訂閱服務(wù)提供的接口連接到訂閱服務(wù)提供的通道。訂閱服務(wù)應(yīng)用編程接口由兩個(gè)基本操作組成(更常見(jiàn)的是異步事件):

TODO在客戶端/對(duì)等體指定的序列號(hào)下添加了一部分用于獲取特定塊的API。

廣播(blob):客戶端調(diào)用這個(gè)廣播任意消息blob來(lái)通過(guò)信道傳播。向服務(wù)發(fā)送請(qǐng)求時(shí)，這也稱為BFT上下文(blob)中的請(qǐng)求。

傳遞(seqno，prevhash，blob):排序服務(wù)在對(duì)等方上調(diào)用此命令，傳遞帶有指定非負(fù)整數(shù)序列號(hào)(seqno)和最近傳輸?shù)腷lob(prevhash)的哈希的消息blob。換句話說(shuō)，它是訂閱服務(wù)的輸出事件。在發(fā)布-訂閱系統(tǒng)中，Delivery()有時(shí)稱為notify()，在BFT系統(tǒng)中稱為commit()。

分類賬和區(qū)塊形成。分類賬(見(jiàn)第1.2.2節(jié))包含訂閱服務(wù)輸出的所有數(shù)據(jù)。簡(jiǎn)而言之，它是一個(gè)傳遞序列(seqno，prevhash，blob)事件，根據(jù)上述prevhash計(jì)算形成一個(gè)散列鏈。

在大多數(shù)情況下，出于效率原因，訂單服務(wù)不輸出單個(gè)事務(wù)(blob)，而是在單個(gè)交付事件中對(duì)blob和輸出塊進(jìn)行分組(批處理)。在這種情況下，排序服務(wù)必須強(qiáng)制并傳達(dá)每個(gè)塊內(nèi)斑點(diǎn)的確定性排序。可以通過(guò)排序服務(wù)動(dòng)態(tài)選擇塊中的塊數(shù)。

在下文中，為了便于介紹，我們定義了訂單服務(wù)屬性(本節(jié)的其余部分)，并解釋了交易背書(shū)的工作流程(第2節(jié))，假設(shè)每個(gè)交付事件都有一個(gè)blob。假設(shè)塊的遞送事件對(duì)應(yīng)于塊內(nèi)每個(gè)塊的單獨(dú)遞送事件的序列，并且根據(jù)塊內(nèi)塊的確定性進(jìn)行排序，則這些容易擴(kuò)展到塊。

訂閱服務(wù)屬性

訂閱服務(wù)(或原子廣播信道)的保證規(guī)定了廣播消息時(shí)會(huì)發(fā)生什么以及傳輸?shù)南⒅g存在什么關(guān)系。這些保證如下:

安全性(一致性保證):只要對(duì)等體連接到通道的時(shí)間足夠長(zhǎng)(它們可以斷開(kāi)連接或崩潰，但會(huì)重新啟動(dòng)和重新連接)，它們就會(huì)看到相同系列的傳遞(seqno、prevhash、blob)消息。這意味著根據(jù)序列號(hào)，輸出(delivery()事件)在所有對(duì)等體上以相同的順序發(fā)生，并為相同的序列號(hào)攜帶相同的內(nèi)容(blob和prevhash)。請(qǐng)注意，這只是一個(gè)邏輯序列，一個(gè)對(duì)等體上的傳遞(seqno，prevhash，blob)不需要發(fā)生在任何實(shí)時(shí)關(guān)系中，這樣傳遞(seqno，prevhash，blob)就可以在另一個(gè)對(duì)等體上輸出相同的消息。換句話說(shuō)，給定一個(gè)特定的seqno，沒(méi)有兩個(gè)正確的對(duì)等體提供不同的prevhash或blob值。此外，除非一些客戶端(對(duì)等體)實(shí)際上被稱為廣播斑點(diǎn)，否則不傳輸值斑點(diǎn)，并且優(yōu)選地，每個(gè)廣播斑點(diǎn)僅傳輸一次。

此外，deliver()事件包含前一個(gè)deliver()事件(prevhash)中數(shù)據(jù)的加密哈希。當(dāng)排序服務(wù)實(shí)現(xiàn)原子廣播保證時(shí)，prevhash是序列號(hào)為seqno-1的deliver()事件的參數(shù)的加密散列。這將在delivery()事件中創(chuàng)建一個(gè)哈希鏈，以幫助驗(yàn)證訂單服務(wù)輸出的完整性，這將在后面的第4節(jié)和第5節(jié)中討論。在第一個(gè)deliver()事件的特殊情況下，prevhash有一個(gè)默認(rèn)值。

生命力(交付保證):訂閱服務(wù)的生命力保證由訂閱服務(wù)的實(shí)現(xiàn)來(lái)規(guī)定。確切的保證可能取決于網(wǎng)絡(luò)和節(jié)點(diǎn)故障模型。

原則上，如果提交客戶端沒(méi)有失敗，訂閱服務(wù)應(yīng)該確保連接到訂閱服務(wù)的每個(gè)正確的對(duì)等體最終都會(huì)提交每個(gè)提交的事務(wù)。

總而言之，訂閱服務(wù)確保以下屬性:

同意。任意兩個(gè)正確對(duì)等體的事件傳遞(seqno，prev hashp，blob0)和傳遞(seqno，prev hashp，blob1)與seqno，prevhash0 = = prevhasp，blob0 == blob1相同；

哈希完整性。對(duì)于正確對(duì)等體的任何兩個(gè)事件傳遞(seqno-1，prevhash0，blob0)和傳遞(seqno，prevhash，blob)，prev hash = hash(seq no-1 | | prev hash 0 | | blob 0)。

如果排序服務(wù)在正確的對(duì)等p上輸出一個(gè)傳遞(seqno，prevhash，blob)，那么seqno >: 0，那么p已經(jīng)傳遞了一個(gè)事件傳遞(seqno-1，prevhash0，blob0)。

沒(méi)有創(chuàng)作。任何事件傳遞(seqno，prevhash，blob)都在廣播(blob)事件之前，正確的對(duì)等體必須在一些(可能不同的)對(duì)等體之前；

無(wú)重復(fù)(可選，但可取)。關(guān)于任何兩個(gè)事件廣播(blob)和廣播(blob ')，當(dāng)兩個(gè)事件傳遞(seqno0，prevhas0，blob)和傳遞(seqno1，prevhasp，blob ')發(fā)生在正確的對(duì)等點(diǎn)并且blob == blob '，seqno0 = = seqno1和prevhash0 = = prevhasp。

活動(dòng)。如果正確的客戶端調(diào)用事件廣播(blob)，那么每個(gè)正確的對(duì)等體“最終”發(fā)出事件傳遞(*、*、blob)，其中*表示任何值。

2.交易背書(shū)的基本工作流程

下面我們概述一個(gè)事務(wù)的高級(jí)請(qǐng)求流。

注:請(qǐng)注意，以下協(xié)議并不認(rèn)為所有交易都是確定性的，即允許非確定性交易。

2.1。客戶端創(chuàng)建一個(gè)事務(wù)，并將其發(fā)送給選定的對(duì)等方

為了調(diào)用一個(gè)事務(wù)，客戶機(jī)向一組選定的支持對(duì)等體發(fā)送一個(gè)“提議”消息(可能不同時(shí)——見(jiàn)第2.1.2和2.3節(jié))。給定鏈碼的一組被識(shí)別的對(duì)等體可以通過(guò)對(duì)等體提供給客戶，并且后者通過(guò)識(shí)別策略知道一組被識(shí)別的對(duì)等體(參見(jiàn)第3節(jié))。例如，一個(gè)事務(wù)可以發(fā)送給給定鏈碼的所有支持者。也就是說(shuō)，有的支持者可能會(huì)下線，有的可能會(huì)反對(duì)，選擇不批準(zhǔn)交易。提交客戶端試圖用可用的支持者來(lái)滿足策略表達(dá)式。

在下文中，我們首先詳細(xì)解釋了PROPOSE消息的格式，然后討論了提交客戶端和代理之間可能的交互模式。

2.1.1。提議消息格式

PROPOSE消息的格式為，其中tx是強(qiáng)制參數(shù)，而anchor是可選參數(shù)，解釋如下。

Tx =，其中

客戶端標(biāo)識(shí)是提交客戶端的標(biāo)識(shí)。

ChaincodeID指交易中涉及的鏈碼。

TxPayload是包含提交的事務(wù)本身的負(fù)載，

時(shí)間戳是由客戶端維護(hù)的單調(diào)遞增的整數(shù)(對(duì)于每個(gè)新事務(wù))

ClientSig是tx其他字段的客戶端簽名。

在調(diào)用事務(wù)和部署事務(wù)(即調(diào)用涉及特定于部署的系統(tǒng)鏈代碼的事務(wù))之間，txPayload的細(xì)節(jié)會(huì)有所不同。TxPayload將由兩個(gè)用于調(diào)用事務(wù)的字段組成

TxPayload =，其中

操作手段鏈碼功能和參數(shù)，

元數(shù)據(jù)表示與調(diào)用相關(guān)的屬性。

TxPayload將由三個(gè)部署事務(wù)字段組成

TxPayload =，其中

Source表示鏈代碼的源代碼。

元數(shù)據(jù)表示與鏈代碼和應(yīng)用程序相關(guān)的屬性，

策略包括與所有對(duì)等體都可以訪問(wèn)的鏈碼相關(guān)的策略，例如識(shí)別策略。請(qǐng)注意，部署事務(wù)中沒(méi)有提供TxCapload的提交策略，但是部署的TxCapload包含提交策略標(biāo)識(shí)及其參數(shù)(參見(jiàn)第3節(jié))。

錨包含讀取版本依賴性，或者更具體地，密鑰版本對(duì)(即錨是KxN的子集)，其將提議請(qǐng)求綁定或“錨定”到KVS的指定版本的密鑰(參見(jiàn)1.2節(jié))。如果客戶指定錨參數(shù)，代理將僅在其本地KVS匹配錨中的相應(yīng)密鑰的讀取版本號(hào)上批準(zhǔn)交易(詳見(jiàn)第2.2節(jié))。

tx的加密散列被所有節(jié)點(diǎn)用作唯一事務(wù)標(biāo)識(shí)符tid(即tid = HASH(tx))?？蛻舳藢id存儲(chǔ)在內(nèi)存中，并等待來(lái)自同意的對(duì)等方的響應(yīng)。

2.1.2。報(bào)文方式

客戶決定與支持者互動(dòng)的順序。例如，客戶端通常向單個(gè)代碼發(fā)送(即沒(méi)有錨參數(shù))，然后生成一個(gè)版本依賴(anchor)，客戶端可以在以后將其作為其PROPOSE消息的參數(shù)提供給其他支持者。又如，客戶端可以直接發(fā)送給所有選中的支持者(沒(méi)有錨點(diǎn))。不同的通信模式是可能的，客戶可以自由決定這些模式(另見(jiàn)第2.3節(jié))。

2.2。識(shí)別對(duì)方的模擬交易并生成簽名

收到

模擬事務(wù)包括通過(guò)調(diào)用事務(wù)引用的鏈碼(chaincodeID)和驗(yàn)證對(duì)等體本地保存的狀態(tài)副本來(lái)授權(quán)對(duì)等體臨時(shí)執(zhí)行事務(wù)(txPayload)。

作為執(zhí)行的結(jié)果，對(duì)等體被支持來(lái)計(jì)算讀取版本依賴性(讀取集)和狀態(tài)更新(寫(xiě)入集)，也稱為數(shù)據(jù)庫(kù)語(yǔ)言的MVCC+后圖像信息。

回想一下，一個(gè)狀態(tài)由一個(gè)鍵/值(k/v)組成。所有k/v條目都是版本化的，也就是說(shuō)，每個(gè)條目都包含有序的版本信息，每當(dāng)存儲(chǔ)在密鑰下的值更新時(shí)，該信息就會(huì)增加。說(shuō)明事務(wù)的對(duì)等體記錄了鏈代碼訪問(wèn)的所有k/v對(duì)，用于讀取或?qū)懭耄珜?duì)等體沒(méi)有更新其狀態(tài)。進(jìn)一步:

識(shí)別對(duì)等體被給予執(zhí)行事務(wù)之前的狀態(tài)，并且對(duì)于事務(wù)讀取的每個(gè)密鑰k，對(duì)(k，s(k))。版本)添加到讀取集中。

此外，對(duì)于由事務(wù)修改的新值v′的每個(gè)密鑰k，一對(duì)(k，v′)被添加到寫(xiě)入集?；蛘?，v '可以是新值相對(duì)于前一個(gè)值(s(k))的增量。值)。

如果客戶端在PROPOSE消息中指定了一個(gè)錨點(diǎn)，則客戶端指定的錨點(diǎn)必須等于支持對(duì)等體在模擬事務(wù)時(shí)生成的讀取集。

然后，對(duì)等方在內(nèi)部(可能還有tx)將建議轉(zhuǎn)發(fā)給其批準(zhǔn)事務(wù)的(對(duì)等方)邏輯部分，稱為批準(zhǔn)邏輯。默認(rèn)情況下，對(duì)等審批邏輯接受轉(zhuǎn)賬方案，只需簽署轉(zhuǎn)賬方案即可。然而，支持邏輯可以解釋任何功能，例如，以轉(zhuǎn)發(fā)建議和tx作為輸入與傳統(tǒng)系統(tǒng)交互，以達(dá)成是否支持交易的決定。

如果批準(zhǔn)邏輯決定批準(zhǔn)交易，它將向提交客戶端(tx.clientID)發(fā)送一條消息，其中:

trans-proposal:=(EpID，tid，chaincodeID，txContentBlob，readset，writeset)，

其中txContentBlob是鏈碼/事務(wù)特定信息。目的是使用txcontentlob作為tx的某種表示(例如，txContentBlob = tx.txPayload)。

EpSig是一種支持對(duì)等體的傳輸簽名

否則，如果批準(zhǔn)邏輯拒絕批準(zhǔn)交易，代理可以向提交的客戶端發(fā)送消息(TRANSACTION-INVALID，tid，REJECTED)。

請(qǐng)注意，在這一步中，代理不會(huì)改變其狀態(tài)，因此背書(shū)上下文中交易模擬生成的更新不會(huì)影響狀態(tài)！

2.3。提交客戶收款交易的背書(shū)，并通過(guò)訂閱服務(wù)進(jìn)行廣播

提交的客戶等待，直到它在(TRANSACTION-SUPPORTED，tid，*)語(yǔ)句中收到“足夠”的消息和簽名，以便獲得交易建議被批準(zhǔn)。如第2.1.2節(jié)所述，這可能涉及與支持者的一次或多次往返互動(dòng)。

“足夠”的確切數(shù)量取決于鏈碼認(rèn)證政策(另見(jiàn)第3節(jié))。如果符合確認(rèn)政策，則交易已被批準(zhǔn)；注意還沒(méi)有答應(yīng)。由簽署交易并確認(rèn)交易被批準(zhǔn)的交易所發(fā)布的交易信息的集合被稱為背書(shū)，并由背書(shū)表示。

如果提交客戶不嘗試收集交易提案的背書(shū)，它將放棄交易并提供稍后重試的選項(xiàng)。

對(duì)于有效的交易，我們現(xiàn)在使用訂閱服務(wù)。提交客戶端使用廣播(blob)調(diào)用排序服務(wù)，其中blob =背書(shū)。如果客戶端不能直接調(diào)用排序服務(wù)，它可以通過(guò)自己選擇的對(duì)等代理進(jìn)行廣播。此類同行必須得到客戶的信任，并且不要從批準(zhǔn)中刪除任何消息，否則交易可能被視為無(wú)效。但是，請(qǐng)注意，代理對(duì)等方可能不會(huì)做出有效的背書(shū)。

2.4。訂閱服務(wù)向?qū)Φ确浇桓督灰?/p>

當(dāng)事件傳遞(seqno，prevhash，blob)發(fā)生并且對(duì)等方將所有狀態(tài)更新應(yīng)用到序列號(hào)低于seqno的blob時(shí)，對(duì)等方執(zhí)行以下操作:

它根據(jù)所引用的鏈代碼(blob . tran-proposition . chain codeid)的策略檢查blob .背書(shū)是否有效。

在一個(gè)典型的例子中，它還驗(yàn)證依賴關(guān)系(blob .背書(shū). tran-proposition . readset)沒(méi)有被違反。在更復(fù)雜的用例中，背書(shū)轉(zhuǎn)讓方案可能會(huì)有所不同。在這種情況下，承認(rèn)政策(第3節(jié))規(guī)定了國(guó)家如何演變。

根據(jù)為狀態(tài)更新選擇的一致性屬性或“隔離保證”，依賴關(guān)系的驗(yàn)證可以通過(guò)不同的方式實(shí)現(xiàn)。除非鏈代碼身份驗(yàn)證策略指定了不同的保護(hù)，否則可序列化是默認(rèn)的隔離保證。通過(guò)要求與讀取集中每個(gè)密鑰相關(guān)聯(lián)的版本等于此狀態(tài)下的密鑰版本，并拒絕不滿足此要求的事務(wù)，可以提供可序列化。

如果所有這些檢查都通過(guò)，則交易被視為有效或已交易。在這種情況下，對(duì)等體在對(duì)等體的位掩碼中將事務(wù)標(biāo)記為1，并將blob .背書(shū). tran-proposition . write set應(yīng)用于塊狀態(tài)(如果轉(zhuǎn)發(fā)方案相同，否則，識(shí)別策略邏輯定義獲取Blob的功能。背書(shū))。

如果blob .背書(shū)的背書(shū)策略驗(yàn)證失敗，則該事務(wù)無(wú)效，對(duì)等方在對(duì)等機(jī)的位掩碼中將該事務(wù)標(biāo)記為0。請(qǐng)注意，無(wú)效事務(wù)不會(huì)改變狀態(tài)。

請(qǐng)注意，這足以使所有(正確的)對(duì)等體在處理具有給定序列號(hào)的傳遞事件(塊)后具有相同的狀態(tài)。也就是說(shuō)，通過(guò)訂閱服務(wù)的保證，所有正確的對(duì)等體將接收到相同的傳遞序列(seqno，prevhash，blob)事件。由于注冊(cè)策略的評(píng)估和讀取集中版本相關(guān)性的評(píng)估是確定性的，因此正確的對(duì)等體將得出相同的結(jié)論，而不管blob中包含的事務(wù)是否有效。因此，所有對(duì)等體提交和應(yīng)用相同的事務(wù)序列，并以相同的方式更新它們的狀態(tài)。

圖1?？赡艿氖聞?wù)流程圖(常見(jiàn)案例路徑)。

3.認(rèn)可政策

3.1。政策規(guī)范的認(rèn)可

批準(zhǔn)政策是同意交易的條件。區(qū)塊鏈對(duì)等方有一組預(yù)先指定的批準(zhǔn)策略，這些策略由安裝特定鏈代碼的部署事務(wù)引用。背書(shū)策略可以參數(shù)化，這些參數(shù)可以由部署事務(wù)指定。

為了保證封鎖和安全屬性，一套審批策略應(yīng)該是一套功能有限的成熟策略，以保證有限的執(zhí)行時(shí)間(終止)、確定性、性能和安全性。

就有限的策略評(píng)估時(shí)間(終止)、確定性、性能和安全保證而言，動(dòng)態(tài)添加識(shí)別策略(例如，通過(guò)在鏈代碼部署時(shí)部署事務(wù))非常敏感。所以不允許動(dòng)態(tài)添加識(shí)別策略，但以后可以支持。

3.2。背書(shū)政策的交易評(píng)估

只有根據(jù)政策獲得批準(zhǔn)，交易才被宣布為有效。鏈碼的調(diào)用交易必須先經(jīng)過(guò)審批，符合鏈碼政策，否則不提交。這是通過(guò)提交客戶和批準(zhǔn)同行之間的互動(dòng)來(lái)完成的，如第2節(jié)所述。

在形式上，背書(shū)政策是背書(shū)的一個(gè)謂詞，并可能進(jìn)一步表明評(píng)估為真或假。對(duì)于部署事務(wù)，根據(jù)系統(tǒng)范圍的策略獲得批準(zhǔn)(例如，從系統(tǒng)鏈代碼)。

識(shí)別策略謂詞引用某些變量。這可能意味著:

與鏈碼相關(guān)聯(lián)的密鑰或身份(在鏈碼的元數(shù)據(jù)中找到)，例如一組簽名者；

鏈碼的進(jìn)一步元數(shù)據(jù)；

背書(shū)要素和背書(shū)提案；

可能更多。

上面的列表是按照表達(dá)性和復(fù)雜性的增加排序的，也就是說(shuō)，只涉及節(jié)點(diǎn)的密鑰和身份的支持策略會(huì)相對(duì)簡(jiǎn)單一些。

識(shí)別策略謂詞的評(píng)估必須是確定性的。每個(gè)對(duì)等體應(yīng)該在本地評(píng)估識(shí)別，這樣對(duì)等體就不需要與其他對(duì)等體交互，但是所有正確的對(duì)等體都以相同的方式評(píng)估識(shí)別策略。

3.3。認(rèn)證政策示例

謂詞可能包含邏輯表達(dá)式，計(jì)算結(jié)果為真或假。通常，條件將使用數(shù)字簽名來(lái)調(diào)用由鏈接到代碼簽名的對(duì)等體發(fā)出的事務(wù)。

假設(shè)chaincode指定了一個(gè)支持者集合E = {Alice，Bob，Charlie，Dave，Eve，F(xiàn)rank，George}。一些示例策略:

來(lái)自e的所有成員的相同轉(zhuǎn)發(fā)方案的有效簽名

任何單個(gè)成員的有效簽名

根據(jù)條件(愛(ài)麗絲或鮑勃)和(任意兩個(gè):查理、戴夫、伊芙、弗蘭克、喬治)，同意轉(zhuǎn)讓方案的簽名有效。

七個(gè)支持者中的任何一個(gè)都有相同轉(zhuǎn)發(fā)方案的有效簽名。(更一般地說(shuō)，對(duì)于n >:3f個(gè)簽名者的鏈碼，n個(gè)簽名者中的任意2f+1個(gè)有效簽名，或任意多于(n+f)/ 2個(gè)簽名者的群)。

假設(shè)對(duì)于支持者，如{愛(ài)麗絲= 49，鮑勃= 15，查理= 15，戴夫= 10，夏娃= 7，弗蘭克= 3，喬治= 1}，總股本為100的有一個(gè)“是”或“權(quán)重”:政策要求一個(gè)擁有多數(shù)股權(quán)的集合(即合并后的股份嚴(yán)格超過(guò)50股)。等等。

前面示例條件中的份額分配可以是靜態(tài)的(固定在鏈代碼的元數(shù)據(jù)中)，也可以是動(dòng)態(tài)的(例如，取決于鏈代碼的狀態(tài)，并在執(zhí)行過(guò)程中進(jìn)行修改)。

4.1。驗(yàn)證分類帳(VLedger)

為了保持分類賬的抽象性，只包括有效且已提交的交易(如比特幣中出現(xiàn)的交易)，除了狀態(tài)和分類賬外，對(duì)等方還可以維護(hù)驗(yàn)證分類賬(或VLedger)。這是一個(gè)哈希鏈，通過(guò)過(guò)濾無(wú)效交易從分類帳中派生出來(lái)。

VLedger塊(此處稱為vBlock)的構(gòu)造如下。由于對(duì)等塊可能包含無(wú)效事務(wù)(即，無(wú)效的已批準(zhǔn)事務(wù)或無(wú)效的版本依賴關(guān)系)，來(lái)自該塊的這些事務(wù)在被添加到vBlock之前被對(duì)等體過(guò)濾掉。每個(gè)對(duì)等體自己執(zhí)行該操作(例如，通過(guò)使用與對(duì)等體相關(guān)聯(lián)的位掩碼)。vBlock被定義為沒(méi)有無(wú)效事務(wù)的塊，并且已經(jīng)被過(guò)濾掉。vBlock本質(zhì)上是動(dòng)態(tài)的，可以是空。下圖顯示了vBlock構(gòu)造的描述

圖2。從挖泥船區(qū)塊驗(yàn)證的分類賬區(qū)塊的形成圖。

每個(gè)對(duì)等體將vBlock鏈接到一個(gè)哈希鏈。更具體地說(shuō)，經(jīng)核實(shí)的分類賬的每一部分包括:

上一個(gè)vBlock的哈希。

vBlock編號(hào)。

計(jì)算自上次vBlock以來(lái)由另一方提交的所有有效事務(wù)的有序列表(即，相應(yīng)塊中的有效事務(wù)列表)。

導(dǎo)出當(dāng)前vBlock的相應(yīng)塊的哈希(在對(duì)等分類帳中)。

所有這些信息都由對(duì)等方連接和散列，并生成一個(gè)散列值來(lái)驗(yàn)證分類帳中的vBlock。

4.2。皮爾勒杰檢查站

分類賬包含無(wú)效交易，可能無(wú)法永久記錄。然而，對(duì)等體不能簡(jiǎn)單地丟棄對(duì)等體塊，從而在建立相應(yīng)的vBlock時(shí)修剪對(duì)等體。也就是說(shuō)，在這種情況下，如果新的對(duì)等體加入網(wǎng)絡(luò)，其他對(duì)等體不能將丟棄的塊(與對(duì)等體相關(guān))轉(zhuǎn)移到加入對(duì)等體，并且不能說(shuō)服加入對(duì)等體其vBlock的有效性。

為了方便地刪除對(duì)等機(jī)，本文引入了檢查點(diǎn)機(jī)制。該機(jī)制通過(guò)對(duì)等網(wǎng)絡(luò)建立vBlock的有效性，并允許檢查點(diǎn)的vBlock替換被丟棄的PeerLedger塊。這又減少了存儲(chǔ)空的數(shù)量，因?yàn)椴恍枰鎯?chǔ)無(wú)效的事務(wù)。它還減少了為加入網(wǎng)絡(luò)的新對(duì)等方重新建立狀態(tài)的工作(因?yàn)樗麄冊(cè)谕ㄟ^(guò)重放對(duì)等機(jī)來(lái)重新建立狀態(tài)時(shí)不需要確定每個(gè)事務(wù)的有效性，而是可以簡(jiǎn)單地重放包含在已驗(yàn)證分類帳中的狀態(tài)更新)。

#### 4.2.1。檢查點(diǎn)協(xié)議

檢查點(diǎn)由對(duì)等點(diǎn)的每個(gè)CHK塊定期執(zhí)行，其中CHK是一個(gè)可配置的參數(shù)。為了啟動(dòng)一個(gè)檢查點(diǎn)，對(duì)等體向其他對(duì)等體廣播(例如，流言)消息，其中blockno是當(dāng)前的塊號(hào)，blocknohash是其對(duì)應(yīng)的散列，stateHash是最新?tīng)顟B(tài)的散列(例如，由Merkle散列生成)，這是在驗(yàn)證blockno和peerSig期間對(duì)等體的簽名(CHECKPOINT、blocknohash、blockno、stateHash)。

對(duì)等方收集檢查點(diǎn)消息，直到獲得足夠多的與blockno、blocknohash和stateHash匹配的正確簽名的消息，以建立有效的檢查點(diǎn)(參見(jiàn)第4.2.2節(jié))。

使用塊號(hào)哈希為塊號(hào)塊號(hào)建立有效檢查點(diǎn)時(shí)，對(duì)等方:

如果blockno >:latestvalidcheckpoint . blockno，則對(duì)等方被分配latestvalidcheckpoint =(blocknohash，blockno)。

構(gòu)成有效檢查點(diǎn)的每個(gè)對(duì)等體的簽名集合被存儲(chǔ)在set latestValidCheckpointProof中，

并將狀態(tài)哈希對(duì)應(yīng)的狀態(tài)存儲(chǔ)在latestValidCheckpointedState中，

(可選)將其PeerLedger修剪為blockno(包含)。

#### 4.2.2。有效檢查點(diǎn)

顯然，檢查點(diǎn)協(xié)議提出了以下問(wèn)題:對(duì)等體何時(shí)可以修剪其對(duì)等體？多少個(gè)CHECKPOINT消息是“足夠”的？這是由檢查點(diǎn)有效性策略定義的，至少有兩種可能的方法，也可以組合使用:

本地(特定于對(duì)象)檢查點(diǎn)有效性策略(LCVP)。給定對(duì)等體p的本地策略可以指定一組對(duì)等體，這些對(duì)等體是可信的，并且其CHECKTUM消息足以建立有效的檢查點(diǎn)。例如，對(duì)等愛(ài)麗絲的LCVP可以定義愛(ài)麗絲需要從鮑勃或查理和戴夫接收檢查點(diǎn)消息。

全球檢查站有效性政策(GCVP)?？梢匀种付z查點(diǎn)有效性策略。這類似于本地對(duì)等策略，但僅在系統(tǒng)(區(qū)塊鏈)粒度上指定，而不是對(duì)等粒度上指定。例如，GCVP可以指定:

如果由11個(gè)不同的對(duì)等點(diǎn)確認(rèn)，每個(gè)對(duì)等點(diǎn)都可以信任該檢查點(diǎn)。

在一個(gè)特定的部署中，每個(gè)用戶與同一個(gè)機(jī)器(即信任域)中的一個(gè)對(duì)等體并置，最多可能是(拜占庭)或(拜占庭)故障，如果f+1中的不同對(duì)等體確認(rèn)與定居者并置，則每個(gè)對(duì)等體可以信任該檢查點(diǎn)。

更多區(qū)塊鏈文章可以加到微信微信官方賬號(hào):智能計(jì)算圈。

知識(shí)星球搜索智能計(jì)算圈或者飯團(tuán)搜索智能計(jì)算圈