KR102603880B1 - 블록 합의 방법 및 트랜잭션 상태 관리 방법 - Google Patents
블록 합의 방법 및 트랜잭션 상태 관리 방법 Download PDFInfo
- Publication number
- KR102603880B1 KR102603880B1 KR1020210002482A KR20210002482A KR102603880B1 KR 102603880 B1 KR102603880 B1 KR 102603880B1 KR 1020210002482 A KR1020210002482 A KR 1020210002482A KR 20210002482 A KR20210002482 A KR 20210002482A KR 102603880 B1 KR102603880 B1 KR 102603880B1
- Authority
- KR
- South Korea
- Prior art keywords
- transaction
- node
- nodes
- block
- message
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 81
- 238000010586 diagram Methods 0.000 description 23
- 230000008569 process Effects 0.000 description 23
- 238000007726 management method Methods 0.000 description 11
- 230000004044 response Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000000644 propagated effect Effects 0.000 description 4
- 230000001174 ascending effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000014509 gene expression Effects 0.000 description 2
- CVOFKRWYWCSDMA-UHFFFAOYSA-N 2-chloro-n-(2,6-diethylphenyl)-n-(methoxymethyl)acetamide;2,6-dinitro-n,n-dipropyl-4-(trifluoromethyl)aniline Chemical compound CCC1=CC=CC(CC)=C1N(COC)C(=O)CCl.CCCN(CCC)C1=C([N+]([O-])=O)C=C(C(F)(F)F)C=C1[N+]([O-])=O CVOFKRWYWCSDMA-UHFFFAOYSA-N 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012797 qualification Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
- H04L67/1068—Discovery involving direct consultation or announcement among potential requesting and potential source peers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3827—Use of message hashing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
-
- 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/3242—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 keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Power Engineering (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
컴퓨팅 장치의 블록 합의 방법이 제공된다. 컴퓨팅 장치는 복수의 노드 각각으로부터 트랜잭션 해시를 포함하는 위임 요청 메시지를 수신하고, 상기 위임 요청 메시지에 기초해서 트랜잭션 해시를 포함하는 후보 블록을 만들고, 상기 복수의 노드로 상기 후보 블록을 포함하는 준비 메시지를 전송한다. 컴퓨팅 장치는 복수의 노드로부터 후보 블록의 유효성에 동의하는 증거를 포함하는 커밋 메시지를 수신하고, 커밋 메시지에 기초해서 확정한 최종 블록을 포함하는 답변 메시지를 전송한다.
Description
본 발명은 블록 합의 방법 및 트랜잭션 상태 관리 방법에 관한 것이다.
비잔틴 오류 감내(Byzantine Fault Tolerance, BFT) 계열의 분산 합의(distributed consensus) 방식에서는 전체 노드 중 선택된 (3f+1)개(f는 비잔틴 노드의 개수)의 합의체 중에서 (2f+1)개의 노드가 동의한 트랜잭션이 블록에 포함된다. 대표적인 BFT 계열의 분산합의 방식인 알고랜드(Algorand)에서는 검증 가능 난수 함수(Verifiable Random Function, VRF)을 이용하여 라운드마다 합의체(또는 검증자) 노드(committee)를 선정하고 선정된 합의체 노드들은 후보 블록을 주고받음으로써 합의를 진행한다. 그러나 합의 과정에서 주고받는 후보 블록 크기의 대부분은 트랜잭션이 차지하고 있기 때문에 트랜잭션의 수가 많아지거나 크기가 커짐에 따라 후보 블록 크기는 커지게 되고 이는 결국 블록 합의 성능 저하를 야기한다.
그러므로 합의 과정 중에 트랜잭션의 크기가 커지거나 트랜잭션의 수가 많아지더라도 합의 성능에 미치는 영향을 줄이는 방법이 필요하다.
본 발명이 이루고자 하는 과제는 노드 간의 주고 받는 메시지의 크기를 줄일 수 있는 블록 합의 방법 및 트랜잭션 상태 관리 방법을 제공하는 것이다.
본 발명의 한 실시예에 따르면, 컴퓨팅 장치의 블록 합의 방법이 제공된다. 상기 블록 합의 방법은 복수의 노드 각각으로부터 트랜잭션 해시를 포함하는 위임 요청(delegate request) 메시지를 수신하는 단계, 상기 위임 요청 메시지에 기초해서 트랜잭션 해시를 포함하는 후보 블록을 만들고, 상기 복수의 노드로 상기 후보 블록을 포함하는 준비(prepare) 메시지를 전송하는 단계, 상기 복수의 노드로부터 상기 후보 블록의 유효성에 동의하는 증거를 포함하는 커밋(commit) 메시지를 수신하는 단계, 그리고 상기 커밋 메시지에 기초해서 확정한 최종 블록을 포함하는 답변(reply) 메시지를 전송하는 단계를 포함한다.
어떤 실시예에서, 상기 위임 요청 메시지는 상기 위임 요청 메시지에 포함된 상기 트랜잭션 해시에 해당하는 원본 트랜잭션을 포함하지 않으며, 상기 준비 메시지는 상기 준비 메시지에 포함된 상기 트랜잭션 해시에 해당하는 원본 트랜잭션을 포함하지 않을 수 있다.
어떤 실시예에서, 각 노드로부터 수신한 상기 위임 요청 메시지에 포함된 상기 트랜잭션 해시는 해당 노드가 상기 후보 블록에 추가하기를 원하는 트랜잭션의 트랜잭션 해시를 포함할 수 있다.
어떤 실시예에서, 상기 준비 메시지를 전송하는 단계는 상기 위임 요청 메시지에 포함된 상기 트랜잭션 해시에 기초해서 상기 복수의 노드 중 소정 수의 노드가 동의한 트랜잭션 해시를 포함하는 상기 후보 블록을 만드는 단계를 포함할 수 있다.
어떤 실시예에서, 상기 복수의 노드의 수가 (2f+1)인 경우, 상기 소정 수는 (f+1)일 수 있다.
어떤 실시예에서, 상기 준비 메시지를 전송하는 단계는 상기 복수의 노드 중에서 상기 후보 블록에 포함된 트랜잭션 해시에 대응하는 원본 트랜잭션을 요청할 노드를 선택하는 단계, 그리고 상기 선택한 노드에 상기 원본 트랜잭션을 요청하는 단계를 포함할 수 있다.
어떤 실시예에서, 상기 준비 메시지를 전송하는 단계는 상기 복수의 노드 각각의 보유 트랜잭션 수를 계산하는 단계를 더 포함할 수 있다. 이 경우, 상기 원본 트랜잭션을 요청할 노드를 선택하는 단계는 상기 보유 트랜잭션 수가 적은 노드부터 차례로 상기 원본 트랜잭션을 요청할 노드를 선택하는 단계를 포함할 수 있다.
어떤 실시예에서, 상기 원본 트랜잭션을 요청하는 단계는 상기 선택한 노드에 K개의 원본 트랜잭션을 요청하는 단계를 포함할 수 있다.
어떤 실시예에서, 서로 다른 노드에 요청되는 상기 원본 트랜잭션은 중복되지 않을 수 있다.
어떤 실시예에서, 상기 커밋 메시지를 수신하는 단계는, 각 노드로부터, 상기 후보 블록에 포함된 트랜잭션 해시 중에서 해당 노드에게 요청된 트랜잭션 해시에 해당하는 원본 트랜잭션을 수신하는 단계를 포함할 수 있다.
어떤 실시예에서, 상기 답변 메시지를 전송하는 단계는, 상기 복수의 노드 중에서 어떤 노드가 상기 위임 요청 메시지를 통해 어떤 트랜잭션의 트랜잭션 해시를 전송하였는지를 지시하는 정보를 전송하는 단계를 더 포함할 수 있다.
본 발명의 다른 실시예에 따르면, 분산 합의에서 컴퓨팅 장치의 트랜잭션 상태 관리 방법이 제공된다. 상기 트랜잭션 상태 관리 방법은 제1 트랜잭션의 해시를 포함하는 블록을 수신하는 단계, 메모리 풀에 상기 제1 트랜잭션이 존재하지 않은 경우, 상기 제1 트랜잭션의 상태를 해시 유일(Hash-only) 상태로 설정하는 단계, 그리고 상기 제1 트랜잭션의 원본 트랜잭션을 요청하여서 얻은 경우, 상기 제1 트랜잭션의 상태를 해시 유일 상태에서 상기 제1 트랜잭션의 실행 준비가 완료된 준비 완료(Ready) 상태로 변경하는 단계를 포함한다.
어떤 실시예에서, 상기 트랜잭션 상태 관리 방법은 상기 준비 완료 상태에서 상기 제1 트랜잭션을 실행하는 단계, 그리고 상기 제1 트랜잭션을 실행하는 경우, 상기 제1 트랜잭션의 상태를 상기 준비 완료 상태에서 실행 완료(Spent) 상태로 변경하는 단계를 더 포함할 수 있다.
어떤 실시예에서, 상기 트랜잭션 상태 관리 방법은 제2 트랜잭션을 실행하기 전에 상기 제2 트랜잭션의 부모 트랜잭션이 실행되었는지를 확인하는 단계를 더 포함할 수 있다.
어떤 실시예에서, 상기 트랜잭션 상태 관리 방법은, 상기 제2 트랜잭션의 부모 트랜잭션이 모두 실행된 경우, 상기 제2 트랜잭션을 실행하는 단계를 더 포함할 수 있다.
어떤 실시예에서, 상기 트랜잭션 상태 관리 방법은, 상기 부모 트랜잭션 중에서 적어도 일부가 실행되지 않은 경우, 실행되지 않은 부모 트랜잭션의 상태를 확인하는 단계를 더 포함할 수 있다.
어떤 실시예에서, 상기 트랜잭션 상태 관리 방법은, 상기 실행되지 않은 부모 트랜잭션 중에서 상기 준비 완료 상태의 부모 트랜잭션이 존재하는 경우, 상기 준비 완료 상태의 부모 트랜잭션의 실행을 대기하는 단계를 더 포함할 수 있다.
어떤 실시예에서, 상기 트랜잭션 상태 관리 방법은, 상기 실행되지 않은 부모 트랜잭션 중에서 상기 해시 유일 상태의 부모 트랜잭션이 존재하는 경우, 상기 해시 유일 상태의 부모 트랜잭션의 원본 트랜잭션을 요청하는 단계를 더 포함할 수 있다.
어떤 실시예에서, 상기 트랜잭션 상태 관리 방법은, 상기 실행되지 않은 부모 트랜잭션 중에서 대기(Waiting) 상태의 부모 트랜잭션이 존재하는 경우, 상기 대기 상태의 부모 트랜잭션이 합의할 블록에 추가되기를 대기하는 단계를 더 포함할 수 있다.
본 발명의 또 다른 실시예에 따르면, 적어도 하나의 명령어를 저장하는 메모리, 그리고 상기 명령어를 실행하는 프로세서를 포함하는 컴퓨팅 장치가 제공된다. 상기 명령어를 실행함으로써, 상기 프로세서는 복수의 노드 각각으로부터 트랜잭션 해시를 포함하는 위임 요청(delegate request) 메시지를 수신하고, 상기 위임 요청 메시지에 기초해서 트랜잭션 해시를 포함하는 후보 블록을 만들고, 상기 복수의 노드로 상기 후보 블록을 포함하는 준비(prepare) 메시지를 전송하고, 상기 복수의 노드로부터 상기 후보 블록의 유효성에 동의하는 증거를 포함하는 커밋(commit) 메시지를 수신하고, 상기 커밋 메시지에 기초해서 확정한 최종 블록을 포함하는 답변(reply) 메시지를 전송한다.
본 발명의 한 실시예에 따르면, 가변적이고 크기가 큰 트랜잭션 대신에 고정된 매운 작은 크기의 트랜잭션 해시를 이용하여 블록 합의를 진행하므로, 노드 간의 주고받는 합의 메시지의 크기를 줄일 수 있다.
도 1은 본 발명의 한 실시예에 따른 블록 합의 방법의 한 예를 나타내는 도면이다.
도 2는 본 발명의 다른 실시예에 따른 블록 합의 방법의 한 예를 나타내는 도면이다.
도 3은 원본 트랜잭션을 포함하는 데이터 구조의 한 예를 나타내는 도면이다.
도 4는 본 발명의 다른 실시예에 따른 트랜잭션 해시 데이터 구조의 한 예를 나타내는 도면이다.
도 5는 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 트랜잭션 요청 대상 선택 과정의 한 예를 설명하는 도면이다.
도 6은 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 트랜잭션 요청 대상 선택 과정의 한 예를 나타내는 도면이다.
도 7은 본 발명의 또 다른 실시예에 따른 트랜잭션 해시 기반 블록 합의 방법의 한 예를 나타내는 도면이다.
도 8은 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 트랜잭션 스테이트 머신 다이어그램의 한 예를 나타내는 도면이다.
도 9는 본 발명의 또 다른 실시예에 따른 트랜잭션 해시 데이터 구조의 한 예를 나타내는 도면이다.
도 10은 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 메모리 풀에서 트랜잭션을 가져오는 방법의 한 예를 나타내는 흐름도이다.
도 11은 본 발명의 한 실시예에 따른 컴퓨팅 장치의 한 예를 나타내는 도면이다.
도 2는 본 발명의 다른 실시예에 따른 블록 합의 방법의 한 예를 나타내는 도면이다.
도 3은 원본 트랜잭션을 포함하는 데이터 구조의 한 예를 나타내는 도면이다.
도 4는 본 발명의 다른 실시예에 따른 트랜잭션 해시 데이터 구조의 한 예를 나타내는 도면이다.
도 5는 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 트랜잭션 요청 대상 선택 과정의 한 예를 설명하는 도면이다.
도 6은 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 트랜잭션 요청 대상 선택 과정의 한 예를 나타내는 도면이다.
도 7은 본 발명의 또 다른 실시예에 따른 트랜잭션 해시 기반 블록 합의 방법의 한 예를 나타내는 도면이다.
도 8은 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 트랜잭션 스테이트 머신 다이어그램의 한 예를 나타내는 도면이다.
도 9는 본 발명의 또 다른 실시예에 따른 트랜잭션 해시 데이터 구조의 한 예를 나타내는 도면이다.
도 10은 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 메모리 풀에서 트랜잭션을 가져오는 방법의 한 예를 나타내는 흐름도이다.
도 11은 본 발명의 한 실시예에 따른 컴퓨팅 장치의 한 예를 나타내는 도면이다.
아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
아래 설명에서 단수로 기재된 표현은 "하나" 또는 "단일" 등의 명시적인 표현을 사용하지 않은 이상, 단수 또는 복수로 해석될 수 있다.
도면을 참고하여 설명한 흐름도에서, 동작 순서는 변경될 수 있고, 여러 동작들이 병합되거나, 어느 동작이 분할될 수 있고, 특정 동작은 수행되지 않을 수 있다.
도 1은 본 발명의 한 실시예에 따른 블록 합의 방법의 한 예를 나타내는 도면이다. 도 1에서는 설명의 편의상 하나의 클라이언트와 네 개의 노드만을 도시하였으며, 도 1에서 화살표는 메시지의 전달을 나타낸다. 어떤 실시예에서, 각 노드는 컴퓨팅 장치를 포함할 수 있다.
도 1을 참고하면, 클라이언트는 블록체인에 존재하는 모든 합의 참여가 가능한 노드(참여 노드)들에게 요청(request) 메시지를 전파한다. 그리고 참여 노드 중에서 이번 블록에 대한 합의 참여 자격을 획득한 (3f+1)개의 합의체(congress) 노드는 위임 요청(delegate request), 준비(prepare), 커밋(commit) 및 답변(reply)의 네 단계 합의 과정을 진행하여 어떤 트랜잭션을 블록에 실을 지를 합의하고 최종 블록(답변된 블록(replied block) 또는 커밋된 블록(committed block))을 클라이언트와 모든 노드에게 전파한다. 세부적인 블록 합의 과정은 다음과 같다.
각 참여 노드는 클라이언트로부터 받은 트랜잭션의 유효성을 검증하고 검증된 트랜잭션을 자신의 메모리 풀(memory pool, mempool)에 저장한다. 만약 참여 노드가 합의체 노드(예를 들면, f=1인 경우로, 4(=3f+1)개의 노드(Node A, Node B, Node C, Node D))인 경우에, 해당 노드는 메모리 풀에서 다음 블록에 싣기 원하는 일정 수의 트랜잭션을 꺼내고, 트랜잭션을 포함하는 위임 요청 메시지를 기본 노드(primary node)(예를 들면, Node A)에게 전달한다. 이 경우, 기본 노드는 자기 자신에 위임 요청 메시지를 전달하거나 위임 요청 메시지를 로컬로 처리할 수 있다. 위임 요청 메시지는 참여 노드의 서명을 더 포함할 수 있다.
한 실시예에서, 기본 노드는 먼저 도착한 (2f+1)개의 위임 요청 메시지(즉, (2f+1)개의 노드(예를 들면, Node A, Node B, Node C)에서 도착한 위임 요청 메시지)에 포함되어 있는 트랜잭션들 중에서 (f+1)개의 노드가 동의한 트랜잭션만을 선택하여 후보 블록(prepared block)을 만들 수 있다. 다른 실시예에서, 기본 노드는 일정 시간 동안 도착한 위임 요청 메시지 중에서 소정의 기준에 따라 우선순위가 높은 (2f+1)개의 위임 요청 메시지에 포함되어 있는 트랜잭션들 중에서 (f+1)개의 노드가 동의한 트랜잭션만을 선택하여 후보 블록을 만들 수 있다. 소정의 기준은 예를 들면 지분 또는 해시 값에 따른 기준을 포함할 수 있다. 또한, 기본 노드는 어떤 노드가 어떤 트랜잭션에 동의하였는지(어떤 노드가 어떤 트랜잭션을 제출하였는지)에 대한 증거를 만들어 이를 후보 블록과 함께 준비 메시지로 위임 요청 메시지를 전송하였던 노드 중 선택된 (2f+1)개의 노드(예를 들면, Node A, Node B, Node C)에게 전송한다. 이 때의 (2f+1)개 노드를 위원회(committee) 노드라고 한다. 어떤 실시예에서, 증거는 트랜잭션을 제출한 위원회 노드의 식별자(identifier, ID)를 키(key)로 가지고 해당 노드가 전달한 트랜잭션의 ID를 값(value)으로 가지는 비트맵("트랜잭션 비트맵"이라 한다)으로 제공될 수 있다. 위임 요청 메시지는 기본 노드의 서명을 더 포함할 수 있다.
각 위원회 노드(예를 들면, Node A, Node B, Node C)는 후보 블록의 유효성을 검증하여 동의하는 경우, 이에 동의한다는 증거인 서명을 포함한 커밋 메시지를 기본 노드에게 전송한다. 기본 노드는 후보 블록에 포함된 모든 트랜잭션을 이미 가지고 있으므로, 각 위원회 노드가 전송하는 커밋 메시지에는 트랜잭션이 포함되지 않는다. 마지막으로 기본 노드는 (2f+1)개의 모든 위원회 노드가 후보 블록에 동의한 경우 최종 블록을 확정 짓고, 이를 블록체인 네트워크 내의 모든 노드와 트랜잭션을 요청한 클라이언트에게 답변 메시지로 전달한다. 답변 메시지는 기본 노드의 서명을 더 포함할 수 있다.
도 1을 참고로 하여 설명한 실시예에서는 위임 요청 및 준비 단계에서 원본 트랜잭션을 포함하는 위임 요청 메시지와 준비 메시지가 전송되므로, 트랜잭션의 크기가 커짐에 따라 전달되는 메시지 양에 따른 부하가 증가할 수 있다. 아래에서는 전달되는 메시지 양을 줄일 수 있는 실시예에 대해서 설명한다.
도 2는 본 발명의 다른 실시예에 따른 블록 합의 방법의 한 예를 나타내는 도면이다. 도 2에서는 설명의 편의상 하나의 클라이언트와 네 개의 노드만을 도시하였으며, 도 2에서 화살표는 메시지의 전달을 나타낸다.
도 2를 참고하면, 먼저 요청 단계에서 클라이언트는 블록체인에 존재하는 모든 합의 참여가 가능한 노드(참여 노드)들에게 요청(request) 메시지를 전파한다. 도 1에서 설명한 것과 유사하게, 참여 노드 중에서 이번 블록에 대한 합의 참여 자격을 획득한 (3f+1)개의 합의체 노드는 위임 요청, 준비, 커밋 및 답변의 네 단계 합의 과정을 진행한다. 여기서, f는 자연수이다.
위임 요청 단계에서, 각 참여 노드는 요청 메시지를 통해 클라이언트로부터 받은 트랜잭션의 유효성을 검증하고 검증된 트랜잭션을 자신의 메모리 풀에 저장한다. 합의체 노드(예를 들면, Node A, Node B, Node C, Node D)는 위임 요청 메시지를 통해 합의할 블록에 담을 트랜잭션을 기본 노드(예를 들면, Node A)에게 제안한다. 이 경우, 합의체 노드는 메모리 풀에서 다음 블록(후보 블록)에 추가하기를 원하는 일정 수의 트랜잭션에 꺼내고, 해당 트랜잭션을 해시(hash)하고, 트랜잭션 해시를 위임 요청 메시지에 실어서 기본 노드로 전달한다. 위임 요청 메시지는 합의체 노드의 서명을 더 포함할 수 있다. 어떤 실시예에서, 트랜잭션을 해시 함수에 입력하여서 고정된 크기의 데이터를 생성함으로써 트랜잭션을 해시할 수 있다. 이 경우, 트랜잭션 해시는 고정된 크기의 데이터에 해당한다.
준비 단계에서, 기본 노드는 (2f+1)개의 노드(예를 들면, Node A, Node B, Node C), 즉 위원회 노드로부터 받은 위임 요청 메시지에 포함된 트랜잭션 해시 중에서 (f+1)개의 노드가 동의한 트랜잭션 해시를 찾아 후보 블록(prepared block)을 만든다. 즉, 후보 블록은 (f+1)개의 노드가 동의한 트랜잭션 해시를 포함한다. 후보 블록을 만들 때, 기본 노드는 트랜잭션의 내용을 보는 것이 아니라, 특정 트랜잭션에 대해 (f+1)개의 노드가 동의했는지를 판단하므로, 기본 노드는 원본 트랜잭션이 아닌 트랜잭션 해시만을 사용하여 후보 블록을 만들 수 있다. 어떤 실시예에서, (2f+1)개의 위원회 노드로부터 받은 위임 요청 메시지는 (3f+1)개의 합의체 노드에서 전송되는 위임 요청 메시지 중에서 먼저 도착한 (2f+1)개의 위임 요청 메시지일 수 있다. 다음, 기본 노드는 트랜잭션 해시로 구성된 후보 블록을 포함하는 준비 메시지를 (2f+1)개의 위원회 노드(예를 들면, Node A, Node B, Node C)에게 전달한다. 본 예시에서 (2f+1)개의 위원회 노드는 기본 노드에 위임 요청 메시지를 먼저 전달한 노드이다. 또한, 기본 노드는 어떤 노드가 어떤 트랜잭션에 동의하였는지(어떤 노드가 어떤 트랜잭션을 제출하였는지)에 대한 증거를 만들어 이를 후보 블록과 함께 준비 메시지로 전달할 수 있다. 어떤 실시예에서, 증거는 트랜잭션을 제출한 위원회 노드의 ID를 키로 가지고 해당 노드가 전달한 트랜잭션 해시의 ID를 값으로 가지는 트랜잭션 비트맵으로 제공될 수 있다. 또한, 기본 노드는 후보 블록을 구성하는 트랜잭션 해시 중에서 자신이 갖고 있지 않은 원본 트랜잭션을 획득하기 위해 원본 트랜잭션 요청 메시지를 위원회 노드들에게 전송할 수 있다. 어떤 실시예에서, 기본 노드는 각 위원회 노드에게 가지고 있는 모든 트랜잭션을 요청하는 것이 아니라, 각 노드로부터 전송 받을 트랜잭션을 지정하여 요청함으로써, 각 노드가 원본 트랜잭션 데이터를 중복하여 전송하는 것을 막을 수 있다. 이와 같이, 기본 노드는 각 위원회 노드에게 위임 준비 메시지를 전송할 때 후보 블록과 증거(트랜잭션 비트맵)뿐만 아니라 원본 트랜잭션을 요청하기 위한 요청을 함께 전송할 수 있다. 또한, 위임 준비 메시지는 기본 노드의 서명을 더 포함할 수 있다.
다음, 커밋 단계에서, 각 위원회 노드(예를 들면, Node A, Node B, Node C)는 전달받은 후보 블록의 유효성을 검증하여 동의하는 경우, 이에 동의한다는 증거인 서명을 포함한 커밋 메시지를 기본 노드에게 전송한다. 이 경우, 각 노드는 전달받은 후보 블록에 포함된 트랜잭션 해시 중에서 요청 받은 원본 트랜잭션(예를 들면, 트랜잭션 비트맵에 의해 지정된 트랜잭션)을 커밋 메시지를 통해서 기본 노드에게 전달할 수 있다.
마지막으로, 답변 단계에서, 기본 노드는 (2f+1)개의 모든 위원회 노드가 후보 블록에 동의한 경우 최종 블록을 확정 짓고 이를 블록체인 네트워크 내의 모든 노드와 트랜잭션을 요청한 클라이언트에게 전달한다.
이상에서 설명한 실시예에 따르면, 위임 요청 및 준비의 단계에서 원본 트랜잭션이 아닌 트랜잭션 해시만을 전달한다. 따라서, 트랜잭션의 크기가 커지더라도 항상 동일한 크기의 해시 데이터를 전달할 수 있으므로, 합의 메시지의 크기가 상대적으로 매우 줄어들 수 있다.
도 3은 원본 트랜잭션을 포함하는 데이터 구조의 한 예를 나타내는 도면이며, 도 4는 본 발명의 다른 실시예에 따른 트랜잭션 해시 데이터 구조의 한 예를 나타내는 도면이다.
도 3에 도시한 것처럼, 도 1을 참고로 하여 설명한 실시예에서 사용하는 메시지는 원본 트랜잭션(payload)을 포함하는 데이터 구조(앞으로 "원본 트랜잭션 데이터 구조"라 한다)를 사용할 수 있다. 이와는 달리, 도 4에 도시한 것처럼, 도 2를 참고로 하여 설명한 실시예에서 사용하는 메시지는 원본 트랜잭션이 제거된 데이터 구조(앞으로 "트랜잭션 해시 데이터 구조"라 한다)를 사용할 수 있다.
도 3 및 도 4에 도시한 것처럼, 어떤 실시예에서, 트랜잭션 해시 데이터 구조에서는 원본 트랜잭션 데이터 구조의 송신 노드 식별자(TxID), 서명자의 공개키(SignerPubKey), 트랜잭션 해시(PayloadHash) 및 서명(Signature)와 같은 트랜잭션의 헤더가 유지되지만, 원본 트랜잭션에 해당하는 바디, 즉 페이로드 부분은 제거될 수 있다.
도 1을 참고로 하여 설명한 실시예에서는, 기본 노드가 특정 트랜잭션을 이미 가지고 있더라도 합의체 노드들은 그 사실을 모르기 때문에, 자신이 가지고 있는 트랜잭션을 모두 기본 노드에게 전달한다. 또한, 각 합의체 노드는 다른 합의체 노드가 기본 노드에게 어떤 트랜잭션을 제출할지 모르기 때문에 최대 (3f+1)개의 동일한 원본 트랜잭션이 중복되어 전달될 수 있다. 반면, 도 2를 참고로 하여 설명한 실시예에서는 위임 요청 메시지로부터 각 노드가 어떤 트랜잭션을 가지고 있는지 파악한 기본 노드는 얻고자 하는 원본 트랜잭션을 특정 노드에 지정하여서 요청할 수 있다. 앞으로, 이 과정을 "트랜잭션 요청 대상 선택" 과정이라 한다. 이와 같이, 기본 노드는 얻고자 하는 원본 트랜잭션만 특정 노드를 지정하여서 요청하므로, 기본 노드가 가지고 있는 트랜잭션은 전달되지 않고, 서로 다른 노드에서 원본 트랜잭션이 중복되어서 전달되지도 않을 수 있다. 따라서, 도 1에서 설명한 실시예와 비교할 때, 비록 커밋 단계에서 원본 트랜잭션이 기본 노드로 전달되더라도, 기본 노드가 가지고 있지 않은 원본 트랜잭션이 중복되어 전달되지 않고, 또한 위임 요청 및 준비 단계에서 원본 트랜잭션이 전달되지 않으므로, 전달되는 메시지 양을 크게 줄일 수 있다.
도 5는 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 트랜잭션 요청 대상 선택 과정의 한 예를 설명하는 도면이다.
도 5를 참고하면, 트랜잭션 요청 대상 선택을 위해, 트랜잭션 비트맵을 나타내는 TxMap, 트랜잭션 해시의 개수를 나타내는 TxCounts 및 트랜잭션의 요청 여부를 나타내는 TxRequestMap을 정의할 수 있다. 예를 들면, TxMap은 트랜잭션을 제출한 위원회 노드의 ID(CommitteeNodeID)를 키로 가지고 해당 노드가 전달한 트랜잭션 해시의 ID들(TxIDs)을 값으로 가질 수 있다. 이에 따라, TxMap은 어떤 노드가 어떤 트랜잭션 해시를 전달했는지를 지시할 수 있다. TxCounts는 트랜잭션 해시를 전달한 위원회 노드의 ID(CommitteeNodeID)를 키로 가지고 해당 노드가 전달한 트랜잭션 해시의 개수에 해당하는 정수 값(int)을 값으로 가질 수 있다. 이에 따라, TxCounts는 후보 블록에 포함된 트랜잭션 해시 중에서 각 위원회 노드가 전달한 트랜잭션 해시의 개수를 지시할 수 있다. 어떤 실시예에서, TxCounts는 각 위원회 노드가 가지고 있는 트랜잭션의 개수 중에서 기본 노드가 이미 가지고 있는 트랜잭션을 제외한 개수를 지시할 수 있다. TxRequestMap은 후보 블록에 포함되어 있지만 기본 노드가 가지고 있지 않은 트랜잭션들에 대해 각 트랜잭션을 요청하였는지를 지시할 수 있다. TxRequestMap는 트랜잭션 해시의 ID를 키로 가지고, 참/거짓(Boolean)을 값으로 가질 수 있다. 예를 들면, TxRequestMap는 각 트랜잭션 해시 ID에 대해서 해당 트랜잭션을 이미 요청한 경우 참(true)을 가지고 아직 요청하지 않은 경우 거짓(false)를 가질 수 있다. 이와 같이, TxRequestMap은 요청 완료한 트랜잭션을 표시함으로써 특정한 노드에 대해 중복으로 요청하는 것을 방지할 수 있다.
어떤 실시예에서, 트랜잭션 요청 대상 선택 과정은 크게 노드별 트랜잭션 개수 카운트 단계와 노드별 트랜잭션 요청 단계로 나눌 수 있다.
노드별 트랜잭션 개수 카운트 단계는 후보 블록에 포함된 트랜잭션에 대해서, 각 위원회 노드가 가지고 있는 트랜잭션의 개수를 계산하는 과정이다. 어떤 실시예에서, 기본 노드는 TxMap을 이용하여 각 노드가 가지고 있는 트랜잭션의 개수(TxCounts)를 계산할 수 있다. 이 때, 기본 노드가 이미 가지고 있는 트랜잭션은 요청할 필요가 없으므로 해당 트랜잭션은 제외하여 개수를 카운트할 수 있다. 예를 들면, 도 5에 도시한 것처럼, 기본 노드는 각 노드(nodeID)에 대해서 트랜잭션의 개수(TxCounts[nodeID])을 계산할 수 있다. 이를 위해, 기본 노드는 대상 노드(nodeID)의 각 트랜잭션 해시의 ID(txID)에 대해서 자신의 TxMap(TxMap[MyNodeID])에 해당 txID가 포함되어 있는지를 판단하고(TxMap[MyNodeID].not_contains(txID)), 포함되어 있지 않으면 해당 노드의 트랜잭션의 개수(TxCounts[nodeID])를 1 증가시킬 수 있다. 이러한 과정을 통해 기본 노드는 각 노드의 트랜잭션의 개수를 계산할 수 있다.
노드별 트랜잭션 요청 단계는 트랜잭션을 가지고 있는 노드에게 원본 트랜잭션을 요구하는 과정이다. 어떤 실시예에서, 기본 노드는 TxCounts에 기초해서 가지고 있는 트랜잭션의 개수가 적은 노드부터 오름차순으로 원본 트랜잭션을 요청할 수 있다. 이와 같이, 트랜잭션을 여러 노드들에게 요청함으로써 트랜잭션 전송을 위한 트래픽이 특정 노드에게 몰리지 않고 여러 노드에게 분산될 수 있다. 어떤 실시예에서, 노드당 한번에 최대 몇 개의 트랜잭션(K)을 요구할지는 구현에 따라 변경될 수 있다. 한 실시예에서, 노드당 우선 트랜잭션 1개씩 요청하고, 요청하지 못한 트랜잭션에 대해 다시 노드를 선택하여 요청하는 과정을 반복할 수 있다(즉, K=1). 이러한 방법은 트랜잭션 전송 트래픽 분산에 효과적이지만, 트랜잭션 요청 대상 선택 과정에 상대적으로 많은 시간이 지연될 수 있다. 다른 실시예에서, 한 노드에 대해 요청하는 트랜잭션의 개수에 제한이 없을 수 있다(즉, K=무한대). 이러한 방법은 각 노드가 가지고 있는 트랜잭션을 모두 요구하므로 K를 1로 설정한 방법보다 분산 효과가 적게 나타날 수 있다. 그렇다 하더라도 트랜잭션이 적은 노드부터 순서대로 요청하기 때문에 트래픽을 분산할 수는 있다. 또한 어떤 실시예에서, 네트워크 실패 상황을 고려하여 각 트랜잭션을 여러 개(P)의 노드에게 요청할 수 있으며, P값과 K값은 시스템 환경과 구현에 따라 변경될 수 있다.
예를 들면, P를 1로 설정하고 K를 1 이상의 정수값으로 설정한 경우, 도 5에 도시한 것처럼, 기본 노드는 먼저 가지고 있는 트랜잭션의 개수가 적은 노드부터 오름차순으로 정렬할 수 있다(TxCounts.sort_ascending_by_value()). 다음, 기본 노드는 요청하지 않은 트랜잭션이 존재하는 동안(TxRequestMap.values.contains(false)), 트랜잭션의 개수(TxCounts)가 적은 노드(nodeID)부터 차례로 트랜잭션을 요청하는 과정을 반복할 수 있다. 먼저, 기본 노드는 대상 노드(nodeID)가 가지고 있는 트랜잭션 해시의 ID들을 설정하고(txIDs = TxMap[nodeID]), 요청할 트랜잭션의 트랜잭션 해시 ID 리스트(reqTxIDs)를 초기화할 수 있다(reqTxIDs[] = []). 다음, 기본 노드는 대상 노드에서 요청할 K개의 트랜잭션 해시를 선택할 수 있다. 이를 위해, 기본 노드는 자신이 가지고 있지 않으면서(TxMap[MyNodeID].not_contains(txID)) 아직 요청하지 않은(TxRequestMap[txID] == false) 트랜잭션 해시의 ID(txID)가 존재하면, 해당 트랜잭션의 ID(txID)를 요청할 트랜잭션 리스트에 추가할 수 있다(reqTxIDs.add(txID)). 이에 따라, 기본 노드는 해당 트랜잭션 해시의 ID는 요청한 트랜잭션으로 설정할 수 있다(TxRequestMap[txID] = true). 만약, 어떤 트랜잭션 해시의 ID(txID)가 기본 노드가 이미 가지고 있거나(TxMap[MyNodeID].not_contains(txID) == false) 이미 요청되었다면(TxRequestMap[txID] == true), 해당 트랜잭션 해시의 ID(txID)는 요청할 트랜잭션 리스트(reqTxIDs)에 추가되지 않는다. 기본 노드는 이러한 과정을 한 노드에 대해 K개의 트랜잭션 해시의 ID를 요청할 트랜잭션에 추가할 때까지 반복할 수 있다. 한 노드에게 요청할 K개의 트랜잭션 선택이 완료되면, 다음 노드에 대해서도 요청할 K개의 트랜잭션을 선택하며 모든 노드에 대해 이를 반복한다 (for nodeID each txCounts.keys). 이후 기본 노드는 아직 요청되지 못한 트랜잭션에 대해 다시 위 과정을 반복한다 (while TxRequestMap.values.contains(false):). 모든 트랜잭션에 대해 요청할 노드가 선택되면, 기본 노드는 각 대상 노드에게 트랜잭션을 요청할 수 있다(request_tx(nodeID, txID)).
도 6은 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 트랜잭션 요청 대상 선택 과정의 한 예를 나타내는 도면이다.
도 6에서는 다섯 개의 위원회 노드(예를 들면, f=2인 경우로, 5(=2f+1)개의 노드(Node_A, Node_B, Node_C, Node_D, Node_E))에 대해 후보 블록에 포함되는 네 개의 트랜잭션(Tx1, Tx2, Tx3, Tx4)을 가지고 있는 경우를 '1", 가지고 있지 않은 경우를 '0'으로 표시한다. 기본 노드(Node_A)는 답변 단계에서 최종 블록을 생성하기 위해 3(=f+1)개 이상의 노드가 요청한 네 개의 트랜잭션이 모두 필요하다. 하지만, 기본 노드(Node_A)는 세 개의 트랜잭션(Tx1, Tx2, Tx3)를 가지고 있지 않으므로 세 개의 트랜잭션(Tx1, Tx2, Tx3)을 다른 노드(Node_B, Node_C, Node_D, Node_E)에게 요청할 수 있다. 이 경우, 기본 노드(Node_A)는 트랜잭션 요청 대상 선택 과정에 따라 각 트랜잭션을 어떤 노드에게 요청할지 결정할 수 있다. 우선 기본 노드(Node_A)는 노드별 트랜잭션 개수 카운트 단계에서 노드 별로 보유 트랜잭션 수(TxCounts)를 계산한다. 보유 트랜잭션 수(TxCounts)를 계산할 때, 기본 노드(Node_A)는 트랜잭션 Tx4를 이미 가지고 있으므로 이를 제외할 수 있다. 따라서, 트랜잭션 Tx4를 제외한 나머지 트랜잭션에 대해 다른 노드(Node_B, Node_C, Node_D, Node_E)가 가지고 있는 트랜잭션의 개수(TxCounts)는 각각 3, 3, 1, 2이다. 다음, 기본 노드(Node_A)는 노드 별 트랜잭션 요청 단계에서 보유 트랜잭션 수(TxCounts)가 적은 순서대로 트랜잭션을 요청할 수 있다. 이에 따라, 기본 노드(Node_A)는 먼저 노드(Node_D)에게 트랜잭션 Tx3을 요청하고, 다음 노드(Node_E)에게 트랜잭션 Tx2를 요청하고, 다음 노드(Node_B)에게 트랜잭션 Tx1을 요청할 수 있다. 어떤 실시예에서, Tx1의 경우, 보유 트랜잭션 개수가 같은 Node_C에게 요청할 수도 있다.
이와 같은 방법으로 기본 노드는 각 위원회 노드에게 준비 메시지에 트랜잭션 요청 메시지를 포함하여 보낼 수 있다. 이 후, 위원회 노드는 커밋 메시지를 요청된 원본 트랜잭션와 함께 기본 노드에게 전달한다. 마지막으로, (2f+1)개의 위원회 노드에게 커밋 메시지를 받은 기본 노드는 해당 트랜잭션들을 포함한 최종 블록을 확정 짓고 답변 메시지를 통해 블록을 전파할 수 있다.
도 2 내지 도 6을 참고로 하여 설명한 블록 합의 방법을 "원본 트랜잭션 기반 블록 합의 방법"이라 할 수 있다.
도 7은 본 발명의 또 다른 실시예에 따른 트랜잭션 해시 기반 블록 합의 방법의 한 예를 나타내는 도면이다. 도 7에서는 설명의 편의상 하나의 클라이언트와 네 개의 노드만을 도시하였으며, 도 7에서 화살표는 메시지의 전달을 나타낸다.
도 7을 참고하면, 요청 단계와 위임 요청 단계는 도 2를 참고로 하여 설명한 원본 트랜잭션 기반 블록 합의 방법과 동일하므로 그 설명을 생략한다.
준비 단계에서, 원본 트랜잭션 기반 블록 합의 방법과 유사하게, 기본 노드(예를 들면, Node A)는 (2f+1)개의 노드(예를 들면, Node A, Node B, Node C)로부터 받은 위임 요청 메시지에 포함된 트랜잭션 해시 중에서 (f+1)개의 노드가 동의한 트랜잭션 해시를 찾아 후보 블록을 만들고, 트랜잭션 해시로 구성된 후보 블록을 포함하는 준비 메시지를 (2f+1)개의 위원회 노드에게 전달한다. 또한 기본 노드는 어떤 노드가 어떤 트랜잭션에 동의하였는지(어떤 노드가 어떤 트랜잭션을 제출하였는지)에 대한 증거를 만들어 이를 후보 블록과 함께 준비 메시지로 전달할 수 있다. 한편, 원본 트랜잭션 기반 블록 합의 방법과 달리, 준비 단계에서 기본 노드는 위원회 노드에게 원본 트랜잭션을 요청하지 않는다.
커밋 단계에서, 각 위원회 노드(예를 들면, Node A, Node B, Node C)는 기본 노드가 제시한 후보 블록에 동의하는지에 대한 서명을 포함하는 커밋 메시지를 기본 노드로 전달한다. 이 경우, 원본 트랜잭션 기반 블록 합의 방법과 달리, 커밋 메시지는 원본 트랜잭션을 포함하지 않는다. 답변 단계에서 최종적으로 결정된 최종 블록이 트랜잭션을 요청한 클라이언트와 블록체인 네트워크 내에 존재하는 노드들에게 전파된다. 이 경우, 최종 블록은 원본 트랜잭션을 포함하지 않고 합의된 트랜잭션의 해시를 포함할 수 있다.
이상에서 설명한 실시예에 따르면, 전파되는 블록의 크기를 획기적으로 줄여 네트워크 트래픽 절감을 통한 합의 성능 향상을 달성할 수 있다.
한편, 답변 단계에서 기본 노드는 어떤 위원회 노드가 위임 요청 메시지를 통해서 어떤 트랜잭션의 트랜잭션 해시를 전송하였는지를 지시하는 정보(예를 들면, 트랜잭션 비트맵)를 답변 메시지로 전달할 수 있다. 따라서, 답변 메시지를 받은 노드는 최종 블록에 해당하는 원본 트랜잭션을 받아 올 위원회 노드를 트랜잭션 비트맵에 기초해서 선택할 수 있다.
이와 같이, 전파되는 최종 블록에는 원본 트랜잭션이 포함되어 있지 않으므로 최종 블록을 받은 각 노드는 원본 트랜잭션을 미리 가지고 있지 않은 경우 확정된 블록의 트랜잭션을 실행할 수 없다. 그러므로, 어떤 실시예에서, 트랜잭션 해시 기반 블록 합의 방법에서는 1) 블록에 포함된 트랜잭션 실행을 위한 원본 트랜잭션 요청/반환 및 그에 따른 트랜잭션 상태 관리 또는 2) 원본 트랜잭션이 존재하지 않아 실행되지 못한 트랜잭션과 다음 블록에 추가할 트랜잭션과의 의존성과 관련된 요구사항을 추가로 고려할 수 있다. 이러한 요구사항을 고려하는 실시예에 대해서 도 8 내지 도 10을 참고로 하여 설명한다.
도 8은 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 트랜잭션 스테이트 머신 다이어그램의 한 예를 나타내는 도면이다. 도 8에 도시한 다이어그램은 메모리 풀에 저장되는 트랜잭션의 상태 변화를 나타낸다.
도 8을 참고하면, 어떤 트랜잭션이 메모리 풀에 존재하지 않는 초기 상태를 공백(Empty) 상태(810)로 표현할 수 있다. 공백 상태(810)인 트랜잭션은 두 가지 방법으로 트랜잭션 실행 준비가 완료된 준비 완료(Ready) 상태(840)로 변할 수 있다. 첫 번째 방법은 대기(Waiting) 상태(820)를 거치는 방법이다. 노드가 클라이언트로부터 또는 다른 노드를 통해서 트랜잭션 요청을 받으면 해당 트랜잭션은 메모리 풀에 대기 상태(820)로 저장된다(S811). 이 때, 노드는 원본 트랜잭션을 받은 것이므로 이후 블록 합의를 통해 해당 트랜잭션이 블록에 실리게 되면 해당 트랜잭션은 실행 준비를 마치게 되어 준비 완료 상태(840)로 변경된다(S821). 첫 번째 방법은 블록이 합의되기 전에 블록에 포함된 원본 트랜잭션을 미리 가지고 있는 상황을 나타낸다. 두 번째 방법은 해시 유일(Hash-only) 상태(830)를 거치는 방법이다. 두 번째 방법은 노드가 합의된 블록을 받았을 때 해당 블록에 포함된 트랜잭션 해시에 해당하는 원본 트랜잭션을 가지고 있지 않는 상황을 나타낸다. 노드가 메모리 풀에 트랜잭션이 존재하지 않는 상황에서 합의된 트랜잭션의 해시만을 받았으므로, 트랜잭션 해시만 메모리 풀에 해시 유일 상태(830)로 저장된다(S812). 노드가 다른 노드에게 원본 트랜잭션(Tx body)을 요청하여 얻어오면(이 때, 예를 들면 도 6을 참고로 하여 설명한 방식을 사용할 수 있다), 해당 트랜잭션은 해시 유일 상태(830)에서 준비 완료 상태(840)로 된다(S831). 도 5를 참고로 하여 설명한 것처럼, 각 노드는 트랜잭션 요청 대상 선택 과정을 거쳐 원본 트랜잭션을 얻어올 노드를 선택할 수 있다. 이러한 두 가지 방법으로 트랜잭션이 준비 완료 상태(840)가 되면 트랜잭션이 실행될 수 있다.
노드가 트랜잭션을 실행하면 해당 트랜잭션은 실행 완료(Spent) 상태(850)가 된다(S841). 실행 완료 상태(850)는 노드에게 이미 실행된 트랜잭션이 또 다시 전달되었을 때, 해당 트랜잭션이 중복하여 실행되지 않도록 하기 위한 트랜잭션 상태이다. 전달된 트랜잭션과 동일한 트랜잭션이 메모리 풀에 실행 완료 상태로 존재하는 경우, 트랜잭션 요청이 오더라도 해당 트랜잭션은 무시될 수 있다. 마지막으로, 중복된 트랜잭션이 전달되지 않을 정도로 충분한 시간이 지나면 해당 트랜잭션은 메모리 풀에서 삭제되고, 삭제(Deleted) 상태(860)로 된다(S851). 만약, 트랜잭션이 메모리 풀에서 삭제된 이후에 악의적인 노드에 의해 중복된 트랜잭션이 또다시 전달되더라도, 해당 트랜잭션은 트랜잭션 상태 데이터베이스를 통해 유효하지 않은 트랜잭션으로 판단되므로 문제가 발생하지 않는다.
한편, 트랜잭션 해시 기반 블록 합의 방법에서 트랜잭션 간의 의존성 문제는 위임 요청 단계에서 각 노드가 기본 노드에게 블록에 추가하길 원하는 트랜잭션을 제출하는 시점에 발생할 수 있다. 확정된 블록이 원본 트랜잭션(트랜잭션의 내용)을 가지고 있지 않기 때문에 블록의 트랜잭션과 위임 요청 메시지에 실릴 트랜잭션이 종속적인 관계가 있는지 알 수 없을 수 있다. 따라서, 어떤 실시예에서, 트랜잭션 해시 기반 블록 합의 방법에서는 트랜잭션 데이터에 트랜잭션의 종속성을 표현하는 데이터를 추가할 수 있다.
도 9는 본 발명의 또 다른 실시예에 따른 트랜잭션 해시 데이터 구조의 한 예를 나타내는 도면이다.
도 9에 도시한 것처럼, 도 4을 참고로 하여 설명한 트랜잭션 해시 데이터 구조에 의존성 데이터(ParentTxIDs)가 추가될 수 있다. 즉, 도 3을 참고로 하여 설명한 데이터 구조에서 원본 데이터(Payload) 대신에 의존성 데이터(ParentTxIDs)가 추가될 수 있다. 의존성 데이터(ParentTxIDs)의 크기(M 바이트)는 원본 데이터(Payload)의 데이터 크기(N 바이트)에 비해 상대적으로 매우 작다. 어떤 실시예에서, 의존성 데이터(ParentTxIDs)는 해당 트랜잭션의 부모 트랜잭션의 ID를 포함할 수 있다.
도 10은 본 발명의 또 다른 실시예에 따른 블록 합의 방법에서 메모리 풀에서 트랜잭션을 가져오는 방법의 한 예를 나타내는 흐름도이다.
도 10을 참고하면, 먼저 노드가 메모리 풀에서 트랜잭션을 꺼내고(S110), 꺼낸 트랜잭션의 부모 트랜잭션(parent Tx)이 모두 실행되었는지 확인한다(S120). 만약 모든 부모 트랜잭션이 실행되었을 경우, 해당 트랜잭션은 의존성 문제가 없으므로 위임 요청 메시지에 추가된다(S130). 만약 일부 또는 모든 부모 트랜잭션이 아직 실행되지 않은 경우, 노드는 실행되지 않은 부모 트랜잭션의 상태를 확인한다(S140). 어떤 부모 트랜잭션의 상태가 준비 완료 상태인 경우(S140), 노드는 해당 부모 트랜잭션의 실행이 완료되기를 대기한다(S150). 어떤 부모 트랜잭션의 상태가 해시 유일 상태인 경우(S160), 노드는 도 9을 참고로 하여 설명한 것처럼 해당 부모 트랜잭션의 원본 트랜잭션을 요청한다(S170). 어떤 부모 트랜잭션의 상태가 대기 상태인 경우에, 노드는 해당 부모 트랜잭션이 블록(예를 들면, 합의할 블록)에 추가되기를 대기한다(S180).
이상에서 설명한 실시예에 따르면, 블록에 포함된 트랜잭션 실행을 위한 원본 트랜잭션 요청/반환 및 그에 따른 트랜잭션 상태 관리 또는 원본 트랜잭션이 존재하지 않아 실행되지 못한 트랜잭션과 다음 블록에 추가할 트랜잭션과의 의존성과 관련된 요구사항을 해결할 수 있다.
도 7 내지 도 10을 참고로 하여 설명한 블록 합의 방법을 "트랜잭션 해시 기반 블록 합의 방법"이라 할 수 있다.
다음, 본 발명의 한 실시예에 따른 블록 합의 방법을 구현할 수 있는 예시적인 컴퓨팅 장치에 대하여 도 11을 참고로 하여 설명한다.
도 11은 본 발명의 한 실시예에 따른 컴퓨팅 장치의 한 예를 나타내는 도면이다. 어떤 실시예에서, 도 11에 도시한 컴퓨팅 장치는 다양한 실시예에 따른 블록 합의 방법 중에서 기본 노드에서 실행되는 동작을 구현할 수 있다.
도 11을 참고하면, 컴퓨팅 장치는 프로세서(1110), 메모리(1120), 저장 장치(1130), 통신 인터페이스(1140) 및 버스(1150)를 포함한다. 컴퓨팅 장치는 다른 범용적인 구성 요소를 더 포함할 수 있다.
프로세서(1110)는 컴퓨팅 장치의 각 구성의 전반적인 동작을 제어한다. 프로세서(1110)는 CPU(central processing unit), MPU(microprocessor unit), MCU(micro controller unit), GPU(graphic processing unit) 등의 다양한 프로세싱 유닛 중 적어도 하나로 구현될 수 있으며, 병렬 프로세싱 유닛으로 구현될 수도 있다. 또한, 프로세서(1110)는 위에서 설명한 블록 합의 방법을 실행하기 위한 프로그램에 대한 연산을 수행할 수 있다.
메모리(1120)는 각종 데이터, 명령 및/또는 정보를 저장한다. 메모리(1120)는 위에서 설명한 블록 합의 방법을 실행하기 위하여 저장 장치(1130)로부터 컴퓨터 프로그램을 로드할 수 있다. 저장 장치(1130)는 프로그램을 비임시적으로 저장할 수 있다. 저장 장치(1130)는 비휘발성 메모리로 구현될 수 있다.
통신 인터페이스(1140)는 컴퓨팅 장치의 무선 통신을 지원한다.
버스(1150)는 컴퓨팅 장치의 구성 요소간 통신 기능을 제공한다. 버스(1150)는 주소 버스(address bus), 데이터 버스(data bus) 및 제어 버스(control bus) 등 다양한 형태의 버스로 구현될 수 있다.
컴퓨터 프로그램은 메모리(1120)에 로드될 때 프로세서(1110)로 하여금 블록 합의 방법을 수행하도록 하는 명령어(instructions)를 포함할 수 있다. 즉, 프로세서(1110)는 명령어를 실행함으로써, 블록 합의 방법을 위한 동작을 수행할 수 있다.
위에서 설명한 본 발명의 다양한 실시예에 따른 블록 합의 방법은 컴퓨터가 읽을 수 있는 매체 상에 컴퓨터가 읽을 수 있는 컴퓨터 프로그램으로 구현될 수 있다. 한 실시예에서, 컴퓨터가 읽을 수 있는 매체는 이동형 기록 매체이거나 고정식 기록 매체일 수 있다. 다른 실시예에서, 컴퓨터가 읽을 수 있는 매체에 기록된 컴퓨터 프로그램은 인터넷 등의 네트워크를 통하여 다른 컴퓨팅 장치에 전송되어 다른 컴퓨팅 장치에 설치되어 실행될 수 있다.
이상에서 본 발명의 실시예에 대하여 상세하게 설명하였지만 본 발명의 권리범위는 이에 한정되는 것은 아니고 다음의 청구범위에서 정의하고 있는 본 발명의 기본 개념을 이용한 당업자의 여러 변형 및 개량 형태 또한 본 발명의 권리범위에 속하는 것이다.
Claims (20)
- 컴퓨팅 장치의 블록 합의 방법으로서,
복수의 노드 각각으로부터 트랜잭션 해시를 포함하는 위임 요청(delegate request) 메시지를 수신하는 단계,
상기 위임 요청 메시지에 기초해서 트랜잭션 해시를 포함하는 후보 블록을 만들고, 상기 복수의 노드로 상기 후보 블록을 포함하는 준비(prepare) 메시지를 전송하는 단계,
상기 복수의 노드로부터 상기 후보 블록의 유효성에 동의하는 증거를 포함하는 커밋(commit) 메시지를 수신하는 단계, 그리고
상기 커밋 메시지에 기초해서 확정한 최종 블록을 포함하는 답변(reply) 메시지를 전송하는 단계를 포함하되,
상기 준비 메시지를 전송하는 단계는 상기 복수의 노드 중에서 상기 후보 블록에 포함된 트랜잭션 해시에 대응하는 원본 트랜잭션을 요청할 노드를 선택하는 단계, 및 상기 선택한 노드에 상기 원본 트랜잭션을 요청하는 단계를 포함하고,
상기 원본 트랜잭션을 요청할 노드를 선택하는 단계는 보유 트랜잭션 수가 적은 노드부터 차례로 상기 원본 트랜잭션을 요청할 노드를 선택하는 블록 합의 방법. - 제1항에서,
상기 위임 요청 메시지는 상기 위임 요청 메시지에 포함된 상기 트랜잭션 해시에 해당하는 원본 트랜잭션을 포함하지 않으며,
상기 준비 메시지는 상기 준비 메시지에 포함된 상기 트랜잭션 해시에 해당하는 원본 트랜잭션을 포함하지 않는
블록 합의 방법. - 제1항에서,
각 노드로부터 수신한 상기 위임 요청 메시지에 포함된 상기 트랜잭션 해시는 해당 노드가 상기 후보 블록에 추가하기를 원하는 트랜잭션의 트랜잭션 해시를 포함하는, 블록 합의 방법 - 제1항에서,
상기 준비 메시지를 전송하는 단계는 상기 위임 요청 메시지에 포함된 상기 트랜잭션 해시에 기초해서 상기 복수의 노드 중 소정 수의 노드가 동의한 트랜잭션 해시를 포함하는 상기 후보 블록을 만드는 단계를 포함하는, 블록 합의 방법. - 제4항에서,
상기 복수의 노드의 수가 (2f+1)인 경우, 상기 소정 수는 (f+1)인, 블록 합의 방법. - 삭제
- 삭제
- 제1항에서,
상기 원본 트랜잭션을 요청하는 단계는 상기 선택한 노드에 K개의 원본 트랜잭션을 요청하는 단계를 포함하는, 블록 합의 방법. - 제1항에서,
서로 다른 노드에 요청되는 상기 원본 트랜잭션은 중복되지 않는, 블록 합의 방법. - 제1항에서,
상기 커밋 메시지를 수신하는 단계는, 각 노드로부터, 상기 후보 블록에 포함된 트랜잭션 해시 중에서 해당 노드에게 요청된 트랜잭션 해시에 해당하는 원본 트랜잭션을 수신하는 단계를 포함하는, 블록 합의 방법. - 제1항에서,
상기 답변 메시지를 전송하는 단계는, 상기 복수의 노드 중에서 어떤 노드가 상기 위임 요청 메시지를 통해 어떤 트랜잭션의 트랜잭션 해시를 전송하였는지를 지시하는 정보를 전송하는 단계를 더 포함하는 블록 합의 방법. - 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020210002482A KR102603880B1 (ko) | 2021-01-08 | 2021-01-08 | 블록 합의 방법 및 트랜잭션 상태 관리 방법 |
| US17/566,411 US20220222655A1 (en) | 2021-01-08 | 2021-12-30 | Method for block consensus and method for managing transaction state |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020210002482A KR102603880B1 (ko) | 2021-01-08 | 2021-01-08 | 블록 합의 방법 및 트랜잭션 상태 관리 방법 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20220100257A KR20220100257A (ko) | 2022-07-15 |
| KR102603880B1 true KR102603880B1 (ko) | 2023-11-20 |
Family
ID=82323137
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020210002482A KR102603880B1 (ko) | 2021-01-08 | 2021-01-08 | 블록 합의 방법 및 트랜잭션 상태 관리 방법 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20220222655A1 (ko) |
| KR (1) | KR102603880B1 (ko) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106716421B (zh) * | 2016-12-30 | 2020-03-31 | 深圳前海达闼云端智能科技有限公司 | 数据查询方法、装置及节点设备 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20220088507A (ko) | 2016-05-04 | 2022-06-27 | 실비오 미칼리 | 분산 거래 전파 및 검증 시스템 |
| CN108805569A (zh) * | 2018-05-29 | 2018-11-13 | 阿里巴巴集团控股有限公司 | 基于区块链的交易处理方法及装置、电子设备 |
| KR102228210B1 (ko) * | 2019-04-29 | 2021-03-16 | 에이치엔핀코어 주식회사 | 블록체인 네트워크에서의 트랜잭션의 삭제를 가능하게 하는 노드 장치 및 그 동작 방법 |
| KR102406020B1 (ko) * | 2019-06-18 | 2022-06-10 | 한국전자통신연구원 | 탈 중앙화된 비잔틴 오류 감내 분산 합의 장치 및 방법 |
-
2021
- 2021-01-08 KR KR1020210002482A patent/KR102603880B1/ko active IP Right Grant
- 2021-12-30 US US17/566,411 patent/US20220222655A1/en active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106716421B (zh) * | 2016-12-30 | 2020-03-31 | 深圳前海达闼云端智能科技有限公司 | 数据查询方法、装置及节点设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20220222655A1 (en) | 2022-07-14 |
| KR20220100257A (ko) | 2022-07-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9888048B1 (en) | Supporting millions of parallel light weight data streams in a distributed system | |
| JP4612715B2 (ja) | 情報処理システム、データ更新方法およびデータ更新プログラム | |
| CN1881945B (zh) | 改进型分布式核心操作系统 | |
| US5987502A (en) | Workload management in an asynchronous client/server computer system | |
| JPH0535903B2 (ko) | ||
| US8024744B2 (en) | Method and system for off-loading user queries to a task manager | |
| US6968359B1 (en) | Merge protocol for clustered computer system | |
| KR20120072908A (ko) | 복수 개의 프락시 서버를 포함하는 분산 저장 시스템 및 그 오브젝트 관리 방법 및 컴퓨터에 의하여 독출가능한 저장 매체 | |
| CN112102044B (zh) | 一种消息队列处理高并发秒杀商品的方法、系统及装置 | |
| JPH10187519A (ja) | 分配システムの競合を防止する方法 | |
| JPWO2004063928A1 (ja) | データベース負荷軽減システムおよび負荷軽減プログラム | |
| JPH0822409A (ja) | ネットワークにおける配布情報管理システム | |
| CN111641470B (zh) | 一种分布式仿真的时间一致性同步方法 | |
| CN110474917A (zh) | 消息中间件上、下线方法、装置、设备及可读存储介质 | |
| WO2024051454A1 (zh) | 处理事务日志的方法及装置 | |
| WO2021052237A1 (zh) | 事务处理方法、装置、设备、存储介质、数据库 | |
| JP2005521945A (ja) | 共通作業キュー環境における最適格サーバ | |
| KR101527634B1 (ko) | 샤딩 서비스를 제공하는 방법 및 장치 | |
| KR20140047230A (ko) | 분산 시스템에서 분산 트랜잭션의 최적화를 위한 방법 및 트랜잭션을 최적화한 분산 시스템 | |
| JP3462064B2 (ja) | 分散シミュレーションシステム | |
| JP2010277467A (ja) | 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム | |
| US20190372825A1 (en) | Communication apparatus, communication method, and recording medium | |
| KR102603880B1 (ko) | 블록 합의 방법 및 트랜잭션 상태 관리 방법 | |
| CN114500416A (zh) | 用于最多一次消息投递的投递方法和投递系统 | |
| US20090083379A1 (en) | Enabling connections for use with a network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| E902 | Notification of reason for refusal | ||
| E90F | Notification of reason for final refusal | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant |