Computation services for a platform of blockchain-related services

Abstract

In one aspect, the present disclosure proposes a method, device, and system for implementing or providing blockchain-related transaction computation or execution services for a client. More specifically, the present disclosure relates to a method for enabling execution of one or more smart contracts based on a request in Hypertext Transfer Protocol (HTTP) transmission protocol format from a client. The method includes the steps of accessing a smart contract SC in the request and identifying an event stream ES implemented using the blockchain, where the event stream ES is specific to the smart contract SC and the event stream ES represents a state of the smart contract SC. Current state of the smart contract ES n The method then includes invoking execution of the smart contract SC. The method then executes a new event E in the event stream ES that is identified in the received request and that is processed by creating a blockchain transaction. n Then, the current state of the smart contract on the blockchain is updated with the new event E n Based on ES n =ES n+1 Then, the updated current state ES n+1 Results related to are provided.

Description

[Technical field]

[0001] The present disclosure generally relates to methods and systems for implementing a platform of 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 blockchain-related functions and applications, such as, but not limited to, event streams or machine-readable contract enforcement, for one or more clients. [Background technology]

[0002] In this specification, 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. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Although 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 are within the scope of this disclosure. The terms "client," "entity," "node," "user," "sender," "recipient," "payer," and "payee" may refer to computing or processor-based resources in this specification. 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 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 will be understood that the term "digital asset" is used throughout this specification to describe a commodity that may be associated with value that may be transferred or provided from one entity to another as payment in a transaction.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized system composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets 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 that 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 the transaction's inputs and outputs that specify how and by whom the transaction's outputs can be accessed. In the Bitcoin platform, these scripts are written using a scripting language based on Stack.

[0004] For a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform work to ensure that each transaction is valid; invalid transactions are rejected from the network. A software client installed on the node performs this validation work by running its lock and unlock scripts on unspent transactions (UTXOs). If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must be i) validated by the first node that receives the transaction; if the transaction is valid, the node relays the transaction to other nodes in the network; ii) added to a new block constructed by miners; and iii) mined, i.e., 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. Proof of Work (PoW) is associated with the original Bitcoin protocol, but it will be appreciated that other consensus mechanisms such as Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Proof of Capacity (PoC), Proof of Elapsed Time (PoET), Proof of Authority (PoA), etc. may be used. Different consensus mechanisms differ in how mining is distributed among the nodes, and the likelihood of successfully mining a block depends, for example, on the hashing power of the miner (PoW), the amount of cryptocurrency held by the miner (PoS), the amount of cryptocurrency entrusted to delegate miners (DPoS), the ability of the miner to remember a given solution to a cryptographic puzzle (PoC), the waiting time randomly assigned to the miner (PoET), etc. Typically, miners are provided with an incentive or reward for mining a block. For example, the Bitcoin blockchain rewards miners with newly issued cryptocurrency (Bitcoins) and fees associated with transactions in a block (transaction fees). With respect to the Bitcoin blockchain, the amount of cryptocurrency issued decreases over time, and the incentive eventually consists solely of transaction fees. Thus, it will be appreciated that the processing of transaction fees is part of the underlying mechanism for committing data to a public blockchain, such as the Bitcoin blockchain.

[0006] As mentioned above, each transaction in a given block encodes the transfer of control of digital assets between participants of the blockchain system. Digital assets do not necessarily correspond to cryptocurrencies. For example, digital assets may relate to digital representations of documents, images, physical objects, etc. Payment of cryptocurrencies and / or transaction fees to miners may simply act as an incentive to maintain the validity of the blockchain by performing the necessary work. The cryptocurrency associated with the blockchain serves as security for miners, and the blockchain itself may be a ledger of transactions primarily related to non-cryptocurrency digital assets. In some cases, transfers of cryptocurrencies between participants may be handled by entities distinct from and / or unrelated to the entities using 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 another transaction input. This transfer is typically, but not necessarily, done using a digital wallet. This digital wallet may be a device, a physical medium, 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, tokens, assets, etc. associated with a user, receive or spend digital assets, and transfer tokens, which may be associated with digital assets such as cryptocurrencies, licenses, property, or other types of resources.

[0008] Although blockchain technology is most widely known for 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. Blockchain technology would be highly advantageous if the blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions could take advantage of the benefits of the blockchain (e.g., permanent tamper-proof record of events, distributed processing, etc.) while broadening their applications.

[0009] One area of ​​current research is the use of blockchain for the implementation of "smart contracts". Machine-readable contracts, or computer programs designed to automate the execution of the terms of agreements, exist. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce outcomes and cause actions to be taken depending on those outcomes. Another area of ​​interest related to blockchain is the use of "tokens" (or "coloured coins") to represent and transfer real-world entities via the blockchain. Potentially sensitive or secret matters may be represented by tokens that have no discernible meaning or value. Thus, tokens act as identifiers that allow real-world matters to be referenced from the blockchain.

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

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

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

[0013] Now, such an improved solution has been devised. The present disclosure addresses the above technical problems by proposing one or more techniques whereby data or information relating to a client may be easily, securely and instantly written to or 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 requiring such client to implement any processing or functionality to use the blockchain, while still being able to take advantage of all the benefits associated with the blockchain.

[0014] In a first aspect, the present disclosure proposes a method, device, and system for implementing or providing computation or software execution services for blockchain-related transactions for a client. More specifically, the present disclosure relates to a method for enabling execution of one or more smart contracts based on a request in a HyperText Transfer Protocol (HTTP) transmission protocol format from a client. The method includes the steps of accessing a smart contract SC in the request and identifying an event stream ES implemented using a blockchain, where the event stream ES is specific to the smart contract SC and the event stream ES represents a state of the smart contract SC. Current state of the smart contract ES n Then, the method includes invoking execution of the smart contract SC. The method then executes a new event E in the event stream ES that is identified in the received request and that is processed by creating a blockchain transaction. n Then, the current state of the smart contract on the blockchain is updated with the new event E. n Based on the ES n =ES n+1 Then, the updated current state ES n+1 Results related to are provided.

[0015] In a second aspect, the present disclosure proposes a method, device and system for accessing a smart contract associated with a blockchain. More specifically, the method of the second aspect includes obtaining or identifying an endpoint associated with a platform for executing the smart contract SC, and receiving one or more events E associated with the smart contract SC. nand sending a request for the smart contract SC to the platform, the request being sent based on an HTTP format. The method includes obtaining one or more software libraries and validation tools for processing data related to the smart contract SC. The method includes receiving the requested event E. n The method also includes receiving a result based on an output script of a blockchain transaction associated with the smart contract SC, the result representing an updated state of the smart contract SC, and the result being received using an HTTP format.

[0016] Throughout this specification, the word "comprise" or variations such as "includes," "comprises," or "comprising" shall 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.

[0017] Aspects and embodiments of the present disclosure are hereinafter described, by way of example only, with reference to the accompanying drawings. [Brief description of the drawings]

[0018] [Figure 1] FIG. 1 is a schematic diagram showing an overview of a platform for multiple blockchain-related services. [Figure 1a] FIG. 2 is a schematic diagram illustrating components of the computing services of the multi-services platform seen in FIG. 1 according to a first embodiment. [Figure 1b] FIG. 1B is a schematic diagram illustrating components of an executor platform or processor of the computation service seen in FIG. 1a according to a first embodiment. [Diagram 2]1 is a flow diagram illustrating a method for enabling execution of one or more smart contracts performed by one or more processors associated with a platform service. [Diagram 3] 1 is a flow diagram illustrating a method for creating an event stream for a smart contract performed by one or more processors associated with a platform service, where the event stream is associated with a blockchain. [Figure 4] 1 is a flow diagram illustrating a method for updating an event stream for a smart contract performed by one or more processors associated with a platform service, where the event stream is associated with a blockchain. [Diagram 5] 1 is a flow diagram illustrating a method for terminating an event stream for a smart contract performed by one or more processors associated with a platform service, where the event stream is associated with a blockchain. [Figure 6] 1 is a flow diagram illustrating a method for accessing a smart contract associated with a blockchain according to a second aspect, implemented by one or more processors associated with a client. [Figure 7] FIG. 1 is a schematic diagram showing game execution as an example of smart contract execution. [Figure 7a] FIG. 1 is a schematic diagram illustrating a state machine for one state of an exemplary smart contract. [Figure 7b] FIG. 1 is a schematic diagram illustrating state transitions for a single event of an exemplary smart contract. [Figure 8] FIG. 11 is a sequence diagram illustrating data and / or process flow associated with events for an example smart contract. [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 PREFERRED EMBODIMENTS

[0019] The present disclosure generally relates to the provision of a platform of services related to blockchain, the platform being provided for a number of clients and implemented by at least one platform processor associated with an application programming interface (API). An example of such a platform of services is described in UK Patent Application No. 2002285.1, filed on February 19, 2020 by nChain Holdings Limited.

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

[0021] The platform processor may be implemented as or associated with an HTTP API endpoint. In some examples, the platform processor is implemented as a Representational State Transfer (REST) ​​endpoint. Advantageously, the API may be implemented as a REST endpoint, thereby still allowing clients to communicate using standard Internet or web-based protocols such as HTTP or HTTPS. Advantageously, implementing the platform provided as an API for one or more clients allows 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. One or more processors associated with the platform may implement one or more of the services provided using a standards-based interface design, such as, but not limited to, REST, which is an architectural style for developing web services and web-based interactions. Advantageously, the clients may thus communicate with the platform services by HTTP or similar internet commands. More advantageously, for any of the services provided, no knowledge of BSV, Bitcoin, blockchain, ECDSA, or other cryptographic key management libraries, or transaction construction software such as digital wallet software, is required to be implemented by the client. A client using one or more processing resources or user terminals can simply register to use the platform by some known authentication technique such as password-protected authorization or a standard Public Key Infrastructure (PKI) to verify the client's identity. The client should then be able to communicate with the platform services simply by basic HTTP, or the like.

[0022] Some examples of blockchain-related services that may be offered by the platform are: - A data service to write / send data to the blockchain to change the blockchain state - Data services to read / get data reflecting the current state of the blockchain - Services relating to simplified payment verification for blockchain-related transactions - Services relating to the management of one or more event streams and / or machine-readable contracts related to the blockchain - Services relating to the management of digital wallet frameworks for multiple clients

[0023] In the case where there may be multiple processors or web servers associated with the platform processor, an application programming interface (API) converter may be provided for receiving requests from a client in HTTP transmission protocol format, converting the received requests to a remote procedure call (RPC) format, and sending an RPC request to a given processor of the multiple processors, configured to perform the service identified in the received request. In the reverse flow path, an associated response may be received in RPC format from the given processor and converted to be sent to the client using HTTP or a similar transmission protocol. This is advantageous as it allows a client to communicate requests related to the blockchain via simple HTTP, seamlessly providing interoperability with any of the nodes or servers that use web-based platform APIs and implement the above-mentioned services but do not communicate using the Internet Protocol communication standard for web services. The implemented API converter is not limited to conversion from HTTPS to RPC and vice versa, or for that matter, from other web-based protocols to alternative communication protocols supported by the platform processor that implements one or more of the above-mentioned services, the network for a given cryptocurrency, or any other digital asset that may be envisioned. The reverse flow path involves receiving responses related to corresponding blockchain transactions from the respective processors in RPC format and correspondingly converting the respective responses using HTTP for sending to the client. Thus, advantageous implementation of the proposed interface by the platform processor enables seamless communication for sending transactions to the blockchain when clients and miners use different wireless data communication protocols and mechanisms.

[0024] In some examples, the HTTP API may be associated with a handle or alias associated with the platform processor. Such a solution has been 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 applications describe an alias-based payment service and associated protocols, called the "bsvalias payment service," in which an alias is used for addressing instead of an entity's published address. In this case, the alias is specific to the platform processor and is provided by an alias-based addressing service, such as bsvalias, that uses machine-readable resources accessible from a defined or well-known location that provide details about one or more capabilities associated with the platform processor. The alias may also be associated with an asymmetric cryptographic key pair for authentication.

[0025] In a first aspect, the present disclosure provides a computer-implemented method for enabling execution of one or more smart contracts 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 services for executing smart contracts. This relates to the platform execution or computer services described above as they relate to facilitating blockchain-related execution or operations for the client. The API may be based on an HTTP API or on alias-based addressing endpoints, as described above with respect to the platform processor.

[0026] The method of the first aspect includes receiving a request from a client, the request being associated with a smart contract SC. A smart contract or machine-readable contract is known to be a computer protocol or software intended to digitally facilitate, verify, or enforce the negotiation or execution of a contract or agreement between two or more entities. The client may be one of a plurality of clients associated with the platform services described above. In some embodiments, the request from the client is based on a Hypertext Transfer Protocol (HTTP) transmission protocol format. The smart contract to be executed is identified from the request. For example, this may be based on an identifier or keyword in the request. The method includes accessing smart contract SC software associated with the request. The smart contract may be accessed from a storage module, such as a contract store, provided in the platform, or may be located or hosted remotely on a server that can be accessed by the platform processor.

[0027] Then, the method includes identifying an event stream (ES) associated with the blockchain, the event stream ES being specific to the smart contract SC and representing the state of the smart contract SC. An exemplary mechanism for implementing an event stream in a blockchain is described in UK Patent Application No. 2002285.1, filed February 19, 2020, by nChain Holdings Limited. An event stream provides a precisely ordered log of events executed in sequence and is implemented on the blockchain. The event stream ES associated with the smart contract SC of the request may be obtained directly from the blockchain, or it may be obtained from an off-chain log or database that replicates the event stream on the blockchain. For example, the platform processor may be associated with a snapshot instance database configured to provide or indicate the current state of the smart contract SC recorded in the respective event stream ES in the blockchain at any given time. There will be only one event stream for each smart contract associated with a given client of the plurality of clients. In some embodiments, each client of the plurality may be associated with an account or identifier that may be used to identify the particular smart contract SC associated with the respective client.

[0028] In some embodiments, an event stream is a well-known computer term that describes a system with a finite number of states, and is implemented on the blockchain as a finite state machine (FSM), such as a deterministic finite automaton (DFA), that may be in only one state at a given time, with transition functions or trigger events for transitioning from one state to the next. In some embodiments, such an event stream is useful for representing a control measure or technique of a technical process. The event stream ES represents a machine-readable contract or smart contract on the blockchain, and advantageously, an immutable record of the past and current states of the smart contract SC is written to the blockchain. In some embodiments, a request received from a client includes a trigger event to enable a state transition to be made in the event stream ES, such as changing the state of the smart contract SC.

[0029] The method of the first aspect includes: n This is determined based on its associated event stream ES. The current state of an SC is determined based on the event stream ES associated with it. n where n is an integer from 0 to N, each integer n representing a current number of current states or events associated with the smart contract SC, and N representing a maximum or final value or state of n. In some embodiments, the determination of the current state may be based on an indication or recording of the current state based on most recent results associated with the event stream ES. As mentioned above, the results represent the state of the smart contract SC, which may be stored on the blockchain or in one or more separate off-chain storage resources for the event stream ES, such as an event log for data associated with the event stream ES specific to the smart contract SC.

[0030] In some embodiments, the event stream ES for each smart contract SC may be identified based on an identifier of a previous or prior blockchain transaction associated with the event stream ES. In some embodiments, if there is no event stream identified for the smart contract SC of the request, or if there is no previous state identified for the event stream ES associated with the smart contract SC, this is a determination that the current state is the initial state, i.e., n=0, and a new event stream will be created for the client associated with the smart contract. In some embodiments, the current state may be retrieved or read directly from the event stream ES 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.

[0031] The disclosed method then includes invoking execution of the smart contract SC based on the received request. In some embodiments, execution of the software code or logic of the smart contract SC is automatically triggered when an event stream ES for the smart contract SC is identified or created. In some embodiments, execution according to the client's request may be performed by one or more processors associated with the platform. In other embodiments, execution of the code or logic of the smart contract may be based on a serverless execution technique, where a platform processor is configured to identify an available server from among a plurality of available servers or a pool of servers. In this case, any required APIs and / or drivers and / or executable code, etc. are provided to the available server to execute one or more software routines or programming instructions associated with the smart contract SC.

[0032] The method includes invoking processing or updating of an event stream ES associated with the smart contract SC such that the event stream reflects the state of the smart contract SC based on the received request. This includes invoking processing or updating of a new event E of the event stream such that the event stream reflects the state of the smart contract SC based on the received request. n This includes handling the new event E n is based on a received request from a client for a smart contract SC. This may be event data related to the request for the smart contract. This same event in some embodiments is the one used for the execution of the smart contract SC mentioned above, since an event stream is associated with it and tracks the stages of the smart contract's SC. In some embodiments, the above steps of invoking the smart contract SC and the event stream are performed in parallel or simultaneously based on the event data as soon as each event is identified. In some embodiments, the event stream ES is processed as soon as the logic of the smart contract SC is executed. In some embodiments, a new event E based on the request is generated. n may be determined with respect to the event stream by the execution of the smart contract. This may therefore mean that the smart contract software itself may be considered as an input to the event stream ES and is notarised or stored in the event stream before any data is processed. This may be the case for initialising a new smart contract SC for a client.

[0033] In some embodiments, invoking the processing or updating of the event stream ES associated with the smart contract is performed by a platform processor. In other embodiments, invoking the processing or updating of the event stream ES includes creating new event streams ES by writing data to the event stream ES associated with the blockchain. nThe method further includes accessing a data writer or data service associated with the platform processor, as described above, to process the data.

[0034] Then, the method generates a new event E that has just been processed with respect to the event stream ES associated with the blockchain. n The updated current state of the smart contract based on n+1 Then, the method includes obtaining an ES for the smart contract SC. n =ES n+1 and storing or providing the results based on the updated current state, which is: In some embodiments, the results may be provided directly to the client in the form of an HTTP submission.

[0035] Advantageously, the first aspect allows for establishing and / or maintaining / updating a tamper-proof record or log or certificate verifying the successive occurrence of events associated with the event stream for execution of the smart contract, the events being based on received client input for a given smart contract. Thus, the present disclosure proposes methods, devices and systems for enabling the processing, i.e., creation, updating and / or termination, of an event stream ES, implemented using blockchain, that automatically creates a tamper-proof log or record of events associated with the smart contract SC associated with the event stream ES.

[0036] In some embodiments, the results may be stored in a snapshot instance database for the smart contract described above, or in a separate off-chain log for the event stream ES that tracks the execution of the smart contract SC, with each stored event stream being specific to a given smart contract. Advantageously, providing the results as a snapshot in either an off-chain event log or an instance snapshot database allows the state of the smart contract SC to be easily and independently verifiable by any other entity, such as the client or any interested third party (provided access is provided or permitted) without the need to retrieve the transactions associated with the blockchain event stream.

[0037] In some embodiments of the first aspect, in response to receiving a request from the client, the method includes providing the client with one or more software libraries and / or validation tools for processing data related to the smart contract SC. This may be provided in the form of a software development kit. Advantageously, the software library provides the client with functionality for replaying the event stream so as to be able to independently obtain a state or snapshot of the smart contract based on a given event. The validation tool provided to the client advantageously allows the client to compare the recovered or replayed snapshot of the smart contract with a result based on the event stream ES obtained, i.e. stored in the blockchain for the smart contract SC. In some embodiments, the validation tool also allows the replayed or recovered event stream to be checked against a current snapshot of the smart contract, possibly stored in an off-chain storage log or instance snapshot database, to verify whether they match. In some embodiments, the validation tool may also allow the client to perform a comparison with data related to the event stream ES in the blockchain, for example, if an audit is required. If the reproduced or recovered event stream matches the captured outcome, it can be established that the captured outcome matches what was recorded on the blockchain and has not been tampered with by a malicious actor on or before reaching the client. If the reproduced event stream does not match the captured outcome or a snapshot of the outcome stored in off-chain storage that reflects the event stream ES of the smart contract SC, this can be an indication that the outcome may not accurately reflect the state of the smart contract.In some embodiments, following such a comparison involving a validation tool, if a comparison using the recovered event stream does not match, there may be an error notification or message generated for the client, and the discrepancy may also be notified to the platform processor, in some cases.

[0038] A new event E is generated based on the event data of a part of the client request received at the platform processor. n The steps involved in processing are described below.

[0039] In some embodiments of the first aspect, if it is determined that n=0, a new event E n is identified as the first event for creating the respective event stream ES associated with the smart contract SC. In this case, the new event E nIt may be processed by the following steps that may be implemented by a specific executor platform for a platform processor or a computing service module, or a data writer module that may be one of the services related to the platform. For the smart contract SC, a first blockchain transaction TX0 including a first unused output that is a dust output is created. In the context of blockchain transactions for the present disclosure, a blockchain transaction dust or simply "dust" is understood to be a consumable transaction for a digital asset or cryptocurrency having a low or minimal value output, i.e., 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 output of a consumable cryptocurrency or digital asset. In some embodiments, the digital asset or cryptocurrency funds related to such a dust transaction, i.e., a transaction 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 with respect to a blockchain transaction is associated with a digital asset having a value less than the value limit for the transaction, i.e., perhaps the value of the dust output is less than the mining fee that may be required to consume such a transaction.

[0040] Assuming that N is the final or maximum value of n, if it is determined that 0 < n < N, then E n is identified as an event for modifying an existing event stream ES related to the smart contract SC. In this case, the new event E nis processed by the following steps, which may be implemented by a data writer module, which may be a platform processor or a specific executor for a computational service module, or one of the services associated with the platform: A first input that consumes a dust output associated with a previous transaction of the same event stream, a first unspent transaction output that is the dust output of the current transaction, and a current event E n The current blockchain transaction TX, which contains the final unspent transaction output associated with the event data n In some embodiments, the event data is included in a data carrier element, which may be a non-consumable OP-RETURN output of the transaction. In some embodiments, the event data is included in a final unspent transaction output of the current blockchain transaction, n The event data for includes a hash of the event data. Advantageously, this keeps the contents of the event data in the event stream ES private. In some embodiments, the hash of the event data is applied by a platform processor, 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 a platform processor. Advantageously, this allows a client to keep the event or event related data in the request private and not even share that data with the platform. In other embodiments, the event data for the event E in the final unspent transaction output is applied by a client device prior to being included in the request received by the platform processor. Advantageously, this allows a client to keep the event or event related data in the request private and not even share that data with the platform. n Event data relating to includes raw event data that is published on the blockchain once it is written or sent to the blockchain.

[0041] If it is determined that n=N, then E nis identified as the final event to terminate the event stream ES associated with the smart contract SC. In this case, the new event E n is processed by the following steps, which may be implemented by a data writer module, which may be a specific executor platform for a platform processor or computational services module, or one of the services associated with the platform: A final blockchain transaction TX that includes a first input consuming a dust output associated with a previous transaction in the event stream and a first unspent 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. N is created. Advantageously, the absence of dust output signals the end of the event stream in this case, as this represents that there is nothing more in the event stream to track, i.e., there are no further events in the sequence. The provision that the first output exceeds the dust limit is to indicate the end of the chain. Furthermore, the final blockchain transaction does not have any event data output, i.e., there is no data carrier element, which advantageously indicates that this is a data event to end the event stream, rather than a data event to modify the event stream.

[0042] In any of the three cases of the event stream ES discussed above, the transaction is sent to the blockchain and a result related to the transaction is provided based on the HTTP transmission protocol format. In some embodiments, the events related to the request, i.e., E0, E n , or E N There may be a single event or more than one event associated with each request. For example, a request may have E0, E n , or E NIn some embodiments, the outcome may include a data set of two or more sub-events related to the transaction. In some embodiments, the outcome is based on the event data output of the transaction or the event associated with the respective transaction. In some embodiments, any outcome or event data returned may be held in the non-consumable OP_RETURN output of the transaction. This is a Script opcode that can be used to write any data to the blockchain and also to mark the output of the transaction as invalid. As another example, OP_RETURN is an opcode in the Script language for creating a non-consumable output of the transaction, which can store data such as metadata in the transaction, thereby immutably recording the metadata on the blockchain. The metadata may include logs or entries or documents that are desired to be stored on the blockchain. The event data or outcome may be considered to be a payload included in the non-consumable output of the respective transaction in some embodiments. Such an output may be made non-consumable by an opcode that terminates the lock script for that output, such as OP_RETURN as described above. However, in other embodiments, the payload or event data may be included in other ways. As described above, the outcome relates to a snapshot of the current state of the smart contract SC. The result is stored in and / or accessible from an instance state database or another off-chain event log for the smart contract associated with the platform processor.

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

[0044] The use of dust outputs in transactions is advantageous and important to maintain an immutable continuous record of all those transactions as they occur with respect to the event stream ES associated with the smart contract being executed. This is because, although by posting a transaction to the blockchain, all blockchain transactions are time-stamped and remain in order in the blockchain, this does not guarantee the preservation of the chronological order of those transactions. This is because transactions may be mined into blocks at different times. Thus, only the order of blocks in the chain follows chronological order in the blockchain, not the individual transactions. On the other hand, the use of dust outputs, which must be consumed by the first input of the next transaction in order, advantageously ensures that the order of transactions is tracked chronologically and a tamper-proof record is created, in order to track, record and audit the exact chronological order of events in an event stream, which may be a smart contract. This is because, when mined into a block, the payment of dust from the previous transaction to the next transaction in the sequence meets Bitcoin protocol rules to ensure that the order of the embedded data carrier elements (which are the final output of each transaction) cannot be changed and that no insertions or deletions can occur that could change the sequence without immediately making it apparent that the event stream has been compromised. In some embodiments, the double spend prevention inherent in the Bitcoin protocol ensures that the movement of cryptocurrency (e.g., dust) between different addresses, and thus the associated events, remain in chronological order. This therefore improves the security of smart contracts on the blockchain and the logging, copying, or replication of a sequence of event occurrences using the event stream inherent to the smart contract. Funds associated with dust outputs may be provided or managed by the platform processor as described above.In some embodiments, the platform processor provided mining fees, for example from an operational float, to ensure that dust outputs actually create mined Tx.

[0045] 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 for a given event stream. Then, from a seed or parent, or master key pair K, a cryptographic private / public key pair is generated such that K=K n=0 to N where n is an integer between 0 and N, each integer n representing a current number of current states or events associated with the smart contract SC, and N representing a maximum or final value of n. Advantageously, this ensures that the keys derived for a particular event stream are related to a common master or seed key and can be derived to process the respective events. In this way, advantageously, a lock script associated with a dust output can store the derived key K for the current event. n and the first input is the previous key pair K n-1 The dust output from the previous transaction is consumed using the key pair, which ensures that the output can only be consumed using the corresponding key pair unique to each previous transaction.

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

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

[0048] In some embodiments, the method includes storing a copy or log of the result-based records for each event of the event stream ES in an off-chain storage resource. This storage resource may be associated with the platform processor or in another device, database, or service from which it may be requested or retrieved when requested by a client. Advantageously, the storage of the logs related to the results of the event stream is stored separately to avoid the need to download the entire blockchain and scrutinize the data for every query related to the event stream. The blockchain implementing the event stream itself may be checked in situations during audits or data validation. A backup or separate copy may then be used for rapid querying and independent validation of the event stream, as described above.

[0049] In some embodiments of the third aspect, a computer-implemented method for accessing a smart contract, performed by one or more processors of a given client of a plurality of clients, is provided, the method including obtaining or identifying an application programming interface (API) endpoint associated with one or more processors associated with a platform, and requesting a service associated with execution of the smart contract SC. The method includes receiving one or more events E associated with the smart contract SC. n As described above, the request is transmitted using the HyperText Transfer Protocol (HTTP) transmission protocol format.

[0050] Then, the method includes obtaining one or more software libraries and / or validation tools for processing data associated with the smart contract SC. nand receiving a result associated with an output script of a blockchain transaction associated with the smart contract SC, said result being received based on an HTTP transmission protocol format. In some embodiments, the result includes an indication of an updated state of the smart contract SC. In some embodiments, the method further includes recovering a snapshot or state associated with the smart contract SC using one or more software libraries, such recovery comprising recovering an event E of the event stream ES. n may be performed based on or using received results relating to an event E n The method may be similar to replaying an event stream associated with the smart contract. Then, using one or more validation tools, the method includes comparing the recovered snapshot with results obtained from the event stream ES to independently validate the state of the smart contract. As described above, if there is any discrepancy after the comparison / validation, i.e., if there is no match based on the replayed or recovered event stream and another off-chain result or obtained result, an error message or notification may be sent to the client and / or platform processor.

[0051] In some embodiments, the method further comprises the step of: the request receives, instead of raw data, an event E n The requested event E is generated to include hashed event data about n This includes applying a hash function to the event data relating to the

[0052] Aspects of the present disclosure also include a computing device including a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform the computer-implemented methods discussed above, and the computing device associated with a platform processor.

[0053] Aspects of the present disclosure also include a computing device including a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform the computer-implemented methods discussed above, the computing device being associated with a client.

[0054] Aspects of the present disclosure also include a computer system including 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 according to the computing device described above, and the at least one client implemented according to the client computing device described above. The at least one platform processor is communicatively coupled via the wireless communications network to one or more of the following components of the platform service: a smart contract store, an event stream log, an instance state database, and a data writer.

[0055] Aspects of the present disclosure also include a computer-readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer, cause the computer to perform the method of any of the above-described aspects and embodiments.

[0056] Some specific embodiments are hereinafter described, by way of example only, with reference to the accompanying drawings in which like reference numerals refer to like features and in which:

[0057] Overview of platform services to provide multiple blockchain-related services The above-mentioned platform processor for providing multiple services may be a Platform as a Service (PaaS) and / or 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 may be seen in FIG. 1, which shows a high-level diagram of the system. The platform service has a platform processor 100 that provides an API 108, through which the services may be accessed by one or more clients.

[0058] The platform service 100 shown in this figure is composed of three families of services, which aim to enable users and organizations to easily and securely take advantage of the advantages offered by the unique characteristics of blockchain, without actually implementing any blockchain-based software, knowledge, or libraries at the client end. These services are: - Data services 102 aimed at simplifying the use of the chain as a product data ledger - A computation service that aims to provide a general-purpose computational framework backed by digital assets such as Bitcoin SV104 - A commerce service that provides businesses with the ability to conduct transactions using digital assets such as Bitcoin SV106

[0059] Aspects and embodiments of the present disclosure relate primarily to computational services 104, which are further described with respect to FIGS. 1a and 1b.

[0060] As mentioned above, since the API is implemented as a web service, a request may be received from a client at the API by 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 blockchain / platform interface software 110 must implement resources, libraries, and / or key management wallets for creating, processing, and sending transactions associated with the blockchain, i.e., associated with the blockchain. Once processed, the transaction may be sent to the blockchain network 105 (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 since the platform service 100 may also be capable of providing and managing digital assets for the client.

[0061] Advantageously, requests for blockchain-based services are sent and received by clients in HTTP transmission protocol format, so that clients can use all the benefits and services specific to blockchain without having to implement any transaction functions or blockchain libraries. This is because the services are provided through platform APIs, which may be HTTP or REST API endpoints. For example, the design standard of the REST API is to process HTTP requests and communications over the Internet using the following HTTP commands shown in the table below, which are all the functions required by the client, i.e., to be able to send and receive messages over the Internet. The platform processor executes the commands remotely or separately for the client.

[0062] [Table 1]

[0063] The received request from the client may be an HTTP GET or HTTP POST or HTTP PUT or HTTP PATCH request that includes or is associated with a client identifier unique to the given client and a service identifier of the given requested service among the services provided by the platform, as described above. In some cases, the result sent to the client is an HTTP POST request based on the client identifier.

[0064] In some instances, mechanisms already exist whereby easy-to-remember, more user-friendly aliases are used instead of the complex public addresses of one or more entities to make addressing easier for blockchain-based computations and transactions. Such a solution has been 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 applications describe an alias-based payment service and associated protocols, called the "bsvalias payment service," where an alias is used for destination addressing instead of the public address of a client entity or, for that matter, a service entity such as the platform 100. An alias in such a system is typically associated with the domain name of the sending / receiving entity and may be a URI or email address. Thus, as long as the sender or entity is aware of or provided with the alias, this is sufficient for the bsvalias payment system or alias-based addressing mechanism. Messages may be sent to the client's alias using instructions provided in a machine-readable resource, such as a JavaScript Object Notation (JSON) document stored at a well-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. Similarly, APIs of platform 100 may also be associated with aliases for addressing, etc.

[0065] It may also be possible to activate the client based on the client identifier and a record corresponding to the client identifier, the record being associated with the platform processor. For example, such a record may have been created, stored, or associated with the platform processor upon client sign-up or registration. Then, based on successful activation of the client, the method includes 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 cases, the attributes or settings may indicate whether a given client is permitted to access all or a portion of the requested service. For example, one or more levels of permissions associated with the client identifier may be provided in the attributes or settings. For example, a given client may be permitted to request a service to read data on the blockchain regarding a particular event, but may not be permitted to modify, delete, or terminate such event, while another client may have permission for all actions related to one or more services.

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

[0067] First aspect: A platform that provides blockchain-related computational services for executing smart contracts Figure 1a illustrates in greater detail some of the components of the computational services 104 provided by the platform 100 of Figure 1, along with a depiction of the components that interact therewith to carry out aspects and embodiments of the disclosure described beginning with Figure 2. The components illustrated in Figure 1a are described below.

[0068] The data services 1004 include a data writer, which may be an HTTP API for writing, i.e., notarizing or publishing, data via the Bitcoin SV blockchain 1005. It will be understood that the present disclosure is not limited to only the use of such a blockchain. Client-side tools related to the data services 1004 may be provided within the customer application 1001 of FIG. 1a. This may be in the form of a software application provided to a client entity / device. The customer application 1001 may be used to verify certified data, allowing any party to verify that the data has not been tampered with since being included in the blockchain. These tools may be provided via the platform services 100 or may be implemented independently based on documented specifications.

[0069] The computation services 104 (of FIG. 1) are shown to include an executor platform 1000, which in some embodiments is referred to as a platform processor in this disclosure for implementing computation services. A contract store 1003 is also provided, which may include a web gallery to allow customers to browse from a catalog of pre-built smart contract software. The executor platform 1000 provides customers with platform-as-a-service capabilities for smart contract deployment and execution. The contract store is a collection of pre-built and platform-configured smart contracts. If multiple customers express a need for the same (or very similar) smart contract, the platform services 100 can provide implementations of such contracts for immediate, zero-development deployment. The contract store 1003 allows customer administrators access to such turn-key contracts, complete with both web and API configuration and parametrisation capabilities.

[0070] With respect to the computation services 104, the client or customer application 1001 also includes a software development kit (SDK) with documentation, libraries, examples, and a local runtime for smart contracts to allow customer developers to build and test their contracts locally before deploying or launching the smart contract platform. Verification tools, which may be off-platform tooling, are also included to verify the correctness of execution of smart contract instances given both the code for the smart contract and the underlying event stream data.

[0071] The executor platform 1000 may include the following components as seen in FIG. 1b, which interact with client applications 1001 and data services 1004 as seen in FIG. 1a. In some embodiments, the methods illustrated in FIGS. 2 through 5 below and the example scenario illustrated in FIG. 8 may be performed or accomplished by the executor platform 1000.

[0072] Event Gateways 1000a and 1000b: These gateways may be JSON-over-HTTP or bsvalias endpoints that feed events, such as input data received from clients, to contracts. In some embodiments, they provide a bridge from external inputs and existing or built-in solutions for authentication and authorization. Event Gateways 1000a and 1000b may be configured to implement the functionality of an HTTP API to provide endpoints that can be accessed or provided to other entities, such as client entities. The event gateways may be implemented as gateway services for the executor platform 1000.

[0073] The Contract Management API 1006 shown in FIG. 1b allows customers or clients to upload smart contract programs and configure their execution environment. This component may be associated with or provided by or through the above-mentioned gateways that are active (including authentication and authorization), the characteristics of the event stream (notarize or publish), and methods for upgrading the smart contract software that may be stored in the contract store 1003 discussed in FIG. 1a and / or associated with the contract repository 1007 discussed below. In some embodiments, this component may be responsible for providing any libraries or software tools and functions that are sent to the client entity to process data related to the smart contract or its associated event stream.

[0074] Contract Repository 1007: This component may be configured to provide storage and management APIs for implementations of smart contracts. This component may be configured to store executables of contracts so that the Executor Platform 100 finds and retrieves the appropriate handle or smart contract identifier for a given input received from a client in order to execute the code of the smart contract. In some embodiments, this may be implemented as the contract store 1003 itself or within the contract store 1003, or may be implemented separately to invoke software for smart contracts stored in the contract store 1003.

[0075] Executor 1008: A platform processor for the compute services 104 of the platform 100 of FIG. 1 and the processing or computation component of the executor platform 1000 of FIG. 1a. The executor 1008 is configured to provide a serverless execution platform for smart contracts upon receiving client input via the gateways 1000a and / or 1000b. Thus, the executor 1008 may be configured to react to events received through the gateways by invoking appropriate contracts identified by the client. The executor is further configured to invoke processing related to event streams associated with the contracts in the blockchain. For example, this may include managing persistence of the smart contract's state and / or connecting to downstream event stream APIs. The executor is further configured to recover the smart contract from the repository and / or retrieve the instance's state from the state database to determine the current state of the smart contract. The executor may be further configured to record the input events into an event stream and execute the smart contract such that the smart contract processes the input event data, which is notarized in the event stream on the blockchain. The executor further provides an updated snapshot state of the smart contract that is persisted back to an instance state database (see below) for off-chain storage of the smart contract's state.

[0076] Instance State Database 1009: This component is a storage checkpoint or database that reflects the state of the contract after completing processing of events from clients. This component may be configured to store a snapshot state of the contract (the state derived from applying the contract's rules to all inputs) following processing by the Executor 1008 during a given smart contract program invocation.

[0077] Smart Contract Implementation - Overview As known, a contract is a legally binding agreement that recognizes and governs the rights and obligations of the parties to the agreement. An agreement generally involves the exchange of goods, services, money, or a promise of any of these. A smart contract is a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or execution of a contract. For example, Ethereum is a popular platform that can execute what may be considered smart contracts. Bitcoin Script itself may be considered a smart contract, as it is software that enforces a set of rules between transacting entities, arguably making Bitcoin a smart contract platform. R3's Corda, along with various other blockchain-like platforms, may be considered a smart contract platform.

[0078] Smart contracts can be broadly categorized as follows:

[0079] On-chain contracts: On-chain smart contracts, such as Bitcoin script, package the rules of a contract along with the parameters of a contract instance. The execution audit trail is published on-chain and is persistent and immutable (assuming the underlying blockchain provides such guarantees). Examples of on-chain contracts include atomic swaps, r-puzzles, accumulator trees, and payment channels. In either case, a supporting off-chain infrastructure is still required, but the core of the contract is expressed by Bitcoin script and executed by miners as part of the validation of the transaction.

[0080] Off-Chain Contracts: Off-chain smart contracts exist as regular computer software. They are operated by an entity that is acceptable to all contracting parties. Off-chain contracts that do not use blockchain are not further considered in this disclosure.

[0081] Hybrid Contracts: Hybrid contracts represent a blend of on-chain and off-chain approaches. Hybrid smart contracts enhance the capabilities of off-chain contracts by leveraging the blockchain. Typically, these additional capabilities include provability and security of data integrity. Several early hybrid smart contract platforms are either in development or have already been launched. Examples include Tokenized and GearSV.

[0082] There are advantages to building a smart contract platform on top of a blockchain, where the underlying blockchain provides certain guarantees that are difficult or impossible to achieve otherwise. For purposes of this disclosure, the term "blockchain" may be used to describe a public proof-of-work blockchain, in particular Bitcoin SV. However, it will be understood that aspects and embodiments of the present disclosure are not limited in this respect.

[0083] Smart contracts in any form provide value through automation. A correctly implemented smart contract operates autonomously, following the rules programmed into the smart contract. Automation provides value because large volumes of contract instances can be processed automatically on regular, inexpensive hardware with a lower error rate than alternative non-automated processes. By binding a smart contract platform to a blockchain, the essential properties of the blockchain can be inherited by all smart contracts that run on that platform. These benefits are primarily derived from the immutable nature of the chain, the absence of a single record-keeping entity, and the security primitives underlying blockchains such as BSV.

[0084] Data may be committed to a blockchain-based product ledger. When constructing a commitment, both the data and associated metadata are captured. This metadata always includes a timestamp, as the blockchain acts as a kind of witness or timestamp authority. The metadata may further include identity information in the form of a digital signature and an associated public key, which may be recognized as a proxy for identity information by existing legal precedent. This may include scenarios where the public key has been certified by some trusted third party or certificate authority, or where a service provider has applied a signature on behalf of an authenticated client.

[0085] Once committed to a blockchain-based ledger of goods, data can be proven to have not changed since its commitment. This may be used to show that no tampering of the records has occurred. By not relying on a single record-keeping authority, it is not possible to seize any such authority to change the records or cast doubt on the provenance of the blockchain as a witness. Implementing smart contracts in conjunction with blockchain is advantageous at least in light of the combination of reduced costs and errors through automation, enhanced auditing and accountability through tamper-evident record-keeping, and the ability to leverage the security fundamentals underlying Bitcoin.

[0086] A finite state machine (FSM) is a 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 inputs, and the changes from one state to another are called transitions. An FSM is defined by its states, its initial state, and a list of inputs that trigger each transition. State machine replication assumes that the replicated process is a deterministic finite automaton (DFA), allowing for atomic broadcast of every event. State machine replication is based on distributed consensus and has much in common with the transactional replication model. DFA is a model of software that is absolutely in exactly one state at a time. The only way an FSM can transition between states is in response to an external event. Replication builds on this property by realizing that if an FSM is deterministic and an input stream of events is faithfully replicated between machines, then each machine that processes those events will end up in exactly the same state.

[0087] In aspects and embodiments of the present disclosure, smart contracts are implemented as FSMs, and more specifically DFAs, i.e., software models that are in exactly one state at a given time.

[0088] Execution of smart contracts according to this disclosure Fig. 2 relates to a method according to a first aspect of the present disclosure for enabling execution of a smart contract related to a blockchain. The method of Fig. 2 is implemented by a platform processor associated with an application programming interface (API) for a service. The platform processor may be the executor platform 1000 shown in Fig. 1a, or an executor 1008 in the executor platform 1000 for implementing the computation service 104 of the platform service 100 shown in Fig. 1.

[0089] Step 202 illustrates receiving a request from a client, the request being associated with a smart contract (SC), the request being in the form of a HyperText Transfer Protocol (HTTP) transmission protocol and provided via an API or bsvalias gateway as described above in FIG.

[0090] Step 204 shows accessing a smart contract SC associated with the request. First, a smart contract to be executed is identified from the request. For example, this may be based on an identifier or keyword in the request. The method includes accessing a smart contract SC software associated with the request. The smart contract may be accessed from a storage module, such as the contract store 1003 or repository 1007 seen in Figures 1a and 1b, respectively, provided in the executor 1000 platform, or the storage module may be remotely located or hosted from a location that can be accessed by the platform processor.

[0091] Step 206 depicts identifying an event stream (ES) associated with the blockchain, where the event stream ES is specific to the smart contract SC and represents the state of the smart contract SC. The event stream ES associated with the smart contract SC of the request may be obtained directly from the blockchain, or it may be obtained from an off-chain log or database that replicates the event stream ES on the blockchain to provide a current snapshot of the contract, such as the instance snapshot database 1009. The event stream ES may be identified based on a transaction identifier associated with the smart contract SC identified in the request in step 202.

[0092] The event stream ES represents a machine-readable contract or smart contract on the blockchain and is implemented based on a finite state machine (FSM) as described above to track the state of the smart contract SC.

[0093] Step 208 is to determine the current state ES of the smart contract SC. n This is determined based on its associated event stream ES. The current state of a smart contract SC is determined based on the event stream ES n where n is an integer from 0 to N, each integer n representing a current number of current states or events associated with the smart contract SC, and N representing a maximum or final value or state of n. In some embodiments, determining the current state may be based on an indication or record of the current state based on the most recent results associated with the event stream representing the state of the smart contract SC. This may be determined directly from transactions associated with the event stream ES on the blockchain, or may be determined within one or more separate off-chain storage resources for the event stream ES, such as an event log for data associated with the event stream ES specific to the smart contract SC.

[0094] Step 210 depicts invoking execution of the smart contract SC based on the received request. In some embodiments, execution of the software code of the smart contract SC is automatically triggered once an event stream ES for the smart contract SC is identified or created. The process of creating or uploading an event stream ES is seen in more detail in Figures 3-5. In some embodiments, execution according to the client request may be performed by one or more processors associated with the platform processor. In other embodiments, execution of the code of the smart contract may be based on serverless execution techniques.

[0095] Serverless computing is a cloud computing execution model in which a cloud provider runs servers and dynamically manages the allocation of machine resources. Serverless computing can simplify the process of deploying code to production. Scaling, capacity planning, and maintenance operations can be hidden from the developer or operator. Popular serverless platforms such as AWS Lambda, Azure Functions, and Cloudflare Workers provide not only a runtime environment that frees the developer or operator from having to care about the underlying compute environment (e.g., virtual machines, operating system configurations), but also an SDK for generating ready-to-run serverless software on the host infrastructure.

[0096] Existing serverless execution providers offer rich configuration for their runtimes along with ready-made entry points into the executable. Common entry points include endpoints, message queues, and file storage. These entry points or gateways fit the smart contract model of feeding inputs to a logical processor (software). In adopting this model of entry point gateways and a commodity runtime environment, the platform may log all inputs from all sources to an event stream (e.g., via data services 1004). Gateways with authentication and authorization features further provide gating or authorization of inputs. Finally, when creating an instance of a new smart contract, capturing an identifier or hash of the contract software in the event stream before any events are written further allows all replicas of the event stream to be confident that they are running the correct FSM associated with the smart contract.

[0097] Step 212 indicates invoking processing or updating of the event stream ES associated with the smart contract SC. In some embodiments, invoking processing or updating of the event stream ES associated with the smart contract SC is performed by a platform processor, i.e., within the executor platform 1001 itself. In other embodiments, invoking processing or updating of the event stream ES includes creating new event streams ES by writing data to the event stream ES associated with the blockchain. n The method further includes accessing a data writer (see data service 1004 in FIG. 1 a ) associated with the platform processor as described above to process the data.

[0098] 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 in the blockchain, such as a deterministic finite automaton (DFA). An FSM may be defined by a list of its states, its initial state, and the conditions for each transition. In the Bitcoin SV blockchain, the UTXO set can be thought of as a state machine, where the spent state of a given output is a function of the previous inputs to the transaction (machine). Thus, by replaying all transactions, the current spent state of any output, and the current contents of the UTXO set, can be deterministically established using the blockchain. Thus, in the embodiment of FIG. 2, a request can be thought of as a request to change the current state of the smart contract SC.

[0099] Step 214 generates a new event E based on the received request. n This processing is described in more detail in Figures 3 through 5 depending on whether the request is to invoke or update a new or existing contract, or to terminate an existing contract associated with the client.

[0100] Step 216 is a new event E n Following or based on the processing of the smart contract ES n The updated current state of the smart contract ES may be stored in an off-chain event log associated with the platform processor. n+1A result is sent to the client based on the result. The result may be associated with an output script for the corresponding blockchain transaction. In some cases, the result includes functionality that allows a snapshot of the event stream to be replayed or restored such that the restored version can be matched against a stored or authoritative version of the event stream.

[0101] In some embodiments, an SDK with software libraries and validation tools may be provided to the client to allow the client to independently process and validate the results. These tools may recover and replay the event stream ES. The state of the smart contract SC may then be checked against the state of a current snapshot held within the platform, for example in an instance snapshot database. If the state of the snapshot from the replay of the event stream matches the state stored off-chain or the results obtained, it may be verified that the actions and executions were performed correctly according to the logic of the smart contract.

[0102] Advantageously, in the present disclosure illustrated in FIG. 2, a smart contract is modeled as a DFA with replication of all input events of the event stream (ES), such that all parties to a smart contract may be able to verify the behavior of the contract software, i.e. that it has correctly executed its logic according to its rule set and that no tampering has occurred, without trusting any of the other parties to the contract, provided certain pre-defined requirements are met.

[0103] Non-deterministic contracts, such as contracts that depend on data sources or events outside the event stream, may not produce the same state given the same input. Common sources of non-determinism include time functions and (pseudo-)random number generators. These sources of non-determinism can be easily addressed to make them deterministic. Time may be sourced externally and fed as input data to the contract just like any other input data. In this way, time may be captured and replicated by the event stream ES.

[0104] (Pseudo)random numbers may be constructed using many different techniques. Often these techniques begin by seeding a random number generator from the first available entropy, and random numbers from this point onwards follow a deterministic pattern. More advanced techniques prevent holders of a replicated log from guessing the next random number generated in a sequence, but still allow ex-post verification of correct operation. Other sources of non-determinism may be addressed in a similar manner. If a smart contract requires external data, such as knowledge of the current price of an asset, commodity, instrument, or similar object, the price may be fed as an input.

[0105] Advantageously, in the present disclosure illustrated in Fig. 2, all inputs are captured in an event stream and replicated to participants to verify the correctness of the contract's operation. Following the deterministic behavior of the contract, it is clear that the inputs must be replicated so that all (authorized) participants of the contract independently verify the correctness of the operation.

[0106] Advantageously, in the present disclosure illustrated in Figure 2, inputs may be gated or protected. If the output of a contract is a function of a stream of inputs, it follows that those inputs must be gated so that only authorized parties, i.e., valid clients that have access to the smart contract, may provide inputs. A smart contract that cannot enforce authorization of actions that generate input events may generate output states that are valid according to the software but invalid according to the terms of the agreement.

[0107] Advantageously, in the present disclosure illustrated in FIG. 2, the event log is faithfully forwarded to all replicas without any possibility of tampering. If the log is modified, tampered with, mutated, omitted, or otherwise malleated between replication targets, each target may arrive at a different view of the current state of the contract. The use of an event stream to track the successive execution states of a smart contract prevents any possibility of tampering.

[0108] Advantageously, in the present disclosure illustrated in Figure 2, the replication targets of the event stream run the same FSM or instance of the smart contract. Otherwise, if the log is replicated correctly, but the software that processes the log entries differs between the replication targets, each target may still arrive at a different view of the current state of the contract. The use of the event stream for a current snapshot of the smart contract that can be independently verified prevents erroneous replication.

[0109] Some existing blockchain-based smart contract platforms attempt to replicate smart contract software on a wide variety of nodes in the network. Each node in the network processes every input to every contract. However, this limits the scalability of the platform to the upper throughput limit of the poorest node in the network. The use of event streams, described above in FIG. 2, to track smart contract execution on the blockchain enables off-chain storage of snapshots of smart contracts and enables independent verification by allowing replay of the event stream by a verifying party, which can then be compared to the stored current snapshot.

[0110] Thus, the mechanism of the present disclosure illustrated in FIG. 2 provides the following capabilities and advantages for the execution of smart contracts: - All input is logged to the event stream. - Off-chain secure input event storage allows Event Stream to notarize all inputs without revealing them on-chain. - The smart contract software itself may be considered an input, and is notarized into the event stream before any data is processed. - The contract is executed by a serverless execution platform. - Contracts respond to events received through the Gateway (HTTP API and BSV Alias). The contract execution environment provides (limited) state management, allowing a snapshot state of the contract instance to be persisted between event executions. The executor can recover a previous snapshot state, provide this together with the event input, and persist an updated snapshot state after smart contract execution. - Mechanisms for dealing with common sources of non-deterministic behavior (time and random numbers) are provided by the platform processor. - An SDK is available for client-side provisioning, which may include: A library for building smart contracts that control receiving and generating entry / exit state snapshots, as well as parsing inputs. A development mode runtime for testing contracts on a developer's device Extensive documentation including quick starts, walkthroughs, API reference material, and instructions for using the operators in development runtime A validation tool that can recover event streams and contract instances from the platform and replay the event streams to validate the desired state of the contract.

[0111] 3, 4, and 5 discuss a method for implementing an event stream ES representing a smart contract SC discussed in FIG. 2 to establish an immutable sequential log or record of the smart contract up to its current state on the blockchain. In some embodiments, in addition to being stored on the blockchain, the log may also be provided or stored off-chain. Since the event stream ES is based on inputs and outputs related to transactions, the described techniques show a method for establishing an immutable chronological log of all transactions related to the event stream ES representing a smart contract SC on the blockchain. The event stream ES may represent the smart contract using an FSM, DFA, etc.

[0112] 3-5 may be performed by a platform processor associated with an application programming interface (API). In some embodiments, the steps of FIGs. 3-5 may be performed by an executor component associated with the computation services module 104 seen in FIG. 1 and described in more detail in FIG. 1b. In other embodiments, the steps of FIGs. 3-5 may be performed by a data writer associated with the data services module 102 seen in FIG. 1 and described in more detail in FIG. 1b. In this case, the data writer is triggered or invoked by the platform processor's executor.

[0113] FIG. 3 relates to creating a new event stream.

[0114] Step 302 shows receiving a request from a client, the request relating to a new smart contract for a given client. Figure 3 relates to creating a new event stream ES using a blockchain for an SC. The request from the client is in the form of a HyperText Transfer Protocol (HTTP) transmission protocol, as described above.

[0115] In step 304, since the request is for a new smart contract associated with the client, a new event stream ES will be initialized or created for this smart contract SC. This step involves identifying new events within the request that should now be associated with the smart contract.

[0116] Step 306 illustrates obtaining data related to the first event E0 based on the event data in the received request of step 302, so that a new event stream ES is created on the blockchain for the smart contract SC.

[0117] Step 308 shows creating a first blockchain transaction TX0 for a new event stream ES where n=0. In some embodiments, prior to the creation of the first transaction, this step may also include determining a hierarchical deterministic (HD) keychain K to be used in 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 or parent or master key based on the known BIP 21 protocol. The HD key creation and transfer protocol greatly simplifies key generation, allows the creation of child accounts that can operate independently, and gives each parent account the ability to monitor or control its child accounts even if the child account is compromised. The HD protocol uses a single root seed to create a hierarchy of child keys, grandchild keys, and other descendant keys with separate deterministically generated integer values. Also, each child key 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 of the entire hierarchy. In addition to the above advantages, in this embodiment, the generation of this key is performed by the platform processor, thus removing the resources and functionality of this generation from the client. Therefore, a HD wallet does not need to be implemented by the client. In step 308, the key chain K is K=K n=0 to N where n is an integer between 0 and N, each integer n representing a current length or current number of events associated with the event stream ES, and N representing a maximum or final value of n.

[0118] 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 a service request made by the client.

[0119] Step 310 is a step of determining whether the output of the blockchain transaction TX0 created in step 308 is a first unspent transaction output (UTXO 0_dust ). In some embodiments, the dust output is associated with a lock script protected by a first derived key pair K0 in the set of keys derived from the HD keychain K in step 308. The dust output is associated with a value (of a digital asset) that is below a defined limit of a transaction or has a defined minimum value, i.e., below the mining fee required to spend such a transaction. There may also be other inputs related to digital assets associated with the operational float, or digital assets or cryptocurrency funds maintained by or associated with the payment processor. It is also possible to have other outputs of the transaction that are digital asset modification outputs.

[0120] Thus, in some embodiments, the Create template of a blockchain transaction for creating an event stream ES as per this embodiment is a Create template whose first input must not be dust. Advantageously, this would indicate that there are no previous entries in the event stream and that this is the first entry. The Create template also specifies that the first output of the template is dust, and that there is no data carrier or data output (hence no OP_RETURN) since there is no event data associated with the Create state other than the creation of a new event stream ES.

[0121] Step 312 illustrates sending transaction TX0 to a blockchain, where the transaction may be sent by a miner node or BSV node software associated with the platform processor to a blockchain such as the Bitcoin SV network for inclusion in a subsequent block. In some embodiments, once mined, the transaction identifier TX0 may be used to uniquely identify a newly created event stream ES or a new smart contract associated with the client.

[0122] Step 314 shows sending the results related to the created event stream ES of TX0 to the client, where the results are provided in HTTP transmission protocol format. The results related to the event stream may be copied or stored separately from the blockchain.

[0123] Figure 4 relates to updating the state of a smart contract by appending a new event to the end of an existing event stream ES associated with the smart contract on the blockchain.

[0124] Step 402 depicts receiving a request from a client, the request being to modify or update an existing smart contract SC identified in the request. The request from the client is in the form of a HyperText Transfer Protocol (HTTP) transmission protocol.

[0125] In step 404, the current state of the smart contract ES nis determined based on an event stream ES that is specific to the smart contract SC. The event stream ES is stored or implemented in a blockchain. In some cases, the current state of the smart contract SC may be determined from a snapshot or log of the event stream ES stored off-chain. For example, this log or snapshot database may be provided within the platform 100 of FIG. 1 or may be stored in a location that can be retrieved or accessed by the platform processor.

[0126] As discussed in connection with step 308 of FIG. 3, in some embodiments, the event stream ES on the blockchain is n=0 to N where n is an integer from 0 to N, each integer n representing a current length or current number of events associated with the event stream ES, and N represents a 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 some other suitable method for validating the client or a service request made by the client.

[0127] Step 406 is event E n , which is an event currently to be appended or appended to the event stream ES on the blockchain based on event data related to the smart contract SC in the received request of step 402.

[0128] Step 408 is to generate a previous blockchain transaction TX associated with the event stream ES of the smart contract SC. n-1 Once identified, the identified previous transaction TX n-1 The key pair K associated withn-1 is determined. As described above, this may be based on the same seed key pair K described in step 404.

[0129] Step 410 indicates creating a current blockchain transaction TX for an event stream ES where 0 < n < N. n In some embodiments, a key pair K for the current event E n is derived from the seed key pair K. The current event E added to the end of the event stream ES n The blockchain transaction TX created for n includes the following. n - A first input that consumes the dust output associated with the previous transaction TX n-1 n-1 n n_dust n_dust n n_data wherein the consumption is authorized by the obtained key pair K for the previous transaction, the first input, n_dust - A first unspent transaction output (UTXO n_dust ) that is the dust output of the current transaction TX, wherein the dust output is associated with a lock script protected by the derived key pair, the first unspent transaction output (UTXO - And a final unspent transaction output (UTXO n n_data n_data ) associated with event data representing the current event E.

[0130] As described above, a dust output is associated with a (digital asset) value that is less than the defined limit of the transaction or has a defined minimum value. There may also be other inputs related to the digital asset based on the operating float. This float may be controlled by the platform processor. It is also possible to have other outputs of the transaction that are digital asset change outputs.

[0131] Thus, in some embodiments, the Update template of a blockchain transaction for updating an event stream as per this embodiment is an Update template where the first input must be dust and the first output must be dust. Advantageously, this indicates the presence of a previous entry in the event stream. n It also indicates that (the now or current event data) comes after the previous transaction or state of the smart contract SC. Thus, advantageously, the transaction follows the dust chain and comes before the next state. The Update template includes a data carrier, i.e. a data output that carries the event data or result related to the current event or state. This may be a non-consumable OP-RETURN output.

[0132] The use of dust outputs in transactions is advantageous to maintain an immutable, continuous record of all transactions as they occur with respect 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 remain in order in the blockchain, but this does not guarantee preservation of the chronological order of the transactions, since transactions may be mined into blocks at different times. The use of a dust output of a previous transaction consumed as a first input of the current transaction, where the consumption is based on a respective unique key associated with the lock / unlock script of each transaction, ensures an unambiguous, continuous, tamper-proof record of the chronologically ordered event stream.

[0133] Step 412: The transaction TX is added to the blockchain. nwhere the transaction may be submitted by a miner node or BSV node software associated with the platform processor to a blockchain such as the Bitcoin SV network for inclusion in a subsequent block. In some embodiments, once mined, the transaction identifier may be used to uniquely identify the event stream ES or smart contract SC.

[0134] Step 414 is TX n The created event stream ES is then sent to the client, where the results are provided in HTTP transmission protocol format. The results may be copied or stored separately from the blockchain. In some embodiments, this may be done by sending the final unspent transaction outputs (UTXOs) to the client. n_data In some embodiments, the event data in the (UTXO n_data Event E in n The 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 embodiments, n The hash may be applied prior to generating event data associated with the request received by the payment processor in the step for . If a hash is applied by the client, the event data in the request is private even before it reaches the platform processor. In other embodiments, the event data may be provided as publicly available raw data from the blockchain.

[0135] FIG. 5 relates to terminating an existing smart contract and corresponding event stream on a blockchain.

[0136] Step 502 illustrates receiving a request from a client, the request relating to the termination of an existing smart contract SC associated with an event stream ES implemented using blockchain. The request from the client is in the form of a HyperText Transfer Protocol (HTTP) transmission protocol.

[0137] As discussed in connection with step 308 of FIG. 3, the event stream ES on the blockchain is n=0 to N where n is an integer from 0 to N, each integer n representing a current length or current number of events associated with the event stream ES, and N representing a 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 some other suitable method of validating the client or the request made.

[0138] In step 504, the current state of the smart contract ES n is determined based on an event stream ES that is specific to the smart contract SC. The event stream ES is stored or implemented in a blockchain. In some cases, the current state of the smart contract SC may be determined from a snapshot or log of the event stream ES stored off-chain. For example, this log or snapshot database may be provided within the platform 100 of FIG. 1 or may be stored in a location that can be retrieved or accessed by the platform processor.

[0139] Step 506 is the final event E N, which is an event currently to be appended or appended to an event stream ES on the blockchain based on event data related to the smart contract SC in the received request of step 502.

[0140] Step 508 is to generate a previous blockchain transaction TX associated with the event stream ES of the smart contract SC. N-1 Once identified, the identified previous transaction TX N-1 The key pair K associated with N-1 is determined. As mentioned above, this is based on the same seed key pair K described in step 504.

[0141] Step 510 calculates the current blockchain transaction TX for the new event stream ES, where n=N. N In some embodiments, the current event E N A key pair K for N is derived from the seed key pair K. The current event E for terminating the event stream ES for the smart contract N Blockchain transaction TX created for N includes the following: - previous transaction TX N-1 a first input that consumes a dust output associated with a key pair K for a previous transaction obtained in step 508; N-1 The first input is authorized by - The first unspent transaction output (UTXO) associated with a digital asset that exceeds the defined limit of unspent outputs N )

[0142] At the final event of the event stream indicating the terminated state of the smart contract SC, all transaction outputs return changes. There is no dust output, as there is no requirement or need to track the next stage of the terminated event stream. Thus, when n=N, no dust output is provided by the platform processor. In other words, the output may be considered a change output (a payment of digital assets) associated with the event stream ES. Advantageously, this represents or indicates the final terminated state of the event stream being tracked. In some embodiments, there is also no event data or data carrier element, i.e., OP_RETURN, for the output, as the event or contract is in a terminated state. Thus, no separate dust and data carrier output is generated to terminate the event stream ES, and the first output, together with the absence of data output, also indicating termination, exceeds the dust limit to signal that this is the end of the event stream on the blockchain. There may be other inputs or change outputs associated with the digital assets from the operational float. In some embodiments, the value of the digital assets associated with the dust described in connection with FIG. 3 and FIG. 4 may simply be added to one or more other outputs.

[0143] Thus, in some embodiments, the Close template for a blockchain transaction to terminate an event stream as in this embodiment is a Close template whose first input must be dust, like the first input of the Update template of Figure 6. The first output must not be dust, which advantageously serves as an end-of-ledger marker and further distinguishes the Close template from an Update template. As with the Create template of Figure 3, there is no data carrier such as OP_RETURN in the Close template.

[0144] Step 512 is to add the transaction TX to the blockchain. Nwhere the transaction may be submitted by a miner node or BSV node software associated with the platform processor to a blockchain, such as the Bitcoin SV network, for inclusion in a subsequent block.

[0145] Step 514 is TX N The event stream ES created in the request is sent to the client with the associated results, the results being provided in HTTP transmission protocol format.

[0146] Figure 6 relates to a second aspect of the disclosure and illustrates a computer-implemented method for accessing a platform for executing smart contracts associated with a blockchain, such as platform 100 illustrated in Figure 1. The method of Figure 6 is implemented by one or more processors associated with a client.

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

[0148] In step 604, a client prepares a request for a service, such as the computation service 104 of FIG. 1. The request may include one or more events E associated with a smart contract SC. n In some embodiments, the step is for the request to be associated with the event E instead of the raw data for additional privacy and security. n The requested event E is generated to include hashed event data about n This includes applying a hash function to the event data relating to the

[0149] In some embodiments, the client includes a client alias or identifier and / or a service identifier in the request so that the request can be routed to the correct endpoint and so that the platform processor can check the validity of the requesting client and the client's permission to use the requested service.

[0150] In step 606, since the platform processor is implemented as an HTTP or REST API, the request prepared in step 604 is transmitted using HyperText Transfer Protocol (HTTP) or a similar transmission protocol format, which may be managed and / or provided by a gateway service for the platform processor discussed above.

[0151] Step 608 includes obtaining one or more software libraries and validation tools for processing data associated with the smart contract SC. The software libraries may include a validation tool that validates the events E provided in the event stream ES associated with the smart contract SC. n The smart contract SC may include functionality allowing the client to recover a snapshot or instance of the state of the smart contract SC based on a replay or recovery of the smart contract. This may be provided in the form of a software development kit (SDK). Advantageously, a validation tool provided to the client together with the SDK allows the client to compare any recovered or replayed snapshot of the smart contract with a respective stored or retrieved instance of the event stream ES representing the resulting state of the smart contract SC. This is to check that any results received by the client have not been tampered with or that incorrect results have not been provided to the client.

[0152] An outcome based on the current state of the smart contract is then received, at step 610. In some embodiments, the received outcome is based on the event E n The result is provided to the client in the form of an HTTP transmission protocol. In some embodiments, the result may identify the state of the smart contract currently reflected in the event stream. n The event stream ES associated with may be stored in log or event stream storage separate from the blockchain within or associated with the platform processor.

[0153] Advantageously, the software library in step 608 may include a real or actual input event E for the smart contract SC. n Test input event TE related to n Provides a client with functionality to replay or restore a snapshot or instance of a smart contract SC based on the test input TE n is the most recent event processed by the platform. n or based on previous input events provided by the client n Then, the test event TE n This recovered snapshot based on its corresponding real-world event E n Regarding or corresponding real-world event E n The state of the smart contract recorded in the event stream ES n can be used to independently verify

[0154] In some cases, the client may request a test event nIn other embodiments, the client may already have executable code associated with the software of the smart contract SC so that the client can execute the software based on the corresponding test input TE. In other embodiments, the client may be able to directly call the executable code associated with the smart contract SC via the platform processor without using any gateway service for the platform, i.e., the direct call may be via a remote procedure call (RPC). This is because the client may be able to directly call the executable code associated with the smart contract SC via the platform processor without using any gateway service for the platform, i.e., the direct call may be via a remote procedure call (RPC). n For a given input event E n Therefore, the software library can, for validation or audit purposes, retrieve real-world events E associated with the event stream ES for the smart contract SC. n This makes it possible to reproduce the

[0155] The verification tool advantageously verifies that the client has replayed or restored the snapshot for a given event E n The smart contract may include one or more software modules or codes provided to the client that allow the state of the smart contract SC to be compared with the state of the smart contract recorded in the (blockchain) transaction, i.e., associated with the event stream ES associated with the smart contract SC. n Note that it is not necessary for E to be the most recent event in the event stream ES, but this is usually the most common case. Any other previous real events E that have taken place and have already been provided or written to the event stream ES may be included in the event stream. n Based on the test input TE n Note that it is possible to provide

[0156] In some embodiments, the validation tool also enables validation of the replayed or recovered event stream by comparison with a current snapshot or state of the smart contract SC, which may be stored off-chain, such as in an event log or instance snapshot database, to verify whether they match. In some embodiments, the validation tool may also enable the client to perform a comparison with data directly related to the event stream ES from the blockchain, if required.

[0157] Thus, in some embodiments, a validation tool in combination with a client-related SDK (client library) enables or performs the following steps: (a) Obtain executable code associated with the smart contract SC. In some examples, this may be based on binary code already available to the client, or the client may invoke the latest version of the smart contract software directly via the executor platform. (b) actual or real events E that have already taken place in relation to a smart contract and thus already written to the blockchain directly, i.e., without using the platform’s gateway or HTTPS API; n Test input event based on TE n Therefore, the test event TE n is a log of smart contracts, i.e., an event stream ES, which is processed in relation to the real events E and stored in the blockchain. n Therefore, the verification tool can generate a corresponding test input event TE n The event E is being verified using n The smart contract SC has a function for directly invoking the contract software for replaying the event stream ES to restore a snapshot or state of the smart contract SC based on the event stream ES. (c) Since the verification tool is generally configured to invoke the contract software based on test events instead of real events that have already occurred, the executor platform 100 may include such test events TE in the event stream ES associated with the smart contract SC. n The validator does not write data or invoke data-writing operations or services to record the test events invoked by the validator. Records of the test events invoked by the validator may be recorded in another off-chain log or store associated with either the client or the platform. However, the test events are not written to the blockchain, and the event stream does not include real-world events E related to the smart contract SC that occurred. n It contains only an unambiguous indication of the sequence of

[0158] Advantageously, the implementation of a blockchain-related event stream and its sequential log for tracking smart contract execution implemented by the methods of the first and second aspects of the present disclosure provides guarantees regarding the immutability of smart contract events and the immutability of event ordering. Once written, all attempts to tamper with the smart contract in any of the following ways are either prevented or revealed: - Change the content of the event - Change the order of events - Insert events at the beginning or middle of a stream - Delete an event from anywhere in the stream In other words, the present disclosure makes it possible to prove the following properties about the event streams that trace smart contracts: - Each entry in the event stream has not been modified since it was written - No entries have been inserted between previously consecutive entries - The entry has not been deleted - Entries are not reordered

[0159] 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 data from the blockchain for all clients, to writing data to the blockchain.

[0160] Example implementation An example of an event stream where capturing an event log such as Event Stream ES is useful is an application that tracks and records smart contracts SC that are configured for a game such as Marx, X, X (or more commonly known as Tic-Tac-Toe) that uses the blockchain.

[0161] The following sections detail the construction of different types of smart contracts to illustrate how specific outcomes are provided through platform services. Here, the smart contract SC is for the game of tic-tac-toe.

[0162] Tic-tac-toe is a paper-and-pencil game for two players, X and O, who alternate between marking a 3x3 grid. The player who successfully lines up three of his / her marks horizontally, vertically, or diagonally is the winner. To win the game, players must line up three of their marks horizontally, vertically, or diagonally.

[0163] A diagram of the game can be seen in Figure 7.

[0164] The game is played by two players, O and X. Players are nominated and may take turns filling squares until a winning sequence of squares is built or, potentially, no such sequence of squares is built.

[0165] Each square is labeled by a coordinate pair A1, B1, ..., B3, C3. A square can be either filled or empty. A filled square must be filled by one player. The whole game may be modeled as a pair of nested state machines. The state machine for a single square can be seen in Figure 7a.

[0166] The outer state machine, which contains nine instances of the above mentioned mass state machines (A1-C3), can be seen in Figure 7b.

[0167] A single play of a game may be represented by initial metadata describing the players, followed by a log of the sequentially filled squares, providing enough data to allow the game to be reproduced by any replica or entity or node, and the outcome of the game to be independently verified.

[0168] The example game from the previous part of this specification, represented by its event stream, may be illustrated as follows:

[0169] [Table 2]

[0170] Each entry in the log above is an event E in the event stream ES for the game (SC). n It is.

[0171] Alice and Bob may use custom client software, such as mobile apps, to interact with the platform services gateway, which in turn interacts with the underlying Executor Platform, shown in Figure 1b, which is responsible for arranging the construction of a new event stream ES and delivering events to the appropriate smart contract program SC.

[0172] After each turn, an event stream ES, encapsulated as a series of on-chain transactions, is generated so that local or client-side applications can view the current state of the game ES n Alternatively, if the snapshot state of the game is small, the current state of the game may be presented back to both players as it is updated.

[0173] The process of making moves by players in a game is detailed in the sequence flow diagram of FIG.

[0174] In this example, there is no explicit message shown as being sent to other players, although this could be the case. To simplify the above diagram, the internal messaging is omitted. Event streams for smart contracts enable the ability of observer replication of the contract's events. Thus, any authorized entity may subscribe to notifications on a given event stream ES to receive updates. Similarly, snapshot notifications may be added, but are not shown above.

[0175] Using the same tic-tac-toe example, below we give an example of providing an immutable, tamper-proof log of continuous events of a smart contract SC using an event stream ES.

[0176] Consider the game up to n=4 (the five states of the smart contract, i.e. the game, from 0 to 4) as follows:

[0177] [Table 3]

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

[0179] [Table 4]

[0180] We believe that there has been an attempt to tamper with or modify the copy of the log maintained for this sequence, such as by inserting a different entry for the outcome when n=4, so that the log does not reflect the actual state of the game, as given below.

[0181] [Table 5]

[0182] This is immediately identified by checking or auditing the automatically generated sequential log of the event stream on the blockchain, since the input of a transaction consuming the dust output of the transaction for n=3 is not enabled. It will be appreciated that if such a game involves financial transactions (e.g., subscriptions), there may be a desire from the player to check the veracity of their game log and whether they are honoring the odds or difficulty advertised by the given game provider. As described above, by storing the individual game entries (or their hashes) of a given game in the event stream ES, the player can be confident that the in-game events can be checked and verified independently of any internal system maintained by the game provider.

[0183] It will be further appreciated that each event in a given event stream does not necessarily 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, tamper-proof log of said events is desired. Examples of events in a given event stream may include, for example, inputs and / or outputs of a given smart contract running locally or remotely (preferably off-chain), messages sent between two or more participants of a given online messaging conversation, physical measurements performed by sensors or IoT devices to measure, for example, weather, location of vehicles, goods, people, etc., tracking of drugs / medicines including, for example, manufacturer, transportation, pharmacist location, prescription amount, recipient information, etc., amounts credited to and / or withdrawn from an account (whether the account is credited with cryptocurrency or fiat currency), changes in exchange rates, execution of trades, requests to buy goods or shares, etc. Ultimately, the context in which an event stream is generated and used is at the convenience of the parties using the platform processor to generate such event streams.

[0184] 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 related 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, a memory controller that may be configured to communicate with a storage subsystem 2606 including 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 described in this disclosure.

[0185] 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 .

[0186] 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 generally as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0187] 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 other systems and transmitting data from the computing device 2600 to other systems. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a network such that the data technician can transmit data to and receive data from the device while at a remote location, such as a data center.

[0188] 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 touch screen integrated into the display, a voice input device such as a voice recognition system, a microphone, and / or other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

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

[0190] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data structures that may provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), when executed by one or more processors, may provide functionality of one or more embodiments of the present disclosure and may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 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 or DVD or Blu-ray) drives 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 described in this disclosure, and data related to the transactions and blocks described in this disclosure.

[0191] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). A device that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted through the ports that connect 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 intended 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.

