KR20240024767A - 커미트먼트의 사용자 체인에 랑데뷰 블록체인 트랜잭션을 첨부하기 위한 방법 및 시스템 - Google Patents
커미트먼트의 사용자 체인에 랑데뷰 블록체인 트랜잭션을 첨부하기 위한 방법 및 시스템 Download PDFInfo
- Publication number
- KR20240024767A KR20240024767A KR1020237020963A KR20237020963A KR20240024767A KR 20240024767 A KR20240024767 A KR 20240024767A KR 1020237020963 A KR1020237020963 A KR 1020237020963A KR 20237020963 A KR20237020963 A KR 20237020963A KR 20240024767 A KR20240024767 A KR 20240024767A
- Authority
- KR
- South Korea
- Prior art keywords
- transaction
- metadata
- blockchain
- data
- alice
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 82
- 238000012546 transfer Methods 0.000 claims description 90
- 150000003839 salts Chemical class 0.000 claims description 27
- 238000006243 chemical reaction Methods 0.000 claims description 2
- 230000009977 dual effect Effects 0.000 claims 2
- 238000012545 processing Methods 0.000 description 163
- 239000000428 dust Substances 0.000 description 107
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 86
- 239000010931 gold Substances 0.000 description 86
- 229910052737 gold Inorganic materials 0.000 description 86
- 238000013515 script Methods 0.000 description 41
- 230000006870 function Effects 0.000 description 33
- 238000007726 management method Methods 0.000 description 20
- 235000006679 Mentha X verticillata Nutrition 0.000 description 16
- 235000002899 Mentha suaveolens Nutrition 0.000 description 16
- 235000001636 Mentha x rotundifolia Nutrition 0.000 description 16
- 230000008569 process Effects 0.000 description 12
- 230000008901 benefit Effects 0.000 description 11
- 239000000969 carrier Substances 0.000 description 9
- 238000010200 validation analysis Methods 0.000 description 9
- 238000005308 sum rule Methods 0.000 description 8
- 230000003287 optical effect Effects 0.000 description 6
- 239000003795 chemical substances by application Substances 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000000644 propagated effect Effects 0.000 description 5
- 238000013475 authorization Methods 0.000 description 4
- 238000013500 data storage Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000005065 mining Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000001902 propagating effect Effects 0.000 description 3
- 238000009938 salting Methods 0.000 description 3
- 230000000295 complement effect Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 239000010970 precious metal Substances 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 101100074836 Caenorhabditis elegans lin-22 gene Proteins 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000007596 consolidation process Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- COCAUCFPFHUGAA-MGNBDDOMSA-N n-[3-[(1s,7s)-5-amino-4-thia-6-azabicyclo[5.1.0]oct-5-en-7-yl]-4-fluorophenyl]-5-chloropyridine-2-carboxamide Chemical group C=1C=C(F)C([C@@]23N=C(SCC[C@@H]2C3)N)=CC=1NC(=O)C1=CC=C(Cl)C=N1 COCAUCFPFHUGAA-MGNBDDOMSA-N 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Classifications
-
- 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
- G06Q20/0658—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed locally
-
- 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/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
-
- 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
-
- 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/381—Currency conversion
-
- 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
- G06Q2220/00—Business processing using cryptography
- G06Q2220/10—Usage protection of distributed data files
-
- 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
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Finance (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Storage Device Security (AREA)
Abstract
블록체인 트랜잭션을 사용하여 자산에 대한 지불이 레코딩되고 트랜잭션과 연관된 변경 불가능한 로그에 기초하여 검증되는 방법이 제공된다.
Description
본 개시는 일반적으로 하나 이상의 클라이언트들에 대한 분산 원장, 즉 블록체인과 연관된 하나 이상의 서비스들의 플랫폼을 구현하기 위한 방법들 및 시스템들에 관한 것이다. 특히, 본 개시는 디지털 및 토큰화된 자산들의 이전(transfer)을 가능하게 하는 것과 같이, 하나 이상의 클라이언트들에 대한 블록체인과 연관된 복수의 기능들 및 애플리케이션들에 대한 액세스의 제공에 관한 것이다(그러나 이에 제한되지 않음).
이 문서에서 우리는 모든 형태의 전자, 컴퓨터 기반, 분산 원장을 포함하기 위하여 '블록체인'이라는 용어를 사용한다. 이는 합의 기반(consensus-based) 블록체인 및 트랜잭션 체인 기술들, 허가 및 비허가 원장들, 공유 원장들, 공용 및 개인 블록체인들 및 이들의 변동들을 포함한다. 다른 블록체인 구현들이 제안되고 개발되었지만, 블록체인 기술의 가장 널리 알려진 애플리케이션은 비트코인 원장이다. 비트코인은 편의 및 예시의 목적으로 본원에서 지칭될 수 있지만, 본 개시내용은 비트코인 블록체인과 함께 사용하는 것으로 제한되지 않으며, 임의의 종류의 디지털 자산 또는 디지털 자산의 표현과 연관된 대안적인 블록체인 구현들 및 프로토콜들이 본 개시내용의 범위 내에 속한다는 것이 주의되어야 한다. "클라이언트", "엔티티", "노드", "사용자", "전송자", "수령인", "지급인", "수취인"이라는 용어들은 본원에서 컴퓨팅 또는 프로세서-기반 자원을 지칭할 수 있다. 본원에서 "비트코인"이란 용어는 비트코인 프로토콜로부터 도출되거나 이에 기초하는 임의의 버전 또는 변동을 포함하는 데 사용된다. "디지털 자산"이라는 용어는 암호화폐, 재산의 적어도 일부를 표현하는 토큰들, 스마트 계약, 라이센스, 즉 소프트웨어 라이센스, 또는 미디어 콘텐츠에 대한 DRM 계약들 등과 같은 임의의 이전 가능한 자산을 지칭할 수 있다. "디지털 자산"이라는 용어는 이 문서 전반에 걸쳐 가치와 연관될 수 있는 상품을 표현하는 데 사용되며, 이는 하나의 엔티티에서 다른 엔티티로의 트랜잭션에서 지불로서 이전되거나 제공될 수 있다는 것이 이해될 것이다.
블록체인은 결국, 트랜잭션들로 구성되는 블록들로 구성된 컴퓨터-기반 탈중앙화된 분산 시스템으로서 구현되는 피어-투-피어 전자 원장이다. 각각의 트랜잭션은 블록체인 시스템의 참여자들 사이의 디지털 자산의 제어의 이전을 인코딩하는 데이터 구조이며, 적어도 하나의 입력 및 적어도 하나의 출력을 포함한다. 각각의 블록은 이전의 블록(previous block)의 해시를 포함하여서, 블록들은 그의 시작 이래로 블록체인에 기록되는 모든 트랜잭션들에 대한 영구적이고 변경 불가능한 레코드를 생성하도록 함께 체이닝된다(chained). 트랜잭션들은 그 입력들 및 출력들에 매립되는 스크립트들로서 알려진 소형 프로그램들을 포함하며, 이들은 트랜잭션의 출력이 어떻게 그리고 누구에 의해 액세스될 수 있는지를 지정한다. 비트코인 플랫폼에서, 이러한 스크립트는 스택-기반 스크립트 언어(stack-based scripting language)를 이용하여 기록된다.
트랜잭션이 블록체인에 기록되기 위해서는 "유효성 검증(validated)"되어야 한다. 네트워크 노드들(채굴자들)은 각각의 트랜잭션이 유효하다는 것을 보장하기 위한 작업을 수행하며, 유효하지 않은 트랜잭션들은 네트워크로부터 거부된다. 노드들 상에 설치된 소프트웨어 클라이언트들은 그의 잠금 및 잠금 해제 스크립트들을 실행함으로써 미지출 트랜잭션(UTXO)에 대하여 이 유효성 검증 작업을 수행한다. 잠금 및 잠금 해제 스크립트들의 실행이 참(TRUE)으로 평가되는 경우, 트랜잭션은 유효하고 트랜잭션은 그 후 블록체인에 기록된다. 따라서, 트랜잭션이 블록체인에 기록되기 위해서는 i) 트랜잭션을 수신하는 제1 노드에 의해 유효성 검증되어야 하며 ― 트랜잭션이 유효성 검증되는 경우, 노드는 트랜잭션을 네트워크의 다른 노드들에 중계함 ― , ii) 채굴자에 의해 구축된 새로운 블록에 추가되어야 하며, iii) 채굴, 즉 과거 트랜잭션들의 공용 원장에 추가되어야 한다.
채굴자들에 의해 수행되는 작업들의 성질은 블록체인을 유지하는 데 사용되는 합의 메커니즘의 유형에 의존한다는 것이 인지될 것이다. 작업 증명(proof of work; PoW)이 오리지널 비트코인 프로토콜과 연관되지만, PoS(proof of stake), DPoS(delegated proof of stake), PoC(proof of capacity), PoET(proof of elapsed time), PoA(proof of authority) 등과 같은 다른 합의 메커니즘들이 사용될 수 있다는 것이 인지될 것이다. 상이한 합의 메커니즘들은 채굴이 노드들 간에 분산되는 방식에 따라 변동되며, 블록을 성공적으로 채굴할 승산(odd)들은 예컨대, 채굴자의 해싱 파워(PoW), 채굴자에 의해 보유되는 암호화폐의 양(PoS), 위임 채굴자(Delegate Miner)에 대해 스테이킹된(staked) 암호화폐의 양(DPoS), 암호화 퍼즐에 대한 사전 결정된 솔루션을 저장하는 채굴자의 능력(PoC), 채굴자에게 랜덤으로 할당된 대기 시간(PoET) 등에 의존한다. 통상적으로, 채굴자들에는 블록의 채굴에 대한 인센티브 또는 보상이 제공된다. 예컨대, 비트코인 블록체인은 새롭게 발행된 암호화폐(비트코인(Bitcoin)) 및 블록 내 트랜잭션들과 관련된 수수료(트랜잭션 수수료)로 채굴자들을 보상한다. 비트코인 블록체인의 경우, 발행된 암호화폐의 양은 시간이 지남에 따라 줄어들고 인센티브는 결국 트랜잭션 수수료들만으로 구성된다. 따라서 트랜잭션 수수료들의 처리는 비트코인 블록체인과 같은 공용 블록체인(public blockchain)에 데이터를 커밋하는(committing) 기본 메커니즘의 일부라는 것이 인지될 것이다.
이전에 언급된 바와 같이, 주어진 블록의 각각의 트랜잭션은 블록체인 시스템의 참여자들 간의 디지털 자산의 제어의 이전을 인코딩한다. 디지털 자산이 반드시 암호화폐에 대응할 필요는 없다. 예컨대, 디지털 자산은 문서, 이미지, 물리적 오브젝트 등의 디지털 표현과 관련될 수 있다. 채굴자들에 대한 암호화폐 및/또는 트랜잭션 수수료들의 지불은 단순히, 필요한 작업을 수행함으로써 블록체인의 유효성을 유지하기 위한 인센티브로서 작용할 수 있다. 블록체인과 연관된 암호화폐는 채굴자들에 대한 보안으로서 작용할지도 모르고, 블록체인 자체는 주로 암호화폐 이외의 디지털 자산과 관련된 트랜잭션들에 대한 원장이다. 일부 경우들에서, 참여자들 간의 암호화폐 이전이 트랜잭션들의 원장을 유지하기 위해 블록체인을 사용하는 엔티티와 상이하고 그리고/또는 그에 독립적인 엔티티에 의해 처리될지도 모른다.
일단 UTXO로서 블록체인에 저장되면, 사용자는 연관된 자원의 제어를 다른 트랜잭션의 입력과 연관된 다른 어드레스로 이전할 수 있다. 이러한 이전은 일반적으로, 디지털 지갑을 사용하여 행해지지만, 반드시 그럴 필요는 없다. 이 디지털 지갑은 디바이스; 물리적 매체; 프로그램; 데스크톱, 랩톱 또는 이동 단말과 같은 컴퓨팅 디바이스 상의 애플리케이션(앱); 또는 인터넷과 같은 네트워크 상의 도메인과 연관된 원격-호스팅 서비스일 수 있다. 디지털 지갑은 공개 및 개인 키들을 저장하고, 사용자와 연관된 자원들; 토큰들 및 자산들 등의 소유권을 추적하고; 디지털 자산들을 수신하거나 지출하고; 암호화폐들, 라이센스들, 재산 또는 다른 유형들의 자원과 같은 디지털 자산들과 관련될 수 있는 토큰들을 이전하는 데 사용될 수 있다.
암호화폐 구현의 사용을 위한 블록체인 기술이 가장 널리 알려져 있지만, 디지털 기업가들은 새로운 시스템을 구현하기 위해 블록체인 상에 저장될 수 있는 데이터 및 비트코인이 기초하고 있는 암호화 보안 시스템 둘 모두를 사용하는 방법을 모색하고 있다. 암호화폐 영역으로 제한되지 않는 자동화된 작업들 및 프로세스들을 위해 블록체인이 사용될 수 있는 경우가 매우 유리할 것이다. 이러한 솔루션은 블록체인의 이점들(예컨대, 이벤트들의 영구적인 위조-방지성 레코드들, 분산 프로세싱 등)을 활용하는 동시에 그의 애플리케이션들에서 더 다재다능해질 수 있을 것이다.
현재 연구의 한 영역은 "스마트 계약들"의 구현을 위한 블록체인의 사용이다. 이들은 기계-판독 가능 계약 또는 동의의 조건들의 실행을 자동화하도록 설계된 컴퓨터 프로그램들이다. 자연어로 기록되는 기존의 계약과 달리, 스마트 계약은 결과들을 생성하기 위해 입력들을 프로세싱할 수 있는 규칙들을 포함하는 기계 실행 가능 프로그램이며, 이는 그 후 그러한 결과들에 의존하여 액션들이 수행되게 할 수 있다.
구체적으로, 하나의 연구 분야는 자산의 이전 및 블록체인의 불변성으로부터 이전의 이점을 보장하기 위해 자산의 이전이 블록체인에 어떻게 레코딩될 수 있는지에 대한 것이다. 또한, 기본 블록체인 인프라구조의 지원으로 자산의 이전이 안전하게 레코딩 및 로깅되는 것을 보장하기 위해 이러한 이전을 로깅하는 수단 외에도, 자산의 이전을 위한 효율적이고 안전한 프로토콜을 제공하는 것이 특히 관심사이다.
본 명세서 전반에 걸쳐, 단어 "포함하다(comprise)", 또는 "포함하다(includes)", "포함하다(comprises)" 또는 "포함하는(comprising)"과 같은 변동들은 언급된 요소, 정수, 단계, 또는 요소들, 정수들, 단계들의 그룹을 포함하지만, 임의의 다른 요소, 정수, 단계, 또는 요소들, 정수들, 또는 단계들의 그룹의 배제를 의미하지 않는 것으로 이해될 것이다.
본 개시는, 예컨대, 상품과 교환하여 화폐를 지불하는 것일 수 있는 지불 이벤트의 레코드를 가능하게 할 수 있는 방법 및 시스템에 관한 것이다.
일부 실시예에서, 적어도 제1 사용자 및 제2 사용자를 수반하는 자산 이전 이벤트를 레코딩하는 컴퓨터 구현 방법이 제공된다. 자산은 블록체인 토큰을 사용하는 물리적 자산의 표현인 것으로 이해될 수 있다. 자산은 블록체인 토큰을 사용하여 표현되는 귀금속일 수 있다. 자산은 토큰화된 자산일 수 있다. 토큰화된 자산은 화폐의 금액일 수 있다. 자산은 제품 또는 서비스일 수 있다. 자산 이전 이벤트는 제품, 항목 또는 서비스에 대한 화폐 지불일 수 있다. 일부 실시예는 화폐 지불이 레코딩되는 것을 가능하게 할 수 있다. 화폐 지불은 임의의 화폐 또는 화폐 유형일 수 있으며, 상품 또는 서비스에 대한 것일 수 있고, 상이한 화폐 또는 화폐 유형에 대한 교환일 수 있다. 일부 실시예는 컴퓨팅 자원에 의해 구현될 수 있다. 컴퓨팅 자원은 구현된 하드웨어 또는 소프트웨어일 수 있다. 컴퓨팅 자원은 로컬적으로 또는 넓은 지리적 영역에 걸쳐 분산될 수 있는 복수의 프로세싱 자원을 포함할 수 있다. 방법은 명령 데이터를 수신하는 단계를 포함할 수 있으며, 명령 데이터는 요청된 자산 이전 이벤트와 관련되며, 명령 데이터는 자산 이전의 발송자와 관련된 메타데이터의 제1 세트 및 자산 이전의 적어도 하나의 수령자와 관련된 메타데이터의 제2 세트를 포함한다. 메타데이터는, 예컨대, 지불 화폐, 계정, 이전을 받거나 이전하도록 지정된 개인, 지불에 대한 약관(terms and conditions) 및 공개 키 또는 지불을 승인하는 디지털 서명의 증거 중 적어도 하나를 식별할 수 있다. 발송자와 수령자 각각은 자산 레지스트리(asset registry)와 연관된 계정과 연관될 수 있다.
방법은 자산의 발송자와 커미트먼트의 제1 체인을 연관시키고, 자산의 수령자와 커미트먼트의 제2 체인을 연관시키는 단계를 더 포함할 수 있고, 커미트먼트의 각각의 체인은 이벤트 스트림과 복수의 블록체인 트랜잭션을 연관시킨다. 이벤트 스트림은 "오프 체인"이고, 즉, 블록체인 상이 아닐 수 있다. 복수의 블록체인 트랜잭션과 이벤트 스트림 간의 연관은, 커미트먼트가 커미트먼트의 체인에 추가될 때마다, 엔트리가 이벤트 스트림에 첨부됨을 의미할 수 있다. 이벤트 스트림에 첨부된 엔트리는 커미트먼트로부터의 메타데이터 중 일부를 포함할 수 있다. 메타데이터는 커미트먼트의 데이터 페이로드 내에 포함될 수 있으며, 메타데이터 중 적어도 일부는 이벤트 스트림의 엔트리 내부에 저장될 수 있다.
이벤트 스트림은, 블록체인 트랜잭션에 레코딩된 데이터가 시간 상으로 정렬된 로그에 추가될 수 있는 블록체인 지원 첨부 전용 로그를 포함할 수 있다. 다시 말해서, 이벤트 스트림은 블록체인에 레코딩된 데이터를 시간 순서대로, 즉, 그들이 블록체인에 나타나는 대로 로깅할 수 있다. 이것은, 블록체인 상의 블록 내 트랜잭션의 순서가 일반적으로 이벤트 스트림 상에 로깅된 대응하는 이벤트의 대응하는 인덱스에 의해 반영될 것이라는 것을 의미한다. 그러나, 이것이 반드시 그럴 필요는 없다. 2개의 동시 이벤트는, 이벤트의 순서가 블록 내 트랜잭션의 순서에 반영되지 않음을 의미한다. 예컨대 N+1과 같은 인덱스를 갖는 이벤트 스트림 상의 이벤트는 블록 B에 레코딩될 수 있는 반면, 인덱스 N을 갖는 이벤트(즉, 다른 이벤트 전에 이벤트 스트림 상에 레코딩됨)는 블록 B+1에 레코딩될 수 있다. 임의의 적절한 데이터 구조를 사용하여 이벤트 스트림이 구현될 수 있다. 이벤트 스트림은 시퀀스에 저장된 일련의 엔트리를 포함할 수 있으며, 시퀀스 내의 각각의 엔트리는 단조적으로 증가하는 숫자에 의해 시퀀스에서 참조된다. 다시 말해서, 이벤트 스트림의 첫 번째 엔트리는 엔트리 1이고, 두 번째 엔트리는 엔트리 2이고, 이러한 식이다. 기본 블록체인의 활용은, 이벤트 스트림에 대한 임의의 변화가 검출 가능할 것이라는 것을 의미하여, 이벤트 스트림의 개별 엔트리가 작성된 이래로 수정되지 않았고, 이전 연속 엔트리 사이에 어떠한 엔트리도 삽입되지 않았고, 그리고 어떠한 엔트리도 제거되지 않았고 어떠한 엔트리도 재정렬되지 않았다는 것을 보장한다.
악의적인 당사자가 시스템에 의한 검출 없이 이벤트를 이벤트 스트림에 첨부하는 것이 가능할 수 있지만, 이벤트 스트림을 초기화한 사용자는 그들이 이벤트 스트림에 첨부하는 모든 각각의 이벤트에 서명할 수 있어서, 악의적인 당사자가 이벤트를 첨부하려고 시도하는 인스턴스가 검출 가능할 것이다.
개개의 발송자 또는 수령자와 커미트먼트의 제1 및 제2 체인 중 어느 하나 또는 둘 모두의 연관은 커미트먼트의 체인의 초기화 및 개개의 발송자 또는 수령자와 커미트먼트의 체인을 연관시키는 것을 포함할 수 있다. 방법은 다른 엔티티와 커미트먼트의 개개의 체인을 연관시키는 단계를 더 포함할 수 있다. 다른 엔티티는 자산 레지스트리와 연관된 레지스트리 관리자 또는 다른 엔티티의 서명자(signatory)일 수 있다.
자산 레지스트리는 개인 또는 조직이 소유한 자산의 레지스트리이다. 자산의 예는 개개의 개인 또는 조직이 소유하거나 제어하는 임의의 자원을 포함한다. 자산의 예는 현금 또는 다른 금전적 가치를 포함한다. 자산 레지스트리의 예는, 예컨대, 특정 화폐로 트랜잭션을 펀딩하는 데 사용될 수 있는 계정에 현금 예금을 등록하는 은행일 수 있다. 또 다른 예는 개인이 소유한 금 예금의 레지스트리인 금 계정일 수 있다. 자산 레지스트리는 자산 레지스트리에 의해 관리되는 계정과 연관된 자산의 발행자와 연관된다. 예시적인 발행자는 왕립 조폐국(Royal Mint)일 수 있다.
방법은, 이전 프로토콜에 따라, 발송자로부터 적어도 하나의 수령자로의 자산의 이전이 이루어질 수 있는지 여부를 결정하기 위해 메타데이터의 제1 세트와 메타데이터의 제2 세트를 비교하는 단계를 더 포함할 수 있고, 이전 프로토콜은 자산 이전 이벤트를 발생시키는 것을 가능하게 하기 위한 적어도 하나의 기준을 정의한다.
이전 프로토콜은 자산 이전 이벤트가 발생하도록 하기 위해 충족되어야 하는 적어도 하나의 기준을 정의할 수 있다. 적어도 하나의 기준은, 발송자와 수령자가 동일한 자산 레지스트리와 연관된 계정과 연관되어 있어야 한다고 요구할 수 있다. 예컨대, 적어도 하나의 기준은 계정이 동일한 은행에 있어야 한다고 요구할 수 있다. 적어도 하나의 기준은 계정이 동일한 유형의 자산과 연관되어야 한다고 요구할 수 있다. 예컨대, 그러한 기준은 양자의 계정이 영국 파운드(GBP)용이어야 한다고 요구할 수 있다.
이전 프로토콜에 따른 메타데이터의 개개의 세트 사이의 비교에 기초하여, 방법은 메타데이터의 개개의 세트 사이의 대응성의 하나 이상의 항목을 결정하는 단계를 더 포함할 수 있다.
커미트먼트는 다른 트랜잭션과 자신을 연관시키는 블록체인 트랜잭션이다. 이러한 트랜잭션은 반드시 블록체인 상의 동일한 블록으로부터 발생하지 않을 수 있다.
본원에서 설명된 바와 같이, 커미트먼트의 체인은, 각각의 트랜잭션이 이전의 트랜잭션에 대한 참조 및 다음 트랜잭션에 대한 참조를 포함(또는 이에 기초하는 데이터를 포함)하는 복수의 트랜잭션을 포함한다.
방법은, 발송자와 수령자 각각에 대해, 적어도 하나의 입력과 적어도 하나의 출력을 포함하는 랑데뷰 블록체인 트랜잭션을 생성하는 단계를 더 포함할 수 있으며, 적어도 하나의 출력은 메타데이터의 제1 및 제2 세트와 연관된 출력 데이터를 포함하고, 메타데이터와 연관된 데이터는 향후 트랜잭션과 관련된 데이터에 추가로 기초한다. 적어도 하나의 입력은 자산 이전 이벤트와 연관된 다른 엔티티에 대한 입력에 추가하여 발송자와 수령자 각각에 대한 하나의 입력을 포함할 수 있다. 각각의 입력은, 입력 및 ??력이 랑데뷰 블록체인 트랜잭션에서 입력 인덱스 및 출력 인덱스가 일치한다는 점에서 출력에 대응할 수 있다. 이것은 입력-출력 쌍을 형성한다.
랑데뷰 블록체인 트랜잭션은 커미트먼트의 개개의 제1 및 제2 체인에 추가될 수 있다. 다시 말해서, 랑데뷰 블록체인 트랜잭션은 커미트먼트의 체인에서 커미트먼트를 형성한다.
방법은, 개개의 랑데뷰 트랜잭션이 생성되어 커미트먼트의 체인에서 다음 커미트먼트를 형성할 때, 커미트먼트의 제1 및 제2 체인과 연관된 개개의 이벤트 스트림에 엔트리를 첨가하는 단계를 더 포함할 수 있으며, 엔트리는 메타데이터의 제1 및 제2 세트와 관련된 데이터를 포함한다.
방법은 랑데뷰 블록체인 트랜잭션과 개개의 오프체인 이벤트 스트림의 개개의 엔트리를 연관시키는 단계를 더 포함할 수 있다. 랑데뷰 블록체인 트랜잭션과 개개의 엔트리의 연관은 개개의 오프체인 이벤트 스트림의 개개의 엔트리에 랑데뷰 트랜잭션에 관련된 저장 수단 내의 트랜잭션에 대한 식별자를 저장하는 것을 포함할 수 있다.
방법은 랑데뷰 블록체인 트랜잭션을 커미트먼트의 개개의 제1 및 제2 체인에 첨부하는 단계를 더 포함할 수 있다.
메타데이터의 제1 및 제2 세트는 자산 이전 이벤트에 대한 지불 명령 데이터세트를 공동으로 형성할 수 있다.
위의 방법은, 블록체인과 이벤트 스트림을 연관시키고 향후 트랜잭션 데이터를 사용하여 개개의 트랜잭션이 다음 트랜잭션으로 커밋되는 트랜잭션의 체인을 형성하는 블록체인 트랜잭션을 생성하는 커미트먼트의 체인을 사용하여 자산 이전 이벤트가 레코딩되는 것을 가능하게 한다. 이것은 자산 이전 이벤트를 레코딩하기 위한 안전하고 복잡하지 않으며 사용자 친화적이고 효율적이며 강력한 접근 방식을 제공한다. 이것은 발송자 또는 수령자와 같은 사용자가 자산 이전 이벤트의 그들의 이력에 빠르고 쉽게 액세스하고 상호작용하도록 허용할 것이다.
본 개시의 양상 및 실시예는 단지 예로서 그리고 첨부된 도면을 참조하여 이제 설명될 것이다.
도 1a는 실시예에 따른 시스템을 도시한다.
도 1b는 블록체인 트랜잭션을 유효성 검증하기 위해 비트코인 소프트웨어를 구현하도록 구성된 노드를 도시한다.
도 1c는 블록체인 네트워크를 도시한다.
도 2는 실시예에 따른 계정의 설정을 상세히 설명하는 흐름도를 도시한다.
도 3a 및 3b는 실시예에 따라 발송자로부터 수령자로의 지불을 상세히 설명하는 흐름도를 도시한다.
도 3c는 실시예에 따른 랑데뷰 트랜잭션을 도시한다.
도 3d는 더스트 트랜잭션의 체인과 이벤트 스트림 사이의 관계를 도시한다.
도 3e는 트랜잭션에 대한 당사자에 대응하는 복수의 이벤트 스트림을 도시한다.
도 4a는 실시예에 따라 발송자로부터 수령자로의 지불을 상세히 설명하는 흐름도를 도시한다.
도 4b는 실시예에 따른 랑데뷰 트랜잭션을 도시한다.
도 4c는 트랜잭션에 대한 당사자에 대응하는 복수의 이벤트 스트림을 도시한다.
도 5a는 실시예에 따라 발송자로부터 수령자로의 지불을 상세히 설명하는 흐름도를 도시한다.
도 5b는 실시예에 따른 랑데뷰 트랜잭션을 도시한다.
도 5c는 트랜잭션에 대한 당사자에 대응하는 복수의 이벤트 스트림을 도시한다.
도 6a 및 6b는 실시예에 따라 발송자로부터 수령자로의 지불을 상세히 설명하는 흐름도를 도시한다.
도 7은 실시예에 따라 생성된 랑데뷰 블록체인 트랜잭션을 도시한다.
도 8은 실시예에 따른 트랜잭션에 대한 당사자에 대한 이벤트 스트림을 도시한다.
도 8a는 커미트먼트의 체인을 도시한다.
도 9는 커미트먼트의 체인을 사용하여 자산 이전 이벤트를 레코딩하는 방법의 단계를 도시한다.
도 10은 복수의 커미트먼트의 체인을 동기화하는 랑데뷰 트랜잭션을 도시한다.
도 11은 상태 다이제스트를 나타내는 머클 트리를 도시한다.
도 12는 데이터 다이제스트를 나타내는 머클 트리를 도시한다.
도 13은 커미트먼트의 복수의 체인을 동기화하는 대안적인 랑데뷰 트랜잭션을 도시한다.
도 1a는 실시예에 따른 시스템을 도시한다.
도 1b는 블록체인 트랜잭션을 유효성 검증하기 위해 비트코인 소프트웨어를 구현하도록 구성된 노드를 도시한다.
도 1c는 블록체인 네트워크를 도시한다.
도 2는 실시예에 따른 계정의 설정을 상세히 설명하는 흐름도를 도시한다.
도 3a 및 3b는 실시예에 따라 발송자로부터 수령자로의 지불을 상세히 설명하는 흐름도를 도시한다.
도 3c는 실시예에 따른 랑데뷰 트랜잭션을 도시한다.
도 3d는 더스트 트랜잭션의 체인과 이벤트 스트림 사이의 관계를 도시한다.
도 3e는 트랜잭션에 대한 당사자에 대응하는 복수의 이벤트 스트림을 도시한다.
도 4a는 실시예에 따라 발송자로부터 수령자로의 지불을 상세히 설명하는 흐름도를 도시한다.
도 4b는 실시예에 따른 랑데뷰 트랜잭션을 도시한다.
도 4c는 트랜잭션에 대한 당사자에 대응하는 복수의 이벤트 스트림을 도시한다.
도 5a는 실시예에 따라 발송자로부터 수령자로의 지불을 상세히 설명하는 흐름도를 도시한다.
도 5b는 실시예에 따른 랑데뷰 트랜잭션을 도시한다.
도 5c는 트랜잭션에 대한 당사자에 대응하는 복수의 이벤트 스트림을 도시한다.
도 6a 및 6b는 실시예에 따라 발송자로부터 수령자로의 지불을 상세히 설명하는 흐름도를 도시한다.
도 7은 실시예에 따라 생성된 랑데뷰 블록체인 트랜잭션을 도시한다.
도 8은 실시예에 따른 트랜잭션에 대한 당사자에 대한 이벤트 스트림을 도시한다.
도 8a는 커미트먼트의 체인을 도시한다.
도 9는 커미트먼트의 체인을 사용하여 자산 이전 이벤트를 레코딩하는 방법의 단계를 도시한다.
도 10은 복수의 커미트먼트의 체인을 동기화하는 랑데뷰 트랜잭션을 도시한다.
도 11은 상태 다이제스트를 나타내는 머클 트리를 도시한다.
도 12는 데이터 다이제스트를 나타내는 머클 트리를 도시한다.
도 13은 커미트먼트의 복수의 체인을 동기화하는 대안적인 랑데뷰 트랜잭션을 도시한다.
우리는 이제 독자에게 본 발명의 완전하고 완벽한 이해를 제공하기 위해 본 발명의 양상 및 실시예에 대한 상세한 논의를 제공한다.
제1 양상에서 볼 때, 적어도 제1 사용자 및 제2 사용자를 포함하는 자산 이전 이벤트를 레코딩하는 컴퓨터 구현 방법이 제공된다. 방법은 화폐 지불이 레코딩되는 것을 가능하게 할 수 있다. 화폐의 지불은 임의의 화폐일 수 있고, 상품 또는 서비스를 위한 것일 수 있다. 방법은 컴퓨팅 자원에 의해 구현될 수 있다. 컴퓨팅 자원은 구현된 하드웨어 또는 소프트웨어일 수 있다. 컴퓨팅 자원은 로컬적으로 또는 넓은 지리적 영역에 걸쳐 분산될 수 있는 복수의 프로세싱 자원을 포함할 수 있다. 방법은: 명령 데이터를 수신하는 단계를 포함할 수 있으며, 명령 데이터는 요청된 자산 이전 이벤트와 관련되며, 명령 데이터는 지불의 발송자와 관련된 메타데이터의 제1 세트 및 지불의 적어도 하나의 수령인과 관련된 메타데이터의 제2 세트를 포함한다. 메타데이터는 지불 화폐, 자산 레지스트리와 연관된 계정, 지불을 받거나 지불을 하도록 지정된 개인, 지불을 위한 약관(terms and conditions), 지불을 승인하는 공개 키 또는 디지털 서명의 증거 중 적어도 하나를 식별할 수 있다. 발송자와 수령자 각각은 자산 레지스트리와 연관된 계정과 각각 연관될 수 있다.
자산의 발송자는 커미트먼트의 제1 체인과 연관될 수 있고 자산의 수령자는 커미트먼트의 제2 체인과 연관될 수 있으며, 커미트먼트의 각각의 체인은 이벤트 스트림과 복수의 블록체인 트랜잭션을 연관시킨다. 커미트먼트의 체인은 이벤트 스트림과 연관된 관련 블록체인 트랜잭션의 세트를 제공할 수 있다. 블록체인 트랜잭션의 세트는 출력 데이터 페이로드에 있을 수 있는 정보에 의해 링크된다.
방법은, 이전 프로토콜에 따라, 발송자로부터 적어도 하나의 수령자로의 자산의 이전이 이루어질 수 있는지 여부를 결정하기 위해 메타데이터의 제1 세트와 메타데이터의 제2 세트를 비교하는 단계를 더 포함할 수 있고, 이전 프로토콜은 자산 이전 이벤트를 발생시키는 것을 가능하게 하기 위한 적어도 하나의 기준을 정의한다.
방법은, 이전 프로토콜에 따른 메타데이터의 개개의 세트 사이의 비교에 기초하여, 메타데이터의 개개의 세트 사이의 대응성의 하나 이상의 항목을 결정할 수 있다.
방법은 커미트먼트의 제1 및 제2 체인과 연관된 개개의 이벤트 스트림에 엔트리를 첨부하는 단계를 더 포함할 수 있으며, 엔트리는 메타데이터의 제1 및 제2 세트와 연관된 데이터를 포함한다.
방법은 적어도 하나의 입력 및 적어도 하나의 출력을 포함하는 랑데뷰 블록체인 트랜잭션을 생성하는 단계를 더 포함할 수 있으며, 적어도 하나의 출력은 메타데이터의 제1 및 제2 세트와 연관된 출력 데이터를 포함하고, 메타데이터와 관련된 데이터는 향후 트랜잭션과 관련된 데이터에 추가로 기초하며, 이전의 트랜잭션에 또한 기초할 수 있다. 적어도 하나의 입력 및 출력은 대응하는 복수의 입력 및 출력일 수 있다.
방법은 랑데뷰 블록체인 트랜잭션과 개개의 이벤트 스트림의 개개의 엔트리를 연관시키는 단계를 더 포함할 수 있다. 랑데뷰 블록체인 트랜잭션과 각각의 엔트리의 연관은 대응하는 이벤트 스트림 엔트리에 랑데뷰 블록체인 트랜잭션에 대한 참조를 저장하는 것을 포함할 수 있다.
랑데뷰 블록체인 트랜잭션이 블록체인으로 송신될 수 있다. 랑데뷰 트랜잭션은 다른 블록체인 트랜잭션의 세트과 함께 전송될 수 있다.
랑데뷰 블록체인 트랜잭션은 발송자와 수령자 각각에 대응하는 입력 및 출력 쌍을 포함할 수 있다. 입력 및 출력 쌍은 그들의 인덱스 측면에서 대응하는 입력 및 출력을 의미하는 것으로 이해될 수 있다. 다시 말해서, 예컨대 입력이 0의 인덱스를 갖는 경우, 입력 및 출력 쌍에서 출력도 또한 0의 인덱스를 갖는다. 예컨대 자산 레지스트리와 같은 다른 엔티티에 대응하는 입력 및 출력 쌍이 또한 있을 수 있다.
적어도 하나의 출력은 메타데이터의 제1 및 제2 세트 및 향후 트랜잭션에 기초하여 생성된 출력 메타데이터를 포함하는 데이터 페이로드를 포함할 수 있다. 출력 메타데이터는 데이터 다이제스트 및 상태 다이제스트를 포함할 수 있다. 적어도 하나의 출력은 지출 불가능할 수 있다. 메타데이터의 제1 및 제2 세트는 데이터 페이로드 내의 포함 전에 해싱되거나 이중 해싱될 수 있다. 향후 트랜잭션 데이터는 향후 트랜잭션에 대한 식별자일 수 있다. 다시 말해서, 데이터 페이로드는, 현재 트랜잭션과 향후 트랜잭션을 링크할 것이고 심지어 이전의 트랜잭션과 향후 트랜잭션을 링크할 수 있는 향후 트랜잭션을 커밋하는 정보를 포함할 수 있다.
데이터 다이제스트는 메타데이터의 제1 및 제2 세트의 해시에 기초하여 생성될 수 있다. 메타데이터의 제1 및 제2 세트의 해시에 추가 해시가 적용될 수 있으며, 이는 길이 확장 공격(length extension attack)에 대한 저항을 제공한다.
데이터 다이제스트는 메타데이터의 제1 및 제2 세트 및 솔트의 조합에 기초하여 생성될 수 있다. 다시 말해서, 솔팅의 동작은 메타데이터의 제1 및 제2 세트의 해시에 사용될 수 있다. 메타데이터의 제1 및 제2 세트는 지불 명령 데이터세트와 같은 데이터의 단일 세트를 형성하기 위해 조합될 수 있다.
해시를 솔팅하는 것은, 임의의 임의적인 데이터인 "솔트"를, 해싱 함수에 대한 입력(해싱되는 데이터와 함께)의 일부로서 사용하는 것을 의미할 수 있다. 솔트는 해시 함수에 대한 다른 입력과 연접될 수 있다. 선택적으로, 솔트는 랜덤이다. 해싱되는 각각의 데이터 엔트리에 대해 상이한 솔트가 선택될 수 있다.
메타데이터의 제1 세트 및 메타데이터의 제2 세트의 조합은 메타데이터의 제1 세트 및 메타데이터의 제2 세트의 조합의 이중 해시를 취하는 것 및 메타데이터의 제1 세트 및 메타데이터의 제2 세트의 조합의 이중 해시와 솔트의 이중 해시를 연접(concatenate)하는 것을 포함할 수 있다.
상태 다이제스트는 데이터 다이제스트 및 향후 트랜잭션에 기초하여 생성될 수 있고, 이전의 트랜잭션에 기초하여 추가로 생성될 수 있다.
상태 다이제스트는 머클 트리의 루트일 수 있다.
메타데이터의 개개의 세트 사이의 대응성의 하나 이상의 항목을 결정하는 것은 다음 중 적어도 하나 사이의 대응성을 결정하는 것을 포함할 수 있다:
i) 메타데이터의 개개의 세트에서 식별되는 지불 화폐;
ii) 발송자에 대응하는 계정으로부터 지급되는 화폐 금액 및 수령자에 대응하는 계정으로부터 요청된 화폐 금액; 및
iii) 발송자 계정 및 수령자 계정과 연관된 자산 레지스트리의 식별자.
컴퓨팅 자원은, 이전 프로토콜에 따라, 이전이 이루어질 수 없다고 결정하고; 이전 프로토콜과의 일관성 부재를 해결하기 위해 메타데이터의 추가 세트를 생성할 수 있고, 이는 제1 화폐와 제2 화폐 간의 변환을 가능하게 하는 메타데이터를 생성하는 것을 포함할 수 있다.
메타데이터의 추가 세트의 생성은 하나의 자산 레지스트리가 주어진 자산의 다른 자산 레지스트리로의 이전을 레코딩하기 위한 메타데이터를 생성하는 것을 포함할 수 있다.
특정 실시예는 이제 첨부된 도면을 참조하여 예시의 방식으로 설명되며, 도면에서 동일한 참조 번호는 동일한 특징을 나타낸다.
시스템 개요
우리는, 이제 도 1a를 참조하여, 시스템(100)의 제1 사용자와 제2 사용자 사이의 자산 이전이 레코딩되는 것을 가능하게 하는 시스템(100)을 설명한다.
시스템(100)은 제1 컴퓨팅 디바이스(102) 및 제2 컴퓨팅 디바이스(104)를 포함한다. 제1 컴퓨팅 디바이스(102) 및 제2 컴퓨팅 디바이스(104)는 임의의 컴퓨팅 자원일 수 있다. 제1 컴퓨팅 디바이스(102) 및 제2 컴퓨팅 디바이스(104) 각각은 개개의 제1 및 제2 애플리케이션 프로그래밍 인터페이스(API)(108)를 통해 지불 프로세싱 자원(106)과 상호작용하도록 구성된다.
지불 프로세싱 자원(106)은 이벤트 스트림 자원(110)을 사용하여 적어도 제1 사용자로 명명된 앨리스(110a), 제2 사용자로 명명된 밥(110b) 및 지불 프로세싱 자원(110c) 각각에 대해 제공되는 이벤트 스트림을 초기화 및/또는 상호작용하도록 구성된다. 지불 프로세싱 자원(106)에 의한 이벤트 스트림과의 초기화 및 상호작용은 nChain Holdings Limited라는 이름으로 2021년 2월 18일에 출원된 영국 특허 출원 제2102314.8호로부터 이해될 것이다.
지불 프로세싱 자원(106)은 블록체인(112)과 상호작용하도록 추가로 구성된다. 블록체인(112)은, 트랜잭션으로 구성되는 블록(BSV1, BSV2, BSV3)의 첨부 전용 원장이라는 점에서 비트코인 사토시 비전(BSV) 프로토콜에 따라 적어도 하나의 공개 작업 증명 블록체인을 포함할 수 있다.
블록체인(112)은, 이제 도 1b와 관련하여 설명되는 소프트웨어에 의해 구성된 복수의 노드(126)를 포함한다. 각각의 노드는 도 1c와 관련하여 아래에 설명된 바와 같이 블록체인의 일부로서 이 소프트웨어에 따라 구성된다.
도 1b는 UTXO-기반 또는 출력-기반 모델의 예에서 네트워크(132)의 각각의 블록체인 노드(126) 상에서 실행되는 노드 소프트웨어(450)의 예를 예시한다. 다른 엔티티는, 네트워크(132) 상의 노드(126)로서 분류되지 않고서, 즉, 노드(126)의 요구된 동작을 수행하지 않고서, 노드 소프트웨어(450)를 실행할 수 있다는 것이 유의된다. 노드 소프트웨어(450)는 프로토콜 엔진(451), 스크립트 엔진(452), 스택(453), 애플리케이션-레벨 결정 엔진(454), 및 일 세트의 하나 이상의 블록체인-관련 기능 모듈들(455)을 포함할 수 있지만 이에 제한되지 않는다. 각각의 노드(126)는, 합의 모듈(455C)(예컨대, 작업 증명), 전파 모듈(455P) 및 저장 모듈(예컨대, 데이터베이스) 중 3개 모두를 포함하지만 이에 제한되지 않는 노드 소프트웨어를 실행할 수 있다. 프로토콜 엔진(401)은 전형적으로 트랜잭션(152)의 상이한 필드들을 인식하고 이들을 노드 프로토콜에 따라 프로세싱하도록 구성된다. 다른 선행 트랜잭션(152i)()의 출력(예컨대, UTXO)을 가리키는 입력을 갖는 트랜잭션(152j)()이 수신될 때, 프로토콜 엔진(451)은 의 잠금해제 스크립트를 식별하고 이를 스크립트 엔진(452)에 전달한다. 프로토콜 엔진(451)은 또한 의 입력의 포인터에 기초하여 를 식별 및 리트리브(retrieve)한다. 는 블록체인(150) 상에서 공개될 수 있고, 이 경우에, 프로토콜 엔진은 노드(126)에 저장된 블록체인(150)의 블록(151)의 사본으로부터 를 리트리브할 수 있다. 대안적으로, 는 여전히 블록체인(150) 상에서 공개되었을 수 있다. 이 경우에, 프로토콜 엔진(451)은 노드(104)에 의해 유지되는 미공개 트랜잭션의 정렬된 세트(154)로부터 를 리트리브할 수 있다. 어느 쪽이든, 스크립트 엔진(451)은 의 참조된 출력에서 잠금 스크립트를 식별하고, 이를 스크립트 엔진(452)으로 전달한다.
따라서, 스크립트 엔진(452)은 의 대응하는 입력으로부터의 잠금해제 스크립트 및 의 잠금 스크립트를 갖는다. 예컨대, 및 로 라벨링된 트랜잭션이 도 2에 예시되지만, 및 같은 트랜잭션들의 임의의 쌍에 동일하게 적용될 수 있다. 스크립트 엔진(452)은 이전에 논의된 바와 같이 2개의 스크립트들을 함께 실행하며, 이는 사용되고 있는 스택-기반 스크립팅 언어(예컨대, Script)에 따라 스택(453) 상에 데이터를 배치하고 스택(403)으로부터 데이터를 리트리브하는 것을 포함할 것이다.
스크립트들을 함께 실행함으로써, 스크립트 엔진(452)은 잠금해제 스크립트가 잠금 스크립트에 정의된 하나 이상의 기준들을 충족시키는지 여부 ― 즉, 잠금 스크립트가 포함되는 출력을 "잠금해제"하는가? 를 결정한다. 스크립트 엔진(452)은 이 결정의 결과를 프로토콜 엔진(451)에 반환한다. 잠금해제 스크립트가 대응하는 잠금 스크립트에 지정된 하나 이상의 기준들을 충족시키는 것으로 스크립트 엔진(452)이 결정하는 경우, 결과 "참"이 반환된다. 그렇지 않으면, 결과 "거짓"이 반환된다.
출력-기반 모델에서, 스크립트 엔진(452)으로부터의 결과 "참"은 트랜잭션의 유효함을 위한 조건들 중 하나이다. 통상적으로 또한 충족되어야 하는, 프로토콜 엔진(451)에 의해 평가되는 하나 이상의 추가의 프로토콜-레벨 조건들; 이를테면, 의 출력(들)에 지정된 디지털 자산의 총 금액이 그의 입력에 의해 가리켜지는 총 금액을 초과하지 않는 것, 그리고 의 가리켜진 출력이 다른 유효한 트랜잭션에 의해 이미 지출되지 않았을 것이 존재한다. 프로토콜 엔진(451)은 하나 이상의 프로토콜-레벨 조건들과 함께 스크립트 엔진(452)으로부터의 결과를 평가하고, 이들이 모두 참인 경우에만, 트랜잭션 을 유효성 검증한다. 프로토콜 엔진(451)은 트랜잭션이 유효한지에 관한 표시를 애플리케이션-레벨 판단 엔진(454)에 출력한다. 이 실제로 유효성 검증된다는 조건에서만, 결정 엔진(454)은 에 대해 그들 개개의 블록체인-관련 기능을 수행하도록 합의 모듈(455C) 및 전파 모듈(455P) 둘 모두를 제어하기로 선택할 수 있다. 이것은 블록(151)에 통합하기 위해 노드의 트랜잭션의 개개의 정렬된 세트(154)에 를 추가하는 합의 모듈(455C), 및 를 네트워크(106)의 다른 블록체인 노드(126)에 포워딩하는 전파 모듈(455P)을 포함한다. 선택적으로, 실시예들에서, 애플리케이션 결정 엔진(454)은, 이러한 기능들 중 어느 하나 또는 둘 모두를 트리거하기 전에 하나 이상의 부가적인 조건들을 적용할 수 있다. 예컨대, 결정 엔진은, 트랜잭션 모두가 유효하고 트랜잭션 수수료가 충분하다는 조건 하에서만 트랜잭션을 공개하기로 선택할 수 있다.
또한, 본원에서 "참" 및 "거짓"이라는 용어들은 단지 단일 바이너리 숫자(비트)의 형태로 표현되는 결과를 반환하는 것으로 반드시 제한되지는 않지만, 이는 확실히 하나의 가능한 구현이라는 것에 주의한다. 보다 일반적으로, "참"은 성공 또는 긍정적인 결과를 표시하는 임의의 상태를 지칭할 수 있고 "거짓"은 실패 또는 비-긍정적인 결과를 표시하는 임의의 상태를 지칭할 수 있다. 예컨대, 계정-기반 모델에서, "참"의 결과는 서명의 암시적인 프로토콜 레벨의 유효성 검증 및 스마트 계약의 부가적인 긍정적인 출력의 조합에 의해 표시될 수 있다(개별 결과들 둘 모두가 참인 경우, 전체 결과가 참을 시그널링하는 것으로 간주됨).
개시된 기술들의 다른 변형들 또는 사용 사례들은 본원에서의 개시가 주어지면 당업자에게 명백해질 수 있다. 본 개시의 범위는 설명된 실시예에 의해 제한되는 것이 아니라 첨부된 청구들에 의해서만 제한된다.
예컨대, 위의 일부 실시예는 비트코인 네트워크(106), 비트코인 블록체인(150) 및 비트코인 노드(126)와 관련하여 설명되었다. 그러나, 비트코인 블록체인은 블록체인(150)의 하나의 특정 예이고, 위의 설명은 일반적으로 임의의 블록체인에 적용될 수 있음을 인지될 것이다. 즉, 본 발명은 결코 비트코인 블록체인에 한정되지 않는다. 보다 일반적으로, 비트코인 네트워크(106), 비트코인 블록체인(150) 및 비트코인 노드(126)에 대한 위의 임의의 참조는 각각 블록체인 네트워크(106), 블록체인(150) 및 블록체인 노드(126)에 대한 참조로 대체될 수 있다. 블록체인, 블록체인 네트워크 및/또는 블록체인 노드는, 전술한 바와 같이, 비트코인 블록체인(150), 비트코인 네트워크(106) 및 비트코인 노드(126)의 설명된 속성 중 일부 또는 전부를 공유할 수 있다.
본 발명의 바람직한 실시예에서, 블록체인 네트워크(132)는 비트코인 네트워크이고, 비트코인 노드(126)는 적어도 블록체인(150)의 블록(151)을 생성, 공개, 전파 및 저장하는 설명된 기능 모두를 수행한다. 이러한 기능의 전부가 아닌 하나 또는 일부만을 수행하는 다른 네트워크 엔티티(또는 네트워크 요소)가 있을 수 있다는 것이 배제되지 않는다. 즉, 네트워크 엔티티는, 블록을 생성 및 공개하지 않고, 블록을 전파 및/또는 저장하는 기능을 수행할 수 있다(이러한 엔티티는 선호되는 비트코인 네트워크(132)의 노드로 간주되지 않는다는 것을 상기함).
본 발명의 바람직하지 않은 실시예에서, 블록체인 네트워크(132)는 비트코인 네트워크가 아닐 수 있다. 이러한 실시예에서, 노드가 블록체인(150)의 블록(151)을 생성, 공개, 전파 및 저장하는 기능의 전부는 아니지만 적어도 하나 또는 일부를 수행할 수 있다는 것이 배제되지 않는다. 예컨대, 그러한 다른 블록체인 네트워크 상에서 "노드"는 블록(151)을 생성 및 공개하지만 이러한 블록(151)을 저장 및/또는 다른 노드로 전파하지 않도록 구성된 네트워크 엔티티를 지칭하는 데 사용될 수 있다.
훨씬 더 일반적으로, 위의 "비트코인 노드"(126)라는 용어에 대한 임의의 언급은 "네트워크 엔티티" 또는 "네트워크 요소"로 대체될 수 있으며, 이러한 엔티티/요소는 블록을 생성, 공개, 전파 및 저장하는 역할 중 일부 또는 전부를 수행하도록 구성된다. 이러한 네트워크 엔티티/요소의 기능은, 블록체인 노드(126)를 참조하여 위에서 설명한 방식과 동일한 방식으로 하드웨어에서 구현될 수 있다.
훨씬 더 일반적으로, 위의 "비트코인 노드"(126)라는 용어에 대한 임의의 언급은 "네트워크 엔티티" 또는 "네트워크 요소"로 대체될 수 있으며, 이러한 엔티티/요소는 블록을 생성, 공개, 전파 및 저장하는 역할 중 일부 또는 전부를 수행하도록 구성된다. 이러한 네트워크 엔티티/요소의 기능은, 블록체인 노드(126)를 참조하여 위에서 설명한 방식과 동일한 방식으로 하드웨어에서 구현될 수 있다.
도 1c는 블록체인(150)을 구현하기 위한 예시적인 시스템(100)을 도시한다. 시스템(100)은 패킷-교환 네트워크(130), 통상적으로 인터넷과 같은 광역 인터네트워크를 포함할 수 있다. 패킷-교환 네트워크(130)는, 패킷-교환 네트워크(130) 내에서 P2P(peer-to-peer) 네트워크(132)를 형성하도록 배열될 수 있는 복수의 블록체인 노드들(126)을 포함한다. 예시되지 않지만, 블록체인 노드(126)는 거의 완전한 그래프로서 배열될 수 있다. 따라서, 각각의 블록체인 노드(126)는 다른 블록체인 노드(126)에 고도로 연결된다.
각각의 블록체인 노드(126)는 피어의 컴퓨터 장비를 포함하며, 노드들(126) 중 상이한 노드들은 상이한 피어들에 속한다. 각각의 블록체인 노드(126)는 하나 이상의 프로세서들, 예컨대, 하나 이상의 CPU(central processing unit)들, 가속기 프로세서들, 애플리케이션 특정 프로세서 및/또는 FPGA(field programmable gate array)들, 및 ASIC(Application Specific Integrated Circuit)와 같은 다른 장비를 포함하는 프로세싱 장치를 포함한다. 각각의 노드는 또한 메모리, 즉 비-일시적 컴퓨터-판독 가능 매체 또는 매체들의 형태의 컴퓨터-판독 가능 저장소를 포함한다. 메모리는 하나 이상의 메모리 매체들, 예컨대, 하드 디스크와 같은 자기 매체; 솔리드 스테이트 드라이브(SSD), 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광학 디스크 드라이브와 같은 광학 매체를 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다.
블록체인(150)은 데이터의 블록들의 체인(151)을 포함하며, 블록체인(150)의 개개의 사본이 분산형 또는 블록체인 네트워크(130)의 복수의 블록체인 노드들(126) 각각에서 유지된다. 위에서 언급된 바와 같이, 블록체인(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)을 가리켰다.
블록체인 노드(126) 각각은 트랜잭션(152)을 다른 블록체인 노드(126)에 포워딩하고 이로써 트랜잭션(152)이 네트워크(132) 전반에 걸쳐 전파되게 하도록 구성된다. 각각의 블록체인 노드(126)는 블록들(151)을 생성하고 동일한 블록체인(150)의 개개의 사본을 그들 개개의 메모리에 저장하도록 구성된다. 각각의 블록체인 노드(126)는 또한 블록(151)으로 통합되기를 대기하는 트랜잭션들(152)의 정렬된 세트(154)를 유지한다. 정렬된 세트(154)는 종종 "멤풀(mempool)"로 지칭된다. 본원에서 이러한 용어는 임의의 특정 블록체인, 프로토콜 또는 모델로 제한되도록 의도되지 않는다. 이것은, 노드(126)가 유효한 것으로 수락하였고 노드(126)가 동일한 출력을 지출하려고 시도하는 임의의 다른 트랜잭션을 수락하지 않도록 해야 되는 트랜잭션의 정렬된 세트를 지칭한다.
주어진 현재 트랜잭션(152j)에서, 그(또는 각각의) 입력은 트랜잭션들의 시퀀스에서 선행 트랜잭션(152i)의 출력을 참조하는 포인터를 포함하여, 그러한 출력이 현재 트랜잭션(152j)에서 "지출"되거나 리딤됨을 지정한다. 일반적으로, 선행 트랜잭션은 정렬된 세트(154) 또는 임의의 블록(151)의 임의의 트랜잭션일 수 있다. 선행 트랜잭션(152i)은 현재 트랜잭션(152j)이 생성되거나 심지어 네트워크(132)로 전송될 때 반드시 존재할 필요는 없지만, 선행 트랜잭션(152i)은 현재 트랜잭션이 유효하기 위해 존재하고 유효성 검증될 필요가 있을 것이다. 따라서 본원에서 "선행(preceding)"이라 함은 포인터들에 의해 링크된 논리적 시퀀스의 선행자를 지칭하며, 반드시 시간적 시퀀스의 전송 또는 생성 시간은 아니고, 따라서 트랜잭션들(152i, 152j)은 순서와 다르게(out-of-order)(고아 트랜잭션들에 대한 아래 논의 참조) 전송되거나 생성되는 것을 반드시 배제하지 않는다. 선행 트랜잭션(152i)은 앞선(antecedent) 트랜잭션 또는 선행자(predecessor) 트랜잭션으로 동등하게 칭해질 수 있다.
현재 트랜잭션(152j)의 입력은 또한 입력 인가(input authorisation), 예컨대, 선행 트랜잭션(152i)의 출력이 잠금된 사용자(103a)의 서명을 포함한다. 차례로, 현재 트랜잭션(152j)의 출력은 새로운 사용자 또는 엔티티(103b)에 대해 암호학적으로 잠금될 수 있다. 따라서 현재 트랜잭션(152j)은 선행 트랜잭션(152i)의 입력에서 정의된 금액을 현재 트랜잭션(152j)의 출력에서 정의된 바와 같은 새로운 사용자 또는 엔티티(103b)에게 전달할 수 있다. 일부 경우들에서 트랜잭션(152)은 다수의 사용자들 또는 엔티티들(이들 중 하나는 잔돈(change)을 주기 위해 오리지널 사용자(103a)일 수 있음) 사이에서 입력 금액을 분할하기 위해 다수의 출력들을 가질 수 있다. 일부 경우에서 트랜잭션은 또한 하나 이상의 선행 트랜잭션들의 다수의 출력들로부터 금액들을 수집하고 현재 트랜잭션의 하나 이상의 출력들에 재분배하기 위해 다수의 입력들을 가질 수 있다.
비트코인과 같은 출력-기반 트랜잭션 프로토콜에 따라, 엔티티, 이를테면, 사용자 또는 머신이 새로운 트랜잭션(152j)을 규정하기를 원할 때, 엔티티는 새로운 트랜잭션을 자신의 컴퓨터 단말로부터 수신자에게 전송한다. 엔티티 또는 수신자는 결국 이러한 트랜잭션을 네트워크(132)의 블록체인 노드(126) 중 하나 이상(이는 오늘날 전형적으로 서버 또는 데이터 센터이지만, 원칙적으로 다른 사용자 단말일 수 있음)에 전송할 수 있다. 또한, 새로운 트랜잭션(152j)을 규정하는 엔티티(103)가 일부 예들에서 수신자가 아니라 블록체인 노드(126) 중 하나 이상에 전송할 수 있다는 것이 배제되지 않는다. 트랜잭션을 수신하는 블록체인 노드(126)는, 블록체인 노드들(126) 각각에 적용되는 블록체인 노드 프로토콜에 따라 트랜잭션이 유효한지를 체크한다. 블록체인 노드 프로토콜은 통상적으로 블록체인 노드(126)가 새로운 트랜잭션(152j)의 암호화 서명이 예상되는 서명과 매칭되는지를 체크하도록 요구하며, 이는 트랜잭션들(152)의 정렬된 시퀀스에서 이전의 트랜잭션(152i)에 의존한다. 이러한 출력-기반 트랜잭션 프로토콜에서, 이는 새로운 트랜잭션(152j)의 입력에 포함된 엔티티(103)의 암호화 서명 또는 다른 인가가 새로운 트랜잭션이 할당하는 선행 트랜잭션(152i)의 출력에 정의된 조건과 매칭된다는 것을 체크하는 것을 포함하며, 여기에서 이 조건은 통상적으로 적어도 새로운 트랜잭션(152j)의 입력의 암호화 서명 또는 다른 인가가 새로운 트랜잭션의 입력이 링크된 이전의 트랜잭션(152i)의 출력을 잠금 해제한다는 것을 체크하는 것을 포함한다. 조건은 선행 트랜잭션(152i)의 출력에 포함된 스크립트에 의해 적어도 부분적으로 정의될 수 있다. 대안적으로, 이는 단순히 블록체인 노드 프로토콜만으로 고정될 수 있거나, 이는 이들의 조합으로 인한 것일 수 있다. 어느 쪽이든, 새로운 트랜잭션(152j)이 유효한 경우, 블록체인 노드(126)는 이를 블록체인 네트워크(132)의 하나 이상의 다른 블록체인 노드들(126)에 포워딩한다. 이러한 다른 블록체인 노드들(126)은 동일한 블록체인 프로토콜에 따라 동일한 테스트를 적용하고, 이에 따라 새로운 트랜잭션(152j)을 하나 이상의 추가 노드들(126)로 포워딩하는 식이다. 이러한 방식으로, 새로운 트랜잭션은 블록체인 노드들(126)의 네트워크 전반에 걸쳐 전파된다.
출력-기반 모델에서, 주어진 출력(예컨대, UTXO)이 할당되는지 여부에 대한 정의는 그것이 블록체인 노드 프로토콜에 따라 다른 전방 트랜잭션(152j)의 입력에 의해 유효하게 리딤되었는지의 여부이다. 트랜잭션이 유효하기 위한 다른 조건은, 할당 또는 리딤을 시도하는 선행 트랜잭션(152i)의 출력이 다른 트랜잭션에 의해 이미 할당/리딤되지 않았다는 것이다. 재차, 유효하지 않은 경우, 트랜잭션(152j)은 (무효한 것으로 플래깅되고 경고를 위해 전파되지 않는 한) 블록체인(150)에 기록되거나 전파되지 않을 것이다. 이는 거래자가 동일한 트랜잭션의 출력을 한번 초과로 할당하고자 시도하는 이중-지출을 경계한다. 반면, 계정-기반 모델은 계정 잔액을 유지함으로써 이중-지출을 경계한다. 재차, 트랜잭션들의 정의된 순서가 존재하기 때문에, 계정 잔액은 임의의 한 시간에 단일의 정의된 상태를 갖는다.
트랜잭션을 유효성 검증하는 것에 추가하여, 블록체인 노드들(126) 은 또한 채굴로서 공통적으로 지칭되는 프로세스에서 트랜잭션들의 블록들을 최초로 생성하기 위해 경쟁하며, 이는 "작업 증명"에 의해 지원된다. 블록체인 노드(126)에서, 유효한 트랜잭션들의 정렬된 세트(154)에, 블록체인(150)에 기록된 블록(151)에 아직 나타나지 않은 새로운 트랜잭션들이 추가된다. 그 후, 블록체인 노드들은 암호화 퍼즐을 해결하도록 시도함으로써 트랜잭션들의 정렬된 세트(154)로부터 트랜잭션들(152)의 새로운 유효한 블록(151)을 조립하기 위해 경쟁한다. 통상적으로 이는 "논스(nonce)"가 트랜잭션들의 정렬된 세트(154)의 표현과 연접되고(concatenated) 해싱될 때, 해시의 출력이 미리 결정된 조건을 충족시키도록 논스 값을 검색하는 것을 포함한다. 예컨대, 미리 결정된 조건은 해시의 출력이 미리 정의된 특정 수의 선행 0들을 갖는 것일 수 있다. 이것은 단지 하나의 특정 유형의 작업 증명 퍼즐이고, 다른 유형이 배제되지 않는다는 것이 유의된다. 해시 함수의 특성은 해시 함수가 그의 입력에 대해 예측 불가능한 출력을 갖는다는 것이다. 따라서, 이 검색은 무차별 대입(brute force)에 의해서만 수행될 수 있고, 이에 따라 퍼즐을 해결하고자 하는 각각의 블록체인 노드(126)에서 상당한 양의 프로세싱 자원을 소비한다.
퍼즐을 해결하고자 하는 제1 블록체인 노드(126)는 이를 네트워크(132)에 발표하고, 그 해(solution)를 증명으로서 제공하며, 이는 그 후 네트워크의 다른 블록체인 노드(126)들에 의해 쉽게 체크될 수 있다(해시에 대한 해가 주어지면, 그 해가 해시의 출력으로 하여금 조건을 충족시키게 한다는 것을 체크하는 것은 간단함). 제1 블록체인 노드(126)는, 블록을 수락하고 따라서 프로토콜 규칙을 시행하는 임계 합의의 다른 노드에 블록을 전파시킨다. 그런 다음, 트랜잭션의 정렬된 세트(154)는 블록체인 노드(126) 각각에 의해 블록체인에 새로운 블록(151)으로서 기록되게 된다. 블록 포인터(155)가 또한 체인에서 이전에 생성된 블록(151n-1)을 뒤로 가리키는 새로운 블록(151n)에 할당된다. 작업 증명 해를, 예컨대, 해시 형태로 생성하는 데 요구되는 상당한 양의 노력은 블록체인 프로토콜의 규칙을 따르게 하기 위한 제1 노드(126)의 의도를 시그널링한다. 이러한 규칙은, 동일한 출력을 이전에 유효성 검증된 트랜잭션으로서 할당하면(이는 달리 이중 지출로 알려짐), 트랜잭션을 유효한 것으로 수락하지 않는 것을 포함한다. 일단 생성되면, 블록(151)은 수정될 수 없는데, 그 이유는 그것이 블록 네트워크(132)의 저장 노드들(126) 각각에서 인식 및 유지되기 때문이다. 블록 포인터(155)는 또한 블록들(151)에 순차적인 순서를 부과한다. 트랜잭션들(152)이 네트워크(132)의 각각의 블록체인 노드(126)에서 정렬된 블록들에 기록되기 때문에, 이는 이에 따라, 트랜잭션들의 변경 불가능한 공개 원장을 제공한다.
임의의 주어진 시간에 퍼즐을 풀기 위해 경쟁하는 상이한 블록체인 노드들(126)은, 그들이 트랜잭션이 수신된 순서 또는 해의 검색을 시작한 시기에 의존하여, 임의의 주어진 시간에 아직 공개되지 않은 트랜잭션의 정렬된 세트(154)의 상이한 스냅샷들에 기초하여 퍼즐을 해결한다는 것이 유의된다. 그들 개개의 퍼즐을 먼저 푸는 사람은, 어떤 트랜잭션들(152)이 어떤 순서로 다음의 새로운 블록(151n)에 포함되는지를 정의하고 공개되지 않은 트랜잭션들의 현재 세트(154)는 업데이트된다. 그 후, 블록체인 노드들(126)은 새롭게 정의된 미해결의 공개되지 않은 트랜잭션의 정렬된 세트(154)로부터 블록을 생성하기 위해 계속 경쟁하며, 이와 같이 계속된다. 발생할 수 있는 임의의 "포크(fork)" ― 이는 2개의 블록체인 노드들(126)이 서로 매우 짧은 시간 내에 그의 퍼즐을 풀어서, 블록체인에 대한 상충되는 뷰(view)가 노드들(126) 사이에 전파되는 경우임 ― 를 해결하기 위한 프로토콜이 또한 존재한다. 요컨대, 가장 길게 성장하는 포크의 갈래가 확정적인 블록체인(150)이 된다. 동일한 트랜잭션이 포크 둘 모두에서 나타날 것이기 때문에, 이는 네트워크의 사용자 또는 에이전트에 영향을 미치지 않아야 한다는 것이 유의된다.
비트코인 블록체인(및 대부분의 다른 블록체인)에 따라, 새로운 블록(126)을 성공적으로 구성한 노드에는, 디지털 자산의 수락된 금액을 새로운 특별한 종류의 트랜잭션에 할당하는 능력이 수여되고, 트랜잭션은 (하나의 에이전트 또는 사용자에서 다른 에이전트 또는 사용자로 디지털 자산의 금액을 이전하는 에이전트간 트랜잭션 또는 사용자간 트랜잭션과 대조적으로) 디지털 자산의 정의된 수량을 분배한다. 이 특별한 유형의 트랜잭션을 일반적으로 "코인베이스 트랜잭션"으로 지칭되지만, 또한 "개시 트랜잭션"으로 칭해질 수 있다. 이것은 일반적으로 새로운 블록(151n)의 제1 트랜잭션을 형성한다. 작업 증명은, 이 특별한 트랜잭션이 나중에 리딤되는 것을 허용하는 프로토콜 규칙을 따르도록 새로운 블록을 구성하는 노드의 의도를 시그널링한다. 블록체인 프로토콜 규칙은, 이 특별 트랜잭션이 리딤되기 전에, 만기 기간, 예컨대, 100개의 블록을 요구할 수 있다. 종종 일반(비-생성) 트랜잭션(152)은 또한, 해당 트랜잭션이 공개된 블록(151n)을 생성한 블록체인 노드(126)를 추가로 보상하기 위해, 그의 출력들 중 하나에 부가적인 트랜잭션 수수료를 지정할 것이다. 이러한 수수료는 정상적으로 "트랜잭션 수수료"로 지칭되고, 아래에 논의된다.
트랜잭션 유효성 검증 및 공개에 수반되는 자원으로 인해, 통상적으로 적어도 블록체인 노드들(126) 각각은 하나 이상의 물리적 서버 유닛들, 또는 심지어 전체 데이터 센터를 포함하는 서버의 형태를 취한다. 그러나, 원칙적으로, 임의의 주어진 블록체인 노드(126)는 사용자 단말 또는 함께 네트워킹된 사용자 단말들의 그룹의 형태를 취할 수 있다.
각각의 블록체인 노드(126)의 메모리는 블록체인 노드 프로토콜에 따라 각자의 역할 또는 역할들을 수행하고 트랜잭션들(152)을 처리하기 위해 블록체인 노드(126)의 프로세싱 장치 상에서 실행되도록 구성된 소프트웨어를 저장한다. 본원에서 블록체인 노드(126)에 기인한 임의의 동작은 각자의 컴퓨터 장비의 프로세싱 장치 상에서 실행되는 소프트웨어에 의해 수행될 수 있다는 것이 이해될 것이다. 노드 소프트웨어는 애플리케이션 계층, 운영 시스템 계층 또는 프로토콜 계층과 같은 하위 계층, 또는 이들의 임의의 조합에서 하나 이상의 애플리케이션들에서 구현될 수 있다.
또한 네트워크(130)에는 소비 사용자들의 역할을 하는 복수의 당사자들(103) 각각의 컴퓨터 장비가 연결되어 있다. 이러한 사용자는 블록체인 네트워크와 상호작용할 수 있지만, 트랜잭션 및 블록의 유효성 검증, 구성 또는 전파에 참여하지 않는다. 이러한 사용자 또는 에이전트(103) 중 일부는 트랜잭션에서 전송자 및 수신자의 역할을 할 수 있다. 다른 사용자는, 반드시 전송자 또는 수신자의 역할을 하지 않고도, 블록체인(150)과 상호작용할 수 있다. 예컨대, 일부 당사자는 블록체인(150)의 사본을 저장하는(예컨대, 블록체인 노드(126)로부터 블록체인의 사본을 획득한) 저장 엔티티의 역할을 할 수 있다.
당사자(103) 중 일부 또는 전부는 상이한 네트워크, 예컨대, 블록체인 네트워크(132)의 최상부에 오버레이된 네트워크의 일부로서 연결될 수 있다. 블록체인 네트워크의 사용자(종종 "클라이언트"로 지칭됨)는 블록체인 네트워크를 포함하는 시스템의 일부라고 할 수 있지만, 이러한 사용자는 블록체인 노드에서 요구되는 역할을 수행하지 않기 때문에 블록체인 노드(126)가 아니다. 대신에, 각각의 당사자(103)는 블록체인 네트워크(132)와 상호작용하고 이로써 블록체인 노드(132)에 연결(즉, 통신)함으로써 블록체인(150)을 활용할 수 있다. 제1 당사자(103a) 및 그/그녀의 개개의 컴퓨터 장비(102a) 및 제2 당사자(103b) 및 그/그녀의 개개의 컴퓨터 장비(102b)인 두 당사자들(103) 및 이들의 개개의 장비(102)가 예시 목적으로 도시된다. 제1 컴퓨팅 디바이스(102) 및 제2 컴퓨팅 디바이스(104)는 개개의 컴퓨터 장비(102a 또는 102b)의 기능성 중 임의의 것을 구현하도록 구성될 수 있다. 훨씬 더 많은 이러한 당사자들(103) 및 이들의 개개의 컴퓨터 장비(102)가 존재하고 시스템(100)에 참여할 수 있지만, 편의상 그것들은 예시되지 않는다는 것이 이해될 것이다. 각각의 당사자(103)는 개인 또는 조직일 수 있다. 순전히 예시로서, 제1 당사자(103a)는 본원에서 앨리스(Alice)로 지칭되고 제2 당사자(103b)는 밥(Bob)으로 지칭되지만, 이것이 제한적이지 않고 본원에서 앨리스 또는 밥에 대한 임의의 참조는 각각 "제1 당사자" 및 "제2 당사자"로 대체될 수 있다는 것이 인지될 것이다.
각각의 당사자(103)의 컴퓨터 장비는 하나 이상의 프로세서들, 예컨대, 하나 이상의 CPU들, GPU들, 다른 가속기 프로세서들, 애플리케이션 특정 프로세서들 및/또는 FPGA들을 포함하는 개개의 프로세싱 장치를 포함한다. 각각의 당사자(103)의 컴퓨터 장비는 메모리, 즉 비-일시적 컴퓨터-판독 가능 매체 또는 매체들의 형태의 컴퓨터-판독 가능 저장소를 더 포함한다. 이 메모리는 하나 이상의 메모리 매체들, 예컨대, 하드 디스크와 같은 자기 매체; 솔리드 스테이트 SSD, 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광학 디스크 드라이브와 같은 광학 매체를 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다. 각각의 당사자(103)의 컴퓨터 장비 상의 메모리는 프로세싱 장치 상에서 실행되도록 배열된 적어도 하나의 클라이언트 애플리케이션(105)의 개개의 인스턴스를 포함하는 소프트웨어를 저장한다. 본원에서 주어진 당사자(103)에 기인한 임의의 동작은 개개의 컴퓨터 장비의 프로세싱 장치 상에서 실행되는 소프트웨어를 사용하여 수행될 수 있다는 것이 이해될 것이다. 각각의 당사자(103)의 컴퓨터 장비는 적어도 하나 사용자 단말, 예컨대, 데스크 톱 또는 랩톱 컴퓨터, 태블릿, 스마트폰, 또는 스마트워치와 같은 웨어러블 디바이스를 포함한다. 주어진 당사자(103)의 컴퓨터 장비는 또한 사용자 단말을 통해 액세스되는 클라우드 컴퓨팅 자원들과 같은 하나 이상의 다른 네트워킹된 자원들을 포함할 수 있다.
예컨대, 서버로부터 다운로드되거나, 또는 이동식 저장 디바이스 이를테면, 이동식 SSD, 플래시 메모리 키, 이동식 EEPROM, 이동식 자기 디스크 드라이브, 자기 플로피 디스크 또는 테이프, 광학 디스크 이를테면, CD 또는 DVD ROM 또는 이동식 광학 드라이브 등 상에서 제공되는 클라이언트 애플리케이션(105)은 적절한 컴퓨터-판독 가능 저장 매체 또는 매체들 상에서 임의의 주어진 당사자(103)의 컴퓨터 장비(102)에 초기에 제공될 수 있다. 클라이언트 애플리케이션(105)은 도 1c에 도시된 디바이스(102a 및 102b) 상의 105a 및 105b에 각각 대응한다.
클라이언트 애플리케이션(105)은 적어도 "지갑" 기능을 포함한다. 이는 2개의 메인 기능성들을 갖는다. 이들 중 하나는, 개개의 당사자(103)가 트랜잭션들(152)을 생성, 인가(예컨대, 서명)하여 하나 이상의 비트코인 노드들(126)에 전송하여, 그런 다음 블록체인 노드들(126)의 네트워크 전반에 걸쳐 전파되고 그리하여 블록체인(150)에 포함되는 것을 가능하게 하는 것이다. 남은 하나는 개개의 당사자에게 자신이 현재 소유하고 있는 디지털 자산의 금액을 다시 보고하는 것이다. 출력-기반 시스템에서, 이 제2 기능성은 블록체인(150) 전반에 걸쳐 흩어져 있는 해당 당사자에 속하는 다양한 트랜잭션들(152)의 출력들에서 정의된 금액들을 대조하는 것을 포함한다.
유의: 다양한 클라이언트 기능이 주어진 클라이언트 애플리케이션(105)에 통합되는 것으로 설명될 수 있지만, 이것은 반드시 제한적인 것은 아니며, 대신에 본원에서 설명된 임의의 클라이언트 기능은 2개 이상의 별개의 애플리케이션들이 한 조로 구현될 수 있는데, 예컨대, API를 통해 인터페이싱하거나 또는 하나가 다른 것에 플러그 인될 수 있다. 더 일반적으로, 클라이언트 기능은 애플리케이션 계층, 또는 운영 시스템과 같은 하위 계층, 또는 이들의 임의의 조합에서 구현될 수 있다. 다음은 클라이언트 애플리케이션(105)의 관점에서 설명될 것이지만, 이것이 제한적이지 않다는 것이 인지될 것이다.
각각의 컴퓨터 장비 상의 클라이언트 애플리케이션 또는 소프트웨어(105)의 인스턴스는 네트워크(132)의 블록체인 노드들(126) 중 적어도 하나에 동작 가능하게 커플링된다. 이는 클라이언트(105)의 지갑 기능이 트랜잭션들(152)을 네트워크(132)로 전송하는 것을 가능하게 한다. 클라이언트(105)는 또한 개개의 당사자(103)가 수신자인 임의의 트랜잭션들에 대해 블록체인(150)에 질의하기 위해(또는 실시예들에서, 블록체인(150)은 그의 공개 가시성을 통해 부분적으로 트랜잭션들의 신뢰를 제공하는 공공 시설(public facility)이므로, 실제로 블록체인(150)에서 다른 당사자들의 트랜잭션을 검사하기 위해) 블록체인 노드들(126)에 접촉할 수 있다. 각각의 컴퓨터 장비 상의 지갑 기능은 트랜잭션 프로토콜에 따라 트랜잭션들(152)을 공식화(formulate) 하고 전송하도록 구성된다. 위에서 제시된 바와 같이, 각각의 블록체인 노드(126)는 블록체인 노드 프로토콜에 따라 트랜잭션(152)을 유효성 검증하고, 그리고 트랜잭션(152)을 블록체인 네트워크(132) 전반에 걸쳐 전파시키기 위해 트랜잭션(152)을 포워딩하도록 구성된 소프트웨어를 실행한다. 트랜잭션 프로토콜 및 노드 프로토콜은 서로 대응하며, 주어진 트랜잭션 프로토콜은 주어진 트랜잭션 모델을 함께 구현하도록 주어진 노드 프로토콜을 따른다. 블록체인(150)의 모든 트랜잭션(152)에 동일한 트랜잭션 프로토콜이 사용된다. 네트워크(132)의 모든 노드들(126)에 의해 동일한 트랜잭션 프로토콜이 사용된다.
주어진 당사자(103), 이를테면, 앨리스가 블록체인(150)에 포함될 새로운 트랜잭션(152j)을 전송하기를 원할 때, 그녀는 (자신의 클라이언트 애플리케이션(105)의 지갑 기능을 사용하여) 관련 트랜잭션 프로토콜에 따라 새로운 트랜잭션을 공식화한다. 그 후, 그녀는 클라이언트 애플리케이션(105)으로부터 그녀가 연결되는 하나 이상의 블록체인 노드들(126)에 트랜잭션(152)을 전송한다. 예컨대, 이는 앨리스의 컴퓨터에 가장 잘 연결된 블록체인 노드(126)일 수 있다. 임의의 주어진 블록체인 노드(126)가 새로운 트랜잭션(152j)을 수신할 때, 주어진 노드는 블록체인 노드 프로토콜 및 각자의 역할에 따라 이를 처리한다. 이는 새롭게 수신된 트랜잭션(152j)이 "유효"하기 위한 특정 조건을 충족시키는지를 먼저 체크하는 것을 포함하며, 그의 예들은 곧 보다 자세히 논의될 것이다. 일부 트랜잭션 프로토콜들에서, 유효성 검증을 위한 조건은 트랜잭션들(152)에 포함된 스크립트들에 의해 트랜잭션 단위로 구성 가능할 수 있다. 대안적으로, 조건은 단순히 노드 프로토콜의 내장 피처이거나, 스크립트 및 노드 프로토콜의 조합으로 정의될 수 있다.
새롭게 수신된 트랜잭션(152j)이 유효한 것으로 간주되기 때문에 테스트를 통과한다는 것을 조건으로(즉, 그것이 "유효성 검증"된다는 조건으로), 트랜잭션(152j)을 수신하는 임의의 블록체인 노드(126)는 새로운 유효성 검증된 트랜잭션(152)을 해당 블록체인 노드(126)에서 유지되는 트랜잭션의 정렬된 세트(154)에 추가할 것이다. 또한, 트랜잭션(152j)을 수신하는 임의의 블록체인 노드(126)는 유효성 검증된 트랜잭션(152)을 네트워크(132)의 하나 이상의 다른 블록체인 노드들(126)로 전방으로 전파시킬 것이다. 각각의 블록체인 노드(126)가 동일한 프로토콜을 적용하기 때문에, 트랜잭션(152j)이 유효하다고 가정하면, 이는 그것이 곧 전체 네트워크(132)에 걸쳐 전파될 것임을 의미한다.
일단 주어진 블록체인 노드(126)에서 유지되는 트랜잭션의 정렬된 세트(154)에 승인되면, 해당 블록체인 노드(126)는 새로운 트랜잭션(152)을 포함하는 그들 개개의 트랜잭션의 정렬된 세트(154)의 최신 버전에 대한 작업 증명 퍼즐을 풀기 위해 경쟁하기 시작할 것이다(다른 블록체인 노드(126)가 트랜잭션의 상이한 정렬된 세트(154)에 기초하여 퍼즐을 풀려고 시도할 수 있지만 먼저 달성한 사람이 최신 블록(151)에 포함된 트랜잭션의 정렬된 세트를 정의할 것임이 상기됨). 결국, 블록체인 노드(126)는 앨리스의 트랜잭션(152j)을 포함하는 정렬된 세트(154)의 일부에 대한 퍼즐을 풀 것이다. 새로운 트랜잭션(152j)을 포함하는 정렬된 세트(154)에 대한 작업 증명이 완료되면, 이는 변경 불가능하게 블록체인(150)의 블록들(151) 중 하나의 부분이 된다. 각각의 트랜잭션(152)은 이전의 트랜잭션에 대한 역 포인터를 포함하여서, 트랜잭션들의 순서가 또한 변경 불가능하게 기록된다.
상이한 블록체인 노드들(126)은 우선 주어진 트랜잭션의 상이한 인스턴스들을 수신하고, 따라서 하나의 인스턴스가 새로운 블록(151)에 공개되기 전에 어떤 인스턴스가 유효한지에 대한 충돌하는 뷰들을 가질 수 있고, 이 지점에서 모든 블록체인 노드들(126)은 공개된 인스턴스가 유일한 유효 인스턴스라고 동의한다. 블록체인 노드(126)가 하나의 인스턴스를 유효한 것으로 수락하고, 그 후 제2 인스턴스가 블록체인(150)에 기록되었다는 것을 발견하면, 해당 블록체인 노드(126)는 이것을 수락해야 하고, 자신이 초기에 수락한 인스턴스(즉, 블록(151)에 공개되지 않은 것)를 폐기(즉, 무효한 것으로 처리)할 것이다.
일부 블록체인 네트워크들에 의해 운영되는 대안적인 유형의 트랜잭션 프로토콜은 계정-기반 트랜잭션 모델의 일부로서 "계정-기반" 프로토콜로서 지칭될 수 있다. 계정-기반의 경우에, 각각의 트랜잭션은 과거 트랜잭션들의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하기 보다는, 절대 계정 잔액을 참조함으로써 전달될 금액을 정의한다. 모든 계정들의 현재 상태는 블록체인과 별개로 해당 네트워크의 노드들에 의해 저장되며 지속적으로 업데이트된다. 이러한 시스템에서, 트랜잭션들은 (또한 "포지션"이라 불리는) 계정의 실행 중인 트랜잭션 총계를 사용하여 정렬된다. 이 값은 그의 암호화 서명의 일부로 발신인에 의해 서명되고 트랜잭션 참조 계산의 부분으로서 해싱된다. 게다가, 선택적 데이터 필드가 또한 트랜잭션에 서명할 수 있다. 이 데이터 필드는 예컨대, 이전의 트랜잭션 ID가 데이터 필드에 포함된 경우 이전의 트랜잭션을 뒤로 가리킬 수 있다.
블록체인(112)에 레코딩된 트랜잭션은, 지출되거나 지출되지 않고 잠금 스크립트에 의해 보호되는 가치의 이전을 모델링한다. 트랜잭션은 자신의 입력을 통한 값을 지출하고, 자신의 출력을 통해 값을 지불한다. 트랜잭션에 입력된 값은 이전의 트랜잭션에 의해 출력된 값과 동일하거나 초과해야 하며, 임의의 잉여 입력은 트랜잭션 수수료로서 징수된다. 잠금 스크립트에 제공된 해결책, 즉, 즉, 잠금해제 스크립트가 잘못된 경우; 트랜잭션이 입력으로 받은 값보다 더 많은 값을 출력하는 경우; 트랜잭션이 이미 지출된 출력을 지출하거나 트랜잭션이 전혀 존재하지 않는 값을 지출하려고 시도하는 경우, 트랜잭션은 무효하다.
잠금 스크립트와 잠금해제 스크립트 둘 모두는 기계 판독 가능 스크립팅 언어로 표현되어, 임의의 데이터를 (증명 가능하게 지출 불가능한 출력 형태로) 데이터 캐리어 출력으로서 임베딩할 수 있는 스크립트를 포함하여, 매우 다양한 스크립트 지출 조건을 허용한다.
도 1a의 지불 프로세싱 자원(106)은 블록체인(112)과 상호작용하도록 구성된다. 지불 프로세싱 자원은 블록체인 트랜잭션을 리트리브하고, 블록체인 트랜잭션으로부터 이전에 미지출된 출력(UTXO)을 지출하기 위한 잠금해제 스크립트를 제공하도록 구성된다. 미지출 트랜잭션은 DHT(distributed hash table)에 저장될 수 있다. 지불 프로세싱 자원(106)은 이전에 미지출된 출력을 사용하여 블록체인 트랜잭션을 생성하고, 이러한 트랜잭션에 대한 입력으로서 자신의 펀드를 제공하도록 구성된다. 지불 프로세싱 자원(106)은, 출력의 존재에 대해 임시/보조 멤풀 또는 DHT를 체크함으로써, 트랜잭션에 의해 지출되는 출력이 이미 지출된 출력이 아니라는 것, 즉, 출력이 미지출 출력이고 이중 지출이 아니라는 것을 체크하도록 구성된다. 그런 다음 지불 프로세싱 자원(106)은 블록체인 트랜잭션을 블록체인(112)으로 전송하고, 트랜잭션이 수신되었을 때 블록체인(112)으로부터 통지를 수신하도록 추가로 구성된다. 트랜잭션이 블록체인(112)에 의해 수신되었다는 통지를 수신할 때, 지불 프로세싱 자원(106)은 트랜잭션에 대한 식별자를 생성하도록 구성된다. 식별자는 영숫자일 수 있다. 지불 프로세싱 자원(106)은, 그가 생성하는 블록체인 트랜잭션에 증명 가능하게 지출 불가능한 출력을 추가하고, 지불 프로세싱 자원(106)에 의해 제공되는 데이터의 해시를 포함하는 데이터 캐리어를 첨부하기 위해 이들을 사용하도록 구성된다.
지불 프로세싱 자원(106)에 의한 식별자의 생성 시에, 지불 프로세싱 자원(106)은 데이터가 이벤트 스트림에 레코딩되는 것을 요청하도록 구성된다(아래에 추가로 설명될 것임).
지불 프로세싱 자원(106)은 지불 프로세싱 자원(106)의 사용자가 사용하는 계정에 관한 정보를 저장하도록 구성된다. 지불 프로세싱 자원(106)은 이들 계정과 관련된 정보를 생성, 삭제 및 관리하기 위해 데이터베이스 관리 시스템(DBMS)(140)을 이용할 수 있다. DBMS(140)는 지불 프로세싱 자원(106)에 대해 로컬적으로 또는 원격에 위치될 수 있고, 지불 프로세싱 자원(106)은 임의의 적절한 원격 통신 매체를 사용하여 DBMS(140)에 액세스할 수 있다.
도 1a의 지불 프로세싱 자원(106)은 키 저장 모듈(122) 및 지불 데이터 저장소(124)와 상호작용하도록 구성된다. 키 저장 모듈(122)은, 트랜잭션이 발생할 수 있도록 지불 프로세싱 자원(106)을 사용하는 당사자의 계정에 대응하는 암호 키를 저장하도록 구성된다. 키 저장 모듈(122)은 임의의 적절한 저장소를 이용할 수 있고, 키 저장 모듈(122)에 암호 키를 저장하는 당사자들의 데이터베이스 내부의 레코드로부터 데이터를 초기화, 저장 및 리트리브하기 위해 데이터베이스 관리 시스템(DBMS)을 이용할 것이다. 지불 데이터 저장소(124)는 지불 프로세싱 자원(106)을 사용하여 구현되는 임의의 지불과 관련된 데이터를 저장하도록 구성된다.
제1 컴퓨팅 디바이스(102) 또는 제2 컴퓨팅 디바이스(126) 중 어느 하나의 사용자는 지불 프로세싱 자원(106)으로 계정을 설정할 수 있다. 이러한 계정의 설정은 이제 도 2를 참조하여 설명된다.
앨리스는 단계(S200)에서 지불 프로세싱 자원(106)에 대한 액세스를 요청하는 입력을 제공함으로써 설정 프로세스를 초기화한다. 제1 컴퓨팅 디바이스(102)는 단계(S202)에서 API(108)에 액세스하고, 지불 프로세싱 자원(106)과의 상호작용이 발생하는 것을 가능하게 하기 위한 인증 데이터를 API(108)에 제공한다. 인증 데이터는 제1 컴퓨팅 디바이스(102)의 사용자를 고유하게 식별할 수 있는 임의의 데이터를 포함할 수 있다. 예는 패스워드, 이름과 출생 데이터의 조합 또는 사용자를 고유하게 식별할 수 있는 임의의 다른 데이터 항목일 것이다. 인증 데이터 승인 시에, 지불 프로세싱 자원(106)은 단계(S204)에서 지불 프로세싱 자원(106)에 대한 계정을 설정하는 데 필요한 정보에 대한 요청을 전송한다.
지불 프로세싱 자원(106)이 계정을 설정하는 데 필요한 정보는 계정을 관리하기 위한 부기 기관(bookkeeping authority)의 역할을 하는 자산 레지스트리의 아이덴티티, 즉 은행 계정을 제공하는 은행, 예컨대 HSBC, 사용자를 식별하는 정보, 예컨대, 사용자를 위한 암호 공개 키, 발행자의 약관의 서명된 버전에 대응하는 데이터, 사용자가 사용하고자 하는 화폐의 식별, 예컨대, GBP(파운드 스털링), 발행자에 대한 암호화 공개 키 및 계정에 대한 최소 값을 설정하는 최소 잔액 값이다. 각각의 자산 레지스트리는 자산 레지스트리에 의해 관리되는 모든 계정과 연관된 대응하는 자산의 적어도 하나의 발행자와 연관된다. 예컨대, 은행은 GBP 및 EUR의 발행자와 연관된다. 은행은 또한 금 및 다른 귀금속과 같은 다른 자산의 발행자와 연관될 수 있다. 금의 발행자의 예는 영국의 왕립 조폐국일 수 있다. 정보는 지불 프로세싱 자원(106)에 의해 DBMS(140)의 레코드에 저장된다.
그런 다음 앨리스는 요구된 정보를 제공한다. 정보는 단계(S206)에서 API(108)를 통해 지불 프로세싱 자원(106)에 전송된다. 세부사항의 수신 시에, 지불 프로세싱 자원(106)은 단계(S208)에서 자산 레지스트리 데이터베이스에 레코드를 생성하고, 단계(S210)에서 제공된 세부사항으로 레코드를 파퓰레이팅한다.
그런 다음 지불 프로세싱 자원(106)은, 단계(S212)에서, 이벤트 스트림이 아직 초기화되지 않은 이벤트에서, 앨리스의 계정에 대응하는 이벤트 스트림(110a)을 영국 특허 출원 제2102314.8호에 따라 초기화한다. 대안적으로 또는 부가적으로, 지불 프로세싱 자원(106)은 이미 앨리스에 대한 이벤트 스트림(110a)을 저장했을 수 있다.
그런 다음 지불 프로세싱 자원(106)은 단계(S214)에서 컨펌 메시지를 제1 컴퓨팅 디바이스(102)로 전송하여 계정이 앨리스를 위해 설정되었음을 컨펌한다. 단계(S200 내지 S214)는 또한 지불 프로세싱 자원(106)(HSBC와 같은 은행과 연관됨)에 계정을 설정하기 위해 밥에 의해 사용될 것이다. 이벤트 스트림(110b)은 또한 밥의 계정에 대응하여 초기화될 것이다.
이벤트 스트림은 블록체인 기반 첨부 전용 로그이다. 앨리스 또는 밥과 같은 지불 프로세싱 자원(106)의 사용자는 그들의 계정에 대응하는 이벤트 스트림을 생성, 이에 첨부 및 종료할 수 있다. 이들은 나중에 설명될 것이다.
대안적으로, 앨리스 또는 밥은, 그들이 이미 사용하고 있는 자산 레지스트리와 연관된 계정의 세부사항을 제공하고, 그들이 필요한 모든 정보를 제공한 경우 단계(S200 내지 S214)를 피할 수 있다.
레코드를 위한 지불 데이터의 준비
우리는 이제 지불 프로세싱 자원(106)에 의해 자산 이전이 가능해지는 복수의 예시적인 시나리오를 설명한다. 이러한 예는, 각각의 예의 특징이 다른 예로부터의 특징과 결합될 수 있다는 점에서 예시적이고 비제한적인 것으로 의도된다.
우리는 이제, 도 3a 및 도 3b를 참조하여 앨리스가 지불 프로세싱 자원(106)을 사용하여 밥에게 5 GBP를 보내는 예시적인 시나리오를 설명한다. 이 예에서, 이전되는 자산은 현금이고, 자산 레지스트리는 은행이다.
단계(S300)에서, 앨리스는 밥에게 연락하여 그의 다가오는 생일을 위해 그에게 5 GBP를 보내고 싶다는 그녀의 의사를 그에게 알린다. 단계(S302)에서, 밥은 그녀의 관대함에 대해 그녀에게 감사하기 위해 임의의 적합한 매체를 사용하여 앨리스에게 메시지를 전송한다.
그런 다음 앨리스는 제1 컴퓨팅 디바이스(102)를 사용하여 지불 프로세싱 자원(106)에 5 GBP를 지불하고자 하는 그녀의 욕구를 표시한다. 제1 컴퓨팅 디바이스(102)는 API(108)에 액세스하여 단계(S200 내지 S214)에 따라 앨리스에 의해 생성된 계정을 사용하여 지불 프로세스를 개시한다. 이것은 단계(S306)이다. 디바이스(102)로부터 API(108)로의 호출은 앨리스가 밥에게 지불하고자 하는 금액을 나타낸다. 디바이스(102)로부터의 호출은 또한 앨리스가 지불하기를 원하는 계정 및 앨리스가 지불하기를 원하는 화폐 및 그녀가 지불하기 원하는 사람, 즉, 밥을 나타낸다. 앨리스가 밥에게 지불하고자 하는 금액, 밥의 식별, 앨리스가 지불하고자 하는 계정의 식별(즉, GBP)은 단계(S308)에서 지불 프로세싱 자원(106)에 전송되는 지불 메타데이터의 세트를 형성한다.
그런 다음, 지불 프로세싱 자원(106)은, 앨리스로부터 지불 메타데이터를 수신하면, 단계(S308)에서 앨리스가 제공한 메타데이터에 기초하여 밥의 계정으로부터 메타데이터를 리트리브한다. 이것은 단계(S310)이다. 지불 프로세싱 자원(106)은 밥의 계정이 관련된 화폐, 즉, 파운드 스털링(GBP) 및 은행을 밥의 계정으로부터 리트리브한다.
그런 다음 지불 프로세싱 자원(106)은, 단계(S312)에서, 앨리스로부터 수신된 지불 메타데이터 및 밥의 계정으로부터 리트리브된 정보를 사용하여 지불 명령 데이터세트를 생성한다.
이 예에서, 밥의 은행 계정의 제공자는 "hsbc.com"이고, 화폐는 GBP로서 식별되고, 지불 값(즉, 밥이 받을 금액)은 5 GBP이고, 계정의 식별은 <Bob:HSBC>으로 제공되고, 사용자는 "kyc" 값에 의해 밥으로서 식별되며, 행위자는 지불의 수취인, 즉 지불을 받는 개인으로 식별된다. 이것은 지불 명령 데이터세트의 일부를 형성한다. 지불 명령 데이터세트는 또한 서명<Bob_sig>을 사용하여 밥이 서명한 약관의 버전을 선택적으로 포함할 수 있다.
지불 명령 데이터세트의 또 다른 부분은 앨리스의 세부사항에 의해 형성된다. 즉, 계정의 제공자는 "hsbc.com"이고, 화폐는 GBP로 식별되며, 밥에게 이전되는 지불 값은 5 GBP이고(즉, 앨리스로부터 밥에게 지불할 5 GBP의 인출액, 그래서 이는 지불 명령 데이터세트에서 -5로 표현됨), 계정의 식별은 <Alice:HSBC>로 제공되고, 사용자는 "kyc" 값에 의해 앨리스로 식별된다. 지불 명령 데이터세트는, URL(uniform resource locator)에 의해 제공되어 액세스될 수 있는 문서에 포함될 수 있는 앨리스가 서명한 약관을 또한 포함할 수 있다. 지불 명령 데이터세트는 또한 행위자를 지불의 발송자, 즉 지불을 하는 개인으로 식별한다.
그런 다음 단계(S314)에서 지불 명령 데이터세트에 대한 앨리스의 서명에 대한 요청과 함께 메시지가 제1 컴퓨팅 디바이스(102)에 전송된다. 그런 다음 앨리스는 밥에게 5 GBP의 지불을 승인하기 위해 단계(S316)에서 그녀의 암호 서명을 제공한다. 그런 다음 앨리스의 서명은 지불 처리 모델(132)에 의해 지불 명령 데이터세트에 적용된다. 다시 말해서, 앨리스는 그녀의 암호 서명으로 지불 명령 데이터세트에 서명한다. 요컨대, 앨리스의 계정에서 인출되고, 밥의 계정에 입금된다. 따라서, 앨리스의 서명이 필요하다. 밥의 서명은, 그가 t&c 링크(즉, 그가 서명한 약관 문서에 대한 URL) 및 약관이 포함된 문서의 해시를 제공한 경우에만 필요할 수 있다. 이것은, 앨리스가 이전된 펀드에 대한 대가로 밥에게서 무언가를 구입하는 이벤트에서, 밥이 지불에 대한 대가로 약관을 제공한 것으로 증명 가능하게 보여질 수 있다는 것을 의미한다.
이 예에서는, 은행이 동일하고 금액이 맞아떨어질 때, 하나의 서명만이 필요하다. 밥이 위에서 제시된 바와 같이 t&c 링크를 제공한 경우, 2개의 서명이 필요할 수 있다.
지불 프로세싱 자원(306)은 그런 다음 단계(S318)에서 지불 명령 데이터세트에 지불 프로토콜 기준을 적용한다. 지불 프로세싱 자원(306)은 단계(S320)에서 지불 프로토콜 모듈(120)에 액세스한다.
지불 프로토콜 모듈(120)은 먼저, 금액이 일관되고, 즉, 앨리스의 계정에서 인출된 금액이 밥의 계정으로 지불된 금액과 동일하다는 점에서, 지불 명령 데이터세트가 제로섬 규칙을 준수한다고 체크한다. 이것은 단계(S322)이다. 5 GBP가 앨리스의 계정에서 인출되고 5 GBP가 밥의 계정에 지불되고, 즉, 금액이 동일하고 은행이 동일하기 때문에, 제로섬 규칙이 준수된다. 다시 말해서, 앨리스의 계정에 -5 GBP가 추가되고 밥의 계정에 +5 GBP가 추가되기 때문에, 개개의 금액 합계는 0이다. 은행이 동일하므로, 이 단계가 충족되고 데이터세트는 제로섬 규칙을 준수한다.
그런 다음 지불 프로토콜 모듈(120)은 앨리스로부터 밥으로 이전되는 금액이 앨리스의 잔고를 일정 최소값 아래로 떨어뜨리지 않게 한다는 것을 체크한다. 이것은 단계(S324)이다. 다시 말해서, 앨리스가 너무 많이 지출하는가? 앨리스가 너무 많이 지출하는 경우, 즉 그녀의 잔액(5 GBP를 뺀 금액)이 최소값 아래로 떨어지면, 지불 프로토콜 모듈(120)은 앨리스에게 에러 메시지를 발행하여 그녀가 지출하고자 하는 금액을 지출할 수 없음을, 즉 그녀가 밥에게 5 GBP를 지불할 펀드가 없음을 그녀에게 알릴 것이다. 실제로, 신용 대출(credit facility)을 사용하는 경우, 최소값이 음수가 될 수 있다. 지불 프로토콜 모듈(120)은, 다시 시작하라는 명령이 주어질 때까지, 즉, 앨리스가 그녀의 은행 계정에 더 많은 펀드를 예금하였거나 그녀의 최소 잔액이 변경되었을 때 단계(S320)로 복귀할 것이다.
그런 다음 지불 프로토콜 모듈(120)은, 자산의 식별에 대응하는 데이터에 걸쳐 필드를 체크함으로써 트랜잭션에 대한 두 당사자 간에 지불과 관련된 데이터가 일관되는지 여부를 체크한다. 이것은 단계(S326)이다. 이 예에서, 제로섬 규칙이 충족되고 은행이 동일하고, 즉, "hsbc.com"이고 화폐가 동일하므로, 데이터가 일관된다. 다시 말해서, 은행 및 자산 식별이 균형을 이룬다. 아래 추가 예에서 볼 수 있듯이, 은행과 자산 식별이 균형에 맞지 않을 때, 요구된 균형을 제공하기 위해 추가 메타데이터가 생성되어야 한다.
이를 설명하는 또 다른 방법은 은행 및 자산 식별을 나타내는 템플릿(XXX_BBBB:AAAA)을 사용할 수 있는데, 여기서 XXX는 계정의 운영자이고, BBBB는 은행 식별이고, AAAA는 자산 식별이다. 우리는 이 템플릿을 사용하여, 5 GBP가 Alice_HSBC:GBP로부터 Bob_HSBC:GBP로 지불됨을 설명할 수 있고, 여기서 은행과 자산 식별이 균형을 이루는 것을 볼 수 있다.
지불 프로세싱 모듈(120)은 앨리스와 밥의 암호 서명이 유효성 검증되는 단계(S328)로 이동한다. 지불 프로세싱 모듈(120)은, 각각의 서명에 대한 해시를 생성하고 단계(S200 내지 S214)에서 생성된 레코드에 저장된 것과 해시를 비교함으로써 앨리스와 밥의 암호 서명을 유효성 검증한다. 이것은 또한 앨리스와 밥의 아이덴티티를 컨펌한다. 대안적으로 또는 추가적으로, 암호 비밀/공개 키 쌍에 기초하는 표준 PKI 기술을 또한 사용하여 각각의 서명을 유효성 검증할 수 있다. 이러한 기술은 또한 클라이언트의 아이덴티티를 검증하는 데 사용될 수 있다.
단계(S322, S324, S326 및 S328)의 충족은, 지불 프로토콜에 의해 규정된 기준이 충족되었음을 의미하고 따라서 지불 프로세싱 자원(106)은 지불 명령 데이터세트에 따라 앨리스로부터 밥에게 5 GBP의 지불이 이루어지도록 허용한다.
그런 다음 지불 프로세싱 자원(106)은 단계(S330)에서 앨리스와 밥 각각에 대해 블록체인(112)으로부터 블록체인 트랜잭션을 리트리브한다. 이것은 도 3c의 예시적인 개략도를 참조하여 설명한다.
앨리스에 대한 블록체인 트랜잭션(402)은 더스트 출력(Tx0, 앨리스)을 포함하고, 밥에 대한 블록체인 트랜잭션(404)은 더스트 출력(Tx0, 밥)을 포함한다.
랑데뷰 트랜잭션의 생성
그런 다음 지불 프로세싱 자원(106)은, 단계(S330)에서 리트리브된 블록체인 트랜잭션으로부터 개개의 더스트 출력을 지출하는 앨리스 및 밥 각각에 대한 더스트 입력을 포함하는 새로운 랑데뷰 블록체인 트랜잭션(406)을 생성한다. 더스트 출력은 앨리스 및 밥과 연관된 이벤트 스트림에 대응하는 더스트 체인으로부터 리트리브될 수 있다. 이것은 또한 도 3c에 도시된다. 402와 404 사이의 406으로의 트랜잭션의 체인은 더스트 트랜잭션 체인으로서 설명될 수 있다. 더스트 입력/출력은 암호화폐 분야에서 "더스트"인 것으로 표시되는 암호화폐의 금액에 대한 입력/출력이다. 본 개시에 대한 블록체인 트랜잭션의 맥락에서 "더스트"는 낮거나 미미한 값의 출력을 갖는 디지털 자산 또는 암호화폐에 대한 지출 가능한 트랜잭션인 것으로 이해되고, 즉, 그 값은 블록체인에서 출력을 채굴하기 위한 비용보다 훨씬 낮을 수 있다.
대안적으로, 지불 프로세싱 자원(106)은, 영국 특허 출원 제2102217.3호에 설명된 바와 같이, 기존 이벤트 스트림의 일부를 형성하지 않는 더스트와 계층적 결정론적(HD) 키 체인의 조합을 사용하여 새로운 더스트 트랜잭션을 생성할 수 있다. 다시 말해서, 더스트를 입력으로서 사용하고 앨리스와 밥 각각에 대응하는 입력을 포함하는 더스트 트랜잭션이 생성되며, 해당 더스트는 이벤트 스트림에서 이전에 사용되지 않았다. HD 키 체인을 소유한 당사자는 서브-키 중 하나 및 더스트를 사용하여 새로운 이벤트 스트림에서 제1 트랜잭션을 생성할 수 있다. 요컨대, 새로운 이벤트 스트림은, 블록체인(112) 상의 기존 트랜잭션으로부터 리트리브되고 새로운 이벤트 스트림의 시작을 위한 베이스로서 사용될 수 있는 더스트에 기초하여 개시될 수 있다. 다시 말해서, 더스트는 (새로운 이벤트 스트림을 시작하기 위해) 트랜잭션을 생성하는 데 사용될 수 있으며, 그런 다음 다른 이벤트 스트림의 개시에 사용되기 전에 플랫폼으로 반환될 수 있다.
더스트 트랜잭션의 체인과 이벤트 스트림 사이의 관계는 이제 도 3d를 참조하여 추가로 자세히 설명된다.
도 3d는 본 개시의 제1 양상에 관한 것이며, 정렬된 첨부-전용 데이터 저장 시스템의 기본 데이터 구조 및 패러다임을 예시한다. 이것은 또한 데이터 로깅 시스템으로서 설명될 수 있다. 도 3d에 도시된 특정 시스템은 이벤트를 로깅하기 위한 이벤트 스트림 시스템이다. 예로서, 이벤트 스트림은 전반에 걸쳐 예시 목적으로 사용되지만, 당업자는, 본원에 설명된 제안된 시스템 및 양상이 일반적으로 데이터 항목 및 정렬된 첨부-전용 데이터 항목 로깅 또는 저장 시스템과 함께 사용될 수 있음을 인지할 것이다. 도 4 및 6과 일치하여, 데이터 항목은 실제 데이터의 해시를 나타낸다. 데이터 자체 대신에 해시의 사용은, 데이터(크고, 심지어 트랜잭션에 대해 너무 클 수 있음)를 트랜잭션에 저장할 필요 없이, 데이터에 대한 존재 증명을 유리하게 제공한다. 이것은 또한, 해시가 온 체인으로 공개될지라도 데이터가 해시로부터 구별 불가능할 것이기 때문에, 데이터의 프라이버시를 보존한다. 본원에 설명된 데이터는, 지불 프로세싱 자원(106)에 의해 레코딩되는 지불에 관련된 지불 명령 데이터이다.
첨부-전용 로그의 각각의 이벤트(502)는 블록체인 트랜잭션(504)에 매핑되고, 블록체인 트랜잭션의 시퀀스는 '더스트의 체인'을 사용하여 정렬되고 링크된다(506). 각각의 이벤트와 연관된 데이터는 각각의 트랜잭션의 일부로서 페이로드(아래에 설명됨)에 저장된다. 데이터 페이로드(즉, 지불 명령 메타데이터의 해시)는 트랜잭션의 지출 불가능한 OP_RETURN 출력에서 보유되고, 이러한 트랜잭션의 예는 앞서 설명된 바와 같이 랑데뷰 트랜잭션(406)이다. 이것은, 블록체인에 임의의 데이터를 기록하고 트랜잭션 출력을 무효한 것으로 표시하는 데 사용될 수 있는 스크립트 작업코드이다. 다른 예로서, OP_RETURN은 트랜잭션 내에 메타데이터와 같은 데이터를 저장하고 그리하여 메타데이터를 블록체인에 변경 불가능하게 기록할 수 있는 트랜잭션의 지출 불가능한 출력을 생성하기 위한 스크립트 언어의 작업코드이다.
더스트의 체인은 암호화폐 입력 및 출력의 끊어지지 않은 체인이며, 이는 본원에서 시퀀스에서 각각의 블록체인 트랜잭션의 그의 바로 이전 블록체인 트랜잭션에 대한 지출 종속성을 부과하는 데 사용된다.
트랜잭션에서 더스트 출력을 사용하는 것은 모든 트랜잭션의 변경 불가능한 순차적 레코드를 유지하는 데 유리하고 중요한데, 왜냐하면 그들이 이벤트 스트림과 같이 정렬된 첨부 전용 데이터 저장 시스템에서 발생하기 때문이다. 이는, 트랜잭션을 블록체인에 포스팅(post)함으로써 모든 블록체인 트랜잭션이 타임스탬핑되고, 일단 모든 블록체인 트랜잭션이 블록체인 상에서 컨펌되거나 블록체인에 추가되면 특정 순서로 유지될지라도, 이것이 그들의 순차적 순서의 보존을 보장하지는 않기 때문이다. 이는, 트랜잭션이 상이한 시간에 블록으로 채굴될 수 있고 그리고/또는 트랜잭션이 동일한 블록 내에서조차 순서가 상이하기 때문이다. 시퀀스에서 다음 트랜잭션의 제1 입력에 의해 지출되는 더스트 출력을 사용하는 것은, 트랜잭션 순서가 시간순으로 추적되고 이벤트 자체와 이벤트의 순차적 순서 둘 모두에 대한 변조 방지 레코드가 생성되는 것을 유리하게 보장한다. 이것은, 일단 블록으로 채굴되면, 시퀀스에서 이전의 트랜잭션으로부터 다음 트랜잭션으로의 더스트의 지불이, 비트코인 프로토콜 규칙에 따라, 페이로드로 불리고 아래에서 논의되는 임베딩된 데이터 캐리어 요소의 시퀀스가 재정렬될 수 없고, 이벤트 스트림이 손상되었다는 것이 즉시 명백해지지 않고는 이를 변경할 수 있는 어떠한 삽입 또는 삭제도 발생할 수 없다는 것을 보장하기 때문이다. 일부 실시예에서, 비트코인 프로토콜에 고유한 이중 지출 방지 메커니즘은, 상이한 트랜잭션 입력과 출력 사이의 암호화폐(예컨대 더스트)의 이동이 시간 순서로 유지되는 것을 보장한다. 더스트 트랜잭션의 체인은 토폴로지 순서를 활용하여, 블록 간 및 내 트랜잭션(그리고 따라서 연관된 이벤트 및 데이터) 순서 보존을 제공한다. 따라서, 이것은 순서화된 첨부 전용 데이터 항목 저장의 무결성을 개선한다.
이러한 방식으로, 블록체인 트랜잭션(504)은 트랜잭션의 방향성 그래프를 형성한다. 그래프의 방향은, 에지(506)로 표시된 바와 같이, 시퀀스에서 이전의 트랜잭션에서 다음 트랜잭션으로 향하는 단방향으로 간주될 수 있음이 유의되어야 한다. 도 3d의 에지(506) 상의 화살표가 다음 트랜잭션을 가리키는 트랜잭션을 나타내지만, 비트코인 트랜잭션의 지출 관계는 실제로 하나의 트랜잭션으로부터 이전의 트랜잭션으로 이어진다. 이 그래프는 트랜잭션 간의 지출 관계에 의해 생성된다. 이러한 지출 관계는 일종의 참조로서 간주될 수 있다. 이벤트를 이벤트 스트림에 추가하는 방법에 관한 추가 세부사항들은 영국 특허 출원 제2102314.8호에서 찾을 수 있으며 특히 비배타적으로, 여기서 이는 "정렬된, 첨부 전용 데이터 저장소(Ordered, Append-only data Storage)", "이벤트 스트림 및 더스트의 체인(Event Stream and the Chain of Dust)" 및 "더스트의 체인에서 백워드 참조(Backward Referencing in the Chain of Dust)"를 나타낸다.
도 3c에 도시된 트랜잭션(406)과 같은 랑데뷰 블록체인 트랜잭션은, 위에서 언급한 주어진 엔티티/사용자와 각각 연관된 복수의 이벤트 스트림을 동기화하기 위한 블록체인 트랜잭션이다. 이것은 대응하는 입력으로서 다수의 더스트 출력을 지출함으로써 달성된다. 이 예에서는, 이것은 앨리스, 밥 및 HSBC 각각에 대응하는 더스트의 체인(즉, 더스트 입력/출력 쌍)이 단일 트랜잭션을 통과하는 것을 허용한다. 더스트 체인 입력/출력 쌍은 트랜잭션에서 대응하는 입력/출력 인덱스를 가져야 한다. 이러한 예시에서, 아래에서 읽을 수 있듯이 트랜잭션과 연관된 모든 이벤트 스트림에 지불을 레코딩할 수 있도록 하는 더스트 체인 입력/출력 쌍이 사용된다.
앨리스에 대한 더스트 출력을 지출하는 더스트 입력은 Tx1, 앨리스로 표시되고, 밥에 대한 더스트 출력을 지출하는 더스트 입력은 Tx1, 밥으로 표시된다. 새로운 랑데뷰 블록체인 트랜잭션(406)이 단계(S332)에서 생성된다.
랑데뷰 블록체인 트랜잭션(406)으로의 펀드는 지불 프로세싱 자원(106)에 의해 추가되고, 지불 프로세싱 자원(106)에 다시 지불될 것이다. 이것은, 유효성 검증을 위해 블록체인(112)으로 전송되는 경우, 랑데뷰 블록체인 트랜잭션(406)의 유효성 검증에 따른 임의의 채굴자 수수료를 뺀 것일 수 있다.
랑데뷰 블록체인 트랜잭션(406)은, Tx1, 앨리스 및 Tx1, 밥을 각각 지출하는 추가 더스트 출력을 포함한다. 이것이 랑데뷰 트랜잭션이므로, 앨리스와 밥에 각각 대응하는 입력/출력 쌍의 인덱스는, 예컨대 Tx1, 앨리스의 입력 인덱스가 숫자 1로서 할당될 수 있고 대응하는 더스트 출력의 출력 인덱스가 출력 인덱스 숫자 1로서 할당될 수 있다는 점에서 동일하다.
지불 프로세싱 자원(106)은 또한 데이터 캐리어(412a 및 412b)의 형태로 앨리스 및 밥 각각에 대한 블록체인 트랜잭션(406)에 증명 가능하게 지출 불가능한 출력을 추가한다.
각각의 데이터 캐리어는 별개의 dataDigest 및/또는 별개의 streamDigest를 보유할 수 있으며, streamDigest는 또한 솔팅될 수 있다.
개개의 데이터 캐리어 내부에 보유된 데이터 페이로드(즉, 지불 명령 메타데이터의 해시)는 트랜잭션의 지출 불가능한 OP_RETURN 출력에 보유되며, 이는 데이터 페이로드가 지출 불가능한 출력으로서 블록체인에 저장될 수 있음을 의미한다. 이것은, 캐리어 내부에 보유된 데이터 페이로드(즉, 지불 명령 메타데이터의 해시)가 트랜잭션의 지출 불가능한 OP_RETURN 출력에 보유된다는 것을 의미하고, 이는 데이터 페이로드가 지출 불가능한 출력으로서 블록체인에 저장될 수 있음을 의미한다.
데이터 캐리어(412) 내부의 데이터는 단계(S300 내지 S328)에서 지불 프로세싱 자원에 의해 생성된 지불 명령 데이터세트의 해시를 포함한다. 이것은 단계(S334)에서 생성된다. 증명 가능하게 지출 불가능한 출력은 랑데뷰 트랜잭션(406)이 트랜잭션에서 지불 명령 데이터세트의 해시를 전달하는 것을 가능하게 하고, 해시가 블록체인에 저장되는 것을 가능하게 한다. 이것은, 지불 명령 데이터세트 및 따라서 지불의 레코드가 블록체인 상에 저장됨을 의미한다. 이것은, 지불의 레코드가 블록체인의 불변성으로부터 이익을 얻는다는 것을 의미한다.
그런 다음, 블록체인 트랜잭션(406)은, 트랜잭션에 대응하는 사용자가 정확하고 사용자, 즉, 앨리스와 밥에 대응하는지를 확인하기 위해 체크될 수 있다. 이것은 단계(S336)이다.
지불 프로세싱 자원(106)은, 단계(S338)에서 블록체인 트랜잭션(406)이 이벤트 스트림, 즉 앨리스와 밥에 관한 이벤트 스트림에 데이터를 추가하기 위한 기반으로서 사용될 수 있다는 것을 컨펌하는 통지를 이벤트 스트림 자원(110)에 발행한다.
이벤트 스트림은 블록체인 지원 첨부 전용 로그이다. 이 예에서, 앨리스와 밥은 각각 그 자신의 이벤트 스트림을 가지고 있지만, 그들이 그렇지 않은 경우, 이벤트 스트림이 초기화될 수 있다. 다시 말해서, 앨리스는 이벤트 스트림(E-Alice)을 갖고, 밥은 이벤트 스트림(E-Bob)을 갖는다. 이벤트 스트림의 엔트리는 ESn으로 표시될 수 있으며, 여기서 n은 0이 아닌 양의 정수 또는 음이 아닌 정수일 수 있다.
도 3d에 도시된 바와 같이, 이벤트 스트림은 일련의 엔트리로 예시될 수 있고, 여기서 스트림의 임의의 엔트리는 단조적으로 증가하는 시퀀스 번호로 참조될 수 있고, 즉, 제1 엔트리는 ES1로 참조될 수 있고, 제2 엔트리는 ES2로 참조될 수 있다.
지불 프로세싱 자원(106)은, 앨리스와 밥이 이벤트 스트림에 액세스하거나 이를 첨부하도록 인가되는 경우에만 개개의 이벤트 스트림에 첨부한다. 인가는, 예컨대, 서명과 지불 프로세싱 자원(106)에 저장된 서명을 비교함으로써 체크될 수 있다. 지불 데이터를 이벤트 스트림에 첨부함으로써, 지불이 레코딩될 수 있으며, 블록체인(112)과 연관된 변경 불가능한 로그에 레코딩되는 것으로부터 이점을 얻을 수 있다. 요컨대, 이벤트 스트림은 앨리스 및 밥과 연관된 계정의 트랜잭션의 순서를 추적하는 데 사용된다. 다시 말해서, 이벤트 스트림의 엔트리는 블록체인(112)과 연관된 변경 불가능한 로그이다. 위에서 설명된 바와 같이 이벤트 스트림은 다음을 보장한다.
●
이벤트 스트림의 개별 엔트리가 작성된 이래로, 개별 엔트리는 수정되지 않았다.
●
이전에 연속된 엔트리 사이에 어떠한 엔트리도 삽입되지 않았다.
●
어떠한 엔트리도 제거되지 않았다.
●
어떠한 엔트리도 재정렬되지 않았다.
●
인가되지 않은 당사자는 스트림에 이벤트를 첨부할 수 없다.
지불 프로세싱 자원(106)은 랑데뷰 트랜잭션(406)을 사용하여, 블록체인 트랜잭션(406)의 데이터 캐리어에 포함된 지불 명령 메타데이터의 해시를 포함하는 각각의 이벤트 스트림에 엔트리를 첨부함으로써, 이벤트 스트림 E-Alice 및 E-Bob과 지불을 동기화한다. 이것은 단계(S340)이다. 이것은 도 3e에 개략적으로 도시된다.
그런 다음 지불 프로세싱 자원(106)은 이벤트 스트림 각각에 추가된 엔트리에 대한 식별자를 생성한다. 이것은 단계(S342)이다. 식별자는 영숫자일 수 있거나 이는 지불 명령 메타데이터의 해시에 기초하여 생성된 숫자일 수 있다. 예컨대, 지불 명령 메타데이터의 해시가 SHA256 암호에 의해 생성된 경우, 식별자는 지불 명령 메타데이터의 해시에 추가 SHA256 암호를 적용함으로써 생성될 수 있다. 다시 말해서, 식별자는 지불 명령 메타데이터의 해시의 해시일 수 있다.
그런 다음 지불 프로세싱 자원(106)은 지불 명령 메타데이터의 사본과 함께 식별자를 지불 데이터 저장소(124)에 저장한다. 이것은 요청 시에 앨리스와 밥 간의 지불을 가능하게 한다.
우리는 이제 앨리스가 다시 밥에게 5 GBP의 총액을 지불하지만 밥의 계정이 HSBC가 아닌 Revolut에 의해 제공되는 추가적인 예시적인 시나리오를 설명한다. 이것은 도 4a 및 도 4b를 참조하여 설명된다. 이 예는 도 3a 내지 도 3e를 참조하여 단계(S326)까지 설명한 예와 동일하다. 따라서, 간결함을 위해, 우리는 단계(S326)를 참조하여 설명된 스테이지에서 우리의 설명을 시작할 것이다.
다시 말해서, 단계(S326)에서 긍정적인 결과를 제공하고 트랜잭션이 진행되려면 은행에 잔액이 있어야 한다. 다시 말해서, 은행과 자산 식별 둘 모두가 균형을 이루게 하는 메타데이터가 생성될 필요가 있다.
다시 말해서, 트랜잭션에 대한 두 당사자에 대응하는 데이터에 걸쳐 필드를 체크함으로써, 지불에 관련된 데이터가 두 당사자 사이에서 일관되는지 여부를 지불 프로토콜 모듈(120)에 의해 (단계(S326)에서) 체크한다. 화폐가 동일하고 금액이 서로 상보적이고, 즉, 앨리스가 -5 GBP의 인출액(debit)을 발생시키고 밥은 5 GBP의 예금을 발생시키지만, 계정의 제공자가 별개라는 것, 즉, 앨리스의 계정의 제공자는 "hsbc.com"이고 밥의 계정의 제공자는 "Revolut"이라는 것을 알 수 있다.
이를 설명하는 또 다른 방법은 은행 및 자산 식별을 나타내는 템플릿(XXX_BBBB:AAAA)을 사용할 수 있는데, 여기서 XXX는 계정의 운영자이고, BBBB는 은행 식별이고, AAAA는 자산 식별이다. 이러한 예시에서, Alice_HSBC:GBP로부터 Bob_REVOLUT:GBP로 5 GBP를 이전하려는 시도는 완료될 수 없다.
그런 다음 지불 프로토콜 모듈(120)은 지불 프로토콜 기준에 대한 지불 명령 데이터세트의 체크를 중단한다. 그런 다음 지불 프로세싱 자원(106)은 지불 명령 데이터세트에 추가될 추가 메타데이터를 생성한다.
2개의 상이한 은행에 대한 추가 메타데이터의 생성
지불 프로세싱 자원(106)은 "Revolut.com" 및 "HSBC"에 대응하는 암호 키에 대한 요청으로 키 저장 모듈(122)에 액세스한다. 이것은 단계(S400)이다.
키 저장 모듈(122)은 복수의 암호 키를 저장한다. 각각의 암호화 키는 "Revolut.com" 또는 "HSBC"와 같은 은행에 대응하는 레코드에 저장되며, 지불 프로세싱 자원(106)이 이러한 은행에 의해 관리되는 계정으로의 지불 및 계정으로부터의 지불과 관련하여 그 자신의 지불 명령 데이터를 생성하는 것을 가능하게 한다. 이것은, 당사자들이 자신의 계정에 대해 선택한 은행이 별개일지라도, 지불 프로세싱 자원(106)에 의해 지불이 안전하게 가능해질 수 있음을 의미하기 때문에, 은행이 별개인 계정 간에 지불이 이루어질 때 특히 유리하다.
키 저장 모듈(122)이 액세스될 때, 키 저장 모듈(122)은 요청된 키에 대응하는 은행을 식별하는 입력을 수신한다. 키 저장 모듈(122)은 은행에 대응하는 키를 반환한다. 이 예에서, 은행 "Revolut.com" 및 "HSBC"에 대응하는 키가 반환된다. 이것은 단계(S402)이다.
그런 다음 지불 프로세싱 자원(106)은 2개의 추가 지불을 상세히 설명하는 추가 메타데이터를 포함하도록 지불 명령 데이터세트를 수정한다. 첫 번째 지불이 앨리스의 HSBC 계정으로부터의 지불이지만 앨리스가 이미 서명한 지불, 즉, 밥에 대한 지불이 아니기 때문에, 첫 번째 지불이 앨리스로부터 HSBC로의 5 GBP에 대한 것이고 그것이 키 저장 모듈(122)로부터 리트리브된 HSBC 키에 의해 서명된다는 것을 메타데이터가 자세히 설명한다. 메타데이터는, 두 번째 지불이 HSBC로부터 Revolut로(5 GBP의 경우, 즉 HSBC 계정에서 5 GBP가 인출됨) 이루어지고 그것이 키 저장 모듈(122)로부터 리트리브된 Revolut.com 키에 의해 서명됨을 추가로 자세히 설명한다. 그런 다음 메타데이터는 추가로, Revolut로부터 밥의 Revolut 계정으로 추가 지불이 이루어짐을 자세히 설명한다(즉, 밥의 잔액은 5 GBP만큼 증가하지만 그런 다음 Revolut은 HSBC 계정으로부터 5 GBP를 인출해야 함). 이것은 밥의 키로 서명된다. 이것은, 단계(S326)에서 식별된 데이터 간의 불일치(inconsistency)가 지불 프로세싱 자원(106)에 의해 해결됨을 의미한다. 이것은 단계(S404)이다. 다시 말해서, 불일치의 존재를 결정할 때, 불일치는 지불 프로세싱 자원(106)에 의해 해결되어, 은행이 일관되고 금액이 일관된다는 것을 보장한다.
위에서 설명한 템플릿을 사용하여, 지불 명령 데이터세트의 수정은, 5 GBP가 Alice_HSBC:GBP에서 HSBC_HSBC:GBP로 지불되고, 그런 다음 5 GBP가 HSBC_HSBC:GBP에서 HSBC_REVOLUT:GBP로 지불되고 그런 다음 HSBC_REVOLUT:GBP에서 Bob_REVOLUT:GBP로 지불이 이루어진다는 것을 의미하는 추가 메타데이터를 포함하고, 이는 은행 식별과 자산 식별의 균형이 맞고 트랜잭션이 완료될 수 있음을 의미한다.
단계(S326)가 초기에 부정적인 결과를 반환함에 따라, 은행이 일관되지 않기 때문에, 지불 프로토콜 모듈(120)은 지불 프로토콜의 관점에서 지불 명령 데이터세트를 평가하기 위해 다시 시작할 필요가 있다. 지불 명령 데이터세트는, 단계(S322 및 S324)를 참조하여 제시된 바와 같이, 앨리스의 지출 제한 및 제로섬 규칙의 충족에 관한 긍정적인 결정을 이미 반환했다. 이제 지불 명령 데이터세트가 지불 프로세싱 자원(106)에 의해 도입된 지불을 포함하도록 수정되어 은행 간의 일관성 부재를 해결하고 자산 식별과 은행의 균형이 맞도록 보장하므로, 지불 프로세싱 모듈(120)은 앨리스와 밥의 암호 서명이 유효성 검증되는 단계(S406)로 이동한다.
지불 프로세싱 모듈(120)은, 각각의 서명에 대한 해시를 생성하고 단계(S200 내지 S214)에서 생성된 레코드에 저장된 것과 해시를 비교함으로써 앨리스와 밥의 암호 서명을 유효성 검증한다. 이것은 또한 앨리스와 밥의 아이덴티티를 컨펌한다. 대안적으로 또는 추가적으로, 암호 비밀/공개 키 쌍에 기초하는 표준 PKI 기술을 또한 사용하여 각각의 서명을 유효성 검증할 수 있다. 이러한 기술은 또한 클라이언트의 아이덴티티를 검증하는 데 사용될 수 있다. 지불 프로세싱 모듈(120)은 또한 유사한 기술을 사용하여 2개의 은행, 즉 HSBC 및 Revolut의 서명을 유효성 검증한다.
단계(S406)의 완료 시에, 지불 프로세싱 자원(106)은 지불 명령 데이터세트에 따라 앨리스로부터 밥으로의 5 GBP의 지불이 이루어지는 것을 허용한다. 다시 말해서, 지불 프로세싱 자원(106)은, 일관성의 부족을 해결하고 지불 명령 데이터세트를 사용한 지불을 수행하기에 적합하게 지불 명령 데이터세트를 만들기 위해 2개의 추가 지불을 적용함으로써 지불 명령 데이터세트에서의 일관성의 부족을 해결한다.
2개의 은행과의 랑데뷰 트랜잭션
그런 다음 지불 프로세싱 자원(106)은 단계(S408)에서 앨리스와 밥 각각에 대해 블록체인(112)으로부터 블록체인 트랜잭션을 리트리브한다. 이것은 도 4b의 예시적인 개략도를 참조하여 설명한다.
앨리스에 대한 블록체인 트랜잭션(602)은 더스트 출력(Tx0, 앨리스)을 포함하고, 밥에 대한 블록체인 트랜잭션(604)은 더스트 출력(Tx0, 밥)을 포함한다. 지불 프로세싱 자원(106)은 또한 지불에 수반된 은행, 즉 HSBC 및 Revolut에 대한 블록체인 트랜잭션을 리트리브한다. HSBC에 대한 리트리브된 블록체인 트랜잭션(608)은 더스트 출력(Tx0, HSBC)을 포함한다. Revolut에 대해 리트리브된 블록체인 트랜잭션(610)은 더스트 출력(Tx0, Revolut)을 포함한다.
그런 다음 지불 프로세싱 자원(106)은, 단계(S408)에서 리트리브된 블록체인 트랜잭션으로부터 개개의 더스트 출력을 지출하는 앨리스 및 밥 각각에 대한 더스트 입력을 포함하는 새로운 랑데뷰 블록체인 트랜잭션(606)을 생성한다. 더스트 출력은 앨리스 및 밥과 연관된 이벤트 스트림에 대응하는 더스트 체인으로부터 리트리브될 수 있다. 이것은 또한 도 4b에 도시된다. 랑데뷰 블록체인 트랜잭션(606)은 블록체인 트랜잭션(408 및 410)으로부터 각각 리트리브된 HSBC 및 Revolut에 대한 더스트 입력을 더 포함한다.
대안적으로 그리고 제1 예에서와 같이, 지불 프로세싱 자원(106)은, 기존 이벤트 스트림의 일부를 형성하지 않는 더스트 및 계층적 결정론적(HD) 키 체인을 사용하여 새로운 더스트 트랜잭션을 생성할 수 있다. .
더스트 트랜잭션의 체인과 이벤트 스트림 간의 관계는 도 3d를 참조하여 이미 설명되었다.
랑데뷰 블록체인 트랜잭션(606)은 앨리스, 밥, Revolut 및 HSBC 각각에 대응하는 복수의 이벤트 스트림을 동기화하기 위한 블록체인 트랜잭션이다.
앨리스에 대한 더스트 출력을 지출하는 더스트 입력은 (Tx1, 앨리스)로 표시되고, 밥에 대한 더스트 출력을 지출하는 더스트 입력은 (Tx1, 밥)으로 표시된다. 새로운 랑데뷰 블록체인 트랜잭션(606)이 단계(S410)에서 생성된다. 새로운 랑데뷰 트랜잭션은 또한 각각 (Tx1, HSBC)로 표시되는 HSBC 및 (Tx1,Revolut)로 표시되는 Revolut에 대응하는 더스트 입력을 포함한다.
랑데뷰 블록체인 트랜잭션(606)으로의 펀드는 지불 프로세싱 자원(106)에 의해 추가되고, 지불 프로세싱 자원(106)에 다시 지불될 것이다. 이것은, 유효성 검증을 위해 블록체인(112)으로 전송되는 경우, 랑데뷰 블록체인 트랜잭션(606)의 유효성 검증에 따른 임의의 채굴자의 수수료를 뺀 것일 수 있다.
랑데뷰 블록체인 트랜잭션(606)은, Tx1, 앨리스 및 Tx1, 밥을 각각 지출하는 추가 더스트 출력을 포함한다. 랑데뷰 블록체인 트랜잭션(606)은 또한 HSBC 및 Revolut.com에 대해 블록체인으로부터 리트리브된 더스트 입력에 대응하는 더스트 출력을 포함한다.
지불 프로세싱 자원(106)은 또한 블록체인 트랜잭션(606)에 증명 가능하게 지출 불가능한 출력을 추가한다. 이것은 데이터 캐리어(612)로서 사용된다. 데이터 캐리어 각각은 동일하고, 동일한 데이터에 기초하고 동일한 지불 명령 데이터세트에 기초할 수 있다. 데이터 캐리어는 캐리어가 첨부되는 특정 데이터 스트림에 대한 streamState에 기초하여 일부 상이한 데이터를 보유할 수 있으며, streamState는 이전 streamState 및/또는 인덱스(또는 시퀀스 번호), 및/또는 해당 데이터 캐리어의 공증에 사용되는 개별적인 솔트에 기초한다. 대안적으로 또는 추가적으로, 블록체인 트랜잭션(606)에 대한 입력을 제공하는 모든 당사자 각각에 대한 데이터 캐리어를 첨부하기 위해 해당 당사자에 대응하도록 추가로 입증 가능하게 지출 불가능한 출력이 추가될 수 있다. 다시 말해서, 각각의 개개의 데이터 캐리어는, 각각의 개개의 데이터 캐리어가 개개의 당사자에 따라 상이할 수 있다는 점에서 각각의 개개의 당사자와 관련된 데이터를 포함할 수 있다. 예컨대, 앨리스와 관련된 데이터 캐리어가 앨리스와만 관련된 데이터, 즉, 그녀의 이름과 그녀의 계정 번호를 포함하고 밥과 관련된 데이터 캐리어는 밥과만 관련된 데이터, 즉 그의 이름과 그의 계정 번호를 포함할 수 있다는 차이가 있을 수 있다.
제1 예와 같이, 데이터 캐리어 내부에 보유된 데이터 페이로드(즉, 지불 명령 메타데이터의 해시)가 트랜잭션의 지출 불가능한 OP_RETURN 출력에 보유된다는 것을 의미하고, 이는 데이터 페이로드가 지출 불가능한 출력으로서 블록체인에 저장될 수 있다는 것을 의미한다.
데이터 캐리어(612) 각각의 내부의 데이터는 지불 프로세싱 자원(106)에 의해 생성된 지불 명령 데이터세트의 해시를 포함한다. 이것은 단계(S412)에서 생성된다. 증명 가능하게 지출 불가능한 출력은 랑데뷰 트랜잭션(606)이 트랜잭션에서 지불 명령 데이터세트의 해시를 전달하는 것을 가능하게 하고, 해시가 블록체인에 저장되는 것을 가능하게 한다. 이것은, 지불 명령 데이터세트 및 따라서 지불의 레코드가 블록체인 상에 저장됨을 의미한다. 이것은, 지불의 레코드가 블록체인의 불변성으로부터 이익을 얻는다는 것을 의미한다.
그런 다음, 블록체인 트랜잭션(606)은 HSBC 및 Revolut에 의해 제공되는 트랜잭션 및 계정에 대응하는 사용자가 정확하고 사용자, 즉, 앨리스 및 밥에 대응하는지를 확인하기 위해 체크될 수 있다. 이것은 단계(S412)이다.
지불 프로세싱 자원(106)은, 단계(S416)에서 블록체인 트랜잭션(606)이 이벤트 스트림, 즉 앨리스, 밥, Revolut 및 HSBC에 관한 이벤트 스트림에 데이터를 추가하기 위한 기반으로서 사용될 수 있다는 것을 컨펌하는 통지를 이벤트 스트림 자원(110)에 발행한다.
이 예에서, 앨리스, 밥 및 HSBC 각각은 그 자신의 이벤트 스트림을 가지고 있지만, 그들이 그렇지 않은 경우, 이벤트 스트림이 초기화될 수 있다. 다시 말해서, 앨리스는 이벤트 스트림(E-Alice)을 갖고, 밥은 이벤트 스트림(E-Bob)을 갖고, HSBC는 이벤트 스트림(E-HSBC)을 갖고, Revolut는 이벤트 스트림(E-Revolut)을 갖는다.
지불 프로세싱 자원(106)은 랑데뷰 트랜잭션(606)을 사용하여, 블록체인 트랜잭션(606)의 데이터 캐리어에 포함된 지불 명령 메타데이터의 해시를 포함하는 각각의 이벤트 스트림에 엔트리를 첨부함으로써, 이벤트 스트림(E-Alice, E-Bob, E-Revolut 및 E-HSBC)과 지불을 동기화한다. 이것은 단계(S418)이다. 이것은 도 4c에 개략적으로 도시된다. 이벤트 스트림(E-Alice, E-Bob, E-Revolut 및 E-HSBC)는 길이가 다를 수 있으며, 지불 명령 데이터의 해시는 개개의 이벤트 스트림의 상이한 위치(인덱스로 또한 알려짐)에 첨부될 수 있다. 이것은, 각각의 이벤트 스트림이 상이한 수의 이벤트를 포함할 수 있기 때문이다. 예컨대, 은행과 같은 특히 활동적인 당사자는 개인보다 훨씬 더 긴 이벤트 스트림을 가질 수 있으며, 지불 명령 데이터는 개인에 대한 것보다 훨씬 더 높은 인덱스에서 은행의 이벤트 스트림에 추가될 수 있다. 이벤트 스트림에 첨부된 엔트리의 수가 미리 결정된 양을 초과한 후, 은행이 새로운 이벤트 스트림을 시작하도록 또한 선택할 수 있을 수 있다.
다른 예에서와 같이, 데이터 캐리어 각각은 별개의 dataDigest 및/또는 별개의 streamDigest를 보유할 수 있다. streamDigest가 또한 솔팅될 수 있다. Revolut와 HSBC는, 앨리스와 밥이 사용하는 것과 상이한 해싱 방법을 사용하여 솔팅된 streamDigest를 생성하도록 선택할 수 있다.
그런 다음 지불 프로세싱 자원(106)은 이벤트 스트림 각각에 추가된 엔트리에 대한 식별자를 생성한다. 이것은 단계(S420)이다. 식별자는 영숫자일 수 있거나 이는 지불 명령 메타데이터의 해시에 기초하여 생성된 숫자일 수 있다. 예컨대, 지불 명령 메타데이터의 해시가 SHA256 암호에 의해 생성된 경우, 식별자는 지불 명령 메타데이터의 해시에 추가 SHA256 암호를 적용함으로써 생성될 수 있다. 다시 말해서, 식별자는 지불 명령 메타데이터의 해시의 해시일 수 있다.
그런 다음 지불 프로세싱 자원(106)은 지불 명령 메타데이터의 사본과 함께 식별자를 지불 데이터 저장소(124)에 저장한다. 이것은 요청 시에 앨리스와 밥 간의 지불을 가능하게 한다.
우리는 이제, 앨리스가 다시 밥에게 총 5 GBP를 지불하지만 HSBC에 의해 관리되는 밥의 계정이 GBP 계정이 아닌 Euro 계정인 추가 예시적인 시나리오를 설명한다.
이것은 도 5a 및 도 5b를 참조하여 설명된다. 이 예는 도 3a 내지 도 3e를 참조하여 설명된 예와 단계(S326)까지 다시 동일하다. 따라서, 간결함을 위해, 우리는 단계(S326)를 참조하여 설명된 스테이지에서 우리의 설명을 시작할 것이다.
다시 말해서, 트랜잭션에 대한 두 당사자에 대응하는 데이터에 걸쳐 필드를 체크함으로써, 지불에 관련된 데이터가 두 당사자 사이에서 일관되는지 여부를 지불 프로토콜 모듈(120)에 의해 (단계(S326)에서) 체크한다. 앨리스와 밥에 대한 계정의 화폐가 상이하다는 것이 확인되었다. 다시 말해서, 앨리스는 HSBC에 GBP로 계정을 가지고 있고, 밥은 HSBC에 유로로 계정을 가지고 있고, 즉, 은행은 동일하지만 화폐, 즉, 자산 식별자가 상이하다.
그런 다음 지불 프로토콜 모듈(120)은, 화폐가 상이하기 때문에 지불 프로토콜 기준에 대한 지불 명령 데이터세트의 체크를 중단한다. 그런 다음 지불 프로세싱 자원(106)은 지불 명령 데이터세트에 추가될 추가 메타데이터를 생성한다.
계정이 상이한 화폐로 되어 있는 경우의 추가 메타데이터의 생성
지불 프로세싱 자원(106)은 GBP에 대해 HSBC가 소유한 계정 및 EUR에 대해 HSBC가 소유한 계정에 대응하는 암호 키에 대한 요청으로 키 저장 모듈(122)에 액세스한다. 이것은 단계(S500)이다.
키 저장 모듈(122)이 액세스될 때, 키 저장 모듈(122)은 요청된 키에 대응하는 은행 및 개개의 자산 식별자, 즉 GBP 및 EUR을 식별하는 입력을 수신한다. 키 저장 모듈(122)은 은행 GBP 및 EUR 계정에 대응하는 키를 반환한다. 이 예에서, HSBC에 의해 관리되는 GBP 및 EUR 계정에 대응하는 키가 반환된다. 이것은 단계(S502)이다.
다시 말해서, 이러한 예시에서, 자산은 (GBP와 EUR은 동일한 화폐가 아니므로) 동일한 식별을 갖지 않지만, 앨리스와 밥은 동일한 은행을 가지고 있다. 이것이 이 예에서 단계(S326)가 부정적인 결과를 제공하게 하는 원인이다. 다시 말해서, 화폐가 상이하기 때문에, 자산 식별과 은행이 완전히 일관되지는 않는다.
다시 말해서, 자산 유형에 잔액이 있어야 하므로, 단계(S326)가 긍정적인 결과를 제공하기 위해 화폐의 잔액이 있어야 한다.
따라서, 지불 프로세싱 모듈(120)은 이러한 불일치를 해결하는 추가 메타데이터를 생성할 필요가 있다. 그런 다음 HSBC에 의해 관리되는 GBP 및 EUR 계정에 대응하는 키를 획득한 지불 프로세싱 모듈(120)은 이 메타데이터를 생성할 수 있다.
단계(S504)에서, 지불 프로세싱 모듈(120)은 2개의 추가 지불에 대응하는 메타데이터를 생성한다. 첫 번째는 앨리스의 GBP HSBC 계정으로부터 HSBC GBP 계정으로 5 GBP에 대한 것이고(즉, 앨리스는 5 GBP를 HSBC에 다시 지불함), 두 번째는 HSBC EUR 계정으로부터 밥의 EUR HSBC 계정으로의 5.81 유로의 지불이다.
단계(S506)에서, 지불 프로세싱 모듈(120)은, 각각의 서명에 대한 해시를 생성하고 단계(S200 내지 S214)에서 생성된 레코드에 저장된 것과 해시를 비교함으로써 (요구되는 경우) 앨리스와 밥의 암호 서명을 유효성 검증한다. 이것은 또한 앨리스와 밥의 아이덴티티를 컨펌한다. 대안적으로 또는 추가적으로, 암호 비밀/공개 키 쌍에 기초하는 표준 PKI 기술을 또한 사용하여 각각의 서명을 유효성 검증할 수 있다. 이러한 기술은 또한 클라이언트의 아이덴티티를 검증하는 데 사용될 수 있다.
이제 은행과 자산 식별이 일관되므로, 단계(S326)의 요건이 충족되고, 지불 프로토콜 기준이 충족될 수 있다. 다시 말해서, 은행과 자산 식별이 균형을 맞게 하는 메타데이터가 생성된다.
이를 설명하는 또 다른 방법은 은행 및 자산 식별을 나타내는 템플릿(XXX_BBBB:AAAA)을 사용할 수 있는데, 여기서 XXX는 계정의 운영자이고, BBBB는 은행 식별이고, AAAA는 자산 식별이다. 다시 말해서, 단계(S504)의 메타데이터 생성 이전에는, Alice_HSBC:GBP로부터 Bob_HSBC:EUR로 5 GBP를 이전하려는 시도가 완료될 수 없다. 그러나, 단계(S504)에서의 메타데이터의 생성은, 5 GBP가 Alice_HSBC:GBP로부터 HSBC_HSBC:GBP로 지불되고, 그런 다음 5.81 EUR(5 GBP를 EUR로 환산한 금액)이 HSBC_HSBC:EUR로부터 Bob_HSBC:EUR로 지불된다는 것을 의미하며, 이것은 은행 식별과 자산 식별이 균형을 이루고 있다는 것을 의미하고 이는 트랜잭션이 완료될 수 있다는 것을 의미한다.
단계(S506)의 완료 시에, 지불 프로세싱 자원(106)은 지불 명령 데이터세트에 따라 앨리스로부터 밥으로의 5 GBP의 지불이 이루어지는 것을 허용한다. 다시 말해서, 지불 프로세싱 자원(106)은, 일관성의 부족을 해결하고 지불 명령 데이터세트를 사용한 지불을 수행하기에 적합하게 지불 명령 데이터세트를 만들기 위해 2개의 추가 지불을 적용함으로써 지불 명령 데이터세트에서의 일관성의 부족을 해결한다.
2개의 화폐를 통한 랑데뷰 트랜잭션
그런 다음 지불 프로세싱 자원(106)은 단계(S508)에서 앨리스와 밥 각각에 대해 블록체인(112)으로부터 블록체인 트랜잭션을 리트리브한다. 이것은 도 5b의 예시적인 개략도를 참조하여 설명한다.
앨리스에 대한 블록체인 트랜잭션(702)은 더스트 출력(Tx0, Alice_HSBC:GBP)을 포함하고, 밥에 대한 블록체인 트랜잭션(704)은 더스트 출력(Tx0, Bob_HSBC:EUR)을 포함한다. 더스트 출력은 앨리스 및 밥과 연관된 이벤트 스트림에 대응하는 더스트 체인으로부터 리트리브될 수 있다. 지불 프로세싱 자원(106)은 또한 지불에 수반된 화폐 계정에 대한 블록체인 트랜잭션을 리트리브한다. HSBC GBP(즉, HSBC_HSBC:GBP) 계정에 대한 리트리브된 블록체인 트랜잭션(708)은 더스트 출력(Tx0, HSBC-GBP)을 포함한다. HSBC EUR(즉, HSBC_HSBC:EUR) 계정에 대한 리트리브된 블록체인 트랜잭션(710)은 더스트 출력(Tx0, HSBC-EUR)을 포함한다. 도 5b에 도시된 바와 같이, 각각의 블록체인 트랜잭션(702, 704, 708 및 710)은 또한 증명 가능하게 지출 불가능한 출력을 포함하며, 이 출력은 지출할 수 없지만 출력과 연관된 데이터 캐리어가 블록체인에 남아 있음을 보장하기 위해 OP_RETURN 커맨드를 포함하는 리딤 스크립트(redeem script)를 포함한다. 더스트 출력((Tx0, HSBC-GBP) 및 (Tx0, HSBC-EUR))은 HSBC의 EUR 및 GBP 계정과 연관된 이벤트 스트림에 대응하는 더스트 체인으로부터 리트리브될 수 있다.
그런 다음 지불 프로세싱 자원(106)은, 단계(S508)에서 리트리브된 블록체인 트랜잭션으로부터 개개의 더스트 출력을 지출하는 앨리스 및 밥 각각에 대한 더스트 입력을 포함하는 새로운 랑데뷰 블록체인 트랜잭션(706)을 (단계(S510)에서) 생성한다. 이것은 또한 도 5b에 도시된다. 랑데뷰 블록체인 트랜잭션(706)은 블록체인 트랜잭션(708 및 710)으로부터 각각 리트리브된 HSBC-GBP 및 HSBC-EUR에 대한 더스트 입력을 더 포함한다.
더스트 트랜잭션의 체인과 이벤트 스트림 간의 관계는 도 3d를 참조하여 이미 설명되었다.
랑데뷰 블록체인 트랜잭션(606)은 앨리스, 밥, Revolut 및 HSBC 각각에 대응하는 복수의 이벤트 스트림을 동기화하기 위한 블록체인 트랜잭션이다.
앨리스에 대한 더스트 출력을 지출하는 더스트 입력은 (Tx1, 앨리스)로 표시되고, 밥에 대한 더스트 출력을 지출하는 더스트 입력은 (Tx1, 밥)으로 표시된다. 새로운 랑데뷰 트랜잭션은 또한 각각 (Tx1, HSBC-GBP) 및 (Tx1,HSBC-EUR)로 표시된 HSBC의 GBP 및 EUR 계정에 대응하는 더스트 입력을 포함한다.
랑데뷰 블록체인 트랜잭션(706)으로의 펀드는 지불 프로세싱 자원(106)에 의해 추가되고, 지불 프로세싱 자원(106)에 다시 지불될 것이다. 이것은, 유효성 검증을 위해 블록체인(112)으로 전송되는 경우, 랑데뷰 블록체인 트랜잭션(706)의 유효성 검증에 따른 임의의 채굴자의 수수료를 뺀 것일 수 있다.
랑데뷰 블록체인 트랜잭션(706)은, Tx1, 앨리스 및 Tx1, 밥을 각각 지출하는 추가 더스트 출력을 포함한다. 랑데뷰 블록체인 트랜잭션(706)은 또한 HSBC-GBP 및 HSBC-EUR에 관련하여 블록체인으로부터 리트리브된 더스트 입력에 대응하는 더스트 출력을 포함한다.
지불 프로세싱 자원(106)은 또한 앨리스, 밥 및 HSBC-GBP 및 HSBC-EUR 계정 각각에 대한 블록체인 트랜잭션(706)에 증명 가능하게 지출 불가능한 출력을 추가한다. 이들은 데이터 캐리어(712a, 712b, 712c 및 712d)로서 사용된다.
제1 예와 같이, 데이터 캐리어 내부에 보유된 데이터 페이로드(즉, 지불 명령 메타데이터의 해시)가 트랜잭션의 지출 불가능한 OP_RETURN 출력에 보유된다는 것을 의미하고, 이는 데이터 페이로드가 지출 불가능한 출력으로서 블록체인에 저장될 수 있다는 것을 의미한다.
제1 및 제2 예에서와 같이, 지불 프로세싱 자원(106)은 기존 이벤트 스트림의 일부를 형성하지 않는 더스트 및 HD 키 체인을 사용하여 새로운 더스트 트랜잭션을 생성하도록 구성될 수 있다. 새로운 더스트 트랜잭션과 기존 더스트 체인의 더스트 입력의 조합은 또한 블록체인 트랜잭션(706)을 생성하는 데 사용될 수 있다.
데이터 캐리어(712a, 712b, 712c 및 712d) 내부의 데이터는 지불 프로세싱 자원(106)에 의해 생성된 지불 명령 데이터세트의 해시를 포함한다. 데이터 캐리어는 동일한 지불 명령 데이터세트에 기초할 때, 그들은 동일할 수 있다. 대안적으로 또는 추가적으로, 데이터 캐리어 내부의 데이터는 각각 상이한 당사자와 관련될 때 상이할 수 있다.
다시 말해서, 각각의 개개의 데이터 캐리어는, 각각의 개개의 데이터 캐리어가 개개의 당사자에 따라 상이할 수 있다는 점에서 각각의 개개의 당사자와 관련된 데이터를 포함할 수 있다. 예컨대, 앨리스와 관련된 데이터 캐리어가 앨리스와만 관련된 데이터, 즉, 그녀의 이름과 그녀의 계정 번호를 포함하고 밥과 관련된 데이터 캐리어는 밥과만 관련된 데이터, 즉 그의 이름과 그의 계정 번호를 포함할 수 있다는 차이가 있을 수 있다.
따라서 데이터 캐리어는 상이한 해시를 생성할 것이다. 이것은 단계(S512)에서 생성된다. 증명 가능하게 지출 불가능한 출력은 랑데뷰 트랜잭션(706)이 트랜잭션에서 지불 명령 데이터세트의 해시를 전달하는 것을 가능하게 하고, 해시가 블록체인에 저장되는 것을 가능하게 한다. 이것은, 지불 명령 데이터세트 및 따라서 지불의 레코드가 블록체인 상에 저장됨을 의미한다. 이것은, 지불의 레코드가 블록체인의 불변성으로부터 이익을 얻는다는 것을 의미한다.
이전 예에서와 같이, 데이터 캐리어 각각은 별개의 dataDigest 및/또는 별개의 streamDigest를 보유할 수 있다.
그런 다음 블록체인 트랜잭션(706)은, (GBP 및 EUR 모두에 관련하여) 트랜잭션에 대응하는 사용자와 HSBC가 제공하는 계정이 정확하고 사용자, 즉, 앨리스와 밥에 대응하는지를 확인하기 위해 체크될 수 있다. 이것은 단계(S514)이다.
지불 프로세싱 자원(106)은, (단계(S516)에서) 블록체인 트랜잭션(606)이 이벤트 스트림, 즉 앨리스, 밥, Revolut 및 HSBC에 관한 이벤트 스트림에 데이터를 추가하기 위한 기반으로서 사용될 수 있다는 것을 컨펌하는 통지를 이벤트 스트림 자원(110)에 발행한다.
이 예에서, (GBP 및 EUR 계정 모두와 관련하여) 앨리스, 밥 및 HSBC 각각은 그 자신의 이벤트 스트림을 가지고 있지만, 그렇지 않은 경우, 이벤트 스트림이 초기화될 수 있다. 다시 말해서, 앨리스는 이벤트 스트림(E-Alice)을 갖고, 밥은 이벤트 스트림(E-Bob)을 갖고, HSBC는 2개의 화폐에 대한 이벤트 스트림, 즉 (E-HSBC-GBP) 및 (E-HSBC-EUR)을 갖는다.
지불 프로세싱 자원(106)은 랑데뷰 트랜잭션(706)을 사용하여, 블록체인 트랜잭션(706)의 데이터 캐리어에 포함된 지불 명령 메타데이터의 해시를 포함하는 각각의 이벤트 스트림에 엔트리를 첨부함으로써, 이벤트 스트림(E-Alice, E-Bob, E-HSBC-GBP 및 E-HSBC-EUR)과 지불을 동기화한다. 이것은 단계(S518)이다. 다시 말해서, 데이터 출력(712a)이 앨리스에 대응하면, 데이터 출력(712a)이 해싱되고 앨리스의 이벤트 스트림에 추가될 것이다. 이것은 도 5c에 개략적으로 도시된다. 각각의 엔트리는 해당 엔트리까지 스트림에 포함된 데이터의 해싱된 다이제스트를 포함할 것이다. 이러한 스트림의 해싱된 다이제스트는 스트림 상에 엔트리와 함께 저장될 것이다.
그런 다음 지불 프로세싱 자원(106)은 이벤트 스트림 각각에 추가된 엔트리에 대한 식별자를 생성한다. 이것은 단계(S520)이다. 다른 예에서와 같이, 식별자는 영숫자일 수 있거나 이는 지불 명령 메타데이터의 해시에 기초하여 생성된 숫자일 수 있다. 예컨대, 지불 명령 메타데이터의 해시가 SHA256 암호에 의해 생성된 경우, 식별자는 지불 명령 메타데이터의 해시에 추가 SHA256 암호를 적용함으로써 생성될 수 있다. 다시 말해서, 식별자는 지불 명령 메타데이터의 해시의 해시일 수 있다.
그런 다음 지불 프로세싱 자원(106)은 지불 명령 메타데이터의 사본과 함께 식별자를 지불 데이터 저장소(124)에 저장한다. 이것은 요청 시에 앨리스와 밥 간의 지불을 가능하게 한다.
우리는 이제, 도 6a 및 도 6b를 참조하여 앨리스가 지불 프로세싱 자원(106)을 사용하여 밥에게 지불을 보내는 예시적인 시나리오를 설명한다. 지불은 금의 양에 관한 것일 수 있다. 금의 양은 자산의 예이고, 자산의 이전 및 자산에 대한 지불은 아래에 설명된 방법에 의해 레코딩된다.
단계(S600)에서, 앨리스는 밥에게 연락하여 49.20 GBP와 교환하여 1g의 금을 얻고 싶다는 그녀의 의사를 그에게 알린다. 단계(S602)에서, 밥은 앨리스에게 가격, 즉 49.20 GBP를 통지한다. 앨리스와 밥 둘 모두는, 예컨대, 주소가 Ynysmaerdy, Pontyclun CF72 8Yt(royalmint.com)인 영국의 왕립 조폐국과 같은 금의 발행자에 계정을 등록하였다. 이것은, 아래에서 설명될 바와 같이, 앨리스와 밥이 합법적이고 레코드 가능한 방식으로 금을 사고 파는 것을 가능하게 한다.
그런 다음 앨리스는 제1 컴퓨팅 디바이스(102)를 사용하여 지불 프로세싱 자원(106)에 1g의 금에 대해 49.20 GBP를 지불하기로 밥과의 그녀의 합의를 표시한다. 제1 컴퓨팅 디바이스(102)는 API(108)에 액세스하여 단계(S200 내지 S214)에 따라 앨리스에 의해 생성된 계정을 사용하여 지불 프로세스를 개시한다. 금은, 제1 컴퓨팅 디바이스가 지불 프로세스를 개시하기 위해 API(108)에 액세스할 때, 제1 컴퓨팅 디바이스(102)에 의해 식별된다. 이것은 지불 프로세싱 자원(106)이 금에 관련하여 존재할 이전을 식별하는 것을 가능하게 한다. 금은 영숫자 식별자, 숫자 코드 또는 임의의 다른 적절한 식별자를 사용하여 식별될 수 있다. 이것은 단계(S606)이다. 디바이스(102)로부터 API(108)로의 요청은 앨리스가 밥에게 지불하기를 원하는 금액을 나타낸다. 디바이스(102)로부터의 요청은 또한 앨리스가 지불하기를 원하는 계정 및 앨리스가 지불하기를 원하는 화폐 및 그녀가 지불하기 원하는 사람, 즉, 밥을 나타낸다. 앨리스가 밥에게 지불하고자 하는 금액, 밥의 식별, 앨리스가 지불하고자 하는 계정의 식별 및 앨리스가 지불하고자 하는 화폐는 단계(S608)에서 지불 프로세싱 자원(106)에 전송되는 지불 메타데이터의 세트를 형성한다.
다시 말해서, 자산은 GBP인 것으로 식별되고, 은행은 또한 지불 프로세싱 자원(106)에 대해 식별된다.
그런 다음, 지불 프로세싱 자원(106)은, 앨리스로부터 지불 메타데이터를 수신하면, 단계(S608)에서 앨리스가 제공한 메타데이터에 기초하여 밥의 계정으로부터 메타데이터를 리트리브한다. 이것은 단계(S610)이다. 지불 프로세싱 자원(106)은 밥의 계정으로부터 밥의 계정이 관련된 화폐, 즉, 파운드 스털링(GBP) 및 금 계정의 발행자, 즉, 왕립 조폐국를 리트리브한다.
그런 다음 지불 프로세싱 자원(106)은, 단계(S612)에서, 앨리스로부터 수신된 지불 메타데이터 및 밥의 계정으로부터 리트리브된 정보를 사용하여 지불 명령 데이터세트를 생성한다.
이 예에서, 밥의 은행 계정의 제공자는 "HSBC"(즉, 앨리스와 동일함)이고, 화폐는 GBP로서 식별되고, 지불 값(즉, 밥이 받을 금액)은 49.20 GBP이고, 계정의 식별은 <Bob:HSBC>으로 제공되고, 사용자는 "kyc" 값에 의해 밥으로서 식별되며, 행위자는 지불의 수취인, 즉, 지불을 받는 개인으로 식별된다. 이것은 지불 명령 데이터세트의 추가 부분을 형성한다. 지불 명령 데이터세트는 또한 서명<Bob_sig>을 사용하여 밥이 서명한 약관의 버전을 선택적으로 포함할 수 있다.
지불 명령 데이터세트의 추가 부분은 금 트랜잭션의 세부사항에 의해 형성된다. 지불 프로세싱 자원(106)은 밥의 금 계정 발행자, 즉, 왕립 조폐국에서 밥의 금 계정에 대한 액세스를 요청한다. 지불 프로세싱 자원(106)에는 액세스가 승인될 수 있도록 밥의 서명에 대한 요청을 제공된다. 그런 다음 지불 프로세싱 자원(106)은 밥에 대응하는 사용자 프로파일로부터 밥의 암호 서명을 리트리브하거나, 밥의 금 계정에 대응하는 서명에 대해 밥에 대한 별도의 요청에 의해 리트리브할 수 있다. 서명은 그의 "HSBC" 계정에 대한 그의 서명과 동일하거나 이와 별개일 수 있다. 대량의 금 또는 금과 관련된 상업 트랜잭션의 경우 밥의 서명이 특히 필요할 수 있고, 여기서 약관의 세트가 수반될 수 있으며 해당 약관에 대한 앨리스 또는 밥의 증명이 필요할 수 있다.
지불 명령 데이터세트의 또 다른 부분은 앨리스의 세부사항에 의해 형성된다. 즉, 앨리스의 계정의 제공자는 "hsbc.com"이고, 화폐는 GBP로 식별되며, 밥에게 이전되는 지불 값은 49.20 GBP이고(즉, 앨리스가 밥에게 지불할 49.20 GBP의 인출액, 그래서 이는 지불 명령 데이터세트에서 -49.20로 표현됨), 계정의 식별은 <Alice:HSBC>로 제공되고, 사용자는 "kyc" 값에 의해 앨리스로 식별되고, 앨리스가 서명한 약관은 앨리스가 제공한 URL에서 제공한 서명된 문서와 상기 문서의 해시에 의해 식별된다. 행위자는 지불의 발신자(originator), 즉, 지불을 하는 개인으로 식별된다.
지불 프로세싱 자원(106)은 또한 발행자, 즉, 왕립 조폐국에서 앨리스의 금 계정에 대한 액세스를 요청한다. 지불 프로세싱 자원(106)에는 액세스가 승인될 수 있도록 앨리스의 서명에 대한 요청을 제공된다.
그런 다음 단계(S614)에서 지불 명령 데이터세트에 대한 앨리스의 서명에 대한 요청과 함께 메시지가 제1 컴퓨팅 디바이스(102)에 전송된다. 그런 다음 앨리스는 밥에게 49.20 GBP의 지불을 승인하기 위해 단계(S516)에서 그녀의 암호 서명을 제공한다. 그런 다음 서명은 지불 프로세싱 자원(120)에 의해 지불 명령 데이터세트에 적용된다. 앨리스의 금 계정에 대응하는 서명은 "hsbc.com"에서 앨리스의 계정에 대한 서명과 상이한 서명일 수 있다. 서명이 상이할 경우, 앨리스는 단계(S616)에서 양자의 서명을 제공할 것이다. 대안적으로, 지불 프로세싱 자원(106)은 이미 앨리스의 금 계정에 대한 서명에 대한 액세스를 가질 수 있다. 다시 말해서, 지불 프로세싱 자원(106)이 앨리스에 의해 신뢰된다면, 앨리스로부터 서명의 리트리벌은 선택적이다.
그런 다음 지불 프로세싱 자원(106)은 밥의 금 계정으로부터 앨리스의 금 계정으로의 금의 이전에 대응하는 추가 메타데이터를 생성한다. 메타데이터는 앨리스로부터 밥으로의 지불 및 하나의 금 계정에서 다른 금 계정으로의 이전을 자세히 설명한다.
지불 프로세싱 자원(106)은 그런 다음 단계(S618)에서 지불 명령 데이터세트에 지불 프로토콜 기준을 적용한다. 지불 프로세싱 자원(106)은 단계(S620)에서 지불 프로토콜 모듈(120)에 액세스한다.
지불 프로토콜 모듈(120)은 먼저, 금액이 일관되고, 즉, 앨리스의 계정에서 인출된 금액이 밥의 계정으로 지불된 금액과 동일하다는 점에서, 지불 명령 데이터세트가 제로섬 규칙을 준수한다고 체크한다. 이것은 단계(S622)이다. 49.20 GBP가 앨리스의 계정에서 인출되고 49.20 GBP가 밥의 계정으로 지불되기 때문에, 제로섬 규칙이 준수된다. 금액 간의 불일치는, 예컨대, 화폐가 다르기 때문일 수 있다. 다시 말해서, 지불 프로토콜 모듈(120)은, 자산 식별과 은행 식별이 일관된다고 결정한다(그리고 이는, 위의 템플릿에 따라, Alice_HSBC:GBP는 Bob_HSBC:GBP와 균형을 이루고, Alice_MINT:GOLD는 Bob_MINT:GOLD와 균형을 이루기 때문이다).
대안적으로 또는 추가적으로, 밥이 HSBC에 GBP 계정만 가지고 있고 앨리스가 Revolut에 EUR 계정만 가지고 있는 경우, 즉 자산 식별이 별개이고, 자산 레지스트리가 별개인 경우, 불일치가 존재할 수 있다(Bob_HSBC:GBP에 대한 지불이 Alice_REVOLUT:EUR로부터 이루어질 수 없음). 그런 다음 지불 프로토콜 모듈(120)은 트랜잭션의 중개 부분(brokerage part)에 대응하는 추가 메타데이터를 생성할 것이다. 이 메타데이터는, 화폐와 은행이 별개이고 이것이 자산 식별과 은행의 불균형을 초래하는 예에서 전술된 것과 유사하게, 화폐와 은행의 불일치를 해결하기 위해 금융 브로커(여기서는 제1 브로커로 열거됨)가 트랜잭션에서 수행할 역할에 대응할 것이다. 이 예에서, 브로커는 HSBC에서 GBP 계정 및 Revolut에서 EUR 계정을 갖는다. 지불 프로토콜 모듈(120)은 이들 2개의 계정에 대응하는 암호 서명에 액세스할 것이다. 메타데이터는, 은행 식별과 자산 유형의 균형을 맞추기 위해 밥의 금 계정으로부터 앨리스의 금 계정으로 합의된 수량의 금을 이전하는 것, 앨리스의 EUR revolut 계정(즉, Alice_REVOLUT:EUR)으로부터 브로커의 Revolut에서의 EUR 계정(즉, Broker_Revolut:EUR)으로의 지불, 및 브로커의 GBP 계정(즉, Broker_Revolut:GBP)으로부터 밥 (Bob_HSBC:GBP)으로의 대응하는 양의 GBP의 지불을 자세히 설명할 것이다. 이 추가 메타데이터는 또한 해당 계정에 대응하는 암호 서명으로 서명될 것이다.
선택적으로 또는 추가로, 제1 브로커가 Revolut 계정 내에서만, 즉 다른 은행 간이 아닌 Revolut 계정 내에서만 EUR 대 GBP 교환만을 제공하는 경우, 지불 프로토콜 모듈(120)은 제1 브로커 외에 제2 브로커가 수행하는 부분에 대응하는 추가 메타데이터를 생성해야 할 것이다. 이 메타데이터는 밥의 금 계정(Bob_MINT:GOLD)으로부터 앨리스의 금 계정(Alice_MINT:GOLD)으로 합의된 양의 금의 이전; 앨리스의 EUR 계정(Alice_Revolut:GOLD)으로부터 제1 브로커가 보유한 EUR 계정(즉, Broker1_Revolut:GBP로 식별될 Revolut에서의 EUR 계정)으로의 지불; 제1 브로커의 GBP 계정(즉, Broker1_REVOLUT:GBP로 식별될 Revolut에서의 GBP 계정)으로부터 제2 브로커의 HSBC에서의 GBP 계정(Broker2_HSBC:GBP)으로의 지불; 및 제2 브로커의 GBP 계정(Broker2_HSBC:GBP)으로부터 밥의 HSBC에서의 GBP 계정(Bob_HSBC:GBP)으로의 지불을 상세히 설명할 것이다. 다시 말해서, 지불 프로토콜 모듈(120)은 단계(S622)에서 체크된 지불 명령 메타데이터의 양상들 사이의 불일치(또는 대응성의 부재)를 해결하기 위해 메타데이터의 세트를 구축하는 데 사용될 수 있다.
그런 다음 지불 프로토콜 모듈(120)은 앨리스로부터 밥으로 이전되는 금액이 앨리스의 잔고를 일정 최소값 아래로 떨어뜨리지 않게 한다는 것을 체크한다. 이것은 단계(S624)이다. 다시 말해서, 앨리스가 밥으로부터 얻는 금에 앨리스가 너무 많은 돈을 지출하는가? 앨리스가 너무 많이 지출하는 경우, 즉 그녀의 잔액이 최소값 아래로 떨어지면, 지불 프로토콜 모듈(120)은 앨리스에게 에러 메시지를 발행하여 그녀가 지출하고자 하는 금액을 지출할 수 없음을 그녀에게 알릴 것이다. 실제로, 신용 대출을 사용하는 경우, 최소값이 음수가 될 수 있다. 지불 프로토콜 모듈(120)은, 다시 시작하라는 명령이 주어질 때까지, 즉, 앨리스가 그녀의 계정에 더 많은 펀드를 예금하였거나 그녀의 최소 잔액이 변경되었을 때 단계(S520)로 복귀할 것이다.
그런 다음 지불 프로토콜 모듈(120)은, 발행 당사자에 대응하는 데이터에 걸쳐 필드를 체크함으로써 트랜잭션에 대한 두 당사자 간에 지불과 관련된 데이터가 일관되는지 여부를 체크한다. 이것은 단계(S626)이다. 자산 식별자 또는 자산 레지스트리가 일관되지 않는 자산 이전에서의 불일치를 해결하기 위해 브로커가 수행할 수 있는 역할에 대응하는 추가 메타데이터를 지불 프로토콜 모듈(120)이 도입함으로써, 계정을 제공하는 당사자가 동일하고 자산 식별이 동일하거나 일관성의 부재가 해결될 때, 두 당사자 간에 데이터가 일관된다. 이전이 금과 관련이 있으므로, 밥으로부터 앨리스로 이전되는 금의 양은 앨리스의 계정에 추가되는 금의 양을 상보적이어야 한다.
다시 말해서, 이전이 가능하려면, 이전 양측에서 식별된 자산 식별자와 은행 사이에 일관성이 있어야 한다는 요건이 있다. GBP와 금 둘 모두에 대해 제로섬 규칙이 충족되어야 한다는 요건이 또한 있다.
지불 프로세싱 모듈(120)은, 각각의 서명에 대한 해시를 생성하고 단계(S200 내지 S214)에서 생성된 레코드에 저장된 것과 해시를 비교함으로써 앨리스와 밥의 암호 서명을 유효성 검증한다. 이것은 단계(S628)이다. 이것은 또한 앨리스와 밥의 아이덴티티를 컨펌한다. 대안적으로 또는 추가적으로, 암호 비밀/공개 키 쌍에 기초하는 표준 PKI 기술을 또한 사용하여 각각의 서명을 유효성 검증할 수 있다. 이러한 기술은 또한 클라이언트의 아이덴티티를 검증하는 데 사용될 수 있다. 지불 프로세싱 모듈(120)은 또한 유사한 기술을 사용하여 앨리스와 밥의 금 계정의 서명을 유효성 검증한다. 지불 프로세싱 모듈(120)은 또한, 필요한 양의 금이 밥으로부터 앨리스로 이전될 수 있도록 필요한 양의 금이 밥의 이름으로 레코딩된다고 결정하기 위해 밥의 계정에 대한 체크를 수행한다. 브로커가 또한 사용되었다면, 중개 계정에 대응하는 암호 서명이 또한 유효성 검증된다.
단계(S622, S624, S626 및 S628)의 충족은, 지불 프로토콜에 의해 규정된 기준이 충족되었음을 의미하고 따라서 지불 프로세싱 자원(106)은 지불 명령 데이터세트에 따라 앨리스로부터 밥에게 49.20 GBP의 지불이 이루어지도록 허용한다. 그런 다음 금 계정의 발행자에 의해 금의 이전이 또한 레코딩될 수 있다.
그런 다음 지불 프로세싱 자원(106)은 단계(S630)에서 앨리스와 밥 각각에 대해 블록체인(112)으로부터 블록체인 트랜잭션을 리트리브한다. 앨리스에 대한 블록체인 트랜잭션(802)은 더스트 출력(Tx0, 앨리스)을 포함하고, 밥에 대한 블록체인 트랜잭션(804)은 더스트 출력(Tx0, 밥)을 포함한다. 더스트 출력은 앨리스 및 밥과 연관된 이벤트 스트림에 대응하는 더스트 체인으로부터 리트리브될 수 있다. 지불 프로세싱 자원(106)은 또한 지불에 수반된 2개의 금 계정, 즉, 왕립 조폐국 - 앨리스 및 왕립 조폐국 - 밥에 대한 블록체인 트랜잭션을 리트리브한다. 왕립 조폐국-밥에 대한 리트리브된 블록체인 트랜잭션(808)은 더스트 출력(Tx0, RYB)을 포함하고, 왕립 조폐국-앨리스에 대한 리트리브된 블록체인 트랜잭션(810)은 더스트 출력(Tx0, RYA)을 포함한다. 브로커가 또한 수반되면, 각각의 브로커에 대해 블록체인 트랜잭션이 또한 블록체인(112)으로부터 리트리브될 수 있다. 더스트 출력((Tx0, RYB) 및 (Tx0, RYA))은 앨리스와 밥의 금 계정과 연관된 이벤트 스트림에 대응하는 더스트 체인으로부터 리트리브될 수 있다.
추가적인 발행자와의 랑데뷰 트랜잭션의 생성
그런 다음 지불 프로세싱 자원(106)은, 단계(S530)에서 리트리브된 블록체인 트랜잭션으로부터 개개의 더스트 출력을 지출하는 앨리스 및 밥 각각에 대한 더스트 입력을 포함하는 새로운 랑데뷰 블록체인 트랜잭션(806)을 생성한다. 이것이 도 7에 도시된다. 랑데뷰 블록체인 트랜잭션(806)은, 즉, 앨리스 및 밥의 금 계정에 대한 블록체인 트랜잭션(808 및 810)으로부터 리트리브된 대응하는 출력을 지출하는 더스트 입력을 더 포함한다.
리트리브된 각각의 블록체인 트랜잭션 각각은 또한 OP_RETURN 스크립트와 관련된 데이터 캐리어, 즉, 증명 가능하게 지출 불가능한 출력을 포함할 수 있다.
앨리스에 대한 더스트 출력을 지출하는 더스트 입력은 Tx1, 앨리스로 표시되고, 밥에 대한 더스트 출력을 지출하는 더스트 입력은 Tx1, 밥으로 표시된다. 새로운 랑데뷰 트랜잭션은 또한 앨리스와 밥이 보유한 금 계정에 대응하는 더스트 입력을 포함하며, 이는 각각 (Tx1, RYA) 및 (Tx1, RYB)로 표시된다. 랑데뷰 블록체인 트랜잭션(806)은 단계(S632)에서 생성된다.
랑데뷰 블록체인 트랜잭션(806)으로의 펀드는 지불 프로세싱 자원(106)에 의해 추가되고, 지불 프로세싱 자원(106)에 다시 지불될 것이다. 이것은, 유효성 검증을 위해 블록체인(112)으로 전송되는 경우, 랑데뷰 트랜잭션(806)의 유효성 검증에 따른 임의의 채굴자 수수료를 뺀 것일 수 있다.
랑데뷰 블록체인 트랜잭션(806)은, Tx1, 앨리스 및 Tx1, 밥을 각각 지출하는 추가 더스트 출력을 포함한다. 랑데뷰 블록체인 트랜잭션(806)은 또한 2개의 금 계정과 관련하여 블록체인으로부터 리트리브된 더스트 입력에 대응하는 더스트 출력을 포함한다. 이것이 랑데뷰 트랜잭션이므로, 앨리스, 밥 및 2개의 금 계정에 각각 대응하는 입력/출력 쌍의 인덱스는, 예컨대 Tx1, 앨리스의 입력 인덱스가 숫자 1로서 할당될 수 있고 대응하는 더스트 출력의 출력 인덱스가 출력 인덱스 숫자 1로서 할당될 수 있다는 점에서 동일하다.
지불 프로세싱 자원(106)은 또한 앨리스, 밥 및 2개의 금 계정과 관련하여 블록체인 트랜잭션(806)에 증명 가능하게 지출 불가능한 출력을 추가한다. 이들은 각각 데이터 캐리어(812a, 812b, 812c 및 812d)로 표시된다.
트랜잭션에 수반된 브로커에 대응하는 증명 가능하게 지출 불가능한 출력이 또한 추가될 수 있다. 그들은 브로커에 대한 데이터 캐리어에 대응한다.
다른 예에서와 같이, 데이터 캐리어 각각은 별개의 dataDigest 및/또는 streamDigest를 보관할 수 있다. streamDigest는 다른 예와 마찬가지로 솔팅될 수 있다.
블록체인 트랜잭션(806)은 또한, 이전에 이벤트 스트림에 대한 기반으로서 사용되지 않은 더스트를 사용하여 생성될 수 있다. 이 "새로운 더스트"는 다른 예와 마찬가지로 블록체인 트랜잭션(806)을 생성하기 위해 영국 특허 출원 제2102217.3호에 설명된 바와 같이 HD 키 체인과 결합하여 사용될 것이다.
다른 예와 같이, 개개의 데이터 캐리어 내부에 보유된 데이터 페이로드(즉, 지불 명령 메타데이터의 해시)가 트랜잭션의 지출 불가능한 OP_RETURN 출력에 보유된다는 것을 의미하고, 이는 데이터 페이로드가 지출 불가능한 출력으로서 블록체인에 추후에 저장될 수 있다는 것을 의미한다. 제1 예와 같이, 트랜잭션의 지출 가능한 OP_RETURN 출력에 보유되는 데이터 캐리어 내부에 데이터 페이로드(즉, 지불 명령 메타데이터의 해시)를 보유하는 것은 데이터 페이로드가 지출 불가능한 출력으로서 블록체인에 추후에 저장될 수 있다는 것을 의미한다.
데이터 캐리어 내부의 데이터는 단계(S600 내지 S628)에서 지불 프로세싱 자원에 의해 생성된 지불 명령 데이터세트의 해시를 포함한다. 데이터 캐리어 내부의 데이터는, 해당 데이터가 동일한 지불 명령 데이터세트에 기초한다는 점에서 동일할 수 있다. 대안적으로 또는 추가적으로, 각각의 데이터 캐리어에 대한 개개의 해시는 데이터가 상이할 때 상이할 수 있다. 예컨대, 앨리스의 데이터는, 해당 데이터가 밥의 데이터가 아니라 그녀의 계정 활동과 관련이 있을 때 밥의 데이터와 상이하다. 이것은 단계(S634)이다. 증명 가능하게 지출 불가능한 출력은 랑데뷰 트랜잭션(806)이 트랜잭션에서 지불 명령 데이터세트의 해시를 전달하는 것을 가능하게 하고, 해시가 블록체인에 저장되는 것을 가능하게 한다. 이것은, 지불 명령 데이터세트 및 따라서 지불의 레코드가 블록체인 상에 저장됨을 의미한다. 이것은, 지불의 레코드가 블록체인의 불변성으로부터 이익을 얻는다는 것을 의미한다. 금의 이전의 경우, 이것은, 블록체인이 하나의 금 계정으로부터 다른 계정으로의 트랜잭션의 레코드를 지원하는 데 사용될 수 있음을 의미한다. 블록체인에 의해 그리고 본원에 설명된 시스템에 의해 제공되는 익명성은 또한, 금의 이전의 기밀성이 유지될 수 있음을 의미한다.
그런 다음 블록체인 트랜잭션(806)은, 트랜잭션에 대응하는 사용자 및 앨리스와 밥이 소유한 것에 대응하는 금 계정이 정확한지를 확인하도록 체크될 수 있다. 이것은 단계(S636)이다.
지불 프로세싱 자원(106)은, 단계(S638)에서 블록체인 트랜잭션(806)이 이벤트 스트림, 즉 앨리스, 밥 및 2개의 금 계정에 관한 이벤트 스트림에 데이터를 첨부하기 위한 기반으로서 사용될 수 있다는 것을 컨펌하는 통지를 이벤트 스트림 자원(110)에 발행한다.
지불 프로세싱 자원(106)은 랑데뷰 트랜잭션(806)을 사용하여, 블록체인 트랜잭션(806)의 개개의 데이터 캐리어에 포함된 지불 명령 메타데이터의 해시를 포함하는 이벤트 스트림 E-Alice, E-Bob, E-RYA(즉, 앨리스의 금 계정) 및 E-RYB(즉, 밥의 금 계정)에 엔트리를 추가함으로써, 지불과 해당 이벤트 스트림을 동기화한다. 다시 말해서, 데이터 출력(812a)에 대응하는 해시는 E-Alice에 추가될 수 있고, 데이터 출력(812b)에 대응하는 해시는 E-Bob에 추가될 수 있다. 이것은 단계(S640)이다. 이것이 도 8에 개략적으로 도시된다. 금의 이전에 수반된 브로커에 대응하는 이벤트 스트림에 엔트리가 또한 첨부될 수 있다.
그런 다음 지불 프로세싱 자원(106)은 이벤트 스트림 각각에 추가된 엔트리에 대한 식별자를 생성한다. 이것은 단계(S642)이다. 식별자는 영숫자일 수 있거나 이는 지불 명령 메타데이터의 해시에 기초하여 생성된 숫자일 수 있다. 예컨대, 지불 명령 메타데이터의 해시가 SHA256 암호에 의해 생성된 경우, 식별자는 지불 명령 메타데이터의 해시에 추가 SHA256 암호를 적용함으로써 생성될 수 있다. 다시 말해서, 식별자는 지불 명령 메타데이터의 해시의 해시일 수 있다.
그런 다음 지불 프로세싱 자원(106)은 지불 명령 메타데이터의 사본과 함께 식별자를 지불 데이터 저장소(124)에 저장한다.
대안적으로 또는 추가적으로, 지불 프로세싱 자원(106)은 트랜잭션을 레코딩하기 위해 커미트먼트의 체인의 원칙을 이용할 수 있다. 커미트먼트의 체인의 원칙은 영국 특허 출원 제2204293.1호(2022년 3월 25일에 출원됨)에 설명되어 있지만, 우리는 아래에서 자산 이전 이벤트를 레코딩하는 데 있어서 그의 적용을 설명할 것이다.
트랜잭션 레코드에 커미트먼트의 체인을 적용하는 것은 이전에 설명한 더스트 체인 접근 방식과 연관된 확실한 이점과 함께 추가적인 이점을 제공한다. 이러한 추가적인 이점은 체인에서 보이지 않는 트랜잭션 간의 링크가 포함되는데, 아래에 설명될 바와 같이, 링크가 데이터 페이로드에 포함되기 때문이고, 데이터 페이로드는, 요컨대, 이전의 트랜잭션과 향후 트랜잭션으로부터의 해시 데이터(hashed data)를 포함하고, 이는, 이전의 트랜잭션 및 향후 트랜잭션의 데이터가 구경꾼에 의해 인식될 수 없다는 것을 의미한다.
위에서, 우리는, 더스트의 체인을 동기화함으로써 자산 이전 이벤트에 수반된 다수의 당사자에 대응하는 이벤트 스트림을 동기화하기 위해 랑데뷰 트랜잭션이 사용되는 다양한 복잡성의 4개의 예를 설명했다. 대안으로서, 우리는 자산 이전 이벤트를 레코딩하기 위해 커미트먼트의 체인을 사용할 것을 제안한다. 간결함을 목적으로, 우리는 커미트먼트의 체인과 관련하여 설명하기 위해 설명된 예 중 4번째 예만을 선택하지만, 이것이 4번째 예에만 제한되는 것으로 간주되어서는 안 된다.
먼저, 우리는 도 8a를 사용하여 도 8에 도시된 이벤트 스트림을 참조하여 커미트먼트의 체인의 개념을 간략하게 도시한다. 커미트먼트의 각각의 체인에 대응하는 이벤트 스트림은 오프체인, 즉 오프 블록체인이며 데이터를 오프체인에 (불변적으로) 저장하는 방법을 나타낸다.
시스템(1400)은 다수의 로그 엔트리(1406a-d)를 저장하는 오프체인(즉, 블록체인 상이 아닌) 데이터 저장 시스템(1404)을 포함한다. 로그 엔트리(1406a-d)는 이벤트 스트림 관리자(110)에 의해 초기화된 이벤트 스트림의 엔트리에 대응할 수 있다.
도 8a의 시스템(1400)은, 이벤트(이를테면, 자산 이전 이벤트)를 블록체인 트랜잭션에 매핑하는 이벤트를 로깅하기 위한 이벤트 스트림 기반 시스템의 일부로서 사용될 수 있다.
오프체인 데이터 저장소(1404)의 각각의 이벤트(1406a-d)는 블록체인 트랜잭션(1408a-d)에 매핑되고, 블록체인 트랜잭션의 시퀀스는 커미트먼트의 체인을 사용하여 정렬 및 링크된다. 커미트먼트의 체인은 정보를 포함하는 트랜잭션의 세트로 볼 수 있으므로, 그들은 서로 연관되거나 트래버싱 가능할 수 있는 트랜잭션의 세트로 볼 수 있다. 랑데뷰 트랜잭션(1000)에 대해 아래에서 논의되는 예에서, 커미트먼트의 체인은, 레코딩되고 있는 자산 이전 이벤트에 대응하는 지불 명령 메타데이터에 기초하여 생성되는 데이터 다이제스트 및 상태 다이제스트에 의해 링크되는 트랜잭션의 세트이다.
아래에 설명되는 바와 같이, 트랜잭션의 세트는, 각각의 트랜잭션이 이전의 트랜잭션에 대한 참조 및 다음 트랜잭션에 대한 참조를 포함(또는 이에 기초하는 데이터를 포함)한다는 점에서 "체인"으로서 구성된다. 랑데뷰 트랜잭션(1000)을 참조하여 아래 예에서 설명되는 바와 같이, 랑데뷰 트랜잭션 출력의 페이로드는 이전의 트랜잭션 및 다음 트랜잭션에 대한 참조에 기초한다.
각각의 트랜잭션은, 블록체인으로 채굴될 트랜잭션에 대해 지불하는 "펀딩 입력" 입력(1410a-d)을 포함한다. 각각의 트랜잭션은 또한 개개의 트랜잭션의 지출 불가능한 출력에 보유될 수 있는 데이터 페이로드(1412a-d)를 포함할 수 있다. 그것은 앞에 OP_RETURN 작업코드가 붙을 수 있다. 이것은, 블록체인 상에 임의적인 데이터를 작성하고 또한 트랜잭션 출력을 무효한 것(즉, 지출 불가능한 것)으로 표시하는 데 사용될 수 있는 스크립트 작업코드이고, 이는, 개개의 트랜잭션이 블록체인 상에 레코딩될 때, 페이로드에 보유된 데이터가 블록체인 상에 불변하게 레코딩되게 한다.
도 8a에 도시된 "데이터 및 참조"는 출력에 포함된 상태 다이제스트 및 데이터 다이제스트를 나타낸다. 랑데뷰 트랜잭션(1000)을 참조하여 아래에 설명되는 예에서, 이들은 대응하는 이벤트 스트림 엔트리에 레코딩된 지불 명령 데이터세트에 기초한다.
요약하면, 우리는 앨리스가 금의 양과 관련하여 밥에게 지불을 보내는 위의 4번째 예를 참조한다. 복잡성은 서명이 또한 필요한 왕립 조폐국에서 계정의 존재로 인해 발생한다. 예에서는, 우리는, 자산 이전 이벤트(즉, 하나의 왕립 조폐국 계정으로부터 다른 계정으로의 금의 이전)가 더스트의 체인에 각각 대응하는 4개의 개별 이벤트 스트림에 레코딩된다는 것을 설명한다. 대안적인 접근 방식은, 랑데뷰 트랜잭션을 사용하여 커미트먼트의 4개의 체인을 원자적으로 동기화하여, 커미트먼트의 4개의 체인에 금의 이전을 레코딩하는 것일 것이다.
우리는 이제, 도 9를 참조하여, 앨리스로부터 밥으로의 금 이전, 즉, 위에 제시된 4번째 예에서 설명한 자산 이전 이벤트를 불변으로 레코딩하기 위해 커미트먼트의 체인이 사용될 수 있는 방법을 설명한다. 지불 프로세싱 자원(106)은 커미트먼트 관리 모듈(160)을 활용하도록 구성된다. 커미트먼트 관리 모듈(160)은 임의의 적절한 수단을 사용하여 지불 프로세싱 자원(106) 및 이벤트 스트림 관리 모듈(110)과 상호작용하도록 구성된다. 각각의 앨리스와 밥, 그리고 왕립 조폐국에서의 그들 개개의 금 계정은 단계(S900)에서 커미트먼트 관리 모듈(160)을 사용하여 초기화된 대응하는 커미트먼트 체인을 갖는다. 커미트먼트의 체인의 초기화는 커미트먼트의 체인에 할당될 수 있는 하드웨어 자원의 설정을 포함할 수 있다. 커미트먼트의 체인은 이미 초기화되었을 수 있거나, 이는 커미트먼트 관리 모듈(160)에 대한 요청에 응답하여 초기화될 수 있다. 단계(S900)는 자산 이전 이벤트의 당사자들에 대응하는 이벤트 스트림에 액세스하기 위해 이벤트 스트림 관리 모듈(110)에 액세스하는 것을 포함할 수 있다.
지불 프로세싱 자원(106)은 커미트먼트의 체인과 개개의 엔티티(이 예에서는 앨리스와 밥 및 그들의 금 계정) 사이의 연관을 결정하도록 구성된다. 연관을 결정할 때, 지불 프로세싱 자원(106)은, 커미트먼트의 체인이 초기화되었음을 나타내는 사용자 프로파일의 엔트리를 식별하고, 커미트먼트 관리 모듈(160)이 정확한 커미트먼트의 체인을 식별하는 데 사용할 수 있는 식별자를 제공한다. 커미트먼트의 체인의 초기화는, 앨리스가 밥에게 연락하여 49.20 GBP와 교환하여 1g의 금을 획득하고 싶다는 그녀의 의사를 그에게 알리는 단계(S600) 이전에 발생했을 수 있다. 커미트먼트의 체인의 초기화는 커미트먼트 관리 모듈(160)에 대한 적절한 요청으로 단계(S600 내지 S642) 중 임의의 것을 실행하는 동안 발생할 수 있다. 커미트먼트의 체인의 초기화는 단계(S628)의 긍정적인 완료 후에, 즉, 지불 프로토콜 기준이 충족되었을 때 발생할 수 있다. 이 단계, 즉, 단계(S628) 이후에, 단계(S630 내지 S642)에 대한 대안으로서 단계(900)가 초기화될 수 있다.
커미트먼트의 각각의 체인은 이벤트 스트림 관리 모듈(110)에 의해 관리되는 개개의 당사자에 대응하는 이벤트 스트림에 대응한다. 그러나, 의심의 여지를 없애기 위해, 커미트먼트의 체인은, 이벤트 스트림이 커미트먼트의 체인의 대응하는 페이로드에 저장될 것보다 각각의 엔트리에 더 많은 정보를 전달할 수 있다는 점에서 대응하는 이벤트 스트림과 정확히 대응해야 한다. 단계(902)에서, 지불 프로토콜에 의해 결정된 기준이 충족되고, 즉, (도 6a에 도시된 바와 같이) 단계(622, 624, 626 및 628)가 충족되었다고 결정되고, 금의 이전이 발생할 수 있으며, 자산 이전 이벤트로서 레코딩될 수 있다. 이것은, 금의 이전이 자산 이전 이벤트로서 레코딩될 필요가 있음을 나타내는, 지불 프로세싱 자원(106)에 의해 생성된 플래그에 액세스함으로써 이루어질 수 있다. 대안적으로 또는 부가적으로, 지불 프로세싱 자원에 의해 생성된 초기 플래그가 생성된 이래로 미리 결정된 시간의 양이 경과한 경우, 단계(S622, S624, S626 및 S628)가 반복될 수 있다.
단계(904)에서, 지불 프로세싱 자원(106)은 요청을 커미트먼트 관리 모듈(160)에 제공하고, 요청은 금의 이전이 앨리스, 밥 및 개개의 왕립 조폐국 계정 각각에 대응하는 커미트먼트의 체인에 레코딩되도록 한다. 지불 프로세싱 자원(106)에 의해 생성된 플래그는 단계(S904)의 실행 동안에 커미트먼트 관리 모듈(160)에 제공될 수 있다.
커미트먼트 관리 모듈(160)은 앨리스, 밥 및 앨리스와 밥 둘 모두에 대응하는 왕립 조폐국 계정 각각에 대한 펀딩 입력(커미트먼트 관리 모듈(160)에 의해 제공됨)을 포함하는 랑데뷰 트랜잭션(1000)을 생성하도록 구성된다. 이것은 단계(S906)이다. 랑데뷰 트랜잭션은 도 10을 참조하여 도시된다. 우리가 도시하는 랑데뷰 트랜잭션은, 금의 이전에 수반된 당사자를 위해 초기화된 커미트먼트의 체인에 대응하는 이벤트 스트림을 동기화한다. 이것은 더스트의 체인에 링크된 이벤트 스트림을 동기화하는 다른 예에서의 랑데뷰 트랜잭션과 구별된다.
도 10에 도시된 랑데뷰 트랜잭션(1000)은 앨리스, 밥 및 왕립 조폐국 계정 각각에 대한 출력을 포함한다. 각각의 출력은 데이터 다이제스트(HDni) 및 상태 다이제스트(Sni)를 포함한다. 아래 첨자 i는 자산 이전 이벤트에 수반된 당사자의 번호를 나타낸다. 아래 첨자 1은 앨리스의 HSBC 계정에 대응한다. 아래 첨자 2는 밥의 HSBC 계정에 대응한다. 아래 첨자 3은 앨리스의 왕립 조폐국 계정에 대응한다. 아래 첨자 4는 밥의 왕립 조폐국 계정에 대응한다. 출력은 1004, 1006, 1008 및 1010으로 열거된다.
각각의 데이터 다이제스트 및 상태 다이제스트는, 그것 앞에 OP_RETURN 작업코드가 붙는다는 점에서 트랜잭션의 지출 불가능한 출력 내부에 보유되는 트랜잭션의 데이터 페이로드 내에 있다. 이것은 임의적인 데이터를 블록체인에 기록하는 데 사용될 수 있는 스크립트 작업코드이며, 또한 트랜잭션 출력을 무효한 것, 즉, 지출 불가능한 것으로 표시한다. 따라서 대응하는 데이터는 블록체인 상에 불변하게 레코딩된다.
도 10에서 볼 수 있듯이, 랑데뷰 트랜잭션(1000)의 각각의 출력은, 커미트먼트의 체인에서 대응하는 링크에 대한 상태 다이제스트의 사용을 통해 대응하는 이전의 블록체인 트랜잭션(즉, 이는 커미트먼트의 개개의 체인에서 이전의 트랜잭션일 수 있음)에 대한 참조에 기초한다. 이전의 블록체인 트랜잭션은 랑데뷰 트랜잭션이거나 비랑데뷰 트랜잭션일 수 있다. 도 10에 도시된 바와 같이, 이러한 트랜잭션은 1012(앨리스의 HSBC 계정, 즉 Alice_HSBC:GBP에 대응함), 1014(밥의 HSBC 계정, 즉 Bob_HSBC:GBP에 대응)함, 1016(앨리스의 금 계정, 즉 Alice_MINT:GOLD에 대응함) 및 1018(밥의 금 계정, 즉 Bob_MINT:GOLD에 대응함)이다. 각각의 랑데뷰 트랜잭션 출력은 또한 다음 트랜잭션 참조의 펀딩 입력 참조를 사용하여 자신의 대응하는 다음 트랜잭션(이는 또한 랑데뷰 트랜잭션일 수 있음)에 대한 참조에 기초한다. 도 10에 도시된 바와 같이, 이러한 트랜잭션은 1020(앨리스의 HSBC 계정에 대응함), 1022(밥의 HSBC 계정에 대응함), 1024(앨리스의 금 계정에 대응함) 및 1026(밥의 금 계정에 대응함)이다. 랑데뷰 트랜잭션(1000) 및 다음 트랜잭션의 출력 간의 관계는, 우리가 데이터 다이제스트 및 상태 다이제스트의 생성을 설명하는 아래에서 명확해질 것이다. 트랜잭션 및 랑데뷰 트랜잭션(1000) 각각에 대한 입력은 플랫폼에 의해 제공될 수 있다. 트랜잭션(1012, 1014, 1016 및 1018)에 의해 제공된 입력이 충분한 펀드를 제공하지 않는 경우, 추가 입력이 제공될 수 있다. 입력은 커미트먼트 펀드(N-1, N 및 N+1)에 대응한다.
데이터 다이제스트 및 상태 다이제스트를 생성하기 위해, 커미트먼트 관리 모듈(160)은 단계(S600 내지 S628)에서 생성된 지불 명령 데이터세트를 리트리브한다. 이것은 단계(S908)이다. 그런 다음, 이제 설명할 바와 같이, 지불 명령 데이터세트는 데이터 다이제스트와 상태 다이제스트를 결정하는 데 사용된다.
데이터 다이제스트는 수학식을 사용하여 지불 명령 데이터세트(데이터 항목 Dni로 열거됨)를 사용하여 단계(S910)에서 도출된다.
여기서 ||는 자신의 앞과 뒤의 멤버의 연접이며, H2는 이중 해시 함수이지만, 단일 해시 함수(H)가 또한 사용될 수 있다. Di는 대응하는 당사자에 대한 지불 명령 데이터세트이다. 다시 말해서, i=1인 경우, 당사자는 앨리스이고, 이러한 식이다. 지불 명령 데이터세트는 모든 당사자에게 동일할 수 있거나, 이는 각각의 당사자마다 별개일 수 있다.
본원에 제공되는 해싱은 단방향 함수의 주요 예이다. 당업자는, 다른 단방향 함수가 또한 사용될 수 있음을 이해할 것이다. 명세서 전반에 걸쳐 사용되는 "해싱"은 적어도 한번의 해싱을 의미할 수 있고, 개개의 해싱 애플리케이션의 여러 애플리케이션을 포함할 수 있다. 두 번 이상의 해싱은 길이 확장 공격(length extension attack)에 대한 저항력을 제공한다. 두 번(또는 그 이상) 해싱하는 것에 대안으로, 길이 확장 공격에 취약하지 않은 상이한 해싱 함수 또는 방법론이 사용된다. 예컨대, SHA-3 및/또는 HMAC(선택적으로 동일한 솔트 또는 다른 솔트를 키로서 사용함)는 이러한 기능성을 제공한다. 또 다른 대안은 {Payment Instruction Dataset, Salt} 리프 항목을 갖는 머클 트리를 생성하는 것일 것이며, 데이터 다이제스트는 머클 트리 루트일 것이다.
해시를 솔팅하는 것은, 임의의 임의적인 데이터인 "솔트"를 해싱 함수에 대한 입력의 일부로서 (해싱되는 지불 명령 데이터세트와 함께) 사용하는 것을 의미할 수 있다. 솔트는 해시 함수에 대한 다른 입력과 연접될 수 있다. 선택적으로, 솔트는 랜덤이다.
해싱되는 각각의 데이터 항목, 즉 이벤트 스트림의 각각의 이벤트에 대해 상이한 솔트가 선택될 수 있거나, 이 예에서, 앨리스, 밥, 개개의 금 계정 각각에 대해 상이한 솔트가 사용될 수 있다.
데이터 다이제스트(HD)는 해당 지불 명령 데이터세트(이는 주요 예에서, 이벤트 스트림에 제출됨)에 대한 고유한 지문으로 볼 수 있다. 데이터 다이제스트를 (지불 명령 데이터세트 자체와 비교하여) 저장함으로써, 이 시스템을 사용하는 클라이언트는, 지불 명령 데이터세트의 콘텐츠를 공개하지 않고도, (클라이언트 데이터의 크기와 무관하게) 알려진 일관된 크기로 지불 명령 데이터세트의 존재 증명을 블록체인 상에 저장할 수 있다.
그런 다음 상태 다이제스트는 도 11에 도시된 바와 같이 단계(S912)에서 머클 트리의 루트로서 도출되고, 여기서 머클 트리의 리프는 이전의 트랜잭션 참조, 다음 트랜잭션 참조 및 클라이언트 데이터에 기초한다. 대안적으로 또는 추가적으로, 상태 다이제스트는 또한 JSON 오브젝트 및 솔팅된 경로에 기초하여 도출될 수 있다.
구체적으로, 머클 트리는 이전의 트랜잭션 참조, 다음 트랜잭션 참조 및 상태 클라이언트 데이터 다이제스트(HD')에 기초한다. 상태 클라이언트 데이터 다이제스트는 데이터 다이제스트(HD) 및 선택적으로 이벤트 및/또는 이벤트 스트림과 연관된 메타데이터에 기초한다. 상태 클라이언트 데이터 다이제스트는 아래에서 더 자세히 설명된다.
상태 다이제스트(S)(편의상 ni 아래첨자만을 무시)는 다음 수학식에 따라 (예시적인 이전의 트랜잭션 참조, 상태 클라이언트 데이터 다이제스트(HD')(다시 편의상 ni 아래첨자만을 무시) 및 다음 트랜잭션 참조를 사용하여) 결정될 수 있다:
여기서 "머클화(Merklize)" 함수는 정렬된 데이터 요소의 세트로부터 리프로서 머클 루트를 생성하고, 여기서 는 요소에 기초한 정렬된 리프의 세트이다. 머클화 함수는 또한, S의 계산에 사용될 수 있는 다른 데이터에 대응하는 추가적인 입력 파라미터를 수신할 수 있다. 예컨대, 복구 프로토콜이 인보크되는 경우에 악의적인 제3자가 스트림을 분기하는 것을 방지할 비밀(secret)이 또한 포함될 수 있다. 리프 각각은 초기에 머클화 함수에서 이중 해싱된다. 중요한 점은, 해싱 및 머클 트리가 작동하는 방법으로 인해, 그에 대한 입력의 세트의 순서가 중요하고, 따라서 동일한 트리(및 따라서 동일한 상태 다이제스트)가 동일한 입력 데이터에 대해 생성되도록, 머클 트리가 생성, 재생성 또는 검증될 때마다, 입력 순서가 동일해야 한다.
선택적으로, 상태 다이제스트는 버전 번호에 기초한다. 아래에 제시된 바와 같이 머클화 함수에 대한 호출에 버전 번호가 지정되면, 각각의 리프 노드는 버전 번호에 기초한다. 각각의 리프 노드 프리이미지 앞에는 버전 번호가 추가될 수 있다. 대안적으로, 각각의 리프 노드 프리이미지 뒤에는 버전 번호가 추가될 수 있다. 유리하게는, (동일한 입력 데이터가 사용되더라도, 상이한 버전 번호는 상이한 머클 트리 루트를 초래할 것이기 때문에) 버전 번호의 사용은 상태 다이제스트가 특정 버전에 바인딩되는 것을 허용한다. 버전 번호에서 변화의 사용은 현재 머클 트리가 구성되는 규격에 대한 임의의 변화와 함께 사용될 수 있다(예컨대, 새로운 및/또는 상이한 리프 노드). 각각의 버전 번호는 생성된 머클 트리에 대한 고유 규격에 결속될 수 있다.
머클화 함수는 선택적으로 다음 수학식에 따라 추가 인수(further argument)로서 버전 번호(v)를 사용한다.
머클화 함수는 다음과 같이 설명될 수 있다.
:
1. v==null인 경우:
1.1. 머클 트리 T를 로서 생성
1.2. 트리 T의 루트 RT를 획득
1.3. RT를 반환
2. 그렇지 않은 경우:
2.1. 버전 번호를 앞에 추가함으로써 리프의 목록의 각각의 리프를 업데이트:
2.1.1.
2.1.2.
2.1.3.
2.2. 업데이트된 리프 세트를 사용하여 머클 트리 T를 생성:
2.3. 트리 T의 루트 RT를 획득한다.
2.4. RT를 반환
머클화 함수는 위에서 제시된 것 외에도 다른 추가적인 입력을 수신할 수 있다.
GenMerkleTree 함수는 리프 데이터 항목의 세트를 고려하여 머클 트리를 생성하는 표준 방법을 의미하는 것으로 간주될 수 있다. GenMerkleTree의 첫 번째 단계는 리프 세트의 각각의 항목을 해싱하는 것일 수 있다(본 예에서는 ).
도 11을 참조하면, 리프 노드 PREV(1102), HD'(1104) 및 NEXT(1106)를 갖는 생성된 머클 트리(1100)의 예가 도시된다. 머클 트리 루트(1108)는 랑데뷰 트랜잭션(1000)의 각각의 출력에서 사용되는 상태 다이제스트(S)이다. 이 예시적인 머클 트리는 각각의 노드에 2개의 자식을 갖는 바이너리 트리로 구성된다(리프 제외). 홀수 개의 입력 데이터 항목(따라서 홀수 개의 리프)이 있기 때문에, 마지막 페어링되지 않은 리프 노드(즉, 가장 먼 "NEXT")는 겸용(double)이 된다. 당업자는, 머클 트리의 이러한 제시된 형태에 대한 엄격한 준수가 필요하지 않으며 또한 작동할 수 있는 다른 형태가 있음을 인지할 것이다. 위에서 논의된 바와 같이, 입력 세트의 각각의 항목은 두 번(1110) 해싱되고, 각각의 두 번 해싱된 항목은 머클 트리의 리프로서 사용된다.
도 11에 도시된 머클 트리 구조에 대한 대안으로서, 상태 다이제스트는 프리이미지를 해싱함으로써 생성될 수 있고, 여기서 프리이미지는 상태 데이터가 기초하는 오브젝트를 연접함으로써 구성된다. 따라서, 상태 다이제스트가 이전의 트랜잭션 참조, 상태 클라이언트 데이터 다이제스트 및 다음 트랜잭션 참조에 기초하는 예에서, 수학식은 다음과 같은 형태일 수 있다.
선택적으로, 솔트가 또한 프리이미지에 통합될 수 있다. 예컨대, 솔트는 프리이미지의 시작 또는 끝에서 연접될 수 있다.
머클 트리 루트에 대한 추가 대안으로서, 해시 체인 또는 표준 JSON 구조를 사용함으로써 상태 다이제스트가 생성될 수 있다. 각각의 중간 해시 결과 앞에 상태 다이제스트가 기초하는 항목이 추가되도록 해시 체인이 구성된다. 예컨대, 상태 다이제스트가 이전의 트랜잭션 참조, 클라이언트 데이터 다이제스트(HD') 및 다음 트랜잭션 참조에 기초하는 경우, 수학식은 다음과 같은 형태일 수 있다.
선택적으로, 솔트가 해시 체인에 통합된다. 선택적으로, 솔트는 각각의 중간 프리이미지에 솔트를 앞에 추가함으로써 통합된다.
PREV는 이전의 트랜잭션에 대한 참조이며, 이는 참조되는 상기 이전의 트랜잭션의 상태 데이터일 수 있다. 도 10에 도시된 랑데뷰 트랜잭션(1000)에서, Sn1은 앨리스에 대응하는 커미트먼트의 체인으로부터의 이전의 트랜잭션인 트랜잭션(1012)의 구성요소인 Sn1-1에 기초할 것이다. 마찬가지로 Sn2는 Sn2-1에 기초하고, 이러한 식이다. 다시 말해서, 이전의 트랜잭션에 대한 참조는, 상기 이전의 트랜잭션이 블록체인에 저장될 때 참조되는 그의 상태 데이터이다. 이전의 트랜잭션 참조는 선택적으로 부모 트랜잭션 참조라고 불리고, 현재 트랜잭션은 그의 자식이다.
참조할 어떠한 이전의 트랜잭션도 없는 경우(즉, 트랜잭션이 커미트먼트의 체인의 첫 번째 트랜잭션임), 이전의 트랜잭션 참조는 0의 문자열일 수 있는 널(null) 참조로 간주될 수 있다. 0의 문자열의 크기는 널이 아닌 이전의 트랜잭션 참조의 크기와 동일할 수 있다. 문자열은 32 바이트의 길이일 수 있다. 아래 표는 PREV의 예를 설명한다.
선택적으로 또는 대안적으로, PREV 프리이미지는 JSON 구조이고 그리고/또는 JSON 구조를 사용하여 표현될 수 있다. JSON 구조는 위에서 언급된 데이터 옵션을 포함한다. 유리하게는, JSON 오브젝트를 사용하면, 더 많은 데이터 요소를 추가해야 하는 경우 이들을 쉽게 추가하고 참조할 수 있는 능력이 제공된다.
NEXT는 다음 트랜잭션에 대한 참조이다. 유리하게는, 다음 트랜잭션의 많은 구성요소는 (그 존재가 향후에 있을 것이고 데이터가 클라이언트에 의해 제출되는 결과로서) 알려지지 않고, 상기 알려지지 않은 구성요소가 참조로서 사용될 수 없지만, 트랜잭션을 펀딩하는 데 사용되는 입력 UTXO 또는 UTXO들은 미리 결정될 수 있으며, 해당 트랜잭션 즉, "NEXT" 트랜잭션이 블록체인에 커밋될 때 해당 트랜잭션에만 고유할 것이다. 입력 UTXO(들)는 아웃포인트에 의해 참조될 수 있다. 아웃포인트는 UTXO가 속한 트랜잭션의 트랜잭션 id(TxID라고 함) 및 상기 참조된 트랜잭션에 대한 출력의 인덱스(vout라고 함)를 포함한다. 다음 트랜잭션 참조는 선택적으로 자식 트랜잭션 참조라고 하며, 현재 트랜잭션은 부모이다.
이전의 트랜잭션 참조와 유사하게, 참조될 어떠한 다음 트랜잭션도 없는 경우(즉, 현재 트랜잭션이 커미트먼트의 체인의 마지막임), 다음 트랜잭션 참조는 널 참조로 간주될 수 있다. 널 참조는 널이 아닌 경우 다음 트랜잭션 참조의 크기(즉, 트랜잭션 아웃포인트의 크기)와 동일한 크기일 수 있는 0의 문자열일 수 있다. 문자열은 32 바이트의 길이일 수 있다. 아래 표는 NEXT를 설명한다.
선택적으로 또는 대안적으로, NEXT 프리이미지는 JSON 구조이고 그리고/또는 JSON 구조로 표현될 수 있다. JSON 구조는 위에서 언급된 데이터 옵션을 포함한다. 유리하게는, JSON 오브젝트를 사용하면, 더 많은 데이터 요소를 추가해야 하는 경우 이들을 쉽게 추가하고 참조할 수 있는 능력이 제공된다.
아래 표는 다음에 기초하는 상태 클라이언트 데이터 다이제스트(HD')의 콘텐츠를 설명한다.
메타데이터 요소가 여러 개인 경우, 그들은 M1, M2 등으로 열거된다. 이것은 도 12의 머클 트리를 통해 설명된다.
예시적인 메타데이터 요소는 또한 다음 중 어느 하나 이상을 포함할 수 있다.
●
whenRecorded ― 지불 명령 메타데이터가 클라이언트로부터 수신되거나 오프체인 로그에 저장된 시간,
●
appVersion ― 커미트먼트의 체인의 버전 번호,
●
seed ― 이벤트 스트림 생성 시작 시에 사용되는 시드 값,
●
delWriteIV ― 이벤트 스트림에 작성하기 위해 위임된 인증 토큰 생성에 사용되는 초기 값,
●
delWriteH0 ― 이벤트 스트림에 작성하기 위해 위임된 인증된 토큰의 유효성 검증에 사용되는 최종 해시 값,
●
timeAC ― 이벤트 스트림이 작성을 위해 개방된 것으로 간주되는 시작 및/또는 종료 시간,
●
delAuthIndex ― 클라이언트가 이벤트를 제출하는 데 사용하는 위임된 토큰의 인덱스,
●
TxIDcreate ― 커미트먼트의 체인의 첫 번째 트랜잭션의 트랜잭션 ID, 및/또는
●
index ― 이벤트 스트림의 현재 이벤트 인덱스(모든 이벤트가 커미트먼트의 체인에 레코딩될 필요는 없으므로, 커미트먼트의 체인의 인덱스와 반드시 동일하지는 않음)
●
nextashSalt ― 다음 이벤트에 사용되는 솔트의 해시. 솔트는 커미트먼트의 체인의 다음 이벤트를 위해 미리 생성될 수 있으며, 이 솔트는 해싱되어 State Client Data Digest 머클 트리 생성에 사용된다.
당업자는 다른 메타데이터 요소가 또한 사용될 수 있음을 인지할 것이다.
도 12를 참조하면, 루트가 상태 클라이언트 데이터 다이제스트(HD')(1104)(도 11을 참조하여 전술한 바와 같이 상태 데이터 머클 트리(1100)에서 사용됨)인 예시적인 머클 트리(1200)가 도시된다.
리프 노드의 세트(1206, 1208, 1210, 1212, 1214)는, 데이터 다이제스트(HD) 및 메타데이터 리프 노드가 솔트와 인터리빙되도록 배열된다. 이 인터리빙은, 제3자가 머클 트리를 무차별 대입하는 데 엄청난 비용이 들게 함으로써 머클 트리의 데이터 보안을 강화한다. 제3자가 커미트먼트의 체인에 대한 프로토콜 설명을 얻고, HD(데이터 다이제스트)가 트랜잭션에 공개적으로 저장될 수 있다는 점을 고려할 때, 제3자는 많은 경우에서 이러한 메타데이터 값이 예측 가능하거나 쉽게 열거할 수 있다는 점을 감안하여 M1,...,Mm에 대한 값을 무차별 대입할 수 있다(예컨대, 메타데이터 요소 중 하나가 타임스탬프인 경우, 트랜잭션이 블록체인에 제출된 시간을 고려하여 이것이 추측할 수 있거나, 메타데이터 요소 중 하나가 단조적으로 증가하는 인덱스일 수 있으며, 이것은 이전 상태로부터 추측 가능할 수 있음). 제3자가 이러한 값을 무차별 공격하고 값 HD'(즉, 트리의 루트)를 올바르게 재구성할 수 있다면, 그들은 메타데이터 값(M1, …,Mm)에 대한 그들의 지식을 성공적으로 컨펌했을 것이다. 일부 경우들에서, 이러한 메타데이터는 민감할 수 있고, 예컨대 whenRecorded 또는 writeAccessControl.region 속성은 EventStream 트랜잭션에서 메타데이터로서 사용되며, 악의적인 제3자에게 중요할 수 있다.
리프 노드의 기초를 형성하는 프리이미지에는 프로토콜 버전 번호가 앞에 추가될 수 있다.
따라서, 예시적인 머클 트리(1200)를 생성하는 프로세스는 다음과 같이 작성될 수 있다.
:
1. SALT의 m-사본을 생성
2. 데이터 항목을 과 같이 정렬
3. 를 생성
4. H'D를 반환
중요하게는, 위에서 논의된 상태 다이제스트의 생성과 동일한 머클화 함수가 사용된다. 동일한 머클화 함수가 사용되므로, 리프 노드에 대한 프리이미지는 유사하게 선택적으로 두 번 해싱된다. 머클화 함수는 H'D의 계산에 사용될 수 있는 다른 파라미터에 대응하는 다른 추가적인 입력을 수신할 수 있다.
위의 머클 트리 생성에 대한 논의와 유사하게, 입력을 연접하고 결과를 해싱하는 것뿐만 아니라 해시 체인을 생성하는 것을 포함하는 머클 트리를 대체할 수 있는 다수의 대안이 가능하다.
상태 클라이언트 데이터 다이제스트(HD')의 생성을 위해, 프로토콜 버전 번호가 (v=null을 제공할 수 있는 위에서 논의된 상태 다이제스트(S)와 비교하여) 사용될 수 있다. 상태 다이제스트(S)가 상태 클라이언트 데이터 다이제스트(HD')에 의존하기 때문에, HD'를 프로토콜 버전 번호(v)에 의존하게 만들면, S는 또한 결국 (자신의 생성에 직접 사용되지는 않더라도) v에 의존하게 된다. 여기서 "의존"은, HD'의 생성에 사용된 프로토콜 버전 번호가 다른 것을 제외하고 동일한 입력이 사용된 경우, S가 상이할 것이라는 것을 의미한다. 이로써, 이것은, 2개의 머클 트리의 생성에서 프로토콜 버전 번호가 두 번 사용되지 않고 S가 프로토콜 버전 번호에 의존하게 할 수 있다.
단계(S914)에서, 랑데뷰 트랜잭션(1000)이 블록체인 상에 포함되도록 제출된다. 그런 다음, 지불 명령 데이터세트의 해시가 개개의 이벤트 스트림에 추가되도록 하는 요청에 따라 이벤트 스트림 관리 모듈(110)에 액세스함으로써, 단계(S916)에서 앨리스, 밥 및 앨리스 및 밥에 대응하는 금 계정에 대응하는 이벤트 스트림에는 지불 명령 데이터세트의 해시가 추가될 수 있다. 상태 다이제스트 및 데이터 다이제스트는 또한 이벤트 스트림의 엔트리에 포함될 수 있거나, 추가적으로 또는 대안적으로, 상태 다이제스트의 해시 및/또는 데이터 다이제스트의 해시가 또한 이벤트 스트림의 엔트리에 포함될 수 있다. 그런 다음 랑데뷰 트랜잭션(1000)은, 그가 대응하는 이벤트 스트림의 엔트리에 링크된다는 점에서, 앨리스, 밥 및 금 계정에 대응하는 커미트먼트의 체인 각각의 일부를 형성한다. 그런 다음 랑데뷰 트랜잭션은 변경 불가능하고 안전한 방식으로 이벤트 스트림의 엔트리에 링크되며, 자산 이전 이벤트는 세부사항을 개시하지 않고 변경 불가능하고 안전하게 레코딩된다.
다시 말해서, 자산 이전을 위한 기준이 충족된다는 지불 프로세싱 자원에 의한 결정 후에, 커미트먼트 관리 모듈(160)은 앨리스, 밥(즉, 그들의 HSBC GBP 계정) 및 앨리스와 밥에 대응하는 2개의 금 계정에 대응하는 커미트먼트의 체인을 동기화하는 랑데뷰 트랜잭션(1000)을 생성한다. 랑데뷰 트랜잭션(1000)의 출력이 생성되고, 지불 명령 데이터세트, 상태 클라이언트 데이터 다이제스트 및 상태 데이터 다이제스트에 기초하는 요소를 포함한다. 그런 다음 랑데뷰 트랜잭션(1000)은 블록체인에 제출되고 당사자에 대응하는 커미트먼트의 체인에 링크될 수 있다.
대안적으로 또는 추가적으로, 도 13에 도시된 바와 같이, 커미트먼트 관리 모듈(160)에 의해 생성될 수 있는 랑데뷰 트랜잭션(1300)의 대안적 형태가 있다. 랑데뷰 트랜잭션(1000)에서와 같이 커미트먼트의 체인마다 상이한 입력 및 출력 대신에, 단일 트랜잭션 입력(1302) 및 출력(1304)이 사용될 수 있다. 다시, 입력은 커미트먼트 관리 모듈(160)에 의해 제공될 수 있다.
출력은 대응하는 이전(PREV) 및 다음(NEXT) 트랜잭션의 조합에 기초하여 공식화될 수 있는 데이터 다이제스트 및 상태 다이제스트를 포함한다. 조합은 연접, 추가 또는 관련 수량을 결합하는 임의의 다른 방법에 의해 실현될 수 있다. 데이터 다이제스트 및 상태 다이제스트가 생성될 때, 트랜잭션(1300)은 블록체인에 포함되도록 제출될 수 있고, 랑데뷰 트랜잭션(1300)은 (랑데뷰 트랜잭션(1000)에) 유사하게 앨리스, 밥 및 앨리스 및 밥에 대응하는 금 계정에 대응하는 이벤트 스트림의 대응하는 엔트리에 링크될 수 있다.
위에서 언급된 양상들 및 실시예들은 본 개시를 제한하기보다는 예시하고, 당업자는 첨부된 청구항들에 의해 정의된 바와 같은 본 개시내용의 범위로부터 벗어남이 없이 다수의 대안적인 실시예들을 설계할 수 있을 것이란 점이 주의되어야 한다. 청구항들에서, 괄호 안의 배치된 임의의 참조 부호들은 청구항들을 제한하는 것으로 해석되어서는 안 된다. "포함하는(comprising)" 및 "포함하다(comprises)" 등의 단어는 전체로서 명세서 또는 임의의 청구항에 나열된 것들 이외의 요소들 또는 단계들의 존재를 배제하지 않는다. 본 명세서에서, "포함하다(comprises)"는 "포함하거나 구성된다(includes or consists of)"를 의미하고 "포함하는(comprising)"은 "포함하거나 구성되는(including or consisting of)"을 의미한다. 요소의 단수 참조는 그러한 요소들의 복수 참조를 배제하지 않으며 그 반대의 경우도 마찬가지이다. 본 개시내용은 여러 별개의 요소들을 포함하는 하드웨어에 의해 그리고 적합하게 프로그래밍된 컴퓨터에 의해 구현될 수 있다. 여러 수단들을 열거하는 디바이스 청구항에서, 이들 수단들 중 여러 개는 하나의 그리고 동일한 하드웨어 항목에 의해 구체화될 수 있다. 소정의 측정들이 서로 상이한 종속 청구항들에서 인용된다는 단순한 사실만으로 이 측정들의 결합이 유리하게 사용될 수 없다는 것을 나타내는 것은 아니다.
Claims (15)
- 적어도 제1 사용자 및 제2 사용자를 수반하는 자산 이전 이벤트(asset transfer event)를 레코딩하는 컴퓨터 구현 방법으로서, 상기 방법은 컴퓨팅 자원에 의해 구현되고, 상기 방법은:
명령 데이터를 수신하는 단계 ― 상기 명령 데이터는 요청된 자산 이전 이벤트와 관련되고, 상기 명령 데이터는 상기 자산의 발송자와 관련된 메타데이터(metadata)의 제1 세트 및 상기 자산의 적어도 하나의 수령자와 관련된 메타데이터의 제2 세트를 포함하고, 상기 발송자 및 상기 수령자 각각은 자산 레지스트리(asset registry)와 연관된 계정과 각각 연관됨 ― ;
상기 자산의 발송자와 커미트먼트(commitment)의 제1 체인을 연관시키고, 상기 자산의 수령자와 커미트먼트의 제2 체인을 연관시키는 단계 ― 커미트먼트의 각각의 체인은 이벤트 스트림과 복수의 블록체인 트랜잭션을 연관시킴 ― ;
이전 프로토콜(transfer protocol)에 따라, 상기 발송자로부터 상기 적어도 하나의 수령자로의 상기 자산의 이전이 이루어질 수 있는지 여부를 결정하기 위해 상기 메타데이터의 제1 세트와 상기 메타데이터의 제2 세트를 비교하는 단계 ― 상기 이전 프로토콜은 자산 이전 이벤트를 발생시키는 것을 가능하게 하기 위한 적어도 하나의 기준을 정의함 ― ;
상기 이전 프로토콜에 따른 메타데이터의 개개의 세트 사이의 상기 비교에 기초하여, 상기 메타데이터의 개개의 세트 사이의 대응성의 하나 이상의 항목을 결정하는 단계;
상기 발송자 및 상기 수령자 각각에 대해, 적어도 하나의 입력 및 적어도 하나의 출력을 포함하는 랑데뷰 블록체인 트랜잭션(rendezvous blockchain transaction)을 생성하는 단계 ― 상기 적어도 하나의 출력은 상기 메타데이터의 제1 세트 및 상기 메타데이터의 제2 세트와 연관된 데이터를 포함하고, 상기 메타데이터의 제1 세트 및 상기 메타데이터의 제2 세트와 연관된 데이터는 향후 블록체인 트랜잭션(future blockchain transaction)과 관련된 데이터에 기초함 ― ;
상기 랑데뷰 블록체인 트랜잭션을 개개의 상기 커미트먼트의 제1 체인 및 상기 커미트먼트의 제2 체인에 첨부하는 단계;
상기 랑데뷰 블록체인 트랜잭션과 개개의 이벤트 스트림의 개개의 엔트리를 연관시키는 단계를 포함하는,
컴퓨터 구현 방법. - 제1항에 있어서, 상기 랑데뷰 블록체인 트랜잭션은 블록체인으로 전송되는,
컴퓨터 구현 방법. - 제1항에 있어서, 상기 발송자에 대응하는 출력은, 상기 메타데이터의 제1 세트에 기초하여 생성된 메타데이터를 포함하는 데이터 페이로드를 포함하고, 수신자에 대응하는 출력은, 상기 메타데이터의 제2 세트에 기초하여 생성된 메타데이터를 포함하는 데이터 페이로드를 포함하는,
컴퓨터 구현 방법. - 제3항 또는 제5항에 있어서, 상기 메타데이터는 데이터 다이제스트(data digest) 및 상태 다이제스트(state digest)를 포함하는,
컴퓨터 구현 방법. - 제4항에 있어서, 상기 데이터 다이제스트는 상기 메타데이터의 제1 세트 및 상기 메타데이터의 제2 세트의 해시(hash)에 기초하여 생성되는,
컴퓨터 구현 방법. - 제5항에 있어서, 상기 데이터 다이제스트는 상기 메타데이터의 제1 세트 및 상기 메타데이터의 제2 세트의 조합 및 솔트(salt)에 기초하여 생성되는,
컴퓨터 구현 방법. - 제6항에 있어서, 상기 메타데이터의 제1 세트 및 상기 메타데이터의 제2 세트의 조합은 상기 메타데이터의 제1 세트 및 상기 메타데이터의 제2 세트의 조합의 이중 해시(double hash)를 취하는 것 및 상기 메타데이터의 제1 세트 및 상기 메타데이터의 제2 세트의 조합의 상기 이중 해시와 상기 솔트의 이중 해시를 연접(concatenate)하는 것을 포함하는,
컴퓨터 구현 방법. - 제4항에 있어서, 상기 상태 다이제스트는 상기 데이터 다이제스트 및 향후 트랜잭션에 기초하여 생성되는,
컴퓨터 구현 방법. - 제4항에 있어서, 상기 상태 다이제스트는 이전의 트랜잭션(previous transaction)에 기초하여 추가로 생성되는,
컴퓨터 구현 방법. - 제4항 내지 제8항 중 어느 한 항에 있어서, 상기 상태 다이제스트는 머클 트리(Merkle tree)의 루트(root)인,
컴퓨터 구현 방법. - 제1항 내지 제10항 중 어느 한 항에 있어서, 상기 메타데이터의 개개의 세트 사이의 대응성의 하나 이상의 항목을 결정하는 단계는:
iv) 상기 메타데이터의 개개의 세트에서 식별되는 지불 화폐;
v) 상기 발송자에 대응하는 계정으로부터 지급되는 화폐 금액 및 상기 수령자에 대응하는 계정으로부터 요청된 화폐 금액; 및
vi) 상기 발송자 계정 및 상기 수령자 계정과 연관된 자산 레지스트리의 식별자
중 적어도 하나 사이의 대응성을 결정하는 단계를 포함하는,
컴퓨터 구현 방법. - 제1항 내지 제11항 중 어느 한 항에 있어서, 상기 컴퓨팅 자원은, 상기 이전 프로토콜에 따라, 상기 이전이 이루어질 수 없다고 결정하고; 상기 이전 프로토콜과의 일관성(concordance) 부재를 해결하기 위해 메타데이터의 추가 세트를 생성하는,
컴퓨터 구현 방법. - 제12항에 있어서, 상기 메타데이터의 추가 세트를 생성하는 것은 제1 화폐와 제2 화폐 사이의 변환을 가능하게 하는 메타데이터를 생성하는 것을 포함하는,
컴퓨터 구현 방법. - 제12항 또는 제13항에 있어서, 상기 메타데이터의 추가 세트를 생성하는 것은, 주어진 자산의 또 다른 자산 레지스트리로의 이전을 레코딩하기 위해 하나의 자산 레지스트리에 대한 메타데이터를 생성하는 것을 포함하는,
컴퓨터 구현 방법. - 제1항 내지 제14항 중 어느 한 항의 방법을 구현하도록 구성된 시스템.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB2109064.2 | 2021-06-24 | ||
| GBGB2109064.2A GB202109064D0 (en) | 2021-06-24 | 2021-06-24 | Computer implemented method and system |
| GB2209173.0 | 2022-06-22 | ||
| PCT/EP2022/067065 WO2022268908A1 (en) | 2021-06-24 | 2022-06-22 | Method and system for appending rendezvous blockchain transaction to user chains of commitment |
| GBGB2209173.0A GB202209173D0 (en) | 2022-06-22 | 2022-06-22 | A computer implemented method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR20240024767A true KR20240024767A (ko) | 2024-02-26 |
Family
ID=82446602
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020237020963A KR20240024767A (ko) | 2021-06-24 | 2022-06-22 | 커미트먼트의 사용자 체인에 랑데뷰 블록체인 트랜잭션을 첨부하기 위한 방법 및 시스템 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20240095692A1 (ko) |
| KR (1) | KR20240024767A (ko) |
| TW (1) | TW202301224A (ko) |
| WO (1) | WO2022268908A1 (ko) |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10762506B1 (en) * | 2017-05-11 | 2020-09-01 | United Services Automobile Association | Token device for distributed ledger based interchange |
-
2022
- 2022-06-22 US US18/275,796 patent/US20240095692A1/en active Pending
- 2022-06-22 KR KR1020237020963A patent/KR20240024767A/ko unknown
- 2022-06-22 WO PCT/EP2022/067065 patent/WO2022268908A1/en active Application Filing
- 2022-06-23 TW TW111123508A patent/TW202301224A/zh unknown
Also Published As
| Publication number | Publication date |
|---|---|
| TW202301224A (zh) | 2023-01-01 |
| US20240095692A1 (en) | 2024-03-21 |
| WO2022268908A1 (en) | 2022-12-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7241216B2 (ja) | ブロックチェーンベースの暗号通貨のためのトークンを検証する、コンピュータにより実行される方法及びシステム | |
| US11625694B2 (en) | Blockchain-based exchange with tokenisation | |
| JP2019508948A (ja) | ブロックチェーンベースにおけるエンティティのセキュアな移転のための方法およびシステム | |
| CN116194940A (zh) | 基于区块链的税收机制 | |
| US20230316272A1 (en) | Divisible tokens | |
| Pop et al. | Blockchain based decentralized applications: Technology review and development guidelines | |
| Sober et al. | Decentralized cross-blockchain asset transfers with transfer confirmation | |
| CN116097264A (zh) | 电子文件签名 | |
| EP4032223A1 (en) | Multi-criteria blockchain protocol | |
| US20220405749A1 (en) | Allocation of a digital asset using blockchain transactions | |
| KR20230062835A (ko) | 동기화되고 원자성 추적을 위한 방법 및 시스템 | |
| KR20240024767A (ko) | 커미트먼트의 사용자 체인에 랑데뷰 블록체인 트랜잭션을 첨부하기 위한 방법 및 시스템 | |
| WO2021213920A1 (en) | Method for implementing a digital coin system using a blockchain | |
| US20240112161A1 (en) | Method and system for synchronising user event streams with dust-based rendezvous transactions | |
| JP2024523071A (ja) | コミットメントのユーザチェーンにランデブーブロックチェーントランザクションを付け加えるための方法およびシステム | |
| Antal et al. | Distributed Ledger Technology Review and Decentralized Applications Development Guidelines. Future Internet 2021, 13, 62 | |
| US20240020681A1 (en) | Digital tokens using blockchain | |
| WO2023156669A1 (en) | Computer implemented method and system for the provision of access to a plurality of functions and applications associated with a blockchain | |
| WO2023180486A1 (en) | Ordered, append-only data storage | |
| TW202312057A (zh) | 電腦實施方法及系統 | |
| CN118235154A (zh) | 一种计算机实现的方法和系统 | |
| WO2024041866A1 (en) | Blockchain transaction | |
| CN115836314A (zh) | 区块链事务输出的概率成员资格测试 |