hyperledger day01

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 是Linux 基金會Hyperledger保護傘項目中的第一個開源項目, 由IBM發(fā)起可創(chuàng)建.
    1.0版本在2017年7月發(fā)布, 1.1版本在2018年3月發(fā)布. 我們的課程就是基于hyperledger1.1版本介紹.
    Hpyerledger fabric項目是一個 模塊化, 可擴展, 超安全的企業(yè)級項目
    特別適用于以下的企業(yè)業(yè)務: 制造業(yè), 農(nóng)業(yè), 醫(yī)療健康 和 資本市場的各種證券業(yè)務
    Hyperledger fabric的革命性在于, 他提供了一種組織之間互相信任的機制, 讓所有的數(shù)據(jù)和信息變化變得可信, 并且這種信任是不需要依賴任何一個中央機構.
    Hyperledger fabric不是一個普通的軟件或者框架 解決普通問題
    hyperledger fabric是一個全新的解決問題的方式.
    解決的最重要的問題, 如何在不信任的個體和組織中引入信任機制.
    這種信任機制可以創(chuàng)建更高效的商業(yè)模式, 你不需要關心中間人, 信任和安全問題
    一句話描述, hyperledger fabric是基于區(qū)塊鏈的企業(yè)級分布式賬本技術,通過智能合約解決多個組織之間的信任問題.
    相信隨著課程的深入, 在案例中, 你會對上面這句話有更加深刻的體會.

hyperledger參與人和合作伙伴

埃森哲、美國運通军洼、思科、三星演怎、日立匕争、IBM、Intel爷耀、J.P.Morgan、NEC 甲骨文跑杭、
百度、小米窄做、招商銀行、民生銀行掏颊、中信、華為


重要人物

張旭陽,Hyperledger治理委員會成員, 百度金融副總裁


蔡棟(Charles Cai),Hyperledger治理委員會成員晰奖,萬達科技集團首席架構師。


楊保華蛆楞,Hyperledger技術指導委員會成員裆悄,甲骨文首席架構師。

從參與者陣容上看,這是一個非常具有前景的框架.更多關于hyperledger的內(nèi)容, 大家可以關注傳智播客智能物聯(lián)網(wǎng)+區(qū)塊鏈學院

幾個名詞回顧

Hyperledger:

由linux基金會孵化的區(qū)塊鏈技術

Hyperledger Fabirc:

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

Hyperledger composer:

一個在DLT框架上創(chuàng)建商業(yè)應用的工具

課程介紹

功能強大. 技術復雜, 概念繁多. 學習曲線非常陡峭.
課程的目的是幫大家降低學習曲線.

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

測驗1:

hyperledger是什么
A. linux基金會孵化重點項目
B. DLT 框架
C. DLT 工具集
D. 以上都是

在DLT中分布式存儲的是什么
A. 數(shù)據(jù)
B. 賬本(book of records)
C. 技術
D. 資產(chǎn)

資產(chǎn)(assert)代表了什么
A. 價值
B. 賬本
C. 轉(zhuǎn)賬信息

資產(chǎn)的變更會生成什么到DLT中
A. 價值(value)
B. 實體(entry)
C. 轉(zhuǎn)賬(transaction)

傳統(tǒng)公有鏈能否解決下面的DLT問題

  • 隱私
  • 機密
  • 標準化

hyperledger重建信任


hyperledger是基于區(qū)塊鏈的, 但hyperledger不是數(shù)字貨幣,
目前大多數(shù)數(shù)字貨幣是區(qū)塊鏈實現(xiàn)的, hpyerledger是區(qū)塊鏈技術但是不是數(shù)字貨幣.
當然你可以使用hyperledger創(chuàng)建一個你自己的數(shù)字貨幣.
在hpyerledger里面沒有挖礦的概念
hyperledger用獨特的共識協(xié)議, 讓挖礦不再是必需.

交易速度

