Event stream for sequence of event related to block chain

Abstract

To propose a method, a device, and a system that implement a platform that provides a plurality of services related to a block chain.SOLUTION: A method includes steps of: receiving a request to create a new event stream (ES) using a block chain that creates the new ES using the block chain from a client; determining a hierarchical deterministic (HD) keychain K to be used with the new event stream to be created; identifying or obtaining data related to a first event E0; creating a first block chain transaction TX0 for the new ES, where n=0, by one or more processors related to a platform processor implementing a data writer; providing a dust output related to a protected lock script using a first derived key pair K0; submitting it to the block chain; and transmitting a result related to the created ES to the client.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present disclosure relates generally 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. In particular, the present disclosure relates to providing access to multiple functions and applications related to blockchain, such as, but not limited to, implementing event streams or machine-readable contracts, for one or more clients. [Background technology]

[0002] In this document, we use the term “blockchain” to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, public and private blockchains, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. While Bitcoin may be referenced herein for convenience and illustrative purposes, it should be noted that this disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols related to any type of digital asset or representation of a digital asset fall within the scope of this disclosure. The terms “client,” “entity,” “node,” “user,” “sender,” “receiver,” “payer,” and “payee” may refer to computing or processor-based resources herein. The term “Bitcoin” is used herein to include any version or variation derived from or based on the Bitcoin protocol. The term “digital asset” may refer to any transferable asset, such as a cryptocurrency, a token representing at least a portion of property, a smart contract, a license, i.e., a software license, or a DRM contract for media content. It is understood that the term "digital asset" is used throughout this document to describe a commodity that may be associated with value that can be transferred or provided as payment in a transaction from one entity to another.

[0003] A blockchain is a computer-based, decentralized, peer-to-peer electronic ledger implemented as a distributed system made up of blocks, each of which is made up of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block so that blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since the blockchain's inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs that specify how and to whom the transaction's outputs can be accessed. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform work to ensure each transaction is valid; invalid transactions are rejected from the network. A software client installed on a node performs this validation work on an unspent transaction (UTXO) by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true, the transaction is valid and the transaction is then written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction; if the transaction is verified, the node relays it to other nodes in the network; ii) be added to a new block constructed by miners; and iii) be mined, or added, to the public ledger of past transactions.

[0005] It will be appreciated that the nature of the work performed by miners depends on the type of consensus mechanism used to maintain the blockchain. While proof of work (PoW) is associated with the original Bitcoin protocol, other mechanisms, such as proof of stake (PoS), delegated proof of stake (DPoS), proof of capacity (PoC), proof of elapsed time (PoET), and proof of authority (PoA), are also used. Different consensus mechanisms differ in how mining is distributed among nodes, and the probability of successfully mining a block depends, for example, on the miner's hashing power (PoW), the amount of cryptocurrency held by the miner (PoS), the amount of cryptocurrency staked in delegated mining (DPoS), the miner's ability to memorize a predetermined solution to a cryptographic puzzle (PoS), a waiting time randomly assigned to the miner (PoET), etc. Typically, miners are provided with an incentive or reward for mining blocks. A Bitcoin block, for example, rewards miners with newly minted cryptocurrency (Bitcoins) and fees associated with transactions in the block (transaction fees). In the case of the Bitcoin blockchain, the amount of cryptocurrency mined decreases over time, and incentives ultimately consist solely of transaction fees. It will be appreciated, therefore, that processing transaction fees is part of the underlying mechanism for committing data to a public blockchain, such as the Bitcoin blockchain.

[0006] As previously mentioned, each transaction in a given block encodes the transfer of control of a digital asset between participants in the blockchain system. Digital assets do not necessarily correspond to cryptocurrency. For example, digital assets may relate to digital representations of documents, images, physical objects, etc. Payment of cryptocurrency and / or transaction fees to miners may simply act as an incentive for maintaining the validity of the blockchain by performing necessary work. The cryptocurrency associated with the blockchain may act as security for miners, and the blockchain itself may be primarily a ledger for transactions related to digital assets other than cryptocurrency. In some cases, transfers of cryptocurrency between participants may be handled by entities different and / or independent from the entities that use the blockchain to maintain the ledger of transactions.

[0007] Once stored on the blockchain as a UTXO, a user can transfer control of the associated resource to another address associated with an input in another transaction. This transfer is typically, though not inherently, accomplished using a digital wallet. This digital wallet can be a device, physical media, a program, an application (app) on a computing device such as a desktop, laptop, or mobile terminal, or a remotely hosted service associated with a domain on a network such as the Internet. Digital wallets can be used to store public and private keys, track ownership of resources such as tokens and assets associated with a user, receive or consume digital assets, and transfer tokens, which may be related to digital assets such as cryptocurrency, licenses, property, or other types of resources.

[0008] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are exploring the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions would be more general in application while still being able to take advantage of the benefits of blockchain (e.g., permanent, tamper-proof recording of events, distributed processing, etc.).

[0009] One area of ​​current research is the use of blockchains for the implementation of "smart contracts." These are computer programs designed to automate the execution of machine-readable agreements or terms of agreements. Unlike traditional contracts, which are written in natural language, smart contracts are machine-executable programs with rules; these rules can process inputs to generate results and then cause actions to be taken in response to those results. Another area of ​​blockchain-related interest is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via blockchains. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Tokens therefore function as identifiers that allow real-world items to be referenced from the blockchain.

[0010] The above example or scenario, while utilizing the benefits of blockchain to provide a permanent, tamper-proof record of events, requires the client, client entity, computing device, or terminal associated with the client to include or implement software and / or hardware or processors / modules, such as a digital wallet to implement functionality for managing digital assets, managing cryptographic keys for the Elliptic Curve Digital Signature Algorithm (ECDSA) used by the BSV (Bitcoin Satoshi's Vision) blockchain. In addition, there is a need for the client device to implement blockchain transaction mechanisms and be able to access BSV libraries. Thus, the client not only needs to include processing to implement such functionality, but also needs to ensure that appropriate security measures are in place for such processes before it can utilize the blockchain network to send, receive, and view data and / or digital assets related to smart contracts or tokens representing real-world asset transactions. [Prior art documents] [Patent documents]

[0011] [Patent Document 1] U.S. Patent Application No. 16 / 384696 [Patent Document 2] UK Patent Application No. 1907180.2 Summary of the Invention [Problem to be solved by the invention]

[0012] It is therefore desirable to implement secure, low-complexity, user-friendly, efficient, and robust techniques that enable any client, whether computationally advanced or not, to instantly access and interact with useful blockchain-related applications in a simple, fast, accurate, reliable, and secure manner that is computationally and functionally low burden. More specifically, it is desirable to utilize the benefits of distributed ledger (blockchain) technology and its increased security, transparency, and reliability of records to provide a common platform or interface for multiple blockchain-related services or applications that enables any client computing device to ensure that any data, event, or digital asset associated with the client can be easily mined or written to the blockchain instantly and securely, thereby providing a permanent, tamper-proof, and auditable record thereof that can be created, written, updated, read, or viewed as needed. [Means for solving the problem]

[0013] Such an improved solution has now been devised. The present disclosure addresses the above technical concerns by proposing one or more techniques whereby data or information related to a client may be easily, securely, and instantly written to and retrieved from a blockchain by methods, devices, and systems that provide an application programming interface (API) for one or more services related to the blockchain without the need for such clients to implement processes or functionality for using the blockchain, while still being able to utilize all of the benefits associated with the blockchain.

[0014] The present disclosure proposes a method, device, and system for providing, creating, updating, and / or terminating an event stream implemented using a blockchain, and creating a tamper-proof log or record of events related to the event chain. An event E related to an event stream ES n is identified in the received request and represents the current length of the event stream ES. E n When n = 0, a blockchain transaction including an unconsumed output that is a dust output is created so that E is the first event to create the event stream ES. E n When 0 < n ≤ N and N is the final or maximum value for n, so that E is an event that modifies the event stream ES, the first input that consumes the dust output related to the previous transaction related to the event stream, the unconsumed transaction output that is the dust output related to the current transaction, and the current event E n A blockchain transaction including an unconsumed transaction output associated with the event data representing is created. E nIf n=N, such that n is an event that terminates the event stream ES, a blockchain transaction is created that includes a first input that consumes dust output associated with a previous transaction for the event stream and an unconsumed transaction output associated with a digital asset that exceeds the defined dust output limit. Once the created transaction is accepted and / or submitted to the blockchain, results associated with the transaction are provided in HTTP transmission protocol format. In some embodiments, one or more transactions in the event stream are accepted or are valid transactions for a given event stream but are not immediately submitted to the blockchain. For example, transactions in the event stream are submitted to a block after a given number or transactions or time has passed, i.e., after 25 or so transactions in the event stream have occurred. Transactions may be held in a mempool until a number or time has passed. In other embodiments, transactions in the event stream can be immediately submitted to the blockchain.

[0015] Throughout this specification, the word "comprises" or variations such as "include," "comprises," or "comprising" will be understood to imply the inclusion of a stated element, integer, step, or group of elements, integers, or steps, but not the exclusion of any other element, integer, step, or group of elements, integers, or steps.

[0016] Aspects and embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a schematic diagram illustrating an overview of a platform for multiple blockchain-related services according to a first embodiment. [Figure 2a] 1 is a flowchart illustrating a method for providing a platform of multiple blockchain-related services according to a first aspect, implemented by one or more processors associated with the platform. [Figure 2b] 1 is a flowchart illustrating a method for accessing a platform of multiple blockchain-related services according to a first aspect, implemented by one or more processors associated with a client. [Figure 3] FIG. 1 is a schematic diagram illustrating components of a platform for multiple blockchain-related services according to a first embodiment. [Figure 4] 10 is a flowchart illustrating a method for implementing a data writing service for transactions related to a blockchain according to a second aspect, implemented by one or more processors associated with a platform service. [Figure 5] 10 is a flowchart illustrating a method for creating an event stream associated with a blockchain according to a third aspect, implemented by one or more processors associated with a platform service. [Figure 6] 10 is a flowchart illustrating a method for updating an event stream associated with a blockchain according to a third aspect, implemented by one or more processors associated with a platform service. [Figure 7] 10 is a flowchart illustrating a method for terminating an event stream associated with a blockchain according to a third aspect, implemented by one or more processors associated with a platform service. [Figure 8] 10 is a flowchart illustrating a method for accessing a data writing service for a transaction related to a blockchain according to the second or third aspect, implemented by one or more processors associated with a client. [Figure 9]FIG. 1 is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0018] While the appended claims relate to a third aspect of the present disclosure, which is described in detail below, a detailed discussion of the first and second aspects is provided herein to provide the reader with a full and complete understanding of the claimed aspects and related embodiments of the present disclosure.

[0019] According to a first aspect, the present disclosure provides a computer-implemented method for providing a platform of multiple blockchain-related services, the platform being provided to a plurality of clients, the method being implemented by a platform processor associated with an application programming interface (API).

[0020] Advantageously, the platform processor API is a web-based interactive interface, i.e., in some embodiments, it may be implemented as a web service for one or more clients so that communication may occur over the Internet using standard Internet communication protocols for web-based services. For example, in some embodiments, this allows HTTP messages or requests at the application level or layer between the client and the server (in this case, the platform service), such as HTTP, HTTPS, etc., to be sent and received based on a transport layer protocol, such as TCP / IP. Reference herein to the HTTP transport protocol or HTTP API also encompasses all standard Internet communication protocols, such as TCP / IP, UDP, HTTPS, etc.

[0021] In some embodiments, the platform processor is implemented as an HTTP API endpoint. In some embodiments, the platform processor is implemented as a Representational State Transfer (REST) ​​endpoint. Advantageously, the API may be implemented as a REST endpoint, thereby allowing clients to communicate using standard internet or web-based protocols such as HTTP or HTTPS.

[0022] The method of the first aspect includes receiving a request from a given client of a plurality of clients, the request from the given client relating to a given service of a plurality of services based on a HyperText Transfer Protocol (HTTP) transmission protocol format. Then, based on an identification of the client and / or a determination that the request is valid, the method includes obtaining a destination address associated with the given service. In some embodiments, the destination address may be an IP address or a network address endpoint. For example, it may be a universal resource identifier (URI) of an endpoint and may include a universal resource location (URL) of a web server from which the requested service may be accessed by a payment processor or one or more other entities (including the client) for the requested service.

[0023] In some embodiments, the destination address may be the same endpoint as the platform API endpoint. This may be the case when the platform provides such requested service as a main or core service. In other embodiments, when there are multiple different types of services provided by the platform, each implemented by a different processor or web server, the destination address may be different from the platform API, which may act as a host server for other processors and web servers associated with the platform. In this case, the platform processor comprises or is associated with multiple processors, each configured to implement a given service of the multiple services in the blockchain, and each associated with a particular destination address or endpoint unique to the respective processor.

[0024] The method of the first aspect further includes processing a request for a given service based on at least one blockchain transaction corresponding to the obtained destination address to obtain an output script. In some embodiments, the output script is associated with data related to the requested service, or a result of the requested service is included in a UTXO, including such data or digital assets related to the transaction. In the first aspect, this result associated with the output script is then transmitted to the given (requesting) client in HTTP or a similar transmission protocol format.

[0025] Advantageously, the method of the first aspect of the present disclosure implements a platform provided as an API for one or more clients, thereby enabling one or more processors associated with the clients to sign up for or use web services provided by the platform processor to write or access data to the blockchain. The one or more processors associated with the platform can implement one or more of the provided services using a standards-based interface design, such as, but not limited to, REST (Representational State Transfer), an architectural style for developing web services and web-based interactions. A resource, in the context of a REST API, can be defined as an object having a type, associated data, relationships to other resources, and a set of methods to operate on it. Thus, the platform or service implemented by the platform processor of the first aspect is advantageously provided as an API implementation to access (the state of) a blockchain or distributed ledger, such as the Bitcoin SV (BSV) blockchain, and trigger operations or functions that can modify that state and expose it as a REST API via an application interface. In other words, one or more servers or processors associated with the platform can be considered REST endpoints for one or more clients that choose to use such services. Thus, advantageously, clients can communicate with platform services via HTTP or similar internet commands, and more advantageously, no knowledge of BSV, Bitcoin, blockchain, ECDSA, or other cryptographic key management libraries, or transaction building software such as digital wallet software, is required to be implemented by clients for any of the services provided.A client using one or more processing resources or user terminals can simply register to use the platform via some known authentication technique, such as password-protected authentication or a standard public key infrastructure (PKI) to verify the client's identity. The client should then simply be able to communicate with the platform services via basic HTTP or the like.

[0026] In some embodiments, some examples of blockchain-related services that may be provided via the platform include: A data service for writing / submitting data to the blockchain to change the state of the blockchain, A data service to read / get data that reflects the current state of the blockchain, Services relating to simplified payment verification for blockchain-related transactions; Services related to the management of one or more event streams and / or machine-readable contracts related to a blockchain; Services relating to the management of a digital wallet framework for multiple clients is.

[0027] In embodiments where there are multiple processors or web services associated with the platform processor of the first aspect, the method of the first aspect further includes providing an application programming interface (API) converter for receiving a request from a client in HTTP transport protocol format, converting the received request to a remote procedure call (RPC), and sending the RPC request to a given processor of the multiple processors configured to implement the service identified in the received request. In the reverse flow path, this embodiment includes receiving an associated response from the given processor in RPC format and converting each response to be sent to the client using HTTP or a similar transport protocol.

[0028] This is advantageous because it allows clients to communicate blockchain-related requests via simple HTTP, using a web-based platform API and providing seamless interoperability with any of the nodes or services that implement the services described above but do not communicate using the Internet Protocol communication standard for web services. The API converter implemented in this embodiment is not limited to converting from HTTP to RPC and vice versa, or for that matter, from other web service protocols to alternative communication protocols supported by the platform processor implementing one or more of the above services, the network for a given cryptocurrency, or other possible digital asset. In the reverse flow path, the method of the first aspect also includes receiving responses related to corresponding blockchain transactions from each processor in RPC format and correspondingly converting each response using HTTP for transmission to the client. Thus, advantageous implementation of the proposed interface by the platform processor enables seamless communication for submitting transactions to the blockchain when the client (payer) and the miner use different wireless data communication protocols and mechanisms.

[0029] In some embodiments of the first aspect, the request received from the client is an HTTP GET, HTTP POST, HTTP PUT, or HTTP PATCH request that includes or is associated with a client identifier unique to the given client and a service identifier for the requested given service of the multiple services provided by the platform, as described above. In some embodiments, the result sent to the client is an HTTP POST request based on the client identifier.

[0030] In some embodiments, mechanisms already exist in which memorable, more user-friendly aliases are used instead of complex public addresses for one or more client entities to simplify client addressing for blockchain transactions. Such solutions are proposed in U.S. Patent Application No. 16 / 384696 and UK Patent Application No. 1907180.2, both in the name of nChain Holdings Limited. These documents present an alias-based payment service and associated protocol, called the bsvalias payment service, in which aliases are used to specify destination addresses instead of the client entity's public addresses. Aliases in such systems are typically associated with the domain name of the sending / receiving client entity and may be a URI or email address. Thus, as long as the sender or entity is aware of or has been provided with the alias, this is sufficient for the bsvalias payment system or alias-based addressing mechanism. Messages can be sent to a client's alias using instructions provided in a machine-readable resource, such as a JavaScript Object Notation (JSON) document, stored at a better-known URI or location for bsvalias or other payment services. In some embodiments of the present disclosure, one or more of the multiple clients may have an alias as described above to identify the respective client.

[0031] In a related embodiment, the method of the first aspect includes validating the client based on a client identifier and a record associated with the platform processor, the record corresponding to the client identifier. For example, such a record may be created, stored, or associated with the platform processor upon client sign-up or registration. Then, based on successful validation of the client, determining whether a received request from the client is valid based on the service identifier and attributes or settings included in the respective record. In some embodiments, the attributes or settings may indicate whether a given client is authorized to access all or part of the requested service. For example, one or more levels of permission associated with the client identifier may be provided in the attributes or settings. For example, a given client may be authorized to request a service that reads data on a blockchain related to a particular event, but may not be authorized to modify, delete, or terminate such event, whereas another client may have permission for all actions related to one or more services.

[0032] In some embodiments, verifying the identity of a given client may be based on a digital signature associated with the client. A cryptographic key pair comprising a private key and a public solution (or public address) associated with each client may be used to verify that a request made to a service truly originates from the given client, i.e., that data signed by a private key can only be recovered or verified using the corresponding public solution. When verification is based on a digital signature, standard public key infrastructure (PKI) techniques may be used and implemented.

[0033] In some embodiments of the first aspect, a computer-implemented method for accessing a platform of multiple services, implemented by one or more processors of a given client of the multiple clients, includes obtaining or identifying an application programming interface (API) endpoint associated with one or more processors associated with the platform; and transmitting a request related to a given service of the multiple services, the request including or associated with a client identifier for the given client and a service identifier for the requested given service. As described above, the request is transmitted using Hypertext Transfer Protocol (HTTP) or a similar transport protocol format. The method also includes a result related to an output script of a blockchain transaction associated with the request, the result being provided to the client in HTTP transport protocol format.

[0034] In a second aspect, the present disclosure provides a computer-implemented method for implementing a data writing service, the method being implemented by a platform associated with an application programming interface (API) to allow a client to access the service for writing data to a blockchain. The method of the second aspect includes receiving a request from a client, the request relating to an event stream ES implemented using a blockchain, the request from the client being based on a Hypertext Transfer Protocol (HTTP) transmission protocol format. In some embodiments, the event stream may be tracked or represented as a finite state machine (FSM), such as a deterministic finite automaton (DFA), a well-known computing term that describes a system that uses transition functions or trigger events to transition from one stage to the next, has a finite number of states, and can be in only one state at a given time. In some embodiments, such an event stream is useful for representing control measures or techniques for technological processes. In some embodiments, the event stream may represent or track inputs, states, and / or events associated with a machine-readable contract or smart contract on a blockchain, advantageously recording an immutable record of the contract's past and current states. In some embodiments, the received request from the client includes a trigger event to enable a state transition to occur in a smart contract associated with the event stream.

[0035] The method of the second aspect is to generate an event stream ES i=nThe method includes determining a current state of the event stream ES, where i is an integer from 0 to N, and each integer i represents a given state of the event stream ES, whereby i=0 represents the created event stream ES, i=n represents the event stream ES in its current state in the blockchain, and i=N represents the final state of the event stream ES. In some embodiments, determining the current state may be an index of the current state based on the most recent results associated with the event stream, the results being stored on the blockchain or in one or more separate off-chain storage resources for the event stream. This may be based on an identifier of a previous or prior blockchain transaction associated with the event stream. If there is no previous state identified for the event stream, this results in a determination that the current state is n=0, i.e., a new event stream should be created. In some embodiments, the current state may also be obtained or read from the blockchain. This may be performed by a data reader as described above, which may be a service among multiple services provided by the platform processor.

[0036] In the method of the second aspect, a new event E is generated for the event stream ES based on the received request. n+1 The step of processing the blockchain transaction TX n+1 creating a blockchain transaction TX n+1 is the previous transaction TX n Transaction Output (TXO) from n ) and unspent outputs (UTXOs) n+1 ) is a new event E n In some embodiments, when n=0, there is no input that consumes the previous output. However, there may be other inputs that represent digital assets associated with the event stream ES. The method then n+1and submitting the result to the blockchain.

[0037] Once submitted, the current state of the event stream is updated based on the submitted blockchain transaction, i.e., the state is updated based on the ES i=n =ES n+1 As in, the newly created event E n+1 Based on ES i=n+1 In some embodiments, the updated state is the unspent output of the latest transaction in the event stream, the UTXO n+1 The method then includes sending a result based on the updated current state of the event stream ESn+1, the result being provided based on an HTTP transfer protocol format.

[0038] A second aspect of the present disclosure discusses an implementation of a data writing service implemented by a platform processor, which enables the ability to write data related to real-world processes, such as controlling the state of a smart contract. The platform processor of the second aspect is related to that discussed in the first aspect, and the second aspect discusses one of multiple blockchain services, namely, a service for writing data to a blockchain to change the current state of the blockchain. Because requests and responses are received using an API for the platform, the second aspect provides all of the advantages associated with the first aspect. Additionally, the data writing service advantageously enables one or more clients to transact the state of a blockchain-implemented smart contract simply by extracting triggers or events from effects. Thus, an immutable record of the various stages of a smart contract can be provided by the data writing service of the second aspect.

[0039] A third aspect of the present disclosure relates to the data writing service of the second aspect, as discussed above with respect to services provided in connection with event streams. In this aspect, or techniques for establishing a tamper-proof record or log or certificate verifying the sequential occurrence of events associated with an event stream. Accordingly, in a third aspect, the method of the present disclosure proposes methods, devices, and systems for providing, creating, updating, and terminating event streams that are implemented using blockchain and automatically create a tamper-proof log or record of events associated with an event chain.

[0040] In a third aspect, the present disclosure provides a computer-implemented method for implementing a data writing service for transactions related to a blockchain, the method being implemented by a platform processor associated with an application programming interface (API) to enable a client to access the service to write data to the blockchain. The method of the third aspect includes receiving a request from the client, the request being related to an event stream ES on the blockchain, the request from the client being based on a Hypertext Transfer Protocol (HTTP) transmission protocol format.

[0041] Then, in the received request from the client, an event E n For an event stream ES, n represents the current length of the event stream ES. E nIf n = 0 such that it is the first event to create the event stream ES, for the event stream ES, a first blockchain transaction including a first unconsumed output that is a dust output is created. Blockchain transaction dust in the context of blockchain transactions according to the present disclosure, or simply "dust", is understood to be a consumable transaction regarding a digital asset or cryptocurrency having an output of a low or very small value, that is, the value may be much less than the fee for mining the output in the blockchain. This dust output may be the minimum value of the consumable cryptocurrency or digital asset output. In some embodiments, the funds of the digital asset or cryptocurrency related to such a dust transaction, that is, the one that processes the transfer of the minimum value of the digital asset in its output, may be provided or managed by the platform processor. In other words, the dust output referred to in the present disclosure regarding a blockchain transaction is associated with a digital asset having a value below the value limit regarding the transaction, that is, perhaps the value of the dust output is lower than the mining fee that may be required to consume such a transaction.

[0042] E n If 0 < n < N such that it is the event to modify the event stream ES and N is the final or maximum value regarding n, a first input that consumes the dust output related to the previous transaction regarding the same event stream, a first unconsumed transaction output that is the dust output regarding the current transaction, and the current event E n A current blockchain transaction including the final unconsumed transaction output associated with the event data representing it is created. In some embodiments, the event data is included within a data carrier element. This may be a non-consumable OP-RETURN output of the transaction. In some embodiments, the event E in the final unconsumed transaction output regarding the current blockchain transactionn The event data for includes a hash of the event data, which advantageously keeps the event data contents of the event stream ES private. In some embodiments, it may also include a salt, which is a unique value that may be randomly generated by a platform processor for each transaction associated with the event stream. In some embodiments, the hash of the event data is applied by a platform processor, thereby advantageously allowing a platform service or processor to keep such event data private. In other embodiments, the hash of the event data is applied by a client device before being included in a request received by the platform processor. This advantageously allows a client to keep the events or data related to the events in a request private without sharing it with the platform. In other embodiments, the event data for the event E in the final unconsumed transaction output may also be included. n Event data relating to includes raw event data that is published on the blockchain once written or submitted to the blockchain.

[0043] E nIf n=N, a blockchain transaction is created that includes a first input that consumes a dust output associated with a previous transaction in the event stream, and a first unconsumed transaction output associated with a digital asset that exceeds a defined dust output limit, i.e., exceeds a defined or minimum value of the digital asset or cryptocurrency, such that n=N is an event that terminates the event stream ES. Advantageously, the absence of dust outputs signifies the end of the event stream, since it represents that there is nothing to track in the event stream, i.e., no more events in the sequence. The provision that the first output exceeds the dust limit signals the end of the chain. Furthermore, the final blockchain transaction does not have any event data outputs, i.e., there is no data carrier element, which advantageously signals that this is a data event that terminates the event stream, rather than an event stream that modifies it.

[0044] In any of the three cases for n discussed above, the transaction is submitted to the blockchain and the results associated with the transaction are provided based on the HTTP transfer protocol format. In some embodiments, the events associated with the request, i.e., E0, E n , or E N Each of the events can be a single event associated with the respective request, or two or more events. For example, a request can have E0, E n , or E NEach transaction may contain two or more sub-event data sets. In some embodiments, the results are based on the transaction's event data output or the events associated with the respective transaction. In some embodiments, any returned results or event data may be held in the transaction's non-consumable OP_RETURN output, which is a scripting opcode that can be used to write arbitrary data to the blockchain and also mark the transaction output as invalid. As another example, OP_RETURN is a scripting language opcode for creating a transaction's non-consumable output that can store data and / or metadata within the transaction, thereby immutably recording the metadata in the blockchain. The metadata may include logs or time entries or documents desired to be stored in the blockchain. The event data or results may, in some embodiments, be considered a payload included in the respective transaction's non-consumable output. Such output may be made non-consumable, for example, by an opcode that terminates the output's locking script, such as OP_RETURN described above. However, in other embodiments, the payload or event data may be included in other ways.

[0045] The use of dust outputs in transactions is advantageous and important for maintaining an immutable, continuous record of all transactions that occurred for an event stream. This is because, although all blockchain transactions are time-stamped and order is maintained in the blockchain by posting the transactions to the blockchain, this does not guarantee the preservation of their order. This is because transactions may be mined into blocks at different times. Thus, in a blockchain, only the order of blocks in the chain follows chronological order, not individual transactions. On the other hand, to track, record, and audit the exact order of events for an event stream, which may be a smart contract, the use of dust outputs, which must be consumed by the first input of the next transaction in the sequence, advantageously ensures that the order of transactions is tracked chronologically and a tamper-proof record is created. This is because, once mined into a block, dust payments from the previous transaction to the next transaction in the sequence, consistent with Bitcoin protocol rules, cannot reorder the sequence of embedded data carrier elements (which are the final output in each transaction) and ensure that no insertions or deletions can occur that would change the sequence without immediately revealing that the event stream has been compromised. In some embodiments, Bitcoin's inherent double-spend prevention ensures that the movement of cryptocurrency (e.g., dust) between different addresses, and therefore the associated events, remain in chronological order, thus improving the security of smart contracts on the blockchain, as well as the logging, copying, or duplication of the sequence of event occurrences.

[0046] In some embodiments, a hierarchical deterministic key chain K is determined to be used for requests related to the event stream ES. Such a key chain is unique to a given event stream. Then, K=K n=0From a seed or parent, or master key pair K, a cryptographic private / public key pair may be derived for each associated event, such that n is an integer between 0 and N, each integer n representing the current length or current number of events associated with the event stream ES, and N is the maximum or final value of n. This advantageously ensures that the keys derived for a particular event stream are related to a common master or seed key and may be derived to process each respective event. In this way, advantageously, a lock script associated with the dust output may use the derived key K for the current event. n and the first input is protected using the previous key pair K n-1 This ensures that outputs can only be consumed using the corresponding key pair unique to each previous transaction.

[0047] In some embodiments, the results associated with the event stream ES include: Event E n The transaction identifier that was submitted to the blockchain Merkle inclusion proof of a transaction into a header in the blockchain A copy of the block header containing the transaction The certificate includes a certificate verifying at least one of the following:

[0048] In some embodiments, each of the created transactions may further include other inputs related to digital assets, as discussed above with respect to the third aspect. This may be provided based on an operational float managed by the platform processor. In some embodiments, this may be associated with digital assets, or cryptocurrency resources or funds maintained or managed by the payment processor to cover mining fees for the transaction and one or more other operations for the blockchain, etc. The transaction may also have one or more change outputs related to the digital assets. As described above, the final transaction has all change outputs.

[0049] In some embodiments, the event stream ES may be identified based on a transaction identifier associated with a submitted blockchain transaction. In some embodiments, the event stream ES may also be identified based on a transaction identifier associated with the most recently submitted blockchain transaction.

[0050] In some embodiments, the method includes storing a copy or log of outcome-based records for each event in the event stream ES in an off-chain storage resource. This storage resource may be associated with the platform processor or in a different device, database, or service that can be requested or retrieved from it when requested by a client. Advantageously, the storage of the log associated with the outcome of the event stream is stored separately to avoid the need to download the entire blockchain and sift through the data for any query related to the event stream. The blockchain implementing the event stream itself can be checked in situations during audits or data validation. A backup or another copy can then be used for quick queries.

[0051] Some specific embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which like reference numerals refer to like features and in which:

[0052] First aspect - Platform API for multiple blockchain-related services The platform processor for providing the multiple services described above for the first aspect may be a Platform as a Service (PaaS) and Software as a Service (SaaS) offering that advantageously enables rapid delivery of useful real-world business and technical applications, such as management of software-controlled technical systems or smart contracts using a blockchain network such as the BSV blockchain. An overview of the platform service can be seen in FIG. 1, which shows a high-level overview of the system. The platform service has a platform processor 100 that provides an API 108 through which the services can be accessed by one or more clients.

[0053] The platform services 100 shown in this figure are comprised of three service families, which aim to enable users or organizations to easily and securely utilize the benefits provided by the unique properties of blockchain without actually implementing any blockchain-based software, knowledge, or libraries on the client side.

[0054] These services are a data service 102 aimed at simplifying the use of the chain as a product data ledger; Computation services 104 that aim to provide a generalized computational framework underpinned by digital assets such as Bitcoin SV; and Commerce service offering enterprise-grade capabilities for transacting using digital assets such as Bitcoin SV106 is.

