NEO主網(wǎng)升級后已穩(wěn)定運行超過62小時，本次升級中較為重要的改進便是NEO dBFT 2.0。為了讓大家更多地了解dBFT 2.0，NEO核心開發(fā)者Jeff Solinsky在Medium上發(fā)布了以下內(nèi)容介紹其優(yōu)勢。

翻譯來自：https://neo.org/fwlink/31

概述

NEO有很多創(chuàng)新性的特性，其目標(biāo)愿景是實現(xiàn)一種智能經(jīng)濟。特性中重要的是快速的一次出塊最終確定性以及支持快速高效的編寫智能合約。為了實現(xiàn)一次出塊，但最終確定，NEO采用了dBFT（委托拜占庭容錯）的協(xié)議，它在pBFT（實用拜占庭容錯）協(xié)議的基礎(chǔ)上做了適量的修改?？梢哉f，要想成功實現(xiàn)一種BFT共識協(xié)議，最大的挑戰(zhàn)在于正確處理由于網(wǎng)絡(luò)延遲和節(jié)點重啟而可能引發(fā)的邊緣情況故障。

對于一種旨在推進可適用于日常業(yè)務(wù)需求的金融交易（智能經(jīng)濟）的區(qū)塊鏈而言，保證網(wǎng)絡(luò)可用性是至關(guān)重要的。在本文中，我將描述使用dBFT 1.0時遇到的問題，及近期NEO主網(wǎng)部署了dBFT2.0共識協(xié)議后，協(xié)議所做的改進功能是如何消除這些問題的。

背景

為了能夠更好地理解dBFT 2.0的優(yōu)點，有必要先對共識協(xié)議的一些操作細節(jié)有一定的了解。諸如NEO的dBFT之類的BFT算法需要收集到大約2/3的驗證人節(jié)點的簽名才能達成共識。對于dBFT協(xié)議而言，其中F是允許的故障節(jié)點數(shù)，下面的公式給出了所需的驗證人節(jié)點數(shù)和所需簽名數(shù)。

· F=允許的故障節(jié)點數(shù)

· 驗證人節(jié)點=3F+1

· 所需簽名數(shù)=2F+1

NEO 1.0協(xié)議中節(jié)點要達成共識需要經(jīng)過以下幾個階段：

1. PrepareRequest：驗證人節(jié)點會輪流被選為議長節(jié)點，由議長節(jié)點將交易打包到當(dāng)前區(qū)塊，并發(fā)起提案。對區(qū)塊高度進行簡單的取模運算可以用來確定區(qū)塊的第一驗證人。

2. PrepareResponse：接收到PrepareRequest消息的驗證人節(jié)點會驗證區(qū)塊中所有交易的有效性，驗證通過后會在發(fā)送的PrepareResponse響應(yīng)消息中附上它們的簽名。

3. 收到2F+1 條PrepareResponses消息后，共識節(jié)點將創(chuàng)建一個帶有簽名的新區(qū)塊。

如果在當(dāng)前超時時間內(nèi)未收集到所需的簽名數(shù)，那么節(jié)點將發(fā)送一條ChangeView消息來選擇上一個區(qū)塊的議長作為議長。超時時間初始值是出塊時間的2倍，之后每次超時都會加倍，直到生成新的區(qū)塊為止。一旦收到2F+1條更改視圖的消息，該過程將從步驟1開始再次重復(fù)執(zhí)行。

問題

NEO的dBFT 1.0算法在出現(xiàn)網(wǎng)絡(luò)延遲的極少數(shù)情況下可能會受到單一區(qū)塊分叉的影響。很長一段時間以來大家都知道有這個問題，并且也有相關(guān)的文檔（例如這篇文章：https://neo.org/fwlink/32）記載。可能會產(chǎn)生分叉區(qū)塊的原因是，算法允許節(jié)點在發(fā)送完P(guān)repareResponse消息后出現(xiàn)超時。由于共識節(jié)點的時鐘永遠都不會（將來也永遠不會）是100%完全同步的，節(jié)點會出現(xiàn)超時并在很小的時間差內(nèi)轉(zhuǎn)向下一個驗證人節(jié)點。如果所有驗證人節(jié)點中有且只有一個出現(xiàn)了超時，并且該驗證人已經(jīng)收到了2F條 PrepareResponse消息，那么它會生成一個有效的帶有簽名的區(qū)塊，而其他驗證人節(jié)點則會切換到下一個議長節(jié)點，在那里他們可以達成共識，并在同一高度對另一個區(qū)塊進行簽名。此時，共識節(jié)點只能建立在其中一個分叉鏈上；所以這個問題有時也被稱為區(qū)塊叉勺。雖然這種情況可能在沒有停止共識的情況下發(fā)生，但許多NEO的全節(jié)點可能會接受分叉的區(qū)塊并停止運行，從而導(dǎo)致終端用戶最終所依賴的網(wǎng)絡(luò)節(jié)點出現(xiàn)操作性問題。

