KR20230160849A - 블록체인-구현 데이터 애플리케이션에서 서명 검증을 위한 개선된 방법 및 시스템 - Google Patents

블록체인-구현 데이터 애플리케이션에서 서명 검증을 위한 개선된 방법 및 시스템 Download PDF

Info

Publication number
KR20230160849A
KR20230160849A KR1020237035074A KR20237035074A KR20230160849A KR 20230160849 A KR20230160849 A KR 20230160849A KR 1020237035074 A KR1020237035074 A KR 1020237035074A KR 20237035074 A KR20237035074 A KR 20237035074A KR 20230160849 A KR20230160849 A KR 20230160849A
Authority
KR
South Korea
Prior art keywords
transaction
blockchain
signature
data
node
Prior art date
Application number
KR1020237035074A
Other languages
English (en)
Inventor
크레이그 스티븐 라이트
잭 데이비스
Original Assignee
엔체인 라이센싱 아게
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엔체인 라이센싱 아게 filed Critical 엔체인 라이센싱 아게
Publication of KR20230160849A publication Critical patent/KR20230160849A/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/68—Special signature format, e.g. XML format

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

실시예는 데이터 지향 블록체인 애플리케이션들과 관련하여 사용하기 위한 검증 방법 및 시스템을 제공한다. 블록체인 프로토콜에서의 종래의 서명 검증과는 대조적으로, 본 명세서에 개시된 실시예는 단일 트랜잭션 내에서 제공되는 데이터만을 사용하여 해당 트랜잭션 내에서 인시츄(in-situ)로 수행된다. 따라서, 다른 트랜잭션으로부터 제공된 서명에 대한 어떠한 의존성이 없으며, 리플레이 공격과 같은 잠재적인 악용이 방지될 수 있다. 실시예에서, 이것은 잠금 스크립트가 아니라 트랜잭션의 출력에 서명을 배치함으로써 달성될 수 있다.

Description

