KR20220017926A

KR20220017926A - 블록체인 캐시 시스템

Info

Publication number: KR20220017926A
Application number: KR1020217040250A
Authority: KR
Inventors: 창구 강
Original assignee: 플라나리아 코프.
Priority date: 2019-05-14
Filing date: 2020-05-12
Publication date: 2022-02-14
Also published as: CN114096962A; JP2022532623A; CA3137742A1; EP3970034A1; US20220129381A1; EP3970034A4; AU2020274505A1; WO2020232012A1

Abstract

본 개시내용은 블록체인으로부터 데이터를 취득하기 위한 시스템, 방법, 및 컴퓨터 프로그램 제품을 제공한다. 예시적인 시스템은 캐시 스토리지 및 블록체인 크롤러를 포함한 캐시 엔진을 포함할 수 있다. 블록체인 크롤러는 블록체인으로부터 블록체인 데이터를 취득하고 블록체인 데이터의 서브세트를 캐시 스토리지에 기입하도로 구성될 수 있다. 블록체인 데이터의 서브세트는 캐시 엔진에 의해 생성된 쿼리를 만족시킬 수 있다. 시스템은 캐시 엔진에 통신 가능하게 결합된 블록체인 쿼리 서비스를 더 포함할 수 있다. 블록체인 쿼리 서비스는 상태 스토리지 및 캐시 크롤러를 포함할 수 있다. 캐시 크롤러는 캐리 스토리지로부터 캐시 데이터를 취득하고 적어도 캐시 데이터에 기초하여 상태 스토리지의 상태를 업데이트하도록 구성될 수 있다.

Description

블록체인 캐시 시스템

[교차 참조]

본 출원은 2019년 5월 14일에 출원한 미국 가특허출원 번호 제62/847,591호에 대해 우선권을 주장하며, 이 우선권 출원은 그 전체가 참조로 본 명세서에 포함된다.

블록체인은 암호화를 사용하여 연결된 데이터 블록의 목록이다. 각 블록은 목록 내의 이전 블록의 해시, 타임스탬프, 및 트랜잭션 데이터를 포함할 수 있다. 특정 블록 내의 데이터를 변경하려면 블록체인 내의 모든 후속 블록을 변경하는 것이 필요하며, 그래서 이러한 후속 블록의 합의를 필요로 할 수 있다. 이러한 이유로 블록체인은 데이터를 안전하게 저장할 수 있는 바람직한 매체가 될 수 있다. 그렇지만 블록체인은 조회(querying)에 최적화되지 못할 수도 있다. 블록체인 소프트웨어가 JSON-RPC(JavaScript Objection Notation-RPC) 같은 내장형 쿼리 메커니즘을 포함할 수 있지만 이러한 메커니즘은 원시적이며 블록체인 조회에 제한된 방법만을 제공할 수 있다. 예를 들어, 블록체인 트랜잭션을 집계하거나 필터링하는 것이 불가능할 수도 있다. 또한, 이러한 원시 쿼리 메커니즘을 사용하면 블록체인 자체 데이터 구조가 지원하는 즉시 사용 가능한 데이터세트를 리트리빙(retrieve)하는 것은 가능할 수 있지만 블록체인으로부터 계산되거나 파생되는 데이터세트에 대해 제2 계층 상태 머신으로서 조회하는 것은 불가능할 수도 있다. 사용 가능한 쿼리 메커니즘이 제공하는 처리량 수준도 낮을 수 있으며 때때로 블록체인 소프트웨어가 충돌할 수도 있고, 그래서 재인덱싱(re-index)을 위해 블록체인 노드가 오프라인 상태가 될 수도 있다. 재인덱싱에는 호스트 머신 및 충돌의 심각도에 따라 몇 시간, 며칠 또는 몇 주가 걸릴 수도 있다. 이 시간 동안 블록체인은 생산(production)에 사용될 수 없다.

본 개시내용은 블록체인으로부터 데이터를 취득하기 위한 시스템, 방법, 및 컴퓨터 프로그램 제품을 제공한다. 본원에서 설명하는 시스템은 블록체인 쿼리 서비스 및 별도의 캐시 엔진을 가질 수 있다. 캐시 엔진은 블록체인을 크롤링하고 이러한 데이터를 인덱싱된 포맷으로 스토리지에 기입(write)함으로써 블록체인으로부터 데이터를 직접 취득할 수 있다. 그런 다음, 캐시 엔진은 데이터를 복제할 수 있거나 데이터를 다른 캐시 엔진에 브로드캐스트할 수 있다. 또한 캐시 엔진은 데이터를 블록체인 쿼리 서비스에서 사용 가능하게 할 수 있다.

블록체인 쿼리 서비스와 캐시 엔진을 별도로 구현하면 많은 이점을 얻을 수 있다. 두 컴포넌트를 분리시키면 블록체인에 대한 직접 쿼리의 수를 최소화할 수 있고, 그래서 네트워크 대역폭 요건 및 블록체인 충돌 가능성을 줄일 수 있다. 두 컴포넌트를 분리시키면 블록체인 쿼리의 레이턴시도 줄일 수 있다. 기존의 블록체인 쿼리 서비스는 그 상태를 업데이트하고 애플리케이션으로부터의 요청에 응답하기 위해, 실제로 그러한 요청을 완수하는 데에 블록체인 데이터의 소규모의 서브세트만 필요한 경우에도, 전체 블록체인을 직접 스크래핑해야 할 수도 있다. 이 프로세스는 불필요한 레이턴시를 도입할 수 있다. 반면, 본원에서 설명하는 캐시 엔진은 조회에 도움이 되는 인덱싱된 포맷으로 블록체인 데이터를 저장할 수 있다. 블록체인 데이터를 인덱싱함으로써, 캐시 엔진은 다수의 상이한 유형의 블록체인 쿼리 서비스에서 블록체인 데이터를 더 빠르고 더 용이하게 사용 가능하게 할 수 있다.

일 양태에 있어서, 본 개시내용은 블록체인 데이터를 취득하기 위한 방법을 제공한다. 방법은 (i) 캐시 스토리지 및 블록체인 크롤러를 포함한 캐시 엔진 및 (ii) 캐시 엔진에 통신 가능하게 결합된 블록체인 쿼리 서비스를 포함하는 블록체인 시스템을 제공하는 단계를 포함할 수 있다. 블록체인 쿼리 서비스는 상태 스토리지 및 캐시 크롤러를 포함할 수 있다. 방법은 블록체인 크롤러를 사용하여, 블록체인으로부터 블록체인 데이터를 취득하고 블록체인 데이터의 서브세트를 캐시 스토리지에 기입하거나 블록체인 데이터의 서브세트에 기초하여 캐시 스토리지의 상태를 업데이트하는 단계를 더 포함할 수 있다. 블록체인 데이터의 서브세트는 캐시 엔진에 의해 생성된 쿼리를 만족시킬 수 있다. 방법은 캐시 크롤러를 사용하여, 캐시 스토리지로부터 캐시 데이터를 취득하고 적어도 캐시 데이터에 기초하여 상태 스토리지의 상태를 업데이트하는 단계를 더 포함할 수 있다.

일부 실시형태에서, 블록체인 데이터의 서브세트는 블록체인 데이터 전부를 포함한다. 일부 실시형태에서, 블록체인 쿼리 서비스는 서버를 포함하고, 방법은 서버를 사용하여, 상태 스토리지의 상태를 하나 이상의 애플리케이션에 전달하는 단계를 더 포함한다. 일부 실시형태에서, 블록체인 쿼리 서비스는 블록체인으로부터 데이터를 직접 취득하지 않는다. 일부 실시형태에서, 방법은 (c) 쿼리 요청(query request) 또는 구독 요청(subscription request)을 캐시 엔진에 전송함으로써 캐시 스토리지로부터 캐시 데이터를 취득하는 단계를 포함한다. 일부 실시형태에서, 쿼리는 블록체인 쿼리 서비스로부터의 쿼리 요청 또는 구독 요청에 적어도 부분적으로 기초할 수 있다. 일부 실시형태에서, 쿼리는 캐시 스토리지의 현재 상태에 적어도 부분적으로 기초할 수 있다. 일부 실시형태에서, 쿼리는 블록체인에서 취득할 복수의 블록을 지정한다. 일부 실시형태에서, 방법은 캐시 엔진을 사용하여, 블록체인 데이터의 서브세트를 캐시 스토리지에 기입할 때에 캐시 업데이터 이벤트를 전송하는 단계를 더 포함한다. 일부 실시형태에서, 쿼리는 일회성 쿼리이다. 일부 실시형태에서, 쿼리는 구독이다. 일부 실시형태에서, 구독은 만족시 블록체인 크롤러로 하여금 블록체인으로부터 데이터를 취득하게 하는 조건을 포함한다. 일부 실시형태에서, 조건은 시간 또는 빈도를 포함한다. 일부 실시형태에서, 조건은 블록체인에 대한 이벤트를 포함한다. 일부 실시형태에서, (b)는 블록체인 데이터의 서브세트를 인덱싱된 포맷으로 캐시 스토리지에 기입하는 단계를 포함한다. 일부 실시형태에서, 인덱싱된 포맷은 파일 시스템, 데이터베이스, 또는 인메모리(in-memory) 스토리지이다. 일부 실시형태에서, 블록체인 크롤러는 상태 전환 엔진을 포함하고, 상태 전환 엔진은 블록체인 데이터의 서브세트를 캐시 스토리지에 기입한다. 일부 실시형태에서, (b)는 상태 전환 엔진을 사용하여, 블록체인 데이터의 서브세트를 생성하기 위해 블록체인 데이터를 정규화, 인코딩, 디코딩, 직렬화, 역직렬화, 변환, 또는 필터링하는 단계를 포함한다. 일부 실시형태에서, 캐시 스토리지는 최대한 블록체인의 전체 콘텐츠의 서브세트를 저장하도록 구성된다. 일부 실시형태에서, 방법은 지정된 시간 프레임 외부에서 발생한 트랜잭션에 해당하는 블록체인 데이터를 캐시 스토리지로부터 프루닝(pruning)하는 단계를 더 포함한다. 일부 실시형태에서, 블록체인 쿼리 서비스는 복수의 블록체인 쿼리 서비스 중 하나이고, 복수의 블록체인 쿼리 서비스 각각은 캐시에 통신 가능하게 결합된다. 일부 실시형태에서, 복수의 블록체인 쿼리 서비스는 블록체인으로부터 데이터를 직접 취득하지 않는다. 일부 실시형태에서, 방법은 블록체인 크롤러를 포함하지 않는 복수의 추가 캐시 엔진을 제공하는 단계, 및 캐시 엔진의 블록체인 크롤러를 사용하여, 블록체인 데이터의 서브세트를 복수의 추가 캐시 엔진에 기입하는 단계를 더 포함한다. 일부 실시형태에서, 복수의 추가 캐시 엔진 각각은 적어도 하나의 추가 블록체인 쿼리 서비스에 통신 가능하게 결합된다. 일부 실시형태에서, 방법은 추가 캐시 엔진을 제공하는 단계를 더 포함하고, 블록체인 쿼리 서비스는 추가 캐시 엔진에 통신 가능하게 결합된다. 일부 실시형태에서, 추가 캐시 엔진은 추가 캐시 스토리지를 포함하고, 캐시 스토리지 및 추가 캐시 스토리지는 동일한 데이터를 저장한다. 일부 실시형태에서, 추가 캐시 엔진은 추가 캐시 스토리지를 포함하고, 캐시 스토리지 및 추가 캐시 스토리지는 상이한 데이터를 저장한다. 일부 실시형태에서, 방법은 캐시 엔진에 통신 가능하게 결합된 캐시 레지스트리(cache registry)를 제공하는 단계; 및 캐시 엔진에 관한 메타데이터를 캐시 레지스트리에 저장하는 단계를 더 포함하고, 캐시 엔진에 관한 메타데이터는 블록체인 쿼리 서비스를 포함한 복수의 블록체인 쿼리 서비스에 의해 액세스 가능하다. 일부 실시형태에서, 메타데이터는 캐시 엔진의 고유 식별자를 포함한다. 일부 실시형태에서, 메타데이터는 캐시 엔진이 제공하는 서비스의 유형을 정의한다.

본 개시내용의 다른 양태는 머신 실행 가능 코드를 포함한 비일시적 컴퓨터 판독 가능 매체를 제공하고, 머신 실행 가능 코드는 전술한 방법 또는 본원의 다른 곳에서 설명하는 방법의 임의의 방법을 구현한다.

본 개시내용의 다른 양태는 하나 이상의 컴퓨터 프로세서 및 이에 결합된 컴퓨터 메모리를 포함하는 시스템을 제공한다. 컴퓨터 메모리는 하나 이상의 컴퓨터 프로세서에 의한 실행 시에 전술한 방법 또는 본원의 다른 곳에서 설명하는 방법의 임의의 방법을 구현하는 머신 실행 가능 코드를 포함한다.

본원의 추가 양태 및 장점은 이어지는 상세한 설명으로부터 당업자에게 수월하게 명백해질 것이며, 이하의 상세한 설명은 본원의 예시적인 실시형태만 개시하고 설명한다. 인식하고 있겠지만, 본 개시내용은 기타 상이한 실시형태들이 가능하며, 몇몇 상세내용은 전체가 그 개시내용에서 벗어나는 일 없이 다양하고 명백한 양태에서 변형될 수 있다. 따라서, 도면 및 설명은 본래 예시적인 것으로, 그리고 제한적이 아닌 것으로 간주되어야 한다.

[참조문헌 포함]

본 명세서에서 언급하는 모든 공보, 특허, 및 특허문헌은 각각의 개별 공보, 특허, 또는 특허 출원이 참조로써 포함되는 것으로 특정적으로 그리고 개별적으로 표시된 것처럼 동일한 정도로 참조로써 본 명세서에 포함된다. 참고로 포함되는 간행물 및 특허 또는 특허 출원이 본 명세서에 포함된 개시내용과 모순되는 범위에서, 본 명세서는 그러한 임의의 모순되는 자료보다 우위에 있고 그리고/또는 대신하는 것이 의도된다.

본 발명의 신규한 특징은 첨부하는 청구범위에서 구체적으로 설명한다. 본 발명의 특징 및 장점에 대한 더 나은 이해는 본 발명의 원리가 사용되는 예시적인 실시형태에 대해 설명하는 이하의 상세한 설명을 참조함으로써 얻을 수 있으며, 첨부 도면(여기서는 "도"라고 표기함)은 다음과 같다.
도 1은 블록체인 쿼리 서비스를 개략적으로 예시한다.
도 2는 블록체인 캐시 서비스를 개략적으로 예시한다.
도 3은 다수의 블록체인 쿼리 서비스를 서빙하기 위해 다중화되는 블록체인 캐시 시스템을 개략적으로 예시한다.
도 4는 다수의 다른 블록체인 캐시 시스템을 서빙하기 위해 다중화되는 블록체인 캐시 시스템을 예시한다.
도 5는 다수의 캐시 엔진을 서빙하기 위해 다중화되는 블록체인 크롤러를 개략적으로 예시한다.
도 6은 다수의 캐시 엔진에 접속하는 블록케인 쿼리 서비스를 개략적으로 예시한다.
도 7은 캐시 레지스트리 시스템을 개략적으로 예시한다.
도 8은 블록체인을 크롤링하기 위한 프로세스의 흐름도이다.
도 9는 블록체인을 리스닝(listening)하기 위한 프로세스의 흐름도이다.
도 10은 클라이언트와 인터페이싱하기 위한 프로세스의 흐름도이다.
도 11은 캐시 엔진을 크롤링하기 위한 프로세스의 흐름도이다.
도 12는 캐시 엔진을 리스닝하기 위한 프로세스의 흐름도이다.
도 13은 도 2의 블록체인 캐시 시스템의 대안의 실시형태를 개략적으로 예시한다.
도 14는 여기에 제공하는 방법을 구현하도록 프로그래밍되거나 달리 구성되는 컴퓨터 시스템을 개략적으로 예시한다.

여기에 본 발명의 다양한 실시형태를 개시하고 설명하지만, 당업자에게는 이들 실시형태가 예에 불과할 뿐임이 명백할 것이다. 다양한 변형, 변경 및 대체가 본 발명으로부터 벗어나는 일 없이 당업자에게 이루어질 수 있다. 여기에서 설명하는 본 발명의 실시형태에 대한 다양한 대안이 채용될 수 있다고 생각한다.

용어 "적어도", "보다 큼" 또는 "이상"이 2개 이상의 일련의 숫자 값에서 첫 번째 숫자 값 앞에 올 때마다 이 용어 "적어도", "보다 큼" 또는 "이상"은 일련의 숫자 값에 있는 각 숫자 값에 적용된다. 예를 들어, 1, 2 또는 3 이상은 1 이상, 2 이상, 또는 3 이상과 같다.

용어 "보다 크지 않음", "미만", 또는 "이하"가 용어가 2개 이상의 일련의 숫자 값에서 첫 번째 숫자 값 앞에 올 때마다 용어 "보다 크지 않음", "미만", 또는 "이하"는 일련의 숫자 값에 있는 각 숫자 값에 적용된다. 예를 들어, 3, 2 또는 1 이하는 3 이하, 2 이하, 또는 1 이하와 같다.

도 1은 블록체인 쿼리 서비스(102)를 개략적으로 예시한다. 블록체인 쿼리 서비스(102)는 블록체인 크롤러(104) 및 쿼리 엔진(106)을 가질 수 있다. 블록체인 크롤러(104)는 블록체인 클라이언트(108) 및 상태 전환 엔진(110)을 가질 수 있다. 블록체인 크롤러(104)는 블록체인(100)에서 데이터를 크롤링하고 쿼리 엔진(106)의 상태 스토리지(112)에 파퓰레이팅하기 위해 블록체인 클라이언트(108)를 통해 블록체인(100)과 통신할 수 있다. 크롤링은 블록체인 클라이언트(108)에 의해 수행될 수 있다. 블록체인(100)을 크롤링하기 위해, 블록체인 클라이언트(108)는 블록체인(100)과 연관된 애플리케이션 프로그래밍 인터페이스("API")에 요청(예컨대, JSON-RPC(JavaScript Objection Notation-RPC) 요청)을 할 수도 있고, 직접 블록체인(100)의 파일 시스템에 액세스할 수도 있고, 등등의 방식이 있다. 이 프로세스는 인터넷으로부터 데이터를 수집하고 추출하기 위해 웹 서치 엔진에서 폭넓게 사용되는 웹 크롤러를 참조하여 "크롤링(crawling)"이라고 칭해질 수 있다. 블록체인 크롤러는 웹 크롤러와 유사할 수도 있지만, 블록체인 크롤러는 웹 크롤러가 통상 채택하는 다양한 방법을 사용하는 대신에 블록체인의 데이터 구조를 시계열로 크롤링할 수 있다(예컨대 블록 1, 2. 3 및 4로부터 데이터를 시계열로 페칭(fetching)하는 방식으로). 웹 크롤러가 인터넷 데이터의 모든 의미있는 측면을 분석하고 인덱싱하려고 하는 것처럼 블록체인 크롤러(104)도 블록체인(100)으로부터 사용 가능한 모든 데이터 피스(piece)를 수집할 수 있다.

이들 데이터의 피스 모두는 다양한 방식으로 인덱싱될 수 있다. 더욱이, 블록체인 데이터는 완전히 상이한 유형의 가상 데이터베이스 또는 스토리지 시스템을 구축하는 데에도 사용될 수 있다. 예를 들어, 가공전(raw) 블록페인 데이터를 저장하는 대신에, 블록체인 쿼리 서비스(102)는 새로운 블록체인 트랜잭션을 해석하고 저장해야 하는 방식을 지시하는 소정의 규칙을 구현할 수 있다. 그리고 이 규칙 세트를 추종하여, 블록체인 데이터를 입력으로서 사용함으로써 본격적인 상태 머신을 가동하는 것이 가능하다. 이 접근법은 가변 데이터베이스의 작성을 가능하게 할 수 있다. 예를 들어, 블록체인 쿼리 서비스(102)는 "+1", "+2", "-1", 및 "+3" 같은 커맨드를 포함하는 트랜잭션을 처리할 수 있는 상태 머신을 구현할 수 있다. 상태 머신은 이러한 커맨드의 결과로서 상태 "5"를 유지할 수 있다. 블록체인 자체가 불변의 스토리지이지만, 블록체인 쿼리 서비스(102)는 방금 설명한 바와 같이 불변 데이터세트를 활용하여 가변 스토리지에 동력을 제공할 수 있기 때문에 이것은 블록체인의 흥미로운 사용법이다. 데이터가 크롤링을 통해 이용 가능하게 되면, 블록체인 쿼리 서비스는 외부 클라이언트 및 애플리케이션(116)이 쿼리 서비스로부터 데이터를 소비할 수 있도록 이 새로운 스토리지에 대한 쿼리 인터페이스를 구현할 수 있다.

블록체인 클라이언트(108)는 블록체인(100)으로부터 데이터를 페칭한 후에, 미리 프로그래밍된 로직에 따라 데이터를 처리할 수 있는 상태 전환 엔진(110)에 데이터를 전달할 수 있다. 클라이언트(108)로부터 추출된 데이터를 사용하는 것 외에도, 상태 전환 엔진(110)은 상태 스토리지(112)를 업데이트하는 방법을 결정하기 위해 상태 스토리지(112)의 현재 콘텐츠를 사용할 수 있다.

블록체인(100)에서 상태 스토리지(112)에 이르는 워크플로우는 온디맨드로 또는 블록체인(100)으로부터 실시간 이벤트를 리스닝하는 것에 기초하여 실행될 수 있다. 예를 들어, 블록체인 클라이언트(108)는 블록체인(100)에 의해 방출된 모든 시스템 이벤트(예컨대, ZeroMQ® 메시지)를 리스닝하고 전술한 블록체인 크롤링 프로세스를 트리거할 수 있다. 상태 스토리지(112)가 파퓰레이팅되고 사용 가능하면, 서버 엔진(114)은 외부 애플리케이션(116)에 쿼리 서비스를 제공하기 위해 상태 스토리지(112)에 접속할 수 있다. 애플리케이션(116)은 블록체인을 조회해야 할 경우에 블록체인(100)을 직접 조회하는 대신에 블록체인 서비스(102)를 조회할 수 있다. 그렇게 하기 위해, 애플리케이션(116)은 서버 엔진(114)에 접속하여 요청을 보낼 수 있다. 서버 엔진(114)은 요청을 해석하고, 상태 스토리지(112)의 쿼리를 수행하고, 응답을 반환할 수 있다.

도 1의 블록체인 쿼리 서비스는 소정의 한계가 있을 수 있다. 이 유형의 블록체인 쿼리 서비스는 블록체인으로부터 데이터를 직접 스크래핑하여 그 상태를 유지할 수 있기 때문에, 이러한 쿼리 서비스와 특정 블록체인 사이의 인터페이스는, 특히 이러한 쿼리 서비스가 하나의 블록체인 노드 인스턴스에 동시에 접속하고 동기화할 때, 병목 현상을 일으킬 수 있다. 이 문제를 해결하기 위한 한가지 방법은 블록체인 노드마다 요청 부하를 분산시키기 위해 블록체인 노드 소프트웨어의 추가 인스턴스를 추가하는 것이다. 그러나 이것은 비효율적일 수 있다.

첫째, 블록체인 노드 소프트웨어의 추가 인스턴스를 생성하려면, 블록체인 쿼리 서비스는 블록 1부터 시작하여 블록체인의 전체 상태 이력을 저장하는 것이 필요할 수 있다. 이를 위해 상당한 양의 메모리가 필요할 수 있고, 메모리에 저장된 데이터의 작은 서브세트만이 대상이 되는 경우가 있다. 둘째, 블록체인 노드 소프트웨어는 항상 네트워크를 통해 블록체인 쿼리 서비스와 동기화하는 것이 필요할 수 있으며, 이는 네트워크 대역폭 제약으로 인해 확장 가능하지 않을 수 있다. 예를 들어, 1 기가바이트("GB") 블록체인 노드의 1000개 인스턴스를 동기화하려면 1 테라바이트의 네트워크 대역폭이 필요하게 된다.

도 1의 블록체인 쿼리 서비스(102)와 같은 블록체인 쿼리 서비스는 추가 제한이 있을 수 있다. 예를 들어, 내장형 JSON-RPC API를 통해 블록체인을 크롤링하거나 로컬 블록체인 파일을 직접 읽거나, 또는 접속된 블록체인 피어(peer)에 피어 투 피어 데이터 요청을 직접 하거나 하는 것과 같이 블록체인에서 데이터를 리트리빙하는 제한된 방법만 있을 수 있다. 블록체인 파일을 로컬로 읽는 것과 관련된 제한은 이 방법이 단일 머신에서만 로컬로 사용될 수 있다는 것이다. 블록체인 쿼리 서비스는 원격 블록체인 인스턴스로부터 데이터를 리트리빙하는 데에 이 방법을 사용하지 못할 수도 있다. JSON-RPC를 사용하는 내장형 쿼리 방법과 관련하여, HTTP2와 같은 프로토콜이 존재하는데, 이것은 다중화(예컨대, 단일 전송 매체에서 신호를 결합하는 것) 및 HTTP2 서버 푸시를 수행하기 때문에 성능적인 면에서 확장된다. 또한 IPFS, BitTorrent, 및 DAT와 같은 피어 투 피어 복제 방법도 있는데 네트워크의 모든 시더(seeder)로 복제를 오프로드할 수 있다. 그러나 블록체인 소프트웨어는 일반적으로 그러한 프로토콜을 사용하지 않는데 그러한 프로토콜을 사용하면 블록체인의 보안을 훼손시킬 수 있기 때문이다.