[0055] As described above, the API is implemented as a web service, so that requests can be received from clients at the API via or using the HTTPS protocol. The requested service is then implemented by one or more service modules or processing resources 102-106 using underlying software 110, such as underlying software 110 associated with a blockchain, to implement resources, libraries, and / or key management wallet implementations for creating, processing, and submitting transactions related to the blockchain. Once processed, the transaction can be submitted to the blockchain network 112 (instead of the client implementing any such functionality or transaction library). At most, the client may or can implement a digital wallet or the like associated with cryptocurrency or some other digital asset, although this is not required, as the platform service 100 may also be able to provide and manage digital assets for the client.

[0056] Figure 2a relates to a first aspect of the disclosure and illustrates a computer-implemented method for providing a platform for multiple blockchain-related services, such as platform 100 shown in Figure 1. The method of Figure 2a is implemented by a platform processor associated with an application programming interface (API).

[0057] Step 202a depicts receiving a request from a given client of a plurality of clients. In some embodiments, a client may be one or more computing devices, resources, or processors associated with the client, the client having signed up or registered to access multiple services offered by the platform processor. As noted above, a platform processor may be one or more processors, each providing different types of functionality or services implemented using a blockchain, such as the Bitcoin SV blockchain (e.g., the processor for data, computation, and commerce services seen in FIG. 1). Thus, there may be only one processor for a single service. Because the platform processor is associated with an API endpoint, such as a URI, for the platform, the request from the given client may be based on a standard Internet protocol, such as the Hypertext Transfer Protocol (HTTP) transmission protocol format. In some embodiments, the request may include an identifier for the client as well as an identifier for the requested service.

[0058] In step 204a, the client's identity is checked to verify whether the client is a valid client registered to use the platform processor and the functionality provided thereby. In some embodiments, this may be based on known authentication methods, such as password-protected login authentication. In this case, a record may be created for a given client based on the client identifier or alias and password included in the request. Verification may be based on the password received at the API matching the password in the record. In other embodiments, standard PKI techniques based on cryptographic private / public key pairs may also be used to verify the digital signature present in the request received from the client in step 202a. In this case, the client's identity may be verified by checking whether a request signed with the private key can be successfully recovered or verified using the public key.

[0059] If the client's identity cannot be verified, or if the verification fails, then in step 206a the request is not processed further.

[0060] If the client is successfully verified, the validity of the request for service in step 202a is checked in step 208a to ensure that the given client is indeed authorized to use the requested service. Permissions or attributes for this purpose may be present in the record for the client to indicate one or more types of access levels or services that can or cannot be provided to the respective client.

[0061] If the request is found to be unauthorized or invalid for the requesting client, then in step 210a the request is not processed further.

[0062] It should be understood that the above-described client and / or service validation embodiments, while useful, are not required for the operation of the first aspect. In some cases, only the validation in steps 204a or 208a may be performed. In some cases, no validation is performed. In this case, any client, registered or not, may use the service or platform with appropriate payment for such access.

[0063] In step 212a, a destination address is obtained, which may be an endpoint URI for a server or processor responsible for implementing the service requested in step 202a. In some embodiments where there are multiple platform processors, the host server or platform API may convert the received request into a remote procedure call (RPC) format to be sent to a destination address associated with the processor configured to implement the identified service.

[0064] In step 214a, the requested service is processed by the respective platform processor responsible for it. The blockchain transaction is obtained, read, or generated by the platform processor based on the destination address / endpoint of the responsible processor, and an output script for the transaction is obtained. While FIG. 2a refers to generating a blockchain transaction in this step, it will be understood that the first aspect of the present disclosure is not so limited. If the request in step 202a is to read or obtain data from the blockchain, the transaction may not be generated; it may simply be read or obtained from the blockchain. There may be multiple blockchain transactions or multiple output scripts for one or more of the generated blockchain transactions.

[0065] In step 216a, the output script may include a data output as a result (e.g., there may be a data carrier UTXO), or a result may be obtained based on the transaction identifier or the remaining outputs of the transaction. There may also be a non-consumable OP-RETURN output associated with the transaction from which a result may be obtained.

[0066] In step 218a, results associated with the output script are provided to the given client in HTTP or similar transaction protocol format. In some embodiments, if the responsible processor for the service is located remotely relative to the host platform API, the platform processor receives the response associated with the blockchain transaction from the responsible processor in RPC format. An API converter then converts this into a message that can be sent based on HTTP format before sending it to the client. As noted above, if the client uses an alias addressing service such as bsvalias, the results are sent in an HTTP message addressed to the client's alias in a format dictated by the bsvalias machine-readable resource.

[0067] Figure 2b relates to a first aspect of the disclosure and illustrates a computer-implemented method for accessing a blockchain-related multiple services platform, such as platform 100 shown in Figure 1. The method of Figure 2b is implemented by one or more processors associated with a client.

[0068] In step 202b, an application programming interface (API) endpoint associated with the platform is identified. As mentioned above, this may be an API associated with the host platform processor, and there may be one or more additional processors responsible for executing the service, each with its own service endpoint or destination address.

[0069] In step 204b, the client prepares a request for a service, such as data writing service 102 in Figure 1. In some embodiments, the client includes a client alias or identifier and / or a service identifier in the request so that it can be routed to the correct service endpoint. This is useful for platform processor checks on the validity of the requesting client and the client's authorization to use the requested service.

[0070] In step 206b, since the platform processor is implemented as an HTTP or REST API, the request prepared in step 204b is sent using Hypertext Transfer Protocol (HTTP) or a similar transmission protocol format.

[0071] In step 208b, a result associated with the output script of the blockchain transaction associated with the request is provided from the platform processor, and the result is provided to the client in an HTTP transaction protocol format.

[0072] Advantageously, in the method of the first aspect, requests for the blockchain-based service are sent and received by the client in HTTP transaction protocol format, thereby allowing the client to utilize all of the benefits and services inherent in blockchain without having to implement any transaction functions or blockchain libraries. This is because the services are provided through a platform API, which can be an HTTP or REST API endpoint. For example, the REST API design standard allows for processing and communicating HTTP requests over the Internet using the following HTTP commands, which are all functions required by the client, i.e., to send and receive messages over the Internet. The platform processor implements the commands remotely or separately for the client. [Table 1]

[0073] FIG. 3 provides a more detailed schematic diagram of multiple services related to a blockchain, which may be implemented by a platform 300 associated with an API through which any one or more of the provided services may be accessed. As seen in this diagram, data service 302 may include a data writer 302a and a data reader service 302b. An event stream implementation using data writer service 302a is described in detail in FIGS. 4 through 8 to enable clients to write data to the blockchain in a simple, secure, and optimized manner. Data reader service 302b allows clients to submit queries, which return data to be stored in the blockchain. This may be using filtered streams, where clients may predefine the type of data they want to read from the blockchain ad hoc or periodically, i.e., within a specific time frame, or related to a set of related or unrelated events or documents processed in blockchain 310. A data archiving function allows access to logs of previous transactions related to a specified event or contract.

[0074] Computation services 306 of platform 300 include applications 306a and frameworks 306b related to smart contracts, which in some embodiments may be represented as state machines within blockchain 310. Computation services 306 interact with data services 302 as data must be input for such computations and results provided to clients.

[0075] The commerce service 304 is responsible for providing enterprise-class functionality via the enterprise wallet 304a for transacting over the blockchain 310 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 two or more people, users, or accounts may need to sign off on a transaction that meets defined criteria, i.e., a transaction involving 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 to transfer large amounts of digital assets, such as cryptocurrency or tokens representing another resource. Transfers of these assets may be represented on the blockchain after processing based on criteria applied by such an enterprise wallet implementation.

[0076] SPV services 308 (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 308 allow light clients to verify that transactions are contained within the blockchain without downloading the entire blockchain 310.

[0077] Second aspect - Platform that provides data writing services related to blockchain Figure 4, relating to a second aspect of the disclosure, illustrates a computer-implemented method for providing a data writing service for transactions related to a blockchain, such as data writer 302a shown in Figure 3 of the first aspect. The method of Figure 3 is implemented by a platform processor associated with an application programming interface (API) for the service.

[0078] Step 402 depicts receiving a request from a client, the request associated with an event stream ES implemented using a blockchain. As with the first aspect, the request from the client is in Hypertext Transfer Protocol (HTTP) transmission protocol format. In some embodiments, the event stream is associated with a state machine and represents a machine-readable contract or smart contract implemented as a finite state machine within the blockchain. A finite state machine (FSM) is a well-known mathematical model of computation. An FSM is an abstract machine that can be in exactly one of a finite number of states at any given time. An FSM can change from one state to another in response to some external inputs, and the change from one state to another is called a transition. An FSM may be defined by its states, its initial state, and a list of conditions for each transition. In the Bitcoin SV blockchain, the UTXO set can be thought of as a state machine, where the consumption state of a given output is a function of previous inputs to the transaction (machine). Thus, by replaying all transactions, the current consumption state of any output and the current contents of the UTXO set can be deterministically established using the blockchain. Thus, in the embodiment of Figure 4, the request can be viewed as a request to change the current state of the smart contract, implemented as an event stream ES in the blockchain.

[0079] Step 404 includes a data writer or platform processor for implementing a data writing service to write the event stream ES i=n Let us consider that i is an integer between 0 and N, and each integer i represents a given state of an event stream ES having a finite number of states, whereby i=0 represents the created event stream ES, i=n represents the event stream ES in its current state in the blockchain, and i=N represents the final state of the event stream ES. Thus, the current state of the event stream ES is En.

[0080] Step 406 determines the next or new event E for the event stream ES based on the received request in step 402. n+1 In this embodiment, the new event may be data or a function that triggers a change of state such that the event stream transitions to the next state.

[0081] Step 408 includes generating a blockchain transaction TX by one or more processors associated with the platform processor that implements the data writer. n+1 Next event E n+1 The steps to create a blockchain transaction TX are shown below. n+1 At least, Previous transaction TX n Transaction Output (TXO) from n ) and this input is the TXO from the previous transaction. n An input that consumes an output, New Event E n+1 Represents the unspent outputs (UTXOs) associated with the event data. n+1 ), which in some embodiments is a data output, i.e., represents the data carrier element of the transaction, and There may be additional inputs, such as a funds input to cover network mining fees if necessary, and other outputs, such as a change output for the transaction.

[0082] Step 410 depicts submitting transaction TXn+1 created in step 408 to a blockchain, where the transaction may be submitted to a blockchain such as Bitcoin SV for inclusion in a subsequent block by a miner node or BSV node software associated with the platform processor.