[0192] Enumerated exemplary embodiments The present disclosure is hereby considered based on the following sections related to the above aspects, which are provided herein as exemplary embodiments to better explain, describe and understand the claimed aspects and embodiments. 1. A computer-implemented method for enabling execution of one or more smart contracts associated with a blockchain, the method being performed by a platform processor associated with an application programming interface (API), comprising: receiving a request from a client, the request being related to a smart contract (SC), the request from the client being based on a HyperText Transfer Protocol (HTTP) transmission protocol format; accessing a smart contract SC related to the request; Identifying an event stream (ES) associated with the blockchain, the event stream ES being specific to a smart contract SC, the event stream representing a state of the smart contract SC; The current state ES of the smart contract SC based on the identified event stream ES n where n is an integer between 0 and N, each integer n representing a current number of current states or events associated with the smart contract SC, and N representing a maximum or final value or state of n; invoking execution of a smart contract SC based on the received request; Create a new event E based on the received request. n and New Event E n Updated current state of smart contract based on ES n+1 Steps to get Invoking updating of an event stream ES associated with a smart contract SC by a step including: Updated current status regarding smart contracts n+1 and storing or providing a result based on the result. 2. The step of invoking the execution of a smart contract SC is Obtaining a unique identifier for the smart contract SC from the received request; Accessing a given smart contract SC from a contract store based on the identifier; The method of claim 1, further comprising providing the smart contract SC to one or more processors to execute one or more software routines or programming instructions associated with the smart contract. 3. Based on the determination that n=0, a new event E n The step of processing A new event E for the smart contract SC in the received requestn identifying, as a first event, each event stream ES associated with the smart contract SC for creating; a first unused output UTXO that is a dust output 0_dust processing the received event E by creating a blockchain transaction TX0 that includes n sending the transaction TX0 to the blockchain; and providing a result associated with the updated event stream ES. The method according to claim 1 or 2, comprising: 4. The method according to claim 3, wherein the blockchain transaction TX0 includes an identifier or hash of the smart contract SC. 5. Based on the determination that 0 < n < N, processing a new event E n comprises: identifying, as a current event, the new event E regarding the smart contract SC in the received request for n modifying each event stream ES associated with the smart contract SC; a first input that consumes a dust output associated with a previous transaction of the event stream ES; a first unused transaction output UTXO that is a dust output; n_dust and a final unused transaction output UTXO associated with event data representing the current event E n creating a blockchain transaction TX n_data including the first input, the first unused transaction output UTXO, and the final unused transaction output UTXO; n processing the received event E by creating the blockchain transaction TX; n sending the transaction TX to the blockchain; and providing a result associated with the updated event stream ES. n The method according to claim 1 or 2, comprising: 6. The current blockchain transaction TX ​n The final unspent transaction output (UTXO) n_data Event E in n 6. The method of claim 5, wherein the event data includes a hash of the event data. 7. The method of claim 6, wherein the hash of the event data is applied by a platform processor. 8. The method of claim 6, wherein the hash of the event data is applied by the client before being included in a request received by the platform processor. 9. Current Blockchain Transaction TX n The final unspent transaction output (UTXO) n_data Event E in n 7. The method of claim 6, wherein the event data comprises raw event data. 10. Based on the determination that n=N, a new event E n The step of processing A new event E for the smart contract SC in the received request n as a final event for terminating the event stream ES; A first input that consumes dust outputs associated with a previous transaction in the event stream ES; and The final unspent output UTXO associated with a digital asset above a defined dust output value N Blockchain transaction TX containing N By creating a n and Transaction TX created on the blockchain N and sending TX N and providing a result related to the event stream ES. 11. The method of any one of clauses 3 to 10, wherein the sending step includes including the created transaction in a subsequent block associated with the mined blockchain. 12. The method of any one of clauses 3 to 11, comprising identifying the event stream ES based on a transaction identifier associated with the sent blockchain transaction. 13. The method of any one of clauses 3 to 12, comprising determining the state of the smart contract SC based on a transaction identifier associated with a sent blockchain transaction. 14. The blockchain transaction that was created Inputs relating to digital assets; and 14. The method of any one of clauses 3 to 13, further comprising one or more change outputs associated with the digital asset. 15. The method of claim 14, wherein the digital asset is associated with an managed float. 16. Determining a hierarchical deterministic keychain K to be used in the event stream ES associated with the smart contract SC, the keychain K being such that K=K n=0 to N 16. The method of any one of clauses 3 to 15, comprising the step of: including a set of private / public key pairs derived from a selected parent key pair such that: 17. The step of invoking updating the event stream ES associated with the smart contract may include updating the event stream ES associated with the smart contract when a new event E n 17. The method of any one of clauses 1 to 16, further comprising accessing a data writer associated with the platform processor to process the data. 18. The method of any one of clauses 1 to 17, wherein the result is a snapshot state of the smart contract SC, and the result is stored in and / or accessible from an instance state database associated with the platform processor. 19. The method according to any one of clauses 1 to 18, wherein the results are provided to the client based on the HTTP transmission protocol format. 20. Current state of smart contract SCES n The results related to - Event E n The transaction identifier that was sent to the blockchain - Merkle proof of inclusion of transactions in the blockchain header - A copy of the block header in which the transaction was included 20. The method of any one of claims 1 to 19, including a certificate verifying at least one of: 21. The method of any one of clauses 1 to 20, wherein the smart contract SC is implemented as a finite state machine (FSM). 22. The method according to any one of clauses 1 to 21, comprising storing a copy or record or log based on the outcome for each event of the event stream ES for the smart contract SC in an off-chain storage resource. 23. The method of any one of clauses 1 to 22, wherein the API is a HyperText Transfer Protocol (HTTP) Application Programming Interface (API) endpoint, the endpoint being provided to the client using HTTP Secure (HTTPS). 24. The method of any one of clauses 1 to 23, wherein the API is an alias associated with the platform processor, the alias is specific to the platform processor and is provided by an alias-based addressing service, the addressing service having machine-readable resources accessible from a defined or well-known location, the machine-readable resources including one or more capabilities associated with the platform processor, and the alias is associated with an asymmetric cryptographic key pair for authentication. 25. The method of any one of clauses 1 to 24, wherein in response to receiving a request from a client, the method includes providing one or more software libraries and / or validation tools for processing data related to a smart contract SC associated with the request. 26. A computer-implemented method for accessing a smart contract associated with a blockchain, the method being performed by one or more processors of a given client among a plurality of clients; Obtaining or identifying an application programming interface (API) endpoint associated with one or more processors associated with the platform for executing the smart contract SC; One or more events E related to the smart contract SC n sending the request to a platform, the request being sent based on a HyperText Transfer Protocol (HTTP) transmission protocol format; obtaining one or more software libraries and validation tools for processing data related to the smart contract SC; Requested event E n receiving a result based on an output script of a blockchain transaction associated with the smart contract SC, the result representing an updated state of the smart contract SC, the result being received using an HTTP transmission protocol format. 27. A request is generated for event E. n Event E n 27. The method of claim 26, comprising applying a hash function to event data relating to the event. 28. Based on the results, recovering an event stream ES associated with the smart contract SC using one or more software libraries; 28. The method of claim 26 or 27, further comprising comparing the recovered event stream ES with a result to verify the state of the smart contract using one or more validation tools. 29. The method of any one of clauses 26 to 28, wherein the one or more software libraries are associated with a software development kit (SDK) received from the platform. 30. The method of clause 26 or 27, wherein the client is associated with an alias related to the platform processor, the alias is specific to the platform processor and is provided by an alias-based addressing service, the addressing service having machine-readable resources accessible from a defined or well-known location, the machine-readable resources including one or more capabilities related to the client, and the alias is associated with an asymmetric cryptographic key pair for authentication. 31. A computing device including a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform a computer-implemented method described in any one of clauses 1 to 25, the computing device being associated with a platform processor. 32. A computing device including a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform a computer-implemented method described in any one of clauses 26 to 30, the computing device being associated with a client. 33. A computer system including 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 according to the computing device of clause 31, the at least one client implemented according to the computing device of clause 32, and the at least one platform processor communicating with the following components of a platform service: Smart Contract Store, Event stream logs, The instance state database, and Data Writer via a wireless communications network, and wherein the platform service provides a plurality of blockchain-related services for a plurality of clients. 34. A computer-readable storage medium having stored thereon executable instructions which, when executed by a computer processor, cause a computer to perform any one of the methods of paragraphs 1 to 30.

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

