原本，這篇文章的標(biāo)題是《區(qū)塊鏈所預(yù)示的未來(lái)，需要什么樣的基礎(chǔ)設(shè)施？》，后來(lái)我反復(fù)想了好久，突然有一個(gè)有趣的念頭緊緊的拽住了我，于是我完全沉迷其中無(wú)法自拔，只能放棄原來(lái)的寫(xiě)作內(nèi)容與提綱，而是努力試圖將自己的這個(gè)設(shè)想，闡述明白。當(dāng)然，這還遠(yuǎn)遠(yuǎn)稱(chēng)不上一份白皮書(shū)!

一、區(qū)塊鏈的本質(zhì)是什么？

有人說(shuō)是：分布式數(shù)據(jù)庫(kù)；有人說(shuō)是：分布式賬本；還有人會(huì)進(jìn)一步說(shuō)明：就是一種以分布式方式記錄賬本的數(shù)據(jù)庫(kù)，但是，這個(gè)數(shù)據(jù)庫(kù)只能添加、讀取，不能修改，刪除。

在苦思冥想的過(guò)程中，我突然想到：什么“賬本”呀，這完全就是一套版本控制系統(tǒng)。

• 除了初始提交，每一個(gè)提交都會(huì)有父提交——全部的提交歷史，也構(gòu)成了一個(gè)鏈，每一個(gè)commit，也可以說(shuō)是一個(gè)block。
• 如果不經(jīng)過(guò)特殊操作，所有的提交都不會(huì)消失，只會(huì)增加——區(qū)塊鏈在這方面的限制更加嚴(yán)格。

所以：我們也許可以借助對(duì)版本管理系統(tǒng)的理解，來(lái)理解區(qū)塊鏈。

二、聯(lián)想：SVN與Git的區(qū)別

更遠(yuǎn)的版本管理系統(tǒng)，咱們不去提他，單說(shuō)SVN與Git的區(qū)別：

SVN的版本號(hào)，是一個(gè)自增長(zhǎng)的數(shù)字，因此，只能有一條鏈。

Git的版本號(hào)，是一串Hash值，不存在必須自增長(zhǎng)的限制，因此Git的版本樹(shù)形狀會(huì)非常多樣，通稱(chēng)DAG（有向無(wú)環(huán)圖）。

如果每一個(gè)節(jié)點(diǎn)，記錄世界上的一批交易的話，我們就會(huì)發(fā)現(xiàn)SVN與Git的兩種模式，存在性能上的巨大差距。因?yàn)镾VN記錄的交易，必須是串行的，任憑世界上同時(shí)發(fā)生多少交易，都必須依次記錄！相比之下，Git的版本，就不必嚴(yán)格依序發(fā)生，最后的版本合并，也容易得多，這就是使得Git的并發(fā)性能，會(huì)好很多！

如果我沒(méi)有理解錯(cuò)誤的話：IOTA的DAG Tangle，應(yīng)該受到Git的很多啟發(fā)。

三、繼續(xù)完善我們的設(shè)想——基于Git的分布式記賬系統(tǒng)

1. 創(chuàng)造一個(gè)初始賬戶(hù)

1. 建一個(gè)空的git倉(cāng)庫(kù)
2. 創(chuàng)建一個(gè)root account文件，內(nèi)容是：100000000
3. 創(chuàng)建一個(gè)初始提交：init root account, 100000000

2. 新增一個(gè)賬戶(hù)A，并且從root得到轉(zhuǎn)賬

1. 新建一個(gè)文件A，內(nèi)容是：+20 from root
2. 修改root文件，添加一行：-20 to A
3. 創(chuàng)建第二次提交：root to A, 20

3. 如上所述，再創(chuàng)建第二個(gè)賬戶(hù)B，也從root得到轉(zhuǎn)賬

1. 新建一個(gè)文件B，內(nèi)容是：+20 from root
2. 修改root文件，添加一行：-20 to B
3. 創(chuàng)建第三次提交：root to B, 20

4. 創(chuàng)建一個(gè)fork倉(cāng)庫(kù)，包含原來(lái)的全部賬本

5. 原始倉(cāng)庫(kù)繼續(xù)發(fā)生交易

1. 新建一個(gè)文件C，內(nèi)容是：+20 from root
2. 修改root文件，添加一行：-20 to C
3. 創(chuàng)建第四次提交：root to C, 20

6. 在fork倉(cāng)庫(kù)中，發(fā)生另一次交易

1. 修改A文件，內(nèi)容是：-10 to B
2. 修改B文件，內(nèi)容是：+10 to A
3. 創(chuàng)建一次新的提交：A to B, 10

