Computer-implemented system and method

Abstract

In a first aspect, the present disclosure proposes methods, apparatuses and systems for implementing a payment service to enable transactions associated with a client to be written or stored in a distributed ledger (i.e., a blockchain). The payment service is implemented as an API that one or more clients can access to process digital asset payments related to the respective client. In the first aspect, includes obtaining mining fee quotes for a client from a plurality of network nodes, and processing a request to submit a transaction to a blockchain based on a selected fee quote. In a second aspect, the present disclosure proposes methods, apparatuses and systems for requesting a transaction associated with a digital asset payment between a client (a payor) and a client's customer (a payee) to be mined in a blockchain based on the digital asset payment. The request is associated with a selected fee quote and / or a service level associated with the selected fee quote from the fee quotes received in the above aspect. In a third aspect, the method includes creating, processing and mining a blockchain transaction associated with a client by a network node based on the network node satisfying a selected fee quote from the client (as described in the above aspect).

Description

Technical Field

[0001] This disclosure generally relates to methods and systems for implementing payment services or payment interfaces for one or more clients. In particular, but not limited to, this disclosure relates to implementing secure and reliable payment transactions associated with a blockchain or distributed ledger for one or more clients, or on behalf of one or more clients, relating to digital asset payments associated with a customer or payer entity. Background Technology

[0002] In this document, we use the term "blockchain" to encompass all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, public and private blockchains, and their variants. It should be noted that alternative blockchain implementations and protocols associated with any type of digital asset or representation of a digital asset fall within the scope of this disclosure. The terms "client," "entity," "node," "user," "sender," "receiver," "payer," and "payee" may refer herein to computing or processor-based resources. The term "digital asset" may refer to any transferable asset, such as cryptocurrency, smart contracts, licenses (i.e., software licenses), or DRM contracts for media content. It should be understood that throughout this document, the term digital asset is used to refer to goods that may be associated with value that can be transferred in transactions from one entity to another or provided as payment.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system composed of blocks, which in turn are transactions. Each transaction is a data structure that encodes the transfer of control of digital assets among participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, and blocks are chained together to create a permanent, immutable record of all transactions written into the blockchain from the very beginning. Transactions contain applets called scripts embedded in their inputs and outputs, specifying how and by whom the transaction's outputs can be accessed.

[0004] For a transaction to be written to the blockchain, it must be "verified." Network nodes perform the work of ensuring each transaction is valid, while invalid transactions are rejected by the network. Software clients installed on nodes perform this verification work on unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid, and it is then written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must: i) be verified by the first node receiving the transaction – if the transaction is verified, that node relays it to other nodes in the network; ii) be added to a new block built by the network nodes; and iii) be mined, which adds the transaction to the public ledger of past transactions.

[0005] Once stored as a UTXO on the blockchain, a user can transfer control of the associated resources to another address associated with an input in another transaction. This transfer is typically accomplished using a digital wallet, but it is not mandatory. The digital wallet can be a device on a computing device such as a desktop, laptop, or mobile terminal; physical media; a program; an application (app); or a remote hosting service associated with a domain on a network (e.g., the internet). The digital wallet stores public and private keys and can be used to track ownership of resources and assets associated with the user, and to receive or spend digital assets.

[0006] While blockchain technology is best known for its implementation in cryptocurrencies, digital entrepreneurs are exploring the use of cryptographically secure systems and data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes beyond the realm of cryptocurrencies. Such solutions would be able to leverage the benefits of blockchain (e.g., permanent, tamper-proof event logging, distributed processing, etc.) while being more versatile in their applications.

[0007] One area of ​​current research is using blockchain to implement "smart contracts." These are computer programs designed to automatically execute machine-readable contracts or agreement terms. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs that contain rules that can process input to produce results, and then perform actions based on those results.

[0008] The examples or scenarios described above involve the transfer of certain assets (i.e., digital assets) or the control of digital assets between users or entities. Therefore, there is a need for a secure and robust system, similar to existing payment or e-commerce systems used for the exchange of funds between two entities (especially for digital asset payments between merchants and customers), that respects real-world assets, offers a better user experience, lower costs for merchants or payees, and a higher level of security. More specifically, there is a desire to leverage the advantages of distributed ledger (blockchain) technology and its enhanced security, transparency, and reliability of records to provide a universal platform or interface that enables any merchant or multiple merchants to ensure that digital asset payments to their corresponding customers are instantly and securely mined or written into the blockchain, thus providing a persistent, tamper-proof, and auditable record of such payments. Summary of the Invention

[0009] An improved solution has now been devised. This disclosure addresses these technical problems by proposing techniques that allow transactions for one or more clients (i.e., merchants or receiving entities) who are recipients of digital assets (e.g., cryptocurrencies) to be instantaneously written into the blockchain via methods, techniques, and devices that provide such clients with application programming interfaces (APIs). In this technology, network nodes will be able to dynamically or instantaneously mine or write transactions into the blockchain, i.e., providing clients with a secure and reliable service that allows for instant transactions or zero-confirmation transactions (0-conf).

[0010] In a first aspect, this disclosure proposes methods, apparatus, and systems for implementing payment services, enabling transactions associated with a client to be written to or stored in a distributed ledger (i.e., a blockchain). The payment service is implemented as an API that one or more clients can access to process digital asset payments related to their respective clients. In this first aspect, the method includes obtaining mining fee quotes for the client from multiple network nodes and processing a request to submit a transaction to the blockchain based on the selected fee quote.

[0011] In a second aspect, this disclosure proposes a method, apparatus, and system for requesting a transaction associated with a digital asset payment based on a digital asset payment between a client (payer) and the client's customer (payee), wherein the transaction will be mined in a blockchain. The request is associated with a fee quote selected from the fee quotes received in the foregoing aspects.

[0012] In the third aspect, the method includes the creation, processing, and mining of blockchain transactions associated with clients by network nodes based on network nodes meeting selected fee quotes from clients (as described above).

[0013] Throughout this specification, the word “comprise” or variations such as “includes”, “comprises”, or “comprising” will be understood to imply inclusion of the said element, integer, or step, or group of elements, integers, or steps, but does not exclude any other element, integer, or step, or group of elements, integers, or steps. Attached Figure Description

[0014] Various aspects and embodiments of this disclosure will now be described by way of example only and with reference to the accompanying drawings, in which:

[0015] Figure 1 It is a flowchart depicting a method for implementing a payment service or payment interface for enabling digital asset transactions associated with a blockchain for one or more clients, the method being implemented by a payment processor according to the first aspect.

[0016] Figure 2 It is a flowchart depicting a method for processing a request for a blockchain transaction associated with a digital asset payment associated with a client, wherein the method is implemented by one or more processors associated with the client according to a second aspect.

[0017] Figure 3 It is a flowchart depicting a method for processing blockchain transactions associated with digital asset payments to clients, wherein the method is implemented by one or more processors associated with network nodes according to a third aspect.

[0018] Figure 4 This is a schematic diagram illustrating a system for certifying a payment service or payment interface used to enable blockchain transactions for clients.

[0019] Figure 5 This is a schematic diagram depicting the data flow associated with a first request, which is used to obtain a cost quote associated with multiple network nodes.

[0020] Figure 6 This is a schematic diagram depicting the data flow associated with a second request used to submit a transaction based on a selected fee quote.

[0021] Figure 7 It is a schematic diagram depicting the data flow associated with state queries based on blockchain transaction identifiers.

[0022] Figure 8 This is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure can be implemented. Detailed Implementation

[0023] According to a first aspect, this disclosure provides a computer-implemented method for providing payment services to one or more clients for transactions associated with a blockchain, the method being implemented by a payment processor associated with the payment service. In some embodiments, the client may be a computing resource or node, or an entity that may be associated with a digital wallet for accepting and / or processing cryptocurrency payments and may be associated with the public key or public address of such wallet. In some embodiments, the client may represent a merchant entity or terminal (e.g., a point-of-sale device) that provides goods or services in the real world and receives digital asset payments for such goods or services, but is not limited thereto. In some embodiments, the payment processor is configured to provide a payment interface for one or more clients as an associated service or third-party service. In some examples, the payment processor is referred to as a payment aggregator because it provides multiple payment services and functionalities associated with the blockchain to clients and network nodes via one or more user-friendly interfaces. In some embodiments, the payment processor is implemented as an application programming interface (API) for providing web-based interaction (i.e., implemented as a web service) to one or more clients, enabling communication over the Internet using standard Internet communication protocols for web-based services (e.g., HTTPS, TCP / IP, etc.). The API is known or available for use by one or more clients associated with the payment processor, or sent / provided to such one or more clients. In some embodiments, the API may be provided to clients during a registration or sign-up process to access services or features offered by the payment processor. In some examples, the API may be provided or published for client use via an API user interface (e.g., Swagger), which is a well-known API design and development tool or interface for clients or other entities wishing to access web-based services.

[0024] The first aspect of the method includes the step of obtaining a fee quote from each of a plurality of network nodes used for mining transactions. This step occurs in response to a first request from a client for a mining fee quote associated with a mining transaction. In some embodiments, the first request from the client may be a fee quote for mining a single transaction or a fee quote for mining multiple transactions(s). In some embodiments, if multiple transactions exist, a payment processor may be associated with a separate API or endpoint for receiving, disposing of, or processing requests associated with two or more transactions(s). Such an endpoint may also handle a single or individual transaction. In other embodiments, the same endpoint (i.e., the API associated with the payment processor mentioned above) is used for both single and multiple transactions. Therefore, the fee quote obtained from one or more network nodes may be: (i) a fee quote from each network node for a single transaction, (ii) multiple separate fee quotes from each network node, one fee quote for each of the multiple transactions, (iii) a single fee quote applicable to each of the multiple transactions, or (iv) a single aggregate fee quote covering the mining fees for all the multiple transactions requested by the client in the first request. In some embodiments, the network node is a node implemented by one or more processors, which are delegated to verify locking and unlocking scripts, and to mine transactions or write transactions to the blockchain, as explained in the background section above. The first aspect of the method includes the step of providing a obtained fee quote to a client. In some embodiments, the fee quote is related to a current fee levied or collected by the network node for mining a transaction into the blockchain, regardless of what the transaction involves or the parties involved. In other embodiments, the fee quote can be customized based on a given transaction, which may be identified in a request. In some embodiments, the payment processor may provide the client with all received fee quotes, or may provide one or more recommended fee quotes from the obtained fee quotes to the client.

[0025] Advantageously, by implementing a payment service as an API provided to one or more clients (i.e., merchants or receiving entities) who act as recipients of digital assets such as cryptocurrencies, the first aspect of the approach allows payment transactions to be mined (written into the blockchain) almost immediately, or as soon as possible, after network nodes solve the proof-of-work puzzle, by allowing clients to register or use the network services provided by the payment processor. By providing a current fee offer, a given network node theoretically agrees or commits to adding the transaction to the next block to be mined by that given network node at that fee. Advantageously, this means that the client (i.e., the merchant entity) no longer has to wait for any confirmation from the network node. Thus, zero-confirmation (0-conf) transactions associated with the client and the corresponding network node can be advantageously implemented. The identity of the client using the payment service API can be advantageously kept anonymous, while all transactions associated with the client can still be reliably mined by network nodes among multiple network nodes that meet or conform to a selected or chosen mining fee offer. Thus, a single client or merchant can take advantage of the transparency, reliability, and benefits of the immutable and verifiable record of all payments associated with the corresponding client, without implementing any additional processing or network resources, simply by utilizing the proposed payment service API.

[0026] In some embodiments of the first aspect, in response to a second request from a client to submit a given transaction relating to or including a selected fee quote from a list of obtained fee quotes, the method includes sending a request to one or more network nodes among a plurality of network nodes to generate a blockchain transaction for the given transaction. In some embodiments, as described above, the request from the client may be to submit multiple transactions rather than a single transaction. This is advantageous where the client may be a merchant entity processing or disposing of a large number of transactions within any given time period, wherein the time period can be dynamically defined or scheduled as minutes, hours, or days. This advantageously allows for seamless scalability of the blockchain network associated with client workload / performance requirements and can be based on the number of transactions and / or clients disposed of by the client. In some embodiments, if multiple transactions exist, the payment processor may be associated with a separate endpoint for submitting multiple transactions. In other embodiments, the same API endpoint of the payment processor is used for requests from the client to submit both single and multiple transactions.