[0083] Step 412 is ES i=n =ES n+1The newly created event E n+1 The current state of the event stream ES based on i=n+1 This indicates that the latest transaction TX submitted to the blockchain on ES is updated to n+1 In some embodiments, the new state corresponds to the last transaction output UTXO n+1 The event information is identified and updated based on the event data output in

[0084] Step 414 is a step of updating the current state ES n+1 The result is provided to the client in HTTP transfer protocol format.

[0085] Third aspect - A platform that provides data writing services for recording event streams related to the blockchain Figures 5, 6, and 7 discuss applications related to implementing event streams, such as those discussed in connection with Figure 4 of the second aspect. The third aspect relates to techniques for establishing an immutable, continuous log or record of an event stream ES up to its current state on a blockchain. In some embodiments, the log may be provided or stored off-chain in addition to being stored on the blockchain. Because the state of an event stream is based on inputs and outputs associated with transactions, the techniques described below for the third aspect present a way to establish an immutable, chronological log of all transactions associated with an event stream on a blockchain. The event stream may represent continuous inputs applied to a smart contract implemented using an FSM, DFA, or the like.

[0086]

[0033] Figure 5, relating to a second aspect of the present disclosure, illustrates a computer-implemented method for providing data writing services for transactions related to a blockchain, such as data writer 302a shown in Figure 3 of the first aspect. The method of Figure 5 is implemented by a platform processor in association with an application programming interface (API). The method relates to creating a new event stream.

[0087] Step 502 shows receiving a request from a client, the request being to create a new event stream ES using the blockchain. As in the first and second aspects, the request from the client is in a Hypertext Transfer Protocol (HTTP) transmission protocol format.

[0088] Step 504 depicts determining a hierarchical deterministic (HD) key chain K to be used with the new event stream ES to be created. In some embodiments, this may be implemented by an HD wallet implementation associated with the platform processor to generate a hierarchical tree-like structure of keys starting from a seed, parent, or master key based on the well-known BIP21 protocol. The HD key creation and transfer protocol greatly simplifies key generation, enables the creation of child accounts that can operate independently, and gives the parent account the ability to monitor or control its children even if the child account is compromised. The HD protocol uses a single root seed to create a hierarchy of child, grandchild, and other descendant keys, each with a distinct deterministically generated integer value. Each child key also obtains a deterministically generated seed, called a chaincode, from its parent. In this way, any compromise of one chaincode does not necessarily compromise the integer sequence for the entire hierarchy. In addition to the above advantages, in this embodiment, this key generation is performed by the platform processor, thus removing the resources and functionality of this key generation from the client. Therefore, the HD wallet does not need to be implemented by the client. In step 504, the key chain K is generated as follows: K = K n=0 to N where n is an integer between 0 and N, each integer n representing the current length or current number of events associated with the event stream ES, and N representing the maximum or final value of n.

[0089] Step 506 depicts identifying or obtaining data related to the first event E0, which is for a new event stream ES to be created in the blockchain based on the event data in the request received in step 502.

[0090] Step 508 depicts creating a first blockchain transaction TX0 for the new event stream ES, where n=0, by one or more processors associated with the platform processor implementing the data writer.

[0091] Step 510 determines whether the output of the blockchain transaction TX0 created in step 508 is a dust output, and whether the output of the blockchain transaction TX0 is a dust output. 0_dust ), where the dust output is associated with a lock script protected with the first derived key pair K0 in the series of keys derived from the HD Key Chain K in step 504. The dust output is associated with a (digital asset) value that is below a defined threshold value for the transaction or has a defined minimum value, i.e., lower than the mining fee required to consume such transaction. There may also be other inputs related to digital assets related to operational float or digital assets or cryptocurrency assets maintained with or associated with the payment processor. It is also possible to have other outputs in a transaction that are digital asset modified outputs.

[0092] Thus, in some embodiments, the creation template for a blockchain transaction to create an event stream according to this embodiment requires that the first input must be greater than dust. This advantageously indicates that there are no previous entities in the event stream and that this is the first entity. The creation template also specifies that there is no data carrier or data output (and therefore no OP_RETURN) because the first output of the template is dust and there is no event data associated with the creation state other than the creation of the new event stream ES. In some embodiments, an OP_RETURN is included for the creation frame, but it does not carry any event data. It may carry metadata describing the parameters of the newly created stream. Examples of example metadata may include details such as public or notarized properties, time of writing to the blockchain, time the event is first accepted, time the event is no longer accepted, geographic region where backing or associated data is stored, maximum size of allowable data, sequence number, etc.

[0093] Step 512 depicts submitting transaction TX0 to a blockchain, where the transaction may be submitted to a blockchain such as Bitcoin SV for inclusion in a subsequent block by a miner node or BSV node software associated with the platform processor. In some embodiments, once mined, the transaction identifier TX0 may be used to uniquely identify the newly created event stream ES.

[0094] Step 514 indicates sending results associated with the event stream ES created in TX0 to the client, where the results are provided in HTTP transmission protocol format. Results associated with the event stream may be copied or stored separately from the blockchain. In some embodiments, the creation of the event stream may be decoupled from submission to the blockchain for on-chain settlement. In this case, an event stream ID unique to each event stream may also be used and provided in the results to the client instead.

[0095] Figure 6, relating to a third aspect of the present disclosure, illustrates a computer-implemented method for providing data writing services for transactions related to a blockchain, such as data writer 302a shown in Figure 3 of the first aspect. The method of Figure 6 is implemented by a platform processor associated with an application programming interface (API). The diagram relates to a request to append a new event to an existing event stream ES on the blockchain.

[0096] Step 602 shows receiving a request from a client, where the request is to modify an existing stream ES identified in the request and implemented in the blockchain. The request from the client is in HyperText Transfer Protocol (HTTP) transmission protocol format, as in the first and second aspects. As discussed in connection with step 504 of FIG. 5, the event stream ES on the blockchain is stored in a manner such that K=K n=0 to N where n is an integer from 0 to N, each integer n being the current length or current number of events associated with the event stream ES, and N representing the maximum or final value of n. In some embodiments, an authentication and authorization check is performed, which may be a test for the presence of an API access token, or a session check or a password / digital signature test, or any other suitable method for validating the client or the service request made.

[0097] In step 604, the current length n of the event stream ES is determined.

[0098] Step 606 indicates n identifying or obtaining data related to event E, which is the event that should currently be appended or added to the event stream ES on the blockchain based on the event data in the request received in step 602.

[0099] In step 608, the previous blockchain transaction TX n-1 related to the event stream ES is identified. Once identified, the key pair K n-1 related to the identified previous transaction TX n-1 is determined. As described above, this is based on the same seed key pair K set in step 602.

[0100] In step 610, the key pair K n for the current event E n is derived from the seed key pair K.

[0101] Step 612 indicates that one or more processors associated with the platform processor implementing the data writer create a current blockchain transaction TX n for the new event stream ES, where 0 < n < N. The blockchain transaction TX n created for the current event E n to be added to the event stream ES is the first input that consumes the dust output related to the previous transaction TX n-1 where the consumption is permitted using the obtained key pair K n-1 for the previous transaction obtained in step 608, as the first input, and the current transaction TXn The first unspent transaction output (UTXO) is the dust output for n_dust ) wherein the dust output is the key pair K derived from step 610 n a first unspent transaction output associated with the lock script protected using Current Events n The event data represents the final unspent transaction output (UTXO) associated with the event data. n_data )and Includes:

[0102] As noted above, a dust output is associated with a (digital asset) value that is below a defined limit or has a defined minimum value for the transaction. There may also be other inputs related to the digital asset based on the operational float. This float may be controlled by the platform processor. There may also be other outputs within a transaction that are digital asset change outputs.

[0103] Thus, in some embodiments, the update template for a blockchain transaction to update an event stream according to this embodiment is one in which the first input must be dust and the first output must be dust. This is to advantageously indicate the presence of a previous entry in the event stream. This also indicates that the event in En in question (the current or current event data) comes after the previous transaction or state. Thus, the transaction advantageously follows the dust chain and comes before the next state. The update template includes a data carrier, i.e., a data output carrying the event data or result related to the current event or state. This may be a non-consumable OP_RETURN output.

[0104] The use of dust outputs in transactions is advantageous in maintaining an immutable, continuous record of all transactions that occur to the event stream ES in the blockchain. This is because, by posting a transaction to the blockchain, all blockchain transactions are time-stamped and order is maintained in the blockchain, but this does not guarantee preservation of their order, as transactions may be mined into blocks at different times. The use of a dust output from a previous transaction being consumed as the first input of a current transaction ensures a clear, continuous, and tamper-proof record of the event stream in chronological order, if the consumption is based on the respective unique keys associated with each transaction's lock / unlock scripts.

[0105] Step 614 is to n to a blockchain, where the transaction may be submitted to a blockchain such as Bitcoin SV for inclusion in a subsequent block by a miner node or BSV node software associated with the platform processor. In some embodiments, once mined, the transaction identifier may be used to uniquely identify the event stream ES.

[0106] Step 616 is TX n , which indicates sending results related to the event stream ES created in to the client, the results being provided in HTTP transmission protocol format. The results may be copied or stored separately from the blockchain. In some embodiments, this may be based on the event data in the final unconsumed transaction output (UTXOn_data). In some embodiments, the event E in (UTXOn_data) nThe event data for event E includes a hash of the event data, thereby ensuring that it is kept private by the platform processor. The hash may be applied by the platform processor or by the client, i.e., in some implementations, n may be applied prior to generating the event data associated with the request received at the platform processor in step 602. When applied by a client, the event data in the request is private even before it reaches the platform processor. In other implementations, the event data may be provided as publicly available raw data from the blockchain.

[0107] Figure 7, related to a third aspect of the present disclosure, illustrates a computer-implemented method for providing data writing services for transactions related to a blockchain, such as data writer 302a shown in Figure 3 of the first aspect. The method of Figure 7 is implemented by a platform processor associated with an application programming interface (API). The request in Figure 7 is to terminate an existing event stream on the blockchain.

[0108] Step 702 shows receiving a request from a client, the request relating to the termination of an existing event stream ES implemented using a blockchain. The request from the client is in the HyperText Transfer Protocol (HTTP) transmission protocol format, as in the first and second aspects. As discussed in connection with step 504 of FIG. 5, the event stream ES on the blockchain is n=0 to Nwhere n is an integer between 0 and N, each integer n representing the current length or current number of events associated with the event stream ES, and N representing the maximum or final value of n. In some embodiments, an authentication and authorization check is performed, which may be a test for the presence of an API access token, or a session check or a password / digital signature test, or any other suitable method for validating the client or the request made.

