KR102230829B1 - 합의 시스템 다운타임 복구 - Google Patents

합의 시스템 다운타임 복구 Download PDF

Info

Publication number
KR102230829B1
KR102230829B1 KR1020197028753A KR20197028753A KR102230829B1 KR 102230829 B1 KR102230829 B1 KR 102230829B1 KR 1020197028753 A KR1020197028753 A KR 1020197028753A KR 20197028753 A KR20197028753 A KR 20197028753A KR 102230829 B1 KR102230829 B1 KR 102230829B1
Authority
KR
South Korea
Prior art keywords
node
nodes
messages
message
consensus
Prior art date
Application number
KR1020197028753A
Other languages
English (en)
Other versions
KR20200112634A (ko
Inventor
다이 양
Original Assignee
어드밴스드 뉴 테크놀로지스 씨오., 엘티디.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. filed Critical 어드밴스드 뉴 테크놀로지스 씨오., 엘티디.
Publication of KR20200112634A publication Critical patent/KR20200112634A/ko
Application granted granted Critical
Publication of KR102230829B1 publication Critical patent/KR102230829B1/ko

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/1469—Backup restoration techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • 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/1474—Saving, restoring, recovering or retrying in transactions
    • 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/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/182—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits based on mutual exchange of the output between redundant processing components
    • 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/187—Voting techniques
    • 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80—Database-specific techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/82—Solving problems relating to consistency

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Hardware Redundancy (AREA)
  • Retry When Errors Occur (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

방법, 시스템, 및 장치는, 합의 시스템 다운타임 복구를 위해 컴퓨터 저장 매체에 인코딩된 컴퓨터 프로그램을 포함한다. 방법들 중 하나는, 백업 노드 중 적어도 일부에 사전-준비 메시지를 멀티캐스팅하는 단계; 백업 노드 중 (Q-1)개 이상의 백업 노드로부터 각각 (Q-1)개 이상의 준비 메시지를 취득하는 단계로서, 준비 메시지 각각은 대응하는 백업 노드에 의한 사전-준비 메시지의 수락을 나타내는, 준비 메시지를 취득하는 단계; 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하는 단계; 백업 노드 중 적어도 일부에, 기본 노드가 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는 확정 메시지를 멀티캐스팅하는 단계; 및 기본 노드와 백업 노드 중 Q개 이상의 노드로부터 Q개 이상의 확정 메시지를 각각 취득하는 단계를 포함하되, Q개 이상의 확정 메시지의 각각은, 대응하는 노드가 대응하는 노드에 의해 수신되는 (Q-1)개 이상의 준비 메시지에 동의함을 나타낸다.

Description

합의 시스템 다운타임 복구
본 출원은, 일반적으로 합의(consensus) 시스템 및 방법을 위한 방법 및 장치에 관한 것으로서, 구체적으로는 실용적 비잔틴 장애 허용(Practical Byzantine Fault Tolerance: PBFT) 합의 시스템 및 방법에 관한 것이다.
실용적 비잔틴 장애 허용(PBFT)은 블록체인 시스템과 같은 분산형 시스템에서 구현될 수 있는 일종의 합의 메커니즘이다. PBFT 합의 메커니즘에 의해, 분산형 시스템은, 시스템의 소정의 노드가 (예를 들어, 불량 네트워크 접속 또는 그 외에는 장애로 인해) 장애가 있을 수 있거나 부정확한 정보를 다른 피어(peer)에 전파할 수 있음에도 불구하고, 안전성 및 활성도(liveness)에 대한 충분한 합의에 도달할 수 있다. 이러한 메커니즘의 목적은, 시스템의 올바른 기능 및 시스템에서의 기능 노드(예를 들어, 장애가 없고 정직한 노드)에 의해 도달된 합의에 대한 비기능 노드의 영향을 완화함으로써, 치명적인 시스템 오류에 대하여 방어하는 것이다.
PBFT 합의 메커니즘은, 독립적 노드 오류 및 특정적이면서 독립적인 노드에 의해 전파되는 조작된 메시지가 있다는 가정하에 비잔틴 장애(예를 들어, 비기능 노드)를 허용하는 실용적 비잔틴 상태 기계 복제를 제공하는 데 중점을 둔다. 이러한 PBFT 합의 메커니즘에서, 예를 들어, 블록체인 시스템의 모든 노드는, 하나의 노드가 기본 노드(primary node; 리더(leader) 또는 마스터 노드라고도 함)이고 나머지 노드를 백업 노드(팔로워 노드라고도 함)로 하는 시퀀스로 정렬된다. 시스템 내의 모든 노드는 서로 통신하며, 그 목표는, 모든 정직한 노드가 시스템의 상태에 대한 동의/합의에 도달하는 것이다.
예를 들어, PBFT 합의 메커니즘이 기능하기 위해서는, 블록체인 시스템에서의 비기능 노드의 양이 주어진 취약성 윈도우에서 시스템의 전체 노드의 1/3과 동시에 같을 수 없거나 초과할 수 없다고 가정한다. 이 방법은, 최대 F개의 노드가 동시에 비기능 노드인 한 활성도와 안전성 모두를 효과적으로 제공한다. 다시 말하면, 일부 구현예에서, PBFT 합의 메커니즘에 의해 허용될 수 있는 비기능 노드의 수 F는 가장 가까운 정수로 내림된 (N-1)/3과 같고, 여기서, N은 시스템의 노드의 총수를 나타낸다. 일부 구현예에서, PBFT 합의 메커니즘을 구현하는 블록체인 시스템은, 전체로서 적어도 3F+1개의 노드가 있는 경우 최대 F개의 비잔틴 장애를 다룰 수 있다.
PBFT 합의 메커니즘은, 일반적으로 정상 동작 프로토콜(3단 프로토콜이라고도 함) 및 뷰 변경 프로토콜을 포함하며, 여기서 정상 동작 프로토콜은 메커니즘의 안전성을 보장하기 위해 제공되는 것인 한편, 뷰 변경 프로토콜은 메커니즘의 활성도를 보장하기 위해 제공되는 것이다. 정상 단계 프로토콜은, 주로 3개의 단계를 포함하는데, 즉, 순서대로 사전-준비(pre-prepare) 단계, 준비 단계, 및 확정(commit) 단계를 포함한다. 모든 단계는 메시지 주도형인데, 즉, 현재 단계에서 충분한 수의 메시지를 취득함으로써 프로토콜의 다음 단계를 트리거하게 된다. 정상적인 작동 프로토콜 하의 전체 프로세스는, 각 단계에서 연속적으로 수신되는 충분한 수의 메시지에 크게 의존하여 진행된다. 뷰 변경 프로토콜에서도, 프로세스는 정상 작동 프로토콜의 준비 메시지에 기초하여 진행된다. 따라서, PBFT 합의 메커니즘은 합의 메시지가 기능하는 데 크게 의존한다는 것을 알 수 있다. 하나 이상의 노드가 비기능으로 되면(예를 들어, 다운타임을 경험한 후 재시작하는 경우)，메모리에 저장된 메시지가 손실되어, 전체 합의 프로세스에 영향을 주어, 심지어 비일관성이 발생한다.
본 명세서의 다양한 실시형태는, 합의 시스템 다운타임 복구를 위한 시스템, 방법, 및 비일시적 컴퓨터 판독가능 매체를 포함하지만, 이에 한정되지는 않는다.
일 실시형태에 따르면, 컴퓨터 구현 합의 방법(computer-implemented consensus method)은 다수(N)의 노드에 의해 유지되는 블록체인 상에 구현되고 노드들 중 하나의 노드는 기본 노드로서 기능하고, 나머지 (N-1)개의 노드는 백업 노드로서 기능하며, 방법은 기본 노드에 의해 수행된다. 방법은, 백업 노드 중 적어도 일부에 사전-준비 메시지를 멀티캐스팅하는 단계; 백업 노드 중 (Q-1)개 이상의 백업 노드로부터 각각 (Q-1)개 이상의 준비 메시지를 취득하는 단계로서, 준비 메시지 각각은 대응하는 백업 노드에 의한 사전-준비 메시지의 수락을 나타내고, Q(정족수)는 가장 가까운 정수로 올림된 (N+F+1)/2이고, F는 가장 가까운 정수로 내림된 (N-1)/3인, 준비 메시지를 취득하는 단계; 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하는 단계; 백업 노드 중 적어도 일부에, 기본 노드가 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는 확정 메시지를 멀티캐스팅하는 단계; 및 기본 노드와 백업 노드 중 Q개 이상의 노드로부터 Q개 이상의 확정 메시지를 각각 취득하는 단계를 포함하되, Q개 이상의 확정 메시지의 각각은, 대응하는 노드가 대응하는 노드에 의해 수신되는 (Q-1)개 이상의 준비 메시지에 동의함을 나타낸다. 일 실시형태에서, Q개 이상의 확정 메시지는 멀티캐스트 확정 메시지를 포함한다.
일부 실시형태에서, 백업 노드 중 적어도 일부에 사전-준비 메시지를 멀티캐스팅하는 단계 전에, 방법은, 하나 이상의 클라이언트 또는 하나 이상의 백업 노드 중 적어도 하나로부터 하나 이상의 트랜잭션 요청을 취득하는 단계를 더 포함한다.
다른 실시형태에서, 사전-준비 메시지는 하나 이상의 트랜잭션 요청에 대응하는 하나 이상의 트랜잭션의 순서를 포함하고; 확정 메시지는, 확정 메시지를 전송하는 대응하는 노드가 순서에 동의함을 나타낸다.
또 다른 실시형태에서, 방법은 순서에 따라 하나 이상의 트랜잭션을 기본 노드에 의해 유지되는 블록체인의 로컬 카피 내에 패킹하는 단계를 더 포함한다.
또 다른 실시형태에서, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하는 단계는, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지만을 저장하는 단계를 포함한다.
일부 실시형태에서, 확정 메시지를 멀티 캐스팅하는 단계 후에, 방법은, 시스템 재시작을 수행하는 단계; 및 저장된 사전-준비 메시지 및 저장된 (Q-1)개 이상의 준비 메시지를 로딩하는 단계를 더 포함한다.
다른 실시형태에서, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하는 단계 후에 그리고 확정 메시지를 멀티캐스팅하는 단계 전에, 방법은, 시스템 재시작을 수행하는 단계; 및 저장된 사전-준비 메시지 및 저장된 (Q-1)개 이상의 준비 메시지를 로딩하는 단계를 더 포함한다.
또 다른 실시형태에서, 백업 노드 중 (Q-1)개 이상의 백업 노드 중 최대 F개는, 확정 메시지를 각각 멀티캐스팅한 후에 기능하지 않고 그리고 시스템 재시작을 수행하지 않는다.
또 다른 실시형태에서, 최대 N개의 모든 노드에서 충돌이 발생하고; 그리고 N개 노드 중 적어도 Q개의 노드는가 시스템 재시작을 수행하고 그리고 대응하는 저장된 사전-준비 메시지 및 저장된 (Q-1)개 이상의 준비 메시지를 각각 로딩한다.
일부 실시형태에서, 시스템 재시작을 수행하는 단계는, 뷰 변경을 트리거하지 않고 시스템 재시작을 수행하는 단계를 포함한다.
다른 실시형태에서, 블록체인을 유지하기 위한 기본 노드로서 기능하는 합의 시스템은, 하나 이상의 프로세서, 및 하나 이상의 프로세서에 결합되고 그리고 선행 실시형태들 중 임의의 실시형태의 방법을 수행하도록 하나 이상의 프로세서에 의해 실행 가능한 명령어가 저장된 하나 이상의 컴퓨터-판독가능 메모리를 포함한다.
또 다른 실시형태에서, 블록체인을 유지하기 위한 기본 노드로서 기능하는 합의 장치는, 선행 실시형태들 중 임의의 실시형태의 방법을 수행하기 위한 복수의 모듈을 포함한다.
또 다른 실시형태에 따르면, 합의 시스템은 블록체인을 유지하기 위한 것이다. 다수(N개)의 노드가 블록체인을 유지하고, N개의 노드 중 하나가 기본 노드로서 기능하고 그리고 나머지 (N-1)개의 노드가 백업 노드로서 기능하고, 합의 시스템은, 기본 노드로서 기능하고 그리고 하나 이상의 프로세서, 및 하나 이상의 프로세서에 결합되고 그리고 시스템이 동작을 수행하게 하도록 하나 이상의 프로세서에 의해 실행될 수 있는 명령어로 구성되는 하나 이상의 비일시적 컴퓨터-판독가능 메모리를 포함하되, 동작은, 백업 노드 중 적어도 일부에 사전-준비 메시지를 멀티캐스팅하는 동작; 백업 노드 중 (Q-1)개 이상의 백업 노드로부터 각각 (Q-1)개 이상의 준비 메시지를 취득하는 동작으로서, 준비 메시지 각각은 대응하는 백업 노드에 의한 사전-준비 메시지의 수락을 나타내고, Q(정족수)는 가장 가까운 정수로 올림된 (N+F+1)/2이고, F는 가장 가까운 정수로 내림된 (N-1)/3인, 준비 메시지를 취득하는 동작; 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하는 동작; 백업 노드 중 적어도 일부에, 기본 노드가 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는 확정 메시지를 멀티캐스팅하는 동작; 및 기본 노드와 백업 노드 중 Q개 이상의 노드로부터 Q개 이상의 확정 메시지를 각각 취득하는 동작을 포함하되, Q개 이상의 확정 메시지의 각각은, 대응하는 노드가 대응하는 노드에 의해 수신되는 (Q-1)개 이상의 준비 메시지에 동의함을 나타낸다.
또 다른 실시형태에 따르면, 비일시적 컴퓨터-판독가능 저장 매체는 블록체인을 유지하기 위한 것이다. 다수(N개)의 노드가 블록체인을 유지하고, N개의 노드 중 하나가 기본 노드로서 기능하고 그리고 나머지 (N-1)개의 노드가 백업 노드로서 기능하고, 저장 매체는, 기본 노드와 연관되고 그리고 하나 이상의 프로세서가 동작을 수행하게 하도록 하나 이상의 프로세서에 의해 실행될 수 있는 명령어로 구성되되, 동작은, 백업 노드 중 적어도 일부에 사전-준비 메시지를 멀티캐스팅하는 동작; 백업 노드 중 (Q-1)개 이상의 백업 노드로부터 각각 (Q-1)개 이상의 준비 메시지를 취득하는 동작으로서, 준비 메시지 각각은 대응하는 백업 노드에 의한 사전-준비 메시지의 수락을 나타내고, Q(정족수)는 가장 가까운 정수로 올림된 (N+F+1)/2이고, F는 가장 가까운 정수로 내림된 (N-1)/3인, 준비 메시지를 취득하는 동작; 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하는 동작; 백업 노드 중 적어도 일부에, 기본 노드가 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는 확정 메시지를 멀티캐스팅하는 동작; 및 기본 노드와 백업 노드 중 Q개 이상의 노드로부터 Q개 이상의 확정 메시지를 각각 취득하는 동작을 포함하되, Q개 이상의 확정 메시지의 각각은, 대응하는 노드가 대응하는 노드에 의해 수신되는 (Q-1)개 이상의 준비 메시지에 동의함을 나타낸다.
또 다른 실시형태에 따르면, 합의 장치는 블록체인을 유지하기 위한 것이다. 다수(N개)의 노드가 블록체인을 유지하고, N개의 노드 중 하나가 기본 노드로서 기능하고 그리고 나머지 (N-1)개의 노드가 백업 노드로서 기능하고, 합의 장치는 기본 노드로서 기능하고 그리고 백업 노드 중 적어도 일부에 사전-준비 메시지를 멀티캐스팅하기 위한 제1 멀티캐스팅 모듈; 백업 노드 중 (Q-1)개 이상의 백업 노드로부터 각각 (Q-1)개 이상의 준비 메시지를 취득하기 위한 제1 취득 모듈로서, 준비 메시지 각각은 대응하는 백업 노드에 의한 사전-준비 메시지의 수락을 나타내고, Q(정족수)는 가장 가까운 정수로 올림된 (N+F+1)/2이고, F는 가장 가까운 정수로 내림된 (N-1)/3인, 제1 취득 모듈; 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하기 위한 저장 모듈; 백업 노드 중 적어도 일부에, 기본 노드가 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는 확정 메시지를 멀티캐스팅하기 위한 제2 멀티캐스팅 모듈; 및 기본 노드와 백업 노드 중 Q개 이상의 노드로부터 Q개 이상의 확정 메시지를 각각 취득하기 위한 제2 취득 모듈을 포함하되, Q개 이상의 확정 메시지의 각각은, 대응하는 노드가 대응하는 노드에 의해 수신되는 (Q-1)개 이상의 준비 메시지에 동의함을 나타낸다.
본 명세서에 개시된 실시형태들은 하나 이상의 기술적 효과를 갖는다. 일부 실시형태에서, 방법 및 시스템은, PBFT 합의 시스템의 다양한 노드가 하나 이상의 노드가 시스템 충돌을 경험한 후에 정상 동작을 재개할 수 있음을 보장할 수 있다. 다른 실시형태에서, 각각의 합의 검증 라운드에서, 합의 시스템의 노드(기본 노드 또는 백업 노드)는 사전-준비 메시지 및 충분한 수의 준비 메시지를 저장할 수 있어서, 중단(예를 들어, 시스템 전체 충돌)이 발생할 때, 노드들은, 일관성 없는 합의 결과를 초래하여 블록체인으로 분기하지 않고서, 합의 검증을 재개할 수 있다. 또 다른 실시형태에서, 충돌 후, 노드는, 시스템 재시작을 수행할 수 있고 저장된 메시지를 로딩하여 정상 기능을 복구할 수 있다. 저장된 메시지를 로딩함으로써 시스템 다운타임 복구를 신속하게 수행할 수 있다. 또 다른 실시형태에서, 사전-준비 메시지 및 적어도 (Q-1)개의 준비 메시지는, (정상 동작 프로토콜의 준비 단계에서) 준비 메시지들을 취득한 후에 그리고 (정상 동작 프로토콜의 확정 단계에서) 확정 메시지를 멀티캐스팅하기 전에 저장될 수 있다. 따라서, 다운타임 복구를 달성하기 위해서는 사전-준비 메시지와 (Q-1)개의 준비 메시지만 저장하면 되므로, 확정을 위해 저장될 시스템 자원이 덜 필요하다. 일부 실시형태에서는, 일관성 없는 합의 결과 및 블록체인 분기 없이 최대 F개의 악의적인 또는 장애가 있는 노드를 허용할 수 있다. 즉, PBFT 합의 시스템의 정족수에 의해 결정된 합의 검증은, 최대 F개의 노드를 신뢰할 수 없는 경우에도, 신뢰될 수 있다.
본 명세서에 개시된 시스템, 방법, 및 비일시적 컴퓨터 판독가능 매체의 이러한 특징부 및 다른 특징부, 및 부품들과 제조 경제의 조합 및 구조의 관련 요소들의 동작과 기능의 방법은, 본 명세서의 일부를 형성하는 첨부 도면을 참조하여 다음에 따르는 상세한 설명과 첨부된 청구범위를 고려할 때 더욱 명백해질 것이며, 도면에서의 유사한 참조 번호는 다양한 도면에서의 대응 부분을 나타낸다. 그러나, 도면은 단지 예시 및 설명을 위한 것이며 한정적인 것을 의도한 것이 아님을 명백히 이해해야 한다.
도 1은 다양한 실시형태에 따른 네트워크를 도시하는 도면.
도 2a는 PBFT의 정상 동작 프로토콜을 도시하는 도면.
도 2b는 하나의 장애 레플리카(faulty replica)를 갖는 PBFT의 정상 동작 프로토콜을 도시하는 도면.
도 2c는 PBFT의 정상 동작 프로토콜 및 뷰 변경 프로토콜을 도시하는 도면.
도 3a는 PBFT의 정상 동작 프로토콜의 단계들의 흐름도.
도 3b는 PBFT의 뷰 변경 프로토콜의 단계들의 흐름도.
도 3c는 다양한 실시형태에 따른 합의 시스템의 정상 동작 프로토콜의 단계들의 흐름도.
도 4a 내지 도 4d는 다양한 실시형태에 따른 합의 단계들의 흐름도.
도 5a는 다양한 실시형태에 따른 합의 방법의 흐름도.
도 5b는 다양한 실시형태에 따른 합의 방법의 흐름도.
도 6a는 다양한 실시형태에 따른 합의 시스템의 블록도.
도 6b는 다양한 실시형태에 따른 합의 시스템의 블록도.
도 7은 본 명세서에 기재된 실시형태들 중 임의의 실시형태가 구현될 수 컴퓨터 시스템의 블록도.
본 명세서에 개시된 실시형태들은, 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 등)를 포함한다. 노드들은, 하나의 블록체인 노드가 다른 블록체인 노드와 통신하는 네트워크(예를 들어, 피어투피어 네트워크)를 형성할 수 있다. 도시된 바와 같은 블록체인 노드들의 순서와 수는 단지 예시일 뿐이고 간략화하기 위한 것이다. 블록체인 노드는 서버, 컴퓨터 등에서 구현될 수 있다. 각 블록체인 노드는, TCP/IP와 같은 다양한 유형의 통신 방법을 통해 함께 결합된 하나 이상의 물리적 하드웨어 장치 또는 가상 장치에 해당할 수 있다. 분류에 따라, 블록체인 노드는 전체 노드, 고이더리움(Geth) 노드, 합의 노드 등을 포함할 수 있다.
다양한 실시형태에서, 블록체인 시스템은, 노드 A 및 노드 B 등의 다른 시스템 및 장치(예를 들어, 경량 노드)와 상호작용할 수 있다. 상호작용은, 예를 들어, 요청을 수신하고 요청의 실행 결과를 리턴하도록 데이터의 송신과 수신을 포함할 수 있다. 일례로, 사용자 A는 블록체인을 통해 사용자 B와 트랜잭션을 행하고 싶을 수 있다. 트랜잭션은, 사용자 A의 계정에 있는 일부 자산을 사용자 B의 계정으로 이체하는 것을 포함할 수 있다. 사용자 A 및 사용자 B는, 트랜잭션을 위한 적절한 블록체인 소프트웨어(예를 들어, 암호화폐 지갑)가 설치된 장치 노드 A 및 장치 노드 B를 각각 사용할 수 있다. 노드 A는 노드 0과의 통신을 통해 블록체인에 액세스할 수 있고, 노드 B는 노드 1과의 통신을 통해 블록체인에 액세스할 수 있다. 예를 들어, 노드 A는 노드 0을 통해 블록체인에 트랜잭션 요청을 제출할 수 있고, 노드 B는 노드 1을 통해 스마트 계약 실행 요청을 블록체인에 제출할 수 있다. 블록체인 외부에서, 노드 A 노드 B는 다른 통신 채널(예를 들어, 노드 0 및 노드 1을 거치지 않는 정기적 인터넷 통신)을 가질 수 있다.
블록체인 노드들의 각각은 메모리를 포함하거나 메모리에 결합될 수 있다. 일부 실시형태에서, 메모리는 풀 데이터베이스를 저장할 수 있다. 풀 데이터베이스는 분산 방식으로 복수의 블록체인 노드에 액세스할 수 있다. 예를 들어, 풀 데이터베이스는 블록체인 노드들의 메모리들에 각각 저장될 수 있다. 풀 데이터베이스는, 사용자에 의해 운영되는 노드 A 및 노드 B와 같은 하나 이상의 사용자 장치에 의해 제출된 복수의 트랜잭션을 저장할 수 있다.
블록체인 노드들은, 합의를 통해 블록체인으로서 알려진 분산 원장에 트랜잭션을 기록하는 네트워크(예를 들어, P2P 네트워크)를 형성한다. P2P 네트워크의 참가자는 블록체인을 유지하는 노드라고 칭할 수 있다. 블록체인 P2P 네트워크에서, 각 노드는, 합의 검증에 참여하고 블록체인의 전체 원장 카피를 저장한다. 모든 노드는, 모든 노드가 일관된 확인 결과를 갖고 이에 따라 블록체인의 일관된 카피를 갖는 것을 보장하도록 블록체인 합의 알고리즘에 의해 일괄 트랜잭션을 확인한다.
블록체인 합의 알고리즘들 중 하나는 실용적 비잔틴 장애 허용(PBFT)이다. 비잔틴 장애 허용은 비잔틴 일반 문제에서 비롯된 것이다. P2P 네트워크 시스템의 경우, 비기능 노드의 수가 소정의 한계값 내에 있는 한, 시스템이 계속 올바르게 동작할 수 있다. 이러한 시스템을 비잔틴 장애 허용 시스템이라고 한다. PBFT는 비잔틴 장애 허용 네트워크 기능을 최적화하는 일례이다. PBFT는, 서버를 카피하고 서버 카피와의 클라이언트 상호작용을 동기화함으로써 네트워크에 비잔틴 상태 기계를 제공한다.
PBF 동작의 중심에는 블록체인에 기록된 정보에 대한 일관된 글로벌 뷰의 유지관리가 있으며, 이는 사용자들이 분산 방식으로 서로 상호작용할 수 있게 하는 백본을 형성한다. PBFT 합의 메커니즘의 안전성은 블록체인 시스템에 있어서 중요하다. 합의 모델의 두 가지 주요 특성은 다음과 같은데, 즉, 1) 안전 또는 일관성으로서, 모든 정직한 노드가 동일한 유효 출력을 생성하고, 2) 활성도로서, 합의된 모든 정직한 노드가 결국 중간 단계에서 멈추지 않고 가치를 생성하는 것이다. 안전하고 강력한 PBFT 합의 메커니즘은, 노드 장애, 네트워크 분할, 메시지 지연, 장애 있는 메시지 전달, 메시지 손상 등을 포함한 다양한 비잔틴 거동을 허용할 필요가 있고, 시스템 내의 비기능 노드의 수가 한정되어 있는 한 노드의 합에 도달할 필요가 있다. 이를 위해, PBFT 모델은, 상호 배타적인 두 개의 프로토콜인 정상 동작/일관성 프로토콜과 아래에서 자세하게 더 설명하는 뷰 변경 프로토콜 중 하나에서 동작한다. 본 명세서에서, 비기능은 장애 및/또는 악의를 의미하고, 기능은 장애가 없고 정직함을 의미한다. 가능한 장애 및/또는 악의적 행위는, 메시지 전달 실패지, 메시지 전달 지연, 순서가 잘못된 메시지 전달, 비잔틴 장애(임의의 메시지를 다른 노드로 전달, 프로토콜 위반) 등을 포함할 수 있다.
일부 실시형태에서, PBFT 메커니즘을 구현하는 블록체인 시스템은 총 N개의 노드를 포함할 수 있으며, N개의 노드 중 하나는 기본 노드로서 기능하고 N개의 노드 중 나머지 도는 백업 노드로서 기능한다. 다른 노드가 뷰 변경 프로토콜을 통해 새로운 기본 노드로 되도록 선택될 수 있으므로, 기본 노드 지정은 특정 노드로 고정되지 않을 수 있다. 예를 들어, 기본 노드는, 최저 일련번호(모듈로 뷰 번호)를 갖는 기능 노드가 새로운 기본 노드로 되는 모듈로 연산을 통해 선택될 수 있다. 현재 뷰 및 총 노드 수 N은 기본 노드 id = (view + 1) mod N을 결정할 수 있다. PBFT에서, 새로운 기본 노드가 선택될 때마다 뷰가 변경된다. 예를 들어, 각 뷰가 변경될 때마다, 뷰가 0에서 단조 증가한다. 즉, 기본 노드의 변경에 따라 뷰가 변경될 수 있다.
일부 실시형태에서, 기본 노드는 뷰 v에서 기능하고, 정상 동작 프로토콜이 실행된다. 정상 동작을 위해, 기본 노드 및/또는 백업 노드는 하나 이상의 클라이언트로부터 검증되지 않은 트랜잭션에 연관된 요청을 수신할 수 있다. 예를 들어, 클라이언트인 노드 A는 기본 노드 및/또는 백업 노드에 요청을 제출할 수 있다. 요청은, 검증되지 않은 트랜잭션(예를 들어, 합의 검증에 의해 블록체인의 새로운 블록에 추가될 트랜잭션)을 포함할 수 있다. 검증되지 않은 트랜잭션은, 예를 들어, 블록체인 기반 금융 트랜잭션, 스마트 계약 배치, 또는 실행 트랜잭션 등을 포함할 수 있다. 기본 노드와 백업 노드는 트랜잭션의 일부 예비 검증을 수행하거나 수행하지 않을 수 있다. 요청을 수신한 백업 노드는 수신된 요청을 기본 노드로 전달할 수 있다. 일단 기본 노드에서 검증되지 않은 트랜잭션이 있는 요청이 소정의 수준에 도달하거나 트리거링 조건을 충족하면, 기본 노드는 합의 검증 라운드를 개시할 수 있고 검증되지 않은 트랜잭션에 대한 검증 결과를 제안할 수 있다. 백업 노드는 합의에 응답하고 합의에 도달하기 위한 제안을 확인할 수 있다. 노드에 대한 요구 사항은, 결정적이며 동일한 상태에서 시작해야 한다는 것이다. 최종 결과는, 모든 정직한 노드가 레코드 순서에 따라 합의에 도달하고 합의를 수락하거나 거부하는 것이다. 일단 합의가 검증되면, 트랜잭션은, 새로운 블록체인 블록으로 패킹되어 노드에 의해 유지되는 로컬 블록체인 카피에 추가될 수 있다. 또한, 원래 요청을 전송한 클라이언트(예를 들어, 노드 A)는 통지받는다.
전술한 바와 같이, 안전성을 유지하기 위해, PBFT 합의 메커니즘은, 정상 동작 프로토콜에 대한 세 가지 단계, 즉, 사전-준비 단계, 준비 단계, 및 확정 단계를 주로 포함한다. 도 2a 내지 도 2c를 참조해 볼 때, PBFT 합의 메커니즘을 구현하는 블록체인 시스템의 일례는, 레플리카 0, 레플리카 1, 레플리카 2, 및 레플리카 3인 네 개의 레플리카(레플리카는 노드의 다른 용어임)를 포함한다. 숫자 0 내지 3은 새로운 기본 노드를 결정하는 데 사용될 수 있는 레플리카 일련번호이다. 레플리카 0은 기본 노드 0에 해당할 수 있고, 레플리카 1, 2, 및 3은 백업 노드 1, 2, 및 3에 해당할 수 있다. 레플리카는, 예를 들어, 전술한 네트워크 시스템(112)의 대응하는 노드에서 구현될 수 있다. 정상 동작 프로토콜은 비기능 노드가 없는 도 2a에 도시되어 있고, 다른 정상 동작 프로토콜은, 레플리카 3이 비기능 노드인 도 2b에 도시되어 있다. 양측 상황 모두에서, 정상 동작 프로토콜은, 사전-준비 단계, 준비 단계, 및 확정 단계에 더하여 요청 단계와 응답 단계인 두 단계를 더 포함할 수 있다. 도 2a에 대응하는 단계들의 흐름도는 도 3a에 도시되어 있다.
도 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개의 준비 메시지 대신 Q-1개(이 경우 2F개)의 준비 메시지가 필요하다. 사전-준비 메시지를 하나 이상의 준비 메시지로서 카운팅한다면, 최대 F개의 비기능 노드가 허용될 수 있는, 사전-준비 메시지를 수락한 모든 노드 중 적어도 Q개(예를 들어, 2F+1개)의 노드를 나타내는 적어도 Q개(예를 들어, 2F+1개)의 별개이면서 유효한 준비 메시지가 존재할 것이다. 따라서, 사전-준비 내지 준비 단계는, 적어도 F+1개(최대 F개의 비기능 노드를 고려한 2F+1개의 준비된 노드임)의 기능 노드가, 요청이 뷰 v에서 실행되는 경우 요청이 시퀀스 번호로 실행되는 것에 동의함을 보장한다. 준비 단계는 뷰 내에서 각 요청의 장애가 허용되는 일관성 있는 순서화를 보장한다.
일부 실시형태에서, 백업 노드는, 사전-준비 메시지와 (Q-1)개의 준비 메시지를 수신한 후, 순서를 검증할 수 있고, 검증 결과를 사전-준비 메시지에서 기본 노드에 의해 작성된 제안된 검증 결과와 비교할 수 있다. 순서를 검증하는 방법에는 여러 가지가 있을 수 있다. 예를 들어, 제안된 검증 결과는, 다이제스트 (d)에 기입되어 제안된 메클 패트리샤 트리(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)개(최대 F개의 비기능 노드를 고려한 Q개의 확정 메시지임)의 기능 노드가, 요청이 해당 시퀀스 번호를 갖는 뷰 v에서 최종적으로 실행됨에 동의하는 것을 보장한다. 노드는 (예를 들어, 일부 노드가 미리 새로운 뷰에 진입하였고 다른 일부 노드가 이전 뷰에 남아 있는 경우) 서로 다른 뷰에서 확정할 수 있으므로, 수신된 확정 메시지는 다른 뷰에서 수행된 확정에 해당할 수 있다. 확정 단계는, 기능 노드가 각 요청의 시퀀스 번호에 동의할 때 뷰마다 각 요청의 장애가 허용되는 일관성 있는 순서화를 보장한다.
일부 실시형태에서, 노드가 적어도 Q개의 별개이면서 유효하며 일관된 확정 메시지를 취득하였다면, 그 노드는 대응하는 요청(들)을 실행할 수 있다. 예를 들어, 일단 Q개의 확정 메시지가 취득되었다면, 이는 새로운 블록이 합의 검증되었음을 의미한다. 따라서, 노드는 새로운 블록을 국부적으로 유지되는 블록체인의 카피에 패킹할 수 있다. 그렇지 않으면, 백업 노드가 뷰 변경 프로토콜을 직접 트리거할 수 있다.
응답 단계에서, 요청(들)의 실행 후, 노드는 클라이언트에 직접 응답 메시지를 전송한다. 블록체인에 패킹된 트랜잭션에 대해, 응답 메시지는 블록체인에 있는 트랜잭션의 어드레스를 포함할 수 있다. 최대 F개의 장애가 허용되기 때문에, 클라이언트는, 결과를 수락하기 전에 다른 노드로부터의 유효한 서명 및 동일한 요청 타임스탬프 및 동일한 실행 결과를 갖는 (Q-F)개의 응답을 기다린다. 도 2a 및 도 2b에 도시된 PBFT 네트워크 시스템의 경우, 총 4개의 노드가 존재하므로, 최대 하나(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와 유사하다. 즉, 단계(331 내지 단계 337)는, 단계(399)가 단계(335)와 단계(336) 사이에 추가로 수행된다는 점을 제외하고는 단계(311 내지 317)와 각각 유사하다. 일부 실시형태에서, 도 3c에 도시된 바와 같이, 준비 단계(백업 노드 또는 기본 노드가 (Q-1)개의 준비 메시지를 취득함)와 확정 단계(백업 노드 또는 기본 노드가 확정 메시지를 멀티캐스팅함) 사이에, 사전-준비 메시지 및 적어도 (Q-1)개의 준비 메시지가 저장 단계에서 저장될 수 있다. 추가 세부 사항은 도 4a 내지 도 6b를 참조하여 이하에서 설명한다.
도 4a는 본 명세서의 다양한 실시형태에 따라 기본 노드에 의해 수행되는 합의 단계(410a)의 흐름도를 도시한다. 도 4b는 본 명세서의 다양한 실시형태에 따라 백업 노드에 의해 수행되는 합의 단계(410b)의 흐름도를 도시한다. 이들 두 도면은, 적어도 3F+1개의 노드가 포함된 PBFT 합의 메커니즘을 구현하는 블록체인 시스템을 도시한다. 그러나, 본 명세서는 이에 한정되지 않는다. 블록체인 시스템은, 유효한 합의 프로세스를 유지하고 안전성과 활성도 요건들을 충족시키도록 노드들의 정족수가 시스템에 있는 한 "적어도 3F+1개"와는 다른 노드 수를 가질 수 있다. 일부 실시형태에서, 뷰 변경을 트리거하지 않고, 합의 단계(410a)는 도 4a에 도시된 바와 같이 뷰 v에서 기본 노드에 의해 수행되며, 합의 단계(410b)는 도 4b에 도시된 바와 같이 뷰 v에서 백업 노드에 의해 수행된다. 뷰는 N개의 노드 중 어느 노드가 기본 노드로서 간주되는지를 나타내며, 여기서 N은 네트워크 시스템의 노드 수를 나타낸다. 단계들(410a 및 410b)은 각각 도 1의 시스템(100)의 하나 이상의 구성요소(예를 들어, 전술한 노드 0, 노드 1, 노드 2,..., 또는 노드 i, 또는 유사한 장치, 또는 임의의 노드와 추가 장치(예를 들어, 노드 A)의 조합)에 의해 구현될 수 있다. 이 도면에서, 노드 A(예를 들어, 전술한 경량 노드)는 클라이언트이고, 노드 0 내지 노드 3은 네트워크 시스템(112)의 노드들이다. 현재 뷰 v에서, 노드 0은 기본 노드로서 기능하고, 노드 1 내지 노드 3은 백업 노드로서 기능한다. 단계들(410a 및 410b)은 각각 다양한 하드웨어 기계 및/또는 소프트웨어를 포함하는 합의 시스템 또는 장치(예를 들어, 컴퓨터, 서버)에 의해 구현될 수 있다. 예를 들어, 합의 시스템 또는 장치는, 하나 이상의 프로세서, 및 하나 이상의 프로세서에 결합되고, 시스템 또는 장치(예를 들어, 프로세서)가 단계(410a 또는 410b)를 수행하게 하도록 하나 이상의 프로세서에 의해 실행 가능한 명령어로 구성된 하나 이상의 비일시적 컴퓨터-판독가능 저장 매체(예를 들어, 하나 이상의 메모리)를 포함할 수 있다. 아래 제시된 동작들은 예시를 위한 것이다. 구현예에 따라, 동작들은, 다양한 순서로 또는 병렬로 수행되는 추가 단계, 더 적은 단계, 또는 대체 단계를 포함할 수 있다.
도 4a 및 도 4b의 수직 방향으로, 다양한 단계는 "요청", "사전-준비", "준비", "저장", "확정", 및 "응답" 단계에 대응하며, 이는 도 1 내지 도 3c를 참조하여 전술한 설명을 참조할 수 있다. 다양한 단계의 배열은, 명확성을 위해 도시된 것이며, 엄격한 시퀀스 요건을 갖지 않아도 된다. 예를 들어, 저장 단계는 준비 단계가 끝나기 전에 시작할 수 있고 및/또는 확정 단계가 시작된 후에 종료될 수 있다. 도 4a에 도시된 바와 같이, 예를 들어, 선택적 단계(498)는, 후술하는 바와 같이 중단(예를 들어, 다운타임 상황)이 발생할 때 단계(415)와 단계(417) 사이에서 추가로 수행될 수 있다. 기본 노드와 백업 노드는 PBFT 합의 메커니즘에서 정의된 노드들일 수 있다.
도 4a의 단계(410a) 및 도 4b의 단계(410b)는, 하나 이상의 요청의 한 라운드의 합의 검증에 적용될 수 있다. 예를 들어, 한 라운드의 합의 검증은 하나 이상의 트랜잭션 요청을 처리할 수 있다. 성공하면, 해당 트랜잭션은 블록체인의 새로운 블록으로 패킹된다. 이하의 설명은, 특정하게 달리 언급하지 않는 한, 소정의 단계들이 서로 얽혀 있으므로 도 4a 또는 도 4b를 참조한 것이다. 단계(411a)와 단계(412a)는 도 4a에서만 찾을 수 있는 한편, 단계(411b)와 단계(412b)는 도 4b에서만 찾을 수 있다. 단계(413, 414, 415, 416 및 417)는 도 4a 및 도 4b 모두에 도시되어 있다.
단계(411a)에서, 도 4a에 도시된 바와 같이. 요청 단계에서, 기본 노드는 클라이언트로부터 요청을 취득할 수 있다. 예를 들어, 요청은, 클라이언트(노드 A)로부터 기본 노드(노드 0)에 의해 직접 취득될 수 있고 또는 점선으로 도시한 바와 같이 요청을 기본 노드로 포워딩한 백업 노드(예를 들어, 노드 1, 2, 또는 3)로부터 취득될 수 있다. 일부 실시형태에서, 요청은, 합의 검증을 위한 (스마트 계약의 유무에 관계없이) 트랜잭션/트랜잭션들을 포함할 수 있다. 합의 검증은 정상 동작 프로토콜의 실행 동안 수행될 수 있다. 대안으로, 요청은 다른 동작에 대응할 수 있다.
단계(412a)에서, 사전-준비 단계에서, 기본 노드(노드 0)는, 사전-준비 메세지를 요청과 함께 백업 노드(노드 1, 2, 및 3)로 멀티캐스팅한다. 일부 실시형태에서, 기본 노드는, 다수의 요청을 취득한 후, 사전-준비 메시지 및 다수의 요청을 각각의 백업 노드에 멀티캐스팅할 수 있다. 사전-준비 메시지는 요청들에 대한 순서(예를 들어, 요청들에 연관된 트랜잭션에 대한 순서)를 포함할 수 있다.
정상 동작 프로토콜 하에서 백업 노드(예를 들어, 노드 1, 2, 또는 3)에 의해 수행되는 단계들을 도시하는 도 4b에 도시된 바와 같이, 백업 노드는 단계(411b)에서 사전-준비 단계의 요청과 함께 사전-준비 메시지를 취득한다. 요청은 합의 검증을 위한 연관된 트랜잭션을 포함할 수 있다. 일부 실시형태에서, 사전-준비 메시지 및 요청은 기본 노드로부터 취득될 수 있다. 일부 실시형태에서, 사전-준비 메시지는 기본 노드로부터 취득될 수 있고, 요청은 클라이언트, 기본 노드, 및/또는 다른 임의의 백업 노드로부터 취득될 수 있다. 기본 노드가 기능하지 않으면, 뷰 변경 프로토콜이 트리거될 수 있다.
단계(412b)에서, 준비 단계에서, 사전-준비 메시지가 유효한 경우, 백업 노드는 준비 메시지를 시스템의 다른 노드로 멀티캐스팅한다.
단계(413)에서, 준비 단계에서, 기본 노드 또는 백업 노드는 다른 노드로부터 전송된 준비 메시지를 수신한다. (Q-1)개의 유효 준비 메시지를 취득하는 것은, 합의 프로세스가 다음 확정 단계에 진입하기 전에 충족되어야 할 조건일 수 있다. 도 4a 및 도 4b에 도시된 실시형태에서, 예를 들어, (Q-1)은 2F이며, 2F개 이상의 준비 메시지가 필요하다. 2F개 이상의 준비 메시지는 백업 노드 또는 기본 노드의 고유한 준비 메시지를 포함할 수 있다. 백업 노드의 경우, 2F개 이상의 준비 메시지는, 단계(412b)에서 준비 메시지(즉, 단계(412b)에서 백업 노드 자체에 의해 멀티캐스팅된 준비 메시지)를 포함할 수 있다.
단계(414)에서, 기본 노드 또는 백업 노드는 사전-준비 메시지 및 적어도 (Q-1)개의 준비 메시지를 저장할 수 있다. 예를 들어, 노드에 의해 다수인 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)가 수행될 수 있다. 일 실시형태에서, 단계(415)에서의 확정 단계는 적어도 사전-준비 메시지 및 (Q-1)개의 준비 메시지가 저장된 후에 수행된다. 단계(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)에서, 기본 노드 또는 백업 노드는, 자신이 일단 저장 단계(단계(414))에서 저장한 사전-준비 메시지 및 적어도 (Q-1)개의 준비 메시지를 로딩할 수 있다. 일부 실시형태에서, 시스템은 중단 후 자발적으로 또는 비자발적으로 재시작할 수 있다. 단계(499)가 수행되면, 소정의 상황에서(예를 들어, 비기능 노드가 기본 노드이고 기본 노드가 타임아웃 기간 내에 자신의 기능 상태를 재개하지 않는 경우) 뷰 변경 프로토콜이 트리거될 수 있다. 그러나, 타임아웃 조건이 충족되지 않으면(예를 들어, 타임아웃 조건을 트리거하기 전에 단계(499)가 완료되면)， 뷰 변경 프로토콜은 도 4a 및 도 4b에 도시된 바와 같이 트리거되지 않을 수 있다. 따라서, 비기능 기본 노드가 타임아웃 조건을 피하기에 충분히 빠르게 자신의 기능 상태를 재개하면 뷰 변경 프로토콜이 트리거되지 않을 수 있고, 프로토콜에서 단계(415 내지 417)가 후속할 수 있다. 타임아웃 조건이 충족되면 (예를 들어, 타임아웃 조건이 트리거되기 전에 단계(499)가 완료되지 않으면)，뷰 변경 프로토콜은 도 4c 및 도 4d를 참조하여 후술하는 바와 같이 트리거될 수 있다.
도 4c는, 본 명세서의 다양한 실시형태에 따라 뷰 v+1에서의 새로운 기본 노드로 되는 뷰 v에서의 백업 노드에 의한 합의 단계들(420a)의 흐름도를 도시한다. 도 4d는, 본 명세서의 다양한 실시형태에 따라 뷰 v+1에서의 백업 노드로서 유지되는 뷰 v에서의 백업 노드에 의한 합의 단계들(420b)의 흐름도를 도시한다. 단계들(420a 및 420b)은, 도 1의 시스템(100)의 하나 이상의 구성요소(예를 들어, 전술한 노드 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의 단계(415) 전에 그리고 단계(414) 후에 트리거되는 경우. 도 4c 및 도 4d에 도시된 단계들이 수행된다. 간결성을 위해, 단계(499) 전의 단계들(도 4b에 도시된 단계(414)까지의 단계들)은 도 4c 및 도 4d에서 재현되지 않는다.
일부 실시형태에서, 도 4c 및 도 4d에 도시된 바와 같은 합의 단계들(420a 및 420b)은 뷰 변경을 트리거하는 상황에 해당할 수 있다. 뷰 v의 기본 노드(예를 들어, 노드 0)는, 장애가 있거나 기능하지 않을 수 있다. 도 4c의 경우, 뷰 v+1에서의 새로운 기본 노드로 되는 뷰 v에서의 백업 노드(예를 들어, 노드 1)는 단계(499, 423, 424a, 425a, 426a, 425, 426, 및 427)를 수행할 수 있다. 뷰 v+1에서의 백업 노드로서 유지되는 뷰 v에서의 백업 노드(예를 들어, 노드 2 또는 노드 3)는 단계(499, 423, 424b, 425b, 426b, 425, 426, 및 427)를 수행할 수 있다. 양측 도면의 수직 방향으로, 다양한 단계는 "뷰 변경", "새로운 뷰", "준비", "확정", 및 "응답" 단계에 해당하며, 도 1 내지 도 3c를 참조하여 전술한 설명을 참조할 수 있다. 다양한 단계의 배열은, 명확성을 위해 도시된 것이며, 엄격한 시퀀스 요건을 갖지 않아도 된다. 기본 노드와 백업 노드는 PBFT 합의 메커니즘에서 정의된 노드들일 수 있다. 이하의 설명은, 소정의 단계들이 서로 얽혀 있으므로 도 4c 또는 도 4d를 참조한다.
일부 실시형태에서, 단계(499)에 도시된 바와 같이, 여전히 뷰 v에서, 기본 노드(노드 0) 및 일부 백업 노드(노드 1, 2, 및/또는 3)의 각각은, 단계(414)에서 각각 저장된 사전-준비 메시지 및 적어도 (Q-1)개의 준비 메시지를 로딩할 수 있다. 메시지가 영구 저장 장치에 저장된 경우, 이제 메시지를 영구 저장 장치로부터 로딩할 수 있다. 시스템 재시작은, 정상 동작의 중단(예를 들어, 시스템 충돌로 인한 다운타임)에 대한 응답으로 수행될 수 있다.
일 실시형태에서, 기본 노드가 기능하지 않을 수 있다고 의심되는 경우, 백업 노드(예를 들어, 노드 1, 2, 또는 3)는, 단계(423)에 도시된 바와 같이 로딩된 사전-준비 메시지 및 로딩된 적어도 (Q-1)개의 준비 메시지를 포함할 수 있는 뷰 변경 메시지를 멀티캐스팅할 수 있다. 뷰 변경 프로토콜에서, 백업 노드들 중 하나는 새로운 기본 노드로 되고, 나머지는 백업 노드로 유지될 수 있다. 새로운 기본 노드의 선택은 전술한 바와 같다. 예를 들어, 도시된 바와 같이, 노드 1은 새로운 기본 노드로 선택될 수 있는 반면, 노드 2 및 노드 3은 백업 노드로서 유지될 수 있다.
단계(424a)에서, 백업 노드가, 대응하는 노드가 뷰 변경 메시지에 동의함을 각각 나타내는 다른 노드로부터 적어도 Q개의 뷰 변경 메시지를 취득한 경우, 새로운 기본 노드(예를 들어, 노드 1)가 선택될 수 있다. 적어도 Q개의 뷰 변경 메시지는 백업 노드 자체에 의해 멀티캐스트 뷰 변경 메시지를 포함할 수 있다. 단계(425a)에서, 새로운 기본 노드(예를 들어, 노드 1)는, 적어도 Q개의 뷰 변경 메시지를 포함하는 새로운 뷰 메시지를 백업 노드들 중 적어도 일부에 멀티캐스팅한다.
도 4d에 도시된 바와 같이. 단계(424b)에서, 뷰 변경 프로토콜 하의 프로세스에서, 백업 노드는, 새로운 기본 노드가 Q개 이상의 뷰 변경 메시지를 수신하였음을 나타내는 새로운 뷰 메시지를 새로운 기본 노드로부터 취득할 수 있고, 여기서, 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의 시스템(100)의 하나 이상의 구성요소(예를 들어, 전술한 노드 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)의 단계들은 현재 뷰에서의 백업 노드에 의해 수행될 수 있으며, 이러한 백업 노드는, 뷰 변경이 발생할 경우 백업 노드로서 유지되거나 새로운 기본 노드로 될 수 있다. PBFT 합의 메커니즘에 따른 뷰는 방법(510)의 구현 동안 변경되거나 변경되지 않을 수 있다. 방법(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개인 다수의 준비 메시지가 저장될 수 있다. 일부 실시형태에서는, 사전-준비 메시지 및 (Q-1)개의 준비 메시지만이 저장된다. 예를 들어, (Q-1)이 2F이고 이전 단계에서 3F개의 준비 메시지가 취득되면, 여기서, 사전-준비 메시지 및 2F개의 준비 메시지만이 저장될 수 있다. 일부 실시형태에서, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하는 단계는 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지만을 저장하는 단계를 포함한다. 예를 들어, 사전-준비 메시지와 (Q-1)개의 준비 메시지만이 저장된다. 사전-준비 메시지와 (Q-1)개 이상의 준비 메시지 이외의 메시지는 저장되지 않는다. 예를 들어, 합의 검증의 각 라운드마다, 확정 메시지가 저장되지 않는다. 이는 다수 라운드의 합의 검증이 수행되는 경우에도 동일하게 적용될 수 있다.
일부 실시형태에서, 사전-준비 메시지 및 적어도 (Q-1)개의 준비 메시지는, 시스템 재시작과 같이 시스템 다운타임 복구 후에 저장된 데이터를 검색할 수 있는 한 다양한 방식으로 저장될 수 있다. 예를 들어, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지는 관계형 데이터베이스, 비관계형 데이터베이스, 문서 시스템 등에 저장될 수 있다. 예를 들어, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지는 영구 저장 장치에 저장될 수 있다. 본 명세서에 설명하는 저장 단계 및 다른 단계는 프로그래밍 언어에 의해 한정되지 않을 수 있다.
일부 실시형태에서, 블록(514)은, 블록(513)이 충족될 때에만, 즉 (Q-1)개 이상의 준비 메시지가 취득될 때에만 수행될 수 있다. 다른 실시형태에서, 각각의 사전-준비 메시지 또는 준비 메시지는 수신되는 즉시 저장될 수 있다.
일부 실시형태에서, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장한 후(블록 514) 그리고 확정 메시지를 멀티캐스팅하기 전에(블록 515), 방법은, 시스템 재시작을 수행하는 단계; 및 저장된 사전-준비 메시지 및 저장된 (Q-1)개 이상의 준비 메시지를 로딩하는 단계를 더 포함한다. 정상적인 동작의 중단(예를 들어, 시스템 충돌, 정전 등)에 대한 응답으로 시스템 재시작을 수행할 수 있다. PBFT 시스템의 노드들 중 하나 이상에 또는 전부에 중단이 발생할 수 있다. 일부 실시형태에서, 최대 N개의 모든 노드에서 충돌이 발생하고, N개의 노드 중 적어도 Q개는, 시스템 재시작을 수행하고, 대응하는 저장된 사전-준비 메시지 및 저장된 (Q-1)개 이상의 준비 메시지를 각각 로딩한다. 다음으로, 뷰 변경 프로토콜이 트리거되거나 트리거되지 않을 수 있다.
일 실시형태에서, 재시작이 타임아웃의 트리거를 피하기에 충분히 빠르면 뷰 변경 프로토콜이 트리거되지 않을 수 있고, 따라서 시스템 재시작은 뷰 변경의 트리거를 피한다. 즉, 시스템 재시작을 수행하는 단계는 뷰 변경을 트리거하지 않고 시스템 재시작을 수행하는 단계를 포함한다. 이에 따라, 블록(515)으로부터 방법(510)의 나머지 단계들이 후속할 수 있다.
그렇지 않다면, 뷰 변경 프로토콜이 트리거될 수 있다. 일 실시형태에서, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장한 후 그리고 확정 메시지를 멀티캐스팅하기 전에, 방법은, 로딩된 사전-준비 메시지 및 로딩된 (Q-1)개 이상의 준비 메시지를 포함하는 뷰 변경 메시지를 멀티캐스팅하는 단계를 더 포함한다. 다른 백업 노드들도 뷰 변경 메시지를 멀티캐스팅할 수 있다. 백업 노드들 중 하나는, 새로운 기본 노드로 되도록 선택될 수 있으며, 이것은 선행 단계들을 수행한 하나의 백업 노드일 수도 있고 아닐 수도 있다.
일부 실시형태에서, 전술한 단계들을 수행한 백업 노드가 새로운 기본 노드로 되도록 선택되지 않으면, 이러한 백업 노드는 뷰 변경 동안 백업 노드로서 유지될 수 있고 후속 단계들을 수행할 수 있다. 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장한 후 그리고 확정 메시지를 멀티캐스팅하기 전에, 방법은, 새로운 기본 노드로부터, 새로운 기본 노드가 Q개 이상의 뷰 변경 메시지를 수신하였음을 나타내는 새로운 뷰 메시지를 취득하는 단계로서, Q개 이상의 뷰 변경 메시지의 각각은 대응 노드가 뷰 변경 메시지에 동의함을 나타내는 단계; 새로운 뷰 메시지의 수락을 나타내는 다른 준비 메시지를, 새로운 기본 노드를 포함하는 백업 노드들 중 적어도 일부에 멀티캐스팅하는 단계; 및 백업 노드들 중 (Q-1)개 이상으로부터 다른 (Q-1)개 이상의 준비 메시지를 각각 취득하는 단계를 더 포함하고, 그 다른 (Q-1)개 이상의 준비 메시지는 멀티캐스팅된 다른 준비 메시지를 포함한다.
다른 실시형태에서, 전술한 단계들을 수행한 노드가 새로운 기본 노드로 되도록 선택되면, 이 노드는 뷰 변경 동안 새로운 기본 노드로 될 수 있으며 후속 단계들을 수행할 수 있다. 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장한 후 그리고 확정 메시지를 멀티캐스팅하기 전에, 방법은, Q개 이상의 뷰 변경 메시지를 백업 노드들 중 Q개 이상의 백업 노드로부터 각각 취득하는 단계로서, Q개 이상의 뷰 변경 메시지의 각각은 대응 노드가 뷰 변경 메시지에 동의함을 나타내고, Q개 이상의 뷰 변경 메시지는 멀티캐스트 뷰 변경 메시지를 포함하는, 단계; 새로운 기본 노드로서 기능하는 하나의 백업 노드가 Q개 이상의 뷰 변경 메시지를 수신하였음을 나타내는 새로운 뷰 메시지를 백업 노드들 중 적어도 일부에 멀티캐스팅하는 단계; 및 백업 노드들 중 (Q-1)개 이상의 백업 노드로부터 다른 (Q-1)개 이상의 준비 메시지를 각각 취득하는 단계를 더 포함하고, 그 다른 (Q-1)개 이상의 준비 메시지는 다른 멀티캐스팅된 준비 메시지를 포함한다.
블록(515 및 516) 및 후속 단계는, 뷰 변경이 발생하지 않으면 블록(511 내지 514)과 동일한 뷰에서 또는 블록(515) 전에 뷰 변경이 발생하면 새로운 뷰에서 수행될 수 있다.
블록(515)은, 하나의 백업 노드가 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는 확정 메시지를, 다른 백업 노드들과 기본 노드 층 적어도 일부에 멀티 캐스팅하는 단계를 포함한다. 일부 실시형태에서, 확정 메시지는, 하나의 백업 노드가 사전-준비 메시지에 동의하고 (Q-1)개 이상의 준비 메시지를 취득하였음을 나타낸다. 일부 실시형태에서는, 확정 메시지를 멀티캐스팅하는 것에 동의하도록 검증 단계들이 수행될 수 있다. 예를 들어, 전술한 바와 같이, 다이제스트 D(m)은 다이제스트 d에 대한 검증 순서에 따라 결정될 수 있다. 일관성이 있는 경우, 확정 메시지가 멀티캐스팅될 수 있다.
일부 실시형태에서, 블록(513)에서 백업 노드들 중 (Q-1)개 이상의 백업 노드 중 최대 F개는, 확정 메시지들을 각각 멀티캐스팅한 후에 장애가 있거나 기능하지 않으며, 시스템 재시작을 수행하지 않는다. 예를 들어, 확정한 F개 노드는, 시스템 충돌을 경험할 수 있고, 기능을 재개하도록 재시작하지 않는다. 그럼에도 불구하고, 일관성 없는 결과를 초래하지 않고 블록체인으로 분기하지 않으면서 합의 검증을 올바르게 수행할 수 있다.
블록(516)은, 기본 노드와 백업 노드들 중 Q개 이상의 노드로부터 Q개 이상의 확정 메시지를 각각 취득하는 단계를 포함하고, Q개 이상의 확정 메시지의 각각은, 대응 노드가 자신이 수신한 (Q-1)개 이상의 준비 메시지에 동의함을 나타낸다. 일부 실시형태에서, 확정 메시지는, 확정 메시지를 멀티캐스팅한 대응 노드가 사전-준비 메시지에 동의하고 (Q-1)개 이상의 준비 메시지들을 취득하였음을 나타낸다. Q개의 확정 메시지는, 별개의 노드에서 온 것일 수 있으며 유효하고 일관되며, Q개의 노드가 요청들을 순서대로 실행할 준비가 되어 있음을 나타낸다. 따라서, 대다수의 노드에 의해 합의에 도달하고, 다음 실행 단계를 수행할 수 있다.
일부 실시형태에서, 확정 메시지를 멀티캐스팅한 후(블록 515) 그리고 요청을 실행하기 전에, 방법은, 시스템 재시작을 수행하는 단계, 및 저장된 사전-준비 메시지 및 저장된 (Q-1)개 이상의 준비 메시지를 로딩하는 단계를 더 포함한다. 시스템 재시작은 자발적으로 또는 비자발적으로 수행될 수 있다. 시스템 충돌과 같이 시스템 또는 장치 기능의 중단에 의해 시스템이 재시작될 수 있다.
일부 실시형태에서, 방법(510)은, 하나 이상의 트랜잭션을 순서에 따라 하나의 백업 노드에 의해 유지되는 블록체인의 로컬 카피에 패킹하는 단계를 더 포함할 수 있다. 예를 들어, 요청은, 적어도 (Q-F)개(최대 F개의 비기능 노드를 고려한 Q개의 확정 메시지임)의 정직한 노드가 해당 확정 메시지의 다이제스트 d를 검증하였으므로(또는 기본 노드에 대해서는, 기본 노드가 다이제스트 d를 제안하였으므로 검증을 수행하지 않아도 됨)，합의 검증될 수 있다. 그 결과, 충분한 노드가 해당 트랜잭션을 검증하였다면, 트랜잭션을 블록체인에 패킹할 수 있다. 원래 요청(들)을 전송한 클라이언트(들)（예를 들어, 노드 A)는 통보받을 수 있다.
도 5b는 본 명세서의 다양한 실시형태에 따른 합의 방법(520)의 흐름도를 도시한다. 방법(520)은 도 1의 시스템(100)의 하나 이상의 구성요소(예를 들어, 전술한 노드 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개인 다수의 준비 메시지가 저장될 수 있다. 일부 실시형태에서는, 사전-준비 메시지 및 (Q-1)개의 준비 메시지만이 저장된다. 예를 들어, (Q-1)이 2F이고 이전 단계에서 3F개의 준비 메시지가 취득되면, 여기서, 사전-준비 메시지 및 2F개의 준비 메시지만이 저장될 수 있다. 일부 실시형태에서, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하는 단계는 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지만을 저장하는 단계를 포함한다. 예를 들어, 사전-준비 메시지와 (Q-1)개의 준비 메시지만이 저장된다. 사전-준비 메시지와 (Q-1)개 이상의 준비 메시지 이외의 메시지는 저장되지 않는다. 예를 들어, 합의 검증의 각 라운드마다, 확정 메시지가 저장되지 않는다. 이는 다수 라운드의 합의 검증이 수행되는 경우에도 동일하게 적용될 수 있다.
일부 실시형태에서, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지는, 시스템 재시작과 같이 시스템 다운타임 복구 후에 저장된 데이터를 검색할 수 있는 한 다양한 방식으로 저장될 수 있다. 예를 들어, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지는 관계형 데이터베이스, 비관계형 데이터베이스, 문서 시스템 등에 저장될 수 있다. 예를 들어, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지는 영구 저장 장치에 저장될 수 있다. 본 명세서에 기술된 저장 단계 및 다른 단계는 프로그래밍 언어에 의해 한정되지 않을 수 있다.
일부 실시형태에서, 블록(523)은, 블록(522)이 충족될 때, 즉 (Q-1)개 이상의 준비 메시지가 취득될 때에만 수행될 수 있다. 다른 실시형태에서, 각각의 사전-준비 메시지 또는 준비 메시지는 수신되는 즉시 저장될 수 있다.
일부 실시형태에서, 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장한 후(블록 523) 그리고 확정 메시지를 멀티캐스팅하기 전에(블록 524), 방법은, 시스템 재시작을 수행하는 단계; 및 저장된 사전-준비 메시지 및 저장된 (Q-1)개 이상의 준비 메시지를 로딩하는 단계를 더 포함한다. 정상적인 동작의 중단(예를 들어, 시스템 충돌, 정전 등)에 대한 응답으로 시스템 재시작을 수행할 수 있다. PBFT 시스템에서 노드들 중 하나 이상 또는 전부에 중단이 발생할 수 있다. 일부 실시형태에서, 최대 N개의 노드 중 최대 전부에서 충돌이 발생하고, N개 노드 중 적어도 Q개는, 시스템 재시작을 수행하고, 대응하는 저장된 사전-준비 메시지 및 저장된 (Q-1)개 이상의 준비 메시지를 각각 로딩한다. 다음으로, 뷰 변경 프로토콜이 트리거되거나 트리거되지 않을 수 있다.
일 실시형태에서, 재시작이 타임아웃의 트리거를 피할 정도로 빠르면 뷰 변경 프로토콜이 트리거되지 않을 수 있고, 따라서 시스템 재시작은 뷰 변경의 트리거를 피한다. 이에 따라, 블록(524)으로부터 방법(520)의 나머지 단계들이 후속할 수 있다. 다른 일 실시형태에서는, 뷰 변경 프로토콜이 트리거될 수 있고, 블록(524)으로부터 방법(520)의 나머지 단계들이 후속하지 않을 수 있다.
블록(524)은 백업 노드들 중 적어도 일부에 확정 메시지를 멀티캐스팅하는 단계를 포함하며, 이 확정 메시지는 기본 노드가 (Q-1)개 이상의 준비 메시지에 동의함을 나타낸다. 일부 실시형태에서, 확정 메시지는 기본 노드가 (Q-1)개 이상의 준비 메시지를 취득하였음을 나타낸다. 일부 실시형태에서, 블록(522)에서 백업 노드들 중 (Q-1)개 이상의 백업 노드 중 최대 F개는, 확정 메시지를 각각 멀티캐스팅한 후에 장애가 있거나 그 외에는 기능하지 않는 것이며, 시스템 재시작을 수행하지 않는다. 예를 들어, 확정된 F개 노드는, 시스템 충돌을 경험할 수 있고, 기능을 재개하기 위해 재시작하지 않을 수 있다. 그럼에도 불구하고, 일관성 없는 결과를 초래하지 않고 블록체인으로 분기하지 않으면서 합의 검증을 적절히 수행할 수 있다.
블록(525)은, 백업 노드들과 기본 노드 중 Q개 이상의 노드로부터, Q 개 이상의 확정 메시지를 각각 취득하는 단계를 포함하고, Q개 이상의 확정 메시지의 각각은, 대응하는 노드가 그 대응하는 노드에 의해 수신되는 (Q-1)개 이상의 준비 메시지에 동의함을 나타내고, Q개 이상의 확정 메시지는 멀티캐스팅된 확정 메시지를 포함한다. 일부 실시형태에서, 확정 메시지는, 확정 메시지를 멀티캐스팅하는 대응하는 노드가 사전-준비 메시지에 동의하고 (Q-1)개 이상의 준비 메시지를 취득하였음을 나타낸다. Q개 이상의 확정 메시지는, 별개의 노드들로부터 온 것일 수 있으며, 유효하고 일관성이 있으며, 이는 Q개 이상의 노드가 요청들을 순서대로 실행할 준비가 되어 있음을 나타낸다. 따라서, 대다수의 노드에 의해 합의에 도달하고, 다음 실행 단계를 수행할 수 있다.
일부 실시형태에서, 확정 메시지를 멀티캐스팅한 후(블록 525) 요청들을 실행하기 전에, 방법은, 시스템 재시작을 수행하는 단계, 및 저장된 사전-준비 메시지 및 저장된 (Q-1)개 이상의 준비 메시지를 로딩하는 단계를 더 포함한다. 시스템 재시작은 자발적으로 또는 비자발적으로 수행될 수 있다. 시스템 재시작은, 시스템 충돌 등의 시스템 또는 장치 기능에 대한 중단으로 인해 야기될 수 있다.
일부 실시형태에서, 방법(520)은, 순서에 따라 기본 노드에 의해 유지되는 블록체인의 로컬 카피에 하나 이상의 트랜잭션을 패킹하는 단계를 더 포함할 수 있다. 예를 들어, 적어도 (Q-F)개(최대 F개의 비기능 노드를 고려한 Q개의 확정 메시지임)의 정직한 노드가 자신의 확정 메시지 내의 다이제스트(d)를 검증하였으므로(또는 기본 노드에 대해서는, 기본 노드가 다이제스트(d)를 제안하였으므로 검증을 수행할 필요가 없을 수도 있음), 요청이 합의-검증될 수 있다. 그 결과, 충분한 노드들이 해당 트랜잭션을 검증하였다면, 트랜잭션을 블록체인에 패킹할 수 있다. 원래 요청(들)을 전송한 클라이언트(들)(예를 들어, 노드 A)는 통지받을 수 있다.
도 6a는 다양한 실시형태에 따른 합의 시스템(610)의 블록도를 도시한다. 합의 시스템(610)(예를 들어 컴퓨터 시스템)은, 전술한 노드 0, 노드 1, 노드 2,…，또는 노드 i 또는 유사한 장치의 구현예, 또는 노드들 중 임의의 노드와 추가 장치(예를 들어, 노드 A)의 조합일 수 있다. 방법(510)은 합의 시스템(610)에 의해 구현될 수 있다. 합의 시스템(610)은, 하나 이상의 프로세서, 및 하나 이상의 프로세서에 연결되고, 시스템 또는 장치(예를 들어, 프로세서)가 방법(510)을 수행하게 하도록 하나 이상의 프로세서에 의해 실행 가능한 명령어로 구성된 하나 이상의 비일시적 컴퓨터-판독가능 저장 매체(예를 들어, 하나 이상의 메모리)를 포함할 수 있다. 합의 시스템(610)은 백업 노드에서 구현될 수 있다. 합의 시스템(610)은 명령어(예를 들어, 소프트웨어 명령어)에 대응하는 다양한 유닛/모듈을 포함할 수 있다.
일부 실시형태에서, 합의 시스템(610)은 합의 장치라고 칭할 수 있다. 합의 장치는 블록체인을 유지하기 위한 것일 수 있고, 여기서, 다수(N개)의 노드들은 블록체인을 유지하고, N개 노드 중 하나의 노드는 기본 노드로서 기능하고, 나머지 (N-1)개의 노드는 백업 노드로서 기능하며, 합의 장치는, (N-1)개의 백업 노드 중 하나의 백업 노드로서 기능하고, 하나 이상의 프로세서, 및 하나 이상의 프로세서에 연결되고, 장치가 동작을 수행하게 하도록 하나 이상의 프로세서에 의해 실행 가능한 명령어로 구성된 하나 이상의 비일시적 컴퓨터-판독가능 메모리를 포함한다. 합의 장치는, 명령어(예를 들어, 소프트웨어 명령어)에 대응하는 다양한 유닛/모듈을 포함할 수 있다. 합의 장치는, 기본 노드로부터 사전-준비 메시지를 취득하기 위한 제1 취득 모듈(611); 나머지 (N-2)개의 백업 노드와 기본 노드 중 적어도 일부에, 사전-준비 메시지의 수락을 나타내는 준비 메시지를 멀티캐스팅하기 위한 제1 멀티캐스팅 모듈(612); (Q-1)개 이상의 백업 노드로부터 (Q-1)개 이상의 준비 메시지를 각각 취득하기 위한 제2 취득 모듈(613)로서, Q(정족수)는 가장 가까운 정수로 올림된 (N+F+1)/2이고, F는 가장 가까운 정수로 내림된 (N-1)/3이고, (Q-1)개 이상의 준비 메시지는 멀티캐스팅된 준비 메시지를 포함하는, 제2 취득 모듈; 사전-준비 메시지와 (Q-1)개 이상의 준비 메시지를 저장하기 위한 저장 모듈(614); 나머지 백업 노드들과 기본 노드 중 적어도 일부에, 하나의 백업 노드가 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는 확정 메시지를 멀티캐스팅하기 위한 제2 멀티캐스팅 모듈(615); 및 백업 노드들과 기본 노드 중 Q개 이상의 노드로부터 Q개 이상의 확정 메시지를 각각 취득하기 위한 제3 취득 모듈(616)을 포함하고, Q개 이상의 확정 메시지의 각각은, 대응하는 노드가 그 대응하는 노드에 의해 수신되는 (Q-1)개 이상의 준비 메시지에 동의함을 나타내고, Q개 이상의 확정 메시지는 멀티캐스팅된 확정 메시지를 포함할 수 있다.
일부 실시형태에서, 제1 취득 모듈(611) 또는 다른 모듈은, 또한, 하나 이상의 클라이언트, 기본 노드, 또는 하나 이상의 다른 백업 노드 중 적어도 하나로부터 하나 이상의 트랜잭션 요청을 취득하기 위한 것이다. 합의 장치는, 하나 이상의 트랜잭션을 순서에 따라 하나의 백업 노드에 의해 유지되는 블록체인의 로컬 카피에 패킹하기 위한 패킹 모듈(617)을 더 포함할 수 있다.
도 6b는 다양한 실시형태에 따른 합의 시스템(620)의 블록도를 도시한다. 합의 시스템(620)(예를 들어, 컴퓨터 시스템)은, 전술한 노드 0, 노드 1, 노드 2,…, 또는 노드 i 또는 유사한 장치의 구현 예, 또는 노드들 중 임의의 노드와 추가 장치(예를 들어, 노드 A)의 조합일 수 있다. 방법(520)은 합의 시스템(620)에 의해 구현될 수 있다. 합의 시스템(620)은, 하나 이상의 프로세서, 및 하나 이상의 프로세서에 연결되고, 시스템 또는 장치(예를 들어, 프로세서)가 방법(520)을 수행하게 하도록 하나 이상의 프로세서에 의해 실행 가능한 명령어로 구성된 하나 이상의 비일시적 컴퓨터-판독가능 저장 매체(예를 들어, 하나 이상의 메모리)를 포함할 수 있다. 합의 시스템(620)은 기본 노드에서 구현될 수 있다. 합의 시스템(620)은, 명령어(예를 들어, 소프트웨어 명령어)에 대응하는 다양한 유닛/모듈을 포함할 수 있다.
일부 실시형태에서, 합의 시스템(620)은 합의 장치라고 칭할 수 있다. 합의 장치는 블록체인을 유지하기 위한 것일 수 있고, 여기서, 다수(N개)의 노드들은 블록체인을 유지하고, N개 노드 중 하나의 노드는 기본 노드로서 기능하고, 나머지 (N-1)개의 노드는 백업 노드로서 기능하며, 합의 장치는, 기본 노드로서 기능하고, 하나 이상의 프로세서, 및 하나 이상의 프로세서에 연결되고, 장치가 동작을 수행하게 하도록 하나 이상의 프로세서에 의해 실행 가능한 명령어로 구성된 하나 이상의 비일시적 컴퓨터-판독가능 메모리를 포함한다. 합의 장치는 명령어(예를 들어, 소프트웨어 명령어)에 대응하는 다양한 유닛/모듈을 포함할 수 있다. 합의 장치는, 백업 노드들 중 적어도 일부에 사전-준비 메시지를 멀티캐스팅하기 위한 제1 멀티캐스팅 모듈(621); (Q-1)개 이상의 백업 노드로부터 (Q-1)개 이상의 준비 메시지를 각각 취득하기 위한 제1 취득 모듈(622)로서, 준비 메시지의 각각은 대응하는 백업 노드에 의한 사전-준비 메시지의 수락을 나타내고, Q(정족수)는 가장 가까운 정수로 올림된 (N+F+1)/2이고, F는 가장 가까운 정수로 내림된 (N-1)/3인, 제1 취득 모듈; 사전-준비 메시지 및 (Q-1)개 이상의 준비 메시지를 저장하기 위한 저장 모듈(623); 백업 노드들 중 적어도 일부에, 기본 노드가 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는 확정 메시지를 멀티캐스팅하기 위한 제2 멀티캐스팅 모듈(624); 및 백업 노드들과 기본 노드 중 Q개 이상의 노드로부터 Q개 이상의 확정 메시지를 각각 취득하기 위한 제2 취득 모듈(625)을 포함하고, Q개 이상의 확정 메시지의 각각은, 대응하는 노드가 그 대응하는 노드에 의해 수신되는 (Q-1)개 이상의 준비 메시지에 동의함을 나타내고, Q개 이상의 확정 메시지는 멀티캐스팅된 확정 메시지를 포함할 수 있다.
일부 실시형태에서, 합의 장치는, 하나 이상의 클라이언트 또는 하나 이상의 백업 노드 중 적어도 하나로부터, 하나 이상의 트랜잭션 요청을 취득하기 위한 제3 취득 모듈(626)을 더 포함할 수 있다. 합의 장치는, 하나 이상의 트랜잭션을 순서에 따라 기본 노드에 의해 유지되는 블록체인의 로컬 카피에 패킹하기 위한 패킹 모듈(627)을 더 포함할 수 있다.
본 명세서에 기재된 기술은 하나 이상의 전용 연산 장치에 의해 구현된다. 전용 연산 장치는, 데스크톱 컴퓨터 시스템, 서버 컴퓨터 시스템, 휴대용 컴퓨터 시스템, 핸드헬드 장치, 네트워킹 장치, 또는 기술을 구현하도록 하드와이어형 및/또는 프로그램 로직을 통합하는 다른 임의의 장치나 이러한 장치들의 조합일 수 있다. 전용 연산 장치는, 개인용 컴퓨터, 랩톱, 셀룰러 폰, 카메라 폰, 스마트폰, 개인 휴대 정보 단말, 미디어 플레이어, 내비게이션 장치, 이메일 장치, 게임 콘솔, 태블릿 컴퓨터, 웨어러블 장치 또는 이들의 조합으로서 구현될 수 있다. 연산 장치(들)는 일반적으로 운영 체제 소프트웨어에 의해 제어 및 조정된다. 종래의 운영 체제는, 실행을 위한 컴퓨터 프로세스를 제어 및 스케줄링하고, 메모리 관리를 수행하고, 파일 시스템, 네트워킹, I/O 서비스를 제공하고, 특히, 그래픽 사용자 인터페이스("GUI") 등과 같은 사용자 인터페이스 기능을 제공한다. 본 명세서에 기재된 다양한 시스템, 장치, 저장 매체, 모듈, 및 유닛은, 전용 연산 장치, 또는 하나 이상의 전용 연산 장치의 하나 이상의 연산 칩에 구현될 수 있다. 일부 실시형태에서, 본 명세서에 기재된 명령어는 전용 연산 장치 상의 가상 기계에서 구현될 수 있다. 명령어는, 실행될 때, 전용 연산 장치가 본 명세서에 기재된 다양한 방법을 수행하게 할 수 있다. 가상 기계는 소프트웨어, 하드웨어, 또는 이들의 조합을 포함할 수 있다. 예를 들어, 가상 기계는, 이더리움의 스마트 계약에 대한 런타임 환경을 제공하는 이더리움 가상 머신(EVM) 소프트웨어를 포함할 수 있다.
도 7은 본 명세서에 기재된 실시형태들 중 임의의 실시형태가 구현될 수 있는 컴퓨터 시스템(700)을 도시하는 블록도이다. 시스템(700)은 본 명세서에 기재된 방법들 중 임의의 방법(예를 들어, 합의 방법(510), 합의 방법(520))을 수행할 수 있다. 시스템(700)은 본 명세서에 기재된 시스템들 중 임의의 시스템(예를 들어, 합의 시스템(610), 합의 시스템(620))에서 구현될 수 있다. 시스템(700)은, 본 명세서에 기재된 노드들 중 임의의 노드에서 구현될 수 있고, 블록체인 계약을 구현하기 위한 대응 단계를 수행하도록 구성될 수 있다. 컴퓨터 시스템(700)은, 정보를 통신하기 위한 버스(702) 또는 다른 통신 메커니즘, 및 정보를 처리하도록 버스(702)와 연결된 하나 이상의 하드웨어 프로세서(704)를 포함한다. 하드웨어 프로세서(들)(704)는, 예를 들어, 하나 이상의 범용 마이크로프로세서일 수 있다.
컴퓨터 시스템(700)은, 또한, 프로세서(들)(704)에 의해 실행 가능한 명령어와 정보를 저장하기 위해 버스(702)에 연결된, 랜덤 액세스 메모리(RAM) 등의 메인 메모리(706), 캐시, 및/또는 다른 동적 저장 장치를 포함한다. 메인 메모리(706)는, 또한, 프로세서(들)(704)에 의해 실행 가능한 명령어의 실행 동안 임시 변수 또는 다른 중간 정보를 저장하는 데 사용될 수 있다. 이러한 명령어는, 프로세서(들)(704)가 액세스할 수 있는 저장 매체에 저장되는 경우, 컴퓨터 시스템(700)을 명령어에 특정된 동작을 수행하도록 맞춤화된 전용 기계로 되게 한다. 컴퓨터 시스템(700)은, 프로세서(들)(704)를 위한 정적 정보 및 명령을 저장하도록 버스(702)에 연결된 ROM(708) 또는 다른 정적 저장 장치를 더 포함한다. 자기 디스크, 광디스크, 또는 USB 썸 드라이브(플래시 드라이브) 등의 저장 장치(710)는, 정보 및 명령어를 저장하도록 제공되고 버스(702)에 연결된다.
컴퓨터 시스템(700)은, 컴퓨터 시스템과 조합하여 컴퓨터 시스템(700)을 전용 기계로 되게 하거나 프로그래밍하는 맞춤형 하드와이어 로직, 하나 이상의 ASIC 또는 FPGA, 펌웨어, 및/또는 프로그램 로직을 사용하여 본 명세서에 기재된 기술을 구현할 수 있다. 일 실시형태에 따르면, 본 명세서에 기재된 동작, 방법, 및 프로세스는, 메인 메모리(706)에 포함된 하나 이상의 명령어의 하나 이상의 시퀀스를 실행하는 프로세서(들)(704)에 응답하여 컴퓨터 시스템(700)에 의해 수행된다. 이러한 명령어는 저장 장치(710) 등의 다른 저장 매체로부터 메인 메모리(706)로 판독될 수 있다. 메인 메모리(706)에 포함된 명령어들의 시퀀스의 실행은 프로세서(들)(704)가 본 명세서에 기재된 프로세스 단계들을 수행하게 한다. 대체 실시형태에서, 하드와이어형 회로는 소프트웨어 명령어 대신 또는 소프트웨어 명령어와 함께 사용될 수 있다.
메인 메모리(706), ROM(708), 및/또는 저장 장치(710)는 비일시적 저장 매체를 포함할 수 있다. "비일시적 매체" 및 유사 용어는, 본원에서 사용되는 바와 같이, 기계가 특정 방식으로 동작하게 하는 데이터 및/또는 명령어를 저장하는 매체를 가리키며, 매체는 일시적 신호를 배제한다. 이러한 비일시적 매체는 비휘발성 매체 및/또는 휘발성 매체를 포함할 수 있다. 비휘발성 매체는, 예를 들어, 저장 장치(710)와 같은 광학 디스크 또는 자기 디스크를 포함한다. 휘발성 매체는 메인 메모리(706)와 같은 동적 메모리를 포함한다. 비일시적 매체의 일반적인 형태는, 예를 들어, 플로피 디스크, 가요성 디스크, 하드 디스크, 솔리드 스테이트 드라이브, 자기 테이프, 또는 다른 임의의 자기 데이터 저장 매체, CD-ROM, 다른 임의의 광학 데이터 저장 매체, 홀 패턴이 있는 임의의 물리적 매체, RAM, PROM, 및 EPROM, FLASH-EPROM, NVRAM, 다른 임의의 메모리 칩이나 카트리지, 및 이들의 네트워크화 버전을 포함한다.
컴퓨터 시스템(700)은 버스(702)에 연결된 네트워크 인터페이스(718)도 포함한다. 네트워크 인터페이스(718)는, 하나 이상의 로컬 네트워크에 접속된 하나 이상의 네트워크 링크에 결합하는 양방향 데이터 통신 연결을 제공한다. 예를 들어, 네트워크 인터페이스(718)는, 종합 정보 통신망(Integrated Services Digital Network; ISDN) 카드, 케이블 모뎀, 위성 모뎀, 또는 해당 유형의 전화선에 데이터 통신 접속을 제공하는 모뎀일 수 있다. 다른 일례로, 네트워크 인터페이스(718)는, 호환가능한 LAN(또는 WAN과 통신하기 위한 WAN 구성요소)에 데이터 통신 접속을 제공하기 위한 근거리 통신망(LAN) 카드일 수 있다. 무선 링크도 구현될 수 있다. 이러한 임의의 구현예에서, 네트워크 인터페이스(718)는, 다양한 유형의 정보를 나타내는 디지털 데이터 스트림을 반송하는 전기 신호, 전자기 신호, 또는 광학 신호를 송수신한다.
컴퓨터 시스템(700)은, 네트워크(들)， 네트워크 링크, 및 네트워크 인터페이스(718)를 통해 프로그램 코드를 비롯한 데이터를 수신할 수 있고 메시지를 송신할 수 있다. 인터넷을 예로 들면, 서버는, 인터넷, ISP, 로컬 네트워크, 및 네트워크 인터페이스(718)를 통해 애플리케이션 프로그램에 대해 요청된 코드를 송신할 수 있다.
수신된 코드는, 수신될 때 프로세서(들)(704)에 의해 실행될 수 있고, 및/또는 추후 실행을 위해 저장 장치(710) 또는 다른 비휘발성 저장 장치에 저장될 수 있다.
이전 섹션에서 설명한 각각의 프로세스, 방법, 및 알고리즘은, 하나 이상의 컴퓨터 시스템 또는 컴퓨터 하드웨어를 포함하는 컴퓨터 프로세서에 의해 실행되는 코드 모듈에 의해 구체화될 수 있고 완전히 또는 부분적으로 자동화될 수 있다. 프로세스 및 알고리즘은 특정 애플리케이션 회로에서 부분적으로 또는 전체적으로 구현될 수 있다.
전술한 다양한 특징과 프로세스는, 서로 독립적으로 사용될 수 있고 또는 다양한 방식으로 조합될 수 있다. 모든 가능한 조합 및 하위 조합은 본 명세서의 범위에 포함하고자 하는 것이다. 또한, 소정의 방법 또는 프로세스 블록들은 일부 구현예에서 생략될 수 있다. 본 명세서에 기재된 방법 및 프로세스는, 또한, 임의의 특정 시퀀스로 한정되지 않으며, 이와 관련된 블록 또는 상태는 적절한 다른 시퀀스로 수행될 수 있다. 예를 들어, 기술된 블록 또는 상태는 특정하게 개시된 순서와는 다른 순서로 수행될 수 있고, 또는 다수의 블록 또는 상태가 단일 블록 또는 상태로 결합될 수 있다. 블록 또는 상태의 예는 직렬, 병렬 또는 다른 소정의 방식으로 수행될 수 있다. 블록 또는 상태는 개시된 실시형태에 추가될 수 있고 또는 개시된 실시형태로부터 제거될 수 있다. 본 명세서에 기재된 시스템과 구성요소의 예는 설명한 것과는 다르게 구성될 수 있다. 예를 들어, 개시된 실시형태와 비교해 볼 때, 요소들을, 개시된 실시형태에 추가할 수 있고, 개시된 실시형태로부터 제거할 수 있고, 또는 재배열할 수 있다.
본 명세서에 기재된 방법의 다양한 동작은, 관련 동작을 수행하도록 일시적으로(예를 들어, 소프트웨어에 의해) 구성되거나 영구적으로 구성된 하나 이상의 프로세서에 의해 적어도 부분적으로 수행될 수 있다. 일시적으로 구성되거나 영구적으로 구성되는 것에 상관없이, 이러한 프로세서는 본 명세서에 기재된 하나 이상의 동작 또는 기능을 수행하도록 동작하는 프로세서-구현 엔진을 구성할 수 있다.
유사하게, 본 명세서에 기재된 방법은 적어도 부분적으로 프로세서로 구현될 수 있으며, 이때, 특정 프로세서 또는 프로세서들은 하드웨어의 예이다. 예를 들어, 방법의 동작들 중 적어도 일부는 하나 이상의 프로세서 또는 프로세서로 구현된 엔진에 의해 수행될 수 있다. 또한, 하나 이상의 프로세서는, 또한, "클라우드 연산" 환경 또는 "서비스형 소프트웨어"(Software as a Service; SaaS)에서 관련 동작의 성능을 지원하도록 동작할 수 있다. 예를 들어, 동작들 중 적어도 일부는 (프로세서를 포함하는 기계의 예인) 컴퓨터들의 그룹에 의해 수행될 수 있으며, 이들 동작은 네트워크(예를 들어, 인터넷) 및 하나 이상의 적절한 인터페이스(예를 들어, 응용 프로그램 인터페이스(API))를 통해 액세스 가능하다.
소정의 동작들의 수행은, 단일 기계 내에 상주하는 프로세서들뿐만 아니라 다수의 기계에 걸쳐 배치된 프로세서들 간에도 분산될 수 있다. 일부 실시형태에서, 프로세서 또는 프로세서로 구현된 엔진은, 단일 지리적 위치에(예를 들어, 가정 환경, 사무실 환경, 또는 서버 팜 내에) 위치할 수 있다. 다른 실시형태에서, 프로세서 또는 프로세서로 구현된 엔진은 다수의 지리적 위치에 걸쳐 분산될 수 있다.
본 명세서 전반에 걸쳐, 복수의 사례는 단일 사례로서 설명된 구성요소, 동작, 또는 구조를 구현할 수 있다. 하나 이상의 방법의 개별 동작이 별도의 동작으로 도시되고 설명되었지만, 하나 이상의 개별 동작은 동시에 수행될 수 있으며, 동작들이 도시된 순서대로 수행될 필요는 없다. 구성에 있어서 개별 구성요소로서 제시된 구조 및 기능은 결합된 구조 또는 구성요소로서 구현될 수 있다. 유사하게, 단일 구성요소로서 제시된 구조 및 기능은 별도의 구성요소로서 구현될 수 있다. 이들 변형, 수정, 추가, 개선, 및 다른 변형, 수정, 추가, 개선은 본원의 주제의 범위 내에 속한다. 또한, 본원에서 사용되는 관련 용어(예를 들어, "제1", "제2", "제3" 등)는, 임의의 순서, 높이, 또는 중요도를 나타내지 않으며, 오히려 한 구성요소를 다른 구성요소와 구별하도록 사용되는 것이다. 또한, "한", "하나", 및 "복수"라는 용어들은, 본원에서의 수량을 한정하는 것이 아니라 오히려 언급된 물품들 중 적어도 하나의 물품의 존재를 나타낸다.
주제의 개요를 특정 실시형태를 참조하여 설명하였지만, 본 명세서의 실시형태들의 넓은 범위를 벗어나지 않고 이들 실시형태에 대해 다양한 수정 및 변경이 이루어질 수 있다. 상세한 설명은 한정적인 의미로 해석되어서는 안 되며, 다양한 실시형태의 범위는, 첨부된 청구범위 및 이러한 청구범위의 자격이 있는 등가물의 전체 범위에 의해서만 정의된다.

Claims (11)

  1. 다수(N)의 노드에 의해 유지되는 블록체인 상에 구현되는 컴퓨터 구현 합의 방법(computer-implemented consensus method)으로서,
    상기 노드들 중 하나의 노드는 기본 노드로서 기능하고, 나머지 (N-1)개의 노드는 백업 노드로서 기능하며, 상기 방법은 상기 기본 노드에 의해 수행되며, 상기 방법은,
    상기 백업 노드 중 적어도 일부에 사전-준비(pre-prepare) 메시지를 멀티캐스팅하는 단계;
    상기 백업 노드 중 (Q-1)개 이상의 백업 노드로부터 각각 (Q-1)개 이상의 준비 메시지를 취득하는 단계로서, 상기 준비 메시지 각각은 대응하는 백업 노드에 의한 상기 사전-준비 메시지의 수락을 나타내고, Q(정족수)는 가장 가까운 정수로 올림된 (N+F+1)/2이고, F는 가장 가까운 정수로 내림된 (N-1)/3인, 상기 준비 메시지를 취득하는 단계;
    N개의 노드 중 하나 이상의 충돌 후 복구를 위해 적어도 최소량의 합의 메시지를 저장하는 단계로서, 상기 최소량의 합의 메시지는, 상기 사전-준비 메시지, 및 상기 (Q-1)개 이상의 준비 메시지 중 적어도 (Q-1)개를 포함하는, 적어도 최소량의 합의 메시지를 저장하는 단계;
    상기 백업 노드 중 적어도 일부에, 상기 기본 노드가 상기 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는 확정 메시지(commit message)를 멀티캐스팅하는 단계; 및
    상기 기본 노드와 상기 백업 노드 중 Q개 이상의 노드로부터 Q개 이상의 확정 메시지를 각각 취득하는 단계를 포함하되, 상기 Q개 이상의 확정 메시지의 각각은, 상기 Q개 이상의 노드의 대응하는 노드가 상기 대응하는 노드에 의해 수신되는 (Q-1)개 이상의 준비 메시지에 동의함을 나타내는, 컴퓨터 구현 합의 방법.
  2. 제1항에 있어서,
    상기 백업 노드 중 적어도 일부에 상기 사전-준비 메시지를 멀티캐스팅하는 단계 전에, 상기 방법은, 하나 이상의 클라이언트 또는 하나 이상의 백업 노드 중 적어도 하나로부터 하나 이상의 트랜잭션 요청을 취득하는 단계를 더 포함하는, 컴퓨터 구현 합의 방법.
  3. 제2항에 있어서,
    상기 사전-준비 메시지는 상기 하나 이상의 트랜잭션 요청에 대응하는 하나 이상의 트랜잭션의 순서를 포함하고; 그리고
    상기 확정 메시지는, 상기 확정 메시지를 전송하는 상기 기본 노드가 상기 순서에 동의함을 나타내는, 컴퓨터 구현 합의 방법.
  4. 제3항에 있어서,
    상기 순서에 따라 상기 하나 이상의 트랜잭션을 상기 기본 노드에 의해 유지되는 상기 블록체인의 로컬 카피 내에 패킹하는 단계를 더 포함하는, 컴퓨터 구현 합의 방법.
  5. 제1항에 있어서,
    상기 Q개 이상의 확정 메시지는 멀티캐스팅된 확정 메시지를 포함하는, 컴퓨터 구현 합의 방법.
  6. 제1항에 있어서, 상기 최소량의 합의 메시지는,
    상기 사전-준비 메시지, 및 상기 (Q-1)개 이상의 준비 메시지 중 상기 적어도 (Q-1)개만을 포함하는, 컴퓨터 구현 합의 방법.
  7. 제1항에 있어서, 상기 확정 메시지를 멀티 캐스팅하는 단계 후에,
    시스템 재시작을 수행하는 단계; 및
    저장된 상기 적어도 최소량의 합의 메시지를 로딩하는 단계를 더 포함하는, 컴퓨터 구현 합의 방법.
  8. 제1항에 있어서, 상기 적어도 최소량의 합의 메시지를 저장하는 단계 후에 그리고 상기 확정 메시지를 멀티캐스팅하는 단계 전에,
    시스템 재시작을 수행하는 단계; 및
    저장된 상기 적어도 최소량의 합의 메시지를 로딩하는 단계를 더 포함하는, 컴퓨터 구현 합의 방법.
  9. 제8항에 있어서, 상기 시스템 재시작을 수행하는 단계는,
    뷰 변경을 트리거하지 않고 상기 시스템 재시작을 수행하는 단계를 포함하는, 컴퓨터 구현 합의 방법.
  10. 블록체인을 유지하기 위한 기본 노드로서 기능하는 합의 시스템으로서,
    하나 이상의 프로세서; 및
    상기 하나 이상의 프로세서에 결합되고, 제1항 내지 제9항 중 어느 한 항에 따른 컴퓨터 구현 합의 방법을 수행하도록 상기 하나 이상의 프로세서에 의해 실행될 수 있는 명령어가 저장된 하나 이상의 컴퓨터-판독가능 메모리를 포함하는, 합의 시스템.
  11. 블록체인을 유지하기 위한 기본 노드로서 기능하는 합의 장치로서,
    제1항 내지 제9항 중 어느 한 항에 따른 컴퓨터 구현 합의 방법을 수행하기 위한 복수의 모듈을 포함하는, 합의 장치.
KR1020197028753A 2019-03-18 2019-03-18 합의 시스템 다운타임 복구 KR102230829B1 (ko)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/078549 WO2019101244A2 (en) 2019-03-18 2019-03-18 Consensus system downtime recovery

Publications (2)

Publication Number Publication Date
KR20200112634A KR20200112634A (ko) 2020-10-05
KR102230829B1 true KR102230829B1 (ko) 2021-03-23

Family

ID=66631239

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020197028753A KR102230829B1 (ko) 2019-03-18 2019-03-18 합의 시스템 다운타임 복구

Country Status (12)

Country Link
US (1) US10977135B2 (ko)
EP (1) EP3580913B1 (ko)
JP (1) JP6731123B1 (ko)
KR (1) KR102230829B1 (ko)
CN (1) CN110915185B (ko)
AU (1) AU2019203864B2 (ko)
CA (1) CA3058233C (ko)
ES (1) ES2862428T3 (ko)
PL (1) PL3580913T3 (ko)
SG (1) SG11201908544UA (ko)
TW (1) TWI729609B (ko)
WO (1) WO2019101244A2 (ko)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110445619B (zh) * 2017-03-30 2020-10-16 腾讯科技（深圳）有限公司 区块链系统、消息处理方法及存储介质
US11341122B2 (en) 2019-07-24 2022-05-24 Vmware, Inc. Byzantine fault tolerance that supports heterogeneous clients
US11334561B2 (en) 2019-07-24 2022-05-17 Vmware, Inc. Flexible byzantine fault tolerant protocol using message delay upper bound for client commit decision
CN114401150B (zh) * 2019-09-05 2023-10-20 创新先进技术有限公司 区块链网络中加入节点的方法和区块链系统
WO2021166928A1 (ja) * 2020-02-21 2021-08-26 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、制御装置、及び、プログラム
US11973857B2 (en) * 2020-04-29 2024-04-30 Kyndryl, Inc. Data archive
CN111526216B (zh) * 2020-07-03 2020-09-22 支付宝(杭州)信息技术有限公司 联盟链中的共识方法和系统
CN111813795B (zh) * 2020-08-28 2020-12-04 支付宝(杭州)信息技术有限公司 在区块链网络中确认交易的方法及装置
US11567848B2 (en) * 2020-11-30 2023-01-31 Cirrus Logic, Inc. Data transmission
US11606205B2 (en) * 2021-05-28 2023-03-14 International Business Machines Corporation Causal total order broadcast protocols using trusted execution environments
US11706320B2 (en) 2021-05-28 2023-07-18 International Business Machines Corporation Scalable leader-based total order broadcast protocol for distributed computing systems
US11665067B2 (en) 2021-05-28 2023-05-30 International Business Machines Corporation Managing reconfigurations of distributed computing systems

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170344987A1 (en) * 2016-05-24 2017-11-30 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permssioned blockchains using bloom filters and audit guarantees
CN109347804A (zh) 2018-09-19 2019-02-15 电子科技大学 一种用于区块链的拜占庭容错共识优化方法

Family Cites Families (58)

* Cited by examiner, † Cited by third party
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
US6928577B2 (en) 2002-07-29 2005-08-09 Eternal Systems, Inc. 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
EP2996385B1 (en) * 2010-09-28 2017-04-12 BlackBerry Limited Residential/enterprise network connection management and csfb scenarios
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
JP2014178793A (ja) * 2013-03-14 2014-09-25 Hitachi Ltd 情報処理システム
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
US10242027B2 (en) 2014-08-15 2019-03-26 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
US10198325B2 (en) 2016-05-24 2019-02-05 Mastercard International Incorporated Method and system for desynchronization recovery for permissioned blockchains using bloom filters
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
WO2018095540A1 (en) 2016-11-25 2018-05-31 NEC Laboratories Europe GmbH Method and system for byzantine fault - tolerance replicating of data
US11954697B2 (en) 2017-02-27 2024-04-09 Ncr Corporation Blockchain consumer ledger
CN107360206B (zh) * 2017-03-29 2020-03-27 创新先进技术有限公司 一种区块链共识方法、设备及系统
CN110445619B (zh) 2017-03-30 2020-10-16 腾讯科技（深圳）有限公司 区块链系统、消息处理方法及存储介质
US20180285217A1 (en) 2017-03-31 2018-10-04 Intel Corporation Failover response using a known good state from a distributed ledger
WO2018194368A1 (en) 2017-04-18 2018-10-25 Samsung Electronics Co., Ltd. Method and apparatus for access control in distributed blockchain-based internet of things (iot) network
US10503614B2 (en) 2017-04-21 2019-12-10 Vmware, Inc. Byzantine agreement using communications having linear complexity
CN107103098A (zh) * 2017-05-12 2017-08-29 曾建伟 一种包含智能合约的区块链网式数据库及工作方法
US11626993B2 (en) 2017-05-22 2023-04-11 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
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 平安科技（深圳）有限公司 基于以太坊的区块链系统和交易数据处理方法
JP7038204B2 (ja) 2017-10-31 2022-03-17 アビニシオ テクノロジー エルエルシー 永続性レベル表示器を使用してコンピュータクラスタを管理すること
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
CN108108967B (zh) * 2017-12-29 2020-10-16 山大地纬软件股份有限公司 面向复杂数字资产的多阶段pbft共识系统及方法
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 南京邮电大学 基于动态授权和网络环境感知的区块链自适应共识方法
CN109345386B (zh) * 2018-08-31 2020-04-14 阿里巴巴集团控股有限公司 基于区块链的交易共识处理方法及装置、电子设备
CN109246122A (zh) * 2018-09-29 2019-01-18 上海海事大学 一种基于谣言传播协议的拜占庭容错区块链生成方法
CN109327959A (zh) * 2018-10-31 2019-02-12 信利光电股份有限公司 一种pcb连板结构
CN109327459B (zh) 2018-11-12 2020-12-01 崔晓晖 一种联盟区块链网络的共识方法
MY189985A (en) 2018-12-13 2022-03-22 Advanced New Technologies Co Ltd Performing a change of primary node in a distributed system
SG11201908387SA (en) 2019-03-18 2019-10-30 Alibaba Group Holding Ltd Consensus system downtime recovery

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170344987A1 (en) * 2016-05-24 2017-11-30 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permssioned blockchains using bloom filters and audit guarantees
CN109347804A (zh) 2018-09-19 2019-02-15 电子科技大学 一种用于区块链的拜占庭容错共识优化方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Eleftherios Kokoris Kogias et al, Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing, 25th USENIX Security Symposium, 2016년*
MOHAMMAD JAVAD AMIRI et al, ParBlockchain: Leveraging Transaction Parallelism in Permissioned Blockchain Systems, 2019년 2월*

Also Published As

Publication number Publication date
AU2019203864A1 (en) 2019-05-31
KR20200112634A (ko) 2020-10-05
EP3580913A4 (en) 2019-12-25
AU2019203864B2 (en) 2021-01-21
JP6731123B1 (ja) 2020-07-29
WO2019101244A2 (en) 2019-05-31
ES2862428T3 (es) 2021-10-07
CN110915185A (zh) 2020-03-24
EP3580913B1 (en) 2021-01-20
TWI729609B (zh) 2021-06-01
CA3058233A1 (en) 2019-05-31
TW202037122A (zh) 2020-10-01
WO2019101244A3 (en) 2019-09-12
SG11201908544UA (en) 2019-10-30
JP2020522725A (ja) 2020-07-30
PL3580913T3 (pl) 2021-06-28
US10977135B2 (en) 2021-04-13
CN110915185B (zh) 2021-08-17
EP3580913A2 (en) 2019-12-18
US20200379852A1 (en) 2020-12-03
CA3058233C (en) 2023-03-07

Similar Documents

Publication Publication Date Title
KR102365793B1 (ko) 합의 시스템 다운타임 복구
KR102230829B1 (ko) 합의 시스템 다운타임 복구
US10671599B2 (en) Consensus system and method
KR102170345B1 (ko) 뷰 변경 프로토콜을 종료하기 위한 시스템 및 방법
TWI717135B (zh) 用於結束視域變換協定的系統和方法
US10938750B2 (en) Consensus system downtime recovery
AU2019101612A4 (en) Consensus system downtime recovery
AU2019101610A4 (en) Consensus system downtime recovery

Legal Events

Date Code Title Description
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant