TW202130153A

TW202130153A - 區塊鏈交易之回叫機制

Info

Publication number: TW202130153A
Application number: TW109134230A
Authority: TW
Inventors: 史帝芬歌芙蘭; 都蘭威爾聖哈; 安布魯斯沙拉; 安德魯Ｊ美伊
Original assignee: 安地卡及巴布達商區塊鏈控股有限公司
Priority date: 2019-09-30
Filing date: 2020-09-30
Publication date: 2021-08-01
Also published as: JP2022549624A; WO2021064565A1; KR20220076486A; US20220405748A1

Abstract

在一態樣中，本揭露內容提議用於處理與一用戶端相關聯的區塊鏈交易之方法、裝置及系統。一支付服務經實施為一或多個用戶端可存取之一閘道器或一API端點。用以提交自一給定用戶端接收之一交易之一請求係與一回叫識別符相關聯。該回叫識別符使得其實現該給定用戶端與另一實體之間的直接通訊，該另一實體諸如一挖掘者或另一對方。支付處理器將該交易提交至一挖掘者，此提交與該回叫識別符相關聯。接著，一旦一挖掘者創建了一對應的區塊鏈交易，則可使用該回叫識別符直接自該挖掘者向該用戶端提供與該對應的區塊鏈交易相關之一回叫通知。

Description

區塊鏈交易之回叫機制

發明領域

本揭露內容大體上係關於用於為一或多個用戶端實施支付服務或支付介面之方法及系統。本揭露內容尤其係關於(但不限於)為或代表一或多個用戶端實現與區塊鏈或分散式分類帳相關聯的安全且可靠的支付交易，該等交易關於與客戶或付款人實體相關聯的數位資產支付。

發明背景

在此文件中，吾人使用術語「區塊鏈」來包括所有形式的基於電腦之電子分散式分類帳。此等分類帳包括基於共識之區塊鏈及交易鏈技術、許可及未許可分類帳、共用分類帳、公用及私用區塊鏈及其變化。區塊鏈技術之最廣泛已知之應用為比特幣分類帳，但已提議並開發了其他塊鏈實施。儘管可在本文中出於便利性及說明的目的提及比特幣，但應注意，本揭露內容不限於關於比特幣區塊鏈之使用，且與數位資產之任何種類或數位資產之表示相關聯的替代區塊鏈實施及協定屬於本揭露內容之範疇內。術語「用戶端」、「實體」、「節點」、「使用者」、「發送者」、「接收者」、「付款人」、「收款人」在本文中可指基於計算或處理器之資源。術語「比特幣」在本文中用以包括源自或基於比特幣協定之任何版本或變化。術語「數位資產」可指任何可轉移資產，諸如密碼貨幣、表示財產之至少一部分之符記、智慧型合約、許可證(亦即軟體許可證)，或用於媒體內容之DRM合約等。應理解，術語數位資產在整個本文件中用於表示商品，其可與可轉移至自一個實體至另一實體之交易中之支付或作為支付提供之值相關聯。

區塊鏈為同級間電子分類帳，其經實施為由區塊構成之基於電腦之去中心化分散式系統，該等區塊又由交易構成。每一交易為一資料結構，且包括至少一個輸入及至少一個輸出，該資料結構編碼區塊鏈系統中之參與者之間的數位資產之控制的轉移。每一區塊含有先前區塊之散列，使得區塊變為鏈接在一起以產生自一開始便已寫入至區塊鏈之所有交易的永久性不可變更之記錄。交易含有嵌入至其輸入及輸出中的被稱為指令碼的小型程式，其指定可如何及由誰存取交易之輸出。在比特幣平台上，此等指令碼係使用基於堆疊之指令碼處理語言來撰寫。

對於交易而言，為了寫入至區塊鏈，交易必須經「驗證」。網路節點(挖掘者(miner))執行工作以確保每一交易有效，其中由網路拒絕無效交易。安裝於節點上之軟體用戶端藉由執行其鎖定及解除鎖定指令碼而對未用交易(UTXO)執行此驗證工作。若鎖定及解除鎖定指令碼之執行評估為真，則交易係有效的且接著將交易寫入至區塊鏈。因此，為了將交易寫入至區塊鏈，其必須i)由接收交易之第一節點驗證—若該交易經驗證，則節點將其中繼至網路中之其他節點；且ii)經添加至由挖掘者建構之新的區塊；且iii)經挖掘，亦即，經添加至過去交易之公用分類帳。

一旦作為UTXO儲存在區塊鏈中，使用者可將相關聯資源之控制轉移至與另一交易中之輸入相關聯的另一位址。此轉移通常而非基本上使用數位電子錢包進行。此數位電子錢包可為裝置，實體媒體，程式，諸如桌上型電腦、膝上型電腦或行動終端等計算裝置上之應用程式(app)，或與網路工作，諸如網際網路上之域相關聯之遠端代管服務。數位電子錢包儲存公用及私用密鑰且可用以追蹤與使用者相關聯之資源、符記及資產等之所有權；接收或使用數位資產；轉移可與數位資產，諸如密碼貨幣或許可證或財產或其他類型之資源有關的符記。

儘管區塊鏈技術由於密碼貨幣實施之使用而為最廣泛已知的，但數位企業家正在探索比特幣所基於之密碼安全系統及可儲存於區塊鏈上以實施新系統之資料二者的使用。區塊鏈技術在區塊鏈可用於不限於密碼貨幣範圍之自動任務及程序時非常有利。此類解決方案將能夠利用區塊鏈之益處(例如，事件之永久性防篡改記錄、分散式處理等)，同時在其應用中變得更通用。

當前研究之一個領域係使用區塊鏈實施「智慧型合約」。此等智慧型合約係經設計以使機器可讀合約或協定之條款之執行自動化的電腦程式。不同於將以自然語言撰寫之傳統合約，智慧型合約係包含可處理輸入以產生結果之規則的機器可執行程式，該等規則接著可取決於彼等結果而使得執行動作。區塊鏈相關關注之另一領域係使用「符記」(或「彩色幣」)以經由區塊鏈表示及轉移真實世界實體。潛在地敏感或秘密之項目可由符記表示，符記不具有可辨別之含義或值。符記因此充當允許自區塊鏈引用現實世界項目之識別符。

上文提及的實例或情境係關於某一資產(亦即數位資產)之轉移或使用者或實體之間的數位資產之控制。因此，需要實施安全並且穩健的系統，該系統類似於現有支付或電子商務系統，其用於在二個實體之間交換資金—尤其用於可尊重現實世界中之資產的商家與客戶之間的數位資產支付，且具有更佳的使用者體驗、更便宜的商家或收款人成本及更高的安全等級。更特定而言，需要利用分散式分類帳(區塊鏈)技術及記錄的安全性、透明度及可靠性增加之優點以提供共同平台或介面，其使得任何商家或多個商家能夠確保與其各別客戶之數位資產支付可瞬時並且安全地經挖掘或寫入至區塊鏈中，藉此提供此類支付的持續的防篡改並且可稽核的記錄。

現在已設計出此改良之解決方案。本揭露內容藉由提出技術來解決此等技術問題，用於一或多個用戶端(亦即商家或收款人實體，其為諸如密碼貨幣之數位資產的接收者)之交易可藉由該等技術藉由提供用於此類用戶端之應用程式設計介面(API)的方法、技術及裝置而瞬時寫入至區塊鏈中。在此類技術中，挖掘者將能夠動態地或立即將交易挖掘或寫入至區塊鏈中，亦即以安全並且可靠的方式為用戶端提供允許即時交易或零確認(0-conf)交易之服務。

發明概要

在一個態樣中，本揭露內容提議用於處理與一用戶端相關聯的區塊鏈交易之與一支付服務相關聯的方法、裝置及系統。該支付服務經實施為一或多個用戶端可存取之一閘道器或一API端點。在本發明方法中，用以提交自一給定用戶端接收之一交易之一請求係與一回叫識別符相關聯。該回叫識別符使得其實現在該給定用戶端與另一實體之間的直接通訊。該支付處理器將該交易連同該回叫識別符提交至一挖掘者。接著，一旦一挖掘者創建了一對應的區塊鏈交易，則可直接自該挖掘者向該用戶端提供與該對應的區塊鏈交易相關之一回叫通知。

在另一態樣中，來自該用戶端之該請求係與一通道相關聯，該通道由一通道服務提供並且與一或多個功能相關聯，該一或多個功能實現該用戶端與另一實體之間的直接通訊。在此狀況下，該用戶端亦具備用於該通道之一或多個存取符記及應用程式設計介面(API)。接著可基於此等存取符記及/或API由該用戶端向另一實體提供對該通道之存取，該另一實體諸如已經被識別為挖掘用於該用戶端之一交易之實體的一挖掘者。此使得與一對應的區塊鏈交易相關之資料能夠藉由另一實體直接寫入至該通道中。特定針對於該對應的交易之一回叫通知接著可經由該通道服務提供。此使得每當需要時或每當有可能如此進行時，諸如當用戶端在線上且經由網路與該通道服務通訊時，與該給定交易相關聯的資料能夠由該用戶端直接自該通道存取。在一些狀況下，該通道服務可由一通道處理器實施。該通道處理器可為與上文所提及之該支付處理器相同的實體，或可為與該支付處理器分離的一實體。

在本說明書通篇中，詞語「包含(comprise)」或諸如「包括」、「包含(comprises)」或「包含(comprising)」之變化形式應理解為暗示包括所陳述之要素、整數或步驟、或要素、整數或步驟之群組，但不排除任何其他要素、整數或步驟、或要素、整數或步驟之群組。

較佳實施例之詳細說明

雖然所附申請專利範圍與下文詳細描述的本揭露內容之第四態樣有關，但本文中提供了對第一、第二及第三態樣的詳細論述，以向讀者提供對本揭露內容之所要求保護的態樣及相關實施例之全面及完整的理解。

根據第一態樣，本揭露內容提供一種電腦實施之方法，其針對與區塊鏈相關聯的交易為一或多個用戶端實施支付服務，該方法由與支付服務相關聯的支付處理器實施。在一些實施例中，其中用戶端可為計算資源或節點，或實體，其可與用於接受及/或處理密碼貨幣支付之數位電子錢包相關聯且可與用於此類電子錢包之公用密鑰或公用位址相關聯。在一些實施例中，用戶端可表示商家實體或終端，諸如銷售點裝置，其可在現實世界中提供商品或服務，並接收此類商品或服務的數位資產付款，但不限於此。在一些實施例中，支付處理器經組配以提供用於一或多個用戶端的支付介面作為相關聯服務或第三方服務。在一些實例中，支付處理器被稱為支付聚合器，此係因為其經由用於用戶端以及挖掘者的一或多個使用者友好介面提供與區塊鏈相關聯的多個支付服務及功能。在一些實施例中，支付處理器經實施為用於為一或多個用戶端提供基於網路之交互(亦即經實施為網路服務)之應用程式設計介面(API)，使得通訊可使用用於基於網路之服務的標準網際網路通訊協定，諸如HTTPS、TCP/IP等經由網際網路進行。此API係已知的，或可用於與支付處理器相關聯的一或多個用戶端，或經發送/提供至該一或多個用戶端。在一些實施例中，可在登記或註冊程序後將此API提供至用戶端以存取由支付處理器提供的服務或功能。在一些實例中，可經由諸如Swagger的API使用者介面提供或公開供用戶端使用的API，該API為用於希望存取基於網路之服務的用戶端或其他實體之眾所周知的API設計及開發工具或介面。

第一態樣之方法包含以下步驟：自多個挖掘者當中的各挖掘者獲得費用報價，以用於挖掘交易。回應於來自用戶端之用於與挖掘交易相關聯的挖掘費用報價的第一請求而進行此步驟。在一些實施例中，挖掘者為由一或多個處理器實施的節點，該等處理器被委託進行鎖定及解除鎖定指令碼的驗證，以及將交易挖掘或寫入至區塊鏈中，如上文同樣在背景技術部分中所解釋。舉例而言，若比特幣中本聰願景(BSV)為將交易或轉移的密碼貨幣或數位資產，則挖掘者可被稱作BSV節點。第一態樣之方法包括將經獲得費用報價提供給用戶端的步驟。在一些實施例中，費用報價係關於挖掘者為將交易挖掘至區塊鏈中而收取的當前費用，而不論與交易相關的內容或涉及的各方。在其他實施例中，可將費用報價定製為基於可在請求中識別的給定交易。在一些實施例中，支付處理器可將所有經接收費用報價提供至用戶端，或可提供一或多個推薦的費用報價以與經獲得費用報價一起提供至用戶端。

有利地，藉由實施作為一或多個用戶端(亦即商家或收款人實體，其為諸如比特幣SV (BSV)之類的密碼貨幣之數位資產的接收者)的API提供之支付服務，第一態樣的方法藉由允許用戶端註冊或使用支付處理器提供的網路服務而允許幾乎瞬時挖掘支付交易(經寫入至區塊鏈中)或在礦工解決工作證明難題後儘快挖掘交易。藉由提供當前費用報價，理論上，給定挖掘者同意或承諾將交易添加至給定挖掘者將以彼費用挖掘的下一個區塊。有利地，此意謂用戶端，亦即商家實體，不再需要等待挖掘者的任何確認。因此，有利地，可實施與用戶端及各別挖掘者相關聯的0-conf交易。使用支付服務API的用戶端之身份可有利地保持匿名，而與用戶端相關聯的所有交易仍可由多個挖掘者當中的一個挖掘者可靠地挖掘，此滿足或符合所選擇挖掘費用報價。因此，在無需實施任何額外處理或網路連接資源之情況下並且藉由利用提議的支付服務API，個別用戶端或商家可利用透明性、可靠性及提供與各別用戶端相關聯的所有支付之不可修改且可驗證的記錄的益處。

在第一態樣之一些實施例中，回應於來自用戶端的提交與經獲得費用報價中當的所選擇的費用報價有關或包括所選擇的費用報價的給定交易之第二請求，該方法包括將請求發送至多個挖掘者當中的一或多個挖掘者以產生用於給定交易之區塊鏈交易。

在一些實施例中，所選擇的費用報價係自用戶端接收，並且被選擇用於給定的交易，鑒於購自用戶端的需要數位資產支付之商品或服務，此又可與用戶端與另一節點或實體(諸如用戶端之客戶)之間的支付請求或支付交易相關。該方法接著包括自滿足所選費用報價的多個挖掘者之的至少一個挖掘者接收與區塊鏈交易相關聯的輸出指令碼，例如UTXO。舉例而言，在一些實施例中，為了滿足費用報價，至少一個挖掘者應已經提供當前費用報價或與當前費用報價相關聯，該當前費用報價的值大於或小於所選擇的費用報價，並且在一些狀況下，大於所選擇的費用報價，此取決於一或多個規則或與用戶端相關聯的預定標準。該方法接著包括將結果發送至用戶端，該結果包括與給定交易(亦即，用戶端與客戶之間的支付)有關的區塊鏈交易之交易識別符(TxID)。

有利地，本揭露內容的API可實施為表示狀態傳送(REST)端點，藉此允許用戶端使用標準網際網路或基於網路之協定(諸如HTTPS)進行通訊。此外，有利地，第一態樣之支付服務使得能夠基於所選擇的費用報價立即創建與數位資產支付相關聯的對應交易並將其立即寫入至區塊鏈中。基於由用戶端或代表用戶端之支付處理器選擇的所選費用報價來挖掘交易，有利地使得多個挖掘者當中的至少一個挖掘者能夠幾乎立即或儘快將交易挖掘或寫入至區塊鏈中，已確保給定的挖掘者將以匹配或符合用戶端選擇的費用報價之當前費用報價來挖掘交易。因此，支付服務API的優點為允許在區塊鏈中以安全並且可靠的方式為用戶端挖掘即時交易或零確認交易(0-conf)，而用戶端不必等待挖掘者確認交易確實已添加至區塊，並將在區塊鏈中進行挖掘。此係因為給定的挖掘者已經指示，該給定的挖掘者可回應於第一請求，藉由發送用於挖礦交易的當前費用報價來執行挖掘。第一態樣之方法降低了與允許挖掘即時交易相關聯的雙重花費風險，此係因為根據第一態樣之挖掘將基於由用戶端選擇的或針對用戶端選擇的所選費用報價進行。因此，只有符合所選擇的費用報價之挖掘者才可挖掘交易，並且一旦滿足費用報價之第一挖掘者將交易添加至與區塊鏈相關聯的區塊中，其他挖掘者就無法挖掘該交易。

根據第一態樣之提供由支付處理器實施的支付服務之方法的一些實施例包含基於判定向用戶端提議的推薦費用來提供經獲得交易挖掘費用報價，其中經判定費用可為來自多個挖掘者之經獲得費用報價之平均值或經獲得費用報價之最大值。有利地，為了避免雙重花費，支付處理器可推薦回應於第一請求而以自多個挖掘者獲得的最高費用值提交交易。如此，可為所有挖掘者提供以其各別當前報價費用挖掘彼交易的相等的機會。然而，若建議以等於或高於經接收之所有費用報價的中位值或平均值之費用提交交易，則報價較高的挖掘者可簡單地將彼交易保存在記憶體池(諸如輔助記憶體池)中並使用其檢查並拒絕交易的任何雙重花費。若所選擇的費用報價係基於經推薦費用報價，或若推薦為用戶端選擇的一部分，則類似的優點亦適用。

有利地，支付處理器推薦費用報價，用戶端接著可選擇該費用報價為所選擇的費用報價，在一些實施例中，該費用報價為用戶端為向用戶端提交與數位資產支付相關聯的交易而願意支付的最大值。若用戶端為計算上不成熟的用戶端，或若用戶端已預先判定支付處理器將提供推薦，而非自己選擇費用報價，則此係有利的。因此，有利地，用戶端可基於推薦的費用報價來選擇費用報價，而非應用新的或單獨的試探法或計算來選擇費用報價，或者任意地選擇費用報價。

在一些實施例中，當自支付服務(亦即由支付處理器提供的API)提供推薦或經推薦費用報價時，可提供此經推薦費用報價，或可提供所有經獲得費用報價，其包括經推薦費用報價，經推薦費用報價包含識別符。有利地，藉由提供推薦以及所接收的所有費用報價，支付處理器為用戶端提供了使用經推薦費用報價來提交交易或選擇與經接收其他費用報價不同的費用報價的選項。

