KR20230084026A

KR20230084026A - 블록체인 트랜잭션 데이터 저장 방법, 장치 및 이를 이용한 분산 저장 시스템

Info

Publication number: KR20230084026A
Application number: KR1020220145312A
Authority: KR
Inventors: 이명철
Original assignee: 한국전자통신연구원
Priority date: 2021-12-03
Filing date: 2022-11-03
Publication date: 2023-06-12

Abstract

본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법은, 블록체인 트랜잭션들을 저장하는 적어도 하나의 블록 파일(block file)을 인코딩 블록 파일 대상(encoding block file target)으로 선택하는 단계; 상기 인코딩 블록 파일 대상을 이용하여 패리티 청크들을 포함하는 인코딩된 청크들을 생성하는 단계; 및 상기 인코딩된 청크들 중 적어도 하나와, 상기 인코딩된 청크들 중 적어도 하나를 저장할 블록체인 노드들 중 적어도 하나를 대응시키는 단계를 포함한다.

Description

블록체인 트랜잭션 데이터 저장 방법, 장치 및 이를 이용한 분산 저장 시스템 {METHOD AND APPARATUS FOR STORING BLOCKCHAIN TRANSACTION DATA AND DISTRIBUTED STORAGE SYSTEM USING THE SAME}

본 발명은 블록체인 트랜잭션 데이터 저장 시스템에 관한 것으로, 특히 블록체인 트랜잭션 데이터를 비잔틴 장애 내성을 보장(guaranteeing Byzantine Fault Tolerance)하면서 다수의 참여 노드들에 분산 저장함으로써 전체 블록체인 시스템의 트랜잭션 데이터 저장 용량을 확장하는 기술에 관한 것이다.

신뢰할 수 있는 제3자에 대한 개인 데이터의 소유 집중화 문제, 그리고 신뢰할 수 있는 제3자에 대한 개인 데이터 유출 및 조작 등의 문제를 해결하기 위해, 상호 신뢰하지 않는 다수의 참여자들 간에 분산된 장부들을 유지하고 이를 통해 데이터의 무결성 및 신뢰성을 확보하는 블록체인 기술이 주목 받고 있다.

최근 비트코인, 이더리움 등 가산 자산의 가치가 급등하면서 가상 자산의 거래도 급증하고, 블록체인 기술에 대한 관심도 급격히 증가하고 있다. 블록체인 기술은 기존 가상 자산 관련 분야뿐만 아니라 일반 산업 및 비즈니스로 그 활용 영역 확장을 시도하고 있다.

다양한 산업 분야에서 블록체인을 활용한 응용 서비스 개발 및 사업화를 시도하고 있으나, 합의, 저장, 분석 등 블록체인이 가진 확장성의 한계로 인해 많은 시도들이 실패해왔고 여전히 블록체인 기술은 가상 자산 위주로 활용되고 있다.

블록체인 저장 계층의 확장성 문제로는, 블록체인의 활용성이 증가하게 되면 결국 저장되는 원장(ledger; 트랜잭션 데이터와 상태 데이터로 구성)의 크기가 급격히 증가한다는 것이다. 원장의 크기가 급격히 증가하면 일반 수준의 개인용 컴퓨터(personal computer; PC)나 서버에서는 이를 저장하거나 처리하는 것이 불가능해진다.

비트코인(Bitcoin), 이더리움(Ethereum) 및 하이퍼레저 패브릭(Hyperleger Fabric) 등 대다수의 블록체인 플랫폼들에서 원장은 데이터 또는 자산(asset)의 최신 상태 데이터를 관리하는 상태 데이터와, 상태들의 변화를 발생시키는 트랜잭션들의 이력을 관리하는 트랜잭션 데이터로 구성된다. 상태 데이터는 보통 LevelDB, RocksDB, CouchDB 등의 키/밸류 스토어 또는 도큐먼트 스토어를 이용하여 관리되고, 트랜잭션 데이터는 파일 시스템 상의 파일(비트코인 또는 하이퍼레저 패브릭의 경우) 또는 키/밸류 스토어(이더리움의 경우)를 이용하여 관리된다.

특히, 트랜잭션 데이터는 기설정된 크기를 가지는 블록들로 모아져서 참여 노드들의 합의, 검증 등의 과정을 거쳐서 최종 상태 데이터에 반영되며, 이와 같이 합의된 블록들은 서로 연결되어 다수의 참여 노드들에 분산 저장되어 공유 장부로서의 역할을 수행하게 된다. 이를 통해, 데이터의 무결성 및 신뢰성이 확보될 수 있다.

그런데, 블록체인의 트랜잭션 데이터는 모든 참여 노드들에 중복되어 저장되고 따라서 과도한 디스크/메모리 용량을 요구하는 것이 문제이다.

비트코인 트랜잭션 데이터는 2019년 4월 약 213GB 였고, 2021년 10월 기준으로 약 360GB에 달하며 이는 2019년 대비 약 150GB 가량 증가한 수치이다.

이와 같은 블록체인 트랜잭션 데이터의 급격한 증가 및 중복 저장 방식으로 인해 블록체인 네트워크에 신규로 참여하는 노드는 기존의 트랜잭션 데이터를 전달 받기 위해 수일 또는 수주에 걸쳐 시간을 소비해야 하고, 매우 높은 수준의 컴퓨팅 자원 및 능력을 보유한 노드들만이 풀 노드(Full Node)로써 블록체인에 참여할 수 있다. 이는 대규모 마이닝 풀의 점유율이 증가하는 결과를 초래하였고, 결국 탈중앙화에 역행하여 또다시 데이터 소유의 중앙화를 야기하는 문제가 초래되었다.

블록체인 트랜잭션 데이터를 참여 노드들에 중복 저장하지 않고 분산 저장하여, 스토리지 용량 문제와 성능 문제를 해결하기 위한 목적으로, 최근 분산 해시 테이블(DHT; Distributed Hash Table), 샤딩(sharding) 및 이레이저 코드(EC; Erasure Code) 등을 활용한 다양한 블록체인 트랜잭션 분산 저장 방법들이 제안되어 왔다.

대규모 데이터를 네트워크상의 참여 노드들에 분산하여 저장하고 관리하는 기술인 분산 해시 테이블(DHT) 기반의 기술의 경우, 일부 연구 기관들이 초기 연구를 수행하고 있으나 대다수 연구들이 실제 구현까지 진행되지 못하고 이론적인 수준에서만 논의되고 있으며, 일부 구현된 기술들은 비잔틴 장애 내성 보장 여부에 대한 검증이 미진하여, 실제로 사용되기에는 아직도 많은 추가 연구 및 검증이 필요한 상황이다.

데이터를 여러 개의 논리적인 그룹들로 분할 저장하는 기술인 샤딩(sharding) 기반의 기술은, 트랜잭션 데이터를 주로 계정을 기준으로 분할하여 해당 샤드 내에서만 데이터를 중복 저장하고, 이를 통해 원장의 용량 증가에 대처하는 기술이나, 서로 다른 샤드 간의 거래시 처리가 복잡하고 샤드 내에서는 데이터가 여전히 중복되며 악의적 공격에 취약한 문제 등이 지적되고 있다.

통신 시스템과 스토리지 시스템에서 주로 활용되던 데이터 가용성(data availability) 보장 기법인 ECC(Error Correction Code), EC(Erasure Code) 등 인코딩 기술 기반의 블록체인 트랜잭션 데이터 분할 및 분산 저장 기법 등이 최근 연구되고 있으나, 비잔틴 장애 내성 보장, 인코딩/디코딩 오버헤드, 분할 분산 저장된 블록의 읽기 성능, 참여 노드 추가/삭제시 재인코딩 필요 등 해결해야 할 문제들이 적지 않다.

2020년 공개된 IEEE 논문 "BFT-Store: Storage Partition for Permissioned Blockchain via Erasure Coding"은 다수의 블록들을 대상으로 이레이져 코딩을 적용하여 인코딩된 블록들을 생성하고 이를 여러 노드들에 분산 저장하는 기술을 제안하고 있으나, 실제 블록들이 파일 등에 저장되는 환경을 고려하지 않고 있어서 기존 블록체인 시스템에 적용되기 어렵고 접근 빈도, 계산 부하나 저장공간의 효율성을 고려하지 못하여 효율성이 떨어진다.

한국공개특허 10-2021-0058744호는 하나 이상의 블록에 인코딩을 적용하고 인코딩된 블록들을 블록체인 네트워크의 모든 참여 노드들에 분할하여 저장하는 기술을 제안하고 있으나, 인코딩된 데이터에 대한 접근이 발생하는 경우에는 매 번 다수의 노드들로부터 인코딩된 블록들을 수집하고 디코딩해야 데이터에 접근이 가능한 문제가 있다.

