如何在區(qū)塊鏈系統(tǒng)中設(shè)計一個標準共識接口

區(qū)塊鏈系統(tǒng)共識：去中心化的共識

本質(zhì)上，區(qū)塊鏈系統(tǒng)是一個分布式系統(tǒng)，但是與普遍的分布式系統(tǒng)不同。普遍的分布式系統(tǒng)，其意義在于：面對增長的業(yè)務(wù)量，用多臺機器承載垂直拆分或水平拆分后的業(yè)務(wù)場景，增大系統(tǒng)容量；根據(jù)業(yè)務(wù)的關(guān)鍵程度，消除單點故障，加強系統(tǒng)可用性。當一個區(qū)塊鏈系統(tǒng)承擔的業(yè)務(wù)場景復(fù)雜如普遍的分布式系統(tǒng)時，當然也需要做如上的考慮。但是區(qū)塊鏈系統(tǒng)之所以應(yīng)當被人重視，是因為它能夠解決存在作惡節(jié)點情況下的數(shù)據(jù)一致性的問題，也就是拜占庭將軍問題。

區(qū)塊鏈世界中，不存在所謂的中心化服務(wù)器，其是由所有愛好者、受益者或其他相關(guān)人共同構(gòu)成的P2P網(wǎng)絡(luò)，網(wǎng)絡(luò)中的任何一個節(jié)點都是不可直接信任的，它們中的任何一個都有作惡可能，這是普遍的分布式系統(tǒng)并不會考慮的問題。這一點，與拜占庭將軍問題的假設(shè)一致：沒有中心化的領(lǐng)導(dǎo)機構(gòu)，這些將軍需要對某個城市發(fā)起攻擊時，所有將軍需要對任何將軍提出的攻擊時間達成共識。那么問題來了，如果將軍們自己決定的攻擊時間不一致，甚至于有將軍已經(jīng)成為叛徒，那么將軍們?nèi)绾芜_成共識呢？

同理，在區(qū)塊鏈系統(tǒng)這個P2P網(wǎng)絡(luò)中，所有的節(jié)點如何針對某一筆交易達成共識呢（也就是基于這一筆交易對節(jié)點各自的數(shù)據(jù)庫做出修改）？

在1982年的論文The Byzantine Generals Problem中，Leslie Lamport證明，當將軍們中的叛徒不超過1/3時，存在有效的算法，無論叛徒們?nèi)绾握垓v，忠誠的將軍們總能達成一致的結(jié)果。而如果叛徒過多，就無法保證一定能達到一致。

那么我們直接假設(shè)區(qū)塊鏈P2P網(wǎng)絡(luò)中，作惡節(jié)點數(shù)量不超過1/3，否則認為區(qū)塊鏈系統(tǒng)構(gòu)建失敗。如此，接下來最難解決的問題就是，在一個作惡節(jié)點不超過1/3的區(qū)塊鏈系統(tǒng)中，要選擇誰的數(shù)據(jù)作為達成最終共識的數(shù)據(jù)？

換一個角度：如果一個節(jié)點希望自己提供的數(shù)據(jù)能夠在區(qū)塊鏈系統(tǒng)中達成共識，他需要做什么？他需要提供一個Proof。一個證明。去說服區(qū)塊鏈系統(tǒng)接受他所提供的數(shù)據(jù)。

據(jù)此，我們開始討論如何在區(qū)塊鏈系統(tǒng)中設(shè)計一個標準共識接口。

標準共識接口設(shè)計

區(qū)塊鏈達成共識的流程：

1.節(jié)點A準備了一個區(qū)塊，廣播給P2P網(wǎng)絡(luò)；

2.P2P網(wǎng)絡(luò)的其他節(jié)點收到區(qū)塊以后，經(jīng)過一系列驗證，決定是否將該區(qū)塊放在本地的最長鏈上；

3.當區(qū)塊鏈系統(tǒng)中的大多數(shù)節(jié)點（如超過2/3）本地某個區(qū)塊高度對應(yīng)的區(qū)塊哈希值都一致的話，我們就可以認為區(qū)塊鏈針對這個高度的區(qū)塊達成了一致。

如果需要一個服務(wù)來幫助節(jié)點A及區(qū)塊鏈其他節(jié)點完成整個共識過程，那么所提供的服務(wù)應(yīng)該大體上有兩種：

1.面對一無所知的A，需要在A詢問的時候，告知其（在區(qū)塊鏈世界中，A使用一個公鑰唯一確定身份）當前能不能嘗試產(chǎn)生區(qū)塊，以及如何設(shè)法使其產(chǎn)生的區(qū)塊讓其他節(jié)點接受；

2.除了A以外的其他節(jié)點，面對從網(wǎng)絡(luò)上收到的一個A廣播出來的區(qū)塊，通過一個開源的所有節(jié)點實現(xiàn)代碼都一致的服務(wù)來驗證該區(qū)塊是否合法。

