KR20220076486A - 블록체인 트랜잭션들을 위한 콜-백 메커니즘들 - Google Patents

블록체인 트랜잭션들을 위한 콜-백 메커니즘들 Download PDF

Info

Publication number
KR20220076486A
KR20220076486A KR1020227014309A KR20227014309A KR20220076486A KR 20220076486 A KR20220076486 A KR 20220076486A KR 1020227014309 A KR1020227014309 A KR 1020227014309A KR 20227014309 A KR20227014309 A KR 20227014309A KR 20220076486 A KR20220076486 A KR 20220076486A
Authority
KR
South Korea
Prior art keywords
channel
client
transaction
blockchain
miner
Prior art date
Application number
KR1020227014309A
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 GB201914043A external-priority patent/GB201914043D0/en
Priority claimed from GBGB2007597.4A external-priority patent/GB202007597D0/en
Priority claimed from GBGB2010339.6A external-priority patent/GB202010339D0/en
Application filed by 엔체인 홀딩스 리미티드 filed Critical 엔체인 홀딩스 리미티드
Priority claimed from GBGB2015358.1A external-priority patent/GB202015358D0/en
Publication of KR20220076486A publication Critical patent/KR20220076486A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • 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
    • 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)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

일 양상에서, 본 개시는 클라이언트와 연관된 블록체인 트랜잭션들을 프로세싱하기 위한 방법들, 디바이스들 및 시스템들을 제안한다. 지불 서비스는 하나 이상의 클라이언트들이 액세스하는 게이트웨이 또는 API 엔드포인트로서 구현된다. 주어진 클라이언트로부터 수신된 트랜잭션을 제출하라는 요청은 콜-백 식별자와 연관된다. 콜-백 식별자는 주어진 클라이언트와 다른 엔티티 이를테면, 채굴자 또는 다른 상대방 간의 직접 통신을 가능하게 하도록 이루어진다. 지불 프로세서는 트랜잭션을 채굴자에게 제출하며, 이 제출은 콜-백 식별자와 연관된다. 그 후, 대응하는 블록체인 트랜잭션이 채굴자에 의해 생성되면, 그것과 관련된 콜-백 알림이 콜-백 식별자를 사용하여 채굴자로부터 직접 클라이언트에 대해 제공될 수 있다.

Description

