Method and system for storing smart contract events

Abstract

A method for distributing event data of smart contracts executing on a blockchain to subscribing systems includes: collecting, by a processor of a blockchain node in a blockchain network, a set of event data issued by smart contracts executing on a blockchain associated with the blockchain network; identifying, by the processor of the blockchain node, communication data of one or more subscriber computing systems; and after a predetermined period of time, transmitting, by a transmitter of the blockchain node, the collected event data to each of the one or more subscriber computing systems using the communication data.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Patent Application No. 17 / 557,597, filed December 21, 2021, the entire disclosure of which is incorporated herein by reference for all purposes.

[0002] The present disclosure relates to distributing smart contract event data, and in particular to collecting event data emitted from smart contracts running on a blockchain via functions, and distributing the collected event data to subscriber systems for feeding to handlers for consumption outside the blockchain. [Background technology]

[0003] Blockchain was initially created as a storage mechanism for use in making payment transactions with cryptocurrencies. Using a blockchain offers many benefits, such as decentralization, distributed computation, transparency regarding transactions, and also providing anonymity regarding individuals or entities involved in transactions. One of the more common aspects of a blockchain is that it is an immutable record, i.e., all transactions that are part of the chain are stored within it and cannot be altered due to computational requirements and bandwidth limitations, especially as chains get longer and more nodes are added to the blockchain network.

[0004] Over time, needs arose for participants beyond the basic digital currency transfers that blockchain is known for. These needs led to the development and creation of smart contracts, which are self-executing data objects that are stored on the blockchain and can automate processes according to the participants' desires. A common use of smart contracts is escrow. In one example, a smart contract can be created and added to a blockchain that monitors the expected addition of new objects onto the chain, such as the hash of a transfer certificate. Once the addition is detected and verified by the contract, the contract self-executes and can submit a new transaction to the blockchain to transfer digital currency from one party to another, as pre-determined in the smart contract. This results in automatic payments to the recipient upon execution of the transfer certificate, such as a payment being automatically made on the blockchain when a homeowner transfers a home ownership certificate to a buyer.

[0005] Although smart contracts provide additional convenience features for users, they also have limitations. Smart contracts can affect the blockchain, for example, by submitting new transactions or by performing other actions that were traditionally performed manually through a blockchain wallet. However, smart contracts cannot perform any actions outside the blockchain. Currently, there are no publicly available systems that allow actions to be performed outside the blockchain as a result of activities performed on the blockchain. Thus, there is a need for such a system, especially one that is scalable and easily adaptable to meet all the needs of interested users. Summary of the Invention

[0006] This disclosure provides a description of a system and method for distributing event data of smart contracts executed on a blockchain to subscribing systems. A smart contract that is added to a blockchain can include an emit function. When a smart contract is executed, a detectable event, the emit function emits data (referred to herein as "event data"), the format and value of which can be determined by the creator of the smart contract and can be influenced by values ​​in the blockchain itself. A blockchain node monitors the execution of smart contracts on the blockchain and collects the emitted event data. Interested users can subscribe to a blockchain node, which can periodically distribute all collected event data to subscribers. The subscriber's system can receive the collected event data and feed the event data to a handler, which can initiate functions outside the blockchain and therefore perform external actions as a result of activity on the blockchain. By using the emit function and automatic distribution to subscribers, any interested user can have all the necessary data collected and automatically distributed by the blockchain node with little to no changes to existing systems. Furthermore, event data can be in any form and amount to suit the user's needs, satisfying a nearly infinite number of use cases, greatly increasing the utility and functionality of smart contracts.

[0007] A method for distributing event data of smart contracts executing on a blockchain to subscribing systems includes: collecting, by a processor of a blockchain node in a blockchain network, a set of event data issued by smart contracts executing on a blockchain associated with the blockchain network; identifying, by the processor of the blockchain node, communication data of one or more subscriber computing systems; and after a predetermined period of time, transmitting, by a transmitter of the blockchain node, the collected event data to each of the one or more subscriber computing systems using the communication data.

[0008] A system for distributing event data of smart contracts executing on a blockchain to subscriber systems includes a blockchain network including blockchain nodes; and one or more subscriber computing systems, the blockchain nodes including a processor that performs the following operations: collect a set of event data issued by smart contracts executing on a blockchain associated with the blockchain network; and identify communication data of the one or more subscriber computing systems; and a transmitter that transmits the collected event data to each of the one or more subscriber computing systems using the communication data after a predetermined period of time.