如果某節(jié)點通過對這個區(qū)塊的驗證，得知該區(qū)塊合法，則稱該節(jié)點對A產(chǎn)生的這個區(qū)塊達成了共識。因為所有節(jié)點的驗證服務(wù)都是同樣的邏輯，區(qū)塊鏈網(wǎng)絡(luò)中所有節(jié)點對該區(qū)塊的合法性都會具有一樣的態(tài)度，終究，這一個區(qū)塊鏈P2P網(wǎng)絡(luò)中（在沒有更長的鏈出現(xiàn)的情況下）對這個區(qū)塊被添加到最長鏈這個事件達成最終一致性也是可以預(yù)見的。

aelf共識通用接口標準

現(xiàn)在開始，我們基于“標準共識接口設(shè)計”中統(tǒng)計出來的兩類服務(wù)，進行aelf共識通用接口的設(shè)計。

首先需要明確，這兩類和共識相關(guān)的服務(wù)（請求區(qū)塊生產(chǎn)相關(guān)的指示、驗證新區(qū)塊）都是只讀的接口，其調(diào)用本身無需修改區(qū)塊鏈網(wǎng)絡(luò)的賬本信息。

其次，這些接口實際上會被aelf主鏈代碼調(diào)用，因此其設(shè)計需要遵循aelf主鏈代碼中關(guān)于生產(chǎn)區(qū)塊和驗證區(qū)塊的邏輯（當然，即便在主鏈代碼中，這些接口也幾乎一一對應(yīng)地出現(xiàn)在共識的服務(wù)Consensus Service中）。

我們分別討論兩種接口：

請求共識命令

繼續(xù)前面的例子，還是節(jié)點A，這是一個已經(jīng)同步到當前aelf最長鏈的節(jié)點。當前時間是2020年1月1日下午13：59：56。A，作為一個誠實的節(jié)點（沒有修改本地主鏈代碼），剛剛同步了一個區(qū)塊（也就是接受到網(wǎng)絡(luò)上其他節(jié)點的區(qū)塊，驗證成功，修改了本地的區(qū)塊鏈賬本信息），本地的Best Chain（維護本地區(qū)塊鏈的一個數(shù)據(jù)結(jié)構(gòu)）得到更新后，Event Bus上裝載了一個事件。這個事件的作用之一，就是提醒節(jié)點A去問一下共識服務(wù)（通過相關(guān)事件訂閱和處理機制），接下來他能做點什么。在進行詢問時，A把自己的公鑰傳給了共識服務(wù)。

共識服務(wù)的核心邏輯作為一個智能合約而存在，因為只有如此才能保證其代碼對于區(qū)塊鏈世界中每一個節(jié)點都是一致的（不一致意味著這個節(jié)點試圖作惡或者硬分叉）。經(jīng)過長達幾毫秒的復(fù)雜計算（也許是簡單計算），共識的智能合約反饋給節(jié)點A一個信息。這個信息的生成就因共識機制的選取而異，但是無論什么共識，都應(yīng)該具備以下結(jié)構(gòu)：

· A什么時間可以產(chǎn)生區(qū)塊？

· 如果A可以產(chǎn)生區(qū)塊，那么A應(yīng)該用什么方式進行下一步的請求：即在當前共識下，A能產(chǎn)生什么區(qū)塊。在此稱這一信息為額外提示。

如果A不能產(chǎn)生區(qū)塊怎么辦？區(qū)塊鏈世界中理論上每個人其實都有可能產(chǎn)生區(qū)塊，但是由于共識機制的設(shè)計不同（比如PoS共識），有些區(qū)塊鏈并不希望大多數(shù)節(jié)點有生產(chǎn)區(qū)塊的權(quán)利。這種情況下，只需要將返回給A的時間設(shè)置到一百年后就可以（可能有些夸張，但是幾個月后總沒問題）。只要節(jié)點A能夠堅持掛機，并且區(qū)塊鏈沒有產(chǎn)生任何一個新的區(qū)塊（任何有效的新的區(qū)塊的同步都會使節(jié)點A重新獲得一個出塊時間）。

不難想象基于這個接口實現(xiàn)PoW有多么容易。只要時間設(shè)置為“立刻”，額外提示為空即可。

在aelf主鏈中，共識服務(wù)得知共識反饋的時間信息后，會立刻更新共識調(diào)度器（如果此前共識調(diào)度器非空，則干掉之前未竟的調(diào)度信息，用新的時間點來填充，也就是說共識調(diào)度器里面只能有一個未執(zhí)行的共識任務(wù)，且共識調(diào)度器是單例的對象）。

接下來就是漫長的倒計時。