[0109] In step 704, the current length N of the event stream ES is determined.

[0110] Step 706 depicts identifying or obtaining data related to the final event EN, which is for the event that is currently to be added or appended to the event stream ES on the blockchain based on the event data in the request received in step 702.

[0111] In step 708, a previous blockchain transaction TX associated with the event stream ES is N-1 Once identified, the identified previous transaction TX N-1 The key pair K associated with N-1 is determined. As above, this is based on the same seed key pair K that was established in step 702.

[0112] In step 710, the current event E N The key pair K for N is derived from the seed key pair K.

[0113] Step 712 includes, by one or more processors associated with the platform processor implementing the data writer, generating a current blockchain transaction TX for the new event stream ES. Nwhere n=N. The blockchain transaction TX created for the current event EN to terminate the event stream ES. N teeth, Previous transaction TX N-1 a first input that consumes a dust output associated with the key pair K obtained for the previous transaction obtained in step 708; N-1 a first input, which is allowed using The first unspent transaction output (UTXO) associated with a digital asset that exceeds the defined dust output limit. N )and Includes:

[0114] For a final event, all transaction outputs return change. There is no dust output, as there is no requirement or need to track the next stage of a terminated event stream. Therefore, when n=N, no dust output is provided by the platform processor. In other words, the output may be considered a change output (digital asset payment) associated with the event stream ES. This advantageously marks or indicates the final end state of the event stream being tracked. In some embodiments, because the event or contract is in a terminated state, there is no event data or data carrier element for the output, i.e., there is no OP_RETURN associated with the event data. Therefore, separate dust and data carrier outputs are not generated to terminate the event stream ES; the first output, along with the absence of an event data output that also indicates termination, exceeds the dust limit, signaling the end of the event stream on the blockchain. In embodiments where metadata is present in the OP_RETURN instead of event data, this metadata may be useful to the validating entity. There may be other inputs or change outputs associated with digital assets from the operational float. In some embodiments, the value of the dust-related digital asset set out in connection with FIGS. 5 and 6 may simply be added to one or more other outputs.

[0115] Thus, in some embodiments, a close template for a blockchain transaction to terminate an event stream according to this embodiment is one in which the first input must be dust, like the first input of the update template in Figure 6. The first output must not be dust, which advantageously acts as an end-of-ledger marker and further distinguishes the close template from the update template. As with the create template in Figure 5, there may be no data carrier for the event data, but OP_RETURN may include metadata in the close template.

[0116] Step 714 is to N to the blockchain, where the transaction may be submitted to Bitcoin, such as the Bitcoin SV network, for inclusion in a subsequent block by a miner node or BSV node software associated with the platform processor.

[0117] Step 716 is TX N , and the results are provided in HTTP transmission protocol format.

[0118] Figure 8 relates to a third aspect of the disclosure and illustrates a computer-implemented method for accessing a platform or data writing service for writing data to an event stream associated with a block, such as platform 100 shown in Figure 1 or platform 300 in Figure 3. The method of Figure 8 is implemented by one or more processors associated with a client.

[0119] An application programming interface (API) endpoint associated with the platform is identified in step 802. As previously mentioned, this may be an API associated with the host platform processor, and there may be one or more additional processors responsible for implementing the service, each having a service endpoint or destination address.

[0120] In step 804, a client prepares a request to a service, such as data write service 302 in Figure 3. The request is associated with one or more events related to the event stream ES in the blockchain. The client in some embodiments includes a client alias or identifier and / or a service identifier in the request so that the request can be routed to the correct service endpoint and so that the platform processor can check the validity of the requesting client and the client's authorization to use the requested service.

[0121] In step 806, the platform processor is implemented as an HTTP or REST API, so the request prepared in step 804 is sent using Hypertext Transfer Protocol (HTTP) or a similar transmission protocol format.

[0122] In step 808, the event E in the request n A result associated with the output script of the blockchain transaction associated with the platform processor is received. The result is provided to the client in an HTTP transmission protocol format. In some embodiments, the result may be stored within the platform processor or in a log separate from the blockchain associated with the platform processor.

[0123] Advantageously, the implementation of the event stream and its continuous log associated with the blockchain, as implemented by the method of the third aspect of the present disclosure, provides guarantees regarding the immutability of events and the immutability of event ordering.

[0124] When written, it can be written in the following way: Change the content of the event; Rearranging the order of events, Inserting events at the beginning or middle of a stream; Delete events from anywhere in the stream Attempts to tamper with the event stream are prevented or revealed in either case.

[0125] In other words, the method according to the third aspect comprises determining the following attributes associated with the event stream: that individual entries in the event stream have not been modified since they were written, No entries have been inserted between previous consecutive entries, The entry has not been deleted, Entries are not sorted Make it provable.

[0126] These properties and advantages have many practical applications, from audit / compliance logs, to state machine replication, to more efficient, tamper-resistant, and accurate ways to read and write data to the blockchain for all clients.

[0127] An example of an event stream where capturing an event log is useful is an application that tracks and records events in games such as Noughts O and Crosses X, which use blockchain.

[0128] For example, suppose a game with n=4 (five states from 0 to 4) is in the following states: [Table 2]

[0129] As the game progresses, a log based on blockchain transactions may be recorded according to the method of the third aspect as follows: [Table 3]

[0130] Consider that there are attempts to tamper with or modify the copy of the log maintained for this sequence, such as inserting a different entry for the outcome when n=4, so that the log does not reflect the actual state of the game, as shown below. [Table 4]

[0131] This would be immediately identified from a check or audit of an automatically generated continuous log of the event stream on the blockchain as an input for a transaction consuming dust output for transactions where n=3 does not verify. It will be appreciated that if such games involve financial transactions (e.g., paying to play), there may be a desire from players to check the authenticity of those game logs and whether they adhere to the odds or difficulty advertised by a given game provider. By storing individual game entries (or hashes thereof) for a given game in the event stream as described above, players can be assured that in-game events can be checked and verified independently of any internal systems maintained by the game provider.

[0132] It will be further understood that each event in a given event stream need not correspond to an individual event occurring within a game session. An event stream may be defined for any log of events where an accurate, sequential, and tamper-proof log of said events is desirable. Examples of events in a given event stream may include, for example, the inputs and / or outputs of a given smart contract executed locally or remotely (preferably off-chain), messages sent between two or more participants of a given offline messaging conference, weather, physical measurements performed by sensors or IoT devices to measure the location of vehicles, goods, people, etc., drug / medicine tracking, including manufacturer, transportation, dispenser location, prescribed dosage, recipient information, etc., amounts credited and / or debited to an account (regardless of whether the account is credited with cryptocurrency or fiat currency), changes in exchange rates, execution of a trade, a request to purchase goods or shares, etc. Ultimately, the context in which an event stream is generated and used is at the discretion of the parties using the platform processor to generate such event streams.

[0133] Turning now to FIG. 9 , an exemplary 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 illustrated and described above. For example, the computing device 2600 may be configured to be used as one or more components of the illustrated DBMS, or the computing device 2600 may be configured to be a client entity associated with a given user, where the client entity makes database requests to a database managed by the DBMS of FIG. 9 . Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 9 , the computing device 2600 may include one or more processors (collectively labeled 2602) having one or more levels of cache memory and a memory controller configured to communicate with a storage subsystem 2606, which includes a main memory 2608 and persistent storage 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 related to 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.

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

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

[0136] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface for receiving data from and transmitting data to other systems from 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 they may be able to send data to and receive data from the device while at a remote location, such as a data center.

[0137] The 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 touchscreen 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 encompass all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0138] 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. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a 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 computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface that facilitates user interaction with applications that execute the described processes and variations thereof, when such interaction may be appropriate.

[0139] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide the functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, may provide the functionality of one or more embodiments of the present disclosure, may be stored within the storage subsystem 2606. These application modules or instructions may be executed by the one or more processors 2602. The storage subsystem 2606 may further provide 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 persistent storage 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid-state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM, DVD, or Blue-Ray) with associated removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments as described in this disclosure, as well as data related to transactions and blocks as described in this disclosure.

[0140] The computing device 2600 may be of various types, including a portable computer 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 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). A device that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. The device may thus be configured to convert optical signals into electrical signals that may be transmitted through ports connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 shown in FIG. 9 is intended only as a specific example to illustrate a preferred embodiment of the device. Many other configurations are possible, having more or fewer components than the system shown in FIG. 9.

[0141] Enumerated exemplary embodiments To better illustrate, explain, and understand the claimed aspects and embodiments, the present disclosure will now be discussed based on the following clauses related to the above aspects, which are provided herein as exemplary embodiments.

[0142] 1. A computer-implemented method for providing a platform for multiple blockchain-related services, the platform being provided to multiple clients, the method being implemented by a platform processor associated with an application programming interface (API), the method comprising: receiving a request from a given client of the plurality of clients, the request relating to a given service of the plurality of services, the request from the given client being based on a Hypertext Transfer Protocol (HTTP) transmission protocol format; obtaining a destination address associated with the given service based on the client's identity and / or a determination that the request is valid; Processing a request for a given service based on at least one blockchain transaction corresponding to the obtained destination address to obtain an output script; sending a result associated with the output script to a given client, the result being provided based on an HTTP transmission protocol format; Including, Computer-implemented methods.

[0143] 2. The method described in clause 1, wherein the platform processor is implemented as an HTTP API endpoint.

[0144] 3. The method of clause 2, wherein the platform processor is implemented as a Representational State Transfer (REST) ​​endpoint.

[0145] 4. The method of any one of clauses 1 to 3, wherein the platform processor comprises or is associated with a plurality of processors, each of the plurality of processors configured to implement a given service of a plurality of services on the blockchain, and each of the plurality of processors is associated with a particular destination address or endpoint unique to the respective processor.

[0146] 5. The platform processor is associated with an API converter, and the API converter: receiving a request from a given client in HTTP transmission protocol format; converting the received request into a remote procedure call (RPC) format and sending the RPC request to a given processor of the plurality of processors that is configured to implement a given service identified in the received request; receiving a response from a given processor in an RPC format related to at least one blockchain transaction; converting each response to be sent to the client using the HTTP transmission protocol; configured to run 6. The method according to any one of clauses 1 to 4.

[0147] 6. The method of any one of clauses 1 to 5, wherein the received request is an HTTP GET or POST or PUT or PATCH request that includes or is associated with a client identifier for a given client and a service identifier for a given service requested, and the result sent to the client is an HTTP POST request based on the client identifier for the given client.

[0148] 7. Validating the client based on a client identifier and a record corresponding to the client identifier, the record being associated with the platform processor; determining, based on successful validation of the client, whether the request received from the client is valid based on attributes or settings contained within the respective record; 6. The method according to clause 5, comprising:

[0149] 8. The method of clause 6 or 7, wherein the client identifier is an alias provided for the given client, the alias is unique to the given client and is provided by an alias-based addressing service, the addressing service having machine-readable resources accessible from a defined or known location, and the machine-readable resources include one or more capabilities relevant to the given client.

[0150] 9. The method of clause 8, wherein the alias is associated with a domain name for a given client.

[0151] 10. The Platform provides the following services implemented using blockchain, namely: A data service for writing / submitting data to the blockchain to change the state of the blockchain, A data service to read / get data that reflects the current state of the blockchain, Services relating to simplified payment verification for blockchain-related transactions; Services related to the management of one or more event streams and / or smart contracts related to the blockchain; Services related to the management of a digital wallet framework for multiple clients related to blockchain including at least one or more of 10. The method according to any one of clauses 1 to 9.

[0152] 11. A computer-implemented method for accessing a platform of multiple blockchain-related services, the platform being provided to a plurality of clients, the method being implemented by one or more processors of a given client of the plurality of clients, the method comprising: obtaining or identifying application programming interface (API) endpoints associated with one or more processors associated with the platform; transmitting a request related to a given service of the plurality of services, the request including or associated with a client identifier for the given client and a service identifier for the given requested service, the request being transmitted based on a Hypertext Transfer Protocol (HTTP) transmission protocol format; receiving a result associated with an output script of a blockchain transaction associated with the request, the result being provided to the client based on an HTTP transmission protocol format; Including, Computer-implemented methods.

[0153] 12. A computer-implemented method for implementing a data writing service for a transaction related to a blockchain, the method being implemented by a platform processor associated with an application programming interface (API), the method comprising: receiving a request from a client, the request relating to an event stream ES implemented using blockchain, the request from the client being based on a Hypertext Transfer Protocol (HTTP) transmission protocol format; Event Stream ES i=n determining a current state of the event stream ES, where i is an integer between 0 and N, each integer i representing a given state of the event stream ES, i=0 representing the created event stream ES, i=n representing the event stream ES in its current state in the blockchain, and i=N representing the final state of the event stream ES; New Event E on Event Stream ES n+1 based on the received request, Blockchain transaction TX n+1 A step of creating a blockchain transaction TX n+1 But the previous transaction TX n Transaction Output (TXO) from n ) and a new event E n+1 Represents the unspent outputs (UTXOs) associated with the event data. n+1 ) Transaction TX n+1 and submitting the and processing the Including, In response to said submission, the method comprises: i=n =ES n+1so that, for the newly created event E n+1 Based on, update the current state of the event stream to ES i=n+1 and the step of The updated current state ES n+1 The step of sending the result based on, where the result is provided based on the HTTP transmission protocol format including A computer-implemented method.

[0154] 13. A computer-implemented method for implementing an event stream related to a blockchain, the method being implemented by a platform processor related to an application programming interface (API), the method being The step of receiving a request related to the event stream ES from a client, where the request is received based on the hypertext transfer protocol (HTTP) transmission protocol format, and the step of Determining the current length n of the event stream ES and including, if n = 0, the method being The event E related to the event stream in the received request n Identifying as the first event for creating the event stream ES, and The first unspent output UTXO which is dust output 0_dust Processing the received event E by creating a blockchain transaction including n and the step of including, if 0 < n < N and N is the final value or the maximum value, the method being The event E related to the event stream in the received request n Identifying as the current event for modifying the event stream ES, and Processing the received event E n by creating a blockchain transaction, where the blockchain transaction is a first input that consumes a dust output associated with a previous transaction on the event stream ES; The first unspent transaction output UTXO, which is the dust output n_dust and, Current Events n The last unspent transaction output UTXO associated with the event data representing n_data and Including steps and and when n=N, the method comprises: Event E on the event stream in the received request n as the final event for creating a finished event stream ES; Received event E n by creating a blockchain transaction, the blockchain transaction comprising: a first input that consumes a dust output associated with a previous transaction on the event stream ES; The last unspent output UTXO associated with a digital asset that exceeds a defined dust output value N and Including steps and wherein the method comprises: submitting the created transaction to the blockchain; sending results related to the event stream ES to the client in TX0, the results being provided in an HTTP transmission protocol format; Including, Computer-implemented methods.

[0155] 14. A computer-implemented method for creating an event stream associated with a blockchain, the method being implemented by a platform processor associated with an application programming interface (API), the method comprising: receiving a request from a client relating to a new event stream ES, the request being received based on a HyperText Transfer Protocol (HTTP) transmission protocol format; determining a hierarchical deterministic key chain K to be used in the new event stream ES, the key chain K being derived from the selected parent key pair such that K=K n=0 to N n is an integer between 0 and N, each integer n represents the current length or current number of events associated with the event stream ES, and N is a maximum or final value of n; Creating a first blockchain transaction TX0 for the new event stream ES, where n=0, and the blockchain transaction comprises: The first unspent transaction output (UTXO) is the dust output. 0_dust ), wherein the dust output is associated with a lock script protected using a key pair K0 originally derived from a key chain K; submitting transaction TX0 to the blockchain; sending results related to the created event stream ES to the client in TX0, the results being provided in an HTTP transmission protocol format; Including, Computer-implemented methods.

[0156] 15. A computer-implemented method for updating an event stream associated with a blockchain, the method being implemented by a platform processor associated with an application programming interface (API), the method comprising: receiving a request from a client to update an existing event stream ES associated with the blockchain, the request being received based on a HyperText Transfer Protocol (HTTP) transmission protocol format, and the event stream ES being updated such that K=K n=0 to Nassociated with the key chain K such that n is an integer from 0 to N, each integer n representing the current length or current number of events associated with the event stream ES, and N being the maximum or final value of n, a step, determining the current length n of the event stream ES, obtaining the current event E to be added to the event stream ES n from the request, identifying the previous blockchain transaction TX n-1 associated with the event stream ES, obtaining the key pair K n-1 associated with the identified previous transaction TX, n-1 deriving the key pair K for the current event E, n creating the current blockchain transaction TX n for the current event E, where 0 < n < N and the current blockchain transaction is the first input consuming the dust output associated with the previous transaction TX, the consumption being approved using the obtained key pair K n for the previous transaction, n a first unspent transaction output (UTXO the first input consuming the dust output associated with the previous transaction TX, the consumption being approved using the obtained key pair K n-1 for the previous transaction, n-1 a first unspent transaction output (UTXO the dust output associated with the current transaction TX, n the first unspent transaction output (UTXO n_dust ]]) being the dust output associated with the current transaction TX, the dust output being associated with a lock script protected using the derived key pair K n a first unspent transaction output (UTXO n_dust ) and the final unspent output (UTXO n ) associated with the event data representing the current event E, n_data and including, a step, the transaction TX nto the blockchain; sending a result related to the updated event stream ES to the client, the result being provided based on an HTTP transmission protocol format; Including, Computer-implemented methods.

[0157] 16. Current Blockchain Transaction TX n The last unspent transaction output (UTXO) n_data Event E in n 16. The method of claim 15, wherein the event data relating to the event includes a hash of the event data.

[0158] 17. The method of clause 16, wherein the hash of the event data is applied by a platform processor.

[0159] 18. The method of clause 16, wherein a hash of the event data is applied by a client device before being included in a request received by a platform processor.

[0160] 19. Current Blockchain Transaction TX n The last unspent transaction output (UTXO) n_data Event E in n 16. The method of clause 15, wherein the event data relating to comprises raw event data.

[0161] 20. A computer-implemented method for terminating an event stream associated with a blockchain, the method being implemented by a platform processor associated with an application programming interface (API), the method comprising: receiving a request from a client to terminate an existing event stream ES associated with the blockchain, the request being received based on a HyperText Transfer Protocol (HTTP) transmission protocol format, and the event stream ES being such that K=Kn=0 to N n is an integer between 0 and N, each integer n representing the current length or current number of events associated with the event stream ES, and N is the maximum or final value of n; determining the current length n=N of the event stream ES; The final event E to be added to the event stream ES N from the request; Previous blockchain transaction TX associated with event stream ES N-1 and identifying Previous transaction TX N-1 The key pair K associated with N-1 obtaining a Final Event E N The key pair K for N and deriving The final event E to be added to the event stream ES N Final blockchain transaction TX N a final blockchain transaction, Previous transaction TX N-1 a first input that consumes a dust output associated with a key pair K obtained for a previous transaction; N-1 a first input, which is validated using The first unspent transaction output (UTXO) associated with a digital asset that exceeds the defined dust output limit. N )and and Transaction TX N to the blockchain; sending a result related to the finished event stream ES to the client, the result being provided based on an HTTP transmission protocol format; Including, Computer-implemented methods.

[0162] 21. The results related to the event stream ES are as follows: Event E n the transaction identifier that was submitted to the blockchain; Merkle inclusion proof of the transaction to the header in the blockchain, A copy of the block header containing the transaction including a certificate verifying at least one of 19. The method according to any one of clauses 12 to 19.

[0163] 22. The method of any one of clauses 12 to 21, wherein the submitting step includes the step of including the created transaction in a subsequent block associated with the blockchain to be mined.

[0164] 23. The created blockchain transaction is Inputs related to digital assets; one or more change outputs associated with the digital asset; further comprising: 23. The method according to any one of clauses 12 to 22.

[0165] 24. The method set forth in clause 23, in which the Digital Assets are associated with the operational float.

[0166] 25. The method of any one of clauses 12 to 24, comprising identifying the event stream ES based on a transaction identifier associated with the submitted blockchain transaction.

[0167] 26. The method of any one of clauses 12 to 25, comprising identifying a state associated with the event stream ES based on a transaction identifier associated with the submitted blockchain transaction.

[0168] 27. The method of any one of clauses 12 to 26, wherein an event stream is used to represent a smart contract on a blockchain.

[0169] 28. The method of clause 27, wherein the smart contract is implemented as a finite state machine (FSM).

[0170] 29. The method of any one of clauses 13 to 28, comprising storing in an off-chain storage resource a copy or record or log of the outcome for each event in the event stream.

[0171] 30. A computer-implemented method for writing data associated with an event stream into a blockchain, the method being implemented by one or more processors of a given client of a plurality of clients, the method comprising: obtaining or identifying an application programming interface (API) endpoint associated with one or more processors associated with the platform for providing a data writing service; One or more events E associated with the event stream n transmitting a request for the service, the request being transmitted in accordance with a HyperText Transfer Protocol (HTTP) transmission protocol format; Requested event E n receiving a result related to an output script of a blockchain transaction related to the transaction, wherein the result is received based on an HTTP transmission protocol format; Including, Computer-implemented methods.