比特幣7筆/秒 以太坊幾百筆/分鐘
hyperledger 50萬筆/分鐘
如果挖礦 挖這些交易, 很多硬件, 很不環(huán)保...

數(shù)據(jù)完整性和安全性

hyperledger是一個分布式系統(tǒng).
沒有單點故障, 沒有單點的信息存放,
每個節(jié)點都保存了全部的數(shù)據(jù).
所有的節(jié)點都保存了一致的區(qū)塊鏈數(shù)據(jù), 不可篡改.
每個節(jié)點存放了所有的轉(zhuǎn)賬記錄(賬本)
假設你的商業(yè)模式是使用hyperledger記錄某個資產(chǎn)的所有者,
因為某種原因, 你錯誤的登記了這個資產(chǎn)的所有人.
在hyperledger里面你沒法把這個錯誤的記錄刪除.
你的做法只能是創(chuàng)建一個新的記錄,標記之前的記錄是錯誤的.
在區(qū)塊鏈系統(tǒng)里面,沒有刪除的概念, 所有對數(shù)據(jù)的添加和修改都會被記錄.
blockchain 記錄了數(shù)據(jù)變化的過程.
每一筆transaction都會導致數(shù)據(jù)的變化, 變化后的狀態(tài)叫世界狀態(tài)(world state)
因為所有的node節(jié)點都保存了所有的transaction, 這些transaction都是一致的,
所以所有的node節(jié)點的世界狀態(tài)也是一致的.

這個賬本是由密碼學簽名保證.
所以說hyperledger 區(qū)塊鏈技術重建信任.

hyperledger為什么特別適合企業(yè)級開發(fā)(business)

  • premissioned network 授權網(wǎng)絡

access control

  • confidential transaction 交易安全

transaction 是可以控制可見性的


  • no cryptocurrency 無數(shù)字貨幣

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

  • programmable 可編程

chaincode (smart contract 智能合約)

使用hyperledger可以創(chuàng)建私有鏈, 可以創(chuàng)建聯(lián)盟鏈, 甚至我們可以用hyperledger創(chuàng)建公有鏈.
只要node節(jié)點處于相同的網(wǎng)絡節(jié)點, 他們可以互相發(fā)現(xiàn), 我們就可以使用hyperledger 來讓他們達成共識協(xié)議.
所以hyperledger的應用場景非常廣泛, 在任何行業(yè),任何應用場景都可以找到可以落地的需求.

最后再補充說一下 hyperledger 沒有51%攻擊.沒有挖礦的概念, 因為hyperledger 采用了獨特的共識協(xié)議,
每個共識協(xié)議的參與者都是由CA來認證的.

測試題

關于企業(yè)級商業(yè)化分布式賬本技術(DLT)特點說法正確的是:
A. 需要是授權網(wǎng)絡
B. 轉(zhuǎn)賬操作要安全可信
C. 沒有挖礦的概念
D. 可編程

請你設計一套數(shù)字貨幣系統(tǒng),可以實現(xiàn)轉(zhuǎn)賬和交易, 從技術角度下面的什么技術可以使用?
A. 以太坊
B. hyperledger

Assets, chaincode& ledger

  • assets : 有價值的東西, 可以被交易的東西

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

  • chaincode

transaction | business logic

  • ledger

記錄所有的transaction

所有的參與者都保存了ledger


hyperledger如何解決現(xiàn)實生活中的問題