[0009] The scope of the present disclosure is best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawing figures, which include the following figures: [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a block diagram illustrating a high-level system architecture for distributing and using event data for smart contracts, according to an example embodiment. [Diagram 2]FIG. 2 is a block diagram illustrating a computing device for distributing, collecting, and using smart contract event data in the system of FIG. 1 according to an exemplary embodiment. [Diagram 3] FIG. 2 is a flow diagram illustrating a process for distributing and using smart contract event data in the system of FIG. 1 according to an exemplary embodiment. [Figure 4] 1 is a flowchart illustrating an example method for distributing event data of a smart contract, according to an example embodiment. [Diagram 5] FIG. 1 is a block diagram illustrating a computer system architecture, in accordance with an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of the exemplary embodiments is for purposes of illustration only, and is therefore not intended to necessarily limit the scope of the disclosure.

[0012] A system for using event data from smart contracts FIG. 1 illustrates a system 100 for distributing event data collected from smart contracts running on a blockchain for use in other systems outside the blockchain.

[0013] The system 100 may include a blockchain network 102. The blockchain network 102 may include a number of blockchain nodes 104. Each blockchain node 104 is a computing system, such as that shown in FIG. 2 or FIG. 5, described in more detail below, configured to perform functions associated with processing and managing a blockchain, including generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, validating new blocks, and maintaining a copy of the blockchain. In some embodiments, the listening system 108 may be a blockchain node 104.

[0014] A blockchain may be a distributed ledger comprising at least a number of blocks. Each block may include at least a block header and one or more data values. Each block header may include at least a timestamp, a block reference value, and a data reference value. The timestamp is the time when the block header is generated and may be represented using any suitable method (e.g., UNIX timestamp, DateTime, etc.). The block reference value may be a value that references (e.g., based on the timestamp) a preceding block in the blockchain. In some embodiments, the block reference value in the block header may be a reference to the block header of the most recently added block preceding each block. In an exemplary embodiment, the block reference value may be a hash value generated by hashing the block header of the most recently added block. The data reference value may similarly be a reference to one or more data values ​​stored in the block including the block header. In an exemplary embodiment, the data reference value may be a hash value generated by hashing one or more data values. For example, the block reference value may be the root of a Merkle tree generated using one or more data values.

[0015] The use of block reference values ​​and data reference values ​​in each block header can provide immutability to the blockchain. Any attempted changes to the data value require the generation of a new data reference value for the block, which in turn requires the generation of a new block reference value for the subsequent block, which in turn requires the generation of new block reference values ​​for all subsequent blocks. For the changes to be permanent, the above must be performed and updated for all blockchain nodes 104 in the blockchain network 102 before a new block is created and added to the blockchain. Computational and communication limitations can make such changes very difficult, if not impossible, and thus the blockchain achieves immutability.

[0016] In some embodiments, a blockchain can be used to store information about blockchain transactions performed between two different blockchain wallets. A blockchain wallet can include a private key of a cryptographic key pair used to generate a digital signature that serves as a payer's acknowledgement of the blockchain transaction. The digital signature can be verified by the blockchain network 102 using the public key of the cryptographic key pair. In some cases, the term "blockchain wallet" can specifically refer to a private key. In other cases, the term "blockchain wallet" can refer to a computing device (e.g., participant device 106, etc.) that stores a private key for use in a blockchain transaction. For example, each computing device can have its own private key for each cryptographic key pair, and each computing device can be a blockchain wallet for use in transactions with a blockchain associated with the blockchain network. The computing device can be any type of device suitable for storing and utilizing a blockchain wallet, such as a desktop computer, a laptop computer, a notebook computer, a tablet computer, a mobile phone, a smartphone, a smart watch, a smart TV, a wearable computing device, an embedded computing device, etc.

[0017] Each blockchain data value stored in the blockchain may correspond to a blockchain transaction or other data storage, if applicable. A blockchain transaction may include at least a digital signature of the sender of the currency (e.g., the first participant device 106), generated using the sender's private key, a blockchain address of the recipient of the currency (e.g., the second participant device 106), generated using the recipient's public key, and the blockchain currency amount to be transferred or other data being stored. In some blockchain transactions, the transaction may also include one or more blockchain addresses of the sender where the blockchain currency is currently stored (e.g., the digital signature certifies access to such currency), and an address generated using the sender's public key for any changes held by the sender. The addresses sent with the cryptocurrency that can be used in future transactions are called "output" addresses, as each address was previously used to capture the output of a previous blockchain transaction, and are also called "unspent transactions". This is because there is currency sent to the address during a previous transaction where that currency remains unspent. In some cases, the blockchain transaction may also include the sender's public key for use by the entity in validating the transaction. For conventional processing of a blockchain transaction, such data may be provided by either the sender or the recipient to a blockchain node 104 in the blockchain network 102. The node may verify the digital signature using the public key of the sender's wallet's cryptographic key pair. The node may also verify the sender's access to the funds (e.g., that the unspent transaction has not yet been spent and was sent to an address associated with the sender's wallet) and a process known as "confirming" the transaction. The node may then include the blockchain transaction in a new block.In a traditional blockchain implementation, a new block may be verified by other nodes in the blockchain network 102 and distributed to all of the blockchain nodes 104 in the blockchain network 102 before being added to the blockchain. If the blockchain data value is not associated with a blockchain transaction but instead is associated with the storage of other types of data, the blockchain data value may still include or involve digital signature verification.

