DA-ChainTalk #5 — 分散式系統

DA-ChainTalk #5 — 分散式系統

各位好,上次我與 @antonsteemit探討了區塊鏈的側鏈概念:

DA-ChainTalk #4 — 側鏈協作的世界

在鏈圈幣圈裡,「中心化」與「分散式」這兩個詞,我們常常聽到,尤其是前者,被當成是壞蛋的感覺,鏈圈人人得而以區塊鏈銖之,邁向「去中心化」的美好境界。也不是不可以,只是,我們真的夠了解網路系統的這些特性嗎?只怕,都是望文生義,不求甚解。固然不會出什麼大錯,但要稱為專家,可能頂多是「磚家」了… lol

沒關係,「DA-ChainTalk」這次與下次,就要來給你加持一下,讓你底氣更足一些!先從「分散式」系統的特徵談起…

此一系列以「DA-ChainTalk」的名稱開頭,您亦可從 #da-chaintalk來追蹤我們的文章。謝謝!


Image Source:https://pplware.sapo.pt

DA-ChainTalk #5 — 分散式系統

前言


相信大家認識區塊鏈的開端,都是比特幣有名的「去中心化分散式電子帳本」。這句話可以說是精準的形容了區塊鏈技術的特性,想要對於區塊鏈有更深的了解,「去中心化」以及「分散式」都是值得我們深入去探討的領域。今天的文章以及下一期的DA Talk,我想要跟各位一起討論這兩個核心的特質,今天就讓我們先從「分散式系統」入手。

什麼是分散式系統?


分散式系統是一門歷史悠久並且已經發展非常完善的學問,先撇開區塊鏈不談,在這個萬物聯網的時代,我們身邊無時無刻不接觸分散式的系統。說的直白一點,只要不是一台電腦自己能完成的任務,都是分散式系統的討論範疇。平常我們常用的ATM就是個最好的例子,如何同步、確定帳戶存款沒有雙花等等,都是分散式系統要解決的問題。

這些問題聽起來可能有些耳熟,因為分散式系統會面臨的問題必定是區塊鏈也必須解決的問題,不過一般的分散式系統跟區塊鏈最大的差別在於,分散式系統不需要符合「去中心化」的條件,這大大降低了這些問題的難度。舉個例子來說,分散式系統可以有著「Master-Slave」這樣的階層關係,讓某些節點負責發出命令。因此如果你對區塊鏈已經略有了解的話,再回頭看分散式系統會覺得問題單純許多。

不過如果我們以「單台電腦作業」為出發點,拓展到「分散式系統」的話,就比較能理解這些問題的為何發生了。接下來我們就簡單介紹分散式系統中的一致性問題、共識機制,以及從CAP理論的角度來看區塊鏈這個分散式系統的特例。

一致性問題

因為分散,所以需要共識(Consensus)

只有一台電腦在運作一個程式時,不會有一致性問題,一個變數是100就是100,如果這個數字沒有要被第二個人用的話,就沒有所謂「相異」或「相同」的問題。但是當有一天,我們必須架設第二個伺服器承擔流量、或是我們的資料庫需要分到不同的節點上運作時,一致性問題就產生了。我們如何讓所有的電腦都了解現在Alice的存款有100元,就是標準的一致性問題,這也是共識演算法(Consensus Algorithm) 的來源:如何讓同一個系統中的不同節點,對於系統中應該一致的「值」保持同步?

共識演算法


在一般分散式系統中最有名的共識算法就是1990年就被提出的Paxos,一種透過兩階段提交來確保共識的演算法(想了解更多可以看這裡)。這種演算法與我們在區塊鏈世界看到的共識協議不太一樣,它只能夠容忍拜占庭錯誤,也就是有一些節點故障、出錯或是離線等等的錯誤,但他並沒有辦法處理「惡意的節點」。

為什麼呢?因為一般的分散式系統是不存在「惡意的節點」的。就像一家銀行,在全世界架設了10000臺的ATM,這些ATM可能時不時有些故障、離線,但是不會存在「故意混亂網路」或是想要「欺騙其他機器」的ATM。一個普通的分散式系統中,所有的節點都是可以被統籌管理,並且可以彼此互信的。這跟區塊鏈有著很大的區別,這也是為什麼區塊鏈應該被視為分散式系統中的一個特例。