[0194] 100 Platform Processors, Platform Services 102 Data services, processing resources 104 Computational services, processing resources 105 Blockchain Network 106 Commerce services, processing resources 108 API 110 Blockchain / Platform Interface Software 1000 Executor Platform 1000a Event Gateway 1000b Event Gateway 1001 Customer Applications 1003 Contract Store 1004 Data Services 1005 Bitcoin SV Blockchain 1006 Contract Management API 1007 Contract Repository 1008 Executor 1009 Instance state database, instance snapshot database 2600 Computing Devices 2602 Processor 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. 1. A computer-implemented method for enabling execution of one or more smart contracts associated with a blockchain, comprising: Implemented by a platform processor associated with an application programming interface (API); receiving a request from a client, the request being related to a smart contract (SC), the request from the client being based on a HyperText Transfer Protocol (HTTP) transmission protocol format; accessing the smart contract SC associated with the request; Identifying an event stream (ES) associated with the blockchain, the event stream ES being specific to the smart contract SC, the event stream ES representing a state of the smart contract SC; A current state ES of the smart contract SC based on the identified event stream ES. n where n is an integer between 0 and N, each integer n representing a current number of current states or events associated with said smart contract SC, and N representing a maximum or final value or state of n; invoking execution of the smart contract SC based on the received request; A new event E is generated based on the received request. n and The new event E n The updated current state of the smart contract based on n+1 Steps to get Invoking updating of the event stream ES associated with the smart contract SC by a step comprising: The updated current state ES of the smart contract. n+1 storing or providing a result based on the A method comprising:

2. The step of invoking execution of the smart contract SC comprises: obtaining a unique identifier for the smart contract SC from the received request; accessing a given smart contract SC from a contract store based on said identifier; providing the smart contract SC to one or more processors for executing one or more software routines or programming instructions associated with the smart contract; The method of claim 1 further comprising:

3. Based on the determination that n=0, a new event E n The step of processing The new event E for the smart contract SC in the received request. n as a first event for creating a respective event stream ES associated with said smart contract SC; The first unspent output, the dust output, is the UTXO. 0_dust Blockchain transaction TX containing 0 By creating a n and The blockchain transaction TX 0 and sending providing results related to the updated event stream ES; 3. The method of claim 1 or 2, comprising:

4. The blockchain transaction TX 0 The method of claim 3, wherein the smart contract SC includes an identifier or a hash of the smart contract SC.

5. Based on the determination that 0 < n < N, the step of processing the new event E n is The new event E for the smart contract SC in the received request. n as a current event for modifying a respective event stream ES associated with said smart contract SC; a first input that consumes a dust output associated with a previous transaction of the event stream ES; The first unspent transaction output UTXO, which is a dust output n_dust , and The current event E n The final unspent transaction output UTXO associated with the event data representing n_data Blockchain transaction TX containing n By creating a n and The transaction TX n and sending providing results related to the updated event stream ES; 3. The method of claim 1 or 2, comprising:

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

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

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