블록체인 트랜잭션들을 위한 콜-백 메커니즘들
본 개시는 일반적으로 하나 이상의 클라이언트들을 위한 지불 서비스 또는 지불 인터페이스를 구현하기 위한 방법들 및 시스템들에 관한 것이다. 특히, 본 개시는 하나 이상의 클라이언트들을 위해 또는 이들을 대신하여 블록체인 또는 분산 원장과 연관된 안전하고 신뢰할 수 있는 지불 트랜잭션을 가능하게 하는 것에 관한 것이며(그러나 이에 제한되지 않음), 이 트랜잭션들은 고객 또는 지급인 엔티티와 연관된 디지털 자산 지불과 관련된다.
이 문서에서 우리는 모든 형태의 전자, 컴퓨터 기반, 분산 원장을 포함하기 위하여 '블록체인'이라는 용어를 사용한다. 이는 합의 기반(consensus-based) 블록체인 및 트랜잭션 체인 기술들, 허가 및 비허가 원장들, 공유 원장들, 공용 및 사설 블록체인들 및 이들의 변동들을 포함한다. 다른 블록체인 구현들이 제안되고 개발되었지만, 블록체인 기술의 가장 널리 알려진 응용은 비트코인 원장이다. 비트코인은 편의 및 예시의 목적으로 본원에서 지칭될 수 있지만, 본 개시는 비트코인 블록체인과 함께 사용하는 것으로 제한되지 않으며, 임의의 종류의 디지털 자산 또는 디지털 자산의 표현과 연관된 대안적인 블록체인 구현들 및 프로토콜들이 본 개시의 범위 내에 속한다는 것이 주의되어야 한다. "클라이언트", "엔티티", "노드", "사용자", "전송자", "수령인", "지급인", "수취인"이라는 용어들은 본원에서 컴퓨팅 또는 프로세서-기반 자원을 지칭할 수 있다. 본원에서 "비트코인"이란 용어는 비트코인 프로토콜로부터 도출되거나 이에 기초하는 임의의 버전 또는 변동을 포함하는 것으로 사용된다. 용어 "디지털 자산"은 암호화폐, 재산의 적어도 일부를 표현하는 토큰들, 스마트 계약, 라이센스, 즉 소프트웨어 라이센스, 또는 미디어 콘텐츠에 대한 DRM 계약들 등과 같은 임의의 이전 가능한 자산을 지칭할 수 있다. "디지털 자산"이라는 용어는 이 문서 전반에 걸쳐 가치와 연관될 수 있는 상품을 표현하는 데 사용되며, 이는 하나의 엔티티에서 다른 엔티티로의 트랜잭션에서 지불로서 이전되거나 제공될 수 있다는 것이 이해될 것이다.
블록체인은 결국, 트랜잭션들로 구성되는 블록들로 구성된 컴퓨터-기반 탈중앙화된 분산 시스템으로서 구현되는 피어-투-피어 전자 원장이다. 각각의 트랜잭션은 블록체인 시스템의 참여자들 사이의 디지털 자산의 제어의 이전을 인코딩하는 데이터 구조이며, 적어도 하나의 입력 및 적어도 하나의 출력을 포함한다. 각각의 블록은 이전 블록의 해시를 포함하여서, 블록들은 그의 시작 이래로 블록체인에 기록되는 모든 트랜잭션들에 대한 영구적이고 변경 불가능한 레코드를 생성하도록 함께 체이닝된다(chained). 트랜잭션들은 그 입력들 및 출력들 내에 매립된 스크립트들로서 알려진 작은 프로그램들을 포함하며, 이는 트랜잭션들의 출력들이 액세스될 수 있는 방법 및 대상을 특정한다. 비트코인 플랫폼에서, 이러한 스크립트들은 스택-기반 스크립트 언어를 사용하여 작성된다.
트랜잭션이 블록체인에 기록되기 위해서는 "유효성 검증(validated)"되어야 한다. 네트워크 노드들(채굴자들)은 각각의 트랜잭션이 유효하다는 것을 보장하기 위한 작업을 수행하며, 유효하지 않은 트랜잭션들은 네트워크로부터 거부된다. 노드들 상에 설치된 소프트웨어 클라이언트들은 그의 잠금 및 잠금해제 스크립트들을 실행함으로써 소비되지 않은 트랜잭션(UTXO)에 대하여 이 유효성 검증 작업을 수행한다. 잠금 및 잠금해제 스크립트들의 실행이 참(TRUE)으로 평가되는 경우, 트랜잭션은 유효하고 트랜잭션은 그 후 블록체인에 기록된다. 따라서, 트랜잭션이 블록체인에 기록되기 위해서는 i) 트랜잭션을 수신하는 제1 노드에 의해 유효성 검증되어야 하며 ― 트랜잭션이 유효성 검증되는 경우, 노드는 트랜잭션을 네트워크의 다른 노드들에 중계하고, ii) 채굴자에 의해 구축된 새로운 블록에 추가되며, iii) 채굴, 즉 과거 트랜잭션들의 공개 원장에 추가되어야 한다.
일단 UTXO로서 블록체인에 저장되면, 사용자는 연관된 자원의 제어를 다른 트랜잭션의 입력과 연관된 다른 어드레스로 이전할 수 있다. 이러한 이전은 일반적으로 디지털 지갑을 사용하여 행해지지만, 반드시 그럴 필요는 없다. 이 디지털 지갑은 디바이스, 물리적 매체, 프로그램, 데스크톱, 랩톱 또는 이동 단말과 같은 컴퓨팅 디바이스 상의 애플리케이션(앱) 또는 인터넷과 같은 네트워크 워크(network work) 상의 도메인과 연관된 원격 호스팅 서비스일 수 있다. 디지털 지갑은 공개 및 개인 키들을 저장하고 사용자와 연관된 자원들, 토큰들 및 자산들 등의 소유권을 추적하고, 디지털 자산들을 수신하거나 소비하고, 암호화폐들, 라이센스들, 재산 또는 다른 유형들의 자원과 같은 디지털 자산들과 관련될 수 있는 토큰들을 이전하는 데 사용할 수 있다.
암호화폐 구현의 사용을 위한 블록체인 기술이 가장 널리 알려져 있지만, 디지털 기업가들은 새로운 시스템을 구현하기 위해 블록체인 상에 저장될 수 있는 데이터 및 비트코인이 기초하고 있는 암호화 보안 시스템 둘 모두를 사용하는 방법을 모색하고 있다. 암호화폐 영역으로 제한되지 않는 자동화된 작업들 및 프로세스들을 위해 블록체인이 사용될 수 있는 경우가 매우 유리할 것이다. 이러한 솔루션은 블록체인의 이점들(예컨대, 이벤트들의 영구적인 위조-방지성 레코드들, 분산 프로세싱 등)을 활용하는 동시에 그의 애플리케이션들에서 더 다재다능해질 수 있을 것이다.
현재 연구의 한 영역은 "스마트 계약들"의 구현을 위한 블록체인의 사용이다. 이들은 기계-판독 가능 계약 또는 동의(agreement)의 조건들의 실행을 자동화하도록 설계된 컴퓨터 프로그램들이다. 자연어로 작성되는 기존의 계약과 달리, 스마트 계약은 결과들을 생성하기 위해 입력들을 프로세싱할 수 있는 규칙들을 포함하는 기계 실행 가능 프로그램이며, 이는 그 후 그러한 결과들에 의존하여 액션들이 수행되게 할 수 있다. 블록체인-관련 다른 관심 영역은 '토큰들'(또는 '컬러드 코인(coloured coin)들')을 사용하여 블록체인을 통해 실세계 엔티티들을 표현 및 이전하는 것이다. 잠재적으로 민감성 또는 비밀 아이템은 어떠한 구별 가능한 의미 또는 가치도 갖지 않는 토큰으로 표현될 수 있다. 따라서 토큰은 실세계 아이템이 블록체인으로부터 참조될 수 있게 하는 식별자로서 역할을 한다.
위에서 언급된 예들 또는 시나리오들은 일부 자산, 즉 디지털 자산의 이전 또는 사용자들 또는 엔티티들 간의 디지털 자산의 제어와 관련된다. 따라서, 2개의 엔티티들 간의 자금(fund)들의 교환을 위해 ― 특히, 더 양호한 사용자 경험, 더 저렴한 판매자 또는 수취인 비용들, 더 안전한 레벨의 보안을 가지면서 실세계의 자산을 존중할 수 있는 판매자와 고객 간의 디지털 자산 지불을 위해 기존 지불 또는 전자 상거래 시스템들과 유사한 안전하고 견고한 시스템을 구현하려는 요구가 있다. 보다 구체적으로, 분산 원장(블록체인) 기술 및 레코드의 증가된 보안, 투명성 및 신뢰성의 이점들을 활용하여 임의의 판매자 또는 복수의 판매자들이, 각자의 고객들과의 디지털 자산 지불들이 순시적으로 그리고 안전하게 채굴되거나 블록체인 내로 기록되도록 보장하고 그리하여 그러한 지불들의 지속적이고 위조-방지성이며 감사 가능한 레코드를 제공하는 것을 가능하게 하는 공통 플랫폼 또는 인터페이스를 제공하려는 요구가 있다.
이러한 개선된 솔루션이 이제 창안되었다. 본 개시는 암호화폐와 같은 디지털 자산들의 수령인들인 하나 이상의 클라이언트들, 즉 판매자들 또는 수취인 엔티티들에 대한 트랜잭션들이 이러한 클라이언트들에 대한 API(application programming interface)를 제공하는 방법들, 기술들 및 디바이스들에 의해 블록체인 내로 순시적으로 기록될 수 있게 하는 기술들을 제안함으로써 이러한 기술적 문제들을 해결한다. 이러한 기술들에서, 채굴자들은 동적으로 또는 즉시, 트랜잭션들을 채굴하거나 트랜잭션들을 블록체인 내로 기록할 수 있을 것인데, 즉 안전하고 신뢰할 수 있는 방식으로 클라이언트에 대한 순시적인 트랜잭션들 또는 제로-컨펌 트랜잭션들(0-conf)을 허용하는 서비스를 제공할 수 있을 것이다.
일 양상에서, 본 개시는 클라이언트와 연관된 블록체인 트랜잭션들을 프로세싱하기 위한 지불 서비스와 연관된 방법들, 디바이스들 및 시스템들을 제안한다. 지불 서비스는 하나 이상의 클라이언트들이 액세스하는 게이트웨이 또는 API 엔드포인트로서 구현된다. 본 방법에서, 주어진 클라이언트로부터 수신된 트랜잭션 제출하라는 요청은 콜-백 식별자(call-back identifier)와 연관된다. 콜-백 식별자는 주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하도록 이루어진다. 지불 프로세서는 콜-백 식별자와 함께 트랜잭션을 채굴자에게 제출한다. 그 후, 대응하는 블록체인 트랜잭션이 채굴자에 의해 생성되면, 그것에 관한 콜-백 알림이 채굴자로부터 직접 클라이언트에 대해 제공될 수 있다.
다른 양상에서, 클라이언트로부터의 요청은 채널과 연관되며, 상기 채널은 채널 서비스에 의해 제공되고 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들과 연관된다. 이 경우에, 클라이언트에는 또한 채널에 대한 하나 이상의 액세스 토큰들 및 API(application programming interface)들이 제공된다. 채널에 대한 액세스는 그 후, 클라이언트에 대한 트랜잭션을 채굴하는 엔티티로서 식별된 채굴자와 같이, 이러한 액세스 토큰들 및/또는 API들에 기초하는 다른 엔티티에 클라이언트에 의해 제공될 수 있다. 이는 대응하는 블록체인 트랜잭션과 관련된 데이터가 다른 엔티티에 의해 직접 채널 내로 기록되는 것을 가능하게 한다. 그 후, 대응하는 트랜잭션 특유의 콜-백 알림이 채널 서비스를 통해 제공될 수 있다. 이는, 필요할 때마다 또는 그렇게 하는 것이 가능할 때마다 이를테면, 클라이언트가 온라인이고 네트워크를 통해 채널 서비스와 통신할 때, 주어진 트랜잭션과 연관된 데이터가 채널로부터 직접 클라이언트에 의해 액세스되는 것을 가능하게 한다. 일부 경우들에서, 채널 서비스는 채널 프로세서에 의해 구현될 수 있다. 채널 프로세서는 위에서 언급된 지불 프로세서와 동일한 엔티티일 수 있거나, 지불 프로세서와 별개의 엔티티일 수도있다.
본 명세서 전반에 걸쳐, 단어 "포함하다(comprise)", 또는 "포함하다(includes)", "포함하다(comprises)" 또는 "포함하는(comprising)"과 같은 변동들은 언급된 요소, 정수 또는 단계, 또는 요소들, 정수들, 단계들의 그룹을 포함하지만, 임의의 다른 요소, 정수, 또는 단계, 또는 요소들, 정수들 또는 단계들의 그룹의 배제를 의미하지 않는 것으로 이해될 것이다.
본 개시의 양상들 및 실시예들은 이제, 단지 예로서만 그리고 첨부 도면들을 참조하여 설명될 것이다.
도 1은 하나 이상의 클라이언트들에 대한 블록체인과 연관된 디지털 자산 트랜잭션들을 가능하게 하기 위한 지불 서비스 또는 지불 인터페이스를 구현하기 위한 방법을 도시하는 흐름도이며, 이 방법은 제1 양상에 따라 지불 프로세서에 의해 구현된다.
도 2는 블록체인 트랜잭션의 프로세싱을 요청하기 위한 방법을 도시하는 흐름도이며, 이 블록체인 트랜잭션은 클라이언트와 연관된 디지털 자산 지불과 연관되고, 여기서 이 방법은 제2 양상에 따라 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현된다.
도 3은 클라이언트에 대한 디지털 자산 지불과 연관된 블록체인 트랜잭션을 프로세싱하는 방법을 도시하는 흐름도이며, 여기서 이 방법은 제3 양상에 따라 채굴자와 연관된 하나 이상의 프로세서들에 의해 구현된다.
도 4는 클라이언트에 대한 블록체인 트랜잭션을 가능하게 하기 위한 지불 서비스 또는 지불 인터페이스를 입증하기 위한 시스템을 예시하는 개략도이다.
도 5는 복수의 채굴자들과 연관된 수수료 견적들을 획득하기 위한 제1 요청과 연관된 데이터의 흐름을 도시하는 개략도이다.
도 6은 선택된 수수료 견적에 기초하여 트랜잭션을 제출하기 위한 제2 요청과 연관된 데이터의 흐름을 도시하는 개략도이다.
도 7은 블록체인 트랜잭션 식별자에 기초한 상태 질의와 연관된 데이터의 흐름을 도시하는 개략도이다.
도 8은 트랜잭션들을 위한 콜-백 메커니즘을 구현하는 방법을 도시하는 흐름도이며, 이 방법은 제4 양상에 따라 지불 프로세서와 연관된 하나 이상의 프로세서들에 의해 구현된다.
도 9는 하나 이상의 클라이언트들에 대한 채널 서비스를 구현하는 방법을 도시하는 흐름도이며, 여기서 이 방법은 제4 양상에 따라 채널 프로세서와 연관된 하나 이상의 프로세서들에 의해 구현된다.
도 10은 지불 서비스에 액세스하는 방법을 도시하는 흐름도이며, 여기서 이 방법은 제4 양상에 따라 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현된다.
도 11은 주어진 블록체인 트랜잭션과 연관된 메시지들을 프로세싱하는 방법을 도시하는 흐름도이며, 이 방법은 제4 양상에 따라 채굴자와 연관된 하나 이상의 프로세서들에 의해 구현된다.
도 12는 본 개시의 다양한 양상들 및 실시예들이 구현될 수 있는 컴퓨팅 환경을 예시하는 개략도이다.
첨부된 청구항들이 아래에 상세히 설명된 본 개시의 제4 양상과 관련되지만, 제1, 제2 및 제3 양상들에 대한 세부사항들의 상세한 논의는 독자에게 본 개시의 청구된 양상들 및 관련된 실시예들의 최대 및 완전한 이해를 제공하기 위해 본원에서 제공된다.
제1 양상에 따르면, 본 개시는 블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 구현하는 컴퓨터 구현 방법을 제공하며, 이 방법은 지불 서비스와 연관된 지불 프로세서에 의해 구현된다. 일부 실시예들에서, 클라이언트는 암호화폐 지불들을 수락하고 그리고/또는 프로세싱하기 위한 디지털 지갑과 연관될 수 있고 그러한 지갑에 대한 공개 키 또는 공개 어드레스와 연관될 수 있는 컴퓨팅 자원 또는 노드 또는 엔티티일 수 있다. 일부 실시예들에서, 클라이언트는 실세계의 상품들 또는 서비스들을 제공하고 이러한 상품들 또는 서비스들에 대한 디지털 자산 지불들을 수신하는(그러나 이러한 것으로 제한되지 않음) 판매자 엔티티 또는 단말, 이를테면, 판매 시점 디바이스(point of sale device)를 표현할 수 있다. 일부 실시예들에서, 지불 프로세서는 연관된 또는 제3자 서비스로서 하나 이상의 클라이언트들에 대한 지불 인터페이스를 제공하도록 구성된다. 일부 예들에서, 지불 프로세서는, 그것이 채굴자들뿐만 아니라 클라이언트들에 대한 하나 이상의 사용자 친화적인 인터페이스들을 통해 블록체인과 연관된 복수의 지불 서비스들 및 기능들을 제공하기 때문에 지불 수집기(payment aggregator)로서 지칭된다. 일부 실시예들에서, 지불 프로세서는 통신이 HTTPS, TCP/IP 등과 같이 웹-기반 서비스들에 대한 표준 인터넷 통신 프로토콜들을 사용하여 인터넷을 통해 발생할 수 있도록 하나 이상의 클라이언트들에 대한 웹-기반 상호작용을 제공하기 위한 API(application programming interface)로서 구현되는데, 즉, 웹 서비스들로서 구현된다. 이 API는 지불 프로세서와 연관된 하나 이상의 클라이언트들에게 알려지거나 이 클라이언트들이 이용 가능하게 되거나 또는 이 클라이언트들에 전송/제공된다. 일부 실시예들에서, 이 API는 지불 프로세서에 의해 제공되는 서비스 또는 기능들에 액세스하기 위한 등록 또는 가입 프로세스에서 클라이언트에 제공될 수 있다. 일부 예들에서, API는 웹-기반 서비스에 액세스하려는 클라이언트들 또는 다른 엔티티들에 대한 잘 알려진 API 설계 및 개발 도구 또는 인터페이스인 API 사용자 인터페이스들 이를테면, Swagger을 통해 클라이언트에 의한 사용을 위해 제공되거나 공개될 수 있다.
제1 양상의 방법은 트랜잭션의 채굴에 대해 복수의 채굴자들 중 각각의 채굴자로부터 수수료 견적을 획득하는 단계를 포함한다. 이 단계는 트랜잭션의 채굴과 연관된 채굴 수수료 견적들에 대한 클라이언트로부터의 제1 요청에 응답하여 발생한다. 일부 실시예들에서, 채굴자들은 위의 배경 섹션에서 또한 설명된 바와 같이, 잠금 및 잠금 해제 스크립트들, 블록체인에 트랜잭션들을 채굴하거나 기록하는 것의 유효성 검증을 맡은 하나 이상의 프로세서들에 의해 구현되는 노드들이다. 예컨대, BSV(Bitcoin Satoshi’s Vision)이 이전되거나 트레이딩되는 암호화폐 또는 디지털 자산인 경우, 채굴자들은 BSV 노드들로서 지칭될 수 있다. 제1 양상의 방법은 획득된 수수료 견적들을 클라이언트에게 제공하는 단계를 포함한다. 일부 실시예들에서, 수수료 견적들은 트랜잭션이 무엇에 관련되는지 또는 당사자들이 무엇과 연루되지에 상관없이 블록체인 내로 트랜잭션을 채굴하기 위해 채굴자에 의해 부과되거나 과금되는 현재 수수료와 관련된다. 다른 실시예들에서, 수수료 견적은 요청에서 식별될 수 있는 주어진 트랜잭션에 기초하도록 맞춤제작될 수 있다. 일부 실시예들에서, 지불 프로세서는 모든 수신된 수수료 견적들을 클라이언트에게 제공할 수 있거나 획득된 수수료 견적들 중에서 클라이언트에게 제공하기 위한 하나 이상의 권고 수수료 견적들을 제공할 수 있다.
유리하게는, 디지털 자산들 이를테면, BSV(Bitcoin SV)와 같은 암호 화폐의 수령인들인 하나 이상의 클라이언트들, 즉 상인 또는 수취인 엔티티들에 대한 API로서 제공되는 지불 서비스를 구현함으로써, 제1 양상의 방법은 지불 트랜잭션들이, 클라이언트가 지불 프로세서에 의해 제공되는 웹 서비스를 사용하거나 가입(sign up)하도록 허용함으로써 채굴자가 퍼즐풀기 증명을 해결한 후 가능한 빨리 채굴되거나 거의 순시적으로 채굴(블록체인 내로 기록)될 수 있게 한다. 현재 수수료 견적을 제공함으로써, 주어진 채굴자는 이론적으로 그 수수료에 대해 주어진 채굴자에 의해 채굴될 다음 블록에 트랜잭션을 추가하는 데 동의하거나 서약(commit)한다. 유리하게는, 이는 클라이언트, 즉 판매자 엔티티가 더 이상 채굴자들로부터의 임의의 확인들을 기다릴 필요가 없다는 것을 의미한다. 따라서, 유리하게는 개개의 채굴자 및 클라이언트와 연관된 0-conf 트랜잭션들이 구현될 수 있다. 지불 서비스 API를 사용하는 클라이언트의 아이덴티티(identity)는 유리하게는 익명으로 유지될 수 있는 반면, 클라이언트와 연관된 모든 트랜잭션들은 채굴에 대한 선정된 또는 선택된 수수료 견적을 충족시키거나 만족시키는, 복수의 채굴자들 중의 채굴자에 의해 여전히 신뢰할 수 있게 채굴될 수 있다. 따라서 개별 클라이언트 또는 판매자는 임의의 부가적인 프로세싱 또는 네트워킹 자원들을 구현할 필요 없이 그리고 제안된 지불 서비스 API를 사용함으로써, 개개의 클라이언트와 연관된 모든 지불들에 대한 수정 불가능하고 검증 가능한 레코드의 투명성, 신뢰성 및 프로비전(provision)의 이점들에 도움이 될 수 있다.
제1 양상의 일부 실시예들에서, 획득된 수수료 견적들 중 선택된 수수료 견적을 포함하거나 그와 관련되는 주어진 트랜잭션을 제출하라는 클라이언트로부터의 제2 요청에 응답하여, 방법은, 주어진 트랜잭션에 대한 블록체인 트랜잭션을 생성하기 위해 복수의 채굴자들 중 하나 이상의 채굴자들에게 요청을 전송하는 것을 포함한다.
일부 실시예들에서, 선택된 수수료 견적은 클라이언트로부터 수신되고 주어진 트랜잭션에 대해 선택되며, 이는 차례로 디지털 자산 지불이 요구되는 클라이언트로부터 구매된 상품들 또는 서비스들의 관점에서 클라이언트와 다른 노드 또는 엔티티 이를테면, 클라이언트에 대한 고객 간의 지불 요청 또는 지불 트랜잭션과 관련될 수 있다. 그 후, 방법은 선택된 수수료 견적을 만족시키는, 복수의 채굴자들 중 적어도 하나의 채굴자로부터의 블록체인 트랜잭션과 연관된 출력 스크립트 예컨대, UTXO를 수신하는 것을 포함한다. 예컨대, 일부 실시예들에서, 수수료 견적을 만족시키기 위해, 적어도 하나의 채굴자는 선택된 수수료 견적보다 높거나 낮고, 일부 경우들에서 클라이언트와 연관된 미리 결정된 기준들 또는 하나 이상의 규칙들에 의존하여 선택된 수수료 견적보다 높은 값을 가진 현재 수수료 견적과 연관되거나 이를 제공했어야 한다. 그 후 방법은 결과를 클라이언트에 전송하는 것을 포함하며, 이 결과는 주어진 트랜잭션, 즉 클라이언트와 고객 간의 지불과 관련된, 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 포함한다.
유리하게는, 본 개시의 API는 REST(Representational State Transfer) 엔드포인트로서 구현될 수 있고, 그리하여 클라이언트가 표준 인터넷 또는 웹-기반 프로토콜들 이를테면, HTTPS를 사용하여 통신할 수 있게 한다. 더욱이, 유리하게는 제1 양상의 지불 서비스는 디지털 자산 지불과 연관된 대응하는 트랜잭션이 생성되고 선택된 수수료 견적에 기초하여 블록체인 내로 순시적으로 기록될 수 있게 한다. 클라이언트에 의해 또는 클라이언트를 대신하는 지불 프로세서에 의해 선택되거나 선정된 선택된 수수료 견적에 기초하여 트랜잭션을 채굴하는 것은 유리하게는, 주어진 채굴자가 클라이언트로부터 선택된 수수료 견적을 만족시키거나 그와 매칭되는 현재 수수료 견적으로 트랜잭션을 채굴할 것이라는 보장을 이미 제공했다면, 복수의 채굴자들 중 적어도 하나의 채굴자가 거의 순시적으로 또는 가능한 한 빨리 블록체인 내로 트랜잭션을 기록 또는 채굴하는 것을 가능하게 한다. 따라서 지불 서비스 API는, 트랜잭션이 실제로 블록에 추가되었고 블록체인에서 채굴될 것이라는 채굴자로부터의 확인을 클라이언트가 기다릴 필요가 없이, 순시의 트랜잭션들 또는 제로-컨펌 트랜잭션들(0-conf)이 안전하고 신뢰할 수 있는 방식으로 클라이언트에 대해 블록체인에서 채굴될 수 있게 하는 이점을 갖는다. 이는 주어진 채굴자가 제1 요청에 대한 응답으로 트랜잭션의 채굴에 대한 현재 수수료 견적을 전송함으로써 주어진 채굴자가 채굴을 수행할 수 있음을 이미 표시했기 때문이다. 제1 양상의 방법은 제1 양상에 따른 채굴이 클라이언트에 의해 또는 클라이언트에 대해 선정된 선택된 수수료 견적에 기초하여 발생하기 때문에 순시의 트랜잭션들이 채굴되도록 허용하는 것과 연관된 이중 소비 위험들을 감소시킨다. 따라서 선택된 수수료 견적을 만족시키는 채굴자만이 트랜잭션을 채굴할 수 있고, 수수료 견적을 만족시키는 제1 채굴자에 의해 블록체인과 연관된 블록에 트랜잭션이 추가되면, 트랜잭션은 다른 채굴자들에 의해 채굴될 수 없다.
지불 프로세서에 의해 구현된 지불 서비스를 제공하는 제1 양상에 따른 방법의 일부 실시예들은 클라이언트에게 제안할 권고 수수료를 결정하는 것에 기초하여 획득된 트랜잭션 채굴 수수료 견적들을 제공하는 것을 포함하고, 여기서 결정된 수수료는 획득된 수수료 견적들의 평균값 또는 복수의 채굴자들로부터의 획득된 수수료 견적들의 최대 값일 수 있다. 유리하게는, 이중 소비들을 회피하기 위한 시도로, 지불 프로세서는 제1 요청에 대한 응답으로 복수의 채굴자로부터 획득된 가장 높은 수수료 값을 갖는 트랜잭션이 제출되도록 권고할 수 있다. 이러한 방식으로, 모든 채굴자들에게는 각자의 현재 견적 수수료로 그 트랜잭션들을 채굴할 동등한 기회가 제공될 수 있다. 그러나 권고(recommendation)가, 수신된 모든 수수료 견적들의 중앙값 또는 평균 이상의 수수료를 갖는 트랜잭션을 제출하는 것인 경우, 더 높은 견적들을 가진 채굴자들은 단순히 2차 메모리 풀과 같은 멤풀(mempool)에서 그 트랜잭션을 유지하고 이를 이용하여 트랜잭션들의 임의의 이중 소비들을 체크 및 거부할 수 있다. 선택한 수수료 견적이 권고 수수료 견적에 기초하는 경우 또는 권고가 클라이언트에 의해 행해진 선택의 부분인 경우 유사한 이점들이 적용된다.
유리하게는, 지불 프로세서는 선택된 수수료 견적인 것으로 클라이언트가 추후에 선정할 수 있는 수수료 견적을 권고하며, 이는 일부 실시예들에서, 클라이언트가 클라이언트에 대한 디지털 자산 지불과 연관된 트랜잭션을 제출하는데 지불할 의향이 있는 최대치이다. 이는 클라이언트가 계산적으로 복잡하지 않은 경우 또는 수수료 견적을 스스로 선택하는 것보다 지불 프로세서에 의해 권고가 제공되도록 클라이언트가 미리 결정한 경우에 유리하다. 따라서, 유리하게는 클라이언트는 수수료 견적을 선택하거나 수수료 견적을 임의로 선택하기 위해 새로운 또는 별개의 휴리스틱 또는 계산을 적용하기 보다는, 권고 수수료 견적에 기초하여 수수료 견적을 선택할 수 있다.
일부 실시예들에서, 권고 또는 권고 수수료 견적이 지불 서비스, 즉 지불 프로세서에 의해 제공되는 API로부터 제공될 때, 이 권고 수수료 견적이 제공될 수 있거나, 또는 권고 수수료 견적 ― 권고 수수료 견적은 식별자를 포함함 ― 을 포함하는 모든 획득된 수수료 견적이 제공될 수 있다. 유리하게는, 수신된 모든 수수료 견적들뿐만 아니라 권고를 제공함으로써, 지불 프로세서는 수신된 다른 수수료 견적들과 상이한 수수료 견적들을 선택하거나 트랜잭션을 제출하기 위해 권고 수수료 견적을 사용하는 옵션을 클라이언트에게 제공하였다.
일부 실시예들에서, 방법은 개개의 수수료 견적을 제공하는 복수의 채굴자들 중 주어진 채굴자의 아이덴티티를 검증하는 단계를 포함하고, 여기서 아이덴티티는 주어진 채굴자와 연관된 디지털 서명에 기초하여 검증된다. 각각의 채굴자와 연관된 개인 키 및 공개 키(또는 공개 어드레스)를 포함하는 암호화 키 쌍들은 수수료 견적들이 실제로 주어진 채굴자로부터 기원한 것임을 검증하는데 사용될 수 있는데, 즉, 개인 키에 의해 서명된 데이터는 대응하는 공개 키를 사용해서만 복원되거나 유효성 검증될 수 있다. 검증이 디지털 서명에 기초하는 경우 표준 PKI(public key infrastructure) 기술들이 사용되고 구현될 수 있다.
다른 실시예들에서, 주어진 채굴자와 관련되는 식별자는 채굴자의 아이덴티티를 검증하기 위해 부가적으로 또는 대안적으로 사용될 수 있다. 일부 실시예들에서, 방법은 MinerID와 같은 지불 프로세서를 포함한다. 일부 실시예들에서, 상기 식별자는 주어진 채굴자에 대한 평판 표시자와 연관될 수 있다. 일부 실시예들에서, MinerID는 주어진 채굴자가 부분을 이루는 채굴 풀에 기초할 수 있거나 주어진 채굴자에 특유할 수 있다. 평판 표시자는 채굴자의 성과의 측정과 관련된다. 예컨대, 일부 예들에서, 이 평판은 주어진 채굴자가 과거에 견적된 수수료로 트랜잭션들을 어떻게 실행하거나 채굴하였는지에 기초할 수 있다. 예컨대, 평판 표시자는 예컨대, 채굴자가 그 채굴자에 의해 견적된 수수료들의 수락 가능한 범위에서 또는 그 범위 내에서 트랜잭션들을 정기적으로 채굴하는 경우, 가치가 더 높아짐으로써 양호한 평판을 표시할 수 있다. 일부 실시예들에서, 채굴자에 대한 평판 점수 또는 표시자는 채굴자에 통신 가능하게 커플링된 적어도 하나의 지불 프로세서에 의해 계산, 유지 및 관리될 수 있다.
일부 실시예들에서, 지불 프로세서에 의해 구현된 제1 양상의 방법은, 채굴자 서명에 기초하여 복수의 채굴자들 중 주어진 채굴자로부터의 획득된 수수료 견적을 유효성 검증하는 단계를 포함하며, 이는 PKI 기술들을 사용하여 주어진 채굴자의 아이덴티티를 검증하기 위한 디지털 서명에 대한 것과 상이하다. 유효성 검증 단계를 위해 지불 프로세서에 의해 사용되는 채굴자 서명은 유리하게는, 지불 프로세서에 제공된 개개의 수수료 견적에 대한 트랜잭션을 채굴할 것이라는 채굴자의 서약으로서 역할을 하거나 이를 표시한다. 유리하게는, 채굴자 서명의 존재는 또한 채굴자가 임의의 충돌하는 트랜잭션(들)을 거부할 것임을 확인하는 역할을 한다. 따라서, 채굴자 서명에 기초하여 유효성 검증하는 단계는 유리하게는 주어진 채굴자가 채굴의 경우 블록에 트랜잭션을 포함시키고 임의의 충돌하는 트랜잭션을 포함시키지 않을 것이라는 게런티(guarantee)로서 작용한다. 일부 실시예들에서, 주어진 채굴자에 의해 제공되는 그러한 게런티(들)에 기초하여 주어진 채굴자의 성과를 모니터링하는 것은 주어진 채굴자와 연관된 채굴자 평판 또는 점수를 정의하거나 그에 영향을 미칠 수 있다.
일부 실시예들에서, 복수의 채굴자들 중 각각의 채굴자에 의해 제공되는 수수료 견적들은 수수료 견적의 값을 포함하는 데이터 유형으로서 지불 프로세서에 제공된다. 일부 실시예들에서, 데이터 유형은 JSON(JavaScript Object Notation) 오브젝트 포맷이다.
일부 실시예들에서, 지불 프로세서에서 적어도 하나의 채굴자로부터의 수신된 출력 스크립트는 적어도 하나의 채굴자에 대한 멤풀과 연관된 UTXO(Unspent Transaction Output)이고, UTXO는 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 포함하며, 여기서 블록체인 트랜잭션은 클라이언트와 고객 간의 디지털 자산 지불과 관련된다.
일부 실시예들에서, 클라이언트가 고객과의 주어진 지불 트랜잭션, 또는 클라이언트와 관련된 임의의 트랜잭션과 관련된 블록체인 트랜잭션들을 유리하게 식별하거나 추적할 수 있도록 하기 위해, 방법은 트랜잭션 식별자에 대한 대응하는 블록체인 트랜잭션을 획득하기 위해 복수의 채굴자들에게 요청을 전송하는 단계들을 포함하며, 이 요청은 클라이언트로부터의 트랜잭션 식별자와 연관된 상태 질의에 응답하여 지불 프로세서에 의해 적어도 하나의 채굴자에게 전송된다. 이에 응답하여, 지불 프로세서는 복수의 채굴자들 중 적어도 하나의 채굴자로부터 이전에 생성된 대응하는 블록체인 트랜잭션을 획득한다. 적어도 하나의 채굴자에 의한 블록체인 트랜잭션의 채굴 상태에 기초하여, 방법은 트랜잭션 식별자와 연관된 획득된 블록체인 트랜잭션과 관련된 상태 결과를 클라이언트에 전송하는 단계를 포함한다. 결과는 블록체인 트랜잭션이 채굴되었는지, 즉 완료되었는지 또는 일부 이유로 거부되었는지, 또는 이 주어진 채굴자 이전에 복수의 채굴자들 중 다른 채굴자에 의해 이미 채굴되었기 때문에 유효하지 않은지를 표시할 수 있다. 이는 유리하게는 상이한 채굴자에 의해 특정 트랜잭션에 대해 채굴이 행해진 경우 이중 소비를 회피한다. 일부 실시예들에서, 채굴자는 채굴되거나 블록에 추가하지 않은 트랜잭션들을 2차 멤풀에 유지할 수 있으며, 이 2차 멤풀은 채굴자와 연관된 1차 멤풀과 별개인 대안적인 또는 부가적인 멤풀이거나 그로서 작용할 수 있다. 2차 멤풀은 TxID들이 이중 소비에 대해 체크될 수 있도록 하는 임시 멤풀일 수 있다. 이는 유리하게는, 트랜잭션이 주어진 채굴자에 의해 채굴되지 않더라도, 그것이 여전히 2차 멤풀에서 유지되고 향후 이중 소비들에 대해 체크되고 거부하는 데 사용되도록 보장한다. 채굴되지 않거나 주어진 채굴자에 의해 주어진 채굴자의 2차 멤풀에 채굴하도록 의도된 트랜잭션을 홀딩하는 데 시간 제한이 존재할 수 있다. 일부 실시예들에서, 2차 멤풀에 저장된 트랜잭션들은 만료 시간과 연관될 수 있으며, 만료 시간 후에, 트랜잭션들은 제거될 것이다. 일부 실시예들에서, 주어진 채굴자에 의해 채굴되지 않은 트랜잭션들을 각자의 2차 멤풀에 저장하기 위해 채굴자와 연관된 별개의 수수료가 존재할 수 있다.
일부 실시예들에서, 제1 양상의 방법은, HTTPS(Hypertext Transfer Protocol Secure) 포맷으로 수수료 견적들에 대한 제1 요청, 클라이언트에 대한 디지털 자산 지불과 연관된 트랜잭션의 제출에 대한 제2 요청, 및/또는 클라이언트로부터의 트랜잭션에 대한 상태 질의를 수신하는 단계; 및 그 후 RPC(Remote Procedure Call)들을 복수의 채굴자들에게 전송하기 전에 이들을 RPC 포맷으로 변환하는 단계를 수행하기 위해 지불 프로세서와 연관된 API(application programming interface) 변환기를 제공하는 단계를 더 포함한다. 이는, 클라이언트가 웹 서비스들에 대한 인터넷 프로토콜 통신 표준들을 사용하여 통신하지 않는 복수의 채굴자들과의 상호운용성을 원활하게 제공하고 웹-기반 API를 사용하여 HTTPS를 통해 블록체인과 연관된 요청들을 통신할 수 있게 하기 때문에 유리하다. 예컨대, 모든 존재하는 BSV 채굴자들 또는 구현들은 원격 프로시저 호출을 사용한다. 이 실시예에서 구현된 API 변환기는 HTTPS로부터 RPC로 또는 그 반대로의 변환, 또는 또한 구상될 수 있는 주어진 암호 화폐 또는 디지털 자산에 대한 개별 채굴자들 또는 네트워크들에 의해 지원되는 다른 웹-기반 프로토콜들 내지 대안적인 통신 프로토콜들로 제한되지 않는다. 역방향 흐름 경로에서, 제1 양상의 방법은 또한, 복수의 채굴자들 중 하나 이상의 채굴자들로부터의 대응하는 블록체인 트랜잭션과 연관된 응답들을 RPC 포맷으로 수신하고 클라이언트에 대해 HTTPS를 사용하여 개개의 응답들을 상응하게 변환하는 것을 포함한다. 따라서 유리하게는, 지불 프로세서에 의해 제안된 인터페이스를 구현하는 것은 클라이언트들(수취인들) 및 채굴자들이 상이한 무선 데이터 통신 프로토콜들 및 메커니즘들을 사용할 때 블록체인에 트랜잭션들을 제출하기 위한 원활한 통신을 가능하게 한다.
일부 실시예들에서, 지불 프로세서와 연관된 API 게이트웨이가 제공될 수 있다. 위에서 언급된 API 변환기는 이러한 실시예들에서 API 게이트웨이와 연관될 수 있다. 또한, API 게이트웨이는 또한 일부 실시예들에서, 다음 즉,
- 트랜잭션들의 캐싱
- 채굴자 노드 장애들의 경우에 복원 기능들을 수행하는 것
- 지불 프로세서 및/또는 클라이언트 및/또는 채굴자 노드로/로부터 메시지들 또는 알림들을 전송하는 데 사용될 수 있는 하나 이상의 엔드포인트들 또는 URL들의 레코드를 유지하는 것
- 일부 이유로 제출하지 못한 트랜잭션들을 계속 추적하는 것을 포함하는 복원 특징들을 제공하는 것 중 하나 이상을 포함(그러나 이에 제한되지 않음)하는 기능들을 수행/담당하도록 하나 이상의 컴퓨팅 디바이스들에서 구현될 수 있다. 일부 예들에서, 이는 지불 프로세서에서 홀딩되거나 그에 의해 세팅되는 구성 가능한 파라미터뿐만 아니라; 만료된 추적된 트랜잭션들을 제거하기 위한 메커니즘의 포함일 수 있다. API 게이트웨이는 또한 장애 시나리오들에서 트랜잭션들을 다시 제출하는 기능성과 연관될 수 있고, 그리하여 진정한 트랜잭션들의 오류 처리 및 이중 소비들을 구별하기 위한 기능성을 제공한다.
제2 양상에 따르면, 본 개시는 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 방법을 제공하며, 이 방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되고, 클라이언트는 클라이언트에 대한 지불 서비스를 구현하는 적어도 하나의 지불 프로세서에 통신 가능하게 커플링된다. 일부 실시예들에서, 지불 프로세서는 위에서 제시된 제1 양상의 방법 및 연관된 실시예들을 구현하도록 구성된다. 클라이언트, 즉 판매자에 의해 구현된 제2 양상의 방법은 적어도 하나의 지불 프로세서들 중의 지불 프로세서에 제1 요청을 전송하는 단계들을 포함하며, 이 요청은 지불 프로세서를 통해 복수의 채굴자들로부터 획득될 트랜잭션 또는 복수의 트랜잭션들의 채굴에 대한 하나 이상의 수수료 견적들에 관련된다. 위에서 언급된 바와 같이, 획득된 수수료 견적들은 임의의 트랜잭션들의 채굴과 관련되거나 고객으로부터의 디지털 자산 지불과 관련된 주어진 트랜잭션에 특정적일 수 있다.
제2 양상의 일부 실시예들에서, 지불 프로세서로부터 하나 이상의 수수료 견적들의 수신에 응답하여, 방법은 하나 이상의 수신된 수수료 견적들 중에서 수수료 견적을 선택하는 것을 포함한다. 제1 양상에서 언급된 바와 같이, 선택된 수수료 견적은 지불 프로세서에 의해 이루어진 권고에 기초할 수 있거나 그렇지 않을 수 있다. 그 후, 제2 양상의 방법은 고객으로부터의 디지털 자산 지불을 요청 및/또는 프로세싱하는 단계를 포함하며, 이 요청은 선택된 수수료 견적과 연관된다. 일부 실시예들에서, 이 요청은 클라이언트에 의해 디지털 자산 지불을 위해 고객에게 발행된 송장 또는 지불 요청과 유사하다. 예컨대, 클라이언트는 디지털 지갑과 연관된 커피숍 단말일 수 있고, 고객은 예컨대, 이 요청에 대한 응답으로 커피에 대해 2사토시를 지불할 수 있으며, 고객은 또한 디지털 지갑과 연관된다. 이제 선택된 수수료 견적이 선정되었으므로, 이는 고객으로부터의 지불에 대한 요청에 추가될 수 있다. 그 후, 방법은 위에서 언급된 고객 지불과 연관된 주어진 트랜잭션에 대한 제2 요청을 지불 프로세서에 제출하는 것을 포함하며, 이 제출은 주어진 트랜잭션의 채굴에 대한 선택된 수수료 견적에 기초한다. 일부 실시예들에서, 선택된 수수료 견적은 명확하게 표시되거나 제2 요청에 포함되어서, 지불 프로세서는 유리하게는, 선택된 수수료 견적에서 또는 그 이하에서 트랜잭션을 채굴할 수 있는 채굴자들을 식별할 수 있거나 부가적으로 또는 대안적으로, 채굴자들은 자신들이 선택된 수수료 견적을 만족시키는 여부를 식별할 수 있다.
위에서 언급한 바와 같이, 일부 실시예들에서, 클라이언트는 지불 프로세서로부터 수신된 가장 높은 수수료 견적, 또는 수신된 수수료 견적들의 값의 평균 또는 중앙값이거나 그 근처에 있을 수 있는 값에 기초하여 수수료 견적을 선택할 수 있다. 어느 하나의 옵션과 연관된 이점들은 위에서 논의한 것과 동일한데, 즉, 최대 값은 모든 채굴자들이 채굴할 기회를 갖도록 허용하고, 다른 값들은 선택된 견적 또는 그 이하에서 트랜잭션을 채굴할 수 있음으로써 수수료 견적을 충족시키는 일부 채굴자들에게 채굴을 제한할 것인 반면, (예컨대, 견적이 너무 높기 때문에) 트랜잭션을 채굴할 수 없는 그러한 채굴자들은 주어진 트랜잭션에 대한 임의의 이중 소비들을 검증하는 데 사용될 수 있도록 2차 멤풀과 같은 임시 저장소에 블록체인 트랜잭션의 레코드를 여전히 유지할 수 있다.
제2 양상의 일부 실시예들에서, 방법은 또한, 적어도 하나의 채굴자에 의해 생성된 블록체인 트랜잭션에 대한 트랜잭션 식별자를 수신하는 것을 포함하며, 블록체인 트랜잭션은 제출된 트랜잭션, 즉 클라이언트와 고객 간의 트랜잭션에 대응한다. 일부 실시예들에서, 방법은 획득된 트랜잭션 식별자와 연관된 상태 질의를 전송하는 것; 그리고 트랜잭션 식별자에 대응하는 블록체인 트랜잭션에 대한 상태 결과를 획득하는 것을 포함한다.
제2 양상과 연관된 이점들은 제1 양상과 관련하여 위에서 논의된 이점들과 관련된다. 제2 양상은 제1 양상을 보완하지만, 트랜잭션이 블록체인에 기록되도록 요청하는 클라이언트에 의해 구현되는 방법을 보여준다. 제2 양상의 방법을 구현하는 클라이언트는 일부 실시예들에서, 제1 양상의 방법에 따라 지불 API로서 지불 서비스를 구현하도록 구성된 적어도 하나의 지불 프로세서와 통신할 수 있다.
추가로, 본 양상의 방법은 유리하게는, 클라이언트들이 지불 서비스에 제공할 수수료 견적을 선택할 수 있게 하며, 이는 클라이언트 또는 판매자 제어 또는 그들의 트랜잭션이 시기 적절한 방식으로 주어진 채굴 수수료로 채굴될 것이라는 사실에 영향을 미치는 확신성을 제공하고 그리하여 제안된 지불 서비스 또는 지불 API를 사용하는 클라이언트에 대해 채굴된 트랜잭션에 대한 증가된 보안, 상호 운용성, 신뢰성, 효율성 및 적시성을 제공한다.
위에서 언급된 바와 같이, 지불 프로세서에 의해 구현된 지불 서비스는 API이기 때문에, 일부 실시예들에서, 클라이언트로부터의 제1 요청 및/또는 상태 질의는 HTTPS GET 요청이고, 제2 요청은 HTTPS POST 요청이다. 따라서 유리하게는, 트랜잭션이 블록체인 내로 채굴되도록 요청하기 위해 표준 인터넷 및 웹-기반 통신 프로토콜들이 클라이언트에 의해 사용될 수 있다. 일부 실시예들에서, 클라이언트로부터의 제1 및/또는 제2 요청 및/또는 상태 질의와 연관된 데이터는 JSON(JavaScript Object Notation) 오브젝트 포맷으로 제공된다.
제3 양상에 따라, 본 개시는 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법을 제공하며, 이 방법은 복수의 채굴자들 중의 채굴자와 연관된 하나 이상의 프로세서들에 의해 구현되고, 여기서 복수의 채굴자들은 클라이언트에 대한 지불 서비스를 구현하는 적어도 하나의 지불 프로세서에 통신 가능하게 커플링된다. 일부 실시예들에서, 지불 서비스는 제1 양상과 관련하여 위에서 설명된 방법들에 기초하여 지불 프로세서에 의해 구현된다. 일부 실시예들에서, 클라이언트는 위에서 논의된 바와 같이 제2 양상과 연관된 방법들을 구현하도록 구성된다. 복수의 채굴자들 중의 채굴자에 의해 구현되는 바와 같은 제3 양상의 방법은 클라이언트와 연관된 트랜잭션에 대한 수수료 견적에 대한 제1 요청에 응답하여, 블록체인에서 트랜잭션을 채굴하기 위해 채굴자와 관련된 현재 수수료 견적을 제공하는 단계들을 포함한다. 일부 실시예들에서, 수수료 견적은 클라이언트와 연관된 지불 프로세서에 대한 데이터 유형으로서 제공될 수 있다. 위에서 논의된 바와 같이, 제1 요청은 임의의 트랜잭션 또는 복수의 트랜잭션들에 대한 현재 수수료 견적에 대한 요청과 관련될 수 있거나 클라이언트와 고객 간의 특정 트랜잭션에 특유할 수 있다.
제3 양상의 일부 실시예들에서, 클라이언트 대신 지불 프로세서로부터의 제2 요청에 응답하여 ― 제2 요청은 블록체인에서 주어진 트랜잭션을 제출하는 것과 관련되고, 주어진 트랜잭션은 선택된 수수료 견적에 기초하며, 여기서 선택은 제1 및 제2 양상들에서 제시된 바와 같이 클라이언트에 의해 행해짐 ― , 방법은 다음 단계들을 포함한다. 주어진 트랜잭션과 연관된 선택된 수수료 견적들이 채굴자에 대한 현재 수수료 견적을 만족시킨다는 결정, 즉 선택된 수수료 견적이 현재 수수료 견적에 있거나 그 범위 내에 있다는 결정에 기초하여, 주어진 채굴자는 그 후 주어진 트랜잭션과 연관된 대응하는 블록체인 트랜잭션을 생성한다. 방법은 또한 생성된 블록체인 트랜잭션에 대한 출력 스크립트(UTXO)를 생성하는 것, 생성된 출력 스크립트를 채굴자와 연관된 멤풀에 추가하는 것, 출력 스크립트를 지불 프로세서에 전송하는 것을 포함하며, 여기서 출력 스크립트는 대응하는 블록체인 트랜잭션과 연관되는 트랜잭션 식별자(TxID)를 포함한다. 일부 실시예들에서, 트랜잭션 식별자와 연관된 상태에 대한 요청에 응답하여, 채굴자는 대응하는 블록체인 트랜잭션의 현재 채굴 상태에 기초한 결과를 반환하는 것을 포함한다.
제3 양상과 연관된 이점들은 제1 및 제2 양상들과 관련하여 위에서 논의된 이점들과 관련된다. 제3 양상은 제1 및 제2 양상을 보완하지만, 블록체인에 기록될 수 있는, 클라이언트에 대한 트랜잭션을 구성하기 위해 지불 프로세서에 커플링된 복수의 채굴자들 중의 채굴자에 의해 구현되는 방법을 보여준다. 제3 양상의 방법을 구현하는 채굴자들은 일부 실시예들에서, 제1 양상의 방법에 따라 지불 API로서 지불 서비스를 구현하도록 구성된 적어도 하나의 지불 프로세서와 통신할 수 있다.
일부 실시예들에서, 현재 수수료 견적을 제공하는 단계 및/또는 출력 스크립트를 전송하는 단계 및/또는 결과를 반환하는 단계는 RPC(Remote Procedure Call)로서 구현된다. 이는 예컨대, BSV 비트코인 네트워크와 같이 채굴자들이 RPC들을 통해 무선에 대응하도록 구성되는 경우 유리하다. 일부 실시예들에서, 제3 양상의 방법은 채굴자 풀 또는 네트워크, 즉 지불 프로세서와 연관된 복수의 채굴자들 간의 데이터 흐름의 부가적인 보안 및 간소화를 위해, 무선 통신 네트워크를 통해 클라이언트에 대한 지불 프로세서로 전파하기 전에 채굴자로부터 노드 커넥터, 및 선택적으로 복수의 채굴자들에 대한 방화벽에 RPC들을 전송하는 단계를 포함할 수 있다. 더욱이, 유리하게는, 노드 커넥터는 지불 프로세서와 연관된 API 변환기와 풀에 있는 하나 이상의 채굴자들 사이에 보안 통신 채널을 제공할 수 있다.
일부 실시예들에서, 주어진 트랜잭션과 연관된 선택된 수수료 견적이 채굴자에 대한 현재 수수료 견적을 만족시키지 않는다는 결정에 기초하여, 예컨대, 현재 수수료 견적이 선택된 수수료 견적보다 높은 경우, 방법은 채굴자와 연관된 부가적인 임시 멤풀일 수 있는 2차 멤풀에 블록체인 트랜잭션과 연관된 출력을 추가하는 것을 포함한다. 위에서 언급된 바와 같이, 이는 본원에서, 채굴자 노드가 이러한 임시 엔트리를 사용하여 주어진 트랜잭션과 연관된 이중 소비들이 존재하지 않는다는 것을 체크하고 유리하게는 이를 보장할 수 있도록 특정한 미리 정의된 시간 기간 동안 저장될 수 있다
그와 연관된 이벤트들 또는 트랜잭션들의 안전하고, 감사 가능하고, 변조 방지 및 신뢰할 수 있는 레코드를 요구하는 다수의 애플리케이션들을 위한 분산 원장(블록체인) 기술의 사용의 스케일링을 통해; 클라이언트들 또는 판매자 엔티티들과 같은 참여 엔티티들에 대한 솔루션들은 전통적으로 블록체인의 전체 사본을 실시간으로 동기화하여, 블록체인으로부터 직접, 그의 애플리케이션들 및 연관된 디지털 지갑들과 관련된 트랜잭션들 및 매립된 데이터를 식별하는 것에 의존해 왔다. 그러나 클라이언트, 즉 판매자 애플리케이션의 범위, 능력 및 보안이 진화함에 따라 그리고 블록체인이 스케일링됨에 따라, 블록체인과 연관된 이점들의 잠재력을 스케일링하고 완전히 실현하고 활용하기 위해 참여 당사자들이 직접 통신하고 이러한 애플리케이션들이 메시지들을 직접 교환할 수 있게 하는 기술적 솔루션 및 계산적으로 정교하든 그렇지 않든 임의의 유형의 클라이언트 또는 엔티티가 이러한 솔루션을 이용 가능하게 하는 것에 대한 필요성이 있다는 것이 분명해졌다. 본 개시의 제4 양상은 제1 양상에서 위에서 논의된 바와 같은 지불 서비스들과 연관된 클라이언트들에 대해 이러한 솔루션을 제공한다.
제4 양상의 제1 구현에 따라, 본 개시는 블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법을 제공하며, 이 방법은 지불 프로세서에 의해 구현된다. 일부 실시예들에서, 지불 프로세서는 제1 양상과 관련하여 논의된 바와 같은 지불 프로세서일 수 있다. 이 방법은 디지털 자산과 연관된 트랜잭션을 블록체인에 제출하라는 요청을 하나 이상의 클라이언트들 중 주어진 클라이언트로부터 수신하는 단계를 포함한다. 이전 양상들에서 위에서 언급된 바와 같이, 이 요청은 HTTP 송신 포맷을 사용하여 지불 프로세서로 전송된다. 일부 예들에서, 이 요청은 트랜잭션을 제출하도록 클라이언트로부터 수신된 위에서 설명된 제2 요청이다.
제4 양상의 제1 구현에서, 클라이언트로부터의 요청은 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하기 위한 콜-백 식별자와 연관된다. 일부 실시예들에서, 콜-백 식별자는 클라이언트와 연관된 액세스 포인트 또는 URI 또는 URL일 수 있다. 다른 유형들의 콜-백 식별자들 및 메커니즘들이 또한 가능하다. 통신 채널이 제공으로, 이러한 메커니즘이 아래에서 상세히 논의된다.
그 후, 제4 양상의 방법은 블록체인에 트랜잭션을 포함시키기 위한 채굴자에 대한 요청과 연관된 트랜잭션을 제출하는 단계를 포함한다. 일부 실시예들에서, 이 단계는 제1 양상과 관련하여 논의된 바와 같이 클라이언트로부터 수신된 제2 요청에 따라 트랜잭션을 제출하는 것과 유사하다. 지불 프로세서는 요청과 연관된 트랜잭션뿐만 아니라 콜-백 식별자를 복수의 채굴자들 중 주어진 채굴자에게 제출한다.
일부 실시예들에서, 주어진 채굴자가 지불 프로세서를 통해 제출된 트랜잭션을 수신할 때, 제1 및/또는 제2 및/또는 제3 양상에서 위에서 언급한 바와 같이, (제출된 요청에 대응하는) 대응하는 블록체인 트랜잭션과 연관된 트랜잭션 식별자(TxID)가 채굴자로부터 응답으로서 수신된다. 일부 실시예들에서, 이는 제1 양상에서 위에서 언급된 바와 같이 대응하는 블록체인 트랜잭션과 연관된 출력 스크립트, 예를 들면 UTXO(Unspent Transaction Output)를 수신하는 것을 포함한다. 대응하는 블록체인 트랜잭션에 대한 이 트랜잭션 식별자(TxID)는 그 후, 클라이언트에 전송된다.
지불 프로세서는 또한 액세스 엔드포인트, 채굴자 식별자(채굴자 ID) 또는 채굴자와 연관된 로케이션을 제공함으로써 클라이언트에게 주어진 채굴자를 식별시킨다. 일부 경우들에서, 채굴자가 TxID로 위에서 언급한 응답의 부분으로서 클라이언트에게 식별될 수 있다. TxID와 관련된 임의의 추가의 서신(correspondence) 또는 메시지들이 계속 추적될 수 있도록 TxID를 갖는 것이 클라이언트에 대해 유리하다. 위에서 언급된 바와 같이, TxID는 또한 클라이언트가 대응하는 트랜잭션의 상태를 체크하는 것을 개시하기로 선택한 경우, 이러한 체크를 행하는 데 사용될 수 있다.
그 후, 방법은 채굴자에 의해 제공되는 대응하는 블록체인 트랜잭션과 관련된 적어도 하나의 콜-백 알림을 클라이언트에 대해 가능하게 하거나 프로세싱하는 단계를 포함한다. 콜-백 식별이 이루어져서 그것이 대응하는 트랜잭션에 관해 즉 클라이언트에 대한 로케이션 또는 URL을 통해 클라이언트에 접촉하기 위해 채굴자에 의해 직접 사용될 수 있는 실시예들에서, 지불 프로세서는 콜-백 알림을 가능하게 한다. 콜-백 식별이 이루어져서 이것이 이러한 직접 통신을 개시하기 위해 액세스 토큰의 제공 또는 키들의 교환 등과 같은 추가 단계를 요구하는 경우, 지불 프로세스는 채굴자가 콜-백 식별자를 사용하여 클라이언트와 통신할 수 있게 하도록 이러한 추가 액세스를 프로세싱해야 한다.
본 개시의 제4 양상의 제2 구현은 트랜잭션을 제출하라는 클라이언트로부터의 요청이 채널과 연관되는 실시예에 관한 것이다. 이 경우에, 제1 구현에서 위에서 언급된 채널 식별자는 채널의 형태이며, 채널은 주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하도록 구성된다. 채널은 이 구현에서, 주어진 클라이언트와 연관된 채널 서비스에 의해 용이하게 되거나 제공되고, 주어진 클라이언트에 대한 주어진 토픽 또는 트랜잭션에 특유하다. 채널은 클라이언트와 연관된 로케이션 또는 URL 또는 채널 식별자에 의해 식별될 수 있다.
채널 서비스는 별개의 채널 프로세서에 의해 제공될 수 있거나, 위에서 언급된 지불 프로세서에 의해 제공될 수 있거나, 또는 클라이언트와 통합될 수 있다. 일부 실시예들에서, 채널은 데이터의 송신을 위해 채널과 관련된 채널 기능들 또는 절차들; 및/또는 채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함하는 하나 이상의 기능들과 연관된다. 따라서 채널은 메시지 또는 데이터 전달을 위해 엔티티들 간의 직접 또는 피어-투-피어 통신 경로들 또는 세션들을 가능하게 한다. 대부분의 실시예들에서, 각각의 채널에 대해 단 2개의 엔티티들만이 있다.
채널 서비스 및/또는 채널 프로세서의 예는 nChain Holdings Limited의 이름으로 출원되고, 그의 청구 대상이 인용에 의해 본원에 포함되는 영국 특허 출원 번호 제2007597.4호에서 상세히 설명된다.
일부 실시예들에서, 하나 이상의 기능들은 인터페이스들의 형태이거나 액세스 포인트들은 클라이언트를 위해 제공되며 대부분의 경우들에서, 예컨대, 각각의 트랜잭션마다 하나씩 클라이언트와 연관될 수 있는 복수의 채널들 중 주어진 채널에 특유하다. 대부분의 실시예들에서, 채널들은 전이중, 즉 클라이언트와 다른 엔티티 간의 양방향 통신을 가능하게 한다. 일부 실시예들에서, 통신은 일 방향으로만 허용될 수 있는데, 즉, 클라이언트는 다른 엔티티에 메시지들을 전송하거나 다른 엔티티로부터 메시지들을 수신하기만을 원할 수 있다.
일부 실시예들에서, 클라이언트는 복수의 채널들의 소유자이거나 복수의 채널들과 연관될 수 있고, 위에서 언급된 채널은 복수의 채널들 중 하나이며, 이들은 채널 서비스에 의해 제공되는 하나 이상의 기능들에 기초하는 채널들이다. 일부 실시예들에서, 하나 이상의 기능들은 주어진 클라이언트에 대해 발행되거나 그에 제공되는 API(application programming interface)들이며, 상기 API는 하나 이상의 채널들에 대한 채널 API들; 및 데이터, 즉 각각의 또는 주어진 채널과 연관된 토픽과 관련된 메시지들에 대한 메시지 API들을 포함한다. API들은 엔드포인트들, 인터페이스들 또는 애플리케이션의 특징들 또는 데이터, 또는 다른 서비스들에 액세스하는 엔티티 이를테면, 이 경우에 클라이언트에 대한 애플리케이션들의 생성 또는 관리를 허용하는 일 세트의 기능들 및 절차들로서 이해될 수 있다. 이 경우에, 이는 메시지 기능들뿐만 아니라 채널 기능들을 구현하는 것이다.
제2 구현에서, 클라이언트로부터의 요청은 채널에 대한 하나 이상의 액세스 토큰들과 추가로 연관된다. 이러한 토큰들은 채널 프로세서에 의해 제공된다. 일부 실시예들에서, 상기 토큰(들)은 다른 엔티티와의 보안 통신을 위해 구성되며, 하나 이상의 액세스 토큰들은 주어진 채널 또는 심지어 주어진 채널의 하나 이상의 메시지들과 관련된다. 일부 실시예들에서, 액세스 토큰들은 주어진 채널 또는 주어진 메시지에 특유한 API 토큰들이다. 액세스 토큰들, 특히 API 토큰들은 일부 실시예들에서, 채널에 대한 액세스를 요청하는 엔티티 또는 애플리케이션에 대한 고유 식별자들로서 작용할 수 있다. 일부 실시예들에서, 액세스 토큰은 클라이언트에 할당된 고유한 인증 크리덴셜(unique authentication credential)들인 것으로 간주될 수 있으며, 개별 채널들 또는 각각의 채널의 개별 메시지만큼의 입도(granular)일 수도 있다. 일부 실시예들에서, 액세스 토큰들은 클라이언트가 인증을 위해 그의 채널들 각각에 대해 다른 엔티티에 이러한 토큰들을 제공할 수 있도록 이루어질 수 있다. 본 실시예들에서, 액세스 토큰들은 트랜잭션과 연관되는 채굴자에 대해, 각각의 트랜잭션마다 클라이언트 또는 채널 서비스에 의해 생성되거나 제공될 수 있다.
일부 실시예들에서, 채널은 채널 식별자와 연관될 수 있고, 채널 식별자는 채널에 대한 로케이션 또는 액세스 포인트와 연관된다. 일부 실시예들에서, 각각의 채널은 특정 채널 식별자와 연관된다. 동일한 주어진 클라이언트는, 채널이 액세스할 수 있게 하는 엔드포인트 또는 로케이션에 대응할 수 있는 자체 고유 식별자를 각각 갖는 다수의 별개의 채널들을 가질 수 있다. 일부 실시예들에서, 주어진 채널은 특정 유형 또는 토픽과 연관된 데이터와 관련하여 임의의 다른 엔티티와 통신하기 위한 것이며, 여기서 채널의 각각의 토픽과 연관된 데이터는 하나 이상의 메시지들 또는 트랜잭션들이거나 그에 포함된다. 유리하게는, 특정 토픽 또는 트랜잭션에 대한 특정 채널을 갖는 것은 특히 판매자 엔티티와 같은 클라이언트의 경우에, 클라이언트에 대해 더 뛰어난 명확성, 신뢰성 및 유연성을 보장하며, 이는 동일한 클라이언트와 연관되는 모든 다른 토픽들 또는 다른 트랜잭션들과 별개로 추적되거나 처리될 필요가 있는 다수의 토픽들(이를테면, 트랜잭션 번호, ID 또는 송장 번호)을 가질 수 있다.
제1 구현의 지불 프로세서가 또한 채널 프로세서인, 즉 그것이 클라이언트를 위한 채널 서비스뿐만 아니라 지불 서비스를 구현하는 실시예들에서, 제4 양상의 방법은 또한 트랜잭션을 위해 주어진 클라이언트와 연관된 채널에 대한 액세스를 채굴자에게 제공하는 단계를 포함할 수 있다. 이는 클라이언트에 대한 모든 통신이 지불 프로세서에 의해 관리되거나 지불 프로세서를 통해 구현되어서, 채널은 또한 클라이언트를 대신하여 지불 프로세서에 의해 세팅되는 실시예들에서 이점들이다. 액세스는 일부 실시예들에서, 채널 식별자 및/또는 로케이션뿐만 아니라, 채굴자가 그 클라이언트에 대한 채널 내로 데이터를 기록하거나 가져오기 위해 채널과 연관된 하나 이상의 채널 및/또는 메시지 기능들 또는 API들에 액세스하는데 필요할 수 있는 액세스 토큰(들)을 채굴자에게 이용 가능하게 함으로써 제공될 수 있다.
채널이 제공되거나 채널에 대한 액세스가 제공되면, 채굴자로부터의 대응하는 블록체인 트랜잭션과 연관된 콜-백 알림들이 그 후 이러한 채널을 사용하여 클라이언트에 제공된다. 따라서 데이터는 채널을 사용하여 채굴자에 의해 제공될 수 있는데 즉, 개개의 채널에 대한 액세스 토큰을 사용하여 획득된 하나 이상의 채널 및 메시지 기능들 또는 API들을 사용하여 채널에 기록될 수 있다.
일부 실시예들에서, 클라이언트에 대한 콜-백 알림은, 데이터가 채널에 기록되자마자 획득되는 경고 또는 메시지일 수 있으며, 상기 알림은 일부 경우들에서 채널 식별자를 포함한다. 이는, 지불 프로세서에 의해 이미 프로세싱된, 즉 지불 프로세서에 의해 채굴자에게 이미 전송된, 주어진 클라이언트에 대한 특정 TxID 또는 블록체인 트랜잭션과 관련되기 때문에 콜-백으로서 지칭된다. 유리하게는, 채널은 주어진 클라이언트에 대해 TxID가 특별히 할당된 채널에서 메시지들 또는 응답들이 제공되는 것을 가능하게 한다.
일부 실시예들에서, 콜-백 알림은 주어진 클라이언트에 의해 이미 제출되고 블록체인에 레코딩된 트랜잭션의 이중 소비 알림과 관련된다. 이 경우에, 채굴자에 의해 채널에서 제공된 데이터는 다음 데이터 즉,
- 이중 소비인 블록체인 트랜잭션의 트랜잭션 식별자(TxID); 및 일부 경우들에서, 선택적으로
- 블록체인 트랜잭션을 제출한 지불 프로세서에 대한 서비스 엔드포인트를 포함하는 반환 페이로드이다. 이는 클라이언트가 복수의 지불 서비스들과 연관되는 경우에 유용하고, 이에 따라 식별자는 처음에 채굴자에게 요청을 제출한 지불 프로세서를 명확하게 표시한다.
일부 실시예들에서, 콜-백 알림은 블록체인에서 주어진 클라이언트에 의해 제출된 트랜잭션의 포함 증명 즉 머클(Merkle) 증명과 관련된다. 이 경우에, 채굴자에 의해 채널에서 제공된 데이터는 채널에서의 반환 머클 증명이고, 상기 반환 머클 증명은 채굴자에 의해 제공되고, 반환 머클 증명은 다음 데이터 즉,
- 머클 증명이 관련된 블록체인 트랜잭션의 트랜잭션 식별자(TxID);
- 블록체인 트랜잭션이 포함되는 블록의 블록 헤더; 및
- 트랜잭션 식별자(TxID)에 대한 형제 해시들의 어레이를 포함한다.
일부 실시예들에서, 제공된 채널 또는 메시지 기능(들)은 콜-백 알림들을 위해 채널에서 하나 이상의 데이터 또는 메시지들의 액세스, 생성 및/또는 관리를 가능하게 하도록, JSON(JavaScript Object Notation)-오버(over)-HTTP(Hyper Text Transfer Protocol) API를 포함한다.
채널을 통해 제공되는 콜-백 알림들과 연관된 이러한 데이터 또는 콜-백 메시지들은 다수의 블록체인 연관 애플리케이션들에 특히 유리할 수 있는데, 그 이유는 채굴자는 추후에, 채널을 사용하여 블록체인에 제출된 트랜잭션에 대한 머클 트리 포함 증명(Merkle tree proof of inclusion) 또는 이중 소비 통지를 다른 엔티티 즉, 이 경우 트랜잭션 제출을 요청한 클라이언트에 직접 전송할 수 있기 때문이다. 이는 판매자와 같은 클라이언트 또는 다른 엔티티가 채굴되었는지 여부를 평가하도록 그러한 트랜잭션을 찾기 위해 블록체인을 검색해야 할 필요가 더 이상 없다는 것을 의미하므로 유용하다. 이는 유리하게는 일단 채굴되면 채널을 사용하여 포함 증명이 직접 제공되기 때문이다.
제4 양상의 제2 구현의 방법은 또한 상기 알림들을 클라이언트에 제공하고 그리고/또는 저장하는 단계를 포함한다. 일부 실시예들에서, 클라이언트가 오프라인이거나 채널 프로세서에 통신 가능하게 연결되지 않을 때, 콜-백 알림들은 채널 프로세서에 의해, 즉 채널에서 주어진 클라이언트에 대해 큐잉되는 데이터에 대한 푸시 알림으로서 저장된다. 다른 실시예들에서, 클라이언트가 온라인이거나 채널 프로세서에 통신 가능하게 연결될 때, 채널의 연관된 데이터(콜-백 알림과 연관됨)는 채널로부터 직접 풀링될 수 있다.
유리하게는, 채널들의 사용은 주어진 채널에 있는 각각의 요청 또는 메시지의 비동기식 프로세싱을 허용한다. 이는, 채널에서 메시지들에 대한 매끄럽고 정확하고 불연속적이거나 지연된 프로세싱 흐름을 허용하는데, 그 이유는, 채널이 이러한 토픽에 특유하므로, 임의의 주어진 토픽 또는 트랜잭션에 대한 메시지들뿐만 아니라 순서의 명확성이 항상 존재하기 때문이다. 이는 클라이언트 또는 다른 엔티티가 동작하지 않거나 온라인이 아니거나 콜-백 알림과 연관된 어떠한 데이터도 실행할 수 없는 구현들 또는 상황들에 특히 유용할 수 있다. 따라서 위의 기술은, 채널 프로세서에 의해 큐잉되는 알림들에 기초하여 채널의 메시지들이 액세스되도록 다음에 온라인이거나 네트워크에 연결되는 채널에 메시지들이 여전히 존재할 것이기 때문에, 채널 당사자가 오프라인이거나 응답하지 않을 때조차도, 채널을 사용하여 요청이 여전히 신뢰할 수 있게 전달되고 정확하고 순서대로 프로세싱되는 것을 가능하게 한다. 위에서 언급된 바와 같이, 채널 프로세서의 기능성은 지불 프로세서를 구현하는 동일한 엔티티에 의해 또한 구현될 수 있다.
또한, 아무리 많이 다른 메시지들이 채널에 제공되었더라도, 이들은 전달 순서대로 다른 엔티티가 액세스 가능하게 될 것이다. 따라서 연결이 지연되거나 중단되더라도, 채널의 메시지들의 프로세싱은 지연이 전혀 없는 것처럼 정확하고 원활하게 완료된다.
따라서, 본 개시와 연관된 제4 양상의 위에서 설명된 제2 구현 및 그의 실시예들은 직접 통신을 위한 채널을 구현함으로써 클라이언트에 대한 트랜잭션들의 프로세싱을 위한 안전하고, 오프체인인 당사자 대 당사자(피어 투 피어/직접) 애플리케이션 메시징 메커니즘들을 제공한다. 이 양상은 당사자들 중 하나가 일시적으로 오프라인 경우들에서 당사자들이 안전한 방식으로 통신할 수 있는 메커니즘을 제공한다. 비즈니스와 연관되거나 이를테면, 판매자와 같이 조직을 대표할 수 있는 클라이언트 엔티티들에 대해, 이러한 클라이언트들은 다수의 상품들과 관련하여 그들과 트랜잭션들을 수행하는 매우 다수의 다른 엔티티들(고객들)을 가질 수 있다. 따라서 이러한 시나리오들에 대해, 하나 이상의 고객들 또는 트랜잭션들과의 통신을 위한 채널들을 사용하는 동안, 이러한 모든 트랜잭션들의 레코드를 유지하는 블록체인과 관련된 임의의 기능성을 구현하는 것으로부터 디커플링되거나 연관 해제(disassociate)되는 것은 아주 유익할 것이다. 채널 서비스를 통한 메시지 기능들뿐만 아니라 채널 기능들의 제공을 통해, 이러한 클라이언트들은 특정 트랜잭션(이를테면, 특정 송장 또는 특정 상품에 대한 질의 등)과 관련된 특정 고객에 대해 특정 채널을 활용하는 능력을 가지며, 언제든지 상기 채널을 통해 이러한 트랜잭션 특유의 임의의 추가 정보를 획득할 수 있다.
제4 양상의 제3 구현에서, 본 개시는 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법을 제공하며, 이 방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현된다. 제3 구현은 제2 구현과 유사하며 유사한 이점들과 연관된다. 방법은 채널 서비스와 관련된 채널 요청을 전송하는 단계를 포함하며, 채널 서비스는 채널 프로세서에 의해 구현된다. 채널 프로세서는 영국 특허 출원 제2007597.4호에서 제시된 바와 같이 클라이언트에 대한 채널 서비스를 구현할 수 있다. 제1 요청은 채널 프로세서에 대한 HTTPS(Hypertext Transfer Protocol Secure) 송신 GET 요청일 수 있다. 그 후 클라이언트 구현 방법은 주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 획득하는 단계를 포함한다. 제2 구현에서와 같이, 상기 하나 이상의 기능들은 데이터의 송신을 위한 하나 이상의 채널들과 관련된 채널 기능들 또는 절차들; 및/또는 하나 이상의 채널들을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함한다. 클라이언트는 또한 위에서 제시된 바와 같이 채널에 대한 하나 이상의 액세스 토큰들을 획득한다.
그 후, 방법은 지불 서비스를 구현하는 지불 프로세서 이를테면, 제1 양상 또는 제4 양상의 제1 구현에서 설명된 프로세서에, 디지털 자산과 연관된 트랜잭션을 블록체인에 제출하라는 요청을 전송하는 단계를 포함한다. 이 요청은 지불 프로세서에 대한 HTTPS(Hypertext Transfer Protocol secure) 송신 POST 요청일 수 있으며, 이는 HTTPS API와 연관될 수 있다.
그 후 클라이언트는 지불 프로세서로부터 응답을 획득하며, 응답은 제출된 트랜잭션에 대응하는 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 포함한다. 트랜잭션과 관련된 대응하는 블록체인 트랜잭션은 지불 프로세서에 의해 채굴자에게 제출된다. 응답으로 수신된 이 TxID는 채굴자에 의해 생성된, 그에 대응하는 블록체인 트랜잭션을 계속 추적하는 데 유용하다.
클라이언트는 또한 위에서 언급된 응답과 별개로 또는 이와 함께, 지불 프로세서로부터, TxID를 제공한 채굴자에 대한 식별자 또는 액세스 포인트 또는 로케이션을 수신한다.
그 후, 채널 프로세서로부터 수신된 하나 이상의 채널 기능들을 사용하여, 방법은 식별된 채굴자와의 통신을 위한 채널을 생성하는 단계, 및 채널과 연관된 하나 이상의 액세스 토큰들을 다른 엔티티 ― 이 경우에 채굴자 ― 에 전송하는 단계를 포함한다. 이는 유리하게는 클라이언트와 채굴자 간의 직접 통신을 위한 안전하고 신뢰할 수 있으며 정확한 채널의 셋업을 가능하게 한다.
그 후, 콜-백 알림은 채널 프로세서로부터 수신되며, 이러한 콜-백 알림은 클라이언트가 온라인일 때 또는 지불 프로세서와 통신 가능하게 연결될 때 클라이언트에서 수신될 수 있다. 이 알림에 기초하여, 특정 블록체인 트랜잭션과 관련된 데이터, 즉 클라이언트와 연관된 TxID는 클라이언트가 온라인일 때 채굴자로부터 클라이언트에 의해 직접 획득될 수 있다.
제4 양상의 제3 구현의 일부 실시예들은 피어 투 피어 통신에 사용되는 채널들에 대한 안전한 어드레싱 및 암호화의 제공과 관련된다. 일부 예들에서, 방법은 클라이언트와 연관된 클라이언트 어드레싱 키를 제공하는 단계, 및 채굴자와 연관된 적어도 하나의 채굴자 어드레싱 키를 획득하는 단계를 포함한다. 일부 경우들에서, 클라이언트 엔드포인트가 또한 제공될 수 있으며, 그러한 엔드포인트들이 클라이언트에 이미 알려져 있지 않거나 이용 가능하게 되지 않은 경우 채굴자 포인트가 획득될 수 있다. 어드레싱 키들은 정적 또는 임시 키들 또는 둘 모두일 수 있고, 개개의 엔드포인트들의 아이덴티티를 검증하는 데 사용될 수 있다. 이 경우에, 채널을 이용한 통신은 공유 비밀 키가 핸드셰이크 패턴에 기초하여 도출될 수 있도록 클라이언트 및/또는 채굴자 어드레싱 키에 기초하여 개시될 수 있다. 그 후 이러한 공유 비밀 키는 채널을 통한 모든 통신을 암호화하는 데 사용될 수 있다. 핸드셰이크 패턴은 노이즈 프로토콜 포맷에 기초할 수 있지만, Libsodium 키 교환 또는 생성 기술들과 같은 다른 메커니즘들이 또한 암호화/기만(deception) 키 또는 키 쌍들을 도출하는데 사용될 수 있다.
유리하게는, 정적 및/또는 동적/임시 키들과 같은 어드레싱 키들뿐만 아니라 엔드포인트 이를테면, 클라이언트에 대한 API 엔드포인트를 제공하는 것은 클라이언트와 연관된 하나 이상의 프로세서들이 채굴자에 안전하게 액세스할 수 있게 한다. 일부 실시예들에서, 키들은 추가로, 채널을 통한 메시지들의 임의의 전달 이전에 인증 절차가 개시되는 것을 가능하게 하고 그리하여 채널을 관리하는 당사자들의 아이덴티티를 검증함으로써 보안을 증가시켜, 채널을 통한 모든 통신이 2개의 인증된 엔티티들 사이에서만 발생하도록 보장한다.
공유 비밀 키가 아이덴티티, 즉 채널을 관리하는 두 당사자들 또는 엔티티들의 어드레싱 키들에 기초하기 때문에, 채널을 사용한 직접 통신이 공유 비밀 키에 기초하여 암호화되도록 공유 비밀 키를 획득하는 것은 추가로 유리하다. 따라서 개개의 유효하고 인증된 당사자들만이 암호화된 암호문을 디코딩할 수 있을 것이고 그리하여 신뢰성뿐만 아니라 프라이버시를 증가시키고 악의적인 당사자들의 사칭 시도들에 저항한다.
일부 실시예들에서, 채굴자 및/또는 클라이언트에 대한 엔드포인트는 HTTP API 엔드포인트들일 수 있으며, 여기서 상기 엔드포인트는 채널을 통한 통신 이전에 HTTPS(HTTP Secure) 전송 프로토콜을 사용하여 다른 당사자(또는 상대방)에게 전달된다. 이는 유리하게는, 엔드포인트가 알려진 그리고 신뢰되는 CA(Certificate Authority)로 뒤로 이어지는 인증서들의 체인을 통해 검증 가능하다는 것을 보장한다. 일부 실시예들에서, 클라이언트 엔드포인트뿐만 아니라 채굴자 엔드포인트는 채널 서비스와 연관된 하나 이상의 기능들에 대한 요청에 대한 응답에 포함되는 URL(Universal Resource Location)일 수 있다. 위에 의해, 유리하게는 당사자의 아이덴티티가 채널에 대한 적어도 하나의 당사자에 의해 PKI 또는 다른 메커니즘들을 사용하여 알려지고 검증될 수 있다.
일부 실시예들에서, 클라이언트에 대한 엔드포인트는 채널의 개개의 엔티티들과 연관된 별칭일 수 있으며, 여기서 별칭은 클라이언트에 특유하고 별칭-기반 어드레싱 서비스에 의해 제공되며, 어드레싱 서비스는 정의되거나 잘 알려진 로케이션으로부터 액세스 가능한 기계 판독 가능 자원을 갖고, 기계 판독 가능 자원은 채널 프로세서와 관련된 하나 이상의 능력들을 포함한다. 별칭은 알려져 있거나 하나 이상의 다른 엔트리들에 제공될 수 있으며, 상기 별칭은 인증을 위한 비대칭 암호화 키 쌍과 연관된다. 위에 의해, 유리하게는 당사자들의 아이덴티티가 알려지고 당사자들 둘 모두에 의해 PKI 또는 다른 메커니즘들을 사용하여 검증될 수 있다. 하나 이상의 클라이언트들 엔티티들에 대해 복잡한 공개 어드레스 대신 기억하기 쉽고 사용자 친화적인 별칭이 사용되는 메커니즘들이 이미 존재한다. 이러한 솔루션은 nChain Holdings Limited의 이름으로 미국 특허 출원 번호 제16/384696호에서 제안된다. 이 문서들은 bsvalias 지불 서비스로서 지칭되는 별칭-기반 지불 서비스 및 연관된 프로토콜들을 제시하며, 여기서 별칭은 클라이언트 엔티티의 공개 어드레스 대신 목적지 어드레싱을 위해 사용된다. 이러한 시스템의 별칭은 일반적으로 전송/수신 클라이언트 엔티티의 도메인 이름과 연관되고 URI 또는 이메일 어드레스일 수 있다. 따라서 전송자 또는 엔티티가 별칭을 인식하거나 그에 별칭이 제공되는 한, 이는 bsvalias 지불 시스템 또는 다른 별칭 기반 어드레싱 메커니즘에 대해 충분하다. 메시지들은 예컨대, bsvalias 또는 다른 지불 서비스를 위해 잘 알려진 URI 또는 로케이션에 저장된, JSON(JavaScript Object Notation) 문서와 같은 기계 판독 가능 자원에 제공된 명령들을 사용하여 클라이언트의 별칭에 전송될 수 있다.
제4 양상의 제4 구현에서, 본 개시는 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법을 제공하며, 이 방법은 채굴자와 연관된 하나 이상의 프로세서들에 의해 구현된다. 제4 구현은 제1 구현과 유사하며 유사한 이점들과 연관된다.
이 구현에서, 채굴자는 지불 프로세서로부터 블록체인으로의 트랜잭션의 제출에 대한 요청을 수신한다. 일부 실시예들에서, 이는 클라이언트를 대신하여 트랜잭션을 제출하라는, 제3 양상에서 논의된 바와 같은 지불 프로세서로부터의 제2 요청과 유사할 수 있다.
그 후, 방법은 요청에 대응하는 블록체인 트랜잭션을 생성하고 블록체인 트랜잭션과 연관된 출력 스크립트(UTXO)를 갖는 응답을 지불 프로세서에 전송하는 단계를 포함한다. 출력 스크립트는 대응하는 블록체인 트랜잭션과 연관된 트랜잭션 식별자(TxID)를 포함한다. 위에서 언급된 바와 같이, 채굴자와 연관된 액세스 포인트 또는 식별자는 또한, 응답으로 클라이언트에 제공될 수 있다.
그 후 TxID에 대한 클라이언트 특유의 채널에 대한 액세스가 수신된다. 이 액세스는 채널이 생성된 후 클라이언트에 의해 직접 제공될 수 있거나, 클라이언트를 대신하여 지불 프로세서에 의해 제공될 수 있다. 앞서 언급된 바와 같이, 이 채널은 주어진 클라이언트와의 직접 통신을 가능하게 한다. 데이터를 기록하기 위해 채널에 액세스하기 위한 액세스 토큰들이 또한 수신된다.
액세스 토큰에 기초하여, 채굴자는 그 후 채널의 콜-백 알림과 연관된 데이터를 제공하기 위한 메시지 기능들 또는 메시지 API들을 획득하거나, 액세스하거나 또는 검색할 수 있으며, 이 데이터는 대응하는 블록체인 트랜잭션(TxID)과 관련된다. 위에서 언급된 바와 같이, 콜-백 알림은 주어진 트랜잭션들에 대한 머클 증명 또는 이중 소비 알림과 관련될 수 있으며, 이는 채널을 통해 클라이언트에게 직접, 안전하게, 정확하게, 그리고 비동기적으로 전달될 수 있다.
따라서 이 제4 구현에서, 채널 또는 메시지 API 및/또는 채널과 연관된 평가 토큰은 클라이언트와의 직접 통신을 가능하게 하도록 채굴자에 의해 획득될 수 있다. 이는 다수의 블록체인 연관 애플리케이션들에 대해 특히 유리할 수 있는데, 그 이유는 채굴자가 추후에, 블록체인에 제출된 트랜잭션 특유의 머클 트리 포함 증명 또는 임의의 다른 메시지를 클라이언트에게 직접 전송하기 위해 채널을 사용할 수 있기 때문이다. 이는 클라이언트 이를테면, 판매자 또는 다른 엔티티 이를테면, 고객 또는 실제로 지불 서비스가 그러한 트랜잭션을 찾거나 그의 상태를 검증하기 위해 블록체인을 검색해야 할 필요가 더 이상 없다는 것을 의미하기 때문에 유용하다. 이는 유리하게는 일단 채굴되면, 포함 증명이 채널을 사용하여 클라이언트에 직접 전송될 수 있기 때문이다. 또는, 어떤 이유로 TxID와 연관된 트랜잭션이 채굴되지 않은 경우, 오류 알림 또는 이중 소비 알림과 같은 메시지가 트랜잭션에 대해 채널을 통해 전송될 수 있다.
본 개시는 또한 컴퓨팅 무선 통신 네트워크를 통해 적어도 하나의 클라이언트 및 적어도 하나의 채굴자에 통신 가능하게 커플링된 지불 프로세서를 포함하는 컴퓨터 시스템을 제공하며, 지불 프로세서는 클라이언트로부터의 HTTPS 요청들을 채굴자들에 대한 RPC 요청들로 또는 그 반대로 변환하기 위한 API 변환기와 연관되고, 지불 프로세서는 제1 양상에 따라 구현된다. 컴퓨터 시스템은 또한 무선 통신 네트워크를 통해 지불 프로세서에 통신 가능하게 커플링되고 적어도 하나의 고객과 통신할 수 있는 클라이언트를 포함하며, 클라이언트는 제2 양상의 컴퓨팅 디바이스에 따라 구현된다. 클라이언트는 또한 무선 통신 네트워크를 통해 채널 프로세서에 통신 가능하게 커플링되며, 이에 의해 채널 프로세서는 제4 양상의 컴퓨팅 디바이스에 따라 구현된다. 컴퓨터 시스템은 또한 복수의 채굴자들을 포함하고, 각각의 채굴자는 무선 통신 네트워크를 통해 지불 프로세서에 통신 가능하게 커플링되며, 각각의 채굴자는 제3 양상에 따라 구현된다.
일부 실시예들에서, 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스가 제공되며, 이 메모리는 프로세서에 의한 실행의 결과로서 디바이스로 하여금, 위에서 논의된 양상들 및/또는 실시예들을 수행하게 하는 실행 가능한 명령들을 포함한다.
일부 실시예들에서, 실행 가능한 명령들이 저장되어 있는 컴퓨터-판독 가능 저장 매체가 제공되며, 이 명령들은 컴퓨터 시스템의 프로세서에 의해 실행된 결과로서, 컴퓨터 시스템으로 하여금, 위에서 논의된 양상들 및/또는 실시예들의 방법을 수행하게 한다.
일부 특정 실시예들은 이제, 유사한 참조 번호들이 유사한 특징들을 지칭하는 첨부 도면들을 참조하여 예시의 방식으로 설명된다.
제1 양상 ― 지불 프로세서
도 1은 본 개시의 제1 양상과 관련되고, 위에서 논의된 바와 같이 클라이언트에 대한 지불 서비스를 구현하기 위해 지불 프로세서에 의해 수행되는 방법을 도시한다. 지불 프로세서는 클라이언트 또는 복수의 클라이언트들에 통신 가능하게 커플링되고, 하나 초과의 채굴자들의 네트워크들 또는 하나 초과의 채굴 풀을 포함할 수 있는 복수의 채굴자들에 또한 커플링된다. 일부 실시예들에서, 지불 프로세서는 클라이언트와 관련하여 구현되거나 그의 부분일 수 있다. 이는 클라이언트가 계산적으로 정교한 판매자 POS(point of sale) 단말인 경우에 해당된다. 본 개시의 양상들 및 실시예들은 이러한 구현들 둘 모두, 즉 원격 지불 프로세서 또는 클라이언트의 부분인 것을 커버하는 것으로 구상된다. 예시적인 시스템 아키텍처는 본원에서 추후에 설명되는 도 4에서 보여진다.
도 1에 도시된 예시적인 시나리오에서, 복수의 채굴 수수료 견적들을 획득하는 단계, 획득된 복수의 채굴 수수료 견적들 중에서 선택된 수수료 견적에 기초하여 트랜잭션을 제출하는 단계뿐만 아니라 트랜잭션 식별자와 관련된 상태 질의를 전송하는 단계들과 관련된 실시예들은 모두 순차적으로 발생하는 것으로 설명되고 도 1의 흐름도에서 단일 프로세스로서 설명된다. 그러나, 본 개시 및 제1 양상은 그러한 것으로 제한되는 것으로 간주되지 않는다. 아래에 설명되는 단계들(102 내지 106)의 제1 요청에서 수수료 견적들을 획득하는 것과 관련된 단계들은 나머지 단계들과 별개로 그리고 그와 독립적으로 구현될 수 있다. 유사하게, 단계들 108로부터 114까지의 제2 요청에서 트랜잭션을 제출하는 것과 관련된 단계들은 수수료 견적들을 획득하는 이전 단계들과 별개로 그리고 상이한 시간에 구현될 수 있다. 동일한 방식으로, 단계(116) 이후의 트랜잭션 상태 문의와 관련된 단계들은 클라이언트가 트랜잭션의 식별자를 알게 된 후 임의의 시간에 구현될 수 있으며 도 1의 순서를 따를 필요가 없다. 모든 단계들은 단순히 설명 및 이해의 편의를 위해 여기에서 순차적으로 도시되며 어떠한 상황에서도 본 개시가 이러한 시퀀스 또는 시나리오로 제한되는 것으로 간주되지 않는다.
단계(102)는 블록체인에서 트랜잭션의 채굴과 연관된 채굴 수수료 견적들에 대해 클라이언트로부터 제1 요청을 수신하는 것을 도시한다. 제1 요청은 또한 복수의 트랜잭션들과 관련될 수 있다. 설명 및 이해의 편의를 위해, 도 1은 클라이언트와 연관된 제1 요청의 단일 트랜잭션과 관련하여 설명될 것이지만, 본 개시는 어떠한 방식으로도 그러한 것으로 제한되지 않는다. 이 단계는 클라이언트를 대신하여 트랜잭션의 채굴에 대해 복수의 채굴자들로부터 채굴 수수료 견적들을 수집하는 것을 의미한다. 트랜잭션은 일반적으로 클라이언트, 즉 판매자 컴퓨팅 자원 또는 엔티티와 고객 엔티티 사이에서 발생하는 디지털 자산 지불과 관련된다. 위에서 언급된 바와 같이, 제1 요청은 HTTPS 프로토콜을 통해 또는 이를 사용하여 그리고 클라이언트로부터 JSON 포맷으로 수신된다. 지불 프로세서는 클라이언트에 대한 API(application programming interface)로서 지불 인터페이스를 구현하고, 이에 따라 API가 웹 서비스로서 구현되기 때문에 HTTPS를 수락하고 프로세싱할 수 있다. API 엔드포인트는 클라이언트에 대해 이용 가능하게 된다. 제1 요청에 다수의 트랜잭션들이 있는 경우에, 동일한 API 엔드포인트 또는 지불 프로세서에 대한 별개의 API 엔드포인트가 사용될 수 있다.
예컨대, 일부 실시예들에서, 지불 프로세서는 REST 인터페이스와 같은 표준-기반 인터페이스 설계를 사용하여 지불 서비스를 구현할 수 있다. REST(Representational State Transfer)는 웹 서비스 및 웹-기반 상호작용들을 개발하기 위한 아키텍처 스타일이다. REST API 설계 표준들은 다음 커맨드들을 사용하여 HTTPS 요청들 및 통신을 프로세싱할 수 있다:
커맨드들 GET POST PUT DELETE
자원 판독 생성 업데이트 삭제
GET 및 POST HTTPS 요청들은 본원에서 주로 논의되지만, 애플리케이션은 이러한 커맨드들로 제한되지 않는다. 이 단계(102)에서, 지불 프로세서에 의해 수신되는 제1 요청은 GET getFeeQuote 형태의 HTTPS 요청일 수 있다.
REST API 맥락의 자원은 유형, 연관된 데이터, 다른 자원들에 대한 관계들 및 그 자원 상에서 동작하는 일 세트의 메서드들을 갖는 오브젝트이다. 일부 실시예들에서, 지불 서비스는 비트코인 SV(BSV) 블록체인과 같은 블록체인 또는 분산 원장의 상태에 액세스하고 애플리케이션 인터페이스를 통해 그 상태를 변경하고 이를 REST API로서 노출할 수 있는 동작들을 트리거하기 위한 API 구현으로서 지불 프로세서에 의해 제공된다. 따라서 지불 프로세서는 하나 이상의 클라이언트들에 대한 REST 엔드포인트로서 간주될 수 있다. 설명의 편의만을 위해, 하나의 클라이언트(또는 판매자) 및 하나의 지불 프로세서가 전반에 걸쳐 논의될 것이지만, 본 개시는 그러한 것으로 제한되지 않는다. 따라서 클라이언트는 유리하게는, HTTPS를 통해 지불 서비스와 통신할 수 있고, 클라이언트는 또한, 지불 프로세서 또는 지불 프로세서에 의해 구현되는 지불 서비스에 대한 익명 액세스를 가질 수 있다. 하나 초과의 클라이언트 및 하나 초과의 지불 프로세서가 존재할 때, 일부 실시예들에서, 클라이언트는 예컨대, 지불 프로세서를 실행하는 하나 이상의 제3자들과 클라이언트가 맺은 임의의 동의에 기초하여 올바른 또는 의도된 지불 프로세서 또는 REST 엔드포인트와 접촉하거나 이를 타겟팅하는 것을 담당할 것이다.
단계(104)는 트랜잭션의 채굴에 대해 복수의 채굴자들 중 각각의 채굴자로부터 수수료 견적을 획득하는 것을 도시한다. 이 단계에서, 지불 프로세서에 커플링된 모든 채굴자들은 지불 프로세서에 의해 접촉되거나 폴링되고, 트랜잭션의 채굴에 대한 현재 수수료 견적을 반환하도록 즉, 잠금 및 잠금해제 스크립트를 유효성 검증한 후 블록체인에 트랜잭션을 기록하도록 요청받을 수 있다. 현재, BSV 네트워크와 같은 일부 블록체인 네트워크들은 RPC(Remote Procedure Call)들을 통한 통신을 지원한다. 따라서 이 경우에, 지불 프로세서와 연관된 API 변환기는 HTTPS 제1 요청 즉, GET getFeeQuote을 RPC 제1 요청 즉, RPC getFeeQuote()으로 또는 그 반대로 변환하는 데 사용된다. 이러한 변환은 이러한 BSV 노드 구현들 또는 RPC들만을 지원하는 다른 구현들을 지원할 필요가 있는 실시예들에서 필수적이다. 위에서 언급된 바와 같이, API 변환기는 API 게이트웨이 또는 지불 프로세서와 연관된 게이트웨이 프로세서의 부분일 수 있으며, 여기서 HTTP/RPC 변환은 API 게이트웨이에 의해 제공되는 기능성들 중 하나일 뿐이다. 채굴자들에게 전송되는 RPC 포맷의 getFeeQuote()의 목적은 각각의 채굴자에 의해 과금되는 수수료들을 클라이언트에게 알리는 것이다. 어떠한 입력 파라미터들도 요구되지 않지만, RPC 인터페이스가 RPC getFeeQuote()와 관련하여 구현될 필요가 있을 수 있어서, 이 커맨드는 각각의 채굴자로부터 수집된 수수료-관련 데이터를 포함하는 JSON(JavaScript Object Notation) 오브젝트, 즉 MinerFeeQuote의 형태로 각각의 채굴자로부터의 데이터 유형을 반환한다.
각각의 채굴자로부터 수집된 획득된 수수료 견적들과 관련된 데이터는 아래 예들에서 주어진 바와 같이 JSON 오브젝트들로서 정의될 수 있다.
각각의 채굴자로부터 반환된 JSON 오브젝트 FeeQuotes는 아래에서 보여진다. 단일 트랜잭션들과 관련된 예들이 보여지지만, 본 개시는 그러한 것으로 제한되지 않으며 다수의 트랜잭션들에 대한 채굴 수수료들을 표현하는 수수료 견적들에 대해 동일하게 적용된다.
Figure pct00001
Figure pct00002
Figure pct00003
Figure pct00004
데이터 아이템들로 채워진 위의 JSON object FeeQuotes의 다른 예가 또한 이해의 편의를 위해 아래에 제공된다:
Figure pct00005
Figure pct00006
일부 실시예들에서, JSON FeeQuotes 오브젝트는 채굴자 세부사항들 및 과금된 수수료의 어레이를 포함하는 반면 MinerFeeQuote는 단일 채굴자로부터 수신된 수수료 데이터 및 채굴자를 포함하는 JSON 구조이다. 위의 JSON 오브젝트의 용어들 중 일부는 아래에서 설명된다.
CurrentHighestBlockHash는 getFeeQuote()가 호출되었을 때 블록체인이 성장한 지점에서 블록 해시를 식별하기 위한 마커로서 사용될 수 있다.
MinerSignature는 위에서 논의한 바와 같이 이 트랜잭션을 보증(guarantee)하기로 동의한 채굴자의 서명을 포함할 수 있다. 이는 채굴자의 아이덴티티를 검증하는 데 사용되는 디지털 서명과 상이하다. 이를 통해, 채굴자는 채굴자가 곧 블록에 트랜잭션을 포함시킬 것이고 선택적으로 임의의 충돌하는 트랜잭션들을 포함시키지 않을 것임을 보증할 수 있다. 채굴자가 트랜잭션을 보증할 의향이 없는 경우, 이는 Null로 세팅될 수 있다.
SignatureTimestamp는 명시된 현재 수수료로 트랜잭션의 채굴에 대해 채굴자가 보증하는 시간을 표시하는데 즉 수수료는 그 지점부터 대체될 때까지 보증된다. 이 시간은 클라이언트가 getFeeQuote()에 대한 후속 호출을 행하는 경우 대체된다.
MinerReputation은 채굴자의 성과 즉, 채굴자가 약속된 또는 견적된 현재 수수료로 트랜잭션들을 얼마나 잘 실행하는지에 관한 측정과 관련된다. 평판 점수/표시자는 각각의 지불 프로세서에 의해 계산, 유지 및 관리될 수 있다.
채굴자 ID는 블록이 채굴될 때 코인베이스(Coinbase) 트랜잭션에 추가되는 2-부분 데이텀(two-part datum)일 수 있다. 어떠한 채굴자 ID도 없는 경우, 지불 프로세서는 그 채굴자를 "NULL"의 채굴자 ID로 태깅하거나 단순히 블랭크로 남겨둘 수 있다.
각각의 MinerFeeQuote 내에서, FeeTypes 오브젝트들의 어레이는 현재 사용 가능한 다양한 수수료 유형들을 캡처하는데 사용될 수 있다. 수수료 유형들은 지불 프로세서에 의해 제공되는 getFeeQuote() 인터페이스에 대한 어떠한 변경도 요구됨 없이 향후에 도입될 수 있다. 모든 트랜잭션들은 하나의 FeeType 어레이를 가질 수 있다.
단계(106)는 지불 프로세서에 의해 클라이언트에게 획득된 수수료 견적을 제공하는 것을 도시한다. 이는 일부 실시예들에서, 지불 프로세서에 의해 결정된 권고 수수료 견적을 포함할 수 있다. 제1 양상과 관련하여 위에서 언급된 바와 같이, 이 단계는 API 변환기에 의한 RPC로부터 HTTPS로의 변환을 포함할 수 있어서, 클라이언트는 웹-기반 API를 사용하여 세부사항들에 액세스할 수 있게 될 것이다.
단계(108)에서, 제2 요청은 클라이언트로부터 수신되며, 제2 요청은 획득된 수수료 견적들 중 선택된 수수료 견적과 관련된 주어진 트랜잭션을 제출하라는 요청이다. 일부 실시예들에서, 주어진 트랜잭션은 클라이언트로부터의 지불 요청에 대한 응답으로 고객에 의해 클라이언트에게 행해진 디지털 자산 지불에 기초한다. 예컨대, 이는 클라이언트가 커피숍의 판매자 단말인 경우 커피 한 잔에 대한 대가로 사토시 또는 다른 유형들의 디지털 자산 지불이 될 수 있다. 이 단계에서, 클라이언트는 지불 프로세서에 의해 구현되는 지불 서비스 API를 통해 이 디지털 자산 지불이 블록체인에 기록되도록 요청한다.
위에서 언급된 바와 같이, 클라이언트로부터의 제2 요청은 일부 실시예들에서, 다수의 트랜잭션들을 제출하라는 요청일 수 있다.
제2 트랜잭션에서 선택된 수수료 견적은 지불 프로세서에 의해 이루어진 권고에 기초할 수 있거나 하나 이상의 트랜잭션들에 대해 클라이언트에 의해 선택될 수 있다.
위에서 언급된 바와 같이, 선택된 견적은 모든 획득된 수수료 견적들의 평균값 또는 최대 값에 기초할 수 있다.
일부 실시예들에서, 제2 요청은 POST submitTransaction(Tx) 형태의 HTTPS 요청이며, 여기서 Tx는 일부 실시예들에서, 클라이언트와 고객 간의 지불을 위해 주어진 트랜잭션과 연관된 JSON 포맷의 오브젝트이다. 따라서 Tx(JSON 오브젝트)는 채굴자들에게 전달하도록 지불 프로세서에 제2 요청을 제출하기 전에 클라이언트가 JSON 구조로서 제공하거나 구성할 수 있는 트랜잭션을 블록체인 상에서 생성하는 데 요구되는 데이터를 포함한다.
단계(110)는 단계(108)에서 주어진 트랜잭션에 대응하는 블록체인 트랜잭션을 생성하기 위해 복수의 채굴자들 중 하나 이상의 채굴자들에게 요청을 전송하는 단계를 도시한다. 이 단계에서, 일부 실시예들의 지불 프로세서는 이전 단계의 HTTPS POST 요청을 채굴자들에게 제출하기 위한 RPC 요청으로 변환한다. 이는 RPC createRawTransaction(Tx) 요청으로 행해질 수 있으며, 여기서 Tx는 단계(108)에서 논의된 바와 같은 JSON 오브젝트로 제공된 주어진 트랜잭션과 연관된 데이터를 포함한다. RPC createRawTransaction(Tx)은 주어진 입력들을 소비하고 새로운 출력들을 생성하는 트랜잭션을 생성하기 위한 RPC 호출이며, 여기서 출력들은 어드레스 또는 데이터일 수 있다. RPC 요청은 복수의 채굴자들에게, 또는 단계(108)에서 클라이언트로부터 선택된 수수료 견적을 충족시키거나 만족시키는 채굴자들에게 전송될 수 있다. 위에서 언급된 바와 같이, 선택된 수수료 견적의 또는 그 이하의 현재 수수료 견적들을 제공한 채굴자들은 이들이 각자의 현재 견적 수수료로 트랜잭션을 채굴할 수 있으므로 선택된 수수료 견적의 요건들을 만족시키는 것으로 간주된다. 이에 응답하여, 선택된 수수료 견적을 만족시키는 채굴자는 주어진 트랜잭션에 대응하는 블록체인 트랜잭션을 생성한다. 일부 실시예들에서, 주어진 트랜잭션에 대응하는 16진법-인코딩된(hex-encoded) 원시 트랜잭션이 지불 프로세서에 반환된다.
단계(112)에서, 복수의 채굴자들 중, 선택된 수수료 견적을 만족시키는 적어도 하나의 채굴자에 의해 생성된 대응하는 블록체인 트랜잭션과 연관된 출력 또는 출력 스크립트가 지불 프로세서에서 수신된다. 출력 스크립트는 개개의 채굴자에 의해 생성된 대응하는 블록체인 트랜잭션과 연관된 UTXO일 수 있다. 일부 실시예들에서, UTXO는 또한 선택된 수수료 견적을 만족시키는 개개의 채굴자의 멤풀에 저장될 수 있다. 이 단계의 출력은 개개의 채굴자에 의해 생성된 대응하는 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 포함할 것이다. TxID는 채굴자의 멤풀에 제출된 16진법-인코딩된 트랜잭션에 대한 참조이며, 이는 그 후 지불 프로세서에 의해 블록체인 트랜잭션에 상응하게 매핑된다.
그 후, 이 블록체인 트랜잭션은 현재 수수료 견적에서 채굴 프로세스를 완료하기 위해 순시적으로 또는 추후의 시간에 채굴될 수 있다. 일부 경우들에서, 생성된 트랜잭션은 다른 채굴자가 그것을 블록체인에 기록했기 때문에 채굴되지 않거나, 또는 이중 소비 또는 시간 경과 또는 무효와 같은 일부 이유로 보류 또는 거부될 수 있다.
단계(114)는 트랜잭션 결과(TxResult)를 클라이언트에 전송하는 것을 보여주며, 이 결과는 개개의 채굴자에 의해 단계(108)에서 주어진 트랜잭션에 대응하여 생성된 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 포함한다. 일부 실시예들에서, 트랜잭션 결과(TxResult)는 단계들(110 및 112)에서 선택된 수수료 견적을 만족시키는 개개의 채굴자에 의해 생성된 대응하는 블록체인 트랜잭션의 세부사항들에 기초하여, HTTPS 프로토콜을 사용하여 지불 프로세서로부터 클라이언트에 전송되는 JSON 오브젝트이다.
클라이언트에 대한 TxResult 오브젝트에 존재하는 세부사항들의 예는 다음과 같이 주어진다:
JSON 오브젝트(TxResult)는 개개의 채굴자에 대해 아래에 보여지며, 단계(104)에서 FeeQuotes JSON 오브젝트의 부분으로서 논의된 일부 용어들 및 오브젝트들을 포함한다.
Figure pct00007
위에 제시된 ReturnResult는 다음과 같은 다음의 가능한 값들 중 하나를 포함할 수 있다:
· Submitted ― 이슈 없음, 트랜잭션이 멤풀에 제출됨
· Rejected_DS ― 이중 소비로 인해 거부됨 ― DoubleSpendTxID는 Null일 수 없음
· Rejected_Policy ― 정책 위반들로 인해 거부됨
· Rejected_Invalid ― 유효하지 않은 트랜잭션으로 인해 거부됨
· Rejected_FeeTooLow ― 수수료가 너무 낮아서, 채굴자가 블록에 Tx를 포함시키지 않을 것임
· Rejected_KeepInMemPool ― Tx는 거부되었지만 이중 소비들을 확인하기 위해 멤풀에서 유지됨
단계(116)는 복수의 채굴자들에 대한 전송에 대해 클라이언트로부터 트랜잭션 식별자(TxID)와 연관된 상태 질의를 수신하는 단계를 보여준다. 이 단계 이후는 복수의 채굴 수수료 견적들 중에서 수수료 견적을 선택한 후 트랜잭션을 제출하도록 준비하는 위의 단계들과 비동기적으로 발생할 수 있으며 제1 양상의 동작에 필수적인 것으로 간주되지 않는다. 단계(116) 이후의 실시예들은 클라이언트가 단계(108)에서 이루어진 하나 이상의 제2 요청들의 상태를 알고자 하는 시나리오와 관련된다.
단계(116)는 클라이언트가 단계(108)에서 논의된 HTTPS POST submitTransaction(Tx)을 통해 지불 프로세서에 제출한 트랜잭션들의 상태를 클라이언트가 질의하는 것을 가능하게 한다. 따라서, 이 단계의 TxID는 클라이언트와 그의 고객들 간의 디지털 자산 지불과 관련된 임의의 주어진 트랜잭션에 대해 이루어진 임의의 제2 요청에 대응할 수 있다. 위의 단계들에서 논의한 바와 같이, 상태 질의는 송신 프로토콜로서 HTTPS를 사용하여 클라이언트로부터 수신되고, 이 질의는 GET queryTransactionStatus(TxID)와 같은 JSON 포맷으로 전송되며 이는 차례로, 복수의 채굴자들 중 하나 이상의 채굴자들에게 전송하기 위한 RPC 요청인 RPC getRawTransaction(TxID)으로 변환된다.
단계(118)에서, 지불 프로세서는 TxID와 연관된 블록체인 트랜잭션을 생성하고 그리고/또는 프로세싱하는 것과 연관되는, 복수의 채굴자들 중 개개의 채굴자로부터 응답을 수신한다. 일부 실시예들에서, 위의 RPC getRawTransaction(TxID)은 1로 세팅된 인수와 관련될 수 있는 Verbose 파라미터를 포함할 수 있다. 이 경우에, 성공적인 경우, 개개의 채굴자로부터의 반환된 결과는 일부 실시예들에서, 단계(110 및 112)에서 디코딩된 대응하는 블록체인 트랜잭션을 포함하는 JSON 포맷일 것이다. 이는 유리하게는, 데이터를 캡처하고 그 내부의 데이터를 프로세싱하는 유연성을 제공한다. Verbose 파라미터가 0으로 세팅된 경우, JSON 데이터 유형 또는 문서 포맷 대신, 16진법-인코딩된 트랜잭션이 지불 프로세서에 반환된다. TxID와 관련된 트랜잭션이 발견되지 않는 경우, Null이 반환될 수 있으며, 이는 차례로 ReturnResult 오브젝트가 'Unknown'으로 세팅되게 할 것이다. 임의의 다른 반환된 오류는 또한 ReturnResult 및 ResultDescription 오브젝트들을 통해 채굴자에 의해 지불 프로세서에 보고될 수 있다. 이러한 오브젝트들은 단계(114)와 관련하여 표시되었다.
단계(120)에서, TxID와 관련된 TxResult가 클라이언트에 반환되고, 응답은 HTTPS를 사용하여 전송된다. 이는 단계(116)의 상태 질의에서 클라이언트에 의해 전송된 주어진 TxID와 연관되는 채굴 결과를 표현한다. 지불 프로세서로부터 클라이언트로 전송된 TxResult의 예는 아래에서 주어진다.
JSON 오브젝트 TxStatus는 아래에서 보여진다.
Figure pct00008
트랜잭션이 성공적으로 채굴되고 개개의 채굴자에 의해 컨펌(Confirmed)(즉, 블록에 추가)된 것으로 플래깅된 경우, BlockHash 및 MinerID가 채워질 수 있다. 채굴자가 자신의 MinerID를 설정하지 않은 경우, 이는 "NULL"로 세팅될 것이다.
그 후 ReturnResult 오브젝트는 다음의 채굴 결과들 중 하나를 포함할 수 있다:
· Submitted ― 이슈 없음, 트랜잭션이 멤풀에 제출됨
· Confirmed ― 트랜잭션 컨펌됨 ― 컨펌(Confirmation)들은 0 또는 Null일 수 없음
· Rejected_DS ― 이중 소비로 인해 거부됨 ― DoubleSpendTxID는 Null일 수 없음
· Rejected_Policy ― 정책 위반들로 인해 거부됨
· Rejected_Invalid ― 유효하지 않은 트랜잭션으로 인해 거부됨
· Rejected_FeeTooLow ― 수수료가 너무 낮아서, 채굴자가 블록에 그 Tx를 포함시키지 않을 것임
· Rejected_KeepInMemPool ― Tx는 거부되었지만 이중 소비들을 확인하기 위해 멤풀에서 유지됨
· Unknown ― 트랜잭션이 보이지 않거나 존재하지 않음 ― 이는 TxID가 제공된 트랜잭션이 멤풀 또는 블록체인에 존재하지 않는다는 것일 수 있다. 만약 그렇다면, 이는 ResultDescription에서 명시되어야 한다.
제2 양상 ― 클라이언트
도 2는 본 개시의 제2 양상과 관련되고 클라이언트와 연관된 하나 이상의 프로세서들에 의해 수행되는 방법을 도시하며, 여기서 클라이언트는 제1 양상과 관련하여 논의된 바와 같은 방법을 구현하는 적어도 하나의 지불 프로세서에 통신 가능하게 커플링된다. 지불 프로세서는 위에서 논의된 바와 같이 클라이언트에 대해 도 1과 관련하여 논의된 지불 서비스 또는 지불 API를 구현한다.
도 2에 도시된 예시적인 시나리오에서, 복수의 채굴 수수료 견적들을 획득하는 단계, 획득된 복수의 채굴 수수료 견적들 중에서 선택된 수수료 견적에 기초하여 트랜잭션을 제출하는 단계뿐만 아니라 트랜잭션 식별자와 관련된 상태 질의를 전송하는 단계들과 관련된 실시예들은 모두 순차적으로 발생하는 것으로 설명되는데 즉, 도 2의 흐름도에서 단일 프로세스로서 설명된다. 그러나, 본 개시 및 제2 양상은 그러한 것으로 제한되는 것으로 간주되지 않는다. 단계들(202 내지 206)의 제1 요청에서 수수료 견적들을 획득하는 것과 관하여 아래에 설명되는 단계들은 나머지 단계들과 별개로 그리고 그와 독립적으로 구현될 수 있다. 유사하게, 단계들 208로부터 212까지의 제2 요청에서 트랜잭션을 제출하는 것과 관련된 단계들은 수수료 견적들을 획득하는 이전 단계들과 별개로 그리고 상이한 시간에 구현될 수 있다. 동일한 방식으로, 단계(214) 이후의 트랜잭션 상태 문의와 관련된 단계들은 클라이언트가 트랜잭션의 식별자를 알게 된 후 임의의 시간에 구현될 수 있으며 도 2의 순서를 따를 필요가 없다. 모든 단계들은 단순히 설명 및 이해의 편의를 위해 여기에서 순차적으로 도시되며 어떠한 상황에서도 본 개시가 이러한 시퀀스 또는 시나리오로 제한되는 것으로 간주되지 않는다. 또한, 도 1과 관련하여 위에서 논의한 바와 같이, 수수료 견적들은, 단일 요청에서, 클라이언트에 의해 제출되는 다수의 트랜잭션들의 세트 또는 배치에 대해 즉, 동시에 또는 매번 개별적으로 단일 트랜잭션에 대해 요청되고 그리고/또는 획득되고 그리고/또는 제출되고 그리고/또는 질의될 수 있다. 설명 및 이해의 편의를 위해, 도 2는 제1 요청/제2 요청에서의 단일 트랜잭션 및 클라이언트와 연관된 상태 질의와 관련하여 설명될 것이지만, 본 개시는 어떠한 방식으로도 그러한 것으로 제한되지 않는다.
단계(202)는 개개의 지불 서비스를 제공하기 위해 클라이언트와 연관된 적어도 하나의 지불 프로세서들 중의 지불 프로세서에 제1 요청을 전송하는 것을 보여준다. 도 1의 단계(102)와 관련하여 논의된 바와 같이, 요청은 클라이언트에 대한 트랜잭션의 채굴에 대한 하나 이상의 수수료 견적들과 관련된다. 이 제1 요청은 단계(102)와 관련하여 논의된 HTTPS GET getFeeQuote와 관련된다. 위에서 논의된 바와 같이, 요청은 클라이언트에 대한 임의의 트랜잭션을 채굴하기 위한 것일 수 있거나 클라이언트와 연관된 고객으로부터 디지털 자산 지불과 관련된 트랜잭션의 채굴에 대한 수수료 견적을 얻기 위한 요청일 수 있다.
단계(204)에서, 복수의 채굴 수수료 견적들이 지불 프로세서로부터 수신되고, 이 수수료 견적들은 클라이언트를 서빙하는 지불 프로세서에 통신 가능하게 커플링된 복수의 채굴자들 각각에 대한 채굴 수수료들과 관련된다. 수신된 수수료 견적들의 구조 및 세부사항들은 도 1의 단계(104)와 관련하여 이미 논의되었다.
단계(206)는 단계(204)에서 수신된 하나 이상의 수수료 견적들 중에서 수수료 견적을 선택하는 것을 보여준다. 일부 실시예들에서, 선택된 수수료 견적은 지불 프로세서에 의해 제안된 권고 수수료 견적에 기초할 수 있다. 일부 실시예들에서, 선택은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 이루어진다. 선택된 수수료 견적은 위에서 논의된 바와 같이, 획득된 수수료 견적들의 평균 또는 중앙값, 또는 복수의 채굴자들로부터의 획득된 수수료 견적들의 최대 값 또는 2차 멤풀에서 가장 높은 수수료 견적일 수 있다. 따라서 클라이언트는 제1 요청에 대한 응답으로 복수의 채굴자들로부터 획득된 가장 높은 수수료 값을 선택할 수 있다. 이러한 방식으로, 모든 채굴자들에게는 각자의 현재 견적 수수료로 그 트랜잭션들을 채굴할 동등한 기회가 제공될 수 있다. 그러나 클라이언트는 수신된 모든 수수료 견적들의 중앙값 또는 평균 이상인 수수료 견적을 대신 선택할 수 있어서, 더 높은 견적들을 가진 채굴자들은 단순히 그 트랜잭션을 2차 멤풀에서 유지하고 이를 사용하여 트랜잭션들의 임의의 이중 소비들을 체크 및/또는 거부할 수 있다.
단계(208)는 클라이언트와 연관된 고객으로부터 디지털 자산 지불을 요청 및/또는 프로세싱하는 단계를 보여준다. 이는 양 당사자들에 대한 개개의 디지털 지갑 구현들에 적용된 알려진 방법들을 사용하여 디지털 자산 지불을 위해 클라이언트에 의해 고객에게 전송된 송장 또는 지불 요청일 수 있다. 블록체인으로의 임의의 트랜잭션의 채굴에 대한 선택한 수수료 견적이 이미 알려져 있으므로, 요청은 선택한 수수료 견적과 연관되거나 이를 포함할 수 있다.
단계(210)는 고객으로부터 지불 프로세서로의 디지털 자산 지불과 연관된 주어진 트랜잭션을 블록체인에 제출하라는 제2 요청을 전송하는 단계를 보여준다. 이 단계의 제출은 단계(206)에서 주어진 트랜잭션의 채굴에 대해 선택된 수수료 견적에 기초한다. 이 단계는 주어진 트랜잭션에 대한 JSON 데이터 유형 포맷의 관련된 세부사항과 함께, 클라이언트가 도 1의 단계(108)에서 지불 프로세서에 HTTPS POST submitTransaction(Tx) 요청을 전송하는 것과 관련된다.
단계(212)는 제출된 트랜잭션에 대응하는 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 수신하는 단계를 보여준다. 도 1의 단계들(110 및 112)에서 논의된 바와 같이, TxID는 선택된 수수료 견적을 만족시키는 적어도 하나의 채굴자에 의해 생성된다. 일부 실시예들에서, 이는 트랜잭션 결과, 즉 개개의 채굴자에 대한 대응하는 블록체인 트랜잭션의 현재 채굴 상태를 보여주는 TxResult와 연관되거나 그의 부분으로서 전송될 수 있다. 이는 도 1의 단계(114)와 관련하여 설명된다.
단계(214)는 클라이언트가 클라이언트와 고객 사이의 지불과 관련하여 단계(210)에서 이전에 제출된 트랜잭션의 채굴 상태를 질의하고자 할 때 클라이언트가 상태 질의를 전송하는 것에 관련된다. 클라이언트가 단계(212)에서 제출된 트랜잭션들의 TxID를 수신했기 때문에, 이 요청은 도 1의 단계(116)에서 설명된 바와 같이 TxID 및 포맷 HTTPS GET queryTransactionStatus(TxID)에 기초할 수 있다.
단계(216)는 단계(214)에서 질의된 트랜잭션 식별자(TxID)에 대응하는 블록체인 트랜잭션에 대한 채굴 상태 결과를 획득하는 것을 보여준다. 이는 JSON 포맷일 수 있고 지불 프로세서가 대응하는 트랜잭션의 세부사항들을 수신한 후 지불 프로세서에 의해 HTTPS를 사용하여 클라이언트에 전송된다. 상태 결과는 도 1의 단계(120)에서 보여지는 바와 같이 TxResult JSON 오브젝트의 형태일 수 있다.
제3 양상 ― 채굴자 구현
도 3은 본 개시의 제2 양상과 관련되고 복수의 채굴자들 중의 채굴자에 의해 수행되는 방법을 도시하며, 여기서 복수의 채굴자들은 제1 양상과 관련하여 논의된 바와 같은 방법을 구현하는 적어도 하나의 지불 프로세서에 통신 가능하게 커플링된다. 지불 프로세서는 클라이언트에 대해 도 1과 관련하여 논의된 지불 서비스 또는 지불 API를 구현한다. 클라이언트는 도 2와 관련하여 논의된 방법을 구현하도록 구성된다.
도 3에 도시된 예시적인 시나리오에서, 복수의 채굴 수수료 견적들을 제공하는 단계, 획득된 복수의 채굴 수수료 견적들 중에서 선택된 수수료 견적에 기초하여 블록체인 트랜잭션을 생성(generating/creating)하는 단계뿐만 아니라 블록체인 트랜잭션 식별자와 관련된 채굴 상태를 제공하는 단계들과 관련된 실시예들은 모두 순차적으로 발생하는 것으로 설명되는데 즉, 도 3의 흐름도에서 단일 프로세스로서 설명된다. 그러나, 본 개시 및 제3 양상은 그러한 것으로 제한되는 것으로 간주되지 않는다. 단계들(302 및 304)의 제1 요청에 대한 응답으로 현재 수수료 견적을 제공하는 것과 관련하여 아래에서 설명된 단계들은 나머지 단계들과 별개로 그리고 그와 독립적으로 구현될 수 있다. 유사하게, 단계들 308에서 314까지의 제2 요청에 대한 응답으로 대응하는 블록체인 트랜잭션을 생성하는 것과 관련된 단계들은 수수료 견적들을 획득하는 이전 단계들과 별개로 그리고 상이한 시간에 구현될 수 있다. 동일한 방식으로, 단계(316)에서 트랜잭션 상태를 제공하는 것과 관련된 단계들은 클라이언트가 트랜잭션의 식별자를 알게 된 후 임의의 시간에 구현될 수 있으며 도 3의 순서를 따를 필요가 없다. 모든 단계들은 단순히 설명 및 이해의 편의를 위해 여기에서 순차적으로 도시되며 어떠한 상황에서도 본 개시가 이러한 시퀀스 또는 시나리오로 제한되는 것으로 간주되지 않는다. 또한, 도 1 및 도 2와 관련하여 위에서 논의한 바와 같이, 수수료 견적들은, 단일 요청에서, 클라이언트에 의해 제출되는 다수의 트랜잭션들의 세트 또는 배치에 대해 즉, 동시에 또는 매번 개별적으로 단일 트랜잭션에 대해 요청되고 그리고/또는 획득되고 그리고/또는 제출되고 그리고/또는 질의될 수 있다. 설명 및 이해의 편의를 위해, 도 3은 제1 요청/제2 요청에서의 단일 트랜잭션 및 클라이언트와 연관된 상태 질의와 관련하여 설명될 것이지만, 본 개시는 어떠한 방식으로도 그러한 것으로 제한되지 않는다.
단계(302)는 클라이언트를 대신하여 트랜잭션의 채굴에 대한 수수료 견적을 제공하기 위해 지불 프로세서로부터 제1 요청을 수신하는 것을 보여준다. 이 요청은 도 1의 단계(104)와 관련하여 제시된 바와 같이 지불 프로세서로부터 전송된 RPC getFeeQuote() 요청과 관련된다.
단계(304)는 블록체인에서 트랜잭션을 채굴하기 위해 복수의 채굴자들 중 각각의 채굴자와 관련된 현재 수수료 견적을 제공하는 것을 보여준다. 수수료 견적은 도 1의 단계(104)와 관련하여 제시된 바와 같이 JSON 오브젝트 FeeQuotes의 포맷으로 제공될 수 있다.
단계(306)는, 복수의 채굴자들 중의 채굴자가 클라이언트와 연관된 주어진 트랜잭션을 블록체인에 제출하는 것과 관련된 제2 요청을 수신하는 단계를 보여주며, 여기서 주어진 트랜잭션은 클라이언트로부터 선택된 수수료 견적에 기초한다. 주어진 트랜잭션은 도 2의 단계(210)에서 POST submitTransaction(Tx)의 Tx, 즉 클라이언트와 고객 간의 주어진 디지털 자산 지불 트랜잭션과 관련된다. 지불 프로세서로부터 수신된 이것의 RPC 버전은 도 1의 단계(110)와 관련하여 설명된 바와 같이, 주어진 트랜잭션에 대한 RPC createRawTransaction(Tx)이다.
단계(308)는 채굴자가 클라이언트로부터 선택된 수수료 견적을 충족시키나 만족시키는지 체크하는 것을 보여준다. 이는 단계(304)에서 개개의 채굴자에 의해 지불 프로세서에 제공된 현재 수수료 견적이, 클라이언트가 주어진 트랜잭션(Tx)을 채굴하기 위해 지불할 의향이 있는 선택된 수수료 견적 이하인지 여부에 관한 결정을 포함할 수 있다.
현재 수수료 견적이 선택된 수수료 견적을 만족시키는 경우, 단계(310)에서, 주어진 트랜잭션에 대응하는 블록체인 트랜잭션이 생성된다. 이는 도 1의 단계(110)와 관련하여 논의된다. 일부 실시예들에서, 주어진 트랜잭션에 대응하는 16진법-인코딩된(hex-encoded) 원시 트랜잭션이 지불 프로세서에 반환된다. 출력 스크립트 또는 UTXO는 또한 도 1의 단계(112)에서 논의된 바와 같이 지불 프로세서에 제공되며, 여기서 출력 스크립트는 개개의 채굴자에 의해 생성된 대응하는 블록체인 트랜잭션과 연관된 트랜잭션 식별자(TxID)를 포함한다. 그 후, 블록체인 트랜잭션에 대한 출력 스크립트(UTXO)는 순시적으로 또는 추후의 시간에 채굴을 위해 채굴자와 연관된 멤풀에 추가될 수 있다.
현재 수수료 견적이 선택된 수수료 견적을 만족시키지 않는 경우, 즉 개개의 채굴자의 현재 수수료 견적이 클라이언트에 의해 선택되거나 허용된 것보다 높은 경우, 각각의 채굴자는 일부 실시예들에서, 현재 수수료 견적보다 낮은 수수료의 채굴을 선택할 수 있거나, 또는 선택된 수수료가 각자의 현재 견적된 수수료보다 낮기 때문에 주어진 트랜잭션을 채굴하지 않기로 선택할 수 있다. 개개의 채굴자가 더 낮은 선택된 수수료 견적으로 트랜잭션을 채굴하지 않기로 선택하는 실시예들에서, 단계(312)에서, 개개의 채굴자는 개개의 채굴자와 연관된 2차 메모리 풀에 주어진 트랜잭션에 대해 구성된 블록체인 트랜잭션과 관련하여 세부사항들을 대신 추가할 수 있다. 이 트랜잭션은 일부 실시예들에서, 2차 멤풀에 홀딩되고 이중 소비들을 체크하는 데 사용될 수 있다. 2차 멤풀에 저장된 모든 트랜잭션들은 만료 시간을 가질 수 있으며, 그 이후 이 트랜잭션들은 제거될 수 있다.
블록체인 트랜잭션이 생성되었다고 가정하면, 즉 개개의 채굴자가 클라이언트에 의해 세팅된 선택된 수수료 견적의 요건들을 충족시킨다고 가정하면, 단계(316)는 개개의 채굴자가 클라이언트에 대해 생성된 블록체인 트랜잭션의 TxID와 연관된 상태 질의를 수신하는 것과 관련된다. 이 상태 문의는 도 1의 단계들(116 및 118)과 관련하여 논의된 API 변환기를 통해 수신된 RPC 요청 RPC getRawTransaction(TxID)에 기초한다.
단계(318)에서, 개개의 채굴자와 관련된 대응하는 블록체인 트랜잭션의 현재 채굴 상태에 기초한 결과가 지불 프로세서에 제공된다. 이는 도 1의 단계(120)와 관련하여 설명된 바와 같이 TxStatus에 대한 JSON 오브젝트 구조에 기초할 수 있다.
도 4는 지불 프로세서(404)에 의해 API로서 클라이언트(402)에 제공되는 지불 서비스의 전개 아키텍처의 개략도이다. 하나 초과의 지불 프로세서(404)가 존재할 수 있으며, 또한 하나 이상의 지불 프로세서들(404)은 클라이언트의 부분으로서 구현될 수 있거나, 클라이언트와 연관될 수 있거나, 또는 클라이언트와 별개로 구현되고 인터넷과 같은 통신 네트워크를 통해 클라이언트와 통신할 수 있다. 위의 양상들에서 논의된 바와 같이, 클라이언트(402)와 지불 프로세서(404) 사이의 통신은 HTTPS 프로토콜을 사용한다. API 변환기(406)는 또한 이 개략도에서 별개로 도시되지만, 일부 실시예들에서, 지불 프로세서(404)의 부분으로서 구현될 수 있다. 일부 실시예들에서, API 변환기(406)는 복수의 채굴자들(412-1 내지 412-n)에 의해 동작되거나 그와 연관되어 구현될 수 있다. API 변환기(406)는 클라이언트(402)에 서비스를 제공하기 위해 지불 프로세서(404)에 커플링된 하나 이상의 채굴자들(412-1 내지 412-n)로 전송하기 전에 HTTPS 요청들을 RPC 요청들로 변환하는 것을 허용한다. API 변환기(406)는 방화벽(408)을 통해 채굴자들(412-1-412-n)에 연결되는 것으로 도시된다. 채굴자들(412-1 내지 412-n)과 연관된 모든 통신들은 RPC를 사용한다. 방화벽(408)을 통해 지불 프로세서(404)에 복수의 채굴자들(412-1 내지 412-n)을 연결하기 위한 노드 커넥터(410)가 또한 도시된다. 일부 실시예들에서, 노드 커넥터는 도 1과 관련하여 논의된 바와 같이 개개의 지불 서비스를 구현하는 하나 이상의 지불 프로세서들과 연관된 RPC 호출들을 보장하거나 프로세싱할 수 있다. 노드 커넥터(410)는 API 변환기(406)와 하나 이상의 채굴자들(412-1 내지 412-n) 사이에 보안 통신 채널을 제공한다.
API 변환기(406)를 통해 채굴자들(412-1 내지 412-n)을 연결하는 하나 이상의 지불 프로세서들(404)이 존재할 수 있다. 클라이언트(402)는 개별 또는 다수의 트랜잭션들에 대해 제1 내지 제3 양상들과 관련하여 설명된 바와 같이, 채굴자 수수료에 대한 견적들을 획득하고(getFeeQuote), 트랜잭션을 제출하고(submitTransaction), 트랜잭션 상태를 문의(queryTransactionStatus)하기 위한 디지털 지갑 애플리케이션을 포함할 가능성이 매우 높다. 지불 프로세서(404)는 클라이언트(402)에 대한 REST 엔드포인트로서 작용하고 클라이언트는 이 서비스에 대한 익명 액세스를 가질 수 있다. 채굴자들(412-1 내지 412-n)은 채굴 보상 ― 이는 일부 실시예들에서, 블록 보상들 및 채굴 수수료들로 구성될 수 있음 ― 의 대가로 하나 이상의 노드들을 채굴할 수 있다. 블록 보상은 채굴자(412)가 블록을 성공적으로 채굴하면 수여되는 BSV 또는 암호화폐를 지칭한다. 채굴자 수수료는 채굴자(412)가 트랜잭션을 컨펌하고 이를 새롭게 채굴된 블록에 추가하는 경우 받는 보상이다.
도 5는 클라이언트로부터 getFeeQuote 커맨드 또는 템플릿을 구현하기 위해 도 4에 도시된 아키텍처 구성요소들 간의 데이터 흐름을 보여주는 개략도이다. 이는 이미 도 1 내지 도 3과 관련하여 위에서 자세히 논의되었으며 도 4는 단순히 채굴 수수료 견적들을 획득하기 위한 클라이언트, 지불 프로세서 및 채굴자들의 상호작용을 개략적으로 제시한다. 흐름은 HTTPS GET getFeeQuote 커맨드가 단계(501)에서 지불 프로세서(404)로 전송될 때 클라이언트(402)로부터 기원된다. 단계(502)에서, GET 커맨드는 API 변환기(406)로 전송되고, 이는 단계(503)에서 이를 RPC 커맨드 RPC getFeeQuote()로 변환한다. 단계(504)에서, MinerFeeQuote는 복수의 채굴자들(412-1 내지 412-n)의 각각의 채굴자(412)로부터 JSON 오브젝트 포맷으로서 API 변환기(406)에 반환되며, 이는 차례로, 단계(505)에서 지불 프로세서(404)에 제공된다. 단계들(502 내지 505)은 복수의 채굴자들(412-1 내지 412-n) 중 각각의 채굴자에 대해 반복되고 결과(수수료 견적들)는 단계(506)에서 HTTPS 송신에서 클라이언트(402)로 전송된다.
도 6은 클라이언트로부터 submitTransaction 커맨드 또는 템플릿을 구현하기 위해 도 4에 도시된 아키텍처 구성요소들 간의 데이터 흐름을 보여주는 개략도이다. 이는 이미 도 1 내지 도 3과 관련하여 위에서 자세히 논의되었으며 도 4는 단순히 클라이언트에 대한 지불과 연관된 블록체인 트랜잭션을 제공하기 위한 클라이언트, 지불 프로세서 및 채굴자들의 상호작용을 개략적으로 제시한다. 흐름은 HTTPS POST submitTransaction(Tx) 커맨드가 단계(601)에서 클라이언트(402)와 고객 사이의 주어진 트랜잭션(Tx)에 대해 지불 프로세서(404)로 전송될 때 클라이언트(402)로부터 기원된다. 위의 양상들과 관련하여 언급된 바와 같이, Tx는 선택된 수수료 견적과 연관될 수 있다(이 도면에서 도시되지 않음). 단계(602)에서, POST 커맨드가 API 변환기(406)로 전송되며, 이 API 변환기는 단계(603)에서 이를 RPC 커맨드 RPC createRawTransaction(Tx)으로 변환한다. 블록체인 트랜잭션은 선택된 수수료 견적을 충족시키는 각각의 채굴자(412)에 대해 구성된다. 단계(604)에서, 16진법-코딩된 블록체인 트랜잭션이 API 변환기(406)로 반환된다. 트랜잭션은 위의 양상들에서 설명된 바와 같이 특정 식별자(TxID)를 포함한다. 단계(605)에서, 블록체인 트랜잭션과 연관된 출력은 지불 프로세서(404)로 전송된다. 블록체인 트랜잭션과 관련된 결과는 단계(606)에서 TxID를 포함하는 JSON TxResult 오브젝트로서 클라이언트에 반환된다.
도 7은 클라이언트로부터 queryTransactionStatus 커맨드 또는 템플릿을 구현하기 위해 도 4에 표시된 아키텍처 구성요소들 간의 데이터 흐름을 보여주는 개략도이다. 이는 이미 도 1 내지 도 3과 관련하여 위에서 자세히 논의되었으며 도 4는 단순히 클라이언트와 연관된 지불과 연관된 블록체인 트랜잭션을 제공하기 위한 클라이언트, 지불 프로세서 및 채굴자들의 상호작용을 개략적으로 제시한다. 흐름은, HTTPS GET queryTransactionStatus(TxID) 커맨드가 단계(701)에서 도 6의 submitTransaction 흐름의 부분으로서 클라이언트에 이전에 반환된 블록체인 트랜잭션과 관련된 주어진 트랜잭션 TxID에 대해 지불 프로세서(404)로 전송될 때 클라이언트(402)로부터 기원된다. 단계(702)에서, GET 커맨드가 API 변환기(406)로 전송되며, 이 API 변환기는 단계(703)에서 이를 RPC 커맨드 RPC getRawTransaction(TxID)로 변환한다. 그 후, TxID와 관련된 주어진 채굴자(412)와 연관된 블록체인 트랜잭션이 식별된다. 단계(704)에서, 식별된 16진법-코딩된 블록체인 트랜잭션 및 그의 연관된 상태가 API 변환기(406)로 반환된다. 단계(705)에서, TxID와 관련된 블록체인 트랜잭션과 연관된 상태 결과가 지불 프로세서(404)로 전송된다. TxID에 대한 블록체인 트랜잭션과 관련된 상태 결과는 단계(706)에서 JSON TxStatus 오브젝트로서 클라이언트에 반환된다.
또한, 도 1 내지 도 3과 관련하여 위에서 논의한 바와 같이, 수수료 견적들은, 단일 요청에서, 즉 동시에 클라이언트에 의해 제출되는 다수의 트랜잭션들의 세트 또는 배치에 대해 또는 매번 개별적으로 단일 트랜잭션에 대해 요청되고 그리고/또는 획득되고 그리고/또는 제출되고 그리고/또는 질의될 수 있다. 설명 및 이해의 편의를 위해, 도 4 내지 도 7은 제1 요청 및/또는 제2 요청에서의 단일 트랜잭션 및/또는 클라이언트와 연관된 상태 질의와 관련하여 위에서 설명되었지만, 본 개시는 어떠한 방식으로도 그러한 것으로 제한되지 않는다는 것이 이해될 것이다.
제4 양상 ― 콜-백 식별자들
도 8은 제4 양상에 따른 트랜잭션들에 대한 콜-백 메커니즘을 용이하게 하는 방법을 도시하는 흐름도이다. 이 도면은 제1 양상과 관련하여 위에서 논의된 바와 같이 지불 서비스와 연관된 하나 이상의 프로세서들에 의해 구현되는 방법에 관한 것이다.
단계(802)는 하나 이상의 클라이언트들 중 주어진 클라이언트로부터 요청을 수신하는 것을 포함한다. 요청은 디지털 자산과 연관된 트랜잭션의 제출과 관련이 있다. 예컨대, 이는 도 1의 단계(108)에서 설명된 트랜잭션을 제출하라는 제2 요청일 수 있다. 요청은 또한 콜-백 식별자와 연관된다. 일부 실시예들에서, 콜-백 식별자는 클라이언트에 의해 제공되거나 클라이언트와 연관된 것일 수 있다. 예컨대, 이는 URL 또는 API 엔드포인트일 수 있으며, 이를 이용하여, 클라이언트가 접촉될 수 있다. 일부 경우들에서, 이는 또한 클라이언트와 연관된 로케이션을 가리킬 수 있다. 일부 경우들에서, 콜-백 식별자는 로케이션 또는 식별자 통신 채널일 수 있다. 이러한 채널은 추가로 아래의 도 9 내지 도 11서 설명된다. 콜-백 식별자의 목적은 클라이언트와 다른 엔티티 간의 직접 통신을 설정하기 위한 수단을 가능하게 하거나 허용하는 것이다. 콜-백 식별자는 클라이언트에 특유하며, 일부 경우들에서, 이 단계의 요청과 연관된 트랜잭션과 같은 특정 토픽에 특유하다.
단계(804)는 블록체인에 트랜잭션을 포함시키기 위해 복수의 채굴자들 중 주어진 채굴자에게 요청과 연관된 트랜잭션을 제출하는 것을 포함한다. 이는 도 1의 단계(110)에서 제2 요청에 대해 수행된 프로세스와 유사하다.
단계(806)는 클라이언트에 대해 주어진 채굴자를 식별하는 것을 포함한다. 이는 다수의 기술들에 의해, 이를테면, 주어진 채굴자와 연관된 URL 또는 엔드포인트를 클라이언트에게 제공함으로써 수행될 수 있다. 이는 HTTPS 송신 프로토콜을 사용하여 클라이언트에 전송될 수 있다. 일부 경우들에서, 채굴자가 이를테면, 위에서 언급된 bsvalias 어드레싱 서비스를 사용하여 어드레싱을 위한 별칭과 연관되는 경우, 이는 클라이언트에 제공될 수 있다. 일부 경우들에서, 채굴자가 위에서 언급된 바와 같이 채굴자 ID 및/또는 평판과 연관되는 경우, 이러한 정보는 또한 클라이언트에 제공될 수 있다. 일부 경우들에서, 이 식별 단계는 아래에 제시된 단계(812)와 함께 또는 그 이후에 이루어질 수 있다.
단계(808)는 단계(802)에서 설명된 콜-백 식별자를 채굴자에게 제공하여서, 채굴자가 이것을 사용하여 클라이언트에 직접 접촉할 수 있게 하는 것을 포함한다. 일부 경우들에서, 지불 프로세서가 클라이언트를 대신하여 통신들을 처리하는 경우, 콜-백 식별자는 지불 프로세서를 가리킬 수 있다. 이 도면은 콜-백 식별자가 클라이언트에 대한 것인 시나리오와 관련되지만, 본 개시는 그러한 것으로 제한되지 않는다. 예컨대, 콜-백 식별자는 클라이언트 또는 지불 프로세서를 고유하게 식별하는 암호화된 식별자(엔드포인트)일 수 있다.
단계(810)에서, 단계(802)에서 트랜잭션 요청에 대해 생성된 대응하는 블록체인 트랜잭션과 관련된 세부사항들을 갖는 응답이 주어진 채굴자로부터 수신된다. 이는 클라이언트에 제공할 수 있는, 트랜잭션에 대한 트랜잭션 식별자(TxID)를 포함할 것이다. 일부 경우들에서, 단계(806)의 채굴자 아이덴티티는 TxID가 수신되면 또는 그 이후 클라이언트에 제공될 수 있다. 일부 실시예들에서, 이 단계의 응답은 제1 양상에서 위에서 언급된 바와 같이 대응하는 블록체인 트랜잭션과 연관된 출력 스크립트, 예를 들면 UTXO(Unspent Transaction Output)를 포함한다. 대응하는 블록체인 트랜잭션에 대한 이 트랜잭션 식별자(TxID)는 그 후, 클라이언트에 전송된다.
단계(812)는 단계(802)에서 언급된 콜-백 식별자에 기초하여 채굴자에 의해 제공되는 대응하는 블록체인 트랜잭션(TxID)과 관련된 적어도 하나의 콜-백 알림을 클라이언트에 대해 가능하게 하거나 프로세싱하는 것을 포함한다. 이 콜-백 식별자가 클라이언트에 대한 콜-백 엔드포인트 URL 또는 URI인 경우, 메시지들은 HTTP POST 메시지로서 이러한 로케이션에 직접 제공될 수 있다. 메시지는 하나 이상의 알려진 기술들에 기초하여 암호화될 수 있다.
도 9는 본 개시의 제4 양상의 제2 구현과 관련되며, 여기서 요청과 연관된 콜-백 식별자는 채널 프로세서에 의해 클라이언트에 대해 제공되는 채널과 관련된다. 앞서 언급된 바와 같이, 채널 프로세서는 클라이언트에 대해 채널 서비스를 제공하는 별개의 엔티티일 수 있고, 지불 프로세서와 동일한 엔티티일 수 있다. 이 도면의 아래 단계들은 채널 프로세서에 의해 구현된 실시예를 도시한다.
단계(902)는 nChain Holdings Limited의 이름으로 출원된 영국 특허 출원 번호 제2007597.4에서 논의된 바와 같이 채널 서비스에 가입한 주어진 클라이언트로부터 채널과 연관된 요청을 수신하는 것을 도시한다. 이 실시예에서 이 요청은 채널의 생성과 관련이 있다. 그러나 채널 서비스는 기존 채널들과 연관된 API의 업데이트와 같이 다른 기능들을 가능하게 할 수 있다. 대부분의 경우들에서, 클라이언트의 아이덴티티는 클라이언트가 채널 서비스 및 그것에 의해 제공되는 기능성을 사용하도록 등록되었는지 확인하기 위해 체크될 수 있다. 일부 실시예들에서, 이는 등록 동안 패스워드 보호 로그인 인증 등과 같은 알려진 인증 방법들에 기초할 수 있다. 유효성 검증은 저장된 레코드의 패스워드와 매칭되는 패스워드의 수신에 기초할 수 있다. 다른 실시예들에서, 암호화 또는 어드레싱 개인/공개 키 쌍들에 기초한 표준 PKI 기술들은 또한, 단계(902)에서 클라이언트로부터 수신된 요청에 존재할 수 있는 디지털 서명을 유효성 검증하는 데 사용될 수 있다. 이 경우에, 클라이언트의 아이덴티티는 개인 키에 의해 서명된 요청이 공개 키를 사용하여 성공적으로 복원되거나 유효성 검증될 수 있는지를 체크함으로써 검증될 수 있다. 클라이언트가 유효하지 않거나 등록되지 않은 경우, 이 단계의 요청은 추가로 진행되지 않거나 등록 단계가 채널 서비스에 의해 개시될 수 있다.
단계(904)에서, 요청된 채널 기능들 및/또는 메시지 기능들이 클라이언트에 제공된다.
채널 및/또는 메시지 기능들/API들의 생성에 대한 요청과 연관된 체계들 및/또는 포맷들의 일부 예들은 채널 프로세서에 의해 제공되는 응답들에 대한 예시적인 체계와 함께 아래에서 도시된다.
1.1 채널 API들:
채널 API들은 피어 투 피어 통신을 위한 채널들을 생성 및/또는 관리하기 위한 서비스로 채널 서비스에 의해 제공되는 JSON-오버-HTTP API 클라이언트 계정들일 수 있다.
모든 API 엔드포인트들은 일부 실시예들에서 인증을 요구할 수 있다. 특정 인증 체계는 구현에 따라 결정될 수 있다. 공통적인 형태들은 OAuth, 기본 인증 및 베어러 토큰 방법과 같은 체계들을 포함한다. 위에서 언급된 바와 같이, 채널 API들은 선택적으로 클라이언트들에 의해 제공되거나 생성되는 API 토큰들에 의해 안전해질 수 있다.
채널 생성: 클라이언트, 즉 채널 서비스의 계정 홀더에 의해 소유된 새로운 채널을 생성한다
요청 포맷:
Figure pct00009
응답 포맷:
성공적으로 생성된 응답은 초기 액세스 토큰을 포함한다. 계정 크리덴셜들이 사용되어 채널 API에 액세스할 수 있지만, 메시징 API에 액세스하기 위해 토큰들이 사용될 필요가 있을 수 있다. 이에 대한 이 초기 액세스 토큰은 채널에 기록하고 판독할 목적으로 계정 홀더에 속한다.
Figure pct00010
Figure pct00011
메시지 API들은 계정 홀더들 및 관련 상대방들(채널에 대한 다른 엔티티)이 주어진 채널들에 대한 메시지들을 기록하거나 판독하도록 허용한다. 다음 메시지 API들은 계정 홀더들 및 그의 상대방들이 메시지들을 교환하기 위한 JSON-오버-HTTP API로서 제공될 수 있다.
2.1 새로운 메시지들에 대한 테스트 채널
요청 포맷:
Figure pct00012
응답 포맷:
Figure pct00013
2.2 채널에 대한 메시지 기록
요청 포맷:
Figure pct00014
응답 포맷:
a) 수락됨
메시지가 채널에 기록되었다.
Figure pct00015
b) 시퀀싱 실패
채널이 순서대로 생성되었고 요청과 연관된 API 토큰이 채널에서 최신 메시지들을 판독한 것으로 마킹하지 않았다. 여전히 적절한 경우, 클라이언트는 기록 시도를 재시도해야 할 필요가 있을 수 있다.
Figure pct00016
c) 메시지가 너무 큼
종단 간 암호화가 예컨대, 노이즈 프로토콜에 기초하여 모든 메시지들을 안전하게 하는 실시예들에서, 임의의 단일 메시지의 최대 크기는 65536 바이트들로 세팅된다. 이보다 큰 메시지들이 있어서는 안 되므로, 일부 실시예들에서 채널에 기록되는 임의의 메시지의 최대 크기를 제한하는 것이 유용할 수 있다. 이보다 큰 메시지들은 채널에 의해 거부될 수 있다.
Figure pct00017
d) 저장 할당량이 초과됨
일부 실시예들에서 서비스 운영자에 의해 세팅될 수 있는 할당량이 초과되었다. 클라이언트 요청이 유효할 수 있지만, 현재 스토리지 서비스에서 이를 이행할 수 없다.
Figure pct00018
2.3 채널에서 메시지 가져오기
채널로부터의 모든 메시지들을 반환하고 선택적으로 단지 읽지 않은 것으로 필터링한다.
요청 포맷:
Figure pct00019
읽지 않음 질의 스트링 파라미터는 선택적이다.
응답 포맷:
Figure pct00020
2.4 메시지를 읽음 또는 읽지 않음으로 마킹: 메시지를 읽음 또는 읽지 않음으로 플래깅한다.
요청 포맷:
Figure pct00021
Figure pct00022
선택적인 구(older) 파라미터는 클라이언트가 단일 호출에서 읽음으로서 제공된 <sequence> 경로 인자와 동일하거나 더 낮은 시퀀스를 갖는 모든 메시지들을 마킹하도록 허용함.
응답 포맷:
Figure pct00023
단계(906)에서, 요청된 채널과 연관된 액세스 토큰 또는 API 토큰들이 클라이언트에 제공된다. 필요한 경우, 일부 실시예들에서, 액세스 토큰들은 또한, 예컨대, 허가들이 수정되었거나 주어진 채널에 대해 클라이언트에 의해 더 이상 요구되지 않는 경우 철회 또는 폐기될 수 있다.
이에 대한 예시적인 체계들이 아래에서 주어진다:
3.1 채널 API 토큰 생성
요청 포맷:
Figure pct00024
응답 포맷:
이는 토큰 값을 반환하는 유일한 API 호출이다. 분실된 경우, 토큰이 삭제되고 새로운 토큰으로 대체되어야 한다.
Figure pct00025
1.6 채널 API 토큰 폐기:
요청 포맷:
Figure pct00026
응답 포맷:
Figure pct00027
단계(908)는 트랜잭션과 같은 특정 토픽에 관해 다른 엔티티(도 8에 제시된 바와 같은 실시예에서, 이 엔티티는 채굴자임)로부터 안전하게 클라이언트에 대해 수신된 알림 또는 경고 또는 임의의 다른 정보의 제공을 도시한다. 따라서 이는 도 8에 언급된 바와 같이 TxID를 가질 수 있는 특정 트랜잭션과 관련하여 콜-백 알림으로서 지칭된다. 이는 상태의 변화의 알림 또는 채널이 생성된 주어진 트랜잭션 또는 토픽과 관련하여 예외가 발생되는 경우들에서 임의의 다른 알림일 수 있다.
알림이 채널을 통해 수신되기 때문에, 클라이언트가 항상 온라인일 필요는 없고 클라이언트가 채널 프로세서와 연결되거나 재연결(온라인)될 때마다 알림들이 비동기적으로 전달될 수 있다. 일부 경우들에서, 클라이언트가 연결된 채로 유지되어야 하는 최소 시간을 부과할 수 있는 세팅들이 제공될 수 있거나, 또는 세팅은, 채널의 모든 '읽지 않은' 경고들 또는 알림들이 클라이언트와 연관된 지갑 또는 클라이언트에 의해 소비될 때까지 클라이언트가 연결된 채로 유지되도록 보장할 수 있다. 따라서, 일부 실시예들에서, 클라이언트는 알림들이 소비되거나 채널로부터 클라이언트에 의해 수신되면 연결해제하도록 허용될 수 있다. 토픽 또는 트랜잭션 당 하나씩, 특정 클라이언트에 대해 제공되는 다수의 이러한 채널들이 있을 수 있다.
일부 실시예들에서, 클라이언트가 채널 프로세서에 연결되는지, 즉 온라인인지 또는 아닌지, 즉 오프라인인지를 검출하기 위한 부가적인 단계가 있을 수 있다. 이는 하나 이상의 알림들 또는 메시지들이 채널에 도달할 때 클라이언트와의 네트워크 연결이 존재하는지 확인하는 알려진 기술에 의해 행해질 수 있다.
채널의 클라이언트에 대한 콜-백 알림들 또는 메시지들은 채널들의 메시지들 및 클라이언트에 전달되는 메시지들에 관한 동기화를 보장하기 위해 온라인일 때 클라이언트에 의해 '풀링'된다.
채널 알림들이 도달했을 때 클라이언트가 연결되지 않았거나 오프라인인 경우, 이들은 채널 프로세서와 연관되는 메모리 또는 캐시에 저장된다. 이는 일부 실시예들에서 주어진 클라이언트에 특유할 수 있다. 클라이언트가 온라인이거나 클라이언트가 연결된 것으로 검출될 때, 이러한 알림들이 클라이언트 엔티티에 제공되거나 푸시된다. 푸시 알림들이 클라이언트에 전송될 수 있어서, 이들은 채널에서 데이터 또는 읽지 않은 메시지들을 획득할 수 있게 한다. 따라서 클라이언트가 오프라인일 때, 메시지들 또는 알림들은 채널 서비스 또는 채널 프로세서에 의해 저장된다. 그 후, 이들은 클라이언트가 온라인일 때 클라이언트에 제공된다.
다른 엔티티가 클라이언트로부터 트랜잭션을 채굴하는 채굴자인 경우, 채널에서 임의의 유형의 메시지가 전송될 수 있지만, 대부분의 경우 채굴자와 클라이언트 간의 직접 통신을 위한 시나리오는 다음과 같다:
1. 트랜잭션의 상태가 업데이트되거나 변할 때,
2. 채굴자로부터 정보에 대한 애드-혹 요청들의 수신 시에,
제1 시나리오에서, 클라이언트가 트랜잭션의 이중 소비와 같은 예외 또는 상태의 변화를 통지받거나 채굴을 확인하거나 트랜잭션의 유효성 또는 무효를 확인하는 등을 할 필요가 있을 때마다, 콜-백 알림이 발생된다.
제2 시나리오에서, 클라이언트는 주기적이거나 임의적일 수 있는 특정 시간에 동일한 채널을 사용하여 채굴자로부터 직접 상태 업데이트에 대해 요청할 수 있다.
도 10은 본 개시의 제4 양상의 제3 구현에 관한 것이며, 여기서 클라이언트는 도 9에 제시된 채널 프로세서에 의해 구현된 채널 서비스와 연관된다. 이는 도 8의 콜-백 식별자가 채널 서비스를 사용하여 클라이언트에 의해 생성된 채널인 실시예들에 대한 것이다. 이 도면의 아래 단계들은 클라이언트에 의해 구현된 실시예를 도시한다.
단계(1002)에서 클라이언트는 채널 서비스에 대한 요청을 준비하고 이를 채널 서비스(채널 프로세서)로 전송한다. 준비된 요청은 HTTP(Hypertext Transfer Protocol) 또는 유사한 송신 프로토콜 포맷을 사용하여 클라이언트에 의해 전송될 수 있다. 일부 실시예들에서, 이는 HTTP 또는 REST API로서 구현되는 채널 프로세서에 전송되고, 응답은 또한 HTTP 송신 프로토콜 포맷으로 클라이언트에 제공될 수 있다. 위에서 언급된 바와 같이, 채널 프로세서는 지불 프로세서와 동일한 엔티티일 수 있거나, 또는 별개의 엔티티일 수 있다.
이 실시예의 요청은 채굴자와 같은 다른 엔티티와의 직접 통신을 위한 메커니즘을 가능하게 하거나, 허용하거나 또는 제공할 수 있는 채널의 생성과 관련된다.
단계(1004)에서, 채널 또는 메시지 기능들/API들과 같은 하나 이상의 기능들은 클라이언트가 다른 엔티티와의 직접 통신을 보장하기 위해 채널을 생성하는 것을 가능하게 하기 위해 채널 프로세서로부터 수신된다. 이 채널 기능들 및 메시지 기능들은 채널 프로세서로부터 수신된 도 9의 단계(904)에서 제시된다. 단계(906)에서 보여진 바와 같은 요청에 대한 액세스 토큰들뿐만 아니라 메시지 API들이 또한 채널에 대해 수신된다.
단계(1006)는 디지털 자산과 연관된 트랜잭션을 제출하라는 요청을 지불 프로세서에 전송하는 것을 도시한다. 이는 클라이언트의 고객과 연관되는 지불 트랜잭션 또는 이와 유사한 것일 수 있다. 도 8의 단계(802)와 관련하여 위에서 또한 제시된 바와 같은 이 단계는 도 2의 단계(208)와 유사하다. 요청은 HTTP를 통해 지불 프로세서에 대한 API로 전송되며 POST 요청일 수 있다.
단계(1008)에서, 트랜잭션 식별자(TXID)는 지불 프로세서로부터 수신된다. 이는 도 8의 단계(810)에서 설명된 바와 같이 주어진 채굴자로부터의 응답에 기초한다.
단계(1010)에서, 클라이언트는 이전 단계에서 TxID를 지불 프로세서로 전송한 채굴자를 식별하거나 인식하게 된다. 이는 도 8에서 위에서 논의된 바와 같이 채굴자와 연관되는 API 또는 로케이션 또는 채굴자 ID 및/또는 평판에 기초할 수 있다.
단계(1012)에서, 단계(1004)에서 채널 프로세서로부터 수신된 API들은 이전 단계(1010)에서 식별된 채굴자와의 채널을 생성하는 데 사용된다. 수신된 액세스 토큰들은 다른 엔티티를 인증하고 채널과 연관된 다양한 기능들에 대한 액세스를 제공하는 데 사용될 수 있다. 일부 실시예들에서, 메시지 API들 및 액세스 토큰은 채널을 통한 통신을 위해 다른 엔티티에 전송될 수 있다. 일부 실시예들에서, 채널의 생성에 이어, 채널을 통한 통신들을 안전하게 하기 위한 키를 설정하기 위해 클라이언트와 채굴자 사이에 핸드셰이크 프로토콜이 발생할 수 있다. 노이즈 프로토콜 프레임워크(Noise Protocol Framework) 또는 Libsodium 키 교환 메커니즘과 같은 임의의 알려진 방법이 이를 위해 사용될 수 있다.
단계(1014)에서, 채굴자로부터의 응답은 채널을 통해 수신된다. 이는 상대방, 즉 채굴자가 클라이언트와의 직접 통신을 위해 이전 단계에서 모든 요구된 메시지 API들 및 액세스 토큰들을 수신했기 때문에 가능하다. 채굴자로부터의 응답은 단계(1008)에서 특정 TxID와 연관될 것이며, 따라서 개개의 채널의 통신은 그 트랜잭션 식별자에 특유할 것이다. 메시지는 TxID와 연관된 임의의 문제와 관련될 수 있다. 예컨대, TxID가 이전 트랜잭션의 이중 소비임을 클라이언트에게 알리기 위해 알림이 채널을 통해 전송될 수 있다. 이는 트랜잭션이 이미 임시 메모리 풀에 있는 경우에 해당할 수 있다. 그렇지 않고 일단 트랜잭션이 블록에 포함되면, 메시지는 트랜잭션에 대한 채굴의 머클 증명과 연관될 수 있다.
도 11은 본 개시의 제4 양상의 제4 구현에 관한 것이며, 여기서 클라이언트는 도 9에 제시된 채널 프로세서에 의해 구현된 채널 서비스와 연관된다. 이는 도 8의 콜-백 식별자가 채널 서비스를 사용하여 클라이언트에 의해 생성된 채널인 실시예들에 대한 것이다. 이 도면의 아래 단계들은 채굴자에 의해 구현된 실시예를 도시한다.
단계(1102)에서, 도 8의 단계(804)에서 알 수 있는 바와 같이 트랜잭션을 채굴하기 위해 지불 프로세서로부터 채굴자에 의한 요청이 수신된다.
단계(1104)에서, 채굴자는 블록체인 트랜잭션을 생성한다. 이 단계는 일부 실시예들에서 제출된 트랜잭션에 대응하는 16진수 인코딩된 원시 트랜잭션이 생성되는 도 3의 단계(310)와 유사하다. 따라서, 개개의 채굴자에 의해 생성된 대응하는 블록체인 트랜잭션과 연관된 트랜잭션 식별자(TxID)를 포함하는 출력 스크립트 또는 UTXO가 제공된다. 그 후, 블록체인 트랜잭션에 대한 출력 스크립트(UTXO)는 순시적으로 또는 추후의 시간에 채굴을 위해 채굴자와 연관된 멤풀에 추가될 수 있다.
단계(1106)에서, 대응하는 블록체인 트랜잭션에 대한 이러한 트랜잭션 식별자(TxID)는 그 후 지불 프로세서를 통해 클라이언트로 전송되어서, 클라이언트는 TxID에 액세스를 가질 수 있고 채굴자를 또한 식별할 수 있다.
단계(1110)에서, 클라이언트가 채굴자와의 직접 통신을 위해 채널 서비스를 사용하여 채널을 생성하면, 채굴자는 임의의 연관된 메시지 API들 및 액세스 토큰들과 함께 클라이언트로부터 채널에 대한 액세스를 수신한다.
단계(1112)에서, 채굴자는 단계(1102)에서 제출된 트랜잭션이 이전 트랜잭션의 이중 소비인지 체크한다. 위에서 언급된 바와 같이, 이는 동일한 트랜잭션이 채굴자와 연관된 보조 또는 임시 메모리 풀에 존재하는지 또는 그것이 블록체인에서 이미 채굴되었는지를 체크함으로써 구현될 수 있다.
이것이 사실인 경우, 채굴자는 채널을 사용하여 클라이언트에게 다시 전송하기 위해 이중 소비 알림 또는 경고를 생성한다. 이중 소비 알림은 채굴자 ID를 통해 추적될 수 있는 자신의 평판을 유지하도록 장려되는 채굴자가 동일한 클라이언트(즉, 판매자 지갑)에 의해 이전에 소비된 디지털 자산들 이를테면, BSV를 소비하려는 시도를 클라이언트에게 알릴 때 발생된다.
예시적인 체계들의 하나의 버전은 다음과 같을 수 있다:
요청:
Figure pct00028
응답:
Figure pct00029
이중 소비 알림에 대한 예시적인 체계들의 다른 버전은 아래에 주어진다:
요청:
Figure pct00030
응답:
Figure pct00031
Figure pct00032
단계(1116)에서, 위에서 알 수 있는 바와 같이 이중 소비 콜-백 알림 또는 "콜-백 페이로드"는 이 실시예에서 채굴자가 액세스를 수신한 채널인 callbackURL로 전송된다. 채널은 API 또는 로케이션 또는 식별자에 의해 식별될 수 있다. 알림은 액세스가 채굴자에게 제공된 채널과 연관된 액세스 토큰들 및 메시지 API들을 사용하여 채널에 추가된다.
단계(1102)에서 제출된 트랜잭션이 이중 소비가 아닌 경우, 단계(1118)에서, 채굴자는 알려진 채굴 기술들을 사용하여 블록체인과 연관된 블록에서 트랜잭션을 채굴하는 것으로 진행되며, 그 중 일부는 본 출원의 배경에서 논의된다.
단계(1120)에서, 채굴자는 그 후, 블록에의 트랜잭션의 포함 증명을 생성한다.
일부 실시예들에서, 증명은 머클 트리 증명일 수 있다. 이는 트리로서 구성된 알려진 인증된 데이터 구조이다. 각각의 데이터 블록의 해시는 베이스 층 또는 리프 상의 노드에 저장되며 트리 또는 분기의 모든 각각의 내부 노드는 그의 2개의 자식/형제 노드들의 해시들로부터 컴퓨팅된 암호화 해시를 포함한다. 트리의 최상위 노드인 머클 루트는 트리가 구성된 데이터 세트를 고유하게 식별한다. 따라서 머클 트리는 효율적인 포함 증명(proof-of-inclusion)을 허용하며, 여기서 채굴자 또는 증명자 노드는 제출자 또는 검증자 노드에, 감사 경로(audit path)를 통해 증명을 그들에 전송함으로써 특정 데이터 블록이 인증된 데이터 세트의 일부임을 보여준다. 감사 경로는 제출자가 전체 데이터 세트를 드러낼 것을 요구함 없이 머클 루트를 재계산하는 데 필요한 노드 해시들을 포함한다. 비트코인 SV에서, 블록에 포함된 트랜잭션들은 머클 트리에 저장된다.
예시적인 체계들은 다음과 같을 수 있다:
요청:
Figure pct00033
응답:
Figure pct00034
머클 증명 알림에 대한 예시적인 체계들의 다른 버전은 아래에서 주어진다:
요청:
Figure pct00035
응답:
Figure pct00036
Figure pct00037
단계(1122)에서, 채굴자는 자신이 액세스를 갖는 채널을 사용하여 블록체인에의 트랜잭션의 포함 증명을 클라이언트에게 직접 전송한다. 따라서 클라이언트 또는 지불 프로세서가 상기 트랜잭션을 찾기 위해 블록체인을 검색하거나 그의 사본을 실행해야 할 필요가 없다.
이제 도 12를 참조하면, 본 개시의 적어도 하나의 실시예를 실행하는데 사용될 수 있는 컴퓨팅 디바이스(2600)의 예시적이고 단순화된 블록도가 제공된다. 다양한 실시예들에서, 컴퓨팅 디바이스(2600)는 위에서 예시되고 설명된 시스템들 중 임의의 것을 구현하는 데 사용될 수 있다. 예컨대, 컴퓨팅 디바이스(2600)는 도면의 DBMS의 하나 이상의 구성요소들로서 사용되도록 구성될 수 있거나, 컴퓨팅 디바이스(2600)는 주어진 사용자와 연관된 클라이언트 엔티티가 되도록 구성될 수 있으며, 클라이언트 엔티티는 도 12의 DBMS에 의해 관리되는 데이터베이스에 대한 데이터베이스 요청들을 행한다. 따라서 컴퓨팅 디바이스(2600)는 휴대용 컴퓨팅 디바이스, 개인용 컴퓨터 또는 임의의 전자 컴퓨팅 디바이스일 수 있다. 도 12에 도시된 바와 같이, 컴퓨팅 디바이스(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)에 디바이스를 연결하는 포트를 통해 송신될 수 있는 전기 신호들로 광학 신호들을 변환하도록 구성될 수 있다. 컴퓨터들 및 네트워크들의 끊임없이 변하는 성질로 인해, 도 12에 도시된 컴퓨팅 디바이스(2600)의 설명은 디바이스의 바람직한 실시예를 예시하기 위한 특정 예로서만 의도된다. 도 12에 도시된 시스템보다 더 많거나 더 적은 구성요소들을 갖는 다수의 다른 구성들이 가능하다.
열거된 예시적 실시예들
이로써 본 개시는 청구된 양상들 및 실시예들을 더 잘 설명하고, 기술하고 이해하기 위한 예시적인 실시예로서 본원에서 제공되는, 위의 양상들과 관련되는 다음의 조항들에 기초하여 논의된다.
1. 블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법으로서,
방법은 지불 프로세서에 의해 구현되고,
하나 이상의 클라이언트들 중 주어진 클라이언트로부터 요청을 수신하는 단계 ― 요청은 디지털 자산과 연관된 트랜잭션을 블록체인에 제출하기 위한 것이고, 요청은 트랜잭션을 위해 주어진 클라이언트와 다른 엔티티 사이의 직접 통신을 가능하게 하기 위한 콜-백 식별자와 연관됨 ― ;
블록체인에 트랜잭션을 포함시키기 위해, 복수의 채굴자들 중 주어진 채굴자에게 요청과 연관된 트랜잭션을 제출하는 단계;
클라이언트에 대해 주어진 채굴자를 식별하는 단계;
채굴자에게 콜-백 식별자를 제공하는 단계를 포함하고,
주어진 채굴자로부터의 요청에 대한 대응하는 블록체인 트랜잭션과 관련된 응답을 수신하는 것에 응답하여, 방법은,
채굴자에 의해 제공되는 대응하는 블록체인 트랜잭션과 관련된 적어도 하나의 콜-백 알림을 클라이언트에 대해 가능하게 하거나 프로세싱하는 단계를 더 포함하고, 콜-백 알림은 요청과 연관된 콜-백 식별자에 기초하는,
블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
2. 조항 1에 제시된 방법에 있어서,
채굴자로부터의 수신된 응답은 트랜잭션 식별자(TxID)와 연관되고, 방법은, 대응하는 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 클라이언트에 전송하는 단계를 더 포함하는,
블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
3. 조항 1 또는 조항 2에 제시된 방법에 있어서,
수신된 응답은 블록체인 트랜잭션과 연관된 출력 스크립트이고, 출력 스크립트는 채굴자에 대한 멤풀(mempool)과 연관된 소비되지 않은 트랜잭션 출력(Unspent Transaction Output, UTXO)를 포함하고, UTXO는 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 포함하는,
블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
4. 조항 1 내지 조항 3 중 어느 한 조항에 제시된 방법에 있어서,
지불 프로세서는 하나 이상의 클라이언트들에 대한 REST(Representational State Transfer) 엔드포인트로서 구현되고, 방법은,
HTTPS(Hypertext Transfer Protocol Secure) 송신 프로토콜 포맷을 사용하여 클라이언트로부터 요청을 수신하는 단계;
개개의 요청을 RPC(Remote procedure Call) 포맷으로 변환하고 RPC를 채굴자에게 제출하는 단계;
채굴자로부터 RPC 포맷으로 대응하는 블록체인 트랜잭션과 연관된 응답을 수신하는 단계; 및
HTTPS 송신 프로토콜을 사용하여 클라이언트에 전송하기 위한 개개의 응답들을 변환하는 단계를 수행하기 위해 지불 프로세서와 연관된 API(application programming interface) 게이트웨이를 제공하는 단계를 더 포함하는,
블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
5. 조항 1 내지 조항 4 중 어느 한 조항에 제시된 방법에 있어서,
주어진 채굴자의 아이덴티티를 검증하는 단계를 포함하고, 검증은 주어진 채굴자와 연관된 디지털 서명에 기초하거나 또는 주어진 채굴자와 관련되는 식별자에 기초하고, 상기 식별자는 선택적으로 주어진 채굴자에 대한 평판 표시자와 연관되는,
블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
6. 조항 1 내지 조항 5 중 어느 한 조항에 제시된 방법에 있어서,
콜-백 알림은 주어진 클라이언트에 의해 제출된 트랜잭션의 이중 소비의 알림과 관련되거나, 또는 콜-백 알림은 주어진 클라이언트에 의해 제출된 트랜잭션의 블록체인에의 포함 증명(proof of inclusion)과 관련되는,
블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
7. 조항 1 내지 조항 6 중 어느 한 조항에 제시된 방법에 있어서,
콜-백 식별자는 클라이언트와 연관된 채널에 대한 로케이션이거나, 또는 콜-백 식별자는 클라이언트에 대한 URI(Universal Resource Identifier)인,
블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
8. 조항 1 내지 조항 7 중 어느 한 조항에 제시된 방법에 있어서,
채널에 대한 액세스를 주어진 채굴자에게 제공하는 단계를 포함하고, 상기 제공하는 단계는 요청과 연관된 채널에 대한 채널 식별자 또는 로케이션, 및 채널과 연관된 하나 이상의 액세스 토큰들을 채굴자에게 제공하는 단계를 포함하는,
블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
9. 하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법으로서,
방법은 채널 프로세서에 의해 구현되고,
하나 이상의 클라이언트들 중 주어진 클라이언트로부터 요청을 수신하는 단계 ― 요청은 채널의 생성과 관련됨 ― ;
채널을 통해 주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 주어진 클라이언트에 제공하는 단계 ― 상기 하나 이상의 기능들은,
데이터의 송신을 위해 채널과 관련된 채널 기능들 또는 절차들; 및/또는
채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함함 ― ;
채널에 대한 하나 이상의 액세스 토큰들을 발행하는 단계 ― 상기 하나 이상의 액세스 토큰들은 채널을 통해 다른 엔티티와의 보안 통신을 위해 구성됨 ― ; 및
주어진 클라이언트에 대해 채널과 연관된 하나 이상의 알림들을 저장 및/또는 제공하는 단계를 포함하는,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
10. 조항 9에 제시된 방법에 있어서,
하나 이상의 기능들은 주어진 클라이언트에 대해 발행되거나 제공된 API(application programming interface)들이고, 상기 API들은 채널에 대한 채널 API들 및 채널과 연관된 데이터에 대한 메시지 API들을 포함하고; 액세스 토큰들은 채널 또는 주어진 메시지에 특유한 API 토큰들인,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
11. 조항 9 또는 조항 10에 제시된 방법에 있어서,
하나 이상의 기능들에 대한 액세스를 제공하는 단계는 하나 이상의 채널들의 생성 및/또는 관리를 가능하게 하기 위해 JSON(JavaScript Object Notation)-오버(over)-HTTP(Hyper Text transfer protocol) API의 제공을 포함하는,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
12. 조항 9 내지 조항 11 중 어느 한 조항에 제시된 방법에 있어서,
채널들과 연관된 하나 이상의 알림들은 채굴자로부터의 콜-백 알림들이고, 채굴자는 채널을 통해 주어진 클라이언트와 직접 통신하는 다른 엔티티인,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
13. 조항 12에 제시된 방법에 있어서,
콜-백 알림은 주어진 클라이언트에 의해 제출된 트랜잭션의 이중 소비의 알림과 관련되는,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
14. 조항 13에 제시된 방법에 있어서,
콜-백 알림은 채널의 반환 페이로드와 연관되며, 상기 반환 페이로드는 채굴자에 의해 제공되고, 반환 페이로드는 다음 데이터 즉,
- 이중 소비인 블록체인 트랜잭션의 트랜잭션 식별자(TxID); 및 선택적으로
- 블록체인 트랜잭션을 제출한 지불 프로세서에 대한 서비스 엔드포인트를 포함하는,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
15. 조항 12에 제시된 방법에 있어서,
콜-백 알림은 블록체인에서 주어진 클라이언트에 의해 제출된 트랜잭션의 포함 증명과 관련되는,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
16. 조항 15에 제시된 방법에 있어서,
콜-백 알림은 채널의 반환 머클(Merkle) 증명과 연관되고, 상기 반환 머클 증명은 채굴자에 의해 제공되고, 반환 머클 증명은 다음 데이터 즉,
- 머클 증명이 관련된 블록체인 트랜잭션의 트랜잭션 식별자(TxID);
- 블록체인 트랜잭션이 포함되는 블록의 블록 헤더; 및
- 트랜잭션 식별자(TxID)에 대한 형제 해시들의 어레이를 포함하는,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
17. 조항 9 내지 조항 16 중 어느 한 조항에 제시된 방법에 있어서,
클라이언트가 오프라인이거나 채널 프로세서에 통신 가능하게 연결되지 않을 때, 하나 이상의 콜-백 알림들은 채널에서 주어진 클라이언트에 대해 저장되거나 큐잉되는(queued) 데이터에 대한 푸시 알림들인,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
18. 조항 9 내지 조항 17 중 어느 한 조항에 제시된 방법에 있어서,
클라이언트가 온라인이거나 채널 프로세서에 통신 가능하게 연결될 때, 하나 이상의 콜-백 알림들과 연관된 데이터가 채널로부터 제공되거나 풀링되는,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
19. 조항 9 내지 조항 18 중 어느 한 조항에 제시된 방법에 있어서,
채널 프로세서는 지불 프로세서이거나 지불 프로세서를 포함하고, 방법은 조항 1 내지 조항 8 중 어느 한 조항에 따라 지불 프로세서에 의해 구현되는 방법을 포함하는,
하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
20. 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법으로서,
방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되고,
채널 서비스에 관한 채널 요청을 전송하는 단계 ― 채널 서비스는 채널 프로세서에 의해 구현되고, 요청은 다른 엔티티와의 통신을 위한 채널의 생성과 관련됨 ― ;
주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 채널 서비스로부터 획득하는 단계 ― 상기 하나 이상의 기능들은,
데이터의 송신을 위해 채널과 관련된 채널 기능들 또는 절차들; 및/또는
채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함함 ― ;
하나 이상의 액세스 토큰들을 채널 서비스로부터 획득하는 단계 ― 상기 액세스 토큰들은 다른 엔티티와의 보안 통신을 가능하게 함 ― ;
디지털 자산과 연관된 트랜잭션을 블록체인에 제출하라는 요청을, 지불 서비스를 구현하는 지불 프로세서에 전송하는 단계;
제출된 트랜잭션에 대응하는 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 지불 프로세서로부터 획득하는 단계;
지불 프로세서로부터의 응답에 기초하여 대응하는 블록체인 트랜잭션과 연관된 채굴자를 식별하는 단계;
채널 프로세서로부터 수신된 하나 이상의 채널 기능들을 사용하여, 식별된 채굴자와의 통신을 위한 주어진 채널을 생성하는 단계;
주어진 채널과 연관된 하나 이상의 액세스 토큰들을 채굴자에게 전송하는 단계;
주어진 채널과 연관된 적어도 하나의 콜-백 알림을 수신하는 단계를 포함하고, 알림은 블록체인 트랜잭션과 연관된 주어진 채널의 데이터와 관련되며, 상기 데이터는 채굴자에 의해 제공되는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
21. 조항 20에 제시된 방법에 있어서,
클라이언트가 오프라인이거나 채널 프로세서에 통신 가능하게 연결되지 않을 때, 콜-백 알림들은 주어진 채널에 큐잉되는 데이터 또는 메시지들에 대한 푸시 알림들로서 획득되는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
22. 조항 20 또는 조항 21에 제시된 방법에 있어서,
클라이언트가 온라인이거나 채널 프로세서에 통신 가능하게 연결될 때, 콜-백 알림들과 연관된 데이터가 주어진 채널로부터 풀링되는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
23. 조항 20 내지 조항 22 중 어느 한 조항에 제시된 방법에 있어서,
하나 이상의 기능들은 주어진 클라이언트에 대한 API(application programming interface)들이고, 상기 API들은 하나 이상의 채널들의 생성 및/또는 관리를 가능하게 하기 위한 채널 API들; 및 주어진 클라이언트 및 하나 이상의 다른 엔티티들이 메시지들을 교환하고 그리고/또는 주어진 채널로부터 데이터를 판독하고 그리고/또는 주어진 채널에 데이터를 기록하는 것을 가능하게 하기 위한 메시지 API들을 포함하고, 액세스 토큰들은 주어진 채널 또는 주어진 메시지에 특유한 API 토큰들인,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
24. 조항 20 내지 조항 23 중 어느 한 조항에 제시된 방법에 있어서,
채널 요청은 채널 프로세서에 대한 HTTPS(Hypertext Transfer Protocol Secure) 송신 GET 요청이고, 지불 프로세서에 대한 요청은 지불 프로세서에 대한 HTTPS(Hypertext Transfer Protocol Secure) 송신 POST 요청인,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
25. 조항 20 내지 조항 24 중 어느 한 조항에 제시된 방법에 있어서,
클라이언트 엔드포인트를 제공하는 단계;
클라이언트와 연관된 적어도 하나의 클라이언트 어드레싱 키를 제공하는 단계;
채굴자 엔드포인트를 획득하는 단계;
채굴자와 연관된 적어도 하나의 채굴자 어드레싱 키를 획득하는 단계;
클라이언트 및 채굴자 어드레싱 키들에 기초하여 주어진 채널을 사용하여 하나 이상의 핸드셰이크 메시지들을 교환하는 단계;
핸드셰이크 결과 또는 패턴에 기초하여, 공유 비밀 키를 획득하는 단계를 더 포함하고,
주어진 채널을 사용하는 임의의 통신은 공유 비밀 키에 기초하여 암호화되는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
26. 조항 25에 제시된 방법에 있어서,
클라이언트 엔드포인트는 HTTP(Hyper Text Transfer Protocol) API(Application Programming Interface) 엔드포인트이고, 상기 클라이언트 엔드포인트는 HTTPS(HTTP Secure)를 사용하여 전달되는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
27. 조항 25에 제시된 방법에 있어서,
클라이언트 엔드포인트는 주어진 채널을 사용하여 전송된 주어진 클라이언트로부터의 메시지에 포함된 URL(Universal Resource Location)인,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
28. 조항 25 내지 조항 27 중 어느 한 조항에 제시된 방법에 있어서,
클라이언트 엔드포인트는 클라이언트와 연관된 별칭이고, 별칭은 클라이언트에 특유하고 별칭-기반 어드레싱 서비스에 의해 제공되며, 어드레싱 서비스는 정의되거나 잘 알려진 로케이션으로부터 액세스 가능한 기계 판독 가능 자원을 갖고, 기계 판독 가능 자원은 클라이언트와 관련된 하나 이상의 능력들을 포함하고, 별칭은 인증을 위한 비대칭 암호화 키 쌍과 연관되는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
29. 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법으로서,
방법은 복수의 채굴자들 중의 채굴자와 연관된 하나 이상의 프로세서들에 의해 구현되고, 복수의 채굴자들은 주어진 클라이언트에 대한 지불 서비스를 구현하는 적어도 하나의 지불 프로세서에 통신 가능하게 커플링되고,
방법은,
지불 프로세서로부터 블록체인으로의 트랜잭션의 제출에 대한 요청을 수신하는 단계;
요청에 대응하는 블록체인 트랜잭션을 생성하는 단계;
블록체인 트랜잭션과 연관된 출력 스크립트(UTXO)를 지불 프로세서로 전송하는 단계 ― 출력 스크립트는 대응하는 블록체인 트랜잭션과 연관된 트랜잭션 식별자(TxID)를 포함함 ― ;
채널에 대한 액세스를 수신하는 단계 ― 채널은 주어진 클라이언트와의 직접 통신을 가능하게 함 ― ;
채널과 연관된 액세스 토큰에 기초하여, 채널에서 콜-백 알림과 연관된 데이터를 제공하거나 기록하기 위한 메시지 기능 또는 메시지 API를 획득하는 단계를 포함하고, 데이터는 대응하는 블록체인 트랜잭션과 관련되는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
30. 조항 29에 제시된 방법에 있어서,
대응하는 블록체인 트랜잭션이 클라이언트에 의해 제출된 이전 트랜잭션의 이중 소비라는 결정에 기초하여; 방법은 반환 페이로드를 제공하는 단계를 더 포함하고, 반환 페이로드는 다음 데이터 즉,
- 이중 소비인 주어진 블록체인 트랜잭션의 트랜잭션 식별자(TxID); 및 선택적으로
- 주어진 블록체인 트랜잭션을 제출한 지불 프로세서에 대한 서비스 엔드포인트를 포함하는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
31. 조항 29에 제시된 방법에 있어서,
블록에서 대응하는 블록체인 트랜잭션을 채굴하는 것에 응답하여, 방법은, 블록에의 트랜잭션의 포함을 확인하는 반환 머클(Merkle) 증명을 제공하는 단계를 더 포함하며, 반환 머클 증명은 다음 데이터 즉,
- 머클 증명이 관련된 블록체인 트랜잭션의 트랜잭션 식별자(TxID);
- 블록의 블록 헤더; 및
- 트랜잭션 식별자에 대한 형제 해시들의 어레이를 포함하는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
32. 조항 29 내지 조항 31 중 어느 한 조항에 제시된 방법에 있어서,
클라이언트 엔드포인트를 획득하는 단계;
클라이언트와 연관된 적어도 하나의 클라이언트 어드레싱 키를 획득하는 단계;
채굴자 엔드포인트를 제공하는 단계;
지불 프로세서와 연관된 적어도 하나의 채굴자 어드레싱 키를 제공하는 단계;
클라이언트 및 채굴자 어드레싱 키들에 기초하여 채널을 사용하여 하나 이상의 핸드셰이크 메시지들을 교환하는 단계;
핸드셰이크 결과 또는 패턴에 기초하여, 공유 비밀 키를 획득하는 단계를 더 포함하고,
채널을 사용한 임의의 통신은 공유 비밀 키에 기초하여 암호화되는,
블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
33. 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스로서,
메모리는 프로세서에 의한 실행의 결과로서 디바이스로 하여금 조항 1 내지 조항 8 중 어느 한 조항에 제시된 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 컴퓨팅 디바이스는 지불 프로세서와 관련되는,
컴퓨팅 디바이스.
34. 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스로서,
프로세서에 의한 실행의 결과로서, 디바이스로 하여금 조항 9 내지 조항 19 중 어느 한 조항에 제시된 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 컴퓨팅 디바이스는 채널 프로세서와 관련되는,
컴퓨팅 디바이스.
35. 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스로서,
프로세서에 의한 실행의 결과로서, 디바이스로 하여금 조항 20 내지 조항 28 중 어느 한 조항에 제시된 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 컴퓨팅 디바이스는 클라이언트와 관련되는,
컴퓨팅 디바이스.
36. 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스로서,
프로세서에 의한 실행의 결과로서, 디바이스로 하여금 조항 29 내지 조항 32 중 어느 한 조항에 제시된 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 컴퓨팅 디바이스는 채굴자와 관련되는,
컴퓨팅 디바이스.
37. 컴퓨터 시스템으로서,
무선 통신 네트워크를 통해 적어도 하나의 클라이언트 및 적어도 하나의 채굴자에 통신 가능하게 커플링된 지불 프로세서 ― 지불 프로세서는 조항 33에 제시된 바와 같은 컴퓨팅 디바이스에 따라 구현됨 ― ;
무선 통신 네트워크를 통해 지불 프로세서에 통신 가능하게 커플링되고 적어도 하나의 고객과 통신할 수 있는 클라이언트 ― 클라이언트는 조항 35에 제시된 컴퓨팅 디바이스에 따라 구현되고; 클라이언트는 무선 통신 네트워크를 통해 채널 프로세서에 통신 가능하게 커플링되고, 채널 프로세서는 조항 34에 제시된 바와 같은 컴퓨팅 디바이스에 따라 구현됨 ― ; 및
무선 통신 네트워크를 통해 지불 프로세서에 통신 가능하게 커플링된 복수의 채굴자들을 포함하고, 각각의 채굴자는 조항 38에 제시된 컴퓨팅 디바이스에 따라 구현되는,
컴퓨터 시스템.
38. 실행 가능한 명령들이 저장되어 있는 컴퓨터-판독 가능 저장 매체로서,
명령들은 컴퓨터의 프로세서에 의해 실행된 결과로서, 컴퓨터로 하여금 조항 1 내지 조항 32 중 어느 한 항의 방법을 수행하게 하는,
컴퓨터-판독 가능 저장 매체.
위에서 언급된 양상들 및 실시예들은 본 개시를 제한하기보다는 예시하고, 당업자는 첨부된 청구항들에 의해 정의된 바와 같은 본 개시의 범위로부터 벗어남이 없이 다수의 대안적인 실시예들을 설계할 수 있을 것이란 점이 주의되어야 한다. 청구항들에서, 괄호 안의 배치된 임의의 참조 부호들은 청구항들을 제한하는 것으로 해석되어서는 안 된다. "포함하는(comprising)" 및 "포함하다(comprises)" 등의 단어는 전체로서 명세서 또는 임의의 청구항에 나열된 것들 이외의 요소들 또는 단계들의 존재를 배제하지 않는다. 본 명세서에서, "포함하다(comprises)"는 "포함하거나 구성된다(includes or consists of)"를 의미하고 "포함하는(comprising)"은 "포함하거나 구성되는(including or consisting of)"을 의미한다. 요소의 단수 참조는 그러한 요소들의 복수 참조를 배제하지 않으며 그 반대의 경우도 마찬가지이다. 본 개시는 여러 별개의 요소들을 포함하는 하드웨어에 의해 그리고 적합하게 프로그래밍된 컴퓨터에 의해 구현될 수 있다. 여러 수단들을 열거하는 디바이스 청구항에서, 이들 수단들 중 여러 개는 하나의 그리고 동일한 하드웨어 아이템에 의해 구체화될 수 있다. 소정의 측정들이 서로 상이한 종속 청구항들에서 인용된다는 단순한 사실만으로 이 측정들의 결합이 유리하게 사용될 수 없다는 것을 나타내는 것은 아니다.