解決方案

dBFT 2.0通過添加類似于pBFT（實用拜占庭容錯）文檔中所描述的提交階段來解決這個問題。為了防止網(wǎng)絡(luò)中斷，dBFT 2.0還在共識協(xié)議中添加了一種恢復(fù)消息機制。在共識節(jié)點出現(xiàn)各種操作問題時，恢復(fù)機制還會帶來一個額外的好處，那就是改進出塊的時間。在以下情況下性能會得到改善：

· 網(wǎng)絡(luò)連接不良，例如由于網(wǎng)絡(luò)中斷或針對共識節(jié)點的網(wǎng)絡(luò)攻擊。

· 由于硬件故障、斷電或其他系統(tǒng)問題，共識節(jié)點進程重新啟動或系統(tǒng)重新啟動。

dBFT 2.0的實現(xiàn)使得對共識節(jié)點任何不當(dāng)行為的審計過程具有可見性。共識節(jié)點會跟蹤已發(fā)生的所有提交，不允許任何其他共識節(jié)點在給定高度上提交對多個可能區(qū)塊的簽名。共識節(jié)點的共識日志使得共識節(jié)點的操作人以及啟用了共識watch-only模式的任何全節(jié)點都可以很容易地獲取這一信息。

測試和質(zhì)量保證

為了確保dBFT 2.0實現(xiàn)的代碼質(zhì)量，代碼更改經(jīng)歷了多個測試階段。NEO核心開發(fā)人員使用NEO的P2P插件在私有網(wǎng)絡(luò)中進行了大量測試，模擬網(wǎng)絡(luò)故障。在NGD管理的私有網(wǎng)絡(luò)中也進行了類似的自動和手動測試。最后，代碼在NEO的公共測試網(wǎng)上進行了測試。

結(jié)論

自6月3日發(fā)布以來，NEO 2.10.2現(xiàn)在正運行在主網(wǎng)的共識節(jié)點上，今天的實踐操作中我們可以看到出塊時間的減少，這也是dBFT 2.0所做的一些改進，如下圖1和圖2所示。此外，通過這次升級，NEO共識節(jié)點現(xiàn)在正運行著能提高內(nèi)存池性能的代碼，這進一步減少了網(wǎng)絡(luò)上的操作負擔(dān)，并確保在網(wǎng)絡(luò)出現(xiàn)更高交易量的期間，可以最小化出塊的時間。

采納并使用于Point-of-Sale

NEO dBFT 2.0的開發(fā)本來是作為NEO3計劃的改進內(nèi)容的，但現(xiàn)在已經(jīng)提前可以在NEO 2.x上使用了。由于dBFT 2.0已經(jīng)在主網(wǎng)上線并投入使用，企業(yè)在生產(chǎn)中使用NEO時所面臨的絕大多數(shù)運營問題都已不再是問題。隨著這個機制的實現(xiàn)，NEO網(wǎng)絡(luò)在銷售點交易上的使用將會得到蓬勃發(fā)展。

為了在Point-of-Sale中最有效地使用加密貨幣，必須同時滿足高可用性和快速最終確定性的要求。即使使用諸如支付渠道之類的第二層解決方案，可以實現(xiàn)近乎即時的Point-of-Sale交易，但在該類渠道還沒建立的情況下，能夠在短時間內(nèi)打開一個渠道也是很重要的。隨著dBFT 2.0共識的改進，NEO現(xiàn)在具備了這種可靠性，而這也是讓更多企業(yè)能夠開始使用NEO區(qū)塊鏈用于Point-of-Sale解決方案所必需的。

來源： NEO智能經(jīng)濟