블록체인-구현 데이터 애플리케이션에서 서명 검증을 위한 개선된 방법 및 시스템
본 개시는 보안 및 검증 방법 및 시스템에 관한 것이며, 특히 블록체인 트랜잭션과 관련하여 수행되는 보안 및 검증 동작을 위한 보안 및 검증 방법 및 시스템에 관한 것이다.
블록체인은 분산형 데이터 구조의 형태를 지칭하며, 여기에서 블록체인의 복제본이 분산형 피어-투-피어(Peer-to-Peer; P2P) 네트워크(아래에 "블록체인 네트워크"로 지칭됨)의 복수의 노드들 각각에서 유지되고 널리 공개된다. 블록체인은 데이터의 블록들의 체인을 포함하며, 각각의 블록은 하나 이상의 트랜잭션들을 포함한다. 소위 "코인베이스 트랜잭션" 이외의 각각의 트랜잭션은, 하나 이상의 코인베이스 트랜잭션으로 거슬러 올라가는 하나 이상의 블록에 걸쳐 있을 수 있는 시퀀스에서 선행 트랜잭션을 다시 가리킨다. 코인베이스 트랜잭션은 아래에 추가로 논의된다. 블록체인 네트워크에 제출된 트랜잭션은 새로운 블록에 포함된다. 새로운 블록은, 복수의 노드 각각이 "작업 증명"을 수행하기 위해 경쟁하는 것, 즉, 블록체인의 새로운 블록에 포함되기를 대기하는 정렬 및 유효성 검증된 계류중인 트랜잭션의 정의된 세트의 표현에 기초하여 암호화 퍼즐을 푸는 것을 수반하는 "채굴"로 종종 지칭되는 프로세스에 의해 생성된다. 블록체인은 일부 노드에서 프루닝될(pruned) 수 있으며, 블록의 공개는 단순한 블록 헤더의 공개를 통해 달성될 수 있다는 것이 유의되어야 한다.
블록체인의 트랜잭션은 다음의 목적: 디지털 자산(즉, 다수의 디지털 토큰)을 전달하는 것, 가상화된 원장 또는 레지스트리에서 엔트리의 세트를 정렬하는 것, 타임스탬프 엔트리를 수신 및 처리하는 것 및/또는 인덱스 포인터를 시간 정렬하는 것 중 하나 이상에 사용될 수 있다. 블록체인 위에 부가적인 기능성을 쌓기 위해 블록체인이 또한 활용될 수 있다. 예컨대, 블록체인 프로토콜들은 트랜잭션의 데이터에 대한 부가적인 사용자 데이터 또는 인덱스의 저장을 허용할 수 있다. 단일 트랜잭션 내에 저장될 수 있는 최대 데이터 용량에 대한 어떠한 미리 특정된 제한도 없고, 따라서 점점 더 복잡한 데이터가 통합될 수 있다. 예컨대, 이는 블록체인에 전자 문서를 저장하거나, 오디오 또는 비디오 데이터를 저장하는 데 사용될 수 있다.
블록체인 네트워크의 노드(종종 "채굴자"로 지칭됨)는, 나중에 더 상세히 설명될 분산형 트랜잭션 등록 및 유효성 검증 프로세스를 수행한다. 요약하면, 이러한 프로세스 동안에, 노드는 트랜잭션을 검증하고, 트랜잭션을 그들이 유효한 작업 증명 해를 식별하려고 시도하는 블록 템플릿 내에 삽입한다. 일단 유효한 해가 발견되면, 새로운 블록이 네트워크의 다른 노드에 전파되고, 따라서 각각의 노드가 새로운 블록을 블록체인 상에 레코딩하는 것을 가능하게 한다. 트랜잭션을 블록체인에 레코딩하기 위해, 사용자(예컨대, 블록체인 클라이언트 애플리케이션)는 트랜잭션을 전파될 네트워크의 노드들 중 하나로 전송한다. 트랜잭션을 수신하는 노드는, 유효성 검증된 트랜잭션을 새로운 블록 내로 통합하는 작업 증명 해를 찾기 위해 경쟁할 수 있다. 각각의 노드는 트랜잭션이 유효하기 위한 하나 이상의 조건들을 포함하는 동일한 노드 프로토콜을 시행하도록 구성된다. 유효하지 않은 트랜잭션들은 블록들 내로 전파되거나 통합되지 않을 것이다. 트랜잭션이 유효성 검증되고 그리하여 블록체인 상에서 수락된다고 가정하면, 트랜잭션(임의의 사용자 데이터를 포함함)은 이에 따라 변경 불가능한 공개 레코드로서 블록체인 네트워크의 노드들 각각에 등록 및 인덱싱된 채로 유지될 것이다.
최신 블록을 생성하기 위하여 작업 증명 퍼즐을 성공적으로 해결한 노드는 일반적으로 디지털 자산의 금액, 즉, 다수의 토큰을 분배하는 "코인베이스 트랜잭션(coinbase transaction)"이라 불리는 새로운 트랜잭션으로 보상을 받는다. 무효한 트랜잭션의 검출 및 거부는, 네트워크의 에이전트로서 역할을 하고 불법 행위(malfeasance)를 보고 및 차단하도록 장려되는 경쟁하는 노드의 동작에 의해 시행된다. 정보의 광범위한 공개는 사용자가 노드의 성능을 계속해서 감사(audit)하는 것을 허용한다. 단지 블록 헤더의 공개는 참여자가 블록체인의 진행중인 무결성을 보장하는 것을 허용한다.
"출력 기반" 모델(때때로 UTXO 기반 모델로 지칭됨)에서, 주어진 트랜잭션의 데이터 구조는 하나 이상의 입력들과 하나 이상의 출력들을 포함한다. 임의의 지출 가능한 출력은, 선행하는 시퀀스의 트랜잭션으로부터 도출 가능한 디지털 자산의 금액을 지정하는 요소를 포함한다. 지출 가능한 출력은 때때로 UTXO(unspent transaction output)로 지칭된다. 출력은 출력의 미래의 리뎀션(redemption)에 대한 조건을 지정하는 잠금 스크립트(locking script)를 더 포함할 수 있다. 잠금 스크립트는, 디지털 토큰 또는 자산을 유효성 검증하고 이전하는 데 필요한 조건의 서술적인 정의이다. (코인베이스 트랜잭션 이외의) 트랜잭션의 각각의 입력은 선행 트랜잭션에서 그러한 출력에 대한 포인터(즉, 참조)를 포함하고, 지시된 출력의 잠금 스크립트를 잠금 해제하기 위한 잠금 해제 스크립트를 더 포함할 수 있다. 따라서 한 쌍의 트랜잭션들이 고려되고, 이들을 제1 및 제2 트랜잭션(또는 "타겟" 트랜잭션)이라고 칭한다. 제1 트랜잭션은 디지털 자산의 금액을 지정하는 적어도 하나의 출력을 포함하고, 출력을 잠금 해제하는 하나 이상의 조건들을 정의하는 잠금 스크립트를 포함한다. 제2 타겟 트랜잭션은 제1 트랜잭션의 출력에 대한 포인터를 포함하는 적어도 하나의 입력, 및 제1 트랜잭션의 출력을 잠금 해제하기 위한 잠금 해제 스크립트를 포함한다.
이러한 모델에서, 제2 타겟 트랜잭션이 블록체인 네트워크로 전송되어 블록체인에 전파 및 레코딩될 때, 각 노드에서 적용되는 유효성을 위한 기준 중 하나는, 잠금 해제 스크립트가 제1 트랜잭션의 잠금 스크립트에 정의된 하나 이상의 조건들 모두를 충족시킨다는 것일 것이다. 다른 하나는, 제1 트랜잭션의 출력이 다른 이전의 유효한 트랜잭션에 의해 이미 리딤되지 않았다는 것일 것이다. 이러한 조건들 중 어느 하나에 따라 타겟 트랜잭션이 무효하다는 것을 발견한 임의의 노드는 (가능하게는 무효 트랜잭션을 등록하지만 유효 트랜잭션으로서) 이를 전파시키지 않거나, 블록체인에 레코딩할 새로운 블록에 이를 포함하지 않지 않을 것이다.
트랜잭션 모델의 대안적인 유형은 계정 기반 모델이다. 이 경우에, 각각의 트랜잭션은 과거 트랜잭션들의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하기 보다는, 절대 계정 잔액을 참조함으로써 전달될 금액을 정의한다. 모든 계정들의 현재 상태는 블록체인과 별개로 노드들에 의해 저장되며 지속적으로 업데이트된다.
위에서 언급한 바와 같이, 이러한 블록체인 모델들 및 그들의 연관된 프로토콜들은, 추가적인 기능을 제공하기 위해 복잡한 애플리케이션 및 시스템이 구축될 수 있는 기본적이고, 기초적인 플랫폼을 형성하는 데 사용될 수 있다. 결과적으로, 블록체인-구현 기술은 단순히 암호화폐의 이전을 넘어 더 넓은 범위의 기술적 혜택을 제공하는 데 사용될 수 있다. 토큰화된 자산과 같은 데이터 및 리소스의 저장 및 전송을 가능하게 하는 기초적인 메커니즘으로서 블록체인 및 그와 연관된 프로토콜을 활용하는 수많은 상위 레벨 애플리케이션이 개발되었다. 하나의 이러한 예는, 데이터를 저장, 구조화, 인덱싱 및 공유하기 위해 종래의 인터넷에 대한 블록체인-기반 대안을 제공하는 "메타넷(Metanet)"이다. 메타넷 프로토콜은 기초적인 블록체인 네트워크 및 연관된 프로토콜(https://bitcoinsv.io/wp-content/uploads/2020/10/The-Metanet-Technical-Summary-v1.0.pdf)의 상단에 자리한다.
이러한 블록체인-구현 기술은, 그들이 전송 및 프로세싱하는 데이터가 인가된 당사자에 의해서만 액세스될 수 있고, 그들이 잠재적인 보안 취약점 또는 악의적인 제3자에 의한 악용(exploit)에 대해 개방되지 않는 것을 보장할 필요가 있다. 따라서, 블록체인 상에 구축된 데이터-지향성 애플리케이션 및 시스템에 의해 활용될 수 있는 안전하고, 유연하고, 효율적인 검증 기술이 필요로 된다.
본 명세서에 개시된 일 양상에 따르면, 기초적인 블록체인 상에서 구현되는 데이터 애플리케이션에 의해 유리하게 활용될 수 있는 서명 검증 기술이 제공된다. 이러한 애플리케이션은 보통 블록체인의 트랜잭션 내에 데이터를 저장하고, 해당 데이터와 관련된 서명 검증은 데이터의 무결성을 보장하고 악용 및 인가되지 않은 활동을 방지하기 위해 필수적이다. 그러나, 기초적인 블록체인의 프로토콜에 따라 트랜잭션 레벨에서 서명 검증이 수행되지만, 데이터가 트랜잭션 내에 저장되는 방식으로 인해 그리고 기초적인 블록체인 프로토콜이 트랜잭션 외부에서 제공되는 데이터를 포함하는 서명된 메시지의 검증을 요구하기 때문에, 이 메커니즘은 때때로 데이터 애플리케이션 레벨에서 검증하기에 불충분하다. 더욱이, 블록체인 프로토콜은 전형적으로 특정 서명 방식의 사용을 요구하는데, 이는 특정 데이터-지향성 구현에서 제한적이거나 바람직하지 않을 수 있다.
본 개시의 실시예는, 데이터 애플리케이션(들)에 의해 사용되는 서명을 입력의 잠금 해제 스크립트로부터 트랜잭션의 다른 곳, 이를테면, 출력으로 재위치시키고, 비트코인 스크립팅 엔진을 사용하여, 서명이 비트코인 네트워크의 노드에 의해 유효성 검증되는 요건을 제거함으로써 적어도 이러한 기술적 난제를 극복한다. 일부 실시예에서, 서명은, 잠재적으로, OP_RETURN과 같은 스크립트의 평가를 종료시키라는 커맨드 이후에, 출력의 잠금 스크립트로 이동될 수 있다. 서명은 그가 위치된 트랜잭션을 고유하게 식별하는 데이터를 포함하는 메시지에 서명함으로써 제공될 수 있고, 따라서 서명과 트랜잭션을 결합 또는 연관시키고 잠재적인 악용의 회피를 가능하게 한다. 또한, 기초적인 블록체인 프로토콜의 서명 검증 메커니즘과 구별되는 검증 기법을 제공함으로써, 특정 서명 방식의 이용과 관련된 제약이 회피될 수 있다. 프로세싱 및 에너지 요건과 같은 채굴자의 리소스가 검증을 위해 필요하지 않기 때문에, 효율성이 또한 획득될 수 있다.
본 개시의 실시예들의 이해를 보조하기 위해 그리고 그러한 실시예들이 어떻게 실행될 수 있는지를 보여주기 위하여, 단지 예로서 첨부 도면들에 대한 참조가 이루어진다.
도 1은 블록체인을 구현하기 위한 시스템의 개략적인 블록도이다.
도 2는 블록체인에 레코딩될 수 있는 트랜잭션들의 일부 예들을 개략적으로 예시한다.
도 3a는 클라이언트 애플리케이션의 개략적인 블록도이다.
도 3b는 도 3a의 클라이언트 애플리케이션에 의해 제공될 수 있는 예시적인 사용자 인터페이스의 개략적인 실물 모형이다.
도 4는 트랜잭션을 프로세싱하기 위한 일부 노드 소프트웨어의 개략적인 블록도이다.
도 5는 각각이 데이터의 저장에 적합하고 공개 키 및 메타넷 트랜잭션 ID로 구성된 노드의 메타넷 인덱스에 의해 메타넷 프로토콜 내에서 고유하게 식별 가능한 노드들의 메타넷-구현 그래프의 간단한 예를 제공한다.
도 6은 예시적인 트랜잭션 TxID1 및 이전 트랜잭션 TxID0, 및 아래에서 논의되는 사례 1에 따라 서명 검증을 위한 메시지로서 사용되는 부분들을 도시한다.
도 7은 예시적인 트랜잭션 TxID2, 및 아래에서 논의되는 사례 2에 따라 서명 검증을 위한 메시지로서 사용되는 부분을 도시한다.
도 8은 예시적인 트랜잭션 TxID3, 및 아래에서 논의되는 사례 3에 따라 서명 검증을 위한 메시지로서 사용되는 부분을 도시한다.
예시적인 시스템 개요
도 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)의 복수의 블록체인 노드들 각각에서 유지된다. 위에서 언급된 바와 같이, 블록체인(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)의 입력은 또한 입력 인가(input authorisation), 예컨대, 선행 트랜잭션(152i)의 출력이 잠금된 사용자(103a)의 서명을 포함한다. 차례로, 현재 트랜잭션(152j)의 출력은 새로운 사용자 또는 엔티티(103b)에 대해 암호학적으로 잠금될 수 있다. 따라서 현재 트랜잭션(152j)은 선행 트랜잭션(152i)의 입력에서 정의된 금액을 현재 트랜잭션(152j)의 출력에서 정의된 바와 같은 새로운 사용자 또는 엔티티(103b)에게 전달할 수 있다. 일부 경우들에서 트랜잭션(152)은 다수의 사용자들 또는 엔티티들(이들 중 하나는 잔돈(change)을 주기 위해 오리지널 사용자(103a)일 수 있음) 사이에서 입력 금액을 분할하기 위해 다수의 출력들을 가질 수 있다. 일부 경우에서 트랜잭션은 또한 하나 이상의 선행 트랜잭션들의 다수의 출력들로부터 금액들을 수집하고 현재 트랜잭션의 하나 이상의 출력들에 재분배하기 위해 다수의 입력들을 가질 수 있다.
비트코인과 같은 출력-기반 트랜잭션 프로토콜에 따라, 당사자(103), 이를테면, 개별 사용자 또는 조직이 새로운 트랜잭션(152j)을 (수동으로 또는 당사자에 의해 채용된 자동화된 프로세스에 의해) 규정하기를 원할 때, 규정 당사자는 새로운 트랜잭션을 자신의 컴퓨터 단말(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)에서, 유효한 트랜잭션들의 정렬된 풀(154)에, 블록체인(150)에 레코딩된 블록(151)에 아직 나타나지 않은 새로운 트랜잭션들이 추가된다. 그 후, 블록체인 노드들은 암호화 퍼즐을 해결하도록 시도함으로써 트랜잭션들의 정렬된 세트(154)로부터 트랜잭션들(152)의 새로운 유효한 블록(151)을 조립하기 위해 경쟁한다. 통상적으로 이는 "논스(nonce)"가 계류중인 트랜잭션들의 정렬된 풀(154)의 표현과 연접되고(concatenated) 해싱될 때, 해시의 출력이 미리 결정된 조건을 충족시키도록 논스 값을 검색하는 것을 포함한다. 예컨대, 미리 결정된 조건은 해시의 출력이 미리 정의된 특정 수의 선행 0들을 갖는 것일 수 있다. 이것은 단지 하나의 특정 유형의 작업 증명 퍼즐이고, 다른 유형이 배제되지 않는다는 것이 유의된다. 해시 함수의 특성은 해시 함수가 그의 입력에 대해 예측 불가능한 출력을 갖는다는 것이다. 따라서, 이 검색은 무차별 대입(brute force)에 의해서만 수행될 수 있고, 이에 따라 퍼즐을 해결하고자 하는 각각의 블록체인 노드(104)에서 상당한 양의 프로세싱 리소스를 소비한다.
퍼즐을 해결하고자 하는 제1 블록체인 노드(104)는 이를 네트워크(106)에 발표하고, 그 해(solution)를 증명으로서 제공하며, 이는 그 후 네트워크의 다른 블록체인 노드(104)들에 의해 쉽게 체크될 수 있다(해시에 대한 해가 주어지면, 그 해가 해시의 출력으로 하여금 조건을 충족시키게 한다는 것을 체크하는 것은 간단함). 제1 블록체인 노드(104)는, 블록을 수락하고 따라서 프로토콜 규칙을 시행하는 임계 합의의 다른 노드에 블록을 전파시킨다. 그런 다음, 트랜잭션의 정렬된 세트(154)는 블록체인 노드(104) 각각에 의해 블록체인에 새로운 블록(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)가 노드들(104) 사이에 전파되는 경우임 ― 를 해결하기 위한 프로토콜이 또한 존재한다. 요컨대, 가장 길게 성장하는 포크의 갈래가 확정적인 블록체인(150)이 된다. 동일한 트랜잭션이 포크 둘 모두에서 나타날 것이기 때문에, 이는 네트워크의 사용자 또는 에이전트에 영향을 미치지 않아야 한다는 것이 유의된다.
비트코인 블록체인(및 대부분의 다른 블록체인)에 따라, 새로운 블록(104)을 성공적으로 구성한 노드에는, 디지털 자산의 추가적인, 수락된 금액을 새로운 특별한 종류의 트랜잭션에 새롭게 할당하는 능력이 수여되고, 트랜잭션은 (하나의 에이전트 또는 사용자에서 다른 에이전트 또는 사용자로 디지털 자산의 금액을 이전하는 에이전트간 트랜잭션 또는 사용자간 트랜잭션과 대조적으로) 디지털 자산의 추가적인 정의된 수량을 분배한다. 이 특별한 유형의 트랜잭션을 일반적으로 "코인베이스 트랜잭션"으로 지칭되지만, 또한 "개시 트랜잭션" 또는 "생성 트랜잭션"으로 칭해질 수 있다. 이것은 일반적으로 새로운 블록(151n)의 제1 트랜잭션을 형성한다. 작업 증명은, 이 특별한 트랜잭션이 나중에 리딤되는 것을 허용하는 프로토콜 규칙을 따르도록 새로운 블록을 구성하는 노드의 의도를 시그널링한다. 블록체인 프로토콜 규칙은, 이 특별 트랜잭션이 리딤되기 전에, 만기 기간, 예컨대, 100개의 블록을 요구할 수 있다. 종종 일반(비-생성) 트랜잭션(152)은 또한, 해당 트랜잭션이 공개된 블록(151n)을 생성한 블록체인 노드(104)를 추가로 보상하기 위해, 그의 출력들 중 하나에 부가적인 트랜잭션 수수료를 지정할 것이다. 이러한 수수료는 정상적으로 "트랜잭션 수수료"로 지칭되고, 아래에 논의된다.
트랜잭션 유효성 검증 및 공개에 수반되는 리소스로 인해, 통상적으로 적어도 블록체인 노드들(104) 각각은 하나 이상의 물리적 서버 유닛들, 또는 심지어 전체 데이터 센터를 포함하는 서버의 형태를 취한다. 그러나, 원칙적으로, 임의의 주어진 블록체인 노드(104)는 사용자 단말 또는 함께 네트워킹된 사용자 단말들의 그룹의 형태를 취할 수 있다.
각각의 블록체인 노드(104)의 메모리는 블록체인 노드 프로토콜에 따라 각자의 역할 또는 역할들을 수행하고 트랜잭션들(152)을 처리하기 위해 블록체인 노드(104)의 프로세싱 장치 상에서 실행되도록 구성된 소프트웨어를 저장한다. 본 명세서에서 블록체인 노드(104)에 기인한 임의의 동작은 각자의 컴퓨터 장비의 프로세싱 장치 상에서 실행되는 소프트웨어에 의해 수행될 수 있다는 것이 이해될 것이다. 노드 소프트웨어는 애플리케이션 계층, 운영 시스템 계층 또는 프로토콜 계층과 같은 하위 계층, 또는 이들의 임의의 조합에서 하나 이상의 애플리케이션들에서 구현될 수 있다.
또한 네트워크(101)에는 소비 사용자들의 역할을 하는 복수의 당사자들(103) 각각의 컴퓨터 장비(102)가 연결되어 있다. 이러한 사용자는 블록체인 네트워크(106)와 상호작용할 수 있지만, 트랜잭션 및 블록의 유효성 검증 또는 구성에 참여하지 않는다. 이러한 사용자 또는 에이전트(103) 중 일부는 트랜잭션에서 전송자 및 수신자의 역할을 할 수 있다. 다른 사용자는, 반드시 전송자 또는 수신자의 역할을 하지 않고도, 블록체인(150)과 상호작용할 수 있다. 예컨대, 일부 당사자는 블록체인(150)의 사본을 저장하는(예컨대, 블록체인 노드(104)로부터 블록체인의 사본을 획득한) 저장 엔티티의 역할을 할 수 있다.
당사자(103) 중 일부 또는 전부는 상이한 네트워크, 예컨대, 블록체인 네트워크(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)에 통합되는 것으로 설명될 수 있지만, 이것은 반드시 제한적인 것은 아니며, 대신에 본 명세서에서 설명된 임의의 클라이언트 기능은 2개 이상의 별개의 애플리케이션들이 한 조로 구현될 수 있는데, 예컨대, API를 통해 인터페이싱하거나 또는 하나가 다른 것에 플러그 인될 수 있다. 더 일반적으로, 클라이언트 기능은 애플리케이션 계층, 또는 운영 시스템과 같은 하위 계층, 또는 이들의 임의의 조합에서 구현될 수 있다. 다음은 클라이언트 애플리케이션(105)의 관점에서 설명될 것이지만, 이것이 제한적이지 않다는 것이 인지될 것이다.
각각의 컴퓨터 장비(102) 상의 클라이언트 애플리케이션 또는 소프트웨어(105)의 인스턴스는 네트워크(106)의 블록체인 노드들(104) 중 적어도 하나에 동작 가능하게 커플링된다. 이는 클라이언트(105)의 지갑 기능이 트랜잭션들(152)을 네트워크(106)로 전송하는 것을 가능하게 한다. 클라이언트(105)는 또한 개개의 당사자(103)가 수신자인 임의의 트랜잭션들에 대해 블록체인(150)에 질의하기 위해(또는 실시예들에서, 블록체인(150)은 그의 공개 가시성을 통해 부분적으로 트랜잭션들의 신뢰를 제공하는 공공 시설(public facility)이므로, 실제로 블록체인(150)에서 다른 당사자들의 트랜잭션을 검사하기 위해) 블록체인 노드들(104)에 접촉할 수 있다. 각각의 컴퓨터 장비(102) 상의 지갑 기능은 트랜잭션 프로토콜에 따라 트랜잭션들(152)을 공식화(formulate) 하고 전송하도록 구성된다. 위에서 제시된 바와 같이, 각각의 블록체인 노드(104)는 블록체인 노드 프로토콜에 따라 트랜잭션(152)을 유효성 검증하고, 그리고 트랜잭션(152)을 블록체인 네트워크(106) 전반에 걸쳐 전파시키기 위해 트랜잭션(152)을 포워딩하도록 구성된 소프트웨어를 실행한다. 트랜잭션 프로토콜 및 노드 프로토콜은 서로 대응하며, 주어진 트랜잭션 프로토콜은 주어진 트랜잭션 모델을 함께 구현하도록 주어진 노드 프로토콜을 따른다. 블록체인(150)의 모든 트랜잭션(152)에 동일한 트랜잭션 프로토콜이 사용된다. 네트워크(106)의 모든 노드들(104)에 의해 동일한 트랜잭션 프로토콜이 사용된다.
주어진 당사자(103), 이를테면, 앨리스가 블록체인(150)에 포함될 새로운 트랜잭션(152j)을 전송하기를 원할 때, 그녀는 (자신의 클라이언트 애플리케이션(105)의 지갑 기능을 사용하여) 관련 트랜잭션 프로토콜에 따라 새로운 트랜잭션을 공식화한다. 그 후, 그녀는 클라이언트 애플리케이션(105)으로부터 그녀가 연결되는 하나 이상의 블록체인 노드들(104)에 트랜잭션(152)을 전송한다. 예컨대, 이는 앨리스의 컴퓨터(102)에 가장 잘 연결된 블록체인 노드(104)일 수 있다. 임의의 주어진 블록체인 노드(104)가 새로운 트랜잭션(152j)을 수신할 때, 주어진 노드는 블록체인 노드 프로토콜 및 각자의 역할에 따라 이를 처리한다. 이는 새롭게 수신된 트랜잭션(152j)이 "유효"하기 위한 특정 조건을 충족시키는지를 먼저 체크하는 것을 포함하며, 그의 예들은 곧 보다 자세히 논의될 것이다. 일부 트랜잭션 프로토콜들에서, 유효성 검증을 위한 조건은 트랜잭션들(152)에 포함된 스크립트들에 의해 트랜잭션 단위로 구성 가능할 수 있다. 대안적으로, 조건은 단순히 노드 프로토콜의 내장 피처이거나, 스크립트 및 노드 프로토콜의 조합으로 정의될 수 있다.
새롭게 수신된 트랜잭션(152j)이 유효한 것으로 간주되기 때문에 테스트를 통과한다는 것을 조건으로(즉, 그것이 "유효성 검증"된다는 조건으로), 트랜잭션(152j)을 수신하는 임의의 블록체인 노드(104)는 새로운 유효성 검증된 트랜잭션(152)을 해당 블록체인 노드(104)에서 유지되는 트랜잭션의 정렬된 세트(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)은 "Tx1"로서 라벨이 지정된다. 이는 시퀀스의 선행 트랜잭션(152i)의 출력(203)에서 앨리스에게 잠금된 디지털 자산의 금액을 취하고, 이 중 적어도 일부를 밥에게 전달한다. 선행 트랜잭션(152i)은 도 2에서 "Tx0"로 라벨링된다. Tx0 및 Tx1은 임의의 라벨일 뿐이다. 이들은, Tx0이 블록체인(151)의 최초 트랜잭션이거나, Tx1이 풀(154)에서 바로 다음 트랜잭션이라는 것을 반드시 의미하지는 않는다. Tx1은 앨리스에게 잠금된 미지출 출력(203)을 여전히 갖는 임의의 선행(즉, 앞선) 트랜잭션을 뒤로 가리킬 수 있다.
선행 트랜잭션 Tx0은 앨리스가 자신의 새로운 트랜잭션 Tx1을 생성할 때, 또는 적어도 그녀가 그것을 네트워크(106)에 전송할 때까지 이미 유효성 검증되고 블록체인(150)의 블록(151)에 포함되었을 수 있다. 이는 그 시간에 이미 블록들(151) 중 하나에 포함되었거나, 정렬된 세트(154)에서 여전히 대기 중일 수 있으며, 이 경우에 곧 새로운 블록(151)에 포함될 것이다. 대안적으로 Tx0 및 Tx1이 생성되고 네트워크(106)에 함께 전송될 수 있거나 또는 노드 프로토콜이 "고아" 트랜잭션들을 버퍼링하도록 허용하는 경우 Tx0은 Tx1 이후에도 전송될 수 있다. 트랜잭션들의 시퀀스의 맥락에서 본 명세서에서 사용된 바와 같은 "선행" 및 "후속"이라는 용어들은 (트랜잭션이 다른 트랜잭션을 뒤로 가리키고, 이와 같이 계속되는) 트랜잭션들에서 지정된 트랜잭션 포인터들에 의해 정의된 바와 같은 시퀀스에서의 트랜잭션들의 순서를 지칭한다. 이들은 "선행자(predecessor)" 및 "후행자(successor)", 또는 "앞선(antecedent)"과 "후위의(descendant)", "부모" 및 "자식" 등으로 동등하게 대체될 수 있다. 이는 그것들이 생성되고, 네트워크(106)로 전송되거나, 임의의 주어진 블록체인 노드(104)에 도달하는 순서를 반드시 의미하지는 않는다. 그럼에도 불구하고, 선행 트랜잭션(앞선 트랜잭션 또는 "부모")을 가리키는 후속 트랜잭션(후위의 트랜잭션 또는 "자식")은 부모 트랜잭션이 유효성 검증될 때까지 그리고 유효성 검증되지 않는 한 유효성 검증되지 않을 것이다. 그의 부모 이전에 블록체인 노드(104)에 도달하는 자식은 고아로 간주된다. 이는 노드 프로토콜 및/또는 노드 거동에 의존하여 부모를 대기하기 위해 특정 시간 동안 버퍼링되거나 폐기될 수 있다.
선행 트랜잭션(Tx0)의 하나 이상의 출력들(203) 중 하나는, 본 명세서에서 UTXO0으로서 라벨이 지정되는 특정 UTXO를 포함한다. 각각의 UTXO는 UTXO에 의해 표현되는 디지털 자산의 금액을 지정하는 값 및 후속 트랜잭션이 유효성 검증되고 따라서 UTXO가 성공적으로 리딤되기 위하여 후속 트랜잭션의 입력(202)에서 잠금 해제 스크립트에 의해 만족되어야 하는 조건을 정의하는 잠금 스크립트를 포함한다. 통상적으로, 잠금 스크립트는 특정 당사자(그것이 포함된 트랜잭션의 수혜자)에게로 금액을 잠근다. 즉, 잠금 스크립트는, 통상적으로 후속 트랜잭션의 입력의 잠금 해제 스크립트가 선행 트랜잭션이 잠겨 있는 당사자의 암호화 서명을 포함하는 조건을 포함하는 잠금 해제 조건을 정의한다.
잠금 스크립트(일명 scriptPubKey)는 노드 프로토콜에 의해 인식되는 도메인 특정 언어로 작성된 코드 조각이다. 이러한 언어의 특정 예는, 블록체인 네트워크에 의해 사용되는 "스크립트(Script)"(대문자 S)라 불린다. 잠금 스크립트는 트랜잭션 출력(203)을 지출하는 데 어떤 정보가 필요한지, 예컨대, 앨리스의 서명 요건을 지정한다. 잠금 해제 스크립트들은 트랜잭션들의 출력에서 나타난다. 잠금 해제 스크립트(일명 scriptSig)는 잠금 스크립트 기준들을 충족시키는 데 필요한 정보를 제공하는 도메인 특정 언어로 작성된 코드 조각이다. 예컨대, 이는 밥의 서명을 포함할 수 있다. 잠금 해제 스크립트들은 트랜잭션들의 입력(202)에 나타난다.
따라서, 예시된 예에서, Tx0의 출력(203)의 UTXO0은 UTXO0가 리딤되기 위해(엄밀히, UTXO0을 리딤하고자 시도하는 후속 트랜잭션이 유효하기 위해) 앨리스의 서명 Sig PA를 요구하는 잠금 스크립트 [Checksig PA]를 포함한다. [Checksig PA]는 앨리스의 공개-개인 키 쌍으로부터의 공개 키 PA의 표현(즉, 해시)을 포함한다. Tx1의 입력(202)은 (예컨대, 실시예에서, 전체 트랜잭션 Tx0의 해시인 그의 트랜잭션 ID인 TxID0에 의해) Tx1을 뒤로 가리키는 포인터를 포함한다. Tx1의 입력(202)은 Tx0 내에서 UTXO0을 식별하는 인덱스를 포함하여 Tx0의 임의의 다른 가능한 출력들 사이에서 그것을 식별한다. Tx1의 입력(202)은 앨리스의 암호화 서명을 포함하는 잠금 해제 스크립트 <Sig PA>를 더 포함하며, 이는 앨리스가 키 쌍으로부터 자신의 개인 키를 데이터의 미리 정의된 부분(때로는 암호화에서 "메시지"라 불림)에 적용함으로써 생성된다. 유효한 서명을 제공하기 위해 앨리스에 의해 서명될 필요가 있는 데이터(또는 "메시지")는 잠금 스크립트, 노드 프로토콜 또는 이들의 조합에 의해 정의될 수 있다.
새로운 트랜잭션 Tx1이 블록체인 노드(104)에 도달할 때, 노드는 노드 프로토콜을 적용한다. 이는 잠금 해제 스크립트가 잠금 스크립트에 정의된 조건(이 조건은 하나 이상의 기준들을 포함할 수 있음)을 충족시키는지를 체크하기 위해 잠금 스크립트 및 잠금 해제 스크립트를 함께 실행하는 것을 포함한다. 실시예들에서, 이는 2개의 스크립트들을 연결하는 것을 수반한다.
<Sig PA> < PA> || [Checksig PA]
여기에서 "||"는 연결을 표현하고 "<...>"는 스택 상에 데이터를 배치하는 것을 의미하고, "[…]"는 잠금 스크립트(이 예에서, 스택-기반 언어)에 의해 구성된 함수이다. 동등하게, 스크립트들을 연결하는 대신, 스크립트들은 공통 스택을 사용하여 차례로 실행될 수 있다. 어느 쪽이든, 함께 실행될 때, 스크립트들은 Tx0의 출력의 잠금 스크립트에 포함된 바와 같은 앨리스의 공개 키 PA를 사용하여, Tx1의 입력의 잠금 해제 스크립트가 데이터의 예상되는 부분에 서명하는 앨리스의 서명을 포함한다는 것을 인증한다. 이 인증을 수행하기 위하여 데이터의 예상되는 부분 자체("메시지")가 또한 포함될 필요가 있다. 실시예들에서, 서명된 데이터는 Tx1 전체를 포함한다(이에 따라, 평문으로 데이터의 서명된 부분을 지정하는 별개의 요소가 포함될 필요가 없는데, 그 이유는 이것이 이미 본질적으로 존재하기 때문임).
공개-개인 암호화에 의한 인증의 세부사항들은 당업자에게 친숙할 것이다. 기본적으로, 앨리스가 자신의 개인 키를 사용하여 메시지에 서명한 경우, 앨리스의 공개 키 및 평문의 메시지를 감안하여, 노드(104)와 같은 다른 엔티티는 메시지가 앨리스에 의해 서명된 것임이 틀림없다는 것을 인증할 수 있다. 서명은 통상적으로 메시지를 해싱하는 것, 해시에 서명하는 것, 그리고 이를 서명으로서 메시지에 태깅하고, 이에 따라 공개 키의 임의의 보유자(holder)가 서명을 인증하는 것을 가능하게 하는 것을 포함한다. 특정 데이터 조각 또는 트랜잭션의 부분에 서명한다는 본 명세서에서의 임의의 참조는 실시예들에서 해당 데이터의 조각 또는 트랜잭션의 부분의 해시를 서명하는 것을 의미한다는 것이 유의된다.
Tx1의 잠금 해제 스크립트가 Tx0의 잠금 스크립트에 지정된 하나 이상의 조건들을 충족시키는 경우(이에 따라, 도시된 예에서, 앨리스의 서명이 Tx1에서 제공되고 인증된 경우), 블록체인 노드(104)는 Tx1이 유효한 것으로 간주한다. 이것은, 블록체인 노드(104)가 Tx1을 계류중인 트랜잭션의 정렬된 풀(154)에 추가할 것이라는 것을 의미한다. 블록체인 노드(104)는 또한 트랜잭션 Tx1이 네트워크 전반에 걸쳐 전파되도록, 해당 트랜잭션을 네트워크(106)의 하나 이상의 다른 블록체인 노드(104)로 포워딩할 것이다. Tx1이 유효성 검증되고 블록체인(150)에 포함되면, 이는 지출된 것으로 Tx0으로부터 UTXO0를 정의한다. Tx1은 그것이 미지출 트랜잭션 출력(203)을 지출하는 경우에만 유효할 수 있다는 것에 주의한다. 다른 트랜잭션(152)에 의해 이미 지출된 출력을 지출하려고 시도하는 경우, 다른 모든 조건들이 충족되는 경우에서조차도 Tx1은 유효하지 않을 것이다. 따라서, 블록체인 노드(104)는 또한 선행 트랜잭션 Tx0에서 참조된 UTXO가 이미 지출되었는지(즉, 다른 유효한 트랜잭션에 대한 유효한 입력을 이미 형성했는지)를 체크할 필요가 있다. 이는 트랜잭션들(152) 상에 정의된 순서를 부과하는 것이 블록체인(150)에 대해 중요한 하나의 이유이다. 실제로, 주어진 블록체인 노드(104)는 트랜잭션들(152)이 지출된 UTXO들(203)을 마킹하는 별개의 데이터베이스를 유지할 수 있지만, 궁극적으로 UTXO가 지출되었는지를 정의하는 것은 블록체인(150)의 다른 유효한 트랜잭션에 대한 유효한 입력이 이미 형성되었는지의 여부이다.
또한, 주어진 트랜잭션(152)의 모든 출력들(203)에서 지정된 총 금액이 모든 그의 입력들(202)에 의해 가리켜지는 총 금액보다 큰 경우, 이는 대부분의 트랜잭션 모델들에서 무효에 대한 다른 근거이다. 따라서, 이러한 트랜잭션들은 블록들(151)에 포함되거나 전파되지 않을 것이다.
UTXO-기반 트랜잭션 모델에서, 주어진 UTXO는 전체로서 지출될 필요가 있다는 것에 주의한다. 다른 프랙션(fraction)이 지출되면서, 지출된 것으로 UTXO에서 정의된 금액의 프랙션이 "남겨둘" 수는 없다. 그러나 UTXO로부터의 금액은 다음 트랜잭션의 다수의 출력들 사이에서 분할될 수 있다. 예컨대, Tx0의 UTXO0에 정의된 금액은 Tx1의 다수의 UTXO들 사이에서 분할될 수 있다. 따라서 앨리스가 UTXO0에 정의된 모든 금액을 밥에게 주기를 원하지 않는 경우, 앨리스는 Tx1의 제2 출력에서 자신에게 잔돈을 주거나, 다른 당사자에게 지불하는 데 나머지를 사용할 수 있다.
실제로, 앨리스는 또한 보통, 그녀의 트랜잭션(104)을 블록(151)에 성공적으로 포함하는 비트코인 노드(104)에 대한 수수료를 포함할 필요가 있을 것이다. 앨리스가 그러한 수수료를 포함하지 않는 경우, Tx0은 블록체인 노드들(104)에 의해 거부될 수 있고, 따라서 기술적으로 유효하더라도, 전파되어 블록체인(150)에 포함되지 않을 수 있다(노드 프로토콜은 블록체인 노드들(104)이 원하지 않는 경우 이들에게 트랜잭션들(152)을 수락하도록 강요하지 않음). 일부 프로토콜들에서, 트랜잭션 수수료는 자체의 별개의 출력(203)을 요구하지 않는다(즉, 별개의 UTXO가 필요하지 않음). 대신, 주어진 트랜잭션(152)의 입력(들)(202)에 의해 가리켜지는 총 금액과 출력(들)(203)에 지정된 총 금액 사이의 임의의 차이가 트랜잭션을 공개한 블록체인 노드(104)에 자동으로 주어진다. 예컨대, UTXO0에 대한 포인터가 Tx1에 대한 유일한 입력이고 Tx1은 단 하나의 출력 UTXO1만을 갖는다고 하자. UTXO0에 지정된 디지털 자산의 금액이 UTXO1에 지정된 금액보다 큰 경우, 차이는 UTXO1을 포함하는 블록을 생성하기 위해 작업 증명 경쟁을 승리한 노드(104)에 의해 할당될 수 있다. 그러나, 대안적으로 또는 부가적으로, 트랜잭션 수수료가 트랜잭션(152)의 UTXO들(203) 중 자체 UTXO에서 명시적으로 지정될 수 있다는 것이 반드시 배제되는 것은 아니다.
앨리스 및 밥의 디지털 자산들은 블록체인(150)의 임의의 위치의 임의의 트랜잭션들(152)에서 그들에게 잠금된 UTXO로 구성된다. 따라서 통상적으로, 주어진 당사자(103)의 자산들은 블록체인(150) 전반에 걸친 다양한 트랜잭션들(152)의 UTXO들에 걸쳐 흩어져 있다. 블록체인(150)의 어떤 위치에도 주어진 당사자(103)의 총 잔액을 정의하는 숫자는 전혀 없다. 클라이언트 애플리케이션(105)에서 지갑 기능의 역할은, 개개의 당사자에게 잠겨 있으며 다른 전방 트랜잭션에서 아직 지출되지 않은 모든 다양한 UTXO들의 값들을 함께 대조하는 것이다. 지갑 기능은, 블록체인(150)의 사본이 비트코인 노드(104) 중 임의의 것에 저장된 것인지에 대해 질의함으로써 이를 행할 수 있다.
스크립트 코드는 종종 개략적으로(즉, 정확한 언어가 아님) 표현된다는 것이 유의된다. 예컨대, 특정 기능을 표현하기 위해 연산 코드(operation code)(작업코드(opcode))가 사용될 수 있다. "OP_..."는 스크립트 언어의 특정 작업코드를 지칭한다. 예로서, OP_RETURN은, 잠금 스크립트의 시작에서 OP_FALSE가 선행할 때, 트랜잭션 내에 데이터를 저장하고 그리하여 데이터를 블록체인(150)에 변경 불가능하게 레코딩할 수 있는 트랜잭션의 지출 불가능한 출력을 생성하는 스크립트 언어의 작업코드이다. 예컨대, 데이터는 블록체인에 저장하고자 하는 문서를 포함할 수 있다.
전형적으로, 트랜잭션의 입력은 공개 키 PA에 대응하는 디지털 서명을 포함한다. 실시예들에서, 이는 타원 곡선 secp256k1을 사용하는 ECDSA에 기초한다. 디지털 서명은 특정 데이터 조각에 서명한다. 일부 실시예들에서, 주어진 트랜잭션에 대해, 서명은 트랜잭션 입력의 일부, 및 트랜잭션 출력의 전부 또는 일부에 서명할 것이다. 서명되는 출력들의 특정 부분들은 SIGHASH 플래그에 의존한다. SIGHASH 플래그는 보통, 어느 출력들이 서명되는지를 선택하기 위해 서명의 끝에 포함된 4-바이트 코드이다(이에 따라, 서명 시에 고정됨).
잠금 스크립트는 때로는, 그것이 전형적으로 개개의 트랜잭션이 잠겨 있는 당사자의 공개 키를 포함한다는 사실을 지칭하는 "scriptPubKey"라 칭해진다. 잠금 해제 스크립트는 때로는, 그것이 전형적으로 대응하는 서명을 제공한다는 사실을 지칭하는 "scriptSig"라 칭해진다. 그러나, 보다 일반적으로, UTXO가 리딤되기 위한 조건이 서명을 인증하는 것을 포함하는 것이 블록체인(150)의 모든 애플리케이션들에서 필수적인 것은 아니다. 보다 일반적으로 스크립팅 언어는 임의의 하나 이상의 조건들을 정의하는 데 사용될 수 있다. 따라서 보다 일반적인 용어들 "잠금 스크립트" 및 "잠금 해제 스크립트"가 선호될 수 있다.
사이드 채널
도 1에 도시된 바와 같이, 앨리스 및 밥의 컴퓨터 장비(102a, 120b) 각각 상의 클라이언트 애플리케이션은 각각 부가적인 통신 기능성을 포함할 수 있다. 이러한 부가적인 기능성은 (어느 한 당사자 또는 제3자의 주도로) 앨리스(103a)가 밥(103b)과 별개의 사이드 채널(107)을 설정하는 것을 가능하게 한다. 사이드 채널(107)은 블록체인 네트워크와 별개로 데이터 교환을 가능하게 한다. 이러한 통신을 때로는 "오프-체인(off-chain)" 통신으로서 지칭된다. 예컨대, 이는 당사자들 중 하나가 블록체인 네트워크(106)로 브로드캐스팅하기로 선택할 때까지, (아직) 트랜잭션이 블록체인 네트워크(106) 상에 등록되거나 체인(150)으로 진행됨 없이 앨리스와 밥 사이에서 트랜잭션(152)을 교환하는 데 사용될 수 있다. 이러한 방식으로 트랜잭션을 공유하는 것은 때때로 “트랜잭션 템플릿"을 공유하는 것으로 지칭된다. 트랜잭션 템플릿에는, 완전한 트랜잭션을 형성하기 위해 요구된 하나 이상의 입력 및/또는 출력이 없을 수 있다. 대안적으로 또는 부가적으로, 사이드 채널(107)은 키들, 협상된 금액들 또는 조건들(terms), 데이터 콘텐츠 등과 같은 임의의 다른 트랜잭션 관련 데이터를 교환하는 데 사용될 수 있다.
사이드 채널(107)은 블록체인 네트워크(106)와 동일한 패킷 교환 네트워크(101)를 통해 설정될 수 있다. 대안적으로 또는 부가적으로, 사이드 채널(301)은 상이한 네트워크 이를테면, 모바일 셀룰러 네트워크, 또는 로컬 영역 네트워크 이를테면, 로컬 무선 네트워크, 또는 심지어, 앨리스 및 밥의 디바이스들(102a, 102b) 사이의 직접 유선 또는 무선 링크를 통해 설정될 수 있다. 일반적으로, 본 명세서의 임의의 위치에서 지칭되는 바와 같은 사이드 채널(107)은 "오프-체인", 즉, 블록체인 네트워크(106)와 별개로 데이터를 교환하기 위한 하나 이상의 네트워킹 기술들 또는 통신 매체들을 통한 임의의 하나 이상의 링크들을 포함할 수 있다. 하나 초과의 링크가 사용되는 경우, 오프-체인 링크들의 번들(bundle) 또는 모음은 전체적으로 사이드 채널(107)로서 지칭될 수 있다. 따라서 앨리스 및 밥이 사이드 채널(107)을 통해 특정 정보 조각들 또는 데이터 등을 교환한다고 하면, 이는 이러한 모든 데이터 조각들이 정확히 동일한 링크 또는 심지어 동일한 유형의 네트워크를 통해 전송되어야 한다는 것을 반드시 의미하는 것은 아니란 것에 주의한다.
클라이언트 소프트웨어
도 3a는 현재 개시된 방식의 실시예를 구현하기 위한 클라이언트 애플리케이션(105)의 예시적인 구현을 도시한다. 클라이언트 애플리케이션(105)은 트랜잭션 엔진(401) 및 사용자 인터페이스(UI) 계층(402)을 포함한다. 트랜잭션 엔진(401)은, 위에서 논의되고 곧 더 상세히 논의되는 방식에 따라, 클라이언트(105)의 기본 트랜잭션 관련 기능을 구현하고, 이를테면, 트랜잭션(152)을 공식화하고, 사이드 채널(301)을 통해 트랜잭션 및/또는 다른 데이터를 수신 및/또는 전송하고, 그리고/또는 블록체인 네트워크(106)를 통해 전파되도록 트랜잭션을 하나 이상의 노드(104)에 전송하도록 구성된다. 본 명세서에 개시된 실시예에 따라, 각각의 클라이언트(105)의 트랜잭션 엔진(401)은 기능(403) 등을 포함한다.
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 요소를 포함할 수 있다는 것이 인지될 것이다.
노드 소프트웨어
도 4는 UTXO-기반 또는 출력-기반 모델의 예에서 네트워크(106)의 각각의 블록체인 노드(104) 상에서 실행되는 노드 소프트웨어(450)의 예를 예시한다. 다른 엔티티는, 네트워크(106) 상의 노드(104)로서 분류되지 않고서, 즉, 노드(104)의 요구된 동작을 수행하지 않고서, 노드 소프트웨어(450)를 실행할 수 있다는 것이 유의된다. 노드 소프트웨어(450)는 프로토콜 엔진(451), 스크립트 엔진(452), 스택(453), 애플리케이션-레벨 결정 엔진(454), 및 일 세트의 하나 이상의 블록체인-관련 기능 모듈들(455)을 포함할 수 있지만 이에 제한되지 않는다. 각각의 노드(104)는, 합의 모듈(455C)(예컨대, 작업 증명), 전파 모듈(455P) 및 저장 모듈(예컨대, 데이터베이스) 중 3개 모두를 포함하지만 이에 제한되지 않는 노드 소프트웨어를 실행할 수 있다. 프로토콜 엔진(401)은 전형적으로 트랜잭션(152)의 상이한 필드들을 인식하고 이들을 노드 프로토콜에 따라 프로세싱하도록 구성된다. 다른 선행 트랜잭션(152i)(Txm-1)의 출력(예컨대, UTXO)을 가리키는 입력을 갖는 트랜잭션(152j)(Txj)이 수신될 때, 프로토콜 엔진(451)은 Txj의 잠금 해제 스크립트를 식별하고 이를 스크립트 엔진(452)에 전달한다. 프로토콜 엔진(451)은 또한 Txj의 입력의 포인터에 기초하여 Txi를 식별 및 리트리브(retrieve)한다. Txi는 블록체인(150) 상에서 공개될 수 있고, 이 경우에, 프로토콜 엔진은 노드(104)에 저장된 블록체인(150)의 블록(151)의 사본으로부터 Txi를 리트리브할 수 있다. 대안적으로, Txi는 아직 블록체인(150) 상에서 공개되지 않았을 수 있다. 이 경우에, 프로토콜 엔진(451)은 노드(104)에 의해 유지되는 미공개 트랜잭션의 정렬된 세트(154)로부터 Txi를 리트리브할 수 있다. 어느 쪽이든, 스크립트 엔진(451)은 Txi의 참조된 출력에서 잠금 스크립트를 식별하고, 이를 스크립트 엔진(452)으로 전달한다.
따라서, 스크립트 엔진(452)은 Txj의 대응하는 입력으로부터의 잠금 해제 스크립트 및 Txi의 잠금 스크립트를 갖는다. 예컨대, Tx0 및 Tx1로 라벨링된 트랜잭션이 도 2에 예시되지만, 동일한 것이 트랜잭션들의 임의의 쌍에 동일하게 적용될 수 있다. 스크립트 엔진(452)은 이전에 논의된 바와 같이 2개의 스크립트들을 함께 실행하며, 이는 사용되고 있는 스택-기반 스크립팅 언어(예컨대, Script)에 따라 스택(453) 상에 데이터를 배치하고 스택(403)으로부터 데이터를 리트리브하는 것을 포함할 것이다.
스크립트들을 함께 실행함으로써, 스크립트 엔진(452)은 잠금 해제 스크립트가 잠금 스크립트에 정의된 하나 이상의 기준들을 충족시키는지 여부 ― 즉, 잠금 스크립트가 포함되는 출력을 잠금 해제 스크립트가 "잠금 해제"하는가? 를 결정한다. 스크립트 엔진(452)은 이 결정의 결과를 프로토콜 엔진(451)에 반환한다. 잠금 해제 스크립트가 대응하는 잠금 스크립트에 지정된 하나 이상의 기준들을 충족시키는 것으로 스크립트 엔진(452)이 결정하는 경우, 결과 "진실"이 반환된다. 그렇지 않으면, 결과 "거짓"이 반환된다.
출력-기반 모델에서, 스크립트 엔진(452)으로부터의 결과 "진실"은 트랜잭션의 유효함을 위한 조건들 중 하나이다. 통상적으로 또한 충족되어야 하는, 프로토콜 엔진(451)에 의해 평가되는 하나 이상의 추가의 프로토콜-레벨 조건들; 이를테면, Txj의 출력(들)에 지정된 디지털 자산의 총 금액이 그의 입력에 의해 가리켜지는 총 금액을 초과하지 않는 것, 그리고 Txi의 가리켜진 출력이 다른 유효한 트랜잭션에 의해 이미 지출되지 않았을 것이 존재한다. 프로토콜 엔진(451)은 하나 이상의 프로토콜-레벨 조건들과 함께 스크립트 엔진(452)으로부터의 결과를 평가하고, 이들이 모두 진실인 경우에만, 트랜잭션 Txj을 유효성 검증한다. 프로토콜 엔진(451)은 트랜잭션이 유효한지에 관한 표시를 애플리케이션-레벨 결정 엔진(454)에 출력한다. Txj이 실제로 유효성 검증된다는 조건에서만, 결정 엔진(454)은 Txj에 대해 그들 개개의 블록체인-관련 기능을 수행하도록 합의 모듈(455C) 및 전파 모듈(455P) 둘 모두를 제어하기로 선택할 수 있다. 이것은 합의 모듈(455C)이 블록(151)에 통합하기 위해 노드의 트랜잭션의 개개의 정렬된 세트(154)에 Txj를 추가하는 것, 및 전파 모듈(455P)이 Txj를 네트워크(106)의 다른 블록체인 노드(104)에 포워딩하는 것을 포함한다. 선택적으로, 실시예들에서, 애플리케이션 결정 엔진(454)은, 이러한 기능들 중 어느 하나 또는 둘 모두를 트리거하기 전에 하나 이상의 부가적인 조건들을 적용할 수 있다. 예컨대, 결정 엔진은, 트랜잭션 모두가 유효하고 트랜잭션 수수료가 충분하다는 조건 하에서만 트랜잭션을 공개하기로 선택할 수 있다.
또한, 본 명세서에서 "진실" 및 "거짓"이라는 용어들은 단지 단일 이진 숫자(비트)의 형태로 표현되는 결과를 반환하는 것으로 반드시 제한되지는 않지만, 이는 확실히 하나의 가능한 구현이라는 것이 유의된다. 보다 일반적으로, "진실"은 성공 또는 긍정적인 결과를 표시하는 임의의 상태를 지칭할 수 있고 "거짓"은 실패 또는 비-긍정적인 결과를 표시하는 임의의 상태를 지칭할 수 있다. 예컨대, 계정-기반 모델에서, "진실"의 결과는 서명의 암시적인 프로토콜 레벨의 유효성 검증 및 스마트 계약의 부가적인 긍정적인 출력의 조합에 의해 표시될 수 있다(개별 결과들 둘 모두가 진실인 경우, 전체 결과가 진실임을 시그널링하는 것으로 간주됨).
특정 공개 자료(DISCLOSURE SPECIFIC MATERIAL)
위에서 설명된 바와 같이, 각각의 블록체인 노드(즉, "채굴자")에 의해 구현된 프로토콜은, 새로운 트랜잭션(152j)에서 공급된 암호 서명이 이전 트랜잭션(152i)에서 특정되고 그에 의해 요구되는 서명과 매칭한다는 것을 노드(104)가 체크할 것을 요구한다. 출력 기반 트랜잭션 프로토콜에서. 서명 요건은 이전 트랜잭션의 출력의 잠금 스크립트에 제공되고, 그 요건을 충족하는 서명은 새로운 트랜잭션의 입력의 잠금 해제 스크립트에 제공된다. 따라서, 블록체인 네트워크의 합의 메커니즘(consensus mechanism)을 구성하는 채굴 노드(104)는 검증 서비스를 수행하고, 다음 트랜잭션의 입력 내의 서명이 특정된 요건을 충족시키지 않으면 출력을 잠금 해제하려는 어떠한 시도도 거부한다. 따라서, 종래의 검증 프로세스는, 검증 프로세스에 3개의 입력들: 메시지, 개인 키를 사용하여 생성된 서명, 및 대응하는 공개 키가 필요하기 때문에, 2개의 상이한 트랜잭션에 의해 개별적으로 제공되는 데이터(메시지)를 수반한다. 다시 말해서, 채굴자-유효성 검증된 서명에 사용되는 메시지는 별개의 트랜잭션에 걸쳐 분할된다/분할될 수 있다. 그래서, 출력이 잠금될 때, 공개 키, 및 대응하는 개인 키를 사용하여 만들어진 서명을 포함하는 잠금 스크립트가 생성된다. 서명을 생성하기 위해 서명된 데이터의 일부는 잠금된 출력을 포함하는 전체 트랜잭션 데이터의 해시 또는 그의 일부 중 어느 하나이다. 후자의 경우, 1-바이트 SIGHASH 플래그는, 개인 키에 의해 서명된 해시에 트랜잭션 데이터의 어떤 부분이 포함되는지를 나타내기 위해 서명에 첨부된다.
비트코인의 SIGHASH 알고리즘은 트랜잭션을 메시지라고 알려진 청크로 세그먼트화("직렬화"라고 알려짐)함으로써 이를 달성한다. 이러한 메시지는 ECDSA 서명을 사용하여 서명되고, 잠금 해제 스크립트에 포함된다.
SIGHASH 알고리즘의 주요 특징은, 특정 트랜잭션 입력에 서명하기 위한 직렬화된 메시지를 생성할 때, 메시지가 통상적으로 해당 입력에서 소비되는 이전 아웃포인트 및 이전 잠금 스크립트를 포함한다는 것이다. 이것은, 서명을 해당 특정 트랜잭션에 관련시키고 따라서 서명이 상이한 트랜잭션 내에서 복사 및 사용되는 것을 방지하기 때문에 중요하다.
결과적으로, 서명될 직렬화된 메시지는 전형적으로 이전 잠금 스크립트에 명시적으로 의존한다. 결정적으로, 이러한 이전 잠금 스크립트가 실제로 이전의 트랜잭션의 일부였다는 것을 보장하는 것이 필요하다. 이것은, 이전 잠금 스크립트가 실제로, 이중 해시가 TxIDPrev를 생성하는 원시 트랜잭션 TxPrev의 일부였음을 검증함으로써 달성될 수 있다.
비트코인 SV에서 구현되고 괄호 안에 데이터 유형이 지정된 전체 SIGHASH 알고리즘은 다음과 같이 작성된다.
1. (4-바이트 리틀 엔디안(little endian)) 내의 nVersion
2. 모든 입력 아웃포인트의 직렬화의 SHA256d(32-바이트 해시)
● ANYONECANPAY 플래그가 설정되면, 이것은 32-바이트 0이어야 한다.
3. 모든 입력의 nSequence의 직렬화의 SHA256d(32-바이트 해시)
● ANYONECANPAY 플래그가 설정되면, 이것은 32-바이트 0이어야 한다.
4. 지출되고 있는 아웃포인트(트랜잭션 ID에 대한 32-바이트 + 인덱스에 대한 4-바이트 리틀 엔디안)
5. subScript의 바이트 단위 길이(빅 엔디안(big endian))
6. subScript(아래에 정의됨)
7. 사토시(Satoshi) 단위의 출력의 amount(8-바이트 리틀 엔디안)
8. 이러한 아웃포인트의 nSequence(4-바이트 리틀 엔디안)
9. 모든 출력 amounts 및 scriptPubKeys의 직렬화의 SHA256d. 이들은 outputs in으로부터 취해진다.
● SINGLE 플래그가 설정되고 입력 인덱스가 출력의 수보다 작은 경우, 이것은 입력과 동일한 인덱스의 scriptPubKey를 갖는 출력의 이중 SHA256이어야 한다
● NONE 플래그가 설정되면, 이것은 32-바이트 0이어야 한다.
10. 트랜잭션 T의 nLocktime(4-바이트 리틀 엔디안)
11. 서명의 sighash 유형(4-바이트 리틀 엔디안)
위의 알고리즘의 단계 6은, 이전 잠금 해제 스크립트를 사용하여 생성된 subScript 및 prevOuts에 의존한다. 이전 트랜잭션 간의 관계는 다음과 같다.
"새로운 subScript는 previousScriptPubKey로부터 생성된다. subScript는 가장 최근의 OP_CODESEPARATOR([실행 중인] OP_CHECKSIG 바로 이전 것)으로부터 시작하여 previousScriptPubKey의 끝까지 이어진다. 어떠한 OP_CODESEPARATOR도 없다면, previousScriptPubKey가 subScript가 된다" - 참조
https://wiki.bitcoinsv.io/index.php/OP_CHECKSIG
더욱이, 비트코인 위에 구축되고 비트코인 원장을 기초적인 데이터 계층으로서 사용하는 데이터-지향성 애플리케이션에서, 애플리케이션 데이터의 진본성을 검증하기 위해 (트랜잭션 또는 출력보다는) 해당 데이터에 서명을 적용할 필요가 있을 수 있다. 예컨대, 애플리케이션이 온체인으로 토지 등록을 공증하는 경우, 신뢰할 수 있는 토지 등록 기관 또는 공증인이 등록 데이터에 서명하도록 하는 것이 유리하다.
등록 데이터의 효율적인 검증을 목적으로, 공증된 데이터 및 진본성에 사용된 서명 둘 모두가 동일한 온체인 비트코인 트랜잭션에 존재하는 것이 유익할 것이다. 이것은, 사용자 또는 검증자가 하나의 비트코인 트랜잭션을 획득하고 (i) 공증된 데이터를 획득하고 그의 무결성을 체크할 뿐만 아니라 (ii) 데이터의 진본성을 체크하기 위해 데이터에 걸친 서명을 검증하는 것을 그것이 허용할 것이기 때문이다.
이상적인 경우, 비트코인을 통해 이러한 애플리케이션에서 사용되는 디지털 서명은 다음의 3개의 속성을 가져야 한다.
● 인-시츄 검증 가능(Verifiable in-situ) - 서명은 그들을 포함한 트랜잭션으로부터 취해진 데이터만을 사용하여 검증 가능해야 하고;
이것은 검증 프로세스를 위한 입력들을 획득하기 위해 더 적은 시간 및 더 적은 리소스가 요구되기 때문에 효율성을 제공함
● 유연한 서명 알고리즘 - 서명은 (예컨대, 양자 저항(quantum-resistance)을 돕기 위해) 애드 혹(ad hoc) 기반으로 임의의 서명 알고리즘을 사용할 수 있어야 하고;
이것은 특정 방식 또는 알고리즘을 사용하는 것에 제약되는 것이 아니라, 대신에 당면한 작업의 특정 특성 또는 요건에 맞는 기술을 사용하기로 선택할 수 있는 더 유연하고 다용도의 해결책의 이점을 제공함
및
● 재생 불가능(Non-replayable) - 서명은 하나의 비트코인 트랜잭션, 즉, 서명이 초기에 제공된 것에 대해서만 유효해야 하고;
이것은 향상된 보안의 이점을 제공하여, 재생 악용을 회피하고 서명이 다른 트랜잭션에서 재사용되지 것을 방지한다.
본 개시의 등장 이전에는, 비트코인 트랜잭션에서 서명을 사용하여 이러한 속성 중 3개 모두는 아니지만 하나 또는 둘을 이행하는 것이 가능하였다. 따라서, 본 개시의 실시예에 의해 더 다용도이고, 효율적이고 안전한 배열이 제공된다. 설명 및 대조를 목적으로, 2개의 예시적인 사례(아래의 사례 1 및 2)가 제공되고, 다음에 3개의 특성 모두를 달성하는 데 사용될 수 있는 본 개시의 바람직한 실시예(사례 3)의 예시가 이어진다.
사례 1: 스크립트 서명(스크립트)
비트코인 트랜잭션에서 데이터에 서명하는 종래의 방법은, 네트워크 상의 채굴자에 의한 트랜잭션 유효성 검증 동안 스크립트 실행에 의해 검증된 서명을 입력하는 것이다. 서명은 이전(지출되는) 트랜잭션 TxID0의 잠금 스크립트에 제공된 서명에 대한 검증을 위해 후속(소비되는) 트랜잭션 TxID1의 잠금 해제 스크립트에 배치된다.
이 전형적인 시나리오에서, 서명에 의해 서명된 메시지는 위에서 설명된 비트코인 SIGHASH 알고리즘을 사용하여 공식화되며, 서명은 DER 인코딩을 갖는 ECDSA 서명이다. 서명된 메시지는 이전 잠금 스크립트와 TxID0으로부터의 출력 값을 포함한다. 다시 말해서, 이러한 검증 동작은 이전 트랜잭션으로부터 제공된 데이터의 사용을 요구한다. 이것은 도 6에 예시되고, 도 6은 트랜잭션의 잠금 해제 스크립트에 입력 서명 Sig P0을 포함하는 TxID1이라고 불리는 예시적인 트랜잭션을 도시한다. 메시지로서 사용되고 디지털적으로 서명된 TxID0(이전 트랜잭션) 및 TxID1의 부분이 도 6에 점선 내에 도시되어 있다.
SIGHASH 플래그가 서명을 이전 트랜잭션의 일부에 서명하도록 강제한다는 것은, TxID1 내에서만 획득 가능하거나 도출 가능한 데이터를 사용함으로써 이러한 트랜잭션이 인-시츄로 검증될 수 없음을 의미한다. TxID0의 데이터의 적어도 일부가 또한 페칭(fetch)되어야 하고, 무결성 체크될 필요가 있을 수 있다. 따라서 입력 서명은 위의 속성 1을 충족시키는 것에 실패한다. 게다가, 그들은 또한, DER-인코딩된 ECDSA 서명으로 제한되는데, 그 이유는 이것이 네트워크의 채굴자에 의해 구현되는 기초적인 블록체인 프로토콜에 의해 지시되기 때문이며, 이는 그들이 속성 2에서 실패한다는 것을 의미한다.
따라서, 사례 1은, 비트코인 스크립트에서 서명이 검증되고 블록체인의 트랜잭션 유효성 검증 메커니즘이 이러한 방식으로 서명이 재생되는 것을 허용하지 않을 것이기 때문에 속성 3만을 달성한다.
사례 2: 비-스크립트 서명(데이터)
이 경우, 서명은 추가적인 데이터로서 출력에 추가된다. 사례 1과 비교하여, 이제 서명은 입력의 잠금 해제 스크립트로부터 제거되고, 출력으로 이동되었다. 서명이 출력에서 다른 데이터에 서명하지만, 서명 자체는 트랜잭션 유효성 검사 동안에 채굴자에 의해 결코 검증되지 않는다.
서명된 메시지가 전체적으로 Tx1 자체 내에 포함되고, 그 내에서 도출/획득 가능하기 때문에, 서명은 인-시츄로 검증될 수 있다. 채굴자가 서명을 체크하지 않기 때문에, 이는 또한 임의의 디지털 서명 알고리즘 및 유연한 인코딩 포맷을 사용할 수 있다.
그러나, 이러한 서명이 단순히 트랜잭션에 추가되는 데이터이기 때문에, 서명을 재생하기 위해 서명이 다른 트랜잭션에 복사 및 붙여넣기될 수 있다.
따라서 이러한 서명 유형은 속성 1과 2만을 달성한다. 이 경우를 예시하기 위해, 도 7은 출력 서명 Sig P0'을 포함하는 예시적인 트랜잭션 TxID2를 도시한다. 서명된 메시지가 점선 내에 도시된다.
사례 3: 재생 불가능한 서명(데이터)
우리는 본 개시의 실시예에 따라, "재생 불가능한 서명"으로 지칭될 수 있는 제3 경우를 제안한다.
사례 2에서와 같이, 이들은 비-스크립트 서명을 포함하고, 따라서 서명은 사례 1의 입력의 잠금 해제 스크립트로부터 제거되고 출력으로 이동되었다. 또한, 사례 3은, 서명된 메시지가 제공되는 트랜잭션에 해당 메시지를 고유하게 결부시키는 데이터의 일부를 해당 메시지가 포함하는 것을 요구한다. 실시예에서, 데이터의 일부는 트랜잭션 내에 포함된 하나 이상의 아웃포인트이다. 메시지에 고유한 트랜잭션 식별 데이터를 포함시키는 것은, 서명이 Tx1에 대해서만 검증될 수 있고, 따라서 후속 트랜잭션에서 재생될 수 없다는 것을 의미한다. 이것은 Tx1이 소비하는 각각의 아웃포인트가 Tx1에 대해 고유하기 때문이다. 따라서, 이러한 서명은 속성 3을 충족시킨다.
이러한 서명이 또한 비-스크립트 서명이므로, 그들은 또한 속성 1 및 2를 충족시킨다. 따라서, 이러한 제3 사례는 데이터 애플리케이션 레벨에서 서명 검증에 사용되는 온 체인 디지털 서명에 바람직한 3개의 속성 모두를 충족시킨다. 예시를 위해, 도 8은 출력 서명 Sig P0 "을 포함하는 예시적인 트랜잭션 TxID3을 도시한다. 서명된 메시지가 점선 내에 도시된다.
예시적인 사용 사례 - 메타넷 트랜잭션
예시 목적으로 그리고 도 5를 참조하여, 우리는 이제 특정 구현에서 사용되는 실시예를 도시하는 시나리오를 제공한다. 이 시나리오에서, 기초적인 블록체인은 비트코인 블록체인이고, 데이터-지향성 애플리케이션은, 실질적으로 WO 2020/109908에 개시된 바와 같이, 메타넷 프로토콜에 따라 형성되고, 그의 내용은 전체로 본 명세서에 통합된다. 메타넷 프로토콜에 관한 추가 정보는 https://wiki.bitcoinsv.io/index.php/The_Metanet에서 확인될 수 있다. 더 상세한 설명은 또한 아래의 "메타넷에 대한 더 상세한 사항"이란 명칭의 섹션에서 확인될 수 있다.
요약하자면, 메타넷은 데이터를 저장, 구조화, 액세스 및 인덱싱하기 위해 인터넷에 대한 블록체인-기반 대안을 제공하는 애플리케이션 계층 프로토콜이다. 데이터는, 우리가 노드로 지칭할 블록체인 상의 트랜잭션에 저장(또는 이로부터 참조)된다. 각각의 메타넷 노드는 그것이 메타넷 프로토콜에 따라 형성되었음을 나타내기 위한 플래그를 포함하고, 따라서, 메타넷-기반 구현에 의해 식별될 수 있다. 각각의 메타넷 노드는 또한 공개 키(DPK)와 트랜잭션 ID(DTxID)를 포함하고, 공개 키와 트랜잭션 ID가 기초적인 블록체인(비트코인) 프로토콜에 따라 요구되는 공개 키와 트랜잭션 ID에 더하여 그리고 이와 별개로 제공된다는 점에서 우리는 이를 "일임"으로 지칭할 것이다. 메타넷 노드의 DPK 및 DTxID는 메타넷 내에서 주어진 데이터의 일부에 대한 인덱스 또는 주소로서 기능하고, 데이터-포함 노드의 그래프형 구조를 형성하는 연관된 트랜잭션의 논리적 계층 구조의 구성을 가능하게 하기 위해 결합하여 사용될 수 있다. 이러한 그래프의 매우 간단한 예는 예시 목적으로 도 5에 도시되어 있지만, 훨씬 더 복잡한 구조가 생성될 수 있다는 것이 인지될 것이다. 그래프의 노드는 에지를 통해 상위 및 하위 계층적 레벨로 구조화된다. 부모 노드(501)로부터 자식 노드(502)(즉, 각각 하위 레벨 노드 및 상위 레벨 노드)를 생성하기 위해, 그들 사이의 에지는 부모 노드의 키로부터 도출된 유효한 서명을 사용하여 생성된다. 일부 구현에서, 자식은 하나 이상의 부모를 가질 수 있다.
그런 다음, 주어진 노드/트랜잭션의 서명 및 공개 키를 검증할 수 있는 것이 메타넷 구현(뿐만 아니라 다른 블록체인-구현 데이터 애플리케이션)에서 중요하다는 것은 명백하다. 위의 사례 1에 도시된 종래의 채굴자 기반 검증에서, 서명은 부모 노드 내의 입력의 잠금 해제 스크립트에 위치된다.
그러나, 채굴자 검증 방법을 사용하면, 이것은 이전 트랜잭션 출력의 잠금 스크립트로부터 데이터를 요구하고, 이는 검증 엔티티에서 사용할 수 없을 수도 있다. 판독기/사용자/애플리케이션이 채굴자 검증 접근법 자체를 명시적으로 수행하거나 트리거링하지 않는다면, 노드의 트랜잭션의 잠금 해제 스크립트에 무효한 서명을 삽입하는 것이 가능할 것이고, 블록체인 네트워크 상의 채굴자는 여전히 이것을 유효한 것으로 받아들일 것이다. 이것은, 잠금 해제 스크립트의 형태가 반드시 이전 잠금 해제 스크립트의 특정 형태를 암시하지는 않기 때문이다(즉, 특히 '표준' 스크립트 유형의 개념이 사용되지 않았던 BSV에서 제네시스 업그레이드 후).
따라서, 표면적으로 유효한 서명 및 공개 키인 메타넷 노드에서의 잠금 해제 스크립트는 반드시 그러한 것은 아니며, 확인을 위해 채굴자 검증 접근법을 사용하여 명시적으로 체크될 필요가 있을 것이다. 이러한 명시적 체크가 수행되지 않은 경우, 표면상의 서명(및 공개 키)은 유효하지 않거나, 서명(및 공개 키)처럼 보이도록 포맷된 임의의 데이터에 단지 랜덤일 수 있다. 결과적으로, 표면상의 메타넷 자식 노드가 블록체인 프로토콜의 구문 요건(syntactical requirement)을 확인하지만 부모로부터의 유효한 서명을 포함하지 않기 때문에, 유효한 자식 노드처럼 보이는 표면상의 메타넷 자식 노드가 생성될 수 있다. 이것은 채굴자에 의해 반드시 거부되지는 않을 것인데, 왜냐하면 유효하지 않은 서명을 포함하는 잠금 해제 스크립트가 여전히 특정 잠금 해제 스크립트(예컨대, 잠금 스크립트, OP_1 OP_DROP OP_DROP, 잠금 해제 스크립트, <Fake Signature> <Fake Public Key>)를 충족시킬 수 있기 때문이다.
따라서, UTXO 검증 레벨에서 비트코인 채굴자에 의해 수행되는 종래의 서명 검증은 이러한 애플리케이션 계층 시나리오에서 의존될 수 없다.
본 개시의 실시예는, 입력의 잠금 해제 스크립트로부터 메타넷 서명을 이동시키고 이를 트랜잭션의 다른 곳(바람직하게는 출력)에 추가하고, 따라서 채굴자에 의한 검증에 의존할 필요를 제거하고, 결국 서명 메시지에 트랜잭션 자체의 외부로부터의 데이터를 포함시킬 필요를 제거함으로써 이러한 잠재적인 악용을 극복한다. 메시지는 이제 임의의 유형의 서명 방식에 의해 서명될 수 있다. 또한, 새로운 검증 접근법은, 외부적으로 소싱된 서명에 의존하지 않고, 트랜잭션에 대해 인-시츄로(즉, 트랜잭션 자체 내에 제공된 데이터만을 자체-포함 방식으로 사용하여) 수행된다. 채굴자에 의해 구현된 기초적인 프로토콜로부터 메타넷 서명 검증을 결합 해제함으로써, 우리는 보안을 유지할 뿐만 아니라 하나의 특정된 유형의 서명 체계를 사용하는 것에 대한 제한이 제거되기 때문에 더 유연한 검증 메커니즘을 제공하는 이점을 얻는다.
이러한 실시예를 사용하여, 메타넷과 같은 데이터 애플리케이션들을 구현하는 애플리케이션들, 봇들, 오라클들 등과 같은 컴퓨터-기반 리소스들은, 잠금 해제 스크립트 외부에 제공되고 서명된 메시지가 위치되는 트랜잭션과 해당 메시지를 고유하게 연관시키는 데이터를 포함하는 해당 메시지에 기초하여 서명 검증을 수행하도록 배열될 수 있다.
이것은 블록체인에서 사용되는 종래의 채굴자-수행 서명 검증의 상당한 재배열이며, 이는, 명칭이 표시하는 바와 같이, 송신들이 정확한 수신자에게 송신되고 있다는 것을 보장하기 위해 그들 사이에 서명을 전달하는 입력에 대한 출력들을 통해 하나의 트랜잭션의 다른 트랜잭션으로의 링크 또는 체인을 요구한다. 실시예에 따르면, 별개의 트랜잭션들 사이에서 서명들의 어떠한 체인 또는 의존성도 없다.
메타넷에 대한 더 상세한 사항
데이터를 트랜잭션 내에 제공함으로써 데이터가 블록체인에 삽입될 수 있는 방법에 대해서는 위의 발명의 내용에서 설명되었다. 완전성을 위해 그리고 도 5를 참조하여, 우리는 이제 메타넷 프로토콜에 관한 더 자세한 내용을 제시하고, 메타넷 프로토콜은 인터넷에 대한 블록체인 구현 대안에서 노드의 어드레싱, 허가 및 콘텐츠 버전 제어를 허용하는 논리적 방식으로 트랜잭션을 구조화하는 데 사용될 수 있다.
본 명세서에서 설명된 구조의 목적은 다음과 같다.
(i) 데이터에 대한 검색, 식별 및 액세스를 가능하게 하도록 서로 다른 트랜잭션의 관련 콘텐츠를 연관시킴
(ii) 검색의 속도, 정확성 및 효율성 개선하기 위해, 인간이 판독 가능한 키워드 검색을 사용하는 콘텐츠의 식별을 허용함
(iii) 블록체인 내에서 서버형 구조를 구축 및 에뮬레이팅함
메타넷 접근 방식은 데이터를 지향된 그래프(DAG)로서 구조화하는 것이다. 이러한 그래프의 노드 및 에지는 다음에 대응한다.
노드 - 메타넷 프로토콜과 연관된 트랜잭션. 노드는 콘텐츠를 저장한다. ("콘텐츠" 및 "데이터"라는 용어는 본 문서에서 상호교환가능하게 사용될 수 있다.)
노드는 <Metanet Flag>가 바로 후속되는 OP_RETURN를 포함함으로써 생성된다. 각각의 노드에는 공개 키(Pnode)가 할당된다. 공개 키 및 트랜잭션 ID의 결합은 노드의 인덱스 를 고유하게 지정한다.
사용된 해시 함수(H)는, 본 발명이, 예컨대, 비트코인에 대해 SHA-256 또는 RIPEMD-160과 함께 사용되는 기초적인 블록체인 프로토콜과 일치해야 한다.
에지 - 자식 노드와 부모 노드의 연관.
에지는, 서명(Sig Pparent)이 메타넷 트랜잭션의 입력에 나타날 때 생성되고, 따라서 부모만이 에지를 생성하기 위한 허가를 제공할 수 있다. 모든 노드가 기껏해야 하나의 부모를 가질 수 있고, 부모 노드는 임의의 수의 자식을 가질 수 있다. 그래프 이론의 언어에서, 각각의 노드의 진입 차수는 기껏해야 1이고, 각각의 노드의 진출 차수는 임의적이다. 에지가 메타넷 프로토콜의 일 양상이며 그 자체가 기초적인 블록체인과 연관된 트랜잭션이 아니라는 점이 유의되어야 한다.
유효한 메타넷 노드(부모를 가짐)는 다음 형태의 트랜잭션에 의해 제공된다.
이러한 트랜잭션은 노드의 인덱스 및 그의 부모를 지정하는 데 필요한 모든 정보를 포함한다.
,
유의: 메타넷 노드는 하나 초과의 부모를 가질 수 있지만, 우리는 본 명세서에서 예시의 간단함을 위해 하나의 부모만을 수반하는 예를 사용할 것이다. 또한, 적어도 하나의 부모 노드의 서명이 요구되기 때문에, 부모만이 자식에 대한 에지를 생성할 수 있다. <TxIDparent> 필드가 없거나 유효 메타넷 트랜잭션을 가리키지 않으면, 노드는 고아(orphan)이다. 고아는 그가 도달할 수 있는 어떠한 상위 레벨 노드도 갖지 않는다. 추가적인 속성이 각각의 노드에 추가될 수 있다. 이들은 플래그, 명칭 및 키워드를 포함할 수 있다. 이것은 아래에서 논의된다.
도시된 바와 같이, 노드(트랜잭션)의 인덱스는 다음과 같이 나누어질 수 있다.
a) 노드의 주소로 해석되는 공개 키 Pnode
b) 노드의 버전으로 해석되는 트랜잭션 ID TxIDnode
이 구조화로부터 2개의 유리한 특징이 발생한다.
1. 버전 제어 - 동일한 공개 키를 가진 2개의 노드가 있다면, 작업 증명이 가장 큰 트랜잭션 ID를 가진 노드가 해당 노드의 최신 버전으로 해석된다. 노드가 다른 블록에 있는 경우, 이것은 블록 높이로 체크될 수 있다. 동일한 블록에 있는 트랜잭션의 경우, 이는 TTOR(Topological Transaction Ordering Rule)에 의해 결정된다.
2. 허가(permissioning) - 공개 키 Pnode의 소유자가 자식 노드 생성 시에 트랜잭션 입력에 서명한 경우에만, 노드의 자식이 생성될 수 있다. 따라서, Pnode는 노드의 주소를 나타낼 뿐만 아니라 자식 노드를 생성하기 위한 허가를 나타낸다. 이것은 의도적으로 표준 비트코인 트랜잭션과 유사하고, 공개 키는 주소를 나타낼 뿐만 아니라 해당 주소와 연관된 허가를 나타낸다.
부모 노드의 서명이 UXTO 잠금 해제 스크립트에 나타나기 때문에, 트랜잭션이 네트워크에 대해 수락되는 시점에서, 서명은 표준 채굴자 유효성 검증 프로세스를 통해 유효성 검증된다는 것이 유의된다. 이것은, 자식 노드를 생성하기 위한 허가가 비트코인 네트워크 자체에 의해 유효성 검증된다는 것을 의미한다.
노드와 에지 구조는, 도 5에 도시된 바와 같이, 우리가 메타넷을 그래프로 시각화하는 것을 허용한다.
따라서, 메타넷 그래프의 계층적 구조는 풍부한 도메인형 구조가 등장하는 것을 허용한다. 우리는 고아 노드를 TLD(top-level domain)로, 고아 노드의 자식을 서브-도메인으로, 손자를 서브-서브-도메인으로, 이러한 식으로 그리고 자식이 없는 노드를 엔드-포인트로 해석한다.
도메인 이름은 IDnode로 해석된다. 메타넷의 각각의 최상부 레벨 도메인은 트리로 생각될 수 있고, 루트는 고아 노드이고, 리프는 자식이 없는 노드이다. 메타넷 자체는 그래프를 형성하는 트리의 글로벌 집합이다. 메타넷 프로토콜은, 임의의 노드가 콘텐츠 데이터를 포함하는 것을 규정하지는 것이 아니라, 리프(자식이 없는) 노드가 데이터 트리 상의 지향된 경로의 끝을 나타내며, 따라서 일반적으로 콘텐츠 데이터를 저장하는 데 사용될 것이다. 그러나, 콘텐츠는 트리의 임의의 노드에 저장될 수 있다. 노드에 속성으로서 포함된 프로토콜 특정 플래그는 데이터 트리에서 노드의 역할(디스크 공간, 폴더, 파일 또는 허가 변경)을 지정하는 데 사용될 수 있다.
인터넷은 DNS(Domain Name System)를 사용하여 인간이 판독할 수 있는 이름과 IP(Internet Protocol) 주소를 연관시킨다는 것이 상기된다. DNS는 어떤 의미에서는 분권화되어 있지만, 실제로는 이는 정부나 대기업과 같은 소수의 핵심 주체에 의해 제어된다. 당신의 DNS 공급자에 의존하여, 동일한 이름이 당신을 상이한 주소로 이끌 수 있다. 이 문제는 인간이 판독 가능한 짧은 이름을 컴퓨터 생성 숫자로 매핑할 때 발생한다.
메타넷은 인간이 판독할 수 있는 최상위 도메인 이름을 루트 노드의 분산화된 인덱스 IDroot에 매핑하는 동등한 분산 시스템을 사용한다. 다시 말해서, 1-1 함수 κ는, 예컨대, 인간이 판독할 수 있는 이름을 메타넷 루트 노드 인덱스에 매핑한다.
좌측으로의 입력은 인간이 판독할 수 있는 단어인 반면, 우측 상의 출력은 해시 다이제스트이며, 이것은 전형적으로 256-비트 데이터 구조일 것이다. Pbobsblog 및 TxIDbobsblog가 또한 일반적으로 인간이 판독할 수 없다는 것이 유의된다. 표준 IP 프로토콜에서, 이것은 www.bobsblog.com로부터 네트워크 내의 대응하는 도메인의 IP 주소로의 맵일 것이다.
맵 κ는, DNS-발행 도메인 이름의 인간-판독 가능성을 복제하는 데 있어서 메타넷과 인터넷의 백워드-호환성(backwards-compatibility)을 보장하기 위한 기준(measure)으로서 해석되어야 하지만, 메타넷의 구조를 제공하는 네이밍 및 어드레싱 방식은 이 맵에 명시적으로 의존하지 않는다.
매핑 함수 κ의 가능한 기존 형태는 IPFS(Interplanetary File System) 또는 OpenNIC 서비스(https://www.openic.org)에 의해 이용되는 DNSLink 시스템을 포함한다. 이러한 매핑은 기존 TXT 레코드에 DNS의 일부로 저장될 수 있다. 이것은 IPFS의 DNSLink와 유사하고, https://docs.ipfs.io/guides/concepts/dnslink/가 참조된다. 그러나, 일반적으로 이것은 1-1인 맵을 제공하기 위해 분권화의 일부 요소를 희생시키고, https://hackernoon.com/ten-terrible-attempts-to-make-the-inter-planetary-file-system-human-friendly-e4e95df0c6fa가 참조된다.
메타넷 노드의 주소로서 사용된 공개 키는 인간이 판독할 수 있는 객체가 아니다. 이것은 인간 사용자의 검색, 참조 및 입력 활동을 오류 발생이 쉽게 만들고 느리게 할 수 있다. 그러나, 사용자가 직접 해석할 수 있는 평문 프리픽스를 포함하는 인간이 인식할 수 있는 공개 키 주소 - 배니티 주소 Pvanity - 를 생성하는 것이 가능하다. 배니티 주소는 종래 기술에 알려져 있다.
이러한 주소를 생성하는 데 있어서의 어려움은 원하는 프리픽스의 문자 길이에 의존한다. 이것은, 인간이 인식할 수 있는 배니티 주소가 중앙 발행이 아닌 소유자의 생성 노력에만 의존하는 노드 주소로서 사용될 수 있다는 것을 의미한다. 주어진 프리픽스에 대해, 서픽스에 남아있는 문자로 인해 많은 별개의 배니티 주소가 존재하고, 따라서 많은 노드 주소는 고유성을 여전히 유지하면서 공통 프리픽스를 공유할 수 있다. 바람직한 프리픽스를 갖는 배니티 주소의 예는 다음과 같다.
: bobsblogHtKNngkdXEeobR76b53LETtpyT
프리픽스: bobsblog
서픽스: HtKNngkdXEeobR76b53LETtpyT
위의 배니티 주소는 'bobsblog'라는 이름으로부터 노드 인덱스 IDbobsblog로의 맵을 체크하고, 주소에 의한 메타넷 노드의 검색 가능성을 돕는 데 사용될 수 있다. 프리픽스가 본 명세서에서 고유하지 않지만 전체 주소 자체가 고유한 엔티티라는 것이 유의된다.
IDnode를 함께 형성하는 TxID와 선택된 주소 Pvanity의 결합은 또한, 이것이 도메인 이름의 중앙 발행자(TxID는 분산화된 작업 증명에 의해 생성됨)가 없고 이름이 블록체인 자체로부터 복구가능하다는 것을 의미하므로, 유리하다. 유리하게, 인터넷 DNS 내에 존재하는 고장점이 더 이상 없다.
메타넷 도메인이 이미 허가 시스템(공개 키)을 제공하기 때문에, 소유권을 증명하기 위해 증명서를 발급할 필요가 없다. 이러한 목적을 위한 블록체인의 사용은, 예컨대, 이미 네임코인(https://namecoin.org/)에서 탐구되었다. 그러나, 본 발명에 따르면, 모든 것이 하나의 블록체인 내에서 달성되기 때문에, 이러한 기능을 위해 별개의 블록체인을 사용할 필요가 없다. 이것은 종래 기술과 비교하여 본 발명에 의해 요구되는 리소스(하드웨어, 프로세싱 리소스 및 에너지)의 양을 상당히 감소시킨다. 이는 또한 장치 및 시스템 구성요소의 배열 측면에서 완전히 상이한 아키텍처를 제공한다. 이러한 네이밍 시스템의 장점은, 사용자가 해시 다이제스트가 아닌 기억에 남는 단어(예컨대, 회사 이름)로 메타넷에서 최상위 레벨 도메인을 식별할 수 있다는 것이다. 이것은 또한 해시 다이제스트보다 키워드를 검색하는 것이 더 빠르기 때문에 도메인의 검색을 더 빠르게 만든다. 이는 또한 입력 오류를 감소시키고, 따라서 블록체인 저장 데이터에 대한 개선된 검색 도구를 제공한다.
도메인 이름으로부터 노드 인덱스로의 맵이 존재하는 경우, 인터넷에 대한 URL(Uniform Resource Locator)의 것과 유사한 리소스 로케이터를 구축하는 것이 가능하다. 이것은 메타넷 URL(MURL)이라고 불릴 수 있고 다음의 형태를 취한다.
URL의 각각의 구성요소 - 프로토콜, 도메인 이름, 경로 및 파일 - 이 MURL의 구조에 매핑되어, 객체를 사용자에게 더 직관적이게 만들고 객체가 기존의 인터넷 구조와 통합되는 것을 가능하게 한다. 이것은, 각각의 노드가 도메인 트리 내의 레벨에서 고유한 자신의 공개 키(주소)와 연관된 이름을 갖는다고 가정한다. 이러한 이름은 항상 주어진 노드에 대한 MURL의 최우측 구성요소이다. 트리의 동일한 레벨에 있는 2개의 노드가 동일한 이름을 갖는 경우, 그들은 동일한 공개 키를 가질 것이고, 그래서 최신 버전이 취해진다.
메타넷의 검색
위의 내용은, 각각의 노드가 고유한 인덱스를 가지며 그에 기인하는 이름을 가질 수 있도록 메타넷 그래프 구조의 실시예를 설명한다. 이것은 콘텐츠가 MURL을 사용하여 로케이팅되는 것을 허용한다. 또한 빠른 검색 기능을 가능하게 하기 위해, 메타넷 프로토콜은 추가적인 키워드가 노드에 기인하게 되는 것을 허용한다. 노드의 고정된 속성은 인덱스 및 부모 노드의 인덱스이고, 선택적인 속성은 이름 및 키워드이다.
노드 속성
일 예에서, 메타넷을 검색하기 위한 실용적인 방법은 먼저 블록 탐색기를 사용하여 블록체인을 대대적으로 조사(trawl)하고, 메타넷 플래그로 모든 트랜잭션을 식별하고, 그들이 유효한 메타넷 노드라는 것을 체크하고, 그렇다면 그들의 인덱스들 및 키워드를 데이터베이스 또는 다른 저장 리소스에 레코딩하는 것일 수 있다. 그런 다음, 이러한 데이터베이스는 원하는 키워드로 노드를 효율적으로 검색하는 데 사용될 수 있다. 일단 원하는 키워드를 갖는 노드(들)의 인덱스가 발견되면, 그의 콘텐츠가 블록 탐색기로부터 리트리브되어 표시될 수 있다. 또한, 메타넷은 노드 트랜잭션에 의해 저장된 콘텐츠의 해시를 추가적인 속성으로서 저장함으로써 CAN(content addressable network)를 통합할 수 있다는 것이 유의된다. 이것은 메타넷 노드가 또한 콘텐츠 해시에 의해 인덱싱되고 검색될 수 있다는 것을 의미한다.
브라우저-지갑 애플리케이션
메타넷 프로토콜에서 모든 데이터가 블록체인 자체에 직접 존재한다는 것이 상기된다. 블록체인에 저장된 메타넷 데이터에 효율적으로 액세스하고, 이를 디스플레이하고, 상호 작용할 수 있는 도구 및 애플리케이션(우리는 편의상 이를 "브라우저-지갑"으로만 지칭할 것임)이 구축될 수 있다.
브라우저-지갑은 최종 사용자가 블록체인 상의 메타넷 인프라구조와 상호작용하는 것을 허용하도록 의도된 애플리케이션이다. 이러한 애플리케이션은 트리에 임베딩된 특정 콘텐츠에 대한 메타넷 그래프의 탐색 검색을 허용해야 한다. 추가적으로, 브라우저-지갑은 콘텐츠의 리트리벌, 암호 해독, 재결합 및 캐싱(선택 사항)을 처리할 것이다. 브라우저-지갑 애플리케이션은 네이티브(또는 외부) 지갑을 지원함으로써 이러한 요소와 암호화폐 지불 메커니즘을 결합한다. 브라우저-지갑은 다음 핵심 요소를 포함할 수 있다.
블록체인 검색 엔진 - IDnode, 노드 이름, 키워드, 블록 높이 및 TxID를 포함한 다양한 인덱스로 메타데이터 노드에 질의하는 제3자 검색 엔진을 지원.
디스플레이 윈도우 - 전체 사본인 블록체인 피어가 브라우저로 반환한 콘텐츠를 언팩(unpack)하는 소프트웨어. 이것은 액세스 토큰의 암호 해독, 재결합, 캐싱 및 리뎀션을 커버한다.
암호화폐 지갑 - 블록체인의 통화에 대한 전용 키 관리. 애플리케이션에 내재되거나 외부 전자 지갑(소프트웨어 또는 하드웨어)과 통신 및 동기화할 수 있도록 인가되어야 함. 새로운 메타넷 노드 트랜잭션뿐만 아니라 표준 블록체인 트랜잭션을 기록할 수 있음. 액세스 키와 액세스 토큰의 온체인 구매를 중재할 수 있음.
암호화폐 공개 키와 메타데이터 노드 주소 둘 모두에 대해 계층적이고 결정론적인 키 관리가 활용된다.
액세스 키/토큰 지갑 - 구매한 액세스 키 또는 토큰에 대한 전용 키 관리. 암호화폐 지갑을 이용해 구매한 키 또는 토큰을 수신할 수 있지만 그들에 대한 어떠한 허가도 없음. 그들은 나중의 만료를 허용하기 위해 사용자에 대해 은닉될 수 있다. 이것은 신뢰할 수 있는 실행 환경의 사용을 통해 달성될 수 있다. 블록체인과 동기화하여 현재 블록 높이를 질의함으로써 시한부 액세스가 안전하게 될 수 있다.
메타넷 브라우저-지갑에 대한 규격에는 다음의 기능을 포함한다.
1. 계층적 키 관리 - 자금을 제어하고 메타넷 트리(그래프)를 관리하는 데 사용되는 키는 동일한 계층적 결정론적 키 인프라구조를 활용하여, 그들의 메타넷 콘텐츠에 대한 키 레코드를 유지하는 데 드는 사용자의 부담을 감소시킨다.
2. 외부 암호화폐 지갑의 지시 - 외부(애플리케이션에 대해 내재되지 않음) 지갑을 인가하고 그에 동기화하는 능력은 브라우저-지갑을 고장점으로서 제거함으로써 추가적인 보안을 허용함.
애플리케이션은 블록체인 트랜잭션을 기록하고, 키를 보관하는 외부 지갑의 서명을 요구할 수 있어서, 소프트웨어 또는 하드웨어를 분리하기 위한 이러한 책임을 위임한다.
3. 메타넷 콘텐츠의 검색 - 브라우저-지갑은, 글로벌 데이터베이스에서 메타넷 노드 트랜잭션 데이터의 크롤링(crawling), 인덱싱, 서비싱 및 랭킹을 포함할 수 있는 기능을 갖는 제3자 검색 엔진을 지원하고 질의할 수 있다. 메타넷 프로토콜 플래그를 포함하는 OP_RETURN 트랜잭션의 데이터베이스가 구축될 수 있다. BitDB 2.0 - https://bitdb.network/ 참조.
검색 엔진은, 데이터가 발견되는 것을 허용하는 노드 인덱스와 함께 브라우저-지갑을 서비싱할 수 있다.
4. 블록체인에 데이터 기록 및 판독 - 검색 엔진 및 전체 노드를 사용하여 브라우저에 콘텐츠를 서빙하는 것 외에도, 암호화폐 지갑에 대한 지원은 또한 브라우저-지갑으로부터 직접 메타넷에 콘텐츠가 기록되는 것을 허용한다.
5. 데이터의 압축 해제 및 암호 해독 - 브라우저-지갑은 암호 해독 키를 처리하고 메타넷 콘텐츠의 압축 해제를 인-시츄로 수행할 수 있다.
6. 노드 아이덴티티(IDnode)의 캐싱 - 고유한 노드 아이덴티티는 더 효율적인 룩업 및 질의를 위해 로컬로 캐싱될 수 있다.
7. 웹 서버의 우회 - 노드 인덱스가 제공되면, 브라우저-지갑은 P2P(peer-to-peer) 블록체인 네트워크의 임의의 전체 복사 멤버에게 노드에 위치된 콘텐츠를 질의할 수 있다. 메타넷은 온체인에 상주하기 때문에, 임의의 전체 복사 피어는 노드와 그의 콘텐츠의 로컬 사본을 가져야 한다.
이것은, 사용자의 브라우저-지갑이 단일 피어에만 질의하면 된다는 것을 의미하며, 이는 직접적으로 그리고 중개자 웹 서버에 대한 필요성 없이 수행될 수 있다.
도 5는 브라우저-지갑에 대한 개략도 및 그의 핵심 기능이 애플리케이션의 상이한 구성요소에 걸쳐 분할되는 방법을 도시한다.
메타넷 검색 엔진
브라우저-지갑 애플리케이션은 노드 아이덴티티(IDnode)의 발견을 위해 제3자 검색 엔진과 통신한다. 제3자는 기존 인터넷 검색 엔진의 능력을 복제하는 서비스를 제공할 수 있다. 제3자의 메타넷 검색 엔진은 메타넷 프로토콜 플래그에 의해 식별 가능한 블록체인에 채굴된 모든 메타넷 트랜잭션의 데이터베이스를 유지한다. 이러한 데이터베이스는 IDnode, 노드 이름, 키워드, TxID 및 블록 높이를 포함하는 범위 인덱스로 모든 메타 노드를 카탈로그화할 수 있다.
블록체인과 지속적으로 동기화하며 트랜잭션 데이터를 표준 데이터베이스 포맷으로 유지하는 서비스가 알려져 있다. 브라우저-지갑은 메타넷 트랜잭션을 크롤링, 인덱싱, 서비싱 및 랭킹하는 임무를 이러한 제3자에 오프로딩하고, 메타넷 그래프에 저장된 콘텐츠를 로케이팅할 때 그들의 서비스에 연결한다.
메타넷 데이터만을 전용으로 하는 데이터베이스를 구비함으로써 효율성 절감이 이루어질 수 있다. 비트 DB와 달리, 이것은 모든 트랜잭션과 연관된 데이터를 저장하지 않고 메타넷 플래그를 포함하는 트랜잭션만을 저장할 것이다. MongoDB와 같은 비관계형 데이터베이스와 같은 특정 데이터베이스는 메타넷의 그래프 구조를 저장하는 데 더 효율적일 수 있다. 이것은 더 빠른 질의, 더 적은 저장 공간, 및 메타넷 도메인 내에서 관련 콘텐츠를 더 효율적으로 연관시키는 것을 허용할 것이다. 프로세스는 다음과 같다
1. 최종 사용자는 브라우저-지갑 검색 바에 키워드를 입력한다.
2. 브라우저-지갑은 키워드 질의를 제3자 SE로 전송한다.
3. SE는 키워드의 데이터베이스에 대해 키워드를 체크하고 관련 콘텐츠를 포함하는 임의의 메타 노드에 대한 IDnode를 반환한다. 제3자는 또한, 관련 콘텐츠에 대한 제안들을 제공할 뿐만 아니라, 각각의 노드에 대한 다른 인덱스를 사용자에게 반환할 수 있다.
4. 브라우저-지갑은 노드 아이덴티티 및 그와 연관된 도메인 이름을 사용하여 MURL을 구성한다.
5. 브라우저-지갑은 블록체인의 전체 사본을 갖는 임의의 네트워크 피어로부터 특정된 노드에 속하는 콘텐츠를 요청한다.
6. 네트워크 피어는 요청된 콘텐츠로 브라우저-지갑을 서빙한다. 피어가 블록체인의 사본을 가지고 있기 때문에, 피어는 또한 콘텐츠의 사본을 가져야 하고, 그래서 하나의 요청만이 이루어지고, 이는 결코 다른 네트워크 피어로 포워딩되지 않는다.
콘텐츠 디스플레이 - 메타데이터 브라우저
브라우저-지갑 애플리케이션은, 임의의 전형적인 웹 브라우저가 제공해야 하는 것과 동일한 프런트 엔드 능력을 에뮬레이팅한다. 이러한 기능은 이에 제한되지는 않지만 다음을 포함한다.
1. 검색 - 콘텐츠를 로케이팅하기 위해 검색 엔진(SE)에 대한 액세스를 제공함.
2. 리트리벌 - 알려진 프로토콜, 예컨대, HTTP(Hypertext Transfer Protocol)를 사용하여 콘텐츠 전송을 가능하게 하기 위해 서버와 통신함.
3. 해석 - (예컨대, JavaScript의) 원시 코드의 파싱 및 실행
4. 렌더링 - 최종 사용자가 보게 될 파싱된 콘텐츠의 효율적인 디스플레이.
5. 사용자 인터페이스(UI) - 사용자 입력을 위한 동작 버튼 및 메커니즘을 포함하는, 사용자가 콘텐츠와 상호 작용하기 위한 직관적인 인터페이스를 제공함.
6. 저장소 - 인터넷 콘텐츠, 쿠키 등을 캐싱하여 콘텐츠에 대한 반복적인 액세스를 향상시키기 위한 로컬 임시 저장 능력
특정 실시예에서, 웹-브라우저로서 작동하는 것을 담당하는 브라우저-지갑 애플리케이션의 소프트웨어 구성요소는, (SE들을 사용하여) 검색 가능하고 그들의 속성을 사용하여 (피어들로부터) 리트리브 가능한 블록체인에 임베딩된 메타넷 콘텐츠에 대해 위의 기능을 수행할 수 있다.
본 발명의 특정 실시예에 따르면, 브라우저-지갑 애플리케이션의 웹-브라우저 소프트웨어 구성요소는 주어진 메타넷 콘텐츠에 대해 수행될 필요가 있는 모든 동작들을 처리할 수 있다. 일반적으로 수행될 필요가 있는 이러한 많은 동작들이 존재하지만, 우리는 적어도 다음의 것이 메타넷 프로토콜 및 인프라구조를 사용하는 애플리케이션에 의해 실행된다고 가정한다.
재결합 - 메타넷 콘텐츠가 분할되어 다수의 개별 노드 트랜잭션으로 삽입될 필요가 있는 경우, 애플리케이션은 모든 관련 노드로부터 콘텐츠를 요청하고, 원래 콘텐츠를 재구성할 것이다. 분할된 콘텐츠의 순서 및 구조는 추가적인 플래그를 사용하여 각각의 노드의 속성에 인코딩될 수 있다.
압축 해제 - 콘텐츠 데이터가 압축된 형태로 블록체인에 저장되는 경우, 이는 어떤 표준 압축 방식이 사용되었음을 브라우저-지갑에 나타내는 플래그를 포함해야 한다. 애플리케이션은 이 플래그에 따라 콘텐츠를 압축 해제할 것이다.
암호 해독 - 콘텐츠가 암호화된 경우, 플래그는 암호화 방식을 나타내는 데 사용되어야 한다. 애플리케이션은 (아래에서 논의되는 바와 같이) 키의 암호 해독 키 지갑으로부터 키를 로케이팅하고, 사용된 암호화 방식에 따라 사용을 위해 콘텐츠 데이터를 암호 해독할 것이다.
콘텐츠 데이터에 대해 이러한 동작을 수행할 때, 플래그는 주어진 동작이 수행되어야 함을 브라우저-지갑에 나타내는 데 사용될 수 있다. 이것은 임의의 다른 동작에 대해서도 일반적이고, 임의의 다른 동작에 대해 동작이 적용되는 노드의 속성의 일부로서 적절한 <operation_flag>가 포함될 수 있다.
캐싱
로컬 파일 및 쿠키의 캐싱은 전형적인 웹 브라우저의 공통적이고 중요한 기능이다. 브라우저-지갑 애플리케이션은 또한, 관심 있는 콘텐츠와 관련된 다른 노드 속성들 및 IDnode의 레코드를 선택적으로 유지하기 위해 유사한 방식으로 로컬 저장소를 사용한다. 이것은 자주 방문하는 메타넷 노드로부터의 콘텐츠의 더 효율적인 룩업 및 리트리벌을 허용한다. 메타넷은, 인터넷 데이터의 캐싱이 변경 가능하고 제공자에 의존하여 웹 브라우징 소프트웨어에 의해 변경 또는 검열될 수 있다는 인터넷 데이터의 캐싱에 내재된 문제를 해결한다. 메타넷 데이터를 캐싱할 때, 사용자는 메타넷 데이터가 블록체인 상에 원래 변경 불가능한 레코드로서 포함되었을 때와 동일한 상태임을 항상 쉽게 검증할 수 있다.
암호화폐 지갑
결정론적 키 Dk는 단일 "시드" 키로부터 초기화된 개인 키이다(Andreas M. Antonopoulos, Chapter 5 in “Mastering Bitcoin" O'Reilly 2nd Ed., 2017, pp. 93-98 참조). 시드는 마스터 키로서 작동하는 랜덤으로 생성된 수이다. 해시 함수는, 결정론적 키를 도출하기 위해 시드와 다른 데이터, 이를테면, 인덱스 번호 또는 "체인 코드"(HD Wallets - BIP-32/BIP-44 참조)를 결합하는 데 사용될 수 있다. 이러한 키는 서로 관련되어 있으며, 시드 키로 완전히 복구할 수 있다. 시드는 또한 상이한 지갑 구현들 사이에서 지갑의 쉬운 임포트/익스포트를 허용하여, 사용자가 메타넷 브라우저-지갑과 함께 외부 지갑을 사용하기를 원하는 경우 추가적인 자유도를 제공한다.
계층적인 결정론적(HD) 지갑은 결정론적 키들의 잘 알려진 도출 방법이다. HD 지갑에서, 부모 키는 자식 키의 시퀀스를 생성하고, 이는 차례로, 손자 키의 시퀀스를 도출하고, 이러한 식이다. 이 트리형 구조는 여러 키를 관리하는 강력한 메커니즘이다. 바람직한 실시예에서, HD 지갑은 메타넷 아키텍처에 통합될 수 있다.
유리하게는, 본 개시의 실시예는 통상의 웹-브라우저들의 기능과 하나 이상의 암호화폐 지갑들을 직접 병합할 수 있다. 이것은 근본적으로 메타넷이 "인터넷" 콘텐츠에 대한 지불과 최종 사용자로의 그의 전달을 결합하는 방법이다.
이를 달성하기 위해, 브라우저-지갑의 실시예는 암호화폐 지갑으로서 동작하는 전용 내장 소프트웨어 구성요소를 가질 수 있다. 이러한 지갑은 애플리케이션 자체에 내재되고, 암호화폐 개인 키를 관리하고 브라우저-지갑 자체 내에서 메타넷 콘텐츠에 대한 지불로서 트랜잭션을 인가하는 데 사용될 수 있다. 이것은, 애플리케이션의 브라우저 구성요소가 메타넷 콘텐츠를 보기 위해 - (암호 해독 키, 액세스 토큰 등을 구매함으로써) 필요한 지불을 인가하도록 지갑 구성요소에 촉구할 수 있다는 것을 의미한다. 애플리케이션은 지불을 프로세싱하기 위해 외부의 제3자를 호출할 필요가 없고, 따라서 관심 있는 메타넷 콘텐츠는 애플리케이션에 의해 소비되고 인-시츄로 지불된다.
사용자가 대신 외부 지갑(소프트웨어 또는 하드웨어) 상에서 암호화폐 개인 키를 관리하거나 유지하거나 또는 심지어 다수의 지갑을 사용하기를 원하는 경우, 동일한 장점들 및 기능성이 애플리케이션의 실시예에 의해 달성될 수 있다. 이것은 애플리케이션의 내재된 지갑 대신 수행되거나 이와 함께 수행될 수 있다. 이러한 실시예에서, 애플리케이션은 외부 지갑(들)과의 링크 또는 페어링을 확립하고, 이와 동기화하지만, 브라우저-지갑 자체에 개인 키들을 저장하지는 않는다. 대신, 브라우저 구성요소가 콘텐츠에 대한 지불이 이루어질 것을 촉구할 때, 애플리케이션은 선택한 외부 지갑으로부터 디지털 서명에 의한 인가를 요청한다. 이 인가는 사용자에 의해 이루어지며, 브라우저-지갑은 트랜잭션을 브로드캐스팅하고 지불된 콘텐츠를 볼 수 있다.
메타넷 트랜잭션의 판독 및 기록
메타넷의 본질적 장점은, 메타넷이 동일한 데이터 구조 - 블록체인 - 를 사용하여 지불과 콘텐츠 데이터 둘 모두를 레코딩한다는 것이다. 이것은 소프트웨어 지갑이 순수하게 암호화폐의 교환에 기초하는 트랜잭션을 생성하는 것 외에도 메타넷 인프라구조에 콘텐츠 데이터를 기록하는 데 사용될 수 있다는 것을 의미한다. 애플리케이션에 내장된 내재된 지갑은 전형적인 SPV(simplified payment verification) 클라이언트 - https://bitcoin.org/en/glossary/simplified-payment-verification 참조 - 보다 더 복잡한 트랜잭션을 블록체인에 기록할 수 있다. 지갑은 사용자가 블록체인에 임베딩될 콘텐츠 데이터를 자신의 컴퓨터로부터 선택함으로써 애플리케이션으로부터 바로 블록체인에 메타넷 노드 트랜잭션을 기록하기로 선택하는 것을 허용한다.
브라우저-지갑 애플리케이션이 사용자 인터페이스(UI)를 갖기 때문에, 이는 지갑 구성요소가 브라우저 구성요소 또는 사용자 컴퓨터에서 미리 구성된 콘텐츠 데이터를 포함하는 트랜잭션을 생성하고 브로드캐스팅하는 것을 허용한다. 특별히 만들어진 지갑(purpose-built wallet)이 단독으로 처리하는 데 있어서 이러한 능력은 달성하기가 훨씬 더 어려울 것이다.
액세스 키/토큰 전자 지갑
메타넷 프로토콜에 내장된 것은 ECC 키 쌍 또는 AES 대칭 키를 사용하여 콘텐츠를 암호화할 수 있는 능력 및 대응하는 암호 해독 키 또는 토큰을 구매할 수 있는 능력이라는 것이 위로부터 상기된다. 우리는 이들을 액세스 키 또는 액세스 토큰으로 지칭할 것이다. 이러한 키/토큰은 사용자에게 콘텐츠(단일 사용 또는 다중 인스턴스 사용)를 보거나 편집할 수 있는 허가를 승인하고, 사용자의 암호화폐 지갑을 제어하는 키와는 별개의 역할을 수행한다(하지만 원하는 경우 동일한 키가 양자 용도로 사용될 수 있음). 이러한 이유로, 애플리케이션의 내재된 암호화폐 지갑과는 별도로, 액세스 키와 토큰을 저장하고 관리하는 데 사용되는 새로운 지갑을 도입하는 것이 유리하다.
특정 시간 기간 후에 액세스 키/토큰이 버닝(burn)되는 것을 허용함으로써 메타넷 콘텐츠에 대한 시한부 액세스 개념이 또한 도입될 수 있다. 이것은, 액세스 키/토큰이 TEE(Trusted Execution Environment)에 저장되고 사용자에 대해 직접 액세스 불가능한 것을 요구함으로써 달성될 수 있다.
액세스 키/토큰이 '버닝'될 수 있다는 사실은 또한, 암호화폐 지갑에 키/토큰을 저장하지 않아 암호화폐 개인 키가 버닝될 위험이 없다는 것을 보장하는 동기 요인이다.
암호화폐 지갑과 유사한 방식으로, 암호 해독 키와 액세스 토큰은 결정론적으로 저장 및 관리되어 효율적인 처리와 배치를 가능하게 할 수 있다. 암호 해독 키(예컨대, ECC 개인 키)는 마스터 키에 대한 후속 추가에 의해 생성 및 복구될 수 있는 반면, 액세스 토큰은 일부 초기 토큰에 의해 시딩되는 해시 체인을 사용하여 재구성될 수 있다.
여기서 암호화폐 지갑은 다른 사용자와 거래하고, 새로운 메타넷 노드를 생성하는 데 사용되는 키 쌍에 대한 결정론적 키 생성을 처리하는 반면, 키/토큰 지갑(들)은 암호화폐 지갑에 의해 구매된 키 및 토큰을 처리한다는 것을 구별하는 것이 중요하다.
블록 높이 허가
타임록(timelock)은 블록 높이 허가를 가능하게 하기 위해 비트코인 스크립트 언어에 포함될 수 있다. op_code OP_CHECKLOCKTIMEVERIFY(CLTV)는 트랜잭션 출력(UTXO)이 지출을 위해 허가 가능한 블록 높이를 설정한다.
블록 높이 허가의 이점은 이중적이다.
1. 버전 제어 - 메타넷 프로토콜에서, 노드의 최신 버전은 가장 큰 블록 높이의 노드로부터 식별될 수 있다. 블록 높이별로 파일의 최신 버전만을 디스플레이하도록 브라우저-지갑이 설정될 수 있어서, 작업 증명 버전 제어를 허용한다.
2. 시한부 액세스 - 브라우저-지갑 애플리케이션은 사용자가 자동으로 구매한 암호 해독 키를 주기적으로 버닝할 수 있다. 이것은, 뷰어가 지불한 시간 기간 동안에만 콘텐츠 데이터에 액세스할 수 있다는 것을 보장한다. 암호 해독 키의 복제는 신뢰할 수 있는 실행 환경(TEE)에 암호 해독 키를 저장함으로써 방지될 수 있다. 또한, 아토믹 스왑(atomic swap)은 (콘텐츠 데이터의 암호 해독을 위한) 결정론적 키 Dk의 구매를 수반한다. 이 결정론적 키가 공개적으로 보이기는 하지만, TEE는 Dk와 안전하게 고립된 개인 키의 결합에 서명하는 데 사용될 수 있다.
브라우저-지갑은, 임의의 외부 클록 또는 제3자 시간 오라클에 의존하지 않고, 블록 높이를 시간에 대한 그 자체의 프록시로서 사용하기 위해 블록체인의 현재 상태와 동기화하도록 배열될 수 있다.
결론
개시된 기술들의 다른 변형들 또는 사용 사례들은 본원에서의 개시가 주어지면 당업자에게 명백해질 수 있다. 본 개시의 범위는 설명된 실시예에 의해 제한되는 것이 아니라 첨부된 청구들에 의해서만 제한된다.
예컨대, 일부 실시예는 비트코인 네트워크(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에 따른 방법에 있어서,
i) 메시지는 디지털적으로 서명되고; 그리고/또는
ii) 메시지의 적어도 일부가 암호화 또는 인코딩되고; 그리고/또는
iii) 서명이 잠금 해제 스크립트와 다른 위치에서 트랜잭션 내에서 제공되고; 그리고/또는
iv) 서명 및/또는 메시지는 트랜잭션의 출력 내에 제공되고, 바람직하게는 이는 트랜잭션의 잠금 스크립트에 제공될 수 있고; 잠금 스크립트는 트랜잭션의 출력 내에 또는 이와 연관하여 제공될 수 있다.
스테이트먼트 3. 스테이트먼트 1 내지 2에 따른 방법에 있어서,
i) 트랜잭션 식별 데이터는 트랜잭션과 고유하게 연관된 데이터의 아웃포인트 또는 다른 부분을 포함하거나 연관되고; 그리고/또는
ii) 트랜잭션 식별 데이터는 인코딩, 해싱 또는 난독화된다.
스테이트먼트 4. 임의의 선행 스테이트먼트에 따른 방법에 있어서,
i) 서명에 대한 검증 동작을 수행하는 단계; 및/또는
ii) 서명에 대한 검증 동작을 수행하기 위해 메시지 및 공개 키를 사용하는 단계를 더 포함한다.
스테이트먼트 5. 임의의 선행 스테이트먼트에 따른 방법에 있어서,
서명을 검증하기 위해 컴퓨터-기반 리소스를 사용하는 단계를 포함하고, 컴퓨터-기반 리소스는 블록체인과 연관된 기본 프로토콜에 따라 채굴 및/또는 검증 동작을 수행하도록 배열되지 않는다.
스테이트먼트 6. 임의의 선행 스테이트먼트에 따른 방법에 있어서,
암호 키를 사용하여 메시지에 디지털적으로 서명하거나 메시지를 인코딩 또는 암호화하는 단계를 더 포함한다.
스테이트먼트 7. 임의의 선행 스테이트먼트에 따른 방법에 있어서,
서명의 검증에 성공한 경우 작업을 허용하거나 메시지의 검증에 실패한 경우 작업을 금지하는 단계를 더 포함한다.
스테이트먼트 8. 임의의 선행 스테이트먼트에 따른 방법에 있어서,
블록체인 트랜잭션은 애플리케이션-레벨 프로토콜에 따라 형성된다.
스테이트먼트 9. 스테이트먼트 8에 따른 방법에 있어서, 프로토콜은:
블록체인 트랜잭션의 논리적 계층을 형성하기 위해 블록체인 트랜잭션의 연관을 가능하게 하도록 배열되고; 그리고/또는
블록체인-구현 메타넷 프로토콜이다.
스테이트먼트 10. 임의의 선행 스테이트먼트에 따른 방법에 있어서,
공개 키를 사용하여 생성된 추가 서명과의 비교 시에 서명 및 공개 키를 사용하는 단계, 또는
공개 키와 추가 공개 키를 비교함으로써 검증을 수행하는 단계를 포함한다.
스테이트먼트 11. 임의의 선행 스테이트먼트에 따른 방법에 있어서, 트랜잭션 식별 데이터는 아웃포인트를 포함한다.
스테이트먼트 12. 블록체인-구현 검증 방법으로서,
블록체인 트랜잭션을 생성 또는 제공하는 단계를 포함하고, 블록체인 트랜잭션은:
i) 메시지 - 메시지는:
트랜잭션을 고유하게 식별하기 위한 트랜잭션 식별 데이터; 및
트랜잭션으로부터 도출 가능하고 그리고/또는 획득 가능한 데이터만을 포함함 - ; 및
ii) 메시지에 관련되거나 메시지에 기초하거나 메시지를 사용하여 생성된 디지털 서명을 포함한다.
스테이트먼트 13. 스테이트먼트 12에 따른 블록체인-구현 검증 방법에 있어서,
i) 트랜잭션은 서명을 생성하는 데 사용되는 암호 키에 관련된 공개 키를 더 포함하고; 그리고/또는
ii) 트랜잭션 식별 데이터는 출력을 포함하고; 그리고/또는
iii) 서명은, 공개 키에 관련된 암호 키를 사용하여 메시지에 디지털적으로 서명함으로써 생성되고; 그리고/또는
iv) 서명은 트랜잭션과 연관된 임의의 입력 외부에 제공된다.
스테이트먼트 14. 블록체인 트랜잭션(Tx)에 제공된 디지털 서명을 검증하는 방법으로서, 블록체인 트랜잭션(Tx)은:
검증될 디지털 서명;
메시지 - 메시지는:
i) 트랜잭션을 고유하게 식별하기 위한 트랜잭션 식별 데이터를 포함하고; 그리고
ii) 트랜잭션으로부터 도출 가능하고 그리고/또는 획득 가능한 데이터만을 포함함 - ;
트랜잭션 ID(TxID);
프로토콜 플래그;
일임 공개 키(DPK); 및
일임 트랜잭션 ID(DTxID)을 포함한다.
스테이트먼트 15. 스테이트먼트 14에 따른 방법에 있어서, 트랜잭션(Tx)은:
저장된 데이터의 일부, 또는 저장된 데이터의 일부에 대한 참조를 더 포함한다.
스테이트먼트 16. 스테이트먼트 14 또는 15에 따른 방법에 있어서,
저장된 데이터의 일부 또는 저장된 데이터의 일부에 대한 참조, 프로토콜 플래그, 일임 공개 키(DPK) 및/또는 일임 트랜잭션 ID(DTxID)는 트랜잭션의 출력(UTXO) 내에, 바람직하게는 출력(UTXO)과 연관된 잠금 스크립트 내에 제공된다.
스테이트먼트 17. 스테이트먼트 14 내지 16에 따른 방법에 있어서, 저장된 데이터의 일부, 저장된 데이터의 일부에 대한 참조, 프로토콜 플래그, 일임 공개 키(DPK) 및/또는 일임 트랜잭션 ID(DTxID)는, 후속 트랜잭션에 대한 입력으로서 후속적 사용을 위해 무효로서 출력을 표시하기 위해 스크립트 작업코드에 후속되는 위치에서 트랜잭션(Tx) 내에 제공된다.
스테이트먼트 18. 스테이트먼트 14 내지 17에 따른 방법에 있어서,
트랜잭션(Tx)은 하나 이상의 속성을 더 포함하고, 바람직하게는,
하나 이상의 속성은:
i) 트랜잭션(Tx) 내에서 제공되거나 트랜잭션(Tx) 내에서 참조되는 데이터의 일부; 및/또는
ii) 트랜잭션(Tx)
과 연관된 키워드, 태그 또는 식별자를 포함한다.
스테이트먼트 19. 스테이트먼트 13 내지 17에 따른 방법에 있어서, 트랜잭션(Tx)은:
논리적 부모 트랜잭션(LPTx)과 연관된 부모 공개 키(PPK)를 더 포함하고, 논리적 부모 트랜잭션(LPTx)은 일임 트랜잭션 ID(DTxID)에 의해 식별되고, 그리고
서명은 부모 공개 키(PPK)를 사용하여 생성된다.
스테이트먼트 20. 스테이트먼트 13 내지 18에 따른 방법에 있어서,
블록체인 내에서 트랜잭션(Tx) 또는 논리적 부모 트랜잭션을 식별하기 위해 일임 공개 키(DPK) 및 트랜잭션 ID(TxID)를 사용하는 단계를 더 포함한다.
스테이트먼트 21. 스테이트먼트 14 내지 20에 따른 방법에 있어서, 프로토콜 플래그는 하나 이상의 블록체인 트랜잭션에서 데이터를 검색, 저장 및/또는 리트리브하기 위한 블록체인-기반 프로토콜과 연관되고 그리고/또는 블록체인-기반 프로토콜을 나타낸다.
스테이트먼트 22. 컴퓨터 장비로서,
하나 이상의 메모리 유닛을 포함하는 메모리; 및
하나 이상의 프로세싱 유닛을 포함하는 프로세싱 장치를 포함하고, 메모리는 프로세싱 장치에서 실행되도록 배열된 코드를 저장하고, 코드는 프로세싱 장치 상에 있을 때 스테이트먼트 1 내지 21 중 어느 하나의 방법을 수행하도록 구성된다.
스테이트먼트 23. 스테이트먼트 22에 따른 컴퓨터 장비에 있어서, 장비는:
i) 블록체인 네트워크 및/또는 블록체인-구현 시스템이거나, 블록체인 네트워크 및/또는 블록체인-구현 시스템과 상호작용하도록 배열 또는 동작하고; 그리고/또는
ii) 하드웨어 지갑을 포함한다.
스테이트먼트 24. 컴퓨터 판독 가능 저장소 상에서 구현되고, 하나 이상의 프로세서들 상에서 실행될 때, 스테이트먼트 1 내지 스테이트먼트 21 중 어느 하나의 방법을 수행하도록 구성된 컴퓨터 프로그램.
스테이트먼트 25. 스테이트먼트 1항 내지 21 중 어느 하나에 따른 블록체인-구현 방법에 있어서,
스테이트먼트 1 내지 21 중 어느 하나의 스테이트먼트를 수행하기 위해 하드웨어 및/또는 소프트웨어 구성요소를 사용 또는 제공하는 단계를 포함하고, 하드웨어 및/또는 소프트웨어 구성요소는:
암호화폐 지갑;
검색 엔진;
블록체인 탐색기; 또는
브라우저이거나 포함하고,
그리고 바람직하게는, 구성요소는 SPV(simplified payment verification) 동작을 수행하도록 동작한다.
본 명세서에 개시된 다른 양상에 따르면, 컴퓨터 구현 방법 및 대응하는 시스템이 제공될 수 있다. 이들은 (암호) 서명을 검증하기 위한 방법들/시스템들로서 설명될 수 있다. 서명은, 예컨대, 메타넷 프로토콜과 같은 블록체인-기반 프로토콜에 따라 형성된 트랜잭션(노드) 내에서 사용될 수 있다. 메타넷 프로토콜은 실질적으로 GB2007238.5 또는 WO 2020/109908 내에 개시된 바와 같을 수 있으며, 이들 둘 모두는 그 전체로 본 명세서에 통합된다. 이와 관련하여 아래에 설명되는 임의의 특징(들), 또는 본 개시의 다른 양상은 위에서 제공된 스테이트먼트 중 하나 이상에서 제시된 방법들과 결합될 수 있다.
본 개시의 이러한 양상에 따른 방법은, 블록체인을 통한 데이터의 프로세싱, 저장, 리트리브, 식별 및/또는 공유를 가능하게 하거나 제어하기 위한 방법으로서 설명될 수 있다. 추가적으로 또는 대안적으로, 방법은 상기 데이터의 식별, 리트리벌 및/또는 저장을 가능하게 하도록 (별개의/상이한) 블록체인 트랜잭션 내에 저장된 데이터를 연관시키거나 링크하기 위한 방법으로서 설명될 수 있다. 추가적으로 또는 대안적으로, 이는 암호 서명을 검증하기 위한 방법으로서 설명될 수 있다. 방법은 트랜잭션 ID(TxID)를 포함하는 적어도 하나의 블록체인 트랜잭션(Tx)을 프로세싱하는 단계를 포함할 수 있고, 적어도 하나의 블록체인 트랜잭션(Tx)은:
프로토콜 플래그;
일임 공개 키(DPK); 및
일임 트랜잭션 ID(DTxID)를 포함한다.
이러한 특징의 결합은 데이터의 일부가 블록체인 상에서 식별되는 것, 및 또한 복수의 트랜잭션에 제공될 때 서로와 링크/연관되는 것을 가능하게 한다. 이는, 데이터의 일부 간의 계층적 관계를 반영하는 그래프 또는 트리형 구조가 구조화되는 것을 가능하게 하여, 데이터의 일부의 프로세싱, 검색, 액세스, 생성 및 공유를 가능하게 한다. 본 명세서에서, "공유"는 데이터의 일부를 노드 또는 사용자에게 제공, 전송, 통신, 송신 또는 이에 대한 액세스를 제공하는 것을 포함할 수 있다.
트랜잭션 ID(TxID)는 블록체인 프로토콜 분야에서 알려진 바와 같이 트랜잭션에 대한 식별자이고, 각각의 블록체인 트랜잭션은 기초적인 블록체인 프로토콜의 일부로서 고유한 ID를 갖는다. 대조적으로, 일임 공개 키(DPK) 및/또는 일임 트랜잭션 ID(DTxID)는, 기초적인 블록체인의 프로토콜에 표시된 바와 같이, 그들이 트랜잭션의 필수 구성요소(들)라기보다는 본 발명의 일부로 제공된다는 점에서 "일임적"일 수 있다. 다시 말해서, 기초적인 블록체인, 예컨대, 비트코인의 프로토콜에 따라 트랜잭션이 유효하기 위해서는, 그들이 필요하지는 않다. 추가적으로 또는 대안적으로, 블록체인 프로토콜이 그들을 필요로 하지 않기 때문에, 그들은 본 발명의 일부로 제공되는 추가의 비필수적인 항목으로 설명될 수 있다.
바람직하게는, 프로토콜 플래그는 하나 이상의 블록체인 트랜잭션에서 데이터를 검색, 저장 및/또는 리트리브하기 위한 블록체인 기반 프로토콜과 연관되고 그리고/또는 이를 나타낸다. 프로토콜 플래그는 표시자 또는 마커일 수 있다. 이것은, 미리 결정된 프로토콜에 따라 트랜잭션이 형성되었음을 나타낼 수 있다. 이것은 기초적인 블록체인의 프로토콜이 아닌 다른 프로토콜일 수 있다. 이는 본 명세서에 설명된 임의의 실시예에 따른 검색 프로토콜(즉, 본 명세서에서 설명되는 "메타넷" 프로토콜로 지칭될 수 있는 것)일 수 있다.
"프로세싱"이라는 용어는 생성, 전송, 유효성 검증, 액세스, 검색, 공유, 블록체인 네트워크에 제출 및/또는 식별을 포함하여 트랜잭션 또는 그의 연관된 데이터에 관련된 임의의 활동을 의미하는 것으로 해석될 수 있다.
일임 트랜잭션 ID는 본 발명의 일 실시예에 따른 트랜잭션(Tx)과 연관된 식별자, 라벨, 표시자 또는 태그일 수 있다. 이러한 모든 용어를 포함하기 위해 "표시자"라는 용어가 사용된다. 당업계에 알려져 있고 숙련된 수취인이 쉽게 이해되는 바와 같이, 블록체인 상의 각각의 트랜잭션은, 전형적으로 해당 기술 분야에서 TxID로 지칭되는 식별자에 의해 고유하게 식별된다는 것이 유의되어야 한다. TxID는 기초적인 블록체인 프로토콜의 필수적이고 요구되고 비일임 부분이다. 이 비일임 TxID는 본 명세서에서 언급된 일임 트랜잭션 ID(DTxID)와 혼동되어서는 안 된다.
바람직하게는, 블록체인 트랜잭션(Tx)은 데이터의 일부 또는 데이터의 일부에 대한 참조를 더 포함한다. 데이터의 일부에 대한 참조는 데이터가 저장된 위치의 포인터, 주소 또는 다른 표시자일 수 있다. 데이터의 일부는 임의의 유형의 데이터 또는 디지털 콘텐츠, 예컨대, 컴퓨터 실행 가능 항목, 텍스트, 비디오, 이미지, 사운드 파일 등일 수 있다. 데이터의 일부는 "콘텐츠"로 지칭될 수 있다. 데이터의 일부 또는 이에 대한 참조는 프로세싱된 형태일 수 있다. 예컨대, 이는 데이터의 일부의 해시 다이제스트일 수 있다. 데이터는 블록체인에 저장되거나 블록체인에 저장되지 않을 수 있다(즉, "오프 체인"). 바람직하게는, 데이터의 일부 또는 데이터의 일부에 대한 참조, 프로토콜 플래그, 일임 공개 키(DPK) 및/또는 일임 트랜잭션 ID(DTxID)가 블록체인 트랜잭션의 출력(UTXO) 내에 제공된다. 이들 중 하나 이상이 출력(UTXO)과 연관된 잠금 스크립트 내에 제공될 수 있다.
바람직하게는, 데이터의 일부, 데이터의 일부에 대한 참조, 프로토콜 플래그, 일임 공개 키(DPK) 및/또는 일임 트랜잭션 ID(DTxID)는, 후속 트랜잭션에 대한 입력으로서 후속 사용을 위해 출력을 무효한 것으로 표시하기 위한 스크립트 또는 작업코드 다음에 오는 위치에서 트랜잭션(Tx) 내에 제공된다.
이러한 스크립트 작업코드는 비트코인 프로토콜의 하나 이상의 변형에서 OP_RETURN 작업코드일 수 있거나, 다른 블록체인 프로토콜로부터의 기능적으로 유사/동등한 작업코드일 수 있다.
바람직하게는, 트랜잭션(Tx)은 하나 이상의 속성을 더 포함한다. 이것은 데이터/콘텐츠 검색에 대한 더 상세한 접근 방식을 가능하게 한다. 속성은 또한 "값", "라벨" 또는 "태그" 또는 "식별자"로 지칭될 수 있다. 속성은 데이터의 일부를 설명하거나 주석을 달거나, 데이터의 일부와 관련된 추가적인 정보를 제공하는 데 사용될 수 있다.
바람직하게는, 하나 이상의 속성은: i) 트랜잭션(Tx) 내에서 제공되거나 트랜잭션(Tx) 내에서 참조되는 데이터의 일부; 및/또는 ii) 트랜잭션(Tx)과 연관된 키워드, 태그 또는 식별자를 포함한다.
바람직하게는, 트랜잭션(Tx)은: 일임 트랜잭션 ID(DTxID)에 의해 식별되는 논리적 부모 트랜잭션(LPTx)과 연관된 적어도 하나의 부모 공개 키(PPK); 및 적어도 하나의 부모 공개 키(PPK)를 사용하여 생성된 서명을 더 포함한다.
이것은 트랜잭션과 그들의 임베딩된 데이터 사이에서 논리적 계층이 구조화되는 것을 가능하게 한다. 자식 노드와 연관된 부모 공개키가 하나의 부모 공개 키(즉, 자식 노드는 단일 부모 노드를 가짐) 또는 하나 초과의 부모 공개키(즉, 자식 노드는 하나 초과의 부모를 가질 수 있음)가 존재할 수 있다. 따라서, 블록체인 상의 복수의 연관되거나 논리적으로 링크된 트랜잭션이 효율적으로, 안전하게 그리고 빠르게 프로세싱될 수 있다. 논리적으로 연관된 트랜잭션은 인접한 블록 높이에서 블록체인에 저장되지 않을 수 있지만, 트랜잭션은 쉽고 안전하게 식별 및/또는 액세스될 수 있다. 바람직하게는, 방법은 일임 공개 키(DPK) 및 트랜잭션 ID(TxID)를 사용하여 블록체인 내에서 트랜잭션(Tx) 또는 논리적 부모 트랜잭션(들)을 식별하는 단계를 더 포함한다.
추가적으로, 실시예는: 트랜잭션 ID를 포함하는 블록체인 트랜잭션(Tx)과 공개 키를 연관시키는 단계; 및 트랜잭션 ID 및 트랜잭션 공개 키에 기초하여 블록체인 트랜잭션(Tx)을 검색하는 단계를 포함할 수 있다. 이것은 블록체인을 통해 데이터의 저장, 검색, 식별, 통신 및/또는 액세스를 위한 개선된 솔루션을 제공할 수 있다. 이는 전자 네트워크, 구체적으로는 피어-투-피어 블록체인 네트워크를 통한 데이터 통신 및 교환을 위한 개선책을 제공할 수 있다. 본 명세서에 설명된 임의의 특징(들)은 또한 본 개시의 이러한 실시예에 따라 활용될 수 있지만(그리고 그 역도 가능함), 간결성 및 명확성을 위해 여기서 재언급되거나 재현되지 않는다. 이는 트랜잭션(Tx) 내에 제공되거나 트랜잭션(Tx)으로부터 참조된 데이터의 일부에 액세스하거나 그렇지 않으면 프로세싱하는 단계를 더 포함할 수 있다.
공개 키 및/또는 트랜잭션 ID는 본 명세서에 설명된 바와 같이 일임적일 수 있다. 트랜잭션은 트랜잭션 ID(TxID), 프로토콜 플래그, 일임 공개 키(DPK) 및 일임 트랜잭션 ID(DTxID)를 포함할 수 있다. 트랜잭션(Tx)은 데이터의 일부, 또는 데이터의 일부에 대한 참조를 더 포함할 수 있다. 데이터의 일부 또는 데이터의 일부에 대한 참조, 프로토콜 플래그, 일임 공개 키(DPK) 및/또는 일임 트랜잭션 ID(DTxID)는 출력(UTXO) 내에, 바람직하게는 출력(UTXO)과 연관된 잠금 스크립트 내에 제공될 수 있다.
데이터의 일부, 데이터의 일부에 대한 참조, 프로토콜 플래그, 일임 공개 키(DPK) 및/또는 일임 트랜잭션 ID(DTxID)는, 출력을 무효한 것으로 표시하기 위한 스크립트 또는 작업코드 다음에 오는 위치에서 트랜잭션(Tx) 내에 제공될 수 있다.
트랜잭션(Tx)은 하나 이상의 속성을 포함할 수 있다. 하나 이상의 속성은: i) 트랜잭션(Tx) 내에서 제공되거나 트랜잭션(Tx) 내에서 참조되는 데이터의 일부; 및/또는 ii) 트랜잭션(Tx)과 연관된 키워드, 태그 또는 식별자를 포함할 수 있다.
트랜잭션(Tx)은: 개개의 논리적 부모 트랜잭션(LPTx)과 연관된 적어도 하나의 부모 공개 키(PPK) - 적어도 하나의 논리적 부모 트랜잭션(LPTx)은 일임 트랜잭션 ID(DTxID)에 의해 식별됨 - ; 및 개개의 부모 공개 키(PPK)를 사용하여 생성된 서명을 포함할 수 있다.
실시예는 일임 공개 키(DPK) 및 트랜잭션 ID(TxID)를 사용하여 블록체인 내에서 트랜잭션(Tx) 또는 논리적 부모 트랜잭션(들)을 식별하는 단계를 포함할 수 있다. 이것은 검색 단계 동안에 수행될 수 있다. 프로토콜 플래그는 하나 이상의 블록체인 트랜잭션에서 데이터를 검색, 저장 및/또는 리트리브하기 위한 블록체인 기반 프로토콜과 연관되고 그리고/또는 이를 나타낼 수 있다.
추가적으로, 본 개시의 실시예는 블록체인에서 트랜잭션(TX)을 식별하기 위한 단계를 포함할 수 있고, 그 단계는, 트랜잭션(TX)과 연관된 공개 키(PK); 및 트랜잭션(TX)의 트랜잭션 ID(TXID)에 니모닉(mnemonic)을 매핑하는 단계를 포함한다.
단계들은 또한: i) 출력을 생성하기 위한 연산에 대한 연산자로서 공개 키(PK) 및 트랜잭션 ID(TXID)를 사용하고, 출력에 니모닉을 매핑하는 단계; ii) 니모닉을 매핑하기 전에 출력을 해싱하는 단계를 포함할 수 있다. 연산은 연접(concatenation) 연산일 수 있다. 공개 키(PK)는 인간이 판독할 수 있는 프리픽스를 포함할 수 있다.
추가적으로, 본 개시의 실시예(들)는 블록체인 상에서 타겟 트랜잭션을 식별하기 위한 단계를 포함할 수 있다. 이들은 타겟 트랜잭션을 식별하기 위해 검색 경로를 사용하는 것을 포함할 수 있으며, 검색 경로는:
i) 루트 트랜잭션과 연관된 공개 키(RTPK) 및 루트 트랜잭션과 연관된 ID(RTID)를 포함하는 루트 트랜잭션 인덱스(RTIndex); 및
ii) 루트 트랜잭션 및/또는 타겟 트랜잭션과 연관된 적어도 하나의 속성을 포함한다.
적어도 하나의 속성은 널(null)일 수 있다. 루트 트랜잭션 인덱스(RTIndex)는 공개 키(RTPK) 및 ID(RTID)의 함수의 해시를 포함할 수 있다. 함수는 연접일 수 있다. 속성들 중 적어도 하나는 루트 트랜잭션 또는 타겟 트랜잭션과 연관된 니모닉일 수 있다. 루트 트랜잭션 및/또는 타겟 트랜잭션은 프로토콜 플래그를 포함할 수 있다. 이는 또한: i) 블록 탐색기를 사용하여, 블록체인에서, 프로토콜 플래그를 포함하는 적어도 하나의 트랜잭션을 식별하는 단계; 및/또는 ii) 블록체인에서, 프로토콜 플래그를 포함하는 적어도 하나의 트랜잭션을 식별하고, 적어도 하나의 트랜잭션에 관련된 데이터를 오프-블록체인 리소스에 저장하는 단계를 포함할 수 있다. 바람직하게는, 적어도 하나의 트랜잭션에 관련된 데이터는: 트랜잭션과 연관된 적어도 하나의 인덱스; 트랜잭션에 링크된 다른 트랜잭션에 연관된 적어도 하나의 인덱스; 및/또는 트랜잭션과 연관된 키워드를 포함한다. 실시예(들)는 또한, 타겟 트랜잭션에 저장되거나 그로부터 참조되는 데이터의 일부에 액세스하는 것을 포함할 수 있다.
추가적으로 본 개시의 실시예는 사용자가 적어도 하나의 블록체인 트랜잭션(Tx)에 제공된 데이터의 일부를 검색, 액세스, 보기, 기록 및/또는 리트리브하는 것을 가능하게 하도록 배열된 컴퓨터 구현 시스템을 포함할 수 있고, 시스템은 적어도 하나의 트랜잭션(Tx)과 연관된 공개 키 및 트랜잭션 ID를 포함하는 트랜잭션 인덱스(TXindex)에 기초하여 적어도 하나의 트랜잭션(Tx)을 식별하도록 배열된다.
시스템은 검색 설비를 포함하고, 검색 설비는 블록체인 검색 시스템 내에 제공되거나; 또는 블록체인 검색 시스템과 인터페이스 및/또는 통신하도록 배열된다. 이는 적어도 하나의 암호화폐 지갑을 포함할 수 있다. 적어도 하나의 지갑은: 1) 계층적 결정론적 키를 생성, 저장 및/또는 프로세싱하고; 및/또는 2) 적어도 하나의 암호 키 및/또는 적어도 하나의 토큰을 신뢰할 수 있는 실행 환경에 저장하도록 배열될 수 있다. 시스템은: 데이터의 일부가 압축된 경우, 데이터의 일부를 압축해제하도록 배열된 압축해제 구성요소; 재결합 구성요소; 및/또는 데이터의 일부가 암호화된 경우, 데이터의 일부를 암호해독하도록 배열된 암호해독 구성요소를 포함할 수 있다. 시스템은 데이터의 일부를 가청 및/또는 시각적 형태로 사용자에게 제공하도록 배열된 적어도 하나의 프리젠테이션 구성요소를 포함할 수 있다. 시스템은 블록체인 상의 적어도 하나의 트랜잭션(Tx)을 식별하기 위한 검색 경로를 입력 또는 생성하기 위한 수단을 포함할 수 있고, 검색 경로는 i) 트랜잭션 인덱스(TXindex); 및 ii) 트랜잭션(Tx)과 연관된 적어도 하나의 속성을 포함한다. 속성 중 적어도 하나는 트랜잭션과 연관된 니모닉(mnemonic)이고; 그리고/또는 적어도 하나의 속성은 널일 수 있다. 시스템은 암호 키, 블록체인 트랜잭션 및/또는 디지털 서명의 프로세싱, 저장 및/또는 생성을 가능하게 하기 위해 암호화폐 지갑 또는 다른 리소스와 통신하도록 동작 가능할 수 있다. 이는 트랜잭션 인덱스(TXindex)를 저장하도록 동작 가능할 수 있고, 바람직하게는 시스템은 하나 초과의 트랜잭션에 대한 개개의 트랜잭션 인덱스를 저장하도록 배열된다. 이는: i) 데이터의 일부에 액세스하기 전에 암호화폐의 일부의 제어를 목적지에 전송하고; ii) 데이터의 일부에 대한 요청을 블록체인 상의 피어에 전송하고; 및/또는 블록체인 상의 피어로부터 데이터의 일부를 수신하도록 동작 가능할 수 있다. 이는 데이터의 일부에 대한 액세스를 제어하기 위해 시간 잠금 메커니즘을 사용하도록 동작할 수 있다.
추가적으로, 본 개시의 실시예는 리소스로부터 추가 리소스로 자산을 전송하는 단계(들)를 제공할 수 있고, 그 단계는, 리소스로부터 추가 리소스로, 적어도 하나의 블록체인 트랜잭션에 관련된 완전한 트랜잭션 데이터, 및 적어도 하나의 블록체인 트랜잭션의 완전한 머클 경로를 전송하는 단계를 포함한다. 리소스 및/또는 추가 리소스는: 디지털 지갑, 암호화폐 지갑, 또는 경량 또는 SPW(Simplified Payment Wallet); 및/또는 지갑을 포함하는 컴퓨터-기반 디바이스; 및/또는 지갑을 포함하는 스마트 카드를 포함할 수 있다. 이는 리소스에서, 또는 리소스 상에, 적어도 하나의 개인 키; 및/또는 적어도 하나의 공개 키를 저장, 수신 및/또는 생성하는 단계; 및/또는 리소스에서, 적어도 하나의 블록 헤더를 수신하는 단계를 포함할 수 있다.
이는: 리소스에 의해 추가 리소스에 전송 데이터를 제공하는 단계를 포함할 수 있고, 전송 데이터는: i) 적어도 하나의 미지출 블록체인 트랜잭션 출력(UTXO)에 관련된 데이터; ii) 적어도 하나의 미지출 블록체인 트랜잭션 출력(UTXO)을 포함하는 트랜잭션에 대한 트랜잭션 ID(TXID); iii) 적어도 하나의 미지출 블록체인 트랜잭션 출력(UTXO)을 지출하기 위한 서명; iv) 적어도 하나의 미지출 블록체인 트랜잭션 출력(UTXO)을 포함하는 트랜잭션에 대한 머클 경로; 및/또는 공개 키 주소를 포함한다.
본 명세서에 개시된 또 다른 양상에 따르면, 컴퓨터 장비를 포함하는 시스템이 제공될 수 있고, 컴퓨터 장비는:
하나 이상의 메모리 유닛을 포함하는 메모리; 및
하나 이상의 프로세싱 유닛을 포함하는 프로세싱 장치를 포함하고, 메모리는 프로세싱 장치 상에서 실행되도록 배열된 코드를 저장하고, 코드는 프로세싱 장치 상에 있을 때 임의의 청구항의 방법, 방법 단계 또는 본 명세서에 포함된 실시예를 수행하도록 구성된다.
컴퓨터 장비는 블록체인 네트워크 및/또는 블록체인 구현 시스템과 상호작용하도록 배열되거나 동작 가능할 수 있고; 그리고/또는 하드웨어 지갑을 포함할 수 있다. 지갑은 SPV(simplified payment verification) 동작을 수행하도록 배열될 수 있다.
실시예는 또한 컴퓨터 판독 가능 저장소에서 구현되고, 하나 이상의 프로세서에서 실행될 때, 임의의 방법, 청구항 또는 본 명세서에 포함된 실시예를 수행하도록 구성된 컴퓨터 프로그램을 제공한다.
실시예는 또한 본 명세서에 포함된 임의의 청구항, 방법, 단계 또는 실시예를 수행하기 위해 하드웨어 및/또는 소프트웨어 구성요소를 사용하거나 제공하는 블록체인-구현 방법을 제공한다. 하드웨어 및/또는 소프트웨어 구성요소는 암호화폐 지갑; 검색 엔진; 블록체인 탐색기; 및/또는 브라우저일 수 있거나 이를 포함할 수 있다. 구성요소는 SPV(simplified payment verification) 동작을 수행하도록 배열되거나 동작할 수 있다.
본 개시의 실시예는 실질적으로 WO 2020/109908 및 PCT/IB2020/050737 내에 개시된 바와 같은 하나 이상의 특징들을 포함할 수 있으며, 이들 둘 모두는 그 전체로 본 명세서에 통합된다.

