技術點解讀 | aelf共識標準設計

區塊鏈系統共識：去中心化的共識

本質上，區塊鏈系統是一個分佈式系統，可是與廣泛的分佈式系統不一樣。廣泛的分佈式系統，其意義在於：面對增加的業務量，用多臺機器承載垂直拆分或水平拆分後的業務場景，增大系統容量；根據業務的關鍵程度，消除單點故障，增強系統可用性。當一個區塊鏈系統承擔的業務場景複雜如廣泛的分佈式系統時，固然也須要作如上的考慮。可是區塊鏈系統之因此應當被人重視，是由於它可以解決存在做惡節點狀況下的數據一致性的問題，也就是拜占庭將軍問題。區塊鏈世界中，不存在所謂的中心化服務器，其是由全部愛好者、受益者或其餘相關人共同構成的P2P網絡，網絡中的任何一個節點都是不可直接信任的，它們中的任何一個都有做惡可能，這是廣泛的分佈式系統並不會考慮的問題。這一點，與拜占庭將軍問題的假設一致：沒有中心化的領導機構，這些將軍須要對某個城市發起***時，全部將軍須要對任何將軍提出的***時間達成共識。那麼問題來了，若是將軍們本身決定的***時間不一致，甚至於有將軍已經成爲叛徒，那麼將軍們如何達成共識呢？同理，在區塊鏈系統這個P2P網絡中，全部的節點如何針對某一筆交易達成共識呢（也就是基於這一筆交易對節點各自的數據庫作出修改）？在1982年的論文The Byzantine Generals Problem中，Leslie Lamport證實，當將軍們中的叛徒不超過1/3時，存在有效的算法，不管叛徒們如何折騰，忠誠的將軍們總能達成一致的結果。而若是叛徒過多，就沒法保證必定能達到一致。那麼咱們直接假設區塊鏈P2P網絡中，做惡節點數量不超過1/3，不然認爲區塊鏈系統構建失敗。如此，接下來最難解決的問題就是，在一個做惡節點不超過1/3的區塊鏈系統中，要選擇誰的數據做爲達成最終共識的數據？換一個角度：若是一個節點但願本身提供的數據可以在區塊鏈系統中達成共識，他須要作什麼？他須要提供一個Proof。一個證實。去說服區塊鏈系統接受他所提供的數據。據此，咱們開始討論如何在區塊鏈系統中設計一個標準共識接口。

標準共識接口設計

區塊鏈達成共識的流程：

1.節點A準備了一個區塊，廣播給P2P網絡；

2.P2P網絡的其餘節點收到區塊之後，通過一系列驗證，決定是否將該區塊放在本地的最長鏈上；

3.當區塊鏈系統中的大多數節點（如超過2/3）本地某個區塊高度對應的區塊哈希值都一致的話，咱們就能夠認爲區塊鏈針對這個高度的區塊達成了一致。

若是須要一個服務來幫助節點A及區塊鏈其餘節點完成整個共識過程，那麼所提供的服務應該大致上有兩種：

1.面對一無所知的A，須要在A詢問的時候，告知其（在區塊鏈世界中，A使用一個公鑰惟一肯定身份）當前能不能嘗試產生區塊，以及如何設法使其產生的區塊讓其餘節點接受；

2.除了A之外的其餘節點，面對從網絡上收到的一個A廣播出來的區塊，經過一個開源的全部節點實現代碼都一致的服務來驗證該區塊是否合法。

若是某節點經過對這個區塊的驗證，得知該區塊合法，則稱該節點對A產生的這個區塊達成了共識。由於全部節點的驗證服務都是一樣的邏輯，區塊鏈網絡中全部節點對該區塊的合法性都會具備同樣的態度，終究，這一個區塊鏈P2P網絡中（在沒有更長的鏈出現的狀況下）對這個區塊被添加到最長鏈這個事件達成最終一致性也是能夠預見的。

aelf共識通用接口標準

如今開始，咱們基於「標準共識接口設計」中統計出來的兩類服務，進行aelf共識通用接口的設計。

首先須要明確，這兩類和共識相關的服務（請求區塊生產相關的指示、驗證新區塊）都是隻讀的接口，其調用自己無需修改區塊鏈網絡的帳本信息。

其次，這些接口實際上會被aelf主鏈代碼調用，所以其設計須要遵循aelf主鏈代碼中關於生產區塊和驗證區塊的邏輯（固然，即使在主鏈代碼中，這些接口也幾乎一一對應地出如今共識的服務Consensus Service中）。

咱們分別討論兩種接口：

請求共識命令

繼續前面的例子，仍是節點A，這是一個已經同步到當前aelf最長鏈的節點。當前時間是2020年1月1日下午13：59：56。A，做爲一個誠實的節點（沒有修改本地主鏈代碼），剛剛同步了一個區塊（也就是接受到網絡上其餘節點的區塊，驗證成功，修改了本地的區塊鏈帳本信息），本地的Best Chain（維護本地區塊鏈的一個數據結構）獲得更新後，Event Bus上裝載了一個事件。這個事件的做用之一，就是提醒節點A去問一下共識服務（經過相關事件訂閱和處理機制），接下來他能作點什麼。在進行詢問時，A把本身的公鑰傳給了共識服務。

共識服務的核心邏輯做爲一個智能合約而存在，由於只有如此才能保證其代碼對於區塊鏈世界中每個節點都是一致的（不一致意味着這個節點試圖做惡或者硬分叉）。通過長達幾毫秒的複雜計算（也許是簡單計算），共識的智能合約反饋給節點A一個信息。這個信息的生成就因共識機制的選取而異，可是不管什麼共識，都應該具有如下結構：

· A什麼時間能夠產生區塊？

· 若是A能夠產生區塊，那麼A應該用什麼方式進行下一步的請求：即在當前共識下，A能產生什麼區塊。在此稱這一信息爲額外提示。

若是A不能產生區塊怎麼辦？區塊鏈世界中理論上每一個人其實都有可能產生區塊，可是因爲共識機制的設計不一樣（好比PoS共識），有些區塊鏈並不但願大多數節點有生產區塊的權利。這種狀況下，只須要將返回給A的時間設置到一百年後就能夠（可能有些誇張，可是幾個月後總沒問題）。只要節點A可以堅持掛機，而且區塊鏈沒有產生任何一個新的區塊（任何有效的新的區塊的同步都會使節點A從新得到一個出塊時間）。

不難想象基於這個接口實現PoW有多麼容易。只要時間設置爲「馬上」，額外提示爲空便可。

在aelf主鏈中，共識服務得知共識反饋的時間信息後，會馬上更新共識調度器（若是此前共識調度器非空，則幹掉以前未竟的調度信息，用新的時間點來填充，也就是說共識調度器裏面只能有一個未執行的共識任務，且共識調度器是單例的對象）。

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

咱們回到節點A這個例子。假設A在請求共識命令後，獲得了一個時間：2020年1月1日下午14：00：00，也就是4秒鐘之後。額外提示：NextRound（這是AEDPoS共識的一個提示，意味着A將終結本輪的出塊流程，並更新下一輪的全部代理出塊節點的出塊順序）。這就意味着調度器會馬上更新爲4秒後執行一個生產區塊的事件。這4秒中作什麼？若是能夠同步到其餘節點發過來的區塊，而這些區塊能夠經過驗證，那就使用Best Chain更新這一事件的處理器，不斷地問共識服務請求共識命令（這一個操做在代碼中稱爲TriggerConsensus），相應的，共識調度器就會不斷地重置：3.5秒，3秒，2.5秒，2秒，……

終於，時間來到了14：00：00。節點A在共識調度器的支配下開始準備生產區塊。此時，按照咱們以前的設計，除了已經發揮了做用的出塊時間，關於如何生產區塊，它惟一知道的信息只有以前共識服務給他的額外提示。

這時，在aelf中，節點A把額外提示信息傳遞給共識服務。在打包交易之餘，還會調用另外兩個服務：· 得到共識區塊頭信息

· 得到共識系統交易

請求共識命令的接口有一個做用是設法讓生產出來的區塊經過驗證。在aelf中，在區塊的一系列驗證步驟中，有兩個和共識相關的驗證：執行前，驗證區塊頭；執行後，對共識合約狀態的修改信息是否和區塊頭中的信息的一致性進行驗證。

簡單作個類比，一個.NET程序員去參加DNT線下沙龍，他拿出參加沙龍的邀請短信給沙龍主辦方進行查驗，這個短信相似於區塊頭，也就是說若是他拿不出邀請短信，那主辦方不會讓他參加。接下來，主辦方還會要求.NET程序員報出手機號，而後在參會人員的花名冊中尋找該手機號，這就相似於在區塊鏈節點執行完共識交易後的驗證。只有這一步也驗證經過，.NET程序員才能順利參加這次沙龍。

綜上所述，針對「請求共識命令」這一類服務，咱們須要三個接口。用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;}

出於對鏈的安全和穩定性考慮，在ConsensusCommand中，除了下次出塊時間（arranged_mining_time）和額外提示（hint），還包括了出塊時間限制（limit_milliseconds_of_mining_block）和最晚廣播時間（mining_due_time）。後面兩個信息都是給區塊生產服務做爲參考的，用來實現若是超過了某個時間限制，生產出來的區塊就無需廣播（或者即使廣播別的節點也不能經過驗證，固然這個驗證是在下面要討論的接口類型的具體實現中保證的）；多生產出一個塊也比擾亂區塊生產秩序要好。

區塊驗證

若是說請求共識命令還值得細緻討論的話，區塊驗證相關的接口就泛善可陳了。由於區塊驗證邏輯本質上是徹底因共識而異的。

接口自己並沒有新意，一個是在共識交易執行前驗證區塊頭，一個是共識交易執行後驗證共識修改的狀態是否和區塊頭中承諾的信息一致。而兩個驗證接口的入參都是二進制數組，意味着該接口接受任何數據，只須要共識的實現者在驗證的具體實現中自行反序列化便可。service ConsensusContract { rpc ValidateConsensusBeforeExecution (google.protobuf.BytesValue) returns (ValidationResult) { option (aelf.is_view) = true; } rpc ValidateConsensusAfterExecution (google.protobuf.BytesValue) returns (ValidationResult) { option (aelf.is_view) = true; }}message ValidationResult { bool success = 1; string message = 2; bool is_re_trigger = 3;}