KR20230101883A - 머클 증명 엔티티 - Google Patents

Abstract

블록체인 트랜잭션이 블록체인 상에 존재한다는 증명을 제공하는 컴퓨터 구현 방법이 제공되며, 방법은 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하지만, 블록체인 네트워크에 새로운 블록체인 블록들을 공개하지 않도록 구성된 머클 증명 엔티티에 의해 수행되고, 방법은, 타겟 블록체인 트랜잭션의 타겟 트랜잭션 식별자를 획득하는 단계 ― 타겟 트랜잭션 식별자는 저장된 트랜잭션 식별자들의 세트의 일부를 형성함 ― ; 타겟 블록체인 트랜잭션에 대한 타겟 머클 증명을 획득하는 단계 ― 대응하는 타겟 머클 루트는 블록체인의 블록헤더 내에 포함됨 ― ; 및 타겟 블록체인 트랜잭션이 블록체인 상에 존재한다는 증명으로서 요청 당사자에 의한 사용을 위해 타겟 머클 증명을 출력하는 단계를 포함한다

Description

머클 증명 엔티티

본 개시내용은 블록체인 트랜잭션이 블록체인 상에 존재한다는 증명을 제공하고 획득하는 방법들에 관한 것이다.

블록체인은 블록체인의 복제본이 분산 P2P(Peer-to-Peer) 네트워크(이하 "블록체인 네트워크"로서 지칭됨) 내 복수의 노드들 각각에서 유지되며 널리 공개되는 분산 데이터 구조의 형태를 지칭한다. 블록체인은 데이터의 블록들의 체인을 포함하며, 각각의 블록은 하나 이상의 트랜잭션들을 포함한다. 소위 "코인베이스 트랜잭션(coinbase transaction)들"이 아닌 각각의 트랜잭션은 시퀀스 내 이전 트랜잭션을 다시 가리키며, 이는 하나 이상의 블록들에 걸쳐 있어 하나 이상의 코인베이스 트랜잭션들로 되돌아갈 수 있다. 코인베이스 트랜잭션은 아래에서 추가로 논의된다. 블록체인 네트워크에 제출된 트랜잭션들은 새로운 블록들에 포함된다. 새로운 블록들은 복수의 노드들 각각이 "작업 증명"을 수행하기 위해 경쟁하는 것 즉, 블록체인의 새로운 블록에 포함되기를 기다리는, 순서화되고 유효성 검증된 보류중인 트랜잭션들의 정의된 세트의 표현에 기초하여 암호화 퍼즐을 해결하는 것을 수반하는 "채굴"로서 지칭되는 프로세스에 의해 생성된다. 블록체인은 일부 노드들에서 프루닝(prune)될 수 있으며 블록들의 공개는 단순 블록 헤더들의 공개를 통해 달성될 수 있다는 것이 주의되어야 한다.

블록체인의 트랜잭션들은 다음 목적들: 디지털 자산(예컨대, 다수의 디지털 토큰들)을 전달하는 것, 가상화된 원장 또는 레지스트리 내 엔트리들의 세트를 순서화하는 것, 타임스탬프 엔트리들을 수신 및 프로세싱하는 것, 그리고/또는 인덱스 포인터들을 시간-순서화하는 것 중 하나 이상을 위해 사용될 수 있다. 블록체인 위에 부가적인 기능성을 쌓기 위해 블록체인이 또한 활용될 수 있다. 예컨대, 블록체인 프로토콜들은 트랜잭션의 데이터에의 부가적인 사용자 데이터 또는 인덱스들의 저장을 허용할 수 있다. 단일 트랜잭션 내에 저장될 수 있는 최대 데이터 용량에 대해 미리 지정된 제한이 없고 이에 따라 점점 더 복잡한 데이터가 통합될 수 있다. 예컨대, 이는 블록체인에 전자 문서를 저장하거나, 오디오 또는 비디오 데이터를 저장하는 데 사용될 수 있다.

블록체인 네트워크의 노드들(종종 "채굴자들"로서 지칭됨)은 분산 트랜잭션 등록 및 검증 프로세스를 수행하며, 이는 나중에 보다 자세히 설명될 것이다. 요약하면, 이 프로세스 동안, 노드는 트랜잭션들을 유효성 검증하여 유효한 작업 증명 솔루션을 식별하려고 시도하는 블록 템플릿에 삽입한다. 유효한 솔루션이 발견되면, 새로운 블록이 네트워크의 다른 노드들로 전파되고, 이에 따라 각각의 노드가 블록체인 상에 새로운 블록을 레코딩하는 것을 가능하게 한다. 트랜잭션을 블록체인에 레코딩하기 위해, 사용자(예컨대, 블록체인 클라이언트 애플리케이션)는 트랜잭션을 전파될 네트워크의 노드들 중 하나로 전송한다. 트랜잭션을 수신하는 노드들은 유효성 검증된 트랜잭션을 새로운 블록에 통합하는 작업 증명 솔루션을 찾기 위해 경합할 수 있다. 각각의 노드는 트랜잭션이 유효하기 위한 하나 이상의 조건들을 포함하는 동일한 노드 프로토콜을 시행하도록 구성된다. 유효하지 않은 트랜잭션들은 블록들 내로 통합되거나 전파되지 않을 것이다. 트랜잭션이 유효성 검증되고 그리하여 블록체인 상에 수락된다고 가정하면, 트랜잭션(임의의 사용자 데이터 포함함)은 이에 따라 불변의 공개 레코드로서 블록체인 네트워크 내 노드들 각각에 등록되고 인덱싱된 상태로 유지된다.

최신 블록을 생성하기 위해 작업 증명 퍼즐을 성공적으로 해결한 노드는 통상적으로 디지털 자산의 금액, 즉 다수의 토큰들을 분배하는 "코인베이스 트랜잭션"이라 불리는 새로운 트랜잭션으로 보상을 받는다. 유효하지 않은 트랜잭션들의 검출 및 거절은 네트워크의 에이전트들로서 작용하는 경쟁 노드들의 액션에 의해 시행되며 불법 행위를 보고하고 차단하도록 장려된다. 광범위한 정보 공개는 사용자들이 노드들의 성능을 지속적으로 감사하도록 허용한다. 단순 블록 헤더들의 공개는 참가자들이 블록체인의 지속적인 무결성을 보장하도록 허용한다.

"출력 기반" 모델(때로는 UTXO 기반 모델로서 지칭됨)에서, 주어진 트랜잭션의 데이터 구조는 하나 이상의 입력들 및 하나 이상의 출력들을 포함한다. 임의의 지출 가능한 출력은 진행중인 트랜잭션 시퀀스로부터 도출 가능한 디지털 자산의 금액을 지정하는 요소를 포함한다. 지출 가능한 출력은 때로는 UTXO("미지출 트랜잭션 출력")로서 지칭된다. 출력은 출력의 향후 리딤션(redemption)을 위한 조건을 지정하는 잠금 스크립트를 더 포함할 수 있다. 잠금 스크립트는 디지털 토큰들 또는 자산들을 유효성 검증하고 이전하는 데 필요한 조건들을 정의하는 술어이다. (코인베이스 트랜잭션 이외의) 트랜잭션의 각각의 입력은 선행 트랜잭션의 이러한 출력에 대한 포인터(즉, 참조)를 포함하고, 가리켜진 출력의 잠금 스크립트를 잠금해제하기 위한 잠금해제 스크립트를 더 포함할 수 있다. 따라서 트랜잭션들의 쌍을 고려하고, 이들을 제1 및 제2 트랜잭션(또는 "타겟" 트랜잭션)이라고 한다. 제1 트랜잭션은 출력을 잠금해제하는 하나 이상의 조건들을 정의하는 잠금 스크립트를 포함하고 디지털 자산의 금액을 지정하는 적어도 하나의 출력을 포함한다. 제2의 타겟 트랜잭션은 제1 트랜잭션의 출력에 대한 포인터를 포함하는 적어도 하나의 입력, 및 제1 트랜잭션의 출력을 잠금해제하기 위한 잠금해제 스크립트를 포함한다.

이러한 모델에서, 제2의 타겟 트랜잭션이 블록체인 네트워크에 전송되어 블록체인에서 전파 및 레코딩될 때, 각각의 노드에 적용되는 유효성에 대한 기준들 중 하나는, 잠금해제 스크립트가 제1 트랜잭션의 잠금 스크립트에 정의된 하나 이상의 조건들 전부 충족하는 것일 것이다. 다른 하나는 제1 트랜잭션의 출력이 다른 더 앞선 유효한 트랜잭션에 의해 이미 리딤되지 않았다는 것일 것이다. 이러한 조건들 중 임의의 것에 따라 유효하지 않은 타겟 트랜잭션을 발견한 임의의 노드는 이를 전파하지 않거나(유효한 트랜잭션으로서 전파하지 않으나, 어쩌면, 유효하지 않은 트랜잭션을 등록하기 위해 전파함) 블록체인에 레코딩될 새로운 블록에 이를 포함시키지 않을 것이다.

대안적인 유형의 트랜잭션 모델은 계정 기반 모델이다. 이 경우에 각각의 트랜잭션은 과거 트랜잭션들의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하기 보다는, 절대 계정 잔액을 참조함으로써 전달될 금액을 정의한다. 모든 계정들의 현재 상태는 블록체인과 별개로 노드들에 의해 저장되며 지속적으로 업데이트된다.

머클 증명은 일반적으로 블록체인 상의 트랜잭션의 존재를 검증하는 데 사용된다. 특정 트랜잭션이 블록체인 상에 존재한다는 것을 검증하기 원하는 당사자(예컨대, 사용자)는 블록체인 노드에서 머클 증명(Merkle proof)을 찾을 수 있다. 수신된 머클 증명을 이용하여, 블록체인의 블록에 포함된 머클 루트와 매칭되는 값으로 트랜잭션을 추적할 수 있다면, 사용자는 해당 트랜잭션이 블록체인 상에 존재한다고 확신할 수 있다. 절대적인 확실성을 위해 부가적인 체크가 요구될 수 있다는 것에 주의한다.

현재 머클 증명을 제공하는 유일한 엔티티는 블록체인 노드(채굴자라고도 함)이다. 위에서 언급된 바와 같이, 블록체인 노드는 주로 트랜잭션 유효성 검증, 블록 구성 및 공개와 관련이 있다.

블록체인 기술의 사용은 계속 증가하고 있으며, 이로써 블록체인 시스템은 증가하는 사용량 및 수요에 매칭되도록 스케일링될 수 있을 필요가 있다. 블록체인 시스템을 스케일링하는 하나의 접근법은 블록의 크기, 트랜잭션들의 레이트를 확장하고, 블록체인 기술을 다양한 데이터 애플리케이션의 변경 불가능한 원장(immutable ledger)으로서 사용하는 것이다. 이것은 블록체인의 크기 및 트랜잭션 유효성 검증에 소요되는 프로세싱 량을 극적으로 증가시킬 것이다. 따라서, 전체 블록체인을 저장하고 트랜잭션을 유효성 검증하고 트랜잭션에 관한 질의에 응답하기 위한 자원들은 최종 사용자와 서비스 제공자에게 (저장 및 프로세싱 요건들 관점에서) 너무 많은 비용이 들 수 있다. 따라서 전체 블록체인을 저장해야 할 필요 없이 트랜잭션이 블록체인 상에 존재한다는 증명을 제공할 수 있는 엔티티가 필요하다.

따라서 트랜잭션이 블록체인 상에 존재한다는 증명을 제공할 수 있는 보다 자원 효율적인 엔티티가 필요하다.

본원에서 개시된 일 양상에 따르면, 블록체인 트랜잭션이 블록체인 상에 존재한다는 증명을 제공하는 컴퓨터 구현 방법이 제공되며, 방법은 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하지만, 블록체인 네트워크에 새로운 블록체인 블록들을 공개하지 않도록 구성된 머클 증명 엔티티에 의해 수행되고, 방법은, 타겟 블록체인 트랜잭션의 타겟 트랜잭션 식별자를 획득하는 단계 ― 타겟 트랜잭션 식별자는 저장된 트랜잭션 식별자들의 세트의 일부를 형성함 ― ; 타겟 블록체인 트랜잭션에 대한 타겟 머클 증명을 획득하는 단계 ― 대응하는 타겟 머클 루트는 블록체인의 블록헤더 내에 포함됨 ― ; 및 타겟 블록체인 트랜잭션이 블록체인 상에 존재한다는 증명으로서 요청 당사자에 의한 사용을 위해 타겟 머클 증명을 출력하는 단계를 포함한다.

아래에서 머클 증명 서버(MPS)로서 또한 지칭되는 머클 증명 엔티티는 새로운 블록체인 블록들을 구성하고 그리고/또는 블록체인 네트워크에 공개해야 할 필요 없이 요청 당사자에게 머클 증명들을 제공할 수 있고 이에 따라 블록체인 노드보다 덜 자원 집약적이다. 블록체인 네트워크에 새로운 블록을 공개한다는 것은 블록체인 상의 블록에 아직 공개되지 않은 트랜잭션들을 포함하는 이전에 확인되지 않은 블록(previously unseen block)을 분배하는 것을 의미한다. 또한, 일부 예들에서, MPS는 전체 블록체인을 저장할 필요가 없고, 이에 따라 블록체인 노드들에 비해 상당히 감소된 저장 요건을 갖는다. 데이터 저장, 데이터 검색 및 데이터 리트리벌(data retrieval)은 관련 정보만을 저장함으로써 최적화되며, 이 경우에, 관련 정보는 저장된 트랜잭션 식별자들만큼 적다.

MPS는 해당 트랜잭션의 개개의 트랜잭션 식별자(즉, 트랜잭션 데이터 자체가 아님)만을 저장함으로써 임의의 공개된 트랜잭션에 대한 머클 증명을 제공할 수 있다. 일부 경우들에서, MPS는 블록체인 트랜잭션들의 특정 세트 예컨대, 토큰화된 또는 메타넷 트랜잭션들과 같은 특정 애플리케이션 또는 서비스와 관련된 트랜잭션들의 트랜잭션 식별자들만을 저장할 수 있다. 그 후 MPS는 임의의 토큰화된 또는 메타넷 트랜잭션의 존재를 검증하는 데 사용될 수 있다.

MPS는 모든 공개된 트랜잭션들(또는 적어도 공개된 트랜잭션들의 세트)의 트랜잭션 ID들(TxID)을 저장하도록 요구된다. MPS는 트랜잭션 식별자들(TxID) 또는 전체 트랜잭션들에 의한 질의(query)들을 지원할 수 있다.

MPS는 블록들을 구성하고 그리고/또는 블록체인 상에 공개하는 동작들을 수행하지 않는다. 즉, 머클 증명 엔티티는 블록체인 노드가 아니다. 일부 예들에서, 머클 증명 엔티티는 임의의 블록체인 트랜잭션들을 저장하지 않는다. 다른 예들에서, 머클 증명 엔티티는 블록 당 단 하나의 블록체인 트랜잭션만을 저장한다. 또 다른 예들에서, 머클 증명 엔티티는 블록당 하나 초과를 저장하지만 모든 블록체인 트랜잭션보다 적게 저장한다.

본원에서 개시된 다른 양상에 따르면, 블록체인 트랜잭션이 블록체인 상에 존재한다는 증명을 획득하는 컴퓨터 구현 방법이 제공되며, 머클 증명 엔티티는 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하고, 머클 증명 엔티티는 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하지만 블록체인 네트워크에 새로운 블록체인 블록들을 공개하지 않도록 구성되며, 방법은 요청 당사자에 의해 수행되고, 타겟 블록체인 트랜잭션 및/또는 타겟 트랜잭션의 타겟 트랜잭션 식별자를 머클 증명 엔티티에 전송하는 단계; 및 머클 증명 엔티티로부터, 타겟 블록체인 트랜잭션에 대한 타겟 머클 증명을 획득하는 단계를 포함하고, 머클 증명은 저장된 트랜잭션 식별자들의 세트 중 하나 이상에 기초한다.

본 개시내용의 실시예들의 이해를 보조하기 위해 그리고 그러한 실시예들이 어떻게 실행될 수 있는지를 보여주기 위하여, 단지 예로서 첨부 도면들에 대한 참조가 이루어진다.
도 1은 블록체인을 구현하기 위한 시스템의 개략적인 블록도이다.
도 2는 블록체인에 레코딩될 수 있는 트랜잭션들의 일부 예들을 개략적으로 예시한다.
도 3a는 클라이언트 애플리케이션의 개략적인 블록도이다.
도 3b는 도 3a의 클라이언트 애플리케이션에 의해 제공될 수 있는 예시적인 사용자 인터페이스의 개략적인 실물 모형이다.
도 4는 예시적인 머클 트리를 개략적으로 예시한다.
도 5는 예시적인 머클 증명을 개략적으로 예시한다.
도 6a 및 도 6b는 본 발명의 일부 실시예들에 따른 예시적인 시스템을 개략적으로 예시한다.
도 7은 본 발명의 일부 실시예들에 따른, 보조 머클 증명 엔티티에 의해 저장된 데이터를 개략적으로 예시한다.
도 8은 본 발명의 일부 실시예들에 따른 예시적인 방법을 예시한다.

예시적인 시스템 개요

도 1은 블록체인(150)을 구현하기 위한 예시적인 시스템(100)을 도시한다. 시스템(100)은 패킷-교환 네트워크(101), 통상적으로 인터넷과 같은 광역 인터네트워크를 포함할 수 있다. 패킷-교환 네트워크(101)는 패킷-교환 네트워크(101) 내에서 P2P(peer-to-peer) 네트워크(106)를 형성하도록 배열될 수 있는 복수의 블록체인 노드들(104)을 포함한다. 예시되지는 않았지만, 블록체인 노드들(104)은 거의 완전한 그래프로서 배열될 수 있다. 따라서, 각각의 블록체인 노드(104)는 다른 블록체인 노드들(104)에 고도로 연결된다.

각각의 블록체인 노드(104)는 피어들의 컴퓨터 장비를 포함하며, 노드들(104) 중 상이한 노드들은 상이한 피어에 속한다. 각각의 블록체인 노드(104)는 하나 이상의 프로세서들, 예컨대, 하나 이상의 CPU(central processing unit)들, 가속기 프로세서들, 애플리케이션 특정 프로세서 및/또는 FPGA(field programmable gate array)들, 및 다른 장비 이를테면, ASIC(application specific integrated circuit)들을 포함하는 프로세싱 장치를 포함한다. 각각의 노드는 또한 메모리, 즉 비-일시적 컴퓨터-판독 가능 매체 또는 매체들의 형태의 컴퓨터-판독 가능 저장소를 포함한다. 메모리는 하나 이상의 메모리 매체들, 예컨대, 하드 디스크와 같은 자기 매체; 솔리드 스테이트 드라이브(SSD), 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광학 디스크 드라이브와 같은 광학 매체를 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다.

블록체인(150)은 데이터의 블록들의 체인(151)을 포함하며, 여기서 블록체인(150)의 개개의 사본은 분산 또는 블록체인 네트워크(106) 내 복수의 블록체인 노드들(104) 각각에서 유지된다. 위에서 언급된 바와 같이, 블록체인(150)의 사본을 유지하는 것은 반드시 블록체인(150)을 전부 저장하는 것을 의미하지는 않는다. 대신, 블록체인(150)은 각각의 블록체인 노드(150)가 각각의 블록(151)의 블록 헤더(아래에서 논의됨)를 저장하는 한, 정리된 상태의 데이터일 수 있다. 체인의 각각의 블록(151)은 하나 이상의 트랜잭션들(152)을 포함하며, 여기서 이 맥락에서 트랜잭션은 일종의 데이터 구조를 지칭한다. 데이터 구조의 성질은 트랜잭션 모델 또는 체계(scheme)의 일부로서 사용되는 트랜잭션 프로토콜의 유형에 의존할 것이다. 주어진 블록체인은 전반에 걸쳐 하나의 특정 트랜잭션 프로토콜을 사용할 것이다. 하나의 공통 유형의 트랜잭션 프로토콜에서, 각각의 트랜잭션(152)의 데이터 구조는 적어도 하나의 입력 및 적어도 하나의 출력을 포함한다. 각각의 출력은 재산으로서 디지털 자산의 양을 표현하는 금액을 지정하며, 그의 예는 출력이 암호학적으로 잠겨 있는 사용자(103)이다(이는 잠금해제되고 그리하여 리딤(redeem) 또는 지출되기 위해 그 사용자의 서명 또는 다른 솔루션을 요구함). 각각의 입력은 선행 트랜잭션(152)의 출력을 뒤로 가리키고, 그리하여 트랜잭션들을 링크한다.

