KR20240034793A - 블록체인 트랜잭션들에 대한 조건들의 시행 - Google Patents

블록체인 트랜잭션들에 대한 조건들의 시행 Download PDF

Info

Publication number
KR20240034793A
KR20240034793A KR1020247004674A KR20247004674A KR20240034793A KR 20240034793 A KR20240034793 A KR 20240034793A KR 1020247004674 A KR1020247004674 A KR 1020247004674A KR 20247004674 A KR20247004674 A KR 20247004674A KR 20240034793 A KR20240034793 A KR 20240034793A
Authority
KR
South Korea
Prior art keywords
transaction
script
signature
message
output
Prior art date
Application number
KR1020247004674A
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 KR20240034793A publication Critical patent/KR20240034793A/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
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • 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/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computing Systems (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Algebra (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

제1 블록체인 트랜잭션을 사용하여 제2 블록체인 트랜잭션에 대해 조건들을 시행하는 컴퓨터 구현 방법이 제공되며, 조건들 중 제1 조건은 제2 트랜잭션의 제1 잠금해제 스크립트가 제1 트랜잭션의 제1 잠금 스크립트와 함께 실행될 때, 제2 트랜잭션의 표현이 메모리에 출력되고, 표현은 제2 트랜잭션의 복수의 필드들 및 제1 트랜잭션의 제1 출력에 기초하고, 방법은, 제1 트랜잭션을 생성하는 단계를 포함하고, 제1 트랜잭션은 제1 출력을 포함하고, 제1 출력은 제1 잠금 스크립트를 포함하고, 제1 잠금 스크립트는, 메시지 서브 스크립트; 서명 서브 스크립트; 개인 키에 대응되는 공개 키; 및 검증 서브 스크립트를 포함한다.

Description

블록체인 트랜잭션들에 대한 조건들의 시행
본 개시내용은 블록체인 트랜잭션에 대해 조건을 시행하는 방법에 관한 것이다. 보다 구체적으로, 제1 블록체인 트랜잭션은 제2의 상이한 블록체인 트랜잭션에 대해 하나 이상의 조건들을 시행하는 데 사용된다.
블록체인은 블록체인의 복제본이 분산 P2P(Peer-to-Peer) 네트워크(이하 "블록체인 네트워크"로서 지칭됨) 내 복수의 노드들 각각에서 유지되며 널리 공개되는 분산 데이터 구조의 형태를 지칭한다. 블록체인은 데이터의 블록들의 체인을 포함하며, 각각의 블록은 하나 이상의 트랜잭션들을 포함한다. 소위 "코인베이스 트랜잭션(coinbase transaction)들"이 아닌 각각의 트랜잭션은 시퀀스 내 이전 트랜잭션을 다시 가리키며, 이는 하나 이상의 블록들에 걸쳐 있어 하나 이상의 코인베이스 트랜잭션들로 되돌아갈 수 있다. 코인베이스 트랜잭션은 아래에서 추가로 논의된다. 블록체인 네트워크에 제출된 트랜잭션들은 새로운 블록들에 포함된다. 새로운 블록들은 복수의 노드들 각각이 "작업 증명"을 수행하기 위해 경쟁하는 것 즉, 블록체인의 새로운 블록에 포함되기를 기다리는, 순서화되고 유효성 검증된 보류중인 트랜잭션들의 정의된 세트의 표현에 기초하여 암호화 퍼즐을 해결하는 것을 수반하는 "채굴"로서 지칭되는 프로세스에 의해 생성된다. 블록체인은 일부 노드들에서 프루닝(prune)될 수 있으며 블록들의 공개는 단순 블록 헤더들의 공개를 통해 달성될 수 있다는 것이 주의되어야 한다.
블록체인의 트랜잭션들은 다음 목적들: 디지털 자산(예컨대, 다수의 디지털 토큰들)을 전달하는 것, 가상화된 원장 또는 레지스트리 내 엔트리들의 세트를 순서화하는 것, 타임스탬프 엔트리들을 수신 및 프로세싱하는 것, 그리고/또는 인덱스 포인터들을 시간-순서화하는 것 중 하나 이상을 위해 사용될 수 있다. 블록체인 위에 부가적인 기능성을 쌓기 위해 블록체인이 또한 활용될 수 있다. 예컨대, 블록체인 프로토콜들은 트랜잭션의 데이터에의 부가적인 사용자 데이터 또는 인덱스들의 저장을 허용할 수 있다. 단일 트랜잭션 내에 저장될 수 있는 최대 데이터 용량에 대해 미리 지정된 제한이 없고 이에 따라 점점 더 복잡한 데이터가 통합될 수 있다. 예컨대, 이는 블록체인에 전자 문서를 저장하거나, 오디오 또는 비디오 데이터를 저장하는 데 사용될 수 있다.
블록체인 네트워크의 노드들(종종 "채굴자들"로서 지칭됨)은 분산 트랜잭션 등록 및 검증 프로세스를 수행하며, 이는 나중에 보다 자세히 설명될 것이다. 요약하면, 이 프로세스 동안, 노드는 트랜잭션들을 유효성 검증하여 유효한 작업 증명 솔루션을 식별하려고 시도하는 블록 템플릿에 삽입한다. 유효한 솔루션이 발견되면, 새로운 블록이 네트워크의 다른 노드들로 전파되고, 이에 따라 각각의 노드가 블록체인 상에 새로운 블록을 레코딩하는 것을 가능하게 한다. 트랜잭션을 블록체인에 레코딩하기 위해, 사용자(예컨대, 블록체인 클라이언트 애플리케이션)는 트랜잭션을 전파될 네트워크의 노드들 중 하나로 전송한다. 트랜잭션을 수신하는 노드들은 유효성 검증된 트랜잭션을 새로운 블록에 통합하는 작업 증명 솔루션을 찾기 위해 경합할 수 있다. 각각의 노드는 트랜잭션이 유효하기 위한 하나 이상의 조건들을 포함하는 동일한 노드 프로토콜을 시행하도록 구성된다. 유효하지 않은 트랜잭션들은 블록들 내로 통합되거나 전파되지 않을 것이다. 트랜잭션이 유효성 검증되고 그리하여 블록체인 상에 수락된다고 가정하면, 트랜잭션(임의의 사용자 데이터 포함함)은 이에 따라 불변의 공개 레코드로서 블록체인 네트워크 내 노드들 각각에 등록되고 인덱싱된 상태로 유지된다.
최신 블록을 생성하기 위해 작업 증명 퍼즐을 성공적으로 해결한 노드는 통상적으로 디지털 자산의 금액, 즉 다수의 토큰들을 분배하는 "코인베이스 트랜잭션"이라 불리는 새로운 트랜잭션으로 보상을 받는다. 유효하지 않은 트랜잭션들의 검출 및 거절은 네트워크의 에이전트들로서 작용하는 경쟁 노드들의 액션에 의해 시행되며 불법 행위를 보고하고 차단하도록 장려된다. 광범위한 정보 공개는 사용자들이 노드들의 성능을 지속적으로 감사하도록 허용한다. 단순 블록 헤더들의 공개는 참가자들이 블록체인의 지속적인 무결성을 보장하도록 허용한다.
"출력 기반" 모델(때로는 UTXO 기반 모델로서 지칭됨)에서, 주어진 트랜잭션의 데이터 구조는 하나 이상의 입력들 및 하나 이상의 출력들을 포함한다. 임의의 지출 가능한 출력은 진행중인 트랜잭션 시퀀스로부터 도출 가능한 디지털 자산의 금액을 지정하는 요소를 포함한다. 지출 가능한 출력은 때로는 UTXO("미지출 트랜잭션 출력")로서 지칭된다. 출력은 출력의 향후 리딤션(redemption)을 위한 조건을 지정하는 잠금 스크립트를 더 포함할 수 있다. 잠금 스크립트는 디지털 토큰들 또는 자산들을 유효성 검증하고 이전하는 데 필요한 조건들을 정의하는 술어이다. (코인베이스 트랜잭션 이외의) 트랜잭션의 각각의 입력은 선행 트랜잭션의 이러한 출력에 대한 포인터(즉, 참조)를 포함하고, 가리켜진 출력의 잠금 스크립트를 잠금해제하기 위한 잠금해제 스크립트를 더 포함할 수 있다. 따라서 트랜잭션들의 쌍을 고려하고, 이들을 제1 및 제2 트랜잭션(또는 "타겟" 트랜잭션)이라고 한다. 제1 트랜잭션은 출력을 잠금해제하는 하나 이상의 조건들을 정의하는 잠금 스크립트를 포함하고 디지털 자산의 금액을 지정하는 적어도 하나의 출력을 포함한다. 제2의 타겟 트랜잭션은 제1 트랜잭션의 출력에 대한 포인터를 포함하는 적어도 하나의 입력, 및 제1 트랜잭션의 출력을 잠금해제하기 위한 잠금해제 스크립트를 포함한다.
이러한 모델에서, 제2의 타겟 트랜잭션이 블록체인 네트워크에 전송되어 블록체인에서 전파 및 레코딩될 때, 각각의 노드에 적용되는 유효성에 대한 기준들 중 하나는, 잠금해제 스크립트가 제1 트랜잭션의 잠금 스크립트에 정의된 하나 이상의 조건들 전부 충족하는 것일 것이다. 다른 하나는 제1 트랜잭션의 출력이 다른 더 앞선 유효한 트랜잭션에 의해 이미 리딤되지 않았다는 것일 것이다. 이러한 조건들 중 임의의 것에 따라 유효하지 않은 타겟 트랜잭션을 발견한 임의의 노드는 이를 전파하지 않거나(유효한 트랜잭션으로서 전파하지 않으나, 어쩌면, 유효하지 않은 트랜잭션을 등록하기 위해 전파함) 블록체인에 레코딩될 새로운 블록에 이를 포함시키지 않을 것이다.
대안적인 유형의 트랜잭션 모델은 계정 기반 모델이다. 이 경우에 각각의 트랜잭션은 과거 트랜잭션들의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하기 보다는, 절대 계정 잔액을 참조함으로써 전달될 금액을 정의한다. 모든 계정들의 현재 상태는 블록체인과 별개로 노드들에 의해 저장되며 지속적으로 업데이트된다.
다른 트랜잭션을 사용하여 블록체인 트랜잭션에 대해 조건을 시행하기 위한 기존 기술들이 존재한다. 예컨대, 선행 트랜잭션의 출력을 잠금해제하려고 시도하는 향후 트랜잭션의 입력들 및/또는 출력들에 대해 조건들을 시행하고 이에 따라 선행 트랜잭션의 출력이 해당 조건들을 시행하는 것을 적어도 부분적으로 담당하는 것이 가능하다. 예컨대, 조건들은 향후 트랜잭션의 입력 및/또는 출력이 특정 데이터를 포함하거나 특정 포맷을 취하는 것을 포함할 수 있다.
향후 트랜잭션에 대한 조건들을 시행하는 데 사용되는 한 가지 기술은 일반적으로 "PUSHTX" 또는 "OP_PUSHTX"로 알려져 있다. PUSHTX는 의사 작업코드인데 즉, 블록체인 스크립팅 언어(예컨대, 스크립트)의 단일 작업코드가 아니라, 실행될 때 동작들의 대응하는 모음을 수행하도록 함께 구성되는 작업코드들(또는 보다 일반적으로 함수들)의 모음이다. PUSHTX 기술은 국제 특허 출원들 PCT/IB2018/053335, PCT/IB2018/053337, PCT/IB2018/053339, PCT/IB2018/053336, PCT/IB2018/056430, PCT/IB2018/056432 및 PCT/IB2018/056431에 처음 개시되었다. PUSHTX의 핵심 아이디어는 스택 상의 데이터 요소 상에서 인-스크립트(in-script)로 서명을 생성하고 OP_CHECKSIG를 호출하여 서명을 검증하는 것이다. 만약 통과한다면, OP_CHECKSIG에 의해 구성된 메시지가 스택에 푸시된 데이터 요소와 동일하다는 것을 의미한다. 따라서 이는 현재 지출 트랜잭션(즉, 선행 트랜잭션의 출력을 잠금해제하는 향후 트랜잭션)을 스택에 푸시하는 효과를 달성한다. 현재 트랜잭션을 스택에 푸시하는 것은 예컨대, 현재 트랜잭션의 특정 필드들(예컨대, 입력들, 출력들, 잠금 시간 등)이 특정 데이터, 값들, 작업코드들, 스크립트들 등을 포함한다는 것을 체크함으로써 조건들의 시행을 가능하게 한다.
본 개시내용은 PUSHTX 기술의 여러 최적화들을 제공한다. 그러나 트랜잭션들을 스택에 푸시하기 위한 다른 유사한 기술들 ― 이는 당업자에게 익숙할 것임 ― 이 있으며, 본 개시내용의 실시예들은 PUSHTX뿐만 아니라 이러한 기술들 중 임의의 것에 일반적으로 적용될 수 있다는 것이 이해되어야 한다.
본원에서 개시된 일 양상에 따르면, 제1 블록체인 트랜잭션을 사용하여 제2 블록체인 트랜잭션에 대해 조건들을 시행하는 컴퓨터 구현 방법이 제공되고, 조건들 중 제1 조건은 제2 트랜잭션의 제1 잠금해제 스크립트가 제1 트랜잭션의 제1 잠금 스크립트와 함께 실행될 때, 제2 트랜잭션의 표현이 메모리에 출력된다는 것이고, 표현은 제2 트랜잭션의 복수의 필드들 및 제1 트랜잭션의 제1 출력에 기초하고, 방법은, 제1 트랜잭션을 생성하는 단계를 포함하고, 제1 트랜잭션은 제1 출력을 포함하고, 제1 출력은 제1 잠금 스크립트를 포함하고, 제1 잠금 스크립트는: 실행될 때, 제2 트랜잭션을 표현하는 후보 메시지를 메모리에 출력하도록 구성된 메시지 서브 스크립트 ― 후보 메시지는 제1 및 제2 트랜잭션들의 복수의 후보 필드들에 기초하고, 후보 필드들 중 하나 이상은 제2 트랜잭션의 제1 잠금해제 스크립트에 포함되고, 상기 메시지 서브 스크립트는 상기 후보 필드들의 개개의 세트에 기초하여 상기 후보 메시지의 하나 이상의 개개의 부분들을 생성하고, 상기 후보 필드들의 개개의 세트들 중 적어도 하나를 상기 후보 메시지의 상이한 개개의 부분으로서 재사용하도록 구성됨 ― ; 실행될 때, 서명을 생성하도록 구성된 서명 서브 스크립트 ― 서명은 적어도 후보 메시지, 개인 키 및 임시 개인 키의 함수임 ― ; 개인 키에 대응되는 공개 키; 및 실행될 때, i) 제2 트랜잭션을 표현하는 타겟 메시지를 구성하고 ― 타겟 메시지는 제2 트랜잭션의 복수의 필드들 및 제1 트랜잭션의 제1 출력에 기초함 ― , ii) 서명이 타겟 메시지에 대해 유효하다는 것을 검증하기 위해 공개 키를 사용하도록 구성된 검증 서브 스크립트를 포함하고, 서명이 타겟 메시지에 대해 유효하다는 것을 검증하는 것은 타겟 메시지가 후보 메시지와 매칭된다는 것을 검증하고 그리하여 메모리에 출력된 후보 메시지가 제2 트랜잭션의 표현이라는 조건을 시행하는 것이다.
제1 트랜잭션의 잠금 스크립트 및 제2 트랜잭션의 잠금해제 스크립트는 제2 트랜잭션의 유효성 검증 동안 실행될 것이다. 제1 트랜잭션의 잠금 스크립트는 각각이 하나 이상의 동작들을 수행하도록 구성된 일련의 서브 스크립트들을 포함한다. 서브 스크립트는 단지 특정 세트의 함수들(예컨대, 작업코드들)에 대한 라벨일 뿐이며 선택적으로 한 세트의 데이터 항목들 예컨대, 공개 키 또는 공개 키 해시이다.
메시지 서브 스크립트는 후보 메시지를 메모리 예컨대, 스택에 출력하도록 구성된다. 메시지는 올바르게 구성되었다면 본원에서 "타겟 메시지"라고 하는 다른 메시지와 매칭될 것이라는 의미에서 "후보 메시지"이다. 후보 메시지는 제2 트랜잭션의 복수의 후보 필드들(예컨대, 입력(들), 출력(들) 등)(예컨대, 제2 트랜잭션의 모든 필드들) 및 제1 트랜잭션의 후보 제1 출력 즉, 제1 잠금 스크립트를 포함하는 출력에 기초한다. 여기서 필드들 및 출력은 데이터 항목들로서 (제1 트랜잭션의 잠금 스크립트 또는 제2 트랜잭션의 잠금해제 스크립트 중 어느 하나에) 포함되고 제1 및 제2 트랜잭션들의 올바른 필드들로 간주된다는 의미에서 "후보들"이다. 예컨대, 잠금 스크립트의 후보 길이는 제2 트랜잭션의 잠금해제 스크립트에 포함될 수 있다.
서명 서브 스크립트는 후보 메시지, 개인 키 및 임시 개인 키에 기초하여 디지털 서명(예컨대, ECDSA 서명)을 생성하도록 구성된다. 일부 실시예들에서, 임시 개인 키는 1과 동일하게 고정될 수 있다. 통상적으로, 임시 개인 키는 큰 수이고 전형적으로 서명의 생성 동안 임시 개인 키가 여러 번 요구된다는 점을 고려하면, 임시 개인 키를 1로 고정하는 것은 잠금 스크립트의 저장 크기를 감소시키고 서명 생성 프로세스를 단순화한다. 임시 개인 키와 관련된 임의의 수학적 연산이 간단해지기 때문에 서명 생성 프로세스가 단순화된다. 서명 서브 스크립트는 개인 키 및 임시 개인 키 둘 모두를 1로 동일하게 고정함으로써 훨씬 더 최적화될 수 있다. 이는 잠금 스크립트의 저장 크기를 추가로 감소시키고 서명 생성 프로세스의 컴퓨테이셔널 복잡성을 감소시킨다. 부가적인 또는 대안적인 실시예들에서, 임시 개인 키 및 개인 키는 잠금 스크립트에서 동일한 값(물론, 이미 언급된 바와 같은 옵션이지만, 값이 1일 필요는 없음)과 동일하게 고정된다. 이들 실시예들은 유사한 이유들로 상당한 절감들을 제공한다. 추후에 설명될 바와 같이, 본 개시내용의 발명자들은 제1 또는 제2 트랜잭션들의 보안을 손상시키지 않고 이러한 절감들이 가능하다는 것을 인식했다.
서명 검증 서브 스크립트(일부 경우들에서, 작업코드와 같은 단일 함수일 수 있음)는 제1 및 제2 트랜잭션의 실제 필드들 예컨대, 제1 트랜잭션의 실제 제1 출력, 제2 트랜잭션의 실제 출력들 등에 기초하여 타겟 메시지를 구성하도록 구성된다. 또한 서명 검증 서브 스크립트는 서명 서브 스크립트에 의해 생성된 서명이 타겟 메시지에 대해 유효하다는 것을 검증한다. 서명이 유효한 경우, 후보 메시지는 반드시 타겟 메시지와 동일하다. 따라서 메모리에 출력된 후보 메시지는 제2 트랜잭션의 표현인 타겟 메시지이다. 즉, 서명 체크를 통과하는 것은 두 메시지들이 동일한 경우에만 가능하고 이에 따라 서명을 검증하는 것은 후보 메시지와 타겟 메시지가 동일하다는 것을 검증한다.
제2 트랜잭션을 메모리(예컨대, 스택)에 출력한 후, 추가 조건들을 시행하도록 추가 체크들이 수행할 수 있다. 예컨대, 본 개시내용의 실시예들은 PELS(perpetually enforcing locking script)를 구성하는 데 사용될 수 있으며, 여기서 PELS는 잠금 스크립트를 포함하는 출력으로부터 기원되는 트랜잭션의 체인 내 모든 향후 트랜잭션들에 대해 일부 조건 또는 조건들을 시행하는 잠금 스크립트이다. 예컨대, PELS는 지출 트랜잭션의 잠금 스크립트를 자체와 동일하게 되도록 강제하기 위해 사용될 수 있다. PELS는 향후 모든 지출 트랜잭션이 잠금 스크립트에 설정된 규칙들을 따를 것임을 보장할 수 있으므로, PELS는 전송자(즉, PELS의 제1 인스턴스를 포함하는 트랜잭션의 생성자)에게 특히 유용하다. 규칙들의 임의의 위반은 스크립트 실행의 관점에서 트랜잭션 유효성 검증을 무효화할 것이다. 사실상, 전송자는 유효성 검증 작업을 블록체인 노드들에 위임함으로써 향후 모든 트랜잭션들로부터 물러날 수 있다.
본 개시내용은, 후보 메시지의 일부를 표현하는 후보 필드들의 하나 이상의 세트들이 후보 메시지의 상이한 부분을 구성하기 위해 재사용될 수 있다는 것을 인식한다. 이것은 후보 필드들의 하나 이상의 세트들이 여러 번 포함되기보다는, 제1 트랜잭션의 잠금 스크립트 또는 제2 트랜잭션의 잠금해제 스크립트에 단 한번만 포함될 필요가 있기 때문에 상당한 공간 절감을 제공한다. 후보 필드들의 하나 이상의 세트들의 재사용의 추가의 효과는 추가의 조건들이 제2 트랜잭션에 대해 시행될 수 있다는 것이다. 예컨대, 위에서 언급된 바와 같이, 후보 메시지는 잠금 스크립트를 시행하는 조건을 포함하는 제1 트랜잭션의 출력에 기초한다. 잠금해제 스크립트는 제1 트랜잭션의 출력을 표현하는 후보 필드들의 세트(예컨대, 값 및 잠금 스크립트)를 포함할 수 있다. 메시지 서브 스크립트는 제2 트랜잭션의 출력을 구성하기 위해 후보 필드들의 세트를 복제할 수 있다. 서명 검증이 통과되면, 후보 메시지는 타겟 메시지와 동일해야 하며, 따라서 제2 트랜잭션은 제1 트랜잭션의 출력과 매칭하는 출력을 포함해야 한다. 다시 말해서, 제2트랜잭션이 유효하다고 간주되기 위해서는 제1트랜잭션의 출력이 제2트랜잭션의 출력으로서 포함되는 것으로 나타나야 한다. 제2 트랜잭션의 동일한 세트의 후보(또는 실제) 필드들을 포함하거나 이에 기초하여 생성되는 후보 메시지(및 따라서 타겟 메시지)의 임의의 부분에 동일한 기술이 적용될 수 있다.
본 개시내용의 실시예들의 이해를 보조하기 위해 그리고 그러한 실시예들이 어떻게 실행될 수 있는지를 보여주기 위하여, 단지 예로서 첨부 도면들에 대한 참조가 이루어진다.
도 1은 블록체인을 구현하기 위한 시스템의 개략적인 블록도이다.
도 2는 블록체인에 레코딩될 수 있는 트랜잭션들의 일부 예들을 개략적으로 예시한다.
도 3a는 클라이언트 애플리케이션의 개략적인 블록도이다.
도 3b는 도 3a의 클라이언트 애플리케이션에 의해 제공될 수 있는 예시적인 사용자 인터페이스의 개략적인 실물 모형이다.
도 4는 트랜잭션들을 프로세싱하기 위한 일부 노드 소프트웨어의 개략적인 블록도이다.
도 5은 본 개시내용의 실시예들을 구현하기 위한 예시적인 시스템의 개략적인 블록도이다.
도 6은 제2 트랜잭션에 대해 조건을 시행하도록 구성된 제1 트랜잭션의 예를 예시한다.
도 7은 제2 트랜잭션의 예를 예시한다.
도 8은 제1 트랜잭션이 최적화되어 다른 부분으로부터 후보 메시지의 일부를 생성하는 제2 트랜잭션의 예를 예시한다.
1. 예시적인 시스템 개요
도 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가 데이터 필드에 포함된 경우 이전 트랜잭션을 뒤로 가리킬 수 있다.
2. 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개의 스크립트들을 컨케터네이팅(concatenating)하는 것을 수반한다.
<Sig PA> <PA> || [Checksig PA]
여기에서 "||"는 컨케터네이션을 표현하고 "<...>"는 스택 상에 데이터를 배치하는 것을 의미하고, "[…]"는 잠금 스크립트(이 예에서, 스택-기반 언어)에 의해 구성된 함수이다. 동등하게, 스크립트들을 컨케터네이팅하는 대신, 스크립트들은 공통 스택을 사용하여 번갈아 실행될 수 있다. 어느 쪽이든, 함께 실행될 때, 스크립트들은 Tx0의 출력의 잠금 스크립트에 포함된 바와 같은 앨리스의 공개 키 PA를 사용하여, Tx1의 입력의 잠금해제 스크립트가 데이터의 예상되는 부분에 서명하는 앨리스의 서명을 포함한다는 것을 인증한다. 이 인증을 수행하기 위하여 데이터의 예상되는 부분 자체("메시지")가 또한 포함될 필요가 있다. 실시예들에서, 서명된 데이터는 Tx1 전체를 포함한다(이에 따라, 평문으로 데이터의 서명된 부분을 지정하는 별개의 요소가 포함될 필요가 없는데, 그 이유는 그것이 이미 본질적으로 존재하기 때문임).
공개-개인 암호화에 의한 인증의 세부사항들은 당업자에게 친숙할 것이다. 기본적으로, 앨리스가 자신의 개인 키를 사용하여 메시지에 서명한 경우, 앨리스의 공개 키 및 평문의 메시지를 감안하여, 노드(104)와 같은 다른 엔티티는 메시지가 앨리스에 의해 서명된 것임이 틀림없다는 것을 인증할 수 있다. 서명은 통상적으로 메시지를 해시하는 것, 해시에 서명하는 것, 그리고 이를 서명으로서 메시지에 태깅하고, 이에 따라 공개 키의 임의의 보유자(holder)가 서명을 인증하는 것을 가능하게 하는 것을 포함한다. 따라서 여기에서 특정 데이터 조각 또는 트랜잭션의 일부 등에 서명하는 것에 대한 임의의 참조는 실시예들에서 해당 데이터 조각 또는 트랜잭션 일부의 해시에 서명하는 것을 의미할 수 있다는 것에 주의한다.
Tx1의 잠금해제 스크립트가 Tx0의 잠금 스크립트에 지정된 하나 이상의 조건들을 충족시키는 경우(이에 따라, 보여진 예에서, 앨리스의 서명이 Tx1에서 제공되고 인증된 경우), 블록체인과 노드(104)는 Tx1이 유효한 것으로 간주한다. 이는 블록체인 노드(104)가 계류중인 트랜잭션들(154)의 순서화된 풀에 Tx1을 추가할 것임을 의미한다. 블록체인 노드(104F)는 또한 트랜잭션 Tx1을 네트워크(106) 내 하나 이상의 다른 블록체인 노드들(104)로 포워딩할 것이어서, 그 트랜잭션이 네트워크(106) 전반에 걸쳐 전파될 것이다. 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 출력에서 자신에게 잔돈을 주거나, 다른 당사자에게 지불하는데 나머지를 사용할 수 있다.
실제로, 앨리스는 또한 일반적으로 블록(151)에 그녀의 트랜잭션(104)을 성공적으로 포함시키는 비트코인 노드(104)에 대한 수수료를 포함할 필요가 있을 것이다. 앨리스가 그러한 수수료를 포함시키지 않는 경우, Tx0은 블록체인 노드들(104M)에 의해 거부될 수 있고, 이에 따라 기술적으로 유효하더라도, 전파되어 블록체인(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들의 값들을 함께 대조하는 것이다. 비트코인 노드들(104) 중 임의의 것에 저장된 블록체인(150)의 사본을 질의함으로써 이것이 수행될 수 있다.
스크립트 코드는 종종 도식적으로(즉, 정확한 언어를 사용하지 않음) 표현된다는 것에 주의한다. 예컨대, 특정 기능을 표현하기 위해 작업 코드(opcode)들이 사용될 수 있다. "OP_..."는 스크립트 언어의 특정 작업코드(opcode)를 지칭한다. 예로서, OP_RETURN은 잠금 스크립트의 선두에서 OP_FALSE가 앞에 있을 때 트랜잭션 내에 데이터를 저장하고 그리하여 데이터를 블록체인(150)에 변경 불가능하게 레코딩할 수 있는 트랜잭션의 지출 불가능한 출력을 생성하는 스크립트 언어의 작업코드이다. 예컨대, 데이터는 블록체인에 저장하고자 하는 문서를 포함할 수 있다.
통상적으로, 트랜잭션의 입력은 공개 키 PA에 대응하는 디지털 서명을 포함한다. 실시예들에서, 이는 타원 곡선 secp256k1을 사용하는 ECDSA에 기초한다. 디지털 서명은 특정 데이터 조각에 서명한다. 일부 실시예들에서, 주어진 트랜잭션에 대해, 서명은 트랜잭션 입력의 일부, 및 트랜잭션 출력들의 전부 또는 일부에 서명할 것이다. 서명되는 출력들의 특정 부분들은 SIGHASH 플래그에 의존한다. SIGHASH 플래그는 일반적으로 어느 출력들이 서명되는지를 선택하기 위해 서명의 끝에 포함된 4-바이트 코드이다(이에 따라, 서명 시에 고정됨).
잠금 스크립트는 때로는, 그것이 통상적으로 개개의 트랜잭션이 잠겨 있는 당사자의 공개 키를 포함한다는 사실을 지칭하는 "scriptPubKey"라 칭해진다. 잠금해제 스크립트는 때로는 그것이 통상적으로 대응하는 서명을 제공한다는 사실을 지칭하는 "scriptSig"라 칭해진다. 그러나, 보다 일반적으로, UTXO가 리딤되기 위한 조건이 서명을 인증하는 것을 포함하는 것이 블록체인(150)의 모든 애플리케이션들에서 필수적인 것은 아니다. 보다 일반적으로 스크립팅 언어는 임의의 하나 이상의 조건들을 정의하는 데 사용될 수 있다. 따라서 보다 일반적인 용어들 "잠금 스크립트" 및 "잠금해제 스크립트"가 선호될 수 있다.
3. 사이드 채널
도 1에 도시된 바와 같이, 앨리스 및 밥의 컴퓨터 장비(102a, 120b) 각각 상의 클라이언트 애플리케이션은 각각 부가적인 통신 기능성을 포함할 수 있다. 즉, 부가적인 기능성은 (어느 한 당사자 또는 제3자의 주도로) 앨리스(103a)가 밥(103b)과 별개의 사이드 채널(107)을 설정하는 것을 가능하게 한다. 사이드 채널(107)은 블록체인 네트워크와 별개로 데이터 교환을 가능하게 한다. 이러한 통신을 때로는 "오프-체인(off-chain)" 통신으로서 지칭된다. 예컨대, 이는 당사자들 중 하나가 네트워크(106)로 브로드캐스팅하기로 선택할 때까지, (아직) 트랜잭션이 블록체인 네트워크(106) 상에 등록되거나 체인(150)으로 진행됨 없이 앨리스와 밥 사이에서 트랜잭션(152)을 교환하는 데 사용될 수 있다. 이러한 방식으로 트랜잭션을 공유하는 것은 때로는 "트랜잭션 템플릿" 공유하는 것으로서 지칭된다. 트랜잭션 템플릿은 완전한 트랜잭션을 형성하기 위해 요구되는 하나 이상의 입력들 및/또는 출력들이 없을 수 있다. 대안적으로 또는 부가적으로, 사이드 채널(107)은 키들, 협상된 금액들 또는 조건들, 데이터 콘텐츠 등과 같은 임의의 다른 트랜잭션 관련 데이터를 교환하는 데 사용될 수 있다.
사이드 채널(107)은 블록체인 네트워크(106)와 동일한 패킷 교환 네트워크(101)를 통해 설정될 수 있다. 대안적으로 또는 부가적으로, 사이드 채널(301)은 상이한 네트워크 이를테면, 모바일 셀룰러 네트워크, 또는 로컬 영역 네트워크 이를테면, 로컬 무선 네트워크, 또는 심지어, 앨리스 및 밥의 디바이스들(102a, 102b) 사이의 직접 유선 또는 무선 링크를 통해 설정될 수 있다. 일반적으로, 본원의 임의의 위치에서 지칭되는 바와 같은 사이드 채널(107)은 "오프-체인", 즉 블록체인 네트워크(106)와 별개로 데이터를 교환하기 위한 하나 이상의 네트워킹 기술들 또는 통신 매체들을 통한 임의의 하나 이상의 링크들을 포함할 수 있다. 하나 초과의 링크가 사용되는 경우, 오프-체인 링크들의 번들(bundle) 또는 모음은 전체적으로 사이드 채널(107)로서 지칭될 수 있다. 따라서 앨리스 및 밥이 사이드 채널(107)을 통해 특정 정보 조각들 또는 데이터 등을 교환한다고 하면, 이는 이러한 모든 데이터 조각들이 정확히 동일한 링크 또는 심지어 동일한 유형의 네트워크를 통해 전송되어야 한다는 것을 반드시 의미하는 것은 아니란 것에 주의한다.
4. 클라이언트 소프트웨어
도 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 요소들을 포함할 수 있다는 것이 인지될 것이다.
5. 노드 소프트웨어
도 4는 UTXO-기반 또는 출력-기반 모델의 예에서 네트워크(106)의 각각의 블록체인 노드(104) 상에서 실행되는 노드 소프트웨어(450)의 예를 예시한다. 다른 엔티티는 네트워크(106) 상에서 노드(104)로 분류되지 않고, 즉 노드(104)에 필요한 액션들을 수행하지 않고 노드 소프트웨어(450)를 실행할 수 있다는 것에 주의한다. 노드 소프트웨어(450)는 프로토콜 엔진(451), 스크립트 엔진(452), 스택(453), 애플리케이션-레벨 판단 엔진(454), 및 일 세트의 하나 이상의 블록체인-관련 기능 모듈들(455)을 포함한다(그러나 이에 제한되지 않음). 각각의 노드(104)는 합의 모듈(455C)(예컨대, 작업 증명), 전파 모듈(455P) 및 저장 모듈(455S)(예컨대, 데이터베이스) 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)은 Txi의 잠금 스크립트 및 Txj의 대응하는 입력으로부터의 잠금해제 스크립트를 갖는다. 예컨대, 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) 둘 모두를 제어하기로 선택할 수 있다. 이는, 블록(151)에 통합하기 위해 노드의 트랜잭션들(154)의 개개의 순서화된 세트(154)에 Txj를 추가하는 합의 모듈(455C) 및 네트워크(106) 내 다른 블록체인 노드(104)에 Txj를 포워딩하는 전파 모듈(455P)을 포함한다. 선택적으로, 실시예들에서, 애플리케이션-레벨 판단 엔진(454)은 이들 기능들 중 어느 하나 또는 둘 모두를 트리거하기 전에 하나 이상의 부가적인 조건들을 적용할 수 있다. 예컨대, 판단 엔진은 트랜잭션이 유효하고 트랜잭션 수수료가 충분히 남아 있다는 것을 조건으로만 트랜잭션을 공개하기로 선택할 수 있다.
또한, 본원에서 "참" 및 "거짓"이라는 용어들은 단지 단일 이진 숫자(비트)의 형태로 표현되는 결과를 리턴하는 것으로 반드시 제한되지는 않지만, 이는 확실히 하나의 가능한 구현이라는 것에 주의한다. 보다 일반적으로, "참"은 성공 또는 긍정적인 결과를 표시하는 임의의 상태를 지칭할 수 있고 "거짓"은 실패 또는 비-긍정적인 결과를 표시하는 임의의 상태를 지칭할 수 있다. 예컨대, 계정-기반 모델에서, "참"의 결과는 서명의 암시적인 프로토콜 레벨의 유효성 검증 및 스마트 계약의 부가적인 긍정적인 출력의 조합에 의해 표시될 수 있다(개별 결과들 둘 모두가 참인 경우, 전체 결과가 참을 시그널링하는 것으로 간주됨).
6. 블록체인 트랜잭션에 대한 조건들의 시행
본 개시내용의 실시예들은 하나의 트랜잭션이 다른 트랜잭션에 대한 조건들을 시행(즉, 부과)하는 것을 가능하게 한다. 조건들을 시행하는 트랜잭션을 "제1 트랜잭션"으로서 지칭될 것이고 시행되는 조건들을 갖는 트랜잭션은 "제2 트랜잭션"으로서 지칭될 것이다. 조건이 충족되지 않는 한 트랜잭션 유효성 검증 동안 제2 트랜잭션이 블록체인 노드(104)에 의해 성공적으로 유효성 검증되지 않는다는 의미에서 조건들이 시행된다. 도 5는 상기 실시예들을 구현하기 위한 예시적인 시스템을 예시한다. 도시된 바와 같이, 시스템은 제1 트랜잭션을 생성하도록 구성된 제1 당사자, 제2 트랜잭션을 생성하도록 구성된 제2 당사자, 및 블록체인 네트워크(106)의 하나 이상의 블록체인 노드들을 포함한다. 편의상, 제1 당사자는 앨리스(103a)로 지칭될 것이고, 제2 당사자는 밥(103b)으로서 지칭될 것다. 일반적으로, 제1 당사자와 제2 당사자 둘 모두는 앨리스(103a) 및/또는 밥(103b)에 의해 수행되는 것으로 위에 설명된 액션들 중 임의의 것을 수행하도록 구성될 수 있다. 시스템은 다른 엔티티들(미도시), 예컨대, 부가적인 사용자들을 포함할 수 있다.
언급된 바와 같이, 앨리스(103a)는 제1 트랜잭션을 생성하도록 구성된다. 제1 트랜잭션은 제1 출력을 포함한다. 제1 출력이 반드시 제1 트랜잭션의 출력들의 목록에서 논리적으로 첫 번째로 나타날 필요는 없지만 첫 번째로 나타나는 것이 하나의 가능성이다. 제1 출력은 "제1 잠금 스크립트"로서 지칭될 잠금 스크립트를 포함한다. 제1 잠금 스크립트는 이 예시적인 시나리오에서, 제2 트랜잭션인 제1 출력을 잠금해제하려고 시도하는 임의의 트랜잭션에 대해 하나 이상의 조건들을 시행하도록 구성된다. 이들 조건들 중 적어도 하나는 제2 트랜잭션의 실행(예컨대, 유효성 검증) 동안 제2 트랜잭션의 표현이 메모리에 출력된다는 것이다. 즉, 제1 트랜잭션(및 특히, 제1 트랜잭션의 제1 잠금 스크립트)은 제2 트랜잭션의 잠금해제 스크립트가 제1 잠금 스크립트와 함께 실행될 때 제2 트랜잭션의 표현이 메모리에 출력되도록 보장하는 효과를 갖는다. 편의상, 제1 트랜잭션의 제1 잠금 스크립트와 함께 실행되는 제2 트랜잭션의 잠금해제 스크립트는 제2 트랜잭션의 제1 입력에 포함되는 "제1 잠금해제 스크립트"로서 지칭될 것이다. 제1 입력이 반드시 제2 트랜잭션의 입력들의 목록에서 논리적으로 첫 번째로 나타날 필요는 없지만 첫 번째로 나타나는 것이 하나의 가능성이다.
제2 트랜잭션의 표현은 특정 블록체인 ― 트랜잭션이 이 특정 블록체인의 일부를 형성함 ― 에 의존하여 변동될 수 있다. 일반적으로, 제2 트랜잭션의 표현은 제2 트랜잭션의 복수의 필드들 및 제1 트랜잭션의 제1 출력에 기초한다. 즉, 현재 트랜잭션의 표현은 현재 트랜잭션과 잠금해제 중인 즉, 지출되고, 할당되고, 이전 등이 되는 이전 트랜잭션의 출력 둘 모두에 기초한다. 아래에서 추가로 논의될 바와 같이, 메모리에 제2 트랜잭션의 표현을 출력하는 것은 제2 트랜잭션의 일부 또는 전부 상에서 체크들이 수행되도록 허용하고 이에 따라 예컨대, 해당 조건들이 충족되었음을 체크하고, 만약 그렇지 않은 경우, 트랜잭션 실행이 실패되게 함으로써 추가 조건들이 시행될 수 있다.
제1 잠금 스크립트는 메모리에 출력되는 표현이 실제로 제2 트랜잭션의 정확한 표현임을 보장하도록 함께 구성되는 서브 스크립트들을 포함한다.
서브 스크립트들 중 제1 서브 스크립트는 "메시지 서브 스크립트"로서 지칭된다. 메시지 서브 스크립트는 제1 잠금 스크립트에서 논리적으로 첫 번째로 나타날 수 있고, 제1 잠금 스크립트 이전에 나타나는 제1 잠금 스크립트에 포함된 다른 서브 스크립트들이 있을 수 있다. 메시지 서브 스크립트는 후보 메시지를 메모리에 출력하도록 구성된다. 후보 메시지는 제2 트랜잭션의 여러 "후보 필드"뿐만 아니라 제1 트랜잭션의 "후보 제1 출력"에 기초한다. 후보 메시지는 그것이 메모리에 출력되는 시점에서, 후보 메시지가 제2 트랜잭션의 실제 필드들 및 제1 트랜잭션의 실제 제1 출력에 기초하여 구성되었다는 점에서 아직 알려지지 않는다(또는 적어도 아직 인-스크립트로 검증되지 않음)는 의미에서 '후보'이다. 후보 필드들 및 후보 제1 출력은 비슷한 의미에서 후보들인데 즉, 인-스크립트(in-script)로 검증될 때까지, 이들은 올바른지 알 수 없다.
후보 필드들 중 적어도 일부는 제2 트랜잭션의 제1 잠금해제 스크립트에 포함된다. 각각의 후보 필드는 별개의 데이터 항목일 수 있거나, 데이터 항목은 하나 초과의 후보 필드를 포함할 수 있다. 후보 제1 출력의 일부 또는 전부(예컨대, 제1 출력에 할당된 값, 제1 출력의 제1 잠금 스크립트, 제1 출력의 제1 잠금 스크립트의 길이)가 또한 제1 잠금해제 스크립트에 포함될 수 있다. 일부 실시예들에서, 제2 트랜잭션의 후보 필드들 중 하나 이상은 제1 트랜잭션의 제1 잠금 스크립트에 포함될 수 있다. 아래에 논의된 바와 같이, 제1 잠금 스크립트에 포함된 후보 메시지가 기초하는 임의의 후보 필드는 반드시 제2 트랜잭션에 포함되어야 한다. 따라서 제2 트랜잭션이 해당 후보 필드(들)를 포함해야 한다는 조건이 시행될 수 있다. 예로서, 제1 잠금 스크립트는 후보 메시지가 기초하는 후보 잠금 시간을 포함함으로써 제2 트랜잭션의 잠금 시간을 고정할 수 있다. 선택적으로, 후보 제1 출력의 일부(전부는 아님)가 제1 트랜잭션의 제1 출력에 포함될 수 있다.
메시지 서브 스크립트는 후보 메시지의 일부 또는 전부를 구성하도록 구성될 수 있다. 예컨대, 메시지 서브 스크립트는 제1 잠금 스크립트 및/또는 제1 잠금해제 스크립트에 포함된 하나 이상의 데이터 항목들을 결합(예컨대, 컨케터네이팅)할 수 있으며, 여기서 각각의 데이터 항목은 하나 이상의 후보 필드들 및/또는 후보 제1 출력(의 일부)을 포함한다. 보다 구체적으로, 메시지 서브 스크립트는 하나 이상의 후보 필드들에 기초하여 후보 메시지의 일부를 구성하고 해당 하나 이상의 후보 필드들 중 적어도 일부를 후보 메시지의 상이한 부분으로서 재사용하도록 구성된다. 예컨대, 하나 이상의 후보 필드들은 복제되어 후보 메시지의 일부를 구성하는 데 사용되고 그 후 메시지의 상이한 부분으로서 사용될 수 있다(또는 메시지의 상이한 부분을 구성하는 데 사용됨). 예로서, 후보 필드들의 세트(예컨대, 후보 출력 값 및 후보 잠금 스크립트)는 제2 트랜잭션의 후보 이전 출력(즉, 제1 트랜잭션의 제1 출력)을 표현하는 후보 메시지의 일부로서 사용될 수 있고, 제2 트랜잭션의 후보 출력으로서 재사용될 수 있다. 이 예에서, 후보 메시지는 제2 트랜잭션의 출력들의 후보 해시를 포함할 수 있고 이에 따라 메시지 서브 스크립트는 후보 필드들의 재사용된 세트를 해싱할 수 있다. 메시지 서브 스크립트는 후보 필드들의 단일 세트를 재사용하거나 후보 필드들의 다수의 세트들을 재사용하도록 구성될 수 있다. 이는 메시지 포맷에 의존할 것이다.
제1 잠금 스크립트는 또한 후보 메시지에 기초하여 서명을 생성하도록 구성된 서명 서브 스크립트를 포함한다. 또한 서명은 개인 키 및 임시 개인 키에 기초하여 생성되며, 이 둘 모두는 제1 잠금 스크립트에 의해 고정(예컨대, 제1 잠금 스크립트의 일부으로서 포함)된다. 서명은 ECDSA 서명일 수 있다. 개인 키 및 임시 개인 키는 제1 잠금 스크립트에 의해 "고정"되기 위해 반드시 제1 잠금 스크립트에 포함될 필요는 없다는 것에 주의한다. 예컨대, 제1 잠금 스크립트는 개인 키 및/또는 임시 개인 키에 기초하고, 이에 따라 해당 개인 키 및/또는 임시 개인 키를 고정하는 값을 포함할 수 있다. 임시 개인 키는 임의의 수, 및 바람직하게는 작은 수일 수 있다. 예컨대, 임시 개인 키는 1과 동일하게 고정될 수 있다. 이는 일반적으로 256 비트 정수인 종래의 임시 개인 키들에 비해 상당한 공간 절감을 제공한다. 게다가, 일반적으로 임의의 수일 수 있는 개인 키는 또한 1과 동일하게 고정되고, 이에 따라 추가 공간 절감을 제공한다(개인 키들은 또한 일반적으로 256 비트 정수들임). 개인 키 및 임시 개인 키 둘 모두가 1과 동일하게 고정되는 것에 대한 대안으로서, 이들은 서로 동일하게 고정될 수 있는데 예컨대, 둘 모두는 2 또는 다른 작은 수의 값을 취할 수 있다. 키들 둘 모두에 대해 동일한 값이 사용되므로 서명 생성 프로세스가 단순화된다.
제1 잠금 스크립트는 또한 검증 서브 스크립트를 포함한다. 검증 서브 스크립트는 제2 트랜잭션을 표현하는 타겟 메시지를 구성하도록 구성된다. 타겟 메시지는 제2 트랜잭션의 복수의 필드들에 기초한다. 타겟 메시지는 제2 트랜잭션 필드들의 실제 필드들 즉, 제2 트랜잭션 자체로부터 취해지거나 제2 트랜잭션에 기초하여 생성된 것에 기초한다. 타겟 메시지는 후보 메시지와 동일한 제2 트랜잭션의 필드들의 세트에 기초한다. 예컨대, 후보 메시지 및 타겟 메시지는 제2 트랜잭션의 하나 이상의 입력들에 기초할 수 있다. 타겟 메시지는 또한 제1 트랜잭션의 실제 제1 출력, 즉 제1 트랜잭션 자체로부터 취해진 것에 기초한다.
또한, 검증 서브 스크립트는 서명 서브 스크립트에 의해 생성된 서명이 타겟 메시지에 대해 유효한 서명이라는 것을 검증하도록 구성된다. 서명은 개인 키에 대응하는 공개 키를 사용하여 유효성 검증된다. 공개 키는 예컨대, 검증 서브 스크립트의 일부로서 제1 잠금 스크립트에 포함된다. (후보 메시지에 기초하여 생성된) 서명이 타겟 메시지에 대해 유효한 서명인 경우, 후보 메시지 및 타겟 메시지는 동일한 메시지이고 이에 따라, 후보 메시지는 제2 트랜잭션의 실제 필드들 및 제1 트랜잭션의 실제 제1 출력에 기초한다는 것이 결과이다. 따라서 메시지 서브 스크립트에 의해 메모리에 출력되는 후보 메시지는 제2 트랜잭션의 표현이며, 스크립트 실행 동안 제2 트랜잭션의 표현이 메모리에 출력된다는 조건이 이행된다. 반대로 서명 검증이 실패하는 경우, 후보 메시지는 타겟 메시지와 동일하지 않고 이에 따라 제2 트랜잭션의 요구된 표현이 아니다.
요약하면, 앨리스(103a)는 잠금 스크립트를 갖는 트랜잭션을 생성하며, 이에 따라 잠금 스크립트가 잠금해제되기 위해, 지출 트랜잭션의 표현이 실행 동안에 메모리(예컨대, 스택)에 출력되어야 한다. 메모리가 스택 기반인 예들에서, 검증 서브 스크립트는 서명이 타겟 메시지에 대해 유효하다는 것을 검증하도록 구성된 OP_CHECKSIG 또는 OP_CHECKSIGVERIFY 작업코드를 포함할 수 있다. OP_CHECKSIG는 서명이 유효한지(1) 아닌지(0)에 의존하여 스택에 1 또는 0을 출력한다. 0은 서명이 유효하지 않음을 표시한다. OP_CHECKSIGVERIFY는 출력을 소비하고 0인 경우, 실행이 실패하게 한다.
제2 트랜잭션이 유효하기 위해, 검증 서브 스크립트에 의해 구성된 타겟 메시지가 메시지 서브 스크립트에 의해 구성된 후보 메시지와 매칭되어야 함을 알 수 있다. 따라서 후보 메시지의 상이한 부분들을 구성하는 데 재사용되는(또는 후보 메시지의 상이한 부분들로서 재사용되는) 후보 필드들의 세트가 제1 트랜잭션의 필드들인 경우, 이들은 또한 제2 트랜잭션의 필드들이어야 한다. 이는 타겟 메시지가 제2 트랜잭션의 실제 필드들에 기초하기 때문이다. 따라서 본 개시내용은 제1 트랜잭션의 일부(예컨대, 잠금 스크립트, 값, 출력 등)가 제2 트랜잭션의 동일한 부분으로서 또한 나타나는 것을 보장하는 데 사용될 수 있다. 다른 말로 하면, 제2 트랜잭션의 일부는 제1 트랜잭션의 일부와 동일해야 한다. 일반적으로, 제2 트랜잭션의 하나 이상의 부분들은 제1 트랜잭션의 하나 이상의 부분들과 동일하도록 강제될 수 있다.
위에서 언급된 바와 같이, 서명은 ECDSA 서명을 포함할 수 있다. 당업자는 ECDSA 서명 자체에 익숙할 것이다. 서명은 형태를 취할 것이며, 여기서 k는 임시 개인 키이고, a는 개인 키이고, z는 후보 메시지의 해시이고, n은 타원 곡선 생성기 점 G의 정수 차수이고, r은 임시 공개 키 모듈로 n의 x 좌표이다. 위에서 또한 언급된 바와 같이, 임시 개인 키 k는 서명 생성을 최적화하기 위해 1로 세팅될 수 있다. 서명 생성을 추가로 최적화하기 위해 개인 키 a가 또한 1로 세팅될 수 있다.
개인 키와 임시 개인 키 둘 모두를 1로 고정하는 것은 서명이 형태를 취하도록 허용하며, 여기서 Gx는 타원 곡선 생성기 점 G의 x 좌표이다. 이는 G가 임시 공개 키 및 공개 키 둘 모두가 되는 효과를 갖는다. 제1 잠금 스크립트(예컨대, 서명 서브 스크립트)는 Gx 및 n의 개개의 값들을 포함할 수 있으며, 해당 값들에 기초하여 서명을 생성하도록 구성될 수 있다.
일부 예들에서, 서명 서브 스크립트는 Gx 및 n의 값들을 한 번 초과로 사용하도록 구성될 수 있다. 메모리가 스택 기반인 예들에서, 공간을 절감하기 위해 제1 잠금 스크립트에 Gx 및 n을 여러 번 포함하는 대신, 제1 잠금 스크립트(예컨대, 서명 서브 스크립트)는 Gx 및 n의 값들을 대안 스택(즉, 제1 잠금 스크립트가 처음 배치된 메인 스택이 이외의 스택)에 출력하고, 필요할 때 대안 스택으로부터 Gx 및 n의 값들을 리트리브하도록 구성될 수 있다.
개인 키 및 임시 개인 키 둘 모두가 동일한 값으로 고정될 때. 해당 값이 1이 아니더라도 절감이 이루어진다. 이는, 서명이 ECDSA 서명 또는 등가의 체계의 형태를 취할 때, 서명은 임시 개인 키 및 개인 키의 역에 기초하여 계산되기 때문이다. 따라서 키들 둘 모두를 동일한 값으로 고정하는 것은, 곱셈이 취소되고 이에 따라 프로세스로부터 2개의 수학적 연산들을 제거하는 효과를 갖는다. 따라서 스크립트에서 서명을 계산하는 것이 단순화된다. 게다가, "a=k"로부터의 절감은 또한, 압축된 공개 키 Gx가 서명 내 r과 동일하고, 이에 따라 (예컨대, 아래에 논의된 바와 같이 알트(alt) 스택을 활용함으로써) 동일한 값을 두 번 사용될 수 있다는 사실로부터 비롯된다.
블록체인 네트워크(106)의 특정 블록체인 프로토콜에 의존하여, 서명 서브 스크립트에 의해 생성된 서명은 예컨대, 검증 서브 스크립트에 의해 검증되기 위해 추가 프로세싱을 요구할 수 있다. 예컨대, 검증 서브 스크립트는 서명이 특정 포맷이 되도록 요구하는 서명 검증 기능(예컨대, 작업코드)을 포함할 수 있다. 예컨대, 서명은 DER(distinguishing encoding rules)에 따라 포맷팅될 필요가 있을 수 있다. 이러한 예들에서, 제1 잠금 스크립트는 서명 서브 스크립트에 의해 생성된 서명을 DER 포맷 서명으로 변환하도록 구성된 DER 서브 스크립트를 포함할 수 있다. DER 서브 스크립트는 서명 서브 스크립트의 일부일 수 있다. 검증 서브 스크립트는 공개 키(위에서 언급된 바와 같이, 일부 예들에서, 생성기 점 G일 수 있음)를 사용하여 DER 포맷 서명을 검증하도록 구성될 수 있다.
일부 예들에서, 서명 서브 스크립트는 서명 플래그를 포함할 수 있고, 서명 서브 스크립트는 생성된 서명과 서명 플래그를 연관(예컨대, 컨케터네이팅)시키도록 구성될 수 있다. 서명 플래그는 때때로 당해 기술 분야에서 "sighash 플래그"로서 지칭된다. 서명 플래그는 트랜잭션의 어느 부분들이 서명에 의해 서명된지를 표시한다. 예컨대, 서명 플래그는 특정 입력들 및/또는 출력들만이 서명에 의해 서명되거나 전체 트랜잭션이 서명으로 서명됨을 표시할 수 있다. 이 예에서 검증 서브 스크립트는 서명 플래그에 기초하여 타겟 메시지를 구성하도록 구성된다. 즉, 검증 서브 스크립트는 서명 서브 스크립트에 포함된 서명 플래그에 의존하여 제2 트랜잭션의 특정 부분들에 기초하여 타겟 메시지를 구성하도록 구성된다. 서명 서브 스크립트에 의해 유효한 서명으로 간주되기 위해, 제2 트랜잭션의 제1 잠금해제 스크립트(및 선택적으로 제1 트랜잭션의 제1 잠금 스크립트)에 포함된 후보 필드들은 타겟 메시지와 매칭되는 후보 메시지를 생성해야 한다. 즉, 후보 메시지는 타겟 메시지와 동일한 제2 트랜잭션의 부분들에 기초해야 하며, 여기서 이러한 부분들은 서명 플래그에 의해 지시된다.
예로서, 서명 플래그는 타겟 메시지가 제2 트랜잭션의 각각의 입력 및 각각의 출력에 기초해야 함을 표시할 수 있다. 이 경우에, 서명 플래그(예컨대, sighash 플래그)는 ALL일 수 있다. 다른 예로서, 서명 플래그는 타겟 메시지가 제1 잠금해제 스크립트를 포함하는 제2 트랜잭션의 입력 및 제2 트랜잭션의 대응하는 출력에만 기초해야 함을 표시할 수 있다. 이 경우 서명 플래그(예컨대, sighash 플래그)는 SINGLE|ANYONECANPAY일 수 있다.
다음 표는 후보(및 타겟) 메시지의 예시적인 포맷을 제공한다. 후보(및 타겟) 메시지는 표 내 항목들의 컨케터네이션일 수 있다. 항목들은 표 내 대응하는 번호에 기초하여 순서대로 나타날 수 있는데, 예컨대, 후보(및 타겟) 메시지는 버전 번호로 시작하고 sighash 플래그로 끝날 수 있다. 이는 단지 예일 뿐이며 모든 예들에서 제한하는 것으로 의도되지 않는다는 것에 주의한다. 예컨대, 항목들은 상이한 순서로 컨케터네이팅될 수 있거나, 후보(및 타겟) 메시지는 다음의 항목들 전부는 아니지만 일부를 포함할 수 있다.
항목들 잠금 스크립트에서 고정되는지 여부
1 버전 번호(리틀 엔디안의 4바이트) 선택적
2 입력 아웃포인트의 해시(32바이트) TxID의 순환 참조로 인해 실행 불가능
3 입력 시퀀스 번호들의 해시(32바이트) 선택적, 지출 트랜잭션에서 더 많은 유연성을 허용하기 위해 권장되지 않음
4 입력 아웃포인트(32바이트 + 리틀 엔디안의 4바이트) TxID의 순환 참조로 인해 실행 불가능(4바이트 인덱스는 선택적일 수 있음)
5 이전 잠금 스크립트의 길이(변수) 선택적, 단순화를 위해 권장되지 않음
6 이전 잠금 스크립트(변수) 잠금 스크립트의 순환 참조로 인해 실행 불가능
7 이전 잠금 스크립트의 값(리틀 엔디안의 8바이트) 선택적
8 시퀀스 번호(리틀 엔디안의 4바이트) 선택적
9 출력들의 해시(32바이트) 사전에 알려진 경우 선택적이고, 그렇지 않으면, 고정 실행 불가능.
10 잠금 시간(리틀 엔디안의 4바이트) 선택적
11 Sighash 플래그(리틀 엔디안의 4바이트) 더 많은 제한을 위해 고정되는 것을 권장함
이 예에서, "이전" 잠금 스크립트는 제1 트랜잭션의 제1 잠금 스크립트를 지칭한다. 다른 모든 항목들은 제2 트랜잭션 자체로부터 취해지거나 제2 트랜잭션에 기초한다. 이 표는 또한 항목이 제1 잠금 스크립트에서 고정될 수 있는지 여부를 도시한다. 예컨대, 제1 잠금 스크립트 자체에서 이전(즉, 제1) 잠금 스크립트를 고정하는 것은 가능하지 않다. 제1 잠금 스크립트는 잠금 스크립트에서 고정 가능한 위의 항목들 중 임의의 항목을 포함할 수 있다. 데이터 항목들 중 일부는 제1 또는 제2 트랜잭션의 필드들인 반면(예컨대, "잠금시간"은 제2 트랜잭션의 필드임), 데이터 항목 중 일부는 제1 또는 제2 트랜잭션의 하나 이상의 필드들에 기초한다(예컨대, "출력들의 해시"는 제2 트랜잭션의 출력들에 기초하며, 여기서 각각의 출력은 제2 트랜잭션의 필드임)는 것에 주의한다.
위에서 논의된 바와 같이, 제1 잠금 스크립트는 제2 트랜잭션의 제1 잠금해제 스크립트에 포함된 후보 필드들 중 하나 이상에 기초하여 후보 메시지의 일부(예컨대, 위의 표 내 항목들 중 하나)를 구성하도록 구성된다. 즉, 제1 잠금해제 스크립트는 후보 필드들의 세트를 포함할 수 있고, 제1 잠금 스크립트는 후보 필드들의 해당 세트를 프로세싱(결합, 컨케터네이팅 또는 해싱 등 중 하나 이상을 포함할 수 있음)하여 후보 메시지의 일부를 생성하면서, 후보 메시지의 상이한 부분으로서 후보 필드들의 해당 세트를 재사용한다. 예컨대, 제2 트랜잭션의 제1 잠금해제 스크립트는 후보 필드로서 제2 트랜잭션의 후보 출력을 표현하는 데이터 항목을 포함할 수 있고, 제1 트랜잭션의 제1 잠금 스크립트는 후보 출력을 위 표 내 항목들 5, 6, 7(제1 트랜잭션의 제1 출력을 표현함)로서 사용할 수 있고 위 표 내 항목 9(제2 트랜잭션의 출력의 해시를 표현함)를 구성하는 데 또한 사용할 수 있다. 이를 행하기 위해, 제1 잠금 스크립트(또는 오히려, 메시지 서브 스크립트)는 항목들 5, 6, 7을 결합 및 해싱하여 항목 9를 생성할 수 있다. 이는 제1 트랜잭션의 제1 출력이 제2 트랜잭션의 출력과 정확히 동일하다는 조건을 시행한다.
이는 일반적으로 필드들의 동일한 세트에 기초할 수 있는 후보 메시지의 임의의 부분에 적용된다는 것에 주의한다. 예컨대, 메시지 서브 스크립트는 이전 잠금 스크립트(항목 7)로서 후보 잠금 스크립트를 재사용하고 이전 잠금 스크립트의 후보 값을 재사용하지 않고 출력(들)(항목 9)의 해시를 생성하도록 구성될 수 있다. 이는 제2 트랜잭션이 제1 트랜잭션의 제1 잠금 스크립트를 포함하는 출력을 포함해야 하지만 출력의 값은 (블록체인 프로토콜의 규칙들 내에서) 마음대로 선택될 수 있다는 조건을 시행한다.
7. 예시적인 구현
다음은 설명된 실시예들의 예시적인 구현을 설명한다.
7.1 인 -스크립트로 서명의 생성
제1 트랜잭션의 제1 잠금 스크립트 하나의 기능은 주어진 메시지 m에 대한 서명을 생성하는 것이다. 다음 스크립트 세그먼트는 제1 잠금 스크립트의 일부이며 입력 데이터는 향후 트랜잭션의 잠금해제 스크립트에 있거나 제1 잠금 스크립트에 하드 코딩될 수 있다.
[sign]:= OP_HASH256 OP_MUL OP_ADD OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT
Input data:
잠금 스크립트의 일부로서 스크립트 세그먼트 [sign](위에서 "서명 서브 스크립트"로서 지칭됨)은 임시 키 k와 개인 키 a 둘 모두를 고정할 수 있다. 누구나 [sign]을 사용하여 유효한 서명을 생성할 수 있지만, 초점은 입력 m에 있다. 요건은 임의의 주어진 지출 트랜잭션에 대해 OP_CHECKSIG를 통과할 수 있는 단 하나의 m 값이 존재한다는 것이다. 개인 키 또는 공개 키가 고정되지 않는 경우, 트랜잭션이 안전하지 않을 것이다. 세부사항들은 섹션 8에서 또한 발견될 수 있다. 임시 키 k가 고정되지 않는 경우, 누구나 상이한 k를 사용하여 상이한 트랜잭션 ID로 유효한 트랜잭션을 생성할 수 있는데, 이는 일부 사용 사례들에서 바람직하지 않다.
서명 내 s 값은 으로서 계산될 수 있다. 진위를 위해 서명을 사용하지 않기 때문에, 개인 키 a 및 임시 키 k는 마음대로 선택되고 공개적으로 보여질 수 있다. 이러한 완화된 사례를 고려하여, 및 을 미리 계산하여 이를 잠금 스크립트에 포함시켜 서명 생성을 훨씬 더 가볍게 만들 수 있다. 더욱이 k 및 a에 대해 1과 같은 작은 값들을 선택할 수 있으며 이들은 매번 동일할 수 있다. k=a=1이면 이며, 여기서 Gx는 생성기 점 G의 x 좌표이다. 압축된 공개 키가 또한 Gx일 것이다. [sign]의 정의는 다음과 같이 재작성될 수 있다:
[sign]:= OP_HASH256 OP_ADD OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT
스크립트 세그먼트 [toDER]는 쌍 (r,s)을 OP_CHECKSIG에 의해 수락되는 표준 DER 포맷으로 변환하는 것이다. 이는 트랜잭션 ID 가단성을 회피하기 위해 s를 0과 n/2 사이의 범위에 있도록 강제한다.
[sign] 내 SIGHASH_FLAG는 지출 트랜잭션의 어느 부분이 스택에 푸시되어야 하는지를 지정하는 데 사용된다는 것에 주의한다. 플래그 ALL는 모든 입력들 및 출력들이 메시지 m에 포함될 것을 요구할 것인 반면, SINGLE|ANYONECANPAY는 이 잠금 스크립트에 대응하는 입력 및 그의 페어링된 출력이 m에 포함될 것을 요구할 것이다.
입력 m으로 스크립트 세그먼트 OP_DUP [sign] 실행한 후, 아래로부터 위까지 스택이 [m, Sig, PK]처럼 보일 것이다. OP_CEHCKSIGVERIFY를 호출하는 것은 서명 및 공개 키를 소비하여 m은 스택 맨 위에 남게 된다. 검증이 성공적인 경우, 스택 상에 남겨진 메시지 m은 지출 트랜잭션을 정확한 표현인 것으로 확신될 수 있다.
7.2 인 -스크립트로 메시지의 구성
직렬화된 포맷의 서명된 메시지는 직렬화된 트랜잭션과 상이하다. 후자는 트랜잭션에 관한 모든 정보를 제공하는 반면, 서명된 메시지는 의도치 않게 해시 값들에서 트랜잭션에 관한 일부 정보를 숨기고 지출되는 출력에 관한 일부 정보 즉, 그의 값 및 그의 잠금 스크립트를 제공한다. 메시지 m은 잠금 스크립트 자체 및 향후 지출 트랜잭션에 대한 일부 미지의 정보를 포함하므로 잠금 스크립트에 완전히 매립될 수 없다. 필드들 중 일부만 예컨대, 버전, 시퀀스 번호 또는 잠금 시간만이 잠금 스크립트에서 명시적으로 시행될 수 있다. 메시지 m은 잠금해제 스크립트에 전체로 제공되거나 잠금해제 스크립트의 일부 입력들 및 잠금 스크립트로부터의 명령들을 사용하여 스크립트로 구성된다. 우리는 지출 트랜잭션의 관점에서 볼 때 더 제한적인 후자에 중점을 둘 것이다. 섹션 6의 위 표는 메시지의 모든 데이터 필드들 및 해당 필드들이 잠금 스크립트에서 고정되어야 하는지 또는 고정될 수 있는지를 캡처한다.
이제부터, 표의 데이터 필드들은 항목 1, 2, 3 등으로서 지칭될 것이다. 잠금 스크립트에 항목을 포함시키는 것이 선택적인 경우, 해당 항목이 잠금 또는 잠금해제 스크립트에 제공되는지는 사용 사례에 의존할 것이다. 일반적인 규칙은 잠금 스크립트를 생성하는 시간에 데이터가 사용 가능하거나 알려진 경우, 데이터는 잠금 스크립트에 포함될 수 있다는 것이다. 고려해야 할 다른 양상은 트랜잭션의 크기 및 그의 지출 트랜잭션이다. 잠금 스크립트와 잠금해제 스크립트 사이에서 데이터를 시프트함으로써, 두 트랜잭션들의 전송자들 간에 트랜잭션 수수료 비용의 일부를 시프트할 수 있다.
순환 참조로 인해 실행 불가능하다고 말할 때, 세분성은 날짜 필드들에 세팅된다는 것에 주의한다. 예컨대, 요구되는 경우 부분 잠금 스크립트 또는 심지어 부분 트랜잭션 ID(예컨대, 처음 2바이트 고정 및 넌스(nonce) 필드를 통한 반복 허용)는 잠금 스크립트에서 고정할 수 있다.
초점은 메시지 m을 구성하는 것이지만, 목표는 m을 사용하여 현재 트랜잭션 내 상이한 필드들에 대해 값들을 시행하는 것이다. 해시 값 뒤의 데이터 즉 항목 9를 시행하기 위해, 잠금 스크립트는 프리이미지를 요청하고 이를 인-스크립트로 해싱하고 그 후 인-스크립트로 서명되도록 메시지를 구성하도록 설계되어야 한다. 항목 9를 예로 들면, 현재 트랜잭션에서 출력을 시행하기 위해, 우리는 다음을 가질 수 있다:
[outputsRequest]:= OP_DUP OP_HASH256 OP_ROT OP_SWAP OP_CAT <item 10 and 11> OP_CAT
Input data: <item 1 to 8> <serialised outputs in current transaction>
스크립트 세그먼트 [outputsRequest](이는 "메시지 서브 스크립트"의 일부일 수 있음)는 항목 1 내지 8 및 스택 상의 직렬화된 출력을 취하여 항목 9를 구성하고 항목 10 및 11을 컨케터네이팅하여 인-스크립트의 메시지 m을 획득한다. [outputsRequest] 이후 [sign] <Gx> OP_CHECKSIGVERIFY를 호출하고 검증을 통과함으로써, 스택 맨 위에 남아 있는 직렬화된 출력들이 현재 트랜잭션의 출력들의 실제 표현이라는 것이 확신될 수 있다.
비교를 위해 스택 상에 <항목 1 내지 7>의 사본을 남겨두는 것이 또한 매우 유용하다. 이는 아래와 같이 스크립트 세그먼트를 수정함으로써 달성될 수 있다:
[outputsRequest]:= OP_2DUP OP_HASH256 OP_SWAP <item 8> OP_CAT OP_SWAP OP_CAT <item 10 and 11> OP_CAT
Input data: <item 1 to 7> <serialised outputs in current transaction>
입력 데이터 상에서 수정된 [outputsRequest]를 실행한 후, 우리는 [sign] <Gx> OP_CHECKSIGVERIFY를 호출하여 메시지를 소비한다. 스택 맨 위에는 현재 직렬화된 출력들이 있고 그 뒤에는 <item 1 to 7>가 이어진다.
이는 연속적인 항목들이 <item 1 to 7>에서와 같이 그룹화되는 경우 더 간단하다. 이들은 모두 잠금해제 스크립트에 있거나 모두 잠금 스크립트에 고정된다. 그러나 더 복잡한 스크립트를 갖는 데 따른 잠재적인 비용으로 더 세부적인 접근법이 사용될 수 있다.
현재 출력들에 대한 직렬화 포맷은 다음과 같다는 것에 주의한다:
a. 출력 8 바이트(리틀 엔디안)의 값,
b. 잠금 스크립트의 길이,
c. 잠금 스크립트, 및
d. 출력이 하나 초과인 경우 직렬화된 출력들을 순서대로 컨케터네이팅하는 것.
서명된 메시지의 이전 출력(항목 5 내지 7)에 대한 직렬화 포맷은 다음과 같다:
a. 잠금 스크립트의 길이,
b. 잠금 스크립트 및
c. 출력 8 바이트(리틀 엔디안)의 값.
다음 예에서, 우리는 이전 출력을 현재 지출 트랜잭션의 출력과 비교하여 동일하게 되도록 강제할 것이다. 2개의 포맷들은 비교를 위한 잠금 스크립트를 설계하는 데 유용할 것이다.
7.3 잠금 스크립트를 영구적으로 시행하기
앨리스가 루트 CA(Certificate Authority)이고 밥이 하위 CA라고 가정한다. 앨리스는 인증서들에 대한 증명들로서 트랜잭션을 온-체인으로 공개하도록 밥에 요구하는 일부 작업을 밥에게 위임할 것이다. 앨리스는 밥이 출력을 다른 곳에 지출하는 것을 원하지 않는다. 따라서 앨리스는 모든 후속 지출 트랜잭션들이 고정된 [P2PKH Bob] 잠금 스크립트 및 고정된 출력 값을 갖도록 강제할 것이다. 밥은 유효한 서명을 생성할 수 있으므로 그가 출력들을 지출할 수 있지만, 동일한 금액을 자신에게 전송하는 것 외에는 어떠한 출력도 선택할 수 없다.
앨리스는 도 6에 도시된 바와 같이 초기 트랜잭션을 구성한다.
스크립트 세그먼트들은 아래와 같이 정의된다:
[outputsRequest]:= OP_2DUP OP_HASH256 OP_SWAP <item 8> OP_CAT OP_SWAP OP_CAT <item 10 and 11> OP_CAT
[sign]:= OP_HASH256 OP_ADD OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT
[toDER]:= [toCanonical][concatenations]
[toCanonical]:= OP_DUP OP_GREATERTHAN OP_IF OP_SWAP OP_SUB OP_ENDIF
[concatenations]:= OP_SIZE OP_DUP <0x24> OP_ADD <0x30> OP_SWAP OP_CAT <0220||> OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
잠금 스크립트의 길이는 (7 + 12) + (6 + 32 + 32 + 33) + (6 + 32 + 32) + (11) + (15 + 34) + (14 + 20) = 286 = 0x011e이다.
항목 8은 0xFFFFFFFF일 수 있고, 항목 10은 0x00000000일 수 있고, 항목 11은 0x41000000일 수 있다는 것에 주의한다.
트랜잭션을 지출하기 위해, 밥은 도 7에 도시된 바와 같이 지출 트랜잭션을 생성한다. 도 7을 참조하면 입력의 Data1은 항목 1 내지 7을 표현하며 다음과 같이 작성될 수 있다:
010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504400000000011e{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}e803000000000000
항목 값
1 버전 01000000
2 입력 아웃포인트들의 해시 2268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b876
3 입력 시퀀스 번호들의 해시 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
4 입력 아웃포인트 00000000
5 이전 잠금 스크립트의 길이 011e
6 이전 잠금 스크립트 {[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
7 이전 잠금 스크립트의 값 e803000000000000
Data2는 TxID1의 출력(값 || 잠금 스크립트 길이 || 잠금 스크립트)을 표현하며 다음과 같이 작성될 수 있다:
e803000000000000011e{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
TxID1의 유효성 검증 동안 실행될 전체 스크립트는 다음과 같다:
[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG
처음 OP_CHECKSIGVERIFY 후에, 우리는 스택 상에(맨 위의 가장 오른쪽) 를 가질 것이다.
단계 스택 실행
1 OP_SWAP <0x68>
2 <0x68> OP_SPLIT OP_NIP
3
<
011e
{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
>
<e803000000000000>		 OP_8 OP_SPLIT OP_SWAP
4
<
011e
{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
e803000000000000
>		 OP_CAT
5
<
e803000000000000
011e
{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
>		 OP_EQUALVERIFY
6 OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG
7 True
TxID1의 크기는 버전+잠금시간+입력+출력=4 + 4 + (36 + 72 + 33 + 104+287+8+287 + 8 + 4) + (8 + 287) = 1142바이트이다.
현재 세팅을 고려하면, 밥은 트랜잭션 수수료를 커버하기 위해 자신의 입력을 추가할 수 있다. 앨리스가 스크립트 세그먼트 [sign]에서 SIGHASH_SINGLE|ANYONECANPAY를 사용하는 경우, 밥은 잔돈들을 수집하기 위해 다른 출력을 추가할 수 있다. 이는 유효하게 앨리스의 잠금 스크립트를 영구적으로 시행하게 한다. 이것은 앨리스와 밥 사이의 스마트 계약으로 간주될 수 있다.
잠금 스크립트가 트랜잭션 수수료를 고려하는 것이 또한 가능하다. 단계 3 이후, 스택 상의 최상부 요소는 이전 출력의 값이다. 단계 4의 컨케터네이션 이전에 <TxFee> OP_SUB를 추가함으로써, 밥이 이전 출력으로부터 트랜잭션 수수료를 지불하는 것을 허용한다. 이는 지출 대비 출력의 값의 감소로 이어질 것이며, 이는 밥이 받을 자격이 있는 지출들의 총 수를 세팅하므로 원하는 특징으로서 작용할 수 있다.
7.4 최적화
Data1은 Data2를 포함하므로, 우리는 Data1로부터 Data2를 구성할 수 있다. 즉, 현재 출력이 이전 출력과 동일하고, 이전 출력을 사용하여 메시지를 구성한다고 가정한다. 그것이 OP_CHECKSIG를 통과하는 경우, 두 출력들이 동일해야 한다. [outputsRequest]의 스크립트 세그먼트는 다음과 같이 다시 재작성될 수 있다:
[outputsRequest]:= OP_2DUP OP_CAT OP_TOALTSTACK OP_SWAP OP_CAT OP_HASH256 <item 8> OP_SWAP OP_CAT OP_FROMALTSTACK OP_SWAP OP_CAT OP_CAT <item 10 and 11> OP_CAT
Input data: <item 1 to 4> <item 5 and 6> <item 7>
이 새로운 [outputsRequest]를 사용하면, 우리는 TxID0 및 TxID1의 잠금 스크립트를 다음과 같이 업데이트할 수 있고:
[outputsRequest][sign] OP_CHECKSIGVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG
잠금해제 스크립트는 <SigB> <PKB> <Data1> <Data2> <Data3>로서 업데이트되며, 여기서 Data1은 항목 1 내지 4:
010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504400000000이고
Data2는 항목 5 및 6:
011b{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}이고
Data3은 항목 7: e803000000000000이다.
TxID1의 크기는 941바이트이다. 단계별 실행은 아래에 주어지며, 여기서 단계 1 내지 5는 [outputsRequest]로부터 나온다.
단계 스택들 실행
1 OP_2DUP OP_CAT OP_TOALTSTACK
2
ALTSTACK: <item 5 to 7>		 OP_SWAP OP_CAT OP_HASH256
3 <item 9>
ALTSTACK: <item 5 to 7>		 <item 8> OP_SWAP OP_CAT
4 <item 8 and 9>
ALTSTACK: <item 5 to 7>		 OP_FROMALTSTACK OP_SWAP OP_CAT
5 <item 5 to 9> OP_CAT <item 10 and 11> OP_CAT
6 <item 1 to 11> [sign] OP_CHECKSIGVERIFY
7 OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG
8 True
Gx 및 n을 저장하기 위해 알트 스택을 사용함으로써 추가 개선이 이루어질 수 있다. 이들 각각의 크기는 32바이트이다. Gcompress는 Gx이고 는 n으로부터 도출될 수 있으므로, 우리는 여러 작업코드들을 사용하여 알트 스택으로부터 이들을 참조할 수 있다.
Before:
[sign]:= OP_HASH256 OP_ADD OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT
[toDER]:= [toCanonical][concatenations]
[toCanonical]:= OP_DUP OP_GREATERTHAN OP_IF OP_SWAP OP_SUB OP_ENDIF
[concatenations]:= OP_SIZE OP_DUP <0x24> OP_ADD <0x30> OP_SWAP OP_CAT <0220||Gx> OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
After:
[sign]:= OP_HASH256 OP_DUP OP_TOALTSTACK OP_ADD OP_DUP OP_TOALTSTACK OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT OP_FROMALTSTACK
[toDER]:= [toCanonical][concatenations]
[toCanonical]:= OP_DUP OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_2 OP_DIV OP_GREATERTHAN OP_IF OP_FROMALTSTACK OP_SWAP OP_SUB OP_ENDIF
[concatenations]:= OP_SIZE OP_DUP <0x24> OP_ADD <0x30> OP_SWAP OP_CAT <0220> OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_CAT OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
우리는 15개의 작업코드들을 추가하고 Gx의 2개의 인스턴스들 및 n의 2개의 인스턴스들을 제거했다. 총 절감은 바이트이다. 따라서 지출 트랜잭션 TxID1의 크기는 828바이트로 추가로 감소될 수 있다.
도 8은 지출 트랜잭션의 최적화된 버전을 예시한다.
8. 보안 분석
주장 1: (r,s)가 메시지들 m 및 m' 둘 모두에 대해 공개 키 P와 관련하여 유효한 서명인 경우 m=m'이다.
증명: 및 라고 하자.
, , 및 라고 하자.
따라서, 우리는 다음을 갖는다: .
〓〉
〓〉
〓〉
〓〉 .
주장 2: 공개 키 P는 잠금 스크립트에서 고정되어야 한다.
추리:
P가 고정되지 않고 (r,s)가 m에 대해 P와 관련하여 유효한 서명이라고 가정한다.
. , and 라고 하자.
우리는 이 되도록 하는 P'를 찾고자 한다.
이제 (r,s)는 m'에 대해 P'와 관련하여 유효하다.
따라서 P는 잠금 스크립트에서 고정되어야 한다.
주장 3: k는 잠금 스크립트에서 고정되어야 한다.
추리:
(r,s)가 m에 대해 P와 관련하여 잠금 스크립트에서 생성된 유효한 서명이라고 가정합니다.
k가 잠금 스크립트에 고정되지 않고 잠금해제 스크립트에 제공된다고 가정한다.
그러면 공격자는 다음을 수행할 수 있다:
1. 지출 트랜잭션을 가로채고,
2. 잠금해제 스크립트에서 k를 k'로 대체한다.
그러면 잠금 스크립트에서 생성된 는 m에 대해 P와 관련하여 유효한 서명일 것이다.
트랜잭션은 여전히 유효할 것이지만 트랜잭션 ID가 변경된다.
주장 4: sighash 플래그는 잠금 스크립트에서 고정되어야 한다.
추리:
(r,s)가 m의 P와 관련하여 잠금 스크립트에서 생성된 유효한 서명이라고 가정한다.
sighash 플래그가 잠금 스크립트에 고정되지 않고 잠금해제 스크립트에 제공된다고 가정한다.
1. 지출 트랜잭션을 가로채고
2. sighash 플래그 변경하고
3. 에 따라 메시지 m을 업데이트한다.
일부 사용 사례에서, 이는 트랜잭션을 무효화할 것이다. 예컨대, 잠금 스크립트는 sighash 플래그 "ALL"을 갖는 다수의 입력들 및 출력들을 예상하고; 플래그를 다른 것으로 변경하는 것은 스크립트 실행을 무효화할 것이다.
다른 경우에, 이는 트랜잭션을 무효화하지 않고 트랜잭션 ID를 변경할 것이다. 예컨대, 잠금 스크립트는 그의 지출 트랜잭션의 출력들에만 조건들을 시행하고; "ANYONECANPAY"를 추가하거나 제거하는 것은 트랜잭션을 무효화하는 것이 아니라 트랜잭션 ID를 변경할 것이다.
9. 예시적인 스크립트들
테스트들은 크기 1415 바이트의 지출 트랜잭션을 달성하는 것이 가능한 것으로 나타났다. 오버헤드는 주로 엔디안 반전(reversing endianness)으로부터 발생한다. 32바이트 문자열은 그의 엔디안을 반전하기 위해 124바이트의 작업코드들을 요구할 것이고, 일부 예들에서, 잠금 스크립트에서 두 문자열들의 엔디안을 반전하는 것이 필수적이다. 잠금 스크립트는 잠금해제 스크립트 및 출력 둘 모두에 나타난다. 따라서 우리 구현에서 엔디안으로부터의 총 오버헤드는 500바이트 초과이다. 단순화를 위해 우리 현재 구현에서 알트 스택을 사용하여 Gx와 n 및 저장하지 않았다. 이는 총 200바이트가 절감될 것이다.
9.1 잠금 스크립트 1(LS1) ― generateSig 및 checkSig
"aa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac"
입력: 섹션 6의 표에 도시된 바와 같이 서명을 위한 직렬화된 트랜잭션 메시지
잠금 스크립트는 메시지 m을 취하고,
1. z를 획득하기 위해 m에 대해 이중(double) SHA256을 적용하고,
2. z의 엔디안을 반전하고,
3. z가 음수로 해석되지 않도록 보장하기 위해 0x00을 추가하고,
4. z 상에서 최소 인코딩을 갖도록 OP_BIN2NUM을 호출하고(단계 3에서 중복성이 도입되는 경우를 고려함),
5. 을 컴퓨팅하고,
6. 이면 s를 로 변환하고,
7. s의 길이를 획득하고,
8. s(32바이트)의 엔디안을 반전하고,
9. s의 길이가 32보다 큰 경우 1 이상의 바이트를 반전시키고,
10. DER 서명의 총 길이(0x24 + s의 길이)를 컴퓨팅하고,
11. DER 프리픽스 0x30을 추가하고,
12. r=Gx를 컨케터네이팅하고,
13. s를 컨케터네이팅하고,
14. sighash 플래그 "ALL"을 컨케터네이팅하고,
15. 압축된 공개 키 Gx를 푸시하고,
16. OP_CHECKSIG를 호출한다.
9.2 잠금 스크립트 2(LS2) ― constructionMsg + LS1 + P2PKH
"6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac"
Input: <> <> <Item 1 to 4> <Item 5 and 6> <Item 7>
잠금 스크립트는 3개의 PUSHDATA 동작들에서 섹션 6의 표에서와 같이 항목 1 내지 7 및 한 쌍의 서명 및 공개 키를 취하고,
1. 이전 값을 취해 새로운 출력 값을 산출하고(고정된 트랜잭션 수수료를 차감함),
2. 새로운 출력에 대한 새로운 잠금 스크립트로서 이전 잠금 스크립트를 취하고,
3. 새로운 출력 값 및 새로운 잠금 스크립트를 컨케터네이팅하여 새로운 출력을 획득하고,
4. 새로운 출력에 이중 SHA256를 적용하여 출력들의 해시(항목 9)를 획득하고,
5. 시퀀스 번호(항목 8)를 푸시하고,
6. 컨케터네이팅하여 메시지 문자열(항목 1 내지 9)을 가져오고,
7. 잠금 시간 및 sigahash 플래그(항목 10 및 11)를 푸시하고,
8. 컨케터네이팅하여 서명된 m이 될 메시지를 획득하고,
9. OP_CHECKSIGVERIFY를 갖는 LS1을 호출하고,
10. P2PKH를 호출하여 PK와 관련하여 Sig를 체크한다.
9.3 트랜잭션 0 ― 제네시스 트랜잭션
{
"txid": "88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34",
"hash": "88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34",
"version": 1,
"size": 730,
"locktime": 0,
"vin": [
{
"txid": "52685bdbaae5c76887c23cee699bc48f293192a313c19b9fad4c77b993655df5",
"vout": 0,
"scriptSig": {
"asm": "3044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a5[ALL|FORKID] 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
"hex": "473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a541210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798"
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 49.99999388,
"n": 0,
"scriptPubKey": {
"asm": "OP_2DUP OP_BIN2NUM 512 OP_SUB 8 OP_NUM2BIN OP_SWAP OP_CAT OP_HASH256 -2147483647 OP_SWAP OP_CAT OP_CAT OP_CAT OP_CAT 0000000041000000 OP_CAT OP_HASH256 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 0 OP_CAT OP_BIN2NUM 9817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be79 OP_ADD 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_MOD OP_DUP 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 2 OP_DIV OP_GREATERTHAN OP_IF 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_SWAP OP_SUB OP_ENDIF OP_SIZE OP_DUP OP_TOALTSTACK OP_TOALTSTACK 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF 1 OP_SPLIT OP_ENDIF OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF OP_SWAP OP_CAT OP_ENDIF OP_SIZE OP_DUP 36 OP_ADD 48 OP_SWAP OP_CAT 022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802 OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 65 OP_CAT 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIGVERIFY OP_DUP OP_HASH160 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac",
"type": "nonstandard"
}
}
],
"hex": "0100000001f55d6593b9774cad9f9bc113a39231298fc49b69ee3cc28768c7e5aadb5b6852000000006a473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a541210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ffffffff019cef052a01000000fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac00000000"
}
9.4 트랜잭션 1 ― 지출 트랜잭션
{
"txid": "c700e1d6c995e4c77014536d4431be84d7fb40d3fbef52ed85be2ad06414eac8",
"hash": "c700e1d6c995e4c77014536d4431be84d7fb40d3fbef52ed85be2ad06414eac8",
"version": 1,
"size": 1415,
"locktime": 0,
"vin": [
{
"txid": "88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34",
"vout": 0,
"scriptSig": {
"asm": "3044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817980220388bd5f619c02287145cf0bb3bc440f883b09e35e67a4adcf50635800219ed34[ALL|FORKID] 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 01000000fb472de1f838d9560dc7b19b1ab62b0c6ed60580779017d3cd32d22bcc051ce13bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504434ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b98800000000 fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac 9cef052a01000000",
"hex": "473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817980220388bd5f619c02287145cf0bb3bc440f883b09e35e67a4adcf50635800219ed3441210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817984c6801000000fb472de1f838d9560dc7b19b1ab62b0c6ed60580779017d3cd32d22bcc051ce13bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504434ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b988000000004d3502fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac089cef052a01000000"
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 49.99998876,
"n": 0,
"scriptPubKey": {
"asm": "OP_2DUP OP_BIN2NUM 512 OP_SUB 8 OP_NUM2BIN OP_SWAP OP_CAT OP_HASH256 -2147483647 OP_SWAP OP_CAT OP_CAT OP_CAT OP_CAT 0000000041000000 OP_CAT OP_HASH256 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 0 OP_CAT OP_BIN2NUM 9817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be79 OP_ADD 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_MOD OP_DUP 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 2 OP_DIV OP_GREATERTHAN OP_IF 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_SWAP OP_SUB OP_ENDIF OP_SIZE OP_DUP OP_TOALTSTACK OP_TOALTSTACK 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF 1 OP_SPLIT OP_ENDIF OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF OP_SWAP OP_CAT OP_ENDIF OP_SIZE OP_DUP 36 OP_ADD 48 OP_SWAP OP_CAT 022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802 OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 65 OP_CAT 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIGVERIFY OP_DUP OP_HASH160 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac",
"type": "nonstandard"
}
}
],
"hex": "010000000134ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b98800000000fd1503473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817980220388bd5f619c02287145cf0bb3bc440f883b09e35e67a4adcf50635800219ed3441210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817984c6801000000fb472de1f838d9560dc7b19b1ab62b0c6ed60580779017d3cd32d22bcc051ce13bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504434ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b988000000004d3502fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac089cef052a01000000ffffffff019ced052a01000000fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac00000000"
}
10. 결론
개시된 기술들의 다른 변형들 또는 사용 사례들은 본원에서의 개시가 주어지면 당업자에게 명백해질 수 있다. 본 개시내용의 범위는 설명된 실시예들에 의해 제한되는 것이 아니라 첨부된 청구항들에 의해서만 제한된다.
예컨대, 위의 일부 실시예들은 비트코인 네트워크(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. 제1 블록체인 트랜잭션을 사용하여 제2 블록체인 트랜잭션에 대해 조건들을 시행하는 컴퓨터 구현 방법으로서, 조건들 중 제1 조건은 제2 트랜잭션의 제1 잠금해제 스크립트가 제1 트랜잭션의 제1 잠금 스크립트와 함께 실행될 때, 제2 트랜잭션의 표현이 메모리에 출력되고, 표현은 제2 트랜잭션의 복수의 필드들 및 제1 트랜잭션의 제1 출력에 기초하고, 방법은,
제1 트랜잭션을 생성하는 단계를 포함하고, 제1 트랜잭션은 제1 출력을 포함하고, 제1 출력은 제1 잠금 스크립트를 포함하고, 제1 잠금 스크립트는:
실행될 때, 제2 트랜잭션을 표현하는 후보 메시지를 메모리에 출력하도록 구성된 메시지 서브 스크립트 ― 후보 메시지는 제1 및 제2 트랜잭션들의 복수의 후보 필드들에 기초하고, 후보 필드들 중 하나 이상은 제2 트랜잭션의 제1 잠금해제 스크립트에 포함되고, 메시지 서브 스크립트는 후보 필드들의 개개의 세트에 기초하여 후보 메시지의 하나 이상의 개개의 부분들을 생성하고, 후보 필드들의 개개의 세트들 중 적어도 하나를 후보 메시지의 상이한 개개의 부분으로서 재사용하도록 구성됨 ― ;
실행될 때, 서명을 생성하도록 구성된 서명 서브 스크립트 ― 서명은 적어도 후보 메시지, 개인 키 및 임시 개인 키의 함수임 ― ;
개인 키에 대응하는 공개 키; 및
실행될 때, i) 제2 트랜잭션을 표현하는 타겟 메시지를 구성하고 ― 타겟 메시지는 제2 트랜잭션의 복수의 필드들 및 제1 트랜잭션의 제1 출력에 기초함 ― , ii) 서명이 타겟 메시지에 대해 유효하다는 것을 검증하기 위해 공개 키를 사용하도록 구성된 검증 서브 스크립트를 포함하고, 서명이 타겟 메시지에 대해 유효하다는 것을 검증하는 것은 타겟 메시지가 후보 메시지와 매칭된다는 것을 검증하고, 그리하여 메모리에 출력된 후보 메시지가 제2 트랜잭션의 표현이라는 조건을 시행하는 것이다.
타겟 메시지가 후보 메시지와 매칭되고 해당 후보 메시지가 제2 트랜잭션의 표현임을 검증하는 것은 서명이 타겟 메시지에 대해 유효한 결과이다.
스테이트먼트 2. 스테이트먼트 1의 방법에 있어서,
상기 후보 메시지의 개개의 부분들 중 하나는 제2 트랜잭션의 하나 이상의 출력들의 해시를 포함하고,
후보 필드들의 제1 개개의 세트는 a) 제1 트랜잭션의 제1 잠금 스크립트의 개개의 길이, 및 b) 제1 트랜잭션의 제1 잠금 스크립트를 포함하고,
메시지 서브 스크립트는, 실행될 때, 후보 필드들 a) 및 b)에 기초하여 하나 이상의 출력들의 해시를 생성하고, 그리하여 제2 트랜잭션의 제1 출력이 제1 트랜잭션의 제1 잠금 스크립트를 포함한다는 조건을 시행하도록 구성된다.
스테이트먼트 3. 스테이트먼트 2의 방법에 있어서,
후보 필드들의 제1 개개의 세트는 c) 제1 트랜잭션의 제1 잠금 스크립트에 의해 잠금된 개개의 값을 포함하고, 그리고
메시지 서브 스크립트는, 실행될 때, 후보 필드들 a), b) 및 c)에 기초하여 하나 이상의 출력들의 해시를 생성하고, 그리하여 제2 트랜잭션의 제1 출력이 제1 트랜잭션의 제1 출력을 포함한다는 조건을 시행하도록 구성된다.
스테이트먼트 4. 임의의 선행 스테이트먼트의 방법에 있어서, 메시지 서브 스크립트는 후보 메시지의 하나 이상의 개개의 부분들 중 적어도 하나를 메모리에 출력하도록 구성된다.
스테이트먼트 5. 임의의 선행 스테이트먼트의 방법에 있어서, 메시지 서브 스크립트는, 실행될 때, 후보 메시지의 부분으로서 후보 메시지의 상이한 개개의 부분으로서 재사용될 후보 필드들의 적어도 하나 또는 개개의 세트들을 복제하도록 구성된다.
스테이트먼트 6. 임의의 선행 스테이트먼트의 방법에 있어서, 제1 잠금 스크립트는, 실행될 때, 서명을 DER(distinguished encoding rules) 포맷 서명으로 변환하도록 구성된 DER 서브 스크립트를 포함하고, 서명이 타겟 메시지에 대해 유효하다는 것을 검증하기 위해 공개 키를 사용하는 것은 DER 포맷 서명이 메시지에 유효하다는 것을 검증하기 위해 공개 키를 사용하는 것을 포함한다.
스테이트먼트 7. 임의의 선행 스테이트먼트의 방법에 있어서, 서명 서브 스크립트는 제2 트랜잭션의 복수의 필드들 중 어느 것이 타겟 메시지의 기초를 형성하는지를 지정하는 서명 플래그를 포함하고, 검증 서브 스크립트는 서명 플래그에 기초하여 타겟 메시지를 구성하도록 구성된다.
스테이트먼트 8. 스테이트먼트 7의 방법에 있어서, 서명 플래그는 제2 트랜잭션의 각각의 입력 및 각각의 출력이 타겟 메시지의 기초를 형성한다는 것을 지정한다.
스테이트먼트 9. 스테이트먼트 7의 방법에 있어서, 서명 플래그는 a) 제2 트랜잭션의 제1 잠금해제 스크립트를 포함하는 제1 입력, 및 b) 제1 입력과 페어링되는 제2의 제1 출력이 타겟 메시지의 기초를 형성한다는 것을 지정한다.
스테이트먼트 10. 임의의 선행 스테이트먼트의 방법에 있어서, 후보 필드들 중 하나 이상은 제1 트랜잭션의 제1 잠금 스크립트에 포함된다.
스테이트먼트 11. 스테이트먼트 10의 방법에 있어서, 다음 후보 필드들:
제2 트랜잭션의 버전 번호,
제1 트랜잭션의 제1 잠금 스크립트의 길이,
제1 트랜잭션의 제1 잠금 스크립트의 값,
제2 트랜잭션의 제1 입력의 시퀀스 번호,
제2 트랜잭션의 잠금 시간,
제2 트랜잭션의 제1 잠금해제 스크립트의 서명 플래그
중 하나 이상이 제1 트랜잭션의 제1 잠금 스크립트에 포함된다.
스테이트먼트 12. 임의의 선행 스테이트먼트의 방법에 있어서, 제2 트랜잭션을 표현하는 후보 메시지는 제2 트랜잭션의 하나 이상의 개개의 후보 필드들의 개개의 세트에 기초하는 하나 이상의 개개의 데이터 항목들을 포함한다.
스테이트먼트 13. 스테이트먼트 12의 방법에 있어서, 하나 이상의 각각의 데이터 항목들은:
제2 트랜잭션의 입력 시퀀스 번호들의 해시,
제2 트랜잭션의 결합된 출력들의 해시 중 하나 이상을 포함한다.
스테이트먼트 14. 임의의 선행 스테이트먼트의 방법에 있어서, 메모리는 스택 기반 메모리이다.
스테이트먼트 15. 스테이트먼트 14의 방법에 있어서, 서명 검증 서브 스크립트는 OP_CHECKSIGVERIFY 작업코드 및 OP_CHECKSIG 작업코드 중 적어도 하나를 포함한다.
스테이트먼트 16. 임의의 선행 스테이트먼트의 방법에 있어서, 블록체인 네트워크의 하나 이상의 노드들에 대해 제1 트랜잭션을 이용 가능하게 하는 단계를 포함한다.
스테이트먼트 17. 임의의 선행 스테이트먼트의 방법에 있어서, 제2 트랜잭션을 생성하기 위해 제1 트랜잭션을 당사자에 대해 이용 가능하게 하는 단계를 포함한다.
스테이트먼트 18. 임의의 선행 스테이트먼트의 방법에 있어서, 임시 개인 키는 제1 잠금 스크립트에 의해 1과 동일하게 고정되고 그리고/또는 임시 개인 키는 개인 키와 동일하게 고정된다.
스테이트먼트 19. 스테이트먼트 17의 방법에 있어서, 개인 키는 제1 잠금 스크립트에 의해 1과 동일하게 고정된다.
스테이트먼트 20. 스테이트먼트 18 또는 스테이트먼트 19의 방법에 있어서, 서명은 형태이고 여기서 k는 임시 개인 키이고, a는 개인 키이고, z는 후보 메시지의 해시이고, n은 타원 곡선 생성기 점 G의 정수 차수이고, r은 임시 공개 키 모듈로 n의 x 좌표이다.
스테이트먼트 21. 스테이트먼트 18 또는 이에 종속하는 임의의 스테이트먼트의 방법에 있어서, 서명은 형태이고, 여기서 Gx는 타원 곡선 생성기 점 G의 x 좌표이고, G는 임시 공개 키 및 공개 키 둘 모두이다.
스테이트먼트 22. 스테이트먼트 21의 방법에 있어서, 서명 서브 스크립트는 Gx 및 n의 개개의 값들을 포함하고, 서명은 Gx 및 n의 개개의 값들에 기초하여 생성된다.
스테이트먼트 23. 스테이트먼트 21 및 스테이트먼트 22의 방법에 있어서, 스택 기반 메모리는 메인 스택 및 대안 스택을 포함하고, 제1 잠금 스크립트는 Gx 및 n의 개개의 값들을 한번 초과로 사용하도록 구성되고, 제1 잠금 스크립트는, 실행될 때, Gx 및 n의 개개의 값들을 대안 스택에 출력하고, 초기 시간 외에 Gx 및 n의 개개의 값들이 요구될 때마다, 대안 스택으로부터 Gx 및 n의 개개의 값들을 획득하도록 구성된다.
스테이트먼트 24. 컴퓨터 장비로서,
하나 이상의 메모리 유닛을 포함하는 메모리; 및
하나 이상의 프로세싱 유닛을 포함하는 프로세싱 장치를 포함하고, 메모리는 프로세싱 장치에서 실행되도록 배열된 코드를 저장하고, 코드는 프로세싱 장치 상에 있을 때 스테이트먼트 1 내지 23 중 어느 하나의 방법을 수행하도록 구성된다.
스테이트먼트 25. 컴퓨터 판독 가능 저장소 상에서 구현되고, 하나 이상의 프로세서들 상에서 실행될 때, 스테이트먼트 1 내지 스테이트먼트 23 중 어느 하나의 방법을 수행하도록 구성된 컴퓨터 프로그램.

Claims (25)

  1. 제1 블록체인 트랜잭션을 사용하여 제2 블록체인 트랜잭션에 대해 조건들을 시행하는 컴퓨터 구현 방법으로서,
    상기 조건들 중 제1 조건은 상기 제2 트랜잭션의 제1 잠금해제 스크립트가 상기 제1 트랜잭션의 제1 잠금 스크립트와 함께 실행될 때, 상기 제2 트랜잭션의 표현이 메모리에 출력되고, 상기 표현은 상기 제2 트랜잭션의 복수의 필드들 및 상기 제1 트랜잭션의 제1 출력에 기초하고, 상기 방법은,
    상기 제1 트랜잭션을 생성하는 단계를 포함하고, 상기 제1 트랜잭션은 제1 출력을 포함하고, 상기 제1 출력은 상기 제1 잠금 스크립트를 포함하고, 상기 제1 잠금 스크립트는:
    실행될 때, 상기 제2 트랜잭션을 표현하는 후보 메시지를 메모리에 출력하도록 구성된 메시지 서브 스크립트 ― 상기 후보 메시지는 상기 제1 및 제2 트랜잭션들의 복수의 후보 필드들에 기초하고, 상기 후보 필드들 중 하나 이상은 상기 제2 트랜잭션의 제1 잠금해제 스크립트에 포함되고, 상기 메시지 서브 스크립트는 상기 후보 필드들의 개개의 세트에 기초하여 상기 후보 메시지의 하나 이상의 개개의 부분들을 생성하고, 상기 후보 필드들의 개개의 세트들 중 적어도 하나를 상기 후보 메시지의 상이한 개개의 부분으로서 재사용하도록 구성됨 ― ;
    실행될 때, 서명을 생성하도록 구성된 서명 서브 스크립트 ― 상기 서명은 적어도 상기 후보 메시지, 개인 키 및 임시 개인 키의 함수임 ― ;
    상기 개인 키에 대응하는 공개 키; 및
    실행될 때, i) 상기 제2 트랜잭션을 표현하는 타겟 메시지를 구성하고 ― 상기 타겟 메시지는 상기 제2 트랜잭션의 복수의 필드들 및 상기 제1 트랜잭션의 제1 출력에 기초함 ― , ii) 상기 서명이 상기 타겟 메시지에 대해 유효하다는 것을 검증하기 위해 상기 공개 키를 사용하도록 구성된 검증 서브 스크립트를 포함하고, 상기 서명이 상기 타겟 메시지에 대해 유효하다는 것을 검증하는 것은 상기 타겟 메시지가 상기 후보 메시지와 매칭된다는 것을 검증하고, 그리하여 상기 메모리에 출력된 후보 메시지가 상기 제2 트랜잭션의 표현이라는 조건을 시행하는 것인,
    컴퓨터 구현 방법.
  2. 제1항에 있어서,
    상기 후보 메시지의 개개의 부분들 중 하나는 상기 제2 트랜잭션의 하나 이상의 출력들의 해시를 포함하고,
    상기 후보 필드들의 제1 개개의 세트는 a) 상기 제1 트랜잭션의 제1 잠금 스크립트의 개개의 길이, 및 b) 상기 제1 트랜잭션의 제1 잠금 스크립트를 포함하고, 그리고
    상기 메시지 서브 스크립트는, 실행될 때, 후보 필드들 a) 및 b)에 기초하여 상기 하나 이상의 출력들의 해시를 생성하고, 그리하여 상기 제2 트랜잭션의 제1 출력이 상기 제1 트랜잭션의 제1 잠금 스크립트를 포함한다는 조건을 시행하도록 구성되는,
    컴퓨터 구현 방법.
  3. 제2항에 있어서,
    상기 후보 필드들의 제1 개개의 세트는 c) 상기 제1 트랜잭션의 제1 잠금 스크립트에 의해 잠금된 개개의 값을 포함하고, 그리고
    상기 메시지 서브 스크립트는, 실행될 때, 후보 필드들 a), b) 및 c)에 기초하여 상기 하나 이상의 출력들의 해시를 생성하고, 그리하여 상기 제2 트랜잭션의 제1 출력이 상기 제1 트랜잭션의 제1 출력을 포함한다는 조건을 시행하도록 구성되는,
    컴퓨터 구현 방법.
  4. 제1항 내지 제3항 중 어느 한 항에 있어서, 상기 메시지 서브 스크립트는 상기 후보 메시지의 하나 이상의 개개의 부분들 중 적어도 하나를 상기 메모리에 출력하도록 구성되는,
    컴퓨터 구현 방법.
  5. 제1항 내지 제4항 중 어느 한 항에 있어서, 상기 메시지 서브 스크립트는, 실행될 때, 상기 후보 메시지의 부분으로서 상기 후보 메시지의 상이한 개개의 부분으로서 재사용될 상기 후보 필드들의 적어도 하나 또는 개개의 세트들을 복제하도록 구성되는,
    컴퓨터 구현 방법.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 제1 잠금 스크립트는, 실행될 때, 상기 서명을 DER(distinguished encoding rules) 포맷 서명으로 변환하도록 구성된 DER 서브 스크립트를 포함하고, 상기 서명이 상기 타겟 메시지에 대해 유효하다는 것을 검증하기 위해 상기 공개 키를 사용하는 것은 상기 DER 포맷 서명이 상기 메시지에 유효하다는 것을 검증하기 위해 상기 공개 키를 사용하는 것을 포함하는,
    컴퓨터 구현 방법.
  7. 제1항 내지 제6항 중 어느 한 항에 있어서, 상기 서명 서브 스크립트는 상기 제2 트랜잭션의 복수의 필드들 중 어느 것이 상기 타겟 메시지의 기초를 형성하는지를 지정하는 서명 플래그를 포함하고, 상기 검증 서브 스크립트는 상기 서명 플래그에 기초하여 상기 타겟 메시지를 구성하도록 구성되는,
    컴퓨터 구현 방법.
  8. 제7항에 있어서, 상기 서명 플래그는 상기 제2 트랜잭션의 각각의 입력 및 각각의 출력이 상기 타겟 메시지의 기초를 형성한다는 것을 지정하는,
    컴퓨터 구현 방법.
  9. 제7항에 있어서, 상기 서명 플래그는 a) 상기 제2 트랜잭션의 제1 잠금해제 스크립트를 포함하는 제1 입력, 및 b) 상기 제1 입력과 페어링되는 제2의 제1 출력이 상기 타겟 메시지의 기초를 형성한다는 것을 지정하는,
    컴퓨터 구현 방법.
  10. 제1항 내지 제9항 중 어느 한 항에 있어서, 상기 후보 필드들 중 하나 이상은 상기 제1 트랜잭션의 상기 제1 잠금 스크립트에 포함되는,
    컴퓨터 구현 방법.
  11. 제10항에 있어서, 다음 후보 필드들:
    상기 제2 트랜잭션의 버전 번호,
    상기 제1 트랜잭션의 제1 잠금 스크립트의 길이,
    상기 제1 트랜잭션의 제1 잠금 스크립트의 값,
    상기 제2 트랜잭션의 제1 입력의 시퀀스 번호,
    상기 제2 트랜잭션의 잠금 시간,
    상기 제2 트랜잭션의 제1 잠금해제 스크립트의 서명 플래그
    중 하나 이상이 제1 트랜잭션의 제1 잠금 스크립트에 포함되는,
    컴퓨터 구현 방법.
  12. 제1항 내지 제11항 중 어느 한 항에 있어서, 상기 제2 트랜잭션을 표현하는 후보 메시지는 상기 제2 트랜잭션의 하나 이상의 개개의 후보 필드들의 개개의 세트에 기초하는 하나 이상의 개개의 데이터 항목들을 포함하는,
    컴퓨터 구현 방법.
  13. 제12항에 있어서, 상기 하나 이상의 각각의 데이터 항목들은:
    상기 제2 트랜잭션의 입력 시퀀스 번호들의 해시,
    상기 제2 트랜잭션의 결합된 출력들의 해시 중 하나 이상을 포함하는,
    컴퓨터 구현 방법.
  14. 제1항 내지 제13항 중 어느 한 항에 있어서, 상기 메모리는 스택 기반 메모리인,
    컴퓨터 구현 방법.
  15. 제14항에 있어서, 상기 서명 검증 서브 스크립트는 OP_CHECKSIGVERIFY 작업코드 및 OP_CHECKSIG 작업코드 중 적어도 하나를 포함하는,
    컴퓨터 구현 방법.
  16. 제1항 내지 제15항 중 어느 한 항에 있어서, 블록체인 네트워크의 하나 이상의 노드들에 대해 상기 제1 트랜잭션을 이용 가능하게 하는 단계를 포함하는,
    컴퓨터 구현 방법.
  17. 제1항 내지 제16항 중 어느 한 항에 있어서, 상기 제2 트랜잭션을 생성하기 위해 상기 제1 트랜잭션을 당사자에 대해 이용 가능하게 하는 단계를 포함하는,
    컴퓨터 구현 방법.
  18. 제1항 내지 제17항 중 어느 한 항에 있어서, 상기 임시 개인 키는 상기 제1 잠금 스크립트에 의해 1과 동일하게 고정되고 그리고/또는 상기 임시 개인 키는 상기 개인 키와 동일하게 고정되는,
    컴퓨터 구현 방법.
  19. 제18항에 있어서, 상기 개인 키는 상기 제1 잠금 스크립트에 의해 1과 동일하게 고정되는,
    컴퓨터 구현 방법.
  20. 제18항 또는 제19항에 있어서, 상기 서명은 형태이고 여기서 k는 상기 임시 개인 키이고, a는 상기 개인 키이고, z는 상기 후보 메시지의 해시이고, n은 타원 곡선 생성기 점 G의 정수 차수이고, r은 임시 공개 키 모듈로 n의 x 좌표인,
    컴퓨터 구현 방법.
  21. 제18항 또는 제18항에 종속하는 어느 한 항에 있어서, 상기 서명은 형태이고, 여기서 Gx는 타원 곡선 생성기 점 G의 x 좌표이고, G는 상기 임시 공개 키 및 상기 공개 키 둘 모두인,
    컴퓨터 구현 방법.
  22. 제21항에 있어서, 상기 서명 서브 스크립트는 Gx 및 n의 개개의 값들을 포함하고, 상기 서명은 상기 Gx 및 n의 개개의 값들에 기초하여 생성되는,
    컴퓨터 구현 방법.
  23. 제21항 및 제22항에 있어서, 상기 스택 기반 메모리는 메인 스택 및 대안 스택을 포함하고, 상기 제1 잠금 스크립트는 Gx 및 n의 개개의 값들을 한번 초과로 사용하도록 구성되고, 상기 제1 잠금 스크립트는, 실행될 때, 상기 Gx 및 n의 개개의 값들을 상기 대안 스택에 출력하고, 초기 시간 외에 상기 Gx 및 n의 개개의 값들이 요구될 때마다, 상기 대안 스택으로부터 상기 Gx 및 n의 개개의 값들을 획득하도록 구성되는,
    컴퓨터 구현 방법.
  24. 컴퓨터 장비로서,
    하나 이상의 메모리 유닛을 포함하는 메모리; 및
    하나 이상의 프로세싱 유닛을 포함하는 프로세싱 장치를 포함하고, 상기 메모리는 상기 프로세싱 장치 상에서 실행되도록 배열된 코드를 저장하고, 상기 코드는 프로세싱 장치 상에 있을 때 제1항 내지 제23항 중 어느 한 항의 방법을 수행하도록 구성되는,
    컴퓨터 장비.
  25. 컴퓨터 판독 가능 저장소 상에서 구현되고, 하나 이상의 프로세서들 상에서 실행될 때, 제1항 내지 제23항 중 어느 한 항의 방법을 수행하도록 구성된 컴퓨터 프로그램.