[0018] The system 100 may include participant devices 106. Participant devices 106 may be computing devices that participate in a blockchain associated with the blockchain network 102, e.g., computing devices that have a blockchain wallet and transfer digital currency from one participant device's blockchain wallet to another participant device's blockchain wallet. Each transfer of digital currency between participant devices 106 may be stored in the blockchain via a blockchain transaction that is stored in a blockchain data value in the blockchain. Participant devices 106 may also participate in the blockchain via the transmission of other data for storage in the blockchain, such as hash values ​​of documents, storage of identity data for use in authentication, and other use cases that may be realized via immutable distributed storage.

[0019] In the system 100, the blockchain can be configured to store smart contracts. A smart contract can be a self-executable data object stored in the blockchain with a blockchain data value that executes when one or more criteria are met. The smart contract can monitor new blocks added to the blockchain until expected data that meets the criteria is added to the blockchain or the criteria is otherwise met. Once the criteria are met, the smart contract self-executes and can result in one or more actions related to the blockchain, such as submitting a new transaction for the transfer of digital currency or submitting new data for storage in a new blockchain data value in the blockchain.

[0020] In one example, users of two different participant devices 106 can enter into a contract to sell a vehicle to be paid for using digital currency. The buyer can agree to pay a specific amount of digital currency, such as 500 units, which is paid upon delivery of the vehicle by the seller. In a traditional situation, the seller would have to give the vehicle to the buyer, hoping that the buyer would fulfill the contractual obligations with difficult recourse if the buyer did not pay. With smart contracts, a self-executing smart contract can be developed to add a new transaction to the blockchain to transfer the 500 units of currency from the buyer's blockchain wallet to the seller's blockchain wallet. The basis for the smart contract can be the storage of a transfer certificate or other document on the blockchain. The smart contract self-executes when it detects the document added to the blockchain, resulting in payment from the buyer to the seller. With smart contracts, if the seller executes the transfer, the buyer cannot block the transfer of currency. Similarly, the seller cannot force the transfer of currency without actually providing the buyer with a documented ownership of the vehicle. The smart contract can also be developed to expire if no storage of the document is detected within a predefined period of time, allowing the seller to execute the transfer of the vehicle in a timely manner and the buyer to retain control of their digital currency if not.

[0021] Traditionally, smart contracts are a convenient tool for automatically performing actions related to a blockchain. However, in traditional blockchains, smart contracts are limited to such actions, limiting the ability of users to perform actions outside of the blockchain as a result of activities performed on the blockchain. The system 100 provides an improvement over traditional blockchains through the use of emit functions in smart contracts.

[0022] In the system 100, a blockchain node 104 monitors the execution of smart contracts on the blockchain to detect the execution of an emit function. An emit function is a function that emits data in any format and size desired by the developer of the smart contract that conforms to the data requirements set forth in the blockchain itself. As described herein, such a function is described as an "emit" function, but any suitable name can be used for the function. When an emit function is executed in a smart contract, the data and value specified by the function are emitted and collected by the monitoring blockchain node 104. The blockchain node 104 collects this data (referred to herein as "event data" because the data is collected as a result of an event, i.e., the execution of a smart contract). In some cases, the collected event data may include a timestamp of collection and additional data associated by the blockchain node, such as an identifier for the smart contract, an identifier for the block in which the blockchain data value or the executed smart contract is stored. In other cases, the collected event data can be stored as a single set without additional information. In such cases, it is up to the developer of the smart contract itself to include identifying information or other data in the collected emit function. For example, a developer can include in an emit function that is collected along with other event data a unique reference number that the developer can understand so that the set of event data can be later identified as desired.

[0023] An example of a smart contract emit function is as follows: function emitPayment (eventName: string, totals: uint, payment: micropayment.Payment): boolean { var map:Map = new Map(); var from:string = payment.from; var to:string = payment.to; var location:string = payment.location; var amount:uint = payment.amount; map.put (“eventName”, eventName); map.put("from", from); map.put(“to”, to); map.put(“location”, location); map.put (“amount,” amount); emit(map); return true; }

[0024] In the above example, the smart contract would result in the emission of event data including a name (e.g., as specified by a developer in the smart contract) and information about the payment in the smart contract (e.g., as detected as a result of the execution of the smart contract), including information about the transferor, transferee, amount, and geographic location. In such an example, a user can use the unique event name to later find the event data, for example, to find when a desired blockchain transaction occurred, and use the transferor, transferor, amount, and location to verify that the transaction was as desired.

[0025] The system 100 may include a listening system 108. The listening system 108 may subscribe to the blockchain node 104. As a result of subscribing, the listening system 108 may receive collected event data from the blockchain node 104, collected from all emit functions detected by the blockchain node 104. To subscribe, the listening system 108 may register with the blockchain node 104 and provide information regarding the collection of event data to be used by the blockchain node 104 to ensure delivery of the collected event data. Such information may include, for example, an email address for delivery by email, a phone number for delivery by short messaging service message, a username or other unique identifier for delivery by an application program or web page, etc. In some cases, the listening system 108 may provide information regarding filtering of the event data. For example, the listening system 108 may provide an identification value and subscribe to only the set of event data that includes the identification value, in which case the blockchain node 104 may deliver only the set of event data in which the identification value is detected.

[0026] After the listening system 108 subscribes to the blockchain node 104, the blockchain node 104 can distribute the collected event data to the listening system 108. In some cases, the blockchain node 104 can distribute the event data at the time of collection. In other words, when an emit function is detected and the event data therein is collected, the blockchain node 104 can distribute the collected event data immediately to all subscribed listening systems 108. In other cases, the blockchain node 104 can distribute the event data in a predetermined period of time. In some cases, the predetermined period of time can be set by the blockchain node 104. For example, the blockchain node 104 can distribute all collected event data on an hourly or daily basis, in which case all event data collected since the last distribution can be distributed after the end of the next period of time. In other cases, the listening system 108 can specify when to distribute the event data. For example, during registration, the listening system 108 may specify that event data is to be delivered every four hours, in which case the blockchain node 104 may deliver all event data collected during each four-hour period to the listening system 108 at the end of that period.

[0027] Delivery of the collected event data may include transmitting all collected event data to the listening system 108 using an appropriate communication network and method. In some cases, the collected event data may be compressed, encrypted, or modified before transmission to suit the needs or requirements of the listening system 108 (e.g., as specified during registration). The listening system 108 may receive the collected event data and then provide the event data to a handler. A handler may be an application program or module configured to accept the event data, perform analysis thereof, and perform additional functions. In some embodiments, the listening system 108 may be configured to filter or format the event data before providing the data to the handler, or the handler may be configured to filter or format the event data before analyzing and using it. For example, the listening system 108 may check each set of event data for a particular event name or other identifier, discard any set of event data in which such a value is not found, and provide sets of event data that include such values ​​to the handler for processing.

[0028] In one example, a buyer may be interested in purchasing a vehicle from a seller, with the desire to store a proof of transfer on the blockchain for immutability and security, but with payment made outside of the blockchain, such as by credit card, wire transfer, or other suitable transaction. In this example, a smart contract may be developed by a participant system (e.g., one of the entities or an authorized third party) that detects the addition of a transfer certificate to the blockchain. Once the certificate is detected, the smart contract may self-execute, where self-execution includes execution of an emit function that includes an identifier with a particular value and a copy of the detected certificate. The identifier and certificate may be collected as event data by the blockchain node 104 and delivered to a listening system 108, which may be utilized by one of the entities or an authorized third party. The listening system 108 may receive the event data and provide the data to a handler. The handler can analyze the event data and, upon receiving event data with that particular identifier, determine that a certificate must be attached to the identifier, that the certificate must be verified to match an expected certificate, and, if the verification is successful, an electronic payment transaction is made from the buyer's account to the seller's account for the payment of the agreed upon amount of fiat currency. As a result, the buyer and seller can store the sale of the car on the blockchain, but the payment is made using a transaction that occurs outside of the blockchain.

[0029] Thus, the methods and systems described herein enable the execution of functions and actions outside of the blockchain as a result of actions taken on the blockchain itself. By using smart contracts and emit functions, data can be collected from smart contracts as a result of blockchain activity and then provided to other systems (listening systems 108) for use in activities taken outside of the blockchain. This significantly expands the actions that blockchain participants can perform. Furthermore, by utilizing smart contracts, the methods described herein can be implemented without modification to existing blockchains, and the blockchain node 104 only needs to detect the execution of an emit function, which can be executed for a single blockchain node 104 in the blockchain network 102 without affecting the operation of the blockchain itself. Furthermore, by using emit functions that do not require specific values ​​or formats, a variety of use cases can be implemented to suit the needs of participants. Thus, the methods and systems described herein can significantly improve existing systems with minimal onboarding and adjustments to existing processes.

[0030] Computing Device 2 illustrates one embodiment of a computing device 200. It will be apparent to one skilled in the art that the embodiment of the computing device 200 illustrated in FIG. 2 is provided by way of example only and is not intended to be exhaustive of all possible configurations of a computing device 200 suitable for performing the functions described herein. For example, computer system 500 illustrated in FIG. 5 and described in more detail below may be a suitable configuration of a computing device 200. The computing devices 200 described herein may be utilized as various components of the system 100, such as the blockchain nodes 104 and the listening system 108.