따라서, 실제 블록의 블록체인 저장 상황을 고려하여 최적의 성능을 보장하고 인코딩된 블록에 대한 접근시 이를 보다 효율적으로 처리할 수 있는 새로운 블록체인 분산 저장 기술의 필요성이 절실하게 대두된다.

본 발명의 목적은 블록 형태로 표현되어 파일 형태로 파일 시스템에 저장되는 블록체인 트랜잭션 데이터를 비잔틴 장애 내성을 보장하면서 다수의 참여 노드들에 분산 저장하여, 트랜잭션 데이터를 참여 노드에 중복 저장하는 경우에 발생하는 저장 공간 낭비 및 데이터 소유의 집중화 문제를 해결하는 것이다.

또한, 본 발명의 목적은 블록체인 시스템의 저장 공간 관리 효율성을 제고하여, 블록체인 기술이 다양한 산업 분야의 대규모 저장/관리에 활용될 수 있도록 하는 것이다.

상기한 목적을 달성하기 위한 본 발명에 따른 블록체인 트랜잭션 데이터 저장 장치에 의하여 수행되는 블록체인 트랜잭션 데이터 저장 방법은, 블록체인 트랜잭션들을 저장하는 적어도 하나의 블록 파일(block file)을 인코딩 블록 파일 대상(encoding block file target)으로 선택하는 단계; 상기 인코딩 블록 파일 대상을 이용하여 패리티 청크들을 포함하는 인코딩된 청크들을 생성하는 단계; 및 상기 인코딩된 청크들 중 적어도 하나와, 상기 인코딩된 청크들 중 적어도 하나를 저장할 블록체인 노드들 중 적어도 하나를 대응시키는 단계를 포함한다.

이 때, 패리티 청크들은 M(M은 자연수)개이고, 상기 블록체인 노드들은 3M+1개이고, 상기 인코딩된 청크들은 3M+1개이고, 상기 인코딩된 청크들과 상기 블록체인 노드들은 1:1 대응될 수 있다.

이 때, 블록체인 노드들 각각은 상기 인코딩된 청크들 중 상응하는 한 개를 위해서는 인코딩된 청크를 그대로 저장하고, 상기 한 개를 제외한 나머지 청크들 중 적어도 일부를 위해서는 해쉬값만 저장할 수 있다.

이 때, 블록체인 트랜잭션 데이터 저장 방법은 상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하는지 여부를 판단하는 단계; 및 상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하지 않는 경우, 상기 인코딩 블록 파일 대상에 포함된 블록들 및 상기 인코딩 블록 파일 대상에 포함된 블록들 중 일부인 복제 블록을 이용하여 2M+1개의 인코딩 대상 블록들을 생성하는 단계를 더 포함할 수 있다. 이 때, 상기 인코딩된 청크들은 상기 인코딩 대상 블록들을 이용한 인코딩을 수행하여 생성될 수 있다.

이 때, 복제 블록은 접근 빈도에 기반하여 상기 인코딩 블록 파일 대상에 포함된 블록들 중에서 선택될 수 있다.

이 때, 인코딩 블록 파일 대상은 2M+1개를 초과하지 않는 개수의 블록들을 포함할 수 있다.

이 때, 2M+1개를 초과하지 않는 개수의 블록들은, 사이즈가 모두 동일하지 않고, 상기 인코딩된 청크들을 생성하기 전에 최대 블록 사이즈를 기준으로 패딩될 수 있다.

이 때, 인코딩 블록 파일 대상은 상기 블록체인 트랜잭션들을 저장하는 블록 파일들 중에서, 상기 블록 파일들 또는 상기 블록 파일들이 포함하는 블록들에 대한 접근 빈도들을 고려하여 선택될 수 있다.

이 때, 해쉬값은 다른 노드에서 읽어온 블록을 검증하는데 사용될 수 있다.

이 때, 인코딩된 청크들 중 2M+1개 이상은 상기 인코딩 대상 블록들을 복원하는 디코딩에 사용될 수 있다.

또한, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 장치는 하나 이상의 프로세서; 및 상기 하나 이상의 프로세서에 의해 실행되는 적어도 하나 이상의 프로그램을 저장하는 실행메모리를 포함한다.

이 때, 상기 적어도 하나 이상의 프로그램은 블록체인 트랜잭션들을 저장하는 적어도 하나의 블록 파일(block file)을 인코딩 블록 파일 대상(encoding block file target)으로 선택하고, 상기 인코딩 블록 파일 대상을 이용하여 패리티 청크들을 포함하는 인코딩된 청크들을 생성하고, 상기 인코딩된 청크들 중 적어도 하나와, 상기 인코딩된 청크들 중 적어도 하나를 저장할 블록체인 노드들 중 적어도 하나를 대응시킬 수 있다.

이 때, 적어도 하나 이상의 프로그램은 상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하는지 여부를 판단하고, 상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하지 않는 경우, 상기 인코딩 블록 파일 대상에 포함된 블록들 및 상기 인코딩 블록 파일 대상에 포함된 블록들 중 일부인 복제 블록을 이용하여 2M+1개의 인코딩 대상 블록들을 생성할 수 있다. 이 때, 상기 인코딩된 청크들은 상기 인코딩 대상 블록들을 이용한 인코딩을 수행하여 생성될 수 있다.

이 때, 인코딩 블록 파일 대상은 사이즈가 모두 동일하지 않은 블록들을 포함하고, 상기 사이즈가 모두 동일하지 않은 블록들은 상기 인코딩된 청크들을 생성하기 전에 최대 블록 사이즈를 기준으로 패딩될 수 있다.

또한, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 분산 저장 시스템은, 인코딩된 청크들 중 제1 청크를 그대로 저장하고, 상기 제1 청크를 제외한 나머지 청크들에 상응하는 해쉬값들을 저장하는 제1 블록체인 노드; 및 상기 제1 청크와 상이한 제2 청크를 그대로 저장하고, 상기 제2 청크를 제외한 나머지 청크들에 상응하는 해쉬값들을 저장하는 제2 블록체인 노드를 포함한다.

이 때, 인코딩된 청크들은, 각각 블록체인 트랜잭션들을 저장하는 블록 파일들(block files) 중에서 선택된 인코딩 블록 파일 대상(encoding block file target)을 이용하여 수행된 인코딩에 기반하여 생성될 수 있다.

본 발명에 따르면, 기존 블록체인 시스템에서 데이터의 신뢰성 보장을 위해 블록체인 네트워크 참여 노드에 트랜잭션 데이터를 중복 저장함으로 인하여 블록체인 네트워크 참여 노드를 증가시키더라도 트랜잭션 데이터의 저장 공간 용량 및 공간 효율성 측면에서의 확장성이 제한되는 문제를 해결할 수 있다.

또한, 본 발명에 따르면 블록체인 트랜잭션 데이터를 비잔틴 장애 내성을 보장하면서 다수의 참여 노드들에 분산 저장하여, 저장 공간 효율성을 높이고 각 참여 노드들의 저장 공간 사용을 최소화할 수 있다.

또한, 본 발명에 따르면 참여 노드의 저장 공간 효율성이 향상되고 각 참여 노드들의 저장 공간 사용을 최소화하여, 결과적으로 전체 블록체인 시스템의 저장 용량이 극대화될 수 있다.

도 1은 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 분산 저장 시스템을 나타낸 블록도이다.
도 2는 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 분산 저장 시스템의 구조를 나타낸 블록도이다.
도 3은 도 2에 도시된 블록체인 데이터 관리기의 일 예를 나타낸 블록도이다.
도 4는 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 분산 저장 시스템에서 블록체인 데이터 저장 흐름을 나타낸 도면이다.
도 5는 블록 파일 저장 개념을 나타낸 블록도이다.
도 6은 파일 시스템에 블록을 블록 파일 형태로 저장한 블록 파일 목록의 일 예를 나타낸 도면이다.
도 7은 블록 파일 저장 구조의 일 예를 나타낸 도면이다.
도 8은 본 발명의 일실시예에 따른 블록 파일 단위 인코딩이 적용되는 경우의 일 예를 나타낸 도면이다.
도 9는 본 발명의 일실시예에 따른 블록 파일 인코딩 기반 블록체인 트랜잭션 데이터 인코딩 방법의 일 예를 나타낸 블록도이다.
도 10은 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법을 나타낸 동작 흐름도이다.
도 11은 다수의 블록 파일들을 기반으로 블록체인 트랜잭션 데이터 인코딩이 적용되는 일 예를 나타낸 도면이다.
도 12는 본 발명의 일실시예에 따른 인코딩 대상 블록 파일 선정 방법을 나타낸 동작 흐름도이다.
도 13은 본 발명의 일실시예에 따른 블록 접근 방법의 일 예를 나타낸 동작 흐름도이다.
도 14는 본 발명의 일실시예에 따른 블록 오류를 발견한 노드의 재인코딩 방법의 일 예를 나타낸 동작 흐름도이다.
도 15는 본 발명의 일실시예에 따른 재인코딩 요청을 수신한 노드의 재인코딩 방법의 일 예를 나타낸 동작 흐름도이다.
도 16은 본 발명의 일실시예에 따른 블록 체인 트랜잭션 데이터 분산 저장 시스템에서 고빈도 접근 블록체인 트랜잭션 데이터의 복제를 나타낸 도면이다.
도 17은 본 발명의 일실시예에 따른 컴퓨터 시스템 구성을 나타낸 블록도이다.

