天天看點

如何用架構師思維解讀區塊鍊技術? 比特币要做什麼? 分析和設計 分布式存儲要解決的3個基本問題 區塊鍊的應用

導讀:很多童鞋回報,區塊鍊技術有點繞,有點晦澀,大都是一知半解,了解不夠通徹。但在阿裡技術專家鄭吉看來,區塊鍊特别是比特币本身,并沒有使用高大上複雜的新技術,隻是對現有技術的組合。其天才的地方展現在系統的架構上,展現在把金融學,貨币學,博弈學,甚至是哲學思想展現在比特币的系統架構上。如果單純從系統中的技術點着手學習研究,那麼往往就會覺得有點繞,有點晦澀。這就像我們在平時工作中了解某個系統,如果首先搞清楚業務本身,了解清楚系統架構的設計,再去看具體的實作技術,從大局到面到點,那麼就有豁然開朗的感覺。

今天,鄭吉将試着幫助大家轉換視角,從架構的思維分析去解析比特币,進而對區塊鍊技術有一個更深入的了解。

準備工作

區塊鍊不是一種技術實作,而是一個系統的架構設計,使用一系列的技術組合用于完成去中心化的資料存儲。比特币在區塊鍊之上融入了金融學,貨币學,博弈學,甚至一定程度的哲學思想,用于電子貨币的發行,運作和交易。在學習區塊鍊之前有一些基礎知識需要提前掌握好,後面将不再對具體技術展開描述,而是從這個技術解決了什麼問題,為什麼要用這個技術這個角度去描述。

  • P2P
  • 不可逆算法
  • 不對稱加密算法
  • Merkle樹
  • CAP理論
  • 最終一緻性算法

比特币要做什麼?

如果你是一個架構師,做一個系統的架構,你首先要搞清楚這個系統要做什麼?要解決一個什麼問題?帶着這個問題進行分析,設計系統整體的架構。對于比特币也一樣,首先搞清楚比特币是要做什麼,要解決什麼問題?然後帶着這些問題去解析比特币的技術實作。

如果用一句話來描述比特币要做什麼,那麼可以這樣描述:做一個去中心化電子貨币發行交易系統。這裡有三個關鍵詞:

1. 去中心化

2. 電子貨币發行

3. 電子貨币交易

分析和設計

本章針對上述比特币的三個關鍵詞,去中心化,電子貨币發行,貨币交易,進行分析和設計。

去中心化

當今世界的所有貨币交易都是有一個第三方可信任的金融機構提供服務處理,任何人不能通路由這個第三方機構中心化存儲的資料,理論上來說如果這個金融機構發生了欺詐或倒閉,那麼存儲在這個機構中的貨币,以及所做的交易就會存在風險。 當然比特币的去中心化,不是因為擔心這種風險,而是根本就不需要這個第三方機構了。這也是區塊鍊的強大颠覆性之一,凡是需要某個第三方可信任的機構需要安全儲存處理的資料,都可以去中心化安全存儲,所有人都可以通路。

從技術角度分析,如何做到去中心化?

中心化對應的就是分布式,去中心化就是分布式。把原先存儲在某個第三方機構,中心化存儲的資料,進行分布式存儲。

分布式存儲要解決的3個基本問題

1. 網絡結構

2. 資料不可篡改性

3. 最終一緻性

網絡結構

去中心化的分布式存儲是指整個發行的電子貨币,以及貨币交易資料由不同機構,不通個人的成千上萬的計算機共同存儲,共同維護了同一份相同的資料,隻有共同維護的這份相同的資料才是認為最終正确的資料,任何個人篡改自己的資料都沒有意義,并且存儲的資料所有人都可通路。

如果做為架構師,你會選擇什麼樣的網絡結構去實作這個分布式存儲?一種方式是可采用類似Hadoop中HDFS的方式,由某個中心節點NameNode進行協調通路,但這種方式就會帶來單點風險,破壞了中心節點,整個體系都将不可通路。或者采用Cassandra無中心化投票機制維護整個叢集狀态,但是這種方式在全球化開放式部署中會導緻根本無法收斂。