9. The current blockchain transaction TX n The final unspent transaction output (UTXO) n_data ) in the event E n The method of claim 6 , wherein the event data comprises raw event data.

10. Based on the determination that n=N, a new event E n The step of processing The new event E for the smart contract SC in the received request. n as a final event for terminating said event stream ES; a first input that consumes a dust output associated with a previous transaction of the event stream ES; and The final unspent output UTXO associated with a digital asset above a defined dust output value N Blockchain transaction TX containing N By creating a n and The created transaction TX on the blockchain N and sending TX N providing a result related to said event stream ES; 3. The method according to claim 1 or 2, comprising:

11. 11. The method of any one of claims 3 to 10, wherein the sending step comprises including the created transaction in a subsequent block associated with the blockchain that is mined.

12. 12. A method according to any one of claims 3 to 11, comprising identifying the event stream ES based on a transaction identifier associated with a sent blockchain transaction.

13. 13. A method according to any one of claims 3 to 12, comprising determining the state of the smart contract SC based on a transaction identifier associated with a sent blockchain transaction.

14. The blockchain transaction that was created Inputs relating to digital assets; and One or more modified outputs associated with said digital asset The method of any one of claims 3 to 13, further comprising:

15. The method of claim 14 , wherein the digital asset is associated with a managed float.