본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 것이며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하며, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

비록 "제1" 또는 "제2" 등이 다양한 구성요소를 서술하기 위해서 사용되나, 이러한 구성요소는 상기와 같은 용어에 의해 제한되지 않는다. 상기와 같은 용어는 단지 하나의 구성요소를 다른 구성요소와 구별하기 위하여 사용될 수 있다. 따라서, 이하에서 언급되는 제1 구성요소는 본 발명의 기술적 사상 내에서 제2 구성요소일 수도 있다.

본 명세서에서 사용된 용어는 실시예를 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다. 명세서에서 사용되는 "포함한다(comprises)" 또는 "포함하는(comprising)"은 언급된 구성요소 또는 단계가 하나 이상의 다른 구성요소 또는 단계의 존재 또는 추가를 배제하지 않는다는 의미를 내포한다.

다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어는 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 해석될 수 있다. 또한, 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다.

이하, 첨부된 도면을 참조하여 본 발명의 실시예들을 상세히 설명하기로 하며, 도면을 참조하여 설명할 때 동일하거나 대응하는 구성 요소는 동일한 도면 부호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다.

도 1은 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 분산 저장 시스템을 나타낸 블록도이다.

도 1을 참조하면, 블록체인 트랜잭션 데이터 분산 저장 시스템에서, 블록들의 체인(블록체인)의 형태로 트랜잭션 이력을 관리하는 트랜잭션 데이터가 참여 노드들에 중복되어 저장되면 과도한 디스크/메모리 용량이 필요한 문제가 생길 수 있다.

도 1에 도시된 블록체인 노드들은 인코딩된 청크들 중 제1 청크를 그대로 저장하고, 상기 제1 청크를 제외한 나머지 청크들에 상응하는 해쉬값들을 저장하는 제1 블록체인 노드 및 상기 제1 청크와 상이한 제2 청크를 그대로 저장하고, 상기 제2 청크를 제외한 나머지 청크들에 상응하는 해쉬값들을 저장하는 제2 블록체인 노드를 포함할 수 있다. 이 때, 상기 인코딩된 청크들은, 각각 블록체인 트랜잭션들을 저장하는 블록 파일들(block files) 중에서 선택된 인코딩 블록 파일 대상(encoding block file target)을 이용하여 수행된 인코딩에 기반하여 생성될 수 있다. 이 때, 인코딩 블록 파일 대상은 하나 이상의 블록 파일에 상응하는 것일 수 있다. 예를 들어, 인코딩 블록 파일 대상은 하나의 블록 파일에 상응할 수 있고, 인코딩 블록 파일 대상은 두 개의 블록 파일들에 상응할 수 있고, 인코딩 블록 파일 대상은 열 개의 블록 파일들에 상응할 수도 있다.

본 발명의 일실시예에 따른 블록체인 데이터 분산 저장 시스템은 블록체인 트랜잭션 데이터를 저장하는 노드들 중 적어도 일부가, 블록체인 트랜잭션 데이터를 블록 파일 단위로 인코딩하고, 인코딩된 청크들 중 일부만을 그대로 저장함으로써 블록체인 트랜잭션 데이터 저장 시스템의 각 노드들에 요구되는 디스크/메모리 공간을 최소화할 수 있다.

도 2는 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 분산 저장 시스템의 구조를 나타낸 블록도이다.

도 2를 참조하면, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 분산 저장 시스템은 블록체인 데이터를 공유하는 다수의 블록체인 노드들(210, 220, 230, 240)로 구성된 블록체인 네트워크 형태로 구축될 수 있다.

블록체인 노드(210)는 데이터 신뢰성 보장을 위한 블록체인 데이터 관리기, 응용 프로그램 개발을 위한 블록체인 코어 인터페이스 및 기타 기반 및 응용 기술을 위한 모듈들로 구성될 수 있다.

이 때, 블록체인 데이터 관리기는 저장소, 상태 관리기 및 트랜잭션 관리기를 포함할 수 있다.

이 때, 블록체인 코어 인터페이스는 관리 인터페이스 및 소프트웨어 개발 도구를 포함할 수 있다.

이 때, 기타 기반 및 응용 기술을 위한 모듈들은 암호 모듈, 보안 하드웨어, 플랫폼 계정 관리기, P2P/통신 프로토콜부, 합의 프로토콜부 및 스마트 컨트랙트부를 포함할 수 있다.

도 2에 도시된 탈중앙화 애플리케이션(DApp)은 블록체인 플랫폼 및 블록체인 네트워크가 제공하는 기능 및 인터페이스를 이용하여 신뢰 기반의 데이터 저장/관리 응용 서비스를 사용자에게 제공할 수 있다.

도 3은 도 2에 도시된 블록체인 데이터 관리기의 일 예를 나타낸 블록도이다.

도 3을 참조하면, 블록체인 데이터 관리기는 원장 관리기(310), 상태 관리기(320), 복합 상태 관리기(330), 단순 상태 관리기(340), 복합 상태 데이터베이스(341), 단순 상태 데이터베이스(342), 트랜잭션 관리기(350), 파일 기반 블록 관리기(360) 및 블록 파일들(371, 372)을 포함할 수 있다.

도 3에 도시된 블록체인 데이터 관리기는 블록체인 원장(ledger; 상태 데이터와 트랜잭션 데이터로 구성)의 관리 기능을 제공한다.

탈중앙화 애플리케이션(DApp)에서 발생한 트랜잭션은 원장 관리기(310)를 통해 상태 관리기(320) 및 트랜잭션 관리기(350)에 전달된다.

상태 관리기(320)는 복합 상태 관리기(330) 및 단순 상태 관리기(340)로 구성되며, 트랜잭션 관리기(350)는 파일 기반 블록 관리기(360)로 구성될 수 있다.

저장소는 상태를 저장하는 복합 상태 데이터베이스(341), 단순 상태 데이터베이스(342) 및 트랜잭션을 저장하는 블록 파일 형태의 블록체인으로 구성될 수 있다.

도 3에는 명시적으로 도시되지 아니하였으나, 저장소 내의 블록 파일들은 블록 파일들 단위로 인코딩되어 인코딩된 청크들이 생성될 수 있고, 블록체인 노드들은 각각 인코딩된 청크들 중 하나만 그대로 저장하고 나머지는 해쉬값만 저장할 수 있다.

도 4는 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 분산 저장 시스템에서 블록체인 데이터 저장 흐름을 나타낸 도면이다.

도 4를 참조하면, 블록체인 응용 서비스(SDK)는 트랜잭션을 블록체인 노드들 중 서명 노드(Endorsing Node)에 전달한다(S410).

서명 노드(Endorsing Node)는 전달받은 트랜잭션을 노드 내부에서 시뮬레이션하기 위해 스마트 컨트랙트를 수행하고 시뮬레이션 결과를 생성(S420)한후, 생성된 시뮬레이션 결과를 응용 서비스에 전달한다(S430).

응용 서비스는 시뮬레이션 결과를 포함한 트랜잭션을 블록 생성 노드(Ordering Service Node)에 제출한다(S440).

블록 생성 노드(Ordering Service Node)는 제출된 트랜잭션들을 모아서 트랜잭션들 사이의 순서를 정하고 블록을 구성한다(S450).

블록이 구성되면 이는 모든 블록 저장 노드들(Committing Nodes)에 전달된다(S460).

각각의 블록 저장 노드(Committing Node)는 전달받은 블록 내의 트랜잭션들 각각을 검증하고 노드 내의 저장소에 저장(commit)한다(S470). 이 때, 블록체인(트랜잭션 데이터의 이력)과 상태 데이터에 변경이 발생한다. 새로운 트랜잭션은 블록 형태로 기존 블록체인의 뒷부분에 기록되고, 기존 상태 데이터는 새로운 값으로 변경된다.