각각의 블록(151)은 또한 블록들(151)에 대한 순차적인 순서를 정의하기 위해 체인에서 이전에 생성된 블록(151)을 뒤로 가리키는 블록 포인터(155)를 포함한다. (코인베이스 트랜잭션 외의) 각각의 트랜잭션(152)은 트랜잭션들의 시퀀스들에 대한 순서를 정의하기 위해 이전 트랜잭션에 대한 역 포인터를 포함한다(트랜잭션들(152)의 시퀀스들은 분기가 허용됨을 주의함). 블록들의 체인(151)은 체인의 최초 블록이었던 제네시스(genesis) 블록(Gb)(153)까지 완전히 거슬러 올라간다. 체인(150) 초반의 하나 이상의 오리지널 트랜잭션들(152)은 선행 트랜잭션이 아닌 제네시스 블록(153)을 가리켰다.

블록체인 노드들(104) 각각은 트랜잭션들(152)을 다른 블록체인 노드들(104)로 포워딩하고 그리하여 트랜잭션들(152)이 네트워크(106) 전체에 전파되게 하도록 구성된다. 각각의 블록체인 노드(104)는 블록들(151)을 생성하고 동일한 블록체인(150)의 개개의 사본을 그들 개개의 메모리에 저장하도록 구성된다. 각각의 블록체인 노드(104)는 또한 블록(151)에 통합되기를 기다리는 트랜잭션들(152)의 순서화된 세트(또는 "풀")(154)를 유지한다. 순서화된 풀(154)은 종종 "멤풀(mempool)"로서 지칭된다. 본원에서 이 용어는 임의의 특정 블록체인, 프로토콜 또는 모델에 제한되는 것으로 의도되지 않는다. 이는 노드(104)가 유효한 것으로 수락하고 노드(104)가 동일한 출력을 지출하려고 시도하는 임의의 다른 트랜잭션들을 수락하지 않을 의무가 있는 트랜잭션들의 순서화된 세트를 지칭한다.

주어진 현재 트랜잭션(152j)에서, 그(또는 각각의) 입력은 트랜잭션들의 시퀀스에서 선행 트랜잭션(152i)의 출력을 참조하는 포인터를 포함하여, 그러한 출력이 현재 트랜잭션(152j)에서 "지출"되거나 리딤됨을 지정한다. 일반적으로, 선행 트랜잭션은 순서화된 세트(154) 또는 임의의 블록(151)의 임의의 트랜잭션일 수 있다. 선행 트랜잭션(152i)은 현재 트랜잭션(152j)이 생성되거나 심지어 네트워크(106)로 전송될 때 반드시 존재할 필요는 없지만, 선행 트랜잭션(152i)은 현재 트랜잭션이 유효하기 위해 존재하고 유효성 검증될 필요가 있을 것이다. 따라서 본원에서 "선행(preceding)"이라 함은 포인터들에 의해 링크된 논리적 시퀀스의 선행자를 지칭하며, 반드시 시간적 시퀀스의 전송 또는 생성 시간은 아니고, 따라서 트랜잭션들(152i, 152j)은 순서와 다르게(out-of-order)(고아 트랜잭션들에 대한 아래 논의 참조) 전송되거나 생성되는 것을 반드시 배제하지 않는다. 선행 트랜잭션(152i)은 앞선(antecedent) 트랜잭션 또는 선행자(predecessor) 트랜잭션으로 동등하게 칭해질 수 있다.

현재 트랜잭션(152j)의 입력은 또한 입력 인가, 예컨대, 선행 트랜잭션(152i)의 출력이 잠겨 있는 사용자(103a)의 서명을 포함한다. 차례로, 현재 트랜잭션(152j)의 출력은 새로운 사용자 또는 엔티티(103b)에 암호학적으로 잠길 수 있다. 따라서 현재 트랜잭션(152j)은 선행 트랜잭션(152i)의 입력에서 정의된 금액을 현재 트랜잭션(152j)의 출력에서 정의된 바와 같은 새로운 사용자 또는 엔티티(103b)에 전달할 수 있다. 일부 경우들에서 트랜잭션(152)은 다수의 사용자들 또는 엔티티들(이들 중 하나는 잔돈(change)을 주기 위해 오리지널 사용자 또는 엔티티들(103a)일 수 있음) 사이에서 입력 금액을 분할하기 위해 다수의 출력들을 가질 수 있다. 일부 경우에서 트랜잭션은 또한 하나 이상의 선행 트랜잭션들의 다수의 출력들로부터 금액들을 수집하고 현재 트랜잭션의 하나 이상의 출력들에 재분배하기 위해 다수의 입력들을 가질 수 있다.

비트코인과 같은 출력-기반 트랜잭션 프로토콜에 따르면, 개별 사용자 또는 조직과 같은 당사자(103)가 새로운 트랜잭션(152j)을 제정(enact)하기를 원할 때(수동으로 또는 당사자에 의해 사용되는 자동화된 프로세스에 의해) 제정 당사자는 자신의 컴퓨터 단말(102)로부터 수령인에게 새로운 트랜잭션을 전송한다. 제정 당사자 또는 수령인은 결국, 이 트랜잭션을 네트워크(106)의 블록체인 노드들(104) 중 하나 이상(이는 요즘에는, 통상적으로 서버들 또는 데이터 센터들이지만, 원칙적으로는 다른 사용자 단말들일 수 있음)에 전송할 것이다. 그것은 또한 새로운 트랜잭션(152j)을 제정하는 당사자(103)가 일부 예들에서는 수령인이 아니라, 블록체인 노드들(104) 중 하나 이상에 직접 트랜잭션을 전송할 수 있는 것이 배제되지 않는다. 트랜잭션을 수신한 블록체인 노드(104)는 블록체인 노드들(104) 각각에 적용되는 블록체인 노드 프로토콜에 따라 트랜잭션이 유효한지를 체크한다. 블록체인 노드 프로토콜은 통상적으로 블록체인 노드(104)가 새로운 트랜잭션(152j)의 암호화 서명이 예상되는 서명과 매칭되는지를 체크하도록 요구하며, 이는 트랜잭션들(152)의 순서화된 시퀀스에서 이전 트랜잭션(152i)에 의존한다. 이러한 출력-기반 블록체인 프로토콜에서, 이는 새로운 트랜잭션(152j)의 입력에 포함된 당사자(103)의 암호화 서명 또는 다른 인가가 새로운 트랜잭션이 할당하는 선행 트랜잭션(152i)의 출력에 정의된 조건과 매칭되는지를 체크하는 것을 포함하며, 여기에서 이 조건은 통상적으로 적어도 새로운 트랜잭션(152j)의 입력의 암호화 서명 또는 다른 인가가 새로운 트랜잭션의 입력이 링크되는 이전 트랜잭션(152i)의 출력을 잠금해제한다는 것을 체크하는 것을 포함한다. 조건은 선행 트랜잭션(152i)의 출력에 포함된 스크립트에 의해 적어도 부분적으로 정의될 수 있다. 대안적으로 이는 단순히 블록체인 노드 프로토콜만으로 고정되거나, 이들의 조합으로 인한 것일 수 있다. 어느 쪽이든, 새로운 트랜잭션(152j)이 유효한 경우, 블록체인 노드(104)는 이를 블록체인 네트워크(106) 내 하나 이상의 다른 블록체인 노드들(104)에 포워딩한다. 이러한 다른 블록체인 노드들(104)은 동일한 블록체인 노드 프로토콜에 따라 동일한 테스트를 적용하고, 이에 따라 새로운 트랜잭션(152j)을 하나 이상의 추가 노드들(104)로 포워딩하는 식이다. 이러한 방식으로, 새로운 트랜잭션은 블록체인 노드들(104)의 네트워크 전반에 걸쳐 전파된다.

출력-기반 모델에서, 주어진 출력(예컨대, UTXO)이 할당(예컨대, 지출)되는지 여부에 대한 정의는 그것이 블록체인 노드 프로토콜에 따라 다른 전방 트랜잭션(152j)의 입력에 의해 유효하게 리딤되었는지의 여부이다. 트랜잭션이 유효하기 위한 다른 조건은 리딤을 시도하는 선행 트랜잭션(152i)의 출력이 다른 트랜잭션에 의해 이미 리딤되지 않은 것이다. 재차, 유효하지 않은 경우, (무효로서 플래깅되고 경고를 위해 전파되지 않는 한) 트랜잭션(152j)은 블록체인(150)에 레코딩되거나 전파되지 않을 것이다. 이는 트랜잭터가 동일한 트랜잭션의 출력을 한번 초과로 할당하고자 시도하는 이중-지출을 경계한다. 반면, 계정-기반 모델은 계정 잔액을 유지함으로써 이중-지출을 경계한다. 재차, 트랜잭션들의 정의된 순서가 존재하기 때문에, 계정 잔액은 임의의 한 시간에 단일의 정의된 상태를 갖는다.

트랜잭션들을 유효성 검증하는 것 외에도, 블록체인 노드들(104)은 또한 일반적으로 "작업 증명"에 의해 지원되는 채굴로서 지칭되는 프로세스에서 트랜잭션들의 블록들을 생성하는 첫 번째가 되기 위해 경쟁한다. 블록체인 노드(104)에서, 새로운 트랜잭션들은 블록체인(150) 상에 레코딩된 블록(151)에 아직 나타나지 않은 유효한 트랜잭션들의 순서화된 풀(154)에 추가된다. 그 후, 블록체인 노드들은 암호화 퍼즐을 해결하도록 시도함으로써 트랜잭션들의 순서화된 세트(154)로부터 트랜잭션들(152)의 새로운 유효한 블록(151)을 조립하기 위해 경쟁한다. 통상적으로 이는 "논스(nonce)"가 계류중인 트랜잭션들(154)의 순서화된 풀의 표현과 컨케터네이팅되고(concatenated) 해시될 때, 해시의 출력이 미리 결정된 조건을 충족시키도록 논스 값을 검색하는 것을 포함한다. 예컨대, 미리 결정된 조건은 해시의 출력이 미리 정의된 특정 수의 선행 0들을 갖는 것일 수 있다. 이는 작업 증명 퍼즐의 단 하나의 특정 유형일 뿐이며 다른 유형들도 배제되지 않는다는 것에 주의한다. 해시 함수의 속성은 해시 함수가 그의 입력에 대해 예측 불가능한 출력을 갖는다는 것이다. 따라서 이 검색은 무차별 대입(brute force)에 의해서만 수행될 수 있고, 이에 따라 퍼즐을 해결하고자 하는 각각의 블록체인 노드(104)에서 상당한 양의 프로세싱 자원을 소비한다.

퍼즐을 해결하고자 하는 제1 블록체인 노드(104)는 이를 네트워크(106)에 발표하고, 그 솔루션을 증명으로서 제공하며, 이는 그 후 네트워크의 다른 블록체인 노드(104)들에 의해 쉽게 체크될 수 있다(해시에 대한 해가 주어지면, 그 해가 해시의 출력으로 하여금 조건을 충족시키게 한다는 것을 체크하는 것은 간단함). 제1 블록체인 노드(104)는 블록을 수락하고 이에 따라 프로토콜 규칙들을 시행하는 다른 노드들의 임계 컨센서스에 블록을 전파한다. 트랜잭션들의 순서화된 세트(154)는 그 후 블록체인 노드들(104) 각각에 의해 블록체인(150)에 새로운 블록(151)으로서 레코딩된다. 블록 포인터(155)가 또한 체인에서 이전에 생성된 블록(151n-1)을 뒤로 가리키는 새로운 블록(151n)에 할당된다. 예컨대, 작업 증명 솔루션을 생성하는 데 요구되는 해시 형태의 상당량의 노력은 블록체인 프로토콜의 규칙들에 따르려는 제1 노드(104)의 의도를 시그널링한다. 이러한 규칙들은 트랜잭션이 이전에 유효성 검증된 트랜잭션과 동일한 출력을 할당 ― 이는 이중 지출로서 달리 알려짐 ― 하는 경우 트랜잭션을 유효한 것으로 수락하지 않는 것을 포함한다. 일단 생성되면, 블록(151)은 블록체인 네트워크(106) 내 블록체인 노드들(104) 각각에서 인식 및 유지되기 때문에 수정될 수 없다. 블록 포인터(155)는 또한 블록들(151)에 순차적인 순서를 부과한다. 트랜잭션들(152)은 네트워크(106)의 각각의 블록체인 노드(104)에서 순서화된 블록들에 레코딩되기 때문에, 이는 이에 따라, 트랜잭션들의 변경 불가능한 공개 원장을 제공한다.

임의의 주어진 시간에 퍼즐을 해결하기 위해 경쟁하는 상이한 블록체인 노드들(104)은 솔루션을 검색하기 시작한 시기 또는 트랜잭션이 수신된 순서에 의존하여, 임의의 주어진 시간에 아직 공개되지 않은 트랜잭션들 풀(154)의 상이한 스냅샷들에 기초하여 퍼즐을 해결할 수 있다는 것에 주의한다. 누구든 각자의 퍼즐을 먼저 해결하는 사람은 어느 트랜잭션들(152)이 어떤 순서로 다음의 새로운 블록(151n)에 포함되는지를 정의하고, 공개되지 않은 트랜잭션들의 현재 풀(154)은 업데이트된다. 그 후 블록체인 노드들(104)은 공개되지 않은 트랜잭션들(154)의 새롭게 정의된 순서화된 풀로부터 블록을 생성하기 위해 계속 경쟁한다. 발생할 수 있는 임의의 "포크(fork)" ― 이는 2개의 블록체인 노드들(104)이 서로 매우 짧은 시간 내에 그의 퍼즐을 해결하여서, 블록체인에 대한 상충되는 뷰(view)가 노드들 사이에 전파되는 경우임 ― 를 해결하기 위한 프로토콜이 또한 존재한다. 요컨대, 가장 길게 성장하는 포크의 갈래가 확정적인 블록체인(150)이 된다. 동일한 트랜잭션들이 포크들 둘 모두에 나타날 것이므로, 이는 네트워크의 사용자들 또는 에이전트들에게 영향을 미치지 않아야 한다.

비트코인 블록체인(및 대부분의 다른 블록체인들)에 따르면, 새로운 블록(104)을 성공적으로 구성하는 노드에는 (하나의 에이전트 또는 사용자로부터 다른 에이전트 또는 사용자로 디지털 자산의 금액을 이전하는 에이전트-간 또는 사용자-간 트랜잭션과 대조적으로) 디지털 자산의 부가적인 정의된 양을 분배하는 새로운 특별한 종류의 트랜잭션들에서 디지털 자산의 부가적인 수락된 금액을 새롭게 할당하는 능력이 승인된다. 이 특별한 유형의 트랜잭션은 일반적으로 "코인베이스 트랜잭션"으로서 지칭되지만, "초기 트랜잭션" 또는 "생성 트랜잭션"이라고도 칭해질 수 있다. 그것은 통상적으로 새로운 블록(151n)의 제1 트랜잭션을 형성한다. 작업 증명은 나중에 이 특별한 트랜잭션이 리딤되도록 허용하는 프로토콜 규칙들을 따르도록 새로운 블록을 구성하는 노드의 의도를 시그널링한다. 블록체인 프로토콜 규칙은 이 특별한 트랜잭션이 리딤되기 전에 만기 기간 예컨대, 100개의 블록들을 요구할 수 있다. 종종 일반(비-생성) 트랜잭션(152)이 또한 그 트랜잭션이 공개된 블록(151n)을 생성한 블록체인 노드(104M)를 추가로 보상하기 위해, 그의 출력들 중 하나에 부가적인 트랜잭션 수수료를 지정할 것이다. 이 수수료는 일반적으로 "트랜잭션 수수료"로서 지칭되고 아래에서 논의된다.

트랜잭션 유효성 검증 및 공개와 관련된 자원들로 인해, 통상적으로 적어도 블록체인 노드들(104) 각각은 하나 이상의 물리적 서버 유닛들, 또는 심지어 전체 데이터 센터를 포함하는 서버의 형태를 취한다. 그러나 원칙적으로 임의의 주어진 블록체인 노드(104)는 사용자 단말 또는 함께 네트워킹된 사용자 단말들의 그룹의 형태를 취할 수 있다.

각각의 블록체인 노드(104)의 메모리는 블록체인 노드 프로토콜에 따라 각자의 역할 또는 역할들을 수행하고 트랜잭션들(152)을 처리하기 위해 블록체인 노드(104)의 프로세싱 장치 상에서 실행되도록 구성된 소프트웨어를 저장한다. 본원에서 블록체인과 노드(104)에 기인한 임의의 액션은 각자의 컴퓨터 장비의 프로세싱 장치 상에서 실행되는 소프트웨어에 의해 수행될 수 있다는 것이 이해될 것이다. 노드 소프트웨어는 애플리케이션 계층, 또는 운영 체제 계층이나 프로토콜 계층과 같은 하위 계층 또는 이들의 임의의 조합에서 하나 이상의 애플리케이션들로 구현될 수 있다.

또한 네트워크(101)에는 소비 사용자들의 역할을 하는 복수의 당사자들(103) 각각의 컴퓨터 장비(102)가 연결되어 있다. 이러한 사용자는 블록체인 네트워크(106)와 상호작용할 수 있지만 트랜잭션들을 검증하거나 블록들을 구성하는 데 참여하지 않는다. 이러한 사용자들 또는 에이전트들(103) 중 일부는 트랜잭션들에서 전송자들 및 수령인들로서 작용할 수 있다. 다른 사용자들은 반드시 전송자들 또는 수령인들로서 작용할 필요 없이 블록체인(150)과 상호작용할 수 있다. 예컨대, 일부 당사자들은 블록체인(150)의 사본을 저장하는 저장 엔티티들로서 작용할 수 있다(예컨대, 블록체인 노드(104)로부터 블록체인의 사본을 획득함).

당사자들(103) 중 일부 또는 전부는 상이한 네트워크, 예컨대, 블록체인 네트워크(106) 위에 오버레이된 네트워크의 부분으로서 연결될 수 있다. 블록체인 네트워크의 사용자들(종종 "클라이언트"로서 지칭됨)은 블록체인 네트워크(106)를 포함하는 시스템의 일부로서 언급될 수 있지만; 이러한 사용자들은 블록체인 노드들에서 요구되는 역할을 수행하지 않기 때문에 블록체인 노드들(104)이 아니다. 대신에, 각각의 당사자(103)는 블록체인 네트워크(106)와 상호작용할 수 있고 그리하여 블록체인 노드(106)에 연결(즉, 통신)함으로써 블록체인(150)을 활용할 수 있다. 제1 당사자(103a) 및 그/그녀의 개개의 컴퓨터 장비(102a) 및 제2 당사자(103b) 및 그/그녀의 개개의 컴퓨터 장비(102b)인 두 당사자들(103) 및 이들의 개개의 장비(102)가 예시 목적으로 도시된다. 훨씬 더 많은 이러한 당사자들(103) 및 이들의 개개의 컴퓨터 장비(102)가 존재하고 시스템(100)에 참여할 수 있지만, 편의상 그것들은 예시되지 않는다는 것이 이해될 것이다. 각각의 당사자(103)는 개인 또는 조직일 수 있다. 순전히 예시로서, 제1 당사자(103a)는 본원에서 앨리스(Alice)로서 지칭되고 제2 당사자(103b)는 밥(Bob)으로서 지칭되지만, 이것이 제한적이지 않고 본원에서 앨리스 또는 밥에 대한 임의의 참조는 각각 "제1 당사자" 및 "제2 당사자"로 대체될 수 있다는 것이 인지될 것이다.

각각의 당사자(103)의 컴퓨터 장비(102)는 하나 이상의 프로세서들, 예컨대, 하나 이상의 CPU들, GPU들, 다른 가속기 프로세서들, 애플리케이션 특정 프로세서들 및/또는 FPGA들을 포함하는 개개의 프로세싱 장치를 포함한다. 각각의 당사자(103)의 컴퓨터 장비(102)는 메모리, 즉 비-일시적 컴퓨터-판독 가능 매체 또는 매체들의 형태의 컴퓨터-판독 가능 저장소를 더 포함한다. 이 메모리는 하나 이상의 메모리 매체들, 예컨대, 하드 디스크와 같은 자기 매체; 솔리드 스테이트 SSD, 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광학 디스크 드라이브와 같은 광학 매체를 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다. 각각의 당사자(103)의 컴퓨터 장비(102) 상의 메모리는 프로세싱 장치 상에서 실행되도록 배열된 적어도 하나의 클라이언트 애플리케이션(105)의 개개의 인스턴스를 포함하는 소프트웨어를 저장한다. 본원에서 주어진 당사자(103)에 기인한 임의의 액션은 개개의 컴퓨터 장비(102)의 프로세싱 장치 상에서 실행되는 소프트웨어를 사용하여 수행될 수 있다는 것이 이해될 것이다. 각각의 당사자(103)의 컴퓨터 장비(102)는 적어도 하나 사용자 단말, 예컨대, 데스크 톱 또는 랩톱 컴퓨터, 태블릿, 스마트폰, 또는 스마트워치와 같은 웨어러블 디바이스를 포함한다. 주어진 당사자(103)의 컴퓨터 장비(102)는 또한 사용자 단말을 통해 액세스되는 클라우드 컴퓨팅 자원들과 같은 하나 이상의 다른 네트워킹된 자원들을 포함할 수 있다.

예컨대, 서버로부터 다운로드되거나, 또는 이동식 저장 디바이스 이를테면, 이동식 SSD, 플래시 메모리 키, 이동식 EEPROM, 이동식 자기 디스크 드라이브, 자기 플로피 디스크 또는 테이프, 광학 디스크 이를테면, CD 또는 DVD ROM 또는 이동식 광학 드라이브 등 상에서 제공되는 클라이언트 애플리케이션(105)은 적절한 컴퓨터-판독 가능 저장 매체 또는 매체들 상에서 임의의 주어진 당사자(103)의 컴퓨터 장비(102)에 초기에 제공될 수 있다.

클라이언트 애플리케이션(105)은 적어도 "지갑" 기능을 포함한다. 이는 2개의 메인 기능성들을 갖는다. 이들 중 하나는 개개의 당사자(103)가 트랜잭션들(152)을 생성하고 인가(예컨대, 서명)하여 하나 이상의 비트코인 노드들(104)에 전송하여, 이어서 블록체인 노드들(104)의 네트워크 전반에 걸쳐 전파되고 그리하여 블록체인(150)에 포함되는 것을 가능하게 하는 것이다. 남은 하나는 개개의 당사자에게 자신이 현재 소유하고 있는 디지털 자산의 금액을 다시 보고하는 것이다. 출력-기반 시스템에서, 이 제2 기능성은 블록체인(150) 전반에 걸쳐 흩어져 있는 해당 당사자에 속하는 다양한 트랜잭션들(152)의 출력들에서 정의된 금액들을 대조하는 것을 포함한다.

참고: 다양한 클라이언트 기능성이 주어진 클라이언트 애플리케이션(105)에 통합되는 것으로서 설명될 수 있지만, 이는 반드시 제한적인 것은 아니며, 대신 본원에서 설명된 클라이언트 기능성은 API를 통해 인터페이싱하거나 하나가 남은 하나에 플러그인하는 두 개 이상의 개별 애플리케이션들의 세트에서 구현될 수 있다. 보다 일반적으로, 클라이언트 기능성은 애플리케이션 계층 또는 운영 체제와 같은 하위 계층 또는 이들의 임의의 조합에서 구현될 수 있다. 다음은 클라이언트 애플리케이션(105)과 관련하여 설명될 것이지만, 이것이 제한적이지 않다는 것이 인지될 것이다.

각각의 컴퓨터 장비(102) 상의 클라이언트 애플리케이션 또는 소프트웨어(105)의 인스턴스는 네트워크(106)의 블록체인 노드들(104) 중 적어도 하나에 동작 가능하게 커플링된다. 이는 클라이언트(105)의 지갑 기능이 트랜잭션들(152)을 네트워크(106)로 전송하는 것을 가능하게 한다. 클라이언트(105)는 또한 개개의 당사자(103)가 수령인인 임의의 트랜잭션들에 대해 블록체인(150)에 질의하기 위해(또는 실시예들에서, 블록체인(150)은 그의 공개 가시성을 통해 부분적으로 트랜잭션들의 신뢰를 제공하는 공공 시설(public facility)이므로, 실제로 블록체인(150)에서 다른 당사자들의 트랜잭션을 검사하기 위해) 블록체인 노드들(104)에 접촉할 수 있다. 각각의 컴퓨터 장비(102) 상의 지갑 기능은 트랜잭션 프로토콜에 따라 트랜잭션들(152)을 공식화(formulate) 하고 전송하도록 구성된다. 위에서 제시된 바와 같이, 각각의 블록체인 노드(104)는 블록체인 노드 프로토콜에 따라 트랜잭션들(152)을 유효성 검증하고 트랜잭션들(152)을 포워딩하여 이들을 블록체인 네트워크(106) 전체에 전파하도록 구성된 소프트웨어를 실행한다. 트랜잭션 프로토콜 및 노드 프로토콜은 서로 대응하며, 주어진 트랜잭션 프로토콜은 주어진 트랜잭션 모델을 함께 구현하도록 주어진 노드 프로토콜을 따른다. 동일한 트랜잭션 프로토콜이 블록체인(150) 내 모든 트랜잭션들(152)에 사용된다. 동일한 노드 프로토콜이 네트워크(106) 내 모든 노드들(104)에 의해 사용된다.

주어진 당사자(103), 이를테면 앨리스가 블록체인(150)에 포함될 새로운 트랜잭션(152j)을 전송하기를 원할 때, 그녀는 (자신의 클라이언트 애플리케이션(105)의 지갑 기능을 사용하여) 관련 트랜잭션 프로토콜에 따라 새로운 트랜잭션을 공식화한다. 그 후, 그녀는 클라이언트 애플리케이션(105)으로부터 그녀가 연결되는 하나 이상의 블록체인 노드들(104)에 트랜잭션(152)을 전송한다. 예컨대, 이는 앨리스의 컴퓨터(102)에 가장 잘 연결된 블록체인과 노드(104)일 수 있다 임의의 주어진 블록체인 노드(104)가 새로운 트랜잭션(152j)을 수신할 때, 주어진 노드는 블록체인 노드 프로토콜 및 각자의 역할에 따라 이를 처리한다. 이는 새롭게 수신된 트랜잭션(152j)이 "유효"하기 위한 특정 조건을 충족시키는지를 먼저 체크하는 것을 포함하며, 그의 예들은 곧 보다 자세히 논의될 것이다. 일부 트랜잭션 프로토콜들에서, 유효성 검증을 위한 조건은 트랜잭션들(152)에 포함된 스크립트들에 의해 트랜잭션 단위로 구성 가능할 수 있다. 대안적으로, 조건은 단순히 노드 프로토콜의 내장 피처이거나, 스크립트 및 노드 프로토콜의 조합으로 정의될 수 있다.

새롭게 수신된 트랜잭션(152j)이 유효한 것으로 간주되기 때문에 테스트를 통과한다는 것을 조건으로(즉, 그것이 "유효성 검증"된다는 조건으로), 트랜잭션(152j)을 수신하는 임의의 블록체인 노드(104)는 새로운 유효성 검증된 트랜잭션(152)을 그 블록체인 노드(104)에서 유지되는 블록체인들(154)의 순서화된 세트(154)에 추가할 것이다. 또한, 트랜잭션(152j)을 수신하는 임의의 블록체인 노드(104)는 유효성 검증된 트랜잭션(152)을 네트워크(106)의 하나 이상의 다른 블록체인 노드들(104)로 전방으로 전파시킬 것이다. 각각의 블록체인 노드(104)가 동일한 프로토콜을 적용하기 때문에, 트랜잭션(152j)이 유효하다고 가정하면, 이는 그것이 곧 전체 네트워크(106)에 걸쳐 전파될 것임을 의미한다.

일단 주어진 블록체인 노드(104)에서 유지되는 계류중인 트랜잭션(154)의 순서화된 풀에 허용되면, 블록체인 노드(104)는 새로운 트랜잭션(152)을 포함하여 트랜잭션(154)의 각자의 풀의 최신 버전 상에서 작업 증명 퍼즐을 해결하기 위해 경쟁하기 시작할 것이다(다른 블록체인 노드들(104)은 트랜잭션들의 상이한 풀(154)에 기초하여 퍼즐을 해결하려고 시도할 수 있지만 누구든 먼저 해결하는 사람은 최신 블록(151)에 포함된 트랜잭션들의 세트를 정의할 것임을 상기한다). 결국 블록체인 노드(104)는 앨리스의 트랜잭션(152j)을 포함하는 순서화된 풀(154)의 일부에 대한 퍼즐을 해결할 것이다. 새로운 트랜잭션(152j)을 포함하는 풀(154)에 대한 작업 증명이 완료되면, 이는 변경 불가능하게 블록체인(150)의 블록들(151) 중 하나의 부분이 된다. 각각의 트랜잭션(152)은 이전 트랜잭션에 대한 역 포인터를 포함하여서, 트랜잭션들의 순서가 또한 변경 불가능하게 레코딩된다.

상이한 블록체인 노드들(104)은 주어진 트랜잭션의 상이한 인스턴스들을 먼저 수신하고 이에 따라 하나의 인스턴스가 새로운 블록(151)에 공개되기 전에 어떤 인스턴스가 '유효'한지에 관한 상충되는 뷰들을 가질 수 있으며, 이 때 모든 블록체인 노드들(104)은 공개된 인스턴스가 유일한 유효 인스턴스라는 것에 동의한다. 블록체인 노드(104)가 하나의 인스턴스를 유효한 것으로 수락하고 그 후 제2 인스턴스가 블록체인(150)에 레코딩되었음을 발견하는 경우, 해당 블록체인 노드(104)는 이를 수락해야 하며 초기에 수락된 인스턴스(즉, 블록(151)에서 공개되지 않은 인스턴스)를 폐기(즉, 유효하지 않은 것으로 취급)할 것이다.

일부 블록체인 네트워크들에 의해 동작되는 트랜잭션 프로토콜의 대안적인 유형은 계정-기반 트랜잭션 모델의 일부로서 "계정-기반" 프로토콜로서 지칭될 수 있다. 계정-기반의 경우에, 각각의 트랜잭션은 과거 트랜잭션들의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하기 보다는, 절대 계정 잔액을 참조함으로써 전달될 금액을 정의한다. 모든 계정들의 현재 상태는 블록체인과 별개로 해당 네트워크의 노드들에 의해 저장되며 지속적으로 업데이트된다. 이러한 시스템에서, 트랜잭션들은 계정의 실행 중인 트랜잭션 집계(또한 "포지션"이라 불림)를 사용하여 순서화된다. 이 값은 그의 암호화 서명의 일부로 발신인에 의해 서명되고 트랜잭션 참조 계산의 부분으로서 해시된다. 게다가, 선택적 데이터 필드가 또한 트랜잭션에 서명할 수 있다. 이 데이터 필드는 예컨대, 이전 트랜잭션 ID가 데이터 필드에 포함된 경우 이전 트랜잭션을 뒤로 가리킬 수 있다.

UTXO-기반 모델

도 2는 예시적인 트랜잭션 프로토콜을 예시한다. 이는 UTXO-기반 프로토콜의 예이다. 트랜잭션(152)(약칭 "Tx")은 블록체인(150)의 기본 데이터 구조이다(각각의 블록(151)은 하나 이상의 트랜잭션들(152)을 포함함). 다음은 출력-기반 또는 "UTXO" 기반 프로토콜을 참조하여 설명될 것이다. 그러나 이것은 모든 가능한 실시예들로 제한되지 않는다. 예시적인 UTXO-기반 프로토콜이 비트코인을 참조하여 설명되지만, 다른 예시적인 블록체인 네트워크들 상에서 동일하게 구현될 수 있다는 것에 주의한다.

UTXO-기반 모델에서, 각각의 트랜잭션("Tx")(152)은 하나 이상의 입력들(202) 및 하나 이상의 출력들(203)을 포함하는 데이터 구조를 포함한다. 각각의 출력(203)은 (UTXO가 아직 리딤되지 않은 경우) 다른 새로운 트랜잭션의 입력(202)에 대한 소스로서 사용될 수 있는 미지출 트랜잭션 출력(unspent transaction output; UTXO)을 포함할 수 있다. UTXO는 디지털 자산의 금액을 지정하는 값을 포함한다. 이는 분산 원장 상의 세팅된 수의 토큰들을 표현한다. UTXO는 또한 다른 정보 중에서도, 그것이 발생한 트랜잭션의 트랜잭션 ID를 포함할 수 있다. 트랜잭션 데이터 구조는 또한 입력 필드(들)(202) 및 출력 필드(들)(203)의 크기의 표시자를 포함할 수 있는 헤더(201)를 포함할 수 있다. 헤더(201)는 또한 트랜잭션의 ID를 포함할 수 있다. 실시예들에서, 트랜잭션 ID는 (트랜잭션 ID 자체는 제외한) 트랜잭션 데이터의 해시이고 노드들(104)에게 제출된 원시 트랜잭션(152)의 헤더(201)에 저장된다.

앨리스(103a)가 해당 디지털 자산의 금액을 밥(103b)에게 전달하는 트랜잭션(152j)을 생성하기를 원한다고 하자. 도 2에서 앨리스의 새로운 트랜잭션(152j)은 "Tx₁"로서 라벨이 지정된다. 이는 시퀀스의 선행 트랜잭션(152i)의 출력(203)에서 앨리스에게 잠긴 디지털 자산의 금액을 취하고, 이 중 적어도 일부를 밥에게 전달한다. 선행 트랜잭션(152i)은 도 2에서 "Tx₀"로 라벨이 지정된다. Tx₀ 및 Tx₁은 임의의 라벨일 뿐이다. 이들은, Tx₀이 블록체인(151)의 최초 트랜잭션이거나, Tx₁이 풀(154)에서 바로 다음 트랜잭션이라는 것을 반드시 의미하지는 않는다. Tx₁은 앨리스에게 잠긴 미지출 출력(203)을 여전히 갖는 임의의 선행(즉, 앞선) 트랜잭션을 뒤로 가리킬 수 있다.

선행 트랜잭션(Tx₀)은 앨리스가 자신의 새로운 트랜잭션(Tx₁)을 생성할 때, 또는 적어도 그녀가 그것을 네트워크(106)에 전송할 때까지 이미 유효성 검증되고 블록체인(150)의 블록(151)에 포함되었을 수 있다. 이는 그 시간에 이미 블록들(151) 중 하나에 포함되었거나, 순서화된 세트(154)에서 여전히 대기 중일 수 있으며, 이 경우에 곧 새로운 블록(151)에 포함될 것이다. 대안적으로 Tx₀ 및 Tx₁이 생성되고 네트워크(106)에 함께 전송될 수 있거나 또는 노드 프로토콜이 "고아" 트랜잭션들을 버퍼링하도록 허용하는 경우 Tx₀는 Tx₁ 이후에도 전송될 수 있다. 트랜잭션들의 시퀀스의 맥락에서 본원에서 사용된 바와 같은 "선행" 및 "후속"이라는 용어들은 (트랜잭션이 다른 트랜잭션을 뒤로 가리키고, 이와 같이 계속되는) 트랜잭션들에서 지정된 트랜잭션 포인터들에 의해 정의된 바와 같은 시퀀스에서의 트랜잭션들의 순서를 지칭한다. 이들은 "선행자(predecessor)" 및 "후행자(successor)", 또는 "앞선(antecedent)"과 "후위의(descendant)", "부모" 및 "자식" 등으로 동등하게 대체될 수 있다. 이는 그것들이 생성되고, 네트워크(106)로 전송되거나, 임의의 주어진 블록체인 노드(104)에 도달하는 순서를 반드시 의미하지는 않는다. 그럼에도 불구하고, 선행 트랜잭션(앞선 트랜잭션 또는 "부모")을 가리키는 후속 트랜잭션(후위의 트랜잭션 또는 "자식")은 부모 트랜잭션이 유효성 검증될 때까지 그리고 유효성 검증되지 않는 한 유효성 검증되지 않을 것이다. 그의 부모 이전에 블록체인과 노드(104)에 도달하는 자식은 고아로 간주된다. 이는 노드 프로토콜 및/또는 노드 거동에 의존하여 부모를 기다리기 위해 특정 시간 동안 버퍼링되거나 폐기될 수 있다.

선행 트랜잭션(Tx₀)의 하나 이상의 출력들(203) 중 하나는, 본원에서 UTXO₀으로서 라벨이 지정되는 특정 UTXO를 포함한다. 각각의 UTXO는 UTXO에 의해 표현되는 디지털 자산의 금액을 지정하는 값 및 후속 트랜잭션이 유효성 검증되고 따라서 UTXO가 성공적으로 리딤되기 위하여 후속 트랜잭션의 입력(202)에서 잠금해제 스크립트에 의해 만족되어야 하는 조건을 정의하는 잠금 스크립트를 포함한다. 통상적으로, 잠금 스크립트는 특정 당사자(그것이 포함된 트랜잭션의 수혜자)에게로 금액을 잠근다. 즉, 잠금 스크립트는, 통상적으로 후속 트랜잭션의 입력의 잠금해제 스크립트가 선행 트랜잭션이 잠겨 있는 당사자의 암호화 서명을 포함하는 조건을 포함하는 잠금해제 조건을 정의한다.

잠금 스크립트(일명 scriptPubKey)는 노드 프로토콜에 의해 인식되는 도메인 특정 언어로 작성된 코드 조각이다. 이러한 언어의 특정 예는 블록체인 네트워크에 의해 사용되는 "스크립트(Script)"(대문자 S)라 불린다. 잠금 스크립트는 트랜잭션 출력(203)을 지출하는 데 어떤 정보가 필요한지, 예컨대, 앨리스의 서명 요건을 지정한다. 잠금해제 스크립트들은 트랜잭션들의 출력에서 나타난다. 잠금해제 스크립트(일명 scriptSig)는 잠금 스크립트 기준들을 충족시키는 데 필요한 정보를 제공하는 도메인 특정 언어로 작성된 코드 조각이다. 예컨대, 이는 밥의 서명을 포함할 수 있다. 잠금해제 스크립트들은 트랜잭션들의 입력(202)에 나타난다.

따라서 예시된 예에서, Tx₀의 출력(203)의 UTXO₀은 UTXO₀가 리딤되기 위해(엄밀히, UTXO₀을 리딤하고자 시도하는 후속 트랜잭션이 유효하기 위해) 앨리스의 서명 Sig P_A를 요구하는 잠금 스크립트 [Checksig P_A]를 포함한다. [Checksig P_A]는 앨리스의 공개-개인 키 쌍으로부터의 공개 키 P_A의 표현(예컨대, 해시)을 포함한다. Tx₁의 입력(202)은 (예컨대, 실시예에서, 전체 트랜잭션 Tx₀의 해시인 그의 트랜잭션 ID인 TxID₀에 의해) Tx₁을 뒤로 가리키는 포인터를 포함한다. Tx₁의 입력(202)은 Tx₀ 내에서 UTXO₀을 식별하는 인덱스를 포함하여, Tx₀의 임의의 다른 가능한 출력들 사이에서 그것을 식별한다. Tx₁의 입력(202)은 앨리스의 암호화 서명을 포함하는 잠금해제 스크립트 <Sig P_A>를 더 포함하며, 이는 앨리스가 키 쌍으로부터 자신의 개인 키를 데이터의 미리 정의된 부분(때로는 암호법에서 "메시지"라 불림)에 적용함으로써 생성된다. 유효한 서명을 제공하기 위해 앨리스에 의해 서명될 필요가 있는 데이터(또는 "메시지")는 잠금 스크립트, 노드 프로토콜 또는 이들의 조합에 의해 정의될 수 있다.