Claims (25)

  1. 블록체인 트랜잭션 내에서 제공된 서명을 검증하기 위한 방법으로서,
    상기 블록체인 트랜잭션 내에 상기 서명을 제공하고 그리고/또는 상기 서명을 검증하는 단계를 포함하고,
    상기 서명은 메시지에 기초하고,
    상기 메시지는:
    상기 트랜잭션을 고유하게 식별하기 위한 트랜잭션 식별 데이터를 포함하고; 그리고
    상기 트랜잭션 내에서 도출 가능하고 그리고/또는 획득 가능한 데이터만을 포함하는,
    방법.
  2. 제1항에 있어서,
    i) 상기 메시지는 디지털적으로 서명되고; 그리고/또는
    ii) 상기 메시지의 적어도 일부가 암호화 또는 인코딩되고; 그리고/또는
    iii) 상기 서명이 잠금 해제 스크립트와 다른 위치에서 상기 트랜잭션 내에서 제공되고; 그리고/또는
    iv) 상기 서명 및/또는 상기 메시지는 상기 트랜잭션의 출력 내에, 바람직하게는 상기 트랜잭션의 잠금 스크립트에 제공되는,
    방법.
  3. 제1항 또는 제2항에 있어서,
    i) 상기 트랜잭션 식별 데이터는 상기 트랜잭션과 고유하게 연관된 데이터의 아웃포인트 또는 다른 부분을 포함하거나 연관되고; 그리고/또는
    ii) 상기 트랜잭션 식별 데이터는 인코딩, 해싱 또는 난독화되는,
    방법.
  4. 제1항 내지 제3항 중 어느 한 항에 있어서,
    i) 상기 서명에 대한 검증 동작을 수행하는 단계; 및/또는
    ii) 상기 서명에 대한 검증 동작을 수행하기 위해 상기 메시지 및 공개 키를 사용하는 단계를 더 포함하는,
    방법.
  5. 제1항 내지 제4항 중 어느 한 항에 있어서,
    상기 서명을 검증하기 위해 컴퓨터-기반 리소스를 사용하는 단계를 포함하고,
    상기 컴퓨터-기반 리소스는 상기 블록체인과 연관된 기본 프로토콜에 따라 채굴 및/또는 검증 동작을 수행하도록 배열되지 않는,
    방법.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서,
    암호 키를 사용하여 상기 메시지에 디지털적으로 서명하거나 상기 메시지를 인코딩 또는 암호화하는 단계를 더 포함하는,
    방법.
  7. 제1항 내지 제6항 중 어느 한 항에 있어서,
    상기 서명의 검증에 성공한 경우 작업을 허용하거나 상기 메시지의 검증에 실패한 경우 작업을 금지하는 단계를 더 포함하는,
    방법.
  8. 제1항 내지 제7항 중 어느 한 항에 있어서,
    상기 블록체인 트랜잭션은 애플리케이션-레벨 프로토콜에 따라 형성되는,
    방법.
  9. 제8항에 있어서,
    상기 프로토콜은:
    블록체인 트랜잭션의 논리적 계층을 형성하기 위해 블록체인 트랜잭션의 연관을 가능하게 하도록 배열되고; 그리고/또는
    블록체인-구현 메타넷 프로토콜인,
    방법.
  10. 제1항 내지 제9항 중 어느 한 항에 있어서,
    상기 공개 키를 사용하여 생성된 추가 서명과의 비교 시에 상기 서명 및 상기 공개 키를 사용하는 단계, 또는
    상기 공개 키와 추가 공개 키를 비교함으로써 검증을 수행하는 단계를 포함하는,
    방법.
  11. 제1항 내지 제10항 중 어느 한 항에 있어서,
    상기 트랜잭션 식별 데이터는 아웃포인트를 포함하는,
    방법.
  12. 블록체인-구현 검증 방법으로서,
    블록체인 트랜잭션을 생성 또는 제공하는 단계를 포함하고,
    상기 블록체인 트랜잭션은:
    i) 메시지 - 상기 메시지는:
    상기 트랜잭션을 고유하게 식별하기 위한 트랜잭션 식별 데이터; 및
    상기 트랜잭션으로부터 도출 가능하고 그리고/또는 획득 가능한 데이터만을 포함함 - ; 및
    ii) 상기 메시지에 관련되거나 상기 메시지에 기초하거나 상기 메시지를 사용하여 생성된 디지털 서명을 포함하는,
    블록체인-구현 검증 방법.
  13. 제12항에 있어서,
    i) 상기 트랜잭션은 상기 서명을 생성하는 데 사용되는 상기 암호 키에 관련된 공개 키를 더 포함하고; 그리고/또는
    ii) 상기 트랜잭션 식별 데이터는 출력을 포함하고; 그리고/또는
    iii) 상기 서명은, 상기 공개 키에 관련된 암호 키를 사용하여 상기 메시지에 디지털적으로 서명함으로써 생성되고; 그리고/또는
    iv) 상기 서명은 상기 트랜잭션과 연관된 임의의 입력 외부에 제공되는,
    블록체인-구현 검증 방법.
  14. 블록체인 트랜잭션(Tx)에 제공된 디지털 서명을 검증하는 방법으로서,
    상기 블록체인 트랜잭션(Tx)은:
    검증될 상기 디지털 서명;
    메시지 - 상기 메시지는:
    i) 상기 트랜잭션을 고유하게 식별하기 위한 트랜잭션 식별 데이터를 포함하고; 그리고
    ii) 상기 트랜잭션으로부터 도출 가능하고 그리고/또는 획득 가능한 데이터만을 포함함 - ;
    트랜잭션 ID(TxID);
    프로토콜 플래그;
    일임 공개 키(DPK); 및
    일임 트랜잭션 ID(DTxID)을 포함하는,
    방법.
  15. 제14항에 있어서,
    상기 트랜잭션(Tx)은:
    저장된 데이터의 일부, 또는 저장된 데이터의 일부에 대한 참조를 더 포함하는,
    방법.
  16. 제14항 또는 제15항에 있어서,
    상기 저장된 데이터의 일부 또는 상기 저장된 데이터의 일부에 대한 참조, 상기 프로토콜 플래그, 상기 일임 공개 키(DPK) 및/또는 상기 일임 트랜잭션 ID(DTxID)는 상기 트랜잭션의 출력(UTXO) 내에, 바람직하게는 상기 출력(UTXO)과 연관된 잠금 스크립트 내에 제공되는,
    방법.
  17. 제14항 내지 제16항 중 어느 한 항에 있어서,
    상기 저장된 데이터의 일부, 상기 저장된 데이터의 일부에 대한 참조, 상기 프로토콜 플래그, 상기 일임 공개 키(DPK) 및/또는 상기 일임 트랜잭션 ID(DTxID)는, 후속 트랜잭션에 대한 입력으로서 후속적 사용을 위해 무효로서 출력을 표시하기 위해 스크립트 작업코드에 후속되는 위치에서 상기 트랜잭션(Tx) 내에 제공되는,
    방법.
  18. 제14항 내지 제17항 중 어느 한 항에 있어서,
    상기 트랜잭션(Tx)은 하나 이상의 속성을 더 포함하고, 바람직하게는,
    상기 하나 이상의 속성은:
    i) 상기 트랜잭션(Tx) 내에서 제공되거나 상기 트랜잭션(Tx) 내에서 참조되는 데이터의 일부; 및/또는
    ii) 트랜잭션(Tx)
    과 연관된 키워드, 태그 또는 식별자를 포함하는,
    방법.
  19. 제13항 내지 제17항 중 어느 한 항에 있어서,
    상기 트랜잭션(Tx)은:
    논리적 부모 트랜잭션(LPTx)과 연관된 부모 공개 키(PPK) - 상기 논리적 부모 트랜잭션(LPTx)은 상기 일임 트랜잭션 ID(DTxID)에 의해 식별됨 - ; 및
    상기 부모 공개 키(PPK)를 사용하여 생성된 상기 서명을 더 포함하는,
    방법.
  20. 제13항 내지 제18항 중 어느 한 항에 있어서,
    블록체인 내에서 상기 트랜잭션(Tx) 또는 상기 논리적 부모 트랜잭션을 식별하기 위해 상기 일임 공개 키(DPK) 및 상기 트랜잭션 ID(TxID)를 사용하는 단계를 더 포함하는,
    방법.
  21. 제14항 내지 제20항 중 어느 한 항에 있어서,
    상기 프로토콜 플래그는 하나 이상의 블록체인 트랜잭션에서 데이터를 검색, 저장 및/또는 리트리브하기 위한 블록체인-기반 프로토콜과 연관되고 그리고/또는 상기 블록체인-기반 프로토콜을 나타내는,
    방법.
  22. 컴퓨터 장비로서,
    하나 이상의 메모리 유닛을 포함하는 메모리; 및
    하나 이상의 프로세싱 유닛을 포함하는 프로세싱 장치를 포함하고,
    상기 메모리는 상기 프로세싱 장치 상에서 실행되도록 배열된 코드를 저장하고, 상기 코드는 프로세싱 장치 상에 있을 때 제1항 내지 제21항 중 어느 한 항의 방법을 수행하도록 구성되는,
    컴퓨터 장비.
  23. 제22항에 있어서,
    상기 장비는:
    i) 블록체인 네트워크 및/또는 블록체인-구현 시스템이거나, 상기 블록체인 네트워크 및/또는 상기 블록체인-구현 시스템과 상호작용하도록 배열 또는 동작하고; 그리고/또는
    ii) 하드웨어 지갑을 포함하는,
    컴퓨터 장비.
  24. 컴퓨터 판독 가능 저장소 상에서 구현되고, 하나 이상의 프로세서들 상에서 실행될 때, 제1항 내지 제21항 중 어느 한 항의 방법을 수행하도록 구성된 컴퓨터 프로그램.
  25. 제1항 내지 제21항 중 어느 한 항에 있어서,
    제1항 내지 제21항 중 어느 한 항을 수행하기 위해 하드웨어 및/또는 소프트웨어 구성요소를 사용 또는 제공하는 단계를 포함하고,
    상기 하드웨어 및/또는 소프트웨어 구성요소는:
    암호화폐 지갑;
    검색 엔진;
    블록체인 탐색기; 또는
    브라우저이거나 포함하고,
    그리고 바람직하게는, 상기 구성요소는 SPV(simplified payment verification) 동작을 수행하도록 동작하는,
    방법.
