Hyperledger

Hyperledger

Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation, including leaders in finance, banking, IoT, supply chain, manufacturing and technology.

https://www.hyperledger.org/
https://www.hyperledger.org/projects/fabric

Hyperledger fabric

• 模塊化
• 可擴展
• 超安全
  Hyperledger fabric的革命性在於, 他提供了一種組織之間互相信任的機制, 讓全部的數據和信息變化變得可信, 而且這種信任是不須要依賴任何一箇中央機構.
  Hyperledger fabric不是一個普通的軟件或者框架 解決普通問題
  hyperledger fabric是一個全新的解決問題的方式.
  解決的最重要的問題, 如何在不信任的個體和組織中引入信任機制.
  這種信任機制能夠建立更高效的商業模式, 你不須要關心中間人, 信任和安全問題
  一句話描述, hyperledger fabric是基於區塊鏈的企業級分佈式帳本技術,經過智能合約解決多個組織之間的信任問題.
  在案例中, 你會對上面這句話有更加深入的體會.

幾個名詞回顧

Hyperledger:

由linux基金會孵化的區塊鏈技術

Hyperledger Fabirc:

第一個孵化出來的商用的DLT 框架

Hyperledger composer:

一個在DLT框架上建立商業應用的工具

理解hyperledger fabric 1.1的基本概念和軟件架構
能根據企業業務狀況,分析hyperledger fabric的應用場景
熟悉hyperledger fabric的關鍵組件: peer, ordering service, ca和msp
可以創建測試網絡,使用node sdk編寫應用程序
可以使用nodejs編寫鏈碼(智能合約)
可以參與到hyperledger fabric開源項目的討論和開發中

測驗1:

hyperledger是什麼
A. linux基金會孵化重點項目
B. DLT 框架
C. DLT 工具集

在DLT中分佈式存儲的是什麼
A. 數據
B. 帳本(book of records)
C. 技術
D. 資產

資產(assert)表明了什麼
A. 價值
B. 帳本
C. 轉帳信息

資產的變動會生成什麼到DLT中
A. 價值(value)
B. 實體(entry)
C. 轉帳(transaction)

傳統公有鏈可否解決下面的DLT問題 不能

• 隱私
• 機密
• 標準化

hyperledger用獨特的共識協議：有個order（排序）節點進行驗證，

數據完整性和安全性

hyperledger是一個分佈式系統.
沒有單點故障, 沒有單點的信息存放,
每一個節點都保存了所有的數據.
全部的節點都保存了一致的區塊鏈數據, 不可篡改.
每一個節點存放了全部的轉帳記錄(帳本)
假設你的商業模式是使用hyperledger記錄某個資產的全部者,
由於某種緣由, 你錯誤的登記了這個資產的全部人.
在hyperledger裏面你無法把這個錯誤的記錄刪除.
你的作法只能是建立一個新的記錄,標記以前的記錄是錯誤的.
在區塊鏈系統裏面,沒有刪除的概念, 全部對數據的添加和修改都會被記錄.
blockchain 記錄了數據變化的過程.
每一筆transaction都會致使數據的變化, 變化後的狀態叫世界狀態(world state)
由於全部的node節點都保存了全部的transaction, 這些transaction都是一致的,
因此全部的node節點的世界狀態也是一致的.

這個帳本是由密碼學簽名保證.
因此說hyperledger 區塊鏈技術重建信任.

hyperledger爲何特別適合企業級開發(business)

• premissioned network 受權網絡

  access control 訪問控制

• confidential transaction 交易安全

  transaction 是能夠控制可見性的
  

• no cryptocurrency 無數字貨幣

  沒有曠工, 低成本, 驗證操做靈活.

  • programmable 可編程
    chaincode (smart contract 智能合約)

使用hyperledger能夠建立私有鏈, 能夠建立聯盟鏈, 甚至咱們能夠用hyperledger建立公有鏈.
只要node節點處於相同的網絡節點, 他們能夠互相發現, 咱們就可使用hyperledger 來讓他們達成共識協議.
因此hyperledger的應用場景很是普遍, 在任何行業,任何應用場景均可以找到能夠落地的需求.

最後再補充說一下 hyperledger 沒有51%攻擊.沒有挖礦的概念, 由於hyperledger 採用了獨特的共識協議,
每一個共識協議的參與者都是由CA來認證的.

測試題

關於企業級商業化分佈式帳本技術(DLT)特色說法正確的是:（ABCD）
A. 須要是受權網絡
B. 轉帳操做要安全可信
C. 沒有挖礦的概念
D. 可編程

請你設計一套數字貨幣系統,能夠實現轉帳和交易, 從技術角度下面的什麼技術可使用?（AB）
A. 以太坊
B. hyperledger

Assets, chaincode& ledger

• assets : 有價值的東西, 能夠被交易的東西

  json表示 {vinnumber:xxx, owner:zhangsan}

• chaincode

  transaction | business logic

• ledger

  記錄全部的transaction

全部的參與者都保存了ledger

超級帳本：

• 記錄所有的transaction -> 查找交易歷史 快
• 記錄當前 world states -> 查找當前餘額/歸屬者 快

hyperledger如何解決現實生活中的問題

來看一下hyperledger fabric爲何有普遍的應用場景
有兩個公司 A 和 B
交換一些東西(資產) 文檔, 數字資產, 版權,健康記錄,集裝箱,房屋,車輛等... 他們交換一些東西
一般狀況 a和b 互不信任.
兩個公司都有本身的server 本身的服務器.
每週或者每個月對帳. 若是對帳成功, 棒棒噠,
可是在現實生活中,他們歷來都不匹配.
不一樣的軟件,不一樣的技術棧,不一樣的操做人員.總總因素致使數據不匹配.
不匹配不要緊, 對帳啊.
若是你有個供應鏈 , 有10個組織, 之間怎麼對帳,怎麼交流?


傳統解決方案:
共同信任同一個中央機構.
問題:

1. 花錢,好多好多錢
2. 全部機構都要共同信任一個中央機構
3. 最主要的問題, 中央機構出了問題? 這個事情是會發生的. 傳統的技術目前沒辦法解決這個問題。
   避免中央機構出問題, 超級複雜的審批流程.硬件級別訪問控制.操做人員背景調查...數據篡改問題依然存在
   
   新的解決方案:
   全部數據在每一個節點同步, 經過智能合約描述商業流程.
   hyperledger 保證數據實時同步, 全部的node節點保存同步的數據.
   若是有人修改了本身的數據. 全部其餘的party就能馬上發現數據錯誤了.
   即便一個很牛逼的黑客, 若是能把全部node節點的數據都修改了. 但數據會校驗失敗.
   節點就會發現數據錯誤,存在問題.
   數據的更新靠smart contract鏈碼, 鏈碼描述了transaction操做是否能夠執行.
   code is law. 鏈碼執行能夠指定背書策略, 某個機構能夠執行什麼策略.
   smart contract能夠用java或者nodejs,go語言去編寫, 任何負責的業務邏輯均可以用編程語言去描述.
   hyperledger inforce trust between partys. 全部人都確信他們的數據是正確的, 沒有被篡改的數據.
   這就是hyperledger. 一個商業級別 能解決社會問題的, 區塊鏈框架.
   hyperledger 解決了人與人,機構與機構之間的信任問題, 經過chaincode 實現價值轉移.

受權網絡和MSP和CA

business ineract with known entities
以太坊屬於匿名網絡. hpyerledger是實名制的網絡

每一個operation在hyperledger網絡 必須擁有數字簽名. update, 查詢, insert, 或者獲取metadata. 都須要數字簽名.數字簽名遵循x.509標準. fabric ca是一個高質量的工具, 幫助咱們自動生成證書.
ca能夠爲不一樣的用戶生成不一樣的證書, 每一個用戶能夠擁有不一樣的attribute(屬性), 在屬性裏面能夠添加角色,帳戶id,account number等等.
你能夠添加任意的信息.
hyperledger fabric 的chaincode能夠獲取用戶的證書, 根據證書的類型決定某個智能合約是否能夠執行.
好比說只有管理員能夠安裝鏈碼, 普通用戶只能查詢.
fabric ca就是生成ca和建立帳戶的工具. 能夠根據本身的安全策略來管理用戶.
這個證書有效期是多久,分發策略是什麼,均可以經過fabric ca來控制.
fabirc ca支持鏈式繼承, 假如某個證書被黑客攻陷, 上一級別的ca能夠很容易做廢這個證書.
經過ca認證, 咱們能夠查詢每一筆交易的參與者,而且參與者沒法抵賴. 這個特性是密碼學保證的
hyperledger的組件是可插拔的, 你徹底能夠不實用fabric ca,
你能夠本身創建一套認證體系,用於管理用戶.
設置用戶屬性,簽名transaction.
可是fabric ca是一個很是高質量,企業級的組件, 推薦你們使用.
MSP只是一個接口，Fabric-CA是MSP接口的一種實現。

MSP是Membership Service Provider - 是可插拔的接口，它用於支持各類認證體系結構，爲membership orchestration architecture提供抽象層。 MSP抽象提供：

具體的身份格式
用戶證書驗證
用戶證書撤銷
簽名生成和驗證
而 Fabric-CA 用於生成證書和密鑰，以真正的初始化MSP。 Fabric-CA是用於身份管理的MSP接口的默認實現。
msp 定義
who you are 你是誰
which network you are 你在什麼網絡
msp的證書是由fabric ca來頒發的
每一個peer都須要msp的證書
每一個order都須要msp的證書.
如今須要明確的概念是, 只有擁有相同msp的 peer才能夠互相發現 互相通信
MSP ID 是一個名字定義一組證書,說明你是誰你在哪一個網絡.
使用hyperledger fabirc sdk的時候 常常須要指定mspid
因此這個概念要注意.

Node和peer,client,orderer

node是區塊鏈的通信終端
在以太坊中全部的node都是相同的

可是在hyperledger中node分爲三種

• client 實例化transaction的(cli , node sdk, java sdk)
• peer 用來存儲和同步ledger的數據
• orderer 用來排序分發transaction的

一個peer是ledger和blockchain存儲的位置,
是blockchain 的ledger存儲的位置, 在生產環境中有多個peer,
peer決定是否update的ledger. 一個peer會屬於不一樣的channel.
每一個channel都在peer裏面,可是是徹底隔離的.
一個peer能夠控制多個channel
peer背書ledger的更新,最後強調一下peer是ledger和blockchain存儲的位置,
peer互相發現,互相同步

order提供排序服務. 在數據被提交到ledger以前, 必須先交給order服務,
order服務建立block區塊, 這些區塊被簽名和驗證, 全部的transaction都在block裏面
order作好了block以後,把數據發給peer, peer接收到block以後就把數據寫入本身的ledger裏面.

在hyperledger區塊鏈中,挖礦的工做,共識的達成是有orderer節點來完成的,orderer負責避免雙花,生成區塊.

Hyperledger項目實戰--場景分析

省區塊鏈漁政管理系統
在內水、近海從事捕撈業的單位和我的，必須按照捕撈許可證關於做業類型、場所、時限和漁具數量的規定進行做業。不得在禁漁區和禁漁期進行捕撈，不得使用禁用的漁具、捕撈方法和小於規定的最小網目尺寸的網具進行捕撈。急功近利，竭澤而漁，非法捕撈水產品，破壞國家對水產資源的管理制度，危害水產資源的存留和發展。所以，必須依法對非法捕撈水產品的犯罪予以懲罰。

　「僅僅抓非法捕撈,治標不治本。只有立足源頭,從非法捕撈、收購、販賣的每個環節實施‘全鏈條’打擊,才能從根本上遏制非法捕撈犯罪行爲,保護資源環境。」

咱們的目標是使用hyperledger 消除非法、未報告和無管制的捕撈活動。