도 4에 도시된 예에서, 서명 노드(Endorsing Node)는 서명 노드로서의 역할뿐만 아니라 동시에 블록 저장 노드(Committing Node)의 역할도 수행할 수 있다.

도 5는 블록 파일 저장 개념을 나타낸 블록도이다.

도 5를 참조하면, 블록(트랜잭션 데이터의 묶음)이 생성되고, 생성된 블록은 각 노드들로 배포되고, 각 노드들에서 파일 시스템 기반 블록 파일 형태로 저장되는 것을 알 수 있다.

즉, 도 4에 도시된 블록체인 데이터 저장 흐름에서 블록 생성 노드에 의해 새로운 블록이 생성되면, 블록 저장 노드에 배포되어 블록 파일 형태로 저장된다. 이는 블록 마이닝 과정으로 볼 수 있다.

블록 저장 노드는 전달 받은 블록을 별도의 파일에 저장하지 않고, 일정한 크기의 블록 파일 형태로 모아서 저장한다. 따라서, 하나의 블록 파일은 여러 개의 블록들을 포함하게 된다. 이 때, 블록체인 데이터의 일관성을 위해 각 블록 저장 노드가 동일한 블록 및 블록 파일을 중복해서 관리할 수 있으나 이 경우 저장공간 부족 문제가 발생할 수 있다.

도 6은 파일 시스템에 블록을 블록 파일 형태로 저장한 블록 파일 목록의 일 예를 나타낸 도면이다.

도 6을 참조하면, 비트코인의 블록은 모든 노드에서 ~/.bitcoin/blocks 디렉토리에 blkNNNNN.dat 블록 파일에 저장되는 것을 알 수 있다. 블록들은 blk00000.dat 블록 파일로부터 시작해서 저장되고, 각 블록 파일이 최대 크기가 되면, 다음 파일에 저장된다. 예를 들어, 비트코인의 블록의 크기는 평균 1MB이고, 블록 파일의 최대 크기는 MAX_BLOCKFILE_SIZE로 정의되며, 기본 값(default value)은 128MiB (134,271,728 바이트)일 수 있다. 예를 들어, 하이퍼레져 패브릭은 비트코인과 유사하게 하나의 블록 파일에 여러 개의 블록들을 모아서 저장한다. 이 때, 최대 블록 파일 크기의 기본 값은 64MB일 수 있다.

도 7은 블록 파일 저장 구조의 일 예를 나타낸 도면이다.

도 7을 참조하면, 블록들이 블록 파일 형태로 저장되는 것을 알 수 있다. 도 7에 도시된 예는 비트코인, 하이퍼레저 패브릭 등의 블록체인 시스템에서 블록 파일들 및 블록 파일들에 저장되는 블록들의 저장 구조를 나타낸 것일 수 있다.

이더리움은 비트코인이나 하이퍼레저 패브릭과 달리 트랜잭션을 기록한 블록을 Transaction Trie에 저장할 수 있다. 이 때, Transaction Trie는 Modified MPT(Merkle Patricia Trie) 형태일 수 있고, MPT는 영속성 보장을 위해 LevelDB RocksDB와 같은 키/밸류 스토어를 이용하여 데이터를 저장할 수 있다.

도 8은 본 발명의 일실시예에 따른 블록 파일 단위 인코딩이 적용되는 경우의 일 예를 나타낸 도면이다. 이 때, 블록 파일 단위 인코딩이 적용되어 데이터 가용성이 보장될 수 있다.

도 8을 참조하면, 텍스트 형태의 입력 데이터(in.txt)는 K+M(K=4, M=2)개의 청크로 인코딩되어 관리될 수 있다.

입력 데이터는 K(=2)개의 동일 크기를 갖는 데이터 청크로 분할되어 저장될 수 있다. 이 때, 데이터 가용성 보장을 위해 M(=2)개의 동일 크기를 갖는 패리티 청크가 생성될 수 있다. 여기서, K는 입력 데이터에 해당하는 데이터 청크들의 수이고, M은 패리티에 해당하는 데이터 청크의 수일 수 있다.

이와 같이 K+M개의 청크들로 인코딩된 데이터는 M개까지의 장애가 발생해도 원본 입력 데이터(in.txt)를 그대로 복원할 수 있는 가용성을 갖게 된다.

즉, 도 8에 도시된 예에서 입력 데이터(in.txt)에 (4,2)의 인코딩이 적용될 수 있다. 이 때, K는 4이고 M은 2이므로 원본 데이터는 4개의 청크들로 분할되고, 가용성 보장을 위한 패리티 청크들은 2개 생성될 수 있다. 총 6개의 청크들은 모두 같은 크기를 가질 수 있다. 만약, 입력 데이터의 크기를 K로 나눈 나머지가 0이 아니면, 마지막 청크(in.txt.3)는 다른 청크들과 동일한 크기를 갖도록 널값(\0) 등의 기설정된 값을 데이터의 뒤에 붙여서 청크들이 모두 같은 크기를 갖도록 패딩(padding)할 수 있다.

이와 같이, 블록 파일 단위로 인코딩된 6개의 청크들은 서로 다른 노드들에 저장될 수 있다. 이 때, 최대 2개까지의 노드들에 장애 또는 비잔틴 상황이 발생되어도(최소 4개의 청크들이 가용) 디코딩을 통하여 원본 데이터(in.txt)와 같은 출력 데이터(out.txt)를 복원할 수 있다. 만약 패리티 청크(in.txt.4, in.txt.5)에만 장애가 발생하고 원본 청크 4개(in.txt.0, in.txt.1, in.txt.2, in.txt.3)가 모두 접근 가능하다면 디코딩 과정을 생략하고, 단순히 원본 청크들을 이어 붙여서 원본 데이터(in.txt)를 복원함으로써 디코딩 시간을 절약할 수도 있다.

도 8의 예와 같이, K가 4이고 M이 2인 경우 하기 표 1과 같은 저장공간 효율성을 갖게 된다. 이 때, 인코딩 방식은 기존에 가용성 보장을 위해서 사용하던 복제 방식(원본의 3배의 저장 공간 사용) 대비 높은 저장공간 효용성(원본의 1.58배의 저장 공간 사용)을 제공함을 알 수 있다.

	복제 방식 (복제 2개)	인코딩 방식 (패리티 2개)
저장 공간사용량	53 바이트 * 3개 = 159 바이트	14 바이트 * 6개 = 84 바이트
저장 공간부하	159 바이트 / 53 바이트 = 3배의 공간 사용	84 바이트 / 53 바이트 = 1.58배 공간 사용

예를 들어, 인코딩은 Reed-Solomon, Cauchy Reed-Solomon, Vandermonde Reed-Solomon, Fountain Code, Local Reconstruction Code(또는 Local Repairable Code) 등 원본 데이터 유지 여부, 저장 공간 효율성, 가용성 정도, 인코딩/디코딩 속도, 재인코딩 필요 여부 등의 측면에서 다양한 서로 다른 특성을 갖는 다양한 방식으로 수행될 수 있다. 본 발명의 블록 파일 인코딩 기반 블록체인 트랜잭션 데이터 분산 저장 방법에서는 다양한 인코딩 방식들 중 하나 이상이 선택되어 사용될 수 있다. 이하, 본 발명은 제안 방법의 이해가 쉽도록 가장 기본적인 인코딩 방식인 Reed-Solomon 방식을 사용하는 예를 중심으로 설명된다.만약, 비잔틴 장애 감내(Byzantine Fault Tolerance) 조건인 K >= 2M+1을 만족하도록 데이터를 블록 파일 단위로 인코딩하여 전체 청크의 개수가 K+M = 3M+1개가 되도록 하여, 각 청크를 K+M = 3M+1개의 노드들에 분할하여 저장한다면, 전체 노드들의 1/3까지의 물리 노드 장애 또는 비잔틴 행위가 발생해도 원본 데이터를 복구할 수 있는 능력, 즉 비잔틴 장애 내성(Byzantine Fault Tolerance, BFT)을 갖게 된다.

반면에, 인코딩을 적용하여 원본 데이터 중 일부 청크만을 각 노드에 저장하게 되면, 해당 노드가 갖고 있지 않은 청크에 접근이 필요한 경우, 다른 노드로부터 데이터를 전송 받아야 하므로 접근 속도 지연 문제가 발생한다. 따라서, 인코딩 방식을 데이터 저장 시스템에 적용하려면 읽기 속도 문제를 고려하여 인코딩을 적용해야 한다.