기존의 블록체인 쿼리 서비스의 또 다른 제한은 특정 블록체인 쿼리 서비스가 해당 블록체인 쿼리 서비스가 수행하는 특정 기능은 용이하게 하지만 다른 기능 또는 검증은 그렇지 못한 포맷으로 데이터를 저장할 수 있다는 것이다. 예를 들어, 블록체인 쿼리 서비스(102)가 카운터 서비스 - 매 새로운 트랜직션마다 카운터를 증분시킴 - 를 제공하는 상태 머신이라면, 블록체인 쿼리 서비스(102)는, 블록체인에서 일어난 모든 이벤트를 추적하고 애플리케이션(116)이 쿼리를 할 때마다 카운터를 재구축한다기보다는, 그것의 상태 스토리지(112)에 카운터만 저장할 수 있다. 이것은 블록체인 쿼리 서비스를 조회하는 써드파티 애플리케이션에서는 효율적일 수 있지만, 데이터세트의 진위성(authenticity)을 검증하는 것이 쉽지 않을 수 있다. 현재 상태의 진위성을 검증하는 것은 블록체인(100)을 재크롤링하는 것, 카운터를 재구축하는 것, 및 그것을 상태 스토리지(112)의 현재 상태와 비교하는 것을 필요로 할 수 있다.

경우에 따라, 블록체인 쿼리 서비스의 기능은 검증 및 진위성이 특히 중요한 경우에는 돈을 수반할 수도 있다. 예를 들어, 블록체인 쿼리 서비스가 토큰 시스템을 구현할 수 있다. 토큰은, 다양한 블록체인 트랜잭션 패턴에 기초하여 동작하고 토큰 전송 또는 기타 중요한 액션을 지시하는 상태 전환을 행할 수 있는 상태 머신일 수 있다. 상태 머신은 블록체인 쿼리 서비스(102)의 형태로 블록체인의 외부에 존재할 수 있다. 이 경우에, 토큰 전송은 블록체인 네트워크의 채굴자에 의해 검증되지 못할 수도 있다. 대신에, 검증은 가상적일 수 있고, 블록체인을 크롤링함으로써 구축될 수 있다. 진위성은 블록체인 채굴자에 의해 직접 강요되는 것이 아니라 블록체인 쿼리 서비스(102)를 실행하는 프로토콜에 의해 이루어지는 것이기 때문에, 토큰 시스템의 고객은 토큰 시스템(블록체인 쿼리 서비스(102)로서 구현됨)의 현재 상태가 정확하고 실제로 블록체인의 상태에 해당하는 것을 확인하기를 원할 수 있다.

그 결과, 블록체인의 재크롤링이 더 빈번해질 수 있고, 블록체인의 부하 밸런싱 문제가 더 심각해질 수 있다. 예를 들어, 법 집행 기관은 진위성을 검증하기 위해 이러한 각 블록체인 쿼리 서비스가 블록체인을 재크롤링하는 것을 요구할 수 있다. 또 블록체인 쿼리 서비스는 에러를 검출하고 최소화기 위해 지속적으로 재크롤링의 실행을 원할 수 있다. 이 경우, 상태 머신의 탄생 초기부터 모든 블록에 대해 블록체인을 재크롤링하는 것은 블록체인 소프트웨어(100)에 너무 많은 부담을 줄 수 있다.

기존의 블록체인 쿼리 서비스의 또 다른 제한은 각 블록체인 쿼리 서비스가 접속하는 블록체인 인스턴스를 중심으로 중앙 집중화될 수 있다는 것이다. 이러한 블록체인 인스턴스는 실패의 중심점이 될 수 있다. 그리고 모든 블록체인 쿼리 서비스가 소스 블록체인 인스턴스에 직접 접속해야 하기 때문에, 이들 블록체인 쿼리 서비스는, 블록체인 자체가 실행 중일 때에도, 소스 블록체인과의 접속을 상실하고 네트워크 파티션과 같은 소정의 에지 케이스 동안 업데이트가 정지할 수 있다. 블록체인 데이터에 대한 저비용 오프체인 복제 방법의 부재는 블록체인 쿼리 서비스의 전체 아키텍처와 생태계를 신뢰할 수 없고 확장 불가능하게 만든다.

기존의 블록체인 쿼리 서비스의 또 다른 제한은 데이터를 저장하기 위한 시스템과 데이터를 서빙하기 위한 시스템이 반드시 동일한 품질을 요구하지 않는다는 것이다. 예를 들어, Amazon Glacier와 같은 기존의 클라우드 아카이브 솔루션은 Amazon S3와 같은 파일 전송 서비스와는 상이한 설계를 가질 수 있다. Amazon Glacier 시스템은 아키이브용으로 설계될 수 있는 반면 S3는 최종 사용자 소비용으로 설계될 수 있다. 결과적으로 S3는 데이터의 고성능 로딩에 최적화될 수 있는 반면 Glacier는 저비용 스토리지에 최적화될 수 있다. 기존의 블록체인 쿼리 서비스처럼 두 특징을 단일 시스템 내에 번들링하게 되면, 두 가지 목적으로 시스템을 최적화하기가 어려울 수 있다. 전술한 블록체인 쿼리 서비스의 현재 기술 상태는 아카이빙 및 서빙 특징이 단일 시스템으로서 번들링되는 고정된 아키텍처이다. 이것은 최적화하기에 어려울 수 있다.

전술한 제한들이 초기 블록체인에서는 블록체인 쿼리 서비스를 실행 불가능하게 하지 않았는데 왜냐하면 데이터 원장으로서의 블록체인의 사용이 저 스루풋으로 초기에는 권장되지 않았기 때문이다. 예를 들어, 비트코인(BTC)은 단일 블록에 1 메가바이트("MB") 내지 4 MB의 트랜잭션 데이터만 저장할 수 있다. 그러나, 최신 블록체인 네트워크는 확장에 그리고 데이터 원장으로서의 사용에 최적화될 수 있고, 그래서 전술한 한계들을 악화시킬 수 있다. 따라서, 블록체인에 대한 직접 쿼리를 최소화하고 블록체인 파생 데이터를 저장하고 복제하는 비용을 크게 삭감하도록 모듈식 블록체인 캐시 및 복제 시스템을 갖는 것이 바람직할 수 있다.

도 2는 일 실시형태에 따른 블록체인 캐시 서비스를 개략적으로 예시한다. 블록체인 캐시 서비스(102)는 블록체인 쿼리 서비스(102) 및 캐시 엔진(200)을 가질 수 있다. 캐시 엔진(200)은 블록체인 크롤러(202) 및 캐시 서비스(204)를 가질 수 있다. 블록체인 쿼리 서비스는 도 1의 블록체인 크롤러(104)의 자리에 캐시 크롤러(216)를 채택할 수 있다. 캐시 크롤러(216)는 블록체인(100)을 직접 크롤링하는 것보다 캐시 엔진(200)과 인터페이싱할 수 있다. 캐시 크롤러(216)는 캐시 엔진(200)으로부터 데이터를 페칭하기 위해 캐시 클라이언트(218)를 통해 캐시 엔진(200)과 인터페이싱할 수 있다.

캐시 엔진(200)은 블록체인 크롤러(202)를 사용하여, 블록체인(100)으로부터 데이터를 크롤링하고 그것을 캐시 서비스(204)에 파퓰레이팅할 수 있다. 블록체인 크롤러(202)는 블록체인 클라이언트(206) 및 상태 전환 엔진(208)을 포함할 수 있다. 캐시 엔진(200)의 블록체인 크롤러(202)는 도 1에서의 블록체인 쿼리 서비스(102)의 블록체인 크롤러(104)와 유사할 수 있고 유사한 기능을 수행할 수 있다. 블록체인 크롤러(202)는 블록체인(100)에 직접 접속할 수 있고 그로부터 데이터를 추출할 수 있다. 크롤링 액션은 JSON-RPC 같은 내장형 블록체인 API를 사용하여 수행될 수도 있지만, 추가로 또는 대안으로 로컬 블록체인 파일 시스템에 직접 액세싱함으로써 또는 기타 기존의 방식에 의해 수행될 수도 있다.

블록체인 크롤러(202)는 추출된 데이터를 상태 전환 엔진(208)에 보낼 수 있고 그래서 상태 전환 엔진은 그 데이터를 사용하여 프로그래밍된 로직에 기초해 캐시 스토리지(210)를 업데이트할 수 있다. 미리 프로그래밍된 로직은 데이터 정규화 (normalization), 인코딩, 디코딩, 직렬화(serialization), 역직렬화(deserialization), 변환(transformation), 필터링 등을 구현하는 로직을 포함할 수 있다. 캐시 스토리지(210)는 파일 시스템, 데이터베이스(예컨대, 관계형 데이터베이스, 문서 데이터베이스, 그래프 데이터베이스, 키-값 데이터베이스 등), 인메모리 스토리지 등으로 구현될 수 있다. 예를 들어, 캐시 스토리지(210)가 파일 시스템으로서 구현되는 경우, 이것을 업데이트하는 것은 파일을 작성, 업데이트, 이동 또는 삭제하는 것을 포함할 수 있다. 캐시 스토리지(210)가 데이터베이스로서 구현되는 경우, 상태 전환 엔진(208)은 데이터베이스 삽입, 업데이트 또는 삭제를 실행할 수 있다. 캐시 스토리지(210)가 인메모리 스토리지로서 구현되는 경우, 상태 전환 엔진(208)은 프로그램에서 다양한 인메모리 변수를 생성, 업데이트 또는 삭제할 수 있다. 상태 전환 엔진(208)은 또한 캐시 스토리지(210)의 상태를 업데이트하는 방법을 결정하기 위해 캐시 스토리지(210)의 기존 콘텐츠를 사용할 수 있다. 캐시 스토리지(210) 내의 데이터는 블록체인 쿼리 서비스(102)에 빠르고 쉽게 액세스할 수 있도록 다양한 방식으로 인덱싱될 수 있다.

캐시 스토리지(210)는 블록체인(100)의 서브세트를 저장할 수 있다. 서브세트는 지정된 시간 프레임, 예컨대, 1시간 전, 5시간 전, 10시간 전, 24시간 전, 48시간 전 등에서 발생한 블록체인 트랜잭션을 포함할 수 있다. 상태 전환 엔진(208)은 새로운 트랜잭션을 위한 공간을 만들기 위해 지정된 시간 프레임 밖에 있는 트랜잭션을 캐시 스토리지(210)로부터 프루닝(prune)할 수 있다. 이것은 캐시 스토리지(210)의 쿼리가 결정론적 결과를 반환하는 것을 보장할 수 있다. 대안으로 또는 추가로, 서브세트는 특정 조건 또는 기준을 충족하는 블록체인 트랜잭션을 포함할 수 있다.

캐시 스토리지(210)는 파퓰레이팅되고 사용 가능하게 되면, 캐시 서비스(204)를 통해 외부 클라이언트에 서빙될 수 있다. 캐시 서비스(204)는 상태 전환 엔진(208)에 의해 상태 관리가 유지되는 캐시 스토리지(210)를 포함할 수 있다. 캐시 서비스(204)는 또한 캐시 서비스(204)를 외부 클라이언트에 노출시킬 수 있는 서버 엔진(214)을 포함할 수 있다. 캐시 클라이언트(218)는 서버 엔진(214)을 통해 캐시 서비스(204)에 접속할 수 있고, 어떤 종류의 데이터를 찾고 있는지 기술하는 요청을 보낼 수 있다. 그러면 서버 엔진(214)은 캐시 스토리지(210)로부터 관련 데이터를 캐시 클라이언트(218)로 전달할 수 있다. 그런 다음 캐시 클라이언트(218)는 블록체인 쿼리 서비스(102)의 상태 스토리지(112)를 프로그래밍 방식으로 업데이트할 수 있는 상태 전환 엔진(220)에 데이터를 보낼 수 있다. 데이터 전송 모드는 풀 기반(pull-based) 또는 푸시 기반(push-based)일 수 있다. 예를 들어, 캐시 클라이언트(218)는 서버 엔진(214)에 계속해서 요청(즉, 풀)을 보낼 수 있거나 초기 일회성 요청을 보낼 수 있으며, 그런 후에 서버 엔진(214)은 초기 요청을 충족하는 데이터를 캐시 클라이언트(218)에 푸시할 수 있다. 블록체인 쿼리 서비스(102)는 이제 블록체인 크롤러(104)(도 1)을 통해 블록체인(100)으로부터 데이터를 직접 소싱하는 대신, 캐시 크롤러(216)를 통해 캐시 엔진(200)으로부터 데이터를 소싱할 수 있다. 블록체인 쿼리 서비스(102)는 캐시 크롤러(216) 및 블록체인 크롤러(104)가 교환 가능하게 전후로 전환될 수 있도록 설계될 수 있다. 블록체인은 전통적으로 분산화된 트리 구조를 가지고 있기 때문에 전술한 바와 같이 중앙 집중식 위치에서 블록체인 데이터를 인덱싱하고 저장하는 것은 비관습적인 것으로 간주될 수 있다.

