Fabric v0.6版本與v1.x版本 架構差異很大，故分兩個版本講
Fabric v0.6版本
在Fabric v0.6中采用的共識演算法是PBFT演算法（Practical Byzantine Fault Tolerance）,可以在信任程度較低的場景下避免拜占庭問題，但是由于演算法本身特性限制，n>=3f+1，才能容忍一個拜占庭節點，因此在v0.6版本下，vp節點數量至少是4個，在v0.6版本中，節點角色分為VP(Validating Peer)、NVP(None validating Peer)以及用于簽發證書的Membership節點3種，當然Fabric從第一個版本v0.6.0-preview開始就采用基于docker的運行時環境，為部署減少了許多麻煩，屏蔽了作業系統的差異，當然最主要的一點也許是由于Chaincode的設計機制導致的，整套生產環境的鏈碼的部署和運行都是基于docker的，也許是出于docker穩定以及相對安全的運行環境的考量，Fabric的智能合約設計理論上可以支持任何開發語言(目前支持 Go, Node.js, Java)，只要實作了相應的介面，因為它是基于Peer節點和鏈碼容器的一個雙向通信完成相應的互動的，
Fabric v0.6版本，相對于1.0版本的架構來說，這種設計來說，區塊鏈角色相對對稱，相對于1.0-1.4版本來說，不存在中心化的Kafka的存在，在實際場景中擁有更合理對等的節點設計，
Fabric v1.x
Fabric在1.0版本的時候，架構進行了重構，相比于v0.6版本來說，有了顛覆性的變革，功能模塊進行了結偶，具有了更好的可伸縮性、性能，進行了channel級別的安全隔離，共識演算法可插拔，具備了更高的可操作性，具備了更豐富的功能，給開發者更好的體驗，v0.6版本中的Membership也升級為了一個獨立的Fabric CA專案，
這種設計的優勢在于可以將前后無關聯的交易以及不同Channel中的交易進行并行執行，提高交易的執行速度，在v0.6版本中是無法做到并行執行的，0.6中是統一進行排序打包，然后按序執行交易，即使交易前后是無關的，
Kafka共識
在v1.0-v1.4版本中，生產環境只有基于分布式訊息佇列Kafka的排序打包方式，Orderer作為生產者將交易統一發送至每個通道Channel對應的Topic的Partition當中進行全域統一地排序，同時每個排序節點基于同樣的切塊規則從Kafka中將區塊切下推送Deliver至與之連接的Leader Peer（在網路環境良好的情況下，每個組織只有一個leader），Leader Peer收到區塊后，會將區塊通過Gossip協議廣播至組織內其余節點，
多通道技術（Muti-channel）
一個Fabric網路中能夠運行多個賬本，每個通道間的邏輯相互隔離不受影響，如下圖所示，每種顏色的線條代表一個邏輯上的通道，每個Peer節點可以加入不同的通道，每個通道都擁有獨立的賬本、世界狀態、鏈碼以及Kafka中的Topic，通道間訊息是隔離的，互不影響的，
每個Peer節點可以配置加入到多個不同的通道,不同業務的交易存盤在不同的通道對應的節點中
系統鏈碼
- ESCC：用于為鏈碼執行結果進行背書，
- VSCC：用于對接收到的區塊中的交易進行校驗，
存盤
- File System 即傳統的檔案系統: 區塊存盤部分
- Level DB : 記錄 Block的索引, 世界狀態的存盤
組態檔
Fabric網路在啟動之前，需要提前生成一些用于啟動的組態檔，主要包括MSP相關檔案（msp/）、TLS相關檔案（tls/）、系統通道初始區塊（orderer.genesis.block）、新建應用通道交易檔案（businesschannel.tx）、錨節點配置更新交易檔案Org1MSPanchors.tx和Org2MSPanchors.tx）等，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/239567.html
標籤：區塊鏈