在一些實施例中，該方法包含以下步驟：在提供各別費用報價的多個挖掘者中驗證給定挖掘者之身份，其中基於與給定挖掘者相關聯的數位簽名來驗證該身份。可使用密碼密鑰對(包括與各挖掘者相關聯的私用密鑰及公用密鑰(或公共位址))來驗證費用報價確實源自給定的挖掘者，亦即其中由私用密鑰簽名的資料僅可使用對應的公用密鑰進行恢復或驗證。若驗證係基於數位簽名，則可使用並實施標準的公用密鑰基礎結構(PKI)技術。

在其他實施例中，另外或替代地，關於給定挖掘者的識別符可用於驗證挖掘者的身份。在一些實施例中，該方法包括支付處理器，諸如MinerID。在一些實施例中，該識別符可與給定挖掘者的信譽指示符相關聯。在一些實施例中，MinerID可基於給定挖掘者為其一部分之挖掘池或可特定針對於給定挖掘者。信譽指示符與挖掘者績效的量度有關。舉例而言，在一些實例中，該信譽可基於給定挖掘者過去如何以報價的費用執行或挖掘交易。舉例而言，信譽指示符可指示良好的信譽，例如，若挖掘者定期以彼挖掘者報價的可接受費用範圍內之費用挖掘交易，則信譽值較高。在一些實施例中，挖掘者之信譽得分或指示符可由以通訊方式耦接至該挖掘者的至少一個支付處理器來計算，維護且管理。

在一些實施例中，由支付處理器實施之第一態樣之方法可包括以下步驟：基於挖掘者簽名來校驗自多個挖掘者當中的給定挖掘者獲得的費用報價，該挖掘者簽名不同於使用PKI技術驗證給定挖掘者之身份的數位簽名。支付處理器用於校驗步驟的挖掘者簽名有利地指示或充當挖掘者對以提供給支付處理器的各別費用報價挖掘交易的承諾。挖掘者簽名的存在亦可有利地用於確認挖掘者將拒絕任何衝突的交易。因此，基於挖掘者簽名的校驗步驟有利地確保給定挖掘者將把交易包括在用於挖掘的區塊中，並且確保其將不包括任何衝突的交易。在一些實施例中，基於由給定挖掘者提供的此類保證來監視給定挖掘者的績效可界定或影響與給定挖掘者相關聯的挖掘者信譽或得分。

在一些實施例中，由多個挖掘者當中的各挖掘者提供的費用報價作為包括費用報價的值之資料類型被提供給支付處理器。在一些實施例中，資料類型呈JavaScript物件表示法(JSON)物件格式。

在一些實施例中，在支付處理器處自至少一個挖掘者接收到的輸出指令碼為與至少一個挖掘者的記憶體池相關聯的未使用交易輸出(UTXO)，該UTXO包括用於區塊鏈交易的交易識別符(TxID)，其中區塊鏈交易與用戶端與客戶之間的數位資產支付有關。

在一些實施例中，為了使用戶端能夠有利地識別或追蹤與同客戶的給定支付交易有關的區塊鏈交易或與該用戶端相關聯的任何交易，該方法包含將請求發送至多個挖掘者以用於獲得用於交易識別符之對應的區塊鏈交易之步驟，此請求由支付處理器回應於與來自用戶端的與交易識別符相關聯的狀態查詢而發送給至少一個挖掘者。作為回應，支付處理器獲得先前自多個挖掘者當中的至少一個挖掘者產生的對應的區塊鏈交易。基於至少一個挖掘者的區塊鏈交易之挖掘狀態，該方法包括以下步驟：將與經獲得區塊鏈交易有關的狀態結果與交易識別符相關聯地發送給用戶端。結果可指示區塊鏈交易是否已經被挖掘，亦即完成或由於某種原因而被拒絕，或者為無效的，因為該區塊鏈交易可能已經在此給定挖掘者之前被多個挖掘者當中的另一個挖掘者挖掘。若不同的挖掘者已經為特定的交易完成了挖掘，則此將有利地避免雙重花費。在一些實施例中，挖掘者可維護尚未添加至區塊或尚未在輔助記憶體池中挖掘的交易，該輔助記憶體池可為或充當替代或額外的記憶體池，同與挖掘者相關聯的主記憶體池分開。輔助記憶體池可為臨時記憶體池，使得可檢查TxID的雙重花費。有利地，此確保即使給定挖掘者未挖掘交易，但該交易仍保留在輔助記憶體池中，並在將來用於檢查且拒絕重複花費。在給定挖掘者的輔助記憶體池中，保持未由給定挖掘者進行挖掘或未打算由給定挖掘者進行挖掘的交易可能會有時間限制。在一些實施例中，儲存在輔助記憶體池中的交易可與到期時間相關聯，在此之後該等交易將被清除。在一些實施例中，可能存在與挖掘者將給定挖掘者未挖掘的交易儲存在其各別輔助記憶體池中相關聯的單獨費用。

在一些實施例中，第一態樣之方法進一步包含以下步驟：提供與支付處理器相關聯的應用程式設計介面(API)轉換器，以用於執行接收針對費用報價之第一請求、提交與用於用戶端之數位資產支付相關聯的交易之第二請求及/或呈超文件安全傳送協定(HTTPS)格式之來自用戶端之交易的狀態查詢之步驟；接著在將RPC發送至多個挖掘者之前將該等交易轉換為遠端程序呼叫(RPC)格式。此係有利的，因為其允許用戶端使用基於網路之API經由HTTPS傳達與區塊鏈相關聯的請求，並無縫地提供與不使用網路服務的網際網路協定通訊標準進行通訊的多個挖掘者的互操作性。舉例而言，當前所有的BSV挖掘者或實施都使用遠端程序呼叫。在此實施例中實施的API轉換器不限於HTTPS至RPC的轉換，反之亦然，或亦可設想的其他基於網路之協定至由個別挖掘者或給定的密碼貨幣或數位資產支援的替代通訊協定。在反向流動路徑中，第一態樣之方法亦包括以RPC格式自多個挖掘者當中的一或多個挖掘者接收與對應的區塊鏈交易相關聯的回應，並相應地使用HTTPS為用戶端轉換各別回應。因此，當用戶端(收款人)及挖掘者使用不同的無線資料通訊協定及機制時，藉由支付處理器有利地實施所提議的介面使得能夠進行無縫通訊以將交易提交至區塊鏈。

在一些實施例中，可提供與支付處理器相關聯的API閘道器。在此類實施例中，上文所提及的API轉換器可與API閘道器相關聯。另外，在一些實施例中，API閘道器亦可在一或多個計算裝置中實施以執行/負責功能，該等功能包括但不限於以下中之一或多者： -交易之高速緩存 -在挖掘者節點發生故障之狀況下執行彈性功能 -記錄一或多個端點或URL，該等端點或URL可用於向/自支付處理器及/或用戶端及/或挖掘者節點發送訊息或通知 -提供彈性特徵，以包括追蹤由於某種原因未能提交的交易。在一些實例中，此可包括在支付處理器處保持或由其設定的可組配參數；以及清除彼等已過期的經追蹤交易的機制。API閘道器亦可與在故障情境下重新提交交易的功能相關聯，藉此提供用於對真正交易進行錯誤處置並區分雙重花費的功能。

根據第二態樣，本揭露內容提供一種用於處理與區塊鏈相關聯之交易之方法，該方法由與用戶端相關聯的一或多個處理器實施，該用戶端以通訊方式耦接至為用戶端實施支付服務之至少一個支付處理器。在一些實施例中，該支付處理器經組配以實施上文所闡述之第一態樣及相關聯實施例的方法。用戶端(亦即商家)實施之第二態樣之方法包含將第一請求發送至至少一個支付處理器當中的支付處理器之步驟，該請求與用於經由支付處理器挖掘待自多個挖掘者獲得之交易或多個交易之一或多個費用報價相關。如上文所提及，經獲得費用報價與挖掘任何交易有關，或可特定於與來自客戶之數位數位支付有關的給定交易。

在第二態樣之一些實施例中，回應於自支付處理器接收一或多個費用報價，該方法包括選擇一或多個經接收費用報價當中的費用報價。如所提及，在第一態樣中，所選擇的費用報價可或可不基於支付處理器的推薦。第二態樣之方法接著包含請求及/或處理來自客戶之數位資產支付，該請求與所選擇的費用報價相關聯。在一些實施例中，此請求類似於支付請求或由用戶端發出至客戶以用於數位資產支付的發貨單。舉例而言，用戶端可為與數位電子錢包相關聯的咖啡館終端，且客戶可回應於此請求而為咖啡支付例如2個中本聰幣(satoshis)，該客戶亦與數位電子錢包相關聯。由於現在選擇了所選擇的費用報價，因此可將其添加至客戶的支付請求中。接著，該方法包括將與上文所提及的客戶支付相關聯的針對給定交易之第二請求提交至支付處理器，該提交係基於用於挖掘給定交易之所選擇的費用報價。在一些實施例中，所選擇的費用報價被清楚地指示或包括在第二請求中，使得支付處理器能夠有利地識別可以所選擇的費用報價或低於所選擇的費用報價挖掘交易之挖掘者，者另外或替代地，能夠使挖掘者識別其是否符合所選擇的費用報價。

如上文所提及，在一些實施例中，用戶端可基於自支付處理器接收的最高費用報價的值來選擇費用報價，或可處於或接近於所接收的費用報價的值之平均值或中位值。與任一選項相關聯的優點與上文所論述相同，亦即最大值允許所有挖掘者都有機會進行挖掘，且其他值將挖掘限於某些藉由能夠以所選擇的報價或低於所選擇的報價來挖掘交易而符合費用報價之挖掘者，而無法挖掘交易之彼等挖掘者(例如，因為報價太高)仍然可在臨時儲存裝置(諸如輔助記憶體池)中維護區塊鏈交易的記錄，使得此可用於驗證給定交易是否有任何雙重花費。

在第二態樣之一些實施例中，該方法亦包括接收用於已經由至少一個挖掘者產生的區塊鏈交易之交易識別符，該區塊鏈交易對應於經提交交易，亦即用戶端與客戶之間的交易。在一些實施例中，該方法包括發送與經獲得交易識別符相關聯的狀態查詢；以及獲得對應於該交易識別符之用於區塊鏈交易之狀態結果。

與第二態樣相關聯的優點係與上文關於第一態樣所論述之優點有關。第二態樣係與第一態樣互補，但描繪由用戶端實施之方法，該方法請求待寫入至區塊鏈中之交易。實施第二態樣之方法之用戶端可在一些實施例中與至少一個支付處理器通訊，該至少一個支付處理器經組配以根據第一態樣之方法將支付服務實施為支付API。

另外，本態樣之方法有利地允許用戶端選擇待提供給支付服務的費用報價，此提供了用戶端或商家控制，或以適時方式以給定挖掘費用挖掘其交易的影響確定性，藉此為針對利用經建議支付服務或支付API的用戶端挖掘的交易提供增加的安全性、互操作性、可靠性、效率及及時性。

如上文所提及，由於由支付處理器實施的支付服務為API，因此在一些實施例中，來自用戶端的第一請求及/或狀態查詢為HTTPS GET請求，並且其中第二請求為HTTPS POST請求。因此，有利地，用戶端可使用基於標準網際網路及網路之通訊協定來請求將交易挖掘至區塊鏈中。在一些實施例中，與第一及/或第二請求相關聯的資料，及/或來自用戶端的狀態查詢，以JavaScript物件表示法(JSON)物件格式提供。

根據第三態樣，本揭露內容提供一種用於處理與區塊鏈相關聯的交易之電腦實施之方法，該方法由與多個挖掘者當中的挖掘者相關聯的一或多個處理器實施，其中多個挖掘者以通訊方式耦接至為用戶端實施支付服務之至少一個支付處理器。在一些實施例中，支付服務係由支付處理器基於上文所描述的與第一態樣相關聯的方法實施。在一些實施例中，用戶端經組配以實施與如上文所論述的第二態樣相關聯的方法。由多個挖掘者當中的挖掘者實施之第三態樣之方法包含回應於針對與用戶端相關聯的交易之費用報價之第一請求而提供與用於挖掘區塊鏈中之交易的挖掘者相關之當前費用報價的步驟。在一些實施例中，費用報價可經提供作為與用戶端相關聯的支付處理器之資料類型。如上文所論述，第一請求可與針對任何交易或多個交易之當前費用報價的請求有關或可特定針對於用戶端與客戶之間的特定交易。

在第三態樣之一些實施例中，回應於來自代表用戶端之支付處理器的第二請求，該第二請求係關於在區塊鏈中提交給定交易，該給定交易基於所選擇的費用報價，其中該部分可藉由用戶端如第一及第二態樣中所闡述來進行，該方法包含以下步驟。基於以下判定：與給定交易相關聯的所選擇的費用報價符合用於挖掘者之當前費用報價，亦即所選擇的費用報價為當前費用報價或在當前費用報價內，給定挖掘者接著產生與給定交易相關聯的對應的區塊鏈交易。該方法亦包括產生用於經創建區塊鏈交易之輸出指令碼(UTXO)、將經產生輸出指令碼添加至與挖掘者相關聯的記憶體池以及將該輸出指令碼發送至支付處理器，其中輸出指令碼包括與對應的區塊鏈交易相關聯的交易識別符TxID。在一些實施例中，回應於針對與交易識別符相關聯的狀態之請求，挖掘者包括基於對應的區塊鏈交易的當前挖掘狀態返回結果。

與第三態樣相關聯的優點係與上文關於第一及第二態樣所論述的優點有關。第三態樣係與第一及第二態樣互補，但描繪由多個挖掘者當中的挖掘者實施之方法，該多個挖掘者耦接至支付處理器以用於構建用於用戶端之交易，該交易可經寫入至區塊鏈中。實施第三態樣之方法之挖掘者在一些實施例中可與至少一個支付處理器通訊，該至少一個支付處理器經組配以根據第一態樣之方法將支付服務實施為支付API。

在一些實施例中，提供當前費用報價之步驟及/或發送輸出指令碼之步驟及/或返回結果之步驟經實施為遠端程序呼叫(RPC)。若例如如同BSV比特幣網路，挖掘者經組配以經由RPC無線地通訊，則此係有利的。在一些實施例中，第三態樣之方法可包括以下步驟：為了挖掘者池或網路(亦即與支付處理器相關聯的多個挖掘者)當中的資料流之額外安全性及精簡，在藉由無線通訊網路傳播至用於用戶端之支付處理器之前，將RPC自挖掘者發送至節點連接器，及用於多個挖掘者之任擇的防火牆。此外，有利地，節點連接器可在與支付處理器相關聯的API轉換器與該池中之一或多個挖掘者之間提供安全通訊通道。

在一些實施例中，基於與給定交易相關聯的所選擇的費用報價不符合用於挖掘者之當前費用報價之判定，例如，若當前費用報價高於所選擇的費用報價，則該方法包括將與區塊鏈交易相關聯的輸出添加至輔助記憶體池，該輔助記憶體池可為與挖掘者相關聯的額外臨時記憶體池。如上文所提及，此可儲存在本文中維持某一預定義時間段，使得挖掘者節點可使用此類臨時條目以檢查並且有利地確保不存在與給定交易相關聯的雙重花費。

在多個需要安全、可稽核、防篡改並可靠地記錄與之相關聯的事件或交易的應用中，隨著分散式分類帳(區塊鏈)技術的使用規模的擴大；傳統上，針對參與實體(諸如用戶端或商家實體)的解決方案依賴於即時地同步區塊鏈的完整複本、直接自區塊鏈識別與其應用程式及相關聯的數位電子錢包相關的交易及嵌入式資料。然而，隨著用戶端(亦即商家應用程式)的範疇、能力及安全性的發展以及區塊鏈的擴展，很明顯，需要一種允許參與方直接通訊並且允許此類應用程式直接交換訊息的技術解決方案，以便擴展並完全實現並且利用與區塊鏈相關聯的優點的全部潛力，並使此類解決方案可用於任何類型的用戶端或實體—無論計算複雜與否。本揭露內容之第四態樣為諸如上文在第一態樣中所論述的與支付服務相關聯的用戶端提供了此類解決方案。

根據第四態樣之第一實施，本揭露內容提供一種為與區塊鏈相關聯的交易之一或多個用戶端提供支付服務之電腦實施之方法，該方法由支付處理器實施。在一些實施例中，支付處理器可如關於第一態樣所論述之支付處理器。該方法包括自一或多個用戶端當中的給定用戶端接收將與數位資產相關聯的交易提交至區塊鏈的請求之步驟。如上文所提及，在先前態樣中，此請求使用HTTP傳輸格式經發送至支付處理器。在一些實例中，此請求為上文所描述的自用戶端接收之提交交易的第二請求。

在第四態樣之第一實施中，來自用戶端之請求係與用於實現用戶端與另一實體之間的直接通訊之回叫識別符相關聯。在一些實施例中，回叫識別符可為與用戶端相關聯的存取點或URI或URL。其他類型的回叫識別符及機構亦為可能的。下文將詳細論述之此類機制係提供通訊通道。

第四態樣之方法接著包括將與請求相關聯的交易提交至挖掘者以用於在區塊鏈中包括交易。在一些實施例中，此步驟係類似於根據自用戶端接收之第二請求提交交易，如關於第一態樣所論述。支付處理器將與請求相關聯的交易以及回叫識別符提交至多個挖掘者當中的給定挖掘者。

在一些實施例中，當給定挖掘者接收經由支付處理器提交之交易時，如上文第一及/或第二及/或第三態樣中提及，與對應的區塊鏈交易(對應於經提交請求)相關聯的交易識別符(TxID)作為回應自挖掘者接收。在一些實施例中，此包括接收與對應的區塊鏈交易相關聯的輸出指令碼，例如未使用交易輸出(UTXO) UTXO，如上文在第一態樣中所提及。用於對應的區塊鏈交易之此交易識別符(TxID)接著經發送至用戶端。

支付處理器亦藉由提供存取端點或挖掘者識別符(挖掘者ID)或與挖掘者相關聯的位置而向用戶端識別給定挖掘者。在一些狀況下，作為上文提及的回應之部分，可運用TxID向用戶端識別挖掘者。用戶端具有TxID係有利的，使得其可追蹤與TxID有關的任何其他對應性或訊息。如上文所提及，若用戶端選擇啟動此類檢查，則TxID亦可用以檢查對應的交易之狀態。