[0027] In some embodiments, the selected fee quote is received from the client and chosen for a given transaction, which may in turn be associated with a payment request or payment transaction between the client and another node or entity (e.g., the client's customer who is considering purchasing goods or services from the client that require payment in digital assets). The method then includes receiving an output script (e.g., a UTXO) associated with the blockchain transaction from at least one network node among a plurality of network nodes that satisfies the selected fee quote. For example, in some embodiments, to satisfy the fee quote, at least one network node should already have a current fee quote or be associated with a current fee quote whose value is higher than or lower than the selected fee quote, and in some cases higher than the selected fee quote, depending on one or more rules or predetermined criteria associated with the client. The method then includes sending a result to the client, which includes a transaction identifier (TxID) of the blockchain transaction associated with the given transaction (i.e., a payment between the client and a customer).

[0028] Advantageously, the API disclosed herein can be implemented as a REST (Representational State Transfer) endpoint, allowing clients to communicate using standard internet or web-based protocols (e.g., HTTPS). Furthermore, advantageously, the payment service of the first aspect enables corresponding transactions associated with digital asset payments to be created and written to the blockchain instantly based on a selected fee quote. Based on the mining of transactions using a selected fee quote chosen by the client or a payment processor on behalf of the client, it advantageously enables at least one of multiple network nodes to mine transactions or write them to the blockchain almost instantly or as quickly as possible, with the guarantee that a given network node will mine the transaction with a current fee quote that matches or satisfies the selected fee quote from the client. Therefore, the payment service API has the advantage of allowing instant or zero-confirmation (0-conf) transactions to be mined in the blockchain for the client in a secure and reliable manner, without the client needing to wait for confirmation from the network node that the transaction has indeed been added to a block and will be mined in the blockchain. This is because the given network node has indicated that it can perform mining by sending a current fee quote for mining the transaction in response to a first request. The first approach reduces the risk of double-spending associated with allowing instant transaction mining because mining under this approach is based on a selected fee quote chosen by the client. Therefore, only network nodes that meet the selected fee quote can mine a transaction, and once the transaction is added to the block associated with the blockchain by the first network node that meets that fee quote, it cannot be mined by other network nodes.

[0029] According to some embodiments of a method for providing payment services according to a first aspect implemented by a payment processor, the method includes providing a transaction mining fee quote based on a determined recommended fee proposed to the client, wherein the determined fee may be the average of fee quotes obtained from multiple network nodes, or the maximum of fee quotes obtained from multiple network nodes. Advantageously, to avoid double-spending, the payment processor may recommend submitting the transaction with the highest fee value obtained from multiple network nodes in response to the first request. In this way, all network nodes can be provided with an equal opportunity to mine the transaction with their corresponding current quoted fees. However, if the recommended fee is a fee equal to or higher than the median or average of all received fee quotes, the network node with the higher quote can simply retain the transaction in a mempool (e.g., a secondary mempool) and use it to check and reject any double-spending of the transaction. Similar advantages apply if the selected fee quote is based on the recommended fee quote, or if the recommendation is part of a choice made by the client.

[0030] Advantageously, the fee quote recommended by the payment processor is then optional for the client to select. In some embodiments, this fee quote is the maximum value the client is willing to pay for a transaction associated with a payment to the digital asset. This is advantageous if the client is computationally uncomplicated, or if the client has predetermined that the fee quote is provided by the payment processor, rather than selecting it themselves. Therefore, advantageously, the client can select a fee quote based on the recommended fee quote, rather than applying new or separate exploration or computation to select a fee quote or arbitrarily selecting a fee quote.

[0031] In some embodiments, when a recommended or suggested fee quote is provided from a payment service (i.e., the API provided by the payment processor), the recommended fee quote can be provided, or all received fee quotes including the recommended fee quote can be provided, the recommended fee quote including an identifier. Advantageously, by providing both the recommended fee quote and all received fee quotes, the payment processor provides the client with the option to submit a transaction using the recommended fee quote or to select a different fee quote from the other received fee quotes.

[0032] In some embodiments, once a fee quote is obtained from a network node, the first aspect of the method includes classifying the obtained fee quote into a service level or service category by a payment processor. In some embodiments, this may be based on a fee quote obtained from each network node for a single transaction or a batch of transactions. For example, if the obtained fee quote is within a dynamically set or predetermined range, a specific service level is assigned to a given network node. In some embodiments, this service level may be based on a transaction fee (e.g., this may be a fee quoted by a network node) and a relay fee. The relay fee is the minimum cost required to get a given network node to consider verifying a transaction and subsequently relay it to peer nodes in the blockchain network. In some cases, these two fees may be the same. In most cases, the relay fee will be lower than the transaction fee quoted from a given network node. For some blockchains, the fee quoted by a network node is typically a set or default transaction fee that remains constant for any transaction. In some embodiments, the relay fee is known or / or may be common to multiple network nodes, i.e., a default relay fee. As mentioned above, in most cases, this relay fee is lower than the transaction fee. Sometimes, it may be the same as the transaction fee.

[0033] In some embodiments, a particular service level among multiple possible service levels assigned to a fee quote obtained from a network node may be based on the priority associated with one or more transactions(s) to be mined in the block. In some embodiments, a particular service level may also be based on the degree of double-spending protection provided by the network node to ensure that any malicious attempts to further spend funds / digital assets associated with the same transaction are rejected. Thus, a higher service level may indicate a higher-priority transaction that may need to be mined within a short period of time (e.g., less than a few minutes, i.e., within 15-20 minutes) and with better double-spending protection. A lower service level may be associated with a longer mining time (e.g., within 24-48 hours) and / or no double-spending protection provided for transactions not mined by a given network node. In some embodiments, transaction priority may be provided by the client, and then the service level is associated with that client for all transactions based on the client's request. In some embodiments, double-spending protection may be associated with a function that stores transactions not mined by a given network node in a secondary mempool, thereby enabling double-spending checks.

[0034] In some embodiments, the determination of the service level may be based on static values ​​and rules associated with configuration records or file entries associated with a payment processor. In this case, these values ​​for allocating the service level may be set at the payment processor. In other embodiments, new values ​​or rules may be added or configuration records may be modified to further define the characteristics associated with a given service level. This may supplement, or in some cases replace, one or more of the transaction priorities and double-spending protections associated with a given service level described above. The service level can then be compared with a fee quote obtained for allocating the service level.

[0035] In some embodiments, the transaction fees associated with a given service level can be dynamically allocated or pre-defined as fees recommended or selected by the payment processor for that service level by default. In some embodiments, the recommended or selected fees can then be sent to the client along with a service level indicator provided by a given network node. In some embodiments, the fees associated with each service level may already be known to or agreed upon with the client. For example, in some cases, a service level requested by the client and a selected fee associated with the client for the transaction can be pre-agreed. This can be based on an external service level agreement or can be set when the client registers to use the services or features provided by the payment processor. In some embodiments, the client can select a service level and fee for each transaction, or, in the case of a batch of multiple transactions, select a service level and fee for that batch of transactions.

[0036] In some embodiments, the service level pre-allocated, recommended, or selected by the payment processor may be based on one or more service requests received from the client as part of a first request. In some embodiments, the service level is provided or identified to network nodes along with the selected / recommended offer and the request for creating a blockchain transaction.

[0037] Advantageously, the classification of mining fees based on a limited set of service levels that can then be associated with the corresponding network nodes ensures transparency and standardization of the mining fee amounts applied to mining transactions, as well as transparency of the performance associated with a given network node used to mine transactions at a specified service level. This limited number of service level classifications ensures greater transparency and visibility of expected fees charged for services as the number of transactions to be published or submitted on the blockchain increases with the blockchain's potential application expansion, and ensures that network nodes provide the level of protection required to prevent double-spending. This is important for ensuring seamless scalability as the number of transactions handled by the payment processor associated with the blockchain, the network nodes, and the number of transactions per client / network node grows exponentially. Currently, using all existing network node fee mechanisms, it is neither guaranteed nor feasible to guarantee that the quoted fee rate will effectively provide 0-conf security.

[0038] In some embodiments, once the payment processor categorizes transactions based on default, limited, or known relay fees, this categorization can be used or applied to network nodes for future transactions. Furthermore, advantageously, this categorization can also encourage network nodes to offer better or more competitive fee quotes for mining transactions, so that they can be associated with different or better service levels suitable for a given client, while persisting in mining transactions that meet the fee quotes (i.e., the first transactions seen to be mined).

[0039] Furthermore, advantageously, service level classification allows clients and network nodes to differentiate transactions based on service levels. Currently, there is no mechanism to differentiate transactions and price different types of transactions for different clients at different prices. Moreover, advantageously, the classification performed by the payment processor based on service levels allows or enables such classification to be implemented without any modification to the network node configuration. This is because the proposed service level-related mechanism externalizes fee evaluation to the payment processor using the payment processor's API, rather than to the network node or verification mode, making it easy to implement, applicable to both clients and network nodes, and greatly contributing to the scalability of the blockchain.

[0040] In some embodiments, the method includes the step of verifying the identity of a given network node among a plurality of network nodes that provides a corresponding fee quote, wherein the identity verification is based on a digital signature associated with the given network node. An encrypted key pair including a private key and a public key (or public address) associated with each network node can be used to verify that the fee quote indeed originates from the given network node; that is, data signed with the private key can only be recovered or verified using the corresponding public key. If verification is based on digital signatures, standard Public Key Infrastructure (PKI) technology can be used and implemented.

[0041] In other embodiments, additionally or alternatively, an identifier associated with a given network node may be used to verify the identity of the network node. In some embodiments, the method includes a payment processor, such as a NetworkNode ID. In some embodiments, the identifier may be associated with a reputation metric of the given network node. A reputation metric relates to a measure of a network node's performance. For example, in some examples, the reputation may be based on how a given network node has historically executed or mined transactions at quoted fees. For example, if a network node regularly mines transactions at fees quoted by the network node or within acceptable limits of those fees, the reputation metric may, for example, indicate a good reputation with a higher value. In some embodiments, the network node's reputation score or metric may be calculated, maintained, and managed by at least one payment processor communicatively coupled to the network node.

[0042] In some embodiments, the method of the first aspect implemented by the payment processor may include a step of verifying a fee offer obtained from a given network node among a plurality of network nodes based on a network node signature, which is different from the digital signature used to verify the identity of the given network node using PKI technology. The network node signature used by the payment processor for the verification step advantageously indicates or serves as a commitment by the network node to mine transactions for the corresponding fee offer provided to the payment processor. The presence of the network node signature can also advantageously be used to confirm that the network node will reject any conflicting transactions. Therefore, the step of verification based on the network node signature advantageously serves as a guarantee that the given network node will include transactions in the block for mining and will not include any conflicting transactions. In some embodiments, monitoring the performance of a given network node based on this guarantee provided by the given network node can limit or influence the network node reputation or score associated with the given network node.

[0043] In some embodiments, a fee quote provided by each of a plurality of network nodes is provided to the payment processor as a data type including the value of the fee quote. In some embodiments, the data type is in JavaScript Object Notation (JSON) object format.

[0044] In some embodiments, the output script received at the payment processor from at least one network node is an unspent transaction output (UTXO) associated with the mempool of at least one network node, the UTXO including a transaction identifier (TxID) of a blockchain transaction, wherein the blockchain transaction relates to a digital asset payment between a client and a customer.

[0045] In some embodiments, to enable a client to advantageously identify or track blockchain transactions associated with or related to a given payment transaction of the client, the method includes the step of sending a request to a plurality of network nodes to obtain a corresponding blockchain transaction for a transaction identifier, the request being sent by a payment processor to at least one network node in response to a status query associated with the transaction identifier from the client. In response, the payment processor obtains the corresponding blockchain transaction previously generated from at least one of the plurality of network nodes. Based on the mining status of the blockchain transaction by at least one network node, the method includes the step of sending a status result to the client related to the obtained blockchain transaction associated with the transaction identifier. The result may indicate whether the blockchain transaction has been mined (i.e., completed), rejected for some reason, or invalidated because it may have been mined by another of the plurality of network nodes before that given network node. This advantageously avoids double-spending in the event that mining for a specific transaction is completed on different network nodes. In some embodiments, a network node may maintain transactions that have not yet been added to a block or mined in an auxiliary mempool, which may be or represent an alternative or additional mempool separate from the main mempool associated with the network node. The secondary memory pool can be a temporary memory pool so that TxIDs can be checked against double-spending. This advantageously ensures that even if a transaction is not mined by a given network node, it remains in the secondary memory pool and can be used in the future to check for and reject double-spending. There may be a time limit for retaining transactions that have not been mined or are intended to be mined by a given network node in its secondary memory pool. In some embodiments, transactions stored in the secondary memory pool may be associated with an expiration time after which they will be cleared. In some embodiments, there may be a separate fee associated with a network node storing transactions that a given network node has not mined in its corresponding secondary memory pool. As described above, where fee quotations are classified into service levels, the secondary memory pool is associated with the network node providing double-spending protection.

[0046] In some embodiments, as described above, a request from a client may be to query the status of multiple transactions in batches, rather than querying the status of a single transaction each time. This is similar to submitting multiple transactions to the blockchain for mining; querying multiple transactions together in a single status query request is advantageous, especially if the client is a merchant entity that processes or disposes of a large number of transactions and has submitted multiple transactions for a one-time processing. This advantageously allows the system to scale seamlessly to client requests and can be based on the number of transactions and / or customers handled by the client. In some embodiments, if multiple transactions exist, the payment processor may be associated with a separate endpoint for querying the multiple transactions. In other embodiments, the same endpoint of the payment processor is used for requests from clients to query both single and multiple transactions.

[0047] In some embodiments, the method of the first aspect further includes the step of providing an application programming interface (API) converter associated with the payment processor to perform the following steps: receiving a first request for a fee quote, a second request for submitting a transaction associated with a digital asset payment to a client, and / or a status query for the transaction from the client in Hypertext Transfer Protocol Secure (HTTPS) format; then converting these into Remote Procedure Call (RPC) format, and then sending the RPC to multiple network nodes. This is advantageous because it allows the client to communicate requests associated with the blockchain via a web-based API using HTTPS, and seamlessly provides interoperability with multiple network nodes that do not communicate using Internet Protocol communication standards used for network services. For example, all existing network nodes or implementations use Remote Procedure Call. The API converter implemented in this embodiment is not limited to HTTPS to RPC and RPC to HTTPS conversion, or other web-based protocols to alternative communication protocols supported by the individual network nodes, or may also be conceivable for a network of a given cryptocurrency or digital asset. In the reverse flow path, the first aspect of the method also includes receiving responses associated with the corresponding blockchain transaction from one or more network nodes in RPC format, and accordingly converting the responses for the client using HTTPS. Therefore, when the client (recipient) and network nodes use different wireless data communication protocols and mechanisms, the proposed interface, advantageously implemented by the payment processor, enables seamless communication to submit transactions to the blockchain.

[0048] In some embodiments, an API gateway associated with the payment processor may be provided. In such embodiments, the aforementioned API converter may be associated with the API gateway. Furthermore, in some embodiments, the API gateway may also be implemented in one or more computing devices to perform / be responsible for functions including, but not limited to, one or more of the following:

[0049] - Cache transactions

[0050] - Implement resilience functions in the event of network node failure.

[0051] - Record one or more endpoints or URLs that can be used to send or receive messages or notifications to / from payment processors and / or clients and / or network nodes.

[0052] - Provides resilience features, including tracking transactions that failed to submit for any reason. In some examples, this might include configurable parameters saved or set by the payment processor; and mechanisms to clear expired tracked transactions. The API gateway can also be associated with the ability to resubmit transactions in failure scenarios, thus providing error handling for genuine transactions and distinguishing between double-spending and rescinding.

[0053] According to a second aspect, this disclosure provides a method for processing transactions associated with a blockchain, implemented by one or more processors associated with a client, the client being communicatively coupled to at least one payment processor that provides payment services to the client. In some embodiments, the payment processor is configured to implement the method and associated embodiments of the first aspect described above. The method of the second aspect implemented by the client (i.e., the merchant) includes the step of sending a first request to the payment processor of the at least one payment processor, the request relating to one or more fee quotations to be obtained via the payment processor from a plurality of network nodes for mining transactions or multiple transactions. As described above, the obtained fee quotations are related to mining any transaction, or may be specific to a given transaction related to a digital asset payment from a client. As described above, the first request may also indicate the service level required for mining.

[0054] In some embodiments of the second aspect, in response to receiving one or more fee quotations from a payment processor, the method includes selecting a fee quotation from the one or more received fee quotations. As described in the first aspect, the selected fee quotation may or may not be based on a recommendation made by the payment processor. The method of the second aspect then includes requesting a digital asset payment from a customer and / or processing a digital asset payment from a customer, the request being associated with the selected fee quotation. In some embodiments, the request is similar to an invoice or payment request for digital asset payment issued by a client to a customer. For example, the client may be a coffee shop terminal associated with a digital wallet, and the customer may pay for coffee in response to the request, the customer also being associated with a digital wallet. Since the selected fee quotation is now selected, it can be added to the payment request from the customer. The method then includes submitting a second request to the payment processor for a given transaction associated with the aforementioned customer payment, the submission being based on the selected fee quotation used to mine the given transaction. In some embodiments, the selected fee quotation is explicitly indicated or included in the second request, enabling the payment processor to advantageously identify network nodes that can mine transactions at or below the selected fee quotation, or additionally or alternatively, network nodes can identify whether they meet the selected fee quotation.

[0055] As described above, in some embodiments, the client may select a fee quote based on the highest fee quote received from the payment processor, or based on the average or median of the fee quotes received. The advantage associated with either option is the same as discussed above: the maximum value allows all network nodes to mine, while other values ​​limit mining to some network nodes that meet the fee quote, as they are able to mine transactions at the selected quote or lower. Meanwhile, those network nodes that cannot mine transactions (e.g., due to the quote being too high) can still keep a record of the blockchain transaction in temporary storage (e.g., an auxiliary mempool), which can be used to verify any double-spending of a given transaction.

[0056] In some embodiments of the second aspect, the method further includes receiving a transaction identifier of a blockchain transaction already generated by at least one network node, the blockchain transaction corresponding to a submitted transaction (i.e., a transaction between a client and a customer). In some embodiments, the method includes sending a status query associated with the obtained transaction identifier; and obtaining a status result of the blockchain transaction corresponding to the transaction identifier.

[0057] The advantages associated with the second aspect are related to those discussed above regarding the first aspect. The second aspect supplements the first aspect but describes a method implemented by a client requesting that a transaction be written into the blockchain. In some embodiments, a client implementing the method of the second aspect may communicate with at least one payment processor configured to implement the payment service as a payment API according to the method of the first aspect.

[0058] Furthermore, the approach in this regard advantageously allows clients to select the fee quotes offered to the payment service, which provides clients or merchants with control or certainty over how transactions affecting them will be mined in a timely manner at a given mining fee, thereby providing greater security, interoperability, reliability, efficiency, and timeliness for transactions mined by clients using the proposed payment service or payment API.

[0059] As described above, in some embodiments, since the payment service implemented by the payment processor is an API, the first request and / or status query from the client is an HTTPS GET request, and the second request is an HTTPS POST request. Therefore, advantageously, the client can use standard internet and web-based communication protocols to request that transactions be mined into the blockchain. In some embodiments, the data associated with the first and / or second requests and / or the status query from the client are provided in JavaScript Object Notation (JSON) object format.

[0060] According to a third aspect, this disclosure provides a computer-implemented method for processing transactions associated with a blockchain, the method being implemented by one or more processors associated with network nodes among a plurality of network nodes, wherein the plurality of network nodes are communicatively coupled to at least one payment processor, the at least one payment processor implementing payment services for a client. In some embodiments, the payment service is implemented by the payment processor based on the method described above in connection with the first aspect. In some embodiments, the client is configured to implement the method associated with the second aspect as described above. The method of the third aspect implemented by network nodes among the plurality of network nodes includes the step of: providing a current fee quote in response to a first request for a fee quote for a transaction associated with the client, the current fee quote relating to a transaction mined in the blockchain by the network node. In some embodiments, the fee quote may be provided as a data type to the payment processor associated with the client. As described above, the first request may be associated with a request for a current fee quote for any transaction or multiple transactions, or may be specific to a particular transaction between the client and a customer.

[0061] In some embodiments of the third aspect, in response to a second request from a payment processor representing a client, the second request relating to submitting a given transaction in the blockchain based on a selected fee quote, wherein this portion can be completed by the client as described in the first and second aspects, the method includes the following steps: Based on determining that the selected fee quote associated with the given transaction satisfies the current fee quote of the network node, i.e., determining that the selected fee quote is equal to or within the current fee quote, the given network node then generates a corresponding blockchain transaction associated with the given transaction. The method further includes generating an output script (UTXO) for the created blockchain transaction, adding the generated output script to a memory pool associated with the network node, and sending the output script to the payment processor, wherein the output script includes a transaction identifier TxID associated with the corresponding blockchain transaction. In some embodiments, in response to a request for a state associated with the transaction identifier, the network node includes returning a result based on the current mining state of the corresponding blockchain transaction.

[0062] The advantages associated with the third aspect are related to those discussed above regarding the first and second aspects. The third aspect complements the first and second aspects, but depicts a method implemented by one of a plurality of network nodes coupled to a payment processor for constructing transactions for clients that can be written into a blockchain. In some embodiments, the network node implementing the method of the third aspect may communicate with at least one payment processor configured to implement the payment service as a payment API according to the method of the first aspect.

[0063] In some embodiments, the steps of providing a current fee quote, and / or sending an output script, and / or returning a result are implemented as Remote Procedure Calls (RPCs). This is advantageous if the network node is configured to correspond to wireless via RPC. In some embodiments, the method of the third aspect may include the steps of sending an RPC from the network node to a node connector and, optionally, a firewall of multiple network nodes, and then propagating it over a wireless communication network to the client's payment processor for additional security and streamlining of data flow between a pool of network nodes or a network (i.e., multiple network nodes associated with the payment processor). Furthermore, advantageously, the node connector may provide a secure communication channel between an API converter associated with the payment processor and one or more network nodes in the pool.

[0064] In some embodiments, based on the determination that a selected fee quote associated with a given transaction does not satisfy the network node's current fee quote—for example, if the current fee quote is higher than the selected fee quote—the method includes adding the output associated with the blockchain transaction to an auxiliary memory pool, which may be an additional temporary memory pool associated with the network node. As described above, this can be stored herein for a predetermined period of time so that the network node can use such temporary entries to check and advantageously ensure that there is no double-spending associated with the given transaction.

[0065] This disclosure also provides a computer system including a payment processor communicatively coupled to at least one client and at least one network node via a wireless communication network. The payment processor is associated with an API converter for converting HTTPS requests from the client into RPC requests for the network node, and vice versa, thereby the payment processor is implemented according to the first aspect. The computer system also includes a client communicatively coupled to the payment processor via the wireless communication network and capable of communicating with at least one client, thereby the client is implemented according to the computing device of the second aspect. The computer system further includes a plurality of network nodes, each communicatively coupled to the payment processor via the wireless communication network, thereby each network node is implemented according to the third aspect.

[0066] In some embodiments, a computing device is provided, the computing device including a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the computing device to perform the aspects and / or embodiments discussed above.

[0067] In some embodiments, a computer-readable storage medium having executable instructions stored thereon is provided, which, when executed by a processor of a computer system, cause the computer system to perform the methods of the aspects and / or embodiments discussed above.

[0068] Some specific embodiments will now be described by way of illustration with reference to the accompanying drawings, in which the same reference numerals refer to the same features.

[0069] First aspect—Payment processor

[0070] Figure 1The first aspect of this disclosure relates to and describes a method executed by a payment processor for implementing payment services for a client, as described above. The payment processor is communicatively coupled to one or more clients. In some embodiments, the payment processor may be part of or implemented in association with a client. This is the case if the client is a computationally complex point-of-sale (POS) terminal. It is envisioned that aspects and embodiments of this disclosure cover both implementations: a remote payment processor or a payment processor as part of a client. Figure 4 The example system architecture can be seen here, and it will be explained later in this article.

[0071] exist Figure 1 In the example scenario depicted, the embodiment involves the following steps: obtaining multiple mining cost quotes, submitting a transaction based on a selected cost quote from the multiple obtained mining cost quotes, and sending a status query associated with the transaction identifier. Figure 1 In the flowchart, all steps are described as occurring sequentially and as a single process. However, this disclosure and the first aspect should not be considered limited thereto. The steps described below relating to obtaining a fee quote in the first request (steps 102-106) can be implemented independently of the remaining steps. Similarly, the steps relating to submitting the transaction in the second request (steps 108-114) can be implemented independently and at a different time than the previous steps of obtaining the fee quote. Likewise, the steps relating to querying the transaction status starting from step 116 can be implemented at any time after the client already knows the transaction identifier and do not need to follow... Figure 1 The order in which the steps are presented is merely for ease of explanation and understanding, and in no way should this disclosure be considered limited to this order or scenario.

[0072] Step 102 describes receiving a first request from a client for a mining fee quote associated with a transaction in the mining blockchain. As previously mentioned, the first request may also be associated with multiple transactions. For ease of explanation and understanding, a single transformation in the first request associated with the client will be used as an example. Figure 1However, this disclosure is not limited thereto in any way. This step represents the collection of mining fee quotes representing client mining transactions from multiple network nodes. Transactions are typically related to digital asset payments between a client (i.e., a merchant's computing resources or entity) and the client entity. As described above, the first request is received via or using the HTTPS protocol and is received from the client in JSON format. The payment processor implements the payment interface as an application programming interface (API) for clients, so that HTTPS can be accepted and processed when the API is implemented as a web service. The API endpoint is available to the client. In the case of multiple transactions in the first request, the same API endpoint of the payment processor or separate API endpoints can be used.

[0073] For example, in some embodiments, the payment processor can use a standards-based interface design, such as a REST interface, to implement payment services. REST is an architectural pattern for developing web services and web-based interactions. The REST API design standard can handle HTTPS requests and communications using the following commands:

[0074]

[0075] This article will primarily discuss GET and POST HTTPS requests, but this application is not limited to these commands. In step 102, the first request received by the payment processor may be an HTTPS request of the form GET getFeeQuote.

[0076] In the context of a REST API, a resource is an object that has a type, associated data, relationships with other resources, and a set of methods for manipulating it. In some embodiments, a payment service is provided by a payment processor as an API implementation to access the state of a blockchain or distributed ledger via an application interface and trigger operations that can change that state, exposing it as a REST API. Therefore, a payment processor can be thought of as a REST endpoint for one or more clients. For ease of explanation only, one client (or merchant) and one payment processor will be discussed throughout, but this disclosure is not limited to this. Thus, the client can communicate with the payment service via HTTPS, and furthermore, the client can advantageously access the payment processor or the payment service implemented by the payment processor anonymously. In some embodiments, when there is more than one client and more than one payment processor, the client will be responsible for locating or contacting the correct or intended payment processor or REST endpoint based on, for example, any protocol that the client may have with one or more third parties running the payment processor.

[0077] Step 104 describes obtaining a fee quote for mining the transaction from each of the multiple network nodes. In this step, the payment processor may poll or contact all network nodes coupled to it and request them to return the current fee quote for mining the transaction, i.e., writing the transaction to the blockchain after verifying the locking and unlocking scripts. Currently, some blockchain networks support communication via Remote Procedure Call (RPC). Therefore, in this case, an API converter associated with the payment processor is used to convert an HTTPS first request (i.e., GET getFeeQuote) into an RPC first request (i.e., RPC getFeeQuote()) and vice versa. This conversion is necessary in embodiments that require support for this node implementation, or in other implementations that only support RPC. As mentioned above, the API converter may be part of an API gateway or gateway processor associated with the payment processor, where HTTP / RPC conversion is just one of the functions provided by the API gateway. The purpose of sending getFeeQuote() in RPC format to the network nodes is to inform the client of the fee charged by each network node. No input parameters are required, but you may need to implement the RPC interface associated with RPC getFeeQuote() so that the command returns a data type from each network node in the form of a JavaScript Object Notation (JSON) object, namely NetworknodeFeeQuote (Network Node Fee Quote), which contains fee-related data collected from each network node.

[0078] The data collected from each network node related to the obtained fee quote can be defined as a JSON object, as shown in the example below.

[0079] The JSON object FeeQuotes returned from each network node is shown below. While an example relating to a single transaction is shown, this disclosure is not limited to this and applies equally to fee quotes representing mining fees for multiple transactions:

[0080]

[0081]

[0082]

[0083] In some embodiments, the JSON FeeQuotes object contains an array of network node details and fees charged, while NetworknodeFeeQuote is a JSON structure containing network nodes and fee data received from individual network nodes. Some terms used in the JSON objects above are explained below.

[0084] CurrentHighestBlockHash can be used as a marker to identify the block hash at the point where the blockchain has grown when getFeeQuote() is called.

[0085] The NetworknodeSignature can contain the signatures of network nodes that agree to guarantee the transaction, as described above. This is different from the digital signature used to verify the identity of a network node. By doing so, a network node can guarantee that it will soon include the transaction in a block, and optionally, will not include any conflicting transactions. If a network node does not wish to guarantee the transaction, it can set it to null.

[0086] The SignatureTimestamp indicates the time during which a network node guarantees to mine a transaction at the specified current fee; that is, from that point in time until it is overridden. This time is overridden if the client subsequently calls getFeeQuote().

[0087] NetworknodeReputation is a metric related to the performance of a network node (i.e., how well the network node executes transactions at the current fees offered or promised). Reputation scores / metrics can be calculated, maintained, and managed by each payment processor.

[0088] A Networknode ID can be two parts of data added to the coinbase transaction when a block is mined. If a Networknode ID does not exist, the payment processor can either mark the network node with an empty (NULL) Networknode ID or simply leave it blank.

[0089] Within each NetworknodeFeeQuote, an array of FeeTypes objects can be used to capture the various fee types currently available. Fee types can be introduced in the future without requiring any changes to the getFeeQuote() interface provided by the payment processor. All transactions can have a single FeeTypes array.

[0090] Step 106 describes the payment processor providing the obtained fee quote to the client. In some embodiments, this may include a recommended fee quote determined by the payment processor. As described above with respect to the first aspect, this step may include a conversion from RPC to HTTPS via an API converter, enabling the client to access details using a web-based API.

[0091] In step 108, a second request is received from the client, which is a request to submit a given transaction related to a selected fee quote among the received fee quotes. In some embodiments, the given transaction is based on a digital asset payment made to the client in response to a payment request from the client. For example, if the client is a merchant terminal in a coffee shop, this might be a digital asset payment in exchange for a cup of coffee. In this step, the client requests the digital asset payment to be written into the blockchain via the payment service API implemented by the payment processor.

[0092] As described above, in some embodiments, the second request from the client may be a request to submit multiple transactions. Requests related to submitting multiple transactions may be sent to the same payment processor API or another endpoint associated with the payment processor. All endpoints associated with the payment processor will be notified or provided to the client. In the case of multiple transactions, the selected fee quote may be associated with mining all the multiple transactions; or a fee may be selected for each transaction among the multiple transactions for the selected fee quote.

[0093] In the case of multiple transactions, the body of the second request can be in the form of an array of original transactions. This endpoint is used to send multiple original transactions to the network node to be included in the next block created by the network node.

[0094] The sample format of the request body is shown below:

[0095]

[0096] An example response could be as follows:

[0097]

[0098] The fee quote selected in the second transaction can be based on a recommendation made by the payment processor, or it can be selected by the client for one or more transactions.

[0099] As mentioned above, the selected quote can be based on the average or maximum of all received fee quotes.

[0100] As described above, in some embodiments, the selected fee quote may be a service level-based quote, wherein the obtained fee quote is categorized into service levels by the payment processor.

[0101] In some embodiments, the mining fees and features / functionality associated with each service level can be pre-determined by a payment processor. Then, based on a given client's requirements, a service level and associated mining fees (selected fee quotes) can be allocated to that client. Client requirements can be based on the type of transaction the client is processing. Service levels can be pre-allocated or pre-agreed, for example, based on an external service level agreement. Therefore, pre-allocation can be based on the priority associated with the transaction and the level of protection against double-spending provided by the network node satisfying the selected fee quote / service level.

[0102] Therefore, for the transaction to be mined, the fees associated with the service level can be pre-determined by the payment processor and agreed upon with the client. If the client has not yet selected a service level or fee, the details of the obtained fee quotes can be provided to the client for selection. The obtained fee quotes are categorized into service levels, and each service level is associated with its corresponding fee.

[0103] Alternatively, the payment processor can recommend a service level and associated fees as a selected fee quote. This recommendation of service level can be based on data and statistics from previous transactions associated with the client. Or, in some cases, the payment processor provides recommendations based on input from the client.

[0104] As described above, in some embodiments, service levels are allocated to network nodes based on the obtained fee quotes and the minimum possible cost (i.e., relay fees) for the network nodes to mine one or more transactions. Therefore, advantageously, different fees can be applied for different transaction types or use cases. In some embodiments, the transaction type or service requirement can be obtained by the client.

[0105] Service levels can also be determined directly by the payment processor based on its knowledge of transaction fee quotes obtained from network nodes and its knowledge of relay fees at those nodes. This allows the payment processor to categorize fees and, optionally, recommend fees to clients, regardless of whether the client has indicated a minimum service level. Once the fees are obtained, the payment processor can inform the client of the expected service level from any selected / recommended transaction fee. These can include attributes associated with the service level.

[0106] The table below provides a matrix example that a payment processor can use to categorize fees in Service Levels (SLs) 0-4 based on relay fees and transaction (TXN) fees. Other digital assets or cryptocurrencies can be used. This matrix can be stored in a static or dynamic profile or entry associated with the payment processor, allowing for service level categorization based on this logic.

[0107] In the example below, two characteristics have been considered for the service level: (i) transaction priority and (ii) protection against double-spending. However, this disclosure is not limited to these, and the service level can be based on other characteristics and attributes.

[0108] 0 ＜0.20 ＜0.3 SL0 1 0.20 0.3 SL1 2 0.25 0.4 SL2 3 0.25 0.5 SL3 4 ＞0.25 ＞0.5 SL4

[0109] Therefore, in this example:

[0110] For Service Level (SL) 0 (i.e., SL0) – there is no network node guarantee for mining, and no double-spending protection, where minRelayrfee < 0.20, meaning no mining service is guaranteed. There is no additional double-spending protection because the fee does not cover transactions that are not mined in the secondary mempool to check for double spending.

[0111] SL1—Low priority, no double-spending protection. If (minRelayrfee) = < 0.20 and (txnfee) = < 0.3, this transaction may not be mined before other transactions in the mining queue, and therefore may be mined (for example) after approximately 24 hours. There is no additional double-spending protection because the fee does not cover transactions that are not mined in the secondary mempool to check for double spending.

[0112] SL2—Medium priority, with double-spending protection. If (minRelayrfee) = 0.25 and (txnfee) = < 0.4, meaning the transaction takes priority over some, but not all or most, other transactions in the mining queue, it may be mined within a period of approximately 12 to 24 hours. Additional double-spending protection is provided because the fee does cover transactions that are not mined in the secondary mempool; this is used to check for double-spending.

[0113] SL3—High priority, with double-spending protection. If (minRelayrfee) >= 0.25 and (txnfee) = 0.5, i.e., the transaction takes precedence over most other transactions in the mining queue, and therefore may be mined within a period of approximately 12 hours. There is additional double-spending protection because the fee does cover transactions that are not mined in the secondary mempool, which will be used to check for double spending.

[0114] SL4—Highest priority, all network nodes will mine this transaction, with full double-spending protection, where txnfee > 0.5, meaning this transaction takes precedence over all other transactions in the mining queue and may therefore be mined within a period of approximately 2 hours. Additional double-spending protection is provided because the fee does cover transactions that are not mined in the secondary mempool, which will be used to check for double-spending.

[0115] In this case, the JSON object FeeQuotes listed in step 104 above may also include:

[0116]

[0117]

[0118] In some embodiments, the second request is an HTTPS request in the form of POST submitTransaction(Tx), where, in some embodiments, Tx is a JSON object associated with a given transaction for a payment between a client and a customer. Therefore, Tx (the JSON object) contains the data needed to create the transaction on the blockchain, which the client can provide or construct as a JSON structure before submitting the second request to the payment processor for transmission to network nodes.

[0119] Step 110 describes the process of sending a request to one or more network nodes among a plurality of network nodes to generate a blockchain transaction corresponding to the given transaction in step 108. In this step, the payment processor, in some embodiments, converts the HTTPS POST request from the previous step into an RPC request to submit to the network node. This can be done by requesting RPCcreateRawTransaction(Tx), where Tx includes data associated with the given transaction, given as a JSON object, as discussed in step 108. RPC createRawTransaction(Tx) is an RPC call used to create a transaction that spends a given input and creates a new output, where the output can be an address or data. The RPC request can be sent to multiple network nodes, or to the network node in step 108 that satisfies or conforms to the selected fee quote from the client. As described above, network nodes that provide a current fee quote equal to or lower than the selected fee quote are considered to satisfy the requirement of the selected fee quote because they can mine transactions with the fee of their corresponding current quote. In response, the network node that satisfies the selected fee quote creates a blockchain transaction corresponding to the given transaction. In some embodiments, the original transaction, in hexadecimal encoding, corresponding to the given transaction, is returned to the payment processor.

[0120] In step 112, the payment processor receives an output or output script associated with a corresponding blockchain transaction created by at least one network node among a plurality of network nodes that meets a selected fee quote. The output script may be a UTXO associated with the corresponding blockchain transaction created by the respective network node. In some embodiments, the UTXO may also be stored in the memory pool of the respective network node that met the selected fee quote. The output in this step will include a transaction identifier (TxID) of the corresponding blockchain transaction created by the respective network node. The TxID is a hexadecimal-encoded reference to the transaction submitted to the network node's memory pool, which is then mapped to the blockchain transaction accordingly by the payment processor.

[0121] The blockchain transaction can then be mined immediately or later to complete the mining process at the current fee quote. In some cases, a created transaction may not be mined because another network node has already written it into the blockchain, or it may be pending or rejected for some reason (e.g., double-spending, delay, or invalidity).

[0122] Step 114 describes sending a transaction result TxResult to the client, which includes a transaction identifier TxID for the blockchain transaction created by the corresponding network node for the given transaction in step 108. In some embodiments, the transaction result TxResult is a JSON object sent from the payment processor to the client using HTTPS protocol based on details of the corresponding blockchain transaction created by the corresponding network node in steps 110 and 112 that satisfies the selected fee quote.

[0123] The following is an example of the detailed information contained in the client's TxResult object:

[0124] The JSON object TxResult is shown below for the corresponding network node and includes some of the terms and objects discussed in step 104 as part of the FeeQuotes JSON object.

[0125]

[0126]

[0127] The ReturnResult above may contain one of the following possible values, which are listed below:

[0128] • Submitted — No problems, the transaction has been submitted to the mempool.

[0129] • Rejected_DS — Rejected due to double-spending – DoubleSpendTxID cannot be null

[0130] •Rejected_Policy — Rejected due to policy violation

[0131] • Rejected_Invalid — Rejected due to invalid transaction.

[0132] • Rejected_FeeTooLow — The fee is too low, so network nodes will not include Tx in the block.

[0133] • Rejected_KeepInMemPool — Tx is rejected but kept in the memory pool for double-spending checks.

[0134] In the event that multiple transactions exist that are associated with the client and submitted together using the same or separate endpoints associated with the payment processor, the response body returned to the second request can be in the following JSON format:

[0135]

[0136] In some embodiments, for multiple transactions submitted in a second request, the response body provides the following:

[0137] - The response groups the header information and transaction level (payload) information.

[0138] - The response report returns the result (or current status) for each transaction.

[0139] - The response returns an error count: count(returnResult<>success)

[0140] The response returns an error threshold, where if the error count is greater than X, further processing of the transaction is stopped, and all multiple transactions submitted in the second request are rejected, where X is a configurable parameter that can be predefined or dynamically defined. If a batch of multiple transactions submitted together in the second request are rejected by the network node due to an error count greater than X, an error code with an appropriate code description can be assigned.

[0141] The following is a list of JSON envelope terminology and its functional descriptions:

[0142] Payload Key Data Payload—Based on Transaction Level Information sign Signature on payload string Public Key Public key used to verify signatures coding Encoding type mine type Multipurpose Internet Mail Extensions

[0143] Below is an example of the payload or message field returned:

[0144]

[0145] Step 116 describes the steps of receiving a status query associated with the transaction identifier TxID from the client to continue sending it to multiple network nodes. This step can begin asynchronously with the steps described above of scheduling transaction submission after selecting a fee quote from multiple mining fee quotes, and is not considered essential to the operation of the first aspect. Embodiments beginning with step 116 relate to scenarios where the client wants to know the status of one or more second requests made in step 108.

[0146] Step 116 enables the client to query the status of transactions that the client has submitted to the payment processor via the HTTPSPOST submitTransaction(Tx) discussed in step 108. Therefore, the TxID in this step can correspond to any second request made for any given transaction related to a digital asset payment between the client and its customers. As discussed in the steps above, the status query is received from the client using HTTPS as the transport protocol. This query is sent in JSON format (e.g., GET queryTransactionStatus(TxID)), which is then converted into an RPC request (RPCgetRawTransaction(TxID)) and sent to one or more network nodes among multiple network nodes.

[0147] In some embodiments, if a client submits multiple transactions in a second request, as described above, the client can query the status of multiple transactions in a single query transaction status request, instead of sending a separate request for each transaction. Requests related to querying the status of multiple transactions can be sent to the same payment processor API or another endpoint associated with the payment processor. All endpoints associated with the payment processor will be notified or made available to the client. This can be provided when the client registers for services associated with the payment processor. As mentioned above, a known open API tool such as Swagger can be used to provide the API to the client.

[0148] When querying multiple transactions, the body of the second request can be in the form of an array of transaction identifiers (TxIDs). An example of the request format is shown below:

[0149]

[0150] In step 118, the payment processor receives a response from the appropriate network node among multiple network nodes associated with the creation and / or processing of the blockchain transaction associated with the TxID. In some embodiments, the RPC getRawTransaction(TxID) described above may include a Verbose parameter, which may be associated with an argument set to 1. In this case, if successful, the result returned from the appropriate network node will be in JSON format in some embodiments, containing the corresponding blockchain transaction decoded in steps 110 and 112. This advantageously provides flexibility in capturing and processing the data therein. If the Verbose parameter is set to 0, the transaction is not returned to the payment processor as a hexadecimal encoded form, but rather as a JSON data type or document format. If no such transaction associated with the TxID is found, null can be returned, which in turn will cause the ReturnResult object to be set to "unknown". Any other returned errors can also be reported to the payment processor by the network node via the ReturnResult and ResultDescription objects. These objects have been indicated with respect to step 114.

[0151] In step 120, the TxResult associated with the TxID is returned to the client, sending a response using HTTPS. This represents the mining result associated with the given TxID sent by the client in the status query in step 116. An example of a TxResult sent from the payment processor to the client is given below. The JSON object TxStatus is shown below:

[0152]

[0153] If a transaction has been successfully mined and marked as Confirmed (i.e., added to a block) by the corresponding network node, then the BlockHash and NetworknodeID can be populated. If a network node does not set its NetworknodeID, then it will be set to "NULL".

[0154] The ReturnResult object can contain one of the following mining results:

[0155] • Submitted — No problems, the transaction has been submitted to the mempool.

[0156] • Confirmed — The transaction has been confirmed – Confirmation cannot be 0 or null.

[0157] • Rejected_DS — Rejected due to double-spending – DoubleSpendTxID cannot be null

[0158] •Rejected_Policy — Rejected due to policy violation

[0159] • Rejected_Invalid — Rejected due to invalid transaction.

[0160] • Rejected_FeeTooLow — The fee is too low, so network nodes will not include this transaction in the block.

[0161] • Rejected_KeepInMemPool — Tx is rejected but kept in the memory pool to check for double-spending.

[0162] • Unknown — The transaction was not seen or does not exist — This could mean that the transaction with the provided TxID does not exist in the mempool or blockchain. If so, this should be stated in the ResultDescription.

[0163] If multiple transactions exist that are to be queried together with the same or separate endpoints associated with the client and the payment processor, the returned response body can be in the following JSON format:

[0164]

[0165] In some embodiments, for multiple transactions queried, the responding entity groups the header information and transaction level (payload) information together.

[0166] Payload Key Data Payload—Based on Transaction Level Information sign Signature on payload string Public Key Public key used to verify signatures coding Encoding type MIME type Multipurpose Internet Mail Extensions

[0167] Below is an example of the returned payload or message field:

[0168]

[0169] The second aspect—the client

[0170] Figure 2 The second aspect of this disclosure describes a method executed by one or more processors associated with a client, wherein the client is communicatively coupled to at least one payment processor that implements the method discussed with respect to the first aspect. As described above, the payment processor implements for the client... Figure 1 The payment services or payment APIs discussed in connection with this topic.

[0171] exist Figure 2 In the example scenario depicted, the embodiment involves the following steps: obtaining multiple mining cost quotes, submitting a transaction based on a selected cost quote from the multiple obtained mining cost quotes, and sending a status query associated with the transaction identifier. Figure 2In the flowchart, all steps are described as occurring sequentially, i.e., as a single process. However, this disclosure and the second aspect should not be considered as limited thereto. The steps described below relating to obtaining a fee quote in the first request (steps 202-206) can be performed independently of the remaining steps. Similarly, the steps relating to submitting the transaction in the second request (steps 208-212) can be performed independently and at a different time than the previous steps of obtaining the fee quote. Likewise, the steps relating to querying the transaction status starting from step 214 can be performed at any time after the client already knows the identifier of the transaction and do not need to follow... Figure 2 The order in which the steps are presented is merely for ease of explanation and understanding, and in no way should this disclosure be considered limited to this order or scenario. Furthermore, as stated above regarding... Figure 1 The discussion can involve requesting and / or receiving and / or submitting and / or querying fee quotes for each individual transaction, or requesting and / or receiving and / or submitting and / or querying fee quotes for multiple transactions that are to be submitted by the client in a single request (i.e., submitted simultaneously) in a group or batch. For ease of explanation and understanding, this will be explained in conjunction with a single transition in the first / second request and the status query associated with the client. Figure 2 However, this disclosure is by no means limited to this.

[0172] Step 202 describes sending a first request to at least one payment processor associated with the client for providing the corresponding payment service. (See also: Regarding...) Figure 1 As discussed in step 102, the request relates to one or more fee quotes for mining transactions for the client. This first request pertains to the HTTPS GETgetFeeQuote discussed in step 102. As mentioned above, this request can be used to mine any transaction for the client, or it can be a request to obtain a fee quote for mining transactions related to digital asset payments originating from a customer associated with the client. As mentioned above, in some embodiments, the first request may also include details of the service level required for the one or more transactions to be mined. This may be related to the mining speed provided by the network node and / or protection against double-spending.

[0173] In step 204, multiple mining fee quotes are received from the payment processor. These quotes relate to the mining fee of each of a plurality of network nodes communicatively coupled to the payment processor serving the client. (Already combined) Figure 1 Step 104 discusses the structure and details of the received fee quote.

[0174] Step 206 describes the selection of a fee quote from one or more fee quotes received in step 204. In some embodiments, the selected fee quote may be based on a recommended fee quote proposed by a payment processor. In some embodiments, the selection is made by one or more processors associated with the client. As described above, the selected fee quote may be the average or median of the obtained fee quotes, or the maximum of the fee quotes obtained from multiple network nodes, or the highest fee quote in the secondary memory pool. Thus, the client may select the highest fee value obtained from multiple network nodes in response to a first request. In this way, all network nodes can be provided with an equal opportunity to mine transactions with their corresponding current quoted fees. However, the client may alternatively select a fee quote equal to or higher than the median or average of all received fee quotes, so that network nodes with higher quotes can simply keep the transaction in the secondary memory pool and use it to check and / or reject any double-spending of the transaction.

[0175] Step 208 describes the steps of requesting digital asset payments from a client associated with the client and / or processing digital asset payments from a client associated with the client. This can be a payment request or an invoice for digital asset payments sent by the client to the client using a known method applicable to the respective digital wallet implementations of both parties. Since the selected fee quote used to mine any transaction onto the blockchain is known, the request can include or be associated with the selected fee quote.

[0176] Step 210 describes the process of sending a second request to submit a given transaction associated with a digital asset payment from the customer to the payment processor to the blockchain. The submission in this step is based on the selected fee quote used in step 206 to mine the given transaction. This step involves... Figure 1 In step 108, the client sends an HTTPS POSTsubmitTransaction(Tx) request to the payment processor, which contains relevant details of the given transaction in JSON data type format.

[0177] Step 212 describes the steps of receiving the transaction identifier (TxID) of the blockchain transaction corresponding to the submitted transaction. For example... Figure 1 As discussed in steps 110 and 112, the TxID is created by at least one network node that satisfies the selected fee quote. In some embodiments, this may be sent in association with or as part of a transaction result; that is, the TxResult indicates the current mining status of the corresponding blockchain transaction for the respective network node. This combines... Figure 1 Step 114 is described.

[0178] Step 214 involves the client sending a status query when it wishes to query the mining status of a transaction previously submitted in step 210, which is related to a payment between the client and the customer. Since the client will receive the TxID of the submitted transaction in step 212, this request can be based on the TxID and formatted as HTTPS GETqueryTransactionStatus(TxID), such as... Figure 1 As described in step 116.

[0179] Step 216 describes obtaining the mining status result of the blockchain transaction corresponding to the transaction identifier TxID queried in step 214. This can be in JSON format and sent to the client by the payment processor using HTTPS after the payment processor receives the details of the corresponding transaction. The status result can be in the form of a TxResult JSON object, such as... Figure 1 As seen in step 120.

[0180] The third aspect—Network node implementation methods

[0181] Figure 3 This disclosure relates to a second aspect and describes a method executed by network nodes among a plurality of network nodes, wherein the plurality of network nodes are communicatively coupled to at least one payment processor, which implements the method as discussed with respect to the first aspect. Figure 1 The relevant discussion concerns payment services or payment APIs. The client is configured to implement [the relevant information / actions]. Figure 2 The methods discussed.

[0182] exist Figure 3 In the example scenario depicted, the implementation involves the following steps: providing multiple mining fee quotes, generating / creating a blockchain transaction based on a selected quote from the multiple mining fee quotes, and providing the mining status associated with the transaction identifier. Figure 3 In the flowchart, all steps are described as occurring sequentially, i.e., as a single process. However, this disclosure and the third aspect should not be considered as limited thereto. The steps described below relating to providing the current fee quote in response to the first request in steps 302 and 304 can be implemented independently of the remaining steps. Similarly, the steps relating to generating the corresponding blockchain transaction in response to the second request from steps 308 to 314 can be implemented independently, and at a different time than the previous steps of obtaining the fee quote. Likewise, the steps relating to providing the transaction status in step 316 can be implemented at any time after the client already knows the identifier of the transaction, and do not need to follow Figure 3The order in which the steps are presented is merely for ease of explanation and understanding, and in no way should this disclosure be considered limited to this order or scenario. Furthermore, as stated above regarding... Figure 1 and Figure 2 The discussion can involve requesting and / or receiving and / or submitting and / or querying a fee quote for each individual transaction, or requesting and / or receiving and / or submitting and / or querying a fee quote for multiple transactions that are to be submitted by the client in a single request (i.e., submitted simultaneously) in a group or batch. For ease of explanation and understanding, the discussion will focus on a single transaction within the first / second request and the associated status query with the client. Figure 3 However, this disclosure is by no means limited to this.

[0183] Step 302 describes receiving a first request from a payment processor, which provides a fee quote on behalf of the client for mining transactions. This request is related to an RPCgetFeeQuote() request sent from the payment processor, as per [reference to...]. Figure 1 As described in step 104.

[0184] Step 304 describes providing a current fee quote associated with each of the multiple network nodes for mining transactions in the blockchain. The fee quote can be provided in the format of a JSON object, FeeQuotes, as per the description. Figure 1 As described in step 104.

[0185] Step 306 describes the steps for one of the multiple network nodes to receive a second request related to a given transaction submitted to the blockchain and associated with a client, wherein the given transaction is based on a selected fee quote from the client. The given transaction and Figure 2 In step 210, Tx in POSTsubmitTransaction(Tx) (i.e., the given digital asset payment transaction between the client and the customer) is related. This RPC version received from the payment processor is RPCcreateRawTransaction(Tx) for the given transaction, as per [reference needed]. Figure 1 As explained in step 110.

[0186] Step 308 describes checking whether the network node meets or conforms to the selected fee quote from the client. This may include determining whether the current fee quote provided by the appropriate network node to the payment processor in step 304 is equal to or lower than the selected fee quote that the client is willing to pay for mining a given transaction Tx.

[0187] If the current fee quote meets the selected fee quote, a blockchain transaction corresponding to the given transaction is created in step 310. This is about... Figure 1Step 110 is discussed. In some embodiments, the original transaction, corresponding to the hexadecimal code of a given transaction, is returned to the payment processor. An output script or UTXO, such as..., is also provided to the payment processor. Figure 1 As discussed in step 112, the output script includes a transaction identifier (TxID) associated with the corresponding blockchain transaction created by the relevant network node. The output script (UTXO) of the blockchain transaction can then be added to the mempool associated with the network node for immediate or later mining.

[0188] In some embodiments, if the current fee quote does not meet the selected fee quote—that is, if the current fee quote of the corresponding network node is higher than the fee quote allowed or selected by the client—the corresponding network node may choose to mine at a fee lower than the current fee quote, or may choose not to mine the given transaction because the selected fee is lower than its corresponding current quote fee. In embodiments where the corresponding network node chooses not to mine the transaction at the lower selected fee quote, in step 312, the corresponding network node may alternatively add details related to the blockchain transaction constructed for the given transaction to an auxiliary mempool associated with the corresponding network node. In some embodiments, the transaction may be retained in the auxiliary mempool and used for double-spending checks. All transactions stored in the auxiliary mempool may have an expiration time after which they can be cleared.

[0189] Assuming a blockchain transaction has already been created, meaning the corresponding network node meets the client's selected fee quote requirements, step 316 involves the corresponding network node receiving a status query associated with the TxID of the blockchain transaction created for the client. This status query is based on the RPC request RPCgetRawTransaction(TxID) received via the API converter, as per [reference needed]. Figure 1 The steps 116 and 118 are discussed.

[0190] In step 318, the result based on the current mining status of the corresponding blockchain transaction associated with the relevant network node is provided to the payment processor. This can be based on a JSON object structure for TxStatus, such as regarding... Figure 1 The explanation is provided in step 120.

[0191] Figure 4This is a schematic diagram of the deployment architecture of a payment service provided as an API to a client 402 by a payment processor 404. There may be more than one such payment processor 404, and one or more payment processors 404 may be implemented as part of a client, or may be associated with a client, or may be implemented separately from a client and communicate with the client via a communication network such as the Internet. As discussed above, communication between the client 402 and the payment processor 404 uses the HTTPS protocol. An API converter 406 is also shown separately in this schematic diagram, but in some embodiments it may be implemented as part of the payment processor 404. In some embodiments, the API converter 406 may be operated by or associated with multiple network nodes 412-1 to 412-n. The API converter 406 allows the conversion of HTTPS requests into RPC requests before sending HTTPS requests to one or more network nodes 412-1 to 412-n, which are coupled to the payment processor 404 for providing services to the client 402. API converter 406 is shown connected to network nodes 412-1 to 412-n via firewall 408. All communication associated with network nodes 412-1 to 412-n uses RPC. Node connector 410 is also shown for connecting multiple network nodes 412-1 to 412-n to payment processor 404 via firewall 408. In some embodiments, the node connector may secure or process RPC calls associated with one or more payment processors implementing the corresponding payment service, such as those related to... Figure 1 The node connector 410 provides a secure communication channel between the API converter 406 and one or more network nodes 412-1 to 412-n, as discussed.

[0192] One or more payment processors 404 may exist, connected to network nodes 412-1 to 412-n via API converter 406. Client 402 will likely include a digital wallet application that retrieves a fee quote from the network nodes (getFeeQuote), submits a transaction (submitTransaction), and queries the transaction status (queryTransactionStatus), as explained in the first to third aspects regarding single or multiple transactions. Payment processor 404 acts as a REST endpoint for client 402, and the client can access the service anonymously.

[0193] Figure 5 It is a description Figure 4 The diagram illustrates the data flow between components in the architecture shown, used to implement the getFeeQuote command or template from the client. This has already been discussed above regarding... Figures 1 to 3A detailed discussion was held, and Figure 4 The interaction between the client, payment processor, and network nodes is illustrated in a simplified diagram to obtain a mining fee quote. The process originates from client 402 when an HTTPS GET getFeeQuote command is sent to payment processor 404 in step 501. In step 502, the GET command is sent to API converter 406, which converts it into an RPC command RPCgetFeeQuote() in step 503. In step 504, NetworknodeFeeQuote is returned as a JSON object from each of the multiple network nodes 412-1 to 412-n to API converter 406, which in turn provides it to payment processor 404 in step 505. Steps 502 to 505 are repeated for each of the multiple network nodes 412-1 to 412-n, and in step 506, the result (fee quote) is sent to client 402 in HTTPS transmission.

[0194] Figure 6 It is a description Figure 4 The diagram illustrates the data flow between components in the architecture shown, used to implement the submitTransaction command or template from the client. This has already been discussed above regarding... Figures 1 to 3 A detailed discussion was held, and Figure 4 The interaction between the client, payment processor, and network nodes is illustrated in a simplified diagram to provide a blockchain transaction associated with a payment to the client. The process originates from client 402 when, in step 601, an HTTPSPOST submitTransaction(Tx) command is sent to payment processor 404 for a given transaction Tx between client 402 and the customer. As mentioned above, Tx may be associated with a selected fee quote (not shown in the diagram). In step 602, the POST command is sent to API converter 406, which in step 603 converts it into an RPC command RPCcreateRawTransaction(Tx). A blockchain transaction is then constructed for each network node 412 that satisfies the selected fee quote. In step 604, the hexadecimal-encoded blockchain transaction is returned to API converter 406. The transaction includes a specific identifier TxID, as explained above. In step 605, the output associated with the blockchain transaction is sent to payment processor 404. In step 606, the result associated with the blockchain transaction is returned to the client as a JSONTxResult object including the TxID.

[0195] Figure 7 It is a description Figure 4The diagram illustrates the data flow between components in the architecture shown, used to implement the queryTransactionStatus command or template from the client. This has already been discussed above regarding... Figures 1 to 3 A detailed discussion was held, and Figure 4 The diagram simply illustrates the interaction between the client, payment processor, and network node to provide a blockchain transaction associated with the payment linked to the client. The process originates from client 402, where the blockchain transaction was previously used as a payment processor in step 701, when an HTTPS GETqueryTransactionStatus(TxID) command is sent to payment processor 404 for a given transaction TxID associated with the blockchain transaction. Figure 6 Part of the submitTransaction process is returned to the client. In step 702, a GET command is sent to API converter 406, and in step 703, API converter 406 converts it into an RPC command RPC getRawTransaction(TxID). The blockchain transaction associated with a given network node 412 associated with TxID is then identified. In step 704, the identified hexadecimal-encoded blockchain transaction and its associated status are returned to API converter 406. In step 705, the status result associated with the blockchain transaction associated with TxID is sent to payment processor 404. Then, in step 706, the status result associated with the blockchain transaction associated with TxID is returned to the client as a JSON TxStatus object.

[0196] In addition, as mentioned above Figures 1 to 3 The discussion may involve requesting and / or receiving and / or submitting and / or querying a fee quote for each individual transaction, or requesting and / or receiving and / or submitting and / or querying a fee quote for multiple transactions that are to be submitted by the client in a single request (i.e., submitted simultaneously) in a group or batch. For ease of explanation and understanding, the above has already explained the individual transaction and / or status query associated with the client in the first and / or second requests. Figures 4 to 7 However, it will be understood that this disclosure is by no means limited to this.

[0197] Turn now Figure 8 This document provides an illustrative simplified block diagram of a computing device 2600 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement any system shown and described above. For example, the computing device 2600 can be configured to serve as one or more components of a DBMS in a graph, or the computing device 2600 can be configured as a client entity associated with a given user, the client entity being configured to... Figure 8The database requests are made to the database managed by the DBMS. Therefore, the computing device 2600 can be a portable computing device, a personal computer, or any electronic computing device. Figure 8 As shown, computing device 2600 may include one or more processors 2602 having one or more levels of cache memory and memory controller, the processors being configured to communicate with a storage subsystem 2606 including main memory (also referred to as memory subsystem 2608) and permanent storage (also referred to as file storage subsystem 2610). As shown, the main memory may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. Storage subsystem 2606 and cache memory may be used to store information, such as details associated with transactions and blocks described in this disclosure. One or more processors 2602 may be used to provide steps or functions of any embodiment described in this disclosure.

[0198] The processor 2602 (one or more) can also communicate with one or more user interface input devices 2612, one or more user interface output devices 2614 and network interface subsystem 2616.

[0199] Bus subsystem 2604 can provide a mechanism for enabling the various components and subsystems of computing device 2600 to communicate with each other as intended. Although bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0200] The network interface subsystem 2616 can provide an interface to other computing devices and networks. The network interface subsystem 2616 can be used as an interface for receiving data from and transferring data to systems other than the computing device 2600. For example, the network interface subsystem 2616 enables data technicians to connect devices to a network, allowing them to transfer data to and receive data from the device while located at a remote location (e.g., a data center).

[0201] User interface input device 2612 may include one or more user input devices, such as a keyboard; pointing devices such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touchscreen integrated into the display; audio input devices such as a voice identification system, microphone; and other types of input devices. Generally, the term "input device" is used to include all possible types of devices and mechanisms for inputting information into computing device 2600.

[0202] One or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light-emitting diode (LED) display, or a projector, or other display devices. Generally, the term "output device" is used to include all possible types of means and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with applications performing the described processes and variations thereof, if such interaction is appropriate.

[0203] Storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that can provide the functionality of at least one embodiment of the present disclosure. When executed by one or more processors, application programs (programs, code modules, instructions) can provide the functionality of one or more embodiments of the present disclosure and may be stored in storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. Additionally, storage subsystem 2606 may provide a repository for storing data used according to the present disclosure. For example, main memory and cache memory can provide volatile storage for programs and data. Persistent storage devices can provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid-state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM, DVD, or Blu-ray) with associated removable media, and other similar storage media. Such programs and data may include programs for performing steps as described in one or more embodiments of the present disclosure, as well as data associated with transactions and blocks described in the present disclosure.

[0204] The computing device 2600 can be of various types, including portable computer devices, tablet computers, workstations, or any other devices described below. Additionally, the computing device 2600 may include another device that can be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that can be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Therefore, the device can be configured to convert optical signals into electrical signals, which can be transmitted for processing via the ports of the computing device 2600. Due to the constantly evolving nature of computers and networks, Figure 8 The description of the computing device 2600 depicted herein is intended only as a particular example to illustrate a preferred embodiment of the device. It has a higher... Figure 8 Many other configurations of the system, with more or fewer components, are possible.

[0205] Listed example embodiments

[0206] This disclosure is discussed in connection with the foregoing aspects, and these provisions are provided herein as exemplary embodiments to better explain, describe and understand the claimed aspects and embodiments.

[0207] 1. A computer-implemented method for providing payment services to one or more clients for transactions associated with a blockchain, the method being implemented by a payment processor and comprising the following steps:

[0208] Receive a first request from a client, which is associated with mining transactions in the blockchain;

[0209] Send a request for a fee quote to each of the multiple network nodes communicatively coupled to the payment processor;

[0210] Obtain a fee quote from each network node for mining the transaction; and

[0211] The client is provided with fee quotes obtained from the plurality of network nodes, wherein a selected fee quote for mining the transaction is determined based on the obtained fee quotes; or