새로운 트랜잭션 Tx₁이 블록체인 노드(104)에 도달할 때, 노드는 노드 프로토콜을 적용한다. 이는 잠금해제 스크립트가 잠금 스크립트에 정의된 조건(이 조건은 하나 이상의 기준들을 포함할 수 있음)을 충족시키는지를 체크하기 위해 잠금 스크립트 및 잠금해제 스크립트를 함께 실행하는 것을 포함한다. 실시예들에서, 이는 2개의 스크립트들을 컨케터네이팅(concatenating)하는 것을 수반한다.

여기에서 "||"는 컨케터네이션을 표현하고 "<...>"는 스택 상에 데이터를 배치하는 것을 의미하고, "[…]"는 잠금 스크립트(이 예에서, 스택-기반 언어)에 의해 구성된 함수이다. 동등하게, 스크립트들을 컨케터네이팅하는 대신, 스크립트들은 공통 스택을 사용하여 번갈아 실행될 수 있다. 어느 쪽이든, 함께 실행될 때, 스크립트들은 Tx₀의 출력의 잠금 스크립트에 포함된 바와 같은 앨리스의 공개 키 P_A를 사용하여, Tx₁의 입력의 잠금해제 스크립트가 데이터의 예상되는 부분에 서명하는 앨리스의 서명을 포함한다는 것을 인증한다. 이 인증을 수행하기 위하여 데이터의 예상되는 부분 자체("메시지")가 또한 포함될 필요가 있다. 실시예들에서, 서명된 데이터는 Tx₁ 전체를 포함한다(이에 따라, 평문으로 데이터의 서명된 부분을 지정하는 별개의 요소가 포함될 필요가 없는데, 그 이유는 그것이 이미 본질적으로 존재하기 때문임).

공개-개인 암호법에 의한 인증의 세부사항들은 당업자에게 친숙할 것이다. 기본적으로, 앨리스가 자신의 개인 키를 사용하여 메시지에 서명한 경우, 앨리스의 공개 키 및 평문의 메시지를 감안하여, 노드(104)와 같은 다른 엔티티는 메시지가 앨리스에 의해 서명된 것임이 틀림없다는 것을 인증할 수 있다. 서명은 통상적으로 메시지를 해시하는 것, 해시에 서명하는 것, 그리고 이를 서명으로서 메시지에 태깅하고, 이에 따라 공개 키의 임의의 보유자(holder)가 서명을 인증하는 것을 가능하게 하는 것을 포함한다. 따라서 여기에서 특정 데이터 조각 또는 트랜잭션의 일부 등에 서명하는 것에 대한 임의의 참조는 실시예들에서 해당 데이터 조각 또는 트랜잭션 일부의 해시에 서명하는 것을 의미할 수 있다는 것에 주의한다.

Tx₁의 잠금해제 스크립트가 Tx₀의 잠금 스크립트에 지정된 하나 이상의 조건들을 충족시키는 경우(이에 따라, 보여진 예에서, 앨리스의 서명이 Tx₁에서 제공되고 인증된 경우), 블록체인과 노드(104)는 Tx₁이 유효한 것으로 간주한다. 이는 블록체인 노드(104)가 계류중인 트랜잭션들(154)의 순서화된 풀에 Tx1을 추가할 것임을 의미한다. 블록체인 노드(104F)는 또한 트랜잭션 Tx₁을 네트워크(106) 내 하나 이상의 다른 블록체인 노드들(104)로 포워딩할 것이어서, 그 트랜잭션이 네트워크(106) 전반에 걸쳐 전파될 것이다. Tx₁이 유효성 검증되고 블록체인(150)에 포함되면, 이는 지출된 것으로 Tx₀으로부터의 UTXO₀를 정의한다. Tx₁은 그것이 미지출 트랜잭션 출력(203)을 지출하는 경우에만 유효할 수 있다는 것에 주의한다. 다른 트랜잭션(152)에 의해 이미 지출된 출력을 지출하려고 시도하는 경우, 다른 모든 조건들이 충족되는 경우조차도 Tx₁은 유효하지 않을 것이다. 따라서 블록체인과 노드(104)는 또한 선행 트랜잭션 Tx₀에서 참조된 UTXO가 이미 지출되었는지(즉, 다른 유효한 트랜잭션에 대한 유효한 입력을 이미 형성했는지)를 체크할 필요가 있다. 이는 트랜잭션들(152) 상에 정의된 순서를 부과하는 것이 블록체인(150)에 대해 중요한 하나의 이유이다. 실제로, 주어진 블록체인 노드(104)는 트랜잭션들(152)이 지출된 UTXO들(203)을 마킹하는 별개의 데이터베이스를 유지할 수 있지만, 궁극적으로 UTXO가 지출되었는지를 정의하는 것은 블록체인(150)의 다른 유효한 트랜잭션에 대한 유효한 입력이 이미 형성되었는지의 여부이다.

주어진 트랜잭션(152)의 모든 출력들(203)에서 지정된 총 금액이 모든 그의 입력들(202)에 의해 가리켜지는 총 금액보다 큰 경우, 이는 대부분의 트랜잭션 모델들에서 무효에 대한 다른 근거이다. 따라서 이러한 트랜잭션들은 전파되지도 않고 블록(151)에 포함되지 않을 것이다.

UTXO-기반 트랜잭션 모델에서, 주어진 UTXO는 전체로서 지출될 필요가 있다는 것에 주의한다. 다른 프랙션(fraction)이 지출되면서, 지출된 것으로 UTXO에서 정의된 금액의 프랙션을 "남겨둘" 수는 없다. 그러나 UTXO로부터의 금액은 다음 트랜잭션의 다수의 출력들 사이에서 분할될 수 있다. 예컨대, Tx₀의 UTXO₀에 정의된 금액은 Tx₁의 다수의 UTXO들 사이에서 분할될 수 있다. 따라서 앨리스가 UTXO₀에 정의된 모든 금액을 밥에게 주기를 원하지 않는 경우, 앨리스는 Tx₁의 제2 출력에서 자신에게 잔돈을 주거나, 다른 당사자에게 지불하는데 나머지를 사용할 수 있다.

실제로, 앨리스는 또한 일반적으로 블록(151)에 그녀의 트랜잭션(104)을 성공적으로 포함시키는 비트코인 노드(104)에 대한 수수료를 포함할 필요가 있을 것이다. 앨리스가 그러한 수수료를 포함시키지 않는 경우, Tx₀은 블록체인 노드들(104M)에 의해 거부될 수 있고, 이에 따라 기술적으로 유효하더라도, 전파되어 블록체인(150)에 포함되지 않을 수 있다(노드프로토콜은 블록체인 노드들(104)이 원하지 않는 경우 이들에게 트랜잭션들(152)을 수락하도록 강요하지 않음). 일부 프로토콜들에서, 트랜잭션 수수료는 자체의 별개의 출력(203)을 요구하지 않는다(즉, 별개의 UTXO가 필요하지 않음). 대신, 주어진 트랜잭션(152)의 입력(들)(202)에 의해 가리켜지는 총 금액과 출력(들)(203)에 지정된 총 금액 사이의 임의의 차이는 트랜잭션을 공개한 블록체인 노드(104)에게 자동으로 주어진다. 예컨대, UTXO₀에 대한 포인터가 Tx₁에 대한 유일한 입력이고 Tx₁는 단 하나의 출력 UTXO₁만을 갖는다고 하자. UTXO₀에 지정된 디지털 자산의 금액이 UTXO₁에 지정된 금액보다 큰 경우, 차이는 UTXO₁을 포함하는 블록을 생성하기 위한 작업 증명 경쟁에서 승리한 노드(104)에 의해 할당될 수 있다. 그러나 대안적으로 또는 부가적으로, 트랜잭션 수수료가 트랜잭션(152)의 UTXO들(203) 중 자체 UTXO에서 명시적으로 지정될 수 있다는 것이 반드시 배제되는 것은 아니다.

앨리스 및 밥의 디지털 자산들은 블록체인(150)의 임의의 위치의 임의의 트랜잭션들(152)에서 그들에게 잠겨 있는 UTXO로 구성된다. 따라서 통상적으로, 주어진 당사자(103)의 자산들은 블록체인(150) 전반에 걸친 다양한 트랜잭션들(152)의 UTXO들에 걸쳐 흩어져 있다. 블록체인(150)의 어떤 위치에도 주어진 당사자(103)의 총 잔액을 정의하는 숫자는 전혀 없다. 클라이언트 애플리케이션(105)에서 지갑 기능의 역할은, 개개의 당사자에게 잠겨 있으며 다른 전방 트랜잭션에서 아직 지출되지 않은 모든 다양한 UTXO들의 값들을 함께 대조하는 것이다. 비트코인 노드들(104) 중 임의의 것에 저장된 블록체인(150)의 사본을 질의함으로써 이것이 수행될 수 있다.

스크립트 코드는 종종 도식적으로(즉, 정확한 언어를 사용하지 않음) 표현된다는 것에 주의한다. 예컨대, 특정 기능을 표현하기 위해 작업 코드(opcode)들이 사용될 수 있다. "OP_..."는 스크립트 언어의 특정 작업코드(opcode)를 지칭한다. 예로서, OP_RETURN은 잠금 스크립트의 선두에서 OP_FALSE가 앞에 있을 때 트랜잭션 내에 데이터를 저장하고 그리하여 데이터를 블록체인(150)에 변경 불가능하게 레코딩할 수 있는 트랜잭션의 지출 불가능한 출력을 생성하는 스크립트 언어의 작업코드이다. 예컨대, 데이터는 블록체인에 저장하고자 하는 문서를 포함할 수 있다.

통상적으로, 트랜잭션의 입력은 공개 키 P_A에 대응하는 디지털 서명을 포함한다. 실시예들에서, 이는 타원 곡선 secp256k1을 사용하는 ECDSA에 기초한다. 디지털 서명은 특정 데이터 조각에 서명한다. 일부 실시예들에서, 주어진 트랜잭션에 대해, 서명은 트랜잭션 입력의 일부, 및 트랜잭션 출력들의 전부 또는 일부에 서명할 것이다. 서명되는 출력들의 특정 부분들은 SIGHASH 플래그에 의존한다. SIGHASH 플래그는 일반적으로 어느 출력들이 서명되는지를 선택하기 위해 서명의 끝에 포함된 4-바이트 코드이다(이에 따라, 서명 시에 고정됨).

잠금 스크립트는 때로는, 그것이 통상적으로 개개의 트랜잭션이 잠겨 있는 당사자의 공개 키를 포함한다는 사실을 지칭하는 "scriptPubKey"라 칭해진다. 잠금해제 스크립트는 때로는 그것이 통상적으로 대응하는 서명을 제공한다는 사실을 지칭하는 "scriptSig"라 칭해진다. 그러나, 보다 일반적으로, UTXO가 리딤되기 위한 조건이 서명을 인증하는 것을 포함하는 것이 블록체인(150)의 모든 애플리케이션들에서 필수적인 것은 아니다. 보다 일반적으로 스크립팅 언어는 임의의 하나 이상의 조건들을 정의하는 데 사용될 수 있다. 따라서 보다 일반적인 용어들 "잠금 스크립트" 및 "잠금해제 스크립트"가 선호될 수 있다.

클라이언트 소프트웨어

도 3a는 현재 개시된 방식의 실시예들을 구현하기 위한 클라이언트 애플리케이션(105)의 예시적인 구현을 예시한다. 클라이언트 애플리케이션(105)은 트랜잭션 엔진(401) 및 사용자 인터페이스(UI) 계층(402)을 포함한다. 트랜잭션 엔진(401)은 클라이언트(105)의 기본 트랜잭션 관련 기능성을 구현하고, 이를테면, 트랜잭션(152)을 공식화하고, 사이드 채널(301)을 통해 트랜잭션들 및/또는 다른 데이터를 수신 및/또는 송신하고, 그리고/또는

위에서 논의되고 곧 더 자세히 논의되는 방식들에 따라 블록체인 네트워크(106)를 통해 전파될 하나 이상의 노드들(104)에 트랜잭션을 전송하도록 구성된다.

UI 계층(402)은 장비(102)의 사용자 출력 수단을 통해 개개의 사용자(103)에게 정보를 출력하고, 장비(102)의 사용자 입력 수단을 통해 개개의 사용자(103)로부터 다시 입력들을 수신하는 것을 포함하여, 개개의 사용자의 컴퓨터 장비(102)의 사용자 입력/출력(I/O) 수단을 통해 사용자 인터페이스를 렌더링하도록 구성된다. 예컨대, 사용자 출력 수단은 시각적 출력을 제공하기 위한 하나 이상의 디스플레이 스크린들(터치 또는 비-터치 스크린), 오디오 출력을 제공하기 위한 하나 이상의 스피커들 및/또는 촉각 출력을 제공하기 위한 하나 이상의 햅틱 출력 디바이스들 등을 포함할 수 있다. 사용자 입력 수단은 예컨대, 하나 이상의 터치 스크린들(출력 수단에 사용되는 것과 동일하거나 상이한 것)의 입력 어레이; 마우스, 트랙패드 또는 트랙볼과 같은 하나 이상의 커서 기반 디바이스들; 스피치 또는 음성 입력을 수신하기 위한 하나 이상의 마이크로폰들 및 스피치 또는 음성 인식 알고리즘들; 수동 또는 신체 제스처들의 형태의 입력을 수신하기 위한 하나 이상의 제스처 기반 입력 디바이스들; 또는 하나 이상의 기계식 버튼들, 스위치들 또는 조이스틱들 등을 포함할 수 있다.

참고: 본원에서 다양한 기능성이 동일한 클라이언트 애플리케이션(105)에 통합되는 것으로 설명될 수 있지만, 이는 반드시 제한적인 것은 아니며 대신에 둘 이상의 개별 애플리케이션들의 모음으로 구현될 수 있는데, 예컨대, 하나는 API(application programming interface)를 통한 인터페이싱하거나 남은 하나에 대한 플러그-인이다. 예컨대, 트랜잭션 엔진(401)의 기능성은 UI 계층(402)과는 별개의 애플리케이션에서 구현될 수 있거나, 트랜잭션 엔진(401)과 같은 주어진 모듈의 기능성은 하나 초과의 애플리케이션 사이에서 분할될 수 있다. 설명된 기능성 중 일부 또는 전부가 말하자면, 운영 체제 계층에서 구현될 수 있다는 것도 배제되지 않는다. 본원 어디에서든 단일 또는 주어진 애플리케이션(105) 등에 대한 참조가 이루어진 경우, 이는 단지 예일 뿐이며 보다 일반적으로, 설명된 기능성은 임의의 형태의 소프트웨어로 구현될 수 있다는 것이 인지될 것이다.

도 3b는 앨리스의 장비(102a) 상의 클라이언트 애플리케이션(105a)의 UI 계층(402)에 의해 렌더링될 수 있는 사용자 인터페이스(UI)(500)의 예의 목-업(mock-up)을 제공한다. 유사한 UI가 밥의 장비(102b)의 클라이언트(105b) 또는 임의의 다른 당사자의 것에 의해 렌더링될 수 있다는 것이 인지될 것이다.

예시로서, 도 3b는 앨리스의 관점으로부터의 UI(500)를 도시한다. UI(500)는 사용자 출력 수단을 통해 별개의 UI 요소들로서 렌더링된 하나 이상의 UI 요소들(501, 502, 502)을 포함할 수 있다.

예컨대, UI 요소들은 상이한 온-스크린 버튼들 또는 메뉴 내 상이한 옵션들 등일 수 있는 하나 이상의 사용자 선택 가능 요소들(501)을 포함할 수 있다. 사용자 입력 수단은 사용자(103)(이 경우에 앨리스(103a))가 온-스크린의 UI 요소를 클릭 또는 터치하거나 원하는 옵션의 이름을 말하는 것과 같이 옵션들 중 하나를 선택하거나 다른 방식으로 동작시키는 것을 가능하게 하도록 배열된다(주의: 본원에서 사용된 바와 같은 "수동"이라는 용어는 자동과 대조하기 위한 것일 뿐이며 반드시 손을 사용하는 것으로 제한되지는 않음).

대안적으로 또는 부가적으로, UI 요소들은 하나 이상의 데이터 엔트리 필드들(502)을 포함할 수 있다. 이러한 데이터 엔트리 필드는 같은 사용자 출력 수단 예컨대, 온-스크린을 통해 렌더링되며 데이터는 사용자 입력 수단 예컨대, 키보드 또는 터치스크린을 통해 필드들에 입력될 수 있다. 대안적으로 데이터는 구두로 예컨대, 스피치 인식에 기초하여 수신될 수 있다.

대안적으로 또는 부가적으로, UI 요소들은 사용자에게 정보를 출력하기 위해 출력되는 하나 이상의 정보 요소들(503)을 포함할 수 있다. 예컨대, 이것/이것들은 청각적으로 또는 스크린 상에 렌더링될 수 있다.

다양한 UI 요소들을 렌더링하고, 옵션들을 선택하고, 데이터를 입력하는 특정 수단은 중요하지 않다는 것이 인지될 것이다. 이러한 UI 요소들의 기능성은 곧 자세히 논의될 것이다. 또한, 도 3에 도시된 UI(500)는 도식화된 실물 모형일 뿐이며 실제로는 간결성을 위해 예시되지 않은 하나 이상의 추가 UI 요소들을 포함할 수 있다는 것이 인지될 것이다.

머클 트리들

머클 트리는 데이터 컬렉션의 보안 검증을 가능하게 하는 계층적 데이터 구조이다. 머클 트리에서, 트리의 각 노드에는 인덱스 쌍 (i, j)이 주어지며 N(i, j)로 표시된다. 인덱스 i, j는 단순히 트리 내의 특정 위치와 관련된 숫자 라벨이다.

머클 트리의 특징은 머클 트리의 노드 각각의 구성이 다음의 수학식에 의해 결정된다는 것이다.

여기에서 H는 암호화 해시 함수이다.

이 수학식에 따라 구성된 이진 머클 트리는 도 4에 도시되어 있다.

의 경우는 리프 노드에 대응하고, 이는 단순히 데이터

의 대응하는 i번째 패킷의 해시임을 알 수 있다.

의 경우는 내부 또는 부모 노드에 대응하고, 이는 하나의 부모(머클 루트)가 발견될 때까지 자식 노드를 재귀적으로 해싱하고 연결하여 생성된다.

예컨대, 노드 N(0,3)는 다음과 같이 4개의 데이터 패킷

로부터 구성된다.

.

트리 깊이 M은 트리에서 노드의 가장 낮은 레벨로 정의되며, 노드의 깊이 m는 노드가 존재하는 레벨이다. 예컨대,

및

이고, 도 4에서 M=3이다.

비트코인 및 일부 다른 블록체인의 머클 트리에 대해, 해시 함수는 이중 SHA256이고, 이는 표준 해시 함수 SHA-256를 2번 적용하는 것이고,

이다.

머클 증명들

머클 트리의 주요 기능은 일부 데이터 패킷 D_i이 N 데이터 패킷의 목록 또는 세트

의 구성원이라는 것을 검증하는 것이다. 검증을 위한 메커니즘은 머클 증명으로 알려져 있으며 주어진 데이터 패킷 D_i 및 머클 루트 R에 대한 머클 경로로 알려진 해시의 세트를 얻는 것을 수반한다. 데이터 패킷에 대한 머클 경로는 단순히 반복적인 해싱 및 연결을 통해 루트 R를 재구성하는 데 필요한 최소 해시 목록이며, 종종 '인증 증명'으로 지칭된다.

모든 패킷

