區塊鏈可插撥
1. 什麼是區塊鏈
區塊鏈是一種帶有數據「散列驗證」功能的資料庫。區塊,就是數據塊,按照時間順序將數據區塊組合成一種鏈式結構,並利用密碼學演算法,以分布式記賬的方式,集體維護資料庫的可靠性。所有數據塊按時間順序相連,從而形成區塊鏈。
區塊鏈系統由數據層、網路層、共識層、激勵層、合約層和應用層組成。 其中,數據層封裝了底層數據區塊以及相關的數據加密和時間戳等基礎數據和基本演算法;網路層則包括分布式組網機制、數據傳播機制和數據驗證機制等;共識層主要封裝網路節點的各類共識演算法;激勵層將經濟因素集成到區塊鏈技術體系中來,主要包括經濟激勵的發行機制和分配機制等;合約層主要封裝各類腳本、演算法和智能合約,是區塊鏈可編程特性的基礎;應用層則封裝了區塊鏈的各種應用場景和案例。該模型中,基於時間戳的鏈式區塊結構、分布式節點的共識機制、基於共識算力的經濟激勵和靈活可編程的智能合約是區塊鏈技術最具代表性的創新點。
區塊鏈主要解決的交易的信任和安全問題,因此它針對這個問題提出了四個技術創新:
(1)分布式賬本,就是交易記賬由分布在不同地方的多個節點共同完成,而且每一個節點都記錄的是完整的賬目,因此它們都可以參與監督交易合法性,同時也可以共同為其作證。
跟傳統的分布式存儲有所不同,區塊鏈的分布式存儲的獨特性主要體現在兩個方面:一是區塊鏈每個節點都按照塊鏈式結構存儲完整的數據,傳統分布式存儲一般是將數據按照一定的規則分成多份進行存儲。二是區塊鏈每個節點存儲都是獨立的、地位等同的,依靠共識機制保證存儲的一致性,而傳統分布式存儲一般是通過中心節點往其他備份節點同步數據。 [8]
沒有任何一個節點可以單獨記錄賬本數據,從而避免了單一記賬人被控制或者被賄賂而記假賬的可能性。也由於記賬節點足夠多,理論上講除非所有的節點被破壞,否則賬目就不會丟失,從而保證了賬目數據的安全性。
(2)非對稱加密和授權技術,存儲在區塊鏈上的交易信息是公開的,但是賬戶身份信息是高度加密的,只有在數據擁有者授權的情況下才能訪問到,從而保證了數據的安全和個人的隱私。
(3)共識機制,就是所有記賬節點之間怎麼達成共識,去認定一個記錄的有效性,這既是認定的手段,也是防止篡改的手段。區塊鏈提出了四種不同的共識機制,適用於不同的應用場景,在效率和安全性之間取得平衡。
區塊鏈的共識機制具備「少數服從多數」以及「人人平等」的特點,其中「少數服從多數」並不完全指節點個數,也可以是計算能力、股權數或者其他的計算機可以比較的特徵量。「人人平等」是當節點滿足條件時,所有節點都有權優先提出共識結果、直接被其他節點認同後並最後有可能成為最終共識結果。以比特幣為例,採用的是工作量證明,只有在控制了全網超過51%的記賬節點的情況下,才有可能偽造出一條不存在的記錄。當加入區塊鏈的節點足夠多的時候,這基本上不可能,從而杜絕了造假的可能.
(4)智能合約,智能合約是基於這些可信的不可篡改的數據,可以自動化的執行一些預先定義好的規則和條款。以保險為例,如果說每個人的信息(包括醫療信息和風險發生的信息)都是真實可信的,那就很容易的在一些標准化的保險產品中,去進行自動化的理賠
其實個人可以簡單理解,其實就是一個金融資料庫。
2. 區塊鏈是什麼如何簡單易懂地介紹區塊鏈
很多人不知道區塊鏈是什麼,這邊給大家詳細的介紹一下,區塊鏈就是顛覆舊模式的新技術,就像人們容易忽視看不見卻不可或缺的氧氣一樣,人們往往忽視了市場經濟中至關重要的東西,那就是信任。沒有信任,任何交易都無法成立。
此外不同的種族、民族、文化、宗教信仰等,會形成信任鴻溝。由於陌生人之間缺乏相互理解和必要的信任,交易很難發生。市場經濟在陌生人中大量出現。市場經濟的產生和發展在於一種新機制的誕生,它解決了陌生人之間的信任問題。
區塊鏈的概念最早是在2008年由比特幣創始人中本聰撰寫的論文中提出的,區塊鏈可以理解為一種公共會計的技術方案,所有數據都將公開透明,不需要中央伺服器作為信任中介,從而在技術層面上保證信息的真實性、不變性和可信度,數據的不變性非常重要。
由於區塊鏈具有大規模擴展、數據公開透明的技術特點,並且由於每個客戶端的數據都是一致的,即使部分客戶端被破壞,也不會影響數據安全的可靠性,尤其是可以有效解決陌生人之間的信任問題,因此這項技術可以擴展到所有可以數字化的領域,如數字貨幣、支付清算、數字票據、權益證明、徵信、政務服務、病歷等,如果區塊鏈技術發達了,未來將與大家息息相關。
3. 區塊鏈的概念是什麼
從字面理解,區塊鏈包含了兩個概念:區塊、鏈。區塊鏈本身是由一個個區塊(Block)組成,而不同節點鏈接在一起構建的網路,就是區塊鏈。區塊鏈的主要作用是儲存信息,任何需要保存的信息,都可以寫入區塊鏈,也可以從裡面讀取。
每個區塊存儲:一些有效的記錄或交易;涉及該塊的信息;通過每個塊的散列到前一個塊和下一個塊的鏈接——可以被認為是塊的指紋的唯一代碼。
因此,每個塊在鏈內具有特定且不可移動的位置,因為每個塊包含來自前一塊的散列的信息。整個鏈存儲在構成區塊鏈的每個網路節點中,因此鏈的精確副本存儲在所有網路參與者中。
用途
從本質上講,區塊鏈可用於存儲任何類型的信息,這些信息必須保持完整,並且比通過中間人以安全,分散和更便宜的方式保持可用。此外,由於存儲的信息是加密的,因此可以保證其機密性,因為只有擁有加密密鑰的人才能訪問它。
在醫療保健中使用區塊鏈。例如,健康記錄可以合並並存儲在區塊鏈中。這意味著每個患者的病史都是安全的,同時,每個被授權的醫生都可以使用,無論患者接受治療的健康中心如何。甚至制葯行業也可以使用這種技術來驗證葯品並防止偽造。
區塊鏈對於管理數字資產和文檔也非常有用。到目前為止,數字化的問題在於一切都很容易復制,但Blockchain允許您記錄購買,契約,文檔或任何其他類型的在線資產,而不會被偽造。
4. 區塊鏈 --- 共識演算法
PoW演算法是一種防止分布式服務資源被濫用、拒絕服務攻擊的機制。它要求節點進行適量消耗時間和資源的復雜運算,並且其運算結果能被其他節點快速驗算,以耗用時間、能源做擔保,以確保服務與資源被真正的需求所使用。
PoW演算法中最基本的技術原理是使用哈希演算法。假設求哈希值Hash(r),若原始數據為r(raw),則運算結果為R(Result)。
R = Hash(r)
哈希函數Hash()的特性是,對於任意輸入值r,得出結果R,並且無法從R反推回r。當輸入的原始數據r變動1比特時,其結果R值完全改變。在比特幣的PoW演算法中,引入演算法難度d和隨機值n,得到以下公式:
Rd = Hash(r+n)
該公式要求在填入隨機值n的情況下,計算結果Rd的前d位元組必須為0。由於哈希函數結果的未知性,每個礦工都要做大量運算之後,才能得出正確結果,而算出結果廣播給全網之後,其他節點只需要進行一次哈希運算即可校驗。PoW演算法就是採用這種方式讓計算消耗資源,而校驗僅需一次。
PoS演算法要求節點驗證者必須質押一定的資金才有挖礦打包資格,並且區域鏈系統在選定打包節點時使用隨機的方式,當節點質押的資金越多時,其被選定打包區塊的概率越大。
POS模式下,每個幣每天產生1幣齡,比如你持有100個幣,總共持有了30天,那麼,此時你的幣齡就為3000。這個時候,如果你驗證了一個POS區塊,你的幣齡就會被清空為0,同時從區塊中獲得相對應的數字貨幣利息。
節點通過PoS演算法出塊的過程如下:普通的節點要成為出塊節點,首先要進行資產的質押,當輪到自己出塊時,打包區塊,然後向全網廣播,其他驗證節點將會校驗區塊的合法性。
DPoS演算法和PoS演算法相似,也採用股份和權益質押。
但不同的是,DPoS演算法採用委託質押的方式,類似於用全民選舉代表的方式選出N個超級節點記賬出塊。
選民把自己的選票投給某個節點,如果某個節點當選記賬節點,那麼該記賬節點往往在獲取出塊獎勵後,可以採用任意方式來回報自己的選民。
這N個記賬節點將輪流出塊,並且節點之間相互監督,如果其作惡,那麼會被扣除質押金。
通過信任少量的誠信節點,可以去除區塊簽名過程中不必要的步驟,提高了交易的速度。
拜占庭問題:
拜占庭是古代東羅馬帝國的首都,為了防禦在每塊封地都駐扎一支由單個將軍帶領的軍隊,將軍之間只能靠信差傳遞消息。在戰爭時,所有將軍必須達成共識,決定是否共同開戰。
但是,在軍隊內可能有叛徒,這些人將影響將軍們達成共識。拜占庭將軍問題是指在已知有將軍是叛徒的情況下,剩餘的將軍如何達成一致決策的問題。
BFT:
BFT即拜占庭容錯,拜占庭容錯技術是一類分布式計算領域的容錯技術。拜占庭假設是對現實世界的模型化,由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊等原因,計算機和網路可能出現不可預料的行為。拜占庭容錯技術被設計用來處理這些異常行為,並滿足所要解決的問題的規范要求。
拜占庭容錯系統 :
發生故障的節點被稱為 拜占庭節點 ,而正常的節點即為 非拜占庭節點 。
假設分布式系統擁有n台節點,並假設整個系統拜占庭節點不超過m台(n ≥ 3m + 1),拜占庭容錯系統需要滿足如下兩個條件:
另外,拜占庭容錯系統需要達成如下兩個指標:
PBFT即實用拜占庭容錯演算法,解決了原始拜占庭容錯演算法效率不高的問題,演算法的時間復雜度是O(n^2),使得在實際系統應用中可以解決拜占庭容錯問題
PBFT是一種狀態機副本復制演算法,所有的副本在一個視圖(view)輪換的過程中操作,主節點通過視圖編號以及節點數集合來確定,即:主節點 p = v mod |R|。v:視圖編號,|R|節點個數,p:主節點編號。
PBFT演算法的共識過程如下:客戶端(Client)發起消息請求(request),並廣播轉發至每一個副本節點(Replica),由其中一個主節點(Leader)發起提案消息pre-prepare,並廣播。其他節點獲取原始消息,在校驗完成後發送prepare消息。每個節點收到2f+1個prepare消息,即認為已經准備完畢,並發送commit消息。當節點收到2f+1個commit消息,客戶端收到f+1個相同的reply消息時,說明客戶端發起的請求已經達成全網共識。
具體流程如下 :
客戶端c向主節點p發送<REQUEST, o, t, c>請求。o: 請求的具體操作,t: 請求時客戶端追加的時間戳,c:客戶端標識。REQUEST: 包含消息內容m,以及消息摘要d(m)。客戶端對請求進行簽名。
主節點收到客戶端的請求,需要進行以下交驗:
a. 客戶端請求消息簽名是否正確。
非法請求丟棄。正確請求,分配一個編號n,編號n主要用於對客戶端的請求進行排序。然後廣播一條<<PRE-PREPARE, v, n, d>, m>消息給其他副本節點。v:視圖編號,d客戶端消息摘要,m消息內容。<PRE-PREPARE, v, n, d>進行主節點簽名。n是要在某一個范圍區間內的[h, H],具體原因參見 垃圾回收 章節。
副本節點i收到主節點的PRE-PREPARE消息,需要進行以下交驗:
a. 主節點PRE-PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了一條在同一v下並且編號也是n,但是簽名不同的PRE-PREPARE信息。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。正確請求,副本節點i向其他節點包括主節點發送一條<PREPARE, v, n, d, i>消息, v, n, d, m與上述PRE-PREPARE消息內容相同,i是當前副本節點編號。<PREPARE, v, n, d, i>進行副本節點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中,用於View Change過程中恢復未完成的請求操作。
主節點和副本節點收到PREPARE消息,需要進行以下交驗:
a. 副本節點PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. n是否在區間[h, H]內。
d. d是否和當前已收到PRE-PPREPARE中的d相同
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的PREPARE消息,則向其他節點包括主節點發送一條<COMMIT, v, n, d, i>消息,v, n, d, i與上述PREPARE消息內容相同。<COMMIT, v, n, d, i>進行副本節點i的簽名。記錄COMMIT消息到日誌中,用於View Change過程中恢復未完成的請求操作。記錄其他副本節點發送的PREPARE消息到log中。
主節點和副本節點收到COMMIT消息,需要進行以下交驗:
a. 副本節點COMMIT消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的COMMIT消息,說明當前網路中的大部分節點已經達成共識,運行客戶端的請求操作o,並返回<REPLY, v, t, c, i, r>給客戶端,r:是請求操作結果,客戶端如果收到f+1個相同的REPLY消息,說明客戶端發起的請求已經達成全網共識,否則客戶端需要判斷是否重新發送請求給主節點。記錄其他副本節點發送的COMMIT消息到log中。
如果主節點作惡,它可能會給不同的請求編上相同的序號,或者不去分配序號,或者讓相鄰的序號不連續。備份節點應當有職責來主動檢查這些序號的合法性。
如果主節點掉線或者作惡不廣播客戶端的請求,客戶端設置超時機制,超時的話,向所有副本節點廣播請求消息。副本節點檢測出主節點作惡或者下線,發起View Change協議。
View Change協議 :
副本節點向其他節點廣播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的編號, C 是 2f+1驗證過的CheckPoint消息集合, P 是當前副本節點未完成的請求的PRE-PREPARE和PREPARE消息集合。
當主節點p = v + 1 mod |R|收到 2f 個有效的VIEW-CHANGE消息後,向其他節點廣播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主節點重新發起的未經完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規則:
副本節點收到主節點的NEW-VIEW消息,驗證有效性,有效的話,進入v+1狀態,並且開始 O 中的PRE-PREPARE消息處理流程。
在上述演算法流程中,為了確保在View Change的過程中,能夠恢復先前的請求,每一個副本節點都記錄一些消息到本地的log中,當執行請求後副本節點需要把之前該請求的記錄消息清除掉。
最簡單的做法是在Reply消息後,再執行一次當前狀態的共識同步,這樣做的成本比較高,因此可以在執行完多條請求K(例如:100條)後執行一次狀態同步。這個狀態同步消息就是CheckPoint消息。
副本節點i發送<CheckPoint, n, d, i>給其他節點,n是當前節點所保留的最後一個視圖請求編號,d是對當前狀態的一個摘要,該CheckPoint消息記錄到log中。如果副本節點i收到了2f+1個驗證過的CheckPoint消息,則清除先前日誌中的消息,並以n作為當前一個stable checkpoint。
這是理想情況,實際上當副本節點i向其他節點發出CheckPoint消息後,其他節點還沒有完成K條請求,所以不會立即對i的請求作出響應,它還會按照自己的節奏,向前行進,但此時發出的CheckPoint並未形成stable。
為了防止i的處理請求過快,設置一個上文提到的 高低水位區間[h, H] 來解決這個問題。低水位h等於上一個stable checkpoint的編號,高水位H = h + L,其中L是我們指定的數值,等於checkpoint周期處理請求數K的整數倍,可以設置為L = 2K。當副本節點i處理請求超過高水位H時,此時就會停止腳步,等待stable checkpoint發生變化,再繼續前進。
在區塊鏈場景中,一般適合於對強一致性有要求的私有鏈和聯盟鏈場景。例如,在IBM主導的區塊鏈超級賬本項目中,PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中,共識模塊被設計成可插拔的模塊,支持像PBFT、Raft等共識演算法。
Raft基於領導者驅動的共識模型,其中將選舉一位傑出的領導者(Leader),而該Leader將完全負責管理集群,Leader負責管理Raft集群的所有節點之間的復制日誌。
下圖中,將在啟動過程中選擇集群的Leader(S1),並為來自客戶端的所有命令/請求提供服務。 Raft集群中的所有節點都維護一個分布式日誌(復制日誌)以存儲和提交由客戶端發出的命令(日誌條目)。 Leader接受來自客戶端的日誌條目,並在Raft集群中的所有關注者(S2,S3,S4,S5)之間復制它們。
在Raft集群中,需要滿足最少數量的節點才能提供預期的級別共識保證, 這也稱為法定人數。 在Raft集群中執行操作所需的最少投票數為 (N / 2 +1) ,其中N是組中成員總數,即 投票至少超過一半 ,這也就是為什麼集群節點通常為奇數的原因。 因此,在上面的示例中,我們至少需要3個節點才能具有共識保證。
如果法定仲裁節點由於任何原因不可用,也就是投票沒有超過半數,則此次協商沒有達成一致,並且無法提交新日誌。
數據存儲:Tidb/TiKV
日誌:阿里巴巴的 DLedger
服務發現:Consul& etcd
集群調度:HashiCorp Nomad
只能容納故障節點(CFT),不容納作惡節點
順序投票,只能串列apply,因此高並發場景下性能差
Raft通過解決圍繞Leader選舉的三個主要子問題,管理分布式日誌和演算法的安全性功能來解決分布式共識問題。
當我們啟動一個新的Raft集群或某個領導者不可用時,將通過集群中所有成員節點之間協商來選舉一個新的領導者。 因此,在給定的實例中,Raft集群的節點可以處於以下任何狀態: 追隨者(Follower),候選人(Candidate)或領導者(Leader)。
系統剛開始啟動的時候,所有節點都是follower,在一段時間內如果它們沒有收到Leader的心跳信號,follower就會轉化為Candidate;
如果某個Candidate節點收到大多數節點的票,則這個Candidate就可以轉化為Leader,其餘的Candidate節點都會回到Follower狀態;
一旦一個Leader發現系統中存在一個Leader節點比自己擁有更高的任期(Term),它就會轉換為Follower。
Raft使用基於心跳的RPC機制來檢測何時開始新的選舉。 在正常期間, Leader 會定期向所有可用的 Follower 發送心跳消息(實際中可能把日誌和心跳一起發過去)。 因此,其他節點以 Follower 狀態啟動,只要它從當前 Leader 那裡收到周期性的心跳,就一直保持在 Follower 狀態。
當 Follower 達到其超時時間時,它將通過以下方式啟動選舉程序:
根據 Candidate 從集群中其他節點收到的響應,可以得出選舉的三個結果。
共識演算法的實現一般是基於復制狀態機(Replicated state machines),何為 復制狀態機 :
簡單來說: 相同的初識狀態 + 相同的輸入 = 相同的結束狀態 。不同節點要以相同且確定性的函數來處理輸入,而不要引入一下不確定的值,比如本地時間等。使用replicated log是一個很不錯的注意,log具有持久化、保序的特點,是大多數分布式系統的基石。
有了Leader之後,客戶端所有並發的請求可以在Leader這邊形成一個有序的日誌(狀態)序列,以此來表示這些請求的先後處理順序。Leader然後將自己的日誌序列發送Follower,保持整個系統的全局一致性。注意並不是強一致性,而是 最終一致性 。
日誌由有序編號(log index)的日誌條目組成。每個日誌條目包含它被創建時的任期號(term),和日誌中包含的數據組成,日誌包含的數據可以為任何類型,從簡單類型到區塊鏈的區塊。每個日誌條目可以用[ term, index, data]序列對表示,其中term表示任期, index表示索引號,data表示日誌數據。
Leader 嘗試在集群中的大多數節點上執行復制命令。 如果復製成功,則將命令提交給集群,並將響應發送回客戶端。類似兩階段提交(2PC),不過與2PC的區別在於,leader只需要超過一半節點同意(處於工作狀態)即可。
leader 、 follower 都可能crash,那麼 follower 維護的日誌與 leader 相比可能出現以下情況
當出現了leader與follower不一致的情況,leader強制follower復制自己的log, Leader會從後往前試 ,每次AppendEntries失敗後嘗試前一個日誌條目(遞減nextIndex值), 直到成功找到每個Follower的日誌一致位置點(基於上述的兩條保證),然後向後逐條覆蓋Followers在該位置之後的條目 。所以丟失的或者多出來的條目可能會持續多個任期。
要求候選人的日誌至少與其他節點一樣最新。如果不是,則跟隨者節點將不投票給候選者。
意味著每個提交的條目都必須存在於這些伺服器中的至少一個中。如果候選人的日誌至少與該多數日誌中的其他日誌一樣最新,則它將保存所有已提交的條目,避免了日誌回滾事件的發生。
即任一任期內最多一個leader被選出。這一點非常重要,在一個復制集中任何時刻只能有一個leader。系統中同時有多餘一個leader,被稱之為腦裂(brain split),這是非常嚴重的問題,會導致數據的覆蓋丟失。在raft中,兩點保證了這個屬性:
因此, 某一任期內一定只有一個leader 。
當集群中節點的狀態發生變化(集群配置發生變化)時,系統容易受到系統故障。 因此,為防止這種情況,Raft使用了一種稱為兩階段的方法來更改集群成員身份。 因此,在這種方法中,集群在實現新的成員身份配置之前首先更改為中間狀態(稱為聯合共識)。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求,它的主要目的是提升分布式系統的可用性。
5. 這幾年,不管是傳統巨頭還是新興企業都在開辟BaaS戰場,各家BaaS平台究竟有哪些優劣勢呢
趣鏈科技的BaaS平台在整個行業是名列前茅的。趣鏈BaaS基於趣鏈區塊鏈平台構建⌄首創驅動模式,也是全球首個基於雲原生技術框架的BaaS。具有快速部署、可視化監控、智能研發、多底層兼容等創新優勢,可提供一站式應用開發服務,實現對多區塊鏈平台、多節點類型、多資源介質的可插拔兼容,滿足區塊鏈節點在不同網路環境中的聯合組網,全面支撐區塊鏈業務的快速落地和拓展。
趣鏈BaaS解決方案逐漸從金融、政務,滲透至能源、司法、醫療、工業互聯網等多種領域。平台已為中國銀行、中國建設銀行、光大銀行、興業銀行等十餘家銀行提供總行級區塊鏈基礎設施服務,落地近百個區塊鏈應用,日均交易量達千萬次,是國內服務金融機構數目最多的BaaS平台。
6. 區塊鏈之聯盟鏈(三) 認識Fabric
Fabric 是超級賬本聯盟推出的核心區塊鏈框架,它適合在復雜的企業內和企業間搭建聯盟鏈。根據超級賬本聯盟的目標, Fabric 被建設為一個模塊化的、支持可插拔組件的基礎聯盟鏈框架。;
與以太坊系的Quorum不同,Fabric從一開始就只考慮企業間的應用。其獨有的channel概念,將企業根據業務目的不同以不同的子網連接起來, 每一個子網對應一個channel,而每個channel有自己獨立的區塊鏈。而Quorum很顯然是只有一個公網(所有企業節點都加入進去),企業與企業間的私有業務是通過Private Manager 完成的。
理解channel的最簡單方法就是,將它類比為一個消息服務提供的Topic,實際上Fabic最早就是基於Kafka 的分布式消息服務來實現。
在Fabric網路中,一個企業可以有一個或多個節點加入整個聯盟鏈;一個企業可以加入1個或者多個Channel(子網); 一個節點可以加入1個或者多個channel。每個channel構成一個子網,所以Fabric 是 一種由子網組成的網路。
那麼Fabric是怎麼實現智能合約的執行和完成業務上鏈(將事務結果記錄在區塊鏈里)的呢?
與其它框架不同, Fabric 將整個過程分成了三個階段:
業務背書階段 : 客戶的請求發送的背書節點,通過智能合約完成業務的計算(但不更新狀態),並完成背書;將背書結果返回個客戶端。
業務的排序階段 : 客戶端將背書結果通過Channel被發送到排序節點(orderer),在排序節點完成事務的排序,並打包到block里,最後下發給所有連接到channel的節點。
業務驗證並寫入賬本階段 : 通過Gossip 網路,所有Channel的節點都會接收到新的block,節點會驗證block中的每一個事務,確定是否有效:有效地將會跟新world state,無效的將會標志為「無效」,不會更新World state,但整個block會被完整的加入到帳本中(包括無效的事務)。
根據以上的描述,Fabric 節點實際可以分為 ,普通節點和Order節點:
Peer, 普通節點, 完成背書(包括只能合約的執行)和驗證.
orderer, 排序節點,完成排序。
加入orderer節點的Fabric網路可以被描述如下:
每一個Channel,都定義了所有屬於channel的節點,但是並不需要所有節點都連接到Orderer 節點(節點間可以通過gossip 協議通訊來傳播私有數據或事務).
在區塊鏈中,共識是區塊鏈的基礎。與公有鏈不同,聯盟鏈的共識要求所有加入賬本的事務是確定的、最終的,也就是不可以有分叉,區塊與區塊間的順序是一定的,只存在唯一條鏈。在Fabric 中,這個客觀需求正是由排序實現的,所有的事務將被提交給orderer節點獲得確定的順序,並最終打包成block進入帳本。 Fabric 從1.4.1開始支持基於Raft實現排序服務, 可以認為基於Raft實現共識。
基於RAFT的排序服務相對於早期的Kafka 具有更好的分布性,配置更加簡單,是聯盟鏈里常用的一個常用的達成共識的演算法,Quorum就 默認使用RAFT作為共識層。簡單的說,RAFT是一個leader和follower的模式, 所有加入RAFT網路的節點,任意時候都有一個leader, 只有這個leader有權決定事務的順序,並打包成Block,其它節點只能作為follower提交事務和同步block。
基於FAFT網路,每個企業可以有一個或多個節點參與到Orderer中去。在Frabric中企業間的網路連接可以變化成如下形式:
區塊鏈的使用用戶在乙太網中被稱作EOA(External of Account), EOA的載體是錢包。我們沿用這個概念,來看看Fabric是如何實現用戶和發起事務的。Fabric中EOA是一個CA中心發布的certificate(x.509),一個Certificate代表一個Identity(這與以太坊還是有很大區別的, 以太坊中一個EOA其實是一個hash地址),EOA能夠參與的channel以及被授權的操作是有channel的MSP( Membership Service Provider)決定的(如下圖)。
註:certificate 是一種密碼學上驗證身份的通用做法; certificate包含了個人的信息,公鑰以及發布這個certificate的CA的簽名。驗證方只需要擁有這個CA的證書(包含CA的公鑰),就可以驗證這個簽名是否正確,certificate的內容是否有篡改。簡單的說,通過CA和Certificate,我們可以獲得一個可驗證的的身份和信任鏈。
如上圖,fabric中通要使用Wallet作為EOA的載體,一個Wallet中可以包含多個Identity(x.509 certificate)。 Identity 通過 CA提供的信任鏈來驗證正確性。
驗證了身份之後, Fabric 通過MSP在區塊鏈網路中解決該身份是否代表組織的成員和在組織內具有什麼角色。例如,channel首先會驗證當前用戶Identity是否是有效地身份,然後通過MSP查看其所處的企業和具有的角色,最終確定該用戶是否有權執行操作。
可以說,Fabric的訪問控制是通過MSP來完成的。在每一個需要訪問控制的地方都需要定義一個MSP。 例如,每個channel都定義一個MSP,這個MSP規定了在channel范圍內資源的訪問許可權。 MSP 是Fabric里一個晦澀難懂的概念,也是其賦予企業間安全訪問的基礎。
前文提到, Fabric 將業務處理和上網分成了三個部分, 背書,排序,驗證後加入賬本。
其中背書是Fabric執行智能合約的階段。以太坊中,智能合約是在EVM中執行的,有多種語言支持。 在Fabric,智能合約被稱為chaincode: 一個chaincode 可以理解為是智能合約的容器,可以包含一個或多個智能合約, 不用於EVM, chaincode是在 JVM 或NodeJS中執行。
客戶應用程序通過智能合約來訪問賬本,每一個可訪問的智能合約都被安裝在客戶端可以訪問的節點上,並被定義在channel里。(有隻能合約的節點被稱為背書節點,沒有隻能合約的節點被稱未提交節點,提交節點只維護賬本)
客戶應用提交一個交易請求, 請求到達背書節點, 背書節點首先會驗證客戶的簽名,確保客戶的身份有權執行本次交易,接著執行交易提及的智能合約(chaincode),並生成一個背書響應(或者叫做交易提案,tran-proposal)。這個背書響應中通常包含World state 的讀集合,寫集合, 以及節點對本次交易的簽名。這里與以太坊系聯盟鏈最主要的不同是: 背書階段只模擬交易,並不真正更新交易結果。 而真正更新交易在第三階段完成。背書節點最後將生成的背書響應fanhui給客戶端, 智能合約部分的執行就結束了。
通常一個交易的執行需要多方的簽名,所以客戶端需要將一個交易發送給多個背書節點,這些背書節點的選擇需要滿足背書策略的要求。
下圖是一個包含有客戶、背書節點,提交節點的網路示意圖。
根據Fabric官方的參考文檔,客戶交易的正果過程可使用下圖描述。
如上圖,從1到3,為背書階段,4為排序階段,4.1,4,2, 5為驗證提交階段。 參考 Frabic的節點 概念,可以了解更多在交易細節的概念。
總的來看, Fabric 更專注於企業間,通過上文,可以讓大家對Fabric的基本構成與概念有一個總的了解。 Fabric本身並不神秘,都是使用的現有的企業間的技術。要更好的了解,建議參考閱讀分布式消息系統和企業的安全基礎設施(CA相關)的支持。與以太坊系聯盟鏈實現比較, Fabric 的子網更概念對於復雜企業間應用適應更強,但是其復雜的安全考量,使得運營成本很高,另外,Fabric 使用Certificate做為用戶身份,有很大的局限性,在新的2.0里,Fabric對於此處將有所改變。
下一篇,我們將來看看Sawtooth , 由Inter 提供的區塊鏈框架。
區塊鏈之聯盟鏈(一) 認識以太坊
區塊鏈之聯盟鏈(二) 認識Quotum
區塊鏈之聯盟鏈(三) 認識Fabric
區塊鏈之聯盟鏈(四) 認識Sawtooth
7. 對於構建一個垂直領域的區塊鏈應用來說,BaaS能起到什麼作用呢
構建一個垂直領域的區塊鏈應用,投入動輒百萬起步,還需要打通上下游企業,花費大量的時間和精力。這時,BaaS的作用就顯而易見了。趣鏈科技為舟山市岱山縣打造數據開放共創中心就是在底層區塊鏈系統開放的基礎上,運用BaaS解決方案,創造性地構建可插拔架構,實現對多資源介質、多區塊鏈底層、多語言合約的可插拔兼容,輕松獲得快速部鏈、智能研發、可視化監控運維等基礎服務及區塊鏈負載均衡、跨鏈互聯等擴展服務。簡單來說,開發者研發一套應用系統就像搭積木一樣,只需根據業務特徵選擇相應模塊即可快速部署,既簡單、又實用。
8. 百度發布「超級鏈」是為了解決什麼問題
6月4日報道稱,網路區塊鏈首席科學家肖偉日前在2018鏈谷大講堂開幕式上發布了一個新的區塊鏈項目。網路區塊鏈首席科學家肖偉首次發布了網路對於區塊鏈發展的解決方案——「超級鏈」。
中國政府打擊加密貨幣後,網路在2月份移除了所有相關廣告,這幾乎與谷歌等國際同業同步。另一方面,該公司積極開發區塊鏈技術,發布了基於區塊鏈的數碼圖像產權管理平台「圖騰」以及區塊鏈寵物游戲「萊茨狗」。
來源:新浪!
9. 區塊鏈是什麼意思
狹義來講,區塊鏈是一種按照時間順序將數據區塊以順序相連的方式組合成的一種鏈式數據結構,並以密碼學方式保證的不可篡改和不可偽造的分布式賬本。
廣義來講,區塊鏈技術是利用塊鏈式數據結構來驗證與存儲數據、利用分布式節點共識演算法來生成和更新數據、利用密碼學的方式保證數據傳輸和訪問的安全、利用由自動化腳本代碼組成的智能合約來編程和操作數據的一種全新的分布式基礎架構與計算方式。
來源:知乎
10. 國內有哪些知名的區塊鏈雲服務BaaS平台
真正做區塊鏈雲服務BaaS的沒有幾家,經過國家審批認可的就更少了,目前主流的幾家平台是騰訊的TBaaS、京東智臻鏈JDChain、螞蟻區塊鏈BaaS平台、榮澤的RBaaS、網路的智能雲、華為雲BCS這7家,其中排名前四名的BaaS平台都是研發區塊鏈技術好幾年的團隊,研發能力都挺厲害的。