16. Determining a hierarchical deterministic keychain K to be used in the event stream ES associated with the smart contract SC, wherein the hierarchical deterministic keychain K is: K=K n=0 to N 16. A method according to any one of claims 3 to 15, comprising the step of including a set of private / public key pairs derived from a selected parent key pair such that:

17. The step of invoking updating the event stream ES associated with the smart contract includes invoking the new event E n The method of claim 1 , further comprising the step of accessing a data writer associated with the platform processor to process the.

18. the result is a snapshot state of the smart contract SC, 18. The method of any one of claims 1 to 17, wherein the results are stored in and / or accessible from an instance state database associated with the platform processor.

19. 19. The method according to any one of claims 1 to 18, wherein the result is provided to the client based on the HTTP transmission protocol format.

20. The current state ES of the smart contract SC n The results related to - Event E n The transaction identifier sent to the blockchain - a Merkle proof of inclusion of said transaction in the header of said blockchain - A copy of the block header in which the transaction was included 20. The method of claim 1, further comprising a certificate verifying at least one of:

21. 21. The method according to any one of claims 1 to 20, wherein the smart contract SC is implemented as a finite state machine (FSM).

22. 22. A method according to any one of claims 1 to 21, comprising storing a copy or record or log based on the outcome for each event of the event stream ES relating to the smart contract SC in an off-chain storage resource.