[0031] The computing device 200 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some cases, the receiving device 202 may be configured to receive data from other blockchain nodes 104, participant devices 106, listening systems 108, and other systems and entities via one or more communication means, such as radio frequency, local area network, wireless area network, cellular communication network, Bluetooth, the Internet, etc. In some embodiments, the receiving device 202 may include multiple devices, such as different receiving devices receiving data over different networks, such as a first receiving device receiving data over a local area network and a second receiving device receiving data over the Internet. The receiving device 202 may receive an electronically transmitted data signal, whereby upon receipt of the data signal by the receiving device 202, data may be superimposed or encoded on the data signal and may be decoded, parsed, read, or retrieved. In some cases, the receiving device 202 may include a parsing module for parsing the received data signal to retrieve the data superimposed thereon. For example, the receiving device 202 may include an analysis program configured to receive and convert data signals into usable input for functions performed by the processing device to implement the methods and systems described herein.

[0032] The receiving device 202 can be configured to receive data signals electronically transmitted by a blockchain node 104, which can be overlaid or encoded with blocks, blockchain data values, confirmation messages, cryptographic keys, collected event data, requests for settings or registration information, etc. The receiving device 202 can also be configured to receive data signals electronically transmitted by a participant device 106, which can be overlaid or encoded with new blockchain transactions, new smart contracts, requests for blockchain data, registration information or settings for distribution of event data, etc. The receiving device 202 can further be configured to receive data signals electronically transmitted by a listening system 108, which can be overlaid or encoded with registration information, settings, requests for collected event data, distribution rules, etc.

[0033] The computing device 200 may also include a communication module 204. The communication module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of the computing device 200 to perform the functions described herein. The communication module 204 may include one or more communication types and may utilize various communication methods for communication within the computing device. For example, the communication module 204 may include a bus, a connecting pin connector, wires, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the computing device 200 and external components of the computing device 200, such as an externally connected database, display device, input device, etc. The computing device 200 may also include a processing unit. The processing unit may be configured to perform the functions of the computing device 200 described herein, as will be apparent to one of ordinary skill in the art. In some embodiments, the processing unit may include and / or consist of multiple engines and / or modules, such as the query module 216, the generate module 218, the handler module 220, etc., that are specifically configured to perform one or more functions of the processing unit. As used herein, the term "module" may be software or hardware that is specifically programmed to receive an input, perform one or more operations using the input, and provide an output. The inputs, outputs, and operations performed by the various modules will be apparent to one of ordinary skill in the art based on this disclosure.

[0034] The computing device 200 can include blockchain data 206. The blockchain data 206 can be configured to store data associated with the blockchain, which can include blockchain wallets, blocks, cryptographic keys, data formatting rules, communication data, etc. If the computing device 200 can be a listening system 108, the blockchain data 206 can also include data used by handlers, filtering rules, formatting rules, etc. If the computing device 200 can be a blockchain node 104, the blockchain data 206 can also include data used to generate new blockchain data values, generate new blocks, verify generated blocks, etc.

[0035] Computing device 200 may also include memory 214. Memory 214 may be configured to store data (e.g., public keys, private keys, symmetric keys, etc.) for use by computing device 200 in performing the functions described herein. Memory 214 may be configured to store data using appropriate data formatting methods and schemas and may be any appropriate type of memory (e.g., read-only memory, random access memory, etc.). Memory 214 may include, for example, encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and application programs for the processing device, and other data suitable for use by computing device 200 in performing the functions disclosed herein, as would be apparent to one of ordinary skill in the art. In some embodiments, memory 214 may include a relational database using a structured query language to store, identify, modify, update, access, etc., stored structured data sets. The memory 214 can be configured to store, for example, cryptographic keys, cryptographic key pairs, cryptographic algorithms, encryption algorithms, communication information, data formatting rules, signature generation algorithms, subscriber information, collected event data, event data filtering and formatting rules, handler program code, and the like.

[0036] The computing device 200 may include a query module 216. The query module 216 may be configured to run a query on a database to identify information. The query module 216 may receive one or more data values ​​or query strings, based on which it may run a query string on a specified database, such as the memory 214 of the computing device 200, to identify information stored therein. The query module 216 may output the identified information to an appropriate engine or module of the computing device 200, as needed. The query module 216 may, for example, run a query on the memory 214 to identify communication information of listening systems 108 currently subscribed to deliver collected event data.

[0037] Computing device 200 may also include a generation module 218. The generation module 218 may be configured to generate data for use by computing device 200 in performing functions described herein. The generation module 218 may receive instructions as input, generate data based on the instructions, and output the generated data to one or more modules of computing device 200. For example, the generation module 218 may be configured to generate blockchain data items, blocks, confirmation messages, cryptographic key pairs, digital signatures, functions and instructions for performing actions, and the like.

[0038] The computing device 200 may also include a handler module 220. The handler module 220 may be configured to analyze the collected event data and perform or initiate one or more actions as a result. The handler module 220 may receive the collected event data as input (which may also include data used to analyze the event data, such as filtering or formatting rules), and may process and execute the collected event data as required and initiate or execute one or more actions as a result. The actions may include sending instructions or other data to another module or engine of the computing device 200. The handler module 220 may be configured, for example, to process the collected event data to determine one or more actions that need to be performed based on the value of the collected event data, and initiate the action(s).

