這篇文章給大家分享的是有關(guān)Fabric交易背書過程的示例分析的內(nèi)容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
10年的南靖網(wǎng)站建設(shè)經(jīng)驗,針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù),響應(yīng)快,48小時及時工作處理。全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同,自動調(diào)整南靖建站的顯示方式,使網(wǎng)站能夠適用不同顯示終端,在瀏覽器中調(diào)整網(wǎng)站的寬度,無論在任何一種瀏覽器上瀏覽網(wǎng)站,都能展現(xiàn)優(yōu)雅布局與設(shè)計,從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)從事“南靖網(wǎng)站設(shè)計”,“南靖網(wǎng)站推廣”以來,每個客戶項目都認真落實執(zhí)行。
Hyperledger Fabric和其他許多區(qū)塊鏈的關(guān)鍵區(qū)別之一,就在于Fabric區(qū)塊鏈的交易執(zhí)行過程:Fabric交易需要首先通過節(jié)點的背書,然后再進行交易排序,最后才利用有序交易進行賬本的更新。本文將介紹Hyperledger Fabric所采用的執(zhí)行-排序-驗證這一三步交易模型的工作原理,以及引入背書環(huán)節(jié)對Hyperledger Fabric區(qū)塊鏈性能的有益作用。
在其他區(qū)塊鏈平臺中,交易生命周期基本由如下環(huán)節(jié)構(gòu)成:
排序:交易有序加入賬本,然后擴散到所有節(jié)點
執(zhí)行:交易在所有節(jié)點上按順序依次執(zhí)行并更新賬本
為了讓所有節(jié)點保持一致的狀態(tài),交易必須確定性執(zhí)行,也就是說,無論何時何地,同樣的交易必須產(chǎn)生同樣的結(jié)果。這一要求對智能合約形成了很強的約束,也是智能合約通常需要使用領(lǐng)域特定語言(DSL)來開發(fā)的原因之一,因此使用像Java或Go這樣的通用開發(fā)語言基本上無法保證確定性。
在Hyperledger Fabric中,交易的聲明周期則有所不同:
執(zhí)行:交易(通過智能合約)以任意順序執(zhí)行,甚至可以并行執(zhí)行
排序:當(dāng)足夠數(shù)量的節(jié)點對交易結(jié)果達成一致,該交易就會 被加入賬本并擴散給所有節(jié)點。
驗證:每個節(jié)點驗證并按順序執(zhí)行交易,從而更新賬本
首先需要注意的一點是,交易的執(zhí)行和對賬本的實際更新被拆分為兩個環(huán)節(jié),這一拆分帶來一些有益的作用:
所有節(jié)點都需要更新賬本,因此所有節(jié)點都需要執(zhí)行驗證步驟。 但并不是所有的節(jié)點都需要執(zhí)行智能合約。Hyperledger Fabric 使用背書策略來定義哪些節(jié)點需要執(zhí)行交易。這意味著指定的 鏈碼(智能合約)不必開放給所有的節(jié)點 —— 那些不在背書策略中 的節(jié)點不需要由訪問鏈碼的權(quán)限。
交易可以在被排序之前先執(zhí)行。這是的節(jié)點可以并行執(zhí)行交易, 從而提高系統(tǒng)的吞吐量
在Fabric的三步交易模型中,在交易被添加到賬本之前,其鏈碼 執(zhí)行結(jié)果是顯式達成一致的,其他區(qū)塊鏈的兩步交易模型使用 確定性的鏈碼,本身就隱含了節(jié)點之間就智能合約的執(zhí)行結(jié)果 達成一致。顯式達成一致可以讓Fabric使用非確定性的鏈碼, 這也是為什么我們可以使用Go、Java和Node.js編寫Fabric鏈碼 的原因。
Hyperledger Fabric允許用戶自己定義鏈碼執(zhí)行的策略。這些背書策略定義了在交易被加入賬本之前,哪些節(jié)點需要就交易結(jié)果達成一致。Fabric提供了一個小型的DSL來定義背書策略。下面展示了一些背書策略樣例:
節(jié)點A、B、C和F都需要對類型為T的交易進行背書
通道中的大部分節(jié)點必須對類型為U的交易進行背書
A、B、C、D、E、F、G中的至少3個節(jié)點必須對類型為V的交易進行背書
背書策略并不保證正確的鏈碼安裝在正確的節(jié)點上。然而,背書和安裝鏈碼的確存在類似的機制,我們將在后續(xù)教程中介紹這一點。
到目前為止,我們都是松散地使用交易(transaction)這一術(shù)語。在排序-執(zhí)行模型中,鏈碼執(zhí)行和賬本更新被合二為一 —— 交易。在Fabric中,這兩個概念是分開的,因此交易本身也被拆分。
Fabric從交易提議(Transaction Proposal)開始。這是一個用來觸發(fā)鏈碼執(zhí)行的數(shù)據(jù)包。交易提議被發(fā)送給用于背書的節(jié)點。背書節(jié)點執(zhí)行鏈碼,如果成功的話就生成一個實際的賬本交易。背書節(jié)點簽名建議并返回交易提議的響應(yīng),這是執(zhí)行-排序-驗證模型中的執(zhí)行步驟。
一旦交易提議的創(chuàng)建者收到足夠的可以滿足背書策略的簽名,它就可以將交易(以及簽名)提交以便添加到賬本中,這就是排序步驟。
Hyperledger Fabric在區(qū)塊鏈交易方面采取了一個新穎的思路,將智能合約的執(zhí)行與賬本的更新分開使它可以提高交易吞吐量,支持更細粒度的隱私控制,實現(xiàn)更靈活強大的智能合約。而這些特性得以實現(xiàn)的一個關(guān)鍵因素就是在交易加入賬本之前進行顯式地交易背書。
感謝各位的閱讀!關(guān)于“Fabric交易背書過程的示例分析”這篇文章就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,讓大家可以學(xué)到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!