KR1020237035074A 2021-03-26 2022-03-17 블록체인-구현 데이터 애플리케이션에서 서명 검증을 위한 개선된 방법 및 시스템 KR20230160849A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2104312.0 2021-03-26
GBGB2104312.0A GB202104312D0 (en) 2021-03-26 2021-03-26 Computer-implemented method & system
PCT/EP2022/057094 WO2022200193A1 (en) 2021-03-26 2022-03-17 Improved methods & systems for signature verification in blockchain-implemented data applications

Publications (1)

Publication Number Publication Date
KR20230160849A true KR20230160849A (ko) 2023-11-24

Family

ID=75783698

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237035074A KR20230160849A (ko) 2021-03-26 2022-03-17 블록체인-구현 데이터 애플리케이션에서 서명 검증을 위한 개선된 방법 및 시스템

Country Status (8)

Country Link
US (1) US20240171407A1 (ko)
EP (1) EP4278555A1 (ko)
JP (1) JP2024512068A (ko)
KR (1) KR20230160849A (ko)
CN (1) CN117136527A (ko)
GB (1) GB202104312D0 (ko)
TW (1) TW202304171A (ko)
WO (1) WO2022200193A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230267134A1 (en) * 2022-02-14 2023-08-24 Unl Network B.V. System and Method for Location Domain Name Service

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11606190B2 (en) * 2017-12-26 2023-03-14 Akamai Technologies, Inc. High performance distributed system of record with cryptographic service support
JP7487196B2 (ja) * 2018-11-27 2024-05-20 エヌチェーン ライセンシング アーゲー ピアツーピアネットワークを介するデータの格納、読み出し、及び通信のためのコンピュータにより実施されるシステム及び方法
GB201907349D0 (en) * 2019-05-24 2019-07-10 Nchain Holdings Ltd Verification of data fields of blockchain transactions

