Computer-implemented methods and systems

Abstract

A computer-implemented system and method for establishing delegated authorization is detailed. A method for validating and generating a delegated authorization token includes obtaining a first delegated authorization token in a chain of delegated authorization tokens. Further delegated authorization tokens in the chain of delegated authorization tokens are generated based on preceding delegated authorization tokens in the chain of delegated authorization tokens. When validating the delegated authorization token, the validity of the first delegated authorization token is based on a comparison of one of the delegated authorization tokens in the chain of delegated authorization tokens to a predetermined value.

Description

[Technical field]

[0001] The present disclosure relates to methods and systems for implementing a platform for one or more services related to a distributed ledger, i.e., blockchain, for one or more clients. More specifically, but not by way of limitation, the present disclosure provides for providing delegated access to blockchain related services. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which duplicate copies of the blockchain are maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereafter also referred to as the "blockchain network"). The blockchain includes a chain of blocks of data, each block including one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to the preceding transaction in the sequence. The sequence may span one or more blocks up to one or more coinbase transactions. Coinbase transactions are discussed below. Transactions submitted to the blockchain network are included in new blocks. New blocks are generated by a process known as "mining". "Mining" involves multiple nodes competing to perform a "proof-of-work", i.e., solving a cryptographic puzzle based on the presentation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. Of note, the blockchain may be pruned at the nodes, and publication of blocks can be achieved through publication of only the block headers.

[0003] Transactions in a blockchain are used to perform one or more of the following: carry digital assets (i.e., multiple digital tokens), order a set of journal entries in a virtual ledger or registry, receive and process timestamp entries, and / or time-sequence index pointers. Blockchains can also be used to layer additional functionality on top of a blockchain. Blockchain protocols may allow additional user data or indexes to be stored on data within a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction. Thus, more complex data can be incorporated. For example, this can be used to store electronic documents, or audio or video data, within a blockchain.

[0004] Nodes of the blockchain network (sometimes called "miners") perform a distributed transaction registration and validation process described below. Briefly, during this process, nodes validate transactions, insert them into a block template, and attempt to identify a valid proof-of-work solution for it. Once a valid solution is found, the new block is propagated to other nodes of the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes of the network for propagation. Nodes receiving the transaction compete to find a proof-of-work solution and include the validated transaction in a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated and are not included in a block. Assuming the transaction is validated and thereby accepted into the blockchain, the transaction (including any user data) thus remains registered and indexed in each node of the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that generates a new amount of digital assets, or number of tokens. Detection and rejection of invalid transactions is performed by the actions of competing nodes that act as agents of the network and are incentivized to report and block illicit activity. Widespread publication of information allows users to continuously audit node performance. By simply publishing block headers, participants can guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset that can be derived from the preceding transaction sequence. A spendable output is sometimes called an unspent transaction output (UTXO). An output may further include a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Thus, when considering a pair of transactions, we refer to them as a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output that includes a locking script that specifies the amount of a digital asset and defines one or more conditions for unlocking the output. The second target transaction includes at least one input including a pointer to an output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when the second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlock script meets all of one or more conditions defined in the lock script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another previous valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction) (but may register an invalid transaction) nor will it be included in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction transfers by referencing absolute account balances, rather than defining the amount to be transferred by referencing back to the UTXO of the preceding transaction in the past sequence of transactions. The current state of every account is stored and constantly updated by nodes separate from the blockchain.

[0009] One area of ​​current research is the use of blockchain-based computer programs for the implementation of "smart contracts". These are computer programs designed to automate the execution of the terms of machine-readable contracts or agreements. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to generate results, which then perform actions dependent on the results. Another area of ​​blockchain-related interest is the use of "tokens" (or "coloured coins") to represent and transfer real-world entities via the blockchain. Potentially confidential or secret items can be represented by tokens that have no identifiable meaning or value. Thus, tokens act as identifiers that allow real-world items to be referenced from the blockchain.

[0010] The above examples or scenarios, while taking advantage of the benefits of blockchain to provide a permanent, tamper-resistant record of events, require the client, client entity, computing device, or terminal associated with the client to include or implement software or hardware, or processors / modules, such as a digital wallet implementing functionality for managing Elliptic Curve Digital Signature Algorithm (ECDSA) encryption keys and managing digital assets used in the BSV (Bitcoin Satoshi's Vision) blockchain. Additionally, the client device must be able to implement blockchain transaction construction and have access to BSV libraries. Thus, the client must not only include processes to implement such functionality, but must also ensure that appropriate security measures are implemented for such processes before utilizing the blockchain network to send, receive, and view data and / or digital assets associated with tokens representing smart contracts or real-world asset transactions. Summary of the Invention

[0011] According to a first aspect, there is provided a computer-implemented method comprising the steps of: obtaining a predetermined value; receiving a request, the request including a first delegated authorization token in a chain of delegated authorization tokens; generating further delegated authorization tokens in the chain of delegated authorization tokens, the generation of each further delegated authorization token in the chain of delegated authorization tokens being based on a preceding delegated authorization token in the chain of delegated authorization tokens; determining the validity of the first delegated authorization token based on a comparison of one of the delegated authorization tokens in the chain of delegated authorization tokens to the predetermined value; A method is provided that includes:

[0012] According to a second aspect, there is provided a computer-implemented method for generating a chain of associated delegated authorization tokens, the method comprising: obtaining a first value and a second value; generating a first delegated authorization token of the chain of delegated authorization tokens, the first delegated authorization token based on the first value and the second value; generating at least one further delegated authorization token in the chain of delegated authorization tokens, where the generation of each further delegated authorization token in the chain of delegated authorization tokens is based on a preceding delegated authorization token in the chain of delegated authorization tokens and the first value; A computer-implemented method is provided, comprising:

[0013] According to a third aspect, there is provided a method of validating a token according to the first aspect, wherein a first delegated authorization token was generated by a client according to the second aspect.

[0014] According to a fourth aspect, there is provided a method comprising the steps of: receiving a delegated authorization token generated according to the method of the second aspect; generating a request including the delegated authorization token; sending said request to a server; A method is provided that includes:

[0015] According to a fifth aspect, there is provided a system comprising: A server; Delegate and With the client, Including, A system is provided, wherein the client is configured to generate a chain of delegated authorization tokens and a first value according to the method of the second aspect, send the first value and a last delegated authorization token in the chain of delegated authorization tokens to a server, and send one of the delegated authorization tokens in the chain of delegated authorization tokens to the delegate.

[0016] Certain specific components and embodiments of the disclosed methods will now be described, by way of example only, with reference to the accompanying drawings, in which like reference numbers indicate like functionality. [Brief description of the drawings]

[0017] [Figure 1] 1 illustrates an exemplary system for implementing a blockchain. [Diagram 2] 1 shows an example of a transaction protocol. [Figure 3A] 1 shows an example of an implementation of a client application and its user interface. [Figure 3B] 1 shows an example of an implementation of a client application and its user interface. [Figure 4] FIGURE 1 shows an example of node software running on each blockchain node in the network. [Diagram 5] FIG. 1 is a schematic diagram showing interactions between a platform processor, a database, a blockchain network, clients and delegates. [Figure 6] 1 illustrates a method for generating a delegated authorization token. [Figure 7] It shows how a delegate delivers the information it needs to interact with a service. [Figure 8] It shows how to check the validity of a delegated authorization token. [Figure 9A] 1 illustrates examples and embodiments of validating a delegated authorization token. [Figure 9B]1 illustrates examples and embodiments of validating a delegated authorization token. [Figure 9C] 1 illustrates examples and embodiments of validating a delegated authorization token. [Figure 9D] 1 illustrates examples and embodiments of validating a delegated authorization token. [Figure 10A] 1 shows an example of interaction with an event stream service. [Figure 10B] 1 shows an example of interaction with an event stream service. [Figure 10C] 1 shows an example of interaction with an event stream service. [Figure 10D] 1 shows an example of interaction with an event stream service. [Figure 10E] 1 shows an example of interaction with an event stream service. [Figure 11] FIG. 1 is a schematic diagram illustrating an overview of a platform for multiple services associated with a blockchain, according to one aspect. [Figure 12] FIG. 1 is a schematic diagram illustrating components of a blockchain-related multi-service platform according to an aspect. [Figure 13] FIG. 1 is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure can be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] It is therefore desirable to implement a secure, low-complexity, user-friendly, efficient, and robust technique that allows any client, regardless of computational sophistication, to instantly access and interact with useful applications related to blockchain. This is done in a simple, fast, accurate, reliable, and secure manner that is computationally and functionally undemanding. More specifically, it is desirable that client-approved delegates can also benefit from such a system, preferably in a secure, reliable, and / or revocable manner.

[0019] Such an improved solution has now been devised. The present disclosure addresses the above technical concerns by proposing one or more techniques whereby data may be easily, securely, and / or instantly written to or retrieved from a blockchain by users who have delegated authorization (and / or possess delegated authorization tokens) for writing, reading, or other actions related to the blockchain. Methods, apparatus, and systems that provide an application programming interface (API) for one or more services related to the blockchain (particularly the delegation of these services) that can utilize all the benefits associated with the blockchain and its delegated authorization without the need for clients to implement processes or functions for using the blockchain or for user management.

[0020] According to a first aspect, there is provided a computer-implemented method comprising the steps of: obtaining a predetermined value; receiving a request, the request including a first delegated authorization token in a chain of delegated authorization tokens; generating further delegated authorization tokens in the chain of delegated authorization tokens, the generation of each further delegated authorization token in the chain of delegated authorization tokens being based on a preceding delegated authorization token in the chain of delegated authorization tokens; determining the validity of the first delegated authorization token based on a comparison of one of the delegated authorization tokens in the chain of delegated authorization tokens to the predetermined value; A method is provided that includes:

[0021] The device or devices implementing the method of the first aspect can be considered as validators since they validate the delegated authorization tokens. Advantageously, by simply providing a predefined value to the validator, the validator can validate any delegated authorization token it receives, providing a secure authorization system that requires minimal data sharing, thus resulting in a smaller attack surface. A smaller attack surface means an overall more secure system. As an advantage, the validator does not need to know the number or ID of the delegated user to validate, thus improving the privacy of the client and the delegate.

[0022] Optionally, the generation is based on a hash of a preceding delegated authorization token in a chain of delegated tokens.

[0023] Optionally, the step of generating further delegated authorization tokens in a chain of delegated authorization tokens comprises, for each further delegated authorization token: determining an intermediate pre-image, the intermediate pre-image being based on a preceding delegated authorization token in a chain of delegated authorization tokens; applying a one-way function to the intermediate pre-image, the output of the one-way function being a further delegated authorization token; Preferably, the one-way function is a hash function. Preferably, the intermediate pre-image is further based on a given value.

[0024] Advantageously, using a one-way function to determine the delegated authorization token means that no member of the system can calculate a delegated authorization token higher up the chain from the current delegated authorization token.

[0025] Advantageously, the pre-image is based on a given value (described below as an initial value), such that without the given value no member of the system can calculate other delegated authorization tokens higher up the chain, and the given value is not provided to any other device other than the device executing the method of the first embodiment, thereby enhancing tamper resistance and resilience against malicious attacks.

[0026] Optionally, the generation of the further delegated authorization token is based on a preceding delegated authorization token in the chain of delegated authorization tokens and the given value.

[0027] Optionally, the method further comprises obtaining the given value from the storage device. Optionally, the given value is received from the client.

[0028] Optionally, the generation is based on a concatenation of the given value and the preceding delegated authorization tokens. Preferably, the generation is based on a hash of a concatenation of the given value and the delegated authorization tokens in the chain of delegated authorization tokens.

[0029] Advantageously, the combination of a one-way function and the use of a given value prohibits a user with a delegated authorization token from calculating other delegated authorization tokens in a chain of delegated authorization tokens (thereby providing additional security), while at the same time enabling a validation service to validate delegated authorization tokens without having to submit all valid tokens. By eliminating the need for a client or other device to submit valid tokens to a validator running the method according to this first aspect, the possibility of a third party obtaining a valid token is again reduced, improving the overall security of the system.

[0030] Optionally, the request further includes an index number, and the number of delegated authorization tokens in the chain of delegated authorization tokens is based on the index number. Optionally, the index may represent a distance from the last delegated authorization token generated by the client.

[0031] If an index is used and provided for delegates to include in their requests, a more secure system is provided in that a hostile third party only needs to know two pieces of information, the hash and the index, and both must be correct for the service to process the request.

[0032] Alternatively, no index is used. If an index is not used or provided to the delegate, advantageously the client is unaware of its position in the chain and therefore cannot determine the number of other delegates, improving privacy for all validated clients and users.

[0033] Optionally, the step of determining the validity of the first delegated authorization token is based on a comparison of the last delegated authorization token in the chain of delegated authorization tokens with a predetermined value.

[0034] Optionally, determining the validity of the first delegated authorization token comprises comparing a last delegated authorization token in the chain of delegated authorization tokens with a predetermined value, the last delegated authorization token having the same value.

[0035] Optionally, the request is to send to or read from the blockchain.

[0036] Optionally, sending the data to a blockchain-based data recording service such that a representation of the data included in the request is recorded on the blockchain. Additionally or alternatively, the request is to read a representation of the data from the blockchain-based data recording service. Preferably, the request to read data includes a reference to the data to be read. Preferably, the blockchain-based data recording service is part of a platform service as described herein.

[0037] Advantageously, the blockchain-based data record service provides a way to simplify the use of blockchain as a commodity data ledger. Furthermore, the delegated authorization tokens provide enhanced security to the blockchain-based data record service. Thus, delegated users of the blockchain-based data record service can interact with the blockchain and take advantage of the properties of the blockchain (immutability, decentralization, optional transparency, traceability, etc.) for their data storage needs in a secure manner, but without necessarily requiring direct interaction with the transaction or the blockchain itself.

[0038] Optionally, determining the validity of the request may be further based on a number of previously received requests that constitute the same first delegated authorization token.

[0039] Advantageously, this allows clients to have fine-grained control over the system, limiting the ability of malicious actors to send spam, or, if a malicious third party does obtain a valid delegated authorization token, limiting the damage they can cause, improving the security of the system overall.

[0040] Preferably, the predetermined value is a client generated delegated authorization token.Preferably, the predetermined value is the last delegated authorization token in a chain of client generated delegated authorization tokens.Preferably, the predetermined value is stored in a stored chain of delegated authorization tokens upon receipt.

[0041] Optionally, the method further comprises the step of storing a chain of delegated authorization tokens based on the validity of the first delegated authorization token. Preferably, the method comprises the steps of receiving a further request including a further delegated authorization token; determining the validity of the further delegated authorization token based on whether the further delegated authorization token is present in a chain of stored delegated authorization tokens; processing the further request based on the validity of the further delegated authorization token; Further includes.

[0042] The intermediate hash results are recorded, advantageously reducing the processing time for subsequent validations. If a token has a lower index than one already received (i.e., the final delegated authorization token or H 0 If the byte is received with a hash value close to 0, then there is no need to perform the hash, saving computer time and power.

[0043] Optionally, the predetermined value is the delegated authorization token with the highest index in the stored chain of delegated authorization tokens. Preferably, the step of generating further delegated authorization tokens is performed until a final delegated authorization token is generated.

[0044] Optionally, the method further includes determining a highest index in the stored chain of delegated authorization tokens, generating further delegated authorization tokens based on the received delegated authorization token until a delegated authorization token having an index equal to the highest index is generated, and determining validity of the received delegated authorization token based on a comparison of the final generated delegated authorization token with the stored delegated authorization token having the highest index.

[0045] Optionally, where each delegated authorization token has an index associated with it, and the distance from the last delegated authorization token can be represented in the index, each delegated authorization token is stored with its associated index and preferably can be searched by index. By storing each delegated authorization token by its index, advantageously, searching for the presence of any token is more time and computationally resource efficient, as a search by and / or at an index is quicker and less computationally resource intensive than iterating through the dataset and comparing each value.

[0046] Optionally, the method further comprises the step of providing an indication of the validity of the request; and / or processing the request based on the validity of the delegated authorization token; Preferably, processing refers to one or more of: forwarding the request, discarding the request, allowing the request, blocking the request, allowing access to the blockchain-based storage system, allowing read access to the blockchain-based storage system, allowing write access to the blockchain-based storage system, providing data from the blockchain-based storage system upon request, and / or writing data to the blockchain-based storage system upon request.

[0047] According to a second aspect, there is provided a computer-implemented method for generating a chain of associated delegated authorization tokens, the method comprising: obtaining a first value and a second value; generating a first delegated authorization token of the chain of delegated authorization tokens, the first delegated authorization token based on the first value and the second value; generating at least one further delegated authorization token in the chain of delegated authorization tokens, where the generation of each further delegated authorization token in the chain of delegated authorization tokens is based on a preceding delegated authorization token in the chain of delegated authorization tokens and the first value; A computer-implemented method is provided, comprising:

[0048] The one or more devices performing the method according to the second aspect will typically be clients, which delegate their access to delegated or delegated users.

[0049] Optionally, the step of generating further delegated authorization tokens in a chain of delegated authorization tokens comprises, for each further delegated authorization token, determining an intermediate pre-image, the intermediate pre-image being based on a preceding delegated authorization token in a chain of delegated authorization tokens and a first value; applying a one-way function to the intermediate pre-image, the output of the one-way function being a further delegated authorization token; Preferably, the one-way function is a hash function. Preferably, the intermediate pre-image is further based on a given value.

[0050] The method provides the same or similar advantages relating to security and more as discussed in relation to the first aspect.

[0051] Preferably, the generation is based on a hash of a concatenation of a given value and a delegated authorization token in a chain of delegated authorization tokens.

[0052] Optionally, the method further comprises providing one of the delegated authorization tokens of the chain of delegated authorization tokens to the delegate device. Preferably, the delegate device is further provided with an index of the delegated authorization token, the index indicating where in the chain of delegated authorization tokens the provided delegated authorization token is.

[0053] Optionally, the method further comprises providing the first value and the last delegated authorization token in the chain of delegated authorization tokens to a verifier. Preferably, the verifier is further provided with a number indicating a maximum number of reads or writes per delegate.

[0054] Optionally, the number of delegated authorization tokens in the chain of delegated authorization tokens is based on the index number. Preferably, the number of delegated authorization tokens in the chain of delegated authorization tokens is equal to the number of delegates.

[0055] As described above with respect to the first aspect, optionally, a delegated authorization token is provided to the delegate to enable the delegate to interact (preferably by writing data to or reading data from) the blockchain-based data record service.

[0056] Thus, the same or similar advantages apply by enhancing security when the delegated authorization tokens described above access the blockchain-based data record service. Thus, delegated users of the blockchain-based data record service can interact with the blockchain and take advantage of the properties of the blockchain (immutability, decentralization, optional transparency, traceability, etc.) for their data storage needs in a secure manner, but without necessarily requiring direct interaction with the transaction or the blockchain itself.

[0057] Optionally, the second value is deleted after the first delegated authorization token is generated.

[0058] Advantageously, by removing the second value, security is improved by eliminating the opportunity for a malicious third party to regenerate tokens, since no one can construct the first delegated authorization token and therefore the entire chain.

[0059] Optionally, the first and second values ​​are randomly generated.

[0060] Preferably, the previous delegated authorization token of the first or second aspect represents the delegated authorization token immediately preceding the delegated authorization token being generated, which may be the most recent delegated authorization token generated or obtained.

[0061] According to a third aspect, there is provided a method of validating a token according to the first aspect, wherein a first delegated authorization token was generated by a client according to the second aspect.

[0062] According to a fourth aspect, there is provided a method comprising the steps of: receiving a delegated authorization token generated according to the method of the second aspect; generating a request including the delegated authorization token; sending said request to a server; A method is provided that includes:

[0063] According to a fifth aspect, there is provided a system, comprising: A server; Delegate and With the client, Including, A system is provided in which a client is configured to generate a chain of delegated authorization tokens and a first value in accordance with the method of the second aspect, send the first value and a last delegated authorization token in the chain of delegated authorization tokens to a server, and send one of the delegated authorization tokens in the chain of delegated authorization tokens to a delegate.

[0064] Optionally, the server is configured to receive and process requests from the delegate in accordance with the method of the first aspect.

[0065] According to one or more of the above aspects, optionally, the request is received from the client and / or the delegated user via or using the HTTPS protocol. Additionally or alternatively, the recipient of the request implements the API as a web service. Optionally, the delegated authorization token is configured to provide delegated access to the event stream and / or data writing service. Advantageously, the use of HTTPS and / or API and / or web services provides complementary security features while allowing the recipient of the web request to provide flexible blockchain-based data services. Further advantages of providing delegated access to the blockchain-based data writer or reader include enabling (in a secure manner) more users than just the first client to have access to the blockchain-based data writer or reader service.

[0066] Example System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a number of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore highly coupled to the other blockchain nodes 104.

[0067] Each blockchain node 104 includes a peer computing device with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application specific processors, and / or other devices such as field programmable gate arrays (FPGAs) and application specific integrated circuits (ASICs). Each node also includes a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium. The memory may include one or more memory units using one or more memory media, for example, a magnetic medium such as a hard disk, an electronic medium such as a solid-state drive (SSD), a flash memory or an EEPROM, and / or an optical medium such as an optical disk drive.

[0068] The blockchain 150 includes a chain of blocks 151 of data, each copy of which is maintained at each of multiple nodes 104 in a distributed or blockchain network 160. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from the blockchain 150 as long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context represents a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount that represents the amount of the digital asset as an asset. In this example, it is the user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock and thereby redeem or use). Each input points to the output of a preceding transaction 152, thereby linking the transactions.

[0069] Each block 151 also contains a block pointer 155 that points back to a previously generated block 151 in the chain to define a sequential order to the blocks 151. Each transaction 152 (other than coinbase transactions) contains a pointer to a previous transaction to define an order to the sequence of transactions (Note: a sequence of transactions 152 is allowed to branch). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153 rather than to a preceding transaction.

[0070] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 across the network 106. Each blockchain node 104 is configured to generate blocks 151 and store respective copies of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into a block 151. The ordered set 154 is sometimes referred to as a "mempool." This term is not limited herein to any particular blockchain, protocol, or model. It represents an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated not to accept other transactions that attempt to use the same output.

[0071] For a given current transaction 152j, the input (or each of them) includes a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. A previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to the network 106, but a previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to something that precedes in a logical sequence linked by a pointer, and not necessarily to a time of creation or transmission in the chronological order. Thus, it does not necessarily exclude transactions 152i, 152j from being created or sent out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or predecessor transaction.

[0072] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, the transaction 152 may have multiple outputs to split the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction may have multiple inputs and aggregate amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0073] According to a Bitcoin-like output-based transaction protocol, when an entity 103, such as a user or a machine, wants to act on a new transaction 152j, it sends the new transaction from its computer terminal 102 to a receiver. The entity or receiver eventually sends this transaction to one or more of the blockchain nodes 104 of the network 106 (these are typically servers or data centers today, but in principle other user terminals are also possible). It is not excluded that in some examples the entity 103 acting on the new transaction 152j may send the transaction to one or more of the blockchain nodes 104 instead of to a receiver. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied to each blockchain node 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the case of such output-based transaction protocols, this may include checking that a cryptographic signature or other authentication of entity 103 included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152j that the new transaction assigns, which typically includes at least checking that the cryptographic signature or other authentication in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be at least partially defined by a script included in the output of the previous transaction 152i, or may simply be fixed in the blockchain node protocol, or may be a combination of both.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0074] In the output-based model, the definition of whether a given allocated output (e.g., UTXO) is allocated is whether it has already been validly redeemed by an input of another onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to allocate or redeem has not yet been allocated / redeemed by another transaction. Again, if not valid, the transaction 152j is not propagated or recorded in the blockchain 150 (unless it is flagged as invalid and propagated to change). This prevents double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Again, because the order of transactions is defined, the account balance has a single defined state at a time.