咱們將使用一個真實世界的例子, 經過hyperledger區塊鏈 實現一個透明清晰的管理 ：漁業供應鏈。
咱們將描述如何改進漁業領域的各個過程, 從源頭，王大壯捕小黃魚，到她的小黃魚在餐廳B結束的過程。
在這段時間裏，咱們將有其餘相關方參與，好比監管機構覈實數據的有效性和小黃魚 捕獲量的可持續性。
咱們將使用hyperledger fabric的框架來跟蹤這個過程的每一部分。如今，有兩個問題你須要注意和思考：
1。網絡中 衆多的參與者，是如何交互的，以及如何進行事務的。
2。王大壯賣給餐館A和餐館B的小黃魚的價格不一樣，如何在保持全部數據在網絡中同步備份, 監管機構和餐館能夠確認裝運小黃魚是可持續和合法來源，但又不須要暴露所有的細節。
讓王大壯和餐館老闆之間能保持足夠的隱私, 這都是咱們須要設計和關心的問題

hyperledger的channel

每一個channel能夠理解成獨立的hyperledger fabric的實例
channel是hyperledger fabirc裏面一個很是重要的概念, 在其餘的區塊鏈系統裏面是沒有channel的概念的
每一個channel能夠理解成獨立的hyperledger fabric的實例, 全部的channel是徹底獨立的.
一個channel不會依賴於其餘的channel,不一樣的channel之間是不會交換數據的.
不一樣的channel會有不一樣的規則,策略,智能合約,他們是徹底獨立的.
channel 能夠理解成private subnet, 有點相似微信的羣.

http://hyperledger-fabric.readthedocs.io/en/release-1.1/fabric_model.html#privacy-through-channels
http://hyperledger-fabric.readthedocs.io/en/release-1.1/channels.html
http://hyperledger-fabric.readthedocs.io/en/release-1.1/channel_update_tutorial.html

舉個例子: 3個parties 漁民王大壯 ,餐館A, 餐館B, 他們都有一些流程
若是他們在同一個channel, 能夠看到所有的數據, 執行chaincode,
可是現實狀況, 王大壯賣給餐館A的小黃魚價格,是私有數據不想讓餐館B看到.
經過王大壯和餐館A建立一個channel, 餐館B就看不到他們的數據.
餐館B甚至都沒法知道 A和c之間有channel的存在
channel控制了誰能夠看到數據,誰能夠操做數據. 固然王大壯建立的channel,漁業主管部門能夠加入進來,對交易進行審計.

你建立hpyerledger fabric網絡的時候, 必定須要建立了一些peer,
peers 默認什麼事情都不作, peer要加入到channel, 纔能有blockchain, update ledger.
peer建立後 要加入到對應的channel. 建立和加入channel的操做很簡單,sdk裏面有工具叫configtx. 咱們實操課會詳細講解.
新的peer加入,必須獲得當前channel裏面的peer的批准.
跟qq羣同樣. 很容易理解. 不是說某個peer一看, 哇,這有一個channel我去加入進去. 不是隨即可以加入的.要知足加入的策略才行.
舉個例子: a和B之間有一個channel, 如今c想加入進去, 只要a和b都贊成,經過工具更新channel的配置文件後, c就能夠加入進去了.
同理, 咱們也能夠把某個peer從channel裏面移除出去. 這就是channel , 道理很簡單,功能卻很強大.
最後再說一下一些技術上的細節,這些細節在咱們實際操做的時候會驗證, 某個peer在加入一個channel的時候,
首先這個channel要是存在的,使用的工具叫configtx. 在建立channel的時候通常都要指定,容許哪些人,哪些peer加入到channel裏面 修改channel配置,須要使用configtxlator工具

一個peer可能加入多個channel
一個channel 可能有多個peer
不一樣的channel是獨立的,數據不會混淆

什麼是chaincode

