KR20220143879A - 플랫폼 서비스 검증 - Google Patents

플랫폼 서비스 검증 Download PDF

Info

Publication number
KR20220143879A
KR20220143879A KR1020227031821A KR20227031821A KR20220143879A KR 20220143879 A KR20220143879 A KR 20220143879A KR 1020227031821 A KR1020227031821 A KR 1020227031821A KR 20227031821 A KR20227031821 A KR 20227031821A KR 20220143879 A KR20220143879 A KR 20220143879A
Authority
KR
South Korea
Prior art keywords
transaction
blockchain
event
client
data
Prior art date
Application number
KR1020227031821A
Other languages
English (en)
Inventor
앤드류 제임스 미
Original Assignee
엔체인 라이센싱 아게
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GBGB2002285.1A external-priority patent/GB202002285D0/en
Priority claimed from GBGB2013929.1A external-priority patent/GB202013929D0/en
Priority claimed from GBGB2020279.2A external-priority patent/GB202020279D0/en
Application filed by 엔체인 라이센싱 아게 filed Critical 엔체인 라이센싱 아게
Priority claimed from GBGB2102217.3A external-priority patent/GB202102217D0/en
Publication of KR20220143879A publication Critical patent/KR20220143879A/ko

Links

Images

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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • 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
    • 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/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

본 개시내용은 블록체인과 연관된 복수의 서비스들을 하나 이상의 클라이언트들에게 제공하는 플랫폼과 연관된 블록체인 트랜잭션들의 검증을 위한 방법들, 디바이스들 및 시스템들을 제안한다.

Description

