招行區塊鏈fabric
㈠ 區塊鏈是什麼意思,區塊鏈在跨境支付方面有什麼應用
為什麼說互聯網時代將要結束,區塊鏈時代即將來臨?

區塊鏈一旦發展起來,將會迸發更多的創新。作為區塊鏈的第一款產品的比特幣自從誕生以後,就相繼誕生許多創新。比如小額跨境支付,記錄貨幣間的轉賬交易,記錄各種股票,登記房屋產權,記錄程序代碼等
蒸汽時代解放了社會生產力,電氣時代盤活了社會協作能力,互聯網時代把世界聯系在一起,而區塊鏈時代,將讓我們真正實現自由。
㈡ 招商銀行系統清算到幾點幾點開始清算,幾點結Ɲ
日終處理時段即清算時間,是銀行系統每日結算儲蓄業務的時間,招行系統清算時段正常情況下在凌晨0:00-2:00。時間長短不一定,不過一般不會持續很久,過幾分鍾再試試。
拓展資料:
招商銀行「鏈」接跨境清算:
區塊鏈的持續火熱,令金融行業積極研究和應用區塊鏈技術,在多個領域已有實現了區塊鏈應用落地。定位「金融科技銀行」的招商銀行用全球首筆基於區塊鏈技術的同業間跨境人民幣清算業務展示了其區塊鏈布局的決心。「招行期望通過區塊鏈領域的金融創新,不斷進行自我變革,圍繞交易本源,逐步提升金融服務能力,實現金融服務專家的社會角色。」招商銀行區塊鏈團隊負責人侯庭偉說。
「鏈」上跨境清算業務:
區塊鏈技術在金融領域的應用前景被廣泛看好,尤其在跨境支付清算領域的實用性和適配度上都堪稱最優,被譽為「最完美的跨境支付解決方案」,其清算流程安全、高效、快速,可以大幅提升客戶體驗。
2017年12月18日,招商銀行作為代理清算行,完成從香港永隆銀行向永隆銀行深圳分行的人民幣頭寸調撥業務。12月20日,三方又完成了以招商海通貿易有限公司為匯款人,前海蛇口自貿區內海通(深圳)貿易有限公司為收款人的跨境人民幣匯款業務。業務的成功上線標志著區塊鏈技術在該行進一步推向應用,而三方機構的參與意味著該方案已經具備同業間進行推廣合作的基礎。
利用區塊鏈技術「分布式記賬」特點,資金清算信息在「鏈上」同步抵達、全體共享、實時更新,清算效率實現質的飛躍。區塊鏈跨境清算技術著眼於信息的高效與安全傳遞,與傳統支付渠道相互補充,從而避免了區塊鏈電子貨幣所面臨的合法性和監管性問題。
㈢ Fabric 動態增加組織
Fabric 是聯盟鏈,一個 channel 就好比一個聯盟,如果有新的機構需要加入,則必須得到聯盟內的成員的認可。
正是基於這樣的場景,fabric 在為 channel 新增 org 時,會涉及諸多的許可權和證書操作。
為 Channel 動態新增 Org 有以下幾步:
4.將新 org 添加入 channel
5.升級chaincode和背書策略
6.測試是否成功
此文通過 fabric-samples 下的 first-network 樣例為基礎,在其區塊鏈網路上,為通道 mychannel 新增一個 Org3,Org3 包含兩個 peer。
fabric-samples 地址為 https://github.com/hyperledger/fabric-samples , 本文採用其中的 first-network 實驗。
first-network 啟動後,會默認創建 1 個 orderer 節點,4個 peer 節點(其中 2個屬於 org1,2個屬於 org2),並提供一個 cli 用於相關操作。
docker ps 之後輸出如下:
first-network 直接提供了自動化添加的腳本 eyfn.sh。執行 ./eyfn.sh up 即可自動化為 channel 添加 org3。此法因不具擴展性,且不方便理解 fabric,因此不再贅述。以下是執行後的輸出,若成功,會輸出 All GOOD 。
會依據 org3-crypto.yaml 生成,生成後的文件位於 org3-artifacts/crypto-config/ 下
org3-crypto.yaml 文件中 Org3 的配置如下:
㈣ 超級賬本Fabric 2.0版本正式發布,重要更新都在這了
1月31日消息,超級賬本(Hyperledger)聯盟正式發布了其企業分布式賬本(DLT)平台Hyperledger Fabric的2.0版,據悉,該版本增加了幾個主要功能,改進了不同參與者之間的交流方式。
Hyperledger Fabric是超級賬本聯盟的主要項目之一,其作為一個私有或「許可」型區塊鏈網路,目前它主要被用於金融和供應鏈等行業。至今,Fabric已獲得了阿里巴巴、AWS、Azure、網路、谷歌、華為、IBM、甲骨文、騰訊等互聯網巨頭的支持。
而2.0版本的Fabric,則迎來了以下這些改進:
對於Fabric 2.0版本的正式發布,超級賬本聯盟成員們紛紛發表了自己的看法,比如:
據悉,Fabric的智能合約可以有多種架構,它可以用主流語言編程,例如Go、Java和Javascript,此外也可以使用Solidity。
而作為一個面向企業的產品,Fabric的特點是非同步升級,這類似於主流軟體的工作方式。
特別聲明
原文:https://www.hyperledger.org/blog/2020/01/30/welcome-hyperledger-fabric-2-0-enterprise-dlt-for-proction
編譯:隔夜的粥
稿源(譯):巴比特資訊(http://www.8btc.com/article_550790)
免責聲明:本文不代表巴比特立場,且不構成投資建議,請謹慎對待。
㈤ 生何種變化,未來招商銀行在金融服務上有何方向
擁抱銀行3.0 時代,作為中國最勇於創新的行業引領者之一,成立於1987年的招商銀行,依託創新基因,正在推動一場金融科技(Fintech))的變革。
3月初,招商銀行與英國央行、波士頓聯儲等11個組織加入了「超級賬本」,這意味著招行區塊鏈技術應用進入加速度模式。
所謂超級賬本(Hyper ledger),是由Linux基金會在2015年12月份發起,旨在推進區塊鏈最前沿技術發展的開源合作項目,其目標是推動成員共同合作,共建開發區塊鏈基礎平台,創建分布式賬本的公開標准,以便支持各種各樣的商業應用場景,實現虛擬和數字形式的價值交換。
㈥ (三)如何使用cello在fabric上創建屬於自己的區塊鏈
進入cello之前讓我們來看一下當前的docker鏡像
如圖,如果您按照上一篇文章搭建好cello後,會看到這六個正在run的docer鏡像,一切長長,下面讓我們正式開始進入8080埠cello後台
注意如果提示創建失敗,說明我們的docker並未開放外網IP訪問,需要配置如下
修改
為
此操作是放開docker外網IP訪問,然後我們重置docker
此時再去填寫IP+埠2375即可
創建角色後我們登錄8081埠界面
㈦ 超級賬本之——Fabric
目前超級賬本下面有5個並行的項目,Fabric屬於其中較為成熟的一個。這個項目由,來自28個不同組織的159名工程師參與開發。
在Fabric的區塊鏈網路中,有四類節點:MSP,Ordering Node,Endorsing Peer,Commtting Peer
MSP(Membership Service Provider), 這類節點主管區塊鏈網路中其他的節點的授權,准入,踢除。通過給不同節點頒發證書的方式,授予不同類型的節點相應的許可權。
中文可以稱作排序節點。通常在一個網路中至少有一個或多個排序節點,這類節點負責 按照指定的演算法,將交易進行排序,並返回給Committing Peer。其並不關心具體的交易細節。
這類節點的主要負責接收交易請求,驗證這筆交易之後,並做一些預處理之後,並將簽名後的數據傳回給客戶端。
這類節點做是區塊鏈網路中的全節點,它們需要記錄完整的區塊信息,並且驗證每筆交易的正確性,是最終將交易打包進區塊鏈的節點。
結合下面這種圖,看看一筆交易的上鏈過程:
1,首先從客戶端發起一筆交易提交到Endorsing Peer,進行預處理。
2,預處理通過之後,將簽名數據,傳回給客戶端。
3,客戶端發起請求,將收到的簽名數據傳給Ordering Node。
4,Ordering Node對交易進行排序,然後傳給Committing Peer。
5,Committing Peer這里將排序好的交易進行驗證,並打包,通過指定的共識演算法達成一致,形成新的區塊。
6,最後將交易結果返回給客戶端。
6,中間過程的每一步,都伴隨著許可權的驗證。會根據MSP頒發的證書,進行判斷。
㈧ 基於Spring的Fabric區塊鏈Gateway,簡化區塊鏈開發
學習Hyperledger Fabric有一陣子了,從網路搭建、SDK調用到基於Spring的Gateway的開發,一路走來,感覺還是有不少的坑。最近,終於有空,將這些東西整理出來,希望能幫到同路的小夥伴們。詳細文檔地址: https://ecsoya.github.io/fabric/ 。
前一陣子,曾整理過一篇文章,詳細的介紹了Fabirc網路的搭建和部署,小夥伴們請自行查閱:推薦幾個開源項目,教你快速搭建Hyperledger Fabric區塊鏈網路
1. Java SDK: GitHub - hyperledger/fabric-sdk-java
2. Gateway: GitHub - hyperledger/fabric-gateway-java
這是我基於官方的Gateway項目,結合Spring MVC做出的一套框架。主要是將Chaincode的函數調用,包裝成了Spring的服務。
1. 項目地址: GitHub - ecsoya/spring-fabric-gateway
2. 詳細文檔: https://ecsoya.github.io/fabric/pages/gateway.html
3. Maven地址:
一個精簡版的Fabric區塊鏈瀏覽器。
1. 項目地址: GitHub - ecsoya/spring-fabric-gateway
2. 詳細文檔: https://ecsoya.github.io/fabric/pages/explorer.html
3. Maven地址:
以上的項目,包含官方的SDK和Gateway,都離不開 Fabric 網路配置文件的支持。
所謂的配置文件,就是將所有的組織、Peer和其相關的證書,全部配置到一個JSON文件或YAML文件中,方便在項目中讀取。
詳細文檔: https://ecsoya.github.io/fabric/pages/network-config.html
1. 文檔: https://ecsoya.github.io/fabric/pages/demo.html
2. 源碼: GitHub - ecsoya/fabric-demo
㈨ 淺析 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
㈩ 區塊鏈之聯盟鏈(三) 認識Fabric
Fabric 是超級賬本聯盟推出的核心區塊鏈框架,它適合在復雜的企業內和企業間搭建聯盟鏈。根據超級賬本聯盟的目標, Fabric 被建設為一個模塊化的、支持可插拔組件的基礎聯盟鏈框架。;
與以太坊系的Quorum不同,Fabric從一開始就只考慮企業間的應用。其獨有的channel概念,將企業根據業務目的不同以不同的子網連接起來, 每一個子網對應一個channel,而每個channel有自己獨立的區塊鏈。而Quorum很顯然是只有一個公網(所有企業節點都加入進去),企業與企業間的私有業務是通過Private Manager 完成的。
理解channel的最簡單方法就是,將它類比為一個消息服務提供的Topic,實際上Fabic最早就是基於Kafka 的分布式消息服務來實現。
在Fabric網路中,一個企業可以有一個或多個節點加入整個聯盟鏈;一個企業可以加入1個或者多個Channel(子網); 一個節點可以加入1個或者多個channel。每個channel構成一個子網,所以Fabric 是 一種由子網組成的網路。
那麼Fabric是怎麼實現智能合約的執行和完成業務上鏈(將事務結果記錄在區塊鏈里)的呢?
與其它框架不同, Fabric 將整個過程分成了三個階段:
業務背書階段 : 客戶的請求發送的背書節點,通過智能合約完成業務的計算(但不更新狀態),並完成背書;將背書結果返回個客戶端。
業務的排序階段 : 客戶端將背書結果通過Channel被發送到排序節點(orderer),在排序節點完成事務的排序,並打包到block里,最後下發給所有連接到channel的節點。
業務驗證並寫入賬本階段 : 通過Gossip 網路,所有Channel的節點都會接收到新的block,節點會驗證block中的每一個事務,確定是否有效:有效地將會跟新world state,無效的將會標志為「無效」,不會更新World state,但整個block會被完整的加入到帳本中(包括無效的事務)。
根據以上的描述,Fabric 節點實際可以分為 ,普通節點和Order節點:
Peer, 普通節點, 完成背書(包括只能合約的執行)和驗證.
orderer, 排序節點,完成排序。
加入orderer節點的Fabric網路可以被描述如下:
每一個Channel,都定義了所有屬於channel的節點,但是並不需要所有節點都連接到Orderer 節點(節點間可以通過gossip 協議通訊來傳播私有數據或事務).
在區塊鏈中,共識是區塊鏈的基礎。與公有鏈不同,聯盟鏈的共識要求所有加入賬本的事務是確定的、最終的,也就是不可以有分叉,區塊與區塊間的順序是一定的,只存在唯一條鏈。在Fabric 中,這個客觀需求正是由排序實現的,所有的事務將被提交給orderer節點獲得確定的順序,並最終打包成block進入帳本。 Fabric 從1.4.1開始支持基於Raft實現排序服務, 可以認為基於Raft實現共識。
基於RAFT的排序服務相對於早期的Kafka 具有更好的分布性,配置更加簡單,是聯盟鏈里常用的一個常用的達成共識的演算法,Quorum就 默認使用RAFT作為共識層。簡單的說,RAFT是一個leader和follower的模式, 所有加入RAFT網路的節點,任意時候都有一個leader, 只有這個leader有權決定事務的順序,並打包成Block,其它節點只能作為follower提交事務和同步block。
基於FAFT網路,每個企業可以有一個或多個節點參與到Orderer中去。在Frabric中企業間的網路連接可以變化成如下形式:
區塊鏈的使用用戶在乙太網中被稱作EOA(External of Account), EOA的載體是錢包。我們沿用這個概念,來看看Fabric是如何實現用戶和發起事務的。Fabric中EOA是一個CA中心發布的certificate(x.509),一個Certificate代表一個Identity(這與以太坊還是有很大區別的, 以太坊中一個EOA其實是一個hash地址),EOA能夠參與的channel以及被授權的操作是有channel的MSP( Membership Service Provider)決定的(如下圖)。
註:certificate 是一種密碼學上驗證身份的通用做法; certificate包含了個人的信息,公鑰以及發布這個certificate的CA的簽名。驗證方只需要擁有這個CA的證書(包含CA的公鑰),就可以驗證這個簽名是否正確,certificate的內容是否有篡改。簡單的說,通過CA和Certificate,我們可以獲得一個可驗證的的身份和信任鏈。
如上圖,fabric中通要使用Wallet作為EOA的載體,一個Wallet中可以包含多個Identity(x.509 certificate)。 Identity 通過 CA提供的信任鏈來驗證正確性。
驗證了身份之後, Fabric 通過MSP在區塊鏈網路中解決該身份是否代表組織的成員和在組織內具有什麼角色。例如,channel首先會驗證當前用戶Identity是否是有效地身份,然後通過MSP查看其所處的企業和具有的角色,最終確定該用戶是否有權執行操作。
可以說,Fabric的訪問控制是通過MSP來完成的。在每一個需要訪問控制的地方都需要定義一個MSP。 例如,每個channel都定義一個MSP,這個MSP規定了在channel范圍內資源的訪問許可權。 MSP 是Fabric里一個晦澀難懂的概念,也是其賦予企業間安全訪問的基礎。
前文提到, Fabric 將業務處理和上網分成了三個部分, 背書,排序,驗證後加入賬本。
其中背書是Fabric執行智能合約的階段。以太坊中,智能合約是在EVM中執行的,有多種語言支持。 在Fabric,智能合約被稱為chaincode: 一個chaincode 可以理解為是智能合約的容器,可以包含一個或多個智能合約, 不用於EVM, chaincode是在 JVM 或NodeJS中執行。
客戶應用程序通過智能合約來訪問賬本,每一個可訪問的智能合約都被安裝在客戶端可以訪問的節點上,並被定義在channel里。(有隻能合約的節點被稱為背書節點,沒有隻能合約的節點被稱未提交節點,提交節點只維護賬本)
客戶應用提交一個交易請求, 請求到達背書節點, 背書節點首先會驗證客戶的簽名,確保客戶的身份有權執行本次交易,接著執行交易提及的智能合約(chaincode),並生成一個背書響應(或者叫做交易提案,tran-proposal)。這個背書響應中通常包含World state 的讀集合,寫集合, 以及節點對本次交易的簽名。這里與以太坊系聯盟鏈最主要的不同是: 背書階段只模擬交易,並不真正更新交易結果。 而真正更新交易在第三階段完成。背書節點最後將生成的背書響應fanhui給客戶端, 智能合約部分的執行就結束了。
通常一個交易的執行需要多方的簽名,所以客戶端需要將一個交易發送給多個背書節點,這些背書節點的選擇需要滿足背書策略的要求。
下圖是一個包含有客戶、背書節點,提交節點的網路示意圖。
根據Fabric官方的參考文檔,客戶交易的正果過程可使用下圖描述。
如上圖,從1到3,為背書階段,4為排序階段,4.1,4,2, 5為驗證提交階段。 參考 Frabic的節點 概念,可以了解更多在交易細節的概念。
總的來看, Fabric 更專注於企業間,通過上文,可以讓大家對Fabric的基本構成與概念有一個總的了解。 Fabric本身並不神秘,都是使用的現有的企業間的技術。要更好的了解,建議參考閱讀分布式消息系統和企業的安全基礎設施(CA相關)的支持。與以太坊系聯盟鏈實現比較, Fabric 的子網更概念對於復雜企業間應用適應更強,但是其復雜的安全考量,使得運營成本很高,另外,Fabric 使用Certificate做為用戶身份,有很大的局限性,在新的2.0里,Fabric對於此處將有所改變。
下一篇,我們將來看看Sawtooth , 由Inter 提供的區塊鏈框架。
區塊鏈之聯盟鏈(一) 認識以太坊
區塊鏈之聯盟鏈(二) 認識Quotum
區塊鏈之聯盟鏈(三) 認識Fabric
區塊鏈之聯盟鏈(四) 認識Sawtooth
