自2018年末推出以來，Lisk改進建議（或LIPs）與Lisk社區(qū)密切合作，幫助改善了生態(tài)系統(tǒng)。我們通過這個過程引入的許多網(wǎng)絡(luò)特性之一是新的拜占庭容錯（BFT）共識系統(tǒng)。在這篇博客文章中，我們已經(jīng)討論了Lisk協(xié)議共識算法的優(yōu)點。在Lisk SDK 3.0.0中實現(xiàn)它之前，我想關(guān)注BFT共識的一個重要方面——計算塊終結(jié)的過程，即保證某個特定塊永遠不會被還原。

BFT的主要好處是什么？

在深入討論這個主題之前，讓我們快速瀏覽一下BFT在區(qū)塊鏈上改進的基本關(guān)鍵特性。

1. 安全性：如果網(wǎng)絡(luò)中超過 2/3 的活動委托誠實地遵循協(xié)議，則兩個沖突塊永遠無法在鏈上最終確定。

2. 活性：即使 1/3 的活動委托脫機，新塊仍可在網(wǎng)絡(luò)上完成。

3. 問責(zé)制：如果代表違反議定書，他/她將對此負責(zé)。

這是BFT為協(xié)議提供的三個高級值。它試圖盡快從分叉中恢復(fù)過來，以更好地完成網(wǎng)絡(luò)鏈的增長。這些特性都需要更廣泛的理解。在這里，我們將更多地關(guān)注實現(xiàn)細節(jié)。

使用BFT共識，每個節(jié)點不僅僅維護了區(qū)塊鏈。它還在內(nèi)存中維護額外的元數(shù)據(jù)，以便根據(jù)算法定義的規(guī)則驗證塊。此信息還將部分保存在區(qū)塊鏈本身上，以確保節(jié)點在崩潰時可以重建內(nèi)存中的數(shù)據(jù)集。對于每個塊，我們額外保留到區(qū)塊鏈的一個屬性是委托之前鍛造的高度和鍛造該塊時預(yù)投票的最大高度。與此同時，每個節(jié)點將保持最終確定的高度，因此在鏈恢復(fù)的情況下，已經(jīng)確定的塊不能被恢復(fù)。

讓我們進入今天的主題——代表們?yōu)閴K投票。

為塊進行民主投票

在Lisk生態(tài)系統(tǒng)中，投票并不是什么新鮮事——它是所有授權(quán)的權(quán)益關(guān)系證明（DPoS）協(xié)商共識算法的核心。LSK代幣持有者可以為代表投票，然后，根據(jù)他們的投票，系統(tǒng)選擇有資格為特定一輪鑄造新區(qū)塊的最高代表。以前，投票制度只用于為代表投票。隨著BFT的引入，這一概念得到了擴展?，F(xiàn)在，每個委托者將為每個塊投一票，唯一的區(qū)別是這些票將由各個節(jié)點維護和保存。只有少數(shù)計算出來的屬性將與網(wǎng)絡(luò)共享，而不是與整個投票分類賬共享。系統(tǒng)中的數(shù)學(xué)公式和協(xié)議檢查將確保每個節(jié)點投出適當?shù)倪x票。

與任何投票系統(tǒng)一樣，基本規(guī)則是，作為一個代表，您只能對特定高度的塊投一次票。由于兩個塊不能在同一高度上存在，所以實際上可以為每個塊投一次票。這個過程稱為預(yù)投票。收集到塊?以上的選票（多數(shù)）有資格獲得下一輪的投票。

第二輪投票稱為預(yù)提交，規(guī)則相同 - 一名代表可以預(yù)先提交一個塊，合格的塊即意味著已經(jīng)獲得了超過2/3的所有預(yù)投票。最終確定的最高塊將被視為鏈的最終高度。所有高度低于最終確定的塊也將被視為最終確定塊，在任何情況下都不能還原。

還有一些其他的規(guī)則：

1. 代表不能預(yù)先投票，也不能預(yù)先提交他們沒有參與的那輪投票的區(qū)塊。這樣做是為了避免垃圾投票。因此，我們需要跟蹤委托何時開始活動。

2. 代表不能提預(yù)投票和預(yù)提交超過兩輪，以提高整個系統(tǒng)的性能。

示例場景#1—四個委托，都是偽造的

為了更好地理解這個概念，讓我們舉一個小例子。假設(shè)網(wǎng)絡(luò)中有四個活動的委托。完成任何塊——至少?（三個代表）必須同意。

4名代表-全部鍛造

讓我們通過一個數(shù)據(jù)模擬來進一步理解這一點。

1. 應(yīng)用區(qū)塊鏈時，需要檢查以下信息： 代表先前偽造的高度、已獲得?的區(qū)塊鏈中最高高度以及上一次委托處于活動狀態(tài)的輪數(shù)

