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 more particularly 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 into handlers for use outside the blockchain. [Background technology]

[0003] Blockchain was originally created as a storage mechanism for use in conducting payment transactions using cryptocurrencies. Using a blockchain offers many benefits, including decentralization, distributed computation, transparency regarding transactions, and 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; that is, all transactions that are part of the chain are stored within it and cannot be changed due to computational requirements and bandwidth limitations, especially as the chain grows longer and more nodes are added to the blockchain network.

[0004] Over time, participants developed needs beyond the basic digital currency transfer for which blockchain is known. These needs led to the development and creation of smart contracts, which are self-executing data objects stored on the blockchain and can automate processes according to participants' wishes. 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 to the chain, such as the hash of a transfer certificate. When 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 predetermined by the smart contract. This results in automatic payments to the recipient upon execution of the transfer certificate, such as a homeowner transferring a home title certificate to a buyer, which is automatically paid on the blockchain.

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

[0006] This disclosure provides a description of a system and method for distributing event data from smart contracts running on a blockchain to subscribing systems. A smart contract added to a blockchain can include an emit function. When a smart contract executes, 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 smart contract's creator and may be affected by values ​​on the blockchain itself. Blockchain nodes monitor the execution of smart contracts on the blockchain and collect the emitted event data. Interested users can subscribe to blockchain nodes, which can periodically distribute all collected event data to subscribers. Subscriber systems can receive the collected event data and supply the event data to handlers, 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 data they need collected by blockchain nodes and automatically distributed, with little or no modification to existing systems. Furthermore, event data can be in any format and quantity to suit the user's needs, satisfying an almost limitless number of use cases and 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, wherein the blockchain nodes include a processor that performs the following operations: collecting sets of event data issued by smart contracts executing on a blockchain associated with the blockchain network; and identifying communication data of the one or more subscriber computing systems; and a transmitter that, after a predetermined period of time, transmits the collected event data to each of the one or more subscriber computing systems using the communication data.