본 발명은 이와 같은 인코딩 방법의 높은 저장 공간 효율성을 활용하기 위해, 블록 파일 기반으로 블록체인 트랜잭션 데이터 저장을 위한 인코딩을 적용하여, 비잔틴 장애 내성 수준의 높은 가용성을 보장하면서도 각 블록체인 노드에 요구되는 저장공간을 최소화할 수 있다. 특히, 본 발명은 실제 블록체인 시스템의 저장소 특성을 고려하여, 트랜잭션 또는 블록 단위가 아닌 블록 파일 단위의 인코딩을 적용한다.

도 9는 본 발명의 일실시예에 따른 블록 파일 인코딩 기반 블록체인 트랜잭션 데이터 인코딩 방법의 일 예를 나타낸 블록도이다.

도 9를 참조하면, 하나의 블록이 인코딩되거나 단순히 인코딩된 블록 개수와 노드 개수를 맞추도록 인코딩하는 것이 아니라, 블록 파일 단위로 인코딩이 적용되는 것을 알 수 있다.

즉, 본 발명은 블록체인 트랜잭션 데이터 분산 저장을 위해 인코딩을 적용하되, 비트코인이나 하이퍼레저 패블릭과 같이 여러 블록을 하나의 블록 파일에 저장하는 블록체인 시스템의 보편적인 블록 저장 구조를 고려하여 인코딩을 적용한다.

도 9에 도시된 예에서, 블록들은 블록 파일들(BLOCK FILE 0, ..., BLOCK FILE 10, ...)에 저장되며, 하나의 블록 파일에는 다양한 크기를 가지는 다수의 블록들이 저장된다. 예를 들어, 블록 파일 10에는 블록 101 ~ 107까지의 블록들이 저장된다. 각 블록 파일들의 크기는 블록체인 시스템에 설정된 블록 파일 최대 크기 값(예를 들어, 64MB)을 넘지 못한다. 블록체인 시스템에 설정된 블록의 최대 크기, 블록 생성 주기, 블록 생성 시점의 트랜잭션 발생량, 블록 생성 시점에 발생한 트랜잭션들의 크기 등에 따라 서로 다른 크기를 갖는 블록들이 생성될 수 있다.

이 때, 각각의 블록체인 노드는 인코딩된 청크들 중 하나를 할당 받을 수 있다.

도 9의 예에서, 하나의 블록체인 노드는 할당 받은 블록(블록 104)에 대해서는 원본 데이터 블록을 저장하여 관리하며, 할당 받지 않은 블록(블록 101, 102, 103, 105, 106, 107, 패리티 1, 2)에 대해서는 해당 블록의 해시값만 저장하여 관리한다. 이를 통해 각 노드에는 원래 배포 받았던 모든 블록들에 대한 정보가 저장되지만, 인코딩시에 할당 받지 못한 블록에 대해서는 저장공간을 작게 차지하는 해시값만 저장하므로, 저장공간을 절약할 수 있다. 이 때, 해시값은 나중에 해당 블록에 대한 접근이 필요하여 다른 노드로부터 블록을 제공 받을 때, 제공 받은 블록에 대한 조작이 발생했는지 여부를 확인하기 위한 목적으로 활용될 수 있다.

도 9에 도시된 예에서는 하나의 블록 파일에 대해 인코딩이 적용되는 경우를 예로 들었으나, 본 발명의 블록 파일 인코딩 기반 블록체인 트랜잭션 데이터 분산 저장 방법은 블록 개수와 노드 개수를 고려하여 다수개의 블록 파일들에 인코딩을 적용할 수 있다.

다수의 기 저장된 블록파일들 중에서 인코딩을 적용할 블록파일을 선정하는 기준은 다음과 같을 수 있다.

- 가장 자주 접근되지 않는(least frequently accessed) 블록이나 블록 파일을 선정한다.

- 오래된 블록이나 블록 파일을 선정한다.

- 노드 수를 고려하여, 필요시 선정된 블록(블록 파일)과 인접한 블록들이나 블록 파일들을 선정한다.

도 10은 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법을 나타낸 동작 흐름도이다.

도 10을 참조하면, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법은, 블록체인 노드들의 개수(3M+1)를 확인한다(S1015).

또한, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법은, 패리티 청크들의 개수를 M으로 설정한다(S1017)

이 때, 블록체인 노드들의 개수는 3M+1로 설정될 수 있다. 즉, 블록체인 노드들의 개수가 정해지면 이에 따라 적절한 패리티 청크들의 개수가 결정될 수도 있고, 반대로 패리티 청크들의 개수가 결정되면 이에 따라 적절한 블록체인 노드들의 개수가 결정되는 것일 수도 있다.

단계(S1015)에서 노드들의 개수가 N개이면, 트랜잭션 데이터의 비잔틴 장애 보장을 위해서는 N = 3M + 1 조건을 만족하도록 인코딩을 적용해야 하며, 인코딩 시에 M개의 패리티 청크들을 갖도록 인코딩을 해야 한다. 또한, 인코딩 대상 블록들의 개수(K), 즉 인코딩 블록 파일 대상(encoding block file target) 또는 인코딩 블록 파일들에 포함되는 블록들의 개수는 2M+1개이어야 한다.

한편, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법은, 먼저 기저장된 블록 파일들 중 하나를 인코딩 대상 블록 파일로 선정하고 파라미터들(K, prevK)을 초기화한다(S1010).

이 때, 인코딩 대상 블록 파일은 블록체인 트랜잭션들을 저장하는 블록 파일들 중에서 블록 파일들 또는 블록 파일들이 포함되는 블록들에 대한 접근 빈도를 고려하여 선택될 수 있다.

이 때, 파라미터 K는 인코딩 대상 블록 개수를 나타내고, 파라미터 prevK는 이전 블록 파일까지의 인코딩 대상 블록 개수를 나타낼 수 있다.

또한, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법은, 블록 파일 내에 포함된 블록들의 개수(B)를 확인한다(S1020).

이 때, 블록 파일들마다 각각의 블록 파일에 포함된 블록들의 개수는 상이할 수 있다.

또한, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법은, 인코딩 대상 블록들의 개수(K)를 설정한다(S1030).

즉, 단계(S1030)는 해당 블록 파일에 포함된 블록들의 개수가 인코딩 대상 블록들에 포함되도록 하고, 그 개수를 카운트한다.

이 때, 파라미터 prevK는 K로 설정되고, 파라미터 K는 K+B로 설정될 수 있다. 이 때, 파라미터 prevK가 K로 설정되는 것은, 이전 블록 파일까지 계산한 부호화 대상 블록들의 개수(K)를 파라미터 prevK에 저장해두는 것이다.

또한, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법은, 인코딩 대상 블록들의 개수(K)가 2M+1(M은 패리티 청크들의 개수)보다 적은지 여부를 판단한다(S1040).

만약, 인코딩 대상 블록 파일(들)에 포함되는 인코딩 대상 블록들의 개수(K)가 2M+1보다 적으면, 2M+1개의 블록들이 인코딩 대상이 될 수 있도록 다음 블록 파일의 블록들을 부호화 대상 블록으로 추가되도록 하여 부호화 대상 블록의 개수(K)가 2M+1에 근접하도록 한다(S1045).

단계(S1045)가 수행된 후에는 단계(S1020)가 다시 수행된다.

만약, 인코딩 대상 블록 파일(들)에 포함되는 인코딩 대상 블록들의 개수(K)가 2M+1보다 크거나 같으면, 인코딩 대상 블록 파일(들)에 포함되는 인코딩 대상 블록들의 개수(K)가 2M+1과 동일한지 여부를 판단한다(S1050).

단계(S1050)의 판단 결과, 인코딩 대상 블록 파일(들)에 포함되는 인코딩 대상 블록들의 개수(K)가 2M+1과 동일하면, K=2M+1개의 인코딩 대상 블록들을 모두 인코딩 대상으로 선정한다(S1055).

단계(S1050)의 판단 결과, 인코딩 대상 블록 파일(들)에 포함되는 인코딩 대상 블록들의 개수(K)가 2M+1과 동일하지 않으면, K > 2M+1인 경우이므로 이전 블록 파일까지만 인코딩 블록 파일 대상(encoding block file target)이 되도록 한다(S1060).

이 때, 인코딩 블록 파일 대상은 하나 이상의 정수개의 인코딩 파일들을 나타내는 것일 수 있다.

이와 같이 이전 블록 파일까지만 인코딩 블록 파일 대상이 되면, 인코딩 대상 블록들의 개수가 2M+1개보다 작은 경우이므로, 부족한 블록들의 개수를 채우기 위한 복제 대상 블록(R)을 선정한다(S1070).