2. 委托檢查前預(yù)提交和使所有導(dǎo)向塊?票為止?？紤]到規(guī)則，該委托不能兩次預(yù)提交相同的塊。委托也不能預(yù)先提交未激活的塊。此外，由于性能原因，我們不會在鏈的當前高度之后的超過兩輪執(zhí)行這些預(yù)提交。

3.在每個塊上，委托將對所有塊進行預(yù)投票。考慮到委托不能對同一個塊進行兩次預(yù)投票的規(guī)則。代表不能在不活躍的時候提前投票。此外，出于性能原因，我們不會從當前鏈的高度執(zhí)行超過兩輪的預(yù)提交。

4. 如圖所示，鏈中的第一個塊在高度6處有三個預(yù)提交。這意味著該塊已經(jīng)完成，并且永遠不會被還原。

5. 鏈中的其余塊顯然應(yīng)用于鏈。為了解決網(wǎng)絡(luò)中的分叉問題，可以適當恢復(fù)這些分叉。

6. 你可能會注意到的塊?選票增加前的預(yù)提交。擁有更多預(yù)投票的塊將有更多的預(yù)提交，并且有更多的機會被最終確定。

有一個重要的事實需要記住——終結(jié)性不是針對單個塊的，而是針對特定塊的高度。如果完成了一個塊，這意味著它下面的所有塊也都完成了。由于委托列表（確定鍛造順序的列表）中的更改，最終結(jié)果并不總是按順序遞增的。這意味著有可能有幾個塊沒有完成，但是下一個塊將會更早完成。在這種情況下，所有先前的塊，高度低于剛剛完成的塊，也將被視為完成。

示例場景#2—四個委托，缺少插槽

為了進一步理解這個預(yù)投票和預(yù)提交流程，讓我們以具有相同四個代表的模擬為例，但是這一次代表開始丟失他們的插槽。這導(dǎo)致鏈的最終性沒有平穩(wěn)地增長，而是在最終塊之間有間隙。

在這個數(shù)據(jù)模擬中，您將注意到第一個最終確定的塊位于高度6，而鏈位于高度11。之所以會出現(xiàn)這種情況，是因為代表們錯過了名額，無法預(yù)投票，也無法預(yù)先對之前的區(qū)塊做出提交。但是由于高度6已經(jīng)確定，所以在該高度之前的所有塊也將被認為是最終確定的。

示例場景#3 -五個委托，全部切換

現(xiàn)在讓我們再舉一個例子，有五名代表正在偽造，但在第三輪之后，他們都被其他代表取代了。

在這個模擬中需要注意的關(guān)鍵事實是，最終的高度是如何從高度1持續(xù)增長到高度15的。然后從15到30保持靜止狀態(tài)。在每個塊上，委托仍然為新塊投票，但是由于委托不能在非活動期間預(yù)先提交任何塊，所以它們沒有預(yù)先提交舊塊。網(wǎng)絡(luò)將會增長，但不會考慮最后確定任何塊。

示例場景#4 - 11個委托，一個委托開關(guān)

這個用例更類似于一個真實的網(wǎng)絡(luò)，在這個網(wǎng)絡(luò)中，委托列表在幾輪中保持一致，然后只有少數(shù)幾個委托交換它們的位置。在這個數(shù)據(jù)模擬中，我們還增加了委托的數(shù)量，這產(chǎn)生了一組令人難以置信的數(shù)字。

在這個例子中，我們可以看到這個網(wǎng)絡(luò)的最終結(jié)果是連續(xù)增長到33，然后停止一段時間（4個塊）。最終結(jié)果又開始增長。這種行為更接近實際生活中的網(wǎng)絡(luò)。

為什么要進行這些模擬呢？

您可能想知道為什么我們要完成并開發(fā)所有這些數(shù)據(jù)密集型的模擬，盡管邏輯已經(jīng)被記錄下來了。但理解邏輯部分是復(fù)雜的，可能會在實現(xiàn)過程中導(dǎo)致錯誤。這些數(shù)據(jù)模擬使我們對數(shù)據(jù)流有了清晰的理解，并可視化了BFT共識性在各種情況下的行為。

與此同時，這些數(shù)據(jù)模擬幫助我們?yōu)閷崿F(xiàn)編寫測試，這不僅使實現(xiàn)變得合理，而且為我們提供了擴展和添加更多測試場景的方法。

我們希望這些數(shù)據(jù)模擬也能幫助您更好地理解BFT共識建議。再次重申，本文只涉及BFT LIP的一個方面，即預(yù)投票和預(yù)提交。在LIP中還有很多，比如分叉的選擇規(guī)則和分叉的恢復(fù)機制，這些結(jié)合起來就可以完成拜占庭式的容錯共識。
來源；區(qū)塊網(wǎng)