Claims (38)

  1. 블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법으로서,
    상기 방법은 지불 프로세서에 의해 구현되고,
    상기 하나 이상의 클라이언트들 중 주어진 클라이언트로부터 요청을 수신하는 단계 ― 상기 요청은 디지털 자산과 연관된 트랜잭션을 상기 블록체인에 제출하기 위한 것이고, 상기 요청은 상기 트랜잭션을 위해 상기 주어진 클라이언트와 다른 엔티티 사이의 직접 통신을 가능하게 하기 위한 콜-백 식별자(call-back identifier)와 연관됨 ― ;
    상기 블록체인에 상기 트랜잭션을 포함시키기 위해, 복수의 채굴자들 중 주어진 채굴자에게 상기 요청과 연관된 트랜잭션을 제출하는 단계;
    상기 클라이언트에 대해 상기 주어진 채굴자를 식별하는 단계;
    상기 채굴자에게 상기 콜-백 식별자를 제공하는 단계를 포함하고,
    상기 주어진 채굴자로부터의 요청에 대한 대응하는 블록체인 트랜잭션과 관련된 응답을 수신하는 것에 응답하여, 상기 방법은,
    상기 채굴자에 의해 제공되는 상기 대응하는 블록체인 트랜잭션과 관련된 적어도 하나의 콜-백 알림을 상기 클라이언트에 대해 가능하게 하거나 프로세싱하는 단계를 더 포함하고, 상기 콜-백 알림은 상기 요청과 연관된 콜-백 식별자에 기초하는,
    블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
  2. 제1 항에 있어서,
    상기 채굴자로부터의 수신된 응답은 트랜잭션 식별자(TxID)와 연관되고,
    상기 방법은,
    상기 대응하는 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 상기 클라이언트에 전송하는 단계를 더 포함하는,
    블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
  3. 전술한 청구항 중 어느 한 항에 있어서,
    상기 수신된 응답은 상기 블록체인 트랜잭션과 연관된 출력 스크립트이고, 상기 출력 스크립트는 상기 채굴자에 대한 멤풀(mempool)과 연관된 소비되지 않은 트랜잭션 출력(Unspent Transaction Output, UTXO)를 포함하고, 상기 UTXO는 상기 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 포함하는,
    블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
  4. 전술한 청구항 중 어느 한 항에 있어서,
    상기 지불 프로세서는 상기 하나 이상의 클라이언트들에 대한 REST(Representational State Transfer) 엔드포인트로서 구현되고, 상기 방법은,
    HTTPS(Hypertext Transfer Protocol Secure) 송신 프로토콜 포맷을 사용하여 상기 클라이언트로부터 상기 요청을 수신하는 단계;
    개개의 요청을 RPC(Remote procedure Call) 포맷으로 변환하고 상기 RPC를 상기 채굴자에게 제출하는 단계;
    상기 채굴자로부터 RPC 포맷으로 대응하는 블록체인 트랜잭션과 연관된 응답을 수신하는 단계; 및
    상기 HTTPS 송신 프로토콜을 사용하여 상기 클라이언트에 전송하기 위한 개개의 응답을 변환하는 단계를 수행하기 위해 상기 지불 프로세서와 연관된 API(application programming interface) 게이트웨이를 제공하는 단계를 더 포함하는,
    블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
  5. 전술한 청구항 중 어느 한 항에 있어서,
    상기 주어진 채굴자의 아이덴티티(identity)를 검증하는 단계를 포함하고,
    상기 검증은 상기 주어진 채굴자와 연관된 디지털 서명에 기초하거나 또는 상기 주어진 채굴자와 관련되는 식별자에 기초하고, 상기 식별자는 선택적으로 상기 주어진 채굴자에 대한 평판 표시자(reputation indicator)와 연관되는,
    블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
  6. 전술한 청구항 중 어느 한 항에 있어서,
    상기 콜-백 알림은 상기 주어진 클라이언트에 의해 제출된 트랜잭션의 이중 소비(double spend)의 알림과 관련되거나, 또는 상기 콜-백 알림은 상기 주어진 클라이언트에 의해 제출된 트랜잭션의 블록체인에의 포함 증명(proof of inclusion)과 관련되는,
    블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
  7. 전술한 청구항 중 어느 한 항에 있어서,
    상기 콜-백 식별자는 상기 클라이언트와 연관된 채널에 대한 로케이션이거나, 또는 상기 콜-백 식별자는 상기 클라이언트에 대한 URI(Universal Resource Identifier)인,
    블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
  8. 전술한 청구항 중 어느 한 항에 있어서,
    상기 채널에 대한 액세스를 상기 주어진 채굴자에게 제공하는 단계를 더 포함하고,
    상기 제공하는 단계는 상기 요청과 연관된 채널에 대한 채널 식별자 또는 로케이션, 및 상기 채널과 연관된 하나 이상의 액세스 토큰들을 상기 채굴자에게 제공하는 단계를 포함하는,
    블록체인과 연관된 트랜잭션들을 위해 하나 이상의 클라이언트들에 대한 지불 서비스를 제공하는 컴퓨터 구현 방법.
  9. 하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법으로서,
    상기 방법은 채널 프로세서에 의해 구현되고,
    상기 하나 이상의 클라이언트들 중 주어진 클라이언트로부터 요청을 수신하는 단계 ― 상기 요청은 채널의 생성과 관련됨 ― ;
    상기 채널을 통해 상기 주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 상기 주어진 클라이언트에 제공하는 단계 ― 상기 하나 이상의 기능들은,
    데이터의 송신을 위해 상기 채널과 관련된 채널 기능들 또는 절차들; 및/또는
    상기 채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함함 ― ;
    상기 채널에 대한 하나 이상의 액세스 토큰들을 발행하는 단계 ― 상기 하나 이상의 액세스 토큰들은 상기 채널을 통해 다른 엔티티와의 보안 통신을 위해 구성됨 ― ; 및
    상기 주어진 클라이언트에 대해 상기 채널과 연관된 하나 이상의 알림들을 저장 및/또는 제공하는 단계를 포함하는,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  10. 제9 항에 있어서,
    상기 하나 이상의 기능들은 상기 주어진 클라이언트에 대해 발행되거나 제공된 API(application programming interface)들이고, 상기 API들은 상기 채널에 대한 채널 API들 및 상기 채널과 연관된 데이터에 대한 메시지 API들을 포함하고; 상기 액세스 토큰들은 상기 채널 또는 주어진 메시지에 특유한 API 토큰들인,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  11. 제9 항 또는 제10 항에 있어서,
    하나 이상의 기능들에 대한 액세스를 제공하는 단계는 하나 이상의 채널들의 생성 및/또는 관리를 가능하게 하기 위해 JSON(JavaScript Object Notation)-오버(over)-HTTP(Hyper Text transfer protocol) API의 제공을 포함하는,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  12. 제9 항 내지 제11 항 중 어느 한 항에 있어서,
    상기 채널들과 연관된 상기 하나 이상의 알림들은 채굴자로부터의 콜-백 알림들이고, 상기 채굴자는 상기 채널을 통해 상기 주어진 클라이언트와 직접 통신하는 다른 엔티티인,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  13. 제12 항에 있어서,
    상기 콜-백 알림은 상기 주어진 클라이언트에 의해 제출된 트랜잭션의 이중 소비의 알림과 관련되는,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  14. 제13 항에 있어서,
    상기 콜-백 알림은 상기 채널의 반환 페이로드와 연관되며, 상기 반환 페이로드는 상기 채굴자에 의해 제공되고, 상기 반환 페이로드는 다음 데이터 즉,
    - 이중 소비인 블록체인 트랜잭션의 트랜잭션 식별자(TxID); 및 선택적으로
    - 상기 블록체인 트랜잭션을 제출한 지불 프로세서에 대한 서비스 엔드포인트를 포함하는,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  15. 제12 항에 있어서,
    상기 콜-백 알림은 블록체인에서 상기 주어진 클라이언트에 의해 제출된 트랜잭션의 포함 증명과 관련되는,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  16. 제15 항에 있어서,
    상기 콜-백 알림은 상기 채널의 반환 머클(Merkle) 증명과 연관되고, 상기 반환 머클 증명은 상기 채굴자에 의해 제공되고, 상기 반환 머클 증명은 다음 데이터 즉,
    - 상기 머클 증명이 관련된 블록체인 트랜잭션의 트랜잭션 식별자(TxID);
    - 상기 블록체인 트랜잭션이 포함되는 블록의 블록 헤더; 및
    - 상기 트랜잭션 식별자(TxID)에 대한 형제 해시들의 어레이를 포함하는,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  17. 제9 항 내지 제16 항 중 어느 한 항에 있어서,
    상기 클라이언트가 오프라인이거나 상기 채널 프로세서에 통신 가능하게 연결되지 않을 때, 상기 하나 이상의 콜-백 알림들은 상기 채널에서 상기 주어진 클라이언트에 대해 저장되거나 큐잉되는(queued) 데이터에 대한 푸시 알림들인,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  18. 제9 항 내지 제17 항 중 어느 한 항에 있어서,
    상기 클라이언트가 온라인이거나 상기 채널 프로세서에 통신 가능하게 연결될 때, 상기 하나 이상의 콜-백 알림들과 연관된 데이터가 상기 채널로부터 제공되거나 풀링되는(pulled),
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  19. 제9 항 내지 제18 항 중 어느 한 항에 있어서,
    상기 채널 프로세서는 지불 프로세서이거나 상기 지불 프로세서를 포함하고, 상기 방법은 제1 항 내지 제8 항 중 어느 한 항에 따라 상기 지불 프로세서에 의해 구현되는 방법을 포함하는,
    하나 이상의 클라이언트들에 대한 채널 서비스를 구현하기 위한 컴퓨터 구현 방법.
  20. 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법으로서,
    상기 방법은 클라이언트와 연관된 하나 이상의 프로세서들에 의해 구현되고,
    채널 서비스에 관한 채널 요청을 전송하는 단계 ― 상기 채널 서비스는 채널 프로세서에 의해 구현되고, 상기 요청은 다른 엔티티와의 통신을 위한 채널의 생성과 관련됨 ― ;
    주어진 클라이언트와 다른 엔티티 간의 직접 통신을 가능하게 하는 하나 이상의 기능들에 대한 액세스를 상기 채널 서비스로부터 획득하는 단계 ― 상기 하나 이상의 기능들은,
    데이터의 송신을 위해 채널과 관련된 채널 기능들 또는 절차들; 및/또는
    채널을 사용하여 송신되는 데이터와 관련된 메시지 기능들 또는 절차들을 포함함 ― ;
    하나 이상의 액세스 토큰들을 상기 채널 서비스로부터 획득하는 단계 ― 상기 액세스 토큰들은 다른 엔티티와의 보안 통신을 가능하게 함 ― ;
    디지털 자산과 연관된 트랜잭션을 상기 블록체인에 제출하라는 요청을, 지불 서비스를 구현하는 지불 프로세서에 전송하는 단계;
    상기 제출된 트랜잭션에 대응하는 블록체인 트랜잭션에 대한 트랜잭션 식별자(TxID)를 상기 지불 프로세서로부터 획득하는 단계;
    상기 지불 프로세서로부터의 응답에 기초하여 상기 대응하는 블록체인 트랜잭션과 연관된 채굴자를 식별하는 단계;
    상기 채널 프로세서로부터 수신된 하나 이상의 채널 기능들을 사용하여, 상기 식별된 채굴자와의 통신을 위한 주어진 채널을 생성하는 단계;
    상기 주어진 채널과 연관된 상기 하나 이상의 액세스 토큰들을 상기 채굴자에게 전송하는 단계;
    상기 주어진 채널과 연관된 적어도 하나의 콜-백 알림을 수신하는 단계를 포함하고, 상기 알림은 블록체인 트랜잭션과 연관된 상기 주어진 채널의 데이터와 관련되며, 상기 데이터는 상기 채굴자에 의해 제공되는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  21. 제20 항에 있어서,
    상기 클라이언트가 오프라인이거나 상기 채널 프로세서에 통신 가능하게 연결되지 않을 때, 상기 콜-백 알림들은 상기 주어진 채널에 큐잉되는 데이터 또는 메시지들에 대한 푸시 알림들로서 획득되는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  22. 제20 항 또는 제21 항에 있어서,
    상기 클라이언트가 온라인이거나 상기 채널 프로세서에 통신 가능하게 연결될 때, 상기 콜-백 알림들과 연관된 데이터가 상기 주어진 채널로부터 풀링되는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  23. 제20 항 내지 제22 항 중 어느 한 항에 있어서,
    상기 하나 이상의 기능들은 상기 주어진 클라이언트에 대한 API(application programming interface)들이고, 상기 API들은 하나 이상의 채널들의 생성 및/또는 관리를 가능하게 하기 위한 채널 API들; 및 상기 주어진 클라이언트 및 하나 이상의 다른 엔티티들이 메시지들을 교환하고 그리고/또는 상기 주어진 채널로부터 데이터를 판독하고 그리고/또는 상기 주어진 채널에 데이터를 기록하는 것을 가능하게 하기 위한 메시지 API들을 포함하고, 상기 액세스 토큰들은 주어진 채널 또는 주어진 메시지에 특유한 API 토큰들인,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  24. 제20 항 내지 제23 항 중 어느 한 항에 있어서,
    상기 채널 요청은 상기 채널 프로세서에 대한 HTTPS(Hypertext Transfer Protocol Secure) 송신 GET 요청이고, 상기 지불 프로세서에 대한 요청은 상기 지불 프로세서에 대한 HTTPS(Hypertext Transfer Protocol Secure) 송신 POST 요청인,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  25. 제20 항 내지 제24 항 중 어느 한 항에 있어서,
    클라이언트 엔드포인트를 제공하는 단계;
    상기 클라이언트와 연관된 적어도 하나의 클라이언트 어드레싱 키를 제공하는 단계;
    채굴자 엔드포인트를 획득하는 단계;
    상기 채굴자와 연관된 적어도 하나의 채굴자 어드레싱 키를 획득하는 단계;
    상기 클라이언트 및 채굴자 어드레싱 키들에 기초하여 상기 주어진 채널을 사용하여 하나 이상의 핸드셰이크 메시지들을 교환하는 단계;
    핸드셰이크 결과 또는 패턴에 기초하여, 공유 비밀 키를 획득하는 단계를 더 포함하고;
    상기 주어진 채널을 사용하는 임의의 통신은 상기 공유 비밀 키에 기초하여 암호화되는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  26. 제25 항에 있어서,
    상기 클라이언트 엔드포인트는 HTTP(Hyper Text Transfer Protocol) API(Application Programming Interface) 엔드포인트이고, 상기 클라이언트 엔드포인트는 HTTPS(HTTP Secure)를 사용하여 전달되는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  27. 제25 항에 있어서,
    상기 클라이언트 엔드포인트는 상기 주어진 채널을 사용하여 전송된 상기 주어진 클라이언트로부터의 메시지에 포함된 URL(Universal Resource Location)인,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  28. 제25 항 내지 제27 항 중 어느 한 항에 있어서,
    상기 클라이언트 엔드포인트는 상기 클라이언트와 연관된 별칭이고, 상기 별칭은 상기 클라이언트에 특유하고 별칭-기반 어드레싱 서비스에 의해 제공되며, 상기 어드레싱 서비스는 정의되거나 잘 알려진 로케이션으로부터 액세스 가능한 기계 판독 가능 자원을 갖고, 상기 기계 판독 가능 자원은 상기 클라이언트와 관련된 하나 이상의 능력들을 포함하고, 상기 별칭은 인증을 위한 비대칭 암호화 키 쌍과 연관되는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  29. 블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법으로서,
    상기 방법은 복수의 채굴자들 중의 채굴자와 연관된 하나 이상의 프로세서들에 의해 구현되고, 상기 복수의 채굴자들은 주어진 클라이언트에 대한 지불 서비스를 구현하는 적어도 하나의 지불 프로세서에 통신 가능하게 커플링되고,
    상기 방법은,
    상기 지불 프로세서로부터 상기 블록체인으로의 트랜잭션의 제출에 대한 요청을 수신하는 단계;
    상기 요청에 대응하는 블록체인 트랜잭션을 생성하는 단계;
    상기 블록체인 트랜잭션과 연관된 출력 스크립트(UTXO)를 상기 지불 프로세서로 전송하는 단계 ― 상기 출력 스크립트는 상기 대응하는 블록체인 트랜잭션과 연관된 트랜잭션 식별자(TxID)를 포함함 ― ;
    채널에 대한 액세스를 수신하는 단계 ― 상기 채널은 상기 주어진 클라이언트와의 직접 통신을 가능하게 함 ― ;
    상기 채널과 연관된 액세스 토큰에 기초하여, 상기 채널에서 콜-백 알림과 연관된 데이터를 제공하거나 기록하기 위한 메시지 기능 또는 메시지 API를 획득하는 단계를 포함하고, 상기 데이터는 상기 대응하는 블록체인 트랜잭션과 관련되는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  30. 제29 항에 있어서,
    상기 대응하는 블록체인 트랜잭션이 상기 클라이언트에 의해 제출된 이전 트랜잭션의 이중 소비라는 결정에 기초하여; 상기 방법은 반환 페이로드를 제공하는 단계를 더 포함하고, 상기 반환 페이로드는, 다음 데이터 즉,
    - 이중 소비인 주어진 블록체인 트랜잭션의 트랜잭션 식별자(TxID); 및 선택적으로
    - 상기 주어진 블록체인 트랜잭션을 제출한 상기 지불 프로세서에 대한 서비스 엔드포인트를 포함하는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  31. 제29 항에 있어서,
    블록에서 상기 대응하는 블록체인 트랜잭션을 채굴하는 것에 응답하여, 방법은, 블록에의 상기 트랜잭션의 포함을 확인하는 반환 머클 증명(return Merkle proof)을 제공하는 단계를 더 포함하며, 상기 반환 머클 증명은 다음 데이터 즉,
    - 상기 머클 증명이 관련된 블록체인 트랜잭션의 트랜잭션 식별자(TxID);
    - 상기 블록의 블록 헤더; 및
    - 상기 트랜잭션 식별자에 대한 형제 해시들의 어레이를 포함하는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  32. 제29 항 내지 제31 항 중 어느 한 항에 있어서,
    클라이언트 엔드포인트를 획득하는 단계;
    상기 클라이언트와 연관된 적어도 하나의 클라이언트 어드레싱 키를 획득하는 단계;
    채굴자 엔드포인트를 제공하는 단계;
    지불 프로세서와 연관된 적어도 하나의 채굴자 어드레싱 키를 제공하는 단계;
    상기 클라이언트 및 채굴자 어드레싱 키들에 기초하여 상기 채널을 사용하여 하나 이상의 핸드셰이크 메시지들을 교환하는 단계;
    핸드셰이크 결과 또는 패턴에 기초하여, 공유 비밀 키를 획득하는 단계를 더 포함하고,
    상기 채널을 사용한 임의의 통신은 상기 공유 비밀 키에 기초하여 암호화되는,
    블록체인과 연관된 트랜잭션들을 프로세싱하기 위한 컴퓨터 구현 방법.
  33. 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스로서,
    상기 메모리는 상기 프로세서에 의한 실행의 결과로서 상기 디바이스로 하여금 제1 항 내지 제8 항 중 어느 한 항에 청구된 바와 같은 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 상기 컴퓨팅 디바이스는 지불 프로세서와 관련되는,
    컴퓨팅 디바이스.
  34. 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스로서,
    상기 메모리는 상기 프로세서에 의한 실행의 결과로서, 상기 디바이스로 하여금 제9 항 내지 제19 항 중 어느 한 항에 청구된 바와 같은 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 상기 컴퓨팅 디바이스는 채널 프로세서와 관련되는,
    컴퓨팅 디바이스.
  35. 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스로서,
    상기 메모리는 상기 프로세서에 의한 실행의 결과로서, 상기 디바이스로 하여금 제20 항 내지 제28 항 중 어느 한 항에 청구된 바와 같은 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 상기 컴퓨팅 디바이스는 클라이언트와 관련되는,
    컴퓨팅 디바이스.
  36. 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스로서,
    상기 메모리는 상기 프로세서에 의한 실행의 결과로서, 상기 디바이스로 하여금 제29 항 내지 제32 항 중 어느 한 항에 청구된 바와 같은 컴퓨터-구현 방법을 수행하게 하는 실행 가능한 명령들을 포함하고, 상기 컴퓨팅 디바이스는 채굴자와 관련되는,
    컴퓨팅 디바이스.
  37. 컴퓨터 시스템으로서,
    무선 통신 네트워크를 통해 적어도 하나의 클라이언트 및 적어도 하나의 채굴자에 통신 가능하게 커플링된 지불 프로세서 ― 상기 지불 프로세서는 제33 항에 청구된 바와 같은 컴퓨팅 디바이스에 따라 구현됨 ― ;
    상기 무선 통신 네트워크를 통해 상기 지불 프로세서에 통신 가능하게 커플링되고 적어도 하나의 고객과 통신할 수 있는 클라이언트 ― 상기 클라이언트는 제35 항에 청구된 바와 같은 컴퓨팅 디바이스에 따라 구현되고; 상기 클라이언트는 상기 무선 통신 네트워크를 통해 채널 프로세서에 통신 가능하게 커플링되고, 상기 채널 프로세서는 제34 항에 청구된 바와 같은 컴퓨팅 디바이스에 따라 구현됨 ― ; 및
    상기 무선 통신 네트워크를 통해 상기 지불 프로세서에 통신 가능하게 커플링된 복수의 채굴자들을 포함하고, 각각의 채굴자는 제38 항에 청구된 바와 같은 컴퓨팅 디바이스에 따라 구현되는,
    컴퓨터 시스템.
  38. 실행 가능한 명령들이 저장되어 있는 컴퓨터-판독 가능 저장 매체로서,
    상기 명령들은 컴퓨터의 프로세서에 의해 실행된 결과로서, 상기 컴퓨터로 하여금 제1 항 내지 제32 항 중 어느 한 항의 방법을 수행하게 하는,
    컴퓨터-판독 가능 저장 매체.