chaincode 就是智能合約 是應用程序, 是代碼 是你的business logic, 他的做用是用來更新帳本數據的.
sdk發起一個transaction, peer執行這個chaincode
chaincode能夠用nodejs java和go編寫, 在hyperledger裏面,只要想讀取和更新數據就必須經過chaincode的來完成
https://www.npmjs.com/package/fabric-shim
chaincode必須屬於某個channel
由於ledger是屬於某個channel的
chaincode操做的是ledger
當你執行一個操做的時候,你須要出示你的權限(ca), 明確在哪一個channel, 執行哪一個chaincode, 執行chaincode的什麼函數, 函數的參數是什麼.
在一個channel裏面能夠定義一個chaincode,也能夠定義多個chaincode, 看大家公司的業務邏輯.
chaincode須要在某個channel的 每一個peer上安裝
若是某個channel裏面有3個peer , 你只在2個peer上安裝chaincode, 最後會致使第三個peer的數據和其餘peer的數據不一致.
那第三個peer就會變成一個無效節點,沒法搭乘共識,沒法獲取數據.

Chaincode的生命週期

chaincode須要先安裝, 而後必需要實例化, 實例化chaincode會啓動docker容器. 在這個容器裏面運行chaincode.

• 安裝 install
• 實例化 init
• 調用 invoke

chaincode的背書策略

http://hyperledger-fabric.readthedocs.io/en/release-1.1/endorsement-policies.html
實例化chaincode須要指定背書策略. 背書策略是hpyerledger中一個很強大的功能.
是全部的peer都要驗證,仍是大多數peer贊成, 仍是至少一個peer贊成, 經過and或者or 這樣的關鍵字定義背書策略.
假設你的業務有10個不一樣的chaincode, 就能夠有10個不一樣的背書策略. 有的代碼要全部的節點贊成才能夠執行,
有的邏輯須要至少有一個節點贊成就能夠執行. 這樣就很是很是的靈活.

chaincode總結

• 每一個peer能夠屬於多個channel
• 每一個channel有獨立的ledger
• 每一個channel能夠有一個或者多個的chaincode
• 每一個chaincode能夠有不一樣的背書策略

這種可擴展,靈活的設計,讓hyperledger能夠適用於任何業務場景.

hyperledger的工做流程

這一講,咱們講解一下hyperledger的工做流程, 背書和模擬執行.
這個圖第一眼看起來有點複雜,可是我解釋完畢後, 你必定會以爲很是容易理解, 而且整個過程很是具備邏輯性.
這其實是最精簡的一個案例, 一個組織, 3個peer節點, 在同一個網絡, 同一個channel上.
sdk , nodejs java go , 命令行cli, 什麼sdk都行.
你如今要執行一個更新帳本的操做, 例如要修改捕撈出來的小黃魚的歸屬者.
這個更新叫 transaction proposal , 一個修改帳本的提案, 我想修改peer節點記錄的小黃魚的歸屬者.
peer 先接收到 proposal, 會模擬執行. 模擬執行. 拿着當前的versoion的ledger去模擬執行. 例如1.0版本帳單 小黃魚歸王大壯
要注意的是每個peer都有一個ledger(帳本)的拷貝. 每一個peer都有一份拷貝.這個數據在peer節點的硬盤裏面存放着.
模擬執行會產生一個讀寫集(read write set),具體讀寫集的內容爲, 某個key要被update成什麼, update後的version是什麼
2.0版本小黃魚歸xxx. 這個模擬操做是由一個或者多個peer都會模擬執行的.
每一個peer會把模擬執行的結果 endorsement response 簽名, 最後返回發送給sdk
sdk收集全部的背書響應. invocation request,發送給orderer節點
order檢查簽名,背書策略,排序, 若是沒有問題,就發送invocation.
背書策略很是重要,不一樣的鏈碼可能對應不一樣的背書策略, 舉個例子,假如背書策略是全部的節點都要贊成.
就須要檢查是否有每一個節點的背書, 若是背書策略是隻要有一個贊成, 那麼只須要收集到一個背書便可.
不合法的invocation request會被拒絕, 不會更新ledger的狀態,(世界狀態,讀寫集)
可是transaction會被記錄到blockchain. 方便之後排查檢查問題. 專業術語叫審計. 方便之後審計.
ordering service還須要檢查全部的背書對應的讀寫集是否同樣, 只有同樣的纔會被接受.
咱們想一下, 正常狀況下全部的peer都保存了同一份帳本的拷貝,執行相同的chaincode智能合約, 那麼他們最終執行出來的結果也應該是一致的
若是數據不一致, 那麼orderer節點就有理由認爲,某個peer節點數據沒有同步,或者peer節點被非法篡改. 我不能更新ledger的數據,
我要把此次狀況記錄到blockchain.
若是數據一致, 那orderer服務就會發起invoke更新請求, 全部的節點都收到請求,更新本身的ledger狀態.
全部的peer數據仍是保持一致的. 由於他們原始數據一致, 又都更新了相同的讀寫集.
另外orderer節點還擔當了排序的角色, 由於在同一時刻,可能有來自於sdk的兩個更新ledger的提案請求.
前後順序必定要排好.舉個例子, 第一個proposal是張三花10塊錢買大米, 在這徹底的同一時刻,
張三花10塊錢買玉米的proposal也發了出來, 可是張三隻有10塊錢,
orderer節點排序後, 第一個買大米的操做是合法的, 可是第二個買玉米的操做就不合法了.
由於張三沒有這麼多錢了. 這也是hyperledger如何解決雙花問題.
在生產環境中, 通常會有多個組織, 多個組織之間的orderer節點 互相同步.
若是幾個節點數據不一樣步, 就不會更新數據, 保證了order節點不會被攻破.
黑客要同時攻擊兩個或者多個order是很是困難的.
這是一個很是很是強的安全模型.
理解了上面的流程, 你就能回答不少用sdk開發的時候疑惑的問題.
爲何我要用sdk發送提案,接收一些返回數據.
爲何我要驗證一些認證相關的信息.
爲何讀寫集的修改這麼複雜
爲何orderer服務 排序的結果 跟我期待的不同
這些問題, 遇到了你們必定要多想一想流程 本身思考.
好了,最後再回顧一下流程:

1. sdk發送transaction proposal給一個或者多個peer
2. peer模擬執行, 給出模擬執行的結果,讀寫集,key的version, 這些信息反饋給sdk
3. sdk收集背書信息,帶着簽名,發給orderer節點
4. orderer節點,檢查數字簽名,檢查每一個peer背書的讀寫集是否一致.排序.若是沒有問題,就發出invocation 讓每一個peer去apply新的讀寫集.
   最後強調幾個細節:
   orderer節點不是馬上處理每一個invocation request.
   在orderer節點內部有一個消息隊列 , 咱們能夠控制這個隊列,控制隊列的數量,容量大小,提交週期等參數
   經過調整參數調整hyperledger的處理效率.這些是hyperledger開發中比較高級的話題,
   關於性能調優, 後面咱們會詳細討論.

術語回顧

channel

數據通道, 能夠理解成獨立的hyperledger fabric的實例
不一樣Channel的數據彼此徹底隔離
Channel能夠保證區塊鏈上數據的隱私問題
Channel相似微信羣組

ChainCode

鏈碼
智能合約
Chaincode定義了business logic
Ledger的變化只能經過調用chaincode來完成
在區塊鏈系統裏面code is law

ledger

帳本
Ledger記錄的是當前的世界狀態(world state)
Ledger還鏈式記錄了全部的歷史世界狀態
在hyperledger裏面,ledger是一個具備受權管理的共享帳本系統
從底層設計上保證數據的一致性,有效性,不可篡改性

network

由peer組成network
在同一network的peer,實時同步記帳,保證ledger數據的一致性

ordering service

排序服務
排序,驗證transaction, 最終提交invocation,把數據寫入peer的ledger

world state

世界狀態
當前ledger裏面存放的數據
Key和value 以version形式存在
當前實現有couchdb和leveldb

membership service provider

管理peer的身份和訪問許可

業務分析

漁民王大壯

