當提到區(qū)塊鏈時，我喜歡用代碼的方式解釋區(qū)塊鏈，以及它與你當前已掌握的開發(fā)知識之間的聯(lián)系。盡管現(xiàn)在很多人都在談?wù)搮^(qū)塊鏈，但由于某些原因，似乎很少有人真正理解這種技術(shù)在我們現(xiàn)有的開發(fā)工具集中的作用。

撇開政治觀點不談，區(qū)塊鏈只不過是我們應(yīng)用程序的一個數(shù)據(jù)層。將來它可能是惟一的持久性層，當然也不一定非要這樣做，也可以在應(yīng)用程序中使用多個這種類型的數(shù)據(jù)層。這里我向你們推薦一個講座，它主要介紹的是關(guān)于我們現(xiàn)在開發(fā)創(chuàng)建相互連接的區(qū)塊鏈時應(yīng)該著重關(guān)注哪些方面，并解釋了這樣做的必要性。

在我們現(xiàn)有的應(yīng)用程序中，我們使用api在一個或多個數(shù)據(jù)庫中存儲信息。區(qū)塊鏈項目也是這樣做的，你可以與API（客戶端或服務(wù)器端）進行交互，以在區(qū)塊鏈中存儲數(shù)據(jù)。

同樣，我們的數(shù)據(jù)庫也有相應(yīng)的模型來構(gòu)造數(shù)據(jù)，比如表格、文檔模型，你可以給它命名，他們都是用來描述數(shù)據(jù)的形態(tài)的。區(qū)塊鏈通常也不一定要遵守這個約定，它們更像是noSql數(shù)據(jù)庫，你可以在存儲數(shù)據(jù)時不去關(guān)心數(shù)據(jù)的格式。但是軟件開發(fā)經(jīng)驗告訴我們，使用非層次數(shù)據(jù)并不一定是個好主意。這就是為什么我們最終使用Mongoose作為MongoDB的工具，它能夠延遲對數(shù)據(jù)建模。因此，在區(qū)塊鏈項目中使用Convector之類的工具，能夠使編寫模型塑造數(shù)據(jù)變得非常簡單和直觀。

相對于數(shù)據(jù)庫的另一個優(yōu)勢（可能是最重要的優(yōu)勢）是存儲過程。存儲過程是存在于數(shù)據(jù)庫本身的邏輯（函數(shù)），它接收數(shù)據(jù)的輸入來執(zhí)行操作。在區(qū)塊鏈開發(fā)中，這通常被稱為智能契約或鏈碼。知道如何編寫這些函數(shù)以及需要考慮的相關(guān)事項是我們所說的區(qū)塊鏈開發(fā)，當然也不要與區(qū)塊鏈核心開發(fā)混淆，后者指的是開發(fā)區(qū)塊鏈技術(shù)本身，或者是數(shù)據(jù)庫引擎。

對軟件開發(fā)人員來說還有一個比較好理解的參考是控制版本系統(tǒng)，如GIT。你對數(shù)據(jù)所做的每一個更改都是版本化的，你可以隨時返回來檢查這些更改。注意：你甚至可以更改區(qū)塊鏈的歷史值！就像你在GIT中做了一個rebase來合并提交或更新消息一樣。但是在GIT和區(qū)塊鏈這兩個環(huán)境中，你最終會得到已更改提交以及所有后續(xù)提交的哈希值。你會得到完全不同的歷史記錄，沒有人會接受來自你的任何更改，因為你偏離了主分支（公開的區(qū)塊鏈版本）。在區(qū)塊鏈中沒有—force強制覆蓋歷史記錄。

區(qū)塊鏈是分散的，智能契約的執(zhí)行必須在不同的計算機上發(fā)生多次，這是區(qū)塊鏈開發(fā)人員在使用區(qū)塊鏈作為數(shù)據(jù)層時必須考慮的分布式計算概念的一部分。

在智能契約執(zhí)行中，可以將其看作GIT中的一個update hook，由包含區(qū)塊鏈副本的節(jié)點執(zhí)行，然后再接收你試圖執(zhí)行的提交。這個hook包含判斷提交作者是否擁有更新存儲庫的權(quán)限的邏輯。你也可以依賴于提交作者的身份驗證，這樣驗證也就只能依靠提交者本人了。

由于你的hook會在所有的對等點執(zhí)行，所以你的操作必須是確定的，因此這里就需要函數(shù)式編程了。你不應(yīng)該依賴全局狀態(tài)（文件系統(tǒng)是全局狀態(tài)）或依賴于外部信息源（如與API的連接或任何網(wǎng)絡(luò)訪問）生成隨機數(shù)。

對于軟件開發(fā)人員來說，區(qū)塊鏈并不是一種罕見的技術(shù)，它的核心功能是建立在我們幾十年前的技術(shù)之上的，就像密碼學(xué)一樣，GIT本身也遵循著今天大多數(shù)區(qū)塊鏈所遵循的核心理念。

我希望這篇文章能夠幫助你在不用深入研究那些困擾你的非常復(fù)雜的術(shù)語的情況下理解這項技術(shù)。