[0212] Based on the obtained fee quote, a selected fee quote is determined for the client to mine the transaction.

[0213] 2. The method according to Clause 1, wherein the transaction associated with the first request comprises a batch of multiple transactions.

[0214] 3. The method described according to Clause 1 or 2 includes the following steps:

[0215] In response to a second request from the client for submitting a given transaction, a request is sent to one or more of the plurality of network nodes to generate a blockchain transaction corresponding to the given transaction, which relates to the selected fee quote among the obtained fee quotes;

[0216] Receive an output script associated with the corresponding blockchain transaction from at least one network node that satisfies the selected fee quote from the plurality of network nodes; and

[0217] The result is sent to the client, the result including a transaction identifier of the blockchain transaction corresponding to the given transaction.

[0218] 4. The method according to Clause 3, wherein the given transaction comprises a batch of multiple transactions.

[0219] 5. The method according to any of the preceding clauses, wherein the step of providing the obtained fee quote further includes: determining a recommended fee quote based on the average of the obtained fee quotes or the maximum value among the obtained fee quotes.

[0220] 6. The method according to Clause 5 further includes: providing the recommended fee quote or providing all obtained fee quotes including the recommended fee quote, wherein the recommended fee quote includes an identifier.

[0221] 7. The method according to any one of Clauses 5 or 7, wherein the selected fee quote is the same as or different from the recommended fee quote, wherein the different fee quote is predetermined or arbitrarily selected.