이 때, 선정되는 복제 대상 블록들(R)의 개수는 2M+1-K개일 수 있다.

이 때, 복제 대상 블록은 접근 빈도에 기반하여 인코딩 블록 대상 파일에 포함된 블록들 중에서 선택될 수 있다. 예를 들어, 복제 대상 블록은 해당 블록 파일 내의 블록들 중 접근 빈도가 빈번한 순서대로 선정된 블록들일 수 있다.

이와 같이 복제된 블록은 복제되지 않은 블록 대비 읽기 요청시에 해당 블록을 가지고 있는 노드들의 개수가 증가하므로 해당 블록에 대한 부호화가 적용되어도 접근 지연이 덜 발생하고, 결국 블록 접근 시간 증가가 최소화된다.

또한, 본 발명의 일실시예예 따른 블록체인 트랜잭션 데이터 저장 방법은, 선정된 복제 대상 블록을 복제하여 전체 인코딩 대상이 2M+1개가 되도록 한다(S1080).

단계(S1080) 또는 단계(S1055)에 의하여 인코딩 대상 블록들이 2M+1개로 결정되면, 이 인코딩 대상 블록들에 대한 인코딩을 수행하여 M개의 패리티 청크들을 포함하는 인코딩된 청크들을 생성한다(S1090).

이 때, 인코딩 대상 블록들은 사이즈가 모두 동일하지 않을 수 있다. 이 때, 인코딩 대상 블록들은 인코딩된 청크들을 생성하기 전에 최대 블록 사이즈를 기준으로 패딩(padding)될 수 있다.

또한, 본 발명의 일실시예에 따른 블록체인 트랜잭션 데이터 저장 방법은, 인코딩 결과에 해당하는 3M+1개의 청크들을 3M+1개의 전체 블록체인 노드들에 1:1 맵핑시킨다(S1095).

이 때, 블록체인 노드들은 각각 맵핑된 청크만 그대로 저장하고, 다른 청크들은 해시값만을 저장할 수 있다.

결국, 도 10에 도시된 방법을 통해 2M+1개의 인코딩 대상 블록들에 대한 인코딩이 수행되어, 원본 블록(청크)들 2M+1개와 M개의 패리티 청크들을 포함하는 총 3M+1개의 청크들이 생성되고, 이 3M+1개의 청크들은 N=3M+1개의 블록체인 노드들에 할당된다.

도 11은 다수의 블록 파일들을 기반으로 블록체인 트랜잭션 데이터 인코딩이 적용되는 일 예를 나타낸 도면이다.

도 11을 참조하면, 복수의 블록 파일들(BLOCK FILE 10, BLOCK FILE 11, BLOCK FILE 12, ...) 중에서 두 개의 블록 파일들(BLOCK FILE 10, BLOCK FILE 11)에 인코딩이 적용되는 것을 알 수 있다.

도 11에서 K는 원본 블록들을 나타내고, R은 복제 블록들을 나타내고, M은 패리티 청크들을 나타낸다.

도 11에 도시된 예에서 부호화 대상 블록 파일들(BLOCK FILE 10, BLOCK FILE 11)에 포함된 블록들의 개수가 2M+1보다 작고, R개의 복제 대상이 선정되고 복제되어 총 2M+1개의 인코딩 대상 블록들이 결정되고, 2M+1개의 인코딩 대상 블록들에 대한 인코딩이 수행되어 M개의 패리티 청크들이 생성되는 것을 알 수 있다. 이와 같이 인코딩 수행 후 원본 데이터(2M+1개의 데이터 청크들)가 유지되도록 하기 위해 시스터매틱 인코딩(systematic encoding)이 적용될 수 있다.

인코딩 결과 총 2M+1개의 원본 데이터 청크들 및 M개의 패리티 청크들을 포함한 3M+1개의 인코딩된 청크들이 생성된다.

도 12는 본 발명의 일실시예에 따른 인코딩 대상 블록 파일 선정 방법을 나타낸 동작 흐름도이다.

본 발명의 일실시예에 따른 인코딩 대상 블록 파일 선정 방법은 트랜잭션, 블록 또는 블록 파일이 생성될 때 바로 적용되지 않고, 블록체인 시스템 내의 전체 저장 공간의 효율성(E), 블록체인 노드의 계산 자원 및 저장 공간 등을 고려해서 적절한 타이밍에 적용될 수 있다.

또한, 모든 블록들 또는 블록 파일들에 인코딩이 적용되지 않고, 접근 빈도가 떨어지는 블록 파일들(또는 블록들)을 선정하고 블록체인 시스템의 계산 자원 부하(L)가 크지 않을 경우에만 선정된 블록 파일들(또는 블록들)에 인코딩을 수행할 수 있다. 만약 블록체인 시스템의 계산 자원 부하(L)가 큰 상황이어도, 전체 저장 공간 효율성이 많이 떨어진 상태이면, 저장 공간 확보를 위해 인코딩이 수행(S1290)될 수 있다.

도 12를 참조하면, 본 발명의 일실시예에 따른 인코딩 대상 블록 파일 선정 방법은, 블록체인 시스템 내의 전체 저장 공간 효율성(E)을 계산한다(S1210).

또한, 본 발명의 일실시예에 다른 인코딩 대상 블록 파일 선정 방법은, 계산된 저장 공간 효율성이 기설정된 비교값(threshold_E)보다 작은지 여부를 판단한다(S1220).

단계(S1220)의 판단 결과, 저장 공간 효율성이 기설정된 비교값보다 작지 않은 경우에는 저장 공간 확보가 불필요하므로 동작을 종료한다.

단계(S1220)의 판단 결과, 저장 공간 효율성이 기설정된 비교값보다 작은 경우에는 블록 접근 빈도(B)가 수집된다(S1230).

또한, 저장 공간 효율성이 기설정된 비교값보다 작은 경우에는 블록 파일 접근 빈도(F)가 계산된다(S1240).

또한, 본 발명의 일실시예에 따른 인코딩 대상 블록 파일 선정 방법은, 블록 접근 빈도(B) 및 블록 파일 접근 빈도(F) 중 하나 이상을 이용하여 블록 파일들을 접근 빈도순으로 정렬한다(S1250).

또한, 본 발명의 일실시예에 따른 인코딩 대상 블록 파일 선정 방법은, 정렬된 블록 파일들을 이용하여 저빈도 접근 블록 파일을 선정한다(S1260).

이 때, 저빈도 접근 블록 파일은 블록 파일에 포함된 블록들에 대한 접근 빈도가 기설정된 기준값(threshold_F)보다 작은지 여부를 이용하여 선정될 수 있다.

또한, 본 발명의 일실시예에 따른 인코딩 대상 블록 파일 선정 방법은, 블록체인 시스템의 계산 자원 부하(L)를 계산한다(S1270).

또한, 본 발명의 일실시예에 따른 인코딩 대상 블록 파일 선정 방법은, 계산된 계산 자원 부하(L)가 기설정된 기준값(threshold_L)보다 작은지 여부를 판단한다(S1280).

단계(S1280)의 판단 결과, 계산 자원 부하가 기준값(threshold_L)보다 작으면 인코딩을 수행한다(S1290).

단계(S1280)의 판단 결과, 계산 자원 부하가 기준값(threshold_L)보다 작지 않으면 전체 저장 공간 효율성을 다시 계산한다(S1285).

또한, 본 발명의 일실시예에 따른 인코딩 대상 블록 파일 선정 방법은, 계산된 전체 저장 공간 효율성이 제2 기준값(threshold_S)보다 작은지 여부를 판단하고(S1287), 전체 저장 공간 효율성이 제2 기준값보다 작은 경우에만 단계(S1290)로 진행하여 인코딩을 수행하고, 전체 저장 공간 효율성이 제2 기준값보다 작지 않은 경우에는 전체 저장 공간 효율성이 심하게 떨어진 상태가 아니므로 동작을 종료한다.

본 발명의 일실시예에 따른 블록 파일 인코딩 기반 블록체인 트랜잭션 데이터 분산 저장 방법이 사용되면, 분산 저장된 블록에 대한 접근이 필요한 경우, 일반적으로 디코딩 과정이 필요 없이 해당 블록을 그대로 가지고 있는 노드를 통해서 원하는 블록을 제공 받을 수 있다.