[0039] The computing device 200 may also include a transmitting device 222. The transmitting device 222 may be configured to transmit data over one or more networks via one or more network protocols. In some cases, the transmitting device 222 may be configured to transmit data to other blockchain nodes 104, participant devices 106, listening systems 108, and other entities via one or more communication means (e.g., a local area network, a wireless area network, cellular communication, Bluetooth, radio frequency, the Internet, etc.). In some embodiments, the transmitting device 222 may include multiple devices, such as a first transmitting device for transmitting data over a local area network and a second transmitting device for transmitting data over the Internet, or different transmitting devices for transmitting data over different networks. The transmitting device 222 may electronically transmit a data signal with the superimposed data, the data being parsable by a receiving computing device. In some cases, the transmitting device 222 may include one or more modules for superimposing, encoding, or formatting the data into a data signal suitable for transmission.

[0040] The transmitting device 222 can be configured to electronically transmit data signals to the blockchain node 104 that may be overlaid or encoded with blockchain data values, blocks, confirmation messages, requests for blockchain data, subscriber registration information, subscriber criteria, requests for collected event data, etc. The transmitting device 222 can also be configured to electronically transmit data signals to the participant devices 106 that may be overlaid or encoded with blockchain data, blocks, blockchain data values, identifiers for new blockchain transactions, requests for digital signatures or cryptographic keys, etc. The transmitting device 222 can further be configured to electronically transmit data signals to the listening system 108 that may be overlaid or encoded with registration information or criteria, collected event data, requests for blockchain data, etc.

[0041] Delivering and using event data from smart contracts Figure 3 illustrates the process of collecting event data emitted from smart contracts executed on a blockchain and using it to perform one or more actions outside of the blockchain.

[0042] In step 302, a blockchain node 104 in the blockchain network 102 can detect an emit function executed by a smart contract stored and executed in the blockchain. To detect an emit function, a receiver 202 of the blockchain node 104 can receive data generated or transmitted by a smart contract, and a processor of the blockchain node 104 can identify an emit function in the data. In step 304, the blockchain node 104 can collect event data that is output as a result of the detected emit function, where the event data can be of any suitable size or format and can include any number and format of data values. In step 306, the blockchain node 104 can temporarily store the event data in the memory 214 of the blockchain node 104, for example, while waiting for a predetermined period of time set by the blockchain node 104 itself or requested by the listening system 108 to which the collected event data is delivered.

[0043] After the predetermined period of time has elapsed, in step 308, the sending device 222 of the blockchain node 104 may then electronically transmit the collected event data, and any other event data collected since the last distribution, to the subscribed listening systems 108 using an appropriate communication network and means. In step 310, the receiving device 202 of the listening system 108 may receive the collected event data. In step 312, the generating module 218 or other appropriate module or engine of the listening system 108 may filter and / or format the received event data, if applicable. For example, the listening system 108 may filter the event data by discarding all collected event data that does not contain a particular data value (e.g., an identifier field having a particular identification number) and format any data that has not been discarded, such as by decrypting the data using an appropriate decryption key.

[0044] At step 314, the listening system 108 may input the filtered and formatted event data to the handler module 220. The handler module may analyze the data using any particular program code, rules, etc., and at step 316 may perform one or more actions as a result. In an exemplary embodiment, the one or more actions may be performed outside of the blockchain. For example, the one or more actions may include an electronic payment transaction using fiat currency, a transfer of data to an external computing system, the execution of an application program, modifications to the configuration of a computing device, etc.

[0045] Exemplary Method for Delivering Event Data FIG. 4 illustrates a method 400 for distributing event data of a smart contract running on a blockchain to subscribing systems.

[0046] In step 402, a set of event data issued by a smart contract executing on a blockchain associated with a blockchain network (e.g., blockchain network 102) may be collected by a processor of a blockchain node (e.g., blockchain node 104) in the blockchain network. In step 404, communication data of one or more subscriber computing systems (e.g., listening system 108) may be identified by a processor (e.g., query module 218) of the blockchain node. In step 406, the collected event data may be transmitted after a predetermined period of time by a transmitter (e.g., transmitter 222) of the blockchain node to each of the one or more subscriber computing systems using the communication data.

[0047] In one embodiment, the method 400 may further include receiving, by a receiver (e.g., receiving device 202) of the blockchain node, a new block of the blockchain, where the smart contract self-executes after receiving the new block. In some embodiments, the predetermined period of time may be specified in the smart contract. In one embodiment, the predetermined period of time may be based on storing, by a processor of the blockchain node, a block in the blockchain that includes the smart contract.