[0075] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process called mining, which is underpinned by a "proof-of-work." Blockchain nodes 104 add new transactions to an ordered set 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. This typically involves looking for a "nonce" value such that when the nonce is concatenated with a representation of the ordered set 154 of transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle, and other types are not excluded. A property of a hash function is that it has an output that is unpredictable with respect to the input. Therefore, this search can only be performed by brute force and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0076] The first blockchain node 104 that solves the puzzle notifies the network 106 and provides the solution as a proof. This solution can be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the output of the hash satisfies the conditions). The first blockchain node 104 propagates the block to the consensus of a threshold of other nodes to accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. The new block 151n is also assigned a block pointer 155, pointing to the previously created block 151n-1 in the chain. The significant amount of effort required to generate the proof-of-work solution, for example in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as a double spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0077] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be solving the puzzle based on different snapshots of the ordered set of transactions 154 that have not yet been published, depending on when they started looking for a solution or the order in which transactions were received. Whoever solves the puzzle first defines the transactions 152 that will be included in the next new block 151n, in the order in which the current set of unpublished transactions 154 is updated. The blockchain nodes 104 then continue to compete to produce blocks from the newly defined current ordered set of unpublished transactions 154. There is also a protocol to resolve possible "forks", which is when two blockchain nodes 104 solve the puzzle within a very short time of each other and inconsistent views of the blockchain propagate between the nodes 104. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both branches.

[0078] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate an approved amount of the digital asset in a new special type of transaction that distributes a predetermined amount of the digital asset (different from an agent-to-agent or user-to-user transaction that transfers an amount of the digital asset from one agent or user to another). This special type of transaction is usually called a "coinbase transaction" but may also be called an "initiation transaction". It forms the first transaction of a standard new block 151n. The proof-of-work signals that the node that constructed the new block intends to follow the protocol rules so that this special transaction can be redeemed later. Blockchain protocol rules may require this special transaction to mature, for example 100 blocks, before it can be redeemed. Regular (non-generating) transactions 152 often specify an additional transaction fee in one of their outputs to further reward the blockchain node 104 that generated the block 151n in which the transaction was published. This fee is usually called a "transaction fee" and is described below.

[0079] Due to the resources involved in validating and publishing transactions, typically at least each of the blockchain nodes 104 takes the form of a server including one or more physical server units, or an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0080] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform one or more of its roles and to process transactions 152 in accordance with the blockchain node protocol. It will be appreciated that any operation pertaining to a blockchain node 104 may be performed by software executing on the processing unit of each computing device. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or protocol layer, or any combination thereof.

[0081] Also connected to the network 101 are computing devices 102 of each of a number of parties 103 that act as consumer users. These users may interact with the blockchain network but do not participate in validating, composing, or propagating transactions and blocks. Some of these users or agents may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0082] Some or all of the parties 103 may be coupled as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of the system that includes the blockchain network. However, these users are not blockchain nodes 104, as they do not perform the required role of a blockchain node. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby coupling (i.e., communicating) with the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob can be interchangeably referred to as the "first party" and the "second party," respectively.

[0083] The computing equipment 102 of each party 103 comprises a respective processing device comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium or media. This memory may include one or more memory units using one or more memory media, e.g., a magnetic medium such as a hard disk, an electronic medium such as a SSD, a flash memory or an EEPROM, and / or an optical medium such as an optical disk drive. The memory on the computing equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 arranged to operate on the processing device. It will be understood that any action attributed to a party 103 given herein may be performed using software executed on the processing device of each computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing device 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0084] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer readable storage media, for example downloaded from a server, or on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk, for example a CD or DVD ROM, or a removable optical drive.

[0085] The client application 105 has at least a "wallet" functionality, which has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign) and send transactions 152 to be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets it currently owns. In an output-based system, this second function involves reconciling the amount defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0086] NOTE: Although various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may be implemented in two or more different suites of applications, interfacing, for example, via an API, or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. The following is described in terms of a client application 105, but it will be understood that this is not limiting.

[0087] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in an embodiment, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust of transactions in part through its public visibility). The wallet function on each computing device 102 is configured to form and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate the transactions 152 according to the blockchain node protocol and to forward the transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol implements a given transaction model with a given node protocol. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used for all nodes 104 in the network 106.

[0088] When a given party 103, for example Alice, wants to send a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions to be "valid", examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of script and node protocol.

[0089] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the blockchain ordered set 154 maintained by that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, it will soon be propagated throughout the network 106.

[0090] Once placed in the ordered set of transactions 154 maintained at a given blockchain node 104, the blockchain nodes 104 start competing to solve a proof-of-work puzzle for the latest version of their respective ordered sets of transactions, including the new transaction 152 (note that other blockchain nodes 104 will try to solve the puzzle based on different ordered sets of transactions 154, but whoever is first will define the ordered set of transactions included in the latest block 151). Eventually, the blockchain node 104 will solve the puzzle for the part of the ordered set 154 that includes Alice's transaction 152j. Once the proof-of-work has been done for the ordered set 154 that includes the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150 in an immutable way. Since each transaction 152 includes a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0091] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore may have conflicting views of which instances are "valid" before one instance is published into a new block 151, at which point all blockchain nodes 104 agree that only the published instance is the valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one that has not yet been published in a block 151).

[0092] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol. In the account-based case, each transaction transfers by referencing an absolute account balance, rather than defining the amount to be transferred by referencing back to the UTXO of a previous transaction in the past sequence of transactions. The current state of every account is stored and constantly updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the successive transaction records (so-called "positions") of the accounts. This value is signed by the senders as part of their cryptographic signatures and hashed as part of the transaction reference calculation. In addition, an optional data field can also sign the transaction. This data field may point back to a previous transaction, for example if a previous transaction ID is included in the data field.

[0093] <UTXOベースのモデル> FIG. 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible implementations. It is noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0094] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies the amount of the digital asset, which represents a set number of tokens on the distributed ledger. Among other information, the UTXO may also include a transaction ID for the transaction from which it originated. The transaction data structure may also include a header 201, which may include an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the unprocessed transaction 152 sent to the node 104.

[0095] For example, suppose Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset in question to Bob 103b. In Figure 2, Alice’s new transaction 152j begins with “Tx 1 " in the sequence. It takes the amount of digital assets locked in Alice and transfers at least a portion of it to Bob in the output 203 of the preceding transaction 152i in the sequence. The preceding transaction 152i is labeled "Tx 0 " Tx 0 and Tx 1 are just arbitrary labels. They do not necessarily refer to Tx 0 is the first transaction on the blockchain 151, or Tx 1 This does not mean that Tx is the next transaction in the pool 154. 1can point to any preceding (i.e. ancestor) transaction that still has an unspent output 203 locked to Alice.

[0096] Preceding transaction Tx 0 Alice creates her new transaction Tx 1 , or at least when she sends it to the network 106, it may already be validated and included in a block 151 of the blockchain 150. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be generated and sent to the network 106, or Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "following" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified in the transaction (such as which transaction points to which other transaction). They may equally be replaced by "preceding" and "inheriting" or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily mean the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or node behavior.

[0097] Preceding transaction Tx 0One of the one or more outputs 203 of the 0 Each UTXO contains a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines the unlocking conditions as follows: the unlocking script in the input of the subsequent transaction contains a cryptographic signature of the party to whom the preceding transaction was locked.

[0098] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies the information needed to consume a transaction output 203, e.g., the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the lock script. For example, it may include Bob's signature. An unlock script appears in the transaction's inputs 202.

[0099] In the illustrated example, Tx 0 Output 203 UTXO 0 The lock script [ChecksigP A ], which is a UTXO 0 In order for the UTXO to be redeemed (strictly speaking, 0 (For a subsequent transaction that attempts to redeem the token to be valid), Alice’s signature SigP A[Checksig P A ] is the public key P from Alice's public-private key pair. A Contains a representation (i.e. a hash) of Tx 1 Input 202 of Tx 1 A pointer to (e.g., its transaction ID, in the embodiment, transaction Tx 0 The TxID, which is a hash of the entire 0 Tx 1 Input 202 of Tx 0 To distinguish it among any other possible outputs of Tx 0 UTXOs in 0 The input 202 of Tx1 further includes an unlock script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a given portion of data (sometimes called a "message" in cryptography). <sigpa>The data (or "message") that Alice needs to sign in order to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0100] New transaction Tx 1 When the arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenation of the two scripts.

number

[0101] The details of public-private cryptographic authentication will be well known to those skilled in the art. Essentially, if Alice signs a message with her private key, then another entity, such as node 104, can authenticate that the message must have been signed by Alice, given Alice's public key and the message in plaintext. Signatures typically allow the holder of the public key to authenticate the signature by hashing the message, signing the hash, and tagging this with the message as the signature. Thus, in embodiments, references to signing a particular piece of data or portion of a transaction, etc., may mean signing a hash of the piece of data or portion of the transaction.

[0102] Tx 1 The unlock script in 0 If one or more conditions specified in the lock script of are met (in the example shown, Alice's signature is Tx 1 If the Tx 1 This means that the blockchain node 104 considers Tx 1 The blockchain node 104 adds the transaction Tx 1 to one or more other blockchain nodes 104 in the network 106, which causes it to be broadcast throughout the network 106. 1 Once validated and included in the blockchain 150, this is called Tx 0 UTXO from 0 is defined as the consumed Tx 1 Note that Tx is only valid when using unspent transaction outputs 203. If you try to consume an output that has already been consumed by another transaction 152, then Tx 1 is invalid even if all other conditions are met. Therefore, the blockchain node 104 cannot 0 has already been spent (already forms a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0103] If the total amount specified in all of the outputs 203 of a given transaction 152 is greater than the total amount pointed to by all of its inputs 202, this is another basis for invalidity in most transaction models. Thus, such a transaction is not propagated and is not included in block 151.

[0104] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave" some of the amount defined in the UTXO while another amount is spent. However, amounts from a UTXO can be split across multiple outputs of subsequent transactions. For example, Tx 0 UTXO 0 The quantity defined by Tx 1 Therefore, if Alice sends UTXO to Bob, 0 If she does not want to give the entire amount defined by Tx 1 In the second output of the transaction, the user can give themselves change or pay another party.

[0105] In particular, Alice would normally also need to include a fee for the Bitcoin node 104 that publishes her transaction. If Alice did not include the fee for the miner, Tx 0 will likely be rejected by the miner's blockchain node 104, and thus, although technically valid, it will still not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept the transaction 152 if they do not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount indicated by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, a UTXO 0 A pointer to Tx 1 is the only input to Tx 1 is one output UTXO 1 Suppose you only have UTXO. 0 The amount of digital assets specified in UTXO 1 If the difference is greater than the amount specified in UTXO 1 However, nothing in this specification necessarily precludes that a transaction fee may be explicitly specified in a unique one of the UTXOs 203 of a transaction 152, alternatively or additionally.

[0106] Alice and Bob's digital assets consist of the UTXOs that were locked to them in any transaction 152 in the blockchain 150. Thus, typically, the assets of a given party 103 are distributed across the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function in the client application 105 to compile the values ​​of all the various UTXOs that are locked to each party and that have not yet been used in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0107] Note that the scripting code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to express a particular function. "OP_...." represents a particular opcode in the scripting language. As an example, OP_RETURN, when preceded by OP_FALSE at the beginning of the locking script, is an opcode in the scripting language to generate an unspent output of the transaction that can store data within the transaction, thereby immutably recording the data to the blockchain 150. For example, the data can include a document that is desired to be stored in the blockchain.

[0108] Typically, the input to a transaction is a public key P A In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs, and all or some of the transaction outputs. The specific parts of the outputs to sign depend on the SIGHASH flag, which is a four-byte code typically included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0109] A lock script is sometimes referred to as a "scriptPubKey" to indicate that each transaction typically includes the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig" to indicate that it typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions under which a UTXO is redeemed include authenticating a signature. More generally, the scripting language may be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" are preferred.

[0110] As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 120b may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the solicitation of either party or a third party). The side channel 301 allows for the exchange of data separately from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob without being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction 152 to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a "transaction template." The transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively or additionally, the side channel 301 may be used to exchange any other transaction-related data, such as keys, amounts or terms to be negotiated, data content, etc.

[0111] The side channel 301 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a local area network, such as a mobile cellular network, or a local wireless network, or a direct wired or wireless link between Alice and Bob's devices 102a, 102b. In general, the side channel 301 referred to anywhere in this specification may include any one or more links over one or more networking technologies or communication media for exchanging data "off-chain", i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, it is noted that when Alice and Bob are said to exchange certain information or pieces of data, etc., over the side channel 301, this does not necessarily mean that all of these pieces of data need to be transmitted over exactly the same links or the same type of network.

[0112] <Client software> 3A illustrates an exemplary implementation of a client application 105 for implementing an embodiment of the disclosed scheme. The client application 105 includes a transaction engine 351 and a user interface (UI) layer 352. The transaction engine 351 is configured to perform the underlying transaction-related functions of the client 105, such as forming transactions 152, receiving and / or sending transactions and / or other data via side channels 301, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106, as described in more detail in accordance with the schemes described above. According to an embodiment disclosed herein, the transaction engine 351 of each client 105 includes functionality 353.

[0113] The UI layer 352 is configured to render a user interface via user input / output (I / O) means of each user computing device 102, including outputting information to each user 103 by user output means of the device 102 and receiving input from each user 103 by user input means of the device 102. For example, the user output means may include one or more display screens (touch or non-touch screen) to provide visual output, one or more speakers to provide audio output, and / or one or more haptic output devices to provide haptic output, etc. The user input means may include, for example, one or more touch screen input arrays (same or different as those used for the output means), one or more cursor-based devices such as a mouse, trackpad or trackball, one or more microphones and voice recognition algorithms for receiving voice or voice input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or one or more mechanical buttons, switches or joysticks, etc.

[0114] Note: Although various functions herein may be described as being integrated in the same client application 105, this is not necessarily limiting and may instead be implemented in two or more separate applications, e.g. one plugging into the other or interfacing via an API (Application Programming Interface). For example, the functionality of the transaction engine 351 may be implemented in a separate application from the UI layer 352, or functionality of a given module, and the transaction engine 351 may be split between more than one application. Also, it does not exclude that some or all of the described functionality is implemented, for example, in the operating system layer. When reference is made elsewhere in this specification to a single or given application 105, etc., it is understood that this is merely by way of example and, more generally, that the described functionality may be implemented in any form of software.

[0115] 3B provides a simulated representation of an example user interface (UI) 360 that may be rendered by the UI layer 352 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by any other party's client 105b, Bob's device 102b, or any other party's device.

[0116] 3B illustrates the UI 360 from Alice's perspective. The UI 360 may include one or more UI elements 362, 362, 363 that are rendered as separate UI elements via user output means.

[0117] For example, the UI elements may include one or more user selectable elements 362, such as, for example, different buttons on a screen or different options in a menu. The user input means is configured to allow the user 103 (in this case Alice 103a) to select or manipulate one of the options by clicking or touching the UI elements on the screen or by speaking the name of the desired option (Note: "manual" as used herein simply means the opposite of automatic and is not necessarily limited to the use of hands).

[0118] Alternatively or additionally, the UI elements may include one or more data entry fields 362 through which a user can enter data. These data entry fields may be rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or a touch screen. Alternatively, data may be received verbally, e.g., based on speech recognition.

[0119] Alternatively or additionally, the UI elements may include one or more information elements 363 that are output to output information to the user, which may for example be drawn on a screen or rendered audibly.

[0120] For example, this / these may be rendered on the screen or audibly. The functionality of these UI elements will be discussed in more detail shortly. It is also understood that the UI 360 shown in FIG. 3 is merely a schematic mockup and may in fact include one or more additional UI elements, which are not shown for simplicity.

[0121] <Node software> FIG. 4 illustrates an example of node software 450 that may be executed by each blockchain node 104 of the network 106 in the example UTXO or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may execute node software including, but not limited to, all three of the following: an agreement module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 351 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Transaction 152j (Tx j ) is received, and another preceding transaction 152i (Tx m-1 ), the protocol engine 451 executes Tx j The protocol engine 451 then identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and search for Tx i may be published on the blockchain 150. In this case, the protocol engine can obtain Txi from a copy of block 151 of the blockchain 150 stored in the node 104. i It is possible that Tx has not yet been published on the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 held by the node 154. i In either case, the script engine 451 identifies the lock script in the referenced output of Txi and passes it to the script engine 452.

[0122] The script engine 452 therefore i Lock script and Tx j It has an unlock script from the corresponding input. For example, Tx 0 and Tx 1 is shown in Figure 2, but the same can be applied to any pair of transactions. The script engine 452 executes two scripts together as described above, which includes putting data on the stack 453 and retrieving data according to the script language (e.g., Script) based on the stack being used.

[0123] By executing the scripts together, the script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., whether the unlock script "unlocks" the output in which the lock script is included. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0124] In the output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, and Tx j the total amount of Digital Assets specified in the Outputs of does not exceed the total amount pointed to by its Inputs; i The output pointed to by the transaction Tx has not yet been consumed by another valid transaction, etc. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and if all of them are true, the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j 455C and / or the propagation module 455P to perform their respective blockchain-related functions as Tx j , which is to control the execution of Tx j and a consensus module 455C that adds Tx j Optionally, in an embodiment, the application level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only conditional on both that the transaction has been declared invalid and that sufficient transaction fees remain.

[0125] It is noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can represent any state that indicates a successful or positive outcome, and "false" can represent any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (where the overall outcome is considered to convey true if both individual outcomes are true).

[0126] Other variations or uses of the disclosed technology may become apparent to those skilled in the art upon review of this specification, and the scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0127] For example, some embodiments described above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it is understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain in any way. More generally, references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 above may be replaced with the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the above-described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104.

[0128] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the above-mentioned functions of generating, publishing, propagating and storing blocks 151 in the blockchain 150. It is not excluded that there are other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks, but may not generate and publish blocks (recall that these entities are not considered as preferred Bitcoin network 106 nodes).

[0129] In non-preferred embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of generating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, a "node" may be used to represent a network entity that is configured to generate and publish blocks 151, but does not store and / or propagate the blocks 151 to other nodes.

[0130] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element." Such an entity / element may be configured to perform some or all of the roles of generating, publishing, propagating, and storing blocks. The functionality of such a network entity / element may be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0131] Delegated Authorization FIG. 5 relates to a system 500 according to a first aspect of the disclosure for provision and use of delegated authorization tokens, preferably part of a platform processor 504 providing multiple services related to the blockchain 101. The platform processor 504 is optionally a platform described in more detail below with respect to FIG. 11 and FIG. 13. However, the delegated authorization method and system as described herein can be used in other services, including services not associated with the blockchain 101. The platform processor 504 is configured to communicate and / or otherwise interact with the blockchain 101, the client 502, and / or the delegated user 506. For ease of explanation, the platform processor 504 is described herein as a monolithic server. It is understood that when a "client," "user," or similar term is used, this often refers to a device owned by the client or user. Those skilled in the art will understand that it can be implemented as a single server, a mainframe, a collection of servers, a microservice, a collection of microservices, a cloud service, any combination of the foregoing and / or one or more other computing platforms. The term "service(s)" as used herein should be understood as a general term for a collection of computing functions or operations, and is not strictly specific to one single application running on one server. This is a non-exhaustive list of examples and options. A service may be one application or multiple applications. A service may run on one hardware server / device or multiple. For example, in the following example, a database is provided that is separate from the service, but this could alternatively be configured as part of the same service, equivalently.

[0132] The system 500 includes a client 502, which is a user with authority over a service on a platform 504. The client's authority allows the client 502 to provide delegated authority to other users 506 (hereafter referred to as delegated users or delegates). The client 502 can be considered the "owner" of the service and preferably triggers the creation of the service on the platform 504. The client 502 wishes to delegate authorization so that other users can access the service. Preferably, the delegated authorization gives the delegated user 506 permission to interact 512 with the platform 504 running the service. More preferably, the interaction is to read, write, or both read and write to the service. Even more preferably, the service described is an event stream, which is described in more detail below with reference to Figures 10A-C, 11 and 12. Those skilled in the art will appreciate that the methods and systems relating to delegated authorization of services herein can also be used with other services.

[0133] Optionally, there are other interactions that the delegated user may have with the service. The types of interactions allowed vary from service to service. For example, if the service offers financial transactions, the delegated user may be delegated to generate or sign transactions. Preferably, the delegated authorization does not grant the ability to add more delegated users or to generate delegated authorization tokens.

[0134] As will be described in more detail below with reference to FIGS. 6 and 7, according to one embodiment of this aspect, the client 502 generates and provides 508 a delegated authorization token to the delegated user 506.

[0135] As described in more detail below with reference to Figures 8 and 9A-9C, according to one embodiment of this aspect, the delegated user 506 is configured to generate a request including these tokens, which is sent 512 to a service executing on the platform 504. Upon receiving the request, the service validates the request and processes the request depending on the validity of the delegated authorization token.

[0136] Generating a Delegated Authorization Token 6 illustrates an example of a method 600 according to an embodiment of the first aspect. The method 600 illustrates the generation of a delegated authorization token (also described herein as a delegatedAuth token) for use when a client 502 wishes to authorize multiple delegated users to interact with a delegated service. Preferably, the method is performed entirely by the client without interaction with other entities in the system 500. Optionally, the delegated authorization token has an associated index that may be provided along with the delegated authorization token.

[0137] The delegated authorization tokens are generated to form a set of related tokens. Preferably, the set is a "chain" of tokens, since each delegated authorization token (except the first delegated authorization token) builds on the preceding delegated authorization token in the chain, as described below.

[0138] First, two random numbers are generated (602): an initial value (hereafter denoted as IV) and a seed value (hereafter denoted as seed).

[0139] Optionally, the number of delegated authorization tokens required is determined 604. This number is typically equal to (and possibly greater than) the number of users for which the client wishes to provide delegated authorization.

[0140] A first delegated authorization token is then generated (606) based on these two values. Preferably, the first delegated authorization token is based on a concatenation of the initial value and the seed value. More preferably, the first delegated authorization token is based on a one-way function that uses the initial value and the seed value as inputs. Even more preferably, the first delegated authorization token is based on a hash of the concatenation of the initial value and the seed value.

[0141] Optionally, the seed value is securely deleted so that the entity cannot use it again.

[0142] Further delegated authorization tokens are generated (608). Each generated delegated authorization token is based on at least a previously generated delegated authorization token. Preferably, each further delegated authorization token is generated based on an initial value and a previously generated delegated authorization token. The previously generated authorization token preferably represents a delegated authorization token generated immediately before the currently generated authorization token, and may also be described as a preceding delegated authorization token. More preferably, each further delegated authorization token is generated based on a combination of the initial value and the previously generated delegated authorization token. More preferably, each further delegated authorization token is generated based on a one-way function that takes as input the combination of the initial value and the previously generated delegated authorization token. Even more preferably, each further delegated authorization token is generated based on a hash of the combination of the initial value and the previously generated delegated authorization token. Even more preferably, the combination is the previously generated authorization token concatenated with the initial value.

