TW202037138A - 共識系統停機時間恢復 - Google Patents
共識系統停機時間恢復 Download PDFInfo
- Publication number
- TW202037138A TW202037138A TW108144879A TW108144879A TW202037138A TW 202037138 A TW202037138 A TW 202037138A TW 108144879 A TW108144879 A TW 108144879A TW 108144879 A TW108144879 A TW 108144879A TW 202037138 A TW202037138 A TW 202037138A
- Authority
- TW
- Taiwan
- Prior art keywords
- preparation
- node
- message
- messages
- nodes
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Abstract
用於共識系統停機時間恢復的方法、系統和設備,包括編碼在電腦儲存媒體上的電腦程式。所述方法之一包括:從主節點獲取預準備訊息;將指示接受所述預準備訊息的準備訊息組播到所述主節點和其他(N-2)個備用節點中的至少一些節點;分別從(Q-1)個或更多個所述備用節點獲得(Q-1)個或更多個準備訊息;儲存所述預準備訊息和所述(Q-1)個或更多個準備訊息;向所述主節點和其他備用節點中的至少一些節點組播提交訊息,所述提交訊息指示該備用節點同意所述(Q-1)個或更多個準備訊息;分別從所述主節點和所述備用節點中的Q個或更多個節點獲得Q個或更多個提交訊息,所述Q個或更多個提交訊息各自指示相應節點同意(Q-1)個或更多個準備訊息。
Description
本發明一般有關用於共識系統和方法的方法和設備,尤其有關實用拜占庭容錯(PBFT)共識系統和方法。
實用拜占庭容錯(PBFT)是一種可以在分散式系統如區塊鏈系統中實現的共識機制。PBFT共識機制使得分散式系統能夠在安全性和活躍性方面達成足夠的共識,儘管系統的某些節點可能發生故障(例如,由於網路連接不良或以其他方式變得有故障)或向其他對等方傳播不正確的資訊(例如,惡意行動)。這種機制的目的是透過減輕無作用節點對系統的正確功能的影響以及對由系統中作用節點(例如,無故障和誠實節點)達成的共識的影響來抵禦災難性的系統故障。
PBFT共識機制偏重於透過假設存在獨立節點故障和由特定並獨立的節點傳播的操縱訊息來提供容忍拜占庭故障(例如,無作用節點)的實用拜占庭狀態機複製。例如,在這種PBFT共識機制中,區塊鏈系統中的所有節點按順序排序,其中一個節點是主節點(也稱為領導節點或主控節點),其他節點稱為備用節點(也稱為從屬節點)。系統內的所有節點彼此通訊,並且目標是讓所有誠實節點對系統狀態達成一致/共識。
例如,為了使PBFT共識機制起作用,假設在給定的漏洞視窗中,區塊鏈系統中的無作用節點的數量不能同時等於或超過系統中總節點數的三分之一。只要至多F個節點同時是無作用節點,該方法就有效地提供活躍性和安全性。換句話說,在一些實現中,PBFT共識機制可以容忍的無作用節點的數量F等於(N-1)/3向下取最接近整數,其中,N表示系統中的節點總數。在一些實現中,實現PBFT共識機制的區塊鏈系統可以處理多達F個拜占庭故障,其中,總共存在至少3F+1個節點。
PBFT共識機制通常包括正常操作協定(也稱為三階段協定)和視域更改協定,其中,提供正常操作協定以確保機制的安全性,提供視域更改協定以確保機制的活躍性。正常階段協定按順序主要包括三個階段,即預準備階段、準備階段和提交(commit)階段。所有階段都是訊息驅動的,即透過在目前階段獲得足夠數量的訊息來觸發協定中的下一個階段。正常操作協定下的整個過程的進展高度取決於在每個階段連續接收的足夠數量的訊息。即使在視域更改協定中,所述過程的進展也是基於正常操作協定中的準備訊息。因此,可以看出,PBFT共識機制極大地依賴於一致性資訊來運行。如果一個或多個節點變得無功能(例如,遇到停機和重啟),則儲存在記憶體中的訊息將丟失,從而影響整個共識過程,甚至引起不一致。
本說明書的各種實施例包括但不限於用於共識系統停機時間恢復的系統、方法和非暫態性電腦可讀媒體。
根據一個實施例,電腦實現的共識方法將在由多個(N個)節點維護的區塊鏈上實現,其中,所述節點的其中之一用作為主節點而其他(N-1)個節點用作為備用節點,所述方法由所述備用節點之一執行。所述方法包括:從主節點獲取預準備訊息;將準備訊息(也稱為“組播(multicast)準備訊息”)組播到主節點和其他(N-2)個備用節點中的至少一些節點,所述準備訊息指示接受所述預準備訊息;分別從(Q-1)個或更多個備用節點獲得(Q-1)個或更多個準備訊息,其中,Q(法定數量,quorum)是(N+F+1)/2向上取最接近的整數,F是(N-1)/3向下取最接近的整數;儲存預準備訊息和(Q-1)個或更多個準備訊息;將提交訊息組播至主節點和其他備用節點中的至少一些節點,所述提交訊息指示該一個備用節點同意(Q-1)個或更多個準備訊息;分別從主節點和備用節點中的Q個或更多個節點獲得Q個或更多個提交訊息,所述提交訊息各自指示相應節點同意由所述相應節點接收的(Q-1)個或更多個準備訊息。在一個實施例中,所述(Q-1)個或更多個準備訊息包括所述組播準備訊息;所述Q個或更多個提交訊息包括組播提交訊息。
在一些實施例中,在從所述主節點獲得所述預準備訊息之前,所述方法還包括從以下中的至少一個獲得一個或多個交易請求:一個或多個客戶端、所述主節點或者一個或多個所述其他備用節點。
在其他實施例中,所述預準備訊息包括與一個或多個交易請求相對應的一個或多個交易的順序;並且所述提交訊息指示發送所述提交訊息的相應節點同意所述順序。
在其他實施例中,所述方法還包括:根據所述順序將所述一個或多個交易打包到所述區塊鏈的由該一個備用節點維護的本地副本中。
在其他實施例中,儲存預準備訊息和(Q-1)個或更多個準備訊息包括:僅儲存預準備訊息和(Q-1)個或更多個準備訊息。
在一些實施例中,在組播所述提交訊息之後,所述方法還包括:執行系統重啟;並載入所儲存的預準備訊息和所儲存的(Q-1)個或更多個準備訊息。
在其他實施例中,在儲存預準備訊息和(Q-1)個或更多個準備訊息之後並且在組播所述提交訊息之前,所述方法還包括:執行系統重啟;並載入所儲存的預準備訊息和所儲存的(Q-1)個或更多個準備訊息。
在其他實施例中,在儲存預準備訊息和(Q-1)個或更多個準備訊息之後並且在組播所述提交訊息之前,所述方法還包括:將視域更改訊息(也稱為“組播視域更改訊息”)組播,所述視域更改訊息包括所載入的預準備訊息和所載入的(Q-1)個或更多個準備訊息。
在其他實施例中,在儲存預準備訊息和至少2F個準備訊息之後並且在組播所述提交訊息之前,所述方法還包括:從新主節點獲得指示新主節點已經接收Q個或更多個視域更改訊息的新視域訊息,所述視域更改訊息各自指示相應節點同意所述視域更改訊息;將另一準備訊息(也稱為“另一組播準備訊息”)組播至包括新主節點的至少一些備用節點,所述另一準備訊息指示接受所述新視域訊息;分別從(Q-1)個或更多個所述備用節點獲得另一(Q-1)個或更多個準備訊息。在一個實施例中,所述Q個或更多個視域更改訊息包括所述組播視域更改訊息;所述另一(Q-1)個或更多個準備訊息包括所述另一組播準備訊息。
在一些實施例中,在儲存所述預準備訊息和所述(Q-1)個或更多個準備訊息之後並且在組播所述提交訊息之前,所述方法還包括:分別從Q個或更多個備用節點獲得Q個或更多個視域更改訊息,所述視域更改訊息各自指示相應節點同意所述視域更改訊息;向至少一些所述備用節點組播新視域訊息,所述新視域訊息指示該一個備用節點作為新主節點已經接收Q個或更多個視域更改訊息;從(Q-1)個或更多個備用節點分別獲得另一(Q-1)個或更多個準備訊息。
在其他實施例中,多達N個節點中的所有節點經歷崩潰;所述N個節點中的至少Q個節點執行系統重啟並分別載入所儲存的相應預準備訊息和所儲存的(Q-1)個或更多個準備訊息。
在其他實施例中,執行系統重啟包括:執行系統重啟且不觸發視域更改。
在一些實施例中,用作為用於維護區塊鏈的備用節點之一的共識系統包括一個或多個處理器和一個或多個電腦可讀記憶體,所述一個或多個電腦可讀記憶體耦接到所述一個或多個處理器並且其上儲存有指令,所述指令可由所述一個或多個處理器執行以執行任何前述實施例的方法。
在其他實施例中,用作為用於維護區塊鏈的備用節點之一的共識設備包括用於執行任何前述實施例的方法的多個模組。
根據另一實施例,共識系統用於維護區塊鏈,其中,多個(N個)節點維護所述區塊鏈,所述N個節點之一用作為主節點而其他(N-1)個節點用作為備用節點,該共識系統用作為(N-1)個備用節點之一並且包括一個或多個處理器和一個或多個非暫態性電腦可讀記憶體,所述記憶體耦接到一個或多個處理器並配置有可由所述一個或多個處理器執行的指令,以促使系統執行包括以下的操作:從主節點獲得預準備訊息;將準備訊息組播至所述主節點和其他(N-2)個備用節點中的至少一些節點,所述準備訊息指示接受所述預準備訊息;分別從(Q-1)個或更多個備用節點獲得(Q-1)個或更多個準備訊息,其中,Q(法定數量)是(N+F+1)/2向上取最接近的整數,F是(N-1)/3向下取最接近的整數;儲存預準備訊息和(Q-1)個或更多個準備訊息;將提交訊息組播至所述主節點和其他備用節點中的至少一些節點,所述提交訊息指示該一個備用節點同意(Q-1)個或更多個準備訊息;分別從主節點和備用節點中的Q個或更多個節點獲得Q個或更多個提交訊息,所述提交訊息各自指示相應節點同意由所述相應節點接收的(Q-1)個或更多個準備訊息。
根據另一實施例,非暫態性電腦可讀儲存媒體用於維護區塊鏈,其中,多個(N個)節點維護所述區塊鏈,其中,N個節點之一用作為主節點,其他(N-1)個節點用作為備用節點,所述儲存媒體與(N-1)個備用節點之一相關聯並被配置有可由一個或多個處理器執行的指令,以促使所述一個或多個處理器執行包括以下的操作:從主節點獲得預準備訊息;將準備訊息組播至所述主節點和其他(N-2)個備用節點中的至少一些節點,所述準備訊息指示接受所述預準備訊息;分別從(Q-1)個或更多個備用節點獲得(Q-1)個或更多個準備訊息,其中,Q(法定數量)是(N+F+1)/2向上取最接近的整數,F是(N-1)/3向下取最接近的整數;儲存預準備訊息和(Q-1)個或更多個準備訊息;將提交訊息組播至所述主節點和其他備用節點中的至少一些節點,所述提交訊息指示該一個備用節點同意(Q-1)個或更多個準備訊息;分別從主節點和備用節點中的Q個或更多個節點獲得Q個或更多個提交訊息,所述提交訊息各自指示相應節點同意由所述相應節點接收的(Q-1)個或更多個準備訊息。
根據又一實施例,共識設備用於維護區塊鏈。多個(N個)節點維護所述區塊鏈,其中,N個節點的其中之一用作為主節點,其他(N-1)個節點用作為備用節點,所述共識設備用作為(N-1)個備用節點之一,並且包括:第一獲取模組,用於從主節點獲取預準備訊息;第一組播模組,用於將準備訊息組播至主節點和其他(N-2)個備用節點中的至少一些節點,所述準備訊息指示接受所述預準備訊息;第二獲取模組,用於分別從(Q-1)個或更多個備用節點獲取(Q-1)個或更多個準備訊息,其中,Q(法定數量)為(N+F+1)/2向上取最接近的整數,F是(N-1)/3向下取最接近的整數;儲存模組,用於儲存預準備訊息和(Q-1)個或更多個準備訊息;第二組播模組,用於將提交訊息組播至主節點和其他備用節點中的至少一些節點,所述提交訊息指示該一個備用節點同意(Q-1)個或更多個準備訊息;第三獲取模組,用於分別從主節點和備用節點中的Q個或更多個節點獲取Q個或更多個提交訊息,所述提交訊息各自指示相應節點同意由所述相應節點接收的(Q-1)個或更多個準備訊息。
本說明書中揭示的實施例具有一個或多個技術效果。在一些實施例中,所述方法和系統可以確保PBFT共識系統的各個節點能夠在一個或多個節點經歷系統崩潰之後恢復正常操作。在其他實施例中,在每輪共識驗證中,共識系統的節點(主節點或備用節點)可以儲存預準備訊息和足夠數量的準備訊息,以便當中斷(例如,系統範圍的(system-wide)崩潰)發生時,節點可以恢復共識驗證且不會導致不一致的共識結果以及區塊鏈分支。在其他實施例中,在崩潰之後,節點可以執行系統重啟並載入所儲存的訊息以恢復正常功能。透過載入所儲存的訊息可以加速系統停機時間恢復。在其他實施例中,可以在獲得準備訊息(在正常操作協定的準備階段)之後並且在組播提交訊息(在正常操作協定的提交階段)之前儲存預準備訊息和至少(Q-1)個準備訊息。因此,需要提交較少的用於儲存的系統資源,這是因為需要儲存至多預準備訊息和(Q-1)個準備訊息以實現停機時間恢復。在一些實施例中,可以容忍多達F個惡意或故障節點,且不存在不一致的共識結果和區塊鏈分支。也就是說,即使多達F個節點不可信,由PBFT共識系統的法定數量確定的共識驗證也是可靠的。
參考圖式考慮以下描述和所附申請專利範圍,本文揭示的系統、方法和非暫態性電腦可讀媒體的這些和其他特徵,以及相關結構元件的操作方法和功能以及部件的組合和製造經濟性將變得更加明顯。所有這些圖式形成本說明書的一部分,其中,相同的圖式標記表示各圖式中的對應部分。然而,應該清楚地理解,圖式僅用於說明和描述的目的,而不是限制性的。
本文揭示的實施例包括但不限於PBFT停機時間恢復系統、方法和非暫態性電腦可讀媒體。在各種實施例中,諸如區塊鏈系統的分散式網路系統可包括多個節點。區塊鏈系統可以實現PBFT共識機制,其中,多個節點的其中之一被指定為主節點而其他節點被指定為備用節點。根據一些實施例,對於在區塊鏈系統中執行的每輪共識驗證,僅儲存部分一致性訊息而不是所有一致性訊息。例如,在正常操作協定期間,儲存預準備訊息和足夠數量的準備訊息。在一些實施例中,僅儲存預準備訊息和(Q-1)個準備訊息。Q代表法定數量,並且為(N+F+1)/2向上取最接近的整數,F是(N-1)/3向下取最接近的整數。以這種方式,可以有效且高效地從任何中斷(例如,系統範圍的崩潰)恢復並且推進共識驗證過程,具有較少的系統儲存消耗且不會導致不一致的共識結果以及區塊鏈分支。與PBFT類似,所揭示的系統、方法和非暫態性電腦可讀媒體可以應用於其他共識協定,例如SecureRing、Byzantine Paxos、Q/U、HQ、Zyzzvyva、ABsTRACTs、RBFT、Adapt、Tangaroa、CheapBFT、MinBFT、FastBFT等。PBFT的各個方面可以參考M. Castro, B. Liskov, “Practical Byzantine Fault Tolerance,” Proceedings of the Third Symposium on Operating Systems Design and Implementation, (Feb 1999),其透過引用完整地併入本文。
圖1示出了根據各種實施例的網路120。下面給出的組件旨在說明。如圖所示,網路120可以包括分散式網路系統112,例如區塊鏈系統。網路系統112可以包括在一個或多個計算設備(諸如,伺服器、電腦、行動電話等)中實現的一個或多個節點(例如,節點0、節點1、節點2、節點3、節點4...節點i等)。網路系統112可以安裝有適當的軟體(例如,共識程式)和/或硬體(例如,有線連接、無線連接),以存取網路120或附加系統的其他設備。每個節點可以包括一個或多個處理器以及耦接到所述一個或多個處理器的一個或多個記憶體。例如,所述一個或多個記憶體是非暫態性的且電腦可讀的,並且配置有可由所述一個或多個處理器執行的指令,以促使所述一個或多個處理器執行本文描述的操作。儘管在該圖中節點被示為單個組件,但是應當理解,這些節點可以實現為單個設備或耦接在一起的多個設備。通常,節點能夠彼此通訊並且與網路系統112外部的其他設備通訊。例如,透過一個或多個有線網路或無線網路(例如,網際網路),資料可以被傳送。
在各種實施例中,網路系統112可以被實現為包括複數個節點的區塊鏈系統。例如,如圖1所示,區塊鏈系統包括複數個區塊鏈節點(例如,節點0、節點1、節點2、節點3、節點4......節點i等)。所述節點可以形成網路(例如,點對點網路,Peer-to-Peer network),其中一個區塊鏈節點與另一區塊鏈節點通訊。所示的區塊鏈節點的順序和數量僅僅是示例性的並且是為了簡化說明。所述區塊鏈節點可以在伺服器、電腦等中被實現。每個區塊鏈節點可以對應於經由各種類型的通訊方法諸如TCP/IP耦接在一起的一個或多個物理硬體設備或虛擬裝置。根據分類,區塊鏈節點可以包括全節點、Geth節點、共識節點等。
在各種實施例中,所述區塊鏈系統可以與諸如節點A和節點B(例如,輕(lightweight)節點)的其他系統和設備互動。所述互動可以涉及資料的發送和接收,以便例如接收請求,並返回所述請求的執行結果。在一個示例中,用戶A可能想要透過區塊鏈與用戶B進行交易。所述交易可以涉及將用戶A的帳號中的某些資產轉移到用戶B的帳號。用戶A和用戶B可以使用各自的安裝有適當區塊鏈軟體(例如,加密貨幣錢包)的設備節點A和節點B進行交易。節點A可以透過與節點0的通訊來存取區塊鏈,節點B可以透過與節點1的通訊來存取區塊鏈。例如,節點A可以透過節點0向區塊鏈提交交易請求,節點B可以透過節點1向區塊鏈提交智慧合約執行請求。在區塊鏈之外,節點A和節點B可以具有其他通訊通道(例如,不經過節點0和節點1的習知網際網路通訊)。
所述區塊鏈節點可以各自包括記憶體或耦接到記憶體。在一些實施例中,記憶體可以儲存池資料庫(pool database)。所述池資料庫可以被分散式方式的複數個區塊鏈節點存取。例如,所述池資料庫可以分別儲存在區塊鏈節點的記憶體中。所述池資料庫可以儲存由一個或多個用戶設備(例如,由用戶操作的節點A和節點B)提交的多個交易。
區塊鏈節點形成網路(例如,P2P網路),所述網路,透過共識,在稱為區塊鏈的分散式分類帳中記錄交易。P2P網路的參與者可以被稱為維護區塊鏈的節點。在區塊鏈P2P網路中,每個節點參與共識驗證並儲存區塊鏈的完整分類帳副本。每個節點透過區塊鏈共識演算法確認批量交易,以確保所有節點具有一致的確認結果,從而確保所有節點具有一致的區塊鏈副本。
區塊鏈共識演算法之一是實用拜占庭容錯(PBFT)。拜占庭容錯源於拜占庭一般問題。對於P2P網路系統,只要無作用節點的數量在一定限度內,所述系統就可以繼續正常運行。這種系統稱為拜占庭容錯系統。PBFT是拜占庭容錯網路能力優化的一個例子。PBFT透過複製伺服器並將客戶端互動與伺服器副本同步,為網路提供拜占庭狀態機。
PBFT操作的核心是維護記錄在區塊鏈上的資訊的一致性全域視域,這形成了使用戶能夠以分散方式彼此互動的主幹。PBFT共識機制的安全性對區塊鏈系統至關重要。共識模型的兩個關鍵屬性是:1)安全性或共識性:所有誠實節點產生相同的有效輸出;2)活躍性:共識中的所有誠實節點最終都會產生值而不會在中間步驟停滯。安全可靠的PBFT共識機制需要容忍各種各樣的拜占庭行為,包括節點故障、網路分區、訊息延遲、無序訊息傳遞、訊息損壞等,並且在節點中達成共識,只要系統內的無作用節點數量是有限的。為此,PBFT模型在兩種互斥協定中的任何一種下工作:正常操作/共識協定和視域更改協定,這將在下面進一步描述。在本說明書中,無功能意味著有故障和/或惡意,起作用意味著無故障和誠實。可能的故障和/或惡意行為可以包括:訊息傳遞故障、訊息傳遞延遲、無序訊息傳遞、拜占庭故障(向不同節點傳遞任意訊息,違反協定)等。
在一些實施例中,實現實用拜占庭容錯(PBFT)機制的區塊鏈系統可以包括總數N個節點,其中,N個節點的其中之一用作為主節點,N個節點中的其他節點用作為備用節點。主節點指定可以不被固定於特定節點,因為可以透過視域更改協定選擇另一節點成為新主節點。例如,可以透過取模運算選擇主節點,其中,具有最低序號(模視域號)的作用節點成為新主節點。目前視域和節點總數N可以確定主節點id=(view+1)mod N。在PBFT中,每次選擇新主節點時都會更改視域。例如,隨著每個視域更改,視域從零開始單調增加。也就是說,所述視域可以隨主節點更改而更改。
在一些實施例中,所述主節點在視域v處運行,並且執行正常操作協定。對於正常操作,所述主節點和/或備用節點可以從一個或多個客戶端接收與未驗證交易相關聯的請求。例如,作為客戶端的節點A可以向主節點和/或備用節點提交請求。所述請求可以包括未驗證交易(例如,透過共識驗證將要添加到區塊鏈的新區塊中的交易)。所述未驗證交易可以包括例如基於區塊鏈的金融交易、智慧合約部署或執行交易等。所述主節點和所述備用節點可以執行或不執行交易的一些初步驗證。接收所述請求的備用節點可以將接收到的請求轉發到主節點。一旦主節點處的具有未驗證交易的請求達到特定級別或以其他方式滿足觸發條件,則所述主節點可以發起一輪共識驗證,並提議對未驗證交易的驗證結果。所述備用節點可以回應共識,並確認所述提議以達成共識。對這些節點的要求是它們是確定性的並且以相同狀態開始。最終的結果是,所有誠實節點對記錄的順序達成共識,所有誠實節點要麼接受它,要麼拒絕它。一旦經過共識驗證,所述交易就可以被打包到區塊鏈的新區塊中,並被添加到由這些節點維護的本地區塊鏈副本中。此外,最初發送請求的客戶端(例如,節點A)被通知。
如上所述,為了保持安全,PBFT共識機制主要包括正常操作協定的三個階段:預準備階段、準備階段和提交階段。參考圖2A至圖2C,實現PBFT共識機制的區塊鏈系統的示例包括四個副本(副本是節點的另一術語):副本0、副本1、副本2和副本3。數字0至3是可用於確定新主節點的副本序號。副本0可以對應於主節點0,副本1、副本2和副本3可以對應於備用節點1、備用節點2和備用節點3。例如,所述副本可以在上述網路系統112的相應節點中被實現。圖2A中示出了正常操作協定,其中,不存在無作用節點,圖2B中示出了另一種正常操作協定,其中,副本3是無作用節點。對於這兩種情況,除了預準備階段、準備階段和提交階段之外,正常操作協定還可以包括兩個階段:請求階段和回覆階段。圖3A中示出了對應於圖2A的步驟的流程圖。
參考圖2A、圖2B和圖3A,當客戶端向負責提倡請求的主節點(副本0)提交請求(訊息)時,正常操作協定在請求階段開始。所述請求可以包括客戶端的資訊、請求操作(例如,用於共識驗證的一個或多個交易)和請求時間戳記。所述客戶端(也稱為客戶端節點)可以例如在上述節點A中被實現。節點A可以是輕節點(例如,在行動電話中被實現)。附加地或替代地,客戶端可以將請求提交給備用節點,所述備用節點在預準備階段之前將所述請求轉發到主節點。無論是主節點還是備用節點接收所述請求,相應節點都可以將所接收的請求組播到網路中的其他節點。因此,主節點可能最終以某種方式獲得客戶端提交給共識網路的未決請求(步驟311)。
因此,主節點用作為領導者並且領導備用節點驗證與請求相關聯的交易。主節點負責在其視域中對請求的執行進行排序。在預準備階段,主節點可以獲得多個請求,驗證所獲得的請求,並為每個請求提出序號。因此,每個請求可以被分配遞增的序號,從而被按順序排列。另外,所述預準備訊息可以包括區塊長度。所述區塊長度可以基於區塊鏈的目前長度。例如,如果區塊鏈目前具有1000個區塊,則區塊長度可以是1000,其表示區塊鏈中已經存在1000個區塊,或者可以是1001,其表示與請求相關聯的交易被提議打包到區塊鏈中尚未被其他節點驗證的第1001個區塊中。所述主節點可以轉發客戶端的請求以及相應序號和/或區塊長度。例如,在獲得所述請求之後,所述主節點可以透過分配序號來將請求按照用於執行相應交易的順序排列,並將其儲存到清單中。所述主節點可以向區塊鏈系統中的每個備用節點(副本1至副本3)發送預準備訊息(步驟312)。如圖2A所示,所述主節點可以將預準備訊息中的清單組播到備用節點或將所述清單與預準備訊息一起組播到備用節點。如圖2B所示,即使備用節點(副本3)是無功能的並且主節點不知道這一點,所述主節點仍然可以發送預準備訊息(步驟313)。每個備用節點都接受預準備訊息,只要所述預準備訊息是有效的。所述預準備訊息可以包含允許確定預準備訊息的有效性的視域號、序號、主節點的簽名、摘要(d)、其他元資料等。
在準備階段,如果備用節點接受預準備訊息,則可以透過將準備訊息組播到區塊鏈系統中的包括主節點的其他節點來繼續(步驟314)。組播所述準備訊息指示發送方節點同意所述預準備訊息。每個準備訊息,只要是有效的,就被接收節點接受。可以基於視域號、序號、相應備用節點的簽名、摘要(d)、其他元資料等類似地確定所述準備訊息的有效性。如果備用節點已經從主節點接收有效的預準備訊息,並且已經從其他節點獲得(Q-1)個或更多個不同的、有效的一致性準備訊息(步驟315),則備用節點準備就緒,其中,法定數量(Q)表示確保所有副本/節點資料一致性和容錯要求所需的副本/節點的數量。在一些實施例中,實現PBFT系統的區塊鏈系統具有多個(至少3F+1個)副本/節點,其中,F表示PBFT安全且活躍地運行可以容忍的拜占庭故障/無作用節點的數量,法定數量(Q)等於2F+1。在這種情況下,可以儲存預準備訊息和至少2F個準備訊息。所述2F個準備訊息可以包括組播準備訊息。這裡,需要Q-1(在這種情況下,2F)個而不是Q個準備訊息,因為預準備訊息可以被視為主節點的準備訊息的等效物(儘管主節點本身可以不發送準備訊息)。如果將預準備訊息計算為另一個準備訊息,那麼將有至少Q(例如,2F+1)個不同且有效的準備訊息,這些準備訊息指示所有節點中的至少Q(例如,2F+1)個節點接受預準備訊息,其中,至多F個無作用節點可以被容忍。因此,所述預準備階段至準備階段確保至少F+1個作用節點(2F+1個準備節點但考慮了至多F個無作用節點)同意:如果在視域v中執行請求,則將按照其序號執行所述請求。所述準備階段確保視域中每個請求的容錯一致性排序。
在一些實施例中,在接收到預準備訊息和(Q-1)個準備訊息之後,所述備用節點可以驗證所述順序並將驗證結果與主節點在預準備訊息中寫入的提議驗證結果進行比較。可以有多種方法來驗證所述順序。例如,所述提議驗證結果可以包括寫入摘要(d)中的建議的Merkle Patricia Trie根。所述備用節點可以根據所述順序對與請求相關聯的交易進行排列,並計算Merkle Patricia Trie根以與提議的Merkle Patricia Trie根進行比較。所述計算還可能需要某些現有資訊,例如區塊鏈中現有區塊的節點雜湊值。所述比較產生由備用節點計算的摘要(D(m))。如果摘要(D(m))與摘要(d)一致,則驗證成功。一旦被驗證,所述備用節點可以同意所述請求的排序(例如,將與請求相關聯的交易打包到區塊鏈的新區塊中的順序)。類似地,所述備用節點可以驗證它接收的提交訊息(下面相對於提交階段描述的)是否包括相同摘要D(m),以確定其他節點是否也同意所述請求的排序。如果準備節點已經獲得Q(例如,2F+1)個提交訊息並且已經執行了具有較低序號的所有請求,則所述節點可以執行所述請求。
在一些實施例中,所述預準備訊息可以包括新區塊的摘要(d)或者與執行所述請求有關的其他資訊(例如,與所述請求相關聯的交易)。所述摘要(d)(例如,雜湊值)可以是將雜湊演算法應用於諸如交易的資料的數值結果。所述備用節點可以執行交易以確認所述摘要(d)。對於多個請求,所述備用節點可以根據順序(即,所述請求的序號)執行所述請求以獲得摘要D(m)。如果D(m)和d是一致的,則所述備用節點組播提交訊息(下面針對提交階段描述的),所述提交訊息指示備用節點與主節點的驗證結果一致。對於特定序號的未決請求,如果準備節點已經獲得Q(例如,2F+1)個提交訊息並且已經執行具有較低序號的所有請求,則所述節點可以執行所述請求。
在提交階段,如果節點準備就緒,則所述節點可以將提交訊息組播到其他節點(步驟316)。所述節點可以從其他節點接收提交訊息。只要提交訊息是有效的,每個節點都接受它。所述提交訊息可以包含允許確定訊息的有效性的視域號、序號、簽名、摘要、其他元資料等。在一些實施例中,如果節點已經獲得至少Q個不同的、有效的一致性提交訊息,則標記法定數量的節點已經提交(即,至少(Q-F)個誠實節點準備就緒)並且已達成共識(步驟317)。至少Q個有效的提交訊息可以包括組播提交訊息。因此,所述準備階段至提交階段確保至少(Q-F)個作用節點(Q個提交訊息但考慮了至多F個無作用節點)同意,請求最終將在視域v中按照其序號被執行。由於節點可以在不同視域(例如,當一些節點已經進入新視域並且一些其他節點依然在先前視域中時)中提交,所接收的提交訊息可以對應於在不同視域中執行的提交。所述提交階段確保跨視域的每個請求的容錯一致性排序,因為作用節點對每個請求的序號達成一致。
在一些實施例中,如果節點已經獲得至少Q個不同的、有效的一致性提交訊息,則所述節點可以執行相應請求。例如,一旦獲得Q個提交訊息,就意味著新區塊被共識驗證。因此,所述節點可以將新區塊打包到本地維護的區塊鏈副本中。否則,所述備用節點可以直接觸發視域更改協定。
在回覆階段,在執行所述請求之後,所述節點直接向客戶端發送回覆訊息。對於打包到區塊鏈中的交易,所述回覆訊息可以包括所述交易在區塊鏈中的位址。由於允許多達F個故障,客戶端在接受結果之前等待來自不同節點的具有有效簽名並具有相同請求時間戳記和相同執行結果的(Q-F)個回覆。對於圖2A和圖2B中所示的PBFT網路系統,總共存在四個節點,因此可以容忍至多一個(F=1)無作用節點。因此,即使副本3是無功能的,在圖2B中仍然可以達成共識。
為了保持活躍性,如果主節點沒有組播請求的情況經過了特定時間量,則可以在視域更改協定中替換主節點。例如,所述備用節點可以維護計時器。所述備用節點在接收請求並且計時器尚未運行時啟動計時器。當所述備用節點不再等待執行請求時(即,所述請求被執行),所述備用節點停止計時器,但是如果在那時它正在等待執行一個或多個其他請求,則重新啟動計時器。如果所述計時器到期,則備用節點可以確定主節點是無功能的。因此,所述備用節點可以將視域更改訊息組播到其他節點。又例如,所述備用節點可以確定主節點是惡意的。因此,所述備用節點可以組播視域更改訊息。再例如,客戶端可以使用計時器來確定在客戶端將所述請求發送到主節點之後是否已經過太多時間而沒有接收到回應。當該計時器到期時,客戶端將其請求發送到所有節點。如果節點已經獲知該請求,則忽略該重新廣播。如果節點未獲知該請求,它將啟動計時器。一旦所述節點的計時器超時,基於懷疑主節點是故障的,所述節點透過將視域更改訊息組播到其他備用節點來啟動視域更改過程(步驟321)。所述視域更改訊息包括系統狀態(以存檔訊息的形式,包括在先前正常操作期間其自己的準備訊息),以便其他節點將獲知發送方節點未發生故障。
絕對多數作用節點可以確定主節點是否是無功能的,並在用下一主節點作為替換的情況下刪除該主節點。當足夠的節點認為主節點發生故障時,發生視域更改。圖2C的一部分示出了視域更改協定,圖3B中示出了與視域更改協定相對應的步驟的流程圖。參考圖2C和圖3B,在視域更改階段,如果目前視域是v,則節點p=(v+1)mod N等待獲得Q個有效視域更改訊息以成為新主節點,其中,p是副本/節點序號,v是視域號,N是副本/節點的總數(步驟322)。Q個視域更改訊息可以包括組播視域更改訊息。由於先前視域是v,因此視域更改訊息可以各自包括新視域v+1。一旦新主節點p獲得Q個視域更改訊息,它就組播新視域訊息(步驟323)。該訊息包含接收的所有有效視域更改訊息以及由於主節點故障而可能尚未完成的所有請求的集合。新主節點可以決定最新的檢查點,並且此外,確保非故障節點趕上最新狀態,這可能涉及在新視域中重新提交先前的請求(例如,準備就緒、提交、但未被執行的請求)。當視域更改發生時,不會接受任何新請求。在節點接收包含Q個視域更改訊息的有效新視域訊息後,它將進入視域v+1並處理未完成的請求的集合。此後,正常操作協定繼續進行,並且節點重做在最新的穩定檢查點的序號和準備訊息中的最高號之間的請求,但是避免重新執行請求。所述備用節點可以設置用於新主節點的計時器(步驟324)。
除了增加儲存階段之外,圖3C類似於圖3B。也就是說,除了在步驟335和步驟336之間另外執行步驟399之外,步驟331至步驟337分別類似於步驟311-步驟317。在一些實施例中,如圖3C所示,在準備階段(備用節點或主節點獲得(Q-1)個準備訊息)和提交階段(備用節點或主節點組播所述提交訊息)之間,可以在儲存階段儲存所述預準備訊息和所述至少(Q-1)個準備訊息。下面參考圖4A至圖6B描述進一步的細節。
圖4A示出了根據本說明書的各種實施例的由主節點執行的共識步驟410a的流程圖。圖4B示出了根據本說明書的各種實施例的由備用節點執行的共識步驟410b的流程圖。這兩幅圖顯示了實施PBFT共識機制的區塊鏈系統,所述區塊鏈系統包括至少3F+1個節點。然而,本說明書不限於此。所述區塊鏈系統可以具有除“至少3F+1”之外的其他數量的節點,只要系統中存在用於維護有效的共識過程並滿足安全性和活躍度要求的法定數量的節點。在一些實施例中,如圖4A所示,共識步驟410a由視域v中的主節點執行,並且如圖4B所示,共識步驟410b由視域v中的備用節點執行,且不觸發視域更改。所述視域指示N個節點中的哪個節點被視為主節點,其中,N表示網路系統中的節點的數量。步驟410a和步驟410b可以各自由圖1的系統112的一個或多個組件(例如,上述節點0、節點1、節點2、......或節點i或者類似設備,或者任何節點和附加設備(例如,節點A)的組合)實現。在該圖中,節點A(例如,上述輕節點)是客戶端,節點0至節點3是網路系統112中的節點。在目前視域v中,節點0用作為主節點,節點1至節點3用作為備用節點。步驟410a和步驟410b可以各自由包括各種硬體機器和/或軟體的共識系統或設備(例如,電腦、伺服器)實現。例如,所述共識系統或設備可以包括一個或多個處理器和一個或多個非暫態性電腦可讀儲存媒體(例如,一個或多個記憶體),所述儲存媒體耦接到一個或多個處理器並配置有可由一個或多個處理器執行的指令,以促使系統或設備(例如,處理器)執行步驟410a或步驟410b。下面的操作旨在說明。根據實施方式,操作可以包括以各種循序執行或並存執行的附加、更少或替代步驟。
在圖4A和圖4B的垂直方向上,各個步驟對應於“請求”、“預準備”、“準備”、“儲存”、“提交”和“回覆”階段,其可以參考上面參照圖1至圖3C所描述的。為清楚起見,各個階段的排列被示出,並且可以沒有嚴格的順序要求。例如,所述儲存階段可以在準備階段結束之前開始,和/或在提交階段開始之後結束。如圖4A所示,例如,當中斷(例如,停機時間情況)發生時,可以在步驟415至步驟417之間另外執行可選步驟498,如下所述。所述主節點和所述備用節點可以是PBFT共識機制中定義的節點。
圖4A的步驟410a和圖4B的步驟410b可以應用於針對一個或多個請求的一輪共識驗證。例如,一輪共識驗證可以處理一個或多個交易請求。如果成功,相應交易將被打包到區塊鏈的新區塊中。除非特別指出,否則下面的描述參照圖4A或圖4B,因為某些步驟是相互交織的。步驟411a和步驟412a僅在圖4A中找到,而步驟411b和步驟412b僅在圖4B中找到。在圖4A和圖4B中均示出了步驟413、步驟414、步驟415、步驟416和步驟417。
在步驟411a,如圖4A所示,在請求階段,所述主節點可以從客戶端獲得請求。例如,所述請求可以由主節點(節點0)直接從客戶端(節點A)獲得,或從備用節點(例如,備用節點1、備用節點2或備用節點3)獲得,所述備用節點將請求轉發到主節點,如虛線所示。在一些實施例中,所述請求可以涉及用於共識驗證的交易(具有或不具有智慧合約)。可以在執行正常操作協定期間執行共識驗證。或者,所述請求可以對應於其他操作。
在步驟412a,在預準備階段,主節點(節點0)將預準備訊息與請求一起組播至備用節點(節點1、節點2和節點3)。在一些實施例中,在獲得多個請求之後,所述主節點可以將預準備訊息和多個請求組播至每個備用節點。所述預準備訊息可以包括請求的順序(例如,與請求相關聯的交易的順序)。
如圖4B所示,圖4B示出了在正常操作協定下由備用節點(例如,節點1、節點2或節點3)執行的步驟,在步驟411b,在預準備階段,所述備用節點獲得預準備訊息以及請求。所述請求可以包括用於共識驗證的相關聯的交易。在一些實施例中,可以從主節點獲得預準備訊息和請求。在一些實施例中,可以從主節點獲得預準備訊息,並且可以從客戶端、主節點和/或任何其他備用節點獲得請求。如果主節點是無功能的,則可以觸發視域更改協定。
在步驟412b,在準備階段,如果預準備訊息是有效的,則備用節點將準備訊息組播到系統中的其他節點。
在步驟413,在準備階段,所述主節點或所述備用節點接收從其他節點發送的準備訊息。獲得(Q-1)個有效的準備訊息可以是在共識過程進入下一提交階段之前要滿足的條件。在圖4A和圖4B所示的實施例中,例如,(Q-1)是2F,並且需要2F個或更多個準備訊息。2F個或更多個準備訊息可以包括備用節點或主節點自己的準備訊息。對於備用節點,2F個或更多個準備訊息可以包括步驟412b處的準備訊息(即,在步驟412b由備用節點自身組播的準備訊息)。
在步驟414,所述主節點或所述備用節點可以儲存預準備訊息和至少(Q-1)個準備訊息。例如,如果節點獲得了多個(3F個)準備訊息,則這些節點可以儲存預準備訊息和多個(2F個至3F個,包括2F個和3F個)準備訊息。在一些實施例中,僅儲存預準備訊息和Q-1個準備訊息。在一些實施例中,僅儲存預準備訊息和2F個準備訊息。例如,如果獲得3F個準備訊息,則預準備訊息和2F個準備訊息可以是在整個系統從中斷(例如,系統崩潰)恢復之後,有效且高效地恢復並且推進共識過程所需要儲存的最小量的一致性訊息,而不消耗太多的系統儲存資源。在一些實施例中,儲存所述預準備訊息和(Q-1)個或更多個準備訊息包括:僅儲存預準備訊息和(Q-1)個或更多個準備訊息,這意味著除了預準備訊息和至少2F個準備訊息之外不儲存任何訊息。例如,對於每輪共識驗證,不儲存提交訊息。當進行多輪共識驗證時,同樣適用。
步驟413和步驟414可以按順序、同時或以其他方式執行。在一些實施例中,可以僅在獲得(Q-1)個或更多個準備訊息時執行預準備訊息和至少(Q-1)個準備訊息的儲存。在其他實施例中,可以在獲得相應的訊息之後的任何時間執行預準備訊息和至少(Q-1)個準備訊息的儲存。
在一些實施例中,可以以各種方式儲存預準備訊息和至少(Q-1)個準備訊息,只要在系統從中斷恢復之後所儲存的訊息是可檢索的。例如,可以將預準備訊息和至少(Q-1)個準備訊息儲存在永久記憶體中,所述永久記憶體確保所述儲存不受系統崩潰和重啟的影響。
在一些實施例中,如果系統操作沒有中斷(例如,由系統崩潰引起的停機時間),則可以執行步驟415。在一個實施例中,在儲存至少預準備訊息和(Q-1)個準備訊息之後執行步驟415的提交階段。對於步驟415,在所述提交階段,所述主節點和所述備用節點各自將提交訊息組播至其他節點。每個節點還可以接收由其他節點組播的提交訊息。在步驟416,所述主節點或所述備用節點可以獲得至少法定數量(Q)的提交訊息(在這種情況下,2F+1)。對於備用節點或主節點,如圖4A和圖4B所示,所述Q個提交訊息可以包括步驟415中的提交訊息(即,在步驟415由備用節點或主節點自身組播的提交訊息)。在步驟417,如果節點看到足夠的節點(例如,Q個節點)已經提交,則這些節點可以根據所述循序執行請求,並透過回覆訊息通知客戶端(節點A)。
在一些實施例中,如果在組播提交訊息之後存在系統操作的中斷(例如,由系統崩潰引起的停機時間),則可以在步驟415之後且在步驟417之前執行可選步驟498。在步驟498,所述主節點或所述備用節點可以執行系統重啟,並且載入這些節點曾經在步驟414處儲存的預準備訊息和至少(Q-1)個準備訊息。在一些實施例中,所述系統可以在中斷之後自動或非自動地重新啟動。然後,可以繼續其餘步驟416至步驟417或步驟417。
在一些實施例中,如果在組播提交訊息之前存在系統操作的中斷(例如,由系統崩潰引起的停機時間),則可以在步驟414之後且在步驟415之前執行可選步驟499。在步驟499,所述主節點或所述備用節點可以載入在儲存階段曾經儲存的預準備訊息和至少(Q-1)個準備訊息(步驟414)。在一些實施例中,所述系統可以在中斷之後自動或非自動地重新啟動。如果執行步驟499,則可以在某些情況下觸發視域更改協定(例如,如果非作用節點是主節點,並且主節點在超時時段內沒有恢復其運行狀態)。然而,如果不滿足超時條件(例如,在觸發超時條件之前完成步驟499),則可以不觸發視域更改協定,如圖4A和圖4B所示。因此,如果無功能主節點足夠快地恢復其運行狀態而避免超時條件,則可以不觸發視域更改協定,並且可以在所述協定中繼續步驟415至步驟417。如果滿足超時條件(例如,在觸發超時條件之前步驟499未完成),如下面參考圖4C和圖4D所述,可以觸發視域更改協定。
圖4C示出了根據本說明書的各種實施例的視域v中的備用節點的共識步驟420a的流程圖,所述備用節點成為視域v+1中的新主節點。圖4D示出了根據本說明書的各種實施例的視域v中的備用節點的共識步驟420b的流程圖,所述備用節點在視域v+1中仍然為備用節點。步驟420a和步驟420b可以各自由圖1的系統112的一個或多個組件(例如,上述節點0、節點1、節點2、......或節點i或者類似設備,或者任何節點和附加設備(例如,節點A)的組合)實現。在該圖中,節點A(例如,上述輕節點)是客戶端,節點0至節點3是區塊鏈節點。如圖4A和圖4B中所述,在視域v中,節點0用作為主節點,但是對於圖4C和圖4D中的視域v+1,節點1變為新主節點,節點2至節點3仍為備用節點。步驟420a和步驟420b可以各自由分散式網路系統(例如,區塊鏈系統)的一個或多個節點實現。步驟420a和步驟420b可以各自由包括各種硬體機器和/或軟體的共識系統或設備(例如,電腦、伺服器)實現。例如,所述共識系統或設備可以包括一個或多個處理器和一個或多個非暫態性電腦可讀儲存媒體(例如,一個或多個記憶體),所述儲存媒體耦接到一個或多個處理器並配置有可由一個或多個處理器執行的指令,以促使系統或設備(例如,處理器)執行步驟420a和步驟420b。下面的操作旨在說明。根據實施方式,操作可以包括以各種循序執行或並存執行的附加、更少或替代步驟。
如上所述,如果在圖4B的步驟414之後且步驟415之前觸發視域更改,則執行圖4C和圖4D中所示的步驟。為簡潔起見,在圖4C和圖4D中不再現步驟499之前的步驟(直到圖4B中所示的步驟414的步驟)。
在一些實施例中,如圖4C和圖4D所示的共識步驟420a和共識步驟420b可以對應於觸發視域更改的情況。視域v中的主節點(例如,節點0)可能變成故障的或者無功能的。對於圖4C,視域v中的備用節點(例如,節點1)可以執行步驟499、步驟423、步驟424a、步驟425a、步驟426a、步驟425、步驟426和步驟427,所述備用節點在視域v+1中成為新主節點。視域v中的備用節點(例如,節點2或節點3)可以執行步驟499、步驟423、步驟424b、步驟425b、步驟426b、步驟425、步驟426和步驟427,所述備用節點在視域v+1中仍然為備用節點。在兩個圖的垂直方向上,各個步驟對應於“視域更改”階段、“新視域”階段、“準備”階段、“提交”階段和“回覆”階段,可以參考上面參考圖1至圖3C所描述的。為清楚起見,各個階段的排列被示出,並且可以沒有嚴格的順序要求。所述主節點和所述備用節點可以是PBFT共識機制中定義的節點。以下描述參考圖4C或圖4D,因為某些步驟是相互交織的。
在一些實施例中,如步驟499所示,仍然處於視域v中,主節點(節點0)和一些備用節點(節點1、節點2和/或節點3)可以各自載入分別在步驟414處儲存的預準備訊息和至少(Q-1)個準備訊息。如果從永久記憶體儲存這些訊息,則現在可以從永久記憶體載入它們。可以回應於正常操作的中斷(例如,由系統崩潰引起的停機時間),執行系統重啟。
在一個實施例中,當懷疑主節點可能是無功能的時,備用節點(例如,節點1、節點2或節點3)可以組播視域更改訊息,所述視域更改訊息可以包括所載入的預準備訊息和所載入的至少(Q-1)個準備訊息,如步驟423所示。在視域更改協定下,所述備用節點之一可以成為新主節點,其餘節點可以仍然為備用節點。上面描述了新主節點的選擇。例如,如圖所示,節點1可以被選為新主節點,而節點2和節點3可以仍然為備用節點。
在步驟424a,當備用節點已經從其他節點獲得至少Q個視域更改訊息時,所述視域更改訊息各自指示相應節點同意所述視域更改訊息,新主節點可以被選擇(例如,節點1)。所述至少Q個視域更改訊息可以包括由備用節點本身組播的視域更改訊息。在步驟425a,新主節點(例如,節點1)將包括至少Q個視域更改訊息的新視域訊息組播至至少一些備用節點。
如圖4D所示,在步驟424b,在視域更改協定下的過程中,備用節點可以從新主節點獲得指示該新主節點已經接收Q個或更多個視域更改訊息的新視域訊息,所述視域更改訊息各自指示相應節點同意所述視域更改訊息。在步驟425b,所述備用節點組播指示接受所述新視域訊息的另一準備訊息。所述另一準備訊息可以至少在視域號方面不同於圖4A和圖4B的準備訊息。
參考圖4C,在步驟426a,新主節點(節點1)可以獲得另一(Q-1)個或更多個準備訊息。在步驟426b,剩餘備用節點可以各自獲得另一(Q-1)個或更多個準備訊息。除了在視域更改之後準備訊息內容可能不同並且一些節點可能已經提交一些所述請求之外,圖4C和圖4D的準備階段類似於圖4A和圖4B的準備階段。為了區分,用於圖4C和圖4D的準備階段的準備訊息被稱為另一準備訊息或另一數量的準備訊息。
視域更改協定下的步驟425至步驟427類似於正常操作協定下的步驟415至步驟417,但是在以下方面可以不同:(1)視域號,(2)不需要在相應節點處重新提交所提交的請求,(3)無作用節點0可以不執行步驟425至步驟427,或者不誠實地執行步驟425至步驟427。
所揭示的方法可以以較少的儲存消耗需求確保區塊鏈系統的正常功能。在一個示例中,在具有至少3F+1個節點的總數的區塊鏈系統中,當至少F+1個節點已經組播所述提交訊息時,這意味著至少2F+1個節點已經準備就緒,並且預準備訊息和至少2F個準備訊息是持久性的。在一些實施例中,在儲存階段,所述預準備訊息和至少2F個準備訊息由相應節點儲存。例如,所述主節點和/或一些備用節點已經儲存預準備訊息和準備訊息。因此,即使一個或多個或最壞情況下所有節點經歷系統崩潰和重啟,與沒有儲存階段的過程不同,在儲存階段曾經儲存的預準備訊息和至少2F個訊息被載入。因此,即使F個節點沒有重啟並恢復功能(可能已經組播或可能沒有組播所述提交訊息),因為儲存並載入了預準備訊息和至少2F個訊息,整個共識驗證過程可以有效地恢復和前進,且對儲存消耗的需求較少並且不受系統崩潰的影響,否則所述系統崩潰可能導致不一致和/或分支或影響系統的安全性和/或活躍性。
在一些實施例中,如果主節點不在重啟的節點中,則可以在超時時段結束時觸發視域更改。因為至少Q個節點已經準備就緒,即使它們中的F個節點已經提交且沒有執行重啟,(Q-F)個節點也可以執行系統重啟並載入所儲存的預準備訊息和準備訊息。由重啟的(Q-F)個節點組播的視域更改訊息將攜帶崩潰之前的預準備訊息和準備訊息,這確保由新主節點組播的新視域訊息將攜帶相同的內容。因此,防止了不一致的共識結果和區塊鏈分支。
在其他實施例中,如果主節點在重啟的Q個節點之中,則主節點可以嘗試恢復正常操作協定或提議其他操作。如果重啟不夠快,由於至少(Q-F)個節點被載入的預準備訊息和準備訊息鎖定,它們將不回應所述主節點。因此,不能達成共識,並且可以觸發視域更改以選擇新主節點。其餘的可以遵循上述視域更改實施例。
圖5A示出了根據本說明書的各種實施例的共識方法510的流程圖。方法510可以由圖1的系統112的一個或多個組件(例如,上述節點0、節點1、節點2、......或節點i或者類似設備,或者任何節點和一個或多個附加設備(例如節點A))的組合實現。方法510可以由一個或多個區塊鏈節點(例如,備用節點)實現。方法510可以由包括各種硬體機器和/或軟體的共識系統或設備(例如,電腦、伺服器)實現。例如,所述共識系統或設備可以包括一個或多個處理器和一個或多個非暫態性電腦可讀儲存媒體(例如,一個或多個記憶體),所述儲存媒體耦接到一個或多個處理器並配置有可由一個或多個處理器執行的指令,以促使系統或設備(例如,處理器)執行方法510。以下呈現的方法510的操作旨在是說明性的。根據實施方式,方法510可以包括以各種循序執行或並存執行的附加、更少或替代步驟。除非另有說明,否則下面描述的各種方塊可以不必按照圖中所示的循序執行。例如,方塊512可以在方塊513開始之後開始並且在方塊513結束之前結束。類似地,方塊515可以在方塊516開始之後開始並且在方塊516結束之前結束。又例如,可以按循序執行或並存執行方塊513和方塊514。
在一些實施例中,方法510可以在由多個(N個)節點維護的區塊鏈上實現,其中,所述節點之一用作為主節點而其他(N-1)個節點用作為備用節點,並且所述方法510由所述備用節點之一執行。N可以是不小於4的任何整數。在一些實施例中,N等於3F+1,其中,F表示系統在PBFT共識機制中可以容忍的無作用節點的數量。所述主節點和所述備用節點可以是PBFT共識機制中定義的節點。方法510可以應用於針對一個或多個請求(例如,區塊鏈交易請求)的一輪共識驗證。方法510的步驟可以由目前視域中的備用節點執行,所述備用節點可以在視域更改發生的情況下仍然為備用節點或者成為新主節點。在方法510的實現期間,根據PBFT共識機制的視域可以改變或可以不改變。方法510的進一步細節可以參考圖1至圖4B以及上面的相關描述。
方塊511包括從主節點獲得預準備訊息。在一些實施例中,在從所述主節點獲得所述預準備訊息之前,所述方法510還包括從以下中的至少一個獲得一個或多個交易請求:一個或多個客戶端、所述主節點或者一個或多個所述其他備用節點。術語“交易請求”中的交易可以透過區塊鏈系統實現並被記錄到區塊鏈中。所述交易可以包括,例如,金融交易、用於部署或調用區塊鏈合約的區塊鏈合約交易、更新區塊鏈狀態(例如,世界狀態)的交易等。所述交易不必涉及金融交易。所述交易請求可以包括要透過共識驗證添加到區塊鏈的區塊鏈交易。在一個實施例中,所述預準備訊息包括與一個或多個交易請求相對應的一個或多個交易的順序。所述順序可以由組播用於執行交易請求的預準備訊息的主節點提議。所述順序可以對應於包含交易的提議新區塊的唯一雜湊值標識。所述主節點和所述備用節點將驗證所提議的順序並嘗試達成共識。或者,所述請求可以包括用於一個或多個計算設備的另一指令,以提供資訊或執行另一功能。
方塊512包括將準備訊息組播至主節點和其他(N-2)個備用節點中的至少一些節點,所述準備訊息指示接受所述預準備訊息。組播意味著廣播到PBFT系統中的一個或多個或所有其他節點。每個運行的備用節點可以組播所述準備訊息。
方塊513包括分別從(Q-1)個或更多個所述備用節點獲得(Q-1)個或更多個準備訊息,其中,Q(法定數量)是(N+F+1)/2向上取最接近的整數,F是(N-1)/3向下取最接近的整數。例如,執行方法510的節點是N個節點之一。所述(Q-1)個準備訊息可以來自不同的節點並且是有效且一致的,這表示至少(Q-1)個備用節點和主節點同意所述預準備訊息。
方塊514包括儲存所述預準備訊息和所述(Q-1)個或更多個準備訊息。例如,如果(Q-1)是2F並且如果在前一步驟中獲得3F個準備訊息,則這裡可以儲存所述預準備訊息和多個(2F至3F個,包括2F個和3F個)準備訊息。在一些實施例中,僅儲存預準備訊息和(Q-1)個準備訊息。例如,如果(Q-1)是2F並且如果在前一步驟中獲得3F個準備訊息,則這裡可以僅儲存預準備訊息和2F個準備訊息。在一些實施例中,儲存預準備訊息和(Q-1)個或更多個準備訊息包括:僅儲存預準備訊息和(Q-1)個或更多個準備訊息。例如,僅儲存預準備訊息和(Q-1)個準備訊息。除了預準備訊息和(Q-1)個或更多個準備訊息之外,不儲存任何訊息。例如,對於每輪共識驗證,不儲存提交訊息。當進行多輪共識驗證時,同樣適用。
在一些實施例中,可以以各種方式儲存預準備訊息和至少(Q-1)個準備訊息,只要在系統停機時間恢復(例如系統重啟)之後所儲存的資料是可檢索的。例如,可以將預準備訊息和(Q-1)個或更多個準備訊息儲存在關聯式資料庫、非關聯式資料庫、文件系統等中。例如,可以將預準備訊息和(Q-1)個或更多個準備訊息儲存在永久記憶體中。本文描述的儲存步驟和其他步驟可以不受編程語言的限制。
在一些實施例中,可以僅在滿足方塊513時執行方塊514,即,僅在獲得(Q-1)個或更多個準備訊息時執行方塊514。在其他實施例中,可以在接收到每個預準備訊息或準備訊息之後立即進行儲存。
在一些實施例中,在儲存預準備訊息和(Q-1)個或更多個準備訊息(步驟514)之後並且在組播提交訊息(步驟515)之前,所述方法還包括:執行系統重啟;並且載入所儲存的預準備訊息和所儲存的(Q-1)個或更多個準備訊息。可以回應於正常操作的中斷(例如,系統崩潰、斷電等)來執行系統重啟。所述中斷可能發生在PBFT系統中的一個或多個或所有節點上。在一些實施例中,多達N個節點中的所有節點經歷崩潰;所述N個節點中的至少Q個節點執行系統重啟並分別載入所儲存的相應預準備訊息和所儲存的(Q-1)個或更多個準備訊息。接下來,可以觸發或不觸發視域更改協定。
在一個實施例中,如果重啟足夠快以避免觸發超時,則可以不觸發視域更改協定,因此系統重啟避免觸發視域更改。也就是說,執行系統重啟包括:執行系統重啟且不觸發視域更改。因此,可以繼續方法510的從方塊515開始的其餘步驟。
否則,可以觸發視域更改協定。在一個實施例中,在儲存預準備訊息和(Q-1)個或更多個準備訊息之後並且在組播提交訊息之前,所述方法還包括:組播包括所載入的預準備訊息和所載入的(Q-1)個或更多個準備訊息的視域更改訊息。其他備用節點也可以組播視域更改訊息。所述備用節點之一可以被選擇成為新主節點,所述備用節點之一可以是或可以不是執行前述步驟的該一個備用節點。
在一些實施例中,如果執行上述步驟的備用節點未被選為新主節點,則它可以仍然為備用節點並在視域更改期間執行以下步驟。在儲存預準備訊息和(Q-1)個或更多個準備訊息之後並且在組播提交訊息之前,所述方法還包括:從新主節點獲得指示所述新主節點已經接收Q個或更多個視域更改訊息的新視域訊息,所述視域更改訊息各自指示相應節點同意所述視域更改訊息;將另一準備訊息組播至包括新主節點的至少一些所述備用節點,所述另一準備訊息指示接受所述新視域訊息;分別從(Q-1)個或更多個備用節點獲得另一(Q-1)個或更多個準備訊息,其中,所述另一(Q-1)個或更多個準備訊息包括組播另一準備訊息。
在其他實施例中,如果執行上述步驟的節點被選為新主節點,則它可以成為新主節點並在視域更改期間執行以下步驟。在儲存預準備訊息和(Q-1)個或更多個準備訊息之後並且在組播提交訊息之前,所述方法還包括:分別從Q個或更多個備用節點獲得Q個或更多個視域更改訊息,所述視域更改訊息各自指示相應節點同意所述視域更改訊息,其中,Q個或更多個視域更改訊息包括所述組播視域更改訊息;向至少一些所述備用節點組播指示該備用節點已經作為新主節點接收所述Q個或更多個視域更改訊息的新視域訊息;分別從(Q-1)個或更多個備用節點獲得另一(Q-1)個或更多個準備訊息,其中,所述另一(Q-1)個或更多個準備訊息包括所述組播另一準備訊息。
如果視域更改沒有發生,則可以在與方塊511至方塊514相同的視域中執行方塊515和方塊516以及隨後的步驟,或者如果在方塊515之前發生視域更改,則可以在新視域中執行方塊515和方塊516以及隨後的步驟。
方塊515包括將提交訊息組播至所述主節點和其他備用節點中的至少一些節點,所述提交訊息指示該一個備用節點同意(Q-1)個或更多個準備訊息。在一些實施例中,所述提交訊息指示該一個備用節點同意預準備訊息並且已經獲得(Q-1)個或更多個準備訊息。在一些實施例中,可以執行驗證步驟以同意組播所述提交訊息。例如,如上所述,可以根據針對摘要d進行驗證的順序來確定摘要D(m)。如果是一致的,則可以組播提交訊息。
在一些實施例中,方塊513中的(Q-1)個或更多個備用節點中的多達F個節點在分別組播提交訊息之後是故障的或者在其他方面是無功能的,並且不執行系統重啟。例如,已提交的F個節點可能會遇到系統崩潰,並且不會重啟以恢復功能。儘管如此,可以正確地執行共識驗證,而不會導致不一致的結果和區塊鏈分支。
方塊516包括分別從所述主節點和所述備用節點中的Q個或更多個節點獲得Q個或更多個提交訊息,所述提交訊息各自指示相應節點同意由所述相應節點接收的(Q-1)個或更多個準備訊息。在一些實施例中,所述提交訊息指示組播所述提交訊息的相應節點同意預準備訊息並且已經獲得(Q-1)個或更多個準備訊息。所述Q個提交訊息可以來自不同的節點並且是有效的且一致的,這指示Q個節點準備就緒以按循序執行所述請求。因此,大多數節點達成共識,並且可以執行下一個執行步驟。
在一些實施例中,在組播提交訊息(方塊515)之後並且在執行請求之前,所述方法還包括:執行系統重啟,並且載入所儲存的預準備訊息和所儲存的(Q-1)個或更多個準備訊息。所述系統重啟可以是自動的或非自動的。所述系統重啟可能是由系統或設備功能中斷引起的,例如系統崩潰。
在一些實施例中,方法510還可以包括根據所述順序將所述一個或多個交易打包到所述區塊鏈的由該一個備用節點維護的本地副本中。例如,所述請求可以被共識驗證,因為至少(Q-F)個誠實節點(Q個提交訊息但考慮了至多F個無作用節點)已經驗證其提交訊息中的摘要d(或者對於主節點,可以不必執行驗證,因為所述主節點提議所述摘要d)。因此,如果足夠的節點已經驗證相應交易,則可以將交易打包到區塊鏈中。可以通知最初發送請求的客戶端(例如,節點A)。
圖5B示出了根據本說明書的各種實施例的共識方法520的流程圖。方法520可以由圖1的系統112的一個或多個組件(例如,上述節點0、節點1、節點2、......或節點i或者類似設備,或者任何節點和一個或多個附加設備(例如節點A)的組合)實現。方法520可以由一個或多個區塊鏈節點(例如,主節點)實現。方法520可以由包括各種硬體機器和/或軟體的共識系統或設備(例如,電腦、伺服器)實現。例如,所述共識系統或設備可以包括一個或多個處理器和一個或多個非暫態性電腦可讀儲存媒體(例如,一個或多個記憶體),所述儲存媒體耦接到一個或多個處理器並配置有可由一個或多個處理器執行的指令,以促使系統或設備(例如,處理器)執行方法520。以下呈現的方法520的操作旨在是說明性的。根據實施方式,方法520可以包括以各種循序執行或並存執行的附加、更少或替代步驟。除非另有說明,否則下面描述的各種方塊可以不必按照圖中所示的循序執行。例如,方塊521可以在方塊522開始之後開始並且在方塊522結束之前結束。類似地,方塊524可以在方塊525開始之後開始並且在方塊525結束之前結束。又例如,可以按循序執行或並存執行方塊522和方塊523。
在一些實施例中,方法520可以在由多個(N個)節點維護的區塊鏈上實現,其中,所述節點之一用作為主節點而其他(N-1)個節點用作為備用節點,並且所述方法520由主節點執行。所述主節點和所述備用節點可以是PBFT模型中定義的節點。方法520可以應用於針對一個或多個請求(例如,區塊鏈交易請求)的一輪共識驗證。方法520的進一步細節可以參考圖1至圖4B以及上面的相關描述。
方塊521包括將預準備訊息組播至至少一些所述備用節點。在一些實施例中,在將所述預準備訊息組播至至少一些所述備用節點之前,方法520還包括從以下中的至少一個獲得一個或多個交易請求:一個或多個客戶端(例如,輕節點)或者一個或多個所述備用節點。所述交易請求可以包括要透過共識驗證添加到區塊鏈中的區塊鏈交易。在一個實施例中,所述預準備訊息包括與一個或多個交易請求相對應的一個或多個交易的順序。所述順序可以由組播用於執行交易請求的預準備訊息的主節點提議。所述順序可以對應於包含交易的提議新區塊的唯一雜湊值標識。所述主節點和所述備用節點將驗證所提議的順序並嘗試達成共識。或者,所述請求可以包括用於一個或多個計算設備的另一指令,以提供資訊或執行另一功能。
除了如果主節點變成無功能的,則視域更改被觸發並且新主節點被選擇之外,方塊522至方塊525可以類似於方塊513至方塊516以及上面的相關描述。
方塊522包括分別從(Q-1)個或更多個備用節點獲得(Q-1)個或更多個準備訊息,其中,所述準備訊息各自指示相應備用節點接受所述預準備訊息,Q(法定數量)是(N+F+ 1)/2向上取最接近的整數,F是(N-1)/3向下取最接近的整數。所述備用節點可以分別組播所述準備訊息。在一些實施例中,F表示為保持N個節點的共識系統運行,N個節點中被允許的無作用節點的最大數量。例如,執行方法520的節點是N個節點之一。所述(Q-1)個或更多個準備訊息可以來自不同的節點並且是有效的且一致的,這指示(Q-1)個或更多個備用節點和主節點同意所述預準備訊息。
方塊523包括儲存所述預準備訊息和所述(Q-1)個或更多個準備訊息。例如,如果(Q-1)是2F並且如果在前一步驟中獲得3F個準備訊息,則這裡可以儲存預準備訊息和多個(2F至3F個,包括2F個和3F個)準備訊息。在一些實施例中,僅儲存預準備訊息和(Q-1)個準備訊息。例如,如果(Q-1)是2F並且如果在前一步驟中獲得3F個準備訊息,則這裡可以僅儲存預準備訊息和2F個準備訊息。在一些實施例中,儲存預準備訊息和(Q-1)個或更多個準備訊息包括:僅儲存預準備訊息和(Q-1)個或更多個準備訊息。例如,僅儲存預準備訊息和(Q-1)個準備訊息。除了預準備訊息和(Q-1)個或更多個準備訊息之外,不儲存任何訊息。例如,對於每輪共識驗證,不儲存提交訊息。當進行多輪共識驗證時,同樣適用。
在一些實施例中,可以以各種方式儲存預準備訊息和(Q-1)個或更多個準備訊息,只要在系統停機時間恢復(例如系統重啟)之後所儲存的資料是可檢索的。例如,可以將預準備訊息和(Q-1)個或更多個準備訊息儲存在關聯式資料庫、非關聯式資料庫、文件系統等中。例如,可以將預準備訊息和(Q-1)個或更多個準備訊息儲存在永久記憶體中。本文描述的儲存步驟和其他步驟可以不受編程語言的限制。
在一些實施例中,可以僅在滿足方塊522時執行方塊523,即,僅在獲得(Q-1)個或更多個準備訊息時執行方塊523。在其他實施例中,可以在接收到每個預準備訊息或準備訊息之後立即進行儲存。
在一些實施例中,在儲存預準備訊息和(Q-1)個或更多個準備訊息(方塊523)之後並且在組播所述提交訊息(方塊524)之前,所述方法還包括:執行系統重啟;並且載入所儲存的預準備訊息和所儲存的(Q-1)個或更多個準備訊息。可以回應於正常操作的中斷(例如,系統崩潰、斷電等)執行系統重啟。所述中斷可以發生在PBFT系統中的一個或多個或所有節點上。在一些實施例中,多達N個節點中的所有節點經歷崩潰;所述N個節點中的至少Q個節點執行系統重啟並分別載入所儲存的相應預準備訊息和所儲存的(Q-1)個或更多個準備訊息。接下來,可以觸發或不觸發視域更改協定。
在一個實施例中,如果重啟足夠快以避免觸發超時,則可以不觸發視域更改協定,因此系統重啟避免觸發視域更改。因此,可以繼續方法520的從方塊524開始的其餘步驟。在另一實施例中,可以觸發視域更改協定,並且可以不繼續方法520的從方塊524開始的其餘步驟。
方塊524包括將提交訊息組播至至少一些備用節點,所述提交訊息指示所述主節點同意(Q-1)個或更多個準備訊息。在一些實施例中,所述提交訊息指示所述主節點已獲得(Q-1)個或更多個準備訊息。在一些實施例中,方塊522中的(Q-1)個或更多個備用節點中的多達F個節點在分別組播所述提交訊息之後是故障的或者在其他方面是無功能的,並且不執行系統重啟。例如,已提交的F個節點可能會遇到系統崩潰,並且不會重啟以恢復功能。儘管如此,可以正確地執行共識驗證,而不會導致不一致的結果和區塊鏈分支。
方塊525包括分別從主節點和備用節點中的Q個或更多個節點獲得Q個或更多個提交訊息,所述提交訊息各自指示相應節點同意由所述相應節點接收的(Q-1)個或更多個準備訊息,其中,Q個或更多個提交訊息包括組播提交訊息。在一些實施例中,所述提交訊息指示組播所述提交訊息的相應節點同意預準備訊息並且已經獲得(Q-1)個或更多個準備訊息。所述Q個或更多個提交訊息可以來自不同的節點並且是有效的且一致的,這指示Q個或更多個節點準備就緒以按循序執行所述請求。因此,大多數節點達成共識,並且可以執行下一個執行步驟。
在一些實施例中,在組播提交訊息(方塊525)之後並且在執行請求之前,所述方法還包括:執行系統重啟,並且載入所儲存的預準備訊息和所儲存的(Q-1)個或更多個準備訊息。所述系統重啟可以是自動的或非自動的。所述系統重啟可能是由系統或設備功能中斷引起的,例如系統崩潰。
在一些實施例中,方法520還可以包括根據所述順序將所述一個或多個交易打包到所述區塊鏈的由所述主節點維護的本地副本中。例如,可以對請求進行共識驗證,因為至少(Q-F)個誠實節點(Q個提交訊息但考慮了至多F個無作用節點)已經驗證其提交訊息中的摘要d(或者對於主節點,可以不必執行驗證,因為所述主節點提議所述摘要d)。因此,如果足夠的節點已經驗證相應交易,則可以將交易打包到區塊鏈中。可以通知最初發送請求的客戶端(例如,節點A)。
圖6A示出了根據各種實施例的共識系統610的方塊圖。共識系統610(例如,電腦系統)可以是上述節點0、節點1、節點2、......或節點i或者類似設備,或者任何節點和附加設備(例如,節點A)的組合的實現的示例。方法510可以由共識系統610實現。共識系統610可以包括一個或多個處理器和一個或多個非暫態性電腦可讀儲存媒體(例如,一個或多個記憶體),所述非暫態性電腦可讀儲存媒體耦接到一個或多個處理器並配置有可由一個或多個處理器執行的指令,以促使系統或設備(例如,處理器)執行方法510。共識系統610可以在備用節點中實現。共識系統610可以包括與指令(例如,軟體指令)相對應的各種單元/模組。
在一些實施例中,共識系統610可以被稱為共識設備。所述共識設備可以用於維護區塊鏈,其中,多個(N個)節點維護區塊鏈,其中,N個節點之一用作為主節點而其他(N-1)個節點用作為備用節點,所述共識設備用作為(N-1)個備用節點之一,並且包括一個或多個處理器和一個或多個非暫態性電腦可讀記憶體,所述記憶體耦接到一個或多個處理器並配置有可由一個或多個處理器執行的指令,以促使所述設備執行操作。所述共識設備可以包括與指令(例如,軟體指令)對應的各種單元/模組。所述共識設備可以包括:第一獲取模組611,用於從主節點獲得預準備訊息;第一組播模組612,用於將準備訊息組播到主節點和其他(N-2)個備用節點中的至少一些節點,所述準備訊息指示接受所述預準備訊息;第二獲取模組613,用於分別從(Q-1)個或更多個備用節點獲取(Q-1)個或更多個準備訊息,其中,Q(法定數量)為(N+F+1)/2向上取最接近的整數,F是(N-1)/3向下取最接近的整數,並且(Q-1)個或更多個準備訊息包括所述組播準備訊息;儲存模組614,用於儲存預準備訊息和(Q-1)個或更多個準備訊息;第二組播模組615,用於將提交訊息組播至主節點和其他備用節點中的至少一些節點,所述提交訊息指示該一個備用節點同意(Q-1)個或更多個準備訊息;第三獲取模組616,用於分別從主節點和備用節點中的Q個或更多個節點獲取Q個或更多個提交訊息,所述提交訊息各自指示相應節點同意由所述相應節點接收的(Q-1)個或更多個準備訊息,其中,所述Q個或更多個提交訊息包括所述組播提交訊息。
在一些實施例中,第一獲取模組611或另一模組還用於從以下中的至少一個獲得一個或多個交易請求:一個或多個客戶端、主節點或者一個或多個其他備用節點。所述共識設備還可以包括打包模組617,用於根據所述順序將所述一個或多個交易打包到所述區塊鏈的由該一個備用節點維護的本地副本中。
圖6B示出了根據各種實施例的共識系統620的方塊圖。共識系統620(例如,電腦系統)可以是上述節點0、節點1、節點2、......或節點i或者類似設備,或者任何節點和附加設備(例如,節點A)的組合的實現的示例。方法520可以由共識系統620實現。共識系統620可以包括一個或多個處理器和一個或多個非暫態性電腦可讀儲存媒體(例如,一個或多個記憶體),所述非暫態性電腦可讀儲存媒體耦接到一個或多個處理器並配置有可由一個或多個處理器執行的指令,以促使系統或設備(例如,處理器)執行方法520。共識系統620可以在主節點中實現。共識系統620可以包括與指令(例如,軟體指令)相對應的各種單元/模組。
在一些實施例中,共識系統620可以被稱為共識設備。所述共識設備可以用於維護區塊鏈,其中,多個(N個)節點維護區塊鏈,其中,N個節點之一用作為主節點而其他(N-1)個節點用作為備用節點,所述共識設備用作為主節點並且包括一個或多個處理器和一個或多個非暫態性電腦可讀記憶體,所述記憶體耦接到一個或多個處理器並配置有可由一個或多個處理器執行的指令,以促使所述設備執行操作。所述共識設備可以包括與指令(例如,軟體指令)對應的各種單元/模組。所述共識設備可以包括第一組播模組621,用於將預準備訊息組播至至少一些所述備用節點;第一獲取模組622,用於分別從(Q-1)個或更多個備用節點獲取(Q-1)個或更多個準備訊息,其中,所述準備訊息各自指示相應備用節點接受預準備訊息,Q(法定數量)是(N+F+1)/2向上取最接近的整數,F是(N-1)/3向下取最接近的整數;儲存模組623,用於儲存預準備訊息和(Q-1)個或更多個準備訊息;第二組播模組624,用於將提交訊息組播至至少一些備用節點,所述提交訊息指示所述主節點同意(Q-1)個或更多個準備訊息;第二獲取模組625,用於分別從主節點和備用節點中的Q個或更多個節點獲取Q個或更多個提交訊息,所述提交訊息各自指示相應節點同意由所述相應節點接收的(Q-1)個或更多個準備訊息,其中,所述Q個或更多個提交訊息包括組播提交訊息。
在一些實施例中,所述共識設備還可以包括第三獲取模組626,用於從以下中的至少一個獲得一個或多個交易請求:一個或多個客戶端或者一個或多個備用節點。所述共識設備還可以包括打包模組627,用於根據所述順序將所述一個或多個交易打包到所述區塊鏈的由所述主節點維護的本地副本中。
本文描述的技術由一個或多個專用計算設備實現。專用計算設備可以是桌上型電腦系統、伺服器電腦系統、便攜式電腦系統、手持設備、網路設備或結合硬連線和/或程式邏輯以實現這些技術的任何其他設備或設備的組合。專用計算設備可以被實現為個人電腦、膝上型電腦、蜂巢式電話、照相電話、智慧慧型電話、個人數位助理、媒體播放機、導航設備、電子郵件設備、遊戲控制台、平板電腦、可穿戴設備或其組合。計算設備通常由作業系統軟體控制和協調。傳統的作業系統控制和調度用於執行的電腦進程,執行記憶體管理,提供檔案系統、網路、I/O服務,以及提供用戶介面功能,例如圖形化用戶介面(“GUI”)等。這裡描述的各種系統、裝置、儲存媒體、模組和單元可以在專用計算設備或者一個或多個專用計算設備的一個或多個計算晶片中實現。在一些實施例中,本文描述的指令可以在專用計算設備上的虛擬機中實現。當被執行時,指令可以促使專用計算設備執行本文描述的各種方法。虛擬機可以包括軟體、硬體或其組合。例如,虛擬機可以包括為乙太坊中的智慧合約提供運行時環境的乙太坊虛擬機(EVM)軟體。
圖7是示出電腦系統700的方塊圖,在所述電腦系統700上可以實現本文描述的任何實施例。系統700可以執行本文描述的任何方法(例如,共識方法510、共識方法520)。系統700可以在本文描述的任何系統(例如,共識系統610、共識系統620)中實現。系統700可以在本文描述的任何節點中實現,並且被配置為執行用於實現區塊鏈合約的相應步驟。電腦系統700包括用於通訊資訊的匯流排702或其他通訊機制,與匯流排702耦接以處理資訊的一個或多個硬體處理器704。硬體處理器704可以是例如一個或多個通用微處理器。
電腦系統700還包括耦接到匯流排702的用於儲存資訊和可由處理器704執行的指令的主記憶體706,例如隨機存取記憶體(RAM)、快取記憶體和/或其他動態儲存裝置設備。主記憶體706還可以用於在執行可由處理器704執行的指令期間儲存臨時變數或其他中間資訊。當這些指令儲存在處理器704可存取的儲存媒體中時,這些指令將電腦系統700呈現為被定制以執行指令中指定的操作的專用機器。電腦系統700還包括耦接到匯流排702的用於儲存處理器704的靜態資訊和指令的唯讀記憶體(ROM)708或其他靜態儲存裝置。儲存裝置710諸如磁碟、光碟或USB拇指驅動器(快閃記憶體驅動器)等被提供並被耦接到匯流排702以儲存資訊和指令。
電腦系統700可以使用與電腦系統相結合使得電腦系統700成為專用機器或將電腦系統700編程為專用機器的定制硬連線邏輯、一個或多個ASIC或FPGA、韌體和/或程式邏輯實現本文所述的技術。根據一個實施例,本文描述的操作、方法和過程由電腦系統700回應於處理器704執行主記憶體706中包含的一個或多個指令的一個或多個序列而執行。這些指令可以從另一儲存媒體(例如,儲存裝置710)讀入主記憶體706中。主記憶體706中包含的指令序列的執行促使處理器704執行本文描述的處理步驟。在替代實施例中,可以使用硬連線電路代替軟體指令或與軟體指令組合。
主記憶體706、ROM 708和/或儲存器710可以包括非暫態性儲存媒體。本文使用的術語“非暫態性媒體”和類似術語是指儲存促使機器以特定方式操作的資料和/或指令的媒體,所述媒體不包括暫態性信號。這種非暫態性媒體可以包括非易失性媒體和/或易失性媒體。例如,非易失性媒體包括光碟或磁片,諸如儲存裝置710。易失性媒體包括動態記憶體,例如主記憶體706。習知形式的非暫態性媒體包括,例如,軟磁碟、軟碟、硬碟、固態硬碟、磁帶或任何其他磁資料儲存媒體、CD-ROM、任何其他光學資料儲存媒體、具有孔圖案的任何物理媒體、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其他記憶體晶片或盒式磁帶的以及它們的網路版本。
電腦系統700還包括耦接到匯流排702的網路介面718。網路介面718提供耦接到一個或多個網路鏈路的雙向資料通訊,所述一個或多個網路鏈路連接到一個或多個本地網路。例如,網路介面718可以是整合式服務數位網路(ISDN)卡、電纜數據機、衛星數據機或數據機,以提供與相應類型的電話線的資料通訊連接。作為另一示例,網路介面718可以是區域網(LAN)卡,以提供到相容LAN(或與WAN通訊的WAN組件)的資料通訊連接。還可以實現無線鏈路。在任何這樣的實施方式中,網路介面718發送和接收攜帶表示各種類型的資訊的數位資料流程的電信號、電磁信號或光信號。
電腦系統700可以透過網路、網路鏈路和網路介面718發送訊息和接收資料,包括程式代碼。在網際網路示例中,伺服器可以透過網際網路、ISP、本地網路和網路介面718發送用於應用程式的請求代碼。
所接收的代碼可在其被接收時由處理器704執行,和/或儲存在儲存裝置710或其他非易失性記憶體中以用於稍後執行。
前面部分中描述的每個過程、方法和演算法可以在由包括電腦硬體的一個或多個電腦系統或電腦處理器執行的代碼模組中實現,並且完全或部分自動化地實現。過程和演算法可以部分或全部地在專用電路中實現。
上述各種特徵和過程可以彼此獨立地使用,或者可以以各種方式組合。所有可能的組合和子組合都旨在落入本說明書的範圍內。另外,在一些實施方式中可以省略某些方法或過程方塊。本文描述的方法和過程也不限於任何特定序列,與其相關的方塊或狀態可以以適當的其他序列執行。例如,所描述的方塊或狀態可以以不同於具體揭示的循序執行,或者多個方塊或狀態可以在單個方塊或狀態中組合。方塊或狀態的示例可以串列、並行或以某種其他方式執行。可以將方塊或狀態添加到所揭示的實施例中或從所揭示的實施例中移除。本文描述的系統和組件的示例可以與所描述的不同地被配置。例如,與所揭示的實施例相比,可以添加、移除或重新排列組件。
本文描述的方法的各種操作可以至少部分地由被臨時配置(例如,透過軟體)或被永久配置為執行相關操作的一個或多個處理器執行。無論是臨時配置還是永久配置,這樣的處理器可以構成處理器實現引擎,所述處理器實現引擎操作以執行本文描述的一個或多個操作或功能。
類似地,本文描述的方法可以至少部分地由處理器實現,其中,一個或多個特定處理器是硬體的示例。例如,所述方法的至少一些操作可以由一個或多個處理器或處理器實現引擎執行。此外,一個或多個處理器還可以操作以支持“雲計算”環境中的相關操作的性能或作為“軟體即服務”(SaaS)。例如,至少一些操作可以由一組電腦(作為包括處理器的機器的示例)執行,這些操作可以經由網路(例如,網際網路)並且經由一個或多個適當的介面(例如,應用程式介面(API))被存取。
某些操作的性能可以在處理器之間分配,不僅駐留在單個機器中,而且跨多個機器被部署。在一些實施例中,處理器或處理器實現引擎可以位於單個地理位置(例如,在家庭環境、辦公室環境或伺服器群內)。在其他實施例中,處理器或處理器實現引擎可以分布在多個地理位置。
在整個說明書中,多個實例可以實現作為單個實例所描述的組件、操作或結構。儘管一個或多個方法的各個操作被示出並描述為獨立的操作,但是可以同時執行一個或多個獨立的操作,並且不需要以所示的循序執行所述操作。在配置中作為獨立組件呈現的結構和功能可以實現為組合結構或組件。類似地,作為單個組件呈現的結構和功能可以實現為獨立的組件。這些和其他變化、修改、添加和改進都落入本文中的主題的範圍內。此外,本文使用的相關術語(諸如“第一”、“第二”、“第三”等)不表示任何順序、高度或重要性,而是用於將一個組件與另一組件區分開。此外,術語“一”、“一個”和“多個”在本文中並不表示數量的限制,而是表示存在至少一個所述的物品。
儘管已經參考具體實施例描述了主題的概述,但是在不脫離本說明書的實施例的較寬範圍的情況下,可以對這些實施例進行各種修改和改變。具體實施方式不應被視為具有限制意義,並且各種實施例的範圍僅由所附申請專利範圍以及這些申請專利範圍所賦予的等同物的全部範圍限定。
112:網路系統
120:網路
610:共識系統
611:第一獲取模組
612:第一組播模組
613:第二獲取模組
614:儲存模組
615:第二組播模組
616:第三獲取模組
617:打包模組
620:共識系統
621:第一組播模組
622:第一獲取模組
623:儲存模組
624:第二組播模組
625:第二獲取模組
626:第三獲取模組
627:打包模組
700:電腦系統
702:匯流排
704:處理器
706:主記憶體
708:唯讀記憶體(ROM)
710:儲存裝置
718:網路介面
[圖1]示出了根據各種實施例的網路。
[圖2A]示出了PBFT的正常操作協定。
[圖2B]示出了具有一個故障副本的PBFT的正常操作協定。
[圖2C]示出了PBFT的正常操作協定和視域更改協定。
[圖3A]示出了PBFT的正常操作協定的步驟的流程圖。
[圖3B]示出了PBFT的視域更改協定的步驟的流程圖。
[圖3C]示出了根據各種實施例的共識系統的正常操作協定的步驟的流程圖。
[圖4A]至[圖4D]各自示出了根據各種實施例的共識步驟的流程圖。
[圖5A]示出了根據各種實施例的共識方法的流程圖。
[圖5B]示出了根據各種實施例的共識方法的流程圖。
[圖6A]示出了根據各種實施例的共識系統的方塊圖。
[圖6B]示出了根據各種實施例的共識系統的方塊圖。
[圖7]示出了電腦系統的方塊圖,其可以實現本文描述的任何實施例。
112:網路系統
120:網路
Claims (15)
- 一種電腦實現之施行於由多個(即N個)節點所維護的區塊鏈上的共識方法,其中,該等節點的其中之一用作為主節點而其他(N-1)個節點用作為備用節點,而且該方法係由該等備用節點的其中之一所執行,該方法包括: 從該主節點獲取預準備訊息; 將準備訊息組播至該主節點和其他(N-2)個備用節點中的至少一些節點,該準備訊息指示接受該預準備訊息; 分別從該等備用節點中的(Q-1)個或更多個獲得(Q-1)個或更多個準備訊息,其中,法定數量Q是(N+F+1)/2向上取最接近的整數,且F是(N-1)/3向下取最接近的整數; 儲存該預準備訊息和該(Q-1)個或更多個準備訊息; 將提交訊息組播至該主節點和該等其他備用節點中的至少一些節點,該提交訊息指示該一個備用節點同意該(Q-1)個或更多個準備訊息;以及 分別從該主節點和該等備用節點中的Q個或更多個節點獲得Q個或更多個提交訊息,該Q個或更多個提交訊息各自指示相應節點同意由該相應節點接收到的(Q-1)個或更多個準備訊息。
- 如請求項1所述的方法,其中: 在從該主節點獲得該預準備訊息之前,該方法還包括從以下中的至少一個獲得一個或更多個交易請求:一個或更多個客戶端、該主節點、或者該等其他備用節點中的一個或更多個。
- 如請求項2所述的方法,其中: 該預準備訊息包括與該一個或更多個交易請求相對應的一個或更多個交易的順序;以及 該提交訊息指示發送該提交訊息的該相應節點同意該順序。
- 如請求項3所述的方法,還包括: 根據該順序將該一個或更多個交易打包到該區塊鏈之由該一個備用節點所維護的本地副本中。
- 如請求項1至4中任一項所述的方法,其中: 該(Q-1)個或更多個準備訊息包含該組播後的準備訊息;以及 該Q個或更多個提交訊息包含該組播後的提交訊息。
- 如請求項1至4中任一項所述的方法,其中,儲存該預準備訊息和該(Q-1)個或更多個準備訊息包括: 僅儲存該預準備訊息和該(Q-1)個或更多個準備訊息。
- 如請求項1至4中任一項所述的方法,在組播該提交訊息之後,還包括: 執行系統重啟;以及 載入該儲存的預準備訊息和該等儲存的(Q-1)個或更多個準備訊息。
- 如請求項1-4中任一項所述的方法,在儲存該預準備訊息和該(Q-1)個或更多個準備訊息之後並且在組播該提交訊息之前,還包括: 執行系統重啟;以及 載入該儲存的預準備訊息和該等儲存的(Q-1)個或更多個準備訊息。
- 如請求項8所述的方法,在儲存該預準備訊息和該(Q-1)個或更多個準備訊息之後並且在組播該提交訊息之前,還包括: 組播視域更改訊息,該視域更改訊息包括該載入的預準備訊息和該等載入的(Q-1)個或更多個準備訊息。
- 如請求項9所述的方法,在儲存該預準備訊息和該(Q-1)個或更多個準備訊息之後並且在組播該提交訊息之前,還包括: 從新主節點獲得指示該新主節點已經接收Q個或更多個視域更改訊息的新視域訊息,該等視域更改訊息各自指示該相應節點同意該視域更改訊息; 將另一準備訊息組播至該等備用節點中包含該新主節點的至少一些,該另一準備訊息指示接受該新視域訊息;以及 分別從該等備用節點中的(Q-1)個或更多個獲得另一(Q-1)個或更多個準備訊息。
- 如請求項10所述的方法,其中: 該Q個或更多個視域更改訊息包含該組播後的視域更改訊息;以及 該另一(Q-1)個或更多個準備訊息包含該另一組播後的準備訊息。
- 如請求項9所述的方法,在儲存該預準備訊息和該(Q-1)個或更多個準備訊息之後並且在組播該提交訊息之前,還包括: 分別從該等備用節點中的Q個或更多個獲得Q個或更多個視域更改訊息,該視域更改訊息各自指示該相應節點同意該視域更改訊息; 向該等備用節點中的至少一些組播指示用作為新主節點的該一個備用節點已經接收到該Q個或更多個視域更改訊息的新視域訊息;以及 分別從該等備用節點中的(Q-1)個或更多個獲得另一(Q-1)個或更多個準備訊息。
- 如請求項8所述的方法,其中,執行該系統重啟包括: 執行該系統重啟且不觸發視域更改。
- 一種用作為備用節點中用以維護區塊鏈的一個備用節點的共識系統,包括: 一個或更多個處理器;以及 耦接到該一個或更多個處理器並且具有指令儲存於其上的一個或更多個電腦可讀記憶體,該等指令能由該一個或更多個處理器執行以實施如請求項1至13中任一項所述的方法。
- 一種用作為備用節點中用以維護區塊鏈的一個備用節點的共識設備,該設備包括用以實施如請求項1至13中任一項所述的方法的複數個模組。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
WOPCT/CN2019/078552 | 2019-03-18 | ||
PCT/CN2019/078552 WO2019101245A2 (en) | 2019-03-18 | 2019-03-18 | Consensus system downtime recovery |
Publications (2)
Publication Number | Publication Date |
---|---|
TW202037138A true TW202037138A (zh) | 2020-10-01 |
TWI724678B TWI724678B (zh) | 2021-04-11 |
Family
ID=66631283
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
TW108144879A TWI724678B (zh) | 2019-03-18 | 2019-12-09 | 共識系統停機時間恢復 |
Country Status (9)
Country | Link |
---|---|
US (2) | US11347598B2 (zh) |
EP (1) | EP3607733B1 (zh) |
JP (1) | JP6880227B2 (zh) |
KR (1) | KR102365793B1 (zh) |
CN (1) | CN110870288B (zh) |
AU (1) | AU2019203865B2 (zh) |
SG (1) | SG11201908387SA (zh) |
TW (1) | TWI724678B (zh) |
WO (1) | WO2019101245A2 (zh) |
Families Citing this family (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
SG11201908853YA (en) * | 2019-03-18 | 2019-10-30 | Alibaba Group Holding Ltd | System and method for ending view change protocol |
CA3058233C (en) | 2019-03-18 | 2023-03-07 | Alibaba Group Holding Limited | Consensus system downtime recovery |
JP6923674B2 (ja) | 2019-03-18 | 2021-08-25 | アドバンスド ニュー テクノロジーズ カンパニー リミテッド | ビュー変更プロトコルを終了するためのシステムおよび方法 |
US10938750B2 (en) | 2019-03-18 | 2021-03-02 | Advanced New Technologies Co., Ltd. | Consensus system downtime recovery |
US11108553B2 (en) * | 2019-04-05 | 2021-08-31 | International Business Machines Corporation | Database transaction guaranteed commitment |
EP3669280B1 (en) | 2019-07-11 | 2021-09-08 | Advanced New Technologies Co., Ltd. | Shared blockchain data storage |
EP3673620B8 (en) | 2019-07-11 | 2022-02-16 | Advanced New Technologies Co., Ltd. | Shared blockchain data storage |
WO2019179538A2 (en) | 2019-07-11 | 2019-09-26 | Alibaba Group Holding Limited | Shared blockchain data storage |
CN114401150B (zh) | 2019-09-05 | 2023-10-20 | 创新先进技术有限公司 | 区块链网络中加入节点的方法和区块链系统 |
CN110730204B (zh) * | 2019-09-05 | 2022-09-02 | 创新先进技术有限公司 | 区块链网络中删除节点的方法和区块链系统 |
US20210099312A1 (en) * | 2019-09-27 | 2021-04-01 | Cypherium Blockchain Inc. | Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system |
CN110460484B (zh) * | 2019-10-10 | 2020-02-18 | 杭州趣链科技有限公司 | 一种基于pbft算法改进的单节点异常主动恢复方法 |
CN111522648B (zh) * | 2020-07-03 | 2020-10-09 | 支付宝(杭州)信息技术有限公司 | 一种区块链的交易处理方法、装置及电子设备 |
KR102447063B1 (ko) * | 2020-12-24 | 2022-09-23 | 한양대학교 산학협력단 | 개선된 pbft 기반의 블록체인 관리 방법, 블록체인 시스템 및 노드 장치 |
US11343313B1 (en) * | 2021-01-28 | 2022-05-24 | International Business Machines Corporation | Fault tolerant periodic leader rotation for blockchain |
US11743327B2 (en) * | 2021-02-05 | 2023-08-29 | International Business Machines Corporation | Topological ordering of blockchain associated proposals |
KR102574890B1 (ko) * | 2021-04-02 | 2023-09-06 | 주식회사 헤세그 | 장애 노드에 내성을 갖는 블록체인 시스템 및 그 동작 방법 |
CN113850600B (zh) * | 2021-12-01 | 2022-04-26 | 深圳前海微众银行股份有限公司 | 基于区块链的交易共识方法、装置、设备及存储介质 |
KR20240047735A (ko) * | 2022-10-05 | 2024-04-12 | 한양대학교 산학협력단 | 상태기계복제를 위한 2단계 비잔틴 합의 방법 및 시스템 |
CN116991623B (zh) * | 2023-08-30 | 2024-01-02 | 杭州趣链科技有限公司 | 区块链节点异常恢复方法、装置、电子设备及存储介质 |
Family Cites Families (63)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6728958B1 (en) | 1998-07-31 | 2004-04-27 | Hewlett-Packard Development Company, L.P. | Volatile resource manager with pre-prepare notification |
US6671821B1 (en) | 1999-11-22 | 2003-12-30 | Massachusetts Institute Of Technology | Byzantine fault tolerance |
EP1543420B1 (en) * | 2002-07-29 | 2012-04-04 | Open Invention Network LLC | Consistent message ordering for semi-active and passive replication |
US7454521B2 (en) * | 2003-10-23 | 2008-11-18 | Microsoft Corporation | Byzantine fault quantifying clock synchronization |
US20080222111A1 (en) | 2007-03-07 | 2008-09-11 | Oracle International Corporation | Database system with dynamic database caching |
US8943271B2 (en) | 2008-06-12 | 2015-01-27 | Microsoft Corporation | Distributed cache arrangement |
US9455992B2 (en) | 2009-06-12 | 2016-09-27 | Microsoft Technology Licensing, Llc | Trusted hardware component for distributed systems |
US8856593B2 (en) | 2010-04-12 | 2014-10-07 | Sandisk Enterprise Ip Llc | Failure recovery using consensus replication in a distributed flash memory system |
US8549142B2 (en) | 2011-03-28 | 2013-10-01 | Siemens Corporation | Replicated state machine utilizing view change protocol resilient to performance attacks |
US20130138614A1 (en) | 2011-11-30 | 2013-05-30 | Mark Travis | Two-phase data locking transaction processing with distributed partitions and mirroring |
US9450852B1 (en) * | 2014-01-03 | 2016-09-20 | Juniper Networks, Inc. | Systems and methods for preventing split-brain scenarios in high-availability clusters |
JP2015146165A (ja) | 2014-02-04 | 2015-08-13 | 日本電信電話株式会社 | 障害耐性信号処理装置および障害耐性信号処理方法 |
US9251017B2 (en) | 2014-03-25 | 2016-02-02 | International Business Machines Corporation | Handling failed cluster members when replicating a database between clusters |
WO2016024986A1 (en) | 2014-08-15 | 2016-02-18 | Hewlett-Packard Development Company, L.P. | Three phase commit for a distributed file system |
US9720789B2 (en) * | 2014-10-15 | 2017-08-01 | Netapp, Inc. | Multicast transport configuration |
US10304143B2 (en) | 2016-05-05 | 2019-05-28 | Lance Timothy Kasper | Consensus system for manipulation resistant digital record keeping |
JP6636058B2 (ja) | 2015-07-02 | 2020-01-29 | ナスダック, インコーポレイテッドNasdaq, Inc. | 分散トランザクションデータベースにおける出所保証のシステムおよび方法 |
US10812582B2 (en) * | 2016-03-10 | 2020-10-20 | Vmware, Inc. | Management of applications across nodes using exo-clones |
US10198325B2 (en) * | 2016-05-24 | 2019-02-05 | Mastercard International Incorporated | Method and system for desynchronization recovery for permissioned blockchains using bloom filters |
US10204341B2 (en) | 2016-05-24 | 2019-02-12 | Mastercard International Incorporated | Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees |
EP3281115B1 (en) | 2016-10-04 | 2019-06-19 | Nec Corporation | Method and system for byzantine fault-tolerance replicating of data on a plurality of servers |
US10158527B2 (en) | 2016-10-28 | 2018-12-18 | International Business Machines Corporation | Changing an existing blockchain trust configuration |
US10797877B2 (en) | 2016-11-25 | 2020-10-06 | Nec Corporation | Method and system for byzantine fault-tolerance replicating of data |
US11954697B2 (en) | 2017-02-27 | 2024-04-09 | Ncr Corporation | Blockchain consumer ledger |
CN110430064B (zh) | 2017-03-30 | 2020-12-04 | 腾讯科技(深圳)有限公司 | 区块链系统、消息处理方法及存储介质 |
US20180285217A1 (en) | 2017-03-31 | 2018-10-04 | Intel Corporation | Failover response using a known good state from a distributed ledger |
US10749677B2 (en) | 2017-04-18 | 2020-08-18 | Samsung Electronics Co., Ltd. | Method and apparatus for access control in distributed blockchain-based internet of things (IoT) network |
US20180308091A1 (en) | 2017-04-21 | 2018-10-25 | Vmware, Inc. | Fairness preserving byzantine agreements |
WO2018217804A1 (en) | 2017-05-22 | 2018-11-29 | Visa International Service Association | Network for improved verification speed with tamper resistant data |
US10740733B2 (en) | 2017-05-25 | 2020-08-11 | Oracle International Corporaton | Sharded permissioned distributed ledgers |
US11055703B2 (en) | 2017-06-19 | 2021-07-06 | Hitachi, Ltd. | Smart contract lifecycle management |
CN107301600B (zh) | 2017-06-23 | 2021-07-20 | 北京天德科技有限公司 | 一种跨链交易的区块链互联网模型的核心构建方法 |
CN107248076A (zh) | 2017-06-24 | 2017-10-13 | 北京天德科技有限公司 | 一种双链式跨链交易的区块链互联网模型的核心算法 |
EP3649558B8 (en) | 2017-07-06 | 2024-04-17 | Chromaway AB | Method and system for a distributed computing system |
CN112804349B (zh) * | 2017-07-14 | 2023-07-04 | 创新先进技术有限公司 | 区块链共识网络中处理共识请求的方法、装置和电子设备 |
US10984134B2 (en) * | 2017-07-14 | 2021-04-20 | Microsoft Technology Licensing, Llc | Blockchain system for leveraging member nodes to achieve consensus |
US11281644B2 (en) | 2017-07-28 | 2022-03-22 | Hitachi, Ltd. | Blockchain logging of data from multiple systems |
CN107423426B (zh) | 2017-08-02 | 2020-06-02 | 众安信息技术服务有限公司 | 一种区块链块数据的数据归档方法及电子设备 |
US10735203B2 (en) | 2017-10-09 | 2020-08-04 | Cisco Technology, Inc. | Sharing network security threat information using a blockchain network |
US10832241B2 (en) | 2017-10-11 | 2020-11-10 | International Business Machines Corporation | Transaction reservation for block space on a blockchain |
CN107819749A (zh) | 2017-10-26 | 2018-03-20 | 平安科技(深圳)有限公司 | 基于以太坊的区块链系统和交易数据处理方法 |
KR102442431B1 (ko) | 2017-10-31 | 2022-09-08 | 아브 이니티오 테크놀로지 엘엘시 | 상태 업데이트의 일관성에 기초하는 컴퓨팅 클러스터 관리 |
US10572352B2 (en) | 2017-11-01 | 2020-02-25 | Vmware, Inc. | Byzantine fault tolerance with verifiable secret sharing at constant overhead |
US10735450B2 (en) | 2017-11-30 | 2020-08-04 | Intel Corporation | Trust topology selection for distributed transaction processing in computing environments |
US11055419B2 (en) | 2017-12-01 | 2021-07-06 | Alan Health and Science | Decentralized data authentication system for creation of integrated lifetime health records |
US11243945B2 (en) | 2017-12-11 | 2022-02-08 | International Business Machines Corporation | Distributed database having blockchain attributes |
US11139979B2 (en) * | 2017-12-18 | 2021-10-05 | Koninklijke Kpn N.V. | Primary and secondary blockchain device |
CN108108967B (zh) | 2017-12-29 | 2020-10-16 | 山大地纬软件股份有限公司 | 面向复杂数字资产的多阶段pbft共识系统及方法 |
CN108134706B (zh) | 2018-01-02 | 2020-08-18 | 中国工商银行股份有限公司 | 区块链多活高可用系统、计算机设备以及方法 |
CN108108487B (zh) | 2018-01-10 | 2019-11-22 | 杭州复杂美科技有限公司 | 一种区块链的共识方法 |
EP3522064B1 (en) * | 2018-02-02 | 2021-12-22 | Università Degli Studi Di Trento | A method and apparatus for distributed, privacy-preserving and integrity-preserving exchange, inventory and order book |
CN108492103B (zh) * | 2018-02-07 | 2021-04-27 | 北京大学深圳研究生院 | 一种联盟区块链共识方法 |
US20190251573A1 (en) | 2018-02-09 | 2019-08-15 | Airbus (S.A.S.) | Systems and methods of verifying credentials of aircraft personnel using a blockchain computer system |
TWI659373B (zh) | 2018-02-14 | 2019-05-11 | 財團法人工業技術研究院 | 區塊鏈系統及應用其的方法 |
CN108616596B (zh) | 2018-05-09 | 2020-12-25 | 南京邮电大学 | 基于动态授权和网络环境感知的区块链自适应共识方法 |
US10671315B2 (en) * | 2018-08-17 | 2020-06-02 | Bank Of America Corporation | Blockchain architecture for selective data restore and migration |
CN109345386B (zh) * | 2018-08-31 | 2020-04-14 | 阿里巴巴集团控股有限公司 | 基于区块链的交易共识处理方法及装置、电子设备 |
CN109347804B (zh) | 2018-09-19 | 2020-02-07 | 电子科技大学 | 一种用于区块链的拜占庭容错共识优化方法 |
CN109472593A (zh) * | 2018-10-10 | 2019-03-15 | 远光软件股份有限公司 | 一种基于区块链技术的结算方法、装置及区块链网络 |
CN111045855B (zh) * | 2018-10-12 | 2024-01-26 | 伊姆西Ip控股有限责任公司 | 备份数据的方法、装置和计算机程序产品 |
CN109327459B (zh) | 2018-11-12 | 2020-12-01 | 崔晓晖 | 一种联盟区块链网络的共识方法 |
CN109447810B (zh) * | 2018-11-29 | 2021-03-09 | 杭州秘猿科技有限公司 | 并行区块链共识方法、系统、电子设备和计算机可读存储介质 |
KR102134549B1 (ko) * | 2018-12-13 | 2020-07-27 | 알리바바 그룹 홀딩 리미티드 | 분산 시스템에서 프라이머리 노드의 체인지 수행 |
-
2019
- 2019-03-18 KR KR1020197028741A patent/KR102365793B1/ko active IP Right Grant
- 2019-03-18 SG SG11201908387S patent/SG11201908387SA/en unknown
- 2019-03-18 AU AU2019203865A patent/AU2019203865B2/en active Active
- 2019-03-18 WO PCT/CN2019/078552 patent/WO2019101245A2/en unknown
- 2019-03-18 JP JP2019553486A patent/JP6880227B2/ja active Active
- 2019-03-18 US US16/490,871 patent/US11347598B2/en active Active
- 2019-03-18 EP EP19725897.3A patent/EP3607733B1/en active Active
- 2019-03-18 CN CN201980003366.5A patent/CN110870288B/zh active Active
- 2019-12-09 TW TW108144879A patent/TWI724678B/zh active
- 2019-12-22 US US16/724,347 patent/US10922195B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
EP3607733B1 (en) | 2022-02-09 |
EP3607733A4 (en) | 2020-05-27 |
WO2019101245A3 (en) | 2020-01-16 |
US20200125456A1 (en) | 2020-04-23 |
AU2019203865B2 (en) | 2021-01-21 |
EP3607733A2 (en) | 2020-02-12 |
KR20200112633A (ko) | 2020-10-05 |
AU2019203865A1 (en) | 2019-05-31 |
TWI724678B (zh) | 2021-04-11 |
US11347598B2 (en) | 2022-05-31 |
CN110870288B (zh) | 2022-05-27 |
SG11201908387SA (en) | 2019-10-30 |
WO2019101245A2 (en) | 2019-05-31 |
JP2020518887A (ja) | 2020-06-25 |
KR102365793B1 (ko) | 2022-02-21 |
CN110870288A (zh) | 2020-03-06 |
JP6880227B2 (ja) | 2021-06-02 |
US20200004643A1 (en) | 2020-01-02 |
US10922195B2 (en) | 2021-02-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
TWI724678B (zh) | 共識系統停機時間恢復 | |
TWI729609B (zh) | 共識系統停機時間恢復 | |
TWI709063B (zh) | 用於結束視域變換協定的系統和方法 | |
CN111630826B (zh) | 共识系统和方法 | |
TWI717135B (zh) | 用於結束視域變換協定的系統和方法 | |
US10938750B2 (en) | Consensus system downtime recovery | |
AU2019101612A4 (en) | Consensus system downtime recovery | |
AU2019101610A4 (en) | Consensus system downtime recovery |