[0222] 8. The method according to any of the preceding clauses, wherein the step of determining the selected fee quote includes: assigning a service level from a plurality of service levels to each obtained fee quote, each service level being associated with a corresponding selected fee quote for mining the transaction.

[0223] 9. The method according to Clause 8, wherein the service level is allocated based on the obtained fee quote and the minimum relay cost associated with the network node, which is related to the corresponding fee quote.

[0224] 10. The method according to Clause 8 or 9, wherein the assigned service level indicates the priority of mining the transaction and / or the level of protection against double-spending associated with the transaction for the recommended fee.

[0225] 11. The method according to any one of Clauses 8 to 10, wherein the service level for the transaction to be mined is allocated based on one or more service requests obtained from the client.

[0226] 12. The method according to any of the preceding clauses includes the step of verifying the identity of a given network node among the plurality of network nodes, wherein the verification is based on a digital signature associated with the given network node, or based on an identifier associated with the given network node, optionally, the identifier being associated with a reputation metric of the given network node.

[0227] 13. The method according to any of the preceding clauses includes the step of verifying a corresponding fee quote obtained from a given network node among the plurality of network nodes based on a network node signature, wherein the network node signature is used as a commitment from the given network node for mining the corresponding fee quote and optionally rejecting any conflicting transactions.