및 그들의 순서가 증명자에게 알려진 경우, 존재 증명(proof-of-existence)은 자명하게(trivially) 수행될 수 있다. 그러나 이는 머클 증명보다 훨씬 더 큰 저장 오버헤드를 요구할 뿐 아니라, 전체 데이터 세트를 증명자가 사용할 수 있어야 한다. 머클 증명을 사용하는 것과 전체 목록을 사용하는 것 사이의 비교가 아래의 표에 나타나 있으며, 여기에서 이진 머클 트리를 사용하고 데이터 블록의 수 N이 2의 정수 거듭제곱과 정확히 같다고 가정하였다.

다음의 표는 머클 트리 내의 리프 노드의 수와 머클 증명(또는 머클 증명)에 필요한 해시 수의 사이의 관계를 도시한다.

데이터 패킷의 수가 리프 노드의 수와 동일한 이 단순화된 시나리오에서, 머클 증명을 계산하는 데 필요한 해시 값의 수가 대수적으로 확장된다는 것을 알 수 있다. N개의 데이터 해시를 저장하고 명시적 증명을 계산하는 것보다

개의 해시를 포함하는 머클 증명을 계산하는 것이 분명히 훨씬 더 효율적이고 실용적이다.

방법

머클 루트 R이 주어졌을 때, 데이터 블록 D₀이 R로 나타내는 순서화된 목록에 속한다는 것(

)을 증명하려면 다음과 같이 머클 증명을 수행할 수 있다.

i. 신뢰할 수 있는 소스로부터 머클 루트 R를 획득한다.

ii. 소스로부터 머클 증명 Γ를 획득한다. 이 경우, Γ는 해시의 세트이다:

.

iii. 다음과 같이 D₁ 및 Γ를 사용하여 머클 증명을 계산한다:

a. 데이터 블록을 해시하여 다음을 획득한다:

.

b.

를 해시와 컨케터네이팅하여 다음을 획득한다:

.

c.

를 해시와 컨케터네이팅하여 다음을 획득한다:

.

d.

를 해시와 컨케터네이팅하여 루트를 획득한다:

,

.

e. 계산된 루트

를 (i)에서 획득한 루트 R과 비교한다:

1.

이면, 트리 내 및 따라서 데이터 세트 D 내에서

의 존재가 확인된다.

2.

이면, 증명은 실패하고

은 D의 구성원임이 확인되지 않는다.

이는 머클 트리와 그의 루트로 표현되는 데이터 세트의 일부로서 일부 데이터에 대한 존재 증명을 제공하기 위한 효율적인 메커니즘이다. 예컨대, 데이터

가 블록체인 트랜잭션에 대응하고 루트 R가 블록 헤더의 일부로 공개적으로 사용 가능하면, 트랜잭션이 해당 블록에 포함되었음을 신속하게 증명할 수 있다.

예시적인 머클 트리의 일부로서

의 존재를 인증하는 프로세스는 도 5에 도시된다. 이는 주어진 블록

및 루트 R에 대해 머클 증명을 수행하는 것이 필요한 최소 수의 해시 값만 사용하여 머클 트리를 '상향'으로 효과적으로 트래버싱한다는 것을 보여준다.

머클 증명을 구성하기 위한 최소 정보

단일 리프의 머클 증명을 구성할 때, 필요한 최소한의 정보는 다음과 같다.

1. 리프의 인덱스: 머클 트리의 리프 계층에서 리프의 위치.

2. 정렬된 해시 값의 목록: 머클 루트를 계산하는 데 필요한 해시 값.

리프의 인덱스가 작동하는 방법을 설명하기 위해, 도 5의 머클 트리가 고려된다. 밥은 루트 R을 알고 있지만, 트리의 모든 리프를 알지는 못한다. D₀에 대한 머클 분기는 하나의 인덱스 0 및 3개의 해시 값(원)으로 구성된다. 인덱스는, 제공된 해시 값이 계산된 해시 값의 왼쪽 또는 오른쪽에 연결되어야 하는지 여부를 나타낸다.

머클 트리가

개의 리프를 갖는다고 가정한다. 계층 0에서 인덱스 i가 주어지면,

,

,

라고 하고, 즉,

p₀은 인덱스가 i₀인 리프 노드의 쌍 리프 노드의 인덱스이다. 머클 트리에서 자신의 부모 해시 노드를 계산하기 위해 리프 노드들이 연결되고 해싱되기 때문에, 그들이 쌍으로 지칭된다(위 참조). 인덱스가 p₀인 노드는 또한 "제공된 해시" 또는 "필요한 데이터"로 지칭되는데, 왜냐하면 i₀ 리프 노드의 머클 루트를 계산할 때 이것이 제공되어야 하기 때문이다.

따라서 우리는 계층 m에서 정의할 수 있고, 다음을 갖고

그러면 제공된 해시의 인덱스는 다음과 같다.

위의 수학식은 인덱스가 0에서 시작한다고 가정한다.

본 발명의 맥락에서, 인덱스 i₀을 갖는 리프 노드는 타겟 트랜잭션의 트랜잭션 식별자이다.

존재 증명 ― 트랜잭션들

도 6은 본 발명의 실시예를 구현하기 위한 예시적인 시스템(600)을 예시한다. 시스템은 머클 증명 엔티티(또는 MPS(Merkle proof server))(601)를 포함한다. "머클 증명 엔티티"라는 용어는 본원에 설명된 액션들을 수행하도록 구성된 엔티티에 대한 편리한 라벨로서만 사용된다는 것이 유의된다. 마찬가지로, "머클 증명 서버"라는 용어는 설명된 액션들이 서버(즉, 하나 이상의 서버 유닛들)에 의해 수행된다는 것을 반드시 의미하지는 않지만 그것은 하나의 가능한 구현이다.

MPS(601)는 트랜잭션이 블록체인(150)에 존재한다는 증명을 제공하도록 구성된다. MPS(601)는 트랜잭션 식별자들(TxID들)의 세트를 저장하도록 구성된다. 각각의 TxID는 각각의 트랜잭션을 고유하게 식별한다. TxID는 트랜잭션의 해시(예컨대, 이중 해시)이다. MPS(601)는 블록체인(150) 상에 공개된 모든 각각의 트랜잭션의 개개의 TxID를 저장할 수 있다. 대안적으로, MPS(601)는 공개된 트랜잭션들의 전부가 아닌 일부만의 개개의 TxID를 저장할 수 있다. 예컨대, MPS(601)는 공통점을 갖는 모든 트랜잭션들의 개개의 TxID를 저장할 수 있는데 예컨대, 특정 블록으로부터의 모든 트랜잭션들, 특정 시간(UNIX 시간 또는 블록 높이에서) 이후 공개된 모든 트랜잭션들, 특정 블록체인 노드(104)에 의해 공개된 블록 또는 블록들로부터의 모든 트랜잭션들 등을 저장할 수 있다.

MPS(601)는 블록체인 노드(104)가 아니다. 즉, MPS(601)는 채굴 노드 또는 "채굴자"가 아니다. MPS(601)는 블록체인 노드에 의해 동작되거나 연결될 수 있지만, MPS(601) 자체는 작업 증명을 수행하고, 블록들을 구성하고, 블록들을 공개하고, 합의 규칙들을 시행하는 등의 동작들을 수행하지 않는다. 일부 예들에서 MPS(601)는 트랜잭션들을 유효성 검증하지 않는다. 그러나 MPS(601)가 블록들을 공개하는 동작들을 수행하지 않고 트랜잭션들을 유효성 검증할 수 있다는 것이 배제되진 않는다.

또한, MPS(601)는 전체 블록체인(150)을 저장할 필요가 없지만, 그것이 배제되진 않는다. 즉, MPS(601)는 공개된 트랜잭션들 전부를 저장할 필요가 없다. 일부 예들에서 MPS(601)는 어떠한 트랜잭션들도 저장하지 않는다. 또는, MPS(601)는 공개된 트랜잭션들 중 선택된 몇 개 예컨대, 하나 이상의 코인베이스 트랜잭션들을 저장할 수 있다.

MPS(601)는 타겟 트랜잭션 식별자, 즉 타겟 트랜잭션의 트랜잭션을 획득하도록 구성된다. 타겟 트랜잭션은 존재 증명이 요청된 트랜잭션이다. 예컨대, 시스템(600)은 하나 이상의 요청 당사자들(602)을 포함할 수 있다. 요청 당사자(602)는 타겟 트랜잭션에 대한 머클 증명의 요청의 일부로서 타겟 TxID를 MPS(601)에 전송할 수 있다. 다른 예들에서, 제3자는 요청 당사자(602)를 대신하여 MPS(601)에 타겟 TxID를 전송할 수 있다. 일부 예들에서, 타겟 TxID를 MPS(601)로 전송하는 것만으로도 머클 증명에 대한 요청으로 간주된다.

타겟 TxID를 수신하는 대신에, MPS(601)는 타겟 트랜잭션 자체를 대신 수신할 수 있다. 즉, 요청 당사자(602) 또는 제3자는 타겟 트랜잭션을 MPS(601)로 전송할 수 있다. 그 후 MPS(601)는 타겟 TxID를 획득하기 위해 타겟 트랜잭션을 해시(예컨대, 이중 해시)할 수 있다. 또한, MPS(601)가 타겟 TxID 및 타겟 트랜잭션 둘 모두를 수신할 수 있다는 것이 배제되진 않는다. 이 예에서, MPS(601)는 타겟 트랜잭션의 (이중) 해시가 타겟 TxID와 매칭된다는 것을 컨펌하고 만약 매칭되지 경우 요청 당사자(602)에게 경고할 수 있다.

MPS(601)는 또한 타겟 트랜잭션에 대한 "타겟 머클 증명", 즉, 타겟 트랜잭션이 블록체인 상에 존재함을 증명하기 위한 머클 증명을 획득하도록 구성된다. 타겟 머클 증명은 대응하는 머클 트리의 리프들이 실제로 TxID들이기 때문에 저장된 TxID들의 세트 중 하나 이상에 기초한다. 머클 증명들은 위에서 설명되었다. 타겟 머클 증명은 적어도 해시 값의 순서화된 세트를 포함한다. 해시 값들의 순서화된 세트 내 해시 값들의 수는 머클 트리 내 리프들의 수, 즉, 타겟 트랜잭션을 포함하는 블록(151) 내 트랜잭션의 수에 기초한다. 머클 증명은 또한, 해시 값들의 순서화된 세트의 첫 번째 해시 값이 타겟 TxID의 왼쪽 또는 오른쪽에 컨케터네이팅되어야 하는지를 표시하는 리프의 인덱스를 포함할 수 있다.

MPS(601)는 각각의 트랜잭션(즉, 각각의 TxID)에 대한 개개의 머클 증명을 저장할 수 있다. 이 예에서, 타겟 머클 증명을 획득하는 것은 저장소로부터 타겟 머클 증명을 추출하는 것을 포함한다. 예컨대, MPS(601)는 각각의 트랜잭션에 대한 머클 증명을 미리 계산할 수 있다. 타겟 TxID가 획득될 때, MPS(601)는 대응하는 머클 증명을 룩업한다(각각의 머클 증명은 저장소 내 개개의 TxID와 연관될 수 있음).

각각의 트랜잭션 또는 TxID에 대한 개개의 머클 증명을 저장하는 대신 또는 추가로, MPS는 하나 이상의 머클 트리들을 미리 계산하고 저장할 수 있다. 각각의 머클 트리는 저장된 TxID들의 세트의 서브세트, 내부 해시 값들(또는 내부 노드들)의 세트 및 머클 루트를 포함한다. 이 예에서 타겟 머클 증명을 획득하는 것은 타겟 TxID를 포함하는 머클 트리로부터 머클 증명(즉, 요구되는 해시 값들)을 추출하는 것을 포함한다.

다른 예로서, MPS(601)는 타겟 TxID 획득에 대한 응답으로 타겟 머클 증명을 계산할 수 있다. 즉, MPS(601)는 (예컨대, 완전한 머클 트리를 계산하고 요구된 해시 값들을 추출함으로써) 타겟 머클 증명을 계산하기 위해 저장된 TxID들의 세트 중 하나 이상을 사용할 수 있다. 이 방법은 MPS(601)가 타겟 트랜잭션을 포함하는 블록(151)으로부터의 모든 TxID들을 저장소에 가질 것을 요구한다는 것에 주의한다.

타겟 머클 증명은 대응하는 머클 트리의 하나 이상의 내부 해시들 또는 내부 노드들을 포함할 수 있다. 이 경우에, 요청 당사자가 선행 해시(예컨대, 타겟 TxID)를 내부 해시의 왼쪽 또는 오른쪽에 컨케터네이팅할지를 알 수 있도록 요청 당사자에게 해당 내부 해시들의 인덱스를 제공하는 것이 유용하다. 따라서, 타겟 머클 증명을 추출할 때, MPS(601)는 리프 해시의 인덱스, 즉, 타겟 트랜잭션의 TxID를 이용하여 타겟 머클 증명에서 내부 해시들의 인덱스들을 계산한다. MPS는 저장된 트리로부터 머클 증명을 추출하기 위해 이러한 인덱스를 계산해야 하고, 즉, MPS는 저장된 트리를 갖고, 리프 인덱스는 올바른 머클 증명을 추출하기 위해 트리로부터 어떤 내부 노드를 선별할지를 결정하도록 허용한다. 적어도 일부 예들에서, MPS(601)는 타겟 TxID의 인덱스만을 계산할 필요가 있다는 것에 주의한다. 이러한 단일 인덱스는 요구된 내부 해시들을 결정하는 데 충분할 수 있다.

MPS(601)는 또한 타겟 머클 증명을 출력하도록 구성된다. 예컨대, 타겟 머클 증명은 요청 당사자(602)에게 직접 송신될 수 있다. 또는, 타겟 머클 증명이, 예컨대, 웹 페이지에 공개될 수 있다. 타겟 머클 증명은, 타겟 트랜잭션이 블록체인 상에 존재한다는 증명으로서 사용될 수 있다.

도 8은 MPS(601)에 의해 수행될 수 있는 예시적인 방법(800)을 예시한다. 단계(801)에서, MPS는 TxID들의 세트를 저장한다. 일부 예들에서, TxID들은 대응하는 트랜잭션들이 블록(151)에 나타나는 순서에 기초하여 순서화된다. 단계(802)에서, MPS(601)는 타겟 TxID를 획득(예컨대, 수신)한다. 단계(803)에서, MPS(601)는 타겟 TxID(즉, 타겟 트랜잭션)에 대한 머클 증명을 획득한다. MPS(601)는 예컨대, 메모리 또는 로컬 저장소로부터, 또는 머클 증명을 계산함으로써 머클 증명을 획득할 수 있다. 단계(804)에서, MPS는 머클 증명을 출력한다.

일부 예들에서, MPS(601)는 또한 타겟 트랜잭션을 포함하는 블록(151)의 블록 헤더로부터 머클 루트를 출력한다. 머클 루트는 머클 루트를 포함하는 블록 헤더의 일부로서 또는 그 자체로 또는 블록 헤더의 하나 이상의 다른 데이터 필드들 예컨대, 이전 블록 해시와 조합하여 출력될 수 있다. 머클 루트는 요청 당사자(602)에게 직접 출력되거나 다른 방식으로 공개될 수 있다.

MPS(601)는 대응하는 트랜잭션들이 공개된 블록에 기초하여 TxID들을 서브세트들에 저장할 수 있다. 즉, 블록 n으로부터의 트랜잭션들의 TxID들은 하나의 서브세트에 저장되고, 블록 n-1으로부터의 트랜잭션들의 TxID들은 상이한 서브세트에 저장될 수 있는 식이다. 각각의 서브세트 내 TxID들은 순서화된 목록에 저장될 수 있으며, 여기서 TxID들의 순서는 주어진 블록 내 대응하는 트랜잭션들의 순서와 매칭된다.

블록체인(150)의 각각의 블록(151)은 개개의 블록 헤더를 포함한다. MPS들(601)은 하나 이상의 블록 헤더들을 저장할 수 있다. 예컨대, MPS(601)는 모든 각각의 공개된 블록(151)에 대한 블록 헤더를 저장할 수 있다. 블록 헤더는 순서화된 목록에 저장될 수 있다. 블록 헤더의 순서는 블록체인(150) 내의 대응하는 블록(151)의 순서와 매칭될 수 있다. 일부 예들에서, 주어진 블록(151)으로부터의 TxID들은 해당 블록(151)에 대한 블록 헤더와 연관되어 저장될 수 있다.

보안을 위해, 블록 헤더 값을 재생산하고 작업 증명을 유효성 검증할 수 있도록 블록 헤더의 모든 필드들이 저장되어야 한다. 그러나 완전한 블록 헤더를 저장하는 대신, MPS(601)가 일부 예들에서 블록 헤더의 모든 데이터 필드들이 아니라 그 중 하나 이상만을 저장할 수 있다는 것이 배제되진 않는다. 예컨대, MPS(601)는 블록 헤더 내에 포함된 머클 루트만을 저장할 수 있다. 또는, MPS(601)는 머클 루트 및 블록 헤더에 포함된 이전 해시(블록 헤더 n에 저장된 이전 해시는 n-1번째 블록 헤더와 동일함)를 저장할 수 있다.

MPS(601)는 블록체인 네트워크(106), 예컨대, 블록체인 노드들로부터 저장된 TxID들의 일부 또는 전부를 획득할 수 있다. 모든 TxID들은 단일 블록체인 노드(104)로부터 획득될 수 있다. 대안적으로, TxID들은 다수의 노드로부터 획득될 수 있는데, 예컨대, 하나의 블록체인 노드로부터 일부를 획득하고, 상이한 블록체인 노드로부터 일부를 획득하는 식일 수 있다. 블록 헤더에도 동일하게 적용된다. 즉, 저장된 블록 헤더의 일부 또는 전부(또는 단지 저장된 머클 루트 및/또는 이전 블록 해시)는 단일 블록체인 노드(104)로부터 또는 다수의 노드(104)에 걸쳐 획득될 수 있다. 일부 예들에서, MPS(601)는 동일한 블록체인 노드(104)로부터의 주어진 블록(및 선택적으로 해당 블록의 블록 헤더)으로부터 모든 트랜잭션들의 TxID들을 획득할 수 있다.

일부 예들에서, MPS(601)는 다수의 노드들(104)로부터 동일한 TxID들 및/또는 블록 헤더들을 획득함으로써 획득된 TxID들 및/또는 블록 헤더들의 일부 또는 전부를 검증할 수 있다.

부가적으로 또는 대안적으로, 도 6에 도시된 바와 같이, 블록 헤더들의 일부 또는 전부는 하나 이상의 SPV(simplified payment verification) 클라이언트들(604)로부터 획득될 수 있다. SPV 클라이언트는 블록체인의 블록 헤더들 중 하나, 일부 또는 전부를 저장하고 SPV 방법을 수행하도록 구성된 클라이언트 애플리케이션이다. 자세한 내용은 예컨대, https://wiki.bitcoinsv.io/index.php/Simplified_Payment_Verification을 참조한다. 예컨대, MPS(601)는 SPV 클라이언트를 동작시키거나, 상이한 엔티티(반드시 상이한 MPS일 필요는 없음)에 의해 동작되는 SPV 클라이언트와의 연결을 가질 수 있다.

요컨대, UTXO를 지출하기 위해, SPV 지갑을 사용하는 발신자는 수신자에게 다음 정보를 전달할 것이다.

1. UTXO를 출력으로서 포함하는 트랜잭션 Tx₀,

2. Tx₀의 머클 증명,

3. 머클 증명(또는 그의 식별자, 예컨대, 블록 높이)으로부터 도출된 머클 루트를 포함하는 블록 헤더,

4. UTXO를 지출하는 트랜잭션 Tx₁.

정보를 유효성 검증하기 위해, 수신자는 Tx₀의 머클 증명으로부터 머클 루트를 계산한다. 그런 다음 수신자는 이를 블록 헤더에 지정된 머클 루트와 비교한다. 그들이 동일한 경우, 수신자는 Tx₀이 블록체인에 있는 것으로 받아들인다.