[0048] In some embodiments, the smart contract may include an emit function, and the event data collected by the blockchain node may be specified in the emit function. In one embodiment, the method 400 may further include collecting, by a processor of the blockchain node, a set of second event data emitted by a second smart contract executing on the blockchain, and the collected set of second event data is transmitted to each of the one or more subscriber computing systems if collected before the end of the predetermined time period. In some embodiments, the blockchain node does not store the collected event data on the blockchain node or a storage medium accessible by the blockchain node. In one embodiment, each of the one or more subscriber computing systems is not a blockchain node in the blockchain network.

[0049] Computer System Architecture 5 illustrates a computer system 500 in which an embodiment of the present disclosure, or portions thereof, can be implemented as computer readable code. For example, the blockchain node 104, participant device 106, and listening system 108 of FIG. 1, and the computing device 200 of FIG. 2 can be implemented in the computer system 500 using hardware, a non-transitory computer readable medium having instructions stored thereon, or a combination thereof, and can be implemented in one or more computer systems or other processing systems. The hardware can embody modules and components used to implement the methods of FIG. 3 and FIG. 4.

[0050] Where programmable logic is used, such logic may be executed on commercially available processing platforms configured with executable software code, resulting in a special purpose computer or special purpose device (e.g., programmable logic arrays, application specific integrated circuits, etc.). Those skilled in the art will appreciate that embodiments of the disclosed subject matter may be implemented in a variety of computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functionality, and pervasive or miniature computers that may be incorporated into virtually any device. For example, the above-described embodiments may be implemented using at least one processor device and memory.

[0051] A processor unit or device described herein may be a single processor, multiple processors, or a combination thereof. A processor device may have one or more processor "cores." The terms "computer program medium," "non-transitory computer-readable medium," and "computer usable medium" described herein are generally used to refer to tangible media, such as removable storage unit 518, removable storage unit 522, and a hard disk installed in hard disk drive 512.

[0052] Various embodiments of the present disclosure are described with respect to this exemplary computer system 500. After reading this description, it will be apparent to one of ordinary skill in the art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations are described as sequential processes, some operations may in fact be performed in parallel, concurrent, and / or distributed environments, where program code is stored locally or remotely for access by uniprocessor or multiprocessor machines. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0053] The processor unit 504 can be a special purpose or general purpose processor unit that is specially configured to perform the functions described herein. The processor unit 504 can be connected to a communication infrastructure 506, such as, for example, a bus, a message queue, a network, a multi-core message passing scheme, etc. The network can be any network suitable for performing the functions disclosed herein and can include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. The computer system 500 can also include a main memory 508 (e.g., random access memory, read only memory, etc.) and can also include a secondary memory 510. The secondary memory 510 can include a hard disk drive 512 and a removable storage drive 514, such as, for example, a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, etc.

[0054] The removable storage drive 514 may read from and write to the removable storage unit 518 in a well-known manner. The removable storage unit 518 may include a removable storage medium that can be read from or written to by the removable storage drive 514. For example, if the removable storage drive 514 is a floppy disk drive or a universal serial bus port, the removable storage unit 518 may be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 518 may be a non-transitory computer readable recording medium.

[0055] In some embodiments, secondary memory 510 may include alternative means for allowing computer programs or other instructions to be loaded into computer system 500 (e.g., removable storage unit 522 and interface 520). Those skilled in the art will appreciate that examples of such means may include program cartridges and cartridge interfaces (e.g., as found in video game systems), removable memory chips (e.g., EEPROM, PROM, etc.) and associated sockets, other removable storage units 522 and interfaces 520.

[0056] Data stored in computer system 500 (e.g., in main memory 508 and / or in secondary memory 510) may be stored on any type of suitable computer-readable medium (e.g., optical storage (e.g., compact disc, digital versatile disc, Blu-ray disc, etc.) or magnetic tape storage (e.g., hard disk drive)). The data may be organized in any type of suitable database configuration (e.g., a relational database, a Structured Query Language (SQL) database, a distributed database, an object database, etc.). Suitable configurations and storage types will be apparent to those skilled in the art.

[0057] Computer system 500 may also include a communications interface 524. Communications interface 524 may be configured to allow software and data to be transmitted between computer system 500 and external devices. Exemplary communications interface 524 may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, and the like. The software and data transferred via communications interface 524 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals as would be apparent to one skilled in the art. The signals travel over communications path 526, which is configured to transmit the signals and may be implemented using wire, cable, optical fiber, a telephone line, a cellular phone link, a radio frequency link, and the like.

[0058] The computer system 500 may further include a display interface 502. The display interface 502 may be configured to allow data to be transferred between the computer system 500 and an external display 530. Exemplary display interfaces 502 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), etc. The display 530 may be any suitable type of display to display data transferred via the display interface 502 of the computer system 500, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, a capacitive touch display, a thin film transistor (TFT) display, etc.