플랫폼 서비스 검증
본 개시내용은 일반적으로 하나 이상의 클라이언트들에 대한 분산 원장, 즉 블록체인과 연관된 하나 이상의 서비스들의 플랫폼을 구현하기 위한 방법들 및 시스템들에 관한 것이다. 특히, 본 개시내용은 이벤트 스트림들 또는 기계 판독 가능 계약들의 구현과 같이, 하나 이상의 클라이언트들에 대한 블록체인과 연관된 복수의 기능들 및 애플리케이션들에 대한 액세스의 제공에 관한 것이다(그러나 이에 제한되지 않음).
이 문서에서 우리는 모든 형태의 전자, 컴퓨터 기반, 분산 원장을 포함하기 위하여 '블록체인'이라는 용어를 사용한다. 이는 합의 기반(consensus-based) 블록체인 및 트랜잭션 체인 기술들, 허가 및 비허가 원장들, 공유 원장들, 공용 및 개인 블록체인들 및 이들의 변동들을 포함한다. 다른 블록체인 구현들이 제안되고 개발되었지만, 블록체인 기술의 가장 널리 알려진 애플리케이션은 비트코인 원장이다. 비트코인은 편의 및 예시의 목적으로 본원에서 지칭될 수 있지만, 본 개시내용은 비트코인 블록체인과 함께 사용하는 것으로 제한되지 않으며, 임의의 종류의 디지털 자산 또는 디지털 자산의 표현과 연관된 대안적인 블록체인 구현들 및 프로토콜들이 본 개시내용의 범위 내에 속한다는 것이 주의되어야 한다. "클라이언트", "엔티티”, "노드", "사용자", "전송자", "수령인", "지급인", "수취인"이라는 용어들은 본원에서 컴퓨팅 또는 프로세서-기반 자원을 지칭할 수 있다. 본원에서 "비트코인"이란 용어는 비트코인 프로토콜로부터 도출되거나 이에 기초하는 임의의 버전 또는 변동을 포함하는 데 사용된다. "디지털 자산"이라는 용어는 암호화폐, 재산의 적어도 일부를 표현하는 토큰들, 스마트 계약, 라이센스, 즉 소프트웨어 라이센스, 또는 미디어 콘텐츠에 대한 DRM 계약들 등과 같은 임의의 이전 가능한 자산을 지칭할 수 있다. "디지털 자산"이라는 용어는 이 문서 전반에 걸쳐 가치와 연관될 수 있는 상품을 표현하는 데 사용되며, 이는 하나의 엔티티에서 다른 엔티티로의 트랜잭션에서 지불로서 이전되거나 제공될 수 있다는 것이 이해될 것이다.
블록체인은 결국, 트랜잭션들로 구성되는 블록들로 구성된 컴퓨터-기반 탈중앙화된 분산 시스템으로서 구현되는 피어-투-피어 전자 원장이다. 각각의 트랜잭션은 블록체인 시스템의 참여자들 사이의 디지털 자산의 제어의 이전을 인코딩하는 데이터 구조이며, 적어도 하나의 입력 및 적어도 하나의 출력을 포함한다. 각각의 블록은 이전 블록의 해시를 포함하여서, 블록들은 그의 시작 이래로 블록체인에 기록되는 모든 트랜잭션들에 대한 영구적이고 변경 불가능한 레코드를 생성하도록 함께 체이닝된다(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로서 블록체인에 저장되면, 사용자는 연관된 자원의 제어를 다른 트랜잭션의 입력과 연관된 다른 어드레스로 이전할 수 있다. 이러한 이전은 일반적으로, 디지털 지갑을 사용하여 행해지지만, 반드시 그럴 필요는 없다. 이 디지털 지갑은 디바이스; 물리적 매체; 프로그램; 데스크톱, 랩톱 또는 이동 단말과 같은 컴퓨팅 디바이스 상의 애플리케이션(앱); 또는 인터넷과 같은 네트워크 상의 도메인과 연관된 원격-호스팅 서비스일 수 있다. 디지털 지갑은 공개 및 개인 키들을 저장하고, 사용자와 연관된 자원들; 토큰들 및 자산들 등의 소유권을 추적하고; 디지털 자산들을 수신하거나 지출하고; 암호화폐들, 라이센스들, 재산 또는 다른 유형들의 자원과 같은 디지털 자산들과 관련될 수 있는 토큰들을 이전하는 데 사용될 수 있다.
암호화폐 구현의 사용을 위한 블록체인 기술이 가장 널리 알려져 있지만, 디지털 기업가들은 새로운 시스템을 구현하기 위해 블록체인 상에 저장될 수 있는 데이터 및 비트코인이 기초하고 있는 암호화 보안 시스템 둘 모두를 사용하는 방법을 모색하고 있다. 암호화폐 영역으로 제한되지 않는 자동화된 작업들 및 프로세스들을 위해 블록체인이 사용될 수 있는 경우가 매우 유리할 것이다. 이러한 솔루션은 블록체인의 이점들(예컨대, 이벤트들의 영구적인 위조-방지성 레코드들, 분산 프로세싱 등)을 활용하는 동시에 그의 애플리케이션들에서 더 다재다능해질 수 있을 것이다.
현재 연구의 한 영역은 "스마트 계약들"의 구현을 위한 블록체인의 사용이다. 이들은 기계-판독 가능 계약 또는 동의의 조건들의 실행을 자동화하도록 설계된 컴퓨터 프로그램들이다. 자연어로 기록되는 기존의 계약과 달리, 스마트 계약은 결과들을 생성하기 위해 입력들을 프로세싱할 수 있는 규칙들을 포함하는 기계 실행 가능 프로그램이며, 이는 그 후 그러한 결과들에 의존하여 액션들이 수행되게 할 수 있다. 블록체인-관련 다른 관심 영역은 '토큰들'(또는 '컬러드 코인(coloured coin)들')을 사용하여 블록체인을 통해 실세계 엔티티들을 표현 및 이전하는 것이다. 잠재적으로 민감성 또는 비밀 아이템은 어떠한 구별 가능한 의미 또는 가치도 갖지 않는 토큰으로 표현될 수 있다. 따라서 토큰은 실세계 아이템이 블록체인으로부터 참조될 수 있게 하는 식별자로서 역할을 한다.
위에서 언급된 예들 또는 시나리오들은 블록체인의 이점들을 이용하여 영구적이고 변조 방지된 이벤트 레코드들을 제공하면서; 예컨대, BSV(Bitcoin Satoshi's Vision) 블록체인에서 사용되는 ECDSA(Elliptic Curve Digital Signature Algorithm)에 대한 암호화 키들을 관리하는 소프트웨어 및/또는 하드웨어, 또는 프로세서/모듈 이를테면, 디지털 자산들을 관리하기 위한 기능성을 구현하기 위한 디지털 지갑을 포함하거나 구현하도록 클라이언트, 클라이언트 엔티티, 컴퓨팅 디바이스들 또는 클라이언트와 연관된 단말에 요구한다. 또한, 클라이언트 디바이스가 블록체인 트랜잭션 구조를 구현하고 BSV 라이브러리들에 대한 액세스를 가질 수 있도록 하는 요건이 있다. 따라서 클라이언트들은 이러한 기능성을 구현하기 위한 프로세싱을 포함할 필요가 있을 뿐만 아니라, 이들은 데이터 및/또는 디지털 자산들 ― 이들은 실세계 자산 트랜잭션을 표현하는 스마트 계약 또는 토큰과 관련이 있음 ― 을 전송, 수신 및 보기 위해 블록체인 네트워크를 사용하기 전에, 이러한 프로세스들에 대해 적절한 보안 조치들이 구현되는 것을 보장할 필요가 있다.
따라서, 계산적으로 정교하든 그렇지 않든 간에, 계산적 및 기능적으로 덜 부담되는, 간단하고 빠르고 정확하며 신뢰할 수 있고 안전한 방식으로, 임의의 클라이언트가 블록체인과 연관된 유용한 애플리케이션들에 즉각적으로 액세스하고 상호작용할 수 있도록 허용하는, 안전하고, 복잡성이 낮고, 사용자 친화적이고, 효율적이며 견고한 기술들을 구현하고자 하는 바람이 있다. 보다 구체적으로, 분산 원장(블록체인) 기술, 및 레코드들의 증가된 보안, 투명성 및 신뢰성의 이점들을 이용하여, 임의의 클라이언트 컴퓨팅 디바이스가, 클라이언트와 연관된 임의의 데이터, 이벤트 또는 디지털 자산이 즉각적으로 그리고 안전하게 채굴되거나 블록체인 내로 기록되고 그리하여 그에 관한 영구적이고, 변조 방지되며 감사 가능한 레코드 ― 이는 요구에 따라 생성되고, 기록되고, 업데이트되고, 판독되고 또는 볼 수 있음 ― 를 제공하도록 보장하는 것을 가능하게 하는 복수의 블록체인 관련 서비스들 또는 애플리케이션들을 위한 공통 플랫폼 또는 인터페이스를 제공하고자 하는 바람이 있다.
이러한 개선된 솔루션이 이제 창안되었다. 본 개시내용은 하나 이상의 기술들을 제안함으로써 위의 기술적 문제를 해결하고, 그에 의해, 클라이언트와 연관된 정보 또는 데이터가, 블록체인과 연관된 모든 이점들을 여전히 이용할 수 있으면서, 이러한 클라이언트가 블록체인을 사용하기 위한 임의의 프로세싱 또는 기능성을 구현할 필요 없이도 블록체인과 연관된 하나 이상의 서비스에 대한 API(application programming interface)를 제공하는 방법들, 디바이스들 및 시스템들에 의해, 간단하고 안전하며 즉각적으로, 블록체인 내로 기록되거나 블록체인으로부터 획득될 수 있다.
제1 양상에서, 본 개시내용은 서비스에 대한 HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷으로 클라이언트 요청을 수신할 수 있는 API(application programming interface)와 연관된 플랫폼 프로세서를 사용하여; 블록체인과 연관된 복수의 서비스들을 제공하는 플랫폼을 구현하기 위한 방법들, 디바이스들 및 시스템들을 제안한다. 요청 및/또는 클라이언트의 아이덴티티의 적절한 검증에 더하여, 요청된 블록체인 서비스에 대한 목적지 어드레스 또는 엔드포인트가 결정되고, 출력 스크립트를 획득하기 위해 목적지 어드레스에 기초하여 적어도 하나의 블록체인 트랜잭션이 생성된다. 그 후 출력 스크립트에 기초한 결과는 HTTP 송신 프로토콜 포맷으로 주어진 클라이언트에 전송된다.
제2 양상에서, 본 개시내용은 블록체인을 이용하여 구현되는 이벤트 스트림(ES)과 관련되고 클라이언트로부터의 HTTP 요청에 기초하여 클라이언트에 대한 블록체인과 연관된 트랜잭션들에 대해, 데이터-기록 서비스를 구현하기 위한 방법들, 디바이스들 및 시스템들을 제안하며, 여기서 이벤트 스트림은 FSM(Finite State Machine)을 표현하거나 추적하는 데 사용될 수 있다. 예컨대, 이 FSM은 스마트 계약일 수 있다. 블록체인 상의 이벤트 스트림의 현재 상태(ESn)가 결정되고 이벤트 스트림(ES)에 대한 새로운 또는 다음 이벤트(En+1)가 수신된 요청에서 식별되고 이벤트 스트림(ES)에 대해 이전 트랜잭션(TX)으로부터의 트랜잭션 출력과 관련된 입력 및 새로운 이벤트(En+1)를 표현하는 이벤트 데이터와 연관된 미지출 출력(UTXO)을 포함하는 블록체인 트랜잭션을 생성함으로써 프로세싱된다. 블록체인에 제출되면, 블록체인 상의 이벤트 스트림의 현재 상태는 새로운 이벤트(En+1)에 기초하여 ESn+1로 업데이트된다. 결과는 현재 상태(ESn+1)와 연관되며, 이 결과는 HTTP 송신 프로토콜 포맷으로 제공된다.
제3 양상에서, 본 개시내용은 블록체인을 사용하여 구현되는 이벤트 스트림을 제공, 생성, 업데이트 및/또는 종결하고, 이벤트 체인과 연관된 이벤트들의 변조 방지 로그 또는 레코드를 생성하기 위한 방법들, 디바이스들 및 시스템들을 제안한다. 이벤트 스트림(ES)에 대한 이벤트(En)는 수신된 요청에서 식별되고 이벤트 스트림(ES)의 현재 길이를 표현한다. n = 0이어서, En이 이벤트 스트림(ES)을 생성하기 위한 제1 이벤트인 경우, 더스트 출력인 미지출 출력을 포함하는 블록체인 트랜잭션이 생성된다. 0 < n ≤ N ― 여기서 N은 n에 대한 최종 또는 최대 값임 ― 이어서, En은 이벤트 스트림(ES)을 수정하기 위한 이벤트인 경우, 이벤트 스트림에 대한 이전 트랜잭션과 연관된 더스트 출력을 지출하는 제1 입력을 포함하는 블록체인 트랜잭션이 생성되고; 미지출 트랜잭션 출력은 현재 트랜잭션에 대한 더스트 출력이고; 및 미지출 트랜잭션 출력은 현재 이벤트(En)를 표현하는 이벤트 데이터와 연관된다. n=N이어서, En이 이벤트 스트림(ES)을 종결하기 위한 이벤트인 경우, 이벤트 스트림에 대한 이전 트랜잭션과 연관된 더스트 출력을 지출하는 제1 입력을 포함하는 블록체인 트랜잭션이 생성되고; 미지출 트랜잭션 출력은 정의된 더스트 출력 제한을 초과하는 디지털 자산과 연관된다. 생성된 트랜잭션이 수락되고 그리고/또는 블록체인에 제출되면, 트랜잭션과 연관된 결과는 HTTP 송신 프로토콜 포맷으로 제공된다. 일부 실시예들에서, 이벤트 스트림 내 하나 이상의 트랜잭션들은 수락되거나 주어진 이벤트 스트림에 대한 유효한 트랜잭션인 동안, 블록체인에 즉시 제출되지 않는다. 예컨대, 이벤트 스트림 내 트랜잭션들은 주어진 수 또는 트랜잭션들 또는 시간이 경과한 후, 즉 예컨대, 이벤트 스트림 내 트랜잭션이 25번 정도 발생한 후 블록에 제출될 것이다. 트랜잭션들은 수 또는 시간이 경과할 때까지 멤풀(mempool)에 홀딩될 수 있다. 다른 실시예들에서, 이벤트 스트림 내 트랜잭션이 블록체인에 즉각적으로 제출되는 것이 가능하다.
제4 양상에서, 본 개시내용은 원자적 블록체인 트랜잭션을 사용하여 블록체인과 연관된 다수의 이벤트 스트림들을 동기화하기 위한 방법들, 디바이스들 및 시스템들을 제안한다.
제5 양상에서, 본 개시내용은 블록체인과 연관된 복수의 서비스들을 하나 이상의 클라이언트들에게 제공하는 플랫폼과 연관된 블록체인 트랜잭션들의 검증을 위한 방법들, 디바이스들 및 시스템들을 제안한다.
본 명세서 전반에 걸쳐, 단어 "포함하다(comprise)", 또는 "포함하다(includes)", "포함하다(comprises)" 또는 "포함하는(comprising)"과 같은 변동들은 언급된 요소, 정수, 단계, 또는 요소들, 정수들, 단계들의 그룹을 포함하지만, 임의의 다른 요소, 정수, 단계, 또는 요소들, 정수들, 또는 단계들의 그룹의 배제를 의미하지 않는 것으로 이해될 것이다.
본 개시내용의 양상들 및 실시예들은 이제, 단지 예로서만 그리고 첨부 도면들을 참조하여 설명될 것이다.
도 1은 제1 양상에 따라, 블록체인과 연관된 복수의 서비스들을 위한 플랫폼의 개요를 도시하는 개략도이다.
도 2a는 제1 양상에 따라, 플랫폼과 연관된 하나 이상의 프로세서들에 의해 구현되는 바와 같은, 블록체인과 연관되는 복수의 서비스들의 플랫폼을 제공하기 위한 방법을 도시하는 흐름도이다.
도 2b는 제1 양상에 따라, 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되는 바와 같은, 블록체인과 연관되는 복수의 서비스들의 플랫폼에 액세스하기 위한 방법을 도시하는 흐름도이다.
도 3은 제1 양상에 따라, 블록체인과 연관되는 복수의 서비스들의 플랫폼의 구성요소들을 도시하는 개략도이다.
도 4는 제2 양상에 따라, 플랫폼 서비스와 연관된 하나 이상의 프로세서들에 의해 구현되는 바와 같은, 블록체인과 연관된 트랜잭션들에 대한 데이터-기록 서비스를 구현하기 위한 방법을 도시하는 흐름도이다.
도 5는 제3 양상에 따라, 플랫폼 서비스와 연관된 하나 이상의 프로세서들에 의해 구현되는 바와 같은, 블록체인과 연관된 이벤트 스트림을 생성하기 위한 방법을 도시하는 흐름도이다.
도 6은 제3 양상에 따라, 플랫폼 서비스와 연관된 하나 이상의 프로세서들에 의해 구현되는 바와 같은, 블록체인과 연관된 이벤트 스트림을 업데이트하기 위한 방법을 나타내는 흐름도이다.
도 7은 제3 양상에 따라, 플랫폼 서비스와 연관된 하나 이상의 프로세서들에 의해 구현되는 바와 같은, 블록체인과 연관된 이벤트 스트림을 종결하기 위한 방법을 나타내는 흐름도이다.
도 8은 제2 또는 제3 양상에 따라, 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되는 바와 같은, 블록체인과 연관된 트랜잭션들에 대한 데이터-기록 서비스에 액세스하기 위한 방법을 도시하는 흐름도이다.
도 9는 제4 양상에 따라, 플랫폼 서비스와 연관된 하나 이상의 프로세서들에 의해 구현되는 바와 같은, 복수의 이벤트 스트림들을 동기화하기 위한 일 실시예에 따른 방법을 도시하는 흐름도이다.
도 10은 제4 양상에 따라, 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되는 바와 같은, 블록체인과 연관된 이벤트 스트림들을 동기화하기 위한 데이터-기록 서비스에 액세스하기 위한 방법을 도시하는 흐름도이다.
도 11은 제5 양상의 제1 실시예에 따라, 블록체인에 대한 서비스들의 플랫폼과 연관된 데이터의 독립적인 검증의 방법을 도시하는 흐름도이다.
도 12는 제5 양상의 제2 실시예에 따라, 블록체인에 대한 서비스들의 플랫폼과 연관된 데이터의 독립적인 검증의 방법을 도시하는 흐름도이다.
도 13은 제5 양상의 제3 실시예에 따라, 블록체인에 대한 서비스들의 플랫폼과 연관된 데이터의 독립적인 검증의 방법을 도시하는 흐름도이다.
도 14는 본 개시내용의 다양한 양상들 및 실시예들이 구현될 수 있는 컴퓨팅 환경을 예시하는 개략도이다.
첨부된 청구항들이 아래에 상세히 설명된 본 개시내용의 제5 양상과 관련되지만, 제1 내지 제2 양상들에 대한 세부사항들의 상세한 논의는 독자에게 본 개시내용의 청구된 양상들 및 관련된 실시예들의 최대 및 완전한 이해를 제공하기 위해 본원에서 제공된다.
제1 양상에 따라, 본 개시내용은 블록체인과 연관된 복수의 서비스들의 플랫폼을 제공하기 위한 컴퓨터 구현 방법을 제공하며, 플랫폼은 복수의 클라이언트들을 위해 제공되고, 방법은 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다.
유리하게는, 플랫폼 프로세서 API는 웹 기반 상호 작용 인터페이스를 허용하는데 즉, 일부 실시예들에서, 하나 이상의 클라이언트들에 대한 웹 서비스로 구현될 수 있어서, 웹-기반 서비스들에 대한 표준 인터넷 통신 프로토콜들을 사용하여 인터넷을 통해 통신이 발생할 수 있다. 예컨대, 일부 실시예들에서, 애플리케이션 레벨, 또는 클라이언트와 서버(이 경우, 플랫폼 서비스) 사이의 층 이를테면, HTTP, HTTPS 등의 HTTP 메시지들 또는 요청들이 이송 층 프로토콜 이를테면, TCP/IP 등에 기초하여 송신 및 수신될 수 있다. 본원에서 HTTP 송신 프로토콜들 또는 HTTP API에 대한 참조는 TCP/IP, UDP, HTTPS 등과 같은 모든 표준 인터넷 통신 프로토콜들을 또한 요약한다.
일부 실시예들에서, 플랫폼 프로세서는 HTTP API 엔드포인트로서 구현된다. 일부 실시예들에서, 플랫폼 프로세서는 REST(Representational State Transfer) 엔드포인트로서 구현된다. 유리하게는, API는 REST 엔드포인트로서 구현될 수 있고, 그리하여 클라이언트가 표준 인터넷 또는 웹 기반 프로토콜들 이를테면, HTTP 또는 HTTPS를 사용하여 통신하도록 허용한다.
제1 양상의 방법은 복수의 클라이언트들 중 주어진 클라이언트로부터, 요청을 수신하는 단계를 포함하고, 요청은 복수의 서비스들 중 주어진 서비스에 관한 것이고, 주어진 클라이언트로부터의 요청은 HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷에 기초한다. 그 후, 클라이언트 아이덴티티 및/또는 요청(들)이 유효하다는 결정에 기초하여, 방법은 주어진 서비스와 연관된 목적지 어드레스를 획득하는 단계를 포함한다. 일부 실시예들에서, 목적지 어드레스는 IP 어드레스 또는 네트워크 어드레스 엔드포인트일 수 있다. 예컨대, 이는 엔드포인트 URI(universal resource identifier)일 수 있고, 웹 서버의 URL(universal resource location)을 포함할 수 있으며, 이로부터, 요청된 서비스가 요청된 서비스에 대해 지불 프로세서 또는 하나 이상의 다른 엔티티들(클라이언트를 포함함)에 의해 액세스될 수 있다.
일부 실시예들에서, 이 목적지 어드레스는 플랫폼 API 엔드포인트와 동일한 엔드포인트일 수 있다. 이는 플랫폼이 메인 또는 코어 서비스의 것과 같은 요청된 서비스를 제공하는 경우에 해당할 수 있다. 다른 실시예들에서, 플랫폼에 의해 제공되는 다수의 상이한 유형들의 서비스들 ― 각각이 상이한 프로세서들 또는 웹서버들에 의해 구현됨 ― 이 있는 경우, 목적지 어드레스는 플랫폼 API와 상이할 수 있으며, 이 플랫폼 API는 플랫폼과 연관되는 웹서버들 및 다른 프로세서에 대한 호스트 서버로서 작용할 수 있다. 이 경우, 플랫폼 프로세서는, 각각이 블록체인 상의 복수의 서비스들 중 주어진 서비스를 구현하도록 구성되고 각각이 개개의 프로세서에 고유한 특정 목적지 어드레스 또는 엔드포인트와 연관되는 복수의 프로세서들과 연관되거나 이들을 포함한다.
제1 양상의 방법은 출력 스크립트를 획득하기 위해 획득된 목적지 어드레스에 대응하는 적어도 하나의 블록체인 트랜잭션에 기초하여 주어진 서비스에 대한 요청을 프로세싱하는 단계를 더 포함한다. 일부 실시예들에서, 출력 스크립트는 요청된 서비스와 관련된 데이터와 연관되거나, 요청된 서비스의 결과는 UTXO에 포함되고 트랜잭션에 대한 이러한 데이터 또는 디지털 자산을 포함한다.
제1 양상에서, 출력 스크립트와 연관된 이 결과는 그 후 HTTP 또는 유사한 송신 프로토콜 포맷으로 주어진(요청하는) 클라이언트에 전송된다.
유리하게는, 본 개시내용의 제1 양상의 방법은, 하나 이상의 클라이언트들에 대한 API로서 제공되는 플랫폼을 구현함으로써, 클라이언트와 연관된 하나 이상의 프로세서들이 블록체인에 데이터를 기록하거나 그에 액세스하도록 플랫폼 프로세서에 의해 제공되는 웹 서비스를 사용하거나 가입(sign-up)하도록 허용한다. 플랫폼과 연관된 하나 이상의 프로세서들은 REST(Representational State Transfer) ― 이는 웹 서비스들 및 웹 기반 상호작용들을 개발하기 위한 아키텍처 스타일임 ― 와 같은(그러나 이에 제한되지 않음) 표준 기반 인터페이스 설계를 사용하여, 제공되고 있는 서비스들 중 하나 이상을 구현할 수 있다. REST API 맥락의 자원은 유형, 연관된 데이터, 다른 자원들에 대한 관계들 및 그 자원 상에서 동작하는 일 세트의 메서드(method)들을 갖는 오브젝트로서 정의될 수 있다. 따라서, 제1 양상의 플랫폼 프로세서에 의해 구현된 플랫폼 또는 서비스들은 유리하게는, 비트코인 SV(BSV) 블록체인과 같은 블록체인의 상태 또는 분산 원장에 액세스하고 애플리케이션 인터페이스를 통해 그 상태를 변경하고 이를 REST API로서 노출할 수 있는 동작들 또는 기능들을 트리거하기 위한 API 구현으로서 제공된다. 다시 말해, 플랫폼과 연관된 하나 이상의 서버들 또는 프로세서들은 이러한 서비스를 사용하기로 선택한 하나 이상의 클라이언트들에 대한 REST 엔드포인트로서 간주될 수 있다. 유리하게는, 클라이언트는 이에 따라 HTTP 또는 유사한 인터넷 커맨드들을 통해 플랫폼 서비스와 통신할 수 있다. 더 유리하게는, BSV, 비트코인, 블록체인 지식, ECDSA 또는 다른 암호화 키 관리 라이브러리들 또는 트랜잭션 구조 소프트웨어 이를테면, 디지털 지갑 소프트웨어 등은, 제공되는 서비스들 중 임의의 것에 대해 클라이언트에 의해 구현될 필요가 없다. 하나 이상의 프로세싱 자원들 또는 사용자 단말들을 사용하는 클라이언트는 클라이언트 신원(client identify)을 검증하기 위한 패스워드 보호 인가(password protection authorisation) 또는 표준 PKI(public key infrastructure)와 같은 일부 알려진 인증 기술들을 통해 플랫폼을 사용하도록 간단히 등록할 수 있다. 그 후, 클라이언트는 기본 HTTP 또는 이와 유사한 것을 통해 플랫폼 서비스와 간단히 통신할 수 있어야 한다.
일부 실시예들에서, 플랫폼을 통해 제공될 수 있는 블록체인과 연관된 서비스들의 일부 예들은 다음과 같다:
- 블록체인의 상태를 변경하기 위해 블록체인에 데이터를 기록/제출하기 위한 데이터 서비스;
- 블록체인의 현재 상태를 반영하는 데이터를 판독/획득하기 위한 데이터 서비스;
- 블록체인과 연관된 트랜잭션들에 대한 간략화된 지불 검증과 연관된 서비스들;
- 하나 이상의 이벤트 스트림들 및/또는 블록체인과 연관된 기계 판독 가능 계약들의 관리와 관련된 서비스들;
- 복수의 클라이언트들에 대한 디지털 지갑 프레임워크의 관리와 연관된 서비스들.
실시예들에서, 제1 양상의 플랫폼 프로세서와 연관된 다수의 프로세서들 또는 웹서버들이 있는 경우, 제1 양상의 방법은 HTTP 송신 프로토콜 포맷으로 클라이언트로부터 요청을 수신하는 단계, 수신된 요청을 RPC(Remote Procedure Call) 포맷으로 변환하는 단계, 및 수신된 요청에서 식별된 서비스를 구현하도록 구성된 복수의 프로세서들 중 주어진 프로세서로 RPC 요청을 전송하는 단계를 수행하기 위한 API(application programming interface) 변환기를 제공하는 단계를 더 포함한다. 역방향 흐름 경로에서, 이 실시예는 RPC 포맷으로 주어진 프로세서로부터 연관된 응답을 수신하는 것, 그리고 HTTP 또는 유사한 송신 프로토콜을 사용하여 클라이언트에 전송될 개개의 응답을 변환하는 것을 포함한다.
이는, 클라이언트가 웹 서비스들에 대한 인터넷 프로토콜 통신 표준들을 사용하여 통신하지 않지만, 위에서 설명된 서비스들을 구현하는 노드들 또는 서버들 중 임의의 것과의 상호운용성(interoperability)을 원활하게 제공하고 웹-기반 플랫폼 API를 사용하여 간단한 HTTP를 통해 블록체인과 연관되는 요청들을 통신하도록 허용하기 때문에 유리하다. 이 실시예에서 구현된 API 변환기는 HTTPS로부터 RPC로 또는 그 반대로의 변환, 또는 그 점에 대해서, 다른 웹-기반 프로토콜들로부터, 위의 서비스들, 주어진 암호화폐에 대한 네트워크들, 또는 달리 구상될 수 있는 디지털 자산들 중 하나 이상을 구현하는 플랫폼 프로세서들에 의해 지원되는 대안적인 통신 프로토콜들로의 변환으로 제한되지 않는다. 역방향 흐름 경로에서, 제1 양상의 방법은 또한, 개개의 프로세서로부터의 대응하는 블록체인 트랜잭션과 연관된 응답들을 RPC 포맷으로 수신하고 클라이언트에 전송하기 위해 HTTP를 사용하여 개개의 응답들을 상응하게 변환하는 것을 포함한다. 따라서 유리하게는, 플랫폼 프로세서에 의해 제안된 인터페이스를 구현하는 것은 클라이언트들(수취인들) 및 채굴자들이 상이한 무선 데이터 통신 프로토콜들 및 메커니즘들을 사용할 때 블록체인에 트랜잭션들을 제출하기 위한 원활한 통신을 가능하게 한다.
제1 양상의 일부 실시예들에서, 클라이언트로부터의 수신된 요청은 위에서 언급된 바와 같이 플랫폼에 의해 제공되는 복수의 서비스들 중 요청된 주어진 서비스에 대한 서비스 식별자뿐만 아니라 주어진 클라이언트 특유의 클라이언트 식별자와 연관되거나 이를 포함하는 HTTP GET 또는 HTTP POST 또는 HTTP PUT 또는 HTTP PATCH 요청이다. 일부 실시예들에서, 클라이언트에 전송된 결과는 클라이언트 식별자에 기초한 HTTP POST 요청이다.
일부 실시예들에서, 블록체인 트랜잭션들에 대한 클라이언트 어드레싱을 더 간단하게 만들기 위해, 하나 이상의 클라이언트들 엔티티들에 대해 복잡한 공개 어드레스 대신 기억하기 쉽고 더 사용자 친화적인 별칭(alias)이 사용되는 메커니즘들이 이미 존재한다. 이러한 솔루션은 둘 모두가 nChain Holdings Limited의 이름으로 US 특허 출원 번호 제16/384696호 및 UK 특허 출원 번호 제1907180.2호에서 제안된다. 이 문서들은 bsvalias 지불 서비스로서 지칭되는 별칭-기반 지불 서비스 및 연관된 프로토콜들을 제시하며, 여기서 별칭은 클라이언트 엔티티의 공개 어드레스 대신 목적지 어드레싱을 위해 사용된다. 이러한 시스템의 별칭은 일반적으로 전송/수신 클라이언트 엔티티의 도메인 이름과 연관되고 URI 또는 이메일 어드레스일 수 있다. 따라서 전송자 또는 엔티티가 별칭을 인식하거나 그에 별칭이 제공되는 한, 이는 bsvalias 지불 시스템 또는 별칭 기반 어드레싱 메커니즘에 대해 충분하다. 메시지들은 예컨대, bsvalias 또는 다른 지불 서비스를 위해 잘 알려진 URI 또는 로케이션에 저장된, JSON(JavaScript Object Notation) 문서와 같은 기계 판독 가능 자원에 제공된 명령들을 사용하여 클라이언트의 별칭에 전송될 수 있다. 본 개시내용의 일부 실시예들에서, 복수의 클라이언트들 중 하나 이상은 개개의 클라이언트를 식별하기 위해 위와 같은 별칭을 가질 수 있다.
관련 실시예들에서, 제1 양상의 방법은 클라이언트 식별자 및 클라이언트 식별자에 대응하는 레코드 ― 레코드는 플랫폼 프로세서와 연관됨 ― 에 기초하여 클라이언트를 유효성 검증하는 것을 포함한다. 예컨대, 이러한 레코드는 클라이언트 가입 또는 등록 시에 생성되고 플랫폼 프로세서와 연관되거나 그에 저장될 수 있다. 그 후, 클라이언트의 성공적인 유효성 검증에 기초하여, 방법은, 개개의 레코드에 포함된 서비스 식별자 및 속성 또는 세팅에 기초하여 클라이언트로부터의 수신된 요청이 유효한지를 결정하는 것을 포함한다. 일부 실시예들에서, 상기 속성 또는 세팅은 주어진 클라이언트가 요청된 서비스의 전부 또는 일부에 대한 액세스를 허용받았는지 여부를 표시할 수 있다. 예컨대, 클라이언트 식별자와 연관된 하나 이상의 허가 레벨들이 속성 또는 세팅에서 제공될 수 있다. 예컨대, 주어진 클라이언트는 특정 이벤트에 대해 블록체인 상에 있는 데이터를 판독하기 위한 서비스를 요청하도록 허용될 수 있지만 그러한 이벤트를 수정, 삭제 또는 종결하도록 허용되지 않을 수 있는 반면, 다른 클라이언트는 하나 이상의 서비스들과 관련된 모든 액션에 대한 허가를 가질 수 있다.
일부 실시예들에서, 주어진 클라이언트의 아이덴티티를 검증하는 단계는 클라이언트와 연관된 디지털 서명에 기초할 수 있다. 각각의 클라이언트와 연관된 개인 키 및 공개 키(또는 공개 어드레스)를 포함하는 암호화 키 쌍들은 서비스에 대해 이루어진 요청이 실제로 주어진 클라이언트로부터 기원한 것임을 검증하는 데 사용될 수 있는데, 즉, 개인 키에 의해 서명된 데이터는 대응하는 공개 키를 사용해서만 복원되거나 유효성 검증될 수 있다. 검증이 디지털 서명에 기초하는 경우 표준 PKI(public key infrastructure) 기술들이 사용되고 구현될 수 있다.
제1 양상의 일부 실시예들에서, 복수의 클라이언트들 중 주어진 클라이언트의 하나 이상의 프로세서들에 의해 구현되는 바와 같은 복수의 서비스들의 플랫폼에 액세스하기 위한 컴퓨터 구현 방법은, 플랫폼과 연관된 하나 이상의 프로세서들과 연관된 API(application programming interface) 엔드포인트를 획득하거나 식별하는 단계, 및 복수의 서비스들 중 주어진 서비스와 관련된 요청을 전송하는 단계를 포함하고, 요청은 주어진 클라이언트에 대한 클라이언트 식별자, 및 요청된 주어진 서비스에 대한 서비스 식별자를 포함하거나 그와 연관된다. 위에서 언급된 바와 같이, 요청은 HTTP(Hypertext Transfer Protocol) 또는 유사한 송신 프로토콜 포맷을 사용하여 전송된다. 방법은 또한 요청과 연관된 블록체인 트랜잭션의 출력 스크립트와 관련된 결과를 수신하는 것을 포함하며, 상기 결과는 HTTP 송신 프로토콜 포맷으로 클라이언트에 제공된다.
제2 양상에서, 본 개시내용은 블록체인과 연관된 트랜잭션들에 대해 데이터-기록 서비스를 구현하기 위한 컴퓨터 구현 방법을 제공하며, 이 방법은 클라이언트들이 블록체인에 데이터를 기록하기 위한 서비스에 액세스하는 것을 가능하게 하도록 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다. 제2 양상의 방법은 클라이언트로부터 요청을 수신하는 단계를 포함하고, 요청은 블록체인을 사용하여 구현되는 이벤트 스트림(ES)과 관련되고, 클라이언트로부터의 요청은 HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷에 기초한다. 일부 실시예들에서, 이벤트 스트림은 유한 수의 상태들을 갖는 시스템을 표현하고 하나의 스테이지로부터 다음 스테이지로 트랜지션을 위한 트랜지션 기능 또는 트리거 이벤트를 통해 주어진 시간에 단 하나의 상태에만 있을 수 있는, 잘 알려진 컴퓨팅 용어인 FSM(Finite State Machine) 이를테면, DFA(Deterministic Finite Automaton)을 표현하거나 이를 추적할 수 있다. 일부 실시예들에서, 이러한 이벤트 스트림은 기술적 프로세스의 제어 수단 또는 기술을 표현하는데 데 유용하다. 일부 실시예들에서, 이벤트 스트림은 블록체인 상의 기계 판독 가능 계약 또는 스마트 계약과 연관된 입력들, 상태들 및/또는 이벤트들을 표현하거나 추적할 수 있으며, 여기서 유리하게는, 계약의 과거 및 현재 상태의 변경 불가능한 레코드가 레코딩된다. 일부 실시예들에서, 클라이언트로부터 수신된 요청은 이벤트 스트림과 연관된 스마트 계약에서 상태 트랜지션이 일어나는 것을 가능하게 하도록 트리거 이벤트를 포함한다.
제2 양상의 방법은 이벤트 스트림의 현재 상태(ESi=n)를 결정하는 단계를 포함하며, 여기서 i는 0 내지 N의 정수이고, 각각의 정수 i는 이벤트 스트림(ES)의 주어진 상태를 표현하고, 여기서 i = 0은 생성된 이벤트 스트림(ES)을 표현하고, i = n은 블록체인에서 현재 상태의 이벤트 스트림(ES)을 표현하며, i = N은 이벤트 스트림(ES)의 최종 상태를 표현한다. 일부 실시예들에서, 현재 상태의 결정은 이벤트 스트림과 연관된 가장 최근 결과에 기초한 현재 상태의 표시일 수 있으며, 상기 결과는 이벤트 스트림에 대한 하나 이상의 별개의 오프-체인 저장 자원들에 또는 블록체인 상에 저장된다. 이는 이벤트 스트림과 연관된 앞선 또는 이전 블록체인 트랜잭션의 식별자에 기초할 수 있다. 이벤트 스트림에 대해 식별된 이전 상태가 없는 경우, 이는 현재 상태가 n = 0, 즉 새로운 이벤트 스트림이 생성될 것이라는 결정을 초래할 것이다. 일부 실시예들에서, 현재 상태는 또한 블록체인으로부터 리트리브(retrieve)되거나 판독될 수 있다. 이는 위에서 설명된 바와 같이 데이터 판독기에 의해 수행될 수 있으며, 이는 플랫폼 프로세서에 의해 제공되는 복수의 서비스들 중의 서비스일 수 있다.
제2 양상의 방법에서, 수신된 요청에 기초하여 이벤트 스트림(ES)에 대한 새로운 이벤트(En+1)를 프로세싱하는 단계는 블록체인 트랜잭션(TXn + 1)을 생성하는 단계를 포함하며, 블록체인 트랜잭션(TXn+1)은 이전 트랜잭션(TXn)으로부터의 트랜잭션 출력(TXOn)과 연관된 입력, 및 새로운 이벤트(En)를 표현하는 이벤트 데이터와 연관되는 미지출 출력(UTXOn+1)을 포함한다. 일부 실시예들에서, n = 0인 경우, 이전 출력을 지출하는 입력은 존재하지 않을 것이다. 그러나 이벤트 스트림(ES)과 연관된 디지털 자산들을 표현하는 다른 입력들이 있을 수 있다. 그 후, 방법은 트랜잭션(TXn+1)을 블록체인에 제출하는 것을 포함한다.
일단 제출되면, 이벤트 스트림의 현재 상태는 제출된 블록체인 트랜잭션에 기초하여 업데이트되는데, 즉, 상태는 ESi =n = ESn+1이 되도록 새롭게 생성된 이벤트 En+1에 기초하여 ESi =n+1이 되도록 업데이트될 것이다. 일부 실시예들에서, 업데이트된 상태는 이벤트 스트림 내 최신 트랜잭션의 미지출 출력인 UTXOn+1에 존재하는 데이터에 기초한다. 그 후, 방법은 이벤트 스트림의 업데이트된 현재 상태(ESn+1)에 기초한 결과를 전송하는 것을 포함하며, 이 결과는 HTTP 송신 프로토콜 포맷에 기초하여 제공된다.
본 개시내용의 제2 양상은 플랫폼 프로세서에 의해 구현된 데이터-기록 서비스의 구현을 논의하거나 즉, 구현은 스마트 계약의 상태들을 제어하는 것과 같이 실세계 프로세스와 연관된 데이터를 기록하는 기능성을 가능하게 한다. 제2 양상의 플랫폼 프로세서는 제1 양상에서 논의된 것과 연관되며, 여기서 제2 양상은 복수의 블록체인 서비스들 중 하나, 즉 블록체인에 데이터를 기록하여 그의 현재 상태를 변경하는 것에 대해 논의한다. 요청 및 응답이 플랫폼에 대한 API를 사용하여 수신 및 제공됨에 따라, 제2 양상은 제1 양상과 연관된 모든 이점들을 제공한다. 게다가, 데이터-기록 서비스는 유리하게는, 효과로부터 트리거들 또는 이벤트들을 간단히 추출함으로써 하나 이상의 클라이언트들이 블록체인-구현 스마트 계약의 상태의 트랜잭션을 인에이블하도록 허용한다. 따라서 스마트 계약의 다양한 스테이지들의 변경 불가능한 레코드는 제2 양상의 데이터 기록 서비스에 의해 제공될 수 있다.
본 개시내용의 제3 양상은 이벤트 스트림들과 관련하여 제공되는 서비스에 대해 위에서 논의된 바와 같이, 제2 양상의 데이터-기록 서비스와 관련된다. 이 양상에서, 변조 방지 레코드 또는 로그, 또는 이벤트 스트림과 연관된 이벤트들의 순차적 발생을 확인하는 인증서를 설정하기 위한 기술이 개시된다. 따라서, 제3 양상에서, 본 개시내용의 방법은 블록체인을 사용하여 구현되고 이벤트 체인과 연관된 이벤트들의 변조 방지 로그 또는 레코드를 자동으로 생성하는 이벤트 스트림을 제공, 생성, 업데이트 및/또는 종결하기 위한 방법들, 디바이스들 및 시스템들을 제안한다.
제3 양상에서, 본 개시내용은 블록체인과 연관된 트랜잭션들에 대해 데이터-기록 서비스를 구현하기 위한 컴퓨터 구현 방법을 제공하며, 이 방법은 클라이언트들이 블록체인에 데이터를 기록하기 위한 서비스에 액세스하는 것을 가능하게 하도록 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다. 제3 양상의 방법은 클라이언트로부터 요청을 수신하는 단계를 포함하고, 요청은 블록체인 상의 이벤트 스트림(ES)과 관련되고, 클라이언트로부터의 요청은 HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷에 기초한다.
그 후 이벤트 스트림(ES)에 대한 이벤트(En)는 클라이언트로부터의 수신된 요청에서 식별된다. 이벤트 스트림(ES)에 대해, n은 이벤트 스트림(ES)의 현재 길이를 표현한다. n = 0이어서, En이 이벤트 스트림(ES)을 생성하기 위한 제1 이벤트인 경우, 더스트 출력인 제1 미지출 출력을 포함하는 제1 블록체인 트랜잭션이 이벤트 스트림(ES)에 대해 생성된다. 본 개시내용에 대해 블록체인 트랜잭션의 맥락에서 블록체인 트랜잭션 더스트 또는 단순히 "더스트"는 낮거나 미미한 값 ― 즉, 값은 블록체인에서 출력을 채굴하기 위한 수수료들보다 훨씬 낮을 수 있음 ― 의 출력을 갖는 디지털 자산 또는 암호화폐에 대한 지출 가능한 트랜잭션인 것으로 이해된다. 이 더스트 출력은 지출될 수 있는 암호화폐 또는 디지털 자산 출력의 최소 값일 수 있다. 일부 실시예들에서, 이러한 더스트 트랜잭션들과 연관된 디지털 자산 또는 암호화폐 자금들, 즉 그의 출력에서 디지털 자산의 최소 값의 이전을 처리하는 것들이 플랫폼 프로세서에 의해 제공되거나 관리될 수 있다. 즉, 블록체인 트랜잭션에 대해 본 개시내용에서 참조된 더스트 출력은 트랜잭션에 대한 값 제한 미만인 값을 갖는 디지털 자산과 연관되는데 즉, 아마도 더스트 출력의 값은 예컨대, 그러한 트랜잭션을 지출하는 데 요구될 수 있는 채굴 수수료보다 낮다.
0 < n ≤ N ― 여기서 N은 n에 대한 최종 또는 최대 값임 ― 이어서, En은 이벤트 스트림(ES)을 수정하기 위한 이벤트인 경우, 동일한 이벤트 스트림에 대한 이전 트랜잭션과 연관된 더스트 출력을 지출하는 제1 입력을 포함하는 현재 블록체인 트랜잭션이 생성되고; 제1 미지출 트랜잭션 출력은 현재 트랜잭션에 대한 더스트 출력이고; 및 최종 미지출 트랜잭션 출력은 현재 이벤트(En)를 표현하는 이벤트 데이터와 연관된다. 일부 실시예들에서, 이벤트 데이터는 데이터 캐리어 요소에 포함된다. 이는 트랜잭션의 지출 불가능한 OP-RETURN 출력일 수 있다. 일부 실시예들에서, 현재 블록체인 트랜잭션에 대한 최종 미지출 트랜잭션 출력 내 이벤트(En)에 대한 이벤트 데이터는 이벤트 데이터의 해시를 포함한다. 이는 유리하게는 이벤트 스트림(ES)의 이벤트 데이터 콘텐츠들을 비공개(private)로 유지한다. 일부 실시예들에서, 이벤트 스트림과 연관된 각각의 트랜잭션에 대해 플랫폼 프로세서에 의해 랜덤으로 생성될 수 있는 고유 값인 솔트(salt)가 또한 포함될 수 있다. 일부 실시예들에서, 상기 이벤트 데이터의 해시는 플랫폼 프로세서에 의해 적용되고, 그리하여 유리하게는 플랫폼 서비스 또는 프로세서들이 그러한 이벤트 데이터를 비공개로 홀딩하도록 허용한다. 다른 실시예들에서, 상기 이벤트 데이터의 해시는 플랫폼 프로세서에 의해 수신되는 요청에 포함되기 전에 클라이언트 디바이스에 의해 적용된다. 이는 유리하게는, 클라이언트가 요청 내 이벤트 또는 이벤트와 연관된 데이터를 비공개로 홀딩하고 심지어 플랫폼과도 공유하지도 않는 것을 가능하게 한다. 다른 실시예들에서, 최종 미지출 트랜잭션 출력 내 이벤트(En)에 대한 이벤트 데이터는 원시 이벤트 데이터를 포함하며, 이는 일단 블록체인에 기록되거나 제출되면 블록체인 상에서 공개적이다.
n=N이어서, En이 이벤트 스트림(ES)을 종결하기 위한 이벤트인 경우, 이벤트 스트림에 대한 이전 트랜잭션과 연관된 더스트 출력을 지출하는 제1 입력을 포함하는 블록체인 트랜잭션이 생성되고; 제1 미지출 트랜잭션 출력은 정의된 더스트 출력 제한을 초과하는, 즉 디지털 자산 또는 암호화폐의 정의된 또는 최소 값을 초과하는 디지털 자산과 연관된다. 유리하게는, 더스트 출력의 부재는 이벤트 스트림에 더 이상 추적할 것이 없음을, 즉 시퀀스에 더 이상 이벤트가 없음을 표현하기 때문에, 이 경우에 이벤트 스트림의 종결을 의미한다. 더스트 제한을 초과하는 제1 출력은 체인의 끝을 시그널링하는 것임을 규정한다. 또한, 최종 블록체인 트랜잭션은 어떠한 이벤트 데이터 출력도 갖지 않는데 즉, 데이터 캐리어 요소가 존재하지 않으며, 이는 유리하게는, 이것이 이벤트 스트림을 변경하기 위한 데이터 이벤트가 아니라 이벤트 스트림을 종결하기 위한 것임을 시그널링한다.
위에서 논의된 n에 대한 3개의 경우들 중 어느 경우든, 트랜잭션은 블록체인에 제출되고 트랜잭션과 연관된 결과는 HTTP 송신 프로토콜 포맷에 기초하여 제공된다. 일부 실시예들에서, 요청과 연관된 이벤트, 즉 E0, En 또는 EN 중 어느 하나는 개개의 요청과 관련된 단일 이벤트 또는 둘 이상의 이벤트들일 수 있다. 예컨대, 요청은 각각의 E0, En 또는 EN에 대한 2개 이상의 서브-이벤트들의 데이터 세트를 포함할 수 있다. 일부 실시예들에서, 결과는 트랜잭션의 이벤트 데이터 출력 또는 개개의 트랜잭션과 연관된 이벤트에 기초한다. 일부 실시예들에서, 리턴되는 임의의 결과 또는 이벤트 데이터는 트랜잭션의 지출 불가능한 OP_RETURN 출력에 홀딩될 수 있다. 이는 블록체인 상에 임의적 데이터를 기록하고 또한 트랜잭션 출력을 유효하지 않은 것으로서 표시하는 데 사용할 수 있는 스크립트 작업코드(Script opcode)이다. 다른 예로서, OP_RETURN은 트랜잭션 내에 데이터 및/또는 메타데이터를 저장하고 그리하여 메타데이터를 블록체인에 변경 불가능하게 레코딩할 수 있는 트랜잭션의 지출 불가능한 출력을 생성하기 위한 스크립트 언어의 작업코드이다. 메타데이터는 블록체인에 저장되기를 원하는 로그 또는 시간 엔트리 또는 문서를 포함할 수 있다. 이벤트 데이터 또는 결과는 일부 실시예들에서 개개의 트랜잭션의 지출 불가능한 출력에 포함된 페이로드인 것으로 간주될 수 있다. 이러한 출력은 해당 출력의 잠금 스크립트를 종결하는 작업코드 예컨대, 위에서 언급된 OP_RETURN에 의해 지출 불가능하게 될 수 있다. 그러나 다른 실시예들에서, 페이로드 또는 이벤트 데이터는 다른 방식들로 포함될 수 있다.
트랜잭션 내 더스트 출력들의 사용은 이들이 이벤트 스트림(ES)에 대해 발생할 때 모든 트랜잭션의 변경 불가능한 순차적 레코드를 유지하는 데 유리하며 핵심이다. 이는 트랜잭션들을 블록체인에 게시함으로써, 모든 블록체인 트랜잭션들이 타임 스탬핑되고 블록체인에서 순서대로 유지될지라도, 이것이 그의 순차적 순서의 보존을 보장하지 않기 때문이다. 이는 트랜잭션들이 상이한 시간들에 블록들 내로 채굴될 수 있기 때문이다. 따라서, 체인 내 블록들의 순서만이 블록체인에서 시간순으로 뒤따르며, 개별 트랜잭션들은 그렇지 않다. 반면에, 스마트 계약일 수 있는 이벤트 스트림에 대한 이벤트들의 정확한 순차적 순서를 추적, 레코드 및 감사하기 위해, 유리하게는 시퀀스 내 다음 트랜잭션의 제1 입력에 의해 지출되어야 하는 더스트 출력들의 사용은 트랜잭션의 순서가 시간순으로 추적되고 변조 방지 레코드가 생성되는 것을 보장한다. 이는 일단 블록 내로 채굴되면, 이전 트랜잭션으로부터 시퀀스 내 다음 트랜잭션으로 더스트의 지불은 비트코인 프로토콜 규칙들에 따라, 이벤트 스트림이 손상되었다는 것이 즉각적으로 드러냄 없이, 임베딩된 데이터 캐리어 요소의 시퀀스(이는 각각의 트랜잭션 내 최종 출력들임)가 재순서화될 수 없고 삽입들 또는 삭제들 ― 이들은 시퀀스를 변경할 수 있음 ― 이 발생하지 않을 수 없음을 보장하기 때문이다. 일부 실시예들에서, 비트코인 프로토콜 고유의 이중 지출 방지는 상이한 어드레스들 사이의 암호화폐(예컨대, 더스트)의 움직임 및 이에 따른 연관된 이벤트들이 시간 순서로 유지되는 것을 보장한다. 따라서 이는 일련의 이벤트 발생들의 로그, 사본 또는 복제뿐만 아니라 블록체인 상의 스마트 계약들의 보안을 개선한다.
일부 실시예들에서, 이벤트 스트림(ES)과 연관된 요청에 대해 사용될 계층적 결정론적 키 체인(K)이 결정된다. 이러한 키 체인은 주어진 이벤트 스트림에 고유하다. 시드 또는 부모(parent) 또는 마스터 키 쌍(K)으로부터의 암호화 개인/공개 키 쌍은 그 후 K = Kn = 0 to N이 되도록 각각의 연관된 이벤트에 대해 도출될 수 있으며, 여기서 n은 0 내지 N까지의 정수이고, 각각의 정수 n은 이벤트 스트림(ES)과 연관된 이벤트들의 현재 길이 또는 현재 수를 표현하며, 여기서 N은 n의 최대 또는 최종 값을 표현한다. 이는 유리하게는, 특정 이벤트 스트림에 대해 도출된 키들이 공통 마스터 또는 시드 키와 관련되고 각각의 개별 이벤트를 프로세싱하기 위해 도출될 수 있음을 보장한다. 이러한 방식으로, 유리하게는, 더스트 출력들과 연관된 잠금 스크립트는 현재 이벤트에 대해 도출된 키(Kn)로 보안되고, 제1 입력들은 각각 이전 키 쌍(Kn - 1)을 사용하여 이전 트랜잭션들로부터의 더스트 출력들을 지출한다. 이는, 출력들이 개개의 이전 트랜잭션들 특유의 대응하는 키 쌍으로만 지출될 수 있음을 보장한다.
일부 실시예들에서, 이벤트 스트림(ES)과 연관된 결과는 다음 중 적어도 하나를 확인하는 인증서를 포함한다:
- 이벤트(En)가 블록체인에 제출한 트랜잭션 식별자
- 블록체인의 헤더에 대한 트랜잭션의 머클 포함 증명
- 상기 트랜잭션이 포함된 블록 헤더의 사본
일부 실시예들에서, 제3 양상에 대해 위에서 논의된 바와 같이, 생성된 트랜잭션들 각각은 디지털 자산과 연관된 다른 입력들을 더 포함할 수 있다. 이는 플랫폼 프로세서에 의해 관리되는 오퍼레이셔널 플로트(operational float)에 기초하여 제공될 수 있다. 일부 실시예들에서, 이것은 트랜잭션 채굴 수수료들 및 블록체인에 대한 하나 이상의 다른 동작들 등을 커버하기 위해 지불 프로세서에 의해 유지 또는 제어되는 디지털 자산 또는 암호화폐 자원 또는 자금과 연관될 수 있다. 트랜잭션들은 또한 디지털 자산과 연관된 하나 이상의 변화 출력들을 가질 수 있다. 위에서 언급된 바와 같이, 최종 트랜잭션은 모든 변화 출력들을 갖는다.
일부 실시예들에서, 이벤트 스트림(ES)은 제출된 블록체인 트랜잭션과 연관된 트랜잭션 식별자에 기초하여 식별될 수 있다. 일부 실시예들에서, 이벤트 스트림(ES)과 연관된 상태는 또한 가장 최근에 제출된 블록체인 트랜잭션과 연관된 트랜잭션 식별자에 기초하여 식별될 수 있다.
일부 실시예들에서, 방법은 오프-체인 저장 자원에, 이벤트 스트림(ES)의 각각의 이벤트에 대한 결과(들)에 기초하는 로그 또는 레코드의 사본을 저장하는 것을 포함한다. 이 저장 자원은 플랫폼 프로세서와 연관되거나, 또는 클라이언트에 의해 요청될 때 리트리브되거나 요청될 수 있는 상이한 디바이스, 데이터베이스 또는 서비스에 있을 수 있다. 유리하게는, 이벤트 스트림의 결과들과 연관된 로그의 저장은 별개로 저장되어, 전체 블록체인을 다운로드하고 이벤트 스트림과 연관된 임의의 질의들에 대한 데이터를 선별하는 요건을 회피한다. 이벤트 스트림을 구현하는 블록체인 자체는 감사들 또는 데이터 검증 동안 상황들에서 체크될 수 있다. 그 후 백-업 또는 별개의 사본이 신속한 질의들을 위해 사용될 수 있다.
제4 양상에서, 본 개시내용은 블록체인과 연관된 복수의 이벤트 스트림들을 동기화하기 위한 컴퓨터 구현 방법을 제공하며, 이 방법은 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다. 제4 양상의 방법은 제3 양상에서 위에서 제시된 바와 같이 단일 이벤트 스트림을 추가하거나 수정하는 방법과 관련된다. 그러나, 제4 양상은 복수의 이벤트 스트림들에 걸쳐 랑데뷰 트랜잭션 또는 원자적 트랜잭션으로서 지칭되는, 단일 블록체인 트랜잭션을 사용하여 단일 또는 공통 이벤트에 기초하는 복수의 별개의 그리고 독립적으로 진행되는 이벤트 스트림들을 동기화하기 위한 기술에 관한 것이다. 제4 양상을 구현하기 위한 플랫폼 서비스를 위한 이 API는 제3 양상에 대해 위에서 참조된 동일 API일 수 있거나, 이벤트 스트림들을 동기화하기 위해 플랫폼 프로세서와 연관된 별개의 그리고 특정한 API일 수 있다.
제4 양상의 방법은 클라이언트로부터 요청을 수신하는 단계를 포함하며, 요청은 블록체인 상의 복수의 M개의 이벤트 스트림들과 관련된다. 일부 실시예들에서, 클라이언트로부터의 요청은 HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷에 기초한다. 블록체인과 연관된 복수의 기존 이벤트 스트림들(ESn =1 to M)을 업데이트하도록 클라이언트로부터 요청이 이루어지며, n은 1 내지 M의 정수이고, 여기서 M ≥ 2이다. 방법은 또한 요청으로부터, 복수의 M개의 이벤트 스트림들(ESn= 1 to M) 중 각각의 이벤트 스트림(ESn)에 추가될 현재 이벤트(En)를 획득하는 것을 포함한다.
위에서 언급된 바와 같이, 클라이언트는 프로세서, 컴퓨팅 자원, 소프트웨어 애플리케이션 또는 프로그램, 또는 이벤트 스트림에 액세스할 수 있거나 이벤트 스트림에 의해 추적되는 자원에 액세스하도록 인가된 다른 엔티티일 수 있다. 일부 실시예들에서, 제4 양상에 따른 동기화 요청에 대해, 참여중인 복수의 M개의 이벤트 스트림들(ESn =1 to M)을 대신하여 에이전트 또는 조정자로서 작용하는 스마트 계약은 또한 동기화 요청을 하는 클라이언트로서 간주될 수 있다.
클라이언트로부터의 요청은 복수의 이벤트 스트림들(ESn =1 to M) 각각에 대한 식별자를 포함하는 JSON 오브젝트로서 API에서 수신될 수 있는데, 즉 M개의 이벤트 스트림 식별자들이 요청을 표현하는 JSON 오브젝트에 포함될 것이다. 대부분의 경우들에서, 식별자들은 요청의 부분으로서 클라이언트로부터 수신된다. 일부 경우들에서, API는 클라이언트와 연관된 계정 또는 레코드로부터 복수의 M개의 이벤트 스트림 식별자들을 획득할 수 있다.
일부 실시예들에서, 클라이언트로부터의 요청은 또한 식별된 이벤트 스트림(ESn) 중 하나 이상에 대한 타겟 인덱스를 지정할 수 있으며, 타겟 인덱스는 동기화 요청에 대해 사용되는 개개의 이벤트 스트림(ESn)의 인덱스인데 즉, 타겟 인덱스는 현재 이벤트(En)가 추가될 주어진 이벤트 스트림 내 다음 가용 포지션을 표현한다.
일부 실시예들에서, 타겟 인덱스는 개개의 이벤트 스트림(ESn)의 시퀀스 번호와 등가이고, 동기화 요청을 위해 사용될 이벤트 스트림(ESn) 내 포인트를 식별한다. 대부분의 경우, 타겟 인덱스들은 요청의 부분으로서 클라이언트로부터 수신된다. 일부 경우들에서, API는 이벤트 스트림(ESn)으로부터 또는 이벤트 스트림(ESn)과 연관된 외부 로그로부터 자동으로 또는 직접 개개의 인덱스들을 획득할 수 있다.
일부 실시예들에서, 제3 양상과 유사하게, 각각의 이벤트 스트림(ESn)에 대해 사용되는 계층적 결정론적 키 체인이 결정된다. 이러한 키 체인은 복수의 M개의 이벤트 스트림들(ESn =1 to M) 중 주어진 이벤트 스트림에 대해 고유하다.
일부 실시예들에서, 이를테면, 제3 양상에 대해 또한 위에서 언급한 바와 같은 검증 체크들은 그의 개개의 키 체인(K) 또는 공개 키에 기초하여 각각의 이벤트 스트림(ESn)에 대해 수행된다. 일부 실시예들에서, 방법은 또한 복수의 이벤트 스트림들(ESn =1 to M) 중 각각의 이벤트 스트림(ESn)에 대한 다음 가용 인덱스 값이 요청에서 지정된 개개의 이벤트 스트림(ESn)에 대한 타겟 인덱스와 동일한지를 체크하기 위한 검증 단계를 포함할 수 있다. 일부 실시예들에서, 복수의 M개의 이벤트 스트림들(ESn =1 to M) 중 이벤트 스트림들의 서브세트가 지정된 타겟 인덱스 값을 가질 것이고 다른 것들은 그렇지 않을 가능성이 있다. 이 경우에, 그 서브세트에 대해서만, 타겟 인덱스가 체크될 것인 반면, 남은 것들에 대해, 임의의 다음 가용 인덱스의 사용이 장애를 야기할 수 없다.
예컨대, 자금들이 하나 X로부터 차감되고 남은 하나 Y에 추가되는, 즉 X로부터 Y로 이전되는 2개의 계정들 X 및 Y를 고려해보자. 본 실시예는 양 계정들을 동기화하기 위한 논리적 클록을 구현하는 데 사용될 수 있어서, 이전에 수반되는 계정들 각각의 상태를 검증하는 것이 가능할 수 있다. 차감되는 계정 X에 대해, X로부터의 차감 이벤트가 X 및 Y 둘 모두와 연관된 이벤트 스트림들에 추가되면, X에 대해 다음 가용 트랜잭션 인덱스가 제공되거나 레코딩된다. X에 대한 다음 가용 트랜잭션 인덱스는 참 또는 유효하기 위해서는 Y로의 이전이 완료될 때까지 변해서는 안 되는데, 즉, 계정 X와 연관된 이벤트 스트림 내 다음 이벤트는 계정 Y에의 자금들의 추가가 되어야 하며, 이 다음 가용 인덱스는 성공적이 되기 위해 클라이언트의 요청에서 X에 대해 지정된 타겟 인덱스(만약 제공된 경우)와 매칭되어야 한다. 타겟 인덱스가 제공되는 경우, 이는 그 후 차감 이벤트 이후 X에 대한 이벤트 스트림 내 트랜잭션들에 대해 사용될 다음 가용 인덱스 값에 기초하여 검증할 수 있다. 반면에 계정 Y, 즉 추가되는 계정의 경우, 차감 이벤트가 Y에 대한 이벤트 스트림에 레코딩된 후 Y에 대한 트랜잭션 인덱스는 제한 없이 자유롭게 증가한다. 예컨대, X로부터 차감 이벤트 후에 계정 Y에 지불되는 다른 자금들이 있고 그리하여 차감 이벤트 직후 Y에 대한 이벤트 스트림에서 추가 트랜잭션들이 발생할 수 있다. 이는 허용될 수 있으며 X로부터 Y로의 이전에 필요한 잔고 또는 이전에 영향을 미치지 않으므로 체크되지 않은 채로 둘 수 있다. 따라서 Y와 연관된 이벤트 스트림 내 트랜잭션들에 대한 인덱스 값들은 검증될 필요가 없을 수 있으며 따라서 이 목적을 위해 제공되지 않을 수 있다.
다수의 이벤트 스트림들을 동기화하기 위해 각각의 개별 이벤트 스트림(ESn)에 현재 이벤트(En)를 추가하는 것과 관련된 요청은 그 후 하나 이상의 검증 체크들이 복수의 이벤트 스트림들 내 모든 이벤트 스트림들(ESn =1 to M)에 대해 성공적인 경우 진행될 것이다. 그렇지 않으면, 이 방법은 오류 알림을 생성하고 이를 클라이언트에 전송하는 것을 포함한다.
그 후, 복수의 이벤트 스트림들 중 각각의 이벤트 스트림(ESn)에 대해, 방법은 개개의 이벤트 스트림(ESn)과 연관된 이전 블록체인 트랜잭션(TXn - 1)을 식별하는 것을 포함한다.
그 후, 방법은 복수의 M개의 이벤트 스트림들을 동기화하기 위해 복수의 M개의 이벤트 스트림들(ESn= 1 to M) 중 각각의 이벤트 스트림(ESn)에 추가될 현재 이벤트(En)에 대한 원자적 블록체인 트랜잭션(TXn)을 생성하는 것을 포함한다.
일부 실시예들에서, 복수의 M개의 이벤트 스트림들을 동기화하기 위해 현재 이벤트(En)와 연관된 이벤트 데이터는 복수의 M개의 이벤트 스트림들 각각에 대해 동일하다. 이는 예컨대, 동일한 환율 또는 동일한 통화를 사용하는 자금들 또는 디지털 자산들이 모든 이벤트 스트림들에 추가되거나 그로부터 제거되는 경우 그러할 수 있다. 다른 실시예들에서, 현재 이벤트(En)와 연관된 이벤트 데이터는 복수의 M개의 이벤트 스트림들 중 하나 이상에 대해 상이할 수 있다. 예컨대, M개의 이벤트 스트림들 중 하나 이상은 나머지에 상이한 환율을 적용할 수 있거나 현재 이벤트(En)에 대해 상이한 유형의 토큰 또는 디지털 자산 또는 암호화폐를 사용할 수 있다. 일부 경우들에서, 동기화에 대해 사용되는 현재 이벤트(En)와 연관된 이벤트 데이터가 전혀 없을 수도 있다. 이 경우에, 이벤트(En)는 메타데이터와만 연관될 수 있다. 메타데이터는 시간 또는 날짜, 또는 복수의 M개의 이벤트 스트림들에 대해, 주어진 이벤트가 주어진 시간에 추가되거나 수행되었으며 동일하거나 상이한 데이터가 있거나 데이터가 전혀 없다는 것을 검증하는 데 사용될 수 있는 임의의 다른 파라미터와 연관될 수 있다. 따라서 동기화 이벤트(En)는 동일한 이벤트 또는 실제로 상이한 이벤트들이 주어진 시점에서 복수의 M개의 이벤트 스트림 동기화를 제공하도록 원자적 블록체인 트랜잭션을 통해 추가되는 것을 보장하기 위한 논리적 타이머일 수 있다.
원자적 블록체인 트랜잭션(TXn)은 랑데뷰 트랜잭션으로서 또한 지칭되며, 다음을 포함한다:
- n = M개의 입력들 ― 각각의 n번째 입력은 개개의 이벤트 스트림(ESn)의 이전 트랜잭션(TXn-1)과 연관된 더스트 출력을 지출함 ― ,
- n개의 입력들 각각에 대해, 개개의 이벤트 스트림(ESn)과 연관된 원자적 트랜잭션(TXn)에 대한 n번째 더스트 출력인 개개의 미지출 트랜잭션 출력(UTXOn_dust), 및
- 현재 이벤트(En)를 표현하는 이벤트 데이터와 연관된 미지출 트랜잭션 출력(UTXOn_data).
더스트 입력 및 출력의 사용 및 이점들은 이미 제3 양상에서 언급되었다. 본 개시내용에서 논의된 모든 이벤트 스트림들에서, 더스트 입력들/출력들의 추적, 즉 더스트의 체인(chain-of-dust)인 트랜잭션들은 삽입/삭제 사후에 로그 내 엔트리들의 재순화를 방지하기 위해 사용된다. 제3 양상과 마찬가지로, 이벤트(En)는 트랜잭션의 지출 불가능한 OP-RETURN 출력을 포함하는 원자적 트랜잭션에 대한 데이터 캐리어 페이로드이다. 일부 경우들에서, 이벤트 데이터(En) 외에도, 개개의 스트림의 상태와 연관된 데이터를 포함하거나 저장하기 위해 입력마다 별개의 또는 부가적인 출력이 있을 수 있다. 위에서 언급된 바와 같이, 입력들/출력들 각각은 또한 이벤트 스트림에 대한 개개의 키로 보안될 수 있다.
그러나 제4 양상의 원자적 트랜잭션은 각각 상이한 이벤트 스트림과 관련된 다수의 더스트 체인들이 단일 블록체인 트랜잭션을 통과하도록 허용한다. 원자적 트랜잭션 내 각각의 개별 이벤트 스트림에 대한 추적성(traceability)을 보장하기 위해, 복수의 이벤트 스트림들(ESn =1 to M) 중 주어진 이벤트 스트림(ESn)에 대한 각각의 n번째 더스트 입력/출력 쌍은 원자적 블록체인 트랜잭션에서 그의 대응하는 인덱스 값과 연관된다.
유리하게는, 복수의 이벤트 스트림들(ESn =1 to M) 각각의 상태 또는 진행이 무엇이든, 제4 양상은 공통 이벤트(En) 또는 공통 이벤트(En)와 연관된 데이터 페이로드가 단일 블록체인 트랜잭션 내 복수의 이벤트 스트림들 각각에 추가될 수 있는 메커니즘을 제공한다. 이는 다수의 자원들 또는 엔티티들에 걸쳐 업데이트 또는 주어진 이벤트를 적용하고 그 후 이러한 다수의 자원들 각각에 걸쳐 데이터가 일관됨을 검증할 수 있게 되는데 유용한 애플리케이션에 유리하다. 이는 참여 이벤트 스트림들이 주어진 클라이언트 또는 계정에 의해 소유되거나 그와 연관되는 실시예들에서 가능하다. 일부 경우들에서, 다수의 이벤트 스트림들 중 하나 이상은 상이한 엔티티들에서 소유된다. 예컨대, 클라이언트는, 모든 입력이 동일해야 한다는 것을 스마트 계약의 규칙들이 지시하는 동기화를 개시하는 데 사용되는 스마트 계약과 연관될 수 있다. 이 경우에, 검증 엔티티는 모든 스트림들이 클라이언트에 의해 액세스될 수 없거나 소유되지 않는 경우에도, 체크 중인 스트림과 동일한 이벤트 또는 데이터가 다른 모든 스트림에 포함된다는 것을 추론할 수 있다. 일 예로는 다수의 은행 계좌들에 대한 자산과 관련된 차변 및/또는 대변 엔트리가 동일한 시점에 동일한 정보를 반영하고 관련된 모든 계좌들에 대해 동일한 트랜잭션을 사용하여 검증할 수 있도록 하는 것을 들 수 있을 것이다. 다른 예로는, 다수의 당사자들이 새로운 환율을 사용하는 데 동의하는 스마트 계약과 연관된 모든 클라이언트들 또는 계정들에 글로벌 변화가 적용되는 경우가 될 것이며, 여기서 각각의 계정은 개개의 주어진 당사자에 대한 별개의 이벤트 스트림에 의해 유지된다.
일부 실시예들에서, 클라이언트로부터의 요청과 연관된 각각의 이벤트 스트림(ESn)은 현재 이벤트(En)가 복수의 M개의 이벤트 스트림들(ESn =1 to M)에 추가될 때까지 또는 상기 복수의 이벤트 스트림들 내 이벤트 스트림들 중 하나 이상에 대해 오류 메시지가 생성될 때까지 임의의 다른 요청 또는 엔티티에 의해 액세스되거나 변경될 수 없는 상태로 유지되거나 잠금될 수 있다. 이는 유리하게는, 동기화가 일어날 때, 업데이트중인 각각의 이벤트 스트림의 이전 상태가 알려지고 예상되며 동기화 요청이 클라이언트로부터 전송된 이후 어떠한 변화들도 없다는 것을 보장한다.
일부 실시예들에서, 클라이언트로부터의 요청과 연관된 다수의 이벤트 스트림들에 대해, 요청에서 선택적으로 지정될 수 있는 시간 윈도우의 준수(compliance)가 체크될 수 있다. 요청이 프로세싱되는 시간이 시간 윈도우를 벗어나는 경우 오류 메시지가 생성될 수 있다.
그 후, 방법은 일부 실시예들에서, 현재 이벤트(En)를 복수의 M개의 이벤트 스트림들(ESn =1 to M) 각각에 추가하는 것에 응답하여, 이벤트 스트림들(ES) 각각에 대한 다음 가용 인덱스 값을 획득하는 것을 포함한다. 이는 그 후 복수의 M개의 이벤트 스트림들에 대해 획득된 다음 인덱스 값들의 응답 어레이로서 제공된다. 이는 유리하게는, 복수의 M개의 이벤트 스트림들이 업데이트되고 동기화되었다는 확인을 제공한다. 그것은 또한, 원자적 블록체인 트랜잭션 후 각각의 개별 스트림 이벤트에 대해 향후 요청들이 이루어질 수 있도록 이러한 스트림들 각각에 대한 새로운 또는 현재 인덱스 값을 제공한다. 일부 실시예들에서, 리턴된 인덱스 값은 동기화 요청이 실패하는 경우 유리하며, 예상치 못한 인덱스는 개개의 이벤트 스트림 내 다른 데이터와 재동기화할 필요성을 표시하는 데 사용될 수 있다. 일부 실시예들에서, 그러한 재동기화는 실패된 요청이 클라이언트에 의해 재시도될 수 있기 전에 요구될 수 있다.
일부 경우들에서, 응답 어레이는 다른 인가된 엔티티들에 의해 액세스될 수 있도록 별개로 또는 외부적으로 저장될 수 있다.
일부 실시예들에서, 원자적 블록체인 트랜잭션의 n = M개의 입력들 각각에 대한 더스트 입력 인덱스는 n번째 입력과 연관된 개개의 이벤트 스트림(ESn)에 레코딩된다. 이는, 더스트 입력 인덱스가 더스트 출력 인덱스 및/또는 이벤트 데이터 인덱스와 같이, 복수의 이벤트 스트림들(ESn =1 to M) 중 주어진 이벤트 스트림에 대한 다른 인덱스를 도출하는 데 사용될 수 있기 때문에 유리하다. 일부 실시예들에서, 원자적 블록체인 트랜잭션의 모든 인덱스들은 n번째 입력과 연관된 개개의 이벤트 스트림(ESn)에 레코딩된다.
일단 이벤트 스트림에 추가되면, 방법은 복수의 동기화된 이벤트 스트림들(ESn =1 to M) 각각과 연관된 결과를 클라이언트에 전송하는 것을 포함한다. 또한, 응답 어레이는 이 결과의 부분으로서 전송될 수 있다. 일부 실시예들에서, 결과는 추가로, 블록체인으로의 원자적 블록체인 트랜잭션(TXn)의 제출 또는 이벤트 스트림의 승인을 리턴한다.
제3 및 제4 양상들의 일부 실시예들에서, 이벤트 스트림과 연관된 데이터를 기록하기 위한 서비스에 액세스하기 위한 컴퓨터 구현 방법이 제공되며, 이는 복수의 클라이언트들 중 주어진 클라이언트의 하나 이상의 프로세서들에 의해 구현된다. 이 방법은 플랫폼의 하나 이상의 프로세서들과 연관된 API(application programming interface) 엔드포인트를 획득하거나 식별하는 단계, 데이터-기록 서비스와 관련된 요청을 전송하는 단계, 및 그 후 이벤트 스트림에 관련된 하나 이상의 이벤트들(En)에 대한 요청을 전송하는 단계를 포함한다. 제4 양상에 대해, 요청은 블록체인 내 복수의 M(M ≥ 2)개의 이벤트 스트림들을 이벤트(En)와 동기화하기 위한 요청을 포함한다. 위에서 언급된 바와 같이, 요청은 HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷을 사용하여 전송된다. 방법은 또한 요청된 이벤트(En)와 관련된 결과를 수신하는 것을 포함하고, 상기 결과는 HTTP 송신 프로토콜 포맷에 기초하여 수신된다. 일부 실시예들에서, 방법은 요청이 원시 데이터 대신에, 이벤트(En)에 대한 해시된 이벤트 데이터를 포함하도록, 요청되고 있는 이벤트(En)와 연관된 이벤트 데이터에 해시 함수를 적용하는 단계를 포함한다.
제4 양상에서, 요청이 공통 이벤트(En)를 추가하기 위해 M개의 이벤트 스트림들을 동기화하기 위한 것인 경우, 방법은 요청에서 복수의 M개의 이벤트 스트림들 각각에 대한 식별자들을 제공하는 것을 포함한다. 일부 경우들에서, 이용 가능한 경우, 각각의 개별 이벤트 스트림에서 이벤트(En)를 추가하기 위해 사용될 복수의 M개의 이벤트 스트림들 중 하나 이상에 대한 타겟 인덱스 값이 또한 포함된다.
본 개시내용의 제5 양상은 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법에 관한 것이다. 이 양상에서, 트랜잭션은 클라이언트와 연관되고 클라이언트는 제1 양상의 서비스들의 플랫폼과 연관된다.
제1 양상에서 위에서 언급된 플랫폼에 대한 기본 검증으로서 또한 지칭되는 제1 구현에서, 본 개시내용의 제5 양상은 검증될 트랜잭션(T)을 식별하는 단계 및 트랜잭션(T)과 연관된 인증서(C)를 획득하는 단계를 포함하는 방법을 제공한다. 인증서는 주어진 블록에 대한 블록 식별자 및 블록체인 내 주어진 블록에 트랜잭션(T)을 링크하는 포함 증명을 포함한다. 방법은 그 후, 블록체인에서 유효 블록들의 최장 체인을 결정하는 단계 및 주어진 블록이 최장 체인에 포함됨을 검증하는 단계를 포함한다. 일부 실시예들에서, 방법은 헤더 클라이언트를 사용하여 최장 블록체인을 소싱(sourcing)하는 단계를 포함한다. 헤더 클라이언트는 트랜잭션(T)과 연관된 블록 헤더들을 저장하도록 구성된 것이다. 최장 체인을 결정하는 다른 알려진 방법들이 또한 사용될 수 있고 제5 양상은 헤더 클라이언트를 사용하는 것으로 제한되지 않는다는 것이 이해될 것이다.
일부 실시예들에서, 제5 양상의 제1 구현은 트랜잭션(T)을 주어진 블록과 연관된 머클 루트(R)에 연결하는 인증서(C) 내 포함 증명으로부터 머클 루트(R')를 계산하는 단계를 포함한다. 이는 주어진 블록의 블록 헤더와 연관될 수 있다. 그 후, R = R'라는 결정에 기초하여, 방법은 R'가 주어진 블록에 포함됨을 검증하고, 그 후, 주어진 블록이 위에서 결정된 최장 체인에 포함됨을 검증하는 단계를 포함한다.
일부 경우들에서, R이 R'와 매칭하지 않고 그리고/또는 R'가 주어진 블록에 포함되지 않고 그리고/또는 주어진 블록이 최장 체인에 포함되지 않는다는 결정에 기초하여, 방법은 오류 메시지를 생성하는 단계를 포함한다.
유리하게는, 제5 양상은 엔티티 이를테면, 클라이언트 또는 검증자(그러나 이에 제한되지 않음)가, 트랜잭션이 실제로 블록체인에 제출되고 유효하다는 것을 검증하기를 원할 때 독립적인 검증 또는 교차-체크 또는 감사를 가능하게 한다. 검증은 플랫폼과 연관된 소스들로부터 또는 다수의 독립적인 소스들로부터 획득된 트랜잭션과 관련된 데이터에 기초할 수 있고 그리하여 검증 데이터에 대해 임의의 하나 또는 몇몇 엔티티들에 의존함 없이, 검증에 사용된 데이터가 사실이고 공평하다는 것을 보장한다. 이러한 방식으로, 클라이언트 또는 플랫폼 또는 데이터 서비스들이 손상되더라도, 인증서들 및 포함 증명들과 같이 별개로 획득된 검증 데이터에 대한 데이터가, 플랫폼을 통해 블록체인에 대한 커밋멘트 이후 클라이언트에게 제공되는 데이터에 대해 체크될 수 있는 경우에만 트랜잭션 검증이 성공될 것이고, 그렇지 않으면 트랜잭션 검증은 실패할 것이다.
일부 실시예들에서, 인증서(C)는 클라이언트와 연관된 로컬 저장소로부터 획득된다. 대안적인 실시예들에서, 인증서(C)는 클라이언트 및/또는 플랫폼과 연관되거나 그와 별개/독립적일 수 있는 검증자 엔티티와 연관된 저장소로부터 획득된다.
유리하게는, 소스가 플랫폼 외부에 있는 경우, 검증에 사용될 정보에 대해 플랫폼에 의존하지 않고 그리하여 검증의 정확성을 개선한다.
다른 실시예에서, 트랜잭션(T)에 대한 인증서(C)는 플랫폼과 연관된 저장소 또는 모듈로부터 획득된다. 이 옵션은 클라이언트가 인증서에 대한 액세스를 갖지 않는 경우, 즉 트랜잭션의 커밋멘트 후 결과를 획득하지 못하거나 획득하는 수단을 갖지 않는 경우, 또는 검증을 위해 요구되는 인증서와 같은 부가적인 데이터를 수신할 수단을 갖지 않는 경우에 유용할 수 있다. 이 경우에, 검증은 플랫폼으로부터 수신된 검증 데이터에 기초하여 클라이언트에 의해 또는 클라이언트에 대해 여전히 수행될 수 있다.
제5 양상의 제2 구현들에서, 본 개시내용의 방법은 위의 제1 양상뿐만 아니라 제2 양상에서 설명된 바와 같이, 플랫폼의 데이터 서비스들과 연관된 트랜잭션들에 대한 검증의 방법을 제공한다. 이는 또한 데이터 기록기 검증으로서 지칭된다. 제5 양상의 제2 구현은, 클라이언트와 연관된 데이터(D), 즉 클라이언트와 연관된 페이로드 또는 요청 데이터를 획득하는 단계 및 그 후 데이터(D)에 기초하여, 블록체인(d)에 커밋되는 데이터 값을 결정하는 단계를 포함한다. 일부 경우들에서, d가 D와 동일할 수 있고, 다른 경우들에서, d가 솔트 또는 해시 함수와 연관될 수 있거나 솔티드(salted)가 D의 값을 가지며, 여기서 솔트는 비밀 세트 또는 임의적 값과 연관되고 해시는 SHA 256과 같은 하나 이상의 알려진 해시 함수들일 수 있다. 그 후 방법은 커밋된 값(d)과 연관된 트랜잭션(T)을 추출하거나 식별하는 단계를 포함한다.
제2 구현은 제1 구현과 동일한 유용한 이점들을 제공하고, 게다가 플랫폼의 데이터 기록기를 사용하여 블록체인에 커밋된 트랜잭션들에 대한 검증들을 구체적으로 수행하는 방식을 제공한다.
제5 양상의 제3 구현들에서, 본 개시내용의 방법은 위의 제2 내지 제4 양상들에서 설명된 바와 같이, 플랫폼과 연관된 이벤트 스트림들과 연관된 트랜잭션들에 대한 검증의 방법을 제공한다. 이는 또한 이벤트 스트림(ES) 검증으로서 지칭된다. 제3 양상과 유사하게, 제5 양상의 제3 구현은 제1 구현 즉, 기본 검증의 방법을 사용하여 ES0과 연관된 제1 트랜잭션(T0)의 포함을 검증함으로써 이벤트 스트림(ESn=0 to N)의 생성을 검증하는 단계를 포함하며, 여기서 n은 0 내지 N의 정수이고, n은 이벤트 스트림의 길이를 표현하며, 여기서 0은 최초 또는 생성 이벤트이고 N은 최종 또는 종결 이벤트이다. 방법은 제1 트랜잭션(T0)에 대한 제1 입력이 더스트가 아니라고 결정하는 단계; 및 그 후 제1 트랜잭션(T0)에 대한 제1 입력이 더스트인 경우 T0의 제1 출력이 더스트라고 결정하는 단계를 더 포함하고, 그리고/또는 T0의 제1 출력이 더스트가 아닌 경우, 방법은 오류 메시지를 생성하는 단계를 포함한다. 오류가 생성되지 않은 경우, 이벤트 스트림(ESn=0 to N)에 대해 클라이언트와 연관된 이벤트에 대한 각각의 n번째 데이터 엔트리(Dn)에 대해, 제2 구현에 따른 방법, 즉 데이터 기록기 검증이 수행된다. 방법은 그 후, n > 0일 때, 이벤트 스트림(ESn) 내 n번째 트랜잭션(Tn)에 대응하는 입력이 이전 트랜잭션(Tn-1)과 연관된 출력을 지출함을 검증하는 단계를 포함한다.
일부 실시예들에서, 제3의 방법은 제1 구현의 기본 검증을 사용하여 이벤트 스트림(ESN)과 연관된 최종 트랜잭션(TN)의 포함을 검증함으로써 ESN의 마무리(closure)를 검증하는 단계를 더 포함한다. 그 후, 방법은 제1 트랜잭션(TN)에 대한 제1 입력이 더스트이고 T0의 제1 출력이 더스트가 아니고; 그리고 이벤트 스트림(ESN) 내 최종 N번째 트랜잭션(TN)에 대응하는 입력이 이전 트랜잭션(TN-1)과 연관된 출력을 지출한다고 결정하는 단계를 포함한다. 제1 트랜잭션(TN)에 대한 제1 입력이 더스트가 아니고 그리고/또는 TN의 제1 출력이 더스트인 경우, 오류 메시지가 생성된다.
제5 양상의 제3 구현은 제1 및 제2 구현과 동일한 유용한 이점들을 제공하고 게다가, 플랫폼을 사용하여 블록체인에 커밋된 이벤트 스트림들과 연관된 트랜잭션들에 대한 검증들을 구체적으로 수행하는 방식을 제공한다. 이벤트 스트림은 위의 방법들을 사용하여 검증될 수 있는 이벤트들의 시퀀스의 로그를 제공한다.
제5 양상의 제1, 제2 및 제3 구현은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현될 수 있다. 다른 실시예에서, 제1, 제2 및 제3 구현은 검증자 엔티티와 연관된 하나 이상의 프로세서들에 의해 구현될 수 있다. 검증자 엔티티는 클라이언트 및/또는 플랫폼으로부터 독립적일 수 있다.
유리하게는, 제5 실시예는 플랫폼 또는 클라이언트와 관련되지 않은 모듈들 또는 엔티티들에 의해 수행될 수 있고, 그리하여 커밋된 트랜잭션을 검증하는 데 사용될 데이터의 임의의 하나의 소스에 의존하지 않고 무신뢰 구현(trust-less implementation)을 보장한다.
대안적인 실시예에서, 제5 양상과 연관된 제1, 제2 및 제3 구현은 플랫폼 그 자체와 연관된 하나 이상의 프로세서들에 의해 구현될 수 있다. 위에서 언급된 바와 같이, 이는 또한 검증 데이터에 대한 외부 데이터 소스들이 클라이언트 또는 검증자 엔티티에 대해 이용 불가능하거나, 오프라인이거나 다른 방식으로 손상된 경우에도 가능하다.
제5 양상에 따른 본 개시내용은 또한 하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법에 관한 것으로, 이 방법은 채널 프로세서에 의해 구현되고, 방법은, 하나 이상의 클라이언트들 중 주어진 클라이언트로부터 요청을 수신하는 단계 - 요청은 채널의 생성과 관련됨 - , 및 채널을 통해 주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 주어진 클라이언트에 제공하는 단계를 포함한다. 하나 이상의 기능들은, 데이터의 송신을 위해 채널과 관련된 채널 기능들 또는 절차들; 및/또는 채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함한다.
방법은 또한, 채널에 대한 하나 이상의 액세스 토큰들을 발행하는 단계를 포함하고, 상기 하나 이상의 액세스 토큰들은 채널을 통해 다른 엔티티와의 보안 통신을 위해 구성된다. 방법은, 주어진 클라이언트에 대해 채널과 연관된 하나 이상의 알림들을 저장 및/또는 제공하는 단계를 포함한다.
제5 양상에 따른 본 개시내용은 추가로, 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법에 관한 것일 수 있으며, 이 방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현된다. 방법은 주어진 클라이언트와 다른 엔티티 사이의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 채널 서비스 액세스를 획득하는 단계를 포함하며, 상기 하나 이상의 기능들은 데이터의 송신을 위한 채널에 관련된 채널 기능들 또는 절차들 및/또는 채널들을 사용하여 송신되는 데이터에 관련된 메시지 기능들 또는 절차들을 포함한다. 방법은, 하나 이상의 액세스 토큰들을 채널 서비스로부터 획득하는 단계를 포함하고, 상기 액세스 토큰들은 다른 엔티티와의 보안 통신을 가능하게 한다. 클라이언트와 연관된 주어진 트랜잭션에 대한 트랜잭션 식별자를 획득하거나 식별하는 것에 응답하여, 방법은, 채널 프로세서로부터 수신된 하나 이상의 채널 기능들을 사용하여, 다른 엔티티와의 통신을 위해 주어진 채널을 생성하는 단계, 및 주어진 채널과 연관된 하나 이상의 액세스 토큰들을 다른 엔티티에 전송하는 단계를 포함한다. 방법은 주어진 채널과 연관된 알림을 수신하는 단계를 포함하고, 알림은 주어진 트랜잭션과 연관된 주어진 채널 내 데이터에 관한 것이며, 상기 데이터는 주어진 트랜잭션이 블록체인에 포함된다는 검증을 위해 제공된다.
유리하게는, 채널들의 사용은 클라이언트들이 블록체인에 대한 어떠한 프로세싱 또는 기능성을 구현할 필요 없이, 채널 또는 메시징 서비스에 대한 인터페이스 또는 기능들을 제공하면서 여전히 이와 연관된 모든 이점들을 이용할 수 있는 방법들, 디바이스들 및 시스템들에 의해, 이러한 클라이언트들에 대한 직접 또는 피어-투-피어 통신을 가능하게 한다. 제5 양상에서 검증에 사용되는 데이터 또는 클라이언트와 연관된 정보는 블록체인으로부터 클라이언트를 분리하는 동안 간단하게, 안전하게, 그리고 즉각적으로 블록체인 내로 기록되거나 블록체인으로부터 획득될 수 있다.
채널 서비스는 별개의 채널 프로세서에 의해 제공될 수 있거나, 위에서 언급된 플랫폼 및 또는 플랫폼 프로세서에 의해 제공될 수 있거나, 또는 클라이언트와 통합될 수 있거나, 또는 클라이언트 및/또는 플랫폼과 별개로/독립적으로 구현될 수 있다. 채널들은 인증서들의 전달 또는 클라이언트 데이터의 제공 등과 같이 검증을 위해 요구되는 데이터 또는 메시지들의 전달을 위한 엔티티들 간의 직접 또는 피어 투 피어 통신 경로들 또는 세션들을 가능하게 한다. 대부분의 실시예들에서, 각각의 채널에 대해 단 2개의 엔티티들만이 있다. 채널 서비스 및/또는 채널 프로세서의 예는 nChain Holdings Limited의 이름으로 출원되고, 그의 청구 대상이 인용에 의해 본원에 포함되는 영국 특허 출원 번호 제2007597.4호에서 상세히 설명된다.
액세스 토큰들 및, 특히 API 토큰들은 일부 실시예들에서, 채널에 대한 액세스를 요청하는 엔티티 또는 애플리케이션에 대한 고유 식별자들로서 작용할 수 있다. 일부 실시예들에서, 액세스 토큰은 클라이언트에 할당된 고유한 인증 크리덴셜들인 것으로 간주될 수 있으며, 개별 채널들 또는 각각의 채널의 개별 메시지만큼의 입도(granular)일 수도 있다. 일부 실시예들에서, 액세스 토큰들은 클라이언트가 인증을 위해 그의 채널들 각각에 대해 다른 엔티티에 이러한 토큰들을 제공할 수 있도록 이루어질 수 있다.
제5 양상에서, 위에서 제시된 채널은 트랜잭션(T), 트랜잭션 식별자(TxID), 클라이언트 데이터(D), 인증서(C), 포함 증명들 등과 같은 검증 데이터의 요청 또는 제공 또는 트랜잭션을 위해 사용되도록 클라이언트 또는 검증자 엔티티에 의해 설정될 수 있다.
본 개시내용의 양상들은 또한, 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스를 포함하며, 메모리는 프로세서에 의한 실행의 결과로서, 디바이스로 하여금 위에서 논의된 바와 같은 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 컴퓨팅 디바이스는 플랫폼 프로세서와 관련된다.
본 개시내용의 양상들은 또한, 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스를 포함하며, 메모리는 프로세서에 의한 실행의 결과로서, 디바이스로 하여금 위에서 논의된 바와 같은 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 컴퓨팅 디바이스는 클라이언트와 관련된다.
본 개시내용의 양상들은 또한 컴퓨터 시스템을 포함하며, 이는 무선 통신 네트워크를 통해 적어도 하나의 클라이언트에 통신 가능하게 커플링된 적어도 하나의 플랫폼 프로세서 ― 적어도 하나의 플랫폼 프로세서는 적어도 하나의 클라이언트로부터의 HTTP 요청들을 프로세싱하기 위한 API(application programming interface) 엔드포인트와 연관되고, 적어도 하나의 플랫폼 프로세서는 위에서 언급된 컴퓨팅 디바이스에 따라 구현됨 ― ; 및 위에서 언급된 클라이언트 컴퓨팅 디바이스에 따라 구현되는 적어도 하나의 클라이언트를 포함한다.
본 개시내용의 양상들은 또한 실행 가능한 명령들이 저장되어 있는 컴퓨터-판독 가능 저장 매체를 포함하며, 명령들은 컴퓨터의 프로세서에 의해 실행된 결과로서, 컴퓨터로 하여금 위에서 제시된 양상들 및 실시예들 중 임의의 것의 방법을 수행하게 한다.
일부 특정 실시예들은 이제, 유사한 참조 번호들이 유사한 특징들을 지칭하는 첨부 도면들을 참조하여 예시의 방식으로 설명된다.
제1 양상 ― 블록체인과 연관된 복수의 서비스들을 위한 플랫폼 API
제1 양상에 대해 위에서 설명된 복수의 서비스들을 제공하기 위한 플랫폼 프로세서는 유리하게는, BSV 블록체인과 같은 블록체인 네트워크를 사용하여 소프트웨어 제어 기술 시스템들 또는 스마트 계약들의 관리와 같은 유용한 실세계 비즈니스 및 기술 애플리케이션들의 신속한 전달을 가능하게 하는 PaaS(Platform as a Service) 및 SaaS(Software as a Service) 제안물일 수 있다. 플랫폼 서비스들의 개요는 시스템의 고레벨 개략도를 보여주는 도 1에서 볼 수 있다. 플랫폼 서비스들은, 서비스들이 하나 이상의 클라이언트들에 의해 액세스될 수 있게 하는 API(108)를 제공하는 플랫폼 프로세서(100)를 갖는다.
이 도면에 도시된 바와 같은 플랫폼 서비스들(100)은 3개의 서비스 패밀리들로 구성되며, 클라이언트 단부에서 어떠한 블록체인 기반 소프트웨어, 지식 또는 라이브러리들도 실제로 구현하지 않고도 사용자들 및 조직들이 블록체인의 고유한 속성들에 의해 제공되는 이점들을 쉽고 안전하게 이용할 수 있게 하는 것을 목표로 한다. 이러한 서비스는 다음과 같다:
- 상품 데이터 원장으로서 체인의 사용을 단순화하는 것을 목표로 하는 데이터 서비스(102).
- 비트코인 SV와 같은 디지털 자산에 의해 뒷받침되는 일반화된 컴퓨팅 프레임워크를 제공하는 것을 목표로 하는 컴퓨팅 서비스(104)
- 비트코인 SV와 같은 디지털 자산을 사용하여 트랜잭팅(transacting)하기 위한 엔터프라이즈-클래스 능력들을 제공하는 커머스 서비스들(106).
위에서 언급된 바와 같이, API가 웹 서비스로 구현되기 때문에, API에서 클라이언트의 HTTPS 프로토콜을 통해 또는 HTTPS 프로토콜을 사용하여 요청들이 수신될 수 있다. 그 후, 요청된 서비스들은 기본 소프트웨어(110)를 사용하여 하나 이상의 서비스 모듈들 또는 프로세싱 자원들(102-106)에 의해 구현되며, 이러한 기본 소프트웨어(110)는 블록체인과 연관되는데, 즉 블록체인과 연관된 트랜잭션들을 생성, 프로세싱 및 제출하기 위한 자원들, 라이브러리들 및/또는 키-관리 지갑 구현들을 구현하기 위한 것이다. 일단 프로세싱되면, 트랜잭션들은 (클라이언트가 임의의 그러한 기능성 또는 트랜잭션 라이브러리들을 구현하는 대신에) 블록체인 네트워크(112)에 제출될 수 있다. 기껏해야, 클라이언트는 암호화폐 또는 일부 다른 디지털 자산과 연관된 디지털 지갑 등을 구현할 수 있지만, 플랫폼 서비스(100)가 또한 클라이언트를 위해 디지털 자산을 제공 및 관리할 수 있기 때문에 이것이 필수적인 것은 아니다.
도 2a는 본 개시내용의 제1 양상에 관한 것이며, 도 1에 도시된 플랫폼(100)과 같이 블록체인과 연관된 복수의 서비스들의 플랫폼을 제공하기 위한 컴퓨터 구현 방법을 도시한다. 도 2a의 방법은 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다.
단계(202a)는 복수의 클라이언트들 중 주어진 클라이언트로부터 요청을 수신하는 것을 도시한다. 일부 실시예들에서, 클라이언트는 클라이언트와 연관된 하나 이상의 컴퓨팅 디바이스들, 자원들 또는 프로세서들일 수 있으며, 상기 클라이언트는 플랫폼 프로세서에 의해 제공되는 복수의 서비스들에 액세스하기 위해 등록 또는 가입되어 있다. 위에서 언급된 바와 같이, 플랫폼 프로세서는 각각이 비트코인 SV 블록체인과 같은 블록체인을 사용하여 구현되는 상이한 유형의 기능 또는 서비스를 제공하는 하나 이상의 프로세서들(이를테면, 도 1에서 보여지는 데이터, 컴퓨팅 및 커머스 서비스들을 위한 프로세서)일 수 있다. 단일 서비스에 대해 단 하나의 프로세서만 있는 것이 또한 가능하다. 플랫폼 프로세서가 플랫폼에 대한 URI와 같은 API 엔드포인트와 연관되기 때문에, 주어진 클라이언트의 요청은 HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷과 같은 표준 인터넷 프로토콜에 기초할 수 있다. 일부 실시예들에서, 요청은 클라이언트에 대한 식별자뿐만 아니라 요청된 서비스에 대한 식별자를 포함할 수 있다.
단계(204a)에서, 클라이언트가 플랫폼 프로세서 및 그것에 의해 제공되는 기능성을 사용하도록 등록된 유효 클라이언트인지를 확인하기 위해 클라이언트의 아이덴티티가 체크될 수 있다. 일부 실시예들에서, 이는 패스워드 보호 로그인 인증 등과 같은 알려진 인증 방법들에 기초할 수 있다. 이 경우에, 요청에 포함된 클라이언트 식별자 또는 별칭, 및 패스워드에 기초하여, 주어진 클라이언트에 대한 레코드가 생성될 수 있다. 유효성 검증은 API에서 수신된 패스워드가 레코드 내 패스워드와 매칭되는 것에 기초할 수 있다. 다른 실시예들에서, 암호화 개인/공개 키 쌍들에 기초하는 표준 PKI 기술들은 단계(202a)에서 클라이언트로부터 수신된 요청에 존재하는 디지털 서명을 유효성 검증하는 데 사용될 수 있다. 이 경우에, 클라이언트의 아이덴티티는 개인 키에 의해 서명된 요청이 공개 키를 사용하여 성공적으로 복원되거나 유효성 검증될 수 있는지를 체크함으로써 검증될 수 있다.
클라이언트 아이덴티티가 검증될 수 없거나 검증이 실패하는 경우, 단계(206a)에서, 요청은 더 이상 추가로 프로세싱되지 않는다.
클라이언트가 성공적으로 유효성 검증되는 경우, 단계(208a)에서, 단계(202a)에서 서비스에 대한 요청의 유효성이 체크된다. 이 단계는 주어진 클라이언트가 실제로 요청된 서비스를 이용 가능하도록 인가받았음을 보장하기 위한 것이다. 이에 대한 허가 또는 속성들은 개개의 클라이언트에 제공될 수 있거나 제공되지 않을 수 있는 액세스 레벨들 또는 서비스의 하나 이상의 유형들을 표시하기 위해 클라이언트에 대한 레코드에 존재할 수 있다.
요청이 요청 클라이언트에 대해 허용되지 않거나 유효하지 않은 것으로 밝혀지는 경우, 단계(210a)에서 요청이 더 이상 추가로 프로세싱되지 않는다.
위에서 제시된 클라이언트 및/또는 서비스를 유효성 검증하는 실시예들이 유용할지라도, 제1 양상의 동작을 위해 필수적인 것은 아니라는 것이 이해될 것이다. 일부 경우들에서, 단계들(204a 또는 208a)의 유효성 검증만이 수행될 수 있다. 일부 경우들에서, 어떠한 유효성 검사도 수행되지 않는다. 이 경우에, 임의의 클라이언트는 등록되었든 안되었든 간에, 이러한 액세스에 대한 적절한 지불 시에 서비스 또는 플랫폼을 사용할 수 있다.
단계(212a)에서, 목적지 어드레스 ― 이는 단계(202a)에서 요청된 서비스를 구현하는 것을 담당하는 서버 또는 프로세서에 대한 엔드포인트 URI일 수 있음 ― 가 획득된다. 일부 실시예들에서, 복수의 플랫폼 프로세서들이 있는 경우, 호스트 서버 또는 플랫폼 API는 식별된 서비스를 구현하도록 구성된 프로세서와 연관된 목적지 어드레스로 전송되도록, 수신된 요청을 RPC(Remote Procedure Call) 포맷으로 변환할 수 있다.
단계(214a)에서, 요청된 서비스는 그것을 담당하는 개개의 플랫폼 프로세서에 의해 프로세싱된다. 블록체인 트랜잭션은 담당 프로세서의 목적지 어드레스/엔드포인트에 기초하여 플랫폼 프로세서에 의해 획득되거나 판독되거나 생성되고, 이 트랜잭션에 대한 출력 스크립트가 획득된다. 도 2a가 이 단계에서 블록체인 트랜잭션을 생성하는 것을 지칭하지만, 본 개시내용의 제1 양상이 그러한 것으로 제한되지 않는다는 것이 이해될 것이다. 단계(202a)의 요청이 블록체인으로부터 데이터를 판독하거나 가져오는 것인 경우, 트랜잭션이 생성되지 않을 수 있고 데이터가 단순히 블록체인으로부터 판독되거나 획득될 수 있다. 생성된 블록체인 트랜잭션들 중 하나 이상에 대해 복수의 블록체인 트랜잭션들 또는 다수의 출력 스크립트들이 있을 수 있다.
단계(216a)에서, 출력 스크립트들은 결과로서 데이터 출력들을 포함할 수 있거나(예컨대, 데이터 캐리어 UTXO가 있을 수 있음), 결과는 트랜잭션 식별자들 또는 트랜잭션의 나머지 출력들에 기초하여 획득될 수 있다. 결과가 획득될 수 있는 트랜잭션들과 관련된 지출 불가능한 OP-RETURN 출력이 또한 있을 수 있다.
단계(218a)에서, 출력 스크립트와 연관된 결과는 HTTP 또는 유사한 송신 프로토콜 포맷으로 주어진 클라이언트에 제공된다. 일부 실시예들에서, 서비스에 대한 담당 프로세서가 호스트 플랫폼 API에 원격으로 로케이팅되는 경우, 플랫폼 프로세서는 RPC 포맷으로 담당 프로세서로부터 블록체인 트랜잭션(들)과 연관된 응답을 수신한다. 그 후, API 변환기는 이를 클라이언트에 전송하기 전에 HTTP 포맷에 기초하여 전송될 수 있는 메시지로 이를 변환한다. 위에서 언급된 바와 같이, 클라이언트가 bsvalias와 같은 별칭 어드레싱 서비스를 사용한 경우, 결과는 bsvalias 기계 판독 가능 자원에 의해 지시되는 포맷으로, 클라이언트에 대한 별칭으로 어드레스싱된 HTTP 메시지로 전송된다.
도 2b는 본 개시내용의 제1 양상에 관한 것이며, 도 1에 도시된 플랫폼(100)과 같이 블록체인과 연관된 복수의 서비스들의 플랫폼에 액세스하기 위한 컴퓨터 구현 방법을 도시한다. 도 2b의 방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현된다.
단계(202b)에서, 플랫폼과 연관된 API(application programming interface) 엔드포인트가 식별된다. 이전에 언급된 바와 같이, 이는 호스트 플랫폼 프로세서와 연관된 API일 수 있으며 서비스의 구현을 담당하는 하나 이상의 추가 프로세서들 ― 각각은 자체 서비스 엔드포인트 또는 목적지 어드레스를 가짐 ― 이 있을 수 있다.
단계(204b)에서, 클라이언트는 도 1의 데이터 기록 서비스(102)와 같은 서비스에 대한 요청을 준비한다. 일부 실시예들에서 클라이언트는 올바른 서비스 엔드포인트로 라우팅될 수 있도록 요청에 클라이언트 별칭 또는 식별자 및/또는 서비스 식별자를 포함시킨다. 이는 요청 클라이언트의 유효성 및 요청된 서비스를 사용하기 위한 클라이언트의 허가에 관한 플랫폼 프로세서에 의한 체크들에 대해 유용하다.
단계(206b)에서, 단계(204b)에서 준비된 요청은, 플랫폼 프로세서가 HTTP(Hypertext Transfer Protocol) 또는 REST API로서 구현되기 때문에 HTTP 또는 유사한 송신 프로토콜 포맷을 사용하여 전송된다.
단계(208b)에서, 요청과 연관된 블록체인 트랜잭션의 출력 스크립트에 관련된 결과는 플랫폼 프로세서로부터 제공된다. 이 결과는 HTTP 송신 프로토콜 포맷으로 클라이언트에 제공된다.
유리하게는, 제1 양상의 방법들의 경우, 블록체인 기반 서비스들에 대한 요청은 HTTP 송신 프로토콜 포맷으로 클라이언트에 의해 전송 및 수신되고, 이에 따라 클라이언트는 어떠한 트랜잭션 능력 또는 블록체인 라이브러리들도 구현해야 할 필요 없이, 클라이언트는 블록체인 고유의 모든 이점들 및 서비스들 사용할 수 있다. 이는 서비스가 HTTP 또는 REST API 엔드포인트일 수 있는 플랫폼 API를 통해 제공되기 때문이다. 예컨대, REST API 설계 표준들은 인터넷을 통해 다음 HTTP 커맨드들을 사용하여 HTTP 요청들 및 통신을 프로세싱할 수 있다 ― 그리고 이는 클라이언트에 의해 요구되는, 즉 인터넷을 통해 메시지들을 전송 및 수신할 수 있게 되는데 요구되는 모든 기능성임 ― . 플랫폼 프로세서(들)는 원격으로 또는 클라이언트에 대해 별개로 커맨드들을 구현한다.
Figure pct00001
도 3은 제공된 서비스들 중 임의의 하나 이상이 액세스될 수 있게 하는 API와 연관된 플랫폼(300)에 의해 구현될 수 있고 블록체인과 연관된 복수의 서비스들의 보다 세분화된 개략도를 제공한다. 이 도면에서 보여지는 바와 같이, 데이터 서비스(302)는 데이터 기록기(302a) 및 데이터 판독기 서비스(302b)를 포함할 수 있다. 데이터 기록기 서비스(302a)를 사용한 이벤트 스트림들의 구현은 클라이언트들이 간단하고 안전하며 최적화된 방식으로 데이터를 블록체인에 기록하는 것을 가능하게 하도록 도 4 내지 도 8에서 자세히 설명될 것이다. 데이터 판독기 서비스(302b)는 클라이언트들이 블록체인에 저장된 데이터를 리턴하는 질의들을 전송하는 것을 가능하게 한다. 이는 클라이언트가 애드 혹(ad hoc) 또는 주기적 기반으로 즉, 특정 시간프레임 내에 블록체인으로부터 판독하고자 하는 데이터의 유형 또는 블록체인(310)에서 프로세싱되는 일 세트의 관련되거나 관련되지 않은 이벤트들 또는 문서들과 연관된 것들을 미리 정의할 수 있는 필터링된 스트림들을 사용할 수 있다. 데이터 아카이브 특징은 지정된 이벤트 또는 계약에 대한 이전 트랜잭션의 로그들에 대한 액세스를 허용한다.
플랫폼(300)의 컴퓨팅 서비스들(306)은 스마트 계약과 연관된 애플리케이션(306a) 및 프레임워크(306b)를 포함하며, 이는 일부 실시예들에서, 블록체인(310)에서 상태 머신으로서 표현될 수 있다. 컴퓨팅 서비스들(306)은, 데이터가 입력되고 임의의 그러한 컴퓨테이션에 대한 결과들이 클라이언트에 제공될 필요가 있기 때문에, 데이터 서비스(302)와 상호작용한다.
커머스 서비스들(304)은 동급 최상의 보안 관행들 및 기술들에 기초하여 블록체인(310)을 통한 트랜잭션을 위해 엔터프라이즈 지갑들(304a)을 통해 엔터프라이즈-클래스 능력들(enterprise-class capabilities)의 제공을 담당한다. 예컨대, 일부 실시예들에서, 엔터프라이즈 지갑들은 하나 초과의 사람 또는 사용자 또는 계정이 정의된 기준을 충족하는, 즉 특정한 미리 정의된 제한을 초과하는 큰 값의 암호화폐와 연관된 트랜잭션에 서명(sign off)할 필요가 있을 때 블록체인 트랜잭션 프로세싱을 가능하게 하는 기능성을 구현할 수 있다. 엔터프라이즈 지갑은 또한 암호화폐 또는 다른 자원을 표현하는 토큰들과 같은 대량의 디지털 자산들을 이동시키기 위해 임계 수 및/또는 유형의 서명들을 구현하는 기능성을 또한 포함할 수 있다. 그 후 이러한 자산들의 움직임은 이러한 엔터프라이즈 지갑 구현에 의해 적용된 기준들에 기초하여 프로세싱된 후 블록체인 상에 표현될 수 있다.
SPV(simplified payment verification) 서비스들(308)은 블록체인으로부터의 정보를 요구하지만 채굴자 노드를 실행하지 않기 때문에 이에 대한 직접 링크를 포함하지 않는 애플리케이션들이다. 이러한 SPV 서비스(308)는 경량 클라이언트가, 전체 블록체인(310)을 다운로드하지 않고도 트랜잭션이 블록체인에 포함되었음을 검증하도록 허용한다.
제2 양상 ― 블록체인과 연관된 데이터 기록 서비스를 제공하는 플랫폼
도 4는 본 개시내용의 제2 양상에 관한 것이고, 제1 양상의 도 3에 도시된 데이터 기록기(302a)와 같이 블록체인과 연관되는 트랜잭션들에 대한 데이터 기록 서비스를 제공하기 위한 컴퓨터 구현 방법을 도시한다. 도 3의 방법은 서비스를 위한 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다.
단계(402)는 클라이언트로부터 요청을 수신하는 것을 도시하며, 요청은 블록체인을 사용하여 구현된 이벤트 스트림(ES)에 관련된다. 클라이언트의 요청은 제1 양상과 마찬가지로 HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷이다. 일부 실시예들에서, 이벤트 스트림은 상태 머신과 관련되고, 블록체인에서 유한 상태 머신으로서 구현되는 기계 판독 가능 계약 또는 스마트 계약을 표현한다. FSM(Finite State Machine)은 잘 알려진 수학적 컴퓨테이션 모델이다. 이는 임의의 주어진 시간에 유한한 수의 상태들 중 정확히 하나에 있을 수 있는 추상적 머신이다. FSM은 일부 외부 입력들에 대한 응답으로 한 상태로부터 다른 상태로 변할 수 있으며, 한 상태에서 다른 상태로의 변화는 트랜지션(transition)이라 불린다. FSM은 그의 상태들의 목록, 그의 초기 상태 및 각각의 트랜지션에 대한 조건들에 의해 정의될 수 있다. 비트코인 SV 블록체인에서, UTXO 세트는 상태 머신으로 간주될 수 있으며 주어진 출력의 지출 상태는 트랜잭션(머신)에 대한 이전 입력들의 함수이다. 따라서, 모든 트랜잭션을 재생함으로써, 임의의 출력의 현재 지출 상태 및 UTXO 세트의 현재 콘텐츠들은 블록체인을 사용하여 결정론적으로 설정될 수 있다. 따라서, 도 4의 실시예에서, 요청은 블록체인에서 이벤트 스트림(ES)으로서 구현되는, 스마트 계약의 현재 상태를 변경하기 위한 요청으로서 간주될 수 있다.
단계(404)는 데이터 기록기 또는 데이터 기록 서비스를 구현하기 위한 플랫폼 프로세서에 의해 이벤트 스트림(ESi=n)의 현재 상태를 결정하는 것을 도시한다. i는 0 내지 N의 정수이며, 각각의 정수 i는 유한 수의 상태들을 갖는 이벤트 스트림(ES)의 주어진 상태를 표현하며, 여기서 i = 0은 생성된 이벤트 스트림(ES)을 표현하고, i = n은 블록체인 내 현재 상태의 이벤트 스트림(ES)을 표현하고, i = N은 이벤트 스트림(ES)의 최종 상태를 표현한다. 따라서 이벤트 스트림(ES)의 현재 상태는 En가 될 것이다.
단계(406)는 단계(402)에서 수신된 요청에 기초하여 이벤트 스트림(ES)에 대한 다음 또는 새로운 이벤트(En+1)와 연관된 데이터를 식별하거나 획득하는 것을 도시한다. 이 실시예에서, 새로운 이벤트는 이벤트 스트림이 다음 상태로 트랜지션하도록 상태의 변경을 트리거하는 데이터 또는 함수일 수 있다.
단계(408)는 데이터 기록기를 구현하는 플랫폼 프로세서와 연관된 하나 이상의 프로세서들에 의해 다음 이벤트(En+1)에 대한 블록체인 트랜잭션(TXn+1)을 생성하는 단계를 도시한다. 블록체인 트랜잭션(TXn+1)은 적어도, 다음을 포함한다:
- 이전 트랜잭션(TXn)으로부터의 트랜잭션 출력(TXOn)과 연관된 입력. 이 입력은 이전 트랜잭션으로부터의 TXOn 출력을 지출한다.
- 새로운 이벤트(En+1)를 표현하는 이벤트 데이터와 연관된 미지출 출력(UTXOn+1). 일부 실시예들에서, 이것은 데이터 출력, 즉 트랜잭션의 데이터 캐리어 요소를 표현한다.
네트워크 채굴 수수료들을 적절하게 커버하기 위한 자금 입력들과 같은 부가적인 입력들이 있을 수 있고, 트랜잭션에 대한 변화 출력들과 같은 다른 출력들이 또한 있을 수 있다.
단계(410)는 단계(408)에서 생성된 트랜잭션(TXn+1)을 블록체인에 제출하는 것을 도시한다. 여기서 트랜잭션은 플랫폼 프로세서와 연관된 채굴자 노드 또는 BSV 노드 소프트웨어에 의해 후속 블록에의 포함을 위해 비트코인 SV 네트워크와 같은 블록체인에 제출될 수 있다.
단계(412)는 ESi=n = ESn+1이 되도록, 이벤트 스트림(ES)의 현재 상태를 새롭게 생성된 이벤트(En+1)에 기초하여 이제 ESi=n+1이 되도록 업데이트하는 것을 도시한다. 이는 ES에 대한 블록체인에 제출된 최신 트랜잭션(TXn+1)에 대응한다. 일부 실시예들에서, 새로운 상태는 최종 트랜잭션 출력(UTXOn+1)에서 출력된 이벤트 데이터에 기초하여 식별되고 업데이트된다.
단계(414)는 단계(412)에서의 업데이트된 현재 상태(ESn+1)에 기초한 결과를 전송하는 것을 도시하며, 이 결과는 HTTP 송신 프로토콜 포맷에 기초하여 클라이언트에 제공된다.
제3 양상 ― 블록체인과 연관된 이벤트 스트림을 레코딩하기 위한 데이터 기록 서비스를 제공하는 플랫폼
도 5, 도 6 및 도 7은 제2 양상의 도 4와 관련하여 논의된 것들과 같은 이벤트 스트림들을 구현하는 것과 연관된 애플리케이션을 논의한다. 제3 양상은 블록체인 상에서 이벤트 스트림(ES)의 현재 상태까지 이벤트 스트림(ES)의 변경 불가능한 순차적 로그 또는 레코드를 설정하기 위한 기술에 관한 것이다. 일부 실시예들에서, 로그는 블록체인 상에 저장되는 것 외에도, 오프-체인으로 제공되거나 저장될 수 있다. 이벤트 스트림의 상태는 트랜잭션들과 연관된 입력들 및 출력들에 기초하므로, 제3 양상에 대해 아래에서 설명된 기술들은 블록체인 상에서 이벤트 스트림과 연관된 모든 트랜잭션들의 변경 불가능한 시간순 로그를 설정하기 위한 방법을 제시한다. 이벤트 스트림은 FSM, DFA 등을 사용하여 구현되는 스마트 계약에 적용되는 순차적 입력들을 표현할 수 있다.
도 5는 본 개시내용의 제2 양상에 관한 것이고, 제1 양상의 도 3에 도시된 데이터 기록기(302a)와 같이 블록체인과 연관되는 트랜잭션들에 대한 데이터 기록 서비스를 제공하기 위한 컴퓨터 구현 방법을 도시한다. 도 5의 방법은 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다. 이 방법은 새로운 이벤트 스트림을 생성하는 것과 관련된다.
단계(502)는 클라이언트로부터 요청을 수신하는 것을 도시하며, 요청은 블록체인을 사용하여 새로운 이벤트 스트림(ES)을 생성하는 것이다. 클라이언트로부터의 요청은 제1 및 제2 양상들과 마찬가지로, HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷이다.
단계(504)는 생성될 새로운 이벤트 스트림(ES)과 함께 사용될 계층적 결정론적(hierarchical deterministic; HD) 키 체인(K)을 결정하는 단계를 도시한다. 일부 실시예들에서, 이것은 알려진 BIP 21 프로토콜에 기초한 시드 또는 부모 또는 마스터 키로부터 시작하는 키들의 계층적 트리-형 구조를 생성하기 위해 플랫폼 프로세서와 연관된 HD 지갑 구현에 의해 구현될 수 있다. HD 키 생성 및 이전 프로토콜은 키 생성을 크게 단순화하고 독립적으로 동작할 수 있는 자식 계정들의 생성을 허용하며, 이는 각각의 부모 계정에, 자식 계정들이 손상된 경우에도 그의 자식 계정을 모니터링하거나 제어하는 능력을 부여한다. HD 프로토콜은 단일 루트 시드를 사용하여, 별개의 결정론적-생성 정수 값들로 자식, 손주 및 다른 후손 키(descended key)들의 계층 구조를 생성한다. 각각의 자식 키는 또한 체인 코드라 불리는, 그의 부모로부터 결정론적-생성 시드를 가져온다. 이렇게 하면, 하나의 체인 코드의 임의의 손상이 전체 계층 구조에 대한 정수 시퀀스를 반드시 손상시키는 것은 아니다. 위의 이점들에 더하여, 본 양상에서, 이러한 키 생성은 플랫폼 프로세서에 의해 수행되고, 이에 따라 키가 클라이언트로부터 생성되는 경우의 자원 및 기능성을 제거한다. 따라서 어떠한 HD 지갑도 클라이언트에 의해 구현될 필요가 없다. 단계(504)에서, 키 체인(K)은 K = Kn = 0 to N가 되도록, 선택된 부모 키 쌍으로부터 도출된 일련의 개인/공개 키 쌍들을 포함하며, 여기서 n은 0 내지 N까지의 정수이고, 각각의 정수 n은 이벤트 스트림(ES)과 연관된 이벤트들의 현재 길이 또는 현재 수를 표현하며, N은 n의 최대 또는 최종 값을 표현한다.
단계(506)는 제1 이벤트(E0)와 연관된 데이터를 식별하거나 획득하는 것을 도시하며, 이는 단계(502)에서의 수신된 요청 내 이벤트 데이터에 기초하여 블록체인에서 생성될 새로운 이벤트 스트림(ES)에 대한 것이다.
단계(508)는 데이터 기록기를 구현하는 플랫폼 프로세서와 연관된 하나 이상의 프로세서들에 의해, 새로운 이벤트 스트림(ES)에 대한 제1 블록체인 트랜잭션(TX0)을 생성하는 것을 도시하며, 여기서 n = 0이다.
단계(510)는, 단계(508)에서 생성된 블록체인 트랜잭션(TX0)의 출력이 더스트 출력인 적어도 제1 미지출 트랜잭션 출력(UTXO0 _dust)을 포함하고, 상기 더스트 출력은 단계(504)에서 HD 키 체인(K)으로부터 도출된 일련의 키들 내 제1 도출된 키 쌍(K0)으로 보안되는 잠금 스크립트와 연관되는 것을 보여준다. 더스트 출력은 트랜잭션에 대한 정의된 제한 미만이거나 정의된 최소 값, 즉 이러한 트랜잭션을 지출하는 데 요구될 채굴 수수료보다 낮은 값을 갖는 (디지털 자산) 값과 연관된다. 또한, 지불 프로세서와 연관되거나 유지되는 오퍼레이셔널 플로트 또는 디지털 자산 또는 암호화폐 자금와 연관된 디지털 자산들과 연관된 다른 입력들이 있을 수 있다. 또한, 트랜잭션 내 다른 출력들 ― 이는 디지털 자산 변화 출력들임 ― 을 갖는 것이 가능하다.
따라서, 일부 실시예들에서, 본 실시예에 따라 이벤트 스트림을 생성하기 위한 블록체인 트랜잭션에 대한 생성(Create) 템플릿은 제1 입력이 더스트보다 커야 하는 템플릿이다. 이는 유리하게는, 이벤트 스트림에 어떠한 이전 엔트리도 없고 이것이 제1 엔트리임을 표시하기 위한 것이다. 생성 템플릿은 또한 템플릿의 제1 출력이 더스트이고 어떠한 데이터 캐리어 또는 데이터 출력도 없음(이에 따라 OP_RETURN가 없음)을 지정하는데, 그 이유는 새로운 이벤트 스트림(ES)의 생성 외에 생성 상태와 연관된 어떠한 이벤트 데이터도 없기 때문이다. 일부 실시예들에서, OP_RETURN은 생성 프레임에 대해 포함되지만, 이는 어떠한 이벤트 데이터도 홀딩하지 않는다. 이는 새롭게 생성된 스트림의 파라미터들을 설명하는 메타데이터를 홀딩할 수 있다. 메타데이터의 예들의 예들은 세부사항들 이를테면, 공개 또는 공증 속성들, 블록체인에의 기록 시간, 이벤트들이 처음 수락될 시간, 이벤트들이 더 이상 수락되지 않을 시간, 뒷받침 또는 관련된 데이터가 저장되는 지리적-지역, 수락 가능한 데이터의 최대 크기, 시퀀스 번호 등을 포함할 수 있다.
단계(512)는 트랜잭션(TX0)을 블록체인에 제출하는 것을 도시한다. 여기서, 트랜잭션은 플랫폼 프로세서와 연관된 채굴자 노드 또는 BSV 노드 소프트웨어에 의해 후속 블록에의 포함을 위해 비트코인 SV 네트워크와 같은 블록체인에 제출될 수 있다. 일부 실시예들에서, 일단 채굴되면, 트랜잭션 식별자(TX0)는 새롭게 생성된 이벤트 스트림(ES)을 고유하게 식별하는 데 사용될 수 있다.
단계(514)는 TX0에서 생성된 이벤트 스트림(ES)과 연관된 결과를 클라이언트에 전송하는 것을 도시하며, 이 결과는 HTTP 송신 프로토콜 포맷으로 제공된다. 이벤트 스트림과 관련된 결과는 블록체인에 별개로 복사되거나 저장될 수 있다.
일부 실시예들에서, 이벤트 스트림의 생성은 온-체인 체결(on-chain settlement)을 위해 블록체인으로의 제출로부터 디커플링될 수 있다. 이 경우에, 개개의 이벤트 스트림에 고유한 이벤트 스트림 id가 또한 사용될 수 있으며, 결국, 클라이언트에 대신 제공될 수 있다.
도 6은 본 개시내용의 제3 양상에 관한 것이고, 제1 양상의 도 3에 도시된 데이터 기록기(302a)와 같이 블록체인과 연관되는 트랜잭션들에 대한 데이터 기록 서비스를 제공하기 위한 컴퓨터 구현 방법을 도시한다. 도 6의 방법은 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다. 이 도면은 블록체인 상의 기존 이벤트 스트림(ES)에 새로운 이벤트를 추가하라는 요청과 관련된다.
단계(602)는 클라이언트로부터 요청을 수신하는 것을 도시하며, 이 요청은 요청에서 식별되고 블록체인에서 구현된 기존 스트림(ES)을 수정하기 위한 것이다. 클라이언트로부터의 요청은 제1 및 제2 양상들과 마찬가지로, HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷이다. 도 5의 단계(504)와 관련하여 논의된 바와 같이, 블록체인 상의 이벤트 스트림(ES)은 K = Kn = 0 to N이 되도록 키 체인(K)과 연관되며, 여기서 n은 0 내지 N까지의 정수이고, 각각의 정수 n은 이벤트 스트림(ES)과 연관된 이벤트들의 현재 길이 또는 현재 수를 표현하며, 여기서 N은 n의 최대 또는 최종 값을 표현한다. 일부 실시예들에서, API 액세스 토큰의 존재에 대한 테스트, 또는 세션 체크 또는 패스워드/디지털 서명 테스트, 또는 클라이언트 또는 이루어진 서비스 요청을 유효성 검증하기 위한 일부 다른 적절한 방법일 수 있는 인증 및 인가 체크들이 수행된다.
단계(604)에서, 이벤트 스트림(ES)의 현재 길이(n)가 결정된다.
단계(606)는 이벤트(En)와 연관된 데이터를 식별하거나 획득하는 것을 도시하며, 이는 단계(602)에서의 수신된 요청 내 이벤트 데이터에 기초하여 블록체인 상의 이벤트 스트림(ES)에 현재 부가되거나 추가될 이벤트이다.
단계(608)에서, 이벤트 스트림(ES)과 연관된 이전 블록체인 트랜잭션(TXn-1)이 식별된다. 일단 식별되면, 식별된 이전 트랜잭션(TXn-1)과 연관된 키 쌍(Kn-1)이 그 후 결정된다. 위에서 언급된 바와 같이, 이는 단계(602)에서 제시된 동일한 시드 키 쌍(K)에 기초한다.
단계(610)에서, 현재 이벤트(En)에 대한 키 쌍(Kn)은 시드 키 쌍(K)으로부터 도출된다.
단계(612)는 데이터 기록기를 구현하는 플랫폼 프로세서와 연관된 하나 이상의 프로세서들에 의해, 새로운 이벤트 스트림(ES)에 대한 현재 블록체인 트랜잭션(TXn)을 생성하는 것을 도시하며, 여기서 0 < n < N이다. 이벤트 스트림(ES)에 추가되도록 현재 이벤트(En)에 대해 생성된 블록체인 트랜잭션(TXn)은 다음을 포함한다:
- 이전 트랜잭션(TXn-1)과 연관된 더스트 출력을 지출하는 제1 입력 ― 상기 지출은 단계(608)에서 획득된 이전 트랜잭션에 대해 획득된 키 쌍(Kn-1)으로 인가됨 ― ;
- 현재 트랜잭션(TXn)에 대한 더스트 출력인 제1 미지출 트랜잭션 출력(UTXOn_dust) ― 상기 더스트 출력은 단계(610)로부터 도출된 키 쌍(Kn)으로 보안된 잠금 스크립트와 연관됨 ― ; 및
- 현재 이벤트(En)를 표현하는 이벤트 데이터와 연관된 최종 미지출 트랜잭션 출력(UTXOn_data).
위에서 언급된 바와 같이, 더스트 출력은 트랜잭션에 대해 정의된 제한 미만이거나 정의된 최소 값을 갖는 (디지털 자산) 값과 연관된다. 오퍼레이셔널 플로트에 기초한 디지털 자산들과 연관된 다른 입력들이 또한 있을 수 있다. 이 플로트는 플랫폼 프로세서에 의해 제어될 수 있다. 또한, 트랜잭션 내 다른 출력들 ― 이는 디지털 자산 변화 출력들임 ― 을 갖는 것이 가능하다.
따라서, 일부 실시예들에서, 본 실시예에 따라 이벤트 스트림을 업데이트하기 위한 블록체인 트랜잭션에 대한 업데이트(Update) 템플릿은 제1 입력이 더스트여야 하고 제1 출력이 더스트여야 하는 템플릿이다. 이는 유리하게는, 이벤트 스트림 내 이전 엔트리의 존재를 표시하기 위한 것이다. 이것은 또한 해당 이벤트(En)(본 또는 현재 이벤트 데이터)가 이전 트랜잭션 또는 상태 다음에 온다는 것을 표시한다. 따라서 트랜잭션은 유리하게는, 더스트 체인을 뒤따르고 다음 상태 이전에 온다. 업데이트 템플릿은 데이터 캐리어, 즉 현재 이벤트 또는 상태와 연관된 이벤트 데이터 또는 결과를 전달하는 데이터 출력을 포함한다. 이는 지출 불가능한 OP_RETURN 출력일 수 있다.
트랜잭션 내 더스트 출력들의 사용은 이들이 블록체인에서 이벤트 스트림(ES)에 대해 발생할 때 모든 트랜잭션의 변경 불가능한 순차적 레코드를 유지하는 데 유리하다. 이는 트랜잭션들을 블록체인에 게시함으로써, 모든 블록체인 트랜잭션들이 타임 스탬핑되고 블록체인에서 순서대로 유지될지라도, 이것이 그의 순차적 순서의 보존을 보장하지 않기 때문이다. 이는 트랜잭션들이 상이한 시간들에 블록들 내로 채굴될 수 있기 때문이다. 현재 트랜잭션의 제1 입력으로서 지출 ― 이 지출은 각각의 트랜잭션의 잠금/잠금 해제 스크립트들과 관련된 개개의 고유 키에 기초함 ― 되는 이전 트랜잭션의 더스트 출력의 사용은 시간순으로 이벤트 스트림의 명확하고 순차적인 변조 방지 레코드를 보장한다.
단계(614)는 트랜잭션(TXn)을 블록체인에 제출하는 것을 도시한다. 여기서 트랜잭션은 플랫폼 프로세서와 연관된 채굴자 노드 또는 BSV 노드 소프트웨어에 의해 후속 블록에의 포함을 위해 비트코인 SV 네트워크와 같은 블록체인에 제출될 수 있다. 일부 실시예들에서, 일단 채굴되면, 트랜잭션 식별자는 이벤트 스트림(ES)을 고유하게 식별하는 데 사용될 수 있다.
단계(616)는 TXn에서 생성된 이벤트 스트림(ES)과 연관된 결과를 클라이언트에 전송하는 것을 도시하며, 이 결과는 HTTP 송신 프로토콜 포맷으로 제공된다. 결과는 블록체인에 별개로 복사되거나 저장될 수 있다. 일부 실시예들에서, 이는 최종 미지출 트랜잭션 출력(UTXOn_data) 내 이벤트 데이터에 기초할 수 있다. 일부 실시예들에서, (UTXOn_data) 내 이벤트(En)에 대한 이벤트 데이터는 상기 이벤트 데이터의 해시를 포함하고, 그리하여 이는 플랫폼 프로세서에 의해 비공개로 유지되는 것을 보장한다. 해시는 플랫폼 프로세서에 의해 적용되거나 클라이언트에 의해 적용될 수 있는데, 즉 일부 실시예들에서, 이벤트(En)에 대해 단계(602)에서 플랫폼 프로세서에서 수신되는 요청과 관련된 이벤트 데이터를 생성하기 전에 적용될 수 있다. 클라이언트에 의해 적용하는 경우에, 요청 내 이벤트 데이터는 플랫폼 프로세서에 도달하기 전에도 비공개이다. 다른 실시예들에서, 이벤트 데이터는 블록체인으로부터 공개적으로 이용 가능한 원시 데이터로서 제공될 수 있다.
도 7은 본 개시내용의 제3 양상에 관한 것이고, 제1 양상의 도 3에 도시된 데이터 기록기(302a)와 같이 블록체인과 연관되는 트랜잭션들에 대한 데이터 기록 서비스를 제공하기 위한 컴퓨터 구현 방법을 도시한다. 도 7의 방법은 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다. 도 7의 요청은 블록체인 상의 기존 이벤트 스트림을 종결하기 위한 것이다.
단계(702)는 클라이언트로부터 요청을 수신하는 것을 도시하며, 요청은 블록체인을 사용하여 구현된 기존 이벤트 스트림(ES)의 종결과 관련된다. 클라이언트로부터의 요청은 제1 및 제2 양상들과 마찬가지로, HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷이다. 도 5의 단계(504)와 관련하여 논의된 바와 같이, 블록체인 상의 이벤트 스트림(ES)은 K = Kn = 0 to N이 되도록 키 체인(K)과 연관되며, 여기서 n은 0 내지 N까지의 정수이고, 각각의 정수 n은 이벤트 스트림(ES)과 연관된 이벤트들의 현재 길이 또는 현재 수를 표현하며, 여기서 N은 n의 최대 또는 최종 값을 표현한다. 일부 실시예들에서, API 액세스 토큰의 존재에 대한 테스트, 또는 세션 체크 또는 패스워드/디지털 서명 테스트, 또는 클라이언트 또는 이루어진 요청을 유효성 검증하기 위한 일부 다른 적절한 방법일 수 있는 인증 및 인가 체크들이 수행된다.
단계(704)에서, 이벤트 스트림(ES)의 현재 길이(N)가 결정된다.
단계(706)는 최종 이벤트(EN)와 연관된 데이터를 식별하거나 획득하는 것을 도시하며, 이는 단계(702)에서 수신된 요청은 내 이벤트 데이터에 기초하여 블록체인 상의 이벤트 스트림(ES)에 현재 부가되거나 추가될 이벤트이다.
단계(708)에서, 이벤트 스트림(ES)과 관련된 이전 블록체인 트랜잭션(TXN-1)이 식별된다. 일단 식별되면, 식별된 이전 트랜잭션(TXN-1)과 연관된 키 쌍(KN - 1)이 그 후 결정된다. 위에서 언급된 바와 같이, 이는 단계(702)에서 제시된 동일한 시드 키 쌍(K)에 기초한다.
단계(710)에서, 현재 이벤트(EN)에 대한 키 쌍(KN)은 시드 키 쌍(K)으로부터 도출된다.
단계(712)는 데이터 기록기를 구현하는 플랫폼 프로세서와 연관된 하나 이상의 프로세서들에 의해, 새로운 이벤트 스트림(ES)에 대한 현재 블록체인 트랜잭션(TXN)을 생성하는 것을 도시하며, 여기서 n=N이다. 이벤트 스트림(ES)을 종결하기 위해 현재 이벤트(EN)에 대해 생성된 블록체인 트랜잭션(TXN)은 다음을 포함한다:
- 이전 트랜잭션(TXN-1)과 연관된 더스트 출력을 지출하는 제1 입력 ― 상기 지출은 단계(708)에서 획득된 이전 트랜잭션에 대해 획득된 키 쌍(KN - 1)으로 인가됨 ― ;
- 정의된 더스트 출력 제한을 초과하는 디지털 자산과 연관된 제1 미지출 트랜잭션 출력(UTXON).
최종 이벤트에 대해, 모든 트랜잭션 출력들은 변화를 리턴한다. 종결된 이벤트 스트림의 다음 스테이지를 추적할 필요가 없거나 추적하도록 요구되지 않기 때문에, 어떠한 더스트 출력도 없다. 따라서 n=N일 때, 어떠한 더스트 출력도 플랫폼 프로세서에 의해 제공되지 않는다. 즉, 출력들은 이벤트 스트림(ES)과 연관된 변화 출력(디지털 자산 지불)으로서 간주될 수 있다. 이는 유리하게는, 이벤트 스트림의 최종 종결 상태가 추적되고 있음을 표시하거나 나타낸다. 일부 실시예들에서, 이벤트 또는 계약이 종결된 상태에 있기 때문에, 출력에 대한 이벤트 데이터 또는 데이터 캐리어 요소가 또한 없는데 즉, 이벤트 데이터에 대한 OP_RETURN이 없다. 따라서 이벤트 스트림(ES)을 종결하기 위해 별개의 더스트 및 데이터 캐리어 출력들이 생성되지 않고 제1 출력이 더스트 제한을 초과하는 것은, 이벤트 데이터 출력의 부재 ― 이는 종결을 또한 표시함 ― 와 함께, 이것이 블록체인 상의 이벤트 스트림의 끝임을 시그널링한다. 이벤트 데이터 대신 OP_RETURN에 메타데이터가 있는 실시예들에서, 이 메타데이터는 엔티티를 검증하는 데 도움이 될 수 있다. 오퍼레이셔널 플로트로부터의 디지털 자산과 연관된 다른 입력들 또는 변화 출력들이 있을 수 있다. 일부 실시예들에서, 도 5 및 도 6과 관련하여 제시된 더스트와 연관된 디지털 자산의 값은 하나 이상의 다른 출력들에 단순히 추가될 수 있다.
따라서, 일부 실시예들에서, 본 실시예에 따라 이벤트 스트림을 종결하기 위한 블록체인 트랜잭션에 대한 닫기(Close) 템플릿은 도 6의 업데이트 템플릿의 제1 입력과 마찬가지로, 제1 입력이 더스트여야 하는 템플릿이다. 제1 출력은 더스트가 아니어야 하고, 이는 유리하게는, 원장-종료 마커(end-of-ledger marker)로서 작용하고 업데이트 템플릿으로부터 닫기 템플릿을 또한 구별한다. 도 5의 생성 템플릿과 마찬가지로, 이벤트 데이터에 대한 어떠한 데이터 캐리어도 없을 수 있지만, OP_RETURN은 닫기 템플릿의 메타데이터를 포함할 수 있다.
단계(714)는 트랜잭션(TXN)을 블록체인에 제출하는 것을 도시한다. 여기서 트랜잭션은 플랫폼 프로세서와 연관된 채굴자 노드 또는 BSV 노드 소프트웨어에 의해 후속 블록에의 포함을 위해 비트코인 SV 네트워크와 같은 블록체인에 제출될 수 있다.
단계(716)는 TXN에서 생성된 이벤트 스트림(ES)과 연관된 결과를 클라이언트에 전송하는 것을 도시하며, 이 결과는 HTTP 송신 프로토콜 포맷으로 제공된다.
도 8은 본 개시내용의 제3 양상에 관한 것이며, 도 1에 도시된 플랫폼(100) 또는 도 3의 플랫폼(300)과 같이 블록체인과 연관된 이벤트 스트림에 데이터를 기록하기 위한 데이터 기록 서비스 또는 플랫폼에 액세스하기 위한 컴퓨터 구현 방법을 도시한다. 도 8의 방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현된다.
단계(802)에서, 플랫폼과 연관된 API(application programming interface) 엔드포인트가 식별된다. 이전에 언급된 바와 같이, 이는 호스트 플랫폼 프로세서와 연관된 API일 수 있으며 서비스의 구현을 담당하는 하나 이상의 추가 프로세서들 ― 서비스 엔드포인트 또는 목적지 어드레스를 각각 가짐 ― 이 있을 수 있다.
단계(804)에서, 클라이언트는 도 3의 데이터 기록 서비스(302)와 같은 서비스에 대한 요청을 준비한다. 요청은 블록체인 내 이벤트 스트림(ES)과 관련된 하나 이상의 이벤트들(En)과 연관된다. 일부 실시예들에서, 클라이언트는 요청에 클라이언트 별칭 또는 식별자 및/또는 서비스 식별자를 포함시켜서, 요청이 올바른 서비스 엔드포인트로 라우팅될 수 있게 하고, 플랫폼 프로세서는 요청 클라이언트의 유효성 및 요청된 서비스를 사용하는 클라이언트의 허가를 체크할 수 있다.
단계(806)에서, 단계(804)에서 준비된 요청은 플랫폼 프로세서가 HTTP(Hypertext Transfer Protocol) 또는 REST API로서 구현되기 때문에 HTTP 또는 유사한 송신 프로토콜 포맷을 사용하여 전송된다.
단계(808)에서, 요청 내 이벤트(En)와 연관된 블록체인 트랜잭션의 출력 스크립트에 관련된 결과가 수신된다. 이 결과는 HTTP 송신 프로토콜 포맷으로 클라이언트에 제공된다. 일부 실시예들에서, 결과는 플랫폼 프로세서 내의 또는 플랫폼 프로세서와 연관된 블록체인과 별개로 로그에 저장될 수 있다.
유리하게는, 본 개시내용의 제3 양상의 방법들에 의해 구현된 바와 같이 블록체인과 연관된 이벤트 스트림 및 그의 순차적 로그의 구현은 이벤트들의 불변성 및 이벤트 시퀀싱의 불변성과 관련된 보장들을 제공한다. 일단 기록되면, 다음 방식들 중 임의의 방식으로 이벤트 스트림을 변조하려는 임의의 시도가 방지되거나 명백해진다:
- 이벤트의 콘텐츠들의 변경
- 이벤트들의 재순서화
- 스트림의 시작 또는 중간에의 이벤트들의 삽입
- 스트림 내 어딘가로부터의 이벤트들의 제거.
즉, 제3 양상에 따른 방법들은 이벤트 스트림과 관련된 다음 속성들을 입증 가능하게 만든다:
- 이벤트 스트림 내 개별 엔트리들은 이들이 기록된 이후 수정되지 않았음
- 이전 인접 엔트리들 사이에 어떠한 엔트리들도 삽입되지 않음
- 어떠한 엔트리들도 제거되지 않음
- 어떠한 엔트리들도 재순서화되지 않음.
이러한 특성들 속성들 및 이점들은 감사/준수 로그들로부터, 상태 머신 복제, 모든 클라이언트들에 대해 블록체인으로부터 데이터를 판독하고 그에 기록하기 위한 보다 효율적이고, 변조에 저항하며 정확한 방법들에 이르는 다수의 실용적인 애플리케이션들을 갖는다.
이벤트 로그의 캡처가 유용할 이벤트 스트림에 대한 예는 블록체인을 사용하는 Nought들 O 및 Crosse들 X와 같은 게임의 이벤트들을 추적 및 레코딩하기 위한 애플리케이션이다.
예컨대, n=4(0 내지 4의 5개 상태들)까지의 게임이 다음 상태에 있는 것으로 간주된다:
Figure pct00002
게임이 진행됨에 따라, 제3 양상의 방법에 의해, 블록체인 트랜잭션들의 출력에 기초한 로그가 다음과 같이 레코딩될 수 있다:
Figure pct00003
아래에 주어진 바와 같이, 로그가 게임의 실제 상태를 반영하지 않도록 n=4일 때, 결과에 대해 상이한 엔트리를 삽입하는 것과 같이, 이 시퀀스에 대해 유지되는 로그 사본을 변조하거나 변조하려는 시도가 있다고 간주한다.
Figure pct00004
이는, n=3인 트랜잭션에 대해 더스트 출력을 지출하는 트랜잭션의 입력이 유효성 검증되지 않기 때문에, 블록체인 상에서 이벤트 스트림의 자동으로 생성된 순차적 로그의 체크 또는 감사로부터 즉시 식별될 것이다. 그러한 게임들이 금융 트랜잭션들(예컨대, 유료(pay to play))을 수반하는 경우, 플레이어들이 그의 게임 로그들의 진실성 및 주어진 게임 제공자가 광고하는 확률들 또는 난이도를 준수하는지 여부를 체크하고자 하는 바람이 있을 수 있다는 것이 인지될 것이다. 위에서 설명된 바와 같이, 이벤트 스트림에 주어진 게임에 대한 개별 게임 엔트리들(또는 그의 해시들)을 저장함으로써, 플레이어들은 게임 제공자에 의해 유지되는 임의의 내부 시스템과 독립적으로 인-게임 이벤트(in-game event)가 체크 및 검증될 수 있다는 것을 보장받을 수 있다.
주어진 이벤트 스트림 내 각각의 이벤트는 게임 세션 내에서 발생하는 개별 이벤트들에 대응할 필요가 없다는 것이 추가로 인지될 것이다. 이벤트 스트림은 상기 이벤트의 정확하고 순차적이며 변조-방지 로그가 바람직한 이벤트들의 임의의 로그에 대해 정의될 수 있다. 주어진 이벤트 스트림 내 이벤트들의 예들은, 예컨대, 로컬로 또는 원격으로(바람직하게는 오프-체인으로) 실행되는 주어진 스마트 계약의 입력들 및/또는 출력들; 주어진 온라인 메시징 대화의 두 명 이상의 참여자들 간에 전송된 메시지들; 예컨대, 날씨, 예컨대, 차량들, 상품들, 사람들 등의 로케이션들을 측정하기 위해 센서들 또는 IoT 디바이스들에 의해 수행되는 물리적 측정들; 약물/약 추적 ― 예컨대, 제조원, 운송, 디스펜서 로케이션, 처방된 복용량, 수신자 정보 등을 포함함; 금융 트랜잭션 이를테면, 예컨대, (계정이 암호화폐 또는 명목화폐로 입금되었는지에 관계없이) 계정이 입금받고 그리고/또는 인출된 금액, 환율의 변화들, 거래들의 실행, 상품들 또는 주식들의 구매에 대한 요청 등을 포함할 수 있다. 궁극적으로, 이벤트 스트림이 생성되고 사용되는 맥락은 이러한 이벤트 스트림을 생성하기 위해 플랫폼 프로세서를 사용하는 당사자의 레저(leisure)에 있을 것이다.
제4 양상 ― 블록체인과 연관된 다수의 이벤트 스트림들을 동기화하기 위한 데이터 기록 서비스를 제공하는 플랫폼
도 9는 복수의 이벤트 스트림들을 업데이트하기 위한 기술을 예시한다. 이벤트 스트림은 위의 제2 및 제3 양상들, 특히 단일 이벤트 스트림에 데이터를 추가하거나 수정하기 위한 방법을 지칭하는 도 6과 관련하여 논의된다. 블록체인 상에서 이벤트 스트림의 현재 상태까지 이벤트 스트림의 변경 불가능한 순차적 로그 또는 레코드를 설정하는 것 외에도, 본 개시내용의 제4 양상은 도 5 내지 도 7에서 제시된 바와 같이 각각이 별개로 진행될 수 있는 복수의 별개의 이벤트 스트림이 동기화되는 것을 가능하게 한다. 제2 및 제3 양상과 마찬가지로, 제4 양상에 따라 일단 동기화된 이벤트 스트림들은 또한, 블록체인 상에 저장되는 것 외에도, 오프-체인으로 제공되거나 저장될 수 있다. 복수의 이벤트 스트림들 각각의 상태는 동기화 이벤트를 모두에 추가함으로써 스트림들을 동기화하는 단일 또는 원자적 트랜잭션들을 포함하는 블록체인 트랜잭션들과 연관된 입력들 및 출력들에 기초하므로, 모든 트랜잭션의 불변의 시간순 로그가 제공되며, 여기서 동기화의 포인트는 단일 원자적 트랜잭션으로 역으로 추적될 수 있다. 위에서 언급한 바와 같이, 복수의 이벤트 스트림들을 동기화하기 위한 이벤트와 연관된 이벤트 데이터는 복수의 이벤트 스트림들 각각에 대해 동일할 수 있거나, 복수의 이벤트 스트림들 중 적어도 하나 이상에 대해 상이할 수 있거나, 일부 경우들에서 어떠한 이벤트 데이터도 없을 수 있다. 도 9의 현재 또는 동기화 이벤트에 대해 이루어지는 참조들은 이러한 모든 가능성들을 커버하는 것으로 이해된다. 설명의 편의를 위해서만 그리고 어떠한 제한도 암시하지 않고, 제4 양상의 일부 실시예들은 단일 이벤트 또는 경우에 따라, 동일한 이벤트 데이터의 관점에서 설명된다.
도 9는 본 개시내용의 제4 양상에 관한 것이며, 복수의 이벤트 스트림들을 동기화하기 위한 데이터 기록 서비스를 제공하기 위한 컴퓨터 구현 방법을 도시한다. 이 방법은 제1 양상의 도 3에서 보여진 데이터 기록기(302a)와 같은 기능 또는 서비스를 제공하는 플랫폼 프로세서에 의해 구현될 수 있다. 도 9의 방법은 API(application programming interface)와 연관된 플랫폼 프로세서에 의해 구현된다. 대부분의 경우들에서, 이 API는 단일 이벤트 스트림을 업데이트하기 위한 방법을 교시하는, 도 6에 표시된 API와 상이한 엔드포인트이다. 그러나 일부 경우들에서, 동일한 엔드포인트가 한 번에 다수의 이벤트 스트림들을 서비스하는 기능성이 있는 경우, API가 도 6의 API와 동일한 엔드포인트가 되는 것이 가능하다. 도 9는 모든 M개의 스트림들을 동기화하기 위해 블록체인 상의 복수의 M개의 이벤트 스트림들에 새로운 이벤트를 추가하라는 클라이언트로부터의 요청과 관련된다.
단계(902)는 클라이언트로부터 요청을 수신하는 것을 도시하며, 이 요청은 블록체인과 연관된 복수의 M개의 기존 이벤트 스트림들(ESn =1 to M)을 동기화하기 위한 것이고 n은 1 내지 M의 정수이며, 여기서 M ≥ 2이다. 일부 실시예들에서, 클라이언트의 요청은 앞선 양상들과 마찬가지로, HTTP(Hypertext Transfer Protocol) 송신 프로토콜 포맷이다.
제3 양상과 관련하여 논의된 바와 같이, 일부 실시예들에서, 복수의 M개의 이벤트 스트림들(ESn =1 to M) 중 각각의 이벤트 스트림(ESn)은 또한 K = K0 to i가 되도록 주어진 이벤트 스트림(ESn) 특유의 키 체인(K)과 연관될 수도 있으며, 여기서, 이 실시예에서, i는 주어진 이벤트 스트림(ESn)과 연관된 이벤트들의 현재 인덱스 값 또는 길이 또는 현재 수를 표현하는 정수이다. 주어진 이벤트 스트림에 추가하는 클라이언트의 권한에 대한 다른 인증 및 검증 체크들이 또한 API 액세스 토큰의 존재에 대한 테스트일 수 있는 비대칭 키 쌍들 또는 디지털 서명들, 또는 세션 체크 또는 패스워드/디지털 서명 테스트, 또는 이벤트 스트림(ESn) 또는 이루어진 서비스 요청을 유효성 검증하기 위한 일부 다른 적절한 방법에 기초하여 수행될 수 있다.
클라이언트로부터의 요청은 이 단계에서 복수의 이벤트 스트림들(ESn =1 to M) 각각에 대한 식별자를 갖는 JSON 오브젝트로서 API에서 수신될 수 있는데, 즉 M개의 이벤트 스트림 식별자들이 요청을 표현하는 JSON 오브젝트에 포함될 것이다. 일부 실시예들에서, 클라이언트로부터의 요청은 또한 하나 이상의 식별된 이벤트 스트림(ESn)에 대한 타겟 인덱스를 지정할 수 있거나, 타겟 인덱스는 다음 가용 인덱스이거나 다시 말해서 동기화 요청에 대해 사용될 이벤트 스트림의 실제 또는 현재 길이 + 1을 표현한다.
단계(904)는 단계(902)의 요청으로부터 현재 이벤트(En)와 연관된 데이터를 식별하거나 획득하는 것을 도시한다. 이는 복수의 M개의 이벤트 스트림들을 동기화하기 위해 사용되는 데이터이며 요청에서 식별된 M개의 이벤트 스트림들(ESn) 각각에 부가되거나 추가될 이벤트(En)이다.
일부 실시예들에서, 위에서 언급된 바와 같이, 동기화 프로세스의 부분으로서 각각의 스트림에 추가된 이벤트(En)와 연관된 이벤트 데이터가 복수의 스트림들 중 하나 이상의 다른 스트림들과 상이할 수 있는 가능성이 있다. 예컨대, 각각의 이벤트 스트림과 연관된 메타데이터는 다른 참여 이벤트 스트림들과 비교할 때 상이할지도 모른다. 메타데이터는 동기화 로직 클록, 주어진 이벤트 스트림 특유의 상이한 통화 또는 환율들의 사용, 랜덤 값 즉, 각각의 스트림에 대한 솔트의 추가, 해시 및/또는 솔트 함수의 속성들 등과 연관될 수 있다.
단계(906)는 다수의 스트림들의 동기화가 발생할 수 있기 전에 하나 이상의 검증 단계들이 발생하는 실시예를 도시한다. 단계(902)에서 2개 이상의 스트림들을 동기화하라는 요청이 API에서 수신될 때, 복수의 스트림들(ESn =1 to M) 중 각각의 스트림(ESn)은 이벤트 스트림이 생성될 때 제공된 공개 키에 대해 제공된 서명이 스트림에 대한 서명된 입력에 대해 유효성 검증된다는 것을 체크함으로써 유효성 검증될 것이며, 이 경우에 데이터는 동기화 이벤트(En)를 추가하라는 요청이다. 예컨대, 서명은 생성 시 주어진 이벤트 스트림에 대해 제공된 공개 키에 기초할 수 있다(도 5 참조).
그 후 동기화 요청은 복수의 M개의 이벤트 스트림들(ESn =1 to M) 각각에 대해 유효성 검증이 성공한 경우에만 진행될 것이다. 하나가 실패하더라도; 동기화 요청이 진행되지 않고 단계(912)에서 표시된 바와 같이 오류 메시지가 생성될 수 있다.
일부 실시예들에서, 이 단계는 또한 이용 가능할 때, 단계(902)에서 클라이언트에 의해, 식별된 이벤트 스트림들 중 하나 이상에 대해 지정된 데이터(En)에 대한 타겟 인덱스가 이벤트 스트림의 마지막 인덱스와 매칭되는지에 관한 검증을 포함한다. 이는 개개의 이벤트 스트림에 데이터를 추가하기 위한 다음 가용 인덱스일 것이다. 이는 모든 M개의 복수의 이벤트 스트림들(ESn =1 to M)에 대해 수행된다. 하나가 실패하는 경우, 동기화가 진행되지 않고, 단계(912)에서 오류 메시지가 생성된다. 따라서, 이 단계는 동시성에 대해 검사하고 실제 인덱스 값이 변경되게 할 수 있는, 주어진 이벤트 스트림과 연관된 시간이 오버랩할 수 있는 요청들이 없음을 검증한다.
타겟 인덱스가 이벤트 스트림 id1의 실제 마지막 또는 다음 가용 인덱스와 매칭되지 않지만, JSON 요청 오브젝트에서 식별된 이벤트 스트림 id0에 대해 매칭되는 오류 응답의 예가 아래에서 주어진다:
Figure pct00005
단계(906)의 성공적인 유효성 검증에 이어, 단계(908)에서, 복수의 M개의 이벤트 스트림들(ESn =1 to M) 중 각각의 이벤트 스트림(ESn)에 대해, 개개의 이벤트 스트림(ES)과 연관된 이전 블록체인 트랜잭션(TXn-1)이 식별된다. 단계(902)에서 제시되고 위에서 언급된 바와 같이, 시드 키 쌍(K) 또는 키 체인은 각각의 이벤트 스트림(ESn)에 특유하고 그와 연관될 수 있다. 이 경우에, 식별된 이전 트랜잭션(TXn-1)과 연관된 키 쌍(Ki - 1)이 그 후 결정된다. 그에 기초하여, 이벤트 스트림(ESn)에 부가될 현재 이벤트(En)에 대한 키 쌍(Kn)은 시드 키 쌍(K)으로부터 도출된다.
단계(910)는 복수의 이벤트 스트림들(ESn= 1 to M)을 동기화하기 위해 M개의 이벤트 스트림(ESn) 각각에 추가될 현재 이벤트(En)에 대한 원자적 블록체인 트랜잭션(TXn)을 생성하는 것을 도시한다. 이 트랜잭션은 M개의 이벤트 스트림들을 주어진 이벤트(En)와 동기화하기 위해 다수의 스트림들을 업데이트하는 단일 트랜잭션이다. 원자적 블록체인 트랜잭션은 랑데뷰 트랜잭션으로서 지칭될 수 있다. 이러한 트랜잭션들은 단일 추가 동작을 가능하게 하는, 도 6의 이벤트 스트림에 대한 개선인데, 그 이유는 이들이, 원자적으로 즉, 랑데뷰 또는 원자적 트랜잭션의 당사자인 모든 이벤트 스트림들이 확장되거나 주어진 En과 동기화되거나, 또는 어떠한 이벤트 스트림들도 그렇게 되지 않는 방식으로, 동일한 이벤트를 다수의 스트림들에 추가할 수 있기 때문이다. 이벤트(En)는 모두에 대해 동일한 이벤트 데이터와 연관될 수 있거나, 이벤트(En)는 복수의 M개의 이벤트 스트림들 중 하나 이상에 대해 상이한 이벤트 데이터와 연관될 수 있다.
원자적 또는 랑데뷰 트랜잭션들은 이벤트 스트림들에 걸친 트랜잭션들이며, 도 6의 단계(612)의 트랜잭션과 달리, 이러한 트랜잭션들은 복수의 더스트 체인들을 구성하는 것을 수반하며, 각각은 제1 입력들로서 복수의 M개의 이벤트 스트림들 중 주어진 이벤트 스트림(ESn)에 대한 것이다.
따라서 원자적 블록체인 트랜잭션(TXn)은, 다음을 포함한다:
- n = M개의 입력들, 각각의 입력은 복수의 이벤트 스트림들 중 개개의 이벤트 스트림(ESn)과 연관되고, 각각의 n번째 입력은 개개의 이벤트 스트림(ESn)의 이전 트랜잭션(TXn-1)과 연관된 더스트 출력을 지출하고,
- n개의 입력들 각각에 대해, 개개의 이벤트 스트림(ESn)과 연관된 원자적 트랜잭션(TXn)에 대한 n번째 더스트 출력인 개개의 미지출 트랜잭션 출력(UTXOn_dust), 및
- 현재 이벤트(En), 즉 데이터 캐리어를 표현하는 이벤트 데이터와 연관된 미지출 트랜잭션 출력(UTXOn_data).
위의 양상들과 마찬가지로, 네트워크 채굴 수수료들을 적절하게 커버하기 위한 자금 입력들과 같은 부가적인 입력들이 있을 수 있고 원자적 트랜잭션에 대한 다른 출력들 이를테면, 변화 출력들 또는 데이터 캐리어 출력들 이를테면, 각각의 이벤트 스트림과 관련된 OP_RETURN이 또한 있을 수 있다.
이벤트 스트림(ESn)이 키 체인(K)과 연관되는 경우, 단계(602)와 유사하게, 개개의 n번째 더스트 입력 지출은 단계(908)에서 획득된 이전 트랜잭션에 대한 획득된 키 쌍(Ki-1)을 사용하여 인가된다. 원자적 블록체인 트랜잭션(TXn)에 대한 n번째 더스트 출력은 단계(908)로부터의 도출된 키 쌍(Kn)으로 보호되는 잠금 스크립트와 연관된다.
본 개시내용에서 논의된 모든 이벤트 스트림들에서, 더스트 입력들/출력들의 추적, 즉 더스트의 체인인 트랜잭션들은 블록체인 네트워크의 보안, 불변성 및 이중 지출 방지를 활용하여 로그 내 엔트리들의 재순서화를 방지하고, 사후 삽입/삭제, 포크(fork)들 즉, 대안적인 타임라인들 등을 방지하는 데 사용된다. 일련의 데이터 캐리어 트랜잭션들 상의 n번째 입력/출력 쌍에 의해 형성된 이 더스트의 체인은 개개의 단일 이벤트 스트림(ESn)을 집합적으로 보호한다.
표준 이벤트 스트림 더스트 체인 트랜잭션들과 마찬가지로, 랑데뷰 또는 원자적 트랜잭션들은 더스트 체인, 플랫폼 자금들 및 변화(트랜잭션 수수료들에 대한 것임), 각각의 이벤트 스트림에 대한 데이터 캐리어를 포함한다. 그러나 원자적 트랜잭션들은 각각 상이한 이벤트 스트림과 관련된 다수의 더스트 체인들이 단일 블록체인 트랜잭션을 통과하도록 허용한다.
따라서 모든 더스트 체인 쌍들은 플랫폼 자금 및 변화를 진행한다. 위에서 설명된 실시예에서 동기화를 위해 사용된 데이터 페이로드 또는 이벤트 데이터(En)는 원자적 트랜잭션의 출력이 될 것이다. 이 트랜잭션의 시맨틱은 더스트 체인이 오프닝(opening) n=M개의 입력/출력 쌍들에 포함되는 모든 스트림들에 데이터 페이로드를 추가하여 다수의 이벤트 스트림들에 걸쳐 데이터의 원자적 커밋을 효과적으로 제공하는 것이다.
위에 도 9에서 제시된 바와 같은 일부 실시예들에서, 입력 및 출력 인덱스들은 일대일 매핑을 가지며, 단일 데이터 요소는 최종 출력 인덱스를 갖는다. 위에서 언급된 바와 같이, 원자적 블록체인 트랜잭션에 참여하는 복수의 이벤트 스트림들이 올바르게 동기화/업데이트되었는지를 별개로 검증하는 것이 가능하다. 감사자 또는 검증 엔티티 또는 프로그램은 특정 이벤트 스트림을 체크하기 위해 개개의 이벤트 스트림(ESn)에 대해 사용되는 입력 인덱스를 요구할 수 있다. 일부 실시예들에서, 인덱스들은 클라이언트 또는 검증 엔티티가 이용 가능할 수 있는 메타데이터의 부분으로서 플랫폼 프로세서를 통해 제공될 수 있거나, 인덱스들은 트랜잭션 입력들의 관찰을 통해, 즉 개개의 이벤트 스트림의 이전 이벤트의 출력과 매칭하도록 입력들을 스캔함으로써 온-체인으로 획득될 수 있다.
클라이언트 대신 작용하는 검증 엔티티가 검증 중인 이벤트 스트림을 소유하거나 그에 대한 액세스를 갖는다고 가정하고, 계정의 모든 각각의 잔액 변화가 다른 계정의 동일하고 반대되는 잔액 변화와 매칭된다는 것을 검증하는 것이 바람직한 이중 엔트리 계정 정책을 사용하여 도 9의 방법을 사용하여 동기화된 이벤트 스트림을 검증하는 예를 고려한다. 이 예는 단 하나의 차변 및 하나의 대변 계정으로 제한되지 않으며 자산 및 발행자에 대한 모든 잔액 변화들의 합이 0인 한, 임의의 수의 계정들에 적용될 수 있다. 예를 들어, 2개의 이벤트 스트림들(A 및 B)을 고려하며, 여기서 A는 주어진 통화에 대해 환율 또는 동의된 오프셋 X를 사용하는 계정을 표현하고 B는 환율 또는 동의된 오프셋 Y를 사용하는 계정을 표현하며, 여기서 1X=0.5Y이다. A가 오프셋 X에서 2개의 통화 유닛들을 B에 이전할 때, 2개의 계정들이 동기화된다고 간주한다. 이 이전은 각각의 스트림에 대한 동기화 이벤트(En)를 표현하지만, 각각과 연관된 이벤트 데이터는 상이할 가능성이 높다. A의 경우, 이벤트 데이터는 오프셋 X에서 2개의 유닛들의 감소를 표현할 수 있다. B의 경우, 이벤트 데이터는 오프셋 Y에서 1개의 유닛의 증가를 표현할 수 있으며, 이는 A로부터 이전되는, 오프셋 X에서 2개의 유닛들을 더한 것과 등가이다.
다른 예들에서, 이전은 2개의 별개의 원자적 트랜잭션들로 분할될 수 있으며, 하나는 양 이벤트 스트림들에 레코딩되는, A로부터 2X 감산 이벤트에 대한 것이고 다른 하나는 양 스트림들에 또한 레코딩되는, B로의 1Y 유닛의 덧셈 이벤트에 대한 것이다.
검증은 원자적 블록체인 또는 랑데뷰 트랜잭션이 직면될 때까지 주어진 이벤트 스트림(ESn) 스트림의 이벤트들을 체크하기 위해 순차적으로 프로세싱될 수 있다. 이 지점으로부터, 검증 엔티티는 동일한 클라이언트에 의해 또한소유된 다른 정들을 검토하고 제로-섬 계산(zero-sum calculation)을 수행할 수 있다. 임의의 오류는 그 후 이 스테이지에서 플래깅될 수 있으며, 오류가 없는 경우, 검증 엔티티는 검증 중인 스트림 내 다음 이벤트를 검증하는 것으로 진행한다.
3개의 스트림들에 추가되는 원자적 트랜잭션 입력들/출력들의 예는 아래에 주어진다.
Figure pct00006
2개의 이벤트 스트림들(T1 및 T2)과 연관된 원자적 트랜잭션의 예는 도 11에서 보여진다. 이 도면에서, 각각의 T1 및 T2의 더스트 입력/출력 쌍은 각각 인덱스 0 및 인덱스 1에서 원자적 트랜잭션(TX12) 내 처음 2개의 엔트리들임을 알 수 있다. TX12는 2개의 이벤트 스트림들(T1 및 T2)과 양 더스트 체인들을 추적한다.
복수의 이벤트 스트림들(ESn =1 to M)을 동기화하는 원자적 트랜잭션에 이어, 일부 실시예들에서 API 엔드포인트는 복수의 이벤트 스트림들(ESn =1 to M) 내 각각의 이벤트 스트림(ESn)과 연관된 다음 가용 인덱스 값들의 응답 어레이를 리턴한다. 이는 동기화를 요청하는 클라이언트에 제공될 수 있다. 응답 어레이는 각각의 이벤트 스트림에 대한 독립적인 검증 목적들을 위해 또는 클라이언트가 다음 이벤트에 대한 요청을 위해 개개의 이벤트 스트림(ESn)에 대해 어떤 인덱스 값을 사용할지를 인식하도록 제공될 수 있다. 인덱스가 하나 이상의 이벤트 스트림들에 대해 알려지지 않은 경우 예컨대, 이벤트 스트림이 비어 있는 경우, 이벤트 스트림에 대해 NULL 값이 포함될 수 있다.
일단 데이터가 추가되고 이에 따라 다수의 M개의 이벤트 스트림들에 전부에 걸쳐 동기화되면, 각각의 개별 이벤트 스트림(ESn)은 원자적 트랜잭션에 이어, 제3 양상에서 논의된 바와 같이 별개의 스트림들로서 독립적으로 진행될 수 있다.
동작에 이어, 복수의 이벤트 스트림들(ESn =1 to M)은 단일 다중-입력/다중-출력 랑데뷰 또는 원자적 트랜잭션에서 온-체인으로 체결되도록 블록체인에 제출된다. 온-체인 체결 시에, 단계(902)의 API는 온-체인으로 체결될 M개의 이벤트 스트림들 각각을 수집하여 단일 블록체인 랑데뷰 트랜잭션으로 그룹화한다.
도 10은 본 개시내용의 제4 양상에 관한 것이며, 도 1에 도시된 플랫폼(100) 또는 도 3의 플랫폼(300)과 같이 블록체인과 연관된 이벤트 스트림들을 동기화하기 위한 데이터 기록 서비스 또는 플랫폼에 액세스하기 위한 컴퓨터 구현 방법을 도시한다. 도 10의 방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현된다.
단계(1002)에서, 이벤트 스트림들을 동기화하기 위한 플랫폼과 연관된 API(application programming interface) 엔드포인트가 식별된다. 이 API는 API들을 전달하는 하나 이상의 알려진 수단에 의해 클라이언트에 대해 이용 가능하게 될 수 있다. 도 8과 관련하여 언급된 바와 같이, 이것은 데이터-기록 서비스를 제공하기 위한 호스트 플랫폼 프로세서와 연관된 API일 수 있거나, 다수의 이벤트 스트림들을 동기화는데 특유의 별개의 API일 수 있다.
단계(1004)에서, 클라이언트는 복수의 M개의 이벤트 스트림들(ESn =1 to M)에 추가되거나 그와 동기화하기 위한 이벤트(En)와 연관된 요청을 준비한다. 위에서 언급한 바와 같이, 복수의 M개의 이벤트 스트림들(ESn =1 to M)에 대한 식별자들 및/또는 복수의 이벤트 스트림들 각각에 대한 타겟 인덱스들이 또한 요청에 포함될 수 있다.
단계(1006)에서, 단계(1004)에서 준비된 요청은 플랫폼 프로세서가 HTTP(Hypertext Transfer Protocol) 또는 REST API로서 구현되기 때문에 HTTP 또는 유사한 송신 프로토콜 포맷을 사용하여 전송된다. 이 요청은 도 9와 관련하여 위에서 언급된 바와 같이 JSON 오브젝트로서 전송된다.
단계(1008)에서, M개의 이벤트 스트림들 각각에 관련된 결과가 수신된다. 이벤트(En)가 복수의 이벤트 스트림들 중의 이벤트 스트림들 중 하나에도 추가되지 않은 경우, 결과는 오류 메시지일 것이다. 이벤트(En)가 M개의 이벤트 스트림들 모두에 성공적으로 추가된 경우, 일부 실시예들에서, API는 복수의 이벤트 스트림들(ESn =1 to M) 각각에 대한 현재 인덱스 또는 길이의 세부사항들을 갖는 응답 어레이를 리턴한다. 일부 실시예들에서 이벤트(En)에 대한 원자적 블록체인 트랜잭션의 출력 스크립트와 연관된 결과가 또한 수신된다. 이 결과는 HTTP 송신 프로토콜 포맷으로 클라이언트에 제공된다. 일부 실시예들에서, 결과는 플랫폼 프로세서 내의 또는 플랫폼 프로세서와 연관된 블록체인과 별개로 로그에 저장될 수 있다.
제5 양상 - 블록체인과 연관된 트랜잭션들의 검증
데이터 기록기(302a)와 연관된 하나 이상의 프로세서들과 같이 도 3의 플랫폼(300)에 의해 제공되는 플랫폼 서비스들과 연관된 데이터 서비스들(302)은 본 개시내용의 제2, 제3 및 제4 양상들에서 논의된 바와 같이 이벤트 스트림들과 같은 메커니즘들의 사용에 의해 불변성을 제공하기 위해 타임스탬핑, 변조-방지 증거(tamper-proof evidence) 및 부인 방지 메커니즘들에 의해 보장되는 데이터 무결성을 보장한다. 데이터 기록기와 연관된 실시예들은 현대 데이터 보호 규정을 준수하는 데이터 저장 및 리트리벌을 위한 솔루션들을 제공하고 부인 방지 속성들을 도입하며, 데이터의 독립적인 검증을 허용하도록 간단한 절차로 모든 속성들의 인증서(certification)를 전달한다.
데이터 서비스들(302) 및, 특히 데이터 기록기(302a)는 고객 또는 클라이언트 데이터가 내부에 임베딩된 온-체인 트랜잭션을 구성한다. 트랜잭션들은 변경 불가능하고 공개되며, 일단 트랜잭션이 블록체인에 포함되면, 트랜잭션은 설명된 바와 같이 제거될 수 없다. 또한 이러한 트랜잭션들은 블록체인 네트워크를 통해 브로드캐스트된다.
일부 경우들에서, 트랜잭션들의 변경 불가능 및 공개 속성들의 이점들은 데이터 개인 프라이버시 및 보호 법률들에 속하거나 기밀인 민감한 데이터를 다룰 때 일부 장애물들을 제시할 수 있다.
플랫폼(300) 및 바람직하게 또는 특히, 데이터 기록기(302a)와 연관된 하나 이상의 프로세서들과 연관된 제1 공증 개념은 고객의 솔티드 지문(salted fingerprint) 또는 레코드 또는 클라이언트 데이터를 블록체인에 커밋한다. 솔트는 데이터 기록기와 연관된 각각의 트랜잭션에 대해 랜덤으로 생성될 수 있는 고유한 값인 것으로 이해된다. 제1 개념의 솔티드 데이터는 아무것도 드러내지 않고 브레인 월렛 공격(brain wallet attack)과 같은 억지 프리이미지 공격(brute force preimage attack)들을 방지하는 이점을 갖는다.
플랫폼 및 특히 데이터 기록기(302a)와 연관된 하나 이상의 프로세서들과 연관된 제2 공개 개념은 전체 데이터 페이로드들을 블록체인에 커밋한다. 이 제2 개념은 유리하게는, 클라이언트 데이터의 영구성 및 분배를 제공한다.
데이터가 공증되거나 공개되면, 블록체인에의 포함의 증명들이 플랫폼에 의해 생성된다. 인클로징 트랜잭션 및 그의 포함 증명의 조합이 인증서를 형성한다. 이러한 인증서들은 위조되거나 변조될 수 없는 수학적으로 확실한 증명들이며, 유리하게는, 플랫폼(300) 또는 데이터 기록기(302a)와 같이 플랫폼과 연관된 임의의 서비스와 떨어져 있거나 별개로 독립적으로 검증 가능하다.
본 개시내용의 제5 양상에서, 도 3의 플랫폼(300)의 데이터 서비스(302)와 연관된 하나 이상의 특징들, 방법들 또는 프로세스들은, 플랫폼(300)과 독립적으로 구현될 수 있는 동시에, 공증 또는 공개 지점에서 공증되거나 공개된 고객 또는 클라이언트 데이터의 저장 또는 제공 및 상기 데이터의 후속 리트리벌을 허용한다. 또한, 일부 실시예들에서, 유리하게는, 클라이언트 또는 고객 엔티티가 플랫폼(300)으로부터, 위에서 언급된 공증 및 공개 인증서들을 리트리브하도록 허용하는 데이터 리트리벌 기능성이 제공된다.
인증 프로세스의 부분으로서, 위에서 언급된 바와 같이, 플랫폼(300) 또는 데이터 서비스들(302)과 연관된 하나 이상의 프로세서들은 하나 이상의 온-체인 트랜잭션들을 생성한다. 블록에 포함되면, 트랜잭션들은 불변성의 기본 속성들을 상속받으며 타임스탬핑 및 변조 증거와 연관될 것이다. 데이터 서비스들은 트랜잭션, 블록 헤더 및 트랜잭션을 블록 헤더에 링크하는 포함 증명을 포함하는 데이터 번들인 인증서를 추가로 생성한다.
플랫폼 서비스들 검증 - 제1 구현
제5 양상의 제1 실시예 또는 구현은 임의의 트랜잭션이 블록에 포함되는 것으로 입증될 수 있는 방법을 설정하기 위한 방법을 도시한다.
트랜잭션이 블록체인에 포함되었음을 검증하기 위해 다음 단계들이 취해진다:
1. 인증된(certied) 트랜잭션이 블록에 포함됨을 보장한다. 일부 실시예들에서, 이는 인증서 내에 포함된 포함 증명을 사용하는 것을 포함한다.
2. 단계 1의 블록이 블록들의 최장 작업 증명 체인의 일부임을 보장한다. 일부 실시예들에서 이는 최장 작업 증명 블록체인의 독립적으로 소싱된 뷰(independently sourced view)를 사용하는 것을 포함한다.
이들 단계들은 일부 예들에서 데이터 서비스들 자체와 연관된 하나 이상의 프로세서들 또는 도구 또는 소프트웨어에 의해 수행될 수 있다. 그러나 데이터 서비스들을 사용하는 것은 검증을 위해 플랫폼(300) 상에 대한 신뢰의 요소를 도입한다. 완전히 독립적인 검증을 전달하기 위해, 본 개시내용에 따른 검증 프로세스는 유리하게는, 어떠한 의존 데이터 서비스들(302) 또는 실제로 어떠한 플랫폼 서비스 도구 없이 수행된다.
제5 양상의 제1 구현에 따른 검증 절차의 예시적인 방식들은 도 11에서 보여지고 아래에 주어진다.
명명법:
Figure pct00007
방법론
1. 단계(1102)에서 트랜잭션(T)을 획득 또는 식별한다. 그 후 단계(1104)에서 클라이언트 또는 계정과 연관된 로컬 사본들 또는 저장소로부터 또는 데이터 서비스 저장소 시설로부터 C를 획득한다.
2. 단계(1106)에 따라 유효한 블록들의 최장 체인을 결정한다. 일부 실시예들에서, 최장 작업 증명 블록체인 뷰를 소싱하는 것은 예컨대, 로컬 헤더-전용 네트워크 클라이언트들을 사용하여 행해질 수 있다. 로컬 헤더 클라이언트는 트랜잭션(T)과 연관된 블록 헤더들을 저장하도록 구성된 것이다. 최장 체인을 설정하기 위한 다른 알려진 또는 기존 기술들이 또한 활용될 수 있다. 참조의 편의를 위해, 헤더 클라이언트의 예는 본 개시내용 이후에 본원에서 언급된다.
3. 단계(1108)에서, 아래에서 주어진 바와 같이 R'를 계산한다.
Figure pct00008
4. 단계(1110)에서 R = R'임을 검증하거나, 그렇지 않으면 단계(1112)에서 실패한다.
5. 단계(1114)에서 R'가 HB에 포함됨을 검증하거나, 그렇지 않으면 실패하고, 단계(1114)에 따라 HB ∈ Ω임을 검증하거나, 그렇지 않으면 단계(1116)에서 실패한다.
비트코인 블록 헤더들의 로컬 데이터베이스에 대해 검증이 수행될 수 있다. 이 데이터베이스는 네트워크 상의 모든 피어들의 회전 서브세트로부터 실시간으로 헤더 메시지들을 동기화함으로써 비트코인 네트워크로부터 채워질 수 있다. 최장 체인은 유리하게는, 모든 피어들의 랜덤 및 회전 선택으로부터 독립적으로 소싱되어 결국 모든 피어들과 동기화된다. 이는 유리하게 제1 실시예의 검증 프로세스에 대한 이클립스(eclipse) 공격들 및 이에 따라, 악의적인 당사자가 블록체인 네트워크 내 다수의 노드들 또는 IP 어드레스들에 대한 액세스를 갖거나 이들을 제어하는 경우 적대적 포크의 생성을 방지한다. 이클립스 공격은 악의적인 당사자가 여전히 수학적으로 역으로 추적될 수 있는 잘못된 증거들을 블록에 제공함으로써 유효한 블록 체인을 은폐하도록 시도할 수 있지만, 그 블록이 유효하지 않거나 악의적인 당사자에 의해 생성된 것일 수 있는 공격이다.
예컨대, 오픈-소스 BSV(Bitcoin SV) 헤더 클라이언트들이 이용 가능해질 수 있다. 헤더 클라이언트는 위에서 설명된 바와 같이 동작하고 헤더들의 최장 체인을 소싱하는 데 사용될 수 있다. 이는 오픈 소스이므로, 식별된 체인이 블록 헤더들의 최장 체인을 충실하고 진실되게 표현한다는 것을 보장하기 위해 독립적인 검증자 엔티티에 의해 또한 검사될 수 있다.
대안적으로, 다른 결과(implication)들이 이용 가능해질 수 있거나 독립적인 검증자가 요구된 데이터를 소싱하기 위해 자체 헤더 클라이언트를 구현할 수 있다.
공개 블록 탐색기 서비스들이 있다. 이러한 서비스들은 웹 인터페이스를 통하든 API를 통하든, 이러한 공개 블록 탐색기들은 일반적으로 블록 해시가 제공될 때 블록 메타데이터를 가져오는(fetch) 기능성을 제공한다. 소싱 헤더들과 마찬가지로, 제3 자 또는 독립적인 데이터 소스들을 사용하는 경우, 바람직하게는 소스들의 선택이 사용될 수 있다. 이는 유리하게는, 임의의 독립적인 검증자가 볼 수 있는 블록체인의 뷰를 제어하는 단일 또는 소수의 외부 행위자들의 가능성을 완화하기 위한 것이다.
위에서 언급된 바와 같이, 채널은 검증 데이터가 전송 및 수신되기 위해 사용될 수 있다.
데이터 기록기 검증 - 제2 구현
제1 내지 제3 양상들과 관련하여 위에서 논의된 바와 같이, 데이터 서비스들의 데이터 기록기(302a)는 고객들이 개별 데이터 페이로드들을 공증 및/또는 공개하도록 허용하는 API를 제공한다. 이는 데이터(위에서 제시된 바와 같은 공개) 또는 데이터의 솔티드 해시 커밋(위에서 지정된 바와 같은 공증)을 비트코인 트랜잭션에 임베딩함으로써 이루어진다. 플랫폼은 그 후 트랜잭션들을 펀딩한다. 따라서, 고객들 또는 클라이언트들은 유리하게는, POST와 같은 HTTP 요청을 통해 임베딩된 데이터를 제공하는 것 외에, 온-체인 트랜잭션 구성에 참여하지 않는다.
데이터 캐리어 트랜잭션은 제3 양상에서 위에서 언급된 바와 같이 플랫폼으로부터 다시 플랫폼으로 가치 또는 자금들(잔돈, 임의의 채굴 수수료보다 작음)을 지불하고, 그 후 부가적인 증명 가능하게 지출 불가능한 트랜잭션 출력으로서 데이터 커밋멘트를 포함한다. 위에서 제시된 공증 및 공개는 유사한 흐름을 따른다.
첫째, 데이터는 블록체인에 제출되는 트랜잭션 내로 엔벨로핑된다(enveloped).
둘째, 추후 시간에, 트랜잭션이 블록 내로 포함된다.
그 후, 클라이언트는 예로서 아래에 주어진 바와 같이 HTTP POST 요청을 함으로써 동작을 개시한다:
Figure pct00009
일부 실시예들에서, 플랫폼은 플랫폼 내에 통합되거나 그렇지 않으면 플랫폼과 연관된 하나 이상의 저장소들 또는 저장 모듈들을 제공할 수 있다. 이러한 저장소들은 플랫폼 서비스들과 연관된 하나 이상의 클라이언트들에 대해 제공될 수 있다. 따라서, 클라이언트가 그와 연관된 저장소를 갖지 않거나 클라이언트와 연관된 하나 이상의 프로세서와 관련하여 또는 클라이언트 엔티티가 아닌 로케이션에 플랫폼(300)과 연관된 데이터를 저장하는 것을 선호하는 것일 수 있는 경우, 플랫폼과 연관된 저장소가 구입되거나 임대되거나 사용될 수 있다. 이 경우에, 플랫폼 관련 저장소가 존재하거나 활성인 경우, 클라이언트 요청(HTTP POST) 내 페이로드는 플랫폼과 연관된 개인 및/또는 지리적-제한 데이터 저장소에 기록된다.
공증의 경우, 전체 고객 또는 클라이언트 페이로드의 솔티드 해시인 커밋멘트 페이로드가 생성된다.
데이터 캐리어 트랜잭션이 구성되고 펀딩된 트랜잭션들이 그 후 블록체인에 제출되어, 수락/거부 메시지를 응답으로 수신되도록 허용한다.
요청에 대한 응답은 식별자 즉, 기록 ID를 포함하며, 이는 추후에, (사용 가능한 경우) 데이터 인증서의 사본을 요청하고 (저장된 경우) 오리지널 데이터 페이로드를 리트리브하는 데 사용될 수 있다.
예시적인 데이터 기록기 HTTP 응답 템플릿이 아래에서 주어진다:
Figure pct00010
제5 양상의 제2 구현에서, 본 개시내용은 제1 실시예에서 제시된 검증을 확장하여서, 트랜잭션의 무결성을 적용할 뿐만 아니라 부가적으로 트랜잭션이 예상된 고객 또는 클라이언트 데이터를 포함한다는 것을 확인한다.
제2 구현은 플랫폼 프로세서에 의존하지 않고 수행될 수 있다.
제5 양상의 제2 구현에 따른 검증 절차의 예시적인 방식들은 도 12에서 보여지고 아래에 주어진다.
명명법:
Figure pct00011
방법론:
1. 로컬 사본들로부터 또는 데이터 서비스 저장 시설로부터 D, C, 및 공증의 경우, S를 획득한다. 도 12의 단계(1202)를 참조한다.
2. 단계(1204)에서 데이터 커밋멘트 d를 결정한다
공증된 데이터의 경우, d := sha256(sha256(S||D))
공개된 데이터에 대해, d := D
3. 단계(1206)에서 C로부터 T를 추출한다. 인증서가 JSON 포맷인 경우, 추출은 키에 기초하여 데이터를 판독하는 것을 포함할 수 있다. 대안적으로, 이진 인코딩 또는 다른 알려진 방법들이 T를 추출하기 위해 C 내 데이터를 파싱하는데 사용될 수 있다.
4. T가 다음 테스트들을 충족시키는 적어도 하나의 출력을 포함한다는 것을 검증하거나, 실패한다.
value == 0, 즉 T 내 출력들 중 적어도 하나가 0으로 세팅된 값을 갖는지를 테스트함
script == OP_FALSE OP_RETURN <d>; 즉, 스크립트 T 중 하나가 리턴된다는 것을 테스트함.
5. 제1 구현 및 도 11에서 논의된 바와 같은 절차를 수행한다.
이벤트 스트림 검증 - 제3 구현
본 개시내용의 제2 및 제3 양상과 관련하여 논의된 바와 같이, 이벤트 스트림들은 블록체인-지원 추가-전용 로그들이다. 플랫폼 서비스들(300)과 연관된 클라이언트들은 도 5 내지 도 8에 제시된 바와 같이 이벤트 스트림들을 생성, 추가 및 마무리할 수 있다. 모든 데이터 서비스들(302)과 마찬가지로, 이벤트 스트림에 추가된 데이터는 공증되거나 공개될 수 있으며, 기본 데이터는 선택적으로 개인 및/또는 지리적-펜스 저장소(geo-fenced storage)에 저장될 수 있다. 이러한 선택들은 엔트리별 En이 아니라 스트림 별 ES 로 이루어질 수 있다.
이벤트 스트림들과 연관된 데이터 기록기(302a)는 위에서 제시된 바와 같이 로그 내의 임의의 단일 엔트리를 인증하는 데 사용될 수 있다. 이벤트 스트림들은 기본 블록체인을 활용하여 이벤트 스트림들과 연관된 적어도 다음의 고유 속성들 또는 규칙들 또는 사실들에 의해 제5 양상의 제1 및 제2 실시예들과 연관된 이점들을 확장한다.
- 이벤트 스트림 내 개별 엔트리들은 한 번 기록되면 수정될 수 없다.
- 스트림들은 추가 전용이고, 이에 따라
이전에 인접 엔트리들 사이에 어떠한 엔트리들도 삽입될 수 없고,
어떠한 엔트리들도 제거될 수 있고,
어떠한 엔트리들도 재순서화될 없다.
- 비인가 당사자들은 이벤트 스트림에 이벤트를 추가할 수 없다.
데이터를 온-체인으로 임베딩한다는 개념과 함께, 제5 양상의 제1 및 제2 구현들과 연관된 검증 절차들이 이벤트 스트림 내의 임의의 개별 이벤트에 대해 여전히 적용된다. 제3 구현에서, 트랜잭션 템플릿은 개별 트랜잭션들을 링크하는 더스트(위에서 언급된 바와 같이, 비트코인의 최저 가능 값)의 체인을 포함하도록 확장된다. 이 더스트 체인 내 각각의 트랜잭션은 스트림 내 단일 이벤트를 표현하는 데이터 캐리어를 포함한다. 더스트 체인 내 트랜잭션들은 제3 양상에서 자세히 설명된 바와 같이 선행 트랜잭션으로부터의 더스트 출력을 지출하는 연속 트랜잭션에 의해 링크된다.
비트코인 블록체인은 시스템에서 어떠한 가치의 이중 지출도 허용하지 않는다. 따라서 각각의 지출된 트랜잭션 출력은 정확히 하나의 후행자 트랜잭션에서 정확히 한 번 지출된다. 이 속성은 유리하게는, (i) 로그의 임의의 포크를 방지하고; (ii) 각각의 엔트리가 정확히 하나의 선행자 및 0개 또는 하나의 후행자를 갖는다는 것을 보장하고; (iii) 위에서 언급된 트랜잭션 이외의 어떠한 다른 트랜잭션도 비트코인의 규칙들 하에서 유효하지 않을 것이고 이에 따라 어떠한 다른 구조도 이벤트 스트림들과 관련하여 가능하지 않을 수 있다.
변경 불가능 원장은 트랜잭션 그래프들이 추후 시점에 재작성되는 것을 방지한다. 이는 유리하게는, 어떠한 엔트리도 사후에 삽입될 수 없도록 보장한다. 당사자가 더스트 체인의 어딘가의 트랜잭션의 세부사항들 및 이에 따라 엔트리를 보류시키는 것이 가능하지만; 그 당사자가, 더스트 체인이 특정 엔트리를 포함하지 않는다는 것을 다른 당사자에게 확신시키기 위해 트랜잭션 포함 유효성 검증 체크(transaction inclusion validation check)들을 통과할 대안적인 자금 움직임을 구성하는 것이 가능하지 않다. 더스트 체인은 당사자가 보류시키려고 시도한 엔트리의 부재를 드러낼 것이다.
모든 이벤트 스트림 상호작용들은 HTTP API들에 의해 구동된다. 스트림이 다음의 예시적인 요청으로 구성될 수 있다:
Figure pct00012
본 개시내용의 예들과 마찬가지로, 위의 이 요청 방식들은 단순화된다. 실제 API 호출은 액세스 제어 정책, 보존 정책, 온-체인 가시성 등을 정의하는 많은 파라미터들을 수락할 수 있다.
그 후, API는 이벤트 스트림과 관련된 정보로 응답할 수 있다:
Figure pct00013
데이터는 다음과 같은 부가적인 HTTP 요청들을 통해 이벤트 스트림에 추가될 수 있다:
Figure pct00014
seq-no의 선택적 after 파라미터는 이벤트 스트림이 마지막으로 관찰된 이래로 추가되지 않은 경우에만 호출자가 이벤트 스트림에 추가하도록 허용한다. 이는 제4 양상에 따라 원자적 블록체인 또는 랑데뷰 트랜잭션들을 사용하여 다수의 클라이언트들 사이에서 이벤트 스트림 동작들을 동기화할 때 유용할 수 있다. 이는 낙관적 동시성 제어의 형태로서 역할을 할 수 있다.
HTTP 응답 템플릿의 예는 아래에 주어진다:
Figure pct00015
after 파라미터가 제공되었고 제공된 seq-no가 이벤트 스트림 내 마지막 엔트리가 아닌 것으로 판명되는 경우, 상기 대신, HTTP 409 Conflict 응답이 대신 리턴될 것이다.
선택적으로 저장된 페이로드들과 같은 이벤트 스트림 데이터에 더해 인증서들은 플랫폼 서비스들 300 HTTP API에서 다운로드될 수 있다. 대안적으로, 인가된 관찰자는 SPV(simple payment verification)와 연관된 것과 같은 상이한 API를 사용하여 이벤트 스트림의 복제들을 수신할 수 있다. 이 API는 새로운 데이터에 대한 푸시 알림들을 제공할 수 있다. 이 구성에서, 이벤트 스트림들 서비스들은 SPV 채널 서버로서 작용하고 (복제들을 수신하는) 관찰자들은 SPV 채널 클라이언트들일 수 있다.
제5 양상의 제3 구현은 제1 및 제2 구현들 둘 모두를 확장하여 이벤트 스트림 내 이벤트들 간의 관계를 부가적으로 확인한다. 이벤트 스트림들에 의해 생성된 인증서들은 인과적인 앞에 나옴(came-before), 뒤에 나옴(comes-after), 직전(immediately-precedes) 및 직후(immediately-follows) 관계들에 대한 증거들을 형성한다.
개별 엔트리들에 대한 제1 및 제2 구현들 외에도, 이벤트 스트림의 무결성은 스트림의 하나의 단부에서 시작하고 스트림의 다른 하나의 단부가 도달될 때까지 더스트 체인 내 각각의 트랜잭션을 순회(traversing)함으로써 제3 구현에서 검증될 수 있다.
각각의 트랜잭션에 대해, 첫째로 도 12에 따라 제2 실시예에서 데이터 기록기에 대해 설명된 검증이 수행되며, 이는 별도로 데이터 기록기 서비스와 동일한 보장이 유지된다는 것을 확인한다.
둘째로, 트랜잭션의 입력들 및 출력들이 검사된다. 트랜잭션에 대한 제1 입력은 더스트여야 하는 이전 트랜잭션의 제1 출력을 참조해야 한다. 더스트 체인에서 임의의 불일치는 연관된 추가-전용 로그가 신뢰할 수 없음을 표시한다.
모든 데이터 서비스들과 마찬가지로, 구현에 따른 방법이 이 검증을 수행하도록 플랫폼 서비스(300)에 의해 수행될 수 있지만; 제5 양상은 완전히 독립적인 검증이 수행되도록 허용한다.
제5 양상의 제3 구현에 따른 검증 절차의 예시적인 방식들은 도 13에서 보여지고 아래에 주어진다.
명명법:
Figure pct00016
방법론:
이 검증은 이벤트 스트림에서 순방향 또는 역방향으로 수행될 수 있다. 순방향 검증
Figure pct00017
이 본원에서 설명되지만 제한하는 것으로 간주되어서는 안 된다.
1. 스트림 생성의 검증: 도 13의 단계(1302)에 따라 T0, C0를 획득한다.
T0, C0에 대한 제1 실시예(도 11)의 검증을 수행한다.
단계(1304)에서 T0에 대한 제1 입력이 더스트가 아님을 검증하고, 그렇지 않으면 단계(1306)에서 실패한다.
1308에 따라 T0의 제1 출력이 더스트임을 검증하고, 그렇지 않으면 단계(1310)에서 실패한다.
2. 첨부-전용 로그 내 각각의 데이터 엔트리(Dn)에 대해:
Dn, Cn를 획득한다.
단계(1312)에 따라 Dn, dn, Cn에 대한 데이터 기록기 검증을 수행하고 임의의 실패 결과를 전파한다.
단계(1314)에 따라 입력(Tnin0)이 출력(Tprevout0)을 지출함을 검증하거나 그렇지 않으면 단계(1316)에서 실패한다.
Tnin0 prevout, previdx 매칭 H(Tprev), 0, 그렇지 않으면 실패
Tnin0scriptSig 리딤 스크립트가 Tprevout0 scriptPubKey 잠금 스크립트(실행하여) 올바르게 풀어냄
3. 선택적으로 마무리 스트림들에 대해, 다음에 기초하여 단계(1318)에서 마무리 트랜잭션을 검증한다
Tfinal, Cfinal를 획득한다.
Tfinal, Cfinal에 대한 제1 실시예 검증을 수행한다.
Tfinal에 대한 제1 입력이 더스트임을 검증하고, 그렇지 않으면 실패한다.
Tfinal의 제1 출력이 더스트가 아님을 검증하고, 그렇지 않으면 실패한다.
입력 Tfinalin0이 출력 Tprevout0을 지출함을 검증한다.
이제 도 14를 참조하면, 본 개시내용의 적어도 하나의 실시예를 실행하는 데 사용될 수 있는 컴퓨팅 디바이스(2600)의 예시적이고 단순화된 블록도가 제공된다. 다양한 실시예들에서, 컴퓨팅 디바이스(2600)는 위에서 예시되고 설명된 시스템들 중 임의의 것을 구현하는 데 사용될 수 있다. 예컨대, 컴퓨팅 디바이스(2600)는 도면의 DBMS의 하나 이상의 구성요소들로서 사용되도록 구성될 수 있거나, 컴퓨팅 디바이스(2600)는 주어진 사용자와 연관된 클라이언트 엔티티가 되도록 구성될 수 있으며, 클라이언트 엔티티는 도 14의 DBMS에 의해 관리되는 데이터베이스에 대한 데이터베이스 요청들을 행한다. 따라서 컴퓨팅 디바이스(2600)는 휴대용 컴퓨팅 디바이스, 개인용 컴퓨터 또는 임의의 전자 컴퓨팅 디바이스일 수 있다. 도 14에 도시된 바와 같이, 컴퓨팅 디바이스(2600)는 하나 이상의 레벨들의 캐시 메모리 및 메인 메모리(2608) 및 영구 저장소(2610)를 포함하는 저장 서브시스템(2606)과 통신하도록 구성될 수 있는 메모리 제어기를 갖는 하나 이상의 프로세서들(집합적으로 2602로 라벨링됨)을 포함할 수 있다. 메인 메모리(2608)는 도시된 바와 같이 동적 랜덤 액세스 메모리(DRAM)(2618) 및 판독 전용 메모리(ROM)(2620)를 포함할 수 있다. 저장 서브시스템(2606) 및 캐시 메모리(2602)는 본 개시내용에서 설명된 바와 같이 트랜잭션들 및 블록들과 연관된 세부사항들과 같은 정보의 저장을 위해 사용될 수 있다. 프로세서(들)(2602)는 본 개시내용에서 설명된 바와 같은 임의의 실시예의 기능성 또는 단계들을 제공하기 위해 활용될 수 있다.
프로세서(들)(2602)는 또한 하나 이상의 사용자 인터페이스 입력 디바이스들(2612), 하나 이상의 사용자 인터페이스 출력 디바이스들(2614) 및 네트워크 인터페이스 서브시스템(2616)과 통신할 수 있다.
버스 서브시스템(2604)은 컴퓨팅 디바이스(2600)의 다양한 구성요소들 및 서브시스템들이 의도된 대로 서로 통신하는 것을 가능하게 하기 위한 메커니즘을 제공할 수 있다. 버스 서브시스템(2604)이 단일 버스로서 개략적으로 도시되지만, 버스 서브시스템의 대안적인 실시예들은 다수의 버스들을 활용할 수 있다.
네트워크 인터페이스 서브시스템(2616)은 다른 컴퓨팅 디바이스들 및 네트워크들에 대한 인터페이스를 제공할 수 있다. 네트워크 인터페이스 서브시스템(2616)은 다른 시스템들로부터 컴퓨팅 디바이스(2600)로 데이터를 수신하고 컴퓨팅 디바이스(2600)로부터 다른 시스템들로 데이터를 송신하기 위한 인터페이스 역할을 할 수 있다. 예컨대, 네트워크 인터페이스 서브시스템(2616)은 데이터 기술자(data technician)가 디바이스를 네트워크에 연결하는 것을 가능하게 할 수 있어서, 데이터 기술자는 데이터 센터와 같은 원격 위치에 있으면서 디바이스로 데이터를 송신하고 디바이스로부터 데이터를 수신할 수 있을 수 있다.
사용자 인터페이스 입력 디바이스들(2612)은 하나 이상의 사용자 입력 디바이스들 이를테면, 키보드; 통합 마우스, 트랙볼, 터치패드 또는 그래픽 태블릿과 같은 포인팅 디바이스; 스캐너; 바코드 스캐너; 디스플레이에 통합된 터치스크린; 음성 인식 시스템들, 마이크로폰들과 같은 오디오 입력 디바이스들; 및 다른 유형들의 입력 디바이스들을 포함할 수 있다. 일반적으로, "입력 디바이스"라는 용어의 사용은 컴퓨팅 디바이스(2600)에 정보를 입력하기 위한 모든 가능한 유형들의 디바이스들 및 메커니즘들을 포함하도록 의도된다.
하나 이상의 사용자 인터페이스 출력 디바이스들(2614)은 디스플레이 서브시스템, 프린터, 또는 비-시각적 디스플레이 이를테면, 오디오 출력 디바이스 등을 포함할 수 있다. 디스플레이 서브시스템은 음극선관(CRT), 평면 패널 디바이스 이를테면, 액정 디스플레이(LCD), 발광 다이오드(LED) 디스플레이, 또는 프로젝션 또는 다른 디스플레이 디바이스일 수 있다. 일반적으로, "출력 디바이스"라는 용어의 사용은 컴퓨팅 디바이스(2600)로부터 정보를 출력하기 위한 모든 가능한 유형들의 디바이스들 및 메커니즘들을 포함하도록 의도된다. 하나 이상의 사용자 인터페이스 출력 디바이스들(2614)은, 예컨대, 설명된 프로세스들 및 변형들을 내부에서 수행하는 애플리케이션과의 사용자 상호작용이 적절할 수 있을 때 그러한 상호작용을 용이하게 하기 위한 사용자 인터페이스를 제시하는 데 사용될 수 있다.
저장 서브시스템(2606)은 본 개시내용의 적어도 하나의 실시예의 기능성을 제공할 수 있는 기본 프로그래밍 및 데이터 구조들을 저장하기 위한 컴퓨터-판독 가능 저장 매체를 제공할 수 있다. 하나 이상의 프로세서들에 의해 실행될 때, 애플리케이션들(프로그램들, 코드 모듈들, 명령들)은 본 개시내용의 하나 이상의 실시예들의 기능성을 제공할 수 있고, 저장 서브시스템(2606)에 저장될 수 있다. 이러한 애플리케이션 모듈들 또는 명령들은 하나 이상의 프로세서들(2602)에 의해 실행될 수 있다. 저장 서브시스템(2606)은 본 개시내용에 따라 사용되는 데이터를 저장하기 위한 저장소를 부가적으로 제공할 수 있다. 예컨대, 메인 메모리(2608) 및 캐시 메모리(2602)는 프로그램 및 데이터를 위한 휘발성 저장소를 제공할 수 있다. 영구 저장소(2610)는 프로그램 및 데이터를 위한 영구(비-휘발성) 저장소를 제공할 수 있으며, 플래시 메모리, 하나 이상의 솔리드 스테이트 드라이브들, 하나 이상의 자기 하드 디스크 드라이브들, 연관된 이동식 매체들을 갖는 하나 이상의 플로피 디스크 드라이브들, 연관된 이동식 매체들을 갖는 하나 이상의 광학 드라이브들(예컨대, CD-ROM 또는 DVD 또는 블루레이 드라이브) 및 다른 유사한 저장 매체들을 포함할 수 있다. 이러한 프로그램 및 데이터는 본 개시내용에 설명된 바와 같은 트랜잭션들 및 블록들과 연관된 데이터뿐만 아니라 본 개시내용에 설명된 바와 같은 하나 이상의 실시예들의 단계들을 수행하기 위한 프로그램들을 포함할 수 있다.
컴퓨팅 디바이스(2600)는 휴대용 컴퓨터 디바이스, 태블릿 컴퓨터, 워크스테이션, 또는 아래에서 설명되는 임의의 다른 디바이스를 포함하는 다양한 유형들로 이루어질 수 있다. 부가적으로, 컴퓨팅 디바이스(2600)는 하나 이상의 포트들(예컨대, USB, 헤드폰 잭, 라이트닝 커넥터 등)을 통해 컴퓨팅 디바이스(2600)에 연결될 수 있는 다른 디바이스를 포함할 수 있다. 컴퓨팅 디바이스(2600)에 연결될 수 있는 디바이스는 광섬유 커넥터들을 수용하도록 구성된 복수의 포트들을 포함할 수 있다. 따라서, 이 디바이스는 프로세싱을 위해 컴퓨팅 디바이스(2600)에 디바이스를 연결하는 포트를 통해 송신될 수 있는 전기 신호들로 광학 신호들을 변환하도록 구성될 수 있다. 컴퓨터들 및 네트워크들의 끊임없이 변하는 성질로 인해, 도 13에 도시된 컴퓨팅 디바이스(2600)의 설명은 디바이스의 바람직한 실시예를 예시하기 위한 특정 예로서만 의도된다. 도 13에 도시된 시스템보다 더 많거나 더 적은 구성요소들을 갖는 다수의 다른 구성들이 가능하다.
열거된 예시적 실시예들
이로써 본 개시내용은 청구된 양상들 및 실시예들을 더 잘 설명하고, 기술하고 이해하기 위한 예시적인 실시예로서 본원에서 제공되는, 위의 양상들과 관련되는 다음의 조항들에 기초하여 논의된다.
1. 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법으로서,
검증될 트랜잭션(T)을 식별하는 단계;
트랜잭션(T)과 연관된 인증서(C)를 획득하는 단계 ― 인증서는 주어진 블록에 대한 블록 식별자 및 블록체인 내 주어진 블록에 트랜잭션을 링크하는 포함 증명을 포함함 ― ;
블록체인에서 유효 블록들의 최장 체인을 결정하는 단계; 및
주어진 블록이 최장 체인에 포함됨을 검증하는 단계를 포함하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
2. 조항 1에 제시된 방법에 있어서,
인증서(C)는 클라이언트와 연관된 로컬 저장소로부터 획득되는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
3. 조항 1에 제시된 방법에 있어서,
인증서(C)는 검증자 엔티티와 연관된 저장소로부터 획득되는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
4. 조항 1에 제시된 방법에 있어서,
인증서(C)는 플랫폼과 연관된 저장소로부터 획득되는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
5. 조항 1 내지 조항 4 중 어느 한 조항에 제시된 방법에 있어서,
트랜잭션(T)과 연관된 블록 헤더들을 저장하도록 구성된 헤더 클라이언트를 사용하여 최장 블록체인을 소싱(sourcing)하는 단계를 포함하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
6. 조항 1 내지 조항 5 중 어느 한 조항에 제시된 방법에 있어서,
트랜잭션(T)을 주어진 블록과 연관된 머클 루트(R)에 연결하는 포함 증명으로부터 머클 루트(R')를 계산하는 단계를 더 포함하고,
R = R'에 응답하여, 방법은,
R'가 주어진 블록에 포함된다고 결정하는 단계; 및
주어진 블록이 최장 체인에 포함된다고 결정하는 단계를 포함하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
7. 조항 6에 제시된 방법에 있어서,
방법은,
R이 R'와 매칭되지 않는다는 결정에 기초하여, 오류 메시지를 생성하는 단계; 및/또는
R'가 주어진 블록에 포함되지 않는다는 결정에 기초하여, 오류 메시지를 생성하는 단계; 및/또는
주어진 블록이 최장 체인에 포함되지 않는다는 결정에 기초하여, 오류 메시지를 생성하는 단계를 더 포함하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
8. 조항 1 내지 조항 7 중 어느 한 조항에 제시된 방법에 있어서,
클라이언트와 연관된 데이터(D)를 획득하는 단계;
데이터(D)에 기초하여, 블록체인에 커밋된 데이터의 값(d)을 결정하는 단계; 및
커밋된 값(d)과 연관된 트랜잭션(T)을 추출하거나 식별하는 단계를 더 포함하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
9. 조항 8에 제시된 방법에 있어서,
커밋된 값(d)은 솔트 값(S)에 기초하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
10. 조항 9에 제시된 방법에 있어서,
커밋된 값(d)은 클라이언트 데이터(D) 및 솔트(S)의 해시인, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
11. 조항 8 내지 조항 10 중 어느 한 조항에 제시된 방법에 있어서,
조항 1 내지 조항 7 중 어느 한 조항의 방법을 사용하여 ES0과 연관된 제1 트랜잭션(T0)의 포함을 검증함으로써 이벤트 스트림(ESn=0toN)의 생성을 검증하는 단계 ― 여기서 n은 0 내지 N의 정수이고, n은 이벤트 스트림의 길이를 표현하며, 여기서 0은 최초 또는 생성 이벤트이고 N은 최종 또는 종결 이벤트임 ― ;
제1 트랜잭션(T0)에 대한 제1 입력이 더스트가 아니라고 결정하는 단계;
T0의 제1 출력이 더스트라고 결정하는 단계;
이벤트 스트림(ESn=0toN)에 대해 클라이언트와 연관된 이벤트에 대한 각각의 n번째 데이터 엔트리(Dn)에 대해, 조항 8 내지 조항 10 중 어느 한 조항의 방법에 청구된 바와 같은 방법을 수행하는 단계; 및
n > 0일 때, 이벤트 스트림(ESn) 내 n번째 트랜잭션(Tn)에 대응하는 입력이 이전 트랜잭션(Tn-1)과 연관된 출력을 지출함을 검증하는 단계를 포함하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
12. 조항 11에 제시된 방법에 있어서,
제1 트랜잭션(T0)에 대한 제1 입력이 더스트인 경우, 오류 메시지를 생성하고, 그리고/또는
T0의 제1 출력이 더스트가 아닌 경우, 오류 메시지를 생성하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
13. 조항 11 또는 조항 12에 제시된 방법에 있어서,
조항 1 내지 조항 7 중 어느 한 조항의 방법을 사용하여 이벤트 스트림(ESN)과 연관된 최종 트랜잭션(TN)의 포함을 검증함으로써 ESN의 마무리를 검증하는 단계;
제1 트랜잭션(TN)에 대한 제1 입력이 더스트라고 결정하는 단계;
T0의 제1 출력이 더스트가 아니라고 결정하는 단계; 및
이벤트 스트림(ESN) 내 최종 N번째 트랜잭션(TN)에 대응하는 입력이 이전 트랜잭션(TN-1)과 연관된 출력을 지출함을 검증하는 단계를 더 포함하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
14. 조항 14에 제시된 방법에 있어서,
제1 트랜잭션(TN)에 대한 제1 입력이 더스트가 아닌 경우, 오류 메시지를 생성하고, 그리고/또는
TN의 제1 출력이 더스트인 경우, 오류 메시지를 생성하는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
15. 조항 1 내지 조항 14 중 어느 한 조항에 제시된 방법에 있어서,
클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
16. 조항 1 내지 조항 15 중 어느 한 조항에 제시된 방법에 있어서,
플랫폼과 연관된 하나 이상의 프로세서들에 의해 구현되는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
17. 조항 1 내지 조항 15 중 어느 한 조항에 제시된 방법에 있어서,
검증자 엔티티와 연관된 하나 이상의 프로세서들에 의해 구현되는, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법..
18. 조항 17에 제시된 방법에 있어서,
검증자 엔티티는 클라이언트 및/또는 플랫폼으로부터 독립적인, 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
19. 하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법으로서,
방법은 채널 프로세서에 의해 구현되고,
하나 이상의 클라이언트들 중 주어진 클라이언트로부터 요청을 수신하는 단계 ― 요청은 채널의 생성과 관련됨 ― ;
채널을 통해 주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 주어진 클라이언트에 제공하는 단계 ― 상기 하나 이상의 기능들은,
데이터의 송신을 위해 채널과 관련된 채널 기능들 또는 절차들; 및/또는
채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함함 ― ;
채널에 대한 하나 이상의 액세스 토큰들을 발행하는 단계 ― 상기 하나 이상의 액세스 토큰들은 채널을 통해 다른 엔티티와의 보안 통신을 위해 구성됨 ― ; 및
주어진 클라이언트에 대해
채널과 연관된 하나 이상의 알림들을 저장 및/또는 제공하는 단계를 포함하는, 하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
20. 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법으로서,
방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되고,
주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 채널 서비스로부터 획득하는 단계 ― 상기 하나 이상의 기능들은,
데이터의 송신을 위해 채널과 관련된 채널 기능들 또는 절차들; 및/또는
채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함함 ― ;
하나 이상의 액세스 토큰들을 채널 서비스로부터 획득하는 단계 ― 상기 액세스 토큰들은 다른 엔티티와의 보안 통신을 가능하게 함 ― ;
클라이언트와 연관된 주어진 트랜잭션에 대한 트랜잭션 식별자(TxID)를 획득하거나 식별하는 것에 응답하여;
채널 프로세서로부터 수신된 하나 이상의 채널 기능들을 사용하여, 다른 엔티티와의 통신을 위한 주어진 채널을 생성하는 단계;
주어진 채널과 연관된 하나 이상의 액세스 토큰들을 다른 엔티티에 전송하는 단계;
주어진 채널과 연관된 알림을 수신하는 단계를 포함하고,
알림은 주어진 트랜잭션이 블록체인에 포함됨을 검증하기 위해 주어진 데이터와 관련되는, 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
위에서 언급된 양상들 및 실시예들은 본 개시를 제한하기보다는 예시하고, 당업자는 첨부된 청구항들에 의해 정의된 바와 같은 본 개시내용의 범위로부터 벗어남이 없이 다수의 대안적인 실시예들을 설계할 수 있을 것이란 점이 주의되어야 한다. 청구항들에서, 괄호 안의 배치된 임의의 참조 부호들은 청구항들을 제한하는 것으로 해석되어서는 안 된다. "포함하는(comprising)" 및 "포함하다(comprises)" 등의 단어는 전체로서 명세서 또는 임의의 청구항에 나열된 것들 이외의 요소들 또는 단계들의 존재를 배제하지 않는다. 본 명세서에서, "포함하다(comprises)"는 "포함하거나 구성된다(includes or consists of)"를 의미하고 "포함하는(comprising)"은 "포함하거나 구성되는(including or consisting of)"을 의미한다. 요소의 단수 참조는 그러한 요소들의 복수 참조를 배제하지 않으며 그 반대의 경우도 마찬가지이다. 본 개시내용은 여러 별개의 요소들을 포함하는 하드웨어에 의해 그리고 적합하게 프로그래밍된 컴퓨터에 의해 구현될 수 있다. 여러 수단들을 열거하는 디바이스 청구항에서, 이들 수단들 중 여러 개는 하나의 그리고 동일한 하드웨어 아이템에 의해 구체화될 수 있다. 소정의 측정들이 서로 상이한 종속 청구항들에서 인용된다는 단순한 사실만으로 이 측정들의 결합이 유리하게 사용될 수 없다는 것을 나타내는 것은 아니다.

Claims (20)

  1. 트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법으로서,
    검증될 트랜잭션(T)을 식별하는 단계;
    상기 트랜잭션(T)과 연관된 인증서(C)를 획득하는 단계 ― 상기 인증서는 주어진 블록에 대한 블록 식별자 및 상기 블록체인 내 상기 주어진 블록에 상기 트랜잭션을 링크하는 포함 증명을 포함함 ― ;
    상기 블록체인에서 유효 블록들의 최장 체인을 결정하는 단계; 및
    상기 주어진 블록이 상기 최장 체인에 포함됨을 검증하는 단계를 포함하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  2. 제1 항에 있어서,
    상기 인증서(C)는 클라이언트와 연관된 로컬 저장소로부터 획득되는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  3. 제1 항에 있어서,
    상기 인증서(C)는 검증자 엔티티와 연관된 저장소로부터 획득되는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  4. 제1 항에 있어서,
    상기 인증서(C)는 플랫폼과 연관된 저장소로부터 획득되는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  5. 제1 항 내지 제4 항 중 어느 한 항에 있어서,
    상기 트랜잭션(T)과 연관된 블록 헤더들을 저장하도록 구성된 헤더 클라이언트를 사용하여 상기 최장 블록체인을 소싱(sourcing)하는 단계를 포함하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  6. 제1 항 내지 제5 항 중 어느 한 항에 있어서,
    상기 트랜잭션(T)을 상기 주어진 블록과 연관된 머클 루트(R)에 연결하는 포함 증명으로부터 머클 루트(R')를 계산하는 단계를 더 포함하고,
    R = R'에 응답하여, 상기 방법은,
    R'가 상기 주어진 블록에 포함된다고 결정하는 단계; 및
    상기 주어진 블록이 상기 최장 체인에 포함된다고 결정하는 단계를 포함하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  7. 제6 항에 있어서,
    상기 방법은,
    R이 R'와 매칭되지 않는다는 결정에 기초하여, 오류 메시지를 생성하는 단계; 및/또는
    R'가 상기 주어진 블록에 포함되지 않는다는 결정에 기초하여, 오류 메시지를 생성하는 단계; 및/또는
    상기 주어진 블록이 상기 최장 체인에 포함되지 않는다는 결정에 기초하여, 오류 메시지를 생성하는 단계를 더 포함하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  8. 제1 항 내지 제7 항 중 어느 한 항에 있어서,
    클라이언트와 연관된 데이터(D)를 획득하는 단계;
    데이터(D)에 기초하여, 상기 블록체인에 커밋된 데이터의 값(d)을 결정하는 단계; 및
    상기 커밋된 값(d)과 연관된 트랜잭션(T)을 추출하거나 식별하는 단계를 더 포함하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  9. 제8 항에 있어서,
    상기 커밋된 값(d)은 솔트 값(salt value)(S)에 기초하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  10. 제9 항에 있어서,
    상기 커밋된 값(d)은 상기 클라이언트 데이터(D) 및 솔트(S)의 해시인,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  11. 제8 항 내지 제10 항 중 어느 한 항에 있어서,
    제1 항 내지 제7 항 중 어느 한 항의 방법을 사용하여 ES0과 연관된 제1 트랜잭션(T0)의 포함을 검증함으로써 이벤트 스트림(ESn=0toN)의 생성을 검증하는 단계 ― 여기서 n은 0 내지 N의 정수이고, n은 상기 이벤트 스트림의 길이를 표현하며, 여기서 0은 최초 또는 생성 이벤트이고 N은 최종 또는 종결 이벤트임 ― ;
    상기 제1 트랜잭션(T0)에 대한 제1 입력이 더스트가 아니라고 결정하는 단계;
    T0의 제1 출력이 더스트라고 결정하는 단계;
    상기 이벤트 스트림(ESn=0toN)에 대해 클라이언트와 연관된 이벤트에 대한 각각의 n번째 데이터 엔트리(Dn)에 대해, 제8 항 내지 제10 항 중 어느 한 항에 청구된 바와 같은 방법을 수행하는 단계; 및
    n > 0일 때, 상기 이벤트 스트림(ESn) 내 n번째 트랜잭션(Tn)에 대응하는 입력이 이전 트랜잭션(Tn-1)과 연관된 출력을 지출함을 검증하는 단계를 포함하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  12. 제11 항에 있어서,
    상기 제1 트랜잭션(T0)에 대한 제1 입력이 더스트인 경우, 오류 메시지를 생성하고, 그리고/또는
    T0의 제1 출력이 더스트가 아닌 경우, 오류 메시지를 생성하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  13. 제11 항 또는 제12 항에 있어서,
    제1 항 내지 제7 항 중 어느 한 항의 방법을 사용하여 이벤트 스트림(ESN)과 연관된 최종 트랜잭션(TN)의 포함을 검증함으로써 ESN의 마무리(closure)를 검증하는 단계;
    상기 제1 트랜잭션(TN)에 대한 제1 입력이 더스트라고 결정하는 단계;
    상기 T0의 제1 출력이 더스트가 아니라고 결정하는 단계; 및
    상기 이벤트 스트림(ESN) 내 최종 N번째 트랜잭션(TN)에 대응하는 입력이 이전 트랜잭션(TN-1)과 연관된 출력을 지출함을 검증하는 단계를 더 포함하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  14. 제14 항에 있어서,
    상기 제1 트랜잭션(TN)에 대한 제1 입력이 더스트가 아닌 경우, 오류 메시지를 생성하고, 그리고/또는
    상기 TN의 제1 출력이 더스트인 경우, 오류 메시지를 생성하는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  15. 제1 항 내지 제14 항 중 어느 한 항에 있어서,
    상기 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  16. 제1 항 내지 제15 항 중 어느 한 항에 있어서,
    플랫폼과 연관된 하나 이상의 프로세서들에 의해 구현되는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  17. 제1 항 내지 제15 항 중 어느 한 항에 있어서,
    검증자 엔티티와 연관된 하나 이상의 프로세서들에 의해 구현되는,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  18. 제17 항에 있어서,
    상기 검증자 엔티티는 상기 클라이언트 및/또는 상기 플랫폼으로부터 독립적인,
    트랜잭션이 블록체인에 포함됨을 검증하기 위한 방법.
  19. 하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법으로서,
    상기 방법은 채널 프로세서에 의해 구현되고
    상기 하나 이상의 클라이언트들 중 주어진 클라이언트로부터 요청을 수신하는 단계 ― 상기 요청은 채널의 생성과 관련됨 ― ;
    상기 채널을 통해 상기 주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 상기 주어진 클라이언트에 제공하는 단계 ― 상기 하나 이상의 기능들은,
    데이터의 송신을 위해 상기 채널과 관련된 채널 기능들 또는 절차들; 및/또는
    상기 채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함함 ― ;
    상기 채널에 대한 하나 이상의 액세스 토큰들을 발행하는 단계 ― 상기 하나 이상의 액세스 토큰들은 상기 채널을 통해 다른 엔티티와의 보안 통신을 위해 구성됨 ― ; 및
    상기 주어진 클라이언트에 대해 상기 채널과 연관된 하나 이상의 알림들을 저장 및/또는 제공하는 단계를 포함하는,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  20. 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법으로서,
    상기 방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되고,
    주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 채널 서비스로부터 획득하는 단계 ― 상기 하나 이상의 기능들은,
    데이터의 송신을 위해 채널과 관련된 채널 기능들 또는 절차들; 및/또는
    채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함함 ― ;
    하나 이상의 액세스 토큰들을 상기 채널 서비스로부터 획득하는 단계 ― 상기 액세스 토큰들은 다른 엔티티와의 보안 통신을 가능하게 함 ― ;
    상기 클라이언트와 연관된 주어진 트랜잭션에 대한 트랜잭션 식별자(TxID)를 획득하거나 식별하는 것에 응답하여;
    상기 채널 프로세서로부터 수신된 하나 이상의 채널 기능들을 사용하여, 상기 다른 엔티티와의 통신을 위한 주어진 채널을 생성하는 단계;
    상기 주어진 채널과 연관된 하나 이상의 액세스 토큰들을 상기 다른 엔티티에 전송하는 단계;
    상기 주어진 채널과 연관된 알림을 수신하는 단계를 포함하고,
    상기 알림은 상기 주어진 트랜잭션이 상기 블록체인에 포함됨을 검증하기 위해 주어진 데이터와 관련되는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
KR1020227031821A 2020-02-19 2021-02-17 플랫폼 서비스 검증 KR20220143879A (ko)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
GBGB2002285.1A GB202002285D0 (en) 2020-02-19 2020-02-19 Computer-implemented system and method
GB2002285.1 2020-02-19
GB2013929.1 2020-09-04
GBGB2013929.1A GB202013929D0 (en) 2020-09-04 2020-09-04 Computer-implemented system and method
GBGB2020279.2A GB202020279D0 (en) 2020-12-21 2020-12-21 Computer-implemented system and method
GB2020279.2 2020-12-21
GB2102217.3 2021-02-17
PCT/IB2021/051333 WO2021165848A1 (en) 2020-02-19 2021-02-17 Platform services verification
GBGB2102217.3A GB202102217D0 (en) 2021-02-17 2021-02-17 Computer-implemented system and method

Publications (1)

Publication Number Publication Date
KR20220143879A true KR20220143879A (ko) 2022-10-25

Family

ID=74844939

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227031821A KR20220143879A (ko) 2020-02-19 2021-02-17 플랫폼 서비스 검증

Country Status (5)

Country Link
US (1) US20230119035A1 (ko)
JP (1) JP2023513846A (ko)
KR (1) KR20220143879A (ko)
TW (1) TW202135504A (ko)
WO (1) WO2021165848A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11893553B1 (en) * 2021-11-17 2024-02-06 Wells Fargo Bank, N.A. Systems and methods of exchanging digital assets using a public key cryptography (PKC) framework

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10333705B2 (en) * 2016-04-30 2019-06-25 Civic Technologies, Inc. Methods and apparatus for providing attestation of information using a centralized or distributed ledger
CN109923521A (zh) * 2016-10-28 2019-06-21 区块链控股有限公司 用于经由区块链实施确定性有限自动机（DFAs）的系统和方法
WO2019032891A1 (en) * 2017-08-09 2019-02-14 Visa International Service Association SYSTEM AND METHOD FOR VERIFYING INTERACTIONS

Also Published As

Publication number Publication date
JP2023513846A (ja) 2023-04-03
TW202135504A (zh) 2021-09-16
US20230119035A1 (en) 2023-04-20
WO2021165848A1 (en) 2021-08-26

Similar Documents

Publication Publication Date Title
JP7461417B2 (ja) セキュアなオフチェーンのブロックチェーントランザクション
US11164165B1 (en) Multi-asset blockchain network platform
US11887072B2 (en) Digital currency minting in a system of network nodes implementing a distributed ledger
CN116982033A (zh) 先进的不可替代令牌区块链架构
US20220311611A1 (en) Reputation profile propagation on blockchain networks
US20230095965A1 (en) Compute services for a platform of services associated with a blockchain
KR102627868B1 (ko) 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템
US20240086914A1 (en) Platform for a plurality of services associated with a blockchain
CN116569517A (zh) 用于发布操作系统的基于区块链的系统和方法
US20230119035A1 (en) Platform services verification
US20220399988A1 (en) Linking blockchain operations
US20230093411A1 (en) Synchronising event streams
Antal et al. Distributed Ledger Technology Review and Decentralized Applications Development Guidelines. Future Internet 2021, 13, 62
EP4107689A1 (en) Platform services verification
US20220067028A1 (en) Trustless operations for blockchain networks
US20220058597A1 (en) Multi-asset blockchain network platform
Bibodi PodWeb: a decentralized application powered by Ethereum network
CN117321598A (zh) 计算机实现的方法和系统