도 2의 컴포넌트들은 하나 이상의 위치에서 하나 이상의 컴퓨터 디바이스 상에 구현될 수 있다. 컴퓨팅 디바이스는 서버, 데스크탑 또는 랩탑 컴퓨터, 전자 태블릿, 모바일 디바이스 등일 수 있다. 컴퓨팅 디바이스는 하나 이상의 장소에 위치할 수 있다. 컴퓨팅 디바이스는 범용 프로세서, 그래픽 프로세싱 유닛(GPU), 주문형 집적 회로(ASIC), 필드 프로그래머블 게이트 어레이(FPGA) 등을 가질 수 있다. 컴퓨팅 디바이스는 메모리, 예컨대 다이내믹 또는 스태틱 랜덤 액세스, 리드 온리 메모리, 플래시 메모리, 하드 드라이브 등을 추가로 가질 수 있다. 메모리는 실행시 컴퓨팅 디바이스로 하여금 서브시스템의 기능을 구현하게 하는 명령어를 저장하도록 구성될 수 있다. 컴퓨팅 디바이스는 네트워크 통신 디바이스를 추가로 가질 수 있다. 네트워크 통신 디바이스는 컴퓨팅 디바이스들이 네트워크를 통해 서로 그리고 임의의 수의 사용자 디바이스와 통신할 수 있게 할 수 있다. 네트워크는 유선 또는 무선 네트워크일 수 있다. 예를 들어, 네트워크는 광섬유 네트워크, Ethernet® 네트워크, 위성 네트워크, 셀룰러 네트워크, Wi-Fi® 네트워크, Bluetooth® 네트워크 등일 수 있다. 다른 구현예에서, 컴퓨팅 디바이스는 인터넷을 통해 액세스 가능한 여러 분산 컴퓨팅 디바이스일 수 있다. 그러한 컴퓨팅 디바이스는 클라우드 컴퓨팅 디바이스로 간주될 수 있다.

캐시 엔진(200) 및 캐시 크롤러(216)는 두 동작 모드를 가질 수 있다: "크롤링 모드(crawl mode)" 및 "리스닝 모드(listen mode)". 캐시 엔진(200)은 작동 중 임의의 순간에 크롤링 모드(도 8) 또는 리스닝 모드(도 9)로 있을 수 있다. 캐시 크롤러(216)도 작동 중 임의의 순간에 크롤링 모드(도 11) 또는 리스닝 모드(도 12)로 있을 수 있다.

캐시 엔진(200)은 크롤링 모드로 있는 경우(도 8), 블록체인으로부터 데이터를 크롤링하고 캐시 스토리지(200)에 저장하기 위해 쿼리 세트를 반복할 수 있다. 캐시 엔진(200)은 리스닝 모드로 있는 경우(도 9), 블록체인으로부터 임의의 이벤트를 리스닝하는 이벤트 루프를 시작할 수 있고, 블록체인을 통해 능동적으로 반복하는 대신 관련 이벤트를 검출할 때만 캐시 스토리지(210)에 대한 상태 전환을 실행한다.

도 8은 블록 X부터 블록 Y까지 블록체인(100)을 크롤링하기 위한 예시적인 프로세스의 흐름도이다. 이 프로세스는 크롤링 모드 동안 도 2의 캐시 엔진(200)에 의해 수행될 수 있다. 블록체인 클라이언트(206)는 블록체인 크롤러(202)가 "X부터 Y까지 모든 블록을 크롤링"해야 하는 것을 지정할 수 있는 QUERY_SET을 구축할 수 있다(800). 블록체인 클라이언트(206)는 여러 상이한 방식으로 QUERY_SET를 구축할 수 있다. 블록체인 클라이언트(206)는 예컨대 X부터 Y까지의 범위의 정수들의 어레이를 작성할 수 있다(예컨대, [X, X+1, X+2, ..., Y]). QUERY_SET는 MongoDB, JQ, 또는 Bitquery 같은 쿼리 언어로 구현될 수 있다. QUERY_SET는 캐시 엔진(200)에 의해 정적으로 지정될 수 있다. 추가로 또는 대안으로, QUERY_SET는 프로그래밍 방식으로 동적으로 생성될 수도 있다. 또한 QUERY_SET는 캐시 엔진(200)에 접속하는 써드파티 외부 클라이언트로부터의 요청, 예컨대 블록체인 쿼리 서비스(102)로부터의 쿼리에 기초할 수도 있다. 예를 들어, 블록체인 서비스(102)는 캐시 엔진(200)을 조회할 수 있고 그것이 필요로 하는 데이터가 캐시 스토리지(200)에서 사용 가능하지 않다는 것, 또는 그러한 데이터가 충분히 최신 상태가 아니라는 것을 발견할 수 있다. 이러한 경우에, QUERY_SET는 사용 가능하지 않거나 충분히 최신 상태가 아닌 데이터를 지정할 수 있다. QUERY_SET는 블록 높이에 제한되지 않을 뿐만 아니라 트랜잭션 푸시 데이터 패턴 또는 다양한 블록체인 메타데이터와 같은 블록체인의 다양한 측면을 포함한 다른 요소도 지정할 수 있다. 일 예는 블록체인 트랜직션 ID의 어레이일 수 있다.

QUERY_SET가 구축되면, 블록체인 클라이언트(206)는 QUERY_SET의 INDEX를 0로 설정하고(802) 쿼리 명령어 QUERY_SET[INDEX]를 사용하여 블록체인(100)으로부터 판독을 시작할 수 있다(804). 쿼리에 대한 블록체인 데이터가 성공적으로 페칭되면, 블록체인 클라이언트(206)는 데이터를 상태 전환 엔진(208)에 보낼 수 있다. 상태 전환 엔진(208)은 인커밍 데이터를 미리 프로그래밍된 로직으로 처리하고 그에 따라 캐시 스토리지(210)를 업데이트할 수 있다(806).

그런 다음 캐시 엔진(200)은 또 다른 캐시 클라이언트(218d, 도 4)와 같은 다른 컴포넌트가 추가 복제에 대해 리스닝하고 있는 경우에 캐시 업데이트 이벤트를 방출할 수 있다(808). 캐시 이벤트 업데이트를 방출한 후에, 블록체인 클라이언트(206)는 INDEX를 INDEX+1로 증분하고(810) INDEX가 QUERY_SET의 길이 이상인지의 여부를 확인함으로써 QUERY_SET가 전체 반복되지 않게 한다(812). INDEX가 QUERY_SET의 길이 이상이 아닌 경우, 블록체인 클라이언트(206)는 명령어 QUERY_SET[INDEX+1]를 사용하여 블록체인(100)을 조회할 수 있다(804). 한편, INDEX가 QUERY_SET의 길이 이상이면, 크롤링은 완료된다. 그후, 캐시 엔진(200)은 정지하거나 리스닝 모드(도 9)에 진입할 수 있다.

캐시 크롤러(216)의 캐시 클라이언트(218)도 유사한 방식으로 캐시 스토리지(210)를 크롤링할 수 있다. 이에 대해서는 도 11에서 더 상세하게 설명할 것이다.

도 9는 블록체인(100)을 리스닝하기 위한 예시적인 프로세스의 흐름도이다. 프로세스는 지속적으로 블록체인(200)에 접속되고 블록체인(200)을 리스닝할 수 있는 블록체인 클라이언트(206)에 의해 수행될 수 있다. 블록체인 클라이언트(206)는 블록체인(100)으로부터 그것에 푸시된 관련 이벤트를 리스닝할 수 있다. 이것은 블록체인 클라이언트(206)가 루프를 반복하고 반복이 종료되면 정지함으로써 능동적으로 블록체인(100)을 조회하는 크롤링 모드(도 8)와 대비된다.

블록체인 클라이언트(206)는 SUBSCRIPTION_QUERY_SET를 구축할 수 있다(900). SUBSCRIPTION_QUERY_SET는 캐시 클라이언트(218)가, 블록체인 클라이언트(206)가 구독하기를 요청한 조건 세트일 수 있다. 조건 세트는 예컨대 소정의 블록체인 블록에 속하는 트랜잭션 또는 소정의 데이터 패턴(예컨대, 소정의 바이트 시퀀스)과 매칭되는 트랜잭션을 포함할 수 있다. 조건 세트는 캐시 서비스(204)의 서버 엔진(214)에 의해 프로그래밍되거나 내장된 정적인 조건 세트일 수 있다. 추가로 또는 대안으로, SUBSCRIPTION_QUERY_SET는 미리 프로그래밍된 로직에 기초하여 동적으로 생성될 수도 있다.

블록체인 클라이언트(206)는 블록체인(100)으로부터의 이벤트를 리스닝할 수 있다(902). 전체 QUERY_SET를 통한 반복이 종료될 때까지 인덱스를 증분함으로써(810) 계속적으로 블록체인을 크롤링하는 크롤링 모드와 달리, 리스닝 모드는 소정의 이벤트가 발생할 시에만 크롤링 액션을 트리거한다(904). 새로운 블록체인 이벤트가 발생할 경우, 캐시 엔진(200)의 블록체인 클라이언트(206)는 이벤트를 검출하고 동작(900)에서 구축된 SUBSCRIPTION_QUERY_SET를 사용하여 블록체인(100)을 조회한다(906). 블록체인(100)에서 SUBSCRIPTION_QUERY_SET에 의해 정의된 조건 세트와 충족하는 업데이트가 있다면, 블록체인 클라이언트(206)는 데이터를 상태 전환 엔진(208)에 보낼 수 있고, 그래서 상태 전환 엔진은 데이터를 처리하고 그에 따라 캐시 스토리지(210)를 업데이트할 수 있다(908). 그런 다음, 캐시 엔진(200)은 캐시 업데이트 이벤트를 방출할 수 있다(910). 그리고 캐시 엔진(200)의 블록체인 클라이언트(206)는 새로운 블록체인 이벤트를 계속해서 리스닝할 수 있다(902). SUBSCRIPTION_QUERY_SET는 모든 이벤트를 리스닝하는 조건일 수 있고, 이 경우에 추가 조회 단계(906)는 필요하지 않을 수 있고 시스템은 단순히 이벤트 데이터를 상태 전환 엔진에 직접 전달할 수 있다(908). 구독을 사용하면 블록체인 쿼리 서비스(102)가 애플리케이션(116)으로부터의 요청에 응답하는데 걸리는 시간을 단축시킬 수 있는데, 응답 데이터는 블록체인(100)에서보다는, 캐시 스토리지(210)에서 수월하게 사용될 수 있어 용이하게 조회될 수 있기 때문이다.

도 10은 클라이언트와 인터페이싱하기 위해 캐시 서버 엔진(214)에 의해 수행되는 예시적인 프로세스의 흐름도이다. 캐시 스토리지(210)는 파퓰레이팅되면, 서버 엔진(214)을 통해 외부 클라이언트에 노출될 수 있다. 캐시 서버 엔진(214)은 HTTP 웹 서버일 수도 있고 또는 dat, IPFS, gRPC 등과 같은 유사한 프로토콜로 구현될 수도 있다.

서버 엔진(214)은 캐시 클라이언트(218)로부터의 인커밍 접속을 리스닝할 수 있다(1000). 캐시 클라이언트(218)로부터의 인커밍 접속 요청이 검출되면(1002), 서버 엔진(214)은 접속 요청이 단일 쿼리 요청인지 지속적 접속을 필요로 하는 구독 요청인지를 결정할 수 있다(1004). 요청이 구독 요청이라면, 서버 엔진(214)은 요청을 파싱하여 관련 접속 메타데이터를 자체 데이터베이스에 저장할 수 있다(1006). 메타데이터는 도 9에서의 SUBSCRIPTION_QUERY_SET, 및 캐시 클라이언트(218)의 접속된 인스턴스를 추적하고 서비스하기에 유용할 수 있는 정보의 다양한 피스를 포함할 수 있다. 캐시 서비스(204)와 캐시 클라이언트(218) 사이에 접속이 확립되면, 캐시 서비스(207)는 캐시 상태 업데이트 이벤트를 리스닝하기 시작할 수 있다(1008). 새로운 캐시 상태 업데이트 이벤트가 있다면(예컨대, 도 9의 동작(910)으로부터), 캐시 서비스(204)는 이벤트를 처리하고(1010) 캐시 클라이언트(218)의 관련 접속된 인스턴스에 통지할 수 있다(1012). 그런 다음 캐시 서비스(204)는 추가 캐시 업데이트 이벤트를 계속해서 리스닝할 수 있다(1008).

한편, 인커밍 접속 요청(1002)이 일회성 쿼리 요청인 경우, 서버 엔진(214)은 인커밍 요청을 사용하여 캐시 스토리지(210)를 조회하고(1014) 대응하는 응답을 캐시 클라이언트(218)에 다시 반환할 수 있다(1016). 그런 다음 캐시 서비스(204)의 서버 엔진(214)은 새로운 접속을 계속해서 리스닝할 수 있다(1000).