我們回到節(jié)點A這個例子。假設(shè)A在請求共識命令后，得到了一個時間：2020年1月1日下午14：00：00，也就是4秒鐘以后。額外提示：NextRound（這是AEDPoS共識的一個提示，意味著A將終結(jié)本輪的出塊流程，并更新下一輪的所有代理出塊節(jié)點的出塊順序）。這就意味著調(diào)度器會立刻更新為4秒后執(zhí)行一個生產(chǎn)區(qū)塊的事件。這4秒中做什么？如果可以同步到其他節(jié)點發(fā)過來的區(qū)塊，而這些區(qū)塊可以通過驗證，那就使用Best Chain更新這一事件的處理器，不斷地問共識服務(wù)請求共識命令（這一個操作在代碼中稱為TriggerConsensus），相應(yīng)的，共識調(diào)度器就會不斷地重置：3.5秒，3秒，2.5秒，2秒，……

終于，時間來到了14：00：00。節(jié)點A在共識調(diào)度器的支配下開始準備生產(chǎn)區(qū)塊。此時，按照我們之前的設(shè)計，除了已經(jīng)發(fā)揮了作用的出塊時間，關(guān)于如何生產(chǎn)區(qū)塊，它唯一知道的信息只有之前共識服務(wù)給他的額外提示。

這時，在aelf中，節(jié)點A把額外提示信息傳遞給共識服務(wù)。在打包交易之余，還會調(diào)用另外兩個服務(wù)：

· 獲得共識區(qū)塊頭信息

· 獲得共識系統(tǒng)交易

請求共識命令的接口有一個作用是設(shè)法讓生產(chǎn)出來的區(qū)塊通過驗證。在aelf中，在區(qū)塊的一系列驗證步驟中，有兩個和共識相關(guān)的驗證：執(zhí)行前，驗證區(qū)塊頭；執(zhí)行后，對共識合約狀態(tài)的修改信息是否和區(qū)塊頭中的信息的一致性進行驗證。

簡單做個類比，一個.NET程序員去參加DNT線下沙龍，他拿出參加沙龍的邀請短信給沙龍主辦方進行查驗，這個短信類似于區(qū)塊頭，也就是說如果他拿不出邀請短信，那主辦方不會讓他參加。接下來，主辦方還會要求.NET程序員報出手機號，然后在參會人員的花名冊中尋找該手機號，這就類似于在區(qū)塊鏈節(jié)點執(zhí)行完共識交易后的驗證。只有這一步也驗證通過，.NET程序員才能順利參加此次沙龍。

綜上所述，針對“請求共識命令”這一類服務(wù)，我們需要三個接口。用Protobuf直接描述如下：

service ConsensusContract {

rpc GetConsensusCommand （google.protobuf.BytesValue）

returns （ConsensusCommand） {

opTIon （aelf.is_view） = true;

}

rpc GetConsensusExtraData （google.protobuf.BytesValue）

returns （google.protobuf.BytesValue） {

opTIon （aelf.is_view） = true;

}

rpc GenerateConsensusTransacTIons （google.protobuf.BytesValue）

returns （TransacTIonList） {

option （aelf.is_view） = true;

}

}

message ConsensusCommand {

int32 limit_milliseconds_of_mining_block = 2;

// Time limit of mining next block.

bytes hint = 3;

// Context of Hint is diverse according to the consensus protocol we choose， so we use bytes.

google.protobuf.Timestamp arranged_mining_time = 4;

google.protobuf.Timestamp mining_due_time = 5;

}

message TransactionList {

repeated aelf.Transaction transactions = 1;

}

出于對鏈的安全和穩(wěn)定性考慮，在ConsensusCommand中，除了下次出塊時間（arranged_mining_time）和額外提示（hint），還包括了出塊時間限制（limit_milliseconds_of_mining_block）和最晚廣播時間（mining_due_time）。后面兩個信息都是給區(qū)塊生產(chǎn)服務(wù)作為參考的，用來實現(xiàn)如果超過了某個時間限制，生產(chǎn)出來的區(qū)塊就無需廣播（或者即便廣播別的節(jié)點也不能通過驗證，當然這個驗證是在下面要討論的接口類型的具體實現(xiàn)中保證的）；多生產(chǎn)出一個塊也比擾亂區(qū)塊生產(chǎn)秩序要好。

區(qū)塊驗證

如果說請求共識命令還值得細致討論的話，區(qū)塊驗證相關(guān)的接口就泛善可陳了。因為區(qū)塊驗證邏輯本質(zhì)上是完全因共識而異的。

接口本身并無新意，一個是在共識交易執(zhí)行前驗證區(qū)塊頭，一個是共識交易執(zhí)行后驗證共識修改的狀態(tài)是否和區(qū)塊頭中承諾的信息一致。而兩個驗證接口的入?yún)⒍际嵌M制數(shù)組，意味著該接口接受任何數(shù)據(jù)，只需要共識的實現(xiàn)者在驗證的具體實現(xiàn)中自行反序列化即可。