위에서 언급된 바와 같이, MPS(601)는 하나 이상의 트랜잭션들, 즉 원시 트랜잭션 데이터를 저장할 수 있다. 예컨대, MP(601)는 블록당 하나의 트랜잭션을 저장할 수 있다. MPS(601)는 각각의 블록에 대한 코인베이스 트랜잭션을 저장할 수 있다(블록당 하나의 코인베이스 트랜잭션만이 있음을 상기함). 그러나 MPS(601)가 코인베이스 트랜잭션 이외의 트랜잭션을 저장할 수 있거나, MPS(601)가 일부 블록들의 개개의 코인베이스 트랜잭션 및 다른 블록들의 상이한 트랜잭션을 저장할 수 있다는 것이 배제되진 않는다.

주어진 블록에 대해 저장된 트랜잭션은 "제1 트랜잭션"으로서 지칭될 것이다. 이는 코인베이스 트랜잭션들의 경우에도 해당하지만, 반드시 트랜잭션이 블록에서 처음 나타나는 것을 의미하지는 않는다. 이러한 예들에서, MPS(601)는 타겟 트랜잭션과 동일한 블록에 공개된 제1 트랜잭션에 대한 머클 증명을 획득할 수 있다. 그 후, MPS(601)는 제1 트랜잭션 자체와 함께 제1 트랜잭션에 대한 머클 증명을, 예컨대, 요청 당사자(602)에게 출력할 수 있다. 이것은 타겟 머클 증명이 올바른 길이인지를 검증하기 위해 요청 당사자(602)에 의해 사용될 수 있다. 예컨대, 제1 트랜잭션에 대한 머클 증명의 길이가 10(즉, 10개의 해시 값들)이면, 타겟 머클 증명의 길이도 또한 10이어야 한다.

MPS(601)는 하나 이상의 사용자 단말들, 이를테면, 데스크톱 컴퓨터, 랩톱 컴퓨터, 태블릿, 스마트폰, 웨어러블 스마트 디바이스, 이를테면, 스마트 시계, 또는 자동차와 같은 차량의 온보드 컴퓨터 등을 포함하는 컴퓨팅 장치의 형태(예컨대, 도 1에 도시된 것과 유사함)를 취한다 부가적으로 또는 대안적으로, 컴퓨팅 장치는 서버를 포함할 수 있다. 여기에서 서버는 하나 이상의 지리적 사이트들에 위치한 하나 이상의 물리적 서버 유닛들을 포함할 수 있는 논리적 엔티티를 지칭한다. 필요한 경우, 분산 또는 "클라우드" 컴퓨팅 기술들은 그 자체가 당업계에 알려져 있다. 서버의 하나 이상의 사용자 단말 및/또는 하나 이상의 서버 유닛은 패킷 교환 네트워크를 통해 서로 연결될 수 있으며, 패킷 교환 네트워크는, 예컨대, 인터넷과 같은 광역 인터넷 네트워크, 3GPP 네트워크와 같은 모바일 셀룰러 네트워크, 이더넷 네트워크와 같은 유선 로컬 영역 네트워크(LAN) 또는 Wi-Fi, Thread 또는 6LoWPAN 네트워크와 같은 무선 LAN을 포함할 수 있다. 컴퓨팅 장치는 제어기 및 인터페이스를 포함한다. 제어기는 인터페이스(204)에 동작 가능하게 커플링된다. 제어기는 MPS에 할당된 액션을 수행하도록 구성된다. 인터페이스는 데이터 예컨대, TxID들, 블록 헤더들, 머클 증명들 등을 송신 및 수신하도록 구성된다.

각각의 제어기 및 인터페이스는 컴퓨터 판독 가능 저장소 상에서 구체화된 소프트웨어 코드 형태로 구현될 수 있으며, 하나 이상의 지리적 위치들에 있는 하나 이상의 컴퓨터 단말들 또는 유닛들 상에 구현된, CPU들와 같은 하나 이상의 프로세서들, GPU들과 같은 작업 가속기 코프로세서들 및/또는 다른 주문형 프로세서들을 포함하는 프로세싱 장치 상에서 실행될 수 있다. 코드가 저장되는 저장소는 재차, 하나 이상의 지리적 위치들에 있는 하나 이상의 컴퓨터 단말들 또는 유닛들 상에서 구현된, 하나 이상의 메모리 매체들(예컨대, 전자 또는 자기 매체들)을 사용하는 하나 이상의 메모리 디바이스들을 포함할 수 있다. 실시예에서, 제어기 및/또는 인터페이스는 서버 상에서 구현될 수 있다. 대안적으로, 이들 구성요소들 중 하나 또는 둘 모두의 각각의 인스턴스는 하나 이상의 사용자 단말들 중 하나, 일부 또는 모두 각각에서 부분적으로 또는 심지어 전체적으로 구현될 수 있다. 추가 예에서, 위에서 언급한 구성요소들의 기능은 사용자 단말들 및 서버의 임의의 조합 간에 분할될 수 있다. 또한, 필요한 경우, 분산형 컴퓨팅 기술 자체가 당업계에 알려져 있음이 유의된다. 또한 이러한 구성요소들 중 하나 이상이 전용 하드웨어에서 구현될 수 있다는 것이 또한 배제되지 않는다.

이제 요청 당사자(602)가 설명될 것이다. 요청 당사자(602)는 머클 증명을 위한 요청을 MPS(601)에 전송하도록 구성된다. 요청 당사자(602)는 타겟 TxID 및/또는 타겟 트랜잭션을 MPS(601)에 전송할 수 있다. 이에 대한 응답으로, 요청 당사자는 타겟 머클 증명을 수신하거나 다른 방식으로 획득하도록 구성된다. 요청 당사자(602)는, 타겟 트랜잭션이 블록체인 상에 존재함을 증명하기 위해 타겟 머클 증명을 사용할 수 있다. 예컨대, 요청 당사자(602)는, 예컨대, 타겟 트랜잭션과 함께 타겟 머클 증명을 수신 당사자(603)에게 전송할 수 있다. 요청 당사자(602)는 또한 타겟 트랜잭션에 기초하는 머클 트리의 머클 루트를 (예컨대, 블록 헤더의 일부로서) 수신 당사자(603)에게 전송할 수도 있다. 머클 루트는 MPS(601)로부터 획득될 수 있다.

일부 예들에서, 요청 당사자(602)는 하나 이상의 부모 트랜잭션들의 존재를 증명하기 위해 타겟 머클 증명을 사용할 수 있다. 이 경우, 타겟 트랜잭션이 자식 트랜잭션인 경우, 타겟 머클 증명은 부모 트랜잭션들 각각이 블록체인(150)에 공개되었음을 증명한다(각각의 부모 트랜잭션이 블록체인(150)에 공개되지 않고서는 자식 트랜잭션이 블록체인(150)에 공개될 수 없음). 일반적으로, 트랜잭션의 체인 내 가장 최근에 공개된 트랜잭션에 대한 머클 증명은 해당 체인 내 다른 모든 트랜잭션들의 존재를 증명한다.

요청 당사자(602)는 SPV 클라이언트일 수 있다(또는 이를 동작시킬 수 있음). 즉, SPV 클라이언트(예컨대, 지출자에 의해 동작됨)는, 즉, 다른 당사자(예컨대, 수신자)에게 타겟 머클 증명을 제공함으로써 SPV 방법을 수행하기 위해 타겟 머클 증명을 사용할 수 있다. 이 경우에, 타겟 트랜잭션은 UTXO를 포함할 수 있고, 지출자에게 잠금되고, 수신자에게 잠금된 UTXO를 포함하는 지출 트랜잭션에 의해 참조된다.

요청 당사자(602)는 지갑 애플리케이션일 수 있다(또는 이를 동작시킬 수 있음). 지갑 애플리케이션은 타겟 트랜잭션을 저장할 수 있다. 온라인 모드 또는 상태(즉, MPS(601)에 연결됨)에서, 지갑 애플리케이션은 타겟 트랜잭션에 대한 타겟 머클 증명을 획득할 수 있다. 그 후 지갑 애플리케이션은 오프라인 모드 또는 상태(즉, MPS(601)에 연결되지 않음)에서 동작할 수 있으며, 지갑 애플리케이션은 타겟 트랜잭션이 블록체인에 존재한다는 증명으로서 수신 당사자(603)에게 타겟 트랜잭션 및 타겟 머클 증명을 제공할 수 있다.

요청 당사자(602)는 앨리스(103a) 또는 밥(103b)의 형태를 취할 수 있다.

요청 당사자(602)는 보조 MPS일 수 있다. 보조 MPS 또는 "무결성 MPS"는 블록체인 트랜잭션들(타겟 트랜잭션을 포함함)의 세트를 저장하고 MPS(601)(기본 MPS 또는 "일반 MPS"로서 또한 지칭됨)에 타겟 TxID를 전송하고, 타겟 머클 증명을 획득하고 타겟 머클 증명을 보조 요청 당사자, 예컨대, 수신 당사자(603), 최종 사용자(예컨대, 앨리스(103a) 또는 밥(103b)) 등에 출력하도록 구성된다.

도 6b는 무결성 MPS(602)와 일반 MPS(601) 사이의 상호작용을 보여주는 예시적인 시스템(600B)을 도시한다. 도시된 바와 같이, 시스템(600B)은 하나 이상의 블록체인 노드(104), 무결성 MPS(602), 일반 MPS(601), 요청 당사자(무결성 MPS와 상이함, 예컨대, 제3자 사용자)(603) 및 SPV 클라이언트(604)를 포함한다. 시스템(600B)은 다수의 요청 당사자들(603) 및/또는 SPV 클라이언트들(604)을 포함할 수 있다.

일반 MPS(601)에서 시작하여, 이것은 주로 주어진 트랜잭션 식별자(TxID)에 대한 머클 증명을 제공하는 것과 관련된다. 일반 MPS(601)는 요청 당사자(603) 또는 무결성 MPS(602)에 머클 증명을 출력할 수 있다. 예컨대, 요청 당사자(603) 또는 무결성 MPS(602)는 TxID를 일반 MPS(601)로 전송할 수 있고, 일반 MPS(601)는 그 대가로 머클 증명을 제공한다. 일반 MPS(601)는 하나 이상의 소스로부터 머클 증명을 생성하는 데 필요한 데이터를 획득할 수 있다. 예컨대, 머클 증명 자체는 블록체인 노드(104)로부터 획득될 수 있다. 부가적으로 또는 대안적으로, 일반 MPS(601)는 블록체인 노드(104) 또는 SPV 클라이언트(604)로부터 TxID 및 대응하는 블록 헤더(들)를 획득할 수 있다. 일반 MPS(601)는 TxID 및 대응하는 블록 헤더를 사용하여 머클 증명을 계산할 수 있다.

무결성 MPS(602)에 대해서, 이것은 주로 요청 당사자(603)에게 머클 증명을 제공하는 것과 관련이 있다. 무결성 MPS(602)는 요청 당사자(603)로부터 트랜잭션 구성요소(또는 트랜잭션 데이터 필드 또는 데이터 항목)를 수신할 수 있고, 그 대가로 해당 구성요소를 포함하는 트랜잭션에 대한 머클 증명을 제공할 수 있다. 요청 당사자(603)는 트랜잭션 및 머클 증명을 다른 당사자, 예컨대, SPV 클라이언트(604)에게 차례로 전송할 수 있다. 무결성 MPS(602)는 블록체인 노드(104) 및/또는 SPV 클라이언트(604)로부터 트랜잭션을 획득할 수 있다. 무결성 MPS(601)는 또한 머클 증명의 일부로서 사용하기 위해 블록체인 노드(104) 및/또는 SPV 클라이언트(604)로부터 블록 헤더를 획득할 수 있지만, 블록 헤더는 충분한 데이터가 이용 가능한 경우 무결성 MPS(602)에 의해 계산될 수 있다.

일반적으로, 무결성 MPS(602)는 일반 MPS(601)로부터 다수의 머클 증명을 획득하고, 예컨대, 저장된 트랜잭션 각각에 대해 하나를 획득할 수 있다. 예컨대, 무결성 MPS가 새로운 트랜잭션을 수신하고 저장할 때, 무결성 MPS(602)는 새로운 트랜잭션에 대한 머클 증명을 위한 요청을 일반 MPS(601)에 전송할 수 있다.

본 발명의 일부 실시예의 예시적인 구현이 이제 설명될 것이다.

일반 MPS

일반 MPS(601)는 수신 당사자, 예컨대, 사용자에게 머클 증명을 제공하는 전용 서버의 역할을 한다. 즉, 일반 MPS(601)는, 트랜잭션이 블록체인에 공개된 경우, 주어진 트랜잭션 또는 트랜잭션 ID에 대한 머클 증명을 제공하는 서버이다. 일반 MPS(601)는 전체 트랜잭션 데이터를 저장하지 않는다. 이것은 머클 트리의 저장소를 갖는 블록체인 네트워크에서 SPV 클라이언트를 보완하는 것으로 간주될 수 있다. 보다 정확하게는, 일반 MPS는 다음과 같은 저장 요건의 목록을 갖는다.

1. 작업 증명이 가장 많은 체인을 나타내는 블록 헤더의 순서화된 목록(선택적 요건)

2. 각각의 블록 헤더에 대한 트랜잭션 ID의 순서화된 목록(핵심 요건)

3. 머클 루트가 블록 헤더에 지정된 것과 매칭되는 각각의 블록 헤더에 대해 미리 계산된 머클 트리(선택적 요건)

4. 각각의 블록의 코인베이스 트랜잭션의 원시 데이터 또는 각각의 블록 헤더에 대한 블록의 트랜잭션의 원시 데이터(선택적 요건)

첫 번째 요건은 일반 MPS(601)의 데이터 무결성을 보장하는 것이다. 블록 헤더의 머클 루트는 트랜잭션 ID 목록에 대한 무결성 체크로서 사용될 수 있다. 즉, 블록 헤더는, 머클 트리의 리프를 형성할 때 주어진 블록로부터의 TxID가 블록 헤더에서 머클 루트를 제공한다는 것을 체크하는 데 사용될 수 있다. 첫 번째 요건은, 예컨대, TxID가 신뢰할 수 있거나 일반 MPS(601)가 신뢰할 수 있는 SPV 클라이언트 또는 작업 증명이 가장 많은 체인의 블록 헤더를 저장하는 것으로 신뢰할 수 있는 임의의 엔티티에 안전하게 액세스할 수 있는 경우, 삭제될 수 있다.

두 번째 요건이 핵심인데 그 이유는 이것이 머클 트리를 재구성할 수 있도록 머클 트리에 나타나는 순서대로 머클 리프를 제공하기 때문이다. 코인베이스 트랜잭션 ID가 항상 목록의 첫 번째 리프 또는 첫 번째 해시라는 것이 유의된다. 리프의 순서는 우승 블록을 구성한 블록체인 노드에 의해 결정된다. 비트코인 SV에서, 순서는 토폴로지 순서 및 처음 본 규칙(first-seen rule)을 반영해야 한다.

세 번째 요건은 계산과 저장 간의 트레이드 오프에 대한 옵션을 제공한다. 도 7은 실선 상자가 필수이고(일부 예들에서) 파선 상자가 선택 사항인 저장 요건을 도시한다. 블록 헤더가 도시된 것에 대한 추가적인 필드를 포함하지만 일반적으로 머클 증명에는 루트 해시만이 필요하다는 것이 유의된다. 이전 해시는 루트 해시를 인덱싱하는 데 사용될 수 있다. 요점은 일반 MPS(601)가 머클 트리의 내부 노드들을 저장할 필요가 없다는 것이다. 블록 헤더 내 작업 증명에 대한 링크를 증명하기 위해, 블록 헤더의 모든 필드들이 요구된다는 것에 주의한다. '이전 해시(Prev Hash)' 필드는 그것이 블록헤더들 간의 체인 관계를 예시하기 때문에 지명되도록 선정된다. '루트 해시(Root Hash)' 필드는 그것이 머클 트리에 대한 링크를 보여주기 때문에 선정된다. 그러나 작업 증명에 대한 링크는 모든 블록 헤더 구성요소들이 제공될 때만 유효성 검증될 수 있다.

네 번째 요건은 머클 트리의 깊이에 대한 증명을 제공하는 것이다. 이것은 일반 MPS(601)에 의해 사용자에게 제공될 수 있는 부가 서비스이다. 트랜잭션의 원시 데이터를 제공받은 임의의 검증자는, 머클 증명의 첫 번째 해시가 실제로 리프임을 확신할 수 있는데, 왜냐하면 리프가 아닌 주어진 해시 값에 대해 의미 있는 트랜잭션을 구성하는 것이 계산적으로 불가능하기 때문이다. 또한, 머클 증명의 길이가 머클 트리의 깊이를 의미하므로, 동일한 트리로부터의 모든 머클 증명은 동일한 길이를 갖는다. 이러한 서비스는, 사용자가 관심 트랜잭션의 원시 데이터를 소유하지 않은 경우에 특히 유용하다.

TxID₁과 같은 트랜잭션 ID가 주어지면, 일반 MPS(601)는 트랜잭션 ID의 순서화된 목록을 검토한다. 일반 MPS(601)가 TxID₁을 찾으면, 일반 MPS는 TxID₁에 대한 머클 증명을 구성하거나 추출하여 이를 출력한다. 그렇지 않으면, 일반 MPS(601)는, 예컨대, "트랜잭션을 찾을 수 없음"을 출력한다. 트랜잭션의 원시 데이터가 주어지면, 일반 MPS(601)는 대응하는 트랜잭션 ID를 획득하기 위해 데이터를 해싱하고 위와 같이 진행할 수 있다.

새로운 블록이 공개될 때, 일반 MPS(601)는 다음을 획득한다.

1. 새로운 블록 헤더,

2. 새로운 블록에 대한 트랜잭션 ID의 순서화된 목록, 그리고

3. 원시 코인베이스 트랜잭션.

일반 MPS(601)는 다음을 선택적으로 체크할 수 있다.

1. 새로운 블록 헤더는 유효한 작업 증명을 갖는다는 것,

2. 트랜잭션 ID로부터 계산된 머클 루트는 블록 헤더의 머클 루트와 동일하다는 것, 및

3. 코인베이스 트랜잭션의 해시는 리프의 첫 번째 요소와 동일하다는 것.

유의 ― 서버가 원시 트랜잭션을 얻거나 트랜잭션에 대한 서명 검증을 실행할 필요는 없다.

다음은 머클 트리의 깊이를 제공하는 것이 가치 있는 서비스인 이유를 설명한다. SPV 클라이언트는 트랜잭션 ID와 머클 증명을 입력으로서 취하고, 머클 루트가 블록 헤더 중 하나의 머클 루트와 매칭되면 참(true)을 출력하고 그렇지 않으면 거짓(false)을 출력한다. 그러나 이러한 검증은, 필요한 정보의 부족으로 인해 머클 증명의 길이가 머클 트리의 길이와 매칭되는지 여부를 체크하지 않는다. 일부 경우에, 적대자는, 존재하지 않는 트랜잭션 ID가 존재한다는 것을 증명하려는 시도로 단축된 머클 증명을 제출할 수 있다. 이 단축된 머클 증명은 리프 또는 후속 해시를 함께 제거함으로써 획득될 수 있다.

머클 증명 제공자로서 일반 MPS(601)는 머클 증명의 길이를 검증하는 데 필요한 정보를 제공할 수 있는 최적의 위치에 있다. 머클 트리의 깊이를 명시적으로 제공하는 대신에, 일반 MPS(601)는 코인베이스 트랜잭션의 원시 데이터 및 그의 머클 증명을 제공한다. 원시 트랜잭션 데이터 및 머클 증명을 위조하는 것은 계산상 실현 불가능하다. 따라서, 이는 머클 트리의 깊이에 대한 증명으로서 역할을 한다. 트리의 깊이를 아는 것은 위에서 언급한 치명적인 취약점을 완화할 수 있다. 관심 트랜잭션의 원시 데이터와 머클 증명이 SPV에 제공되면, 이는 이러한 취약점에 대해 안전하다는 것이 유의된다. SPV가 관심 있는 트랜잭션의 원시 데이터가 없는 경우, 우리는 코인베이스 트랜잭션의 원시 데이터와 그의 머클 증명을 사용하여 머클 트리의 깊이 또는 이러한 머클 트리와 관련된 머클 증명의 정확한 길이를 설정할 수 있다.