블록체인 쿼리 서비스(102)는 캐시 크롤러(216)를 통해 캐시 엔진(200)에 접속될 수 있다. 캐시 크롤러(216)는 캐시 엔진(200)에 접속하고 요청을 함으로써 원하는 데이터를 리트리빙할 수 있다. 요청은 캐시의 전체 콘텐츠를 요구할 수도 있거나 캐시의 필터링되고 처리된 버전을 요구할 수도 있다. 캐시 엔진(200)과 마찬가지로, 캐시 크롤러(216)도 두가지 모드: 크롤링 모드 및 리스닝 모드를 갖는다.

도 11은 블록체인(210)을 크롤링하기 위한 예시적인 프로세스의 흐름도이다. 이 프로세스는 크롤링 모드 동안 캐시 크롤러(216)에 의해 수행될 수 있다. 크롤링 모드에서, 캐시 크롤러(216)는 캐시 엔진(200)으로부터 취득하기 원하는 데이터의 유형을 정의할 수 있는 QUERY_SET를 구축할 수 있다(1100). 캐시 크롤러(216)는 QUERY_SET를 통해 반복할 수 있고 접속된 캐시 엔진(200)에 요청을 할 수 있다. 예를 들어, 캐시 크롤러(216)는 블록 X 내지 Y에서 모든 블록을 페칭하기를 원할 수 있다. 이러한 경우에, QUERY_SET는 X와 Y 사이의 정수들의 어레이일 수 있다: [X, X+1, X+2, ... Y].

QUERY_SET를 통해 반복하기 위해, 캐시 크롤러(216)는 INDEX를 0으로 설정할 수 있다(1102). INDEX의 매 반복마다, 캐시 크롤러(216)는 쿼리 명령어 QUERY_SET[INDEX]를 사용하여 캐시 엔진(220)에 요청을 할 수 있다(1004). 그렇지만, 이 프로세스가 다중 요청에 제한되는 것은 아니다. 프로세스는 다중 응답을 초래하는 단일 뱃치 요청, 또는 심지어, HTTP2와 같은 다양한 프로토콜을 통해 달성될 수 있는, 스트리밍 요청 및 응답을 전송하는 것을 수반할 수도 있다. 캐시 엔진(200)이 관련 응답을 캐시 클라이언트(218)에 반환하면, 캐시 클라이언트(218)는 데이터를 처리하고 데이터를 상태 전환 엔진(220)에 보낼 수 있다. 그러면 상태 전환 엔진(220)은 캐시 클라이언트(218)로부터의 인커밍 데이터와 상태 스토리지(112)의 콘텐츠를 사용하여, 자체의 미리 프로그래밍된 로직을 실행하고 마지막으로 블록체인 쿼리 서비스(102)의 상태 스토리지(112)를 업데이트할 수 있다(1106).

상태 전환이 종료되면, 캐시 크롤러(216)는 INDEX를 INDEX+1로 증분하고(1108) INDEX가 QUERY_SET의 길이 이상인지의 여부를 확인함으로써 QUERY_SET가 전체 반복되지 않게 한다(1110). INDEX가 QUERY_SET의 길이 이상이 아닌 경우, 캐시 크롤러(216)는 쿼리 명령어 QUERY_SET[INDEX+1]를 사용하여 캐시 엔진을 조회할 수 있다. 한편, INDEX가 QUERY_SET의 길이보다 크면, 캐시 크롤러는 정지하거나 리스닝 모드에 진입할 수 있다.

도 12는 캐시 엔진(200)을 리스닝하기 위한 예시적인 프로세스의 흐름도이다. 이 프로세스는 리스닝 모드 동안 캐시 크롤러(216)에 의해 수행될 수 있다. 리스닝 모드에서, 캐시 크롤러(216)는 QUERY_SET를 통해 반복하지 않는다. 대신, 처음에 캐시 크롤러(216)는 캐시 엔진(200)으로부터 어떤 유형의 데이터를 취득하기를 원하는지를 정의하는 SUBSCRIPTION_QUERY_SET를 작성할 수 있다. 캐시 크롤러(216)는 SUBSCRIPTION_QUERY_SET를 캐시 엔진(200)에 보내고, 임의의 새로운 캐시 업데이트 이벤트에 대해 캐시 엔진(200)을 리스닝하고 캐시 업데이트 이벤트를 도달하는 대로 처리할 수 있다.

캐시 크롤러(216)는 SUBSCRIPTION_QUERY_SET를 구축할 수 있다(1200). SUBSCRIPTION_QUERY_SET는 수동으로 작성된 스태틱 필터, 쿼리 언어, 또는 프로그래머블 함수일 수 있다. SUBSCRIPTION_QUERY_SET의 일례는 "모든 캐시 업데이트 이벤트를 리스닝함"을 의미할 수 있는 단일 항목 "ALL"이다. SUBSCRIPTION_QUERY_SET의 다른 예는 관련 캐시 업데인트 이벤트만 필터링하는 조건부 필터를 정의하는 것이다. 캐시 크롤러는 Bitquery와 같은 쿼리 언어를 사용하여 필터를 구축할 수 있다. 추가로 또는 대안으로, 필터는 JavaScript, C, Python, Java 등과 같은 임의의 프로그래밍 언어로 작성된 맵/필터 함수일 수 있다. 추가로 또는 대안으로, SUBSCRIPTION_QUERY_SET은 다중 조건을 구독하기 위하여 동시에 다수의 이들 쿼리 유형을 포함할 수 있다.

SUBSCRIPTION_QUERY_SET를 구축한 후에, 캐시 크롤러(216)는 요청을 캐시 엔진에 보낼 수 있다(1202). 그런 다음 캐시 크롤러(216)는 캐시 엔진(200)에 의해 방출되는 모든 캐시 업데이트 이벤트를 리스닝할 수 있다(1204). 이러한 리스닝은 웹소켓 또는 Server Sent Events와 같이 폭넓게 사용되는 프로토콜 및 개방형 표준을 사용하여 처음부터 구현될 수도 이지만, Apache Kafka, ZeroMQ, RabbitMQ, Redis, MongoDB 복제 등과 같은 자동 동기화를 가능하게 하는 다수의 기존 기술로 구현될 수도 있다. 새로운 이벤트가 발생할 경우, 캐시 엔진(200)은 도 10의 단계 1012에서 설명한 바와 같이, 캐시 업데이트 이벤트를 방출할 수 있다. 캐시 크롤러(216)가 이것을 검출할 수 있고(1206), 캐시 클라이언트(218)가 업데이트된 콘텐츠를 페칭하기 위해 캐시 엔진(200)에 추가 크롤링 요청을 할 수 있고, 그런 다음 응답을 상태 전환 엔진(220)에 전달하면, 인커밍 데이터 및 상태 스토리지(112)의 콘텐츠를 사용하여 상태 스토리지(112)에 대한 상태 전환을 프로그래밍 방식으로 수행할 수 있다. 이 상태 전환 후에, 사이클은 단계 1204로 되돌아 가고 이벤트 루프가 계속되는데, 여기서 캐시 크롤러(216)는 접속된 캐시 엔진 이벤트를 계속 리스닝한다(1204). 다른 실시형태에서, 캐시 엔진(200)으로부터 방출된 캐시 업데이트 이벤트는 필요한 데이터의 전체 페이로드를 포함할 수 있고 캐시 크롤러(216)는 이 데이터를 직접 상태 전환 엔진(220)에 전달하여, 추가 크롤링 단계의 필요성을 회피할 수 있다.

도 11의 QUERY_SET 및 도 12의 SUBSCRIPTION_QUERY_SET는 애플리케이션(116)으로부터의 요청에 기초하여 구축될 수 있다. 경우에 따라, 원하는 데이터를 캐시 스토리지(210)에서 사용할 수 없을 수 있다. 이러한 경우에, 블록체인 크롤러(202)는 이러한 데이터를 블록체인(100)으로부터 취득하고 상태 전환 엔진(208)을 통해 그것을 캐시 스토리지(210)에 기입할 수 있다.

일부 실시형태(도 3)에서, 하나의 캐시 엔진(200)이 다수의 블록체인 쿼리 서비스(102a 및 102b)를 서빙할 수 있다. 이 경우 블록체인 쿼리 서비스(102a 및 102b)는 데이터를 애플리케이션(116a 및 116b)에 각각 제공할 수 있다. 이 구성에서, 애플리케이션(116a)은 블록체인 쿼리 서비스(102a)에 접속하여 데이터를 취득할 수 있다. 블록체인 쿼리 서비스(102a)는 캐시 크롤러(216a)를 포함할 수 있다. 캐시 크롤러(216a)는 캐시 클라이언트(218a) 및 상태 전환 엔진(220a)을 포함할 수 있다. 캐시 클라이언트(218a)는 데이터를 요청하기 위해 캐시 엔진(200)에 접속할 수 있다. 마찬가지로, 애플리케이션(116b)은 블록체인 쿼리 서비스(102b)에 접속할 수 있다. 블록체인 쿼리 서비스(102b)는 캐시 크롤러(216a)를 포함할 수 있다. 캐시 크롤러(216b)는 상태 전환 엔진(220b) 및 캐시 클라이언트(218b)를 포함할 수 있다. 캐시 클라이언트(218b)는 데이터를 요청하기 위해 캐시 엔진(200)에 접속할 수 있다. 이렇게 두 블록체인 쿼리 서비스(102a 및 102b) 모두는 블록체인(100)에 직접 접속하기보다는 단일 공유 캐시 엔진(200)에 접속할 수 있다. 도 3에는 2개의 블록체인 쿼리 서비스만을 도시하고 있지만, 다수의 그러한 서비스가 동시에 캐시 엔진(200)에 접속할 수 있다. 도 3의 구성은 블록체인에 대한 접속 수를 줄일 수 있고, 그래서 네트워크 대역폭 요건 및 블록체인 충돌 가능성을 줄일 수 있다.

일부 실시형태(도 4)에서는, 하나의 캐시 엔진이 복제 서비스를 구현할 수 있다. 캐시 엔진(200c)은 시드(seed) 캐시 엔진, 즉 블록체인(100)에 직접 접속하는 캐시 엔진으로서 역할할 수 있다. 캐시 엔진(200c)은 파퓰레이팅되면, 서비스를 다른 캐시 엔진에 제공할 수 있다. 이 시나리오에서, 캐시 엔진(200d, 200e)은 각각 캐시 클라이언트(218d, 218e)를 통해 시드 캐시 엔진(200c)에 접속하는 캐시 크롤러(216d, 216e)를 가질 수 있다. 캐시 클라이언트(218d, 218e)는 캐시 엔진(200c)의 캐시 스토리지의 전체 콘텐츠를 복제하기 위해 캐시 엔진(200c)에 요청을 보낼 수 있다. 대안으로, 캐시 클라이언트(218d, 218e)는 캐시 엔진(200c)의 캐시 스토리지 콘텐츠의 서브세트만을 요청할 수 있다. 그러면, 캐시 클라이언트(218d, 218e)는 상태 전환 엔진(220d, 220e)에 각각 데이터를 전송할 수 있다. 캐시 엔진(200d, 200e)은 접속을 위해 자신을 노출시킬 수 있고 블록체인 쿼리 서비스(102d, 102e)는 캐시 엔진에 접속하여 그 데이터를 취득할 수 있다. 도 4의 구성은, 이러한 애플리케이션이 다중 블록체인 쿼리 서비스 및 다중 캐시 엔진과 병렬로 인터페이싱할 수 있기 때문에 애플리케이션이 블록체인 데이터에 액세스할 수 있는 속도를 향상시킬 수 있다.

일부 실시형태(도 5)에서, 블록체인 크롤러(202)는 블록체인을 크롤링하면서, 캐시 엔진(200f, 200g, 200h)의 캐시 서비스(204f, 204g, 204h)에 각각 데이터를 보낼 수 있다. 캐시 엔진(200f 및 200h)에는 자체 블록체인 크롤러가 없을 수도 있다. 대신에, 캐시 엔진(202g)의 블록체인 크롤러(202)는 블록체인으로부터 취득한 데이터를 캐시 엔진(200f, 200g, 200h) 모두에 브로드캐스트할 수 있다. 이것은 도 4의 구성과 유사한 이점을 제공할 수 있다.

일부 실시형태(도 6)에서, 블록체인 쿼리 서비스(102)는 다중 캐시 엔진(200i, 200j, 200k)으로부터 데이터를 취득할 수 있다. 블록체인 쿼리 서비스(102)는 임의의 조합으로 캐시 엔진(200i, 200j, 200k)에 접속할 수 있다. 예를 들어, 블록체인 쿼리 서비스(102)는 캐시 엔진(200i, 200j, 200k)에 접속할 수 있다. 또 통상의 상황에서는 캐시 엔진(200i)에 접속하지만 캐시 엔진(200i)을 사용할 수 없게 되면 캐시 엔진(200j 또는 200k)에 접속할 수 있다. 또 모든 캐시 엔진(200i, 200, 200k)에 접속하여 이들로부터 판독하고 그로부터 동시에 데이터를 취득할 수 있다. 블록체인 쿼리 서비스(102)는 이러한 데이터를 교차 검증할 수 있다. 캐시 엔진(200i, 200j, 200k)은 동일한 데이터를 저장하고 서빙할 수 있거나 상이한 데이터(예컨대, 블록체인의 상이한 부분)를 저장하고 서빙할 수 있다. 도 6은 3개의 캐시 엔진만을 도시하지만, 블록체인 쿼리 서비스(102)는 다중 캐시 엔진에 접속할 수 있다.

