聯盟鏈 Hyperledger Fabric 應用場景
一、說明
本文主要通過一個例子分享以 Hyperledger Fabric
為代表的聯盟鏈應用場景。
關於 Fabric 的相關概念請先參考文章 《Hyperledger Fabric 核心概念》
二、業務場景
我們看一個購物場景:
- 首先消費者在某個購物平臺上購物例如淘寶。
- 然後使用第三方支付渠道進行支付例如支付寶。
- 最後在銀行完成資金的扣款。
這樣整個過程使用目前傳統技術來實現的話,相互之間的資料是 不透明 的,每個平臺所產生的資料都只是儲存在 各自 的資料庫裡面;
例如淘寶儲存的是訂單資料,支付寶儲存了支付記錄,銀行記錄了扣款記錄和餘額;對於整條鏈路上的每個參與者來說資料是 不透明 的。
可能會產生兩個問題:
-
安全風險:由於資料都掌握在平臺自己手裡的,例如銀行單方面把你的餘額修改了,又或者淘寶被開發人員刪庫了導致你的訂單資訊全沒了。
-
溯源困難:因為平臺或者機構之間的資料是相互不透明的,所以資料溯源非常困難;例如如果交易鏈路很長,銀行想要識別一些犯罪行為,追蹤資金的來源是非常困難的。
三、區塊鏈架構
上面的業務場景,我們代入到 Hyperledger Fabric
的網路中來實現的話,架構圖如下:
-
組織:先定義3個組織,
組織1
是購物平臺
有一個應用淘寶,組織2
是支付平臺
有一個應用支付寶,組織3
是銀行
; -
節點:為每個組織分別擁有兩個節點,每個組織的應用都分別往自己的節點寫入交易資訊;
-
通道:通過一個通道,把所有的節點統一管理起來。
在整個區塊鏈網路搭建完成之後,當每個個購物流程走完之後區塊鏈的賬本上會新增3條記錄,分別是一條 訂單資訊
一條 支付資訊
和一條 扣款資訊
;
區塊鏈的特性,每個節點都有一份全量資料的賬本副本。
四、總結
對比傳統技術中存在的問題有以下優勢:
- 安全性 :區塊鏈的不可篡改特性,資料不存在被某個組織進行惡意修改的問題,因為每個組織都擁有一份全量的賬本,只要進行對賬就會發現問題,所以任何的篡改都不會達成
共識
的; - 溯源 :區塊鏈的資料結構特性,賬本會按鏈路的方式,循序地儲存著所有的交易資訊;所以例如銀行需要最終資金的來源,識別犯罪行為就非常方便了。
掃碼關注有驚喜!
「其他文章」
- 記一次批量更新整型型別的列 → 探究 UPDATE 的使用細節
- 編碼中的Adapter,不僅是一種設計模式,更是一種架構理念與解決方案
- 執行緒池底層原理詳解與原始碼分析
- 30分鐘掌握 Webpack
- 線性迴歸大結局(嶺(Ridge)、 Lasso迴歸原理、公式推導),你想要的這裡都有
- Django 之路由層
- 【前端必會】webpack loader 到底是什麼
- day42-反射01
- 中心化決議管理——雲端分析
- HashMap底層原理及jdk1.8原始碼解讀
- 詳解JS中 call 方法的實現
- 列印 Logger 日誌時,需不需要再封裝一下工具類?
- 初識設計模式 - 代理模式
- 設計模式---享元模式
- 密碼學奇妙之旅、01 CFB密文反饋模式、AES標準、Golang程式碼
- [ML從入門到入門] 支援向量機:從SVM的推導過程到SMO的收斂性討論
- 從應用訪問Pod元資料-DownwardApi的應用
- Springboot之 Mybatis 多資料來源實現
- Java 泛型程式設計
- CAS核心思想、底層實現