是以比特币采用了一種更加簡單直接的方式,利用P2P協定維護整個比特币網絡叢集,不需要某個中心節點協調節點之間的通信,不需要所有機器投票維護叢集狀态。而是通過P2P協定進行節點之間的資料傳輸,任何節點都可以随時加入或者離開比特币網絡叢集,而不會對比特币網絡叢集産生影響,也不需要特意去修複這個叢集中的故障機器。

利用P2P協定進行節點之間資料傳輸主要有兩個功能點:

a. 把需要存儲的資料廣播到所有節點上進行儲存。

b. 查詢整個網絡叢集中所有節點的最新資料,如果自己節點的資料與大部分節點的資料不一緻,則更新自身的資料與大部分節點存儲的資料一緻。

比特币是去中心化存儲,最大的風險是整個比特币網絡叢集被破壞,篡改了整個網絡存儲的資料。但是上述第二個功能點能夠有效的防止這種風險,由于系統會自動更新為整個叢集中大部分節點存儲的相同資料,是以要篡改資料,必須要同時篡改整個網絡一半以上的資料,這不是說做不到,但是比特币利用區塊鍊的方式再加上利益博弈機制,當你擁有這種能力的時候,也不需要去做篡改這種投入産出比這麼低的事了,在資料不可篡改性一節中再較長的描述。

通過圖示看一下比特币網絡結構的運作:

Jack把某一筆交易資料往A伺服器上送出,A伺服器驗證資料合法性後存儲到自身的資料庫中,同時把這筆交易資料點對點的傳輸到比特币網絡叢集的所有B,C,D,E節點上。A和所有其它的B,C,D,E節點保持點對點通信,自動更新為這個叢集中大多數節點維護的相同的資料。如果B,C,D三台伺服器儲存的資料相同,但是與A,E不一緻,則A和E自動更新為與B,C,D相同的資料。是以Jack的這筆交易,需要等待這個比特币網絡叢集中所有節點都接受到,并且認為合法存儲後,才認為這筆交易成功完成。當然在現實情況下,不需要等待所有節點都确認完成,通常隻需要少數伺服器确認完成後即可認為交易完成,因為每個伺服器維護的自身與整個網絡叢集的資料狀态,當少量伺服器都認為與整個叢集一緻時,此時從機率上就是一緻的。在最終一緻性一節中将繼續對這種網絡結構下的資料存儲進行描述。

資料不可篡改性

在設計了比特币系統運作的網絡結構之後,需要考慮資料的不可篡改性,因為這種資料存儲是去中心化的,任何人都可以通路,那麼就容易被篡改,上節描述了在這種網絡結構的運作機制下,要篡改資料,必須同時更改這個網絡叢集上一半以上的節點資料,如果每個節點沒有一個安全的保護機制的話,那是很容易做到被同時修改網絡叢集中一半以上節點的資料。

先想想,如果你是架構師,你會如何設計這個保護機制,确儲存儲的資料無法被篡改?在傳統上,我們把交易資料一條記錄一條記錄的儲存在資料庫表中,資料庫放在某個第三方機構的伺服器上,這個第三方機構給伺服器所處的網絡,伺服器,資料庫設定了嚴格的通路限制用于資料的安全性。但是在一個去中心化,沒有一個機構或者一個人可以控制系統的通路權限的情況下,如何去保護資料的安全性?

一種方式是每個人把自己的插入的這條資料hash後用自己的密鑰進行簽名,然後附帶上自己的公鑰,系統可以用簽名和公鑰驗證插入的資料是否被修改過。如果把資料庫表比喻為一本帳本,表中的每一條資料就認為是賬本中記錄的每一筆交易。這裡還有兩個問題,第一,不能随意插入資料,如果你沒有比特币,但還是插入一條轉帳給某人的資料,系統需要發現是不合法的,拒絕此次插入請求。第二,除了不能随意插入和修改外,也需要防止删除資料,上述把每條記錄進行簽名并不能阻止被惡意删除。帶着這些問題,如果你是架構師,你會做什麼樣的架構設計實作這些需求?