도 3 내지 도 6에 도시하는 실시형태들은 임의의 조합으로 함께 통합될 수도 있다. 예를 들어, 다중 캐시 엔진은 도 5와 같이 단일 블록체인에 접속할 수 있다. 그런 다음 다중 캐시 엔진 각각은 도 3과 같이 다중 블록체인 쿼리 서비스에, 또는 도 4와 같이 다수의 다른 캐시 엔진에 접속할 수 있다. 추가로, 도 3 내지 도 6 중 임의의 도면에서의 블록체인 서비스 및 캐시 엔진의 수량은 더 작거나 훨씬 클 수도 있다. 예를 들어, 도 6의 실시형태에서 캐시 엔진의 수량은 약 1, 2, 3, 5, 10, 20, 50, 100, 1000 또는 그 이상일 수 있다.

도 2 내지 도 6의 블록들이 반드시 개별 물리적 머신(예컨대, 컴퓨터)에 대응하는 것은 아니다. 예를 들어, 도 2에서, 블록체인 쿼리 서비스 컴포넌트(102)와 캐시 엔진(200)은 동일한 머신 상에 구현될 수도 있고, 또 이들은 상이한 머신 상에 구현될 수도 있다. 서버 엔진(114)은 상태 스토리지(112)와 동일한 머신 상에 있을 수도 있고 없을 수도 있다. 상태 전환 엔진(220)과 캐시 클라이언트(218)는 동일한 머신 상에 있을 수도 있고 없을 수도 있다. 서버 엔진(214)과 캐시 스토리지(210)는 동일한 머신 상에 있을 수도 있고 없을 수도 있다. 그리고 상태 전환 엔진(208)과 블록체인 클라이언트(206)는 동일한 머신 상에 있을 수도 있고 없을 수도 있다. 또한 블록체인(100) 자체는 나머지 컴포넌트와 동일한 머신 상에 시스템에 있을 수도 있고 없을 수도 있다. 이들 컴포넌트 모두는 마이크로서비스로서 구현될 수 있으며 여기에 설명하는 방법 중 하나를 사용하여 네트워크를 통해 서로 통신하는 다중 호스트 컴퓨터 상에 분산될 수 있다.

일부 실시형태에서, 캐시 엔진은 다양한 캐시 클라이언트로부터의 탐색(discovery)을 허용하기 위해 캐시 레지스트리에 자신을 광고할 수 있다. 도 7에서, 캐시 엔진(200)의 캐시 서비스(204)는 자신이 제공하고 있는 캐시 서비스의 유형에 대한 메타데이터 뿐만아니라 고유하게 식별 가능한 정보를 요청함으로써 캐시 레지스트리(700a, 700b)에 자신을 광고할 수 있다. 그런 다음, 캐시 클라이언트(218)는 캐시 레지스트리(700a, 700b)를 검색함으로써 캐시 엔진(200)을 발견할 수 있고, 일단 발견되면 캐시 엔진에 접속할 수 있다. 캐시 레지스트리(700a, 700b)는 상이한 형태를 가질 수 있다. 예를 들어, 이들은 데이터베이스를 가진 중앙 서버에 저장될 수 있다. 대안으로, 캐시 레지스트리는 분산 해시 테이블일 수 있다. 다른 실시형태에서, 도 7은 캐시 클라이언트(218)가 캐시 레지스트리에 자신을 광고하고 캐시 서비스(204)가 캐시 클라이언트(218)를 발견한 후 캐시 서비스(204)가 캐시 클라이언트에 접속할 수 있는 역 방식으로 구현될 수도 있다. 이에 캐시 클라이언트는 이전에 알려지지 않은 캐시 서비스를 탐색할 수 있으며 그 반대의 경우도 마찬가지이다.

일부 실시형태에서, 캐시 서비스(204)는 캐시 클라이언트(218)로부터의 인커밍 접속을 관리하기 위해 추가 데이터베이스를 유지할 수도 있다. 캐시 클라이언트(218)는 소정의 메타데이터를 포함하는 소정의 요청을 할 수 있고, 캐시 서비스(204)는 각 클라이언트에 대한 메타데이터를 저장할 수 있다. 이것은 모든 요청에 대해 각 클라이언트에 커스텀 응답(customized response)을 전달하거나 캐시 크롤러 리스닝 모드(도 12) 동안 커스텀 이벤트를 전달하기 위해, 또는 캐시 클라이언트를 기억하기 위한 세션을 관리하는 데 필요한 정보를 포함할 수 있다.

일부 실시형태에서, 캐시 시스템은 요청-응답 패턴에 기초하는 것이 아니라 지속적인 동기화에 기초하여 기능할 수 있다. 예를 들어, 도 2에서, 캐시 클라이언트(218)는 캐시 서비스(204)로부터 데이터를 능동적으로 요청할 수 없고, 대신에 캐시 스토리지(210)의 복제 인스턴스로서 존재할 수 있다. 이것은 MongoDB, CouchDB, Apache Kafka, DAT, 및 IPFS 같은 다수의 스토리지 시스템 및 프로토콜에 의해 지원되는 다양한 데이터 복제 방법을 통해 달성될 수 있다. 캐시 스토리지(210)는 이러한 복제 방법 중 하나를 구현하고 마스터 인스턴스로 기능할 수 있으며, 캐시 클라이언트(218)의 다양한 구현예는 캐시 스토리지(210)를 복제하는 팔로워 복제 인스턴스를 임베딩할 수 있다. 그런 다음, 캐시 클라이언트(218)가 새로운 상태로 동기화함에 따라, 새로운 업데이트를 상태 전환 엔진(220)에 보내는 경우에, 상태 스토리지(112)를 처리하고 업데이트한다. 대안으로, 상태 스토리지(112) 자체는 캐시 스토리지(210)의 팔로워 복제 인스턴스로서 구현될 수 있으며, 이 경우 상태 스토리지(112)는 캐시 클라이언트(218) 및 상태 전환 엔진(220)을 스킵하고 스토리지를 직접 업데이트할 수 있다.

일부 실시형태에서, 캐시 크롤러(216)는, 블록 내의 모든 가공전 트랜잭션뿐만 아니라, 캐시 클라이언트(218)가 캐시 엔진 공급자를 신뢰할 필요 없이 나머지 데이터의 진위성을 검증하기 위해 사용할 수 있는 블록의 머클 루트도 포함할 수 있는, 전체 블록 데이터의 완전한 세트를 요청할 수 있다.

일부 실시형태에서, 이벤트는 대신 빈번한 폴링으로서 에뮬레이트될 수 있다. 예를 들어, 캐시 엔진으로부터의 이벤트를 리스닝하는 대신 캐시 클라이언트는 업데이트를 위해 캐시 엔진을 지속적으로 폴링할 수 있다.

일부 실시형태(도 13)에서, 블록체인(100)은 오프체인 블록체인 트랜잭션 스토리지(1300)로 대체될 수도 있다. 오프체인 트랜잭션 스토리지(1300)는 서명된 또는 서명되지 않은 블록체인 트랜잭션을 블록체인 외부에 저장하는 스토리지 시스템일 수 있다. 오프체인 블록체인 트랜잭션 스토리지(1300)는 블록체인의 사용자에 의해 유지되는 스토리지 시스템일 수도 있고, 또는 최종 사용자를 대신하여(예컨대, 수수료를 징수) 블록체인에 트랜잭션을 기입하는 엔티티에 의해 유지되는 스토리지 시스템일 수도 있다. 오프체인 트랜잭션 스토리지는 최종 사용자가 트랜잭션을 블록체인 피어 네트워크에 브로드캐스트하거나 블록체인 채굴자에게 직접 보내기 전에 트랜잭션을 임시로 저장하는 데 사용될 수 있다. 오프체인 트랜잭션 스토리지는 블록체인 채굴자가 브로드캐스트하기 전에 사용자로부터 트랜잭션을 직접 수락하는 데에도 사용될 수 있다. 오프체인 트랜잭션 스토리지는 블록체인 채굴자가 사용자로부터의 트랜잭션 제출을 직접 수락하여 추후 블록 채굴 시에 잠재적으로 블록에 포함시키는 데에 사용될 수 있다. 그리고 그것은 다수의 다른 용도로도 사용될 수 있다. 오프체인 블록체인 트랜잭션 스토리지(1300)는 오프체인 블록체인 트랜잭션 스토리지 API 서비스(1302)에 접속될 수 있다. 오프체인 블록체인 트랜잭션 스토리지 API 클라이언트(1304)는 블록체인 트랜잭션을 API 서비스(1302)에 보낼 수 있다. 그러면 API 서비스(1302)는 그것을 오프체인 블록체인 트랜잭션 스토리지(1300)에 저장할 수 있다. 이 경우, 캐시 엔진(200)은 블록체인(100) 대신에 이 오프체인 블록체인 트랜잭션 스토리지(1300)를 크롤링하고 리스닝할 수 있지만, 나머지 아키텍처는 동일할 수 있다. 오프체인 블록체인 트랜잭션 스토리지(1300)는 스토리지에 최적화될 수 있지만 판독 또는 필터링에는 그렇지 않다. 예를 들어, 오프체인 트랜잭션 스토리지(1300)는 Apache Kafka 같은 시스템을 사용하여 추가 전용 로그 구조(append-only log structure)로 구현될 수도 또는 파일 시스템에 단순히 원시 덤프(raw dump)로서 구현될 수도 있다. 오프체인 블록체인 트랜잭션 스토리지(1300)는 저장된 트랜잭션이 나중에 리트리빙될 수 있게 할 수 있지만 유연하고 강력한 인덱스 및 쿼리 인터페이스를 제공하도록 설계되지 않을 수도 있다. 이와 같이, 캐시 엔진(200)은 블록체인(100)을 크롤링하는 것과 동일한 유형의 부가 가치를 제공할 수 있다.

컴퓨터 시스템

본 개시내용은 개시내용의 방법을 구현하도록 프로그래밍된 컴퓨터 시스템을 제공한다. 도 14는 도 2의 블록체인 쿼리 서비스(102) 또는 캐시 엔진(200)을 구현하거나, 도 8 내지 도 12의 프로세스를 수행하도록 프로그래밍되거나 달리 구성된 컴퓨터 시스템(1401)을 보여준다.

컴퓨터 시스템(1401)은 싱글 코어 또는 멀티 코어 프로세서, 또는 병렬 프로세싱을 위한 복수의 프로세서일 수 있는 중앙 처리 장치(CPU, 여기서는 "프로세서" 및 "컴퓨터 프로세서"라고도 함)(1405)를 포함한다. 컴퓨터 시스템(1401)은 또한 메모리 또는 메모리 위치(1410)(예컨대, 랜덤 액세스 메모리, 리드 온리 메모리, 플래시 메모리), 전자 저장 유닛(1415)(예컨대, 하드 디스크), 하나 이상의 다른 시스템과의 통신을 위한 통신 인터페이스(1420)(예컨대, 네트워크 어댑터), 및 캐시, 기타 메모리, 데이터 저장 및/또는 전자 디스플레이 어댑터와 같은 주변 디바이스(1425)를 포함한다. 메모리(1410), 저장 유닛(1415), 인터페이스(1420), 및 주변 디바이스(1425)는 마더보드 같은 통신 버스(실선으로 표시)를 통해 CPU(1405)와 통신한다. 저장 유닛(1415)은 데이터를 저장하기 위한 데이터 저장 유닛(또는 데이터 레포지토리)일 수 있다. 컴퓨터 시스템(1401)은 통신 인터페이스(1420)의 도움으로 컴퓨터 네트워크("네트워크")(1430)에 작동 가능하게 결합될 수 있다. 네트워크(1430)는 인터넷, 인트라넷 및/또는 엑스트라넷, 또는 인터넷과 통신하는 인트라넷 및/또는 엑스트라넷일 수 있다. 경우에 따라 네트워크(1430)는 통신 및/또는 데이터 네트워크이다. 네트워크(1430)는 클라우드 컴퓨팅 같은 분산 컴퓨팅을 가능하게 할 수 있는 하나 이상의 컴퓨터 서버를 포함할 수 있다. 네트워크(1430)는 경우에 따라 컴퓨터 시스템(1401)의 도움으로 피어-투-피어 네트워크를 구현할 수 있으며, 이는 컴퓨터 시스템(1401)에 결합된 디바이스들이 클라이언트 또는 서버로서 동작하는 것을 가능하게 할 수 있다.

CPU(1405)는 프로그램 또는 소프트웨어에 수록될 수 있는 일련의 머신 판독 가능 명령어를 실행할 수 있다. 명령어는 메모리(1410)와 같은 메모리 위치에 저장될 수 있다. 명령어는 CPU(1405)를 대상으로 하여, 본 개시내용의 방법을 구현하도록 CPU(1405)를 후속적으로 프로그래밍하거나 달리 구성할 수 있다. CPU(1405)에 의해 수행되는 동작의 예는 페치(fetch), 디코딩(decode), 실행(execute) 및 라이트백(writeback)을 포함할 수 있다.

