在很多關於bft的共識演算法中，都說在拜占庭節點為 f 個的時候，要保證整體的節點數至少要3f+1。在**中是這麼描述的：當有f個節點是故障的時候，至少要有3f+1個節點來保障系統的安全性和活性。需要3f+1個節點是因為在系統中可能存在f個故障節點，而收到的訊息中，有f個訊息可能是錯誤的，因此需要收到的訊息中有至少f+1個是正確的。因此整個系統至少要保證3f+1個節點。
這裡將故障節點和拜占庭節點做了區分，誠實節點不回訊息即為故障，拜占庭節點會回訊息但可能全部是假訊息。
前提：所有節點的狀態機初始狀態是一致的
primary：收到client的requst,傳送<,m>給其他節點，其中v代表當前輪次，n是共識的序列號，d是訊息m的hash, m是訊息。
replica：
1、驗證request
replica（包含primary）：
1、收集prepare訊息，至少f+1個非拜占庭節點的訊息，實際應收到不少於2f（primary不傳送prepare訊息，如果傳送的話就是2f+1）個訊息。
2、commit, 廣播
replica：收集commit訊息，至少f+1個非拜占庭節點的訊息，實際應收到不少於2f+1個訊息，將結果返回給client
pbft的2階段投票分別為pre-prepare->prepare,prepare->commit 2個階段。(3階段協議，2次投票)
其中pre-prepare -> prepare節點用來確定同乙個view下各個節點的request的順序是一致的
prepare->commit階段用於確定各個節點commit的順序是一致的。
假設0輪投票：
replica收到request就進行提交，無法確定自己收到的跟其他節點收到的是一致的，會很容易導致分叉。如主節點是拜占庭節點，傳送不同的request給不同的節點。
假設1輪投票：
replica進行一輪投票後進行提交，此時雖然節點收到了足夠的投票來證明其他節點收到的request是一致的，但無法確定其他節點是否收到了足夠數量的投票。因此只有1輪投票會出現自己提交而其他節點沒有提交的情況。
備忘：hotstuff需要3輪投票也是一樣的原因，需要多一輪投票是因為hotstuff的網路模型是投票發給leader，而不是廣播。
因此可以認為replica在收到第一輪投票結果的時候確認了 各個節點request順序是一致的，在收到第二輪投票結果的時候確認了 各個節點都收到了第一輪投票（即各個節點都知道其他節點request順序與自己一致），在收到第三輪投票結果的時候可以確認多數節點都會提交相同的request，因此提交request。
如果缺失了一輪投票，2次投票後就提交request。那replica就無法確定其他的replica是否會提交相同的區塊，因為投票結果是leader傳送的，有可能leader只將第二次投票結果發給了一部分replica，而另一部分replica因為一些原因（網路原因或者leader造假）導致沒有收到第二次投票結果所以不會提交request。
關於Web路徑的備忘
在處理web頁上一大堆連線的時候，常常被一些相對路徑搞得很迷糊，現在整理一下，當作是提醒備忘。其實，很簡單，只是老是不記住。呵 通常我們遇到的相對路徑會有下面三種情況，下面一一來舉例說明。一 以 為首字母的路徑，其完整路徑將會是主機名加上該路徑名 article實際指向 http hostname ...
關於加密解密備忘
在資料傳輸中,同一定遇到unicode一樣,你一定會遇到加密問題.下面說說我的理解.一.對稱演算法,非對稱演算法.有加密就有解密,解密和解密都要用到乙個或多個密碼,俗稱金鑰.金鑰一致的就是對稱演算法,而不一致的就是非對稱演算法.非對稱如同你在乙個門上放了兩把鎖一樣,鑰匙不同,也可以解鎖.對稱,就是一...
關於Ajax中URL的備忘
ajax中的url有絕對路徑和相對路徑之分 專案部署路徑為 http jsy 005 8080 xy plan 注 jsy 005 1.如果ajax中url寫成如下的格式 ajax error function err 那麼，最後的請求路徑為 這是因為url中以 開頭，意思是直接找到當前頁面的url...