KR1020247004674A 2021-07-19 2022-06-20 블록체인 트랜잭션들에 대한 조건들의 시행 KR20240034793A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2110348.6 2021-07-19
GB2110348.6A GB2609194A (en) 2021-07-19 2021-07-19 Enforcing conditions on blockchain transactions
PCT/EP2022/066649 WO2023001461A1 (en) 2021-07-19 2022-06-20 Enforcing conditions on blockchain transactions

Publications (1)

Publication Number Publication Date
KR20240034793A true KR20240034793A (ko) 2024-03-14

Family

ID=77443449

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020247004674A KR20240034793A (ko) 2021-07-19 2022-06-20 블록체인 트랜잭션들에 대한 조건들의 시행

Country Status (8)

Country Link
US (1) US20240333503A1 (ko)
EP (1) EP4374535A1 (ko)
JP (1) JP2024525888A (ko)
KR (1) KR20240034793A (ko)
CN (1) CN117693923A (ko)
GB (1) GB2609194A (ko)
TW (1) TW202318444A (ko)
WO (1) WO2023001461A1 (ko)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10569088B2 (en) 2016-09-16 2020-02-25 Medtronic, Inc. Dorsal spinal column characterization with evoked potentials
US10327154B2 (en) 2016-09-16 2019-06-18 Qualcomm Incorporated Beam switching
WO2018053335A1 (en) 2016-09-16 2018-03-22 Iogen Llc Oral molecular iodine composition and method
JP7088913B2 (ja) 2016-09-16 2022-06-21 オラクル・インターナショナル・コーポレイション 脅威を検出するための動的ポリシーの導入およびアクセスの可視化
WO2018056430A1 (ja) 2016-09-23 2018-03-29 株式会社Ｄｎａチップ研究所 気分障害を検出する方法
JPWO2018056432A1 (ja) 2016-09-26 2019-07-04 東レ株式会社 血液検体の溶血を検出する方法及び溶血検出用チップ
JP6913956B2 (ja) 2016-09-26 2021-08-04 池田食研株式会社 Ｌ−キヌレニンの測定方法及び測定キット
CN118569851A (zh) * 2017-05-22 2024-08-30 区块链控股有限公司 将未确定来源的未确定数据安全地提供到区块链交易的锁定脚本中
WO2018215947A1 (en) * 2017-05-26 2018-11-29 nChain Holdings Limited Script-based blockchain interaction
GB2592338A (en) * 2019-07-25 2021-09-01 Nchain Holdings Ltd Digital contracts using blockchain transactions
EP4256751A1 (en) * 2020-12-02 2023-10-11 Trock, Stanislav Blockchain