CPU(1405)는 집적 회로 같은 회로의 부분일 수 있다. 시스템(1401)의 하나 이상의 다른 컴포넌트가 그 회로에 포함될 수 있다. 경우에 따라 회로는 주문형 집적 회로(ASIC)이다.

저장 유닛(1415)은 드라이버, 라이브러리, 저장된 프로그램과 같은 파일을 저장할 수 있다. 저장 유닛(1415)은 사용자 데이터, 예를 들어, 사용자 설정(user preference) 및 사용자 프로그램을 저장할 수 있다. 일부 경우에 컴퓨터 시스템(1401)은 인트라넷 또는 인터넷을 통해 컴퓨터 시스템(1401)과 통신하는 원격 서버에 위치하는 것과 같이 컴퓨터 시스템(1401) 외부에 있는 하나 이상의 추가 데이터 저장 유닛을 포함할 수 있다.

컴퓨터 시스템(1401)은 네트워크(1430)를 통해 하나 이상의 원격 컴퓨터 시스템과 통신할 수 있다. 예를 들어, 컴퓨터 시스템(1401)은 사용자의 원격 컴퓨터 시스템(예컨대, 애플리케이션(116)이 구현되어 있는 컴퓨터)과 통신할 수 있다. 원격 컴퓨터 시스템의 예는 퍼스널 컴퓨터(예컨대, 휴대용 PC), 슬레이트 또는 태블릿 PC(예컨대, Apple® iPad, Samsung® Galaxy Tab), 전화기, 스마트폰(예컨대, Apple® iPhone, Android 지원 디바이스, Blackberry®), 또는 퍼스널 디지털 어시스턴트를 포함한다. 사용자는 네트워크(1430)를 통해 컴퓨터 시스템(1401)에 액세스할 수 있다.

여기에서 설명한 방법은 예컨대 메모리(1410) 또는 전자 저장 유닛(1415)과 같은, 컴퓨터 시스템(1401)의 전자 스토리지 위치 상에 저장된 머신(예컨대, 컴퓨터 프로세서) 실행 코드를 통해 구현될 수 있다. 머신 실행 또는 머신 판독 가능 코드는 소프트웨어의 형태로 제공될 수 있다. 사용 중에 코드는 프로세서(1405)에 의해 실행될 수 있다. 경우에 따라, 코드는 저장 유닛(1415)으로부터 리트리빙될 수 있고 프로세서(1405)에 의한 준비된 액세스를 위해 메모리(1410) 상에 저장될 수 있다. 상황에 따라, 전자 저장 유닛(1415)은 배제될 수 있고, 머신 실행 가능 명령어는 메모리(1410)에 저장된다.

코드는 미리 컴파일되어 코드를 실행하도록 적응된 프로세서를 구비한 머신와 함께 사용하도록 구성되거나 런타임 중에 컴파일될 수 있다. 코드는 미리 컴파일되거나 컴파일된 대로 실행 가능하도록 선택될 수 있는 프로그래밍 언어로 제공될 수 있다.

컴퓨터 시스템(1401)과 같은 여기에 제공된 시스템 및 방법의 양태들은 프로그래밍으로 구현될 수 있다. 기술의 다양한 양태들은 일반적으로 일종의 머신 판독 가능 매체에 포함되거나 구현되는 머신(또는 프로세서) 실행 코드 및/또는 연관된 데이터의 형태로 "제품" 또는 "제조품"으로 간주될 수 있다. 머신 실행 코드는 메모리(예컨대, 리드 온리 메모리, 랜덤 액세스 메모리, 플래시 메모리) 또는 하드 디스크 같은 전자 저장 유닛에 저장될 수 있다. "저장"형 매체는 다양한 반도체 메모리, 테이프 드라이브, 디스크 드라이브 등과 같은, 컴퓨터, 프로세서 등의 유형적 메모리, 또는 이들의 연관된 모듈의 일부 또는 전부를 포함할 수 있고, 소프트웨어 프로그래밍을 위해 언제든지 비일시적 스토리지를 제공할 수 있다. 소프트웨어의 전부 또는 일부는 때때로 인터넷이나 다양한 기타 통신 네트워크를 통해 통신될 수 있다. 예를 들어, 그러한 통신은 한 컴퓨터 또는 프로세서에서 다른 컴퓨터 또는 프로세서로, 예를 들어 관리 서버 또는 호스트 컴퓨터에서 애플리케이션 서버의 컴퓨터 플랫폼으로 소프트웨어의 로딩을 가능하게 할 수 있다. 따라서 소프트웨어 엘리먼트를 포함할 수 있는 또 다른 유형의 매체는 유선 및 광학 랜드라인 네트워크 및 다양한 에어 링크를 통해 로컬 디바이스 간의 물리적 인터페이스 전반에 걸쳐 사용되는 것과 같은 광학, 전기 및 전자기파를 포함한다. 유선 또는 무선 링크, 광 링크 등과 같이 이러한 전파를 전달하는 물리적 엘리먼트도 소프트웨어를 포함하는 매체로 간주될 수 있다. 여기에서 사용하는 바와 같이, 비일시적, 유형적 "저장" 매체로 제한되지 않는 한, 컴퓨터 또는 머신 "판독 가능 매체"와 같은 용어는 실행을 위해 프로세서에 명령어를 제공하는 데 참여하는 임의의 매체를 가리킨다.

따라서, 컴퓨터 실행 가능 코드와 같은 머신 판독 가능 매체는 유형적 저장 매체, 반송파 매체 또는 물리적 전송 매체를 포함하지만 이들에 제한되지 않는 다수의 형태를 취할 수 있다. 비휘발성 저장 매체는 예컨대, 도면에 도시한 데이터베이스 등을 구현하는 데 사용될 수 있는 임의의 컴퓨터 등의 임의의 저장 디바이스와 같은 광학 또는 자기 디스크를 포함한다. 휘발성 저장 매체는 이러한 컴퓨터 플랫폼의 메인 메모리와 같은 다이내믹 메모리를 포함한다. 유형적 전송 매체는 컴퓨터 시스템 내의 버스를 포함하는 와이어를 비롯해, 동축 케이블; 구리 와이어 및 광섬유를 포함한다. 반송파 전송 매체는 전기 또는 전자기 신호, 또는 고주파(RF) 및 적외선(IR) 데이터 통신 중에 생성되는 것과 같은 음향 또는 광파의 형태를 취할 수 있다. 따라서 일반적인 형태의 컴퓨터 판독 가능 매체는 예컨대: 플로피 디스크, 플렉서블 디스크, 하드 디스크, 자기 테이프, 기타 자기 매체, CD-ROM, DVD 또는 DVD-ROM, 기타 광학 매체, 펀치 카드 페이퍼 테이프, 홀 패턴이 있는 기타 물리적 저장 매체, RAM, ROM, PROM 및 EPROM, FLASH-EPROM, 기타 메모리 칩 또는 카트리지, 데이터 또는 명령어를 전송하는 반송파, 이러한 반송파를 전송하는 케이블 또는 링크, 또는 컴퓨터가 프로그래밍 코드 및/또는 데이터를 읽을 수 있는 기타 매체를 포함한다. 이들 형태의 컴퓨터 판독 가능 매체의 다수는 실행을 위해 프로세서에 하나 이상의 명령어의 하나 이상의 시퀀스를 전달하는 데 관련될 수 있다.

컴퓨터 시스템(1401)은, 예컨대 여기에서 설명하는 임의의 API 또는 애플리케이션(예컨대, 애플리케이션(116))을 제공하기 위한 사용자 인터페이스(UI)(1440)를 포함하는 전자 디스플레이(1435)를 포함하거나 이와 통신할 수 있다. UI의 예는, 제한 없이, 그래픽 사용자 인터페이스(GUI) 및 웹 기반 사용자 인터페이스를 포함한다.

본 개시내용의 방법 및 시스템은 하나 이상의 알고리즘을 통해 구현될 수 있다. 알고리즘은 중앙 처리 장치(1405)에 의해 실행될 때 소프트웨어를 통해 구현될 수 있다. 알고리즘은 예컨대 도 8과 같은 블록체인 크롤링 모드 또는 도 9와 같은 블록체인 리스닝 모드를 구현하는 알고리즘일 수 있다.

여기에 본 발명의 바람직한 실시형태를 개시하고 설명하였지만, 당업자에게는 이들 실시형태가 예에 불과할 뿐임이 명백할 것이다. 또한, 본 발명은 명세서 내에 제공된 특정 예에 의해 한정되는 것으로 의도되지 않는다. 본 발명은 이상의 상세한 설명을 참조하여 기술되었지만, 여기의 실시형태의 설명 및 예시는 제한적인 의미로 해석되어서는 안 된다. 다양한 변형, 변경 및 대체가 이제 본 발명으로부터 벗어나는 일 없이 당업자에게 이루어질 것이다. 더욱이, 본 발명의 모든 양태는 각종의 조건 및 변수에 종속되는 여기에 설명한 특정 묘사, 구성 또는 상대적인 비율에 제한되어서는 안된다. 본 발명을 실시할 때에 여기에 설명한 본 발명의 실시형태에 대한 다양한 대안이 채택될 수 있는 것이 이해될 것이다. 이에, 본 발명은 이러한 임의의 대안, 변형, 변화 및 동류도 포함하는 것으로 간주된다. 이하의 청구범위는 본 발명의 범주를 규정하고, 이에 이들 청구범위 및 그 균등한 범주 내의 방법 및 구조가 포함되는 것이다.

Claims

