各位好，上次我與 @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