[0143] The combination of the initial value and the previously generated delegated authorization token can be described as a pre-image.

[0144] Instead of prepending an initial value to the previous delegated authorization token (concatenation as above), no initial value is used at all and the previous delegated authorization token is based solely on the previous delegated authorization token that was generated. To generate the next delegated authorization token in this manner, a one-way function is used on the previous delegated authorization token, and the output of that function becomes the next delegated authorization token. Preferably, the one-way function is a hash function.

[0145] The delegated authorization token is preferably in the form of a binary string and / or a byte string. The length of the binary string depends on the one-way function used. If the one-way function used is SHA256, the length of the delegated authorization token will be 256 bits (or 32 bytes). Optionally, this binary string can be represented and / or encoded as a hex string, a base64 string, or any other suitable encoding scheme.

[0146] This generation step 608 is stopped when the token generating client 502 determines it has enough tokens and / or when the number of tokens generated is equal to or greater than the number determined in step 604.

[0147] Preferably, the method 600 described above is used to generate each type of interaction between a delegated user and a service. Preferably, one chain of delegated authorization tokens is generated for read access to the service and another chain of delegated authorization tokens is generated for write access to the service. Each user for whom the client wishes to provide read authorization receives one read delegated authorization token and each user for whom the client wishes to provide write authorization receives one write delegated authorization token. The number of read and write delegated authorization tokens does not have to be the same.

[0148] Optionally, a delegated user can receive multiple tokens, which allows the delegated user to perform more writes in limited interaction cases, such as the write described here.

[0149] The steps (606, 608) involved in generating a chain of delegation tokens may also be illustrated in the following table. In this table, "R" is used to represent tokens and data associated with "read" permissions, and "W" is used to represent tokens and data associated with "write" permissions. The "H" function is a one-way function, preferably a hash function, and the "||" symbol preferably represents the concatenation of each edge of the symbol. Four tokens of each type are generated only as an example. Different numbers may be used for each type of token. [Table 1]

[0150] As can be seen from the table above, the last delegated authorization token in the chain of delegated authorization tokens is the H0 hash.

[0151] Preferably, for write delegated authorization tokens, there is also a maximum number of writes per token, which can be extended to other interactions if the client wishes to limit the number of interactions each token can perform.

[0152] An example of the method 600 described above is described with reference to FIG. 10D. An example system 1070 is shown in which a client receives a random initial value IV and seed and generates a chain of delegated authorization tokens. An event stream "create" message is then sent to an Event Stream service, where the event stream create message includes the final delegated authorization token (H0) and the initial value. The event stream service creates an event stream, associates the final token and the initial value with the created stream, and responds to the create message with an "esid" (event stream identifier). The esid is used for future interactions by the client and / or the delegated user.

[0153] The create request is preferably a JSON object, containing the following:

number

[0154] According to a further embodiment, FIG. 7 illustrates a method 700 for delivering information necessary to provide delegated authorization to a user.

[0155] Once the delegated authorization tokens have been generated (702), optionally according to the embodiment described in Figure 6, the client provides the tokens to each delegated user (704), as well as any data the platform or service needs to determine the validity of any delegated tokens (706). Preferably, the data the platform or service needs to determine the validity of the tokens includes the last delegated authorization token in the chain of delegated authorization tokens (WH0 and / or RH0, as in the example above) and an initial value (WIV and / or RIV, as in the example above).

[0156] Delegated authorization tokens inherently have an ordering to them and can therefore be indexed. Preferably, when providing 704 the tokens to each delegated user, an index of the tokens is also provided.

[0157] Although steps 704, 706 relating to providing data to the delegated user and the platform are presented sequentially, they may be performed in any order or simultaneously.

[0158] Since each chain of tokens is generated for each interaction (eg, read or write), method 700 is performed for each type of interaction that the client wishes to delegate.

[0159] The delegate may be provided with the delegated authorization token before the service is set up, or on-demand after the service is running.

[0160] At any time, the client 502 can revoke any number or all of these tokens. This is done by the client generating a request that includes data indicating the service for which the token is to be revoked (meaning, in the example below, identifying a particular event stream), the type of interaction for which the token is to be revoked (e.g., read or write), the token to be revoked and / or the index of the token to be revoked. Preferably, both the token to be revoked and the index are used, optionally only one is used. Preferably, all tokens start out as valid / revoked and the client 502 must revoke them. An example of revocation is shown in Figures 10C and 10E.

[0161] The ability to revoke individual tokens provides the client 502 with greater flexibility and control in managing access to services. Furthermore, because the delegated user 506 does not know or can compute other tokens, when a client wants to revoke access, it does not need to notify or update other delegated users that are still valid / not yet revoked, thereby saving computational resources and time.

[0162] Using Delegated Grant Tokens Referring to FIG. 8, a method 800 according to a further embodiment is shown, in which a process for receiving (804), validating (806), and processing (808) a request to interact with a service is described. In this embodiment, for ease of explanation, the method 800 is described as being performed by a service executing on a platform. In another embodiment, the platform is now executing a further process configured to perform the method 800. This process may be described as an "authorization service" or "access control service", and optionally executes on the same platform 504 as the service being interacted with. As a further alternative, the authorization service acts as a filter before the service receives the request.

[0163] Prior to the step of receiving a request from a delegated user, the service receives (802) appropriate validation data from the client that generated the delegated authorization token. The validation data includes at least the last hash (or the last delegated authorization token) in the chain of delegated authorization tokens. This last token is also described as the last delegated authorization token received from the client. As used herein, this last hash is referred to as H0,R H0 , or W H0 Preferably, the validation data also includes an initial value that is used in the process of generating a chain of delegated authorization tokens, as described above with reference to FIG.

[0164] The service may receive this data at any time prior to validating a request from a delegated user 802. Preferably, validation information is provided to the service when a new event stream is created.

[0165] After some time, the service receives requests from the delegated user to use the service and / or the event stream (804). These requests include the delegated authorization token. If a request does not include the delegated authorization token or is not from the client, it is not considered valid. Requests from clients preferably do not require the delegated authorization token and are validated or authenticated using another system.

[0166] The service determines 806 the validity of the request based on the delegated authorization token and the validation data. This step is described in more detail with respect to Figures 9A-D. The validation may include regenerating a subset of the chain of delegated authorization tokens from the received delegated authorization token to the last delegated authorization token. If the regenerated last delegated authorization token is the same as the last delegated authorization token received by the client, then the received delegated authorization token is valid.

[0167] Optionally, the service further determines the validity of the request based on whether the delegated authorization token has been revoked: if the token and / or index for the interaction with this service has been revoked, the request is found to be invalid.

[0168] Finally, the request is processed depending on the validity determined in step 806. If the token is not valid, the request is not processed.

[0169] If the method 800 is performed by an authorization service, processing step 806 includes the authorization service providing an indication to the service and / or platform regarding the result of the validation. Alternatively, if the authorization service acts as a filter, processing step 806 includes dropping the request and not forwarding the request to the service if the token is invalid. If the token is valid, it passes the request to the service, optionally with additional information indicating that the request is valid.

[0170] The methods shown in Figures 9A-D illustrate various examples of how a service can validate a received delegated authorization token. A first method 900 illustrates when a first request is received. The chain of delegated authorization tokens is regenerated starting from the received delegated authorization token. A second method illustrates when a further request is received that is higher in the chain than the previously received delegated authorization token and has an index that the service did not calculate. A third method illustrates when another further request is received that is lower in the chain and has an index that the service has already calculated.

[0171] When "top" and "bottom" are used in reference to the chain, this refers to the index provided. "Top" refers to having a higher index number and being further away from the final delegated authorization token, and "bottom" the other way around. Index 0 is the lowest index and indexes the final / last generated delegated authorization token in the chain. The delegated authorization token with index 0 is the one provided by the client for validation purposes as described above.

[0172] Preferably, the validation method uses the same method that the client uses to build the chain of delegated authorization tokens. Methods 900, 920, 940 of the first, second and third example scenarios show that the hash chain (or a subset thereof) is reconstructed using substantially the same method that it was generated.

[0173] 9A illustrates a first validation method 900 in which a token is initially received by a service (902). The first request includes the initially received delegated authorization token. Preferably, the request also includes an index.

[0174] Because this is the first delegated authorization token received, the service has not generated any other parts of the chain of delegated authorization tokens.