來看一下hyperledger fabric為什么有廣泛的應用場景
有兩個公司 A 和 B
交換一些東西(資產(chǎn)) 文檔, 數(shù)字資產(chǎn), 版權,健康記錄,集裝箱,房屋,車輛等... 他們交換一些東西
通常情況 a和b 互不信任.
兩個公司都有自己的server 自己的服務器.
每周或者每月對賬. 如果對賬成功, 棒棒噠,
但是在現(xiàn)實生活中,他們從來都不匹配.
不同的軟件,不同的技術棧,不同的操作人員.總總因素導致數(shù)據(jù)不匹配.
不匹配沒關系, 對賬啊.
如果你有個供應鏈 , 有10個組織, 之間怎么對賬,怎么交流?




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

  1. 花錢,好多好多錢
  2. 所有機構都要共同信任一個中央機構
  3. 最主要的問題, 中央機構出了問題? 這個事情是會發(fā)生的. 傳統(tǒng)的技術目前沒辦法解決這個問題伴奥。
    避免中央機構出問題, 超級復雜的審批流程.硬件級別訪問控制.操作人員背景調(diào)查...數(shù)據(jù)篡改問題依然存在



    新的解決方案:
    所有數(shù)據(jù)在每個節(jié)點同步, 通過智能合約描述商業(yè)流程.
    hyperledger 保證數(shù)據(jù)實時同步, 所有的node節(jié)點保存同步的數(shù)據(jù).
    如果有人修改了自己的數(shù)據(jù). 所有其他的party就能立刻發(fā)現(xiàn)數(shù)據(jù)錯誤了.
    即使一個很牛逼的黑客, 如果能把所有node節(jié)點的數(shù)據(jù)都修改了. 但數(shù)據(jù)會校驗失敗.
    節(jié)點就會發(fā)現(xiàn)數(shù)據(jù)錯誤,存在問題.
    數(shù)據(jù)的更新靠smart contract鏈碼, 鏈碼描述了transaction操作是否可以執(zhí)行.
    code is law. 鏈碼執(zhí)行可以指定背書策略, 某個機構可以執(zhí)行什么策略.
    smart contract可以用java或者nodejs,go語言去編寫, 任何負責的業(yè)務邏輯都可以用編程語言去描述.
    hyperledger inforce trust between partys. 所有人都確信他們的數(shù)據(jù)是正確的, 沒有被篡改的數(shù)據(jù).
    這就是hyperledger. 一個商業(yè)級別 能解決社會問題的, 區(qū)塊鏈框架.
    hyperledger 解決了人與人,機構與機構之間的信任問題, 通過chaincode 實現(xiàn)價值轉(zhuǎn)移.

授權網(wǎng)絡和MSP和CA

business ineract with known entities
以太坊屬于匿名網(wǎng)絡. hpyerledger是實名制的網(wǎng)絡


每個operation在hyperledger網(wǎng)絡 必須擁有數(shù)字簽名. update, 查詢, insert, 或者獲取metadata. 都需要數(shù)字簽名.數(shù)字簽名遵循x.509標準. fabric ca是一個高質(zhì)量的工具, 幫助我們自動生成證書.
ca可以為不同的用戶生成不同的證書, 每個用戶可以擁有不同的attribute(屬性), 在屬性里面可以添加角色,賬戶id,account number等等.
你可以添加任意的信息.
hyperledger fabric 的chaincode可以獲取用戶的證書, 根據(jù)證書的類型決定某個智能合約是否可以執(zhí)行.
比如說只有管理員可以安裝鏈碼, 普通用戶只能查詢.
fabric ca就是生成ca和創(chuàng)建賬戶的工具. 可以根據(jù)自己的安全策略來管理用戶.
這個證書有效期是多久,分發(fā)策略是什么,都可以通過fabric ca來控制.
fabirc ca支持鏈式繼承, 假如某個證書被黑客攻陷, 上一級別的ca可以很容易作廢這個證書.
通過ca認證, 我們可以查詢每一筆交易的參與者,并且參與者無法抵賴. 這個特性是密碼學保證的
hyperledger的組件是可插拔的, 你完全可以不實用fabric ca,
你可以自己建立一套認證體系,用于管理用戶.
設置用戶屬性,簽名transaction.
但是fabric ca是一個非常高質(zhì)量,企業(yè)級的組件, 推薦大家使用.
MSP只是一個接口尼啡,F(xiàn)abric-CA是MSP接口的一種實現(xiàn)。

MSP是Membership Service Provider - 是可插拔的接口书聚,它用于支持各種認證體系結(jié)構,為membership orchestration architecture提供抽象層驯杜。 MSP抽象提供:

具體的身份格式
用戶證書驗證
用戶證書撤銷
簽名生成和驗證
而 Fabric-CA 用于生成證書和密鑰滚局,以真正的初始化MSP藤肢。 Fabric-CA是用于身份管理的MSP接口的默認實現(xiàn)。
msp 定義
who you are 你是誰
which network you are 你在什么網(wǎng)絡
msp的證書是由fabric ca來頒發(fā)的
每個peer都需要msp的證書
每個order都需要msp的證書.
我們實戰(zhàn)的課程會具體的來帶著大家操作.
現(xiàn)在需要明確的概念是, 只有擁有相同msp的 peer才可以互相發(fā)現(xiàn) 互相通訊
MSP ID 是一個名字定義一組證書,說明你是誰你在哪個網(wǎng)絡.
使用hyperledger fabirc sdk的時候 經(jīng)常需要指定mspid
所以這個概念要注意.

Node和peer,client,orderer

node是區(qū)塊鏈的通訊終端
在以太坊中所有的node都是相同的


但是在hyperledger中node分為三種

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

一個peer是ledger和blockchain存儲的位置,
是blockchain 的ledger存儲的位置, 在生產(chǎn)環(huán)境中有多個peer,
peer決定是否update的ledger. 一個peer會屬于不同的channel.
每個channel都在peer里面,但是是完全隔離的.
一個peer可以控制多個channel
peer背書ledger的更新,最后強調(diào)一下peer是ledger和blockchain存儲的位置,
peer互相發(fā)現(xiàn),互相同步

order提供排序服務. 在數(shù)據(jù)被提交到ledger之前, 必須先交給order服務,
order服務創(chuàng)建block區(qū)塊, 這些區(qū)塊被簽名和驗證, 所有的transaction都在block里面
order做好了block之后,把數(shù)據(jù)發(fā)給peer, peer接收到block之后就把數(shù)據(jù)寫入自己的ledger里面.


在hyperledger區(qū)塊鏈中,挖礦的工作,共識的達成是有orderer節(jié)點來完成的,orderer負責避免雙花,生成區(qū)塊.

Hyperledger項目實戰(zhàn)--場景分析

省區(qū)塊鏈漁政管理系統(tǒng)
在內(nèi)水灭贷、近海從事捕撈業(yè)的單位和個人仗岖,必須按照捕撈許可證關于作業(yè)類型、場所檩电、時限和漁具數(shù)量的規(guī)定進行作業(yè)俐末。不得在禁漁區(qū)和禁漁期進行捕撈,不得使用禁用的漁具烹卒、捕撈方法和小于規(guī)定的最小網(wǎng)目尺寸的網(wǎng)具進行捕撈。急功近利坠非,竭澤而漁炎码,非法捕撈水產(chǎn)品攒菠,破壞國家對水產(chǎn)資源的管理制度,危害水產(chǎn)資源的存留和發(fā)展凹炸。因此啤它,必須依法對非法捕撈水產(chǎn)品的犯罪予以懲罰。


“僅僅抓非法捕撈,治標不治本。只有立足源頭,從非法捕撈台妆、收購频丘、販賣的每一個環(huán)節(jié)實施‘全鏈條’打擊,才能從根本上遏制非法捕撈犯罪行為,保護資源環(huán)境迂卢“凶常”

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