이론적으로, 이 취약점은 또한 일반 MPS(601)를 속여 리프 또는 임의의 후속 레벨이 함께 제거된 머클 트리를 수락하도록 하는 데 사용될 수도 있다. 그러나, 일반 MPS(601)는 수신된 정보의 일관성과 정확성을 보장하기 위해 다수의 블록체인 노드(104)에 연결될 수 있다. 또한, 일반 MPS(601)는 또한 새로운 블록에 대한 머클 트리의 깊이를 검증하기 위해 코인베이스 트랜잭션의 원시 데이터를 다운로드하도록 선택할 수도 있다.

때때로, 일반 MPS(601)는, 동일한 블록 높이에 대해 동시에 둘 이상의 블록이 발견될 때 발생하는 경쟁 블록, 재구성 및 고아 블록(orphan block)을 처리해야 할 수 있다. 다행스럽게도, 이러한 상황은 가장 최근의 헤더를 제외하고는 발생하지 않으며, 이것은 드물게 발생한다. 블록체인(150)은 보통 하나 또는 2개의 블록 후에 경쟁 체인 중 하나로 수렴할 것이다. 따라서, 일반 MPS(601)가 동일한 높이에서 둘 이상의 블록(151)을 수신할 때, 일반 MPS는, 블록체인 네트워크가 가장 많은 작업 증명을 가진 체인으로 수렴될 때까지, 모든 블록을 유지할 것이다.

저장소 절약

현재 BSV 글로벌 원장에는 대략 총 5억개의 트랜잭션들이 있다(유사한 순서 번호는 BTC에 대한 것임). 총 TxID들은 대략 15GB의 저장 공간을 요구할 것이다. BSV 블록체인 자체는 현재 224GB이다. 일반 MPS(601)은 전체 블록체인의 6.7%를 저장할 것을 요구할 것이다. 또한, 저장소는 그 크기가 아닌 트랜잭션들의 수에 의존한다. 블록 높이가 638009이고 블록 헤더가 80바이트인 경우, 블록 헤더들은 총 49MB의 저장소가 필요하며 매년 4MB가 추가된다.

일반 MPS(601)가 머클 증명 생성 시간을 빠르게 하기 위해 머클 트리들의 미리 계산된 부분들을 저장하는 경우: 루트 노드 다음의 첫 번째 계층은 2개의 노드들로 구성되며 트리당 2x32바이트를 요구할 것이다. 따라서 80바이트의 블록 헤더에 컨케터네이팅된 64바이트들은 MPS가 임의의 tx의 머클 분기를 생성할 때 MPS의 하나의 해시 계산을 절약할 것인데, 즉, MPS는 헤더당 80바이트 대신 144바이트를 사용한다. 머클 트리의 두 번째 계층은 4개의 노드들, 즉 헤더당 272바이트로 구성된다. 이런 식이다. 10번째 계층은 헤더당 65552바이트를 요구하고 요구되는 저장소를 총 39GB로 증가시킬 것이다. 이는 15GB의 TXID를 포함하여야 하며, 각각의 블록은 1024개의 트랜잭션들을 갖는다고 가정한다.

TxID 전용 MPS의 한계

설명된 일반 MPS(601)에는 일부 한계를 갖는다. TxID_payment라고 하는 미공개 트랜잭션이 주어지면, 일반 MPS(601)는 입력에서 참조된 아웃포인트가 존재한다는 것을 체크할 수 없을 것이다. 그 이유는 아웃포인트가 트랜잭션 ID와 인덱스의 연결이기 때문이다. 일반 MPS(601)는 트랜잭션 ID의 존재 여부를 결정할 수 있지만, 그것은 트랜잭션이 갖는 출력의 개수 또는 출력이 지출 가능한지 여부에 관한 어떠한 정보도 갖지 않는다. 이를 극복하기 위한 하나의 방법은, 입력의 일부로서 일반 MPS(601)에 대한 TxID_payment에서 참조되는 트랜잭션의 원시 데이터를 제공하는 것이다. 대안적인 방법은 일반 MPS(601)가 미지출 트랜잭션의 원시 데이터를 저장하는 것이다. (여기서 미지출 트랜잭션은 적어도 하나의 지출되지 않고 지출할 수 있는 출력을 갖는 트랜잭션을 나타낸다. )

일반 MPS(601)가 트랜잭션 ID 및 대응하는 인덱스만을 저장하는 경우, 일반 MPS(601)는 인덱스가 변조되지 않았음을 검증하거나 증명할 수 없다는 것이 유의된다. 일반 MPS(601)는 인덱스의 무결성을 검증하거나 증명하기 위해 전체 원시 데이터를 요구한다.

또한, 이는 잠금 스크립트 또는 플래그와 같은 트랜잭션 내부의 특정 데이터 요소를 검색하는 것을 사용자에게 제공할 수 없을 것이다. 따라서, 이는, 예컨대, 블룸(Bloom) 필터를 사용하는 사용자를 지원할 수 없을 것인데, 왜냐하면 블룸 필터가 트랜잭션에 포함된 잠금 스크립트 및 공개 키에 정상적으로 기초하여 트랜잭션을 필터링할 것이기 때문이다.

이것은 보다 세분화된 레벨에서 정보를 제공할 수 있는 MPS를 필요로 한다. 이것은 무결성 MPS로서 지칭된다. 무결성 MPS는 일부 트랜잭션의 원시 데이터를 저장할 것이다. 전체 트랜잭션이 사용자에 의해 제공된 경우, 일반 MPS(601)는 공개된 트랜잭션의 무결성을 증명하는 데 사용될 수 있다는 것이 유의된다. 무결성 MPS는, 관심 있는 전체 트랜잭션을 저장함으로써 공개된 트랜잭션으로부터 추출된 일부 데이터의 무결성을 증명하는 데 사용될 수 있다. 이는 사용자에게 전체 트랜잭션을 제공하도록 요구하지 않는다.

무결성 MPS

무결성 MPS는 관심 트랜잭션의 세트에 대한 원시 트랜잭션 및 그들의 대응하는 머클 증명을 저장한다. 이 세트 내의 트랜잭션에 대한 질의에 대해, 이러한 서버는 원시 트랜잭션 및 그의 머클 증명을 그의 무결성의 증명으로서 제공할 수 있다. 이는 또한 트랜잭션 콘텐츠에서 부분적인 트랜잭션 또는 데이터 요소의 검색을 허용한다. 관심 있는 트랜잭션은 Weather SV, Tokenized, Metanet과 같은 데이터 애플리케이션 또는 임의의 다른 데이터 프로토콜, 또는 심지어 잠금 스크립트, 공개 키, 아웃포인트 등과 같은 데이터 스트링에 기초하여 결정될 수 있다. 따라서 Weather SV만을 전달하는 트랜잭션을 저장하도록 구성된 Weather SV 애플리케이션에 대한 전용 무결성 MPS가 있을 수 있다.

관심 있는 원시 트랜잭션의 세트는 무결성 MPS로 전달되고, 그들이 공개된 경우 서버에서 지속된다. 무결성 MPS는 게이트웨이로 간주되거나, 애플리케이션-특정 트랜잭션에 대한 게이트웨이에 액세스할 수 있다. 블록체인 시스템이 테라바이트 블록으로 확장될 때, 이것은 무결성 MPS을 유지하는 가장 효율적인 방법이 될 것이다. 완전히 탈중앙화된 피어-투-피어 데이터 애플리케이션과 같은 다른 경우에는, 우리는 트랜잭션의 전체 블록을 다운로드하고 블룸 필터를 사용하여 비트코인 개선 제안 37(BIP37)에서와 같이 관심 없는 트랜잭션을 프루닝하거나 그 트랜잭션을 필터링하는 메커니즘에 의존해야 한다.

동작 동안

무결성 MPS는, 머클 트리에서 관심 있는 원시 트랜잭션 및 그들의 머클 증명을 유지하여, 일부 실시예에서 다음 단계를 수행한다.

1 단계: 관심 있는 원시 트랜잭션을 획득.

2 단계: 원시 트랜잭션을 해싱하여 트랜잭션 ID를 획득.

3 단계: 일반 MPS(601)에 그의 머클 증명을 질의.

4 단계: 트랜잭션이 블록에 공개되지 않은 경우 10분 동안 기다린 후 다시 시도.

3 단계에서 일반 MPS(601)에 대한 종속성은 다운로드 및 프루닝의 메커니즘으로 대체될 수 있지만, 이것은 덜 효율적일 것이다. 4 단계에서 공개되지 않은 트랜잭션은 혼잡을 피하기 위해 미리 정의된 시간 제한 후에 삭제될 수 있다. 제한은 애플리케이션마다 다를 수 있다.

트랜잭션은 그의 머클 증명을 제공함으로써 블록체인(150) 상에 공개된 것으로 증명될 수 있다. 대안적으로, 트랜잭션은 그의 지출된 출력들 중 하나를 통해 증명될 수 있다. 트랜잭션 tx_i의 출력이 트랜잭션 tx_j에서 지출될 때, 우리는 tx_i를 부모 트랜잭션이라 하고 tx_j를 자식 트랜잭션이라 한다. 다수의 출력들을 갖는 트랜잭션은 그것이 다수의 자식들을 가질 수 있음을 의미한다. 다수의 입력들을 갖는 트랜잭션은 그것이 다수의 부모들을 가질 수 있음을 의미한다. 트랜잭션의 원시 데이터가 사용 가능한 경우, 이 트랜잭션의 머클 증명은 그의 모든 부모가 공개되었음을 증명하기에 충분하며, 우리는 부모의 머클 증명들을 저장할 필요가 없다.

사실상, 우리는 우리가 트랜잭션들의 체인을 갖는 경우 체인 내 마지막 트랜잭션의 머클 증명 및 모든 트랜잭션들의 원시 데이터가 체인 내 모든 트랜잭션들의 존재를 증명할 수 있다고 진술함으로써 이 관찰을 일반화할 수 있다.

이는 우리가 트랜잭션의 머클 증명을 제거하고 이를 그의 자식들 중 임의의 것의 머클 증명으로 대체하도록 허용한다. 이는 다음과 같은 경우에 유용하다:

1. 블록 크기들 ― 자식 트랜잭션은 부모 트랜잭션보다 훨씬 더 작은 블록에 공개되며, 이 경우 자식 트랜잭션과 그의 머클 증명의 총 크기는 부모 트랜잭션에 대한 머클 증명의 크기보다 작고; 또는

2. 다수의 입력들 ― 자식 트랜잭션은 상이한 트랜잭션들로부터 유래하는 다수의 입력들을 갖고, 이 경우 자식 트랜잭션 및 그의 머클 증명의 총 크기는 그의 부모 트랜잭션들에 대한 모든 머클 증명들의 총 크기보다 작다.

예컨대, 특정 애플리케이션의 경우, 모든 트랜잭션들은 전용 머클 증명 출력을 가질 수 있다. 때때로, 이러한 출력들은 하나의 자식 트랜잭션에서 수집 및 지출된다. 자식 트랜잭션 및 그의 머클 증명은 모든 부모 트랜잭션들의 무결성 및 존재를 증명할 수 있을 것이다. 따라서 부모 트랜잭션들 중 임의의 것에 대한 머클 증명을 저장할 필요가 없다.

제공된 데이터로부터 도출할 수 있는 증명들을 나열한 다음 표에 관찰내용이 요약될 수 있다.

표는 다음과 같은 경우 출력이 존재하는 것으로 증명되었음을 보여준다:

1. 원시 트랜잭션이 제공되고 해당 트랜잭션이 존재하는 경우, 또는

2. 해당 출력 또는 더 높은 인덱스 출력은 기존 트랜잭션을 지불하는 데 사용된 경우.

결론

개시된 기술들의 다른 변형들 또는 사용 사례들은 본원에서의 개시가 주어지면 당업자에게 명백해질 수 있다. 본 개시내용의 범위는 설명된 실시예에 의해 제한되는 것이 아니라 첨부된 청구들에 의해서만 제한된다.

예컨대, 위의 일부 실시예들은 비트코인 네트워크(106), 비트코인 블록체인(150) 및 비트코인 노드(104) 관점에서 설명되었다. 그러나 비트코인 블록체인은 블록체인(150)의 하나의 특정 예이며 위의 설명은 모든 블록체인에 일반적으로 적용될 수 있다는 것이 인지될 것이다. 즉, 본 발명은 결코 비트코인 블록체인으로 제한되지 않는다. 보다 일반적으로, 비트코인 네트워크(106), 비트코인 블록체인(150) 및 비트코인 노드(104)에 대한 위의 임의의 참조는 각각 블록체인 네트워크(106), 블록체인(150) 및 블록체인 노드(104)에 대한 참조로 대체될 수 있다. 블록체인, 블록체인 네트워크 및/또는 블록체인 노드는 위에서 설명된 바와 같이 비트코인 블록체인(150), 비트코인 네트워크(106) 및 비트코인 노드(104)의 설명된 성질들 중 일부 또는 전부를 공유할 수 있다.

본 발명의 바람직한 실시예들에서, 블록체인 네트워크(106)는 비트코인 네트워크이고 비트코인 노드들(104)은 블록체인(150)의 블록들(151)을 생성, 공개, 전파 및 저장하는 설명된 기능들 모두를 적어도 수행한다. 이러한 기능들의 전부는 아니지만 하나 또는 일부만을 수행하는 다른 네트워크 엔티티들(또는 네트워크 요소들)이 있을 수 있음을 배제되지 않는다. 즉, 네트워크 엔티티는 블록들을 생성 및 공개하지 않고 블록들을 전파 및/또는 저장하는 기능을 수행할 수 있다(이러한 엔티티들은 바람직한 비트코인 네트워크(106)의 노드들로 간주되지 않음을 상기한다).

본 발명의 다른 실시예들에서, 블록체인 네트워크(106)는 비트코인 네트워크가 아닐 수 있다. 이러한 실시예들에서, 노드가 블록체인(150)의 블록들(151)을 생성, 발행, 전파 및 저장하는 기능들 전부는 아니지만 적어도 하나 또는 일부를 수행할 수 있다는 것이 배제되지 않는다. 예컨대, 이러한 다른 블록체인 네트워크들에서, "노드"는 블록들(151)을 생성 및 공개하지만 해당 블록들(151)을 저장하고 그리고/또는 다른 노드에 전파하진 않도록 구성된 네트워크 엔티티를 지칭하는 데 사용될 수 있다.

보다 더 일반적으로, 위의 "비트코인 노드"(104)라는 용어에 대한 임의의 참조는 "네트워크 엔티티" 또는 "네트워크 요소"라는 용어로 대체될 수 있으며, 이러한 엔티티/요소는 블록들을 생성, 공개, 전파 및 저장하는 역할들의 일부 또는 전부를 수행하도록 구성된다. 이러한 네트워크 엔티티/요소의 기능들은 블록체인 노드(104)를 참조하여 위에서 설명된 동일 방식으로 하드웨어로 구현될 수 있다.

위의 실시예들은 단지 예로서만 설명되었다는 것이 인지될 것이다. 보다 일반적으로, 다음 스테이트먼트들 중 임의의 하나 이상에 따른 방법, 장치 또는 프로그램이 제공될 수 있다.

스테이트먼트 1.

블록체인 트랜잭션이 블록체인 상에 존재한다는 증명을 제공하는 컴퓨터 구현 방법으로서, 방법은 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하지만, 블록체인 네트워크에 새로운 블록체인 블록들을 공개하지 않도록 구성된 머클 증명 엔티티에 의해 수행되고, 방법은,

타겟 블록체인 트랜잭션의 타겟 트랜잭션 식별자를 획득하는 단계 ― 타겟 트랜잭션 식별자는 저장된 트랜잭션 식별자들의 세트의 일부를 형성함 ― ;

타겟 블록체인 트랜잭션에 대한 타겟 머클 증명을 획득하는 단계 ― 대응하는 타겟 머클 루트는 블록체인의 블록헤더 내에 포함됨 -; 및

타겟 블록체인 트랜잭션이 블록체인 상에 존재한다는 증명으로서 요청 당사자에 의한 사용을 위해 타겟 머클 증명을 출력하는 단계를 포함하는, 컴퓨터 구현 방법.

머클 증명 엔티티는 블록체인에서 블록을 구성 및/또는 공개하는 작업을 수행하지는 않는다. 즉, 머클 증명 엔티티는 블록체인 노드가 아니다. 일부 예들에서, 머클 증명 엔티티는 임의의 블록체인 트랜잭션들을 저장하지 않는다. 다른 예들에서, 머클 증명 엔티티는 블록 당 단 하나의 블록체인 트랜잭션만을 저장한다. 또 다른 예들에서, 머클 증명 엔티티는 블록당 블록체인 트랜잭션들의 일부 또는 전부를 저장한다.

스테이트먼트 2. 스테이트먼트 1의 방법에 있어서,

머클 증명 엔티티는 전체 블록체인을 저장하지 않는, 컴퓨터 구현 방법.

스테이트먼트 3. 스테이트먼트 1 또는 스테이트먼트 2의 방법에 있어서,

타겟 머클 증명을 획득하는 단계는 대응하는 타겟 머클 트리의 리프 계층 내에서 타겟 트랜잭션 식별자의 인덱스를 계산하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 4. 스테이트먼트 3의 방법에 있어서,

인덱스를 요청 당사자에게 출력하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 5. 임의의 선행 스테이트먼트의 방법에 있어서,

상기 타겟 트랜잭션 식별자를 획득하는 단계는 요청 당사자로부터 타겟 트랜잭션 식별자를 획득하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 6. 임의의 선행 스테이트먼트의 방법에 있어서,

상기 타겟 트랜잭션 식별자를 획득하는 단계는 타겟 블록체인 트랜잭션을 획득하는 단계 및 타겟 블록체인 트랜잭션에 기초하여 타겟 트랜잭션 식별자를 구성하는 단계를 포함하는, 컴퓨터 구현 방법.

타겟 블록체인 트랜잭션은 요청 당사자로부터 수신될 수 있다.

스테이트먼트 7. 임의의 선행 스테이트먼트의 방법에 있어서,

상기 타겟 머클 증명을 획득하는 단계는 저장된 트랜잭션 식별자들의 세트 중 하나 이상을 사용하여 타겟 머클 증명을 계산하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 8. 임의의 선행 스테이트먼트의 방법에 있어서,

머클 증명 엔티티는 타겟 트랜잭션 식별자를 포함하는 저장된 트랜잭션 식별자들의 세트 중 하나 이상에 대한 개개의 머클 증명을 저장하고, 상기 타겟 머클 증명을 획득하는 단계는 저장 위치로부터 타겟 머클 증명을 추출하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 9. 임의의 선행 스테이트먼트의 방법에 있어서,

상기 타겟 머클 증명을 출력하는 단계는 타겟 머클 증명을 요청 당사자에게 송신하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 10. 임의의 선행 스테이트먼트의 방법에 있어서,

상기 타겟 머클 증명을 출력하는 단계는 타겟 머클 증명을 공개하는 단계를 포함할 수 있는, 컴퓨터 구현 방법.

스테이트먼트 11. 임의의 선행 스테이트먼트의 방법에 있어서,

머클 증명 엔티티는 하나 이상의 머클 루트들을 저장하고, 각각의 머클 루트는 저장된 트랜잭션 식별자들의 세트의 개개의 서브세트에 기초하는, 컴퓨터 구현 방법.

스테이트먼트 12. 스테이트먼트 11의 방법에 있어서,

타겟 트랜잭션 식별자에 기초한 머클 루트를 요청 당사자에게 출력하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 13. 스테이트먼트 11 또는 스테이트먼트 12의 방법에 있어서,

머클 증명 엔티티는 하나 이상의 머클 루트들 각각에 대해, 머클 트리를 저장하는, 컴퓨터 구현 방법.