7. 原始倉(cāng)庫(kù)合入fork倉(cāng)庫(kù)的變更

1. fork倉(cāng)庫(kù)發(fā)起一次pull request
2. 原始倉(cāng)庫(kù)accept pull request
3. 由于兩邊的文件變更不存在沖突，所以合入直接完成，A向B轉(zhuǎn)賬的交易，也被計(jì)入主線
4. fork倉(cāng)庫(kù)同步原始倉(cāng)庫(kù)的版本（git pull），fork倉(cāng)庫(kù)的賬本同步至最新版本

四、基于Git的分布式記賬系統(tǒng)——要點(diǎn)

1. 每一臺(tái)Git Server，就是一個(gè)賬本庫(kù)

因此，一筆交易的雙方，可以選擇任意一臺(tái)服務(wù)器，記錄他們的交易。前提是：

• 這臺(tái)服務(wù)器上的賬本，是最新的（至少保存了交易雙方賬本的最新版本）；
• 交易雙方都信任這臺(tái)服務(wù)器的記錄是準(zhǔn)確，且及時(shí)的；
• 理論上，這臺(tái)服務(wù)器提供了轉(zhuǎn)賬與記賬的服務(wù)，可以收取服務(wù)費(fèi)。

2. 交易雙方經(jīng)過(guò)協(xié)商，可以選擇任何一臺(tái)服務(wù)器進(jìn)行交易，并且支付費(fèi)用

因此，賬本服務(wù)器，存在競(jìng)爭(zhēng)關(guān)系。理論上，以下優(yōu)點(diǎn)將幫助交易服務(wù)器勝出：

• 交易賬本數(shù)據(jù)最新最全（這是核心競(jìng)爭(zhēng)力，否則交易速度將會(huì)變慢）
• 交易記錄速度最快
• 交易費(fèi)用最低（這需要一個(gè)平衡）

3. 數(shù)據(jù)同步成功率與服務(wù)可信度

為了確保自己的服務(wù)器上，擁有最新最全的數(shù)據(jù)。各家服務(wù)器都會(huì)有動(dòng)力，頻繁的拉取其他服務(wù)器的賬本數(shù)據(jù)（git pull）。

可能存在這樣的現(xiàn)象：A拉取B服務(wù)器的數(shù)據(jù)，但是出現(xiàn)了版本沖突，因?yàn)橛匈~戶(hù)x，同時(shí)在A、B記錄了兩筆不同的交易。理論上，需要B先拉取A服務(wù)器的數(shù)據(jù)，然后A才能成功拉取B服務(wù)器的數(shù)據(jù)。類(lèi)似于我們git push之前，需要先git pull.

當(dāng)A服務(wù)器拉取失敗時(shí)，他有義務(wù)通知B服務(wù)器：“你的版本太老”。于是B服務(wù)器會(huì)拉取A服務(wù)器的數(shù)據(jù)。當(dāng)A服務(wù)器再次重試時(shí)，拉取成功了。

于是，長(zhǎng)期來(lái)看，A服務(wù)器拉取B服務(wù)器的數(shù)據(jù)，就會(huì)有一個(gè)成功率的記錄。我們也可以記錄，某臺(tái)服務(wù)器，針對(duì)其他所有服務(wù)器的拉取請(qǐng)求，其成功率的數(shù)據(jù)。這樣的數(shù)據(jù)，就代表其服務(wù)可信度。

4. 可信度最高的服務(wù)器，通常為了確保其數(shù)據(jù)的及時(shí)與準(zhǔn)確性，需要投入大量的成本，他們的交易服務(wù)費(fèi)用，也將會(huì)比較高（好的服務(wù)，當(dāng)然應(yīng)該貴一些）

于是：我們得到了一個(gè)良性的，分布式多中心的，交易賬本系統(tǒng)！

五、三種交易類(lèi)型與應(yīng)對(duì)策略

1. 最簡(jiǎn)單的交易，就是發(fā)生在兩個(gè)賬戶(hù)之間的

參考復(fù)式記賬法，一筆交易我們至少需要同時(shí)修改兩個(gè)文件，因此我們需要確保在那臺(tái)git server上，兩個(gè)賬戶(hù)文件都已經(jīng)是最新版本了：

賬戶(hù)A說(shuō)：我的賬戶(hù)地址是XXXX1，我的最新版本是YYYY1，你可以去以下服務(wù)器查證。

賬戶(hù)B說(shuō)：我的賬戶(hù)地址是XXXX2，我的最新版本是YYYY2，你可以去以下服務(wù)器查證。