我們將使用一個真實世界的例子, 通過hyperledger區(qū)塊鏈 實現(xiàn)一個透明清晰的管理 :漁業(yè)供應鏈。
我們將描述如何改進漁業(yè)領域的各個過程, 從源頭逮光,王大壯捕小黃魚,到她的小黃魚在餐廳B結(jié)束的過程副女。
在這段時間里碑幅,我們將有其他相關方參與沟涨,比如監(jiān)管機構核實數(shù)據(jù)的有效性和小黃魚 捕獲量的可持續(xù)性。
我們將使用hyperledger fabric的框架來跟蹤這個過程的每一部分【骼耍現(xiàn)在睛竣,有兩個問題你需要注意和思考:
1射沟。網(wǎng)絡中 眾多的參與者,是如何交互的挥转,以及如何進行事務的准潭。
2刑然。王大壯賣給餐館A和餐館B的小黃魚的價格不同,如何在保持所有數(shù)據(jù)在網(wǎng)絡中同步備份, 監(jiān)管機構和餐館可以確認裝運小黃魚是可持續(xù)和合法來源择镇,但又不需要暴露全部的細節(jié)。
讓王大壯和餐館老板之間能保持足夠的隱私, 這都是我們需要設計和關心的問題

hyperledger的channel

每個channel可以理解成獨立的hyperledger fabric的實例
channel是hyperledger fabirc里面一個非常重要的概念, 在其他的區(qū)塊鏈系統(tǒng)里面是沒有channel的概念的
每個channel可以理解成獨立的hyperledger fabric的實例, 所有的channel是完全獨立的.
一個channel不會依賴于其他的channel,不同的channel之間是不會交換數(shù)據(jù)的.
不同的channel會有不同的規(guī)則,策略,智能合約,他們是完全獨立的.
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, 可以看到全部的數(shù)據(jù), 執(zhí)行chaincode,
但是現(xiàn)實情況, 王大壯賣給餐館A的小黃魚價格,是私有數(shù)據(jù)不想讓餐館B看到.
通過王大壯和餐館A創(chuàng)建一個channel, 餐館B就看不到他們的數(shù)據(jù).
餐館B甚至都無法知道 A和c之間有channel的存在
channel控制了誰可以看到數(shù)據(jù),誰可以操作數(shù)據(jù). 當然王大壯創(chuàng)建的channel,漁業(yè)主管部門可以加入進來,對交易進行審計.


你創(chuàng)建hpyerledger fabric網(wǎng)絡的時候, 一定需要創(chuàng)建了一些peer,
peers 默認什么事情都不做, peer要加入到channel, 才能有blockchain, update ledger.
peer創(chuàng)建后 要加入到對應的channel. 創(chuàng)建和加入channel的操作很簡單,sdk里面有工具叫configtx. 我們實操課會詳細講解.
新的peer加入,必須得到當前channel里面的peer的批準.
跟qq群一樣. 很容易理解. 不是說某個peer一看, 哇,這有一個channel我去加入進去. 不是隨便可以加入的.要滿足加入的策略才行.
舉個例子: a和B之間有一個channel, 現(xiàn)在c想加入進去, 只要a和b都同意,通過工具更新channel的配置文件后, c就可以加入進去了.
同理, 我們也可以把某個peer從channel里面移除出去. 這就是channel , 道理很簡單,功能卻很強大.
最后再說一下一些技術上的細節(jié),這些細節(jié)在我們實際操作的時候會驗證, 某個peer在加入一個channel的時候,
首先這個channel要是存在的,使用的工具叫configtx. 在創(chuàng)建channel的時候一般都要指定,允許哪些人,哪些peer加入到channel里面 修改channel配置,需要使用configtxlator工具

一個peer可能加入多個channel
一個channel 可能有多個peer
不同的channel是獨立的,數(shù)據(jù)不會混淆


什么是chaincode

chaincode 就是智能合約 是應用程序, 是代碼 是你的business logic, 他的作用是用來更新賬本數(shù)據(jù)的.
sdk發(fā)起一個transaction, peer執(zhí)行這個chaincode
chaincode可以用nodejs java和go編寫, 在hyperledger里面,只要想讀取和更新數(shù)據(jù)就必須通過chaincode的來完成
https://www.npmjs.com/package/fabric-shim
chaincode必須屬于某個channel
因為ledger是屬于某個channel的
chaincode操作的是ledger
當你執(zhí)行一個操作的時候,你需要出示你的權限(ca), 明確在哪個channel, 執(zhí)行哪個chaincode, 執(zhí)行chaincode的什么函數(shù), 函數(shù)的參數(shù)是什么.
在一個channel里面可以定義一個chaincode,也可以定義多個chaincode, 看你們公司的業(yè)務邏輯.
chaincode需要在某個channel的 每個peer上安裝
如果某個channel里面有3個peer , 你只在2個peer上安裝chaincode, 最后會導致第三個peer的數(shù)據(jù)和其他peer的數(shù)據(jù)不一致.
那第三個peer就會變成一個無效節(jié)點,無法搭乘共識,無法獲取數(shù)據(jù).