[0172] 31. The request is made in response to event E. n Event E to contain hashed event data about n 31. The method of clause 30, comprising applying a hash function to event data relating to

[0173] 32. A computing device comprising a processor and a memory, wherein the memory includes executable instructions that, upon execution by the processor, cause the device to perform a computer-implemented method described in any one of clauses 1 to 10 and 12 to 29, and wherein the computing device is associated with a platform processor.

[0174] 33. A computing device comprising a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform a computer-implemented method described in any one of clauses 11, 30, or 31, and the computing device is associated with a client.

[0175] 34. A computer system comprising at least one platform processor communicatively coupled to at least one client via a wireless communications network, wherein the at least one platform processor is associated with an application programming interface (API) endpoint for processing HTTP requests from the at least one client, the at least one platform processor being implemented in accordance with the computing device described in clause 32, and the at least one client being implemented in accordance with the computing device described in clause 33.

[0176] 35. A computer-readable storage medium having stored thereon executable instructions which, when executed by a computer processor, cause the computer to perform the method of any one of clauses 1 to 31.

[0177] The above aspects and embodiments illustrate, rather than limit, the present disclosure, and it should be noted that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present disclosure, as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the scope of the claim. The use of terms such as "comprising" and "comprises" does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. As used herein, "comprising" means "including or consisting of," and "comprising" means "comprising or consisting of." A reference to an element in the singular does not exclude a reference to a plural of such element, and vice versa. The present disclosure may be implemented by hardware comprising several distinct elements and by a suitably programmed computer. In a device claim enumerating several means, these means may be embodied by one and the same item. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage. [Explanation of symbols]

[0178] 100 Platform Processors, Platform Services, Platform 102 Data Services, Service Modules or Processing Resources 104 Computational Services, Service Modules or Processing Resources 106 Commerce Services, Service Modules or Processing Resources 108 API 110 Underlying Software 300 Platform 302 Data services, data writing services 302a Data writer services, data writers 302b Data Reader Service 304 Commerce Services 304a Enterprise Wallet 306 Computational Services 306a Application 306b Framework 308 SPV Services 310 Blockchain 2600 Computing Devices 2602 processor, cache memory 2604 Bus Subsystem 2606 Storage Subsystem 2608 main memory 2610 Persistent Storage 2612 User Interface Input Device 2614 User Interface Output Device 2616 Network Interface Subsystem 2618 Dynamic Random Access Memory (DRAM) 2620 Read-Only Memory (ROM)

Claims

1. A computer-implemented method for implementing an event stream related to a blockchain, the method being implemented by a platform processor related to an application programming interface (API), the method comprising: Receiving, from a client, a request related to an event stream ES, the request being received based on a hypertext transfer protocol (HTTP) transmission protocol format; Determining a current length n of the event stream ES; wherein when n = 0, the method comprises: An event E for the event stream in the received request n as a first event for creating said event stream ES; The first unspent output, the dust output, is a UTXO. 0_dust The received event E is then processed by creating a blockchain transaction including n and a step of processing wherein when 0 < n < N and N is a final value or a maximum value, the method comprises: An event E for the event stream in the received request n as a current event for modifying said event stream ES; The received event E n by creating a blockchain transaction, the blockchain transaction comprising: A first input for consuming a dust output related to a previous transaction related to the event stream ES; The first unspent transaction output UTXO, which is the dust output n_dust and, the current event E n The last unspent transaction output UTXO associated with the event data representing n_data and including; wherein when n = N, the method comprises: An event E for the event stream in the received request n as the final event for creating a finished event stream ES; The received event E n by creating a blockchain transaction, the blockchain transaction comprising: A first input for consuming a dust output related to a previous transaction related to the event stream ES; The last unspent output UTXO associated with a digital asset that exceeds a defined dust output value N and including; including, the method comprising: Submitting the created transaction to the blockchain; TX results related to the event stream ES 0 sending the result to the client in the HTTP transmission protocol format; including; A computer-implemented method.

2. A computer-implemented method for creating an event stream related to a blockchain, the method being implemented by a platform processor related to an application programming interface (API), the method comprising: Receiving, from a client, a request related to a new event stream ES, the request being received based on a hypertext transfer protocol (HTTP) transmission protocol format; determining a hierarchical deterministic key chain K to be used in the new event stream ES, said key chain K being derived from a selected parent key pair such that K=K n=0 to N n is an integer between 0 and N, each integer n representing the current length or current number of events associated with the event stream ES, and N is a maximum or final value of n; A first blockchain transaction TX for the new event stream ES. 0 where n=0 and the blockchain transaction is The first unspent transaction output (UTXO) is the dust output. 0_dust ), and the dust output is a key pair K initially derived from the key chain K. 0 a step associated with a lock script protected using The transaction TX 0 to the blockchain; TX the results related to the created event stream ES 0 sending the result to the client in the HTTP transmission protocol format; including; A computer-implemented method.

3. A computer-implemented method for updating an event stream related to a blockchain, the method being implemented by a platform processor related to an application programming interface (API), the method comprising: receiving a request from a client to update an existing event stream ES associated with the blockchain, the request being received based on a HyperText Transfer Protocol (HTTP) transmission protocol format, and the event stream ES being updated such that K=K n=0 to N n is an integer between 0 and N, each integer n representing a current length or current number of events associated with said event stream ES, and N is a maximum or final value of n; Determining a current length n of the event stream ES; The current event E to be added to the event stream ES n from the request; The previous blockchain transaction TX associated with the event stream ES n-1 and identifying The identified previous transaction TX n-1 The key pair K associated with n-1 and obtaining the current event E n The key pair K for n and deriving The current event E to be added to the event stream ES n The current blockchain transaction TX regarding n Create, where 0 < n < N and the current blockchain transaction is Previous transaction TX n-1 a first input that consumes a dust output associated with the obtained key pair K for the previous transaction; n-1 a first input, which is validated using The current transaction TX n The first unspent transaction output (UTXO) is the dust output for n_dust ) wherein the dust output is n The first unspent transaction output (UTXO) associated with the lock script protected using n_dust )and, the current event E n The last unspent output (UTXO) associated with the event data represents n_data )and including; The transaction TX n to the blockchain; Sending, to the client, a result related to the updated event stream ES, the result being provided based on the HTTP transmission protocol format; including; A computer-implemented method.

4. The current blockchain transaction TX n The last unspent transaction output (UTXO) n_data ) in the event E n The method of claim 3 , wherein the event data for comprises a hash of the event data.

5. The method of claim 4 , wherein the hash of the event data is applied by the platform processor.

6. The method of claim 4 , wherein the hash of the event data is applied by the client device before being included in the request received by the platform processor.

7. Current Blockchain Transaction TX n The last unspent transaction output (UTXO) n_data ) in the event E n The method of claim 3 , wherein the event data relating to comprises raw event data.

8. 1. A computer-implemented method for terminating an event stream associated with a blockchain, the method being implemented by a platform processor associated with an application programming interface (API), the method comprising: receiving a request from a client to terminate an existing event stream ES associated with the blockchain, the request being received based on a HyperText Transfer Protocol (HTTP) transmission protocol format, and the event stream ES being configured to terminate an existing event stream ES such that K=K n=0 to N n is an integer between 0 and N, each integer n representing a current length or current number of events associated with said event stream ES, and N is a maximum or final value of n; determining a current length n=N of said event stream ES; The final event E to be added to the event stream ES N from the request; The previous blockchain transaction TX associated with the event stream ES N-1 and identifying Previous transaction TX N-1 The key pair K associated with N-1 and obtaining Final Event E N The key pair K for N and deriving The final event E to be added to the event stream ES N Final blockchain transaction TX N creating a final blockchain transaction, Previous transaction TX N-1 a first input that consumes a dust output associated with the obtained key pair K for the previous transaction; N-1 a first input, which is validated using The first unspent transaction output (UTXO) associated with a digital asset that exceeds the defined dust output limit. N )and and The transaction TX N to the blockchain; sending a result related to the finished event stream ES to the client, the result being provided based on the HTTP transmission protocol format; Including, Computer-implemented methods.

9. The results related to the event stream ES are: Event E n a transaction identifier submitted to the blockchain; a Merkle inclusion proof of the transaction in a header in the blockchain; A copy of the block header containing the transaction including a certificate verifying at least one of 9. The method according to any one of claims 1 to 8.

10. 10. The method of claim 1, wherein the submitting step comprises including the created transaction in a subsequent block associated with the blockchain to be mined.

11. The created blockchain transaction is Inputs related to digital assets; one or more modified outputs associated with said digital asset; further comprising:

11. The method according to any one of claims 1 to 10.

12. The method of claim 11 , wherein the digital asset is associated with an operational float.

13. 13. The method of claim 1, comprising identifying the event stream ES based on a transaction identifier associated with the submitted blockchain transaction.

14. 14. The method of claim 1, further comprising identifying a state associated with the event stream ES based on a transaction identifier associated with the submitted blockchain transaction.

15. 15. The method of claim 1, wherein the event stream is used to represent a smart contract on the blockchain.

16. 16. The method of claim 15, wherein the smart contract is implemented as a finite state machine (FSM).

17. 17. The method of any one of claims 1 to 16, comprising storing a copy or record or log based on the results for each event in the event stream in an off-chain storage resource.

18. 1. A computer-implemented method for writing data associated with an event stream into a blockchain, the method being implemented by one or more processors of a given client of a plurality of clients, the method comprising: obtaining or identifying an application programming interface (API) endpoint associated with one or more processors associated with the platform for providing a data writing service; One or more events E associated with the event stream n transmitting a request for the service, wherein the request is transmitted based on a HyperText Transfer Protocol (HTTP) transmission protocol format; The requested event E n receiving a result related to an output script of a blockchain transaction related to the transaction, wherein the result is received based on the HTTP transmission protocol format; Including, Computer-implemented methods.

19. The request is made in response to the event E n event E to include hashed event data relating to the event n 20. The method of claim 18, comprising applying a hash function to event data relating to the event.

20. 18. A computing device comprising a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform the computer-implemented method of any one of claims 1 to 17, the computing device being associated with a platform processor.

21. 20. A computing device comprising a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform the computer-implemented method of claim 18 or 19, the computing device being associated with a client.

22. 21. A computer system comprising at least one platform processor communicatively coupled to at least one client via a wireless communications network, the at least one platform processor associated with an application programming interface (API) endpoint for processing HTTP requests from the at least one client, the at least one platform processor implemented in accordance with the computing device of claim 20, and the at least one client implemented in accordance with the computing device of claim 21.

23. A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer, cause the computer to perform the method of any one of claims 1 to 19.

Images