微軟首席架構師Yaron Goland最近發表了一篇文章，講述了一個區塊鏈客戶端如何可以被實現為AP的或CP的，這取決于它的實現方式。具體是要可以配置在一個事務結束之后必須有多少個區塊收到這個事務，才認為它可以被接受了。在事務之后接收到它的區塊越多，它就越可能獲得系統范圍內的共識，即一致性。
一個區塊鏈就是一套點對點的分布式數據庫，沒有中心節點可以決定數據正確與否。Goland講述到在諸如比特幣之類的數字貨幣等場景下，這個問題尤其會造成巨大的困擾。可能用戶以為他已經用真實的貨幣換到了比特幣，可是等了一會他去查看自己的錢包時，卻發現比特幣不翼而飛了。
可是區塊鏈只是一系列的不可變的數據塊，而且非常可能每個節點都各自構建起一套不同的事務歷史鏈。這樣的背離叫做分枝，也是Goland的例子中一致性問題的根源所在。他解釋了區塊鏈是如何用一致性算法解決這個問題的，最終會有絕大多數達成一致，拋棄掉某些分枝。
“這是最終一致性的一個非常經典的例子。兩個相互沖突的值被記錄下來，系統在內部各節點之間進行通信，最終使用一種沖突解決協議來選出優勝者。”
Goland指出，選擇是否等待區塊鏈最終變成一致的，這決定了客戶端是AP的還是CP的。要成為AP的，一旦事個事務被加入到區塊鏈中，客戶端就要馬上接受它。這樣，就沒有對其它節點的依賴，并且可以使數據可用，但這里有個風險，就是別的節點有可能會拒絕這個事務，因而這樣做犧牲了一致性。如果想要成為CP的，客戶端就應該在區塊鏈針對某個事務達成了一致決議之后，才接受它。這樣做的負面影響在于，數據的確一致了，但在有網絡分區問題存在時卻可能會阻礙一致性的達成，從而使數據不可用。
關于如何等待一個事務達成系統內一致性的問題，Goland，總結起來就是：“直到至少有X個區塊同意之后，才能認為某件事發生了”。這就意味著一個事務發生之后，客戶端必須等待，直到再有X個區塊也收到了，才能接受它。
Yanos還強調，讓客戶端在這個方面成為可配置的，這樣做并不違反CAP原理。因為這樣的配置方法是在可用性和一致性之間做出的權衡——是不可能同時擁有這兩種特性的：
“所以我們上面解釋的并不是在說比特幣如何能既是AP的又是CP的。我們上面只是在講述如何通過完全不同的CAP權衡來構建兩種完全不同的系統，方法就是除了客戶端之外，讓比特幣的所有部分都保持相同。”
總之，Goland證明了盡管區塊鏈是一種點對點的模型，強一致性的需求仍然是可以被滿足的。這對于比特幣之類的數字貨幣來說尤其重要，因為這種權衡意味著用戶可以信任事務的結果。
閱讀英文原文：The Blockchain and the CAP Theorem
京公網安備 11010502049343號