兩個(gè)賬戶(hù)，都可以選擇更加保守的策略，在更多的服務(wù)器上，互相查證對(duì)方的賬戶(hù)版本，是否為最新，并且最終商議出一個(gè)雙方共同認(rèn)可的交易服務(wù)器。

假設(shè)找不到一臺(tái)服務(wù)器，同時(shí)保存了雙方賬戶(hù)的最新版本，那就只能等待某一臺(tái)服務(wù)器，最終同步到了最新的版本，然后再執(zhí)行交易。

2. 對(duì)于頻繁收錢(qián)，或者頻繁支出的賬戶(hù)，如果每次都需要交易雙方協(xié)調(diào)版本，那交易成本就太高了

以頻繁收錢(qián)的賬戶(hù)為例，他可以對(duì)外公布一個(gè)自己的收款地址+服務(wù)器地址。所有的支付者，都到這個(gè)服務(wù)器上，與他交易。

付款者向指定服務(wù)器發(fā)出付款要求，指定服務(wù)器首先同步付款者的賬戶(hù)到最新版，交易服務(wù)器完成交易。

對(duì)于收款者而言，并發(fā)的支付請(qǐng)求，在交易服務(wù)器上被批量處理并記錄。不必嚴(yán)格遵守交易的先后次序，只要最終被全部記錄且數(shù)據(jù)一致即可。

頻繁支出的賬戶(hù)，也可以按類(lèi)似方式處理。

3. 從個(gè)人賬戶(hù)到銀行賬戶(hù)

如果是個(gè)人對(duì)個(gè)人的交易，大家都是從我的錢(qián)包到你的錢(qián)包，這樣的交易可以和具體的交易服務(wù)器無(wú)關(guān)，也可以說(shuō)每次交易都可以選擇任意的交易服務(wù)器。但是，如果是經(jīng)常存在賬戶(hù)進(jìn)出的情況，那么選擇在某家“銀行”開(kāi)戶(hù)，就變成很自然的事情。

過(guò)去是從個(gè)人錢(qián)包發(fā)起交易，每次選擇交易記賬的服務(wù)?，F(xiàn)在變成直接委托某個(gè)交易服務(wù)器，完成進(jìn)出。那么，不僅僅是完成數(shù)字貨幣進(jìn)出，也完全可以將一部分?jǐn)?shù)字貨幣，保存在那個(gè)“銀行”里。這樣當(dāng)然會(huì)更加方便快捷。

后續(xù)的發(fā)展，我們可以想象：現(xiàn)在的銀行能夠?yàn)榭蛻?hù)提供哪些服務(wù)，今后的數(shù)字貨幣銀行，同樣也有機(jī)會(huì)提供出來(lái)。

六、聯(lián)想與結(jié)語(yǔ)

1.本文未完善之處

我沒(méi)有深入去思考：如何達(dá)成信任這件事情?；蛘哒f(shuō)：我認(rèn)為通過(guò)算法保障信任，其實(shí)非常危險(xiǎn)。因?yàn)榻^大多數(shù)人，是無(wú)法真正理解算法，最后也只能是盲目信任。所以，信任只能來(lái)自于歷史上是否清白，是否存在污點(diǎn)？算法公開(kāi)是不夠的，數(shù)據(jù)要公開(kāi)，過(guò)程要公開(kāi)，所有歷史數(shù)據(jù)，都需要公開(kāi)，這樣才能夠談得上信任。

換言之，信任不是0/1的選擇，信任是一個(gè)X%的事情。我對(duì)這個(gè)服務(wù)有80%的信任，于是我愿意冒著20%的風(fēng)險(xiǎn)，去使用這一服務(wù)，如此而已。

沒(méi)有深入思考算法與協(xié)議的細(xì)節(jié)：為了實(shí)現(xiàn)一個(gè)幾乎沒(méi)有漏洞的架構(gòu)，我現(xiàn)在大概只能算是完成了1%的工作，開(kāi)了一個(gè)頭而已。要是有朋友對(duì)于這個(gè)架構(gòu)，也非常感興趣，大家倒是可以一起研究一下。

2.未來(lái)的數(shù)字貨幣架構(gòu)

一個(gè)逐漸完善的架構(gòu)，肯定是分層、分模塊，多個(gè)組件是可以組合/替換的。目前的大多數(shù)公鏈，都想的是打造一個(gè)完整的，全面可用的架構(gòu)，我覺(jué)得他們多半都會(huì)失敗。但是，有誰(shuí)能夠構(gòu)造一個(gè)類(lèi)似于TCP/IP這一的協(xié)議族呢？我非常期待！

作者：莊表偉

鏈接：https://www.jianshu.com/p/d2f1e9bd56ea

本文由 @莊表偉 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自網(wǎng)絡(luò)