該方法接著包括為用戶端啟用或處理由挖掘者提供之與對應的區塊鏈交易相關的至少一個回叫通知。在實施例中，在回叫識別使得其可直接由挖掘者用於接觸關於對應的交易之用戶端(亦即經由用戶端之位置或URL)的情況下，接著支付處理器啟用回叫通知。若經識別回叫使得其要求其他步驟，諸如提供存取符記或交換密鑰等以啟動此類直接通訊，則支付程序必須處理此類其他存取以允許挖掘者使用回叫識別符與用戶端通訊。

本揭露內容之第四態樣的第二實施係關於一實施例，其中來自用戶端之提交交易之請求係與通道相關聯。在此狀況下，上文在第一實施中所提及之通道識別符呈通道之形式，該通道經組配以實現給定用戶端與另一實體之間的直接通訊。此實施中之該通道係由與給定用戶端相關聯的通道服務促進或提供，並且特定針對於給定用戶端之給定主題或交易。該通道可藉由與用戶端相關聯的位置或URL或通道識別符識別。

通道服務可由單獨的通道處理器提供，或可由上文提及的支付處理器提供，或可與用戶端整合。在一些實施例中，該通道係與一或多個功能相關聯，該一或多個功能包括：與用於傳輸資料相關之通道功能或程序；及/或與使用該等通道傳輸資料相關之訊息功能或程序。因此，該通道允許實體之間的用於轉移訊息或資料的直接或同級間通訊路徑或會話。在大部分實施例中，各通道僅存在二個實體。

以nChain Holdings Limited之名義提交之英國專利申請案第2007597.4號中詳細描述通道服務及/或通道處理器之實例，該申請案之主題以引用的方式併入本文中。

在一些實施例中，一或多個功能呈介面之形式，或存取點經提供用於用戶端且在大部分狀況下特定針對於可與用戶端相關聯的多個通道當中的給定通道，例如一個通道用於各交易。在大部分實施例中，該等通道實現全雙工，亦即用戶端與另一實體之間的雙向通訊。在一些實施例中，可僅允許在一個方向上之通訊，亦即用戶端僅可想要將訊息發送至另一實體或自另一實體接收訊息。

在一些實施例中，該用戶端可為多個通道之所有者或與該多個通道相關聯，且上文提及的通道為該多個通道中之一者，此等通道為基於由通道服務提供之一或多個功能之通道。在一些實施例中，一或多個功能為針對給定用戶端發出或經提供至給定用戶端之應用程式設計介面(API)，該等API包括用於一或多個通道之通道API；以及用於資料之訊息API，亦即係關於與各或給定通道相關聯的主題之訊息。API可被理解為允許創建或管理實體(諸如在此狀況下為用戶端)之應用程式的端點、介面或一組功能及程序，其存取應用程式之特徵或資料或其他服務。在此狀況下，其將實施通道功能以及訊息功能。

在第二實施中，來自用戶端之請求係進一步與用於該通道之一或多個存取符記相關聯。此等符記由通道處理器提供。在一些實施例中，該(等)符記經組配以用於與另一實體之安全通訊，該一或多個存取符記與給定通道或甚至給定通道中之一或多個訊息相關。在一些實施例中，存取符記為特定針對於給定通道或給定訊息之API符記。在一些實施例中，存取符記，且尤其API符記，充當用於請求對通道之存取的實體或應用程式之僅有的識別符。在一些實施例中，存取符記可被視為指派至用戶端的僅有的認證憑證，並且甚至可與針對個別通道或各通道中之個別訊息一樣精細。在一些實施例中，存取符記可使得用戶端可針對其通道中之各者將此等符記提供給另一實體以用於認證。在本發明實施例中，對於與交易相關聯的挖掘者，存取符記可由用戶端或通道服務針對各交易產生或提供。

在一些實施例中，該通道可與通道識別符相關聯，該通道識別符與用於通道之位置或存取點相關聯。在一些實施例中，各通道係與特定通道識別符相關聯。相同的給定用戶端可具有多個單獨的通道，各通道具有其自身的唯一識別符，該識別符可對應於經由其存取通道之位置或端點。在一些實施例中，給定通道係用於與關於與特定類型或主題之資料相關聯的任何其他實體通訊，其中通道中之相關聯的各主題資料係包括於一或多個訊息或交易中。有利地，針對特定主題或交易具有特定通道確保用戶端之較強清晰性、可靠性及靈活性，尤其在如商家實體之用戶端之狀況下，該用戶端可具有多個主題(諸如交易數目或ID或發貨單數目)，該等主題需要與同相同用戶端相關聯的所有其他主題或其他交易分開來被追蹤或處理。

在第一實施中之支付處理器亦為通道處理器(亦即其為用戶端實施支付服務以及通道服務)之實施例中，第四態樣之方法亦可包括向挖掘者提供對與交易之給定用戶端相關聯的通道之存取。在用戶端之所有通訊係藉由支付處理器管理或經由支付處理器實施之實施例中，此係優點，使得該通道亦將由代表用戶端之支付處理器設定。在一些實施例中，可藉由使挖掘者存取一或多個通道及/或與通道相關聯的訊息功能或API以便獲取資料或將資料寫入至用於彼用戶端之通道中可能需要的通道識別符及/或位置以及存取符記可用於挖掘者來提供存取。

一旦已經提供通道或已經提供對通道之存取，則接著使用此類通道向用戶端提供與來自挖掘者之對應的區塊鏈交易相關聯的回叫通知。因此，挖掘者可使用該通道提供資料，亦即使用一或多個通道及訊息功能或API將資料寫入至通道中，該一或多個通道及訊息功能或API係使用用於各別通道之存取符記而獲得。

在一些實施例中，用於用戶端之回叫通知可為一旦資料經寫入至通道中即獲得之警示或訊息，該通知在一些狀況下包括通道識別符。其被稱作回叫係因為其與用於給定用戶端之特定TxID或區塊鏈交易相關，該特定TxID或區塊鏈交易已經由支付處理器處理，亦即已經藉由支付處理器發送至挖掘者。有利地，該通道使得訊息或回應能夠經提供於專門被指派給定用戶端之TxID的通道中。

在一些實施例中，回叫通知係關於已經由給定用戶端提交並且經記錄在區塊鏈中之交易的雙重花費之通知。在此狀況下，藉由挖掘者提供於通道中之資料為包括以下資料之返回有效負載： -作為雙重花費之區塊鏈交易的交易識別符(TxID)；且在一些狀況下，任擇地 -提交區塊鏈交易之支付處理器的服務端點。此在用戶端係與多個支付服務相關聯之狀況下為適用的，且因此該識別符清晰地指示首先將請求提交至挖掘者之支付處理器。

在一些實施例中，回叫通知係關於包括給定用戶端在區塊鏈中提交之交易的證明，亦即默克爾證明(Merkle Proof)。在此狀況下，藉由挖掘者提供於通道中之資料為通道中之返回默克爾證明，該返回默克爾證明由挖掘者提供，該返回默克爾證明包括以下資料： -與默克爾證明有關之區塊鏈交易的交易識別符(TxID)； -其中包括區塊鏈交易之區塊的區塊標頭；以及 -用於交易識別符(TxID)之同層級散列的陣列。

在一些實施例中，經提供之通道或訊息功能包括JavaScript物件表示法(JSON)經由超文件傳送協定(HTTP)之API，以使得能夠針對回叫通知來存取、創建及/或管理通道中之一或多個資料或訊息。

與經由通道提供之回叫通知相關聯的此等資料或回叫訊息對於多個區塊鏈相關聯的應用程式可為尤其有利的，此係因為挖掘者接著可使用通道以將默克爾樹包括證明或用於提交至區塊鏈之交易的雙重花費通知直接發送至另一實體，該另一實體在此狀況下亦即請求交易提交之用戶端。此係適用的，因為其意謂不再需要諸如商家或另一實體之用戶端必須搜索區塊鏈以找到此類交易以評估該交易是否經挖掘。此係因為，有利地，一旦該交易經挖掘，則直接使用通道提供包括證明。

第四態樣之第二實施之方法亦包括將該等通知儲存及/或提供至用戶端。在一些實施例中，當用戶端離線或不以通訊方式連接至通道處理器時，回叫通知係由通道處理器儲存，亦即作為用於在通道中針對給定用戶端列隊之資料的推送通知。在其他實施例中，當用戶端在線上或以通訊方式連接至通道處理器時，通道中之相關聯的資料(與回叫通知相關聯)可直接自通道提取。

有利地，使用通道允許給定通道中之各請求或訊息的異步處理。此允許用於通道中之訊息的無縫並且準確、不連續或延遲的處理流程，此係由於用於任何給定主題或交易的次序及訊息始終清晰可見，此係因為該通道特定針對於此類主題。此可尤其適用於其中用戶端或其他實體可能不可操作或可能不在線上或可能不能夠操作與回叫通知相關聯的任何資料之實施或情形。因此，以上技術使得能夠使用通道仍可靠地遞送請求並且準確地按次序處理請求，即使當通道一方離線或無回應時亦如此，此係因為訊息在諸方接下來在線上或連接至網路時將仍存在於通道中，因此諸方可基於藉由通道處理器列隊之通知存取通道中之訊息。如上文所提及，通道處理器之功能性亦可藉由實施支付處理器之相同實體實施。

此外，不管可在通道中提供多少其他訊息，其仍將可由另一實體按遞送次序存取。因此，儘管連接性有延遲或中斷，但通道中之訊息的處理得以準確並且無縫地完成，如同完全沒有延遲一樣。

因此，上文所描述之第四態樣之第二實施及其與本揭露內容相關聯的實施例提供用於藉由實施用於直接通訊的通道而處理用於用戶端之交易的安全、鏈外、諸方間(同級間/直接)應用程式訊息傳遞機制。此態樣提供了當事人可經由其甚至在諸方中之一方暫時離線之情形下仍以安全方式進行通訊的機制。對於與企業相關聯或可表示諸如商家之組織的用戶端實體，此類用戶端可具有多個其他實體(客戶)，該等其他實體與其進行有關多種商品的交易。因此，對於此類情境，使用通道以用於與一或多個客戶或交易通訊，同時與實施與維持所有此類交易記錄的區塊鏈有關的任何功能解除關聯或分離，此將為非常有益的。經由通道服務提供通道功能以及訊息功能，此類用戶端便能夠為與特定交易(諸如特定發貨單或某些商品的查詢等)有關的特定客戶利用特定通道，並且能夠在任何時候經由該通道獲得特定針對於此類交易的任何其他資訊。

在第四態樣之第三實施中，本揭露內容提供一種用於處理與區塊鏈相關聯的交易之電腦實施之方法，該方法由與用戶端相關聯的一或多個處理器實施。第三實施類似於第二實施，並且與類似優點相關聯。該方法包含發送與通道服務相關的通道請求之步驟，該通道服務由通道處理器實施。該通道處理器可實施用於用戶端之通道服務，如在英國專利申請案第2007597.4號中闡述。第一請求可為至通道處理器之超文件安全傳送協定(HTTPS)傳輸GET請求。接著，用戶端實施之方法包括獲得對一或多個功能之存取，該一或多個功能使得能夠在給定用戶端與另一實體之間直接通訊。如同第二實施，該一或多個功能包括：與用於傳輸資料之一或多個通道相關的通道功能或程序；及/或與使用一或多個通道傳輸資料相關之訊息功能或程序。該用戶端亦獲得用於如上文所闡述之通道之一或多個存取符記。

該方法接著包括將一請求發送至實施支付服務之支付處理器，諸如在第一態樣或第四態樣之第一實施中解釋的處理器，該請求為將與數位資產相關聯的交易提交至區塊鏈。此請求可為至支付處理器的超文件安全傳送協定(HTTPS)傳輸POST請求，其可與HTTPS API相關聯。

該用戶端接著自支付處理器獲得回應，該回應包括用於區塊鏈交易之對應於經提交交易的交易識別符(TxID)。對應的區塊鏈交易與由支付處理器提交至挖掘者之交易相關。作為回應接收之此TxID係適用於追蹤對應於該TxID之已經由挖掘者產生的區塊鏈交易。

該用戶端亦與上文所提及之回應分離地或連同該回應自支付處理器接收用於提供TxID之挖掘者的識別符或存取點或位置。

接著，使用自通道處理器接收之一或多個通道功能，該方法包括創建與經識別挖掘者進行通訊之通道，及將與該通道相關聯的一或多個存取符記發送至另一實體，該另一實體在此狀況下為挖掘者。此有利地使得能夠安全、可靠並且準確地設置通道以用於在用戶端與挖掘者之間直接通訊。

接著，回叫通知係自通道處理器接收到，當用戶端在線上時或當其以通訊方式連接至支付處理器時，可在用戶端處接收此類回叫通知。基於此通知，與特定區塊鏈過渡相關之資料，亦即與用戶端相關聯的TxID，可在用戶端在線上時由該用戶端直接自挖掘者獲得。

第四態樣之第三實施的一些實施例係關於為用於同級間通訊之通道提供安全定址及加密。在一些實例中，該方法包括提供與用戶端相關聯的用戶端定址密鑰，及獲得與挖掘者相關聯的至少一個挖掘者定址密鑰。在一些狀況下，亦可提供用戶端端點，並且若此類端點尚不可用於用戶端或不為用戶端已知，則可獲得挖掘者點。定址密鑰可為靜態或臨時密鑰或二者，且可用於驗證各別端點之身份。在此狀況下，可基於用戶端及/或挖掘者定址密鑰而啟動使用該通道之通訊，使得可基於交握模式導出共用秘密密鑰。此類共用秘密密鑰接著可用於經由通道對所有通訊加密。交握模式可基於雜訊協定格式，但其他機制亦可用以導出加密/解密密鑰或密鑰對，諸如Libsodium密鑰交換或產生技術。

有利地，提供諸如用於用戶端之API端點之端點以及諸如靜態及/或動態/臨時密鑰的定址密鑰，允許與用戶端相關聯的一或多個處理器安全地存取挖掘者。在一些實施例中，密鑰進一步使得能夠在經由通道的訊息之任何轉移之前啟動認證程序，藉此藉由驗證管理通道之諸方的身份來增加安全性，藉此確保經由通道之所有通訊僅在二個經認證實體之間進行。

獲得共用秘密密鑰使得使用通道之直接通訊係基於共用秘密密鑰而經加密係進一步有利的，此係因為共用秘密密鑰係基於身份，亦即管理通道之二方或實體之定址密鑰。因此，僅各別有效的並且經認證的諸方將能夠解碼經加密密文，藉此增加可靠性以及隱私，並且可抵禦惡意方的假冒嘗試。

在一些實施例中，用於用戶端及/或挖掘者之端點可為HTTP API端點，且其中在經由該通道之通訊之前使用安全HTTP (HTTPS)傳送協定將該端點遞送至另一方(或對方)。此有利地確保可藉由來自已知且受信任的授權機構(CA)的一系列憑證來驗證該端點。在一些實施例中，用戶端端點以及挖掘者端點可為回應於對與通道服務相關聯的一或多個功能之請求而包括的通用資源位置(URL)。藉由以上內容，有利地，通道的至少一方可使用PKI或其他機制來知道且驗證一方的身份。

在一些實施例中，用於用戶端之端點可為與通道之各別實體相關聯的別名，其中該別名係特定針對於用戶端並且由基於別名之定址服務提供，該定址服務具有可自經界定或眾所周知的位置存取之機器可讀資源，該機器可讀資源包括與通道處理器相關之一或多個能力。該別名可為已知的或經提供至一或多個其他條目，該別名係與用於認證之不對稱密碼密鑰對相關聯。藉由以上內容，有利地，雙方可使用PKI或其他機制知道且驗證諸方的身份。已經存在其中代替用於一或多個用戶端實體之複雜的公用位址來使用容易記住且對於使用者較友好的別名。以nChain Holdings Limited的名義在美國專利申請案第16/384696號中提議此解決方案。此等文件闡述被稱作bsvalias支付服務之基於別名之支付服務及相關聯的協定，其中別名係用於目的地定址而非用戶端實體之公用位址。此系統中之別名通常與發送/接收用戶端實體之域名相關聯且可為URI或電子郵件位址。因此，只要發送者或實體瞭解或具備該別名，則此對於bsvalias支付系統或另一基於別名之定址機制係足夠的。舉例而言，可使用在用於bsvalias或其他支付服務之眾所周知的URI或位置中保存之機器可讀資源(諸如JavaScript物件表示法(JSON)文件)中提供之指令來將訊息發送至用戶端的別名。

在第四態樣之第四實施中，本揭露內容提供一種用於處理與區塊鏈相關聯的交易之電腦實施之方法，該方法由與挖掘者相關聯的一或多個處理器實施。第四實施類似於第一實施，並且與類似優點相關聯。

在此實施中，挖掘者自支付處理器接收對將交易提交至區塊鏈之請求。在一些實施例中，此可類似於來自如在第三態樣中所論述之支付處理器的對代表用戶端提交交易之第二請求。

該方法接著包括產生對應於該請求之區塊鏈交易及將具有與區塊鏈交易相關聯的輸出指令碼(UTXO)之回應發送至支付處理器。該輸出指令碼包括與對應的區塊鏈交易相關聯的交易識別符(TxID)。如上文所提及，與挖掘者相關聯的存取點或識別符亦可與回應一起經提供至用戶端。

接著接收對特定針對於TxID之用戶端的通道之存取。此存取可在用戶端創建了通道之後由用戶端直接提供，或可由支付處理器代表用戶端提供。如先前所提及，此通道實現與給定用戶端直接通訊。亦接收用於存取將資料寫入至其中之通道的存取符記。

基於存取符記，挖掘者接著可獲得、存取或擷取訊息功能或訊息API以用於在通道中提供與回叫通知相關聯的資料，該資料與對應的區塊鏈交易(TxID)相關。如上文所提及，回叫通知可與用於給定交易之雙重花費通知或默克爾證明有關，該雙重花費通知或默克爾證明可經由通道直接、安全地、準確地並且異步地遞送至用戶端。