Chaincode的生命周期

chaincode需要先安裝, 然后必須要實例化, 實例化chaincode會啟動docker容器. 在這個容器里面運行chaincode.

  • 安裝 install
  • 實例化 init
  • 調(diào)用 invoke

chaincode的背書策略

http://hyperledger-fabric.readthedocs.io/en/release-1.1/endorsement-policies.html
實例化chaincode需要指定背書策略. 背書策略是hpyerledger中一個很強大的功能.
是所有的peer都要驗證,還是大多數(shù)peer同意, 還是至少一個peer同意, 通過and或者or 這樣的關鍵字定義背書策略.
假設你的業(yè)務有10個不同的chaincode, 就可以有10個不同的背書策略. 有的代碼要所有的節(jié)點同意才可以執(zhí)行,
有的邏輯需要至少有一個節(jié)點同意就可以執(zhí)行. 這樣就非常非常的靈活.

chaincode總結(jié)

  • 每個peer可以屬于多個channel
  • 每個channel有獨立的ledger
  • 每個channel可以有一個或者多個的chaincode
  • 每個chaincode可以有不同的背書策略

這種可擴展,靈活的設計,讓hyperledger可以適用于任何業(yè)務場景.

hyperledger的工作流程

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

  1. sdk發(fā)送transaction proposal給一個或者多個peer
  2. peer模擬執(zhí)行, 給出模擬執(zhí)行的結(jié)果,讀寫集,key的version, 這些信息反饋給sdk
  3. sdk收集背書信息,帶著簽名,發(fā)給orderer節(jié)點
  4. orderer節(jié)點,檢查數(shù)字簽名,檢查每個peer背書的讀寫集是否一致.排序.如果沒有問題,就發(fā)出invocation 讓每個peer去apply新的讀寫集.
    最后強調(diào)幾個細節(jié):
    orderer節(jié)點不是立刻處理每個invocation request.
    在orderer節(jié)點內(nèi)部有一個消息隊列 , 我們可以控制這個隊列,控制隊列的數(shù)量,容量大小,提交周期等參數(shù)
    通過調(diào)整參數(shù)調(diào)整hyperledger的處理效率.這些是hyperledger開發(fā)中比較高級的話題,
    關于性能調(diào)優(yōu), 后面我們會詳細討論.

術語回顧

channel

數(shù)據(jù)通道, 可以理解成獨立的hyperledger fabric的實例
不同Channel的數(shù)據(jù)彼此完全隔離
Channel可以保證區(qū)塊鏈上數(shù)據(jù)的隱私問題
Channel類似微信群組

ChainCode

鏈碼
智能合約
Chaincode定義了business logic
Ledger的變化只能通過調(diào)用chaincode來完成
在區(qū)塊鏈系統(tǒng)里面code is law

ledger

賬本
Ledger記錄的是當前的世界狀態(tài)(world state)
Ledger還鏈式記錄了所有的歷史世界狀態(tài)
在hyperledger里面,ledger是一個具有授權管理的共享賬本系統(tǒng)
從底層設計上保證數(shù)據(jù)的一致性,有效性,不可篡改性

network

由peer組成network
在同一network的peer,實時同步記賬,保證ledger數(shù)據(jù)的一致性

ordering service

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

world state

世界狀態(tài)
當前l(fā)edger里面存放的數(shù)據(jù)
Key和value 以version形式存在
當前實現(xiàn)有couchdb和leveldb

membership service provider

管理peer的身份和訪問許可

業(yè)務分析


漁民王大壯

靠打漁,賣魚為生
需要加入到區(qū)塊鏈網(wǎng)絡,把魚賣給餐館
漁政監(jiān)管部門也需要加入?yún)^(qū)塊鏈網(wǎng)絡,監(jiān)管打漁的合法性
王大壯把捕魚的數(shù)據(jù)加入到區(qū)塊鏈網(wǎng)絡,餐館和漁政部門均可訪問審計數(shù)據(jù)

數(shù)據(jù)

每次捕獲后儡遮,王大壯需要記錄捕撈的信息
包括
唯一的ID號
捕獲的位置
捕獲的時間
捕撈重量
捕魚船信息
捕撈人信息
為了簡單起見屡久,我們只設計這六個數(shù)據(jù)屬性爱榔。然而,在實際應用中唇聘,更多的細節(jié)需要被記錄下來。氣溫, 捕撈深度, 作業(yè)設備類型,漁網(wǎng)大小,捕撈區(qū)域水源水質(zhì)分析, 等等..

數(shù)據(jù)定義

由于ledger的世界狀態(tài)是key/value的形式存在
所以數(shù)據(jù)適合采用json方式表示
應用程序的開發(fā)適合采用nodejs開發(fā)


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

消費者

餐館A
餐館B

消費者痛點分析

餐館希望能買到低價格,優(yōu)質(zhì)的小黃魚
餐館不希望買到非法捕撈的小黃魚(避免嚴厲的監(jiān)管處罰)
餐館不確定市場上的小黃魚是否合法,是否新鮮
王大壯希望把自己合法捕撈的小黃魚,以合適的價格銷售出去
監(jiān)管部門需要了解小黃魚的捕撈量和銷售數(shù)量

信任問題

餐館不信任王大壯
監(jiān)管部門不信任 餐館
監(jiān)管部門不信任 王大壯
王大壯的隱私問題

隱私業(yè)務分析


價格是任何商業(yè)模型里面非常重要的一環(huán). 是非常非常敏感的隱私. 餐館A有可能是王大壯的新客戶, 王大壯的營銷策略是, 打算用較低的價格贏得新客戶, 一旦客戶穩(wěn)定后再去漲價.
但這個優(yōu)惠的價格是不應該被餐館B的老板看到的.
在傳統(tǒng)的公有區(qū)塊鏈里面宪肖,一旦王大壯和餐館A完成了交易么介,整個網(wǎng)絡可以查看此協(xié)議的細節(jié)壤短,18.5元一斤的小黃魚所有的節(jié)點都可以看到。
你可以想象桶现,餐館B老板看到這個價格后的心情. 一定會有 一萬只草泥馬在遼闊的草原上奔跑.

漁政監(jiān)管需求分析

“僅僅抓非法捕撈,治標不治本骡和。只有立足源頭,從非法捕撈、收購婆赠、販賣的每一個環(huán)節(jié)實施‘全鏈條’打擊,才能從根本上遏制非法捕撈犯罪行為,保護資源環(huán)境休里。”
監(jiān)管部門需要具有權限,可以驗證查看區(qū)塊鏈ledger的每一條記錄
監(jiān)管部門應該只具有查詢ledger的權限.
監(jiān)管部門通過查詢捕魚的重量和位置來確定漁民是否合法捕撈
監(jiān)管部門應該具有從blockchain網(wǎng)絡中添加或者刪除漁民的權限
如果王大壯的捕撈是非法的, 超過許可的. 監(jiān)管部門可以把王大壯從hpyerledger fabirc區(qū)塊鏈網(wǎng)絡里面移除, 那么王大壯就失去了賣魚的權利

業(yè)務復盤