Also Published As

Publication number Publication date
US20240333503A1 (en) 2024-10-03
CN117693923A (zh) 2024-03-12
JP2024525888A (ja) 2024-07-12
WO2023001461A1 (en) 2023-01-26
GB2609194A (en) 2023-02-01
TW202318444A (zh) 2023-05-01
EP4374535A1 (en) 2024-05-29
GB202110348D0 (en) 2021-09-01

Similar Documents

Publication Publication Date Title
KR20230121100A (ko) 블록체인 트랜잭션들의 생성 및 유효성 검증
US20230134619A1 (en) Method of generating a hash-based message authentication code
US20240281806A1 (en) Multi-party blockchain address scheme
WO2023117230A1 (en) Blockchain transaction
WO2022135812A1 (en) Multisignature transactions
JP2023529467A (ja) カスタムトランザクションスクリプト
KR20240034793A (ko) 블록체인 트랜잭션들에 대한 조건들의 시행
KR20240037243A (ko) 블록체인 트랜잭션들에 대한 조건들의 시행
US20240214179A1 (en) Blockchain-implemented hash function
US20240235848A1 (en) Multi-party blockchain address scheme
JP2024516895A (ja) マルチパーティブロックチェーンアドレス方式
WO2024017786A1 (en) Proving and verifying input data
WO2023156099A1 (en) Identity-linked blockchain addresses
WO2023117274A1 (en) Signature-based atomic swap
EP4454195A1 (en) Signature-based atomic swap
WO2023135217A1 (en) Proving and verifying an ordered sequence of events
EP4454194A1 (en) Blockchain transaction
WO2024199871A1 (en) Methods performed by a computing device
GB2606194A (en) Methods and devices for pruning stored merkle tree data
CN117121434A (zh) 区块链实现的散列函数