因此，在此第四實施中，可由挖掘者獲得與通道相關聯的通道或訊息API及/或評估符記以使得能夠與用戶端直接通訊。此對於多個區塊鏈相關聯的應用程式可為尤其有利的，此係因為挖掘者接著可使用通道以將默克爾樹包括證明或特定針對於直接提交至區塊鏈的交易之任何其他訊息發送至用戶端。此係適用的，因為不再需要諸如商家之用戶端或諸如客戶之另一實體或實際上支付服務都必須搜索區塊鏈以找到此類交易或驗證其狀態。此係因為，有利地，一旦經挖掘，可使用通道直接將包括證明發送至用戶端。或者，若出於某一原因，不挖掘與TxID相關聯的交易，則可經由通道為交易發送諸如誤差通知或雙重花費通知的訊息。

本揭露內容亦提供一種電腦系統，其包含經由無線通訊網路以通訊方式耦接至至少一個用戶端及至少一個挖掘者之支付處理器，該支付處理器與用於將來自用戶端之HTTPS請求轉換為用於挖掘者之RPC請求且反之亦然的API轉換器相關聯，其中根據第一態樣實施支付處理器。該電腦系統亦包含用戶端，該用戶端經由無線通訊網路以通訊方式耦接至該支付處理器並且能夠與至少一個客戶通訊，其中根據第二態樣之計算裝置實施該用戶端。該用戶端亦經由無線通訊網路以通訊方式耦接至通道處理器處理器，其中根據第四態樣之計算裝置實施該通道處理器。該電腦系統亦包含多個挖掘者，各挖掘者經由無線通訊網路以通訊方式耦接至支付處理器，其中根據第三態樣實施各挖掘者。

在一些實施例中，提供一種包含處理器及記憶體之計算裝置，該記憶體包括可執行指令，該等可執行指令由於由處理器執行使得該裝置執行上文所論述之態樣及/或實施例。

在一些實施例中，提供一種電腦可讀儲存媒體，其上儲存有可執行指令，作為由電腦系統之處理器執行之一結果，該等可執行指令使得電腦系統執行上文所論述之態樣及/或實施例之方法。

現在作為說明參考附圖描述一些特定實施例，在該等附圖中，相同參考數字指代相同特徵。第一態樣—支付處理器

圖1係關於本揭露內容之第一態樣並且描繪一種藉由支付處理器執行以用於為用戶端實施支付服務之方法，如上文所論述。支付處理器以通訊方式耦接至用戶端或多個用戶端，且亦耦接至可包括挖掘者的多於一個網路或多於一個挖掘池之多個挖掘者。在一些實施例中，支付處理器可為用戶端之部分或與該用戶端相關聯地實施。此在用戶端為計算上複雜的商家銷售點(POS)終端之情況下係真的。設想本揭露內容之態樣及實施例以涵蓋二個此類實施，亦即遠端支付處理器或為用戶端之一部分的支付處理器。圖4中可見下文加以解釋之實例系統架構。

在圖1中所描繪的實例情境中，與獲得多個挖掘費用報價、基於經獲得之多個挖掘費用報價當中的所選擇的費用報價提交交易以及發送與交易識別符有關之狀態查詢的步驟有關之實施例全部經描述為按順序進行並且經描述為圖1之流程圖中的單個程序。然而，本揭露內容及第一態樣不應被視為限於此。與在下文所描述之步驟102至106中獲得第一請求中之費用報價有關之步驟可單獨地並且獨立於剩餘的步驟實施。類似地，可單獨地並且在與獲得費用報價之先前步驟不同的時間實施與在來自步驟108至114之第二請求中提交交易有關之步驟。以相同方式，可在用戶端已經瞭解交易的識別符並且不需要遵循圖1的序列之後的任何時間實施與自步驟116開始的交易狀態詢問有關的步驟。僅僅為易於解釋及理解，在本文中按順序展示所有步驟並且絕不將本揭露內容視為限於此類序列或情境。

步驟102描繪自用戶端接收挖掘與挖掘區塊鏈中之交易相關聯的費用報價之第一請求。該第一請求亦可關於多個交易。為易於解釋及理解，將關於與用戶端相關聯的第一請求中之單個過渡解釋圖1，但本揭露內容不以任何方式限於此。此步驟表示代表用戶端自用於挖掘交易之多個挖掘者收集挖掘費用報價。該交易通常係與在用戶端(亦即商家計算資源或實體)與客戶實體之間進行的數位資產支付有關。如上文所提及，經由或使用HTTPS協定且以JSON格式自用戶端接收第一請求。支付處理器將支付介面實施為用於用戶端之應用程式設計介面(API)，且因此可當API經實施為網路服務時，接受並且處理HTTPS。可使API端點用於用戶端。在第一請求中之多個交易之狀況下，可使用相同的API端點或用於支付處理器之單獨的API端點。

舉例而言，在一些實施例中，支付處理器可使用諸如REST介面之基於標準之介面設計來實施支付服務。表示狀態傳送(REST)為用於開發網路服務及基於網路之交互的架構型式。REST API設計標準可使用以下命令來處理HTTPS請求及通訊：

命令	GET	POST	PUT	DELETE
資源	讀取	創建	更新	刪除

本文中將主要論述GET及POST HTTPS請求，但應用程序不限於此等命令。在此步驟102中，由支付處理器接收之第一請求可為形式GET getFeeQuote之HTTPS請求。

在REST API之上下文中之資源為具有一類型、相關聯資料、與其他資源之關係及對其進行操作之一組方法的物件。在一些實施例中，支付服務係由支付處理器提供作為API實施，以存取諸如比特幣SV (BSV)區塊鏈之區塊鏈或分散式分類帳的狀態，及經由應用程式介面觸發可更改彼狀態並且將其暴露為靜止API之操作。因此，支付處理器可被視為用於一或多個用戶端之REST端點。為僅易於解釋，將通篇論述一個用戶端(或商家)及一個支付處理器，但本揭露內容不限於此。該用戶端因此可經由HTTPS與支付服務通訊，並且此外有利地，用戶端可匿名存取支付處理器或由支付處理器實施之支付服務。當存在多於一個用戶端及多於一個支付處理器時，在一些實施例中，該用戶端將負責基於例如用戶端可與運行支付處理器之一或多個第三方具有的任何協議而確定或聯繫正確或期望的支付處理器或REST端點。

步驟104描繪自多個挖掘者當中的各挖掘者獲得用於挖掘交易之費用報價。在此步驟中，所有耦接至支付處理器之挖掘者可由支付處理器輪詢或聯繫，並且被請求返回用於挖掘交易(亦即，在校驗鎖定及解除鎖定指令碼之後將交易寫入至區塊鏈)之當前費用報價。目前，諸如BSV網路之一些區塊鏈網路經由遠端程序呼叫(RPC)支援通訊。因此，在此狀況下，與支付處理器相關聯的API轉換器係用於將HTTPS第一請求，亦即GET getFeeQuote，轉換為RPC第一請求，亦即RPC getFeeQuote()，且反之亦然。此轉換在需要支援此類BSV節點實施之實施例或僅支援RPC之其他實施中係必要的。如上文所提及，API轉換器可為與支付處理器相關聯的API閘道器或閘道器處理器之部分，其中HTTP/RPC轉換僅為API閘道器提供之功能中之一者。經發送至挖掘者之呈RPC格式之getFeeQuote()的目的在於向用戶端通知各挖掘者收取的費用。不需要輸入參數，但RPC介面可能需要關於RPC getFeeQuote()來實施，使得此命令返回來自各挖掘者之呈JavaScript物件表示法JSON物件之形式的資料類型，亦即MinerFeeQuote，其含有自各挖掘者收集之與費用有關的資料。

與自各挖掘者收集之經獲得費用報價有關的資料可經界定為JSON物件，如在以下實例中所給定。