스테이트먼트 14. 스테이트먼트 13의 방법에 있어서,

상기 타겟 머클 증명을 획득하는 단계는 타겟 트랜잭션 식별자를 포함하는 저장된 머클 트리로부터 타겟 머클 증명을 추출하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 15. 임의의 선행 스테이트먼트의 방법에 있어서,

저장된 트랜잭션 식별자들의 세트는 트랜잭션 식별자들의 복수의 서브세트들을 포함하고, 트랜잭션 식별자들의 각각의 서브세트는 블록체인의 개개의 블록으로부터의 모든 트랜잭션 식별자들을 포함하는, 컴퓨터 구현 방법.

트랜잭션 식별자의 각각의 서브세트는 개개의 블록에 저장된 블록체인 트랜잭션의 순서에 대응하는 순서화된 목록에 저장될 수 있다.

스테이트먼트 16. 스테이트먼트 15의 방법에 있어서,

트랜잭션 식별자들의 각각의 서브세트는 블록체인의 개개의 블록의 개개의 블록 헤더와 연관되어 저장되는, 컴퓨터 구현 방법.

개개의 블록 헤더는 블록체인 상에 공개된 블록의 순서에 대응하는 순서화된 목록에 저장될 수 있다.

스테이트먼트 17. 임의의 선행 스테이트먼트의 방법에 있어서,

블록체인 상에 공개된 각각의 블록체인 트랜잭션의 개개의 트랜잭션 식별자를 저장하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 18. 임의의 선행 스테이트먼트의 방법에 있어서,

저장된 트랜잭션 식별자들의 세트 중 적어도 일부는 하나 이상의 블록체인 노드들로부터 획득되는, 컴퓨터 구현 방법.

예컨대, 저장된 트랜잭션 식별자들 전부는 블록체인 노드로부터 획득될 수 있다.

스테이트먼트 19. 스테이트먼트 16 또는 이에 의존하는 임의의 스테이트먼트의 방법에 있어서,

블록 헤더들의 적어도 일부는 하나 이상의 블록체인 노드들로부터 획득되고 그리고/또는 블록 헤더들의 적어도 일부는 하나 이상의 SPV(simplified payment verification) 클라이언트 애플리케이션들로부터 획득되는, 컴퓨터 구현 방법.

스테이트먼트 20. 스테이트먼트 16 또는 이에 의존하는 임의의 스테이트먼트의 방법에 있어서,

머클 증명 엔티티는 블록 헤더들 중 하나 이상을 저장하는 SPV 클라이언트 애플리케이션을 동작시키거나 SPV 클라이언트 애플리케이션에 대한 액세스를 갖는, 컴퓨터 구현 방법.

스테이트먼트 21. 스테이트먼트 15 또는 이에 의존하는 임의의 스테이트먼트의 방법에 있어서,

머클 증명 엔티티는 트랜잭션 식별자들의 각각의 서브세트에 대해, 개개의 블록으로부터의 제1 블록체인 트랜잭션을 저장하는, 컴퓨터 구현 방법.

스테이트먼트 22. 스테이트먼트 21의 방법에 있어서,

제1 블록체인 트랜잭션에 대한 제1 머클 증명을 획득하는 단계 ― 제1 머클 증명은 저장된 트랜잭션 식별자들의 세트 중 하나 이상에 기초함 ― ; 및

타겟 머클 증명의 길이가 대응하는 타겟 머클 트리의 길이와 매칭된다는 것을 검증하는데 요청 당사자에 의한 사용을 위해 제1 블록체인 트랜잭션 및 제1 머클 증명을 출력하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 23. 스테이트먼트 22의 방법에 있어서,

제1 블록체인 트랜잭션은 생성 트랜잭션인, 컴퓨터 구현 방법.

코인베이스 트랜잭션 또는 개시 트랜잭션으로서 또한 알려진 생성 트랜잭션은 블록에서 논리적으로 처음 공개된 트랜잭션이다. 그것은 해당 블록을 공개한 블록체인 노드에 의해 생성된다.

스테이트먼트 24. 임의의 선행 스테이트먼트의 방법에 있어서,

요청 당사자는 SPV(simplified payment verification) 클라이언트 애플리케이션을 동작시키는, 컴퓨터 구현 방법.

요청 당사자는 오프라인 지갑 애플리케이션을 동작시킬 수 있다.

스테이트먼트 25. 스테이트먼트 1 내지 스테이트먼트 23 중 어느 하나의 방법에 있어서,

요청 당사자는 타겟 블록체인 트랜잭션을 포함하는 블록체인 트랜잭션들의 세트를 저장하고 타겟 머클 증명을 제2 요청 당사자에게 출력하도록 구성된 보조 머클 증명 엔티티를 포함하는, 컴퓨터 구현 방법.

예컨대, 제2 요청 당사자는 최종 사용자일 수 있다.

스테이트먼트 26. 블록체인 트랜잭션이 블록체인 상에 존재한다는 증명을 획득하는 컴퓨터 구현 방법으로서, 머클 증명 엔티티는 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하고, 머클 증명 엔티티는 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하지만 블록체인 네트워크에 새로운 블록체인 블록들을 공개하지 않도록 구성되며, 방법은 요청 당사자에 의해 수행되고,

타겟 블록체인 트랜잭션 및/또는 타겟 트랜잭션의 타겟 트랜잭션 식별자를 머클 증명 엔티티에 전송하는 단계; 및

머클 증명 엔티티로부터, 타겟 블록체인 트랜잭션에 대한 타겟 머클 증명을 획득하는 단계를 포함하고, 머클 증명은 저장된 트랜잭션 식별자들의 세트 중 하나 이상에 기초하는, 컴퓨터 구현 방법.

스테이트먼트 27. 스테이트먼트 26의 방법에 있어서,

타겟 블록체인 트랜잭션이 블록체인에 존재한다는 증명으로서 타겟 머클 증명을 제2 요청 당사자에게 전송하는 단계를 포함하는, 컴퓨터 구현 방법.

스테이트먼트 28. 스테이트먼트 26 또는 스테이트먼트 27의 방법에 있어서,

타겟 블록체인 트랜잭션은 블록체인 트랜잭션들의 체인 중 가장 최근 트랜잭션이며, 요청 당사자는 블록체인 트랜잭션들의 체인의 각각의 트랜잭션에 대한 액세스를 갖고, 타겟 머클 증명은 블록체인 트랜잭션들의 체인 내 각각의 트랜잭션이 블록체인 상에 존재한다는 증명인, 컴퓨터 구현 방법.

스테이트먼트 29. 컴퓨터 장비로서,

하나 이상의 메모리 유닛들을 포함하는 메모리; 및

하나 이상의 프로세싱 유닛들을 포함하는 프로세싱 장치를 포함하고, 메모리는 프로세싱 장치 상에서 실행되도록 구성된 코드를 저장하고, 코드는 프로세싱 장치 상에 있을 때, 스테이트먼트 1 내지 스테이트먼트 25 중 어느 하나의 방법을 수행하도록 구성되는, 컴퓨터 장비.

스테이트먼트 30. 컴퓨터 판독 가능 저장소 상에 구체화되고 하나 이상의 프로세서들 상에서 실행될 때 스테이트먼트 1 내지 스테이트먼트 25 중 어느 하나의 방법을 수행하도록 구성된 컴퓨터 프로그램.

스테이트먼트 31. 컴퓨터 장비로서,

하나 이상의 메모리 유닛들을 포함하는 메모리; 및

하나 이상의 프로세싱 유닛들을 포함하는 프로세싱 장치를 포함하고, 메모리는 프로세싱 장치 상에서 실행되도록 구성된 코드를 저장하고, 코드는 프로세싱 장치 상에 있을 때, 스테이트먼트 26 내지 스테이트먼트 28 중 어느 하나의 방법을 수행하도록 구성되는, 컴퓨터 장비.

스테이트먼트 32. 컴퓨터 판독 가능 저장소 상에 구체화되고 하나 이상의 프로세서들 상에서 실행될 때 스테이트먼트 26 내지 스테이트먼트 28 중 어느 하나의 방법을 수행하도록 구성된 컴퓨터 프로그램.

본원에서 개시된 또 다른 양상에 따르면, 머클 증명 엔티티 및 요청 당사자의 액션들을 포함하는 방법이 제공될 수 있다.

본원에서 개시된 또 다른 양상에 따르면, 머클 증명 엔티티 및 요청 당사자의 컴퓨터 장비를 포함하는 시스템이 제공될 수 있다.

Claims (32)

1. 블록체인 트랜잭션이 블록체인 상에 존재한다는 증명을 제공하는 컴퓨터 구현 방법으로서,
   상기 방법은 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하지만, 상기 블록체인 네트워크에 새로운 블록체인 블록들을 공개하지 않도록 구성된 머클 증명 엔티티(Merkle proof entity)에 의해 수행되고, 상기 방법은,
   타겟 블록체인 트랜잭션의 타겟 트랜잭션 식별자를 획득하는 단계 ― 상기 타겟 트랜잭션 식별자는 상기 저장된 트랜잭션 식별자들의 세트의 일부를 형성함 ― ;
   상기 타겟 블록체인 트랜잭션에 대한 타겟 머클 증명을 획득하는 단계 ― 대응하는 타겟 머클 루트는 상기 블록체인의 블록헤더 내에 포함됨 ― ; 및
   상기 타겟 블록체인 트랜잭션이 상기 블록체인 상에 존재한다는 증명으로서 요청 당사자에 의한 사용을 위해 상기 타겟 머클 증명을 출력하는 단계를 포함하는,
   컴퓨터 구현 방법.
2. 제1 항에 있어서,
   상기 머클 증명 엔티티는 전체 블록체인을 저장하지 않는,
   컴퓨터 구현 방법.
3. 제1 항 또는 제2 항에 있어서,
   상기 타겟 머클 증명을 획득하는 단계는 대응하는 타겟 머클 트리의 리프 계층(leaf layer) 내에서 상기 타겟 트랜잭션 식별자의 인덱스를 계산하는 단계를 포함하는,
   컴퓨터 구현 방법.
4. 제3 항에 있어서,
   상기 인덱스를 상기 요청 당사자에게 출력하는 단계를 포함하는,
   컴퓨터 구현 방법.
5. 전술한 청구항 중 어느 한 항에 있어서,
   상기 타겟 트랜잭션 식별자를 획득하는 단계는 상기 요청 당사자로부터 상기 타겟 트랜잭션 식별자를 획득하는 단계를 포함하는,
   컴퓨터 구현 방법.
6. 전술한 청구항 중 어느 한 항에 있어서,
   상기 타겟 트랜잭션 식별자를 획득하는 단계는 상기 타겟 블록체인 트랜잭션을 획득하는 단계 및 상기 타겟 블록체인 트랜잭션에 기초하여 상기 타겟 트랜잭션 식별자를 구성하는 단계를 포함하는,
   컴퓨터 구현 방법.
7. 전술한 청구항 중 어느 한 항에 있어서,
   상기 타겟 머클 증명을 획득하는 단계는 상기 저장된 트랜잭션 식별자들의 세트 중 하나 이상을 사용하여 상기 타겟 머클 증명을 계산하는 단계를 포함하는,
   컴퓨터 구현 방법.
8. 전술한 청구항 중 어느 한 항에 있어서,
   상기 머클 증명 엔티티는 상기 타겟 트랜잭션 식별자를 포함하는 상기 저장된 트랜잭션 식별자들의 세트 중 하나 이상에 대한 개개의 머클 증명을 저장하고, 상기 타겟 머클 증명을 획득하는 단계는 저장 위치로부터 상기 타겟 머클 증명을 추출하는 단계를 포함하는,
   컴퓨터 구현 방법.
9. 전술한 청구항 중 어느 한 항에 있어서,
   상기 타겟 머클 증명을 출력하는 단계는 상기 타겟 머클 증명을 상기 요청 당사자에게 송신하는 단계를 포함하는,
   컴퓨터 구현 방법.
10. 전술한 청구항 중 어느 한 항에 있어서,
    상기 타겟 머클 증명을 출력하는 단계는 상기 타겟 머클 증명을 공개하는 단계를 포함할 수 있는,
    컴퓨터 구현 방법.
11. 전술한 청구항 중 어느 한 항에 있어서,
    상기 머클 증명 엔티티는 하나 이상의 머클 루트들을 저장하고, 각각의 머클 루트는 상기 저장된 트랜잭션 식별자들의 세트의 개개의 서브세트에 기초하는,
    컴퓨터 구현 방법.
12. 제11 항에 있어서,
    상기 타겟 트랜잭션 식별자에 기초한 머클 루트를 상기 요청 당사자에게 출력하는 단계를 포함하는,
    컴퓨터 구현 방법.
13. 제11 항 또는 제12 항에 있어서,
    상기 머클 증명 엔티티는, 상기 하나 이상의 머클 루트들 각각에 대해, 머클 트리를 저장하는,
    컴퓨터 구현 방법.
14. 제13 항에 있어서,
    상기 타겟 머클 증명을 획득하는 단계는 상기 타겟 트랜잭션 식별자를 포함하는 저장된 머클 트리로부터 상기 타겟 머클 증명을 추출하는 단계를 포함하는,
    컴퓨터 구현 방법.
15. 전술한 청구항 중 어느 한 항에 있어서,
    상기 저장된 트랜잭션 식별자들의 세트는 상기 트랜잭션 식별자들의 복수의 서브세트들을 포함하고, 트랜잭션 식별자들의 각각의 서브세트는 상기 블록체인의 개개의 블록으로부터의 모든 트랜잭션 식별자들을 포함하는,
    컴퓨터 구현 방법.
16. 제15 항에 있어서,
    트랜잭션 식별자들의 각각의 서브세트는 상기 블록체인의 개개의 블록의 개개의 블록 헤더와 연관되어 저장되는,
    컴퓨터 구현 방법.
17. 전술한 청구항 중 어느 한 항에 있어서,
    상기 블록체인 상에 공개된 각각의 블록체인 트랜잭션의 개개의 트랜잭션 식별자를 저장하는 단계를 포함하는,
    컴퓨터 구현 방법.
18. 전술한 청구항 중 어느 한 항에 있어서,
    상기 저장된 트랜잭션 식별자들의 세트 중 적어도 일부는 하나 이상의 블록체인 노드들로부터 획득되는,
    컴퓨터 구현 방법.
19. 제16 항 또는 이에 종속하는 임의의 항에 있어서,
    상기 블록 헤더들의 적어도 일부는 하나 이상의 블록체인 노드들로부터 획득되고 그리고/또는 상기 블록 헤더들의 적어도 일부는 하나 이상의 SPV(simplified payment verification) 클라이언트 애플리케이션들로부터 획득되는,
    컴퓨터 구현 방법.
20. 제16 항 또는 이에 종속하는 임의의 항에 있어서,
    상기 머클 증명 엔티티는 상기 블록 헤더들 중 하나 이상을 저장하는 SPV 클라이언트 애플리케이션을 동작시키거나 상기 SPV 클라이언트 애플리케이션에 대한 액세스를 갖는,
    컴퓨터 구현 방법.
21. 제15 항 또는 이에 종속하는 임의의 항에 있어서,
    상기 머클 증명 엔티티는 트랜잭션 식별자들의 각각의 서브세트에 대해, 상기 개개의 블록으로부터의 제1 블록체인 트랜잭션을 저장하는,
    컴퓨터 구현 방법.
22. 제21 항에 있어서,
    상기 제1 블록체인 트랜잭션에 대한 제1 머클 증명을 획득하는 단계 ― 상기 제1 머클 증명은 상기 저장된 트랜잭션 식별자들의 세트 중 하나 이상에 기초함 ― ; 및
    상기 타겟 머클 증명의 길이가 대응하는 타겟 머클 트리의 길이와 매칭된다는 것을 검증하는데 상기 요청 당사자에 의한 사용을 위해 상기 제1 블록체인 트랜잭션 및 상기 제1 머클 증명을 출력하는 단계를 포함하는,
    컴퓨터 구현 방법.
23. 제22 항에 있어서,
    상기 제1 블록체인 트랜잭션은 생성 트랜잭션인,
    컴퓨터 구현 방법.
24. 전술한 청구항 중 어느 한 항에 있어서,
    상기 요청 당사자는 SPV(simplified payment verification) 클라이언트 애플리케이션을 동작시키는,
    컴퓨터 구현 방법.
25. 제1 항 내지 제23 항 중 어느 한 항에 있어서,
    상기 요청 당사자는 상기 타겟 블록체인 트랜잭션을 포함하는 블록체인 트랜잭션들의 세트를 저장하고 상기 타겟 머클 증명을 제2 요청 당사자에게 출력하도록 구성된 보조 머클 증명 엔티티를 포함하는,
    컴퓨터 구현 방법.
26. 블록체인 트랜잭션이 블록체인 상에 존재한다는 증명을 획득하는 컴퓨터 구현 방법으로서,
    머클 증명 엔티티는 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하고, 상기 머클 증명 엔티티는 개개의 블록체인 트랜잭션들의 트랜잭션 식별자들의 세트를 저장하지만 블록체인 네트워크에 새로운 블록체인 블록들을 공개하지 않도록 구성되며, 상기 방법은 요청 당사자에 의해 수행되고, 상기 방법은:
    타겟 블록체인 트랜잭션 및/또는 타겟 트랜잭션의 타겟 트랜잭션 식별자를 상기 머클 증명 엔티티에 전송하는 단계; 및
    상기 머클 증명 엔티티로부터, 상기 타겟 블록체인 트랜잭션에 대한 타겟 머클 증명을 획득하는 단계를 포함하고, 상기 머클 증명은 상기 저장된 트랜잭션 식별자들의 세트 중 하나 이상에 기초하는,
    컴퓨터 구현 방법.
27. 제26 항에 있어서,
    상기 타겟 블록체인 트랜잭션이 상기 블록체인에 존재한다는 증명으로서 상기 타겟 머클 증명을 제2 요청 당사자에게 전송하는 단계를 포함하는,
    컴퓨터 구현 방법.
28. 제26 항 또는 제27 항에 있어서,
    상기 타겟 블록체인 트랜잭션은 블록체인 트랜잭션들의 체인 중 가장 최근 트랜잭션이며, 상기 요청 당사자는 상기 블록체인 트랜잭션들의 체인의 각각의 트랜잭션에 대한 액세스를 갖고, 상기 타겟 머클 증명은 상기 블록체인 트랜잭션들의 체인 내 각각의 트랜잭션이 상기 블록체인 상에 존재한다는 증명인,
    컴퓨터 구현 방법.
29. 컴퓨터 장비로서,
    하나 이상의 메모리 유닛들을 포함하는 메모리; 및
    하나 이상의 프로세싱 유닛들을 포함하는 프로세싱 장치를 포함하고, 상기 메모리는 상기 프로세싱 장치 상에서 실행되도록 구성된 코드를 저장하고, 상기 코드는 상기 프로세싱 장치 상에 있을 때, 제1 항 내지 제25 항 중 어느 한 항의 방법을 수행하도록 구성되는,
    컴퓨터 장비.
30. 컴퓨터 판독 가능 저장소 상에 구체화되고 하나 이상의 프로세서들 상에서 실행될 때 제1 항 내지 제25 항 중 어느 한 항의 방법을 수행하도록 구성된 컴퓨터 프로그램.
31. 컴퓨터 장비로서,
    하나 이상의 메모리 유닛들을 포함하는 메모리; 및
    하나 이상의 프로세싱 유닛들을 포함하는 프로세싱 장치를 포함하고, 상기 메모리는 상기 프로세싱 장치 상에서 실행되도록 구성된 코드를 저장하고, 상기 코드는 상기 프로세싱 장치 상에 있을 때, 제26 항 내지 제28 항 중 어느 한 항의 방법을 수행하도록 구성되는,
    컴퓨터 장비.
32. 컴퓨터 판독 가능 저장소 상에 구체화되고 하나 이상의 프로세서들 상에서 실행될 때 제26 항 내지 제28 항 중 어느 한 항의 방법을 수행하도록 구성된 컴퓨터 프로그램.

Images