23. the API is a HyperText Transfer Protocol (HTTP) Application Programming Interface (API) endpoint; 23. The method of any one of claims 1 to 22, wherein the endpoint is provided to the client using HTTP Secure (HTTPS).

24. the API is an alias associated with the platform processor; the alias is unique to the platform processor and is provided by an alias-based addressing service; the addressing service having machine-readable resources accessible from a defined or well-known location; the machine-readable resources include one or more capabilities associated with the platform processor; 24. The method of any one of claims 1 to 23, wherein the alias is associated with an asymmetric cryptographic key pair for authentication.

25. 25. The method of any one of claims 1 to 24, wherein in response to receiving the request from the client, the method comprises providing one or more software libraries and / or validation tools for processing data related to the smart contract SC associated with the request.

26. 1. A computer-implemented method for accessing a smart contract associated with a blockchain, comprising: Executed by one or more processors of a given client among the plurality of clients; Obtaining or identifying an application programming interface (API) endpoint associated with one or more processors associated with the platform for executing the smart contract SC; One or more events E related to said smart contract SC n sending the request to the platform, the request being sent based on a HyperText Transfer Protocol (HTTP) transmission protocol format; obtaining one or more software libraries and validation tools for processing data related to said smart contract SC; Requested event E n receiving a result based on an output script of a blockchain transaction related to the smart contract SC, the result representing an updated state of the smart contract SC, the result being received using an HTTP transmission protocol format; A method comprising:

27. The request is for the event E n The event E n 27. The method of claim 26, comprising applying a hash function to the event data relating to the event.

28. based on the results, recovering an event stream ES associated with the smart contract SC using the one or more software libraries; comparing the recovered event stream ES with the results to validate the state of the smart contract using the one or more validation tools.

28. The method of claim 26 or 27, further comprising:

29. 29. The method of any one of claims 26 to 28, wherein the one or more software libraries are associated with a software development kit (SDK) received from the platform.

30. the client is associated with an alias associated with the platform processor; the alias is unique to the platform processor and is provided by an alias-based addressing service; the addressing service having machine-readable resources accessible from a defined or well-known location; the machine-readable resources include one or more capabilities associated with the client; 28. A method according to claim 26 or 27, wherein the alias is associated with an asymmetric cryptographic key pair for authentication.

31. 26. A computing device including a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform a computer-implemented method according to any one of claims 1 to 25; A computing device, wherein the computing device is associated with a platform processor.

32. 31. A computing device including 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 according to any one of claims 26 to 30; A computing device, the computing device being associated with a client.

33. 1. A computer system comprising at least one platform processor communicatively coupled to at least one client over a wireless communications network, 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 is implemented in accordance with the computing device of claim 31 , The at least one client is implemented in accordance with the computing device of claim 32, The at least one platform processor processes the following components of a platform service: Smart Contract Store, Event stream logs, The instance state database, and Data Writer communicatively coupled via the wireless communications network to one or more of The platform service provides a plurality of blockchain-related services for a plurality of clients.

34. A computer readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer, cause the computer to perform the method of any one of claims 1 to 25.

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

Images