所以共識演算法的來源是分散式系統,而區塊鏈因為他去中心化的特質,在這方面的演算法設計勢必更加困難。(我們就留到下一期再仔細介紹去中心化xD)

CAP定理


在分散式系統中有個非常重要的CAP定理:在一個分散式系統的以下三個特性裡,一個系統最多只能同時達到兩項,而不能三者兼顧:

  • (C)一致性 Consistency: 所有節點在任意時間點看到相同結果。
  • (A)可用性 Availability:某些節點失靈不影響其他節點正常回應請求。
  • (P)分區容錯性 Partition tolerance:容忍網路斷線造成的節點無法溝通。

Image Source: Ebook: Distributed System

我們可以這樣理解:如果我們是一個「分區容錯」的系統,當一個網路發生故障、造成兩個節點無法溝通時(Partition發生,這時我們要繼續運作),我們勢必要在C (一致性)與A(可用性)之間做出選擇:因為在沒辦法與另一個節點Node B取得聯繫的情況下,如果我們允許A(可用性、被使用者操作),則我們狀態改變後就無法保持與Node B的一致性;反之,若我們在這時鎖住系統不讓任何人操作,即保持了一致性,但放棄了可用性。

由CAP定理來看區塊鏈


我們剛剛說了,區塊鏈可以當作是分散式系統的一種特例,那他究竟是放棄了CAP定理這三點中的哪一點呢?(放棄A的稱為CP系統、放棄P的稱為CA系統、放棄C的就是AP系統)

答案是,「系統」的定義其實是很廣的,透過不同的Client端設計,我們可以將區塊鏈視為CP或是AP系統。

如果我們單單透過節點的特性來看的話,區塊鏈應該是一個不符合Consistency的AP系統。為什麼呢?因為一旦一筆交易被放到一個Block裡之後,那個節點就會告訴使用者這筆交易成功了。但在區塊鏈的世界裡,大家的帳本是存在歧異的,我們知道有時候鏈會分叉,因此在此時如果你去問另一個節點,它可能還沒收到這個Block,或是它選擇一條不包含此交易的分支,因此同時訪問這兩個節點,得到的結果可能不同,不符合Consistency。

你可能會覺得奇怪,區塊鏈不就主打著安全而且可靠嗎?沒錯,但是共識是需要時間的,尤其在PoW這種模式之下,我們可以保證「長期來看」大家會持有相同的帳本,但卻無法確保每個時間點保有Consistency。

換一個角度說,如果我們的Client端(如錢包)設計成:在確定達成共識之後才認帳,也就是說,不再是一打包就確定扣款,而是在確定這個Block被成功加到鍊上,並且又經過X個區塊在他之上後,才在錢包顯示「轉帳完成」;這樣子設計的系統就變成大家比較信任的,符合Consistency但無法隨時提供Availability的CP系統。像是我們轉帳到交易所時,常常要等待好久才會確定入帳讓我們買賣,就是這種模式。

這就是分散式系統系統設計有趣的地方,同樣是在區塊鏈之上,單看我們如何規定不同的Client行為,就好像是描述兩種截然不同的系統。

結語


說了這麼多,其實是想讓大家回頭來想想,區塊鏈底層還是個「分散式」系統,透過對分散式系統的更多認識,可以讓我們對於區塊鏈所提供的價值有更多理解。我也是最近才開始研究分散式系統,在慢慢探索的過程中也漸漸理解哪些問題是「分散式系統的問題」、哪些問題是「加上去中心化」帶來的問題,這一路學習的過程也讓我更讚嘆「區塊鏈是個神的發明!」

總之,這是我目前學習分散式系統回頭檢視區塊鏈的一些小心得,其實並不多,希望未來越學越深可以再來跟大家分享。那麼,大家就來期待下一篇關於「去中心化」的討論吧!


#da-chaintalk


This page is synchronized from the post: ‘DA-ChainTalk #5 — 分散式系統’

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×