[0175] Then, starting from the first received delegated authorization token, a chain of delegated authorization tokens is regenerated. The chain is generated using the same method as the chain was generated as described above. Thus, the chain is preferably generated by concatenating an initial value with the first received delegated authorization token and hashing it to receive the next delegated authorization token in the chain. This step is repeated many times. If an index is present in the request, the number of delegated authorization tokens in the generated chain is based on the index. The index can be considered as the distance from the last delegated authorization token in the chain of delegated authorization tokens. Further delegated authorization tokens are generated until the last delegated authorization token is generated. For example, if the index in the request is 3, three more hashes are generated (H2', H1', ​​H0') as shown below. This notation is used to indicate that this is a chain based on the received delegated authorization tokens and may not be the same as the chain generated by the client. Here, "R" and "W" are not used because the process is the same for read ("R"), write ("W"), or other interactions.

number

[0176] Obtaining H0' can also be done with a single formula:

number

[0177] Preferably, the received delegated authorization token (H3') and each of the intermediate hashes H2' and H1' in the chain (which are also delegated authorization tokens and may be used by future delegates) are stored for future use if the tokens are found to be valid. The use of these intermediate tokens is further described in connection with the following exemplary method 940 shown in FIG. 9C. More preferably, the received and generated delegated authorization tokens are stored in a data storage mechanism (array, database, hard drive, or other similar system or module) so that they can be indexed according to their position in the chain. Advantageously, associating the delegated authorization tokens with their indexes (also called indexing) facilitates retrieval, such as in the situation described with reference to FIG. 9C. If the tokens are found to be invalid, the entire constructed chain is not stored and / or deleted.

[0178] The validity of the initially received token is determined based on a comparison of the final hash H0' generated in the first step 802 of the validation method 800 described above with the final hash received from the client as part of the validation data. If H0 and H0' are equal, the delegated authorization token is valid.

[0179] Alternatively, if no index is used, the method is modified so that delegated authorization tokens are continually generated and each generated token is compared to H0. The process stops when the comparison is successful or the maximum number of tokens is reached. If the maximum number is reached and no comparison is successful, the first received delegated authorization token is known to be invalid.

[0180] 9B, a method 920 is shown in which a further request is received that also includes a delegated authorization token and an index 922. For purposes of illustration, in this example method, the delegated authorization token and / or index have not been previously known by the service and are not present in a pre-computed chain of delegated authorization tokens.

[0181] Once received, the service determines (924) whether the delegated authorization token is already present in a previously generated chain. Preferably, an indexed data storage mechanism is used, and a search is performed based on the index. If the data storage mechanism is an array, this means accessing the data at the entry in the index. In this example, the delegated authorization token is not present in the index.

[0182] Instead of indexing the delegated authorization token using an index, the method can also loop through all stored delegated authorization tokens and check if they exist.

[0183] Since the token is not yet present in the currently stored chain, a further chain of delegated authorization tokens needs to be generated to ensure that it is present in the chain generated by the client. The chain is constructed in the same / similar manner as before (which is preferably by concatenating an initial value with further received delegated authorization tokens and repeatedly passing it through a one-way function). Preferably, rather than repeating all these steps until the last delegated authorization token in the chain (H0), these steps are repeated until the first generated or received delegated authorization token in the chain of delegated authorization tokens is encountered. Since the token generation method is deterministic, if the starting data is the same, the same chain will be generated. This is true not only for the first delegated authorization token, but also when starting from any point in the chain.

[0184] Because a one-way function is used, in building the chain, the service (or any other device in the system, including other delegates) cannot compute a delegated authorization token higher up the chain from any given point, even if an initial value is prepended to the token. This is a property of one-way functions: they have an output but cannot compute an input. Thus, the chain must always be built in a forward direction from any received delegated authorization token.

[0185] For example, if the index of the received token is 5, and delegated authorization tokens with indexes 3, 2, 1, 0 (H3, H2, H1, H0) are already stored in the data storage mechanism, then to determine whether a further received delegated authorization token is valid, one need only perform the following calculation:

number

[0186] If H3' is equal to the already stored H3, then the rest of the chain will be the same, the further received delegated authorization token will be valid, and the remaining concatenation and one-way function steps can be skipped. If H3' is not equal to H3, then the rest of the chain will also be different (and therefore the computations can also be skipped) and the delegated authorization token will be invalid.

[0187] Thus, in this example, the validity of the received delegated authorization token is determined based on a comparison of one of the currently generated delegated authorization tokens (preferably the last of the currently generated delegated authorization tokens) with the stored and / or previously generated delegated authorization tokens, preferably the highest indexed token of the stored and / or previously generated delegated authorization tokens.

[0188] The stored delegated authorization token with the highest index is likely to be a previously received delegated authorization token that was found to be valid. Thus, the method further includes determining the highest index of any previously received delegated authorization token, generating further delegated authorization tokens based on the received delegated authorization token until a delegated authorization token is generated having an index equal to the index of the previously received valid delegated authorization token, and determining the validity of the received delegated authorization token based on a comparison of the last generated delegated authorization token with the previously received delegated authorization token. If the received token is valid, it becomes the token with the highest index of any previously received token.

[0189] 9C, an exemplary method is shown in which another further request is received including another further delegated authorization token and an index (942). In this example, the token is part of a stored chain of already delegated authorization tokens. The token may already be stored because it has been used before or a valid token with a higher index was received prior to receiving this token.

[0190] If there is another further delegated authorization token received and its index (924), it is determined that there is a previously generated and stored delegated authorization token associated with the index (in this example) (944). Preferably, this determination involves querying a data storage mechanism for a delegated authorization token at the given index. A comparison is made between the another further received delegated authorization token and the stored delegated authorization token associated with the index. The validity of the token is based on this comparison. Preferably, if the tokens are the same, the received token is valid. If the tokens are not the same, the received token is invalid.

[0191] Preferably, the first, second and third methods 900, 920, 940 are used together to validate a delegated authorization token. Advantageously, these methods 900, 920, 940 provide a cache so that the chain of delegated authorization tokens does not have to be calculated each time a delegated authorization token is received, thus saving computer processing power and time while providing strong access control security. When there are a large number of delegates, the hashing process may be computationally time consuming.

[0192] Alternatively, only the first method 900 is used. If only the first method 900 is used, the entire chain of delegated authorization tokens is generated as every request is received and the chain is not stored. This provides the advantage of not having to store intermediate delegated authorization tokens that may not be used and maintains strong access control security.

[0193] 9D, an overall method 960 is shown to show how and when this occurs. When any request is received that includes a delegated authorization token and index (962), a determination is made as to whether it has been previously calculated and stored in a data store (964).

[0194] If no delegated authorization tokens have been generated previously, further delegated authorization tokens are generated (966) starting from the index until the last delegated authorization token is generated or a previously calculated / received known valid delegated authorization token is generated. If any of the generated delegated authorization tokens are equal in both value and index to a previously received or generated delegated authorization token, the received token is considered valid. Preferably, only enough delegated authorization tokens are generated to satisfy the indexes of the previously received or generated delegated authorization tokens. For example, if H3 was previously received or generated and H5' is currently received, then only H5', H4', and H3' are generated. The validity of the currently received token is determined by comparing the currently delegated authorization token with the lowest index with the index of the previously received or generated delegated authorization token with the highest index. For example, comparing H3 and H3' as described above with respect to FIG. 9B.

[0195] When validating a delegated authorization token for writing, preferably the client also provides a "max writes" value as part of the validation data in the first step 802 of the validation method 800 described above. Preferably, another validation step is used to ensure that the delegated user does not write more data to the service than allowed. The service stores a "writes" value associated with each delegated authorization token, which starts at 0 and is incremented each time the delegated user writes to the service. After token validation, a "max writes" validation is also performed. In this validation, the "writes" is compared to the "max writes". If the "writes" of the delegated authorization token is equal to or greater than the "max writes" value, the request is not processed. If it is less, the "writes" value is incremented and the request is processed. Optionally, the "writes" is incremented only if the request successfully writes data to the event stream and / or the blockchain. Those skilled in the art will appreciate that this can also be applied to other interactions besides writes. Writes were used just as an example.

[0196] In some embodiments, the request is in the form of a Hypertext Transfer Protocol (HTTP) request or a Hypertext Transfer Protocol Secure (HTTPS) request. Optionally, the delegated authorization token is stored in a header of the HTTP(S) request. Optionally, the header is in the following format:

number

[0197] The Base64 encoding of the two values ​​delegatedAuthIndex and delegatedAuth is optional. Alternatively, a binary representation of the two may be used.

[0198] Advantageously, by moving the delegated authorization to a header, the authorization process can be made more compatible with the Basic HTTP Authentication framework described in RFC7235.

[0199] A single delegate If only one delegate is needed for reading and / or writing, only one hash is generated using the method 600 described with reference to FIG. 6, based on a combination of an initial value and a seed value used as input to a one-way function. The service receives this "final" (and only) delegated authorization token for validation purposes. The initial value is not used, since there is no chain of delegated authorization tokens to reconstruct. Therefore, clients can pass any random data they want to the service, or nothing at all. Since the service receives only the last delegated authorization token, validation of an incoming request becomes a comparison of the delegated authorization token of the incoming request with the last delegated authorization token. Any other tokens become invalid.

[0200] Platform System According to an aspect, any one or more aspects described above relating to client delegation may be used with a platform processor as described herein. Preferably, the client delegation aspects are used in delegating access to data services 1502, computation services 1504, and / or commerce services 1506 provided by the API 1508. The delegated access may be in the form of read, write, read / write, send, and / or any other action that may be associated with a particular service. This aspect may be a Platform as a Service (PaaS) and Software as a Service (SaaS) that advantageously enables rapid delivery of practical real-world business and technology applications, such as management of software controlled technology systems or smart contracts, using a blockchain network such as the BSV blockchain.

[0201] 10A-10E, example interactions with platform services (described in more detail below with reference to FIGS. 11-13) are shown. The example interactions shown are adding an event to an event stream, querying (or reading) an event on an event stream, revoking a delegated user's interaction with an event stream, generating an event stream and a delegated authorization token, and an overall method involving various embodiments and aspects of the system. These are provided as examples of how a delegated authorization token may be used in the context of an event stream and platform services.

[0202] In these embodiments, the platform includes a number of components, including an event stream service 1004, a client authorization service 1006, a database 1008, and a message bus 1010 (as described in the previous embodiments).

[0203] In these examples, the platform service provides multiple different EventStreams, and thus the client and / or delegated user provides an identifier for the particular EventStream they wish to interact with. Thus, the request further includes a service identifier. Optionally, if the platform provides only one such service to interact with, an identifier is not required.

[0204] 10A and onwards, a client application 1002, which may be a client 504 or a delegated user 506 as described above, adds an event to an event stream service 1004. The client application 1002 sends an "appendEvent" request to the event stream service. The "appendEvent" request includes data associated with the event and, if the client application is a delegated user, delegatedAuth information, which includes the delegated authorization token and index. If the client application is a client 502, a different client authorization process is performed using a client authorization service 1006 (separate from the authorization service described above or with particular reference to FIG. 8).

[0205] The event stream service 1004 validates the data and passes 1014 the delegated authorization information associated with the request, if any, to a database 1008. The database is configured to perform the validation methods described with reference to Figures 8-9D and to store previously generated delegated authorization tokens. The database responds to the received delegated authorization information with the validity of the delegated authorization (not shown). Since this is a write service, the database also validates that the number of writes associated with the particular delegated authorization token used does not exceed a predefined "max writes".

[0206] With the indicator of valid authorization, the event stream service 1004 continues to process the additional information, including inserting the event into the database 1008 (1016), receiving an index for the event (1018), publishing the event to the blockchain via the message bus 1010 (1020), completing the claim processing (1022), and finally responding to the client application 1002 with an indication that the event was successfully added (1024).

[0207] 10B, a client application 1002 is requesting to read data from an event stream service 1004. The client application 1002 sends a "queryData" request to the event stream service 1004. The event stream service 1004 validates the parameters and approves 1014 (if a delegated authorization token is present) or authorizes (if a separate client authorization service is used) in the same or similar manner as the "appendEvent" example 1000. Because this is a read service, there are preferably no maximum reads, writes, or other interactions to keep track of.

[0208] Once the client application 1002 is authenticated or authorized, any filters that are part of the data query (time range, type of data, user who provided the data, etc.) are used to construct a database query. The database query may be in SQL format. Once the query is formatted, it is sent to the database 1008 in the form of a selection. The billing information is sent (1034) to a message bus 1010 for other services to review and manage. Finally, the requested data is returned (1036) to the client application in the form of a JSON response.

[0209] In Figure 10C, a client application 1002 wishes to revoke a delegated authorization token. Preferably, only the client 502 can perform such an action, therefore there is no option for the delegated authorization token to be approved and only client authentication methods are available.

[0210] The client sends 1052 an HTTP request to the event stream service 1004 containing the PUT method to be cancelled. The request includes: -esid, the EventStream ID. · accessType, which is the interaction the client is trying to modify, preferably "read" or "write", so that the database knows the chain associated with the referenced EventStream. index, which is the index of the delegated authorization token in the chain. token, which is the delegated authorization token.

[0211] These parameters are validated and the client is approved.

[0212] The event stream service 1004 sends a further request (1054) to the database 1008 to update the data storage mechanism storing the delegated user information. Preferably, there is a column, flag, or other data associated with each delegated authorization token and / or each index (as all delegated authorization tokens may not be known). This data is updated to reflect that even if the correct index and delegated authorization token are provided, the token will not be considered valid. Alternatively, if there is a "max writes" associated with the service, the write count for that delegated authorization token is set equal to the "max writes". This invalidates all future interactions.

[0213] The database 1008 returns (1056) the number of times the delegated authorization token was used to the event stream service 1004. The billing information is sent (1058) to the message bus 1010 for other services to review and manage. Finally, a response including whether the revocation was successful is returned (1060) to the client application, preferably in the form of a JSON response. Optionally, the response also includes the number of interactions that occurred using the revoked delegated authorization token.

[0214] As described above, FIG. 10D illustrates a system 1070 in which a client generates a chain of delegated authorization tokens according to the second embodiment and the method of FIG. 6 and generates an event stream on an event stream service.

[0215] With reference to FIG. 10E, an overall system is shown that includes many of the embodiments and features described herein. The client creates a chain of delegated authorization tokens and creates an event stream as described with reference to FIG. 10D. At a later time, not necessarily immediately after, the client provides the details the delegate needs to interact with the event stream. The details include an identification (in the figure, "esid") to identify which event stream on the event stream service to interact with, the delegated authorization token (in the figure, "H"), and an index (in this example, "3"). With this information, the delegate now has enough information to send data to the event stream service using an "appendEvent" request. The request includes all of the same details received from the client, plus the data the delegate wants to send to the event stream.

[0216] Figure 10E also shows an example of revocation taking place, where a client sends a request to revoke a delegated authorization token. The request identifies the event stream for which the token should be revoked from (esid), the token itself with the token's index, and the type of interaction to revoke ("write" in this example). If a valid token and index match for a given event stream, the event stream service invalidates the token.

[0217] An overview of the Platform Services is shown in Figure 11, which shows a high-level overview of the system. The Platform Services has a platform processor 1500 that provides an API 1508, through which one or more clients can access the services.

[0218] The platform services 1500 depicted in this Figure 11 are composed of three service families, aimed at enabling users and organizations to easily and securely take advantage of the benefits offered by the unique properties of blockchain without having to actually implement blockchain-based software, knowledge, or libraries on the client side. These services are: A data service 1502 aimed at simplifying the use of the chain as a commodity data ledger. The data service preferably uses the data structures and methods provided herein to implement writing and reading data to the blockchain. Computing services 1504 aimed at providing a general-purpose computing framework backed by digital assets such as Bitcoin SV. · Commerce services providing enterprise-class capabilities for transacting using digital assets, such as Bitcoin SV1506.

[0219] Since the API is implemented as a web service, the API can receive requests from clients over or using the HTTPS protocol. The requested service is then implemented by one or more service modules or processing resources 1502-1506 using underlying software 1510, such as underlying software 1510 associated with a blockchain, i.e., implementing resources, libraries and / or key management wallets for generating, processing and sending transactions associated with a blockchain. Once processed, the transaction can be sent to the blockchain network 1512 (rather than the client implementing such functionality or transaction libraries). At most, the client need only or can implement a digital wallet or the like associated with cryptocurrency or other digital assets, although this is not required as the platform services 1500 can also provide and manage digital assets for the client.

[0220] FIG. 12 provides a more detailed schematic diagram of a number of services related to the blockchain that can be implemented by the platform 1600 in conjunction with APIs that can access any one or more of the services provided. As seen in this FIG. 12, the data services 1602 can include a data writing service 1602a and a data reading service 1602b. Delegated authorization as described above is preferably used to provide delegated access to the event stream, and / or the data writer, and / or the data reader. Similarly, a delegated user wishing to access the data archive using the data reader 1602b preferably has delegated authorization in accordance with the above description. Further details of the event stream are discussed with reference to FIGS. 4 to 8 of UK Patent Application No. 2002285.1 (filed by nChain Holdings Limited on February 19, 2020), which is incorporated herein by reference. The data writing service 1602a allows a client to write data to the blockchain in an easy, secure and optimized manner. The data reading service 1602b allows a client to submit a query that returns data stored in the blockchain. This may be the use of filtered streams where a client can pre-define the type of data they want to read from the blockchain, ad-hoc or periodically, within a certain time frame, or the type of data associated with a series of related or unrelated events or documents being processed in the blockchain 1610. The data archive feature allows access to a log of previous transactions for a specified event or contract.

[0221] Computing services 1606 of platform 1600 include applications 1606a and frameworks 1606b associated with smart contracts, which in some embodiments are represented as state machines in a blockchain 1610. Computing services 1606 interact with data services 1602 as data is input and results need to be provided to clients for such computations.

[0222] The commerce service 1604 is responsible for providing enterprise-class functionality via the enterprise wallet 1604a for transacting over the blockchain 1610 based on best-in-class security practices and technology. For example, in some embodiments, the enterprise wallet may implement functionality to enable blockchain transaction processing when multiple people, users, or accounts are required to sign off on a transaction that meets defined criteria; i.e., associated with a large value of cryptocurrency that exceeds a certain predefined limit. The enterprise wallet may also include functionality to implement threshold numbers and / or types of signatures for transferring large amounts of digital assets, such as cryptocurrency or tokens that represent another resource. Transfers of these assets may be represented on the blockchain after being processed based on criteria applied by such enterprise wallet implementation.

[0223] SPV services 1608 (simplified payment verification) are applications that require information from the blockchain, but do not run miner nodes and therefore do not include a direct link to the blockchain. Such SPV services 1608 allow light clients to verify that a transaction is included in the blockchain without downloading the entire blockchain 1610.

[0224] <Illustrative Use Cases> The systems and methods described herein enable many different use scenarios in conjunction with smart contracts, blockchains, and more specifically event streams. The use cases provided herein are examples, and one of ordinary skill in the art will appreciate that many more uses are possible. One of ordinary skill in the art will appreciate that although the examples refer specifically to event streams, these examples may also be implemented using other smart contract technologies, other blockchain technologies, or the like.

[0225] Example 1: Voting service In an ever-increasing number of cases, the public is offered the opportunity to vote on one topic or another (e.g., The Voice, Strictly, Goal of the Month, Favorite Artist, etc.). Such polls involve a potentially large number of independent people wishing to cast a vote (or multiple votes) within a limited time period. Such public polls typically use phone-in, web, or phone app front-ends. The embodiments described herein can provide a low-cost, scalable back-end that uses event streams and delegated authorization to provide transparency and public vote inspection.

[0226] Suppose a voting master (acting as client 502 as described above) wants to conduct a vote among a group of voters (acting as delegated users 506 as described above). Each voter can cast between 1 and N votes within a bounded time period. This can be achieved using the event stream service and delegated authorization tokens as follows: 1. The Voting Master is responsible for generating a set of delegatedAuth tokens and their delegatedAuthIndex values ​​(collectively referred to as "Voter Authorisation Tokens (VAT)") and distributing them to voters before the start of the voting period. Individual voters save their own VAT for display when their vote is cast. 2. The Voting Master generates an event stream that starts and ends at specific times. 3. A voter can submit a vote at any time during the voting period by calling the appendEvent endpoint. The vote must be submitted with a valid VAT. 4. Each vote is acknowledged using a VAT and added to the stream without a sequenceNumber. The order of individual events is usually not important. Streams can be configured to accept 1 to N votes per VAT, with a maximum number of writes optionally provided during the creation of the event stream. 5. At the end of the voting period, the voting master finalizes the event stream and tallys the votes using the queryData endpoint. Auditors can also use delegated read access to iterate over the votes using queryData, validating the event data as needed and verifying the state of the stream on-chain.

[0227] Features of this voting service include: · Voting will be strictly restricted to the population of eligible voters who possess a valid VAT. The maximum number of votes per voter will be strictly limited by the Voting Master before the voting period. The voting period is under the direct control of the voting master, who can set fixed start and end times when generating the stream. The event stream service does not know the identity of the voter, so there is no basis for prioritizing one vote over another (although the voter's IP address may be known). · Votes will be recorded in approximate order of arrival time. The record of all votes is immutable and auditable as a result of event stream technology in particular and blockchain technology more generally. The event messages themselves may or may not be obfuscated (according to rules set by the voting master), determining the practicality of public auditing.

[0228] An example of the configuration data used when generating an event stream:

number

[0229] The use of event streams and blockchain technology here has the advantage of providing a level of transparency not typically found in other "public" voting situations. A vote may be structured in such a way that any voter can see their vote in the dataset and calculate the outcome of the vote for themselves. The outcome of such a vote is immediately available if the voting data is stored in plaintext, but if the voting data is obfuscated, one must wait until the voting master declares the outcome of the vote.

[0230] VAT distribution For a fair vote, the VAT must be distributed to voters before the start of the voting period. The VAT can be distributed in any way that is practical for the use case. For example, each VAT can be distributed to a phone app. The VAT may or may not be associated with a registered user.

[0231] Alternatively, the VAT may be kept in the account data and a web interface provided to the account user.

[0232] Alternatively, a dial-up telephone service could be connected to a driver who converts phone calls and / or keypad inputs into voting data, each associated with a cache of VAT.

[0233] Each voter application must include the VAT N Each voter receives a VAT containing a delegated authorization token, called

[0234] VAT Validation When generating the event stream, the WIV and WH0 are provided so that the event service can use the VAT instead of the usual client authentication data. N The service expects a call to appendEvent containing N and N. The validation process is the same as or similar to that described above with reference to Figure 8 and Figures 9A-D. If known beforehand, the service checks the configuration of the maximum number of votes per VAT and the N The service accepts or rejects a vote depending on the number of previous votes cast using the VAT N must be hashed N times and the final result compared to WH0. If they are equal, the vote is accepted and recorded. For example, for N=3, if WH0 is equal to H(WIV||H(WIV||H(WIV||H(WIV||VAT3)))), the vote is accepted.

[0235] Voting Rating It is preferably the sole responsibility of the Ballot Master to evaluate the votes and determine the results.

[0236] Example 2: Instrument Activity Log High-end equipment manufacturers may want access to important activity logs of their customers' equipment as part of a warranty or service agreement. By analyzing the logs, the manufacturer can take proactive steps to ensure that the equipment is operating at peak efficiency. Factory-fitting the equipment with delegated authorization tokens allows the equipment to automatically log important events during its lifetime, which begins with registration.

[0237] In this case, it is recommended that: · Manufacturers can configure separate event streams for each product line. Delegated authorization tokens are attached to devices at the factory using a delegate index recorded in the manufacturer's client database. The device automatically records important events during the validity period starting from registration. · Manufacturers can remotely monitor any activity including: heartbeat, run time, changes in critical components, use of certified materials, etc.

[0238] An example of the configuration data used when generating an event stream:

number

[0239] Example 3: Auction-based bidding process Consider a local council that wants to have an honest and open tendering process: the council issues tender documents that clearly identify the requirements and the basis for awarding the bid.

[0240] Let's say 20 companies register their intention to bid. The council needs to generate a delegated token of at least 20 elements and generate an event stream to record the bids. The 20 companies are each given a token to use when submitting their bid documents. They can also provide the same or a different token so that they can read all the bids after the bidding period has ended.

[0241] The stream ID ("esid" in the example above) can be used in advance to check the stream's metadata to ensure that the bidding terms are acceptable.

[0242] To ensure that the bidding process is performed without prejudice, the event stream can be configured as follows:

number

[0243] With this configuration, companies that receive the delegatedAuth token can register their bidding documents and amend them up to three times. Bids are strictly accepted within a specified time period, and bids cannot be viewed until the end of the bidding period. Recording such bidding information on the blockchain provides a way to publicly audit such bidding processes, thereby ensuring that the overall process is being followed, thereby reducing the possibility of malicious actors interfering with the bidding process and overall improving the security of such multi-party interactions.

[0244] Immediately after each bid is submitted, companies can also monitor a digest of the bid on-chain. Such a digest acts as a proof of existence, ensuring that the contents of the bid have not been altered between submission and audit. Advantageously, the existence of a bid can be recorded without revealing what the bid was.

[0245] Example 4: Obfuscating a message The need to obfuscate event data (hereafter referred to as ED) depends on the use case. For transparency and ease of public auditing, clear-text event data is recommended. However, event data is highly sensitive and should not be exposed even to the service providing the event stream. In such cases, a client can specify that events should be obfuscated such that the client can read each event but not other events. A relatively easy way to achieve this is through the use of a shared secret.

[0246] Along with the delegatedAuth token and index, the client also provides each contributor with a separate random IV (fIV in the following) (i.e., a shared secret that must be kept secret), which is used as an initialization vector when encrypting the contributor's data.

[0247] Each contributor formats its event data ED according to rules specified by the client.

[0248] The ED is encrypted using a common method such as AES with the contributor's individual IV so that the ED can only be read by the contributor and the client.

[0249] Then, you can construct your event message as follows:

number

[0250] When a client wishes to evaluate a contributor's data, it can use queryData to retrieve the event record, which contains the delegate's index that can be used to look up the contributor's id, and a shared secret iv that can be used to recover the cleartext event data from the obfuscated data elements.

[0251] Platform Equipment Referring to FIG. 13, an illustrative simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the systems or methods described above and illustrated. For example, the computing device 2600 may be configured to be used as one or more components in the previously described system 500 of FIG. 5. The computing device 2600 may be configured as a client entity associated with a given user, i.e., a client entity that makes database requests and / or transmissions to a platform processor. The computing device 2600 may be configured as a delegated user. Upon receiving a delegated authorization token, the delegated user may make data requests and / or transmissions to the platform processor. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in Figure 13, computing device 2600 may include one or more processors with one or more levels of cache memory and memory controller (collectively labeled 2602) that may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a persistent storage device 2610. The main memory 2608 may include dynamic random access memory (DRAM) 2618 and read only memory (ROM) 2620 as shown. The storage subsystem 2606 and cache memory 2602 may be used for storage of information such as details associated with transactions and blocks as described in this disclosure. The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

[0252] The processor 2602 may also communicate with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0253] Bus subsystem 2604 may provide a mechanism that allows the various components and subsystems of computing device 2600 to communicate with each other as intended. Although bus subsystem 2604 is illustrated generally as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0254] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616, in some embodiments, may act as an interface to receive data from and transmit data to other systems in the computing device 2600. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a network so that the data technician can send data to and receive data from the device without being in a remote location, such as a data center.

[0255] User interface input devices 2612 may include one or more user input devices, such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen integrated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into computing device 2600.

[0256] The 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, etc. The display subsystem may include a flat panel device such as a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection, or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface and facilitate user interaction with applications that perform the processes and transformations described herein, when such interaction is appropriate.

[0257] The storage subsystem 2606 may provide a computer-readable storage medium that stores basic programming and data structures that provide the functionality of at least one embodiment of the present disclosure. Applications (e.g., programs, code modules, instructions) that, when executed by one or more processors, provide the functionality of one or more embodiments of the present disclosure may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 also provides a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The permanent storage device 2610 may provide permanent (non-volatile) storage of programs and data and may include a magnetic hard disk drive, one or more floppy disk drives associated with removable media, one or more optical drives (e.g., CD-ROM, or DVD, or Blue-Ray) drives associated with removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments described in this disclosure, and data associated with the transactions and blocks described in this disclosure.

[0258] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). A device that may be connected to the computing device 2600 may include multiple ports configured to receive optical fiber connectors. The device may thus be configured to convert optical signals into electrical signals that are transmitted to the computing device 2600 through the ports connecting the devices for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 shown in FIG. 13 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 13.