[0228] 14. The method according to any of the preceding clauses, wherein the fee quote obtained from each network node is provided in the form of a data type, said data type being JavaScript Object Notation (JSON) object format.

[0229] 15. The method according to any of the preceding clauses, wherein the received output script is an unspent transaction output (UTXO) associated with the memory pool of the at least one network node, the unspent transaction output (UTXO) including the transaction identifier (TxID) of the blockchain transaction.

[0230] 16. The method described under any of the preceding clauses includes the following steps:

[0231] In response to a status query associated with a transaction identifier from the client, a request is sent to the plurality of network nodes to obtain the blockchain transaction corresponding to the transaction identifier;

[0232] Obtain the corresponding blockchain transaction from at least one of the plurality of network nodes; and

[0233] The status results related to the obtained blockchain transactions are sent to the client.

[0234] 17. The method according to any of the preceding clauses, wherein the payment processor is implemented as a representation state transition (REST) ​​endpoint for the one or more clients, and wherein the method further comprises: providing an application programming interface (API) converter associated with the payment processor to perform the following steps:

[0235] The client receives a first request and / or a second request and / or a status query related to the given transaction using the Hypertext Transfer Protocol Secure (HTTPS) transport protocol format.

[0236] The corresponding request is converted into a Remote Procedure Call (RPC) format and sent to one or more of the plurality of network nodes;