도 9를 통해 설명한 바와 같이, 모든 블록체인 노드들은 블록 파일 부호화 기반 블록체인 트랜잭션 데이터 인코딩을 통해 할당 받지 않은 블록에 대해서도 해시값을 가지고 있기 때문에, 다른 노드가 제공한 블록의 조작 여부를 확인할 수 있다. 블록에 따라, 모든 블록들의 크기가 동일해지도록 하기 위해 추가로 저장된 패딩 부분은 제거하는 과정이 필요할 수 있다.

도 13은 본 발명의 일실시예에 따른 블록 접근 방법의 일 예를 나타낸 동작 흐름도이다.

도 13을 참조하면, 본 발명의 일실시예에 따른 블록 접근 방법은 요청된 블록(청크)을 해당 노드가 보유하고 있는지 여부를 확인한다(S1310).

단계(S1310)의 확인 결과, 요청된 블록을 해당 노드가 보유하고 있으면 저장된 블록에서 불필요한 패딩을 제거하고(S1320), 요청된 블록 데이터를 요청자에게 제공한다(S1330).

단계(S1310)의 확인 결과, 요청된 블록을 해당 노드가 보유하고 있지 않으면 요청된 블록을 보유한 노드가 확인된다(S1311).

요청된 블록을 보유한 노드가 확인되면 해당 노드에 요청된 블록을 요청하고(S1313), 블록을 전송 받은 후(S1315), 전송 받은 블록의 해시값을 체크한다(S1317). 즉, 단계(S1317)는 전송 받은 블록의 해시값을 구하고, 구해진 해시값과 기저장된 해시값을 비교한다.

또한, 본 발명의 일실시예에 따른 블록 접근 방법은 전송 받은 블록의 해시값에 이상이 있는지 여부를 체크하여 이상이 없으면 단계(S1320)로 진행하여 불필요한 패딩을 제거한 후에 블록 데이터를 제공하고, 이상이 있으면 기설정된 횟수만큼 재시도를 수행한다(S1319).

즉, 본 발명의 일실시예에 따른 블록 접근 방법은, 다른 노드로부터 제공 받은 블록의 해시값과 노드가 보유한 해시값이 동일하지 않으면 해당 블록을 보유한 다른 노드로부터 다시 블록을 제공받는다. 만일 여러 번 재시도를 해서 모든 보유 노드로부터 블록을 받았는데 모든 노드로부터 받은 블록에 기반하여 계산된 해시값들에 모두 이상이 있으면 동작을 종료하고, 후술할 디코딩 및 재인코딩 절차를 거친 후 블록 접근을 다시 시작할 수 있다.

도 14는 본 발명의 일실시예에 따른 블록 오류를 발견한 노드의 재인코딩 방법의 일 예를 나타낸 동작 흐름도이다.

도 14를 참조하면, 인코딩된 블록들(청크들) 중 적어도 하나에 문제(저장 노드 장애 또는 비잔틴 행위 수행)가 발생하는 경우, 디코딩 절차가 수행되는 것을 알 수 있다.

즉, 블록 오류가 발견되면(S1410), 모든 노드들에 재인코딩이 요청된다(S1420).

물론, 인코딩된 블록들(청크들) 중 적어도 하나에 문제(저장 노드 장애 또는 비잔틴 행위)가 발생하지 않으면 도 13에 도시된 과정을 통해 디코딩 과정 없이 원하는 블록을 바로 읽을 수 있다.

하지만 데이터 블록에 장애가 발생하면 재인코딩 과정을 통해서 블록을 복원할 필요가 있을 수 있다.

도 15는 본 발명의 일실시예에 따른 재인코딩 요청을 수신한 노드의 재인코딩 방법의 일 예를 나타낸 동작 흐름도이다.

도 15를 참조하면, 블록체인 노드들이 재인코딩 요청을 수신한다(S1510).

재인코딩 요청을 수신한 블록체인 노드들은 재인코딩 합의를 수행하고(S1520), 합의가 실패하면 동작을 종료한다.

합의가 성공하면, 재인코딩 요청을 수신한 블록체인 노드들은 각각 다른 노드들로부터 미보유 블록(청크)들을 수신하고(S1540), 수신한 블록들의 해시값을 확인한다(S1550).

해시값에 이상이 없으면 블록체인 노드들은 디코딩을 수행하고(S1560), 디코딩을 통해 얻은 데이터를 다시 인코딩하여 인코딩된 청크들을 다시 생성한다(S1570).

기존 블록체인 노드들 이외에 새로운 노드들이 블록체인 네트워크에 참여하게 되면, 노드 수(N)가 달라지게 되고 이에 따라 기존 인코딩된 청크들이 저장된 상태로는 BFT 보장이 불가능해질 수 있다. 본 발명에서는 다양한 인코딩 방법을 활용하여 불록 파일 기반 블록체인 트랜잭션 데이터 인코딩이 가능하며, 활용되는 인코딩 방법에 따라서는 재인코딩이 필요 없는 인코딩 방법도 있고, 복제 개수를 추가하여 BFT를 보장해야 하는 인코딩 방법도 있다. 경우에 따라서는 도 15를 통해 설명된 재인코딩을 수행해야 BFT가 보장될 수도 있다.

반대로 블록체인 네트워크에 참여 중이던 노드가 탈퇴하거나 장애가 발생하면 해당 노드가 저장 및 관리하던 블록에 대한 접근이 불가능해지는 문제가 발생할 수 있다. 활용되는 인코딩 방법에 따라 그리고 해당 노드가 관리하던 블록에 따라 이러한 경우에도 여전히 BFT를 보장할 수 있는 인코딩 방법도 있고, 또는 관련 블록을 복제하거나 도 15를 통해 설명된 재인코딩을 수행해야 BFT가 보장될 수도 있다.

도 16은 본 발명의 일실시예에 따른 블록 체인 트랜잭션 데이터 분산 저장 시스템에서 고빈도 접근 블록체인 트랜잭션 데이터의 복제를 나타낸 도면이다.

도 16을 참조하면, 블록체인 네트워크에서 워크로드의 변화에 따라 노드 수의 변화 없이 자주 접근되는 블록이 변하면, 해당 블록의 복제 개수를 늘려서 해당 블록에 대한 접근 지연을 최소화할 수 있는 것을 알 수 있다.

지금까지 설명한 본 발명의 구성 및 동작 방식은 참여 노드의 1/3까지 장애 보장을 위한 BFT 보장 방법뿐만 아니라, 보다 가용성 보장이 강하거나 약한 다양한 보장 수준을 위해서도 활용 및 적용이 가능하다.

이와 같이 본 발명의 블록 파일 기반 인코딩이 적용되면, 대규모 블록체인 트랜잭션 데이터를 저장하는 블록체인 시스템에서 각 노드에 저장되는 데이터 용량을 줄여서 전체 블록체인 네트워크의 저장 공간 효율성을 향상시키고, 보다 적은 노드들로 대규모의 블록체인 트랜잭션 데이터를 저장 관리할 수 있다.

또한, 본 발명의 블록 파일 기반 인코딩을 이용한 블록체인 분산 저장 기술은 블록체인 트랜잭션 데이터를 파일 시스템 상에 저장 관리하는 일반적인 형태의 블록체인 플랫폼에 널리 적용될 수 있다.

도 17은 본 발명의 일실시예에 따른 컴퓨터 시스템 구성을 나타낸 블록도이다.

실시예에 따른 블록체인 트랜잭션 데이터 저장 장치 및 블록체인을 구성하는 노드들은 컴퓨터로 읽을 수 있는 기록매체와 같은 컴퓨터 시스템(1700)에서 구현될 수 있다.

컴퓨터 시스템(1700)은 버스(1720)를 통하여 서로 통신하는 하나 이상의 프로세서(1710), 메모리(1730), 사용자 인터페이스 입력 장치(1740), 사용자 인터페이스 출력 장치(1750) 및 스토리지(1760)를 포함할 수 있다. 또한, 컴퓨터 시스템(1700)은 네트워크(1780)에 연결되는 네트워크 인터페이스(1770)를 더 포함할 수 있다. 프로세서(1710)는 중앙 처리 장치 또는 메모리(1730)나 스토리지(1760)에 저장된 프로그램 또는 프로세싱 인스트럭션들을 실행하는 반도체 장치일 수 있다. 메모리(1730) 및 스토리지(1760)는 휘발성 매체, 비휘발성 매체, 분리형 매체, 비분리형 매체, 통신 매체, 또는 정보 전달 매체 중에서 적어도 하나 이상을 포함하는 저장 매체일 수 있다. 예를 들어, 메모리(1730)는 ROM(1731)이나 RAM(1732)을 포함할 수 있다.

이 때, 메모리(1730)에는 적어도 하나의 프로그램이 기록될 수 있다.