Also Published As

Publication number Publication date
GB202104312D0 (en) 2021-05-12
CN117136527A (zh) 2023-11-28
WO2022200193A1 (en) 2022-09-29
US20240171407A1 (en) 2024-05-23
TW202304171A (zh) 2023-01-16
JP2024512068A (ja) 2024-03-18
EP4278555A1 (en) 2023-11-22

Similar Documents

Publication Publication Date Title
JP7513609B2 (ja) ブロックチェーンネットワークを介するデータの効率的且つセキュアな処理、アクセス、及び送信のためのシステム及び方法
US20240126825A1 (en) Sharing data via transactions of a blockchain
KR20230011330A (ko) 블록체인을 통한 데이터의 효율적이고 안전한 처리, 액세스 및 전송을 위한 컴퓨터 구현 시스템 및 방법
US20240171407A1 (en) Improved methods &amp; systems for signature verification in blockchain-implemented data applications
WO2023012127A1 (en) A computer implemented method and system
US20240205030A1 (en) Uniform resource identifier
JP2024102053A (ja) ブロックチェーンネットワークを介するデータの効率的且つセキュアな処理、アクセス、及び送信のためのシステム及び方法
WO2023227467A1 (en) Blockchain-based message journaling
WO2024028077A1 (en) Wrapped encryption
CN118435558A (zh) 编辑区块链事务的内容