在下文展示自各挖掘者返回之JSON物件FeeQuotes。儘管展示與單次交易有關的實例，但本揭露內容不限於此且其同樣適用於表示用於多個交易之挖掘費用的費用報價： [ {# MinerFeeQuote '' MinerID '' : ＜Alphanumeric＞, # If MinerID is null (empty) then '' NO-ID '' is defaulted '' CurrentHighestBlockHash '' : ＜Alphanumeric＞, '' MinerSignature '' : ＜Alphanumeric＞, # Includes Current Block Hash + Block Height '' SignatureTimestamp '' : ＜UTC Timestamp＞, # Miner guarantees fee from this time until superseded '' MinerReputation '' : ＜Alphanumeric＞, # If this is blank (null), return '' Unknown '' [ { # FeeTypes '' FeeType '' : ＜ '' SPB '' || '' SPDB '' || … ＞, # Satoshis-per-byte, Satoshis-per-data-byte, etc '' CurrentFee '' : ＜Floating Point Number＞, '' Expiry '' : ＜Integer＞, duration or date/time at which Fee expires, '' FeeOnExpiry '' : ＜Floating Point Number＞, # If Expiry is 0 then this should be set to CurrentFee '' GuaranteeFee '' : ＜Floating Point Number＞ # Guarantees to process Tx at this fee (none if 0) '' KeepInMempoolFee '' : ＜Floating Point Number＞, # Fee for retaining Tx in secondary mempool }, { … } ] '' Margin '' : ＜Floating Point Number＞, # Acceptable margin for error due to use of FP numbers '' APIversion '' : ＜Numeric＞ # API version NN.nn (major.minor version no.) }, { # MinerFeeQuote '' MinerID '' : ＜Alphanumeric＞, # If MinerID is null (empty) then '' NO-ID '' is defaulted '' CurrentHighestBlockHash '' : ＜Alphanumeric＞, '' MinerSignature '' : ＜Alphanumeric＞, # Includes Current Block Hash + Block Height '' SignatureTimestamp '' : ＜UTC Timestamp＞, # Miner guarantees fee from this time until superseded '' MinerReputation '' : ＜Alphanumeric＞, # If this is blank (null), return '' Unknown '' [ { # FeeTypes '' FeeType '' : ＜ '' SPB '' || '' SPDB '' || … ＞, # Satoshis-per-byte, Satoshis-per-data-byte, etc '' CurrentFee '' : ＜Floating Point Number＞, '' Expiry '' : ＜Integer＞, duration or date/time at which Fee expires, if 0 fee is not guaranteed to not change '' FeeOnExpiry '' : ＜Floating Point Number＞, # If Expiry is 0 then this should be set to CurrentFee '' GuaranteeFee '' : ＜Floating Point Number＞ # Guarantees to process Tx at this fee (none if 0) '' KeepInMempoolFee '' : ＜Floating Point Number＞, # Fee for retaining Tx in secondary mempool }, { … .} ] '' Margin '' : ＜Floating Point Number＞, # Acceptable margin for error due to use of FP numbers '' APIversion '' : ＜Numeric＞ # API version NN.nn (major.minor version no.) }, MinerFeeQuote may repeat as necessary - one per miner ] 為易於理解，下文亦給出以上JSON物件FeeQuotes之另一實例，其用資料項目填寫：GET /mapi/feeQuote 回應

在一些實施例中，JSON FeeQuotes物件含有挖掘者細節及經收取費用之陣列，而為含有自單個挖掘者接收之挖掘者及費用資料的JSON結構。下文解釋以上JSON物價中之術語中之一些。

CurrentHighestBlockHash 可用作用以當呼叫getFeeQuote()時在區塊鏈增長至的點處識別區塊散列之標記。

MinerSignature 可含有同意保證此交易之挖掘者的簽名，如上文所論述。此不同於用於驗證挖掘者的身份之數位簽名。藉由這樣做，挖掘者可保證挖掘者將迅速在區塊中包括交易且任擇地將不包括任何衝突之交易。若挖掘者不願意保證交易，則此可經設定為空。

SignatureTimestamp 指示挖掘者保證以經陳述當前費用挖掘交易，亦即自彼點起直至被取代之前保證費用，之時間。若用戶端隨後呼叫getFeeQuote()，則此時間經取代。

MinerReputation 係關於挖掘者之績效之量度，亦即挖掘者以經承諾或報價之當前費用執行交易之能力如何。信譽得分/指示符可由各支付處理器計算、維持及管理。

挖掘者 ID 可為二份式基準，其在挖掘區塊時經添加至Coinbase交易。若不存在挖掘者ID，則支付處理器可運用挖掘者ID「空」標記彼挖掘者或僅僅將其留空。

在各MinerFeeQuote內，可使用FeeTypes物件之陣列以捕獲當前可用的各種費用類型。可在未來引入費用類型，且由支付處理器提供之getFeeQuote()介面無需任何改變。所有交易均可具有一個FeeTypes陣列。

步驟106描繪藉由支付處理器將經獲得費用報價提供至用戶端。在一些實施例中，此可包括由支付處理器判定之經推薦費用報價。如上文關於第一態樣所提及，此步驟可包括藉由API轉換器將RPC轉換至HTTPS，使得用戶端將能夠使用基於網路之API存取細節。

在步驟108中，自用戶端接收第二請求，該第二請求為提交與經獲得費用報價當中的所選擇的費用報價相關之給定交易的請求。在一些實施例中，給定交易係基於客戶回應於來自用戶端之支付請求而向用戶端進行之數位資產支付。舉例而言，若用戶端為咖啡館之商家終端，則此可中本聰幣或其他類型的數位資產支付以換取一杯咖啡。在此步驟中，客戶經由藉由支付處理器實施之支付服務API請求此數位資產支付經寫入至區塊鏈中。

如上文所提及，在一些實施例中，來自用戶端之第二請求可為提交多個交易之請求。

第二交易中之所選擇的費用報價可基於藉由支付處理器進行之建議或可由用戶端針對一或多個交易選擇。

如上文所提及，所選擇的報價可基於所有經獲得費用報價之平均值或最大值。

在一些實施例中，第二請求為呈POST submitTransaction(Tx)之形式的HTTPS請求，其中Tx在一些實施例為與用於用戶端與客戶之間的支付的給定交易相關聯的呈JSON格式之物件。因此，Tx (JSON物件)含有在將第二請求提交至支付處理器以傳遞至挖掘者之前在區塊鏈上創建用戶端可將其作為JSON結構提供或構建的交易之資料。

步驟110描繪將產生對應於步驟108中之給定交易之區塊鏈交易的請求發送至多個挖掘者當中的一或多個挖掘者的步驟。在此步驟中，支付處理器在一些實施例中將先前步驟中之HTTPS POST請求轉換為用於提交至挖掘者之RPC請求。此可運用請求RPC createRawTransaction(Tx)來進行，其中Tx包括與給定交易相關聯的資料，其作為如步驟108中所論述之JSON物件給定。RPC createRawTransaction(Tx)為用以創建使用給定輸入並且創建新的輸出之交易之RPC呼叫，其中輸出可為位址或資料。在步驟108中，RPC請求可自用戶端發送至多個挖掘者，或發送至滿足或符合所選擇的費用報價之挖掘者。如上文所提及，提供等於或低於所選擇的費用報價之當前費用報價的挖掘者被認為符合所選擇的費用報價之要求，此係因為其可以其各別當前經報價費用挖掘交易。作為回應，符合所選擇的費用報價之挖掘者創建對應於給定交易之區塊鏈交易。在一些實施例中，對應於給定交易之經十六進位編碼之原始交易經返回至支付處理器。

在步驟112中，與已經由多個挖掘者當中的至少一個挖掘者創建之對應的區塊鏈交易相關聯的輸出或輸出指令碼在支付處理器處被接收，該多個挖掘者符合所選擇的費用報價。輸出指令碼可為與由各別挖掘者創建之對應的區塊鏈交易相關聯的UTXO。在一些實施例中，UTXO亦可儲存於符合所選擇的費用報價之各別挖掘者的記憶體池中。此步驟中之輸出將包括用於各別挖掘者創建之對應的區塊鏈交易之交易識別符(TxID)。TxID為對經提交至挖掘者之記憶體池的經十六進位編碼之交易的引用，該經十六進位編碼之交易接著藉由支付處理器經相應地映射至區塊鏈交易。

接著可立即或稍後挖掘此區塊鏈交易以按當前費用報價完成挖掘程序。在一些狀況下，可不挖掘經創建交易，因為另一挖掘者已將其寫入至區塊鏈中，或該經創建交易可出於諸如雙重花費或時移或無效之某一原因而待處理或被拒絕。

步驟114描繪將交易結果TxResult發送至用戶端，該結果包括用於對應於步驟108中之給定交易由各別挖掘者創建之區塊鏈交易的交易識別符TxID。在一些實施例中，交易結果TxResult為使用HTTPS協定自支付處理器發送至用戶端之JSON物件，該JSON物件基於由符合所選擇的費用報價之各別挖掘者在步驟110及112中創建之對應的區塊鏈交易之細節。

存在於用於用戶端之TxResult物件中之細節的實例如下給出： JSON物件TxResult 針對各別挖掘者在下文展示，且包括在步驟104中作為FeeQuotes JSON物件之部分論述的一些術語及物件。[ { '' ReturnResult '' : ＜Alphanumeric＞, # ReturnResult is defined below '' ResultDescription '' : ＜Alphanumeric＞, # Reason for failure (e.g. which policy failed and why) '' DoubleSpendTxID '' : ＜Alphanumeric＞, # Tx ID of double spend transaction '' ExceptionTimestamp '' : ＜UTC Timestamp＞, #Time exception was detected (e.g. doublespend time) '' BlockHash '' : ＜Alphanumeric＞, # Block that includes this transaction '' BlockHeight '' : ＜Integer＞, '' MinerID '' : ＜Alphanumeric＞, # If MinerID is null (empty) then '' NO-ID '' is defaulted '' MinerSignature '' : ＜Alphanumeric＞, # Block Hash + Block Height + TxID '' SignatureValidFrom '' : ＜UTC Timestamp＞, # MinerSignature validity time (from getFeeQuote) '' TxID '' : ＜Alphanumeric＞, # Transaction ID assigned when submitted to mempool '' txSecondMempoolExpiry '' : ＜Integer＞, # Duration (minutes) Tx will be kept in secondary mempool '' '' APIversion '' : ＜Numeric＞ # API version NN.nn (major.minor version no.) } ]

在上文闡述之ReturnResult 可含有以下可能值中之一者，該等值如下： • 經提交-無問題，交易經提交至記憶體池 • Rejected_DS-由於雙重花費經拒絕-DoubleSpendTxID不能為空 • Rejected_Policy—由於違反政策而經拒絕 • Rejected_Invalid—由於交易無效而經拒絕 • Rejected_FeeTooLow—費用過低，因此挖掘者將不在區塊中包括Tx • Rejected_KeepInMemPool—Tx被拒絕，但保留在記憶體池中以檢查是否有雙重花費。

步驟116描繪自用戶端接收與交易識別符TxID相關聯的狀態查詢以用於發送至多個挖掘者之步驟。自此步驟開始可與安排在多個挖掘費用報價當中選擇一費用報價之後提交交易的以上步驟異步地進行並且被認為對於第一態樣之操作為必要的。自步驟116之實施例開始係關於其中用戶端希望知道在步驟108中進行之一或多個第二請求的狀態之情境。

步驟116使得用戶端能夠查詢用戶端經由在步驟108中論述之HTTPS POST submitTransaction(Tx)提交至支付處理器之交易之狀態。因此，此步驟中之TxID可對應於針對係關於用戶端與其客戶之間的數位資產支付之任何給定交易進行的任何第二請求。如在以上步驟中所論述，狀態查詢係使用作為傳輸協定之HTTPS自用戶端接收，該查詢係以JSON格式(諸如GET queryTransactionStatus(TxID))發送，該查詢又轉換為用於發送至多個挖掘者當中的一或多個挖掘者之RPC請求、RPC getRawTransaction(TxID)。

在步驟118中，支付處理器自多個挖掘者當中的各別挖掘者接收回應，該多個挖掘者與創建及/或處理與TxID相關聯的區塊鏈交易相關聯。在一些實施例中，以上RPC getRawTransaction(TxID)可包括Verbose參數，其可與設定為1之自變數有關。在此狀況下，在步驟110及112中，自各別挖掘者返回之結果若成功則將在一些實施例中呈JSON格式，其含有經解碼之對應的區塊鏈交易。此有利地提供捕獲並且處理其中之資料的靈活性。若Verbose 參數經設定為0，則代替JSON資料類型或文件格式，經十六進位編碼之交易經返回至支付處理器。若未找到與TxID有關之此類交易，則可返回空，此又將引起使ReturnResult 物件經設定為「未知」。任何其他經返回誤差亦可由挖掘者經由ReturnResult 及ResultDescription 物件經報告給支付處理器。已經關於步驟114指示此等物件。

在步驟120中，與TxID相關之TxResult經返回至用戶端，該回應使用HTTPS發送。此表示挖掘結果，該挖掘結果係與用戶端在步驟116中之狀態查詢中發送之給定TxID相關聯。下文給出自支付處理器發送至用戶端之TxResult的實例。

在下文展示JSON物件TxStatus ：[ { '' ReturnResult '' : ＜Alphanumeric＞, # ReturnResult is defined below '' ResultDescription '' : ＜Alphanumeric＞, # Reason for failure (e.g. which policy failed and why) '' DoubleSpendTxID '' : ＜Alphanumeric＞, # Tx ID of double spend transaction '' ExceptionTimestamp '' : ＜UTC Timestamp＞,# Time exception was detected (e.g. doublespend time) '' BlockHash '' : ＜ Alphanumeric＞, '' BlockHeight '' : ＜Integer＞, '' Confirmations '' : ＜Integer＞, # 0 if not yet unconfirmed '' MinerID '' : ＜Alphanumeric＞, # If MinerID is null (empty) then '' NO-ID '' is defaulted '' MinerSignature '' : ＜Alphanumeric＞, # Block Hash + Block Height + TxID '' SignatureValidFrom '' : ＜UTC Timestamp＞, # MinerSignature validity time '' APIversion '' : ＜Numeric＞ # API version NN.nn (major.minor version no.) } ]

若交易已經由各別挖掘者成功地挖掘並且標記為經確認(亦即經添加至區塊)，則可填充BlockHash及MinerID。若挖掘者尚未設置其MinerID，則其將經設定為「空」。

ReturnResult物件接著可含有以下挖掘結果中之一者： • 經提交-無問題，交易經提交至記憶體池 • 已確認—交易經確認—確認不能為0或空 • Rejected_DS-由於雙重花費經拒絕-DoubleSpendTxID不能為空 • Rejected_Policy—由於違反政策而經拒絕 • Rejected_Invalid—由於交易無效而經拒絕 • Rejected_FeeTooLow—費用過低，因此挖掘者將不在區塊中包括彼Tx • Rejected_KeepInMemPool—Tx被拒絕，但經保留在記憶體池中以檢查是否有雙重花費 • 未知—未看到交易或交易不存在—具有經提供TxID之交易可能不存在於記憶體池或區塊鏈中。若如此，此應在ResultDescription中加以陳述。第二態樣—用戶端

圖2係關於本揭露內容之第二態樣並且描繪由與用戶端相關聯的一或多個處理器執行之方法，其中用戶端以通訊方式耦接至實施如關於第一態樣所論述之方法的至少一個支付處理器。支付處理器實施關於圖1針對用戶端論述之支付服務或支付API，如上文所論述。

在圖2中所描繪的實例情境中，與獲得多個挖掘費用報價、基於經獲得多個挖掘費用報價當中的所選擇的費用報價提交交易以及發送與交易識別符有關的狀態查詢之步驟有關的實施例均經描述為按順序進行，亦即經描述為圖2之流程圖中之單個程序。然而，本揭露內容及第二態樣並非被認為限於此。可單獨地並且獨立於剩餘的步驟實施與獲得步驟202至206中之第一請求中之費用報價有關的下文所描述之步驟。類似地，可單獨地並且在與獲得費用報價之先前步驟不同的時間實施與提交來自步驟208至212之第二請求中之交易有關的步驟。以相同方式，自與來自步驟214之交易狀態詢問有關的步驟開始可在用戶端已經瞭解交易之識別符並且不需要遵循圖2之序列之後的任何時間實施。在本文中僅僅為易於解釋及理解起見而按順序展示所有步驟並且絕不將本揭露內容視為限於此類序列或情境。此外，如上文關於圖1所論述，可每次單獨地針對單個交易或針對將在單個請求中由用戶端提交之一組或一批多個交易(亦即同時)請求及/或獲得及/或提交及/或查詢費用報價。為易於解釋及理解，將關於第一請求/第二請求中之單個過渡及與用戶端相關聯的狀態查詢解釋圖2，但本揭露內容不以任何方式限於此。

步驟202描繪將第一請求發送至與用戶端相關聯的至少一個支付處理器當中的支付處理器以用於提供各別支付服務。如關於圖1的步驟102所論述，該請求係與用於為用戶端挖掘交易之一或多個費用報價相關。此第一請求係與關於步驟102所論述之HTTPS GET getFeeQuote有關。如上文所論述，該請求可用於為用戶端挖掘任何交易或可為對獲得用於挖掘交易之費用報價之請求，該交易與來自與用戶端相關聯的客戶之數位資產支付有關。

在步驟204中，自支付處理器接收多個挖掘費用報價，該等費用報價係關於用於以通訊方式耦接至服務於用戶端之支付處理器的多個挖掘者中之各者之挖掘費用。已經關於圖1的步驟104論述經接收費用報價之結構及細節。

步驟206描繪在步驟204中接收的一或多個費用報價當中選擇一費用報價。在一些實施例中，所選擇的費用報價可基於支付處理器提議之經推薦費用報價。在一些實施例中，由與用戶端相關聯的一或多個處理器進行選擇。所選擇的費用報價可為來自多個挖掘者之經獲得費用報價之平均值或中位值，或經獲得費用報價之最大值或輔助記憶體池中之最高費用報價，如上文所論述。因此，用戶端可回應於第一請求而選擇自多個挖掘者獲得之最高費用值。以此方式，所有挖掘者可具備以其各別當前經報價費用挖掘彼交易之相等機率。然而，用戶端可實際上選擇等於或高於所有經接收費用報價之中位值或平均值的費用報價，使得具有較高報價之挖掘者可簡單地將彼交易保留在輔助記憶體池中且使用其來檢查及/或拒絕交易之任何雙重花費。

步驟208描繪請求及/或處理來自與用戶端相關聯的客戶之數位資產支付之步驟。此可為由用戶端因數位資產支付而發送至客戶之支付請求或發貨單，該數位資產支付者針對二方使用施加至各別數位電子錢包實施之已知方法。由於用於將任何交易挖掘至區塊鏈之所選擇的費用報價已經為已知的，因此該請求可包括所選擇的費用報價或與所選擇的費用報價相關聯。

步驟210描繪發送將與自客戶至支付處理器之數位資產支付相關聯的給定交易提交至區塊鏈的第二請求之步驟。此步驟中之提交係基於用於挖掘步驟206中之給定交易之所選擇的費用報價。此步驟係關於用戶端將HTTPS POST submitTransaction(Tx)請求發送至圖1的步驟108中之支付處理器，且具有用於給定交易之呈JSON資料類型格式之相關細節。

步驟212描繪接收用於對應於經提交交易之區塊鏈交易的交易識別符(TxID)之步驟。如在圖1的步驟110及112中所論述，符合所選擇的費用報價之至少一個挖掘者創建TxID。在一些實施例中，此可與交易結果相關聯或作為交易結果之部分發送，該交易結果亦即展示各別挖掘者之對應的區塊鏈交易之當前挖掘狀態的TxResult。此係關於圖1的步驟114加以描述。

步驟214係關於當用戶端希望查詢先前在步驟210中提交之交易的挖掘狀態時用戶端發送狀態查詢，該交易係關於用戶端與客戶之間的支付。由於用戶端將在步驟212中接收經提交交易之TxID，因此此請求可基於TxID且呈格式HTTPS GET queryTransactionStatus (TxID)，如圖1的步驟116中所描述。

步驟216描繪獲得用於對應於在步驟214中查詢之交易識別符TxID的區塊鏈交易之挖掘狀態結果。此可在支付處理器接收對應的交易之細節之後呈JSON格式並且由支付處理器使用HTTPS發送至用戶端。狀態結果可呈TxResult JSON物件之形式，如圖1的步驟120中所見。第三態樣—挖掘者實施

圖3係關於本揭露內容之第二態樣並且描繪由多個挖掘者當中的一挖掘者執行之方法，其中多個挖掘者以通訊方式耦接至實施如關於第一態樣所論述之方法的至少一個支付處理器。該支付處理器為用戶端實施關於圖1所論述之支付服務或支付API。該用戶端經組配以實施關於圖2所論述之方法。

在圖3中所描繪的實例情境中，與提供多個挖掘費用報價、基於經獲得之多個挖掘費用報價當中的所選擇的費用報價產生/創建區塊鏈交易以及提供與交易識別符有關之挖掘狀態的步驟有關之實施例全部經描述為按順序進行，亦即經描述為圖3的流程圖中之單個程序。然而，本揭露內容及第三態樣不應視為限於此。可單獨地並且獨立於剩餘的步驟實施與回應於步驟302及304中之第一請求而提供當前費用報價有關的下文所描述之步驟。類似地，可單獨地且在與獲得費用報價之先前步驟不同的時間實施與回應於來自步驟308至314之第二請求而產生對應的區塊鏈交易有關的步驟。以相同方式，可在用戶端已經瞭解交易之識別符並且不需要遵循圖3的序列之後的任何時間實施與在步驟316中提供交易狀態有關的步驟。在本文中僅僅為易於解釋及理解而按順序展示所有步驟，且絕不應將本揭露內容視為限於此類序列或情境。此外，如上文關於圖1及圖2所論述，可每次單獨地針對單個交易或針對由用戶端將在單個請求中提交之一組或一批多個交易，亦即同時地，請求及/或獲得及/或提交及/或查詢費用報價。為易於解釋及理解，將關於第一請求/第二請求中之單個交易及與用戶端相關聯的狀態查詢來解釋圖3，但本揭露內容不以任何方式限於此。

步驟302描繪自支付處理器接收提供用於代表用戶端挖掘交易之費用報價的第一請求。此請求係關於自支付處理器發送之RPC getFeeQuote()請求，如關於圖1的步驟104所闡述。

步驟304描繪提供用於挖掘區塊鏈中之交易的與多個挖掘者當中的各挖掘者相關之當前費用報價。可以JSON物件FeeQuotes之格式提供費用報價，如關於圖1的步驟104所闡述。

步驟306描繪多個挖掘者當中的一挖掘者接收與將與用戶端相關聯的給定交易提交至區塊鏈有關的第二請求之步驟，其中給定交易係基於來自用戶端之所選擇的費用報價。給定交易係關於圖2之步驟210中之POST submitTransaction(Tx)中的Tx，亦即用戶端與客戶之間的給定數位資產支付交易。自支付處理器接收之此RPC版本為用於給定交易之RPC createRawTransaction(Tx)，如關於圖1的步驟110所解釋。

步驟308描繪檢查挖掘者滿足或符合來自用戶端之所選擇的費用報價。此可包括判定由各別挖掘者在步驟304中提供至支付處理器之當前費用報價是否等於或低於用戶端願意為挖掘給定交易Tx所支付的所選擇的費用報價。

若當前費用報價符合所選擇的費用報價，則在步驟310中，創建與給定交易對應的區塊鏈交易。此係關於圖1的步驟110論述。在一些實施例中，對應於給定交易之經十六進位編碼之原始交易經返回至支付處理器。輸出指令碼或UTXO亦經提供至支付處理器，如在圖1的步驟112中所論述，其中該輸出指令碼包括與已經由各別挖掘者創建的對應的區塊鏈交易相關聯的交易識別符(TxID)。用於區塊鏈交易之輸出指令碼(UTXO)接著可添加至與用於立即或稍後挖掘之挖掘者相關聯的記憶體池。

若當前費用報價不符合所選擇的費用報價，亦即若各別挖掘者之當前費用報價高於用戶端允許或選擇的費用報價，則各別挖掘者可在一些實施例中選擇以低於當前費用報價之費用來挖掘，或可選擇不挖掘給定交易，此係由於所選擇的費用低於其各別當前經報價費用。在各別挖掘者選擇不以較低所選擇的費用報價來挖掘交易之實施例中，在步驟312中，各別挖掘者可實際上在與各別挖掘者相關聯的輔助記憶體池中添加與針對給定交易構建之區塊鏈交易有關的細節。在一些實施例中，此交易可經保留在輔助記憶體池中且用於檢查是否有雙重花費。儲存於輔助記憶體池中之所有交易均可具有到期時間，其後可清除該等交易。

假設已經創建區塊鏈交易，亦即假設各別挖掘者符合用戶端設定之所選擇的費用報價的要求，則步驟316係關於各別挖掘者接收與針對用戶端創建之區塊鏈交易的TxID相關聯的狀態查詢。此狀態詢問係基於經由API轉換器接收之RPC請求RPC getRawTransaction(TxID)，如關於圖1的步驟116及118所論述。

在步驟318中，基於與各別挖掘者相關之對應的區塊鏈交易之目前的挖掘狀態之結果經提供至支付處理器。此可基於用於TxStatus之JSON物件結構，如關於圖1中之步驟120所解釋。

圖4為作為API由支付處理器404提供至用戶端402之支付服務的部署架構之示意圖。可存在多於一個此類支付處理器404，且一或多個支付處理器404亦可實施為用戶端之一部分，或可與用戶端相關聯，或可與用戶端單獨地實施並且經由諸如網際網路之通訊網路與用戶端通訊。如在以上態樣中所論述，用戶端402與支付處理器404之間的通訊使用HTTPS協定。API轉換器406亦在此示意圖中單獨地展示但可在一些實施例中實施為支付處理器404之一部分。在一些實施例中，API轉換器406可由多個挖掘者412-1至412-n操作或與該多個挖掘者相關聯地實施。API轉換器406允許在將HTTPS請求發送至耦接至支付處理器404之一或多個挖掘者412-1至412-n以用於將服務提供至用戶端402之前將HTTPS請求轉換為RPC請求。API轉換器406經展示為經由防火牆408連接至挖掘者412-1至412-n。與挖掘者412-1至412-n相關聯的所有通訊均使用RPC。節點連接器410亦經展示為用於經由防火牆408將多個挖掘者412-1至412-n連接至支付處理器404。在一些實施例中，節點連接器可確保或處理與實施各別支付服務之一或多個支付處理器相關聯的RPC呼叫，如關於圖1所論述。節點連接器410提供API轉換器406與一或多個挖掘者412-1至412-n之間的安全通訊通道。

可存在經由API轉換器406連接挖掘者412-1至412-n之一或多個支付處理器404。用戶端402將最可能包括數位電子錢包應用程式以獲得用於挖掘者費用之報價(getFeeQuote)、提交交易(submitTransaction)及詢問交易的狀態(queryTransactionStatus)，如關於第一至第三態樣針對個別或多個交易所解釋。支付處理器404充當至用戶端402之REST端點，且用戶端可匿名存取此服務。挖掘者412-1至412-n可挖掘一或多個節點以交換挖掘獎勵，該等挖掘獎勵在一些實施例中可由區塊獎勵及挖掘者費用組成。區塊獎勵被稱為一旦挖掘者412成功地挖掘區塊即被授予之BSV或密碼貨幣。挖掘者費用為挖掘者412在其確認交易並將其添加至最新挖掘的區塊之情況下接收的獎勵。

圖5為描繪圖4中所展示的架構之組件之間的用於實施來自用戶端之getFeeQuote命令或範本之資料流動的示意圖。此在上文已經詳細關於圖1至圖3論述，且圖4簡單地示意性地闡述用戶端、支付處理器及挖掘者的相互作用以用於獲得挖掘費用報價。當HTTPS GET getFeeQuote命令在步驟501中發送至支付處理器404時，該流動源自用戶端402。在步驟502中，GET命令經發送至API轉換器406，該API轉換器在步驟503中將該GET命令轉換為RPC命令RPC getFeeQuote()。在步驟504中，MinerFeeQuote作為JSON物件格式自多個挖掘者412-1至412-n中之各挖掘者412返回至API轉換器406，該MinerFeeQuote又在步驟505中經提供至支付處理器404。步驟502至505針對多個挖掘者412-1至412-n當中的各挖掘者重複，且該結果(費用報價)在步驟506中在HTTPS傳輸中經發送至用戶端402。

圖6為描繪圖4中所展示的架構之組件之間的用於實施來自用戶端之submitTransaction命令或範本之資料流動的示意圖。此在上文已經詳細關於圖1至圖3論述，且圖4簡單地示意性地闡述用戶端、支付處理器及挖掘者的相互作用以用於向用戶端提供與支付相關聯的區塊鏈交易。當HTTPS POST submitTransaction(Tx)命令針對用戶端402與客戶之間的給定交易Tx而在步驟601中發送至支付處理器404時，該流動源自用戶端402。如關於以上態樣所提及，Tx可與所選擇的費用報價(此圖中未展示)相關聯。在步驟602中，POST命令經發送至API轉換器406，該API轉換器在步驟603中將該POST命令轉換為RPC命令RPC createRawTransaction(Tx)。接著針對符合所選擇的費用報價之各挖掘者412構建區塊鏈交易。在步驟604中，經十六進位寫碼之區塊鏈交易經返回至API轉換器406。該交易包括特定識別符TxID，如在以上態樣中所解釋。在步驟605中，與區塊鏈交易相關聯的輸出經發送至支付處理器404。在步驟606中，與區塊鏈交易相關之結果接著作為包括TxID之JSON TxResult物件返回至用戶端。

圖7為描繪圖4中所展示的架構之組件之間的用於實施來自用戶端之queryTransactionStatus命令或範本之資料流動的示意圖。此已經在上文詳細關於圖1至圖3論述，且圖4簡單地示意性地闡述用戶端、支付處理器及挖掘者的相互作用以用於提供與同用戶端相關聯的支付相關聯的區塊鏈交易。當HTTPS GET queryTransactionStatus(TxID)命令針對與區塊鏈交易有關的給定交易TxID在步驟701中發送至支付處理器404時，該流動源自用戶端402，該區塊鏈交易先前作為圖6中之submitTransaction流動之部分經再調諧至用戶端。在步驟702中，GET命令經發送至API轉換器406，該API轉換器在步驟703中將該GET命令轉換為RPC命令RPC getRawTransaction(TxID)。接著識別與給定挖掘者412相關聯的區塊鏈交易，該區塊鏈交易與TxID相關。在步驟704中，經識別之經十六進位寫碼之區塊鏈交易及其相關聯的狀態經返回至API轉換器406。在步驟705中，與同TxID相關之區塊鏈交易相關聯的狀態結果經發送至支付處理器404。在步驟706中，與用於TxID之區塊鏈交易相關之狀態結果接著作為JSON TxStatus物件經返回至用戶端。

此外，如上文關於圖1至圖3所論述，可每次單獨地針對單個交易或針對將由用戶端在單個請求中提交之一組或一批多個交易，亦即同時地，請求及/或獲得及/或提交及/或查詢費用報價。為易於解釋及理解，上文已經關於第一請求及/或第二請求中之單個過渡及/或與用戶端相關聯的狀態查詢解釋圖4至圖7，但應理解，本揭露內容不以任何方式限於此。第四態樣—回叫識別符

圖8為根據第四態樣之描繪促進用於交易之回叫機制的方法之流程圖。此圖係關於由與支付服務相關聯的一或多個處理器實施之方法，如上文關於第一態樣所論述。

步驟802包括自一或多個用戶端當中的給定用戶端接收請求。該請求係與提交與數位資產相關聯的交易有關。舉例而言，此可為提交在圖1的步驟108中解釋之交易的第二請求。該請求亦與回叫識別符相關聯。在一些實施例中，該回叫識別符可為由用戶端提供或與用戶端相關聯的回叫識別符。舉例而言，此可為URL或API端點，可使用該URL或API端點聯繫該用戶端。在一些狀況下，此亦可指向與用戶端相關聯的位置。在一些狀況下，回叫識別符可為位置或識別符通訊通道。下文在圖9至圖11中進一步解釋此通道。回叫識別符之目的在於實現或允許建立用戶端與另一實體之間的直接通訊之手段。該回叫識別符係特定針對於用戶端，且在一些狀況下，特定針對於特定主題，諸如與此步驟中之請求相關聯的交易。

步驟804包括將與請求相關聯的交易提交至多個挖掘者當中的給定挖掘者以用於將該交易包括在區塊鏈中。此係類似於針對圖1的步驟110中之第二請求所實行的程序。

步驟806包括向用戶端識別給定挖掘者。此可藉由多個技術執行，該等技術諸如將與給定挖掘者相關聯的端點或URL提供至用戶端。此可使用HTTPS傳輸協定發送至用戶端。在一些狀況下，若挖掘者係與用於諸如使用上文所提及之bsvalias定址服務進行定址之別名相關聯，則此可經提供至用戶端。在一些狀況下，若挖掘者係與如上文所提及之挖掘者ID及/或信譽相關聯，則此類資訊亦可提供至用戶端。在一些狀況下，此識別步驟可連同下文闡述之步驟812一起進行或在該步驟之後進行。

步驟808包括將步驟802中所描述之回叫識別符提供至挖掘者，使得挖掘者可使用該回叫識別符來直接聯繫用戶端。在一些狀況下，若支付處理器代表用戶端處置通訊，則回叫識別符可指向支付處理器。此圖係關於其中回叫識別符係用於用戶端之情境，但本揭露內容不限於此。舉例而言，回叫識別符可為唯一地識別用戶端或支付處理器之經加密識別符(端點)。

在步驟810中，回應係自給定挖掘者接收，且具有與已經針對步驟802中之交易請求產生的對應的區塊鏈交易有關的細節。此將包括用於交易之交易識別符(TxID)，其可提供至用戶端。在一些狀況下，一旦已經接收TxID或在接收TxID之後，步驟806中之挖掘者身份可提供至用戶端。在一些實施例中，此步驟中之回應包括與第一態樣中之如上文所提及的對應的區塊鏈交易相關聯的輸出指令碼，例如未使用交易輸出(UTXO)。用於對應的區塊鏈交易之此交易識別符(TxID)接著發送至用戶端。

步驟812包括基於在步驟802中提及之回叫識別符為用戶端啟用或處理由挖掘者提供的對應的與區塊鏈交易(TxID)相關之至少一個回叫通知。若此回叫識別符為用於用戶端之回叫端點URL或URI，則該訊息可作為HTTP POST訊息直接提供至此類位置。可基於一或多種已知技術對該訊息進行加密。

圖9係關於本揭露內容之第四態樣之第二實施，其中與請求相關聯的回叫識別符係關於由通道處理器向用戶端提供之通道。如上文所提及，通道處理器可為向用戶端提供通道服務之單獨的實體，或可為與支付處理器相同的實體。此圖中之以下步驟描繪通道處理器實施之實施例。

步驟902描繪自已經為通道服務簽名之給定用戶端接收與通道相關聯的請求，諸如在以nChain Holdings Limited之名義提交的英國專利申請案第2007597.4號中所論述。此實施例中之此請求係關於創建通道。然而，通道服務能夠實現其他功能，諸如更新與現有通道相關聯的API。在大多數狀況下，可檢查用戶端之身份以查看用戶端是否註冊使用通道服務及由該通道服務提供的功能。在一些實施例中，此可基於註冊期間之已知認證方法，諸如密碼保護的登錄認證等等。校驗可基於經接收密碼匹配經儲存記錄中之密碼。在其他實施例中，基於密碼或定址私用/公用密鑰對之標準PKI技術亦可用於驗證數位簽名，該數位簽名可存在於在步驟902中自用戶端接收之請求中。在此狀況下，可藉由檢查是否可使用公用密鑰成功地恢復或認證藉由私用密鑰簽名之請求來驗證用戶端之身份。若用戶端無效或未註冊，則此步驟中之請求不會進一步進行，或註冊步驟可藉由通道服務啟動。

在步驟904中，經請求通道功能及/或訊息功能經提供至用戶端。

下文展示與用於創建通道及/或訊息功能/API之請求相關聯的方案及/或格式之一些實例，連同用於由通道處理器提供之回應的實例方案。 1.1通道API：

通道API可為JSON經由HTTP之API用戶端賬戶，其由通道服務至服務提供以創建及/或管理用於同級間通訊之通道。

在一些實施例中，所有API端點均可需要認證。特定的認證方案可為實施判定的。常見形式包括諸如OAuth、基本認證及承載符記方法之方案。如上文所提及，任擇地，可藉由用戶端提供或產生之API符記保護通道API。

創建通道：創建用戶端所擁有的新的通道，亦即用於通道服務之賬戶持有者

請求格式： POST /api/賬戶/＜賬戶-id＞/通道授權：... 內容類型：應用程式/json 內容長度：... { "public_read": true | false, "public_write": true | false, "sequenced": true | false, "retention": { "min_age_days": null | ＜number＞, "max_age_days": null | ＜number＞, "auto_prune": true | false } }

回應格式：成功地創建之回應含有初始存取符記。賬戶憑證可用於存取通道API，但符記可能需要用於存取訊息傳遞API。為此，出於其讀取及寫入至通道的目的，此初始存取符記屬於賬戶持有者。 201 OK 內容類型：應用程式/json 內容長度：... { "id": "...", "href": "https://example.org/channel/＜id＞", "public_read": true | false, "public_write": true | false, "sequenced": true | false, "head": ＜sequence＞, "retention": { "min_age_days": null | ＜number＞, "max_age_days": null | ＜number＞, "auto_prune": true | false }, "access_tokens": [ { "id": "...", "token": "...", "description": "Owner", "can_read": true, "can_write": true } ] } }

訊息API允許賬戶持有者及相關對方(用於通道之其他實體)自用於給定通道之訊息讀取或寫入該訊息。以下訊息API可作為JSON經由HTTP之API提供給賬戶持有者及其對方，以交換訊息。

2.1用於新訊息的測試通道請求格式： HEAD/api/通道/＜id＞授權：＜api-符記＞回應格式： 201 OK ETag：＜max-序列＞

2.2將訊息寫入至通道請求格式： POST /api/通道/＜id＞授權：＜api-符記＞內容類型：... 內容長度：... 回應格式： a) 已接受該訊息經寫入至通道。 201已創建 b) 排序失敗該通道按順序創建，且與請求相關聯的API符記尚未標記為讀取通道中之最新訊息。若其仍為適當的，則該用戶端可能需要重試寫入嘗試。 409衝突 c) 訊息過大在端至端加密例如基於雜訊協定保護所有訊息之實施例中，任一單個訊息之最大大小經設定為65536個位元組。由於不應存在大於此之訊息，因此在一些實施例中限制任何寫入至通道之訊息之最大大小可為有用的。大於此之訊息可能被通道拒絕。 413有效負載過大 d) 超過儲存配額已經超過可在一些實施例中由服務操作者設定之配額。用戶端請求可為有效的，但儲存服務此時無法實現該用戶端請求。 507不充足的儲存

2.3 獲取通道中之訊息返回來自通道之所有訊息，任擇地將其過濾為未讀。請求格式： GET /api/通道/＜id＞[?未讀=真] 授權：＜api-符記＞未讀的查詢字串參數係任擇的。回應格式： 201 OK 內容類型：應用程式/json 內容長度：... ETag：＜max-序列＞ { "messages": [ { "sequence": ＜number＞, "received": ＜unix-timestamp＞, "content_type": "...", "payload": "hex/base64" } ] }

2.4將訊息標記為已讀或未讀：將訊息標誌為已讀或未讀。請求格式： POST /api/通道/＜id＞/＜序列＞[?次序=真] 授權：＜api-符記＞內容類型：應用程式/json 內容長度：... {"read": true | false } 任擇的早期的參數允許用戶端在單個呼叫中將具有低於或等於經供應＜序列＞路徑自變數之序列的所有訊息標記為已讀。回應格式： 201 OK 在步驟906中，與經請求通道相關聯的存取符記或API符記經提供至用戶端。在一些實施例中，視需要，若例如權限已經修改或用戶端針對給定通道不再需要該等權限，則存取符記亦可經取消或撤銷。

為此，下文給出實例方案：

3.1 產生通道API符記請求格式： POST /api/賬戶/＜賬戶-id＞/通道/＜通道-id＞/api-符記授權：... 內容類型：應用程式/json 內容長度：... { "description": "...", "can_read": true | false, "can_write": true | false } 回應格式：此為唯一的將返回符記值的API呼叫。若其丟失，則應刪除符記並且用新的符記替換該符記。 201經創建內容類型：應用程式/json 內容長度：... { "id": "...", "token": "...", "description": "...", "can_read": true | false, "can_write": true | false }

1.6 撤銷通道API符記：請求格式： DELETE /api/賬戶/＜賬戶-id＞/通道/＜通道-id＞/api-符記/＜符記-id＞授權：... 回應格式： 204無內容

步驟908展示提供關於諸如交易之特定主題的通知或警示或任何其他資訊，其針對用戶端安全地自其他實體(在如圖8中所展示之實施例中，此實體為挖掘者)接收。因此，此被稱作關於特定交易之回叫通知，其可具有如圖8中所提及之TxID。此在關於創建通道所針對的給定交易或主題而引發異常之情況下可為狀態變化之通知，或任何其他通知。

由於經由通道接收通知，因此用戶端不需要一直在線上，且每當用戶端與通道處理器連接或重新連接(在線上)即可異步地遞送通知。在一些狀況下，可能會提供設置，該等設置可能會強制要求用戶端應保持連接的最短時間，或該等設置可確保用戶端保持連接直至用戶端或與用戶端相關聯的電子錢包消耗掉通道中之所有「未讀」警示或通知為止。因此，在一些實施例中，一旦用戶端或電子錢包自該通道消耗或接收通知，即可允許用戶端斷開。可存在針對給定用戶端提供之許多此類通道，一個通道有一個主題或交易。

在一些實施例中，可存在額外步驟，以偵測用戶端是否連接至通道處理器，亦即是否在線上，亦即是否離線。此可藉由已知技術進行以當一或多個通知或訊息到達通道中時看到用戶端存在網路連接。

當用戶端在線時會在通道中「提取」一次用於用戶端之回叫通知或訊息以確保同步，亦即與通道中之訊息及經遞送至用戶端之訊息同步。

若當通道通知到達時用戶端未連接或離線，則該等通道通知經儲存於與通道處理器相關聯的記憶體或快取記憶體中。此可在一些實施例中特定針對於給定用戶端。一旦用戶端在線上或當偵測到用戶端經連接時，可將此等通知推送或提供至用戶端實體。推送通知可經發送至用戶端，使得其可獲得通道中之資料或未讀訊息。因此，當用戶端離線時，訊息或通知係由通道服務或通道處理器儲存。一旦用戶端在線上，該等訊息或通知接著經提供至用戶端。

儘管可在通道中發送任何類型的訊息，其中其他實體為自用戶端挖掘交易之挖掘者，但在大多數狀況下用於挖掘者與用戶端之間的直接通訊之情境為： 1.當交易狀態更新或改變時 2.在自挖掘者接收對資訊之特用請求後

在第一情境中，每當需要告知用戶端狀態變化或異常，諸如交易之雙重花費，或每當用戶端需要確認挖掘或需要確認交易之有效性或無效性等，即發起回叫通知。

在第二情境中，用戶端可在某一可為週期性或任意的時間直接使用相同通道來自挖掘者請求狀態更新。

圖10係關於本揭露內容之第四態樣的第三實施，其中用戶端係與由圖9中所闡述之通道處理器實施的通道服務相關聯。此係用於其中圖8中之回叫識別符為用戶端使用通道服務創建之通道的實施例。此圖中之以下步驟描繪用戶端實施之一實施例。

在步驟1002中，用戶端為通道服務準備請求並且將其發送至通道服務(通道處理器)。所準備的請求可由用戶端使用超文件傳送協定(HTTP)或類似傳輸協定格式來發送。在一些實施例中，所準備的請求經發送至經實施為HTTP或REST API之通道處理器，且回應亦可以HTTP傳輸協定格式提供至用戶端。如上文所提及，通道處理器與支付處理器可為相同實體，或通道處理器可為單獨的實體。

此實施例中之請求係關於創建通道，該通道可實現、允許或提供用於與諸如挖掘者之另一實體的直接通訊之機制。

在步驟1004中，一或多個功能，諸如通道或訊息功能/API，係自通道處理器接收以使得用戶端能夠創建通道以確保與其他實體直接通訊。此通道功能及訊息功能係在圖9的步驟904中闡述，自通道處理器接收。亦針對通道接收用於如步驟906中所見之請求的訊息API以及存取符記。

步驟1006描繪將請求發送至支付處理器以提交與數位資產相關聯的交易。此可為與用戶端的客戶相關聯的支付交易或類似交易。此步驟類似於圖2的步驟208，亦如上文關於圖8的步驟802所闡述。該請求經由HTTP發送至支付處理器之API且可為POST請求。

在步驟1008中，交易識別符(TXID)係自支付處理器接收。此係基於來自給定挖掘者之回應，如在圖8之步驟810中所解釋。

在步驟1010中，用戶端識別或瞭解在先前步驟中將TxID發送至支付處理器之挖掘者。此可基於與挖掘者相關聯的API或位置或挖掘者ID及/或信譽，如上文在圖8中所論述。

在步驟1012中，接著使用在步驟1004中自通道處理器接收之API以運用已經在先前步驟1010中識別之挖掘者來創建通道。經接收存取符記可用於認證其他實體並且提供對與通道相關聯的各種功能之存取。在一些實施例中，訊息API以及存取符記可經發送至其他實體以用於經由通道通訊。在一些實施例中，在創建通道之後，交握協定可在用戶端與挖掘者之間進行以建立用於保護經由通道之通訊的密鑰。諸如雜訊協定框架或Libsodium密鑰交換機制之任何已知方法可用於此。

在步驟1014中，經由通道接收來自挖掘者之回應。此係可能的，因為另一方，亦即挖掘者，已在先前步驟中接收所有所需訊息API以及存取符記以用於與用戶端直接通訊。來自挖掘者之回應將與步驟1008中之特定TxID相關聯，且因此各別通道中之通訊將特定針對於交易識別符。該訊息可係關於與TxID相關聯的任何內容。舉例而言，通知可經由通道發送以通知用戶端TxID為先前交易之雙重花費。若交易已經存在於臨時記憶體池中，則可為此狀況。否則，一旦交易包括於區塊中，則該訊息可與用於交易之挖掘的默克爾證明相關聯。

圖11係關於本揭露內容之第四態樣的第四實施，其中用戶端係與由圖9中所闡述之通道處理器實施的通道服務相關聯。此係用於其中圖8中之回叫識別符為用戶端使用通道服務創建之通道的實施例。此圖中之以下步驟描繪挖掘者實施之一實施例。

在步驟1102中，挖掘者自支付處理器接收對挖掘交易之請求，如圖8的步驟804中所見。

在步驟1104中，挖掘者產生區塊鏈交易。此步驟類似於圖3的步驟310，其中在一些實施例中，產生對應於經提交交易之經十六進位編碼之原始交易。因此提供輸出指令碼或UTXO，其包括與已經由各別挖掘者創建之對應的區塊鏈交易相關聯的交易識別符(TxID)。用於區塊鏈交易之輸出指令碼(UTXO)接著可添加至與挖掘者相關聯的記憶體池以用於立即或稍後進行挖掘。

在步驟1106中，用於對應的區塊鏈交易之此交易識別符(TxID)接著經由支付處理器發送至用戶端，使得用戶端可存取TxID且亦可識別挖掘者。

在步驟1110中，一旦用戶端使用通道服務創建通道以用於直接與挖掘者進行通訊，則挖掘者運用任何相關聯的訊息API及存取符記自用戶端接收對通道之存取。

在步驟1112中，挖掘者檢查在步驟1102中提交之交易是否為前一個交易之雙重花費。如上文所提及，此可藉由檢查相同交易是否存在於與挖掘者相關聯的輔助或臨時記憶體池中或是否已經在區塊鏈中挖掘相同交易來實施。

若狀況如此，則挖掘者接著產生雙重花費通知或警示以使用通道發送回至用戶端。當受到激勵以維持其信譽(其可經由其挖掘者ID來追蹤)之挖掘者告知用戶端有關嘗試使用數位資產，諸如先前由同一用戶端(亦即商家電子錢包)使用之BSV時，會發出雙重花費通知。

實例方案之一個版本可為：請求：

回應：

下文給出用於雙重花費通知之實例方案之另一版本。請求：POST /mapi/tx 主體： 當內容類型為應用程式 /json 時：

回應：

在步驟1116中，如上文所見到之雙重花費回叫通知或「callbackpayload」經發送至callbackURL，其在此實施例中為挖掘者已接收對其存取之通道。該通道可由API或位置或識別符識別。該通知使用與已經向挖掘者提供對其存取之通道相關聯的訊息API及存取符記經添加至通道中。

若在步驟1102中提交之交易並非雙重花費，則在步驟1118中，挖掘者使用用於挖掘的已知技術繼續挖掘與區塊鏈相關聯的區塊中之交易，該等已知技術中之一些在本申請案之背景中加以論述。

在步驟1120中，挖掘者接著產生將交易包括至區塊中之證明。

在一些實施例中，該證明可為默克爾樹證明。此為經組織為樹之已知經認證資料結構。各資料區塊之散列經儲存於基層或葉上之節點中，並且樹或分支之每一內部節點含有密碼散列，其自其二個子/同層級節點之散列計算。樹、默克爾根之頂部節點唯一地識別自其構建樹之資料集。因此，默克爾樹允許高效的包括證明，其中挖掘者或證明者節點藉由運用審查路徑向提交者或驗證者節點發送證明而向其展示某一資料區塊為經認證資料集之一部分。該審查路徑含有重新計算默克爾根所必需之節點散列，而不需要提交者揭露整個資料集。在比特幣SV中，區塊中所含有的交易經儲存於默克爾樹中。

該實例方案可為：請求：

回應：

下文給出用於默克爾證明通知之實例方案之另一版本：請求：POST /mapi/tx 主體： 當內容類型為應用程式 /json 時：

回應：

在步驟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傳輸至其他系統之介面。舉例而言，網路介面子系統2616可使資料技術員能夠將裝置連接至網路，使得資料技術員可能夠在處於諸如資料中心之遠端位置中時將資料傳輸至裝置及自裝置接收資料。

使用者介面輸入裝置2612可包括：一或多個使用者輸入裝置，諸如鍵盤；指標裝置，諸如整合式滑鼠、軌跡球、觸控板或圖形平板電腦；掃描器；條形碼掃描器；觸控螢幕，其併入至顯示器中；音訊輸入裝置，諸如語音辨識系統、麥克風；以及其他類型之輸入裝置。一般而言，使用術語「輸入裝置」意欲包括用於將資訊輸入至計算裝置2600之所有可能類型的裝置及機構。

一或多個使用者介面輸出裝置2614可包括顯示子系統、印表機或諸如音訊輸出裝置之非視覺顯示器等。顯示子系統可為陰極射線管(CRT)、諸如液晶顯示器(LCD)之平板裝置、發光二極體(LED)顯示器或投影裝置或其他顯示裝置。一般而言，使用術語「輸出裝置」意欲包括用於輸出來自計算裝置2600之資訊的所有可能類型的裝置及機構。舉例而言，一或多個使用者介面輸出裝置2614可用以呈現使用者介面以在使用者與應用程式之互動可係適當的時促進此互動，該等應用程式執行所描述之程序及其中之變化。

儲存子系統2606可提供電腦可讀儲存媒體，該電腦可讀儲存媒體用於儲存可提供本揭露內容之至少一個實施例之功能性的基本程式設計及資料構建。應用程式(程式、程式碼模組、指令)在由一或多個處理器執行時可提供本揭露內容之一或多個實施例的功能性，且可儲存於儲存子系統2606中。此等應用程式模組或指令可由一或多個處理器2602執行。儲存子系統2606可另外提供用於儲存根據本揭露內容所使用之資料的儲存庫。舉例而言，主記憶體2608及快取記憶體2602可提供用於程式及資料之揮發性儲存器。持久性儲存器2610可提供用於程式及資料之持久性(非揮發性)儲存器且可包括快閃記憶體、一或多個固態驅動機、一或多個磁性硬碟驅動機、具有相關聯可移媒體之一或多個軟碟驅動機、具有相關聯可移媒體之一或多個光學驅動機(例如CD-ROM或DVD或Blue-Ray)驅動機及其他類似儲存媒體。此程式及資料可包括用於實行如本揭露內容中所描述的一或多個實施例之步驟的程式以及與如本揭露內容中所描述之交易及區塊相關聯的資料。

計算裝置2600可具有各種類型，包括攜帶型電腦裝置、平板電腦、工作站或下文所描述之任何其他裝置。另外，計算裝置2600可包括另一裝置，其可藉由一或多個埠(例如，USB、耳機插口、Lightning連接器等)連接至計算裝置2600。可連接至計算裝置2600之裝置可包括經組配以接受光纖連接器之多個埠。因此，此裝置可經組配以將光學信號轉換成可藉由將裝置連接至計算裝置2600之埠傳輸的電信號以供處理。歸因於電腦及網路不斷改變之本質，出於說明裝置之較佳實施例之目的，圖12中描繪之計算裝置2600之描述僅意欲作為一特定實例。具有比圖12中描繪之系統多或少之組件的許多其他組配係可能的。經枚舉實例實施例

本揭露內容特此基於與上述態樣相關之以下條項來論述，該等條項在本文中經提供作為例示性實施例以用於較佳地解釋、描述及理解所主張之態樣及實施例。

1. 一種向用於與一區塊鏈相關聯的交易之一或多個用戶端提供一支付服務之電腦實施之方法，該方法由一支付處理器實施並且包含以下步驟：自該一或多個用戶端當中的一給定用戶端接收一請求，該請求為將與一數位資產相關聯的一交易提交至該區塊鏈，該請求與用於實現該給定用戶端與用於該交易之另一實體之間的直接通訊之一回叫識別符相關聯；將與該請求相關聯的該交易提交至多個挖掘者當中的一給定挖掘者，以用於將該交易包括在該區塊鏈中；向該用戶端識別該給定挖掘者；將該回叫識別符提供至該挖掘者；回應於自該給定挖掘者接收與用於該請求之一對應的區塊鏈交易相關之一回應，該方法進一步包括：為該用戶端啟用或處理由該挖掘者提供之與該對應的區塊鏈交易相關之至少一個回叫通知，該回叫通知係基於與該請求相關聯的該回叫識別符。

2. 如條項1之方法，其中來自該挖掘者之經接收回應係與一交易識別符(TxID)相關聯，該方法進一步包括將用於該對應的區塊鏈交易之一交易識別符(TxID)發送至該用戶端。

3. 如任一前述條項之方法，其中該經接收回應為與該區塊鏈交易相關聯的一輸出指令碼，該輸出指令碼包括與用於該挖掘者之一記憶體池相關聯的一未使用交易輸出(UTXO)，該UTXO包括用於該區塊鏈交易之該交易識別符(TxID)。

4. 如任一前述條項之方法，其中該支付處理器經實施為用於該一或多個用戶端之一表示狀態傳送(REST)端點，且其中該方法進一步包含提供與該支付處理器相關聯的一應用程式設計介面(API)閘道器之步驟以用於執行以下步驟：使用一超文件安全傳送協定(HTTPS)傳輸協定格式自該用戶端接收該請求；將各別請求轉換為一遠端程序呼叫(RPC)格式，且將該RPC提交至該挖掘者；以一RPC格式自該挖掘者接收與一對應的區塊鏈交易相關聯的一回應；以及轉換各別回應以用於使用該HTTPS傳輸協定發送至該用戶端。

5. 如任一前述條項之方法，其包含驗證該給定挖掘者之身份的步驟，其中該驗證係基於與該給定挖掘者相關聯的一數位簽名，或基於與該給定挖掘者相關之一識別符，任擇地，該識別符係與用於該給定挖掘者之一信譽指示符相關聯。

6. 如任一前述條項之方法，其中該回叫通知係關於由該給定用戶端提交之該交易之一雙重花費的一通知，或其中該回叫通知係關於由該給定用戶端提交之該交易包括在該區塊鏈中的一證明。

7. 如任一前述條項之方法，其中該回叫識別符為與該用戶端相關聯的用於一通道之一位置，或其中該回叫識別符為用於該用戶端之一通用資源識別符(URI)。

8. 如任一前述條項之方法，其進一步包含向該給定挖掘者提供對該通道之存取之步驟，其中該提供步驟包括將與該請求相關聯的用於該通道之一通道識別符或位置及與該通道相關聯的一或多個存取符記提供至該挖掘者。

9. 一種用於為一或多個用戶端實施一通道服務之電腦實施之方法，該方法由一通道處理器實施並且包含以下步驟：自該一或多個用戶端當中的一給定用戶端接收一請求，該請求與創建一通道相關；向該給定用戶端提供對一或多個功能之存取，該一或多個功能經由該通道實現該給定用戶端與另一實體之間的直接通訊，其中該一或多個功能包括：用於傳輸資料之與該通道相關之通道功能或程序；及/或與使用該通道傳輸該資料相關之訊息功能或程序；發出用於該通道之一或多個存取符記，該一或多個存取符記經組配以用於經由該通道與另一實體進行安全通訊；及儲存與該通道相關聯的一或多個通知及/或向該給定用戶端提供該一或多個通知。

10. 如條項9之方法，其中該一或多個功能為向該給定用戶端發出或經提供至該給定用戶端之應用程式設計介面(API)，該等API包括用於該通道之通道API及與該通道相關聯的用於資料之訊息API；且其中該等存取符記為特定針對於該通道或一給定訊息之API符記。

11. 如條項9或10之方法，其中提供對一或多個功能之存取之步驟包括提供一JavaScript物件表示法(JSON)經由超文件傳送協定(HTTP)之API，以實現創建及/或管理一或多個通道。

12. 如條項9至11中任一項之方法，其中與該等通道相關聯的該一或多個通知為來自一挖掘者之回叫通知，該挖掘者為經由該通道與該給定用戶端直接通訊之另一實體。

13. 如條項12之方法，其中該回叫通知係關於由該給定用戶端提交之一交易之一雙重花費的一通知。

14. 如條項13之方法，其中該回叫通知係與該通道中之一返回有效負載相關聯，該返回有效負載由該挖掘者提供，該返回有效負載包括以下資料： -作為一雙重花費之區塊鏈交易的交易識別符(TxID)；以及任擇地 -提交區塊鏈交易之支付處理器的一服務端點。

15. 如條項12之方法，其中該回叫通知係關於由該給定用戶端提交之一交易包括在該區塊鏈中的一證明。

16 . 如條項15之方法，其中該回叫通知係與該通道中之一返回默克爾證明相關聯，該返回默克爾證明由該挖掘者提供，該返回默克爾證明包括以下資料： -與該默克爾證明有關之一區塊鏈交易的一交易識別符(TxID)； -其中包括該區塊鏈交易之區塊的一區塊標頭；以及 -用於該交易識別符(TxID)之同層級散列的一陣列。

17. 如條項9至16中任一項之方法，當該用戶端離線或不以通訊方式連接至該通道處理器時，一或多個回叫通知為用於在該通道中針對該給定用戶端儲存或列隊之資料的推送通知。

18. 如條項9至17中任一項之方法，當該用戶端在線上或以通訊方式連接至該通道處理器時，與該一或多個回叫通知相關聯的該資料係自該通道提供或提取。

19. 如條項9至18中任一項之方法，其中該通道處理器為或包括一支付處理器，且其中該方法包括由該支付處理器實施之如條項1至8中任一項之方法。

20. 一種用於處理與一區塊鏈相關聯的交易之電腦實施之方法，該方法由與一用戶端相關聯的一或多個處理器實施並且包含以下步驟：發送與一通道服務相關之一通道請求，該通道服務由一通道處理器實施，該請求係關於創建一通道以用於與另一實體通訊；自該通道服務獲得對一或多個功能之存取，該一或多個功能實現給定用戶端與另一實體之間的直接通訊，該一或多個功能包括：用於傳輸資料之與一通道相關之通道功能或程序；及/或與使用一通道傳輸該資料相關之訊息功能或程序；自該通道服務獲得一或多個存取符記，該等存取符記實現與該另一實體之安全通訊；使將與一數位資產相關聯的一交易提交至該區塊鏈之一請求發送至實施一支付服務之一支付處理器；自該支付處理器獲得用於對應於經提交交易之一區塊鏈交易之一交易識別符(TxID)；基於來自該支付處理器之一回應來識別與對應的區塊鏈交易相關聯的一挖掘者；使用自該通道處理器接收之一或多個通道功能，創建一給定通道以用於與經識別挖掘者進行通訊；將與該給定通道相關聯的該一或多個存取符記發送至該挖掘者；接收與該給定通道相關聯的至少一個回叫通知，該通知與該給定通道中與區塊鏈交易相關聯的資料相關，該資料由該挖掘者提供。

21. 如條項20之方法，其中當該用戶端離線或不以通訊方式連接至該通道處理器時，該等回叫通知經獲得作為用於在該給定通道中列隊之資料或訊息的推送通知。

22. 如條項20或21之方法，其中當該用戶端在線上或以通訊方式連接至該通道處理器時，與該等回叫通知相關聯的該資料自該給定通道提取。

23 . 如條項20至22中任一項之方法，其中該一或多個功能為用於該給定用戶端之應用程式設計介面(API)，該等API包括用於實現創建及/或管理一或多個通道之通道API；以及用於使得該給定用戶端及一或多個其他實體能夠交換訊息及/或自該給定通道讀取資料及/或將資料寫入至該給定通道之訊息API；且其中該等存取符記為特定針對於一給定通道或一給定訊息之API符記。

24 . 如條項20至23中任一項之方法，其中該通道請求為至該通道處理器之一超文件安全傳送協定(HTTPS)傳輸GET請求，且其中至該支付處理器之該請求為至該支付處理器之一超文件安全傳送協定(HTTPS)傳輸POST請求。

25. 如條項20至24中任一項之方法，其進一步包含以下步驟：提供一用戶端端點；提供與該用戶端相關聯的至少一個用戶端定址密鑰；獲得一挖掘者端點；獲得與該挖掘者相關聯的至少一個挖掘者定址密鑰；基於該用戶端定址密鑰及該挖掘者定址密鑰使用該給定通道交換一或多個交握訊息；基於一交握結果或模式，獲得一共用秘密密鑰；其中使用該給定通道之任何通訊係基於該共用秘密密鑰而加密。

26. 如條項25之方法，其中該用戶端端點為一超文件傳送協定(HTTP)應用程式設計介面(API)端點，且其中該用戶端端點使用一安全HTTP (HTTPS)遞送。

27. 如條項25之方法，其中該用戶端端點為包括於來自該給定用戶端之使用該給定通道發送之一訊息中的一通用資源位置(URL)。

28. 如條項25至27中任一項之方法，其中該用戶端端點為與該用戶端相關聯的一別名，該別名係特定針對於該用戶端並且由一基於別名之定址服務提供，該定址服務具有可自一經界定或眾所周知的位置存取之一機器可讀資源，該機器可讀資源包括與該用戶端相關之一或多個能力，且其中該別名係與用於認證之一不對稱密碼密鑰對相關聯。

29. 一種用於處理與一區塊鏈相關聯的交易之電腦實施之方法，該方法由與多個挖掘者當中的一挖掘者相關聯的一或多個處理器實施，該多個挖掘者以通訊方式耦接至為一給定用戶端實施一支付服務之至少一個支付處理器，該方法包含以下步驟：自該支付處理器接收對將一交易提交至該區塊鏈之一請求；產生對應於該請求之一區塊鏈交易；將與該區塊鏈交易相關聯的一輸出指令碼(UTXO)發送至該支付處理器，其中該輸出指令碼包括與對應的區塊鏈交易相關聯的一交易識別符(TxID)；接收對一通道之存取，該通道實現與該給定用戶端直接通訊；基於與該通道相關聯的一存取符記，獲得一訊息功能或一訊息API以用於在該通道中提供或寫入與一回叫通知相關聯的資料，該資料與該對應的區塊鏈交易相關。

30. 如條項29之方法，其中基於該對應的區塊鏈交易為由該用戶端提交之一前一個交易之一雙重花費的一判定；該方法進一步包括提供一返回有效負載之步驟，該返回有效負載包括以下資料： -作為一雙重花費之給定區塊鏈交易的一交易識別符(TxID)；以及任擇地 -提交該給定區塊鏈交易之該支付處理器的一服務端點。

31. 如條項29之方法，其中回應於挖掘一區塊中之該對應的區塊鏈交易，方法進一步包括提供一返回默克爾證明之步驟，該返回默克爾證明確認在一區塊中包括該交易，該返回默克爾證明包括以下資料： -與該默克爾證明有關之一區塊鏈交易的一交易識別符(TxID)； -該區塊之區塊標頭；以及 -用於該交易識別符之同層級散列之一陣列。

32. 如條項29至31中任一項之方法，其進一步包含以下步驟：獲得一用戶端端點；獲得與該用戶端相關聯的至少一個用戶端定址密鑰；提供一挖掘者端點；提供與支付處理器相關聯的至少一個挖掘者定址密鑰；基於該用戶端定址密鑰及該挖掘者定址密鑰使用該通道交換一或多個交握訊息；基於一交握結果或模式，獲得一共用秘密密鑰；其中使用該通道之任何通訊係基於該共用秘密密鑰而加密。

33. 一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令使得該裝置執行如條項1至8中任一項之電腦實施之方法，該計算裝置與一支付處理器相關。

34. 一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令使得該裝置執行如條項9至19中任一項之電腦實施之方法，該計算裝置與一通道處理器相關。

35. 一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令使得該裝置執行如條項20至28中任一項之電腦實施之方法，該計算裝置與一用戶端相關。

36. 一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令使得該裝置執行如條項29至32中任一項之電腦實施之方法，該計算裝置與一挖掘者相關。

37. 一種電腦系統，其包含：一支付處理器，其經由一無線通訊網路以通訊方式耦接至至少一個用戶端及至少一個挖掘者，其中該支付處理器根據如條項33之計算裝置來實施；一用戶端，其經由該無線通訊網路以通訊方式耦接至該支付處理器並且能夠與至少一個客戶通訊；該用戶端根據如條項35之計算裝置來實施；該用戶端經由該無線通訊網路以通訊方式耦接至一通道處理器，其中該通道處理器根據如條項34之計算裝置來實施；以及多個挖掘者，其經由該無線通訊網路以通訊方式耦接至該支付處理器，各挖掘者根據如條項38之計算裝置來實施。

38. 一種電腦可讀儲存媒體，其上儲存有可執行指令，作為由一電腦之一處理器執行之一結果，該等可執行指令使得該電腦執行如條項1至32中任一項之方法。

應注意，上文所提及之態樣及實施例說明而非限制本揭露內容，且熟習此項技術者將能夠設計許多替代性實施例而不偏離本揭露內容之如由所附申請專利範圍界定的範疇。在申請專利範圍中，置放於圓括號中的任何參考符號不應被認為限制申請專利範圍。詞語「包含」及其類似者並不排除除任何請求項或說明書中作為整體列出之彼等元件或步驟外的元件或步驟之存在。在本說明書中，「包含」意謂「包括或由……組成」。元件之單數參考並不排除此類元件之複數參考，且反之亦然。本揭露內容可藉助於包含若干獨特元件之硬體且藉助於經合適程式化之電腦實施。在枚舉若干構件之裝置技術方案中，此等構件中之若干者可由硬體之同一項目體現。某些措施敍述於相互不同的附屬項中之純粹事實並不指示此等措施之一組合不能有利地使用。

102,104,106,108,110,112,114,116,118,120,202,204,206,208,210,212,214,216,302,304,306,308,310,312,316,318,501,502,503,504,505,506,601,602,603,604,605,606,701,702,703,704,705,706,802,804,806,808,810,812,902,904,906,908,1002,1004,1006,1008,1010,1012,1014,1102,1104,1106,1110,1112,1116,1118,1120,1122:步驟 402:用戶端 404:支付處理器 406:API轉換器 408:防火牆 410:節點連接器 412,412-1,412-2,412-n:挖掘者 2600:計算裝置 2602:處理器 2604:匯流排子系統 2606:儲存子系統 2608:主記憶體 2610:持久性儲存器 2612:使用者介面輸入裝置 2614:使用者介面輸出裝置 2616:網路介面子系統 2618:動態隨機存取記憶體(DRAM) 2620:唯讀記憶體(ROM)

現將僅作為實例且參考附圖描述本揭露內容之態樣及實施例，在附圖中：圖1為根據第一態樣之描繪用於實施支付服務或支付介面以用於為一或多個用戶端實現與區塊鏈相關聯的數位資產交易之方法的流程圖，該方法由支付處理器實施。圖2為根據第二態樣之描繪用於請求處理區塊鏈交易之方法的流程圖，該區塊鏈交易與同用戶端相關聯之數位資產支付相關聯，其中該方法係由與用戶端相關聯的一或多個處理器實施。圖3為根據第三態樣之描繪處理與針對用戶端之數位資產支付相關聯的區塊鏈交易之方法的流程圖，其中該方法係由與挖掘者相關聯的一或多個處理器實施。圖4為說明證明實現用於用戶端之區塊鏈交易的支付服務或支付介面之系統的示意圖。圖5為描繪與對獲得與多個挖掘者相關聯的費用報價的第一請求相關聯之資料流的示意圖。圖6為描繪與對基於選定的費用報價提交交易之第二請求相關聯之資料流的示意圖。圖7為描繪與基於區塊鏈交易識別符之狀態查詢相關聯的資料流之示意圖。圖8為根據第四態樣之描繪實施用於交易之回叫機制的方法之流程圖，其中該方法係由與支付處理器相關聯的一或多個處理器實施。圖9為根據第四態樣之描繪實施用於一或多個用戶端之通道服務的方法之流程圖，其中該方法係由與通道處理器相關聯的一或多個處理器實施。圖10為根據第四態樣之描繪存取支付服務的方法之流程圖，其中該方法係由與用戶端相關聯的一或多個處理器實施。圖11為根據第四態樣之描繪處理與給定區塊鏈交易相關聯之訊息的方法之流程圖，其中該方法係由與挖掘者相關聯的一或多個處理器實施。圖12為說明其中可實施本揭露內容之各種態樣及實施例的計算環境之示意圖。

802,804,806,808,810,812:步驟

Claims

一種向用於與區塊鏈相關聯的交易之一或多個用戶端提供支付服務之電腦實施方法，該方法由一支付處理器實施並且包含以下步驟：自該一或多個用戶端當中的一給定用戶端接收一請求，該請求為將與一數位資產相關聯的一交易提交至該區塊鏈，該請求與用於實現該給定用戶端與用於該交易之另一實體之間的直接通訊之一回叫識別符相關聯；將與該請求相關聯的該交易提交至多個挖掘者當中的一給定挖掘者，以用於將該交易包括在該區塊鏈中；向該用戶端識別該給定挖掘者；將該回叫識別符提供至該挖掘者；回應於自該給定挖掘者接收與用於該請求之一對應的區塊鏈交易相關之一回應，該方法進一步包括：為該用戶端啟用或處理由該挖掘者提供之與該對應的區塊鏈交易相關之至少一個回叫通知，該回叫通知係基於與該請求相關聯的該回叫識別符。
如請求項1之方法，其中來自該挖掘者之經接收回應係與一交易識別符相關聯，該方法進一步包括將用於該對應的區塊鏈交易之一交易識別符發送至該用戶端。
如任一前述請求項之方法，其中該經接收回應為與該區塊鏈交易相關聯的一輸出指令碼，該輸出指令碼包括與用於該挖掘者之一記憶體池(mempool)相關聯的一未使用交易輸出(UTXO)，該UTXO包括用於該區塊鏈交易之該交易識別符。
如任一前述請求項之方法，其中該支付處理器經實施為用於該一或多個用戶端之一表示狀態傳送(REST)端點，且其中該方法進一步包含提供與該支付處理器相關聯的一應用程式設計介面(API)閘道器之步驟以用於執行以下步驟：使用一超文件安全傳送協定(HTTPS)傳輸協定格式自該用戶端接收該請求；將各別請求轉換為一遠端程序呼叫(RPC)格式，且將該RPC提交至該挖掘者；以一RPC格式自該挖掘者接收與一對應的區塊鏈交易相關聯的一回應；以及轉換各別回應以用於使用該HTTPS傳輸協定發送至該用戶端。
如任一前述請求項之方法，其包含驗證該給定挖掘者之身份的步驟，其中該驗證係基於與該給定挖掘者相關聯的一數位簽名，或基於與該給定挖掘者相關之一識別符，該識別符可選地係與用於該給定挖掘者之一信譽指示符相關聯。
如任一前述請求項之方法，其中該回叫通知係關於由該給定用戶端提交之該交易之一雙重花費的一通知，或其中該回叫通知係關於由該給定用戶端提交之該交易包括在該區塊鏈中的一證明。
如任一前述請求項之方法，其中該回叫識別符為與該用戶端相關聯的用於一通道之一位置，或其中該回叫識別符為用於該用戶端之一通用資源識別符(URI)。
如任一前述請求項之方法，其進一步包含向該給定挖掘者提供對該通道之存取之步驟，其中該提供步驟包括將與該請求相關聯的用於該通道之一通道識別符或位置及與該通道相關聯的一或多個存取符記提供至該挖掘者。
一種用於為一或多個用戶端實施通道服務之電腦實施方法，該方法由一通道處理器實施並且包含以下步驟：自該一或多個用戶端當中的一給定用戶端接收一請求，該請求與創建一通道相關；向該給定用戶端提供對一或多個功能之存取，該一或多個功能經由該通道實現該給定用戶端與另一實體之間的直接通訊，其中該一或多個功能包括：用於傳輸資料之與該通道相關之通道功能或程序；及/或與使用該通道傳輸之該資料相關之訊息功能或程序；發出用於該通道之一或多個存取符記，該一或多個存取符記經組配以用於經由該通道與另一實體進行安全通訊；以及為該給定用戶端儲存及/或提供與該通道相關聯的一或多個通知。
如請求項9之方法，其中該一或多個功能為向該給定用戶端發出或經提供至該給定用戶端之應用程式設計介面(API)，該等API包括用於該通道之通道API及用於與該通道相關聯的資料之訊息API；且其中該等存取符記為特定於該通道或一給定訊息之API符記。
如請求項9或10之方法，其中提供對一或多個功能之存取之步驟包括提供一JavaScript物件表示法(JSON)經由超文件傳送協定(HTTP)之API，以實現創建及/或管理一或多個通道。
如請求項9至11中任一項之方法，其中與該等通道相關聯的該一或多個通知為來自一挖掘者之回叫通知，該挖掘者為經由該通道與該給定用戶端直接通訊之另一實體。
如請求項12之方法，其中該回叫通知係關於由該給定用戶端提交之一交易之一雙重花費的一通知。
如請求項13之方法，其中該回叫通知係與該通道中之一返回有效負載相關聯，該返回有效負載由該挖掘者提供，該返回有效負載包括以下資料：作為一雙重花費之區塊鏈交易的交易識別符；以及任擇地提交該區塊鏈交易之支付處理器的一服務端點。
如請求項12之方法，其中該回叫通知係關於由該給定用戶端提交之一交易包括在該區塊鏈中的一證明。
如請求項15之方法，其中該回叫通知係與該通道中之一返回默克爾證明相關聯，該返回默克爾證明由該挖掘者提供，該返回默克爾證明包括以下資料：與該默克爾證明有關之一區塊鏈交易的一交易識別符；其中包括該區塊鏈交易之區塊的一區塊標頭；以及用於該交易識別符之同層級散列的一陣列。
如請求項9至16中任一項之方法，當該用戶端離線或不通訊地連接至該通道處理器時，該一或多個回叫通知為用於在該通道中針對該給定用戶端儲存或列隊之資料的推送通知。
如請求項9至17中任一項之方法，當該用戶端在線上或通訊地連接至該通道處理器時，與該一或多個回叫通知相關聯的該資料係自該通道提供或提取。
如請求項9至18中任一項之方法，其中該通道處理器為或包括一支付處理器，且其中該方法包括由該支付處理器實施之如請求項1至8中任一項之方法。
一種用於處理與區塊鏈相關聯的交易之電腦實施方法，該方法由與一用戶端相關聯的一或多個處理器實施並且包含以下步驟：發送與一通道服務相關之一通道請求，該通道服務由一通道處理器實施，該請求係關於創建一通道以用於與另一實體通訊；自該通道服務獲得對一或多個功能之存取，該一或多個功能實現給定用戶端與另一實體之間的直接通訊，該一或多個功能包括：用於傳輸資料之與一通道相關之通道功能或程序；及/或與使用一通道傳輸之該資料相關之訊息功能或程序；自該通道服務獲得一或多個存取符記，該等存取符記實現與該另一實體之安全通訊；使將與一數位資產相關聯的一交易提交至該區塊鏈之一請求發送至實施一支付服務之一支付處理器；自該支付處理器獲得用於對應於經提交交易之一區塊鏈交易之一交易識別符；基於來自該支付處理器之一回應來識別與對應的區塊鏈交易相關聯的一挖掘者；使用自該通道處理器接收之一或多個通道功能，創建一給定通道以用於與經識別挖掘者進行通訊；將與該給定通道相關聯的該一或多個存取符記發送至該挖掘者；接收與該給定通道相關聯的至少一個回叫通知，該通知與該給定通道中與區塊鏈交易相關聯的資料相關，該資料由該挖掘者提供。
如請求項20之方法，其中當該用戶端離線或不通訊地連接至該通道處理器時，該等回叫通知經獲得作為用於在該給定通道中列隊之資料或訊息的推送通知。
如請求項20或21之方法，其中當該用戶端在線上或通訊地連接至該通道處理器時，與該等回叫通知相關聯的該資料係自該給定通道提取。
如請求項20至22中任一項之方法，其中該一或多個功能為用於該給定用戶端之應用程式設計介面(API)，該等API包括用於實現創建及/或管理一或多個通道之通道API；以及用於使得該給定用戶端及一或多個其他實體能夠交換訊息及/或自該給定通道讀取資料及/或將資料寫入至該給定通道之訊息API；且其中該等存取符記為特定於一給定通道或一給定訊息之API符記。
如請求項20至23中任一項之方法，其中該通道請求為至該通道處理器之一超文件安全傳送協定(HTTPS)傳輸GET請求，且其中至該支付處理器之該請求為至該支付處理器之一安全超文件傳送協定(HTTPS)傳輸POST請求。
如請求項20至24中任一項之方法，其進一步包含以下步驟：提供一用戶端端點；提供與該用戶端相關聯的至少一個用戶端定址密鑰；獲得一挖掘者端點；獲得與該挖掘者相關聯的至少一個挖掘者定址密鑰；基於該用戶端定址密鑰及該挖掘者定址密鑰使用該給定通道交換一或多個交握訊息；基於一交握結果或模式，獲得一共用秘密密鑰；其中使用該給定通道之任何通訊係基於該共用秘密密鑰加密。
如請求項25之方法，其中該用戶端端點為一超文件傳送協定(HTTP)應用程式設計介面(API)端點，且其中該用戶端端點使用一安全HTTP (HTTPS)遞送。
如請求項25之方法，其中該用戶端端點為包括於來自該給定用戶端之使用該給定通道發送之一訊息中的一通用資源位置(URL)。
如請求項25至27中任一項之方法，其中該用戶端端點為與該用戶端相關聯的一別名，該別名係特定於該用戶端並且由一基於別名之定址服務提供，該定址服務具有可自一經界定或眾所周知的位置存取之一機器可讀資源，該機器可讀資源包括與該用戶端相關之一或多個能力，且其中該別名係與用於認證之一不對稱密碼密鑰對相關聯。
一種用於處理與區塊鏈相關聯的交易之電腦實施方法，該方法由與多個挖掘者當中的一挖掘者相關聯的一或多個處理器實施，該多個挖掘者通訊地耦接至為一給定用戶端實施一支付服務之至少一個支付處理器，該方法包含以下步驟：自該支付處理器接收對將一交易提交至該區塊鏈之一請求；產生對應於該請求之一區塊鏈交易；將與該區塊鏈交易相關聯的一輸出指令碼(UTXO)發送至該支付處理器，其中該輸出指令碼包括與對應的區塊鏈交易相關聯的一交易識別符；接收對一通道之存取，該通道實現與該給定用戶端直接通訊；基於與該通道相關聯的一存取符記，獲得一訊息功能或一訊息API以用於在該通道中提供或寫入與一回叫通知相關聯的資料，該資料與該對應的區塊鏈交易相關。
如請求項29之方法，其中基於該對應的區塊鏈交易為由該用戶端提交之一先前交易之一雙重花費的一判定；該方法進一步包括提供一返回有效負載之步驟，該返回有效負載包括以下資料：作為一雙重花費之給定區塊鏈交易的一交易識別符；以及任擇地提交該給定區塊鏈交易之該支付處理器的一服務端點。
如請求項29之方法，其中回應於挖掘一區塊中之該對應的區塊鏈交易，方法進一步包括提供一返回默克爾證明之步驟，該返回默克爾證明確認在一區塊中包括該交易，該返回默克爾證明包括以下資料：與該默克爾證明有關之一區塊鏈交易的一交易識別符；該區塊之區塊標頭；以及用於該交易識別符之同層級散列之一陣列。
如請求項29至31中任一項之方法，其進一步包含以下步驟：獲得一用戶端端點；獲得與該用戶端相關聯的至少一個用戶端定址密鑰；提供一挖掘者端點；提供與支付處理器相關聯的至少一個挖掘者定址密鑰；基於該用戶端定址密鑰及該挖掘者定址密鑰使用該通道交換一或多個交握訊息；基於一交握結果或模式，獲得一共用秘密密鑰；其中使用該通道之任何通訊係基於該共用秘密密鑰加密。
一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令使得該裝置執行如請求項1至8中任一項之電腦實施方法，該計算裝置與一支付處理器相關。
一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令使得該裝置執行如請求項9至19中任一項之電腦實施方法，該計算裝置與一通道處理器相關。
一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令使得該裝置執行如請求項20至28中任一項之電腦實施方法，該計算裝置與一用戶端相關。
一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令使得該裝置執行如請求項29至32中任一項之電腦實施方法，該計算裝置與一挖掘者相關。
一種電腦系統，其包含：一支付處理器，其經由一無線通訊網路通訊地耦接至至少一個用戶端及至少一個挖掘者，其中該支付處理器根據如請求項33之計算裝置來實施；一用戶端，其經由該無線通訊網路通訊地耦接至該支付處理器並且能夠與至少一個客戶通訊；該用戶端根據如請求項35之計算裝置來實施；該用戶端經由該無線通訊網路通訊地耦接至一通道處理器，其中該通道處理器根據如請求項34之計算裝置來實施；以及多個挖掘者，其經由該無線通訊網路通訊地耦接至該支付處理器，各挖掘者根據如請求項38之計算裝置來實施。
一種電腦可讀儲存媒體，其上儲存有可執行指令，作為由一電腦之一處理器執行之一結果，該等可執行指令使得該電腦執行如請求項1至32中任一項之方法。