[0259] The various methods described above may be implemented by a computer program. The computer program may include computer code configured to instruct a computer to perform one or more functions of the various methods described above. The computer program and / or code for performing such methods may be provided to an apparatus such as a computer on one or more computer readable media or, more generally, on a computer program product. The computer readable media may be transitory or non-transitory. The one or more computer readable media may be, for example, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, or a transmission medium for data transmission, for example, for downloading code via the Internet. Alternatively, the one or more computer readable media may take the form of one or more physical computer readable media, such as a semiconductor or solid-state memory, a magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk such as a CD-ROM, a CD-R / W, or a DVD.

[0260] In implementation, the modules, components and other features described herein may be implemented as discrete components or integrated into the functionality of hardware components such as an ASIC, FPGA, DSP or similar device.

[0261] A "hardware component" or "hardware module" is a tangible (e.g., non-transient) physical component (e.g., a set of one or more processors) that can perform specific operations and may be configured or arranged in a specific physical way. A hardware component may include dedicated circuitry or logic that is permanently configured to perform specific operations. A hardware component may be or include a special-purpose processor, such as a field programmable gate array (FPGA) or an ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform specific operations.

[0262] Thus, the phrase "hardware component" or "hardware module" should be understood to include a tangible entity that is physically constructed, permanently configured (e.g., wired) or temporarily configured (e.g., programmed) to operate in a particular manner or to perform particular operations described herein.