這裡就開始要引出區塊鍊的設計了。上面把資料庫表比喻為一本帳本,如果系統中隻有一張表,也就是一本帳本,那麼這本帳本中的資料很容被更改。如果讓系統每10分鐘自動生成一張表,也就是生成一本新帳本,新的交易記錄都記錄在新帳本中。 并且建立這個新帳本需要一定的條件,用目前帳本的順序号,上一個帳本的所有記錄的hash值,系統時間戳(10分鐘一個次元),再找一個随機值,幾個資料加在一起Hash後滿足一定的條件,比如開始多少位都是0,那麼系統就接收這個新帳本。産生的新帳本通過帳本順序号串在上個帳本之後,形成一個帳本的鍊式結構,新的帳本依賴于上一個帳本的資料和目前系統時間戳,是以一旦新帳本産生後,曆史帳本的資料就無法被篡改,因為一旦篡改,就與之後的帳本對不上,帳本被破壞,按照上節網絡結構中描述的自動更新為網絡叢集中大部分節點維護的相同的帳本。

一旦形成了鍊式帳本後就無法去更改某個曆史帳本中的資料,更改了某個曆史帳本,那麼在它之後的所有帳本都需要更改,但是每個帳本都是根據目前的系統時間戳驗證hash值是否滿足條件才能接收,是以無法去篡改曆史帳本的資料。所能做的隻能另外投入非常大的代價再建構一個比特币叢集,這個叢集超過目前的叢集,那麼資料就自動按照新建構的叢集為準。這就是多個帳本的互相保護機制比單個帳本更難以被篡改。後續貨币的發行和交易中再會描述,當你有能力重新建構一個新的比特币網絡叢集用于去攻擊篡改資料時,你獲得的收益将遠遠低于你投入的成本。

為了防止上個帳本的資料被篡改,産生新的帳本需要依賴于上一個帳本中的所有交易記錄的hash值,這樣一旦上個帳本的資料發生變化就與新帳本對應不上。但是帳本中所有交易記錄計算hash值是一件耗時的計算,是以比特币采用了merkle樹對某個帳本中的所有交易記錄進行hash計算。它主要是解決帳本中交易記錄hash計算的效率問題。如下圖HA,HB...HP是具體的交易記錄,每相臨的兩條交易記錄向上形成一個Hash值,再與相鄰的節點再往上形成hash值,一直到樹根形成所有交易記錄的唯一hash值。

之前描述的網絡結構和本節描述的帳本鍊式結構,本質上都是用于解決去中心化的資料安全存儲。

最終一緻性

是分布式存儲就繞不開CAP理論,比特币也一樣,比特币采用P2P協定進行節點之間的資料傳輸,放棄了CAP中的Consistency,采用了AP兩個次元。如果放棄了Consistency這個屬性,那麼就産生了拜占庭将軍問題,這麼多節點如何達成資料一緻性。拜占庭軍隊都是一個個小分隊組成,每個小分隊都有一個将軍負責,将軍們通過号令兵傳達一系列行動,但是當中出現一些叛将,故意破壞号令怎麼辦?

分布式存儲系統和拜占庭将軍問題一樣,做到一緻性是很難的,在比特币開放式的全球化部署的系統叢集更是如此。是以比特币放棄了強一緻性,并且通過P2P點對點通信,沒有中心節點,整個叢集中的伺服器故障,離開,加入叢集都不會對整個叢集産生影響。

上節中描述了帳本的産生基本機制,用目前帳本的順序号,上一個帳本的所有記錄的hash值,系統時間戳(10分鐘一個次元),再找一個随機值,幾個資料加在一起Hash後滿足一定的條件,比如開始多少位都是0,那麼系統就接收這個新帳本,這就是這個叢集中所有節點的共識,所有節點隻接收這樣的帳本,而尋找這個随機值是需要龐大的計算能力。在比特币中稱它為Proof-of-Work(POW)挖礦。

當每隔10分鐘找到這個值,就是生成了新的帳本。但網絡叢集都是開放的,可能同時找到了兩個值,在叢集中少部分節點中産生了2個帳本,針對這種情況比特币系統設計為:整個網絡叢集采用少數服從多數原則,叢集中大部分采用了哪個帳本,少數節點服從多數節點,丢棄沒被大多數采用的帳本,達到最終一緻性。

電子貨币發行