[0237] Receive, in RPC format, responses associated with the corresponding blockchain transactions from one or more of the plurality of network nodes; and

[0238] The corresponding response is transformed so that it can be sent to the client using the HTTPS transport protocol.

[0239] 18. A computer-implemented method for processing transactions associated with a blockchain, the method being implemented by one or more processors associated with a client, the client being communicatively coupled to at least one payment processor that implements payment services for the client, the method comprising the steps of:

[0240] Send a first request to one of the at least one payment processors, the request relating to one or more fee quotes for mining a transaction related to a digital asset payment from a customer; and

[0241] In response to receiving one or more fee quotes from the payment processor, a fee quote is selected from the one or more received fee quotes.

[0242] 19. The method described in Clause 18 includes the following steps:

[0243] From the customer, requesting digital asset payments and / or processing digital asset payments from the customer, the request being associated with a selected fee quote;

[0244] Send a second request to submit a given transaction to the blockchain associated with a digital asset payment from the customer to the payment processor, the submission being based on a selected fee quote used to mine the given transaction; and

[0245] Obtain the transaction identifier (TxID) of the blockchain transaction corresponding to the submitted transaction.

[0246] 20. The method according to Clause 19, wherein the given transaction in the second request comprises a batch of multiple transactions.

[0247] 21. The method according to any one of Clauses 18 to 20, comprising the following steps:

[0248] Send a status query associated with the obtained transaction identifier; and

[0249] Obtain the status result of the blockchain transaction corresponding to the transaction identifier.

[0250] 22. The method according to any one of Clauses 18 to 21, wherein the client includes or is communicatively coupled to the at least one payment processor, the at least one payment processor being configured to implement the method according to any one of Clauses 1 to 17.

[0251] 23. The method according to any one of clauses 18 to 22, wherein the first request and / or the status query is an HTTPS GET request, and wherein the second request is an HTTPS POST request.

[0252] 24. The method according to any one of Clauses 18 to 23, wherein the step of selecting a fee quote includes: determining an average of the obtained fee quotes and selecting a fee quote based on the determined average.

[0253] 25. The method according to any one of Clauses 18 to 24, wherein the step of selecting a fee quote includes: determining the maximum value of the fee quotes obtained, and selecting a fee quote based on the maximum value.

[0254] 26. The method according to any one of clauses 18 to 25, wherein the data associated with the first request and / or the second request and / or the status query is provided in JavaScript Object Notation (JSON) object format.

[0255] 27. A computer-implemented method for processing transactions associated with a blockchain, the method being implemented by one or more processors associated with network nodes among a plurality of network nodes, the plurality of network nodes being communicatively coupled to at least one payment processor that implements payment services for a client, the method comprising the steps of:

[0256] Receive a first request from the payment processor, the first request being a fee quote for mining transactions associated with the client; and

[0257] Provide a current fee quote related to the network node mining the transaction in the blockchain, wherein the current fee quote represents a promise to mine the transaction at the current fee quote.

[0258] 28. The method described in Clause 27 includes the following steps:

[0259] In response to submitting a second request to the blockchain related to a given transaction associated with the client, the given transaction being based on a selected fee quote, the method further includes the following steps:

[0260] Based on the determination that the selected fee quote associated with the given transaction satisfies the current fee quote of the network node, a blockchain transaction corresponding to the given transaction is generated;

[0261] Generate output scripts (UTXO) for the blockchain transactions;

[0262] Add the generated output script to the memory pool associated with the network node; and

[0263] The output script is sent to the payment processor, wherein the output script includes a transaction identifier (TxID) associated with the corresponding blockchain transaction.

[0264] 29. The method according to Clause 28 includes: in response to a request for a state associated with the transaction identifier, returning a result based on the mining state of the corresponding blockchain transaction.

[0265] 30. The method according to any one of Clauses 27 to 29, wherein the steps of providing the current cost quote and / or sending the output script and / or returning the result are implemented as a remote procedure call (RPC).

[0266] 31. The method according to Clause 30 includes the steps of: sending an RPC from the network node to a node connector and optionally a firewall of the plurality of network nodes, and then propagating the RPC to a payment processor of a client via a wireless communication network.

[0267] 32. The method according to any one of Clauses 27 to 31, wherein, based on determining that a selected fee quote associated with the given transaction does not satisfy the current fee quote of the network node, an output associated with the corresponding blockchain transaction is added to an auxiliary memory pool associated with the network node.

[0268] 33. The method according to any one of Clauses 27 to 32, wherein the network node is communicatively coupled to the at least one payment processor, the at least one payment processor being configured to implement the method according to any one of Clauses 1 to 9, and wherein the at least one payment processor is associated with or communicatively coupled to the client, the client being configured to implement the method according to any one of Clauses 12 to 19.

[0269] 34. A computer-implemented method for providing payment services to one or more clients for transactions associated with a blockchain, the method being implemented by a payment processor and comprising the following steps:

[0270] Receive one or more service requests from the client for transactions to be mined in the blockchain, or agree on one or more service requests with the client;

[0271] Receive a first request from the client to mine one or more transactions in the blockchain;

[0272] Send a request for a fee quote to each of the multiple network nodes that are communicatively coupled to the payment processor;

[0273] Obtain a fee quote from each network node for mining the one or more transactions;

[0274] The obtained cost quotes are categorized into a given service level among multiple service levels offered by the mining, with each service level associated with a set mining cost;

[0275] The service level of the client is determined based on the received one or more service requests; wherein the set mining fee associated with the determined service level is a selected fee quote for mining the one or more transactions associated with the client; and wherein the determined service level indicates the priority for mining transactions and / or the level of protection to prevent double-spending.

[0276] 35. A computing device comprising: a processor; and a memory including executable instructions, which, when executed by the processor, cause the device to perform a computer-implemented method according to any one of clauses 1 to 17 and 33, the computing device relating to a payment processor.

[0277] 36. A computing device comprising: a processor; and a memory including executable instructions, which, when executed by the processor, cause the device to perform a computer-implemented method according to any one of claims 18 to 26, the computing device relating to a client.

[0278] 37. A computing device comprising: a processor; and a memory including executable instructions, which, when executed by the processor, cause the device to perform a computer-implemented method according to any one of claims 27 to 33, the computing device relating to a network node.

[0279] 38. A computer system, comprising:

[0280] A payment processor, communicatively coupled to at least one client and at least one network node via a wireless communication network, optionally associated with an API converter for converting HTTPS requests from the client into RPC requests for the network node and vice versa, wherein the payment processor is implemented by a computing device as described in Clause 35;

[0281] A client, communicatively coupled to a payment processor via the wireless communication network, and capable of communicating with at least one customer; the client is implemented using a computing device as described in Clause 36; and

[0282] Multiple network nodes are communicatively coupled to the payment processor via the wireless communication network, each network node being implemented by a computing device as described in Clause 37.

[0283] 39. A computer-readable storage medium having executable instructions stored thereon, the executable instructions causing the computer to perform any of the methods of clauses 1 to 34 when executed by a processor of the computer.

[0284] It should be noted that the foregoing aspects and embodiments are illustrative and not limiting of this disclosure, and those skilled in the art will be able to devise many alternative embodiments without departing from the scope of this disclosure as defined by the appended claims. Any reference numerals in parentheses within the claims should not be construed as limiting the claims. The words “comprising”, “comprise”, etc., do not exclude the presence of any element or step other than those listed in any claim or the entire specification. In this specification, “comprise” means “include or consist of”, and “comprising” means “including or consist of”. The singular form of an element does not exclude the plural form of such element, and vice versa. This disclosure can be implemented by hardware comprising several different elements and by a suitably programmed computer. In the device claims enumerating several components, several of these components can be implemented by one and the same item of hardware. The fact that certain means are recited in dissimilar dependent claims does not imply that combinations of these means cannot be advantageously used.

Claims

1. A computer-implemented method for providing payment services to one or more clients for transactions associated with a blockchain, the method being implemented by a payment processor and comprising the following steps: Receive a first request from a client, which is associated with mining transactions in the blockchain; Send a request for a fee quote to each of the multiple network nodes communicatively coupled to the payment processor; Obtain a fee quote from each network node for mining the transaction; The client is provided with fee quotes obtained from the plurality of network nodes, wherein a selected fee quote for mining the transaction is determined based on the obtained fee quotes; or, a selected fee quote for mining the transaction is determined for the client based on the obtained fee quotes; and The corresponding fee quote obtained from a given network node among the plurality of network nodes is verified based on the network node signature, which serves as a commitment from the given network node to mine the corresponding fee quote and to reject any conflicting transactions; The step of determining the selected fee quote includes: assigning a service level from a plurality of service levels to each obtained fee quote, with each service level associated with a corresponding selected fee quote used to mine the transaction; The allocated service level indicates the level of protection against double spending associated with transactions involving recommended fees.

2. The method according to claim 1, wherein, The transactions associated with the first request include a batch of multiple transactions.

3. The method according to claim 1 or 2, comprising the following steps: In response to a second request from the client to submit a given transaction, a request is sent to one or more of the plurality of network nodes to generate a blockchain transaction corresponding to the given transaction, which relates to the selected fee quote among the obtained fee quotes; Receive an output script associated with the corresponding blockchain transaction from at least one of the plurality of network nodes that satisfies the selected fee quote; as well as The result is sent to the client, the result including the transaction identifier of the blockchain transaction corresponding to the given transaction.

4. The method according to claim 3, wherein, The given transaction comprises a batch of multiple transactions.

5. The method according to claim 1, wherein, The step of providing the obtained fee quotes further includes: determining a recommended fee quote based on the average of the obtained fee quotes or the maximum value among the obtained fee quotes.

6. The method according to claim 5, further comprising: Provide the recommended fee quote or provide all obtained fee quotes including the recommended fee quote, wherein the recommended fee quote includes an identifier.

7. The method according to any one of claims 5 or 6, wherein, The selected fee quote may be the same as or different from the recommended fee quote, wherein the different fee quotes are predetermined or arbitrarily selected.

8. The method according to claim 1, wherein, The service level is allocated based on the obtained fee quote and the minimum relay cost associated with the network node corresponding to the fee quote.

9. The method according to claim 1, wherein, The assigned service level indicates the priority of mining the transaction.

10. The method according to any one of claims 1, 8, and 9, wherein, The service level of the transactions to be mined is allocated based on one or more service requirements obtained from the client.

11. The method according to claim 1, comprising: The step of verifying the identity of a given network node among the plurality of network nodes, wherein the verification is based on a digital signature associated with the given network node, or on an identifier associated with the given network node.

12. The method according to claim 11, wherein, The identifier is associated with the reputation metric of the given network node.

13. The method according to claim 1, wherein, The fee quotes obtained from each network node are provided in the form of a data type, which is a JavaScript Object Notation (JSON) object format.

14. The method according to claim 3, wherein, The received output script is an unspent transaction output (UTXO) associated with the memory pool of the at least one network node, the unspent transaction output (UTXO) including the transaction identifier (TxID) of the blockchain transaction.

15. The method according to claim 1, comprising the following steps: In response to a status query associated with a transaction identifier from the client, a request is sent to the plurality of network nodes to obtain the blockchain transaction corresponding to the transaction identifier; Obtain the corresponding blockchain transaction from at least one of the plurality of network nodes; as well as The status results related to the obtained blockchain transactions are sent to the client.

16. The method according to claim 3, wherein, The payment processor is implemented as a representation state transition (REST) ​​endpoint for the one or more clients, and the method further includes the step of providing an application programming interface (API) converter associated with the payment processor to perform the following steps: The client receives the first request and / or the second request in relation to the given transaction using the Hypertext Transfer Protocol Secure (HTTPS) transport protocol format. The corresponding request is converted into a Remote Procedure Call (RPC) format and the RPC is sent to one or more of the plurality of network nodes; Receive responses associated with the corresponding blockchain transaction from one or more of the plurality of network nodes in a Remote Procedure Call (RPC) format; and The corresponding response is transformed so that it can be sent to the client using the Hypertext Transfer Protocol Secure (HTTPS) transport protocol.

17. The method according to claim 15, wherein, The payment processor is implemented as a representation state transition (REST) ​​endpoint for the one or more clients, and the method further includes the step of providing an application programming interface (API) converter associated with the payment processor to perform the following steps: The status query is received from the client using the Hypertext Transfer Protocol Secure (HTTPS) transport protocol format; The corresponding request is converted into a Remote Procedure Call (RPC) format and the RPC is sent to one or more of the plurality of network nodes; Receive responses associated with the corresponding blockchain transaction from one or more of the plurality of network nodes in a Remote Procedure Call (RPC) format; and The corresponding response is transformed so that it can be sent to the client using the Hypertext Transfer Protocol Secure (HTTPS) transport protocol.

18. A computing device, comprising: processor; And a memory including executable instructions, which, when executed by the processor, cause the computing device to perform a computer-implemented method according to any one of claims 1 to 17, the computing device relating to a payment processor.

19. A computer system comprising: A payment processor is communicatively coupled to at least one client and at least one network node via a wireless communication network, wherein the payment processor is implemented using the computing device according to claim 18; A client, communicatively coupled to the payment processor via the wireless communication network and capable of communicating with at least one customer; the client is implemented as a computing device including a second processor and a second memory, the second memory including second executable instructions, which, upon execution by the second processor, cause the computing device to perform a computer-implemented method as follows: Send a first request to one of the at least one payment processors, the request relating to one or more fee quotes for mining a transaction related to a digital asset payment from a customer; and, in response to receiving one or more fee quotes from the payment processor, select a fee quote from the one or more received quotes; and Multiple network nodes are communicatively coupled to the payment processor via the wireless communication network. Each network node is implemented as a computing device, including a third processor and a third memory. The third memory includes third executable instructions, which, upon execution by the third processor, cause the computing device to perform a computer-implemented method as follows: Receives a first request from the payment processor, the first request being a fee quote for mining transactions associated with the client, and... Provide a current fee quote related to the network node mining the transaction in the blockchain, wherein the current fee quote indicates a guarantee to mine the transaction at the current fee quote and to reject any conflicting transactions.

20. The computer system according to claim 19, wherein, The payment processor is associated with an application programming interface (API) converter, which is used to convert Hypertext Transfer Protocol Security (HTTPS) requests from clients into Remote Procedure Call (RPC) requests for network nodes, and to convert RPC requests from network nodes into HTTPS requests for clients.

21. A computer-readable storage medium having executable instructions stored thereon, the executable instructions causing the computer to perform the method according to any one of claims 1 to 17 when executed by a processor of the computer.

Images