이 때, 프로세서(1710)는 상기 프로그램을 실행할 수 있다. 이 때, 상기 프로그램은 블록체인 트랜잭션들을 저장하는 적어도 하나의 블록 파일(block file)을 인코딩 블록 파일 대상(encoding block file target)으로 선택하고, 상기 인코딩 블록 파일 대상을 이용하여 패리티 청크들을 포함하는 인코딩된 청크들을 생성하고, 상기 인코딩된 청크들 중 적어도 하나와, 상기 인코딩된 청크들 중 적어도 하나를 저장할 블록체인 노드들 중 적어도 하나를 대응시킬수 있다.

이 때, 상기 프로그램은 상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하는지 여부를 판단하고, 상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하지 않는 경우, 상기 인코딩 블록 파일 대상에 포함된 블록들 및 상기 인코딩 블록 파일 대상에 포함된 블록들 중 일부인 복제 블록을 이용하여 2M+1개의 인코딩 대상 블록들을 생성할 수 있다. 이 때, 상기 인코딩된 청크들은 상기 인코딩 대상 블록들을 이용한 인코딩을 수행하여 생성될 수 있다.

이상에서와 같이 본 발명에 따른 블록체인 트랜잭션 데이터 저장 방법, 장치 및 블록체인 트랜잭션 데이터 분산 저장 시스템은 상기한 바와 같이 설명된 실시예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상기 실시예들은 다양한 변형이 이루어질 수 있도록 각 실시예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.

1700: 컴퓨터 시스템 1710: 프로세서
1720: 버스 1730: 메모리
1731: 롬 1732: 램
1740: 사용자 인터페이스 입력 장치
1750: 사용자 인터페이스 출력 장치
1760: 스토리지 1770: 네트워크 인터페이스
1780: 네트워크

Claims

블록체인 트랜잭션 데이터 저장 장치에 의하여 수행되는 블록체인 트랜잭션 데이터 저장 방법에 있어서,
블록체인 트랜잭션들을 저장하는 적어도 하나의 블록 파일(block file)을 인코딩 블록 파일 대상(encoding block file target)으로 선택하는 단계;
상기 인코딩 블록 파일 대상을 이용하여 패리티 청크들을 포함하는 인코딩된 청크들을 생성하는 단계; 및
상기 인코딩된 청크들 중 적어도 하나와, 상기 인코딩된 청크들 중 적어도 하나를 저장할 블록체인 노드들 중 적어도 하나를 대응시키는 단계
를 포함하는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
청구항 1에 있어서,
상기 패리티 청크들은 M(M은 자연수)개이고, 상기 블록체인 노드들은 3M+1개이고, 상기 인코딩된 청크들은 3M+1개이고, 상기 인코딩된 청크들과 상기 블록체인 노드들은 1:1 대응되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
청구항 2에 있어서,
상기 블록체인 노드들 각각은
상기 인코딩된 청크들 중 상응하는 한 개를 위해서는 인코딩된 청크를 그대로 저장하고, 상기 한 개를 제외한 나머지 청크들 중 적어도 일부를 위해서는 해쉬값만 저장하는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
청구항 3에 있어서,
상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하는지 여부를 판단하는 단계; 및
상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하지 않는 경우, 상기 인코딩 블록 파일 대상에 포함된 블록들 및 상기 인코딩 블록 파일 대상에 포함된 블록들 중 일부인 복제 블록을 이용하여 2M+1개의 인코딩 대상 블록들을 생성하는 단계
를 더 포함하고,
상기 인코딩된 청크들은 상기 인코딩 대상 블록들을 이용한 인코딩을 수행하여 생성되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
청구항 4에 있어서,
상기 복제 블록은
접근 빈도에 기반하여 상기 인코딩 블록 파일 대상에 포함된 블록들 중에서 선택되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
청구항 2에 있어서,
상기 인코딩 블록 파일 대상은
2M+1개를 초과하지 않는 개수의 블록들을 포함하는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
청구항 6에 있어서,
2M+1개를 초과하지 않는 개수의 블록들은,
사이즈가 모두 동일하지 않고, 상기 인코딩된 청크들을 생성하기 전에 최대 블록 사이즈를 기준으로 패딩되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
청구항 1에 있어서,
상기 인코딩 블록 파일 대상은
상기 블록체인 트랜잭션들을 저장하는 블록 파일들 중에서, 상기 블록 파일들 또는 상기 블록 파일들이 포함하는 블록들에 대한 접근 빈도들을 고려하여 선택되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
청구항 3에 있어서,
상기 해쉬값은
다른 노드에서 읽어온 블록을 검증하는데 사용되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
청구항 4에 있어서,
상기 인코딩된 청크들 중 2M+1개 이상은
상기 인코딩 대상 블록들을 복원하는 디코딩에 사용되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 방법.
하나 이상의 프로세서; 및
상기 하나 이상의 프로세서에 의해 실행되는 적어도 하나 이상의 프로그램을 저장하는 실행메모리를 포함하고,
상기 적어도 하나 이상의 프로그램은
블록체인 트랜잭션들을 저장하는 적어도 하나의 블록 파일(block file)을 인코딩 블록 파일 대상(encoding block file target)으로 선택하고,
상기 인코딩 블록 파일 대상을 이용하여 패리티 청크들을 포함하는 인코딩된 청크들을 생성하고,
상기 인코딩된 청크들 중 적어도 하나와, 상기 인코딩된 청크들 중 적어도 하나를 저장할 블록체인 노드들 중 적어도 하나를 대응시키는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 장치.
청구항 11에 있어서,
상기 패리티 청크들은 M(M은 자연수)개이고, 상기 블록체인 노드들은 3M+1개이고, 상기 인코딩된 청크들은 3M+1개이고, 상기 인코딩된 청크들과 상기 블록체인 노드들은 1:1 대응되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 장치.
청구항 12에 있어서,
상기 블록체인 노드들 각각은
상기 인코딩된 청크들 중 상응하는 한 개를 위해서는 인코딩된 청크를 그대로 저장하고, 상기 한 개를 제외한 나머지 청크들 중 적어도 일부를 위해서는 해쉬값만 저장하는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 장치.
청구항 13에 있어서,
상기 적어도 하나 이상의 프로그램은
상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하는지 여부를 판단하고,
상기 인코딩 블록 파일 대상에 포함된 블록들의 개수가 2M+1에 상응하지 않는 경우, 상기 인코딩 블록 파일 대상에 포함된 블록들 및 상기 인코딩 블록 파일 대상에 포함된 블록들 중 일부인 복제 블록을 이용하여 2M+1개의 인코딩 대상 블록들을 생성하고,
상기 인코딩된 청크들은 상기 인코딩 대상 블록들을 이용한 인코딩을 수행하여 생성되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 장치.
청구항 14에 있어서,
상기 복제 블록은
접근 빈도에 기반하여 상기 인코딩 블록 파일 대상에 포함된 블록들 중에서 선택되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 장치.
청구항 12에 있어서,
상기 인코딩 블록 파일 대상은
사이즈가 모두 동일하지 않은 블록들을 포함하고,
상기 사이즈가 모두 동일하지 않은 블록들은
상기 인코딩된 청크들을 생성하기 전에 최대 블록 사이즈를 기준으로 패딩되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 장치.
청구항 11에 있어서,
상기 인코딩 블록 파일 대상은
상기 블록체인 트랜잭션들을 저장하는 블록 파일들 중에서, 상기 블록 파일들 또는 상기 블록 파일들이 포함하는 블록들에 대한 접근 빈도들을 고려하여 선택되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 장치.
청구항 13에 있어서,
상기 해쉬값은
다른 노드에서 읽어온 블록을 검증하는데 사용되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 장치.
청구항 14에 있어서,
상기 인코딩된 청크들 중 2M+1개 이상은
상기 인코딩 대상 블록들을 복원하는 디코딩에 사용되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 저장 장치.
인코딩된 청크들 중 제1 청크를 그대로 저장하고, 상기 제1 청크를 제외한 나머지 청크들에 상응하는 해쉬값들을 저장하는 제1 블록체인 노드; 및
상기 제1 청크와 상이한 제2 청크를 그대로 저장하고, 상기 제2 청크를 제외한 나머지 청크들에 상응하는 해쉬값들을 저장하는 제2 블록체인 노드를 포함하고,
상기 인코딩된 청크들은, 각각 블록체인 트랜잭션들을 저장하는 블록 파일들(block files) 중에서 선택된 인코딩 블록 파일 대상(encoding block file target)을 이용하여 수행된 인코딩에 기반하여 생성되는 것을 특징으로 하는 블록체인 트랜잭션 데이터 분산 저장 시스템.