漁民王大壯,捕獲小黃魚,使用hyperledger fabirc的sdk接口調(diào)用chaincode把捕魚數(shù)據(jù)寫入?yún)^(qū)塊鏈網(wǎng)絡 .
整個過程是,首先sdk發(fā)出transaction申請, 每個peer節(jié)點模擬執(zhí)行,把背書結(jié)果反饋給sdk, sdk收集到足夠的背書后,把請求發(fā)給ordering節(jié)點, ordering節(jié)點排序后,把數(shù)據(jù)生成block.
Block廣播給每個peer節(jié)點,每個節(jié)點驗證后, 最后更新自己ledger的數(shù)據(jù).
監(jiān)管部門在小黃魚的供應鏈里面, 每筆交易都被記錄, 監(jiān)管部門可以查詢交易的細節(jié),但是監(jiān)管部門無權查詢交易的價格. 因為監(jiān)管部門不在具體交易的channel里面.
漁民王大壯分別和餐館A 餐館B約定了不同的價格, 交易在不同的channel里面, 紫色區(qū)塊鏈里面的交易價格為18.5元/斤 紅色區(qū)塊鏈里面的價格為28.5元/斤
不同channel彼此隔離,充分保證了交易雙方的隱私

?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市浇借,隨后出現(xiàn)的幾起案子宰衙,更是在濱河造成了極大的恐慌,老刑警劉巖睬愤,帶你破解...
    沈念sama閱讀 206,311評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件尤辱,死亡現(xiàn)場離奇詭異光督,居然都是意外死亡,警方通過查閱死者的電腦和手機船老,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,339評論 2 382
  • 文/潘曉璐 我一進店門郭赐,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人捌锭,你說我怎么就攤上這事俘陷。” “怎么了观谦?”我有些...
    開封第一講書人閱讀 152,671評論 0 342
  • 文/不壞的土叔 我叫張陵拉盾,是天一觀的道長。 經(jīng)常有香客問我坎匿,道長盾剩,這世上最難降的妖魔是什么雷激? 我笑而不...
    開封第一講書人閱讀 55,252評論 1 279
  • 正文 為了忘掉前任蜀撑,我火速辦了婚禮沃饶,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好君纫,可當我...
    茶點故事閱讀 64,253評論 5 371
  • 文/花漫 我一把揭開白布陡叠。 她就那樣靜靜地躺著,像睡著了一般诗宣。 火紅的嫁衣襯著肌膚如雪裁眯。 梳的紋絲不亂的頭發(fā)上旦袋,一...
    開封第一講書人閱讀 49,031評論 1 285
  • 那天专控,我揣著相機與錄音幸冻,去河邊找鬼强缘。 笑死觉阅,一個胖子當著我的面吹牛割笙,可吹牛的內(nèi)容都是我干的走净。 我是一名探鬼主播琢蛤,決...
    沈念sama閱讀 38,340評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼搂誉,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起味悄,我...
    開封第一講書人閱讀 36,973評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎肪凛,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體志衣,經(jīng)...
    沈念sama閱讀 43,466評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,937評論 2 323
  • 正文 我和宋清朗相戀三年驶社,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,039評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情诈皿,我是刑警寧澤避除,帶...
    沈念sama閱讀 33,701評論 4 323
  • 正文 年R本政府宣布书斜,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏屡江。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,254評論 3 307
  • 文/蒙蒙 一赛不、第九天 我趴在偏房一處隱蔽的房頂上張望惩嘉。 院中可真熱鬧,春花似錦踢故、人聲如沸文黎。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,259評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽耸峭。三九已至,卻和暖如春淋纲,著一層夾襖步出監(jiān)牢的瞬間劳闹,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,485評論 1 262
  • 我被黑心中介騙來泰國打工洽瞬, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留本涕,地道東北人。 一個月前我還...
    沈念sama閱讀 45,497評論 2 354
  • 正文 我出身青樓伙窃,卻偏偏與公主長得像菩颖,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子对供,可洞房花燭夜當晚...
    茶點故事閱讀 42,786評論 2 345

推薦閱讀更多精彩內(nèi)容