[0059] The computer program medium and computer usable medium may refer to memory (e.g., main memory 508 and secondary memory 510), which may be semiconductor memory (e.g., DRAM, etc.). These computer program products may be a means for providing software to the computer system 500. Computer programs (e.g., computer control logic) may be stored in the main memory 508 and / or the secondary memory 510. The computer programs may also be received via the communication interface 524. Such computer programs, when executed, may enable the computer system 500 to perform the methods described herein. In particular, the computer programs, when executed, may enable the processor unit 504 to perform the methods described herein shown in Figures 3 and 4. Thus, such computer programs may represent the controller of the computer system 500. When the present disclosure is implemented using software, the software may be stored in the computer program product and loaded into the computer system 500 using the removable storage drive 514, the interface 520, and the hard disk drive 512 or the communication interface 524.

[0060] The processor unit 504 may include one or more modules or engines configured to perform the functions of the computer system 500. Each module or engine may be implemented using hardware and in some cases may utilize software (e.g., corresponding to program code and / or programs stored in the main memory 508 or secondary memory 510). In such cases, the program code may be compiled by the processor unit 504 (e.g., by compiling the module or engine) before execution by the hardware of the computer system 500. For example, the program code may be source code written in a programming language (e.g., assembly language or machine code) that is translated into a lower-level language for execution by the processor unit 504 and / or any additional hardware components of the computer system 500. The compilation process may include the use of lexical analysis, preprocessing, parsing, semantic analysis, syntax-driven translation, code generation, code optimization, and any other techniques suitable for translating the program code into a lower-level language suitable for controlling the computer system 500 to perform the functions disclosed herein. Those skilled in the art will appreciate that such processing results in computer system 500 being a specially configured computer system 500 that is uniquely programmed to perform the functions described above.

[0061] The technology consistent with the present disclosure provides, among other things, a system and method for distributing event data of a smart contract executed on a blockchain to a subscribing system. Although various exemplary embodiments of the disclosed system and method are described above, it should be understood that they are presented for purposes of illustration only and are not limiting. They are not exhaustive and do not limit the disclosure to the precise forms disclosed. Modifications and variations are possible in light of the above teachings, or may be obtained from implementations of the present disclosure without departing from the breadth or scope.

Claims

1. 1. A method for distributing event data of a smart contract executed on a blockchain to a subscribing system, comprising: collecting, by a processor of a blockchain node in a blockchain network, a set of event data issued by a smart contract executing on a blockchain associated with the blockchain network; identifying, by the processor of the blockchain node, communication data of one or more subscriber computing systems; After a predetermined period of time, transmitting, by a transmitter of the blockchain node, the collected event data to each of the one or more subscriber computing systems using the communication data; A method comprising:

2. 10. The method of claim 1, further comprising receiving, by the blockchain node receiver, a new block of the blockchain, wherein the smart contract self-executes after receiving the new block.

3. 2. The method of claim 1 , wherein the predetermined period of time is specified in the smart contract.

4. 2. The method of claim 1 , wherein the predetermined period of time is based on storing, by the processor of the blockchain node, a block on the blockchain that includes the smart contract.

5. The smart contract includes an emit function, The method of claim 1 , wherein the event data collected by the blockchain node is specified in the emit function.

6. collecting, by the processor of the blockchain node, a second set of event data emitted by a second smart contract executing on the blockchain; The method of claim 1 , wherein the second set of collected event data is transmitted to each of the one or more subscriber computing systems if collected before the end of the predetermined period of time.

7. 2. The method of claim 1, wherein the blockchain node does not store the collected event data at the blockchain node or on a storage medium accessible by the blockchain node.

8. The method of claim 1 , wherein each of the one or more subscriber computing systems is not a blockchain node in the blockchain network.

9. A system for distributing event data of a smart contract executed on a blockchain to a subscribing system, comprising: a blockchain network including blockchain nodes; one or more subscriber computing systems; The blockchain node includes: collecting a set of event data emitted by smart contracts executing on a blockchain associated with the blockchain network; identifying communication data of the one or more subscriber computing systems; a transmitter that transmits the collected event data to each of the one or more subscriber computing systems using the communication data after a predetermined period of time; Including, the system.

10. 10. The system of claim 9, wherein the blockchain node further comprises a receiver for receiving a new block of the blockchain, and wherein the smart contract self-executes upon receipt of the new block.

11. 10. The system of claim 9, wherein the predetermined period of time is specified in the smart contract.

12. 10. The system of claim 9, wherein the predetermined period of time is based on storing, by the processor of the blockchain node, a block on the blockchain that includes the smart contract.

13. The smart contract includes an emit function, 10. The system of claim 9, wherein the event data collected by the blockchain nodes is specified in the emit function.

14. The processor of the blockchain node further collects a second set of event data issued by a second smart contract executing on the blockchain; 10. The system of claim 9, wherein the second set of collected event data is transmitted to each of the one or more subscriber computing systems if collected before the end of the predetermined period of time.

15. 10. The system of claim 9, wherein the blockchain node does not store the collected event data at the blockchain node or on a storage medium accessible by the blockchain node.

16. 10. The system of claim 9, wherein each of the one or more subscriber computing systems is not a blockchain node in the blockchain network.

Images