KR1020227014309A 2019-09-30 2020-09-29 블록체인 트랜잭션들을 위한 콜-백 메커니즘들 KR20220076486A (ko)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
GB1914043.3 2019-09-30
GB201914043A GB201914043D0 (en) 2019-09-30 2019-09-30 Computer-implemented system and method
GB2007597.4 2020-05-21
GBGB2007597.4A GB202007597D0 (en) 2020-05-21 2020-05-21 Computer-implemented system and method
GBGB2010339.6A GB202010339D0 (en) 2020-07-06 2020-07-06 Computer-implemented system and method
GB2010339.6 2020-07-06
GB2015358.1 2020-09-29
GBGB2015358.1A GB202015358D0 (en) 2020-09-29 2020-09-29 Call-back mechanisms for blockchain transactions
PCT/IB2020/059095 WO2021064565A1 (en) 2019-09-30 2020-09-29 Call-back mechanisms for blockchain transactions

Publications (1)

Publication Number Publication Date
KR20220076486A true KR20220076486A (ko) 2022-06-08

Family

ID=72826924

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227014309A KR20220076486A (ko) 2019-09-30 2020-09-29 블록체인 트랜잭션들을 위한 콜-백 메커니즘들

Country Status (5)

Country Link
US (1) US20220405748A1 (ko)
JP (1) JP2022549624A (ko)
KR (1) KR20220076486A (ko)
TW (1) TW202130153A (ko)
WO (1) WO2021064565A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115842813A (zh) * 2021-09-18 2023-03-24 华为技术有限公司 通信方法以及相关装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES231501Y (es) 1977-10-20 1978-04-16 Numerador de funcionamiento automatico perfeccionado.
EP4344130A3 (en) * 2017-06-14 2024-06-12 nChain Licensing AG Systems and methods for addressing security-related vulnerabilities arising in relation to off-blockchain channels in the event of failures in a network
US10528551B2 (en) * 2017-09-29 2020-01-07 Oracle International Corporation System and method for providing a representational state transfer proxy service for a blockchain cloud service
WO2019092508A2 (en) * 2017-11-07 2019-05-16 Khalil Ramy Abdelmageed Ebrahim System and method for scaling blockchain networks with secure off-chain payment hubs