[0263] Additionally, the modules and components may be implemented as firmware or functional circuits within a hardware device. Additionally, the modules and components may be implemented in any combination of hardware devices and software components, or may be implemented solely in software (e.g., code stored or otherwise embodied in a machine-readable medium or transmission medium).

[0264] Unless otherwise indicated, and as will be apparent from the discussion that follows, discussions throughout the description using terms such as "determining," "providing," "calculating," "computing," "identifying," "combining," "establishing," "transmitting," "receiving," "storing," "estimating," "ascertaining," "obtaining," and the like will be understood to refer to operations and processes of a computer system or similar electronic computing device that manipulate and transform data represented as physical (electronic) quantities in the registers and memory of the computer system into other data similarly represented as physical quantities in the memory or registers of the computer system or other such information storage, transmission or display devices.

[0265] The term "comprising" as used in this specification and the claims means "constitute at least a part of." When interpreting each statement in this specification and the claims that includes the term "comprising," there may be other features or features preceded by the term. Related terms such as "comprise" and "comprises" are to be interpreted in the same manner.

[0266] Reference to a range of numerical values ​​disclosed herein (e.g., 1 to 10) is intended to include references to all rational numbers within that range (e.g., 1, 1.1, 2, 3, 3.9, 4, 5, 6, 6.5, 7, 8, 9, 10) and to any rational range within that range (e.g., 2 to 8, 1.5 to 5.5, 3.1 to 4.7), and therefore all subranges of all ranges explicitly disclosed herein are expressly disclosed herein. These are merely examples of what is specifically intended, and all possible combinations of numerical values ​​between the lowest and highest values ​​recited are to be considered as expressly set forth in this application in a similar manner.

[0267] As used herein, the term "and / or" means "and" or "or" or both.

[0268] As used herein, "(s)" following a noun refers to the plural and / or singular form of the noun.

[0269] The singular reference of an element does not exclude the plural reference of such elements and vice versa.

[0270] It should be understood that the above description is illustrative, and not restrictive. Many other implementations will be apparent to those skilled in the art upon reading and understanding the above description. Although the disclosure has been described with reference to specific embodiments, it will be recognized that the disclosure is not limited to the described embodiments, but can be practiced with modification and alteration within the scope of the appended claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense. The scope of the disclosure should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.< / sigpa>

Claims

1. A method implemented by a computer, comprising: obtaining a predetermined value; receiving a request, the request including a first delegated authorization token of a chain of delegated authorization tokens; generating a further delegated authorization token of the chain of delegated authorization tokens, wherein the generation of each further delegated authorization token in the chain of delegated authorization tokens is based on a preceding delegated authorization token in the chain of delegated authorization tokens; determining the validity of the first delegated authorization token based on a comparison between one of the delegated authorization tokens in the chain of delegated authorization tokens and the predetermined value; A method comprising the above steps.

2. The method implemented by a computer according to claim 1, wherein the generation is based on a hash of the preceding delegated authorization token in the chain of delegated authorization tokens.

3. The step of generating a further delegated authorization token of the chain of delegated authorization tokens comprises, for each further delegated authorization token: determining an intermediate image, the intermediate image being based on the preceding delegated authorization token in the chain of delegated authorization tokens; applying a one-way function to the intermediate image, the output to the one-way function being the further delegated authorization token; The method implemented by a computer according to claim 1, including performing the above steps.

4. The method implemented by a computer according to claim 3, wherein the one-way function is a hash function.

5. The method implemented by a computer according to claim 3, wherein the intermediate image is further based on a given value.

6. The method implemented by a computer according to claim 1, wherein the generation of the further delegated authorization token is based on the preceding delegated authorization token in the chain of delegated authorization tokens and a given value.

7. The method implemented by a computer according to claim 5, further including obtaining the given value from a storage device.

8. The method implemented by a computer according to claim 5, wherein the given value is received from a client. **Claim 9**: The method implemented by a computer according to claim 5, wherein the generation is based on a concatenation of the given value and the preceding delegated authorization token. **Claim 10** The method implemented by a computer according to claim 9, wherein the generation is based on a hash of a concatenation of the given value and the preceding delegated authorization token in the chain of delegated authorization tokens. **Claim 11** The method implemented by a computer according to claim 1, wherein the request further includes an index number, and the number of delegated authorization tokens in the chain of delegated authorization tokens is based on the index number. **Claim 12** The method implemented by a computer according to claim 1, wherein the step of determining the validity of the first delegated authorization token is based on a comparison between the last delegated authorization token in the chain of delegated authorization tokens and the predetermined value. **Claim 13** The method implemented by a computer according to claim 1, wherein the step of determining the validity of the first delegated authorization token includes a step of comparing the last delegated authorization token in the chain of delegated authorization tokens with the predetermined value. **Claim 14** The method implemented by a computer according to claim 1, wherein the request is a transmission to or a reading from a blockchain. **Claim 15** The method implemented by a computer according to claim 1, wherein the processing of the request further is based on the number of previously received requests including the same first delegated authorization token. **Claim 16** The method implemented by a computer according to claim 1, further including the step of storing the chain of delegated authorization tokens. **Claim 17** Receiving a further request including a further delegated authorization token; Determining the validity of the further delegated authorization token based on whether the further delegated authorization token exists in the chain of delegated authorization tokens in which the further delegated authorization token is stored; Processing the further request based on the validity of the further delegated authorization token; The method implemented by a computer according to claim 16, further including the above steps. **Claim 18** Providing an indication of the validity of the request and / or processing the request based on the validity of the delegated authorization token; The computer-implemented method according to any one or more of claims 1 to 17, further comprising. Claim 19 A computer-implemented method for generating a chain of associated delegated authorization tokens, comprising: Obtaining a first value and a second value; Generating a first delegated authorization token of the chain of delegated authorization tokens, the first delegated authorization token being based on the first value and the second value; Generating at least one further delegated authorization token of the chain of delegated authorization tokens, each generation of a further delegated authorization token in the chain of delegated authorization tokens being based on a preceding delegated authorization token in the chain of delegated authorization tokens and the first value; A computer-implemented method comprising. Claim 20 The step of generating a further delegated authorization token of the chain of delegated authorization tokens, for each further delegated authorization token, comprises: Determining an intermediate preimage, the intermediate preimage being based on the preceding delegated authorization token in the chain of delegated authorization tokens and the first value; Applying a one-way function to the intermediate preimage, the output to the one-way function being the further delegated authorization token; The computer-implemented method according to claim 19, comprising performing. Claim 21 The computer-implemented method according to claim 20, wherein the generation is based on a concatenation of the first value and a preceding delegated authorization token. Claim 22 The computer-implemented method according to claim 21, wherein the generation is based on a hash of a concatenation of a given value and a preceding delegated authorization token in the chain of delegated authorization tokens. Claim 23 The computer-implemented method according to claim 19, further comprising providing one of the delegated authorization tokens of the chain of delegated authorization tokens to a delegate device. Claim 24 The delegating device is further provided with an index of the delegated authorization tokens, the index indicating where in the chain of delegated authorization tokens the provided delegated authorization token is, a method implemented by a computer according to claim 23.

25. The method implemented by a computer according to claim 19, further comprising the step of providing the verification device with the first value and the last delegated authorization token in the chain of delegated authorization tokens.

26. The method implemented by a computer according to claim 25, wherein the verification device is further provided with a number indicating a maximum number of reads or writes per delegate.

27. The method implemented by a computer according to claim 19, wherein the number of delegated authorization tokens in the chain of delegated authorization tokens is based on the number of delegates.

28. The method implemented by a computer according to claim 27, wherein the number of delegated authorization tokens in the chain of delegated authorization tokens is greater than or equal to the number of delegates.

29. The method implemented by a computer according to claim 19, wherein the second value is deleted after the first delegated authorization token is generated.

30. The method implemented by a computer according to claim 19, wherein the first and second values are randomly generated.

31. The method implemented by a computer according to claim 1, wherein the preceding delegated authorization token refers to the delegated authorization token immediately preceding the delegated authorization token being generated.

32. The method implemented by a computer according to claim 1, wherein the first delegated authorization token is generated by a client according to the method of claim 19.

33. A method implemented by a computer, comprising: receiving a delegated authorization token generated according to the method of claim 19; generating a request including the delegated authorization token; transmitting the request to a server. A method implemented by a computer including the above steps.

34. A system, comprising: a server; a delegate; a client; wherein the client generates a chain of delegated authorization tokens and a first value according to the method of claim 19. ​ Send the first value and the last delegated authorization token in the chain of the delegated authorization tokens to the server, Send one of the delegated authorization tokens in the chain of the delegated authorization tokens to the delegate, A system configured as such.

35. The system according to claim 34, wherein the server is configured to receive and process a request from the delegate according to the method of claim 1.

Images