靠打漁,賣魚爲生
須要加入到區塊鏈網絡,把魚賣給餐館
漁政監管部門也須要加入區塊鏈網絡,監管打漁的合法性
王大壯把捕魚的數據加入到區塊鏈網絡,餐館和漁政部門都可訪問審計數據

數據

每次捕獲後，王大壯須要記錄捕撈的信息
包括
惟一的ID號
捕獲的位置
捕獲的時間
捕撈重量
捕魚船信息
捕撈人信息
爲了簡單起見，咱們只設計這六個數據屬性。然而，在實際應用中，更多的細節須要被記錄下來。氣溫, 捕撈深度, 做業設備類型,漁網大小,捕撈區域水源水質分析, 等等..

數據定義

因爲ledger的世界狀態是key/value的形式存在
因此數據適合採用json方式表示
應用程序的開發適合採用nodejs開發

var caught = {    id: '0001',    holder: '王大壯',    location: {        latitude: '41.40238',        longitude: '22.17032'    },    when: '201804161323',    weight: '58kg',    vessel: '奮進號38A'};

消費者

餐館A
餐館B

消費者痛點分析

餐館但願能買到低價格,優質的小黃魚
餐館不但願買到非法捕撈的小黃魚(避免嚴厲的監管處罰)
餐館不肯定市場上的小黃魚是否合法,是否新鮮
王大壯但願把本身合法捕撈的小黃魚,以合適的價格銷售出去
監管部門須要瞭解小黃魚的捕撈量和銷售數量

信任問題

餐館不信任王大壯
監管部門不信任 餐館
監管部門不信任 王大壯
王大壯的隱私問題

隱私業務分析

價格是任何商業模型裏面很是重要的一環. 是很是很是敏感的隱私. 餐館A有多是王大壯的新客戶, 王大壯的營銷策略是, 打算用較低的價格贏得新客戶, 一旦客戶穩定後再去漲價.
但這個優惠的價格是不該該被餐館B的老闆看到的.
在傳統的公有區塊鏈裏面，一旦王大壯和餐館A完成了交易，整個網絡能夠查看此協議的細節，18.5元一斤的小黃魚全部的節點均可以看到。
你能夠想象，餐館B老闆看到這個價格後的心情. 必定會有 一萬隻草泥馬在遼闊的草原上奔跑.

漁政監管需求分析

　「僅僅抓非法捕撈,治標不治本。只有立足源頭,從非法捕撈、收購、販賣的每個環節實施‘全鏈條’打擊,才能從根本上遏制非法捕撈犯罪行爲,保護資源環境。」
監管部門須要具備權限,能夠驗證查看區塊鏈ledger的每一條記錄
監管部門應該只具備查詢ledger的權限.
監管部門經過查詢捕魚的重量和位置來肯定漁民是否合法捕撈
監管部門應該具備從blockchain網絡中添加或者刪除漁民的權限
若是王大壯的捕撈是非法的, 超過許可的. 監管部門能夠把王大壯從hpyerledger fabirc區塊鏈網絡裏面移除, 那麼王大壯就失去了賣魚的權利

業務覆盤

漁民王大壯,捕獲小黃魚,使用hyperledger fabirc的sdk接口調用chaincode把捕魚數據寫入區塊鏈網絡 . 整個過程是,首先sdk發出transaction申請, 每一個peer節點模擬執行,把背書結果反饋給sdk, sdk收集到足夠的背書後,把請求發給ordering節點, ordering節點排序後,把數據生成block. Block廣播給每一個peer節點,每一個節點驗證後, 最後更新本身ledger的數據. 監管部門在小黃魚的供應鏈裏面, 每筆交易都被記錄, 監管部門能夠查詢交易的細節,可是監管部門無權查詢交易的價格. 由於監管部門不在具體交易的channel裏面. 漁民王大壯分別和餐館A 餐館B約定了不一樣的價格, 交易在不一樣的channel裏面, 紫色區塊鏈裏面的交易價格爲18.5元/斤 紅色區塊鏈裏面的價格爲28.5元/斤 不一樣channel彼此隔離,充分保證了交易雙方的隱私