上一章節去中心化中,主要描述了一個去中心化系統,如何做到安全的資料存儲,不被篡改。它主要采用了P2P網絡結構+區塊鍊式結構解決了資料的安全存儲。但是對于一個貨币,還需要解決一個貨币的發行,如何發行,發行給誰?如何讓比特币系統能夠讓所有的人自發的運作下去?貨币的發行需要公平,公開,公正,而且貨币不能發行到某個第三方機構中,任何人隻要符合一定的條件就能擷取發行的貨币。想一想,如果你是架構師,你會如何設計系統去發行貨币?

本質上講,比特币系統自身就可以尋找一個随機值,産生新的帳本。但是比特币把發行貨币和尋找新帳本背後的計算力結合在一起。尋找新帳本需要消耗計算力,誰找到了符合新帳本條件的随機值,代表了他消耗了大量的計算力,新帳本一旦被系統接收,那麼系統自動在該新帳本中記錄一條轉帳給他一定個數比特币的紀錄,就完成了貨币的發行。

比特币的運作必須依賴于新帳本的産生,而誰找到新帳本,誰就能獲得系統自動生成的轉帳紀錄,也就是獲得了一定數量的比特币,這就是挖礦。這也就激勵了人們不斷的投入到挖礦中,不斷的挖出新帳本,通過激勵維持着比特币系統的運作。

這裡展現設計天才的地方是,比特币融入了金融學,貨币學,博弈學,通過系統形成了一定的運作機制,激勵着人們讓這個系統能夠自發的運作下去。

電子貨币交易

上節電子貨币發行一節中描述了,誰通過算力找到了新的帳本,系統就會自動記一筆賬,轉一定數量的比特币給誰,他也就獲得了比特币。那麼如何确認記錄的這筆交易是屬于你的,而不被别人拿走呢?做為架構師的你如何解決這個問題?

比特币采用了非對稱加密技術對使用者的帳戶操作,公鑰就是使用者的帳戶号碼,誰找到了新帳本,系統自動往新帳本發現者的公鑰帳戶,記一條特定數量比特币的紀錄。當使用者要消費比特币時,需要用私鑰進行簽名,系統會用帳戶号碼也就是公鑰驗證簽名是否正确,并且根據使用者的帳戶号碼從曆史的交易中計算出目前帳戶中的真實金額,確定使用者操作的資金在帳戶真實金額之内。這裡的設計有兩個要點:

  1. 插入的每一條紀錄都需要用私鑰簽名,系統用帳戶号碼也就是公鑰進行驗證簽名是否正确,驗證正确則認為合法。
  2. 如果滿足第一個條件,則驗證插入的紀錄中轉帳金額是否正确,驗證的方式是對該公鑰以往的所有交易紀錄進行計算得出該帳戶目前的金額,如果不超過該金額值則為合法。圖示如下:

這種機制能夠保證隻能對自己的帳戶進行操作,再結合P2P網絡結構下的最終一緻性原則,以及帳本的鍊式結構,一個攻擊者需要建立超過目前比特币網絡叢集,并且算力超過目前的叢集下才能建立另外一個帳本分之,而且也隻能更改自己的帳戶,是以這種攻擊投入和産出的收益極低,而對于比特币系統來說,你建構了龐大的叢集以及強大的算力,即使攻擊成功了,獲得了一部分的收益,反過來卻讓比特币系統更加的穩健了。

區塊鍊的應用

比特币系統解決了去中心化的安全存儲問題,解決了貨币的發行問題,解決了貨币交易的帳戶安全問題後,就建構了一個目前的比特币電子虛拟貨币系統了。而比特币使用的區塊鍊被認為是一個颠覆性的技術,革命性的技術,那他的颠覆性展現在什麼地方呢?它不是技術上面的颠覆,主要是在思想層面上的,商業運作模式層面上的革命性。就比如一個國家從集權式的到民主式的轉變,對這個國家和社會就是一個革命性的變化。而區塊鍊技術帶來兩個基本功能:

1. 去中心化的資料存儲

2. 保證帳戶的安全性

理論上讓原先需要通過某個第三方機構提供的資料服務,都可以革命性更改為去中心化的方式提供服務,比如比特币可以替代各個國家的法币使用。區塊鍊這種特性也會衍生出各行各業的商業模式颠覆性的變化。

原文釋出時間為:2018年03月27日

本文作者:技術邊城

本文來源:

CSDN

,如需轉載請聯系原作者。