Also Published As

Publication number Publication date
US20220405748A1 (en) 2022-12-22
WO2021064565A1 (en) 2021-04-08
JP2022549624A (ja) 2022-11-28
TW202130153A (zh) 2021-08-01

Similar Documents

Publication Publication Date Title
US20220215132A1 (en) Methods and systems for using digital signatures to create trusted digital asset transfers
US11159537B2 (en) Multicomputer processing for data authentication and event execution using a blockchain approach
EP3424176B1 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
WO2017107976A1 (zh) 用于授权访问的客户端装置、服务器装置和访问控制***
CN113056741B (zh) 基于分布式账本的简档验证
KR20190099076A (ko) 전자 어음 관리 방법, 장치 및 기록매체
KR20210128455A (ko) 블록체인 네트워크를 통한 이전을 구현하는 컴퓨터 구현 시스템 및 방법
US20220303258A1 (en) Computer-implemented system and method
WO2020212447A1 (en) Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys
CN111095863A (zh) 在区块链网络上通信、存储和处理数据的基于区块链的***和方法
US20230095123A1 (en) Systems and Methods for Digitally Signed Contracts with Verifiable Credentials
CN114341908A (zh) 具有要约和接受的区块链交易的***和方法
US11038685B1 (en) Correcting blockchain transactions with cryptocurrency type mistakes
US11556959B2 (en) Internet data usage control system
JP2018533131A (ja) 認証サービス顧客データの管理方法及びシステム
CN114567643A (zh) 跨区块链的数据流转方法、装置及相关设备
KR20220071241A (ko) 컴퓨터-구현 시스템 및 방법
TW202139668A (zh) 用於與區塊鏈相關聯之多個服務之平台
KR20220076486A (ko) 블록체인 트랜잭션들을 위한 콜-백 메커니즘들
WO2023244993A1 (en) Systems and methods for mitigating network congestion on blockchain networks by supporting blockchain operations through off-chain interactions
EP4038829A1 (en) Call-back mechanisms for blockchain transactions
Hardjono et al. Privacy-preserving claims exchange networks for virtual asset service providers
JP7508521B2 (ja) ブロックチェーンネットワークを介してデータを通信し、格納し、及び処理するためのブロックチェーンベースのシステム及び方法
TW202205834A (zh) 電腦實施系統及方法
US20240054458A1 (en) Systems and methods for securely sharing public blockchain addresses