블록체인으로부터 데이터를 취득하기 위한 시스템에 있어서,
캐시 스토리지(cache storage) 및 블록체인 크롤러(blockchain crawler)를 포함한 캐시 엔진; 및
상기 캐시 엔진에 통신 가능하게 결합된 블록체인 쿼리 서비스를 포함하고,
상기 블록체인 크롤러는, 상기 블록체인으로부터 블록체인 데이터를 취득하고 상기 블록체인 데이터의 서브세트를 상기 캐시 스토리지에 기입(write)하거나 상기 블록체인 데이터의 상기 서브세트에 기초하여 상기 캐시 스토리지의 상태를 업데이트하도록 구성되고, 상기 블록체인 데이터의 상기 서브세트는 상기 캐시 엔진에 의해 생성된 쿼리를 만족시키며,
상기 블록체인 쿼리 서비스는 상태 스토리지 및 캐시 크롤러를 포함하고, 상기 캐시 크롤러는 상기 캐시 스토리지로부터 캐시 데이터를 취득하고 적어도 상기 캐시 데이터에 기초하여 상기 상태 스토리지의 상태를 업데이트하도록 구성되는, 시스템.
제1항에 있어서, 상기 블록체인 데이터의 상기 서브세트는 상기 블록체인 데이터 전부를 포함하는, 시스템.
제1항에 있어서, 상기 블록체인 쿼리 서비스는 상기 상태 스토리지의 상기 상태를 하나 이상의 애플리케이션에 전달하도록 구성된 서버를 포함하는, 시스템.
제1항에 있어서, 상기 블록체인 쿼리 서비스는 상기 블록체인으로부터 데이터를 직접 취득하도록 구성되지 않는, 시스템.
제1항에 있어서, 상기 캐시 크롤러는 쿼리 요청(query request) 또는 구독 요청(subscription request)을 상기 캐시 엔진에 전송함으로써 상기 캐시 스토리지로부터 상기 캐시 데이터를 취득하도록 구성되는, 시스템.
제1항에 있어서, 상기 쿼리는 상기 블록체인 쿼리 서비스로부터의 상기 쿼리 요청 또는 상기 구독 요청에 적어도 부분적으로 기초하는, 시스템.
제6항에 있어서, 상기 쿼리는 상기 캐시 스토리지의 현재 상태에 적어도 부분적으로 기초하는, 시스템.
제1항에 있어서, 상기 쿼리는 상기 블록체인에서 취득할 복수의 블록체인을 지정하는, 시스템.
제1항에 있어서, 상기 캐시 엔진은 상기 블록체인 데이터의 상기 서브세트를 상기 캐시 스토리지에 기입할 때 캐시 업데이트 이벤트를 전송하도록 구성되는, 시스템.
제1항에 있어서, 상기 쿼리는 일회성 쿼리인, 시스템.
제1항에 있어서, 상기 쿼리는 구독인, 시스템.
제11항에 있어서, 상기 구독은 만족시 상기 블록체인 크롤러로 하여금 상기 블록체인으로부터 데이터를 취득하게 하는 조건을 포함하는, 시스템.
제11항에 있어서, 상기 조건은 시간 또는 빈도를 포함하는, 시스템.
제11항에 있어서, 상기 조건은 상기 블록체인에 대한 이벤트를 포함하는, 시스템.
제1항에 있어서, 상기 블록체인 크롤러는 상기 블록체인 데이터의 상기 서브세트를 인덱싱된 포맷으로 상기 캐시 스토리지에 기입하도록 구성되는, 시스템.
제15항에 있어서, 상기 인덱싱된 포맷은 파일 시스템, 데이터베이스, 또는 인메모리(in-memory) 스토리지인, 시스템.
제1항에 있어서, 상기 블록체인 크롤러는 상기 블록체인 데이터의 상기 서브세트를 상기 캐시 스토리지에 기입하도록 구성된 상태 전환 엔진을 포함하는, 시스템.
제17항에 있어서, 상기 상태 전환 엔진은 상기 블록체인 데이터의 상기 서브세트를 생성하기 위해 상기 블록체인 데이터를 정규화, 인코딩, 디코딩, 직렬화, 역직렬화, 변환, 또는 필터링하도록 구성되는, 시스템.
제1항에 있어서, 상기 캐시 스토리지는 최대한 상기 블록체인의 전체 콘텐츠의 서브세트를 저장하도록 구성되는, 시스템.
제19항에 있어서, 상기 캐시 엔진은 지정된 시간 프레임 외부에서 발생한 트랜잭션에 해당하는 블록체인 데이터를 상기 캐시 스토리지로부터 프루닝(prune)하도록 구성되는, 시스템
제1항에 있어서, 상기 블록체인 쿼리 서비스는 복수의 블록체인 쿼리 서비스 중 하나이고, 상기 복수의 블록체인 쿼리 서비스 각각은 상기 캐시에 통신 가능하게 결합되는, 시스템.
제21항에 있어서, 상기 복수의 블록체인 쿼리 서비스는 상기 블록체인으로부터 데이터를 직접 취득하도록 구성되지 않는, 시스템.
제1항에 있어서, 복수의 추가 캐시 엔진을 더 포함하고, 상기 복수의 추가 캐시 엔진은 블록체인 크롤러를 포함하지 않으며, 상기 캐시 엔진의 상기 블록체인 크롤러는 상기 블록체인 데이터의 상기 서브세트를 상기 복수의 추가 캐시 엔진에 기입하도록 구성되는, 시스템.
제23항에 있어서, 상기 복수의 추가 캐시 엔진 각각은 적어도 하나의 추가 블록체인 쿼리 서비스에 통신 가능하게 결합되는, 시스템.
제1항에 있어서, 추가 캐시 엔진을 더 포함하고, 상기 블록체인 쿼리 서비스는 상기 추가 캐시 엔진에 통신 가능하게 결합되는, 시스템.
제25항에 있어서, 상기 추가 캐시 엔진은 추가 캐시 스토리지를 포함하고, 상기 캐시 스토리지와 상기 추가 캐시 스토리지는 동일한 데이터를 저장하는, 시스템.
제25항에 있어서, 상기 추가 캐시 엔진은 추가 캐시 스토리지를 포함하고, 상기 캐시 스토리지와 상기 추가 캐시 스토리지는 상이한 데이터를 저장하는, 시스템.
제1항에 있어서, 상기 캐시 엔진에 통신 가능하게 결합되고 상기 캐시 엔진에 관한 메타데이터를 저장하도록 구성된 캐시 레지스트리(cache registry)를 더 포함하고, 상기 캐시 엔진에 관한 상기 메타데이터는 상기 블록체인 쿼리 서비스를 포함한 복수의 블록체인 쿼리 서비스에 의해 액세스 가능한, 시스템.
제28항에 있어서, 상기 메타데이터는 상기 캐시 엔진의 고유 식별자를 포함하는, 시스템.
제28항에 있어서, 상기 메타데이터는 상기 캐시 엔진이 제공하는 서비스의 유형을 포함하는, 시스템.
블록체인으로부터 데이터를 취득하기 위한 시스템에 있어서,
시드(seed) 캐시 스토리지 및 블록체인 크롤러를 포함한 시드 캐시 엔진;
상기 시드 캐시 엔진에 통신 가능하게 결합된 복수의 캐시 엔진; 및
상기 복수의 캐시 엔진에 통신 가능하게 결합된 복수의 블록체인 쿼리 서비스를 포함하고,
상기 블록체인 크롤러는, 상기 블록체인으로부터 블록체인 데이터를 취득하고 상기 블록체인 데이터의 서브세트를 상기 시드 캐시 스토리지에 기입하거나 상기 블록체인 데이터의 상기 서브세트에 기초하여 상기 캐시 스토리지의 상태를 업데이트하도록 구성되고, 상기 블록체인 데이터의 상기 서브세트는 상기 시드 캐시 엔진에 의해 생성된 쿼리를 만족시키며,
상기 복수의 캐시 엔진 중의 캐시 엔진은 캐시 스토리지 및 캐시 크롤러를 포함하고, 상기 캐시 크롤러는 상기 시드 캐시 스토리지로부터 캐시 데이터를 취득하고 상기 캐시 데이터를 상기 캐시 스토리지에 기입하도록 구성되며,
상기 복수의 블록체인 쿼리 서비스는 상기 복수의 캐시 엔진을 조회하도록 구성되는, 시스템.
블록체인 데이터를 취득하기 위한 시스템에 있어서,
캐시 스토리지 및 블록체인 크롤러를 포함한 캐시 엔진; 및
상기 캐시 엔진에 통신 가능하게 결합된 블록체인 쿼리 서비스를 포함하고,
상기 블록체인 크롤러는, 오프체인 트랜잭션 스토리지로부터 블록체인 데이터를 취득하고 상기 블록체인 데이터의 서브세트를 상기 캐시 스토리지에 기입하거나 상기 블록체인 데이터의 상기 서브세트에 기초하여 상기 캐시 스토리지의 상태를 업데이트하도록 구성되고, 상기 블록체인 데이터의 상기 서브세트는 상기 캐시 엔진에 의해 생성된 쿼리를 만족시키며,
상기 블록체인 쿼리 서비스는 상태 스토리지 및 캐시 크롤러를 포함하고, 상기 캐시 크롤러는 상기 캐시 스토리지로부터 캐시 데이터를 취득하고 적어도 상기 캐시 데이터에 기초하여 상기 상태 스토리지의 상태를 업데이트하도록 구성되는, 시스템.
블록체인 데이터를 취득하기 위한 방법에 있어서,
(a) (i) 캐시 스토리지 및 블록체인 크롤러를 포함한 캐시 엔진 및 (ii) 상기 캐시 엔진에 통신 가능하게 결합된 블록체인 쿼리 서비스를 포함하는 블록체인 시스템을 제공하는 단계 - 상기 블록체인 쿼리 서비스는 상태 스토리지 및 캐시 크롤러를 포함함 -;
(b) 상기 블록체인 크롤러를 사용하여, 상기 블록체인로부터 블록체인 데이터를 취득하고 상기 블록체인 데이터의 서브세트를 상기 캐시 스토리지에 기입하거나 상기 블록체인 데이터의 상기 서브세트에 기초하여 상기 캐시 스토리지의 상태를 업데이트하는 단계 - 상기 블록체인 데이터의 상기 서브세트는 상기 캐시 엔진에 의해 생성된 쿼리를 만족시킴 -; 및
(c) 상기 캐시 크롤러를 사용하여, 상기 캐시 스토리지로부터 캐시 데이터를 취득하고 적어도 상기 캐시 데이터에 기초하여 상기 상태 스토리지의 상태를 업데이트하는 단계를 포함하는, 방법.
제33항에 있어서, 상기 블록체인 데이터의 상기 서브세트는 상기 블록체인 데이터 전부를 포함하는, 방법.
제33항에 있어서, 상기 블록체인 쿼리 서비스는 서버를 포함하고, 상기 방법은 상기 서버를 사용하여, 상기 상태 스토리지의 상기 상태를 하나 이상의 애플리케이션에 전달하는 단계를 더 포함하는, 방법.
제33항에 있어서, 상기 블록체인 쿼리 서비스는 상기 블록체인으로부터 데이터를 직접 취득하지 않는, 방법.
제33항에 있어서, (c)는 쿼리 요청 또는 구독 요청을 상기 캐시 엔진에 전송함으로써 상기 캐시 스토리지로부터 상기 캐시 데이터를 취득하는 단계를 포함하는, 방법.
제33항에 있어서, 상기 쿼리는 상기 블록체인 쿼리 서비스로부터의 상기 쿼리 요청 또는 상기 구독 요청에 적어도 부분적으로 기초하는, 방법.
제38항에 있어서, 상기 쿼리는 상기 캐시 스토리지의 현재 상태에 적어도 부분적으로 기초하는, 방법.
제33항에 있어서, 상기 쿼리는 상기 블록체인에서 취득할 복수의 블록체인을 지정하는, 방법.
제33항에 있어서, 상기 캐시 엔진을 사용하여, 상기 블록체인 데이터의 상기 서브세트를 상기 캐시 스토리지에 기입할 때 캐시 업데이트 이벤트를 전송하는 단계를 더 포함하는, 방법.
제33항에 있어서, 상기 쿼리는 일회성 쿼리인, 방법.
제33항에 있어서, 상기 쿼리는 구독인, 방법.
제43항에 있어서, 상기 구독은 만족시 상기 블록체인 크롤러로 하여금 상기 블록체인으로부터 데이터를 취득하게 하는 조건을 포함하는, 방법.
제43항에 있어서, 상기 조건은 시간 또는 빈도를 포함하는, 방법.
제43항에 있어서, 상기 조건은 상기 블록체인에 대한 이벤트를 포함하는, 방법.
제33항에 있어서, (b)는 상기 블록체인 데이터의 상기 서브세트를 인덱싱된 포맷으로 상기 캐시 스토리지에 기입하는 단계를 포함하는, 방법.
제47항에 있어서, 상기 인덱싱된 포맷은 파일 시스템, 데이터베이스, 또는 인메모리 스토리지인, 방법.
제33항에 있어서, 상기 블록체인 크롤러는 상태 전환 엔진을 포함하고, 상기 상태 전환 엔진은 상기 블록체인 데이터의 상기 서브세트를 상기 캐시 스토리지에 기입하는, 방법.
제49항에 있어서, (b)는 상기 상태 전환 엔진을 사용하여, 상기 블록체인 데이터의 상기 서브세트를 생성하기 위해 상기 블록체인 데이터를 정규화, 인코딩, 디코딩, 직렬화, 역직렬화, 변환, 또는 필터링하는 단계를 포함하는, 방법.
제33항에 있어서, 상기 캐시 스토리지는 최대한 상기 블록체인의 전체 콘텐츠의 서브세트를 저장하도록 구성되는, 방법.
제51항에 있어서, 지정된 시간 프레임 외부에서 발생한 트랜잭션에 해당하는 블록체인 데이터를 상기 캐시 스토리지로부터 프루닝하는 단계를 더 포함하는, 방법.
제33항에 있어서, 상기 블록체인 쿼리 서비스는 복수의 블록체인 쿼리 서비스 중 하나이고, 상기 복수의 블록체인 쿼리 서비스 각각은 상기 캐시에 통신 가능하게 결합되는, 방법.
제53항에 있어서, 상기 복수의 블록체인 쿼리 서비스는 상기 블록체인으로부터 데이터를 직접 취득하지 않는, 방법.
제33항에 있어서,
블록체인 크롤러를 포함하지 않는 복수의 추가 캐시 엔진을 제공하는 단계; 및
상기 캐시 엔진의 상기 블록체인 크롤러를 사용하여, 상기 블록체인 데이터의 상기 서브세트를 상기 복수의 추가 캐시 엔진에 기입하는 단계를 더 포함하는, 방법.
제55항에 있어서, 상기 복수의 추가 캐시 엔진 각각은 적어도 하나의 추가 블록체인 쿼리 서비스에 통신 가능하게 결합되는, 방법.
제33항에 있어서, 추가 캐시 엔진을 제공하는 단계를 더 포함하고, 상기 블록체인 쿼리 서비스는 상기 추가 캐시 엔진에 통신 가능하게 결합되는, 방법.
제57항에 있어서, 상기 추가 캐시 엔진은 추가 캐시 스토리지를 포함하고, 상기 캐시 스토리지와 상기 추가 캐시 스토리지는 동일한 데이터를 저장하는, 방법.
제57항에 있어서, 상기 추가 캐시 엔진은 추가 캐시 스토리지를 포함하고, 상기 캐시 스토리지와 상기 추가 캐시 스토리지는 상이한 데이터를 저장하는, 방법.
제33항에 있어서,
상기 캐시 엔진에 통신 가능하게 결합되는 캐시 레지스트리를 제공하는 단계; 및
상기 캐시 엔진에 관한 메타데이터를 상기 캐시 레지스트리에 저장하는 단계를 더 포함하고,
상기 캐시 엔진에 관한 상기 메타데이터는 상기 블록체인 쿼리 서비스를 포함한 복수의 블록체인 쿼리 서비스에 의해 액세스 가능한, 방법.
제60항에 있어서, 상기 메타데이터는 상기 캐시 엔진의 고유 식별자를 포함하는, 방법.
제60항에 있어서, 상기 메타데이터는 상기 캐시 엔진이 제공하는 서비스의 유형을 포함하는, 방법.