您好,登錄后才能下訂單哦!
這篇文章主要介紹了Fabric區塊鏈中Python開發的示例分析,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
Hyperledger 是一個旨在推動區塊鏈跨行業應用的開源項目, 由 Linux基金會在2015年12月主導發起該項目, 成員包括金融、銀行、物聯網、供應鏈、制造和科技等多個行業的領頭羊,托管了眾多面向企業的區塊鏈開源框架和工具:
Hyperledger Fabric(后文簡稱Fabric)是其中發展最好的一個__企業級區塊鏈平臺__,最初由Digital Asset和IBM 貢獻,目前已經應用于沃爾瑪的食物溯源鏈(Foodtrust)和馬士基的物流跟蹤鏈(TradeLens)中, 代表了當下企業級區塊鏈應用的最高水平。可以認為Fabric是一種聯盟鏈(Consortium Blockchain)平臺, 它適合構建跨越多個企業邊界的去中心化應用。
由于Fabric項目的目標是應用于相對可信的企業聯盟環境,因此其設計思路與比特幣、以太坊 等公鏈平臺有明顯的差異。Fabric借鑒了區塊鏈的數據結構,但引入了相當多的身份驗證與 權限控制機制,以及數據隱私保護機制,以適應企業級應用的要求。同時由于企業聯盟環境 要比完全開放的公鏈環境可控,因此Fabric沒有強調其共識體系對拜占庭容錯的實現,允許使用 非拜占庭容錯算法建立共識,從而可以達到相當實用的交易吞吐量。
毫無疑問,Fabric是受到比特幣的啟發而誕生的,因此它借鑒了比特幣、以太坊這些公鏈中的一些 核心特性,例如采用不可篡改的區塊鏈結構來保存數據、采用非對稱加密技術來進行身份識別與認證、支持智能合約等等。
但是Fabric定位于企業級的分布式賬本技術(DLT - D istributed L edger T echnology)平臺,它的主要目的是為跨越多個企業邊界的活動提供不可篡改的分布式記賬平臺。例如在食物溯源應用中,為了讓消費者可以了解到所購買食物是否安全,就必須將從農場到加工商、分銷商、零售商乃至監管機構等各個環節的檢驗與放行信息記錄到區塊鏈上,以保證溯源信息的透明與可信:
因此Fabric是一種聯盟鏈(Consortium Blockchain),它適合在多個企業間實現分布式記賬,這一 定位使Fabric的實現與以太坊這樣的公鏈有了明顯的差異:
分布式賬本 vs. 區塊鏈
分布式賬本是比區塊鏈更加寬泛的概念,可以認為區塊鏈只是分布式賬本的一種實現技術, 其他的分布式賬本實現還包括哈希圖等。
去中心化 vs. 分布式
Fabric淡化了去中心化(Decentralized),而以分布式(Distributed)代替,這一思路帶來了系統設計 與實現上的巨大影響。例如,在Fabric中,采用中心化的CA機制來發放證書,只有持有有效證書的節點和用戶才可以訪問區塊鏈上的賬本數據。因此Fabric是 許可制 / Permissioned 的區塊鏈,這與 不需要許可 / Permissionless 的以太坊這樣的公鏈形成了鮮明的對比。
拜占庭容錯 vs. 崩潰容錯
由于采用許可機制,Fabric也淡化了對不可信(Trustless)環境下共識達成的依賴性,而假設聯盟鏈中的企業有可能是值得信賴的,因此并不依賴于工作量證明這樣的拜占庭容錯算法 —— 雖然Fabric模塊化的設計可以支持引入不同的共識算法實現,但目前的產品化方案是Kafka共識,它顯然是不能對抗拜占庭錯誤的 —— 不過對不可信環境支持的淡化處理有利于提高交易的吞吐量,這對于企業級應用也是有益的。
數據隱私保護
在另一方面,Fabric強化了隱私保護能力。例如,Fabric支持在同一套企業網絡上建立多個不同的 通道 / Channel,每一個通道都有自己的區塊鏈和訪問控制,彼此互不影響,這有利于復用基礎設施,例如不同企業間的銷售部門可以建立一個通道來分享市場數據,而這些企業間的研發部門可以建立另一個通道來分享技術數據。
Fabric并不是唯一的聯盟鏈解決方案,但目前可以說是最復雜的企業聯盟鏈實現,這種復雜性源于設計者對應用場景的假設和推演,以及對Fabric廣泛適用性的考量,這是我們在學習過程中需要換位思考的一點。
感謝你能夠認真閱讀完這篇文章,希望小編分享的“Fabric區塊鏈中Python開發的示例分析”這篇文章對大家有幫助,同時也希望大家多多支持億速云,關注億速云行業資訊頻道,更多相關知識等著你來學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。