md_blockchain是一個Java區(qū)塊鏈平臺，基于Springboot開發(fā)的區(qū)塊鏈平臺。

理想中的區(qū)塊鏈平臺：

項目說明

主要有存儲模塊、網(wǎng)絡模塊、PBFT共識算法、加密模塊、區(qū)塊解析入庫等。

該項目屬于"鏈"，非"幣"。不涉及虛擬幣和挖礦。

存儲模塊

Block內存儲的是類Sql語句。聯(lián)盟間預先設定好符合業(yè)務場景需要的數(shù)據(jù)庫表結構，然后設定好各個節(jié)點對表的操作權限（ADD，UPDATE，DELETE），將來各個節(jié)點就可以按照自己被允許的權限，進行Sql語句的編寫，并打包至Block中，再全網(wǎng)廣播，等待全網(wǎng)校驗簽名、權限等信息的合法性。如果Block合法，則進入PBFT共識算法機制，各節(jié)點開始按照PrePrepare、Prepare、Commit等狀態(tài)依次執(zhí)行，直到2f+1個commit后，開始進行本地生成新區(qū)塊。新區(qū)塊生成后，各節(jié)點進行區(qū)塊內容解析，并落地入庫的操作。

場景就比較廣泛了，可以設定不同的表結構，或者多個表，進而能完成各自類型信息的存儲。譬如商品溯源，從生產(chǎn)商、運輸、經(jīng)銷商、消費者等，每個環(huán)節(jié)都可以對某個商品進行ADD信息的操作。

存儲采用的是key-value數(shù)據(jù)庫rocksDB，了解比特幣的知道，比特幣用的是levelDB，都是類似的東西?？梢酝ㄟ^修改yml中db.levelDB為true，db.RocksDB為false來動態(tài)切換使用哪個數(shù)據(jù)庫。

結構類似于sql的語句，如ADD（增刪改） tableName（表名）ID（主鍵） JSON（該記錄的json）。這里設置了回滾的邏輯，也就是當你做了一個ADD操作時，會同時存儲一條Delete語句，以用于將來可能的回滾操作。

網(wǎng)絡模塊

網(wǎng)絡層，采用的是各節(jié)點互相長連接、斷線重連，然后維持心跳包。網(wǎng)絡框架使用的是t-io，也是oschina的知名開源項目。t-io采用了AIO的方式，在大量長連接情況下性能優(yōu)異，資源占用也很少，并且具備group功能，特別適合于做多個聯(lián)盟鏈的SaaS平臺。并且包含了心跳包、斷線重連、retry等優(yōu)秀功能。

在項目中，每個節(jié)點即是server，又是client，作為server則被其他的N-1個節(jié)點連接，作為client則去連接其他N-1個節(jié)點的server。同一個聯(lián)盟，設定一個Group，每次發(fā)消息，直接調用sendGroup方法即可。

但仍需要注意的是，由于項目采用了pbft共識算法，在達到共識的過程中，會產(chǎn)生N的3次方數(shù)量的網(wǎng)絡通信，當節(jié)點數(shù)量較多，如已達到100時，每次共識將會給網(wǎng)絡帶來沉重的負擔。這是算法本身的限制。

共識模塊PBFT

分布式共識算法是分布式系統(tǒng)的核心，常見的有Paxos、pbft、bft、raft、pow等。區(qū)塊鏈中常見的是POW、POS、DPOS、pbft等。

比特幣采用了POW工作量證明，需要耗費大量的資源進行hash運算（挖礦），由礦工來完成生成Block的權利。其他多是采用選舉投票的方式來決定誰來生成Block。共同的特點就是只能特定的節(jié)點來生成區(qū)塊，然后廣播給其他人。

區(qū)塊鏈分如下三類：

私有鏈：這是指在企業(yè)內部部署的區(qū)塊鏈應用，所有節(jié)點都是可以信任的，不存在惡意節(jié)點；

聯(lián)盟鏈：半封閉生態(tài)的交易網(wǎng)絡，存在不對等信任的節(jié)點，可能存在惡意節(jié)點；

公有鏈：開放生態(tài)的交易網(wǎng)絡，為聯(lián)盟鏈和私有鏈等提供全球交易網(wǎng)絡。

由于私有鏈是封閉生態(tài)的存儲系統(tǒng)，因此采用Paxos類共識算法（過半同意）可以達到最優(yōu)的性能；聯(lián)盟鏈有半公開半開放特性，因此拜占庭容錯是適合選擇之一，例如IBM超級賬本項目；對于公有鏈來說，這種共識算法的要求已經(jīng)超出了普通分布式系統(tǒng)構建的范疇，再加上交易的特性，因此需要引入更多的安全考慮。所以比特幣的POW是個非常好的選擇。

我們這里可選的是raft和pbft，分別做私鏈和聯(lián)盟鏈，項目中我使用了修改過的pbft共識算法。

先來簡單了解pbft：

（1）從全網(wǎng)節(jié)點選舉出一個主節(jié)點（Leader），新區(qū)塊由主節(jié)點負責生成。

（2）每個節(jié)點把客戶端發(fā)來的交易向全網(wǎng)廣播，主節(jié)點將從網(wǎng)絡收集到需放在新區(qū)塊內的多個交易排序后存入列表，并將該列表向全網(wǎng)廣播。

（3）每個節(jié)點接收到交易列表后，根據(jù)排序模擬執(zhí)行這些交易。所有交易執(zhí)行完后，基于交易結果計算新區(qū)塊的哈希摘要，并向全網(wǎng)廣播。

（4）如果一個節(jié)點收到的2f（f為可容忍的拜占庭節(jié)點數(shù)）個其它節(jié)點發(fā)來的摘要都和自己相等，就向全網(wǎng)廣播一條commit消息。

（5）如果一個節(jié)點收到2f+1條（包括自己）commit消息，即可提交新區(qū)塊到本地的區(qū)塊鏈和狀態(tài)數(shù)據(jù)庫。

（6）客戶端收到f + 1個成功（即便有f個失敗、再f個惡意返回的錯誤信息，f + 1個正確的也是多數(shù)派）的返回，即可認為該次寫入請求是成功的。

可以看到，傳統(tǒng)的pbft是需要先選舉出leader的，然后由leader來搜集交易，并打包，然后廣播出去。然后各個節(jié)點開始對新Block進行校驗、投票、累積commit數(shù)量，最后落地。

而我這里對pbft做了修改，這是一個聯(lián)盟，各個節(jié)點是平等的，而且性能要高。所以我不想讓每個節(jié)點都生成一個指令后，發(fā)給其他節(jié)點，再大家選舉出一個節(jié)點來搜集網(wǎng)絡上的指令組合再生成Block，太復雜了，而且又存在了leader節(jié)點的故障隱患。

我對pbft的修改是，不需要選擇leader，任何節(jié)點都可以構建Block，然后全網(wǎng)廣播。其他節(jié)點收到該Block請求時即進入Pre-Prepare狀態(tài)，校驗格式、hash、簽名、和table的權限，校驗通過后，進入Prepare狀態(tài)，并全網(wǎng)廣播狀態(tài)。待自己累積的各節(jié)點Prepare的數(shù)量大于2f+1時，進入commit狀態(tài)，并全網(wǎng)廣播該狀態(tài)。待自己累積的各節(jié)點Commit的數(shù)量大于2f+1時，認為已達成共識，將Block加入?yún)^(qū)塊鏈中，然后執(zhí)行Block中sql語句。

很明顯，和有l(wèi)eader時相比，缺少了順序的概念。有l(wèi)eader時能保證Block的順序，當有并發(fā)生成Block的需求時，leader能按照順序進行廣播。譬如大家都已經(jīng)到number=5的區(qū)塊了，然后需要再生成2個，有l(wèi)eader時，則會按照6、7的順序來生成。而沒有l(wèi)eader時，則可能發(fā)生多節(jié)點同時生成6的情況。為了避免分叉，我做了一些處理，具體的可以在代碼里看實現(xiàn)邏輯。

區(qū)塊信息查詢

各節(jié)點通過執(zhí)行相同的sql來實現(xiàn)一個同步的sqlite數(shù)據(jù)庫（或mysql等其他關系型數(shù)據(jù)庫），將來對數(shù)據(jù)的查詢都是直接查詢sqlite，性能高于傳統(tǒng)的區(qū)塊鏈項目。

由于各個節(jié)點都能生成Block，在高并發(fā)下會出現(xiàn)區(qū)塊不一致的情況。如果因為某些原因導致鏈分叉了，也提供了回滾機制，sql可以回滾。原理也很簡單，你ADD一個數(shù)據(jù)時，我會在區(qū)塊里同時記錄兩個指令，一個是ADD，一個是回滾用的DELETE。同理，UPDATE時也會保存原來的舊數(shù)據(jù)。區(qū)塊里的sql落地，譬如順序執(zhí)行1-10個指令，回滾時就是從10-1執(zhí)行回滾指令。

每個節(jié)點都會記錄自己已經(jīng)同步了的區(qū)塊的值，以便隨時進行sql落地入庫。

對區(qū)塊鏈信息的查詢，那就簡單了，直接做數(shù)據(jù)庫查詢即可。相比于比特幣需要檢索整個區(qū)塊鏈的索引樹，速度和方便性就大不同了。