[0009] The scope of the present disclosure will be best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings, of which the following figures are included: [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a block diagram illustrating a high-level system architecture for distributing and consuming event data for smart contracts, according to an example embodiment. [Figure 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. [Figure 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 example embodiment. [Figure 4] 1 is a flowchart illustrating an example method for distributing smart contract event data, according to an example embodiment. [Figure 5] FIG. 1 is a block diagram illustrating a computer system architecture, according to an exemplary embodiment. DETAILED DESCRIPTION OF THE INVENTION

[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 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 by other systems outside the blockchain.

[0013] The system 100 may include a blockchain network 102. The blockchain network 102 may include multiple blockchain nodes 104. Each blockchain node 104 is a computing system, such as that shown in FIG. 2 or FIG. 5 and described in more detail below, configured to perform functions related to blockchain processing and management, including generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, validating new blocks, and maintaining copies 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 plurality 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 the block header was 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 a preceding block in the blockchain (e.g., based on the timestamp). 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 containing 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 a block reference value and a data reference value in each block header may provide immutability to the blockchain. Any attempted change to the data value requires the generation of a new data reference value for that block, which in turn requires the generation of a new block reference value for the subsequent block, which in turn requires the generation of a new block reference value for all subsequent blocks. For the change to be permanent, this 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 may 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 contain a private key of a cryptographic key pair used to generate a digital signature that serves as a payer's authorization 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 blockchain transactions. 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 devices can be any type of device suitable for storing and utilizing a blockchain wallet, such as a desktop computer, laptop computer, notebook computer, tablet computer, mobile phone, smartphone, smartwatch, smart TV, wearable computing device, embedded computing device, etc.

[0017] Each blockchain data value stored in a blockchain may correspond to a blockchain transaction or other data storage, if applicable. A blockchain transaction may include at least the digital signature of the sender of the currency (e.g., a first participant device 106) generated using the sender's private key, the blockchain address of the recipient of the currency (e.g., a second participant device 106) generated using the recipient's public key, and the amount of blockchain currency to be transferred or other stored data. 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., a digital signature certifying access to such currency) and an address generated using the sender's public key for any changes held by the sender. Addresses sent with cryptocurrency that can be used in future transactions are called "output" addresses, as they are previously used to capture the output of previous blockchain transactions and are also called "unspent transactions." This is because there may be currency sent to the address during a previous transaction where that currency remains unspent. In some cases, a blockchain transaction may also include the sender's public key for use by entities in verifying the transaction. For traditional processing of blockchain transactions, such data may be provided by either the sender or the recipient to a blockchain node 104 in the blockchain network 102. The node can verify the digital signature using the public key of the sender's wallet's cryptographic key pair. The node can 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 the transaction, a process known as "confirming" the transaction. The node can 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 the verification of a digital signature.

[0018] The system 100 may include participant devices 106. A participant device 106 can be a computing device that participates in a blockchain associated with the blockchain network 102, e.g., a computing device that has a blockchain wallet and transfers 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 can be stored in the blockchain via a blockchain transaction that is stored in a blockchain data value within the blockchain. A participant device 106 can also participate in the blockchain through the submission 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 can be realized through immutable distributed storage.

[0019] In system 100, the blockchain can be configured to store smart contracts. A smart contract can be a self-executable data object stored on 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 are 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 within the blockchain.

[0020] In one example, users of two different participant devices 106 may enter into a contract to sell a vehicle to be paid for using digital currency. The buyer may 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 hand over the vehicle to the buyer, hoping that the buyer would fulfill their contractual obligations, which would entail difficult recourse if the buyer did not pay. With a smart contract, a self-executing smart contract may be developed to add a new transaction to the blockchain to transfer 500 units of currency from the buyer's blockchain wallet to the seller's blockchain wallet. The basis for the smart contract may be the storage of a transfer certificate or other document on the blockchain. When the smart contract detects the document added to the blockchain, it self-executes, resulting in payment from the buyer to the seller. Using a smart contract, if the seller executes the transfer, the buyer cannot block the currency transfer. Similarly, the seller cannot force the currency transfer without actually providing the buyer with documented vehicle title. The smart contract can also be developed to expire if no storage of the document is detected within a predetermined period of time, allowing the seller to execute the vehicle transfer 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 a user's ability to perform actions outside of the blockchain as a result of activity occurring on the blockchain. 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, conforming to the data requirements defined by the blockchain itself. As described herein, such a function is described as an "emit" function, although any appropriate 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, or the like. 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 understands so that the set of event data can later be 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 publication of event data that includes a name (e.g., specified by a developer in the smart contract) and information about the payment in the smart contract (e.g., 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 detect 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 a 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 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 via email, a phone number for delivery via short messaging service messages, a username or other unique identifier for delivery via 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 sets of event data that include the identification value, in which case the blockchain node 104 may deliver only sets of event data in which the identification value is detected.

[0026] After a listening system 108 subscribes to a blockchain node 104, the blockchain node 104 can distribute 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 event data therein is collected, the blockchain node 104 can immediately distribute the collected event data to all subscribed listening systems 108. In other cases, the blockchain node 104 can distribute the event data at a predetermined time period. In some cases, the predetermined time period can be set by the blockchain node 104. For example, the blockchain node 104 can distribute all collected event data hourly or daily, in which case all event data collected since the last distribution can be distributed after the end of the next time period. 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 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] Distribution of 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 event data, analyze it, and perform additional functions. In some embodiments, the listening system 108 may be configured to filter or format the event data before providing it 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 a value to the handler for processing.

[0028] In one example, a buyer may be interested in purchasing a vehicle from a seller, hoping to store proof of transfer on the blockchain for immutability and security, but make payment 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. Upon detection of the certificate, the smart contract may self-execute, which in this case includes execution of an emit function that includes an identifier with a specific value and a copy of the detected certificate. The identifier and certificate may be collected by the blockchain node 104 as event data and delivered to the 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 affix the identifier, that the certificate must be verified to match an expected certificate, and, if the verification is successful, that an electronic payment transaction be made from the buyer's account to the seller's account for payment of an agreed-upon amount of fiat currency. As a result, the buyer and seller can store the sale of the car on the blockchain, but 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 a 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 (such as the listening system 108) for use in activities taking place 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 modifying an existing blockchain; a blockchain node 104 simply needs to detect the execution of an emit function, which can be executed for a single blockchain node 104 within 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 realized to suit the needs of participants. Thus, the methods and systems described herein can significantly improve existing systems while minimizing onboarding and adjustments to existing processes.

[0030] Computing Device 2 illustrates one embodiment of a computing device 200. It will be apparent to those skilled in the art that the embodiment of computing device 200 illustrated in FIG. 2 is provided by way of example only and does not encompass 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 system 100, such as blockchain nodes 104 and listening systems 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 embodiments, 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, a local area network, a wireless area network, a 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 data may be superimposed or encoded on the data signal upon receipt by the receiving device 202 and decoded, parsed, read, or otherwise obtained. In some cases, the receiving device 202 may include an analysis module for analyzing the received data signal to obtain 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 blockchain nodes 104, which can be overlaid or encoded with blocks, blockchain data values, confirmation messages, cryptographic keys, collected event data, requests for configuration or registration information, etc. The receiving device 202 can also be configured to receive data signals electronically transmitted by participant devices 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 listening systems 108, which can be overlaid or encoded with registration information, settings, requests for collected event data, distribution rules, etc.

[0033] Computing device 200 may also include a communications module 204. Communications module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of computing device 200 to perform the functions described herein. Communications module 204 may include one or more communication types and may utilize various communication methods for communication within the computing device. For example, communications module 204 may include a bus, a contact pin connector, wires, etc. In some embodiments, communications module 204 may also be configured to communicate between internal components of computing device 200 and external components of computing device 200, such as externally connected databases, display devices, input devices, etc. Computing device 200 may also include a processing unit. The processing unit may be configured to perform the functions of computing device 200 described herein, as will be apparent to one skilled in the art. In some embodiments, the processing unit may include and / or consist of multiple engines and / or modules, such as query module 216, generation module 218, and handler module 220, 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 input, perform one or more operations using the input, and provide an output. The inputs, outputs, and operations performed by various modules will be apparent to one of ordinary skill in the art based on this disclosure.

[0034] The computing device 200 may include blockchain data 206. The blockchain data 206 may be configured to store data associated with a blockchain, which may include blockchain wallets, blocks, cryptographic keys, data formatting rules, communication data, etc. If the computing device 200 may be a listening system 108, the blockchain data 206 may also include data used by handlers, filtering rules, formatting rules, etc. If the computing device 200 may be a blockchain node 104, the blockchain data 206 may 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 processing unit application programs, and other data suitable for use by computing device 200 in performing the functions disclosed herein, as would be apparent to one skilled 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 queries 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 the query string on a designated 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 the 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, etc.

[0038] Computing device 200 may also include a handler module 220. Handler module 220 may be configured to analyze collected event data and perform or initiate one or more actions as a result. Handler module 220 may receive collected event data as input (which may also include data used to analyze the event data, such as filtering or formatting rules), process and execute the collected event data as requested, and initiate or perform one or more actions as a result. This action may include sending instructions or other data to another module or engine of computing device 200. Handler module 220 may be configured, for example, to process 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 having superimposed data that is parseable by a receiving computing device. In some cases, the transmitting device 222 may include one or more modules for superimposing, encoding, or formatting 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, which 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, which 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 also be configured to electronically transmit data signals to the listening system 108, which 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 emit functions executed by smart contracts stored and executed on the blockchain. To detect emit functions, the receiver 202 of the blockchain node 104 receives data generated or transmitted by the smart contract, and a processor of the blockchain node 104 can identify the emit functions in the data. In step 304, the blockchain node 104 can collect event data output as a result of the detected emit functions, 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, such as in the memory 214 of the blockchain node 104, while waiting for a predetermined period of time, for example, set by the blockchain node 104 itself or requested by the listening system 108 to which the collected event data is delivered.

[0043] Subsequently, at step 308, after a predetermined period of time has elapsed, the sending device 222 of the blockchain node 104 may electronically transmit the collected event data, and other event data collected since the last distribution, to subscribed listening systems 108 using an appropriate communication network and means. At step 310, the receiving device 202 of the listening system 108 may receive the collected event data. At 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 smart contracts running on a blockchain to subscribing systems.

[0046] In step 402, a set of event data issued by smart contracts 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 of the blockchain node (e.g., query module 218). In step 406, the collected event data may be transmitted, after a predetermined period of time, by a transmitter of the blockchain node (e.g., transmitter 222) to each of the one or more subscriber computing systems using the communication data.

[0047] In one embodiment, method 400 may further include receiving, by a receiver (e.g., receiving device 202) of the blockchain node, a new block of the blockchain, in which case 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, 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, wherein 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 a predetermined period of time. In some embodiments, the blockchain node does not store the collected event data on the blockchain node or on 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 embodiments of the present disclosure, or portions thereof, may 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 may be implemented in the computer system 500 using hardware, a non-transitory computer-readable medium having instructions stored thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The hardware may embody modules and components used to implement the methods of FIGS. 3 and 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 array, application-specific integrated circuit, etc.). Those skilled in the art will appreciate that embodiments of the disclosed subject matter may be practiced 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 unit 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 skilled in the art how to implement the present disclosure using other computer systems and / or computer architectures. While 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 specially configured to perform the functions described herein. The processor unit 504 can be connected to a communications infrastructure 506, such as a bus, message queue, network, multi-core message passing scheme, or the like. 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 communications network, a satellite network, the Internet, fiber optics, 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 a secondary memory 510. The secondary memory 510 can include a hard disk drive 512 and a removable storage drive 514, such as a floppy disk drive, magnetic tape drive, optical disk drive, flash memory, or the like.

[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 by which computer programs or other instructions can 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., 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 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 structure (e.g., relational database, structured query language (SQL) database, distributed database, object database, etc.). Suitable structures 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, or 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 apparent to those skilled in the art. The signals travel over communications path 526, which is configured to transmit the signals and may be implemented using electrical wire, cable, optical fiber, a telephone line, a cellular phone link, a radio frequency link, or the like.

[0058] Computer system 500 may further include a display interface 502. Display interface 502 may be configured to allow data to be transferred between 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. Display 530 may be any suitable type of display that displays data transferred via display interface 502 of 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] 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 provide software to computer system 500. Computer programs (e.g., computer control logic) may be stored in main memory 508 and / or secondary memory 510. Computer programs may also be received via communications interface 524. Execution of such computer programs enables computer system 500 to perform the methods described herein. In particular, execution of the computer programs may enable processor unit 504 to perform the methods described herein and illustrated in FIGS. 3 and 4. Such computer programs may thus represent a controller of computer system 500. If the present disclosure is implemented using software, the software may be stored in a computer program product and loaded into computer system 500 using removable storage drive 514, interface 520, and hard disk drive 512 or communications interface 524.

[0060] Processor unit 504 may include one or more modules or engines configured to perform the functions of computer system 500. Each module or engine may be implemented using hardware or, in some cases, may utilize software (e.g., corresponding to program code and / or programs stored in main memory 508 or secondary memory 510). In such cases, the program code may be compiled by processor unit 504 (e.g., by compiling the module or engine) before execution by the hardware of 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 processor unit 504 and / or any additional hardware components of 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 program code into a lower-level language suitable for controlling 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 this disclosure provides, among other things, systems and methods for distributing event data of smart contracts running on a blockchain to subscribing systems. While various exemplary embodiments of the disclosed systems and methods are described above, it should be understood that they have been presented by way of example only and are not intended to be 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 acquired from implementations of the present disclosure without departing from the breadth or scope thereof.

Claims

1. 1. A method for distributing event data of a smart contract running on a blockchain to a subscriber computing system, comprising: monitoring, by a processor of a blockchain node in a blockchain network, execution of a smart contract to detect execution of an emit function in the smart contract; collecting, by the processor of the blockchain node in the blockchain network, a set of event data emitted by the smart contract executing on a blockchain associated with the blockchain network and specified by the emit function; identifying, by the processor of the blockchain node, communication data of one or more subscriber computing systems; transmitting, by a transmitter of the blockchain node after each predetermined period of time, 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 a receiver of the blockchain node, 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 the period of time between the processor of the blockchain node storing a block in the blockchain that includes the smart contract and the processor storing a next block in the blockchain.

5. 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 collected second set of 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.

6. 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.

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

8. 1. A system for distributing event data of a smart contract running on a blockchain to a subscriber computing system, comprising: a blockchain network including blockchain nodes; one or more subscriber computing systems; The blockchain node comprises: monitoring execution of a smart contract to detect execution of an emit function within the smart contract; Collecting a set of event data emitted by the smart contract executing on a blockchain associated with the blockchain network and specified by the emit function; and 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 each predetermined period of time; Including, the system.

9. 10. The system of claim 8, wherein the blockchain node further comprises a receiver that receives a new block of the blockchain, and wherein the smart contract self-executes after receiving the new block.

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

11. 9. The system of claim 8, wherein the predetermined period of time is the period of time between the processor of the blockchain node storing a block in the blockchain that includes the smart contract and the processor storing a next block in the blockchain.

12. The processor of the blockchain node further collects a second set of event data published by a second smart contract executing on the blockchain; The system of claim 8 , wherein the collected second set of 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.

13. 10. The system of claim 8, 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.

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

Images