KR20230044262A - 블록체인 토큰들 - Google Patents

블록체인 토큰들 Download PDF

Info

Publication number
KR20230044262A
KR20230044262A KR1020237006558A KR20237006558A KR20230044262A KR 20230044262 A KR20230044262 A KR 20230044262A KR 1020237006558 A KR1020237006558 A KR 1020237006558A KR 20237006558 A KR20237006558 A KR 20237006558A KR 20230044262 A KR20230044262 A KR 20230044262A
Authority
KR
South Korea
Prior art keywords
token
transaction
script
output
component
Prior art date
Application number
KR1020237006558A
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 KR20230044262A publication Critical patent/KR20230044262A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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
    • 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
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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
    • H04L9/3239—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 involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

토큰 트랜잭션은 제1 토큰 출력을 포함하고, 제1 토큰 출력은 제1 토큰 잠금 스크립트 및 제1 토큰 금액을 포함하고, 제1 토큰 잠금 스크립트는 가변 구성요소 및 불변 구성요소를 포함하고, 가변 구성요소는 지불 템플릿에 매립되는 제1 지불 주소를 포함하고, 불변 구성요소는 토큰 역학 하위 구성요소를 포함한다.

Description

블록체인 토큰들
본 개시내용은 블록체인 트랜잭션들을 이용하여 토큰들을 전송(예컨대, 발행, 이전, 분할, 스왑, 상환)하는 방법에 관한 것이다.
블록체인은 트랜잭션들을 사용하여 기본 디지털 자산의 이전을 가능하게 한다. 이 디지털 자산은 종종 "암호화폐" 또는 "네이티브 토큰(native token)"으로서 지칭된다. 이는 특정 블록체인에 고유한 디지털 자산이다. 예시적인 예로서, 비트코인 블록체인의 디지털 자산은 비트코인으로서 알려져 있다.
블록체인을 사용하여 이전될 수 있는 다른 유형의 디지털 자산은 "토큰"이다. 블록체인 기술의 맥락에서, 토큰은 일반적으로 트랜잭션 내의 부가적인 데이터 필드들을 사용하여 생성 및 정의된다. "토큰 데이터"라고 하는 이 부가적인 데이터는 블록체인의 사용자들 또는 특정 토큰 프로토콜의 사용자들에 의해 토큰으로서 해석된다. 즉, 사용자들이 특정 토큰 데이터(예컨대, 금액이 뒤따르는 토큰 프로토콜 플래그)를 포함하는 트랜잭션, 또는 보다 구체적으로 트랜잭션의 출력 부분이 토큰으로서 해석되고 토큰으로서 사용된다는 데 동의한다. 출력을 소유한 사람 ― 이는 일반적으로 출력이 잠겨 있는 주소의 사용자를 의미함 ― 이 토큰을 소유한다. 그 후, 토큰은 특정 토큰 프로토콜에 따라 특정 목적을 위해 사용, 판매, 교환 등이 될 수 있다. 예컨대, 영화 티켓은 사용자에게 토큰을 발행할 수 있으며, 그 후 이 사용자는 영화관에서 영화를 본 대가로 토큰을 지불하거나, 또는 은행이 자신의 클라이언트 USD 예치금들과 교환하여 토큰들을 발행할 수 있으며, 이 토큰들은 정규 지불들에서 클라이언트들에 의해 사용되고 추후에 제3 당사자들에 의해 은행에서 USD로 다시 교환된다.
위에서 언급된 바와 같이, 블록체인을 사용하여 토큰들을 생성하려는 이전의 시도들은, 일반적으로 출력 스크립트 코드의 실행되지 않은 부분 또는 심지어 부가적인 별개의 지출 불가능한 트랜잭션 출력에 토큰 데이터를 포함시킴으로써, 트랜잭션의 부가적인 데이터 필드에 토큰들을 정의하는 것을 수반하였다. 이러한 토큰들은 토큰들이 생성되는 블록체인의 기본 디지털 자산(그의 네이티브 토큰들로부터 그 자체로 구성됨)과 상이하다. 즉, 이러한 이전 방식들에 따라 토큰을 포함하는 트랜잭션은 기본 디지털 자산(또는 "네이티브 토큰")을 정상적으로 사용하면서, 부가적인 데이터 구조들에서 새로운 토큰을 또한 생성한다. 새로운 토큰은 네이티브 토큰과 관련되지 않는다. 새롭게 생성된 토큰들과 그의 네이티브 부수물(native associate)들의 이러한 디커플링은 모든 최신 시도들이 실패한 것을 달성하는 데 부담스럽고 불필요한 조정을 요구하여, 결국 토큰이 의도한 대중화에 도달하는 것을 방해하였다.
본원에서 개시된 일 양상에 따르면, 블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법이 제공된다. 각각의 토큰은 블록체인의 기본 디지털 자산 네이티브 단위의 단일 단위에 의해 표현된다. 방법은 제1 토큰 트랜잭션을 생성하고 제1 토큰 트랜잭션을 블록체인 네트워크로 송신하는 것을 포함한다. 제1 토큰 트랜잭션은 제1 토큰 출력을 포함하고, 제1 토큰 출력은 제1 토큰 잠금 스크립트 및 제1 토큰 금액을 포함한다. 제1 토큰 잠금 스크립트는 가변 구성요소 및 불변 구성요소를 포함한다. 가변 구성요소는 지불 템플릿에 포함된 제1 지불 주소를 포함한다. 불변 구성요소는 지출 트랜잭션의 입력 스크립트 ― 입력 스크립트가 지출 트랜잭션의 자체 입력 스크립트를 제외한 전부뿐만 아니라 개개의 잠금 스크립트 및 지출되는 이전 트랜잭션 출력에서 잠긴 금액을 포함하는 토큰 역학 하위 구성요소를 포함함 ― 와 함께 실행될 때, 토큰 역학 하위 구성요소는 다음 동작들을 수행하도록 구성된다. 제1 동작은 지출 트랜잭션의 입력 스크립트로부터 하나 이상의 데이터 쌍들을 획득하는 것을 포함하며, 각각의 데이터 쌍은, i) 지출 트랜잭션 출력들의 개개의 잠금 스크립트에 포함된 적어도 개개의 지불 주소 및 ii) 해당 출력의 개개의 잠금 스크립트들에 의해 잠긴 기본 디지털 자산의 대응하는 금액을 포함한다. 다른 동작은 지출 트랜잭션의 하나 이상의 출력들이, a) 미리 결정된 지불 주소를 포함하는 개개의 지불 스크립트 템플릿, 또는 b) 미리 결정된 지불 주소 이외의 개개의 지불 주소를 포함하는 개개의 가변 구성요소 및 가변 구성요소를 뒤따르는 불변 구성요소를 포함하는 개개의 잠금 스크립트를 포함한다는 것을 검증하는 것을 포함한다. 다른 동작은 지불 트랜잭션의 해당 하나 이상의 출력들에 대해, 하나 이상의 출력들의 개개의 잠금 스크립트들에 의해 잠긴 기본 디지털 자산의 총 금액이 제1 토큰 금액과 동일하다는 것을 검증하는 것을 포함한다. 토큰 역학 하위 구성요소는 검증 단계들 중 임의의 것이 실패하는 경우 실행 동안 실패하도록 구성된다.
이전의 토큰 시도들과 달리, 본 발명에 따른 새롭게 발행된 토큰들은 기본 디지털 자산 토큰들 자체이다. 즉, 네이티브 토큰들 자체가 새로운 유형의 토큰으로 변형된다. 이러한 새로운 토큰들은, 그의 발행 시 자체적으로 인코딩된 소정의 특정 조건들 하에서 기본 디지털 자산으로 역으로 변환되지 않는 한, 더 이상 네이티브 토큰으로서의 그의 정규 기능을 수행하지 않는다.
토큰이 지출, 할당 또는 다른 방식으로 이전되고 이에 따라 토큰으로서 기능하기 위해, 지출 트랜잭션이 성공적이 되기 위해서는 지출 중인 이전 트랜잭션 출력(UTXO*라고 함)과 동일한 포맷의 잠금 스크립트를 그의 다음 출력에 가져야 한다. 즉, 지출 중인 토큰 트랜잭션 출력과 같이, 지출 트랜잭션이 성공적으로 송신될 수 있기 위해, 새로운 토큰 출력과 동일한 불변 구성요소를 갖는 잠금 스크립트를 갖는 출력을 포함해야 한다. 이 불변 부분은 그의 상환 때까지 토큰의 수명을 통해 변경하거나 생략될 수 없다.
이 불변 부분은 토큰의 코드 부분이며, 이는 그의 다양한 동작들 사이에서, 토큰의 성질을 변형하기 위해, 트랜잭션마다 1) 그의 자체 불변성, 2) 자체 누락 불가능, 및 3) 가장 중요하게는, 토큰 금액의 보존을 지시하는데, 즉, 그것은 토큰들을 잠가, 토큰들의 금액(전체 또는 일부)이 채굴자 수수료로서 유출되지 않게 하거나(총 출력 금액이 총 입력들보다 적은 경우), 자체 스마트 잠금 스크립트 포맷 출력들(지정된 주소로 상환되지 않는 한, 발행 시 자체로 인코딩됨) 이외의 임의의 다른 것으로 지출되지 않게 한다.
간단히 말해서, 이는 새롭게 정의된 토큰을 시행하는 동안 네이티브 토큰들의 정규 사용을 불가능하게 하고, 이에 따라 그의 성질을 변경한다.
이는 기본 디지털 자산의 각각의 단일 단위가 이제 재정의된 단일 토큰을 표현하고 그의 정규 기능을 정지시키는 효과를 갖는다. 비트코인 블록체인의 예를 계속하기 위해, 단일 사토시(single satoshi)는 이제 단일 토큰으로서 재정의된다. 잠금 스크립트가 새로운 토큰 메카닉을 시행하는 정확히 동일한 불변 구성요소를 포함하지 않는 한, 토큰(들)의 소유자는 토큰(들)을 다른 사용자에게 이동시킬 수 없다. 잠금 스크립트에서 변경될 수 있는 모든 것은 표준 템플릿에 포함된 주소에 따라 소유권을 이전하는 것, 즉 현재 소유자가 토큰(들)의 일부 또는 전부를 다음 소유자에게 이동시키는 것을 가능하게 하는 것을 담당하는 이러한 표준 템플릿(예컨대, 기본 자산의 네이티브 토큰들에서와 동일한 방식으로 사용됨)일 수 있는 가변 구성요소이다.
달리 말하면, 토큰을 표현하기 위해 메타데이터 첨부들에 의존하는 이전 시도들과 달리, 이 방식에 따르면, 본 발명의 토큰들은 상이한 규칙들(그 자체로 인코딩됨)에 의해 동작하도록 별개의 엔티티로서 기능하게 재구성된 기본 디지털 자산의 단일 단위이다.
위에서 언급된 바와 같이, 토큰들은, 토큰들이 위의 스크립트의 불변 부분에 인코딩된 특정 조건들을 충족하고 예컨대, 미리 결정된 상환 주소로 움직이는 경우 그리고 그러한 경우에만, 기본 디지털 자산으로 즉, 네이티브 토큰으로서 다시 한 번 사용되도록 역으로 변환될 수 있다. 즉, 하드코딩된 사용자 또는 기관(즉, 상환 주소에 대한 제어를 갖는 엔티티)만이 토큰들을 정규 기본 디지털 자산의 성질로 되돌려 그의 오리지널 기능을 복원하는 능력을 갖는다.
본 개시내용의 실시예들의 이해를 보조하기 위해 그리고 그러한 실시예들이 어떻게 실행될 수 있는지를 보여주기 위하여, 단지 예로서 첨부 도면들에 대한 참조가 이루어진다.
도 1은 예시적인 토큰 트랜잭션을 개략적으로 예시한다.
도 2는 예시적인 토큰 잠금 스크립트를 개략적으로 예시한다.
도 3a 및 도 3b는 정규 토큰 트랜잭션과 아토믹 스왑 토큰 트랜잭션 간의 차이를 개략적으로 예시한다.
도 4는 발행으로부터 상환까지의 토큰들의 예시적인 흐름을 개략적으로 예시한다.
본 발명의 실시예들은 블록체인 트랜잭션들의 생성 및 송신을 수반한다. 당업자는 블록체인 기술 자체에 친숙할 것이지만, 실시예들 자체가 상세히 설명되기 전에 먼저 블록체인의 간략한 개요가 제공된다.
블록체인은 블록체인 네트워크로 송신된 모든 유효한 트랜잭션들의 레코드로서 작용하는 분산 데이터베이스(또는 원장)의 한 형태이다.
블록체인 네트워크에서 브로드캐스팅되는 유효한 트랜잭션들은 채굴자들(채굴 노드들로서 또한 지칭됨)에 의해 블록체인 상에 블록으로 레코딩된다. 블록체인 트랜잭션은 디지털 자산의 금액에 대한 보호권(custody), 즉 소유권을 이전하는 데 사용된다. 예시적인 블록체인은 비트코인 블록체인이 있으며, 비트코인 블록체인의 디지털 자산이 비트코인으로서 지칭된다. 상이한 블록체인들이 존재하며 본 발명은 임의의 특정 구현으로 제한되지 않는다. 각각의 트랜잭션은 다른 것들 중에서도, 적어도 하나의 입력 및 적어도 하나의 출력을 포함한다. 입력은 이전 트랜잭션으로부터의 미지출 트랜잭션 출력(UTXO)에 대한 참조를 포함한다. 트랜잭션은 입력들로서 미지출 트랜잭션 출력들(UTXO)을 사용하고 그의 값을 새로운 출력들에 분배한다. 출력은 통상적으로 해당 출력의 값을 잠그는 잠금 조건을 포함하여, 잠금해제되기 위해 새로운 다음 트랜잭션의 입력에 특정 데이터(예컨대, 일 세트의 서명들 또는 다른 정보)가 제공될 것을 요구한다. 출력들은 또한 원장에 데이터(예컨대, 텍스트, 이미지들 등)를 기입하는 데 사용될 수 있다. 트랜잭션의 입력은 일반적으로 트랜잭션의 적어도 일부에 대해 서명하는 디지털 서명을 포함한다. 따라서 트랜잭션들의 체인은 트랜잭션의 생성까지 내내 거슬러 올라가 디지털 자산의 유효한 교환들에 대한 전체 이력을 매핑하는 디지털 서명들의 체인을 포함한다.
블록체인은 가장 먼저 생성된 블록인 "제네시스 블록"으로 시작한다. 블록체인의 각각의 블록은 이전 블록을 참조하며, 제네시스 블록까지 내내 거슬러 올라간다. 즉, n번째 블록은 n-1번째 블록을 참조하고 n-1번째 블록은 n-2번째 블록을 참조하는 식으로 제네시스 블록까지 거슬러 올라간다.
블록은 블록체인 트랜잭션들의 순서화된 목록 및 블록 헤더를 포함한다. 블록 헤더는 블록체인 트랜잭션들의 순서화된 목록을 머클(Merkle) 트리로 해싱함으로써 생성되는 머클 루트, 타임스탬프, 현재 블록이 빌드 업되는 이전 블록에 대한 참조 및 다른 채굴자들이 블록을 유효한 것으로 수락하는 데 필요한 "작업 증명"을 유효성 검증하는 수단을 포함한다. 해당 유효성 검증 수단은 각각의 블록에 고유한 해시 퍼즐에 대한 답변이다. 블록체인 네트워크의 채굴 노드들에 의해 실행되는 블록체인 프로토콜은 해당 채굴자들이 퍼즐 풀기를 시도하기 전에 그의 후보 블록을 프리-빌딩(pre-build)하도록 요구하는 해싱 알고리즘을 사용한다. 새로운 블록들은 올바른 답변 없이 네트워크에 제출될 수 없는데 ― "채굴"의 프로세스는 본질적으로 현재 블록을 "푸는(solve)" 답변을 찾기 위해 차기(next)가 되도록 경쟁하는 프로세스이다. 각각의 블록의 해시 퍼즐은 풀기 어렵지만, 일단 유효한 솔루션이 발견되면, 나머지 네트워크가 솔루션이 올바른지를 컨펌(confirm)하는 것은 매우 쉽다. 임의의 주어진 블록에 대해 다수의 유효한 솔루션들이 존재하는데 ― 블록이 풀어지기 위해 솔루션들 중 단 하나만이 발견될 필요가 있다.
다음은 블록체인에 새로운 블록을 채굴하려고 시도하는 프로세스를 간략히 설명한다. 블록체인 트랜잭션이 채굴 노드로 송신될 때, 이는 먼저 블록체인 네트워크의 컨센서스 규칙들에 따라 유효성 검증된다. 트랜잭션이 유효한 경우, 이는 컨펌되지 않은 트랜잭션들의 풀에 추가된다. 풀은 때로는 "멤풀(mempool)"로서 지칭된다. 멤풀은 다음 블록으로 채굴될 트랜잭션들의 임시 스토어로서 작용한다. 각각의 채굴 노드는 자체 멤풀을 가질 것이고, 임의의 주어진 트랜잭션이 하나 초과의 채굴 노드에 브로드캐스팅된 경우 하나 초과의 멤풀에 포함될 수 있다.
채굴자는 다음 블록에 포함하려는 트랜잭션들을 가져와 머클 트리 구조로 해싱하고 결과적인 머클 루트를 후보 블록 헤더 내에 포함시킨다. 그 후 채굴자는 이 후보 블록 헤더를 해싱하여 유효한 작업 증명을 찾으려고 시도한다. 머클 트리는 해시 값들의 트리 형태의 데이터 구조이다. 블록체인의 맥락에서, 트랜잭션은 트리의 리프 노드를 형성하기 위해 해싱된다. 리프 노드들의 쌍들은 컨케터네이팅되고(concatenated) 그 후 해싱되어 트리의 상위 계층의 노드를 형성한다. 그 후 해당 계층의 노드 쌍들이 컨케터네이팅되고 해싱되어 트리의 더 높은 계층의 노드를 형성한다. 이 프로세스는 루트 노드 또는 머클 루트로서 지칭되는 단일 노드만이 남을 때까지 반복된다.
해시 함수는 임의적 길이의 데이터 문자열을 해시 값 또는 해시 다이제스트라 불리는 고정 길이 고유(사실상의 충돌 확률이 0임) 값으로 변환하는 함수이다. 해싱은 단방향 함수이며, 이는 해싱으로부터 생성된 해시 값을 조사함으로써 입력 데이터가 무엇인지를 결정하는 것이 실행 불가능하다. 반면에, 동일한 해시 함수를 통해 동일한 입력 데이터를 실행하고 동일한 해시를 재생산하는 것은 사소한 일이다. 일부 블록체인 프로토콜들은 SHA-256 해싱 알고리즘을 사용하고 일부 프로토콜들은 SHA-256 해싱 알고리즘을 두 번 사용하는데, 즉, 후보 블록 헤더가 동일한 해싱 알고리즘을 두 번 통과한다.
유효한 작업 증명은, 결과가 타겟 값이라 불리는 다른 값보다 작을 때까지 (아래에서 논의되는 바와 같이, 다른 데이터와 조합하여) 후보 블록 헤더를 해싱함으로써 발견된다. 타겟 값은 블록체인 프로토콜에 의해 자동으로 조정되어서, 블록체인 네트워크에서 유효한 작업 증명을 찾는 데 평균적으로 10분이 걸린다.
해시 값을 변경하기 위해, 채굴 노드가 후보 블록 헤더에 부가적인 정보를 추가해야 한다. 채굴 노드들은 통상적으로 2개의 "논스(nonce) 필드들"을 사용하여 해시될 값 및 이에 따른 결과적인 해시 값을 변경한다. 제1 논스 필드는 블록 헤더 자체에 포함되고 제2 논스 필드는 "코인베이스 트랜잭션"에 포함된다. 코인베이스 트랜잭션은 채굴 노드에 의해 생성되고 후보 블록에 포함되는 트랜잭션이다. 각각의 필드는 증분될 수 있는 카운터 파라미터를 포함한다. 해시 함수는 제1 논스 필드의 모든 값들을 통해 순환하고 그 후 제1 논스 필드의 모든 순열들을 다시 거치기 전에 제2 논스 필드를 증분(또는 다른 방식으로 변경)한다. 제2 논스 필드를 증분시키는 것은, 머클 트리에 포함된 코인베이스 트랜잭션의 해시를 수정하기 때문에 머클 루트를 재컴퓨팅하는 것을 수반한다.
채굴 노드가 블록에 대한 유효한 작업 증명 해시(즉, 타겟 값보다 작은 값으로 해싱하는 후보 블록 헤더)를 발견한 경우, 채굴 노드는 새로운 블록을 나머지 블록체인 네트워크에 브로드캐스팅한다. 네트워크 상의 다른 노드들은, 새로운 블록 내의 모든 트랜잭션들이 유효하고 아직 블록에 포함되지 않은 경우에만 이 새로운 블록을 수락한다. 모든 각각의 블록은 타임스탬핑되고 자신에 선행하는 블록의 해시를 참조하고, 이에 따라 블록들의 체인을 발생시키고 이러한 이유로 "블록체인"이란 용어가 된다.
이제 블록체인 트랜잭션들이 더 상세히 설명될 것이다. 아래 표는 일부 블록체인 프로토콜들에 따른 통상적인 트랜잭션의 구조의 개략적 표현이다. 상이한 블록체인 프로토콜들이 상이한 트랜잭션 구조들을 사용할 수 있다는 것이 인지될 것이다. 따라서 다음 논의는 문맥상으로만 제공되며 모든 실시예들에 관한 제한인 것으로 의도되지 않는다.
보여진 대로, 트랜잭션은 일 세트의 데이터 필드들로 구성된다. 그의 원시 형식에서, 트랜잭션은 통상적으로 16진수로 표현되는 직렬화된 세트의 데이터 필드들로 구성된다.
Figure pct00001
트랜잭션은 각각이 이전 트랜잭션의 출력을 참조하는 하나 이상의 입력들을 갖는다. 각각의 입력은 동일한 이전 트랜잭션의 상이한 출력, 상이한 트랜잭션들의 출력들 또는 이들의 조합을 참조할 수 있다. 각각의 입력은, 올바른 데이터를 포함하는 경우, 참조된 출력을 잠금해제하는 잠금해제 스크립트(때로는 "ScriptSig"로서 지칭됨)를 포함한다. 그 후 이전 트랜잭션의 잠금해제된 출력 또는 오히려, 이전에 해당 출력에 잠겨진 디지털 자산의 금액은 현재 트랜잭션의 출력에 의해 지출(즉 현재 트랜잭션의 출력에 할당)될 수 있다. 잠금해제된 디지털 자산의 금액은 단일 출력에 의해 그 전체가 지출될 수 있거나, 현재 트랜잭션의 하나 초과의 출력에 걸쳐 분배될 수 있다.
트랜잭션은 또한 입력들에 의해 잠금해제된 디지털 자산의 총 금액을 함께 분배하는 하나 이상의 출력들을 갖는다. 일반적으로 출력 값들의 합은 입력 값들의 합보다 적으며, 그 차이는 새로운 블록에 트랜잭션을 레코딩하는 채굴 노드에 수수료로서 지불된다. 출력은 지출 가능한 출력 또는 지출 불가능한 출력일 수 있다. 지불 가능한 출력은, 추후 트랜잭션의 입력에 의해 잠금해제되기 위해 충족되어야 하는 하나 이상의 조건들을 정의하는 잠금 스크립트(때로는 "ScriptPubKey"로서 지칭됨)를 포함한다. 지출 불가능한 출력은 잠금해제될 수 있는 잠금 스크립트를 포함하지 않는다. 즉, 지출 불가능한 출력은 잠금 스크립트의 실행이 실패되게 하는 잠금 스크립트를 포함한다.
본 발명의 실시예들은 제1 당사자(그녀를 "앨리스"라고 부름)가 제2 당사자(그를 "밥"이라고 부름)에게 하나 이상의 토큰들을 전송하는 것을 가능하게 한다. 다음 설명 중 적어도 일부는 토큰을 제1 당사자인 앨리스가 제2 당사자인 밥에게 전송하는 것을 참조할 것이다. 그러나 이는 단지 예시를 위한 것이라는 것이 주의되어야 한다. 실시예는 제2 당사자인 밥이 제3 당사자, 예컨대, 상인에게 토큰을 전송하는 것에 동일하게 적용된다. 또한, 토큰 발행자, 즉 초기에 예컨대, 앨리스에 토큰을 발행한 당사자에 대한 참조가 또한 이루어질 것이다. 또한, 다음 설명 중 적어도 일부는 "제1 토큰 트랜잭션"을 참조할 것이다. 맥락이 달리 요구하지 않는 한, 제1 토큰 트랜잭션은 앨리스, 밥 또는 토큰 발행자 중 어느 하나에 의해 생성될 수 있다.
도 4는 여러 당사자들 예컨대, 토큰 발행자, 앨리스, 밥 및 상인을 포함하는 예시적인 시스템을 예시한다. "당사자"라는 용어는 사용자(예컨대, 앨리스)를 지칭하는 데 사용될 수 있지만, 당사자는 다른 형태들 예컨대, 회사 또는 다른 형태의 조직과 같이 사용자들의 집합적 그룹을 취할 수 있다. 또한, 당사자가 자율적 엔티티, 즉 하나 이상의 조건들에 기초하여 미리 결정된 액션들을 수행하는 엔티티일 수 있다는 것이 배제되지 않는다. 그러한 자율적 엔티티는 때로는 당업계에서 "에이전트"로서 지칭된다.
도면들에서 도시하지 않지만, 각각의 당사자는 개개의 컴퓨터 장비를 동작시킨다. 각각의 당사자의 컴퓨터 장비는 하나 이상의 프로세서들, 예컨대, 하나 이상의 CPU들, GPU들, 다른 가속기 프로세서들, 애플리케이션 특정 프로세서들 및/또는 FPGA들을 포함하는 개개의 프로세싱 장치를 포함한다. 각각의 당사자의 컴퓨터 장비는 메모리, 즉 비-일시적 컴퓨터-판독 가능 매체 또는 매체들의 형태의 컴퓨터-판독 가능 저장소를 더 포함한다. 이 메모리는 하나 이상의 메모리 매체들, 예컨대, 하드 디스크와 같은 자기 매체; SSD, 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광학 디스크 드라이브와 같은 광학 매체를 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다. 각각의 당사자의 컴퓨터 장비 상의 메모리는 프로세싱 장치 상에서 실행되도록 배열된 적어도 하나의 클라이언트 애플리케이션의 개개의 인스턴스를 포함하는 소프트웨어를 저장한다. 본원에서 주어진 당사자에 기인한 임의의 액션은 개개의 컴퓨터 장비의 프로세싱 장치 상에서 실행되는 소프트웨어를 사용하여 수행될 수 있다는 것이 이해될 것이다. 각각의 당사자의 컴퓨터 장비는 적어도 하나 사용자 단말, 예컨대, 데스크 톱 또는 랩톱 컴퓨터, 태블릿, 스마트폰, 또는 스마트워치와 같은 웨어러블 디바이스를 포함한다. 주어진 당사자의 컴퓨터 장비는 또한 사용자 단말을 통해 액세스되는 클라우드 컴퓨팅 자원들과 같은 하나 이상의 다른 네트워킹된 자원들을 포함할 수 있다.
예컨대, 서버로부터 다운로드되거나, 또는 이동식 저장 디바이스 이를테면, 이동식 SSD, 플래시 메모리 키, 이동식 EEPROM, 이동식 자기 디스크 드라이브, 자기 플로피 디스크 또는 테이프, 광학 디스크 이를테면, CD 또는 DVD ROM 또는 이동식 광학 드라이브 등 상에서 제공되는 클라이언트 애플리케이션은 적절한 컴퓨터-판독 가능 저장 매체 또는 매체들 상에서 임의의 주어진 당사자의 컴퓨터 장비에 초기에 제공될 수 있다.
토큰 발행자는 초기 수신자 예컨대, 앨리스에게 토큰을 발행하는 당사자이다. 토큰(들)은 토큰 발행자에 의해 생성된 초기 토큰 트랜잭션을 사용하여 앨리스에게 발행될 수 있거나 앨리스 자신이 초기 토큰 트랜잭션을 생성할 수 있다. 예컨대, 토큰 발행자 및 앨리스는 앨리스에게 발행될 토큰들의 수(및 임의의 다른 적용 가능한 계약 조건들)에 동의할 수 있고, 그 후 앨리스는 하나 이상의 토큰들을 상이한 당사자 예컨대, 밥에게 이동시킴으로써 토큰들을 효과적으로 그녀 자신에게 발행할 수 있다.
앨리스(또는 토큰 발행자)는 초기 토큰 트랜잭션을 생성한다. 토큰 트랜잭션은 하나 이상의 입력들 및 하나 이상의 출력들을 포함한다. 필요한 경우, 입력들 중 하나는 토큰 트랜잭션을 블록에 재코딩하기 위해 채굴 노드에 트랜잭션 수수료를 지불하기 위한 수수료 지불로서 사용될 수 있다. 트랜잭션 수수료들은 항상 요구되는 것은 아니고, 이에 따라 이러한 수수료 지불이 필수적인 것은 아니다. 모든 블록체인 트랜잭션과 마찬가지로, 토큰 트랜잭션은 이전 트랜잭션의 출력을 잠금해제하기 위한 입력을 포함한다. 초기 토큰 트랜잭션에 대해, 이전 트랜잭션의 참조된 출력은, 최소한으로, 토큰들로 재구성될 기본 자산의 금액을 포함해야 한다. 도 4에 도시된 바와 같이, 초기 토큰 금액은 1000이고, 따라서 참조된 출력은 기본 자산의 적어도 1000 단위의 값을 가져야 한다. 이 숫자는 임의적으로 선택되었으며 일반적으로 임의의 숫자가 초기 토큰 금액으로서 사용될 수 있다는 것이 인지될 것이다. 간결함을 위해, 기본 자산의 단위가 사토시로서 지칭될 것이다. 이는 비트코인 블록체인의 특정 단위이지만, 이것이 모든 실시예들을 어떠한 방식으로도 제한하지 않는다.
초기 토큰 트랜잭션은 제1 토큰 출력을 포함한다. 제1 토큰 출력은 초기 토큰 금액(1000 사토시)을 잠근다. 즉, 제1 토큰 출력은 초기 사토시 금액을 동일한 금액의 새롭게 정의된 토큰으로 잠그는 제1 토큰 잠금 스크립트를 포함한다. 제1 토큰 잠금 스크립트는 가변 구성요소 및 불변 구성요소를 포함한다. 달리 말하면, 가변 구성요소는 제1 토큰 잠금 스크립트의 하나의 섹션(즉, 일부)이고 불변 구성요소는 제1 토큰 잠금 스크립트의 상이한 섹션(즉 일부)이다. 그 이름이 암시하는 바와 같이, 가변 구성요소는 토큰 트랜잭션마다 변동될 수 있는 반면에, 불변 구성요소는 동일하게 유지될 것이다.
가변 구성요소는 토큰들이 다른 당사자에게 이동되도록 허용하는 토큰 잠금 스크립트의 일부이다. 가변 구성요소는 지불 주소를 포함하는(예컨대, 둘러싸는) 지불 템플릿을 포함한다. 지불 주소는 수령 당사자의 공개 키에 기초할 수 있다. 예컨대, 지불 주소는 공개 키 해시(PKH) 주소, 즉 공개 키의 해시(또는 이중 해시)일 수 있다. 초기 토큰 트랜잭션이 토큰 발행자에 의해 생성되는 경우, 지불 주소는 앨리스에 링크될 것이다. 앨리스가 초기 토큰 트랜잭션을 생성하는 경우, 지불 주소는 앨리스에 의해 선택될 것이다. 앨리스는 자신에게 링크된 다른 주소를 선택할 수 있거나, 또는 상이한 당사자 예컨대, 밥 또는 상인에 링크된 주소를 선택할 수 있다. 지불 주소는 가변 구성요소의 하위 구성요소로서 취급될 수 있다. 가변 구성요소는 하나 이상의 부가적인 불변 하위 구성요소들을 포함할 수 있다. 예컨대, 가변 구성요소는 P2PKH(pay-to-public-key-hash) 포맷 출력을 생성하기 위한 하나 이상의 불변 작업코드(opcode)들을 포함할 수 있다.
불변 구성요소는 이하 불변 구성요소의 불변 하위 구성요소인 "토큰 하위 구성요소"로서 축약된 토큰 역학 하위 구성요소(token mechanics sub-component)를 포함한다. 토큰 하위 구성요소는 기본 디지털 자산을 토큰으로 용도 변경하는 제1 토큰 잠금 스크립트의 일부이다. 예로는 1000 사토시를 1000개의 토큰으로 전환하는 것이다. 토큰 하위 구성요소는 지출 트랜잭션의 입력으로부터 데이터를 획득하고 적어도 2번의 검증 단계들을 수행하도록 구성된다. 또한, 토큰 하위 구성요소는 검증이 실패하는 경우 토큰 잠금 스크립트 실행이 실패되게 하도록 구성된다. 즉, 검증 단계들 중 어느 하나가 실패하는 경우, 지출 트랜잭션 입력으로부터의 잠금해제 스크립트와 함께 토큰 잠금 스크립트의 실행이 실패할 것이다.
토큰 하위 구성요소는 유효하게 실행하기 위해 지출 트랜잭션의 입력(특히 입력의 잠금해제 스크립트)이 특정 데이터를 포함하도록 요구한다. 지출 트랜잭션의 입력은 지출 입력으로서 지칭될 것이다. 특히, 지출 입력의 잠금해제 스크립트는 잠금해제 스크립트 자체가 아닌 지출 트랜잭션의 적어도 일부, 즉 지출 트랜잭션 데이터(일부는 있는 그대로인 반면, 나머지만이 해싱 결과들임)를 포함해야 한다. 지금부터, 이 데이터는 해시 프리이미지(hash preimage)(그의 해시가 ECDSA 검증 공식의 입력으로 사용되기 때문에) 또는 단지 프리이미지라고 칭한다. 프리이미지는 지출 트랜잭션들의 필드들뿐만 아니라 지출중인 지출 트랜잭션, 그리고 이러한 트랜잭션 필드에 기초하여 생성(해시)된 데이터 아이템들을 포함한다. 다른 실시예들에서, 지출 트랜잭션의 모든 데이터 필드들은 지출 입력 축약의 잠금해제 스크립트에 포함된다.
토큰 하위 구성요소는 실행될 때, 프리이미지 외에 지출 입력의 잠금해제 스크립트로부터 하나 이상의 데이터 쌍들을 획득하도록 구성된다. 각각의 데이터 쌍은 적어도, 지출 트랜잭션의 잠금 스크립트의 지불 주소 및 해당 잠금 스크립트에 의해 잠긴 기본 디지털 자산의 대응하는 금액을 포함한다. 일부 예들에서, 지출 트랜잭션은 단지 하나의 출력, 즉 하나의 잠금 스크립트만을 포함한다. 이 경우에, 토큰 하위 구성요소는 하나의 데이터 쌍을 획득한다. 다른 예들에서, 지출 트랜잭션은 다수의 출력들, 즉 다수의 잠금 스크립트들을 포함한다. 이 경우에, 토큰 하위 구성요소는 다수의 데이터 쌍들을 획득한다.
요구되는 데이터는 지출 입력의 잠금해제 스크립트를 파싱(parsing)하고 데이터 쌍들을 추출함으로써 획득될 수 있다. 이는 미리 정의된 위치들에서 잠금해제 스크립트에 데이터 쌍들이 포함되도록 요구할 수 있다. 보다 상세한 논의는 아래에서 제공된다.
하나 이상의 데이터 쌍들을 획득하면, 토큰 하위 구성요소는 지출 트랜잭션의 출력(들)이 특정 포맷을 갖는다는 것을 검증하도록 구성된다. 지출 트랜잭션의 적어도 하나의 출력은 단지 미리 결정된 표준 지불 템플릿의 일부로서 미리 결정된 지불 주소 또는 미리 결정된 표준 지불 템플릿의 일부로서 임의적 주소뿐만 아니라, 뒤따르는 토큰 출력의 불변 구성요소(즉, 바로 그 동일한 불변 구성요소)를 포함해야 한다. 토큰 하위 구성요소는, 지출 트랜잭션의 하나 초과의 출력이 미리 결정된 표준 지불 템플릿에 매립되고 토큰 출력의 불변 구성요소가 뒤따르는 임의적 지불 주소를 포함한다는 것을 결정 및 검증할 수 있다. 지출 트랜잭션은 지출 트랜잭션이 미리 결정된 지불 주소(그의 대응하는 표준 템플릿만을 가짐) 또는 그의 대응하는 표준 템플릿을 갖고 토큰 출력의 불변 구성요소가 뒤따르는 임의적 지불 주소를 포함하지 않는 하나 이상의 출력들을 포함한다는 것을 검증할 수 있다.
또한, 토큰 하위 구성요소는, 더불어, 미리 결정된 지불 주소 또는 불변 구성요소가 뒤따르는 임의적 지불 주소 중 어느 하나를 포함하는 지출 트랜잭션의 출력들에 의해 잠긴 값들의 합이 초기 토큰 금액과 동일(즉, 똑같음)하다는 것을 검증하도록 구성된다. 미리 결정된 지불 주소 또는 불변 구성요소 중 어느 하나를 포함하는 지출 트랜잭션의 출력은 스마트 토큰 출력으로서 지칭될 수 있다. 토큰 하위 구성요소는 스마트 토큰 출력들에 의해 잠긴 토큰의 총 금액이 초기 토큰 금액과 동일하다는 것을 검증하여, 그의 오리지널 또는 임의의 다른 사용 포맷으로 다시 유출되는 것을 방지한다.
예컨대, 지출 트랜잭션이 단일 스마트 토큰 출력 ― 지출 트랜잭션의 제1 출력을 포함하는 경우를 고려한다. 토큰 하위 구성요소는 지출 트랜잭션의 제1 출력이 특정 포맷을 취하거나 오히려 특정 데이터를 포함하는 제1 잠금 스크립트를 갖는다는 것을 검증하도록 구성된다. 특히, 제1 잠금 스크립트는 (지불 템플릿의 부분으로서) 미리 결정된 지불 주소 또는 (지불 템플릿의 부분으로서) 토큰 잠금 스크립트의 불변 부분이 뒤따르는 임의적 지불 주소를 포함해야 한다. 둘 중 단 하나만이 요구되지만, 둘 다 누락하는 경우, 검증은 실패할 것이다. 이 검증 프로세스는 토큰 하위 구성요소가 지출 입력의 잠금해제 스크립트로부터 지출 트랜잭션의 제1 잠금 스크립트를 획득하였기 때문에 달성 가능하다. 따라서 토큰 하위 구성요소는 미리 결정된 지불 주소 또는 불변 구성요소에 대한 제1 잠금 스크립트를 검색할 수 있다.
지출 트랜잭션은 위에서 논의된 바와 같이 다수의 출력들을 포함할 수 있다. 부가적인 출력들 중 일부는 또한 스마트 토큰 출력들일 수 있거나, 상이한 목적들을 위해 사용될 수 있다. 이 경우에, 토큰 하위 구성요소는 지출 트랜잭션의 하나 초과의 출력이 미리 결정된 지불 주소 또는 토큰 트랜잭션의 불변 구성요소, 즉 토큰 잠금 스크립트의 불변 구성요소가 뒤따르는 임의적 지불 주소 중 어느 하나를 포함한다는 것을 검증하도록 구성된다. 구현에 의존하여, 토큰 하위 구성요소는 지출 트랜잭션의 다수의 출력들 각각 및 모든 각각의 출력이 미리 결정된 지불 주소 또는 불변 구성요소를 포함한다는 것을 검증하도록 구성될 수 있다. 다른 예들에서, 토큰 하위 구성요소는 다수의 출력들 중 전부가 아닌 일부가 미리 결정된 지불 주소 또는 불변 구성요소를 포함한다는 것을 검증하도록 구성될 수 있다. 예컨대, 토큰 하위 구성요소는 지출 트랜잭션의 미리 결정된 수의 출력들 예컨대, 처음 두 개의 출력들 ― 즉, 지출 트랜잭션에서 논리적으로 먼저 나타나는 두 개의 출력들이 불변 구성요소를 포함한다는 것을 검증할 수 있다.
지출 트랜잭션이 단일 스마트 토큰 출력을 포함하는 예들에서, 토큰 하위 구성요소는 지출 트랜잭션의 제1 잠금 스크립트들에 의해 잠긴 기본 디지털 자산의 제1 금액이 초기 토큰 금액(즉, 1000 사토시)과 동일하다는 것을 검증하도록 구성된다. 여기서 제1 잠금 스크립트를 갖는 제1 출력은 지출 트랜잭션에서 논리적으로 먼저 나타나는 출력이다.
지출 트랜잭션이 다수의 출력들을 포함하는 경우, 예컨대, 제2 출력이 디지털 자산의 제2 금액을 잠그는 제2 잠금 스크립트를 갖는 경우, 토큰 하위 구성요소는 제1 금액 및 제2 금액의 합이 초기 토큰 금액과 동일하다는 것을 검증하도록 구성된다. 여기서 제2 출력은 지출 트랜잭션에서 논리적으로 두 번째로 나타나는 출력이다. 일반적으로 지출 트랜잭션이 미리 결정된 지불 주소 또는 불변 구성요소 중 어느 하나를 포함하는 다수의 출력들을 포함하는 경우, 토큰 하위 구성요소는 그의 개개의 금액들의 합이 초기 토큰 금액과 동일하다는 것을 검증한다.
이 프로세스는 지출 트랜잭션의 임의의 수의 출력들에 대해 반복될 수 있다. 지출 트랜잭션은, 지출 트랜잭션의 출력들 전부에 의해 잠긴 디지털 자산의 합이 초기 토큰 금액보다 크게 되게 하는 디지털 자산의 금액을 잠그는 출력을 포함하도록 허용될 수 있다. 이 경우에, 토큰 하위 구성요소는 더불어, 지출 트랜잭션의 미리 결정된 수의 스마트 토큰 출력들이 초기 토큰 금액과 동일한 디지털 자산의 금액을 잠근다는 것을 검증하도록 구성되고, 비-스마트 토큰 출력들에 의해 잠긴 금액은 고려되지 않는다. 비-스마트 토큰 출력은 수수료 잔액 출력(fee change output) 또는 아토믹 스왑 출력(atomic swap output)일 수 있다. 예컨대, 토큰 트랜잭션의 처음 2개의 출력들에 의해 잠긴 총 금액은 초기 토큰 금액과 동일해야 하는 반면, 제3 출력(예컨대, 수수료 잔액 출력)은 부가적인 입력에 의해 펀딩되는 부가적인 금액을 잠글 수 있다. 제3 출력은 예시 목적으로 사용된다는 것에 주의한다. 수수료 잔액 결과들이 아래에서 추가로 논의된다. 우선, 수수료 잔액 출력(또는 상이한 유형의 "부가적인 출력")이 토큰 출력이 아닌 경우, 즉 토큰 잠금 스크립트의 불변 구성요소를 포함하지 않는 경우에만 이것이 허용된다고 말하는 것으로 충분할 것이다.
토큰 잠금 스크립트의 불변 구성요소는 미리 결정된 지불 주소를 포함할 수 있다. 즉, 미리 결정된 지불 주소는 불변 구성요소에 하드코딩될 수 있고 이에 따라 지출 트랜잭션의 제1 잠금 스크립트에 포함되어야 한다. 미리 결정된 지불 주소는 상환 주소, 예컨대, 토큰들 이외의 어떤 것, 예컨대, 명목 화폐(FIAT currency)로 상환되기 위해 토큰들 중 일부 또는 전부가 이동될 수 있는 주소일 수 있다.
위에서 논의된 바와 같이, 지출 트랜잭션의 지출 입력의 잠금해제 스크립트는 프리이미지를 포함할 수 있다. 프리이미지는 아래 표의 필드들 중 하나, 일부 또는 전부를 포함할 수 있다.
프리이미지 필드 크기
트랜잭션의 nVersion 4바이트 리틀 엔디안
hashPrevouts 32바이트
hashSequence 32바이트
Outpoint 32바이트 해시 + 4바이트 리틀 엔디안
입력의 scriptCode(CTxOuts 내부의 스크립트들로서 직렬화됨 변수
입력에 의해 지출된 출력의 값 8바이트 리틀 엔디안
입력의 nSequence 4바이트 리틀 엔디안
hashOutputs 32바이트 해시
트랜잭션의 nLocktime 4바이트 리틀 엔디안
서명의 시그해시 유형 4바이트 리틀 엔디안
프리이미지의 이 특정 구조는 예시 목적으로 포함되며 다른 구조들이 사용될 수 있는데, 예컨대, 데이터 필드들의 크기는 본 발명을 구현하는 데 사용되는 특정 블록체인에 의존하여 다를 수 있다는 것에 주의한다.
이러한 예들에서, 토큰 하위 구성요소는 초기 토큰 트랜잭션의 토큰 잠금 스크립트(즉, 입력의 scriptCode) 및 초기 토큰 금액(즉, 입력에 의해 지출된 출력의 값)을 프리이미지로부터 추출함으로써 이들을 획득하도록 구성될 수 있다. scriptCode를 제외한 프리이미지의 모든 데이터 필드들의 크기는 알려져 있기 때문에, 토큰 하위 구성요소는 미리 결정된 포지션들의 데이터를 파싱하고 추출함으로써 요구된 필드들을 추출할 수 있다.
위의 표에서 볼 수 있듯이, 프리이미지는 지출 트랜잭션의 출력들의 해시(hashOutputs)를 포함할 수 있다. 이는 각각의 출력, 즉 잠금 스크립트에 의해 잠긴 값의 해시 및 잠금 스크립트 자체이다. 따라서 지출 트랜잭션이 단일 출력을 포함하는 경우, hashOutputs는 하나의 잠금 스크립트와 컨케터네이팅된 하나의 값의 해시를 포함한다. 지출 트랜잭션이 2개의 출력들을 포함하는 경우, 각각의 값-잠금 스크립트 쌍이 컨케터네이팅되고 그 후 해시되어 hashOutputs를 형성한다. 토큰 하위 구성요소는 예컨대, 특정 포지션에서 데이터를 파싱하고 추출함으로써 프리이미지로부터 hashOutputs을 추출할 수 있다.
지출 트랜잭션의 잠금해제 스크립트는 위에서 논의된 바와 같이 하나 이상의 데이터 쌍들을 포함한다. 각각의 데이터 쌍은 값 및 잠금 스크립트를 포함한다는 것을 상기한다. 토큰 하위 구성요소는 자체 버전의 hashOutputs를 생성하고 즉, 하나 이상의 데이터 쌍들의 해시를 생성하고 그 후 생성된 해시가 프리이미지로부터 추출된 해시(즉, hashOutputs)와 동일하다는 것을 검증하도록 구성될 수 있다. 이는, 지출 사용자 예컨대, 앨리스 또는 밥이 지출 트랜잭션의 잠금해제 스크립트에 올바른 데이터 쌍을 포함한다는 것을 컨펌하기 위해 행해질 수 있다.
일부 예들에서, 토큰 하위 구성요소는 지출 트랜잭션의 잠금해제 스크립트에 포함된 프리이미지가 올바르게 생성되었다는 것, 즉 프리이미지의 데이터 필드들이 지출 트랜잭션의 실제 데이터 필드들에 대응한다는 것을 검증하도록 구성될 수 있다. 이는 시스템 사용자들이 지출 트랜잭션을 올바르게 생성하도록 신뢰할 수 있다고 가정될 수 없는 경우에 필요하다. 이를 위해, 토큰 하위 구성요소는 위의 표의 모든 데이터 필드들을 포함하는 프리이미지와 같이 지출 트랜잭션의 예상되는 프리이미지의 자체 버전을 생성한다. 그 후 토큰 하위 구성요소는 지출 트랜잭션의 잠금해제 스크립트로부터 추출된 프리이미지가 토큰 하위 구성요소에 의해 생성된 프리이미지와 매칭된다는 것을 검증할 수 있다.
지출 트랜잭션의 잠금해제 스크립트에 포함된 프리이미지가 올바르다는 것을 검증하는 하나의 방식은 OP_PUSH_TX로서 당업계에 알려진 의사-작업코드(pseudo-opcode)를 사용하는 것이다. 그러나 임의의 등가의 작업코드 또는 보다 일반적으로 OP_PUSH_TX와 등가의 기능을 수행하는 임의의 등가의 코드가 대신 사용될 수 있다.
일반적으로, 토큰 하위 구성요소는 개인 키 및 잠금해제 스크립트로부터의 프리이미지를 사용하여 디지털 서명(예컨대, ECDSA 서명)을 생성하도록 구성될 수 있다. 개인 키는 지출 트랜잭션의 잠금해제 스크립트에 포함된다. 그 후, 토큰 하위 구성요소는, 생성된 프리이미지(즉, 토큰 하위 구성요소에 의해 생성된 프리이미지) 및 개인 키에 대응하는 공개 키에 대해 유효성 검증할 때 디지털 서명이 유효한 서명임을 검증한다. 공개 키는 또한 지출 트랜잭션의 잠금해제 스크립트에 포함된다. 디지털 서명은 2개의 프리이미지들이 정확히 매칭되는 경우에만 유효할 것이다. 사용된 개인 키는 블록체인 상에 레코딩된 덕분에 공개될 것이므로, "더미" 개인 키, 즉 드러날 때 다른 데이터 또는 블록체인 트랜잭션의 보안을 손상시키지 않는 개인 키가 사용되어야 한다. 그러나 일반적으로 임의의 개인 키 예컨대, 임의의 랜덤 키가 사용될 수 있다. 이 서명 체크는 서명을 검증하기 위해 OP_CHECKSIG 작업코드를 활용함으로써 수행될 수 있다. OP_CHECKSIG는 서명이 현재 트랜잭션, 즉 이 경우 지출 트랜잭션에 대한 것인 경우에만 성공(즉, 성공적으로 실행)하는 작업코드이다.
지출 트랜잭션의 출력들로 돌아가서, 토큰 하위 구성요소는 지출 트랜잭션의 출력(들)(특히 그의 개개의 잠금 스크립트들)이 미리 결정된 유형, 즉 포맷의 개개의 지불 주소를 포함한다는 것을 검증하도록 구성될 수 있다. 바람직하게는, 개개의 지불 주소들은 토큰 트랜잭션의 가변 구성요소에 포함된 지불 주소와 동일한 유형이어야 한다. 보다 바람직하게는, 지불 주소는 PKH 주소여야 한다. 이는 지불 주소 자체에만 기초하여 검증될 수 있거나 지불 주소 및 하나 이상의 부가적인 데이터 아이템 예컨대, 하나 이상의 작업코드 또는 지불 주소의 어느 한 측의 다른 데이터에 기초하여 검증될 수 있다. 예컨대, P2PKH 출력은 출력에서 체크될 수 있는 특정한 부가적인 데이터를 포함한다.
불변 구성요소의 토큰 하위 구성요소는 위에서 논의되었다. 불변 구성요소는 또한 불변 데이터 하위 구성요소(이하 "데이터 하위 구성요소"로 축약됨)를 포함할 수 있다. 일반적으로, 데이터 하위 구성요소는 각각의 토큰 출력에 저장될 임의의 데이터를 포함할 수 있다. 예컨대, 데이터 하위 구성요소는 토큰 프로토콜 식별자, 예컨대, 토큰들이 특정 프로토콜로 이루어짐을 표시하는 플래그를 포함할 수 있다. 예로는 토큰들이 FIAT 통화(currency)를 표현한다는 것을 표시하는 것이다. 부가적으로 또는 대안적으로, 데이터 하위 구성요소는 블록체인 상에 레코딩된 트랜잭션("토큰 발행 트랜잭션"이라 함)의 트랜잭션 식별자(TxID)를 포함할 수 있다. 유사하게, 토큰 발행 트랜잭션은 일반적으로 임의의 데이터를 포함할 수 있다. 예로는 토큰 발행자에 의해 발행된 토큰 발행 계약 및/또는 초기 토큰 금액이 있다. 데이터 하위 구성요소는 OP_RETURN 작업코드 또는 등가의 기능을 수행하는 코드 뒤에 포함될 수 있다.
위의 설명은 주로 초기 토큰 트랜잭션 및 지출 트랜잭션에 관한 것이다. 이제 다음은 그 자체가 토큰 트랜잭션인 지출 트랜잭션을 보다 자세히 설명할 것이다. 지출 트랜잭션은 "지출 트랜잭션"이라는 용어가 제1 토큰 트랜잭션의 출력을 참조하는 추후 트랜잭션을 위해 예약되도록 허용하기 위해 "제1 토큰 트랜잭션"으로서 지칭될 것이다.
제1 토큰 트랜잭션은 도 1을 참조하여 설명될 것이다. 도 1에 도시된 바와 같이, 제1 토큰 트랜잭션(100)은 트랜잭션 식별자(토큰 TxID), 하나 이상의 입력들(104) 및 하나 이상의 출력들(106)을 포함한다. 각각의 입력(104)은 입력 값(108) 및 잠금해제 스크립트(110)를 포함한다. 도 1은 개략적 표현이라는 것에 주의한다. 입력들(104) 자체는 입력 값(108)을 포함하지 않는다. 오히려, 입력들(104)은 이전 출력의 미지출 트랜잭션 출력(UTXO)에 대한 포인터(예컨대, TXID 및 VOUT)를 포함하고, 그 이전 출력은 이제 입력 값(108)으로서 지칭되는 값(108)을 잠근다. 그러나 개개의 잠금해제 스크립트(110)에 의해 잠금해제된 값(108)은 예시 목적을 위해 도시된다. 각각의 출력(106)은 출력 값(112) 및 잠금 스크립트(114)를 포함한다.
제1 토큰 트랜잭션(100)의 출력들(106)은 지출 트랜잭션을 참조하여 위에서 이미 설명되었으므로 먼저 설명될 것이다. 토큰 트랜잭션(100)은 적어도 제1 토큰 출력("상환/토큰 출력")을 포함한다. 제1 토큰 출력은 도 2에서 예시된다. 도 2에 도시되고 위에서 이미 설명된 바와 같이, 제1 토큰 출력(200)은 가변 구성요소(202) 및 불변 구성요소(204)를 포함한다. 불변 구성요소(204)는 토큰 역학 하위 구성요소(206)를 포함하고, 이 예에서, 불변 데이터 하위 구성요소(208)를 포함한다.
가변 구성요소(202)는 제1 토큰 금액(예컨대, 700 토큰)이 할당되는 당사자의 개개의 지불 주소를 포함한다. 토큰 하위 구성요소(206)는 위에서 설명된 검증 단계들의 일부 또는 전부를 수행하도록 구성된다. 예컨대, 토큰 하위 구성요소(206)는 지출 트랜잭션의 미리 결정된 수(예컨대, 하나 또는 두 개)의 출력들에 의해 잠길 디지털 자산의 총 금액이 제1 토큰 금액(700 토큰들)과 동일하다는 것을 검증하도록 구성된다. 제1 토큰 출력(200)의 토큰 하위 구성요소(206)는 또한 제1 토큰 출력(200)을 잠금해제하려고 시도하는 추후 지출 트랜잭션의 입력이 상환 지불 주소를 포함하는 정규 지불 템플릿 또는 가변 구성요소(202) 및 불변 구성요소(204)를 포함하는 제1 토큰 출력(200)의 전체 포맷 중 어느 하나를 갖는 출력을 포함한다는 것을 검증하도록 구성된다. 일반적으로, 토큰 하위 구성요소(206)는 이전에 설명된 검증 기술들 중 임의의 것을 수행하도록 구성될 수 있다.
제1 토큰 트랜잭션(100)은 또한 제2 토큰 출력을 포함할 수 있다. 제2 토큰 출력은 또한 개개의 가변 구성요소 및 개개의 불변 구성요소를 포함한다. 제2 토큰 출력의 가변 구성요소는 제1 토큰 출력(200)의 가변 구성요소(202)와 비교하여 상이한 지불 주소를 포함할 수 있다. 제2 토큰 출력의 토큰 하위 구성요소는, 이제 검증이 상이한 지출 트랜잭션, 즉 제2 토큰 출력을 참조하는 입력이 있는 트랜잭션이라는 점을 제외하면, 제1 토큰 출력(200)의 토큰 하위 구성요소(206)와 동일한 검증 단계들을 수행하도록 구성된다. 즉, 제1 토큰 트랜잭션(100)은 하나 초과의 출력을 가질 수 있고, 이들 출력들 각각은 상이한 지출 트랜잭션에 의해 지출(잠금해제)될 수 있다. 예컨대, 제2 토큰 출력의 토큰 하위 구성요소는 지출 트랜잭션의 미리 결정된 수(예컨대, 하나 또는 두 개)의 출력들에 의해 잠긴 디지털 자산의 총 금액이 제2 토큰 금액(300)과 동일하다는 것을 검증하도록 구성된다.
제1 토큰 트랜잭션(100)은 그의 개개의 토큰 금액들의 합이 지출하려고 시도하고 있는, 제1 토큰 출력(트랜잭션 입력의 TXID 필드에 의해 참조됨)에 잠긴 값(1000개의 토큰들)과 정확히 동일한 한, 임의의 수의 토큰 출력들을 포함할 수 있다.
제1 토큰 트랜잭션(100)은 수수료 잔액 출력을 포함할 수 있다. 이 출력은 수수료 잔액(X-δ)이 수수료 잔액 지불 주소로 리턴되도록 허용한다. 도 1의 예에서, 입력 값(X)을 갖는 수수료 지불 입력은 트랜잭션 수수료(δ)를 지불하는 데 사용된다.
부가적으로 또는 대안적으로, 제1 토큰 트랜잭션(100)은 아토믹 스왑 출력을 포함할 수 있다. 아토믹 스왑 출력은 아래에서 설명될 것이다.
도 1의 예에서, 제1 토큰 트랜잭션(100)은 토큰 입력을 포함한다. 토큰 입력은 위에서 상세히 설명된 지출 입력과 등가이다. 보다 구체적으로, 토큰 입력은 이전 토큰 트랜잭션, 예컨대, 초기 토큰 트랜잭션의 토큰 출력을 참조한다. 이 예에서, 참조된 토큰 출력은 1000개의 토큰들을 잠근다. 토큰 입력은 제1 토큰 트랜잭션(200)의 각각의 출력(106)에 대한 개개의 데이터 쌍을 포함하여, 제1 토큰 트랜잭션의 자체 토큰 입력을 제외한 전부를 포함한다. 즉, 이 예에서, 토큰 입력은 3개의 값들(700, 300, X-δ) 및 토큰의 잠금 스크립트들 각각으로부터 하나씩 3개의 대응하는 지불 주소들("상환/토큰 출력", "토큰 출력(분할)", "수수료 잔액/아토믹 스왑")을 포함한다. 값들(112) 및 지불 주소들은 페어링될 수 있어서, 제1 토큰 금액(700) 다음에는 제1 토큰 출력 잠금 스크립트로부터의 지불 주소가 뒤따르고 그 다음에는 제2 토큰 금액(300), 및 제2 출력 잠금 스크립트로부터의 대응하는 지불 주소가 뒤따르는 식이다. 토큰 입력은 또한, 참조된 토큰 출력을 잠금해제하기 위한 서명을 포함한다. 즉, 서명은 참조된 토큰 출력의 가변 구성요소에 포함된 지불 주소에 대응한다. 앨리스가 토큰들을 이동시키는 경우, 앨리스의 서명이 지출 트랜잭션의 입력에 포함된다. 일부 예들에서, 단지 지불 주소 대신, 전체 잠금 스크립트가 (즉, 데이터 쌍의 일부로서) 입력에 포함될 수 있다.
도 1에 도시된 바와 같이, 제1 토큰 트랜잭션(100)은 수수료 지불 입력을 포함한다. 수수료 지불 입력은 별개의 이전 정규 비-토큰 트랜잭션 출력의 출력을 참조하고, 블록에 제1 토큰 트랜잭션(100)을 포함하기 위해 채굴 노드에 지불되는 수수료를 포함한다. 수수료 지불 입력은 그것이 참조하는 출력의 요건들에 의존하여 적어도 하나의 디지털 서명을 포함한다. 일부 예들에서, 디지털 서명은 제1 토큰 트랜잭션(100)의 토큰 입력에 의해 참조되는 토큰 출력의 소유자에 의해 생성된다. 예컨대, 앨리스가 1000개의 토큰들 중 700개를 밥에게 전송하고 토큰들 중 300개를 상인에게 전송하는 경우, 앨리스는 트랜잭션을 펀딩할 수 있다. 이 경우에, 앨리스의 서명이 수수료 지불 입력에 포함된다. 그러나 상이한 당사자 예컨대, 밥이 밥에게 잠긴 UTXO를 잠금해제함으로써 트랜잭션을 펀딩할 수 있다는 것이 배제되지 않는다. 이 경우에, 밥의 서명이 수수료 지불 입력에 포함된다. 아토믹 스왑 출력은 위에서 언급되었으며, 이 경우에 채굴자 수수료 지불 입력이 (토큰에 대한) 부가적인 지불 작업을 갖는다. 이 예에서 밥은 수수료/"토큰 구매" 입력에 자신의 서명을 포함시킴으로써 트랜잭션을 펀딩하고 "수수료 잔액"/ "아토믹 스왑" 출력이 밥에게 잠긴다. 즉, "수수료 잔액"/"아토믹 스왑" 출력은 밥에 링크된 지불 주소, 예컨대, 밥에 의해 소유되는 공개 키의 해시를 포함한다.
아토믹 스왑을 시행하기 위해, 앨리스는 수수료/"토큰 구매" 지불 입력을 제외한 완전한 트랜잭션을 생성한다. 그 후, 밥은 수수료/"토큰 구매" 지불 입력을 생성 및 추가한다. 이를 행하는 하나의 방식은 앨리스가 자신의 입력(즉, 토큰 입력) 및 다른 당사자가 입력을 추가하도록 허용하는 시그해시 플래그(예컨대, ALL|ANYONECANPAY)로 2개의 대응하는 출력들에 서명하는 것이다. 그 후 밥은 상이한 시그해시 플래그로 입력을 추가한다(예컨대, ALL- 전체 트랜잭션을 밀봉하여 트랜잭션에 어떠한 추가의 추가들도 허용하지 않음).
도 3a 및 도 3b는 아토믹 스왑의 개념을 보다 자세히 예시한다. 실선 화살표들은 필수 입력들 및 출력들을 표시하고 파선 화살표들은 선택적 입력들 및 출력들을 표시한다. 트랜잭션에 대한 입력들은 도면들의 좌측 상에 도시되고 트랜잭션의 출력들은 우측 상에 도시된다. 도 3a는 도 1의 것과 유사한 트랜잭션을 개략적으로 예시한다. 이 예시적인 토큰 트랜잭션은 트랜잭션 수수료(블록에 트랜잭션을 레코딩하기 위해 채굴 노드에 의해 취해진 수수료)를 펀딩하기 위한 수수료 지불 입력과 함께, 이전 토큰 트랜잭션의 토큰 출력을 잠금해제하는, 앨리스에 의해 생성된 토큰 입력을 포함한다. 토큰 트랜잭션은 또한 밥에게 전송된 토큰 출력이 200에서와 같이 토큰 포맷에 포함된 밥의 주소로 잠기는 것과 함께, 앨리스에게 잔액을 지불하는 수수료 잔액 출력이 정규 지불 포맷으로 앨리스의 주소로 잠기는 것을 포함한다(그의 출력에서 지정된 잔액은 수수료 입력 지불과 트랜잭션 수수료 사이의 차이임).
도 3b는 아토믹 스왑 트랜잭션의 예를 예시한다. 밥의 토큰 출력은 도 3a의 것과 동일한 방식으로 생성된다. 앨리스는 재차 이전 토큰 트랜잭션의 토큰 출력을 잠금해제하기 위해 토큰 입력을 생성하지만 이번에는 'ALL/ANYONECANPAY' 시그해시 플래그로 트랜잭션에 서명한다. 이는 앨리스의 서명이 모든 출력들에 서명하는 것이 아니라, 이 단 하나의 입력, 즉 토큰 출력을 지출하는 입력이 이 시그해시 플래그로 서명된다는 것을 의미한다. 나머지 입력들은 제외된다. 이 시그해시 플래그는 누구나 다른 입력들을 추가하거나 제거하도록 허용하여서, 누구나 트랜잭션에 펀드를 추가할 수 있지만, 목적지들 및 금액들을 변경할 수는 없다. 이는 밥이 채굴자 수수료를 또한 포함할 자신의 지불 입력만을 추가하도록 허용한다. 밥은 서명을 포함하고 'ALL' 시그해시 플래그로 서명한다. 이는 밥의 서명이 모든 입력들 및 출력들에 서명하여, 임의의 추가로 가능한 수정으로부터 모든 요소들을 보호함을 의미한다. 이 예에서, 제2 출력은 밥 입력에 의해 추가된 것으로부터 앨리스에게 지불된다. 이는 밥이 토큰에 대해 앨리스에게 지불하는 경우 그리고 그 경우에만 토큰이 밥에게 전송되는 아토믹 스왑을 시행하는 효과를 갖는다. 밥이 트랜잭션의 어떤 구성요소로도 만족되지 않는 경우, 밥은 단순히 서명을 제공하지 않고 이에 따라 토큰이 그의 주소로 이동되지 않고 앨리스에게 지불되지 않는다. 마찬가지로, 밥은 앨리스에 의해 생성되고 서명된 입력들 및 출력들을 수정할 수 없기 때문에, 앨리스는 앨리스에 의해 세팅된 지불 조건이 충족되는 경우에만 밥이 토큰을 수신할 수 있음을 확신할 수 있다.
도 4는 발행으로부터 상환까지의 토큰들의 예시적인 흐름을 예시한다. 흐름은 일반적으로 위로부터 아래로 진행된다. 선택적 제1 단계로서, 토큰 발행자와 초기 수신자인 앨리스 간에 법적 계약이 체결된다. 계약은 토큰을 상환하는 방법 및 초기 토큰 금액(예컨대, 1000)을 포함하여 토큰의 약관들 및 조건들을 명시할 수 있다. 그 후, 토큰 발행자는 초기 토큰 트랜잭션을 생성하고 토큰들을 앨리스에게 전송할 수 있다. 대안적으로, 앨리스는 초기 토큰 트랜잭션을 생성하고 그 중 일부 또는 전부를 다른 사용자 예컨대, 밥 또는 심지어 자신에게 전송할 수 있다. 도 4에서, 앨리스는 모든 토큰들을 밥에게 전송하는데 즉, 모든 토큰들은 밥의 지불 주소에 전송되는 단일 토큰 출력에 할당된다. 그 후 밥은 2개의 토큰 출력들을 갖는 토큰 트랜잭션을 생성한다. 제1 토큰 출력은 상인의 지불 주소로 300개의 토큰들을 전송한다. 제2 토큰 출력은 밥의 상이한 지불 주소일 수 있는 밥의 지불 주소로 700개의 토큰들을 전송한다. 그 후 상인은 즉, 상환 지불 주소로 토큰들을 전송함으로써 300개의 토큰을 상환한다. 그 후 밥은 또한 초기에 500개의 토큰들을 상환하면서, 남은 200개의 토큰들을 밥과 링크된 다른 지불 주소로 전송한다. 마지막으로, 밥은 200개의 토큰들을 상환한다. 각각의 트랜잭션에서, 인입하는 토큰들의 금액은 나가는 토큰들의 금액과 매칭된다는 것에 주의한다.
본 발명의 실시예들은 위에서 일반적으로 설명되었다. 본 발명의 특정 구현이 이제 설명될 것이다. 이 특정 예는 주로 명목 화폐를 표현하는 토큰들의 관점에서 설명되는데. 즉, 토큰들은 명목화폐-고정 토큰(fiat-pegged token)들이다. 그러나 이는 본 발명의 다수의 가능한 사용 사례들 중 단지 하나일 뿐이다. 또한, 이 예는 비트코인 블록체인을 사용하여 구현되는 것으로 의도된다. 그러나 일반적으로 임의의 출력-기반(예컨대, UTXO-기반) 블록체인이 사용될 수 있으며 그 중 비트코인 블록체인은 하나의 특정 예이다.
이 예에 따르면, 토큰들은 비트코인, 보다 구체적으로 사토시 또는 사토시 단위라고 하는 비트코인의 기본 단위를 사용하여 표현된다. 토큰 출력은 단일 토큰(예컨대, 이벤트들, 영화 티켓들, 버스 티켓들 등을 위한 유틸리티 토큰)을 표현하는 단일 사토시를 포함할 수 있다. 따라서 이 토큰은 분할 불가능하고 그의 수명 사이클 동안 분할될 수 없다. 또는, 토큰 출력은 다수의 토큰들의 엔벨로프를 표현하는 다수의 사토시를 포함할 수 있다(예컨대, USD-고정 토큰들은 하나의 토큰이 1 USD 센트를 표현함).
토큰 출력은 가변 부분 및 불변 부분을 포함한다. 가변 부분은 ECDSA 사용을 통해 소유한 비트코인(예컨대, 사토시)을 전달하는 정규 비트코인 지불 템플릿과 동일하다. 불변 부분은 토큰의 수명 시간 전반에 걸쳐 변경하거나 생략할 수 없다.
이제 각각의 사토시는 토큰을 표현하며 1 사토시 자체보다 더 저렴하거나 더 비싼 것을 표현할 수 있다는 사실에 관계없이 그의 정규 기능을 정지시킨다. 앨리스는 다음 토큰 트랜잭션에서 이 정확한 템플릿을 잠금 스크립트로서 유지하지 않는 한, 밥에게 어떠한 토큰도 이동시킬 수 없다. 가변 부분 내 소유 주소만이 변경될 수 있다.
이는 메타데이터를 사용하여 토큰 출력으로서 출력을 해석하는 이전 토큰 시도들과 동일하지 않다는 것에 주의한다. 본 발명은 비트코인으로서의 그의 정규 용도와 관련하여 사토시의 역학을 근본적으로 변경한다.
가변 부분은 의도적으로 토큰 잠금 스크립트의 맨 처음에 있으며, 단지 정규 지불 템플릿 예컨대, P2PKH 템플릿이다. 이는 기존 블록체인 클라이언트 애플리케이션들 및 브라우저들과의 최대 호환성을 제공하고, 지불 주소(템플릿에서 래핑됨(wrapped))가 현재 행해지는 방식으로 검색 및 로케이팅되게 한다.
토큰 역학 부분은 적어도 3개의 조건들을 시행한다. 첫째, 토큰 지출은 다음 UTXO가 새로운 소유 주소를 제외하고 지출되는 UTXO와 정확히 동일한 잠금 스크립트를 갖는 경우에만 가능하다. 둘째, 정규 비트코인 잠금 스크립트 템플릿(예컨대, P2PKH, P2PK 등)으로 트랜잭션에 의한 지출은 그것이 미리 결정된 상환 지불 주소를 포함하는 P2PKH가 아니면 실패한다. 미리 결정된 상환 지불 주소는 앨리스에게 발행된 계약에 포함되며 토큰 잠금 스크립트에 하드코딩된다. 토큰 발행자가 상환 주소를 자신에게 링크된 주소로 세팅하는 경우, 이는 발행자만이 예컨대, USD, 금 등과 같은 표현된 자산을 릴리즈함으로써 자산-표현 사토시를 사토시로서의 그의 오리지널 정규 용도로 전환하는 능력을 갖는다는 것을 의미한다. 이는 토큰들을 퍼미션리스(permissionless)로 만든다. 셋째, 토큰들을 이동시킬 때 현재 미지출 토큰 출력(UTXO)의 토큰 출력에서 사토시의 금액은 지출 트랜잭션(예컨대, 상환 또는 다음 토큰 트랜잭션)의 토큰 출력에서 사토시의 금액과 정확히 동일하거나 두 개 이상의 토큰들의 세트 ― 이들의 금액의 합은 UTXO의 오리지널 금액이 동일해야 함 ― 로 분할되어야 한다. 예컨대, 토큰들은 지출 트랜잭션의 2개의 출력들로 분할될 수 있으며, 2개의 출력들의 잠금 스크립트들은 지출되는 (가변 부분의 주소들을 제외하고) UTXO의 잠금 스크립트와 동일하다.
이러한 스테이트풀 트랜잭션(stateful transaction)들을 통해 푸시된 상태는 각각의 홉마다 업데이트된 소유 주소 및 (토큰들의 엔벨로프의 경우에만) 분할을 통해 감소될 수 있는 토큰들의 금액이다.
불변 데이터 부분은 2개의 필드들을 갖는다. 하나의 필드는 토큰 프로토콜 식별자 예컨대, 명목화폐-고정 토큰(fiat-pegged token)에 대한 토큰 프로토콜 플래그를 포함한다. 식별자는 토큰 유형을 지정하는 데 사용된다. 제2 필드는 특수 트랜잭션에 대한 포인터(TxID)이며, 이는 a) 모든 법적 약관들, 조건들, 라이선스들 및 토큰 속성들 및 발행과 관련된 임의의 다른 필수 정보를 가진 (예컨대, 발행 엔티티와 클라이언트 간의) 초기 발행 계약; 및 b) 토큰 출력과 관련하여 후속 트랜잭션(이는 발행 트랜잭션이 될 것임)에서 토큰들로 변형되도록 미리 결정된 정확한 사토시 잔액을 제2 필드에 포함한다.
불변 데이터 필드는 스크립트 평가 동안 스크립트 코드의 부분으로서 실행의 시도들을 회피하는 데이터 첨부가 되도록 OP_RETURN 작업코드 뒤에 배치된다. 즉, 불변 데이터는 바람직하게는, OP_RETURN 트랜잭션들에서 검색들을 수행하는 앱들 및 브라우저들에 대한 최대 호환성을 위해 잠금 스크립트의 끝 및 OP_RETURN 작업코드 바로 뒤에 포함된다.
트랜잭션 구조 자체와 관련하여, 토큰 트랜잭션의 출력들은 다음 3개의 유형들: i) 상환을 위한 정규 출력, ii) 토큰 출력 또는 iii) 수수료 잔액, 아토믹 스왑 등에 사용되는 정규 출력 중 하나를 취할 수 있다.
예로서, 앨리스는 그녀를 대신하여 1000개의 토큰들을 발행하도록 법 인가 엔티티(legal authorised entity)에 요청하고 엔티티에 자신의 지불 주소를 제공할 수 있다. 엔티티는 요청된 금액(이 경우에, 1000)에 대응하는 사토시의 사전 할당된 금액을 갖는 지출 가능한 트랜잭션의 형태로 합의(agreement)를 생성한다. 합의의 약관들, 조건들 및 라이센스는 앨리스의 요구된 액션들(예컨대, 대응하는 금액의 명목 화폐를 엔티티에 이전)를 명시하고 엔티티가 예컨대, ALL|ANYONECANPAY 플래그로 서명하여 앨리스가 자산의 서명을 추가하도록 허용한다. 앨리스가 서명하고 블록체인에 대한 합의를 게시하고 명시된 요구된 액션들(명목 금액의 이전)을 수행하면, 엔티티는 그녀를 대신하여 그녀의 지불 주소로 토큰을 발행한다. 이제 앨리스는 모든 토큰들을 한 번에 또는 토큰들의 일부를 사용/지출/이전할 수 있다. 후속 소유자들은 마음대로 토큰들을 상환할 수 있고, 이에 따라 토큰은 퍼미션-리스(permission-less)가 된다.
토큰 출력의 불변 부분으로 돌아가서, 불변 부분은 대략 2개의 부분들을 포함한다. 제1 부분은 OP_PUSH_TX를 구현하고, 스크립트 실행 내에서 현재 트랜잭션의 필드들에 액세스하는 것을 담당한다. 제2 부분은 토큰 로직들(tokens logics)이다.
시그해시 프리이미지는 위에서 설명되었다. OP_PUSH_TX는 현재 트랜잭션 즉, 토큰 출력을 잠금해제하는 지출 트랜잭션에 대응하는 프리이미지의 ECDSA 서명을 수행하며, 이는 실행된 스크립트 내부에서 액세스되도록 잠금해제 스크립트에 푸시된다. OP_PUSH_TX는 결국 서명의 검증을 위해 OP_CHECKSIG를 호출한다. 이 내부 ECDSA 서명은 공개적으로 액세스 가능하고 이에 따라 토큰 소유 릴레이에 사용되는 것들과 관련이 없어야 하는 임의적 개인-공개 키 쌍들(하나의 임시 쌍, 하나의 불변 쌍)로 수행된다. 또한, 이 경우 OP_CHECKSIG는 유효성 검증기로서 역할을 하는데, 그 이유는 이것이 호출될 때 실제 이전 및 현재 트랜잭션 필드들로부터 ECDSA 검증을 위해 자체 프리이미지를 구성하기 때문이다. 따라서 그것은 실제 필드들이 잠금해제 스크립트에 푸시된 필드들과 동일한 것(또는 동일하지 않은 것)에 의존하여 실패 또는 성공할 것이다.
토큰 로직은 비트코인 사토시를 토큰들로 전환한다. 이를 위해, 코드는 사토시 지출을 제어하기 위해 이전 트랜잭션(즉, 그의 미지출 출력이 토큰들을 포함함)의 사토시 값(금액) 및 현재 트랜잭션(즉, 지출 트랜잭션)의 사토시 값에 대한 액세스를 요구한다. 코드는 또한 출력 잠금 스크립트의 포맷을 제어하기 위해 이전 및 현재 잠금 스크립트들에 대한 액세스를 요구한다.
현재(지출) 트랜잭션의 잠금해제 스크립트에 푸시된 프리이미지가 실제 현재 트랜잭션 프리이미지와 동일한 것으로 유효성 검증되면, 그것은 scriptCode 및 이 입력에 의해 지출된 출력의 값 및 hashOutputs을 포함하는 모든 관련 필드들의 추출을 위해 파싱된다. 잠금 스크립트 및 이전 UTXO(즉, 지출되는 것)의 값들(즉, 금액들)은 그대로 프리이미지에서 제공되지만, (그의 새로운 값들과 결합되는) 새롭게 생성된 모든 출력들의 잠금 스크립트들의 해싱의 결과만이 이용 가능하다. 따라서 이러한 새로운 출력의 잠금 스크립트들 및 이들의 대응하는 값들은, 호출될 때, OP_CHECKSIG가 구성하는 것과 동일한 것으로 이전에 입증된 프리이미지의 hashOutputs 필드에 대해 다음에 유효성 검증되도록 지출 트랜잭션의 잠금해제 스크립트에서 프리이미지 옆에 배치되어야 한다.
이전 및 다음 출력들에서 트랜잭션에 대한 모든 잠금 스크립트들 및 이들의 값들(예컨대, 금액들)이 실행되는 코드에 의해 액세스 가능하면, 토큰 규칙들을 시행하는 것이 가능하다.
다음 예시적인 규칙들이 시행될 수 있다. 특정 사용 사례에 의존하여 다른 부가적인 또는 대안적인 규칙들이 구현될 수 있다는 것이 인지될 것이다. 이 예에서는 다음이 허용된다:
1. 상환 기능 ― 토큰들의 성질을 사토시의 고유한 성질, 즉 기본 디지털 자산으로 다시 변경할 수 있는 하드코딩된 주소를 정의하는 데 사용됨.
2. 토큰들의 금액을 최대 2개의 가능한 출력들로 분할함.
3. 채굴자 수수료 지출로부터 잔액을 받기 위한 P2PKH 포맷을 갖는 제3 선택적 출력은 토큰 셀러가 돈을 받기 위한 "아토믹 스왑"의 경우에 또는 부가적인 입력으로 수행된다.
더 구체적으로 말하면, 규칙들은 다음과 같다:
1. 토큰 트랜잭션의 제1 출력은 다음을 위해서만 사용된다:
a) 상환 ― 필수 하드코딩된 상환 주소를 포함하는 표준 P2PKH 템플릿, 또는
b) 토큰 릴레이 ― 이전 출력 포맷과 동일한 스마트 토큰 잠금 스크립트.
2. 제2 출력은 토큰 분할의 경우에 대해 선택적이며 스마트 토큰 유형만 가능하다. 게다가:
a) 존재하는 경우, 그의 출력 금액 및 제1 출력 금액의 합은 지출되는 UTXO의 금액과 동일해야 한다.
b) 그렇지 않으면, 제1 출력의 금액은 소비되는 UTXO의 양과 동일해야 한다.
3. 제3 출력은 표준 P2PKH 템플릿 전용이 되어야 한다(주소는 임의적임). 존재하는 경우, 이는 토큰 동작들에 대한 지불의 변경(즉, 부가적인 입력으로 행해짐)에 사용된다.
P2PKH 템플릿은 트랜잭션 출력 스크립트라는 것에 주의하며, 그의 16진수 형식은: 그의 25바이트 길이로 인해 VarInt(다음 스크립트의 길이를 지정함) 0x19에 선행하는 잠금해제 스크립트로 푸시할 때 "0x76a914 + PKH + 0x88ac"이다. PKH는 공개 키 해시 주소이다.
이제 이러한 규칙들을 시행하기 위한 예시적인 의사 코드가 제공된다.
redemption_PKH = 25daa25932d355826ce60881978f79621f1dfcd9 // pushed into stack before function code
function token (sighashPreimage, amountOne, PKH_One, amountTwo, PKH_Two, amountChange, PKH_Change) {
// validate the preimage is correct
assert ( validate( sighashPreimage ) );
// parse the preimage
len = sizeof( sighashPreimage );
// since script size range is known, VarInt has '0xfd' prefix followed by two bytes with size value
// skip '0xfd' prefix to the actual script length
VarInt = sighashPreimage[ 105:107];
// scriptCode is a locking script of previous output
scriptCode = sighashPreimage[ 107: 107+VarInt ];
value = sighashPreimage[ len ― 52 : len ― 44 ];
hashOutputs = sighashPreimage [ len ― 40 : len ― 8 ];
First Script;
// first output script maty be either P2PKH (redemption case) or exactly the same script as in the previous TX apart from the PKH address
if( PKH_One != redemption_PKH ){
// read from scriptCode the constant part that follows new address (after: "76a914" + PKH)
// reconstruct the whole script with data parts, substituting only new possessor address
// 23 is the length of the first 3 opcodes and the address
FirstScript = concatenate( VarInt, "76a914", PKH_One, scriptCode[ 23: ]);
}
else {
//redemption may be part of a split, but must be first output
// remainder is "88ac";
FirstScript = concatenate("1976a914", PKH_One, "88ac"); // in case of P2pKH VarInt is 0x19
}
NextScripts = concatenate( amountOne, FirstScript );
// second optional output for splitting tokens case (if present, it may only be smart token output)
// allow to split to tokens with no value (0) ― may be used for proves
if ( PKH_Two ){
NextScripts = concatenate (NextScripts, amountTwo, VarInt, "76a914", PKH_Two,
scriptCode[ 23 : ] );
assert( value == ( amountOne + amountTwo ) );
}
else {
assert( value == amountOne );
}
// third optional output for a change of TX payment (of present, mandatory P2PKH format)
if ( PKH_Change ){
// 0x19 prefix added ― it is VarInt of P2PKH (25)
NextScripts == concatenate( NextScripts, amountChange, "1976a914", PKH_Change, "88ac" );
}
// finally validate concatenation of all new outputs' locking scripts and amounts
assert ( hashOutputs == sha256( sha256( NextScripts ) ) );
}
다음 코드는 비트코인 스크립트 언어의 실제 예시적인 구현을 예시한다. 이 구현의 경우, 잠금해제 스크립트 파라미터들은 위의 의사 코드 함수 정의에서와 동일한 순서(왼쪽에서 오른쪽)로 사용되었으며, 이는 가장 왼쪽이 먼저 스택에 푸시된다는 것을 의미한다. 하드코딩된 상환 함수 주소는 잠금 스크립트의 "불변 코드" 부분의 제1 필드가 되도록 배치되고, 이에 따라 (ECDSA 서명 검증을 행하는 가변 부분을 고려하지 않는 경우) 잠금해제 스크립트 데이터 직후에 스택으로 푸시된다.
이 스크립트 구현은 (비트코인의 현재 수수료 지불은 TX 크기에만 의존하기 때문에) 시간 보다는, 공간에 최적화된다는 것에 주의한다.
// The 'variable data' part template (P2PKH), followed by redemption address and preimage fetch:
OP_DUP OP_HASH160 2f2ec98dfa6429a028536a6c9451f702daa3a333 OP_EQUALVERIFY OP_CHECKSIG OP_VERIFY 25daa25932d355826ce60881978f79621f1dfcd9 OP_7 OP_ROLL OP_DUP
// OP_PUSH_TX implementation
OP_HASH256 OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_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 00 OP_CAT 4091de8968a1066ab9c6f292823ab43111fb1d0630f3f087e7e42f03533f92a2d779753ff4a0922831cf7fd3692ec96055665621e97adc95a8a45766e3e0c26a OP_ADD 119ef8f4f04e6864c0608c6d71018e00fb2d17049a8750644299c78b547c2924 OP_MUL 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_TUCK OP_MOD OP_2DUP OP_SWAP OP_2 OP_DIV OP_GREATERTHAN OP_IF OP_SUB OP_ELSE OP_NIP OP_ENDIF OP_SIZE OP_DUP 25 OP_ADD 30 OP_SWAP OP_CAT 022100c7a2f4a156ecd42ba9326b31a86c61225dec5a71c3238408f360a9d2f3cf0be002 OP_CAT OP_SWAP OP_CAT OP_SWAP OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT 41 OP_CAT 03ea9a8e84d865bcd6fc0d1354816bc2eb423a6adf80e42654f1edc101ed033ce3 OP_CHECKSIGVERIFY
// parse sighash preimage into 4 relevant fields: VarInt (length), scriptCode, value (amount being spent), hashOutputs (hash of all outputs pair with their respective amounts)
68 OP_SPLIT OP_NIP OP_3 OP_SPLIT 17 OP_SPLIT OP_NIP OP_OVER OP_1 OP_SPLIT OP_NIP 00 OP_CAT 17 OP_SUB OP_SPLIT OP_8 OP_SPLIT OP_4 OP_SPLIT OP_NIP 20 OP_SPLIT OP_DROP
// prepare the first output amount
OP_10 OP_ROLL OP_8 OP_NUM2BIN OP_DUP
// construct first output script according to address (smart token locking script or standard 'P2PKH' for redemption)
OP_11 OP_ROLL OP_DUP OP_8 OP_ROLL OP_EQUAL
OP_NOTIF OP_6 OP_PICK 76a914 OP_CAT OP_SWAP OP_CAT OP_5 OP_PICK OP_CAT
OP_ELSE 1976a914 OP_SWAP OP_CAT 88ac OP_CAT
OP_ENDIF
// pair (concatenate) the first output script with its previously prepared amount
OP_CAT
// construct second optional smart output (if exists)
// enforce immutability of amount of tokens (for both cases ― splitting or plain transfer)
OP_8 OP_PICK
OP_IF OP_9 OP_PICK OP_8 OP_NUM2BIN OP_CAT OP_5 OP_PICK 76a914 OP_CAT OP_9 OP_PICK OP_CAT OP_5 OP_PICK OP_CAT OP_CAT OP_3 OP_ROLL OP_ROT OP_9 OP_PICK OP_ADD OP_NUMEQUALVERIFY
OP_ELSE OP_3 OP_ROLL OP_ROT OP_NUMEQUALVERIFY
OP_ENDIF
// construct third optional standard P2PKH output for change (if exists)
OP_4 OP_PICK
OP_IF OP_5 OP_PICK OP_8 OP_NUM2BIN OP_CAT 1976a914 OP_5 OP_PICK OP_CAT 88ac OP_CAT OP_CAT
OP_ENDIF
// validate that all new outputs with their corresponding amounts passed to unlocking script (on top of the stack)
// were the correct ones ― their hashing result identical to hashOutputs field from preimage (second to the top of the stack),
// which proved to be consistent with actual spending transaction at the very first step.
OP_HASH256 OP_EQUAL
// constant data part
OP_RETURN 27ed5442ab151b32db7b586d433879d84af3398a 723c903d83cdce9f32246a451652f4b4f469ef78d630bf0f22770cb16bbc187b
결론
위의 실시예들은 단지 예로서만 설명되었다는 것이 인지될 것이다.
더 일반적으로, 본원에서 개시된 일 양상에 따르면, 블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법이 제공되며, 각각의 토큰은 블록체인의 기본 디지털 자산 네이티브 유닛들 중 단일 유닛에 의해 표현되며, 방법은, 제1 토큰 트랜잭션을 생성하는 단계; 및 제1 토큰 트랜잭션을 블록체인 네트워크로 송신하는 단계를 포함하고, 제1 토큰 트랜잭션은 제1 토큰 출력을 포함하고, 제1 토큰 출력은 제1 토큰 잠금 스크립트 및 제1 토큰 금액을 포함하고, 여기서 제1 토큰 잠금 스크립트는 가변 구성요소 및 불변 구성요소를 포함하고, 가변 구성요소는 지불 템플릿에 매립된 제1 지불 주소를 포함하고, 불변 구성요소는 토큰 역학 하위 구성요소를 포함하고, 지출 트랜잭션의 입력 스크립트 ― 입력 스크립트는 지출 트랜잭션의 자체 입력 스크립트를 제외한 전부뿐만 아니라 개개의 잠금 스크립트 및 지출되는 이전 트랜잭션 출력에서 잠긴 금액을 포함함 ― 와 함께 실행될 때, 토큰 역학 하위 구성요소는, 지출 트랜잭션의 입력 스크립트로부터 하나 이상의 데이터 쌍들을 획득하고 ― 각각의 데이터 쌍은, i) 지출 트랜잭션 출력들의 개개의 잠금 스크립트에 포함된 적어도 개개의 지불 주소 및 ii) 해당 출력의 개개의 잠금 스크립트들에 의해 잠긴 기본 디지털 자산의 대응하는 금액을 포함함 ― ; 지출 트랜잭션의 하나 이상의 출력들이, a) 미리 결정된 지불 주소를 포함하는 개개의 지불 스크립트 템플릿, 또는 b) 미리 결정된 지불 주소 이외의 개개의 지불 주소를 포함하는 개개의 가변 구성요소 및 가변 구성요소를 뒤따르는 불변 구성요소를 포함하는 개개의 잠금 스크립트를 포함한다는 것을 검증하고; 그리고 지불 트랜잭션의 해당 하나 이상의 출력들에 대해, 하나 이상의 출력들의 개개의 잠금 스크립트들에 의해 잠긴 기본 디지털 자산의 총 금액이 제1 토큰 금액과 동일하다는 것을 검증하도록 구성되고, 그리고 토큰 역학 하위 구성요소는 검증 단계들 중 임의의 것이 실패하는 경우 실행 동안 실패하도록 구성된다.
지불 트랜잭션은 제1 잠금 스크립트 포맷을 포함하는 적어도 하나의 출력을 포함한다. 지출 트랜잭션은 하나 초과의 출력, 예컨대, 각각이 개개의 잠금 스크립트 포맷을 갖는 제2 출력 및 제3 출력을 포함할 수 있다. 트랜잭션이 성공적이 되기 위해, 이러한 지출 트랜잭션의 새로운 출력들의 모든 잠금 스크립트들은 미리 결정된 상환 주소를 갖는 표준 지불 템플릿을 갖거나 지출되는 이전 트랜잭션의 출력과 동일한 스마트 토큰 포맷을 가져야 한다. 유일한 예외는 선택적 출력(예컨대, 마지막 출력)이며, 이 선택적 출력의 잠금 스크립트는, 예컨대, 필요한 경우 채굴자 수수료 지불로부터의 잔액 또는 아토믹 스왑 지불 수신에 대해 사용되는 임의의 임의적 주소가 포함되어 있는 표준 지불 템플릿이어야 한다. 지출 트랜잭션의 입력은 전체 트랜잭션의 시그해시 프리이미지 및 각각의 출력에 대한 데이터 쌍을 포함해야 하며, 그의 해싱의 결과는 ECDSA 검증 공식에서 입력으로서 역할을 한다. 토큰 역학 하위 구성요소는 이 가정에서 동작하도록 구성되는데 ― 가정이 충족되지 않는 경우, 토큰 역학 하위 구성요소의 실행이 실패하여, 어떠한 토큰 동작도 불가능하게 될 것이다. 7
또한, 이것은, 지출 트랜잭션이 지출되도록 시도된 출력의 제1 토큰 잠금 스크립트의 불변 구성요소를 포함하지 않는 부가적인 선택적 채굴자 수수료 잔액 출력을 갖는 경우에 해당된다. 이러한 선택적 출력에 잠긴 네이티브 토큰은 하나의 트랜잭션을 통해 다른 트랜잭션으로 새롭게 정의된 토큰들의 보존된 금액의 일부가 아니다.
지출 트랜잭션의 일부 부분들은 그의 원시 형식으로 입력 스크립트에 포함되는 반면, 다른 일부는 그의 해싱의 결과로서 포함된다.
각각의 지불 주소는 지불 템플릿에 매립될 수 있다.
실시예들에서, 지출 트랜잭션은 제1 잠금 스크립트를 포함하는 제1 출력 및 제2 잠금 스크립트를 포함하는 제2 출력을 포함할 수 있으며, 토큰 역학 하위 구성요소는, 지출 트랜잭션의 제1 출력이, a) 미리 결정된 지불 주소를 포함하는 개개의 지불 스크립트 템플릿, 또는 b) 미리 결정된 지불 주소 이외의 개개의 지불 주소를 포함하는 개개의 가변 구성요소 및 가변 구성요소를 뒤따르는 불변 구성요소를 포함하는 제1 잠금 스크립트를 포함한다는 것을 검증하고; 만약 존재하는 경우, 지출 트랜잭션의 제2 출력이, a) 미리 결정된 지불 주소를 포함하는 개개의 표준 지불 스크립트 템플릿, 또는 b) 미리 결정된 지불 주소 이외의 임의의 주소를 포함하는 개개의 가변 구성요소 및 가변 구성요소를 뒤따르는 불변 구성요소를 포함하는 제2 잠금 스크립트를 포함한다는 것을 검증하고; 그리고 제2 출력이 존재하는 경우, 지출 트랜잭션의 제1 잠금 스크립트 및 제2 잠금 스크립트에 의해 잠긴 디지털 자산의 총 금액이 제1 토큰 금액과 동일하다는 것을 검증하도록 구성된다.
실시예들에서, 토큰 역학 구성요소는 지출 트랜잭션의 제1 잠금 스크립트가 미리 결정된 지불 주소를 포함하는 표준 지불 스크립트 템플릿을 포함하지 않는 경우, 제1 잠금 스크립트가 미리 결정된 지불 주소 이외의 지불 주소를 포함하는 개개의 가변 구성요소, 및 가변 구성요소를 뒤따르는 불변 구성요소 ― 불변 구성요소는 지출되는 이전 트랜잭션의 제1 토큰 잠금 스크립트의 대응하는 불변 구성요소와 동일함 ― 를 포함한다는 것을 검증하고; 그리고/또는 지출 트랜잭션의 제2 잠금 스크립트가 존재하는 경우, 제2 잠금 스크립트가 임의의 지불 주소를 포함하는 개개의 가변 구성요소, 및 가변 구성요소에 뒤따르는 불변 구성요소 ― 불변 구성요소는 지출되는 이전 트랜잭션의 제1 토큰 잠금 스크립트의 대응하는 불변 구성요소와 동일함 ― 를 포함한다는 것을 검증하도록 구성될 수 있다.
실시예들에서, 불변 구성요소는 미리 결정된 지불 주소를 포함할 수 있다.
즉, 미리 결정된 주소는 불변 부분에 하드코딩된다.
실시예들에서, 지출 트랜잭션의 입력 스크립트는 시그해시 프리이미지(sighash preimage)를 포함하고, 프리이미지는 제1 토큰 잠금 스크립트 및 제1 토큰 금액을 포함할 수 있고, 토큰 역학 하위 구성요소는, 상기 검증 단계들을 수행하기 위해 프리이미지로부터 지출되는 출력의 제1 토큰 금액 및 제1 토큰 잠금 스크립트 둘 모두를 추출하도록 구성된다.
지출 트랜잭션의 입력에 포함된 제1 토큰 잠금 스크립트는 그 순간 실행되고 있는 것과 동일하며 지출되도록 시도된 출력의 잠금 스크립트이다. 지출 트랜잭션의 입력에 포함된 제1 토큰 금액은 지출되도록 시도된 출력에서 유지된 값이다.
실시예들에서, 프리이미지는 하나 이상의 데이터 쌍들의 컨케터네이션의 해시를 포함하고, 각각의 데이터 쌍은 지출 트랜잭션의 개개의 잠금 스크립트로부터의 개개의 지불 주소 및 개개의 잠금 스크립트에 의해 잠긴 대응하는 금액을 포함할 수 있고, 토큰 역학 하위 구성요소는, 프리이미지로부터 하나 이상의 데이터 쌍들의 컨케터네이션의 해시를 추출하고; 하나 이상의 데이터 쌍들에 기초하여 해시를 생성하고; 그리고 생성된 해시가 추출된 해시와 동일하다는 것을 검증하도록 구성된다.
지출 트랜잭션의 출력들의 포맷에 의존하여, "대응하는 금액들" 중 하나 이상이 네이티브 토큰들 예컨대, 선택적인 잔액 또는 "아토믹 스왑" 지불 수신에 대한 출력일 수 있고, 대응하는 금액들 중 하나 이상은 예컨대, 상환 또는 토큰 출력들을 위해 재정의된 토큰일 수 있다.
실시예들에서, 하나 이상의 데이터 쌍들이 사용되어 입력 스크립트로부터 획득되거나 프리이미지로부터 이전 출력 잠금 스크립트의 입력 주소 및 금액 쌍을 획득함으로써 구성된 해시를 생성할 수 있다.
"해시"에 대한 임의의 참조는 "이중 sha256 해싱"과 동일시될 수 있다. 일반적으로, 동일한 해시 함수가 일관되게 사용되는 한, 임의의 해시 함수가 사용될 수 있다.
실시예들에서, 토큰 역학 하위 구성요소는, 지출 트랜잭션 데이터의 프리이미지를 생성하고; 그리고 지출 트랜잭션 데이터의 생성된 프리이미지가 지출 트랜잭션의 입력 내에 포함된 프리이미지와 동일하다는 것을 검증하도록 구성될 수 있다.
실시예들에서, 지출 트랜잭션의 입력은 더미 개인 키 및 대응하는 더미 공개 키를 포함할 수 있고, 토큰 역학 하위 구성요소는, 더미 개인 키 및 지출 트랜잭션의 입력에 포함된 프리이미지의 해시를 사용하여 디지털 서명을 생성하고; 그리고 더미 공개 키 및 지출 트랜잭션의 생성된 프리이미지의 해시에 대해 유효성 검증될 때 디지털 서명이 유효한 서명이라고 검증함으로써, 지출 트랜잭션의 생성된 프리이미지가 지출 트랜잭션의 입력 내에 포함된 프리이미지와 동일하다는 것을 검증하도록 구성된다.
예컨대, ECDSA 서명들을 생성하기 위해 특정 서명 알고리즘에 의존하여, 더미 개인 임시 개인 키가 요구될 수 있다.
예컨대, 토큰 역학 하위 구성요소는 생성된 프리이미지의 상기 검증을 수행하도록 구성된 OP_PUSH_TX 의사-작업코드 구현을 포함할 수 있다.
실시예들에서, 토큰 역학 하위 구성요소는, 지출 트랜잭션의 개개의 잠금 스크립트에 포함된 개개의 지불 주소가 제1 토큰 출력의 가변 구성요소에 포함된 제1 지불 주소와 동일한 유형이라는 것을 검증하도록 구성될 수 있다.
또한, 토큰 역학 하위 구성요소는 지출 트랜잭션의 개개의 출력(들)이 제1 토큰 출력에 포함된 지불 스크립트 템플릿과 동일한 유형의 개개의 지불 스크립트 템플릿 예컨대, P2PKH 잠금 스크립트를 포함한다는 것을 검증하도록 구성될 수 있다.
실시예들에서, 제1 지불 주소의 유형은 공개 키 해시 주소일 수 있다.
실시예들에서, 제1 토큰 금액은 기본 디지털 자산의 단일 단위를 포함할 수 있다.
실시예들에서, 제1 토큰 금액은 기본 디지털 자산의 다수의 단위들을 포함할 수 있다.
실시예에서, 불변 구성요소는 데이터 하위 구성요소를 포함할 수 있고, 여기서 데이터 하위 구성요소는 토큰 프로토콜 식별자; 및 토큰 발행 트랜잭션의 식별자 중 하나 또는 둘 모두를 포함하고, 토큰 발행 트랜잭션은 i) 토큰 발행자와 초기 토큰 수신자 사이의 발행 계약, 및 ii) 초기 토큰 금액 중 하나 또는 모두를 포함한다.
불변의 변경 불가능 데이터 하위 구성요소는 OP_RETURN 작업코드 뒤에 배치될 수 있다.
실시예들에서, 지출 트랜잭션은 제3 잠금 스크립트 및 대응하는 제3 금액을 포함하는 제3 출력을 포함할 수 있고, 토큰 역학 하위 구성요소는, 제3 잠금 스크립트가 미리 결정된 지불 유형 템플릿의 개개의 지불 주소 및 그 개개의 대응하는 금액을 포함한다는 것을 검증하도록 구성된다. 예로는 P2PKH 지불 템플릿의 PKH 주소가 있다.
실시예들에서, 제1 토큰 트랜잭션은 이전 토큰 트랜잭션의 개개의 토큰 출력을 지출하는 제1 토큰 입력을 포함할 수 있고, 제1 토큰 입력은, 제1 토큰 트랜잭션의 자체 제1 토큰 입력을 제외한 전부, 개개의 잠금 스크립트 및 지출되는 이전 토큰 트랜잭션 출력의 개개의 값; 및 적어도 하나 이상의 데이터 쌍들을 포함하고, 각각의 데이터 쌍은 적어도, 제1 토큰 트랜잭션의 개개의 잠금 스크립트에 포함된 지불 주소 및 개개의 잠금 스크립트에 의해 잠긴 기본 디지털 자산의 대응하는 금액을 포함한다.
실시예들에서, 제1 토큰 트랜잭션은 제2 토큰 출력을 포함할 수 있고, 제2 토큰 출력은 제2 토큰 잠금 스크립트 및 제2 토큰 금액을 포함하고, 제2 토큰 잠금 스크립트는 개개의 가변 구성요소 및 개개의 불변 구성요소를 포함하고, 개개의 가변 구성요소는 제2 지불 주소를 포함하고, 개개의 불변 구성요소는 제1 토큰 잠금 스크립트의 불변 구성요소와 매칭된다.
실시예들에서, 제1 토큰 트랜잭션은 제3 출력을 포함할 수 있고, 제3 출력은 제3 지불 주소를 포함한다.
실시예들에서, 제1 토큰 입력은 제1 당사자에 의해 생성된 제1 서명을 포함하고, 제1 토큰 트랜잭션은 제2 입력을 포함할 수 있고, 제2 입력은 제2 당사자에 의해 생성된 제2 서명을 포함하고, 제1 토큰 트랜잭션은 지불 템플릿에 포함된 지불 주소를 포함하는 지불 출력을 포함하고, 지불 주소는 제1 당사자에 링크된다.
지불 출력은 제1 당사자와 링크되어 판매된 토큰들에 대해 제2 당사자로부터 지불을 받는다.
본원에서 개시된 다른 양상에 따르면, 컴퓨터 장비가 제공되며, 이 컴퓨터 장비는, 하나 이상의 메모리 유닛들을 포함하는 메모리; 및 하나 이상의 프로세싱 유닛들을 포함하는 프로세싱 장치를 포함하고, 메모리는 프로세싱 장치 상에서 실행되도록 구성된 코드를 저장하고, 코드는 프로세싱 장치 상에 있을 때, 위에서 설명된 실시예들 중 임의의 것을 수행하도록 구성된다.
본원에서 개시된 다른 양상에 따르면, 컴퓨터-판독 가능 저장소 상에서 구체화되고 컴퓨터 장비 상에서 실행될 때 위에서 설명된 실시예들 중 임의의 것을 수행하도록 구성된 컴퓨터 프로그램이 제공된다.
본원에서 개시된 다른 양상에 따르면, 제1 토큰 출력을 포함하는 제1 토큰 트랜잭션이 제공되며, 제1 토큰 출력은 제1 토큰 출력을 포함하고, 제1 토큰 출력은 제1 토큰 잠금 스크립트 및 제1 토큰 금액을 포함하고, 여기서 제1 토큰 잠금 스크립트는 가변 구성요소 및 불변 구성요소를 포함하고, 가변 구성요소는 지불 템플릿에 매립된 제1 지불 주소를 포함하고, 불변 구성요소는 토큰 역학 하위 구성요소를 포함하고, 지출 트랜잭션의 입력 스크립트 ― 입력 스크립트는 지출 트랜잭션의 자체 입력 스크립트를 제외한 전부뿐만 아니라 개개의 잠금 스크립트 및 지출되는 이전 트랜잭션 출력에서 잠긴 금액을 포함함 ― 와 함께 실행될 때, 토큰 역학 하위 구성요소는, 지출 트랜잭션의 입력 스크립트로부터 하나 이상의 데이터 쌍들을 획득하고 ― 각각의 데이터 쌍은, i) 지출 트랜잭션 출력들의 개개의 잠금 스크립트에 포함된 적어도 개개의 지불 주소 및 ii) 해당 출력의 개개의 잠금 스크립트들에 의해 잠긴 기본 디지털 자산의 대응하는 금액을 포함함 ― ; 지출 트랜잭션의 하나 이상의 출력들이, a) 미리 결정된 지불 주소를 포함하는 개개의 지불 스크립트 템플릿, 또는 b) 미리 결정된 지불 주소 이외의 개개의 지불 주소를 포함하는 개개의 가변 구성요소 및 가변 구성요소를 뒤따르는 불변 구성요소를 포함하는 개개의 잠금 스크립트를 포함한다는 것을 검증하고; 그리고 지불 트랜잭션의 해당 하나 이상의 출력들에 대해, 하나 이상의 출력들의 개개의 잠금 스크립트들에 의해 잠긴 기본 디지털 자산의 총 금액이 제1 토큰 금액과 동일하다는 것을 검증하도록 구성되고, 그리고 토큰 역학 하위 구성요소는 검증 단계들 중 임의의 것이 실패하는 경우 실행 동안 실패하도록 구성된다.
본원에서 개시된 다른 양상에 따르면, 토큰 트랜잭션이 저장되어 있는 컴퓨터 판독 가능 저장 매체가 제공된다.
개시된 기술들의 다른 변형들 또는 사용 사례들은 본원에서의 개시가 주어지면 당업자에게 명백해질 수 있다. 본 개시내용의 범위는 설명된 실시예에 의해 제한되는 것이 아니라 첨부된 청구들에 의해서만 제한된다.

Claims (23)

  1. 블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법으로서,
    각각의 토큰은 상기 블록체인의 기본 디지털 자산 네이티브 유닛들 중 단일 유닛에 의해 표현되며, 상기 방법은,
    제1 토큰 트랜잭션을 생성하는 단계; 및
    상기 제1 토큰 트랜잭션을 상기 블록체인 네트워크로 송신하는 단계를 포함하고,
    상기 제1 토큰 트랜잭션은 제1 토큰 출력을 포함하고, 상기 제1 토큰 출력은 제1 토큰 잠금 스크립트 및 제1 토큰 금액을 포함하고, 상기 제1 토큰 잠금 스크립트는 가변 구성요소 및 불변 구성요소를 포함하고, 상기 가변 구성요소는 지불 템플릿에 매립된 제1 지불 주소를 포함하고, 상기 불변 구성요소는 토큰 역학 하위 구성요소(token mechanics sub-component)를 포함하고, 지출 트랜잭션의 입력 스크립트 ― 상기 입력 스크립트는 상기 지출 트랜잭션의 자체 입력 스크립트를 제외한 전부뿐만 아니라 개개의 잠금 스크립트 및 지출되는 이전 트랜잭션 출력에서 잠긴 금액을 포함함 ― 와 함께 실행될 때, 상기 토큰 역학 하위 구성요소는,
    상기 지출 트랜잭션의 입력 스크립트로부터 하나 이상의 데이터 쌍들을 획득하고 ― 각각의 데이터 쌍은, i) 상기 지출 트랜잭션 출력들의 개개의 잠금 스크립트에 포함된 적어도 개개의 지불 주소 및 ii) 해당 출력의 개개의 잠금 스크립트들에 의해 잠긴 상기 기본 디지털 자산의 대응하는 금액을 포함함 ― ;
    상기 지출 트랜잭션의 하나 이상의 출력들이, a) 미리 결정된 지불 주소를 포함하는 개개의 지불 스크립트 템플릿, 또는 b) 상기 미리 결정된 지불 주소 이외의 개개의 지불 주소를 포함하는 개개의 가변 구성요소 및 상기 가변 구성요소를 뒤따르는 상기 불변 구성요소를 포함하는 개개의 잠금 스크립트를 포함한다는 것을 검증하고; 그리고
    상기 지불 트랜잭션의 해당 하나 이상의 출력들에 대해, 상기 하나 이상의 출력들의 개개의 잠금 스크립트들에 의해 잠긴 상기 기본 디지털 자산의 총 금액이 상기 제1 토큰 금액과 동일하다는 것을 검증하도록 구성되고, 그리고
    상기 토큰 역학 하위 구성요소는 검증 단계들 중 임의의 것이 실패하는 경우 실행 동안 실패하도록 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  2. 제1 항에 있어서,
    상기 지출 트랜잭션은 제1 잠금 스크립트를 포함하는 제1 출력 및 제2 잠금 스크립트를 포함하는 제2 출력을 포함하고, 상기 토큰 역학 하위 구성요소는,
    상기 지출 트랜잭션의 제1 출력이, a) 미리 결정된 지불 주소를 포함하는 개개의 지불 스크립트 템플릿, 또는 b) 상기 미리 결정된 지불 주소 이외의 개개의 지불 주소를 포함하는 개개의 가변 구성요소 및 상기 가변 구성요소를 뒤따르는 상기 불변 구성요소를 포함하는 제1 잠금 스크립트를 포함한다는 것을 검증하고;
    만약 존재하는 경우, 상기 지출 트랜잭션의 제2 출력이, a) 미리 결정된 지불 주소를 포함하는 개개의 표준 지불 스크립트 템플릿, 또는 b) 상기 미리 결정된 지불 주소 이외의 임의의 주소를 포함하는 개개의 가변 구성요소 및 상기 가변 구성요소를 뒤따르는 상기 불변 구성요소를 포함하는 제2 잠금 스크립트를 포함한다는 것을 검증하고; 그리고
    상기 제2 출력이 존재하는 경우, 상기 지출 트랜잭션의 제1 잠금 스크립트 및 제2 잠금 스크립트들에 의해 잠긴 상기 기본 디지털 자산의 총 금액이 상기 제1 토큰 금액과 동일하다는 것을 검증하도록 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  3. 제1 항 또는 제2 항에 있어서,
    상기 토큰 역학 구성요소는,
    상기 지출 트랜잭션의 제1 잠금 스크립트가 미리 결정된 지불 주소를 포함하는 표준 지불 스크립트 템플릿을 포함하지 않는 경우, 상기 제1 잠금 스크립트가 상기 미리 결정된 지불 주소 이외의 지불 주소를 포함하는 개개의 가변 구성요소, 및 상기 가변 구성요소를 뒤따르는 상기 불변 구성요소 ― 상기 불변 구성요소는 지출되는 이전 트랜잭션의 상기 제1 토큰 잠금 스크립트의 대응하는 불변 구성요소와 동일함 ― 를 포함한다는 것을 검증하고; 그리고/또는
    상기 지출 트랜잭션의 제2 잠금 스크립트가 존재하는 경우, 상기 제2 잠금 스크립트가 임의의 지불 주소를 포함하는 개개의 가변 구성요소, 및 상기 가변 구성요소에 뒤따르는 상기 불변 구성요소 ― 상기 불변 구성요소는 지출되는 이전 트랜잭션의 상기 제1 토큰 잠금 스크립트의 대응하는 불변 구성요소와 동일함 ― 를 포함한다는 것을 검증하도록 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  4. 제1 항 내지 제3 항 중 어느 한 항에 있어서,
    상기 불변 구성요소는 상기 미리 결정된 지불 주소를 포함하는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  5. 제1 항 내지 제4 항 중 어느 한 항에 있어서,
    상기 지출 트랜잭션의 입력 스크립트는 시그해시 프리이미지(sighash preimage)를 포함하고, 상기 프리이미지는 상기 제1 토큰 잠금 스크립트 및 상기 제1 토큰 금액을 포함하고, 상기 토큰 역학 하위 구성요소는,
    상기 검증 단계들을 수행하기 위해 상기 프리이미지로부터 지출되는 출력의 제1 토큰 금액 및 상기 제1 토큰 잠금 스크립트 둘 모두를 추출하도록 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  6. 제5 항에 있어서,
    상기 프리이미지는 하나 이상의 데이터 쌍들의 컨케터네이션(concatenation)의 해시를 포함하고, 각각의 데이터 쌍은 상기 지출 트랜잭션의 개개의 잠금 스크립트로부터의 개개의 지불 주소 및 상기 개개의 잠금 스크립트에 의해 잠긴 대응하는 금액을 포함하고, 상기 토큰 역학 하위 구성요소는,
    상기 프리이미지로부터 상기 하나 이상의 데이터 쌍들의 컨케터네이션의 해시를 추출하고;
    상기 하나 이상의 데이터 쌍들에 기초하여 해시를 생성하고; 그리고
    상기 생성된 해시가 상기 추출된 해시와 동일하다는 것을 검증하도록 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  7. 제6 항에 있어서,
    상기 해시를 생성하는 데 사용되는 하나 이상의 데이터 쌍들은 상기 입력 스크립트로부터 획득되거나, 상기 프리이미지로부터 상기 이전 출력 잠금 스크립트의 입력 주소 및 금액 쌍을 획득함으로써 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  8. 제5 항 내지 제7 항 중 어느 한 항에 있어서,
    상기 토큰 역학 하위 구성요소는,
    상기 지출 트랜잭션 데이터의 프리이미지를 생성하고; 그리고
    상기 지출 트랜잭션 데이터의 생성된 프리이미지가 상기 지출 트랜잭션의 입력 내에 포함된 프리이미지와 동일하다는 것을 검증하도록 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  9. 제8 항에 있어서,
    상기 지출 트랜잭션의 입력은 더미 개인 키(dummy private key) 및 대응하는 더미 공개 키를 포함하고, 상기 토큰 역학 하위 구성요소는,
    상기 더미 개인 키 및 상기 지출 트랜잭션의 입력 내에 포함된 상기 프리이미지의 해시를 사용하여 디지털 서명을 생성하고; 그리고
    상기 더미 공개 키 및 상기 지출 트랜잭션의 생성된 프리이미지의 해시에 대해 유효성 검증될 때, 상기 디지털 서명이 유효한 서명이라고 검증함으로써,
    상기 지출 트랜잭션의 생성된 프리이미지가 상기 지출 트랜잭션의 입력 내에 포함된 프리이미지와 동일하다는 것을 검증하도록 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  10. 제1 항 내지 제9 항 중 어느 한 항에 있어서,
    상기 토큰 역학 하위 구성요소는,
    상기 지출 트랜잭션의 개개의 잠금 스크립트에 포함된 개개의 지불 주소가 상기 제1 토큰 출력의 가변 구성요소에 포함된 제1 지불 주소와 동일한 유형이라는 것을 검증하도록 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  11. 제1 항 내지 제10 항 중 어느 한 항에 있어서,
    상기 제1 지불 주소의 유형은 공개 키 해시 주소인,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  12. 제1 항 내지 제11 항 중 어느 한 항에 있어서,
    상기 제1 토큰 금액은 상기 기본 디지털 자산의 단일 단위를 포함하는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  13. 제1 항 내지 제11 항 중 어느 한 항에 있어서,
    상기 제1 토큰 금액은 상기 기본 디지털 자산의 다수의 단위들을 포함하는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  14. 제1 항 내지 제13 항 중 어느 한 항에 있어서,
    상기 불변 구성요소는 데이터 하위 구성요소를 포함하고, 상기 데이터 하위 구성요소는,
    토큰 프로토콜 식별자; 및
    토큰 발행 트랜잭션의 식별자 중 하나 또는 둘 모두를 포함하고,
    상기 토큰 발행 트랜잭션은 i) 토큰 발행자와 초기 토큰 수신자 사이의 발행 계약, 및 ii) 초기 토큰 금액 중 하나 또는 모두를 포함하는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  15. 제2 항 또는 이에 종속하는 임의의 항에 있어서,
    상기 지출 트랜잭션은 제3 잠금 스크립트 및 대응하는 제3 금액을 포함하는 제3 출력을 포함하고, 상기 토큰 역학 하위 구성요소는,
    상기 제3 잠금 스크립트가 미리 결정된 지불 유형 템플릿의 개개의 지불 주소 및 그 개개의 대응하는 금액을 포함한다는 것을 검증하도록 구성되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  16. 제1 항 내지 제15 항 중 어느 한 항에 있어서,
    상기 제1 토큰 트랜잭션은 이전 토큰 트랜잭션의 개개의 토큰 출력을 지출하는 제1 토큰 입력을 포함하고, 상기 제1 토큰 입력은,
    상기 제1 토큰 트랜잭션의 자체 제1 토큰 입력을 제외한 전부, 개개의 잠금 스크립트 및 지출되는 상기 이전 토큰 트랜잭션 출력의 개개의 금액; 및
    적어도 하나 이상의 데이터 쌍들을 포함하고, 각각의 데이터 쌍은 적어도, 상기 제1 토큰 트랜잭션의 개개의 잠금 스크립트에 포함된 지불 주소 및 상기 개개의 잠금 스크립트에 의해 잠긴 상기 기본 디지털 자산의 대응하는 금액을 포함하는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  17. 제16 항에 있어서,
    상기 제1 토큰 트랜잭션은 제2 토큰 출력을 포함하고, 상기 제2 토큰 출력은 제2 토큰 잠금 스크립트 및 제2 토큰 금액을 포함하고, 상기 제2 토큰 잠금 스크립트는 개개의 가변 구성요소 및 개개의 불변 구성요소를 포함하고, 상기 개개의 가변 구성요소는 제2 지불 주소를 포함하고, 상기 개개의 불변 구성요소는 상기 제1 토큰 잠금 스크립트의 불변 구성요소와 매칭되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  18. 제17 항에 있어서,
    상기 제1 토큰 트랜잭션은 제3 출력을 포함하고, 상기 제3 출력은 제3 지불 주소를 포함하는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  19. 제16 항 내지 제18 항 중 어느 한 항에 있어서,
    상기 제1 토큰 입력은 제1 당사자에 의해 생성된 제1 서명을 포함하고, 상기 제1 토큰 트랜잭션은 제2 입력을 포함하고, 상기 제2 입력은 제2 당사자에 의해 생성된 제2 서명을 포함하고, 상기 제1 토큰 트랜잭션은 지불 템플릿에 포함된 지불 주소를 포함하는 지불 출력을 포함하고, 상기 지불 주소는 상기 제1 당사자에 링크되는,
    블록체인 트랜잭션들을 사용하여 디지털 토큰들을 전송하는 컴퓨터 구현 방법.
  20. 컴퓨터 장비로서,
    하나 이상의 메모리 유닛들을 포함하는 메모리; 및
    하나 이상의 프로세싱 유닛들을 포함하는 프로세싱 장치를 포함하고, 상기 메모리는 상기 프로세싱 장치 상에서 실행되도록 구성된 코드를 저장하고, 상기 코드는 상기 프로세싱 장치 상에 있을 때, 제1 항 내지 제19 항 중 어느 한 항의 방법을 수행하도록 구성되는,
    컴퓨터 장비.
  21. 컴퓨터-판독 가능 저장소 상에서 구체화되고, 컴퓨터 장비 상에서 실행될 때 제1 항 내지 제19 항 중 어느 한 항의 방법을 수행하도록 구성된 컴퓨터 프로그램.
  22. 제1 토큰 출력을 포함하는 토큰 트랜잭션으로서,
    상기 제1 토큰 출력은 제1 토큰 잠금 스크립트 및 제1 토큰 금액을 포함하고, 상기 제1 토큰 잠금 스크립트는 가변 구성요소 및 불변 구성요소를 포함하고, 상기 가변 구성요소는 지불 템플릿에 매립된 제1 지불 주소를 포함하고, 상기 불변 구성요소는 토큰 역학 하위 구성요소를 포함하고, 지출 트랜잭션의 입력 스크립트 ― 상기 입력 스크립트는 상기 지출 트랜잭션의 자체 입력 스크립트를 제외한 전부뿐만 아니라 개개의 잠금 스크립트 및 지출되는 이전 트랜잭션 출력에서 잠긴 금액을 포함함 ― 와 함께 실행될 때, 상기 토큰 역학 하위 구성요소는,
    상기 지출 트랜잭션의 입력 스크립트로부터 하나 이상의 데이터 쌍들을 획득하고 ― 각각의 데이터 쌍은, i) 상기 지출 트랜잭션 출력들의 개개의 잠금 스크립트에 포함된 적어도 개개의 지불 주소 및 ii) 해당 출력의 개개의 잠금 스크립트에 의해 잠긴 상기 기본 디지털 자산의 대응하는 금액을 포함함 ― ;
    상기 지출 트랜잭션의 하나 이상의 출력들이, a) 미리 결정된 지불 주소를 포함하는 개개의 지불 스크립트 템플릿, 또는 b) 상기 미리 결정된 지불 주소 이외의 개개의 지불 주소를 포함하는 개개의 가변 구성요소 및 상기 가변 구성요소를 뒤따르는 상기 불변 구성요소를 포함하는 개개의 잠금 스크립트를 포함한다는 것을 검증하고; 그리고
    상기 지불 트랜잭션의 해당 하나 이상의 출력들에 대해, 상기 하나 이상의 출력들의 개개의 잠금 스크립트들에 의해 잠긴 상기 기본 디지털 자산의 총 금액이 상기 제1 토큰 금액과 동일하다는 것을 검증하도록 구성되고, 그리고
    상기 토큰 역학 하위 구성요소는 검증 단계들 중 임의의 것이 실패하는 경우 실행 동안 실패하도록 구성되는,
    제1 토큰 출력을 포함하는 토큰 트랜잭션.
  23. 제22 항의 토큰 트랜잭션이 저장되어 있는 컴퓨터-판독 가능 저장 매체.
KR1020237006558A 2020-07-29 2021-03-09 블록체인 토큰들 KR20230044262A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2011753.7 2020-07-29
GB2011753.7A GB2597672A (en) 2020-07-29 2020-07-29 Blockchain tokens
PCT/EP2021/055905 WO2022022864A1 (en) 2020-07-29 2021-03-09 Blockchain tokens

Publications (1)

Publication Number Publication Date
KR20230044262A true KR20230044262A (ko) 2023-04-03

Family

ID=72339173

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237006558A KR20230044262A (ko) 2020-07-29 2021-03-09 블록체인 토큰들

Country Status (7)

Country Link
US (1) US20230291561A1 (ko)
EP (1) EP4189913A1 (ko)
JP (1) JP2023536163A (ko)
KR (1) KR20230044262A (ko)
CN (1) CN116210200A (ko)
GB (1) GB2597672A (ko)
WO (1) WO2022022864A1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11907939B2 (en) * 2020-08-06 2024-02-20 James Cramer Methods for user authentication using non-fungible digital assets
GB2622627A (en) * 2022-09-23 2024-03-27 Nchain Licensing Ag Atomic swap token trades
CN116976883A (zh) * 2023-07-31 2023-10-31 北京神州数码方圆科技有限公司 基于区块链的预付费卡资金监管方法和系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB201720767D0 (en) * 2017-12-13 2018-01-24 Barker Trevor Computer-implemented system and method

Also Published As

Publication number Publication date
GB2597672A (en) 2022-02-09
CN116210200A (zh) 2023-06-02
GB202011753D0 (en) 2020-09-09
JP2023536163A (ja) 2023-08-23
US20230291561A1 (en) 2023-09-14
WO2022022864A1 (en) 2022-02-03
EP4189913A1 (en) 2023-06-07

Similar Documents

Publication Publication Date Title
JP7241216B2 (ja) ブロックチェーンベースの暗号通貨のためのトークンを検証する、コンピュータにより実行される方法及びシステム
JP7381625B2 (ja) 分散ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用した契約の実行を制御する方法及びシステム
JP7450678B2 (ja) アンロッキングトランザクションバイトコードの制約注入
US20230291561A1 (en) Blockchain tokens
CN112437922A (zh) 分布式数据记录
CN113874839A (zh) 区块链交易内的脚本内函数
Dinh et al. A blueprint for interoperable blockchains
JP2023543728A (ja) コンメンサルトークンシステム
Lovejoy et al. Hamilton: A {High-Performance} Transaction Processor for Central Bank Digital Currencies
WO2021224428A1 (en) Blockchain
WO2021139391A1 (en) Methods and devices for mitigating invoice financing fraud
KR20220143879A (ko) 플랫폼 서비스 검증
US20240095692A1 (en) Computer implemented method and system
US20230093411A1 (en) Synchronising event streams