[0001] This disclosure relates to the technical field of data structures and databases, and more particularly to blockchains.

BACKGROUND

[0002] A blockchain is a type of distributed database that maintains a continuously growing series (i.e., a chain) of records called blocks. Each block contains a timestamp and a link to a previous block. The blocks may store transactions or other types of information. The verification process for a block may be performed fairly simply, which reduces the possibility of fraudulent transactions. By storing data distributed across a network, the blockchain reduces or eliminates the risks that come with data being held centrally.

[0003] Further, blockchain technology can make it very difficult to alter retroactively any single block of the chain. For example, the database is distributed (i.e., stored on a plurality of different computers concurrently) so all users with access to any one computer in the distributed database may be notified immediately of new additions to the blockchain.

[0004] In some cases, the transactions performed and recorded using a blockchain may be for "smart contracts" which are computer-executable "agreements" such as for performing a certain action if a certain condition is met. However, conventionally, there is no expedient way to obtain the necessary information for auditing or otherwise checking some aspects of the smart contract transactions from the corresponding blockchains.

SUMMARY

[0005] Some examples herein include a plurality of computing nodes configured as a plurality of consensus nodes participating in a consensus system. As one example, a first node able to communicate with one or more second nodes, receives an indication that a smart contract associated with a blockchain is to be executed. The first node may determine whether the blockchain includes auditing information in one or more blocks of the blockchain. For instance, the auditing information may include at least one of: node information about the first node and the one or more second nodes, digital signature information corresponding to the smart contract, information related to data received for execution of the smart contract, or information related to a communication received to invoke execution of the smart contract. Based at least partially on determining that the blockchain includes the auditing information, the first node proceeds with executing the smart contract. In some cases, if the blockchain does not include the auditing information, rather than executing the smart contract, the first node may send a notification, such as to a client device associated with a participant in the smart contract, indicating that expected auditing information is not present in the blockchain.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The detailed description is set forth with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items or features.

[0007] FIG. 1 illustrates an example architecture of a system for blockchain monitoring and management according to some implementations.

[0008] FIG. 2 illustrates an example consensus node computing device according to some implementations .

[0009] FIG. 3 illustrates an example of blockchain construction in a consensus system according to some implementations.

[0010] FIG. 4 illustrates an example of a blockchain portion according to some implementations .

[0011] FIG. 5 illustrates an example of a blockchain portion according to some implementations.

[0012] FIG. 6 is a flow diagram illustrating an example process for adding consensus node information to a blockchain according to some implementations.

[0013] FIG. 7 illustrates an example consensus node information data structure according to some implementations.

[0014] FIG. 8 is a flow diagram illustrating an example process of adding a digital signature and smart contract information to a blockchain according to some implementations.

[0015] FIG. 9 illustrates an example digital signature and smart contract source code data structure according to some implementations.

[0016] FIG. 10 is a flow diagram illustrating an example process for adding external data information to a blockchain according to some implementations.

[0017] FIG. 11 illustrates an example of an external data information data structure according to some implementations.

[0018] FIG. 12 is a flow diagram illustrating an example process for smart contract execution according to some implementations. [0019] FIG. 13 illustrates an example smart contract execution information data structure according to some implementations.

[0020] FIG. 14 is a flow diagram illustrating an example process for checking participating nodes according to some implementations.

[0021] FIG. 15 illustrates an example participating node data structure according to some implementations .

[0022] FIG. 16 is a flow diagram illustrating an example process for checking participating nodes according to some implementations.

[0023] FIG. 17 is a flow diagram illustrating an example process for determining a master node according to some implementations.

[0024] FIG. 18 is a flow diagram illustrating an example process of performing an audit according to some implementations.

[0025] FIG. 19 is a flow diagram illustrating an example process of managing a blockchain in association with execution of a smart contract according to some implementations.

DESCRIPTION OF THE EMBODIMENTS

[0026] Some implementations herein are directed to techniques and arrangements for determining and obtaining information used for managing and monitoring blockchains, such as blockchains used for executing smart contracts. In examples herein, smart contracts include computer protocols and executable code that facilitate, verify, or otherwise cause the performance of an action or other function based on the occurrence of a condition specified according to the contract. The ability to monitor or otherwise audit the execution of smart contracts with blockchains is desirable because smart contracts typically only save execution results.

[0027] In some examples herein, a blockchain that is generated for a smart contract is generated with additional auditing information such as a smart contract execution time, execution node information for nodes that executed the smart contract, and information about an event, data, or other input condition that triggered execution of the smart contract. For example, the blockchains herein enable detection if, e.g., a smart contract is attempted to be executed without one or more of the participating parties having provided a digital signature to authorize execution of the smart contract. As another example, if the smart contract relies on external data to execute the smart contract, the external data and associated metadata may be included in the blockchain, and may later be checked to validate that the function was properly executed in response to a condition of the contract, even though the external data may no longer otherwise be available. As still another example, such as in the case of a private blockchain consensus system, it may be possible for a particular participant who controls a large number of consensus nodes to add a smart contract favorable to the particular participant to the blockchain. However, implementations herein provide techniques for guarding against such action.

[0028] Some examples herein apply in the environment of private blockchain systems that include a plurality of consensus node computing devices. To obtain the auditing information that may be used for the auditing functions herein, the consensus nodes may be configured to add, to the blockchain, additional information such as information about the respective consensus node itself, e.g., a node identifier (ID) of the consensus node, a location of the consensus node, and an operator and/or owner of the consensus node. In addition, the consensus node may add node information about other consensus nodes in the system to one or more blocks of the blockchain. Furthermore, each consensus node may add information to the blockchain about a smart contract, e.g., information regarding a time at which the smart contract was executed, a time that a communication was received from a client or external system to cause execution of the smart contract, a time at which a consensus was obtained among the consensus nodes, identities of the nodes that executed the smart contract, and the like. Additionally, the consensus nodes may add client information to the blockchain, e.g., evidence that a digital signature of a client was received, and information about the smart contract itself. Further, the consensus nodes may add information related to the external system to the blockchain, such as adding external data that caused execution of the smart contract, an identifier, IP address, or the like of a computing device that sent the external data, and so forth.

[0029] Additionally, in some examples, the system may include a set of rules for providing an auditable system. For example, the rules may include that all consensus nodes are in agreement at the time of consensus. Alternatively, the rules may include, for each participant in the smart contract, that at least one consensus node that is associated with each participant in the smart contract is in agreement at the time of consensus. As still another alternative, the rules may include that the participants to the contract do not place restrictions on which nodes participate in the consensus as long as a consensus is reached. Furthermore, with respect to the smart contract itself, in some examples, the rules may include that all necessary information for the smart contract is stored in the blockchain. Alternatively, in other examples, the rules may include that only certain information for the smart is stored in the blockchain and other information is available from the external system. Additionally, in some cases, before a smart contract is executed, the consensus nodes executing the smart contract may determine that all the specified auditing information is present in the blockchain, or available to be included in the blockchain.

[0030] In some examples, an auditing computing device may communicate with one or more of the consensus nodes to obtain the blockchain for conducting an audit of the information included in the blockchain to ensure that the blockchain and the consensus nodes are in compliance with the requirements for auditing of the blockchains produced and the smart contracts executed by the system. For example, the auditing computing device may determine that the node information for all the nodes is included in the blockchain, that the digital signatures of the participants to the smart contract are listed in the blockchain, and that the external data, if any, is also included or described in the blockchain. If any of the information is not included in the blockchain, the auditor program may notify one or more of the participants to the contract. For example, the auditing computing device may send a notification to one or more participants indicating that specified auditing information is not available to be included and/or is not included in the blockchain. In response, the participant may suspend execution of the contract or take other action to prevent the contract from being executed until the required auditing information is included in the blockchain.

[0031] For discussion purposes, some example implementations are described in the environment of blockchains used in connection with execution of smart contracts. However, implementations herein are not limited to the particular examples provided, and may be extended to blockchains and similar data structures used for other applications, other types of computing systems, other system architectures, and so forth, as will be apparent to those of skill in the art in light of the disclosure herein.

[0032] FIG. 1 illustrates an example architecture of a system 100 according to some implementations. The system 100 includes a plurality of consensus node computing devices 102(1), 102(2), 102(3), 102(N), referred to hereinafter as consensus nodes 102, that are able to communicate with each other over one or more networks 104. Additionally, the consensus nodes 102 are able to communicate through the one or more networks 104 with one or more auditing computing devices 106, one or more client computing devices 108, and/or one or more external system computing devices 110.

[0033] In some examples herein, the system 100 is a scalable, decentralized peer-to-peer system able to generate and maintain at least one blockchain 112. Thus, the integrity of the data is based on a consensus mechanism rather than, e.g., a mere trust-based infrastructure. In examples herein, "consensus" may refer to a collective decision-making process or agreement as to what is true or false. For instance, the system 100 provides a distributed consensus network made up of the participating consensus nodes 102 in which the various different consensus nodes 102 participating in the system 100 may come to an agreement. Individual consensus nodes 102 may each contribute their own data to enable the consensus network as a whole to achieve a collective agreed-upon decision.

[0034] The system 100 is configured to record the chronological order of transactions or other information as successive blocks in the blockchain 112, which serves as a distributed database for the corresponding transactions. As a result, the transaction records are securely recorded and practically unalterable. All the consensus nodes 102 in the system 100 may execute the same node program 114 (including the same consensus program 116 and the same smart contract audit program 118) against the same transactions, and thus may validate (or invalidate) each transaction and may add auditing information to the blockchain 112 for each transaction. Valid transactions are written to a next block in the blockchain 112. The consensus nodes 102 may also add auditing information to the blockchain, as discussed additionally below, such as for each transaction, i.e., corresponding to each execution of a smart contract 120.

[0035] In some examples, the decentralized peer-to-peer nature of the system 100 herein may help prevent any single user or group of users from controlling the underlying infrastructure or undermining the integrity of the system 100. For instance, users 119 of the system 100 may all have equal status and may adhere to the same protocols. In some cases, the users 119 may be individuals, corporations, state actors, organizations, and so forth, or a combination of any these entities. In some examples herein, the system 100 may be private (i.e., not generally accessible to the public) and the consensus nodes 102 may typically be owned by, operated by, or otherwise associated with one or more of the users 119. For instance, in some cases, some of the consensus nodes 102 may be associated with a first participant to the smart contract 120, and some other ones of the consensus nodes 102 nodes may be associated with a second participant to the smart contract 102. Of course, in other cases, some or all of the consensus nodes 102 may be associated with a third party who is not associated with either the first participant or the second participant.

[0036] The consensus nodes 102 may each maintain a copy of the blockchain 120 and may participate in validating transactions conducted according to the smart contract 120. For instance, the system 100 may be used for executing one or more smart contracts 120 for a variety of different applications, such as for tracking supply chains for products, performing asset management regarding usage of enterprise assets, tracking crowdfunding projects, generating cryptocurrency, making the results of governance publically available, decentralizing file storage, managing internet of things (IoT) devices, protecting intellectual property, managing data, registering land titles, tracking stock trades, tracking banking transactions, and so forth.

[0037] The smart contracts 120 used in conjunction with the blockchain technology herein may be used to perform the above-discussed example applications or any of numerous other applications. As mentioned above, a smart contract may include an agreement that a function will be performed when a condition is met. Thus, the smart contract 120 may be executable code programmed to specify a condition to be met and a corresponding function to be performed, and the blockchain 112 may ensure that the condition is met and the corresponding function is automatically carried out.

[0038] As one example, with respect to the IoT, smart contracts may be used for automating the management of remote IoT systems, such as for automatically controlling the temperature in different zones in a building based on a plurality of detected conditions. As another example, smart contracts 120 and blockchains 112 may be used for enterprise asset management, e.g., for managing the usage and lifecycle of physical assets of an organization. As another example, smart contracts 120 and blockchains 112 may be used for executing and recording financial transactions, such as brokerage transactions, e.g., paying a derivative when a financial instrument meets a certain benchmark, buying/selling a stock when a certain price is reached, etc. As still another example, smart contracts 120 and blockchains 112 may be used for automatically redistributing electric power, such as in the case that a local solar microgrid produces excess energy, the smart contract 120 and blockchain 112 may be used to automatically redistribute the excess energy. Numerous other functions may be performed using blockchains 112 and smart contracts 120, with the examples discussed herein being only a few of the many possible applications.

[0039] When the smart contract 120 is first set up or otherwise established, the one or more participants (i.e., users 119) in the smart contract 120 may use a respective client program 122 on a respective client computing device 108 to sign the smart contract. For example, the client program 122 may be executed to configure the client computing device to send the smart contract 120 and digital signature 124 for the smart contract to the consensus nodes 102 that will execute the smart contract 120. Thus, as discussed below, the consensus nodes 102 may verify that the smart contract is signed before executing the smart contract. In some examples, the digital signature 124 may be included in the auditing information for a transaction executed using the smart contract 120.

[0040] In some examples, the execution of the smart contract 120 may be dependent on receipt of external data 126 from the one or more external system computing devices 110. For example, an external system program 128 may be configured to send the external data 126 to the consensus nodes 102. Depending on the nature of the smart contract 120, the external data 126 may be any corresponding type of data. For example, if the smart contract is for control of one or more thermostats in a building, the external data may be temperature data of zones corresponding to the thermostats. If the smart contract is for managing one or more securities, the external data may be current stock market information, or the like. Numerous other types of external data will be apparent to those of skill in the art in view of the examples discussed above and the disclosure herein.

[0041] Upon receipt of the external data, the consensus nodes 102 may determine to execute the smart contract. In some examples, the consensus nodes may execute the smart contract audit program 118 first to ensure that all required auditing information is present or available, such as base on one or more rules as discussed above. Each consensus node 102 may execute the smart contract 120 as a transaction. In some cases, the consensus nodes 102 may include a master node, as discussed additionally below, that sends and/or receives auditing information 130 to and from the other consensus nodes to enable the auditing information to be added to a blockchain maintained by each consensus node in the consensus system 100. The auditing information 130 may be added to the blockchain 112 as one or more additional blocks based on a consensus of the consensus nodes 102.

[0042] In addition, the auditing computing device(s) 106 may execute an auditing program 132. For example, the auditing program 132 may be executed periodically, at the request of a user 119, or based on some other trigger. The auditing program 132 may check the blockchain 112 to ensure that the consensus nodes 102 are configured to add specified auditing information to the blockchain 112, such as based on one or more rules 134, as discussed above. For instance, the auditing program 132 may access the blockchain 112 to determine that specified auditing information has been added to the blockchain 112. In some cases, such as if the system 100 is not properly configured according to the rules 134, the auditing program 132 may configure the auditing computing device 106 to send an audit result notification 136 to a user 119 at a client computing device 108, such as a participant in the smart contract and/or to an administrator 138 at the auditing computing device 106. In some examples, in response to receiving a negative audit result notification 136, execution of the smart contract 112 may be suspended by the user 119 and or the administrator 138, and the cause of the negative result may be determined and corrected. Further, while the auditing computing device 106 is illustrated as being a separate computing device in this example, in other examples, the auditing computing device may be combined with a consensus node 102 such that one or more of the consensus nodes 102 may also perform the functions of the auditing computing device.

[0043] In some examples, following each execution of the smart contract 120, a smart contract execution result 140 may be sent to at least one of the client computing device(s) 108 or the external system computing device(s) 110. For example, receipt of the smart contract execution result 140 may cause the client program 122 or the system program 128 to perform a function based on the execution result 140. For example, if the smart contract is for control of a thermostat, the execution result 140 may cause the system program 128 to increase or decrease the thermostat a specified amount. In some examples, the smart contract execution result may include the entire blockchain 122. In other examples, the execution result may include only an output value of the smart contract. Numerous other variations will be apparent to those of skill in the art having the benefit of the disclosure herein.

[0044] FIG. 2 illustrates an example of a consensus node 102 according to some implementations. In some cases, the consensus nodes 102 may include a plurality of physical servers or other types of computing devices that may be embodied in any number of ways. For instance, in the case of a server, the modules, programs, other functional components, and a portion of data storage may be implemented on the servers, e.g., at one or more server farms or data centers, cloud-hosted computing services, and so forth, although other computer architectures may additionally or alternatively be used. In the illustrated example, the consensus node 102 includes, or may have associated therewith, one or more processors 202, one or more communication interfaces 204, one or more computer-readable media 206, and one or more input/output (I/O) devices 208. For example, the computer-readable media may include a local storage 210 and a memory 212. Further, while a description of one consensus node 102 is provided, the other consensus nodes 102 may have the same or similar hardware and software configurations and components. Additionally, the auditing computing device(s) 106, the client computing device(s) 108, and the external system computing device(s) 108 may have similar hardware configurations with different programs, software, and other functional components thereon.

[0045] Each processor 202 may be a single processing unit or a number of processing units, and may include single or multiple computing units, or multiple processing cores. The processor(s) 202 can be implemented as one or more central processing units, microprocessors, microcomputers, microcontrollers, digital signal processors, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. For instance, the processor(s) 202 may be one or more hardware processors and/or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. The processor(s) 202 can be configured to fetch and execute computer-readable instructions stored in the computer-readable media 206, which program the processor(s) 202 to perform the functions described herein.

[0046] The computer-readable media 206 may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information such as computer-readable instructions, data structures, program code, or other data. For example, the computer-readable media 206 may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, optical storage, solid state storage, magnetic tape, magnetic disk storage, RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store the desired information and that can be accessed by a computing device. Depending on the configuration of the consensus node 102, the computer-readable media 206 may be a tangible non-transitory medium to the extent that, when mentioned, non-transitory computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and/or signals per se. In some cases, the computer-readable media 206 may be at the same location as the consensus node 102, while in other examples, the computer-readable media 206 may be separate or partially remote from the consensus node 102.

[0047] The computer-readable media 206 may be used to store any number of functional components that are executable by the processor(s) 202. In many implementations, these functional components comprise instructions, modules, or programs that are executable by the processor(s) 202 and that, when executed, specifically program the processor(s) 202 to perform the actions attributed herein to the consensus node 102. Functional components stored in the computer-readable media 206 may include the node program 114, which includes the consensus program 116 and the smart contract audit program 118. Additional functional components include the smart contract(s) 120 and an operating system (OS) 214, which may control and manage various functions of the consensus node 102. Each of the functional components may include one or more computer programs, applications, executable code, computer-readable instructions, or portions thereof. Further, while the consensus program 116 and the smart contract audit program 118 are shown as part of the node program 114 in this example, in other examples, these programs may be separate, may each include multiple separate programs, may be combined into a single program, and so forth. In some cases, the functional components may be stored in the local storage 210 of the computer-readable media 206, loaded into the memory 212 of the computer-readable media 206, and executed by the one or more processors 202. Numerous other software and/or hardware configurations will be apparent to those of skill in the art having the benefit of the disclosure herein.

[0048] In addition, the computer-readable media 206 may store data and data structures used for performing the functions and services described herein. For example, the computer-readable media 206 may store data, metadata, data structures, and/or other information used by the node program 114, the smart contract(s) 120, and/or the OS 214. For instance, some or all of the consensus nodes 102 may maintain the blockchain(s) 112, as well as node configuration information 216 and a participating node data structure 218. For example, the participating node data structure 218 may be generated and updated by the node program 114. The node configuration information 216 may include information about the particular node, and may be initially set up by an administrator and thereafter is loaded at boot time when initiating the consensus system. Each consensus node 102 may also include or maintain other functional components and data, which may include programs, drivers, etc., and other data used or generated by the functional components. Further, the consensus node 102 may include many other logical, programmatic, and physical components, of which those described above are merely examples that are related to the discussion herein.

[0049] The communication interface(s) 204 may include one or more interfaces and hardware components for enabling communication with various other devices, such as over the network(s) 104. Thus, the communication interfaces 204 may include, or may couple to, one or more ports that provide connection to the network(s) 104 for communication with other consensus nodes 102, the client device(s) 108, the auditing computing device(s) 106, and the external system computing device(s) 110. For example, the communication interface(s) 204 may enable communication through one or more of a LAN (local area network), WAN (wide area network), the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi) and wired networks (e.g., Fibre Channel, fiber optic, Ethernet), direct connections, as well as close- range communications such as BLUETOOTH®, and the like, as additionally enumerated elsewhere herein.

[0050] The one or more networks 104 may include any suitable communication technology, including a wide area network, such as the Internet; a local area network, such as an intranet; a wireless network, such as a cellular network; a local wireless network, such as Wi-Fi; short- range wireless communications, such as BLUETOOTH®; a wired network including Fibre Channel, fiber optics, Ethernet, or any other such network, a direct wired connection, or any combination thereof. Thus, the network(s) 104 may include wired and/or wireless communication technologies. The protocols used to communicate over such networks are well known in the art and will not be discussed in detail in this disclosure.

[0051] The I/O devices 208 may include a display, various user interface controls (e.g., mouse, keyboard, touch screen, etc.), audio speakers, connection ports, and so forth. Numerous other hardware and software configurations will be apparent to those of skill in the art having the benefit of the disclosure herein. Thus, the scope of the examples disclosed herein is not limited to a particular set of hardware, software, or a combination thereof.

[0052] FIG. 3 illustrates an example of blockchain generation 300 according to some implementations. An example of the blockchain 112 that is generated is illustrated on the left side of FIG. 3, showing blocks added, and a corresponding consensus sequence flow 302 is illustrated on the right side. In this example, four consensus nodes 102(1)-102(4) participate in the consensus system, with the first consensus node 102(1) being designated as a master node in this example. In addition, in this example, a client A device 108(1), a client B device 108(2), and the external system computing device 110 may contribute information, as discussed additionally below.

[0053] At 304, the consensus system is started and a genesis block 306 is generated to start generation of the blockchain 112. The genesis block 306 is the first block in the blockchain 112 and has a block height (i.e., sequential block number) of "0". All of the consensus nodes 102(1)- 102(4) share the genesis block 306. Of course, if the blockchain 112 has already been generated, then this step is not performed. Further, as part of the consensus system start up, the consensus nodes 102(2)- 102(4) may send information from their respective node configuration information data structures 216 to the master/first consensus node 102(1), and the master/first consensus node 102(1) may generate the participating nodes data structure 218 from the received information and from its own node configuration information data structure 216. The participating node data structure 218 is discussed additionally below with reference to FIG. 15.

[0054] Blocks 308 and 310 are performed for each consensus node. For instance, at 308, the master node forwards the information from the node configuration information data structure 216 for the first consensus node 102(1) to the other consensus nodes 102(2), 102(3) and 102(4). At 310, a consensus is reached among the consensus nodes 102(1)- 102(4).

[0055] In examples herein, consensus includes a process of agreeing on one result among the group of consensus nodes 102(1)-102(4). There are several techniques of determining agreement, such as Practical Byzantine Fault Tolerance (PBFT), Paxos Consensus Protocols, and the Raft Consensus Algorithm. For example, PBFT generally relies on receiving a sufficient number of responses that are identical for reaching agreement that a transaction is valid. Additionally, in a Paxos consensus system, a coordinator may suggest a value to all nodes and gathers the nodes responses as to whether the nodes agree with the value or not. If all nodes agree (or a sufficient number agree in some examples), the value is accepted and the coordinator contacts all nodes to let them know that the value is final.

[0056] As another example, similar to Paxos, the Raft algorithm achieves consensus via an elected leader. For instance, a server in a raft cluster is either a leader (i.e., the master), a follower (i.e., a node). The leader accepts a client's request and forwards the request to the followers. After the leader receives agreement from the majority of the followers the request is considered committed. Further, while several example techniques for reaching consensus are discussed herein, other possible techniques will be apparent to those of skill in the art having the benefit of the disclosure herein.

[0057] The master/first consensus node 102(1) forwards the information from the node configuration information data structure 216 of the first consensus node 102(1) to the second consensus node 102(2), the third consensus node 102(3), and the fourth consensus node 102(4). The master/first consensus node 102(1) receives confirmation from a majority of the consensus nodes and the request is considered committed. As a result, each consensus node may add the same block to its blockchain 112. As indicated at 312, the process is repeated for the node information for each of consensus nodes 102(1)- 102(4), resulting in four blocks being added to the blockchain 112, as indicated at 314, with each added block including the node information for a different one of the consensus nodes 102(1)- 102(4) participating in the consensus system.

[0058] After the fourth node information block 316 is added to the blockchain 112, the blockchain 112 has five blocks. The master/first consensus node 102(1) may check the participating nodes, as indicated at 318. The operation of checking the participating nodes at 318 may be performed to confirm which consensus nodes 102 participated in the consensus 310 to add the blocks 314 to the blockchain 112. This may include determining that all active consensus nodes in the consensus system have been identified and that all consensus nodes that have been identified are still active. The process of checking participating nodes is discussed additionally below with respect to FIGS. 14-16. Further, the determining the consensus 310 and the checking participating nodes 318 may be performed once for each block added. Thus, operations 310 and 318 are performed four times in this example, one time each for each of the four blocks 314 added to the blockchain 112. After checking the participating nodes, the blockchain 112 includes the node information of each of the consensus nodes 102(1)- 102(4) that are participating in the consensus system. [0059] As indicated at 320, one of the client computing devices 108(1) or 108(2) may send the smart contract to each of the consensus nodes 102(1)- 102(4). Alternatively, the client computing device 108(1) or 108(2) may send the smart contract to the master/first consensus node 102(1), and the master/first consensus node 102(1) may send the smart contract to the other consensus nodes 102(2)-102(4). At 322, a consensus is reached regarding the deployment of the smart contract, and each of the consensus nodes 102(1)- 102(4) adds a block 324 to its blockchain 112 to include the smart contract block 324 in the blockchain 112. As an alternative, such as in the case that the contract has already been added to the blockchain, one of the clients may send an update to the contract, e.g., updated code to modify the contract, or other data for the contract. In such a case, the procedure performed by the consensus system may be similar, and the contract code/data may be added to the blockchain 112 at each consensus node 102(1)- 102(4). At 326, the master/first consensus node 102(1) may again check the participating nodes in the consensus system.

[0060] At 328, the client A computing device 108(1) may send a digital signature of client A to the consensus system to indicate that execution of the smart contract is authorized. For example, the client A computing device 108(1) may send A's digital signature to each of the consensus nodes 102(1)- 102(4). Alternatively, the client A computing device 108(1) may send A's digital signature to the master/first consensus node 102(1), and the master/first consensus node 102(1) may send the digital signature to the other consensus nodes 102(2)- 102(4). At 330, a consensus is reached regarding A's digital signature, and each of the consensus nodes 102(1)- 102(4) adds a block 332 to its blockchain 112 to include the block 332 with A's digital signature in the blockchain 112. At 336, the master/first consensus node 102(1) may again check the participating nodes in the consensus system. Blocks 328, 330 and 336 are repeated to add B's digital signature to the blockchain 112.

[0061] At 338, the external system computing device 110 may send data to the consensus system. For example, depending on the nature of the smart contract, the external system 110 may send data that is relevant for execution of the smart contract. For example, the received data at 338 may be an input that is indicative of one of more preconditions of the smart contract which, when met, may cause execution of one or more functions to produce an output result. For example, the external system 110 may send the data to each of the consensus nodes 102(1)- 102(4), such as through operation of an application programming interface (API). Alternatively, the external system 110 may send the data to the master/first consensus node 102(1), and the master/first consensus node 102(1) may send the data to the other consensus nodes 102(2)- 102(4). At 340, a consensus is reached regarding the data, and each of the consensus nodes 102(1)-102(4) adds a block 342 to its blockchain 112 to include the data in the blockchain 112. At 344, the master/first consensus node 102(1) may again check the participating nodes in the consensus system.

[0062] At 348, the consensus system may receive a communication from the external system 110 or a client computing device 108 to invoke the smart contract. As one example, the communication may merely be the transmission of the data to the consensus system, and the master/first consensus node 102(1) may determine based on the data to invoke the smart contract. As another example, the communication may be an instruction to one or more of the consensus nodes to execute the smart contract. The communication may be to the master/first consensus node 102(1), or may be to multiple ones or all of the consensus nodes. If the communication is only to the master/first consensus node 102(1), the master/first consensus node 102(1) may send a communication to the other consensus nodes to obtain a consensus, or may otherwise gain a consensus, as indicated at 350, using any of the techniques discussed herein. At 354, the master/first consensus node 102(1) may again check the participating nodes in the consensus system.

[0063] At 356, 358, 360, and 362, the respective consensus nodes 102(1)402(4) may execute the smart contract based on the data received from the external system at 338. As one example, each of the consensus nodes 102 may execute the smart contract as an executed transaction to determine at least one output based on the data from the external system as at least one input. In some cases, each executed transaction result may be sent by individual consensus nodes 102(2)-102(4) to the master/first consensus node 102(1). The master/first consensus node 102(1) may then seek a consensus on each executed transaction result by sending the results to all of the consensus nodes. As indicated at 364, a consensus is may be reached, and the executed transaction information is added by each consensus node 102(1)-102(4) as block 366 to its own blockchain 112. At 370, the master/first consensus node 102(1) may again check the participating nodes in the consensus system to ensure that the participating consensus nodes that participated in the consensus 364 have not changed. The process of blocks 364 and 370 may be repeated for each transaction result from each consensus node 102(1)- 102(4), so that four blocks may be added to each consensus node's blockchain 112, as indicated at 368.

[0064] FIG. 4 illustrates an example blockchain portion 400 according to some implementations herein. In this example, the fifth, sixth, and seventh blocks of the blockchain 112 of FIG. 3 are illustrated, i.e., block 316 is the fifth block (have a block height of 4), block 324 is the sixth block (having a block height of 5), and block 332 is the seventh block (having a block height of 6) in the blockchain 112. Further, as discussed above with respect to FIG. 3, the blockchain 112 includes other blocks not shown in FIG. 4.

[0065] The primary identifier of a block in a blockchain is its block header hash 402. The block header hash 402 is a digital fingerprint, typically made by hashing a block header 404 twice using the SHA256 algorithm, although other techniques and/or algorithms may be used. The resulting block header hash 402 is a 32-byte hash value that uniquely represents the header of the corresponding block. The block header hash can be independently derived by any consensus node or user by simply hashing the block header 404 of the particular block.

[0066] Typically, the block header hash 402 is not included inside the block data structure when the block is stored as part of the blockchain. Rather, the block header hash 402 may be calculated by a node, e.g., as the block is generated on the node or received from another node. As one example, each node that maintains a blockchain may maintain a correspond metadata data structure (not shown in FIG. 4) that includes block header hashes 402 for all the blocks in the blockchain as well as other metadata for the blockchain.

[0067] In addition, the blocks in a blockchain may be identified by a block height 406, which is the sequential position of the block in the blockchain. For instance, the first block generated in a blockchain (the genesis block) has a block height of zero. As blocks are added to the blockchain, they are sequentially numbered using increasing positive integers. Each subsequent block added on to the previous block is one position higher in the blockchain. The block height 406 is also typically not a part of the block's data structure, i.e., is not stored within the block. Rather, each consensus node 102 or other computing device may dynamically identify each block's position (block height 406) in the blockchain 112. Alternatively, in some cases, the block height information may be stored by the consensus node as metadata. Thus, in the illustrated example, block 316 has a block height value = 4, block 324 has a block height value = 5, and block 332 has a block height value = 6.

[0068] In addition to the block header 404, each block includes a block body 408, which may include the data or other information being stored by the block. For instance in the illustrated example, block 316 stores participating node information 410, which includes the node configuration information data structure 216 for one of the consensus nodes 102 that is participating in the consensus system. Further, the block body 408 for the block 324 includes smart contract information 412, such as the smart contract code 414 (or at least a hash of the smart contract source code), and smart contract participant IDs 416, such as names, contact information, etc., of the smart contract participants, public keys, or other identifying information. In addition, the block body 408 for the block 332 includes a user signature 418, including a digital signature 420 (e.g., a public key and an encrypted hash, such as source code hash of the smart contract as discussed below) of each contract participant, and time 422 at which the digital signature was received. In some examples, a public key of the smart contract participants may be included as a digital signature 420 along with an encrypted hash value of at least a portion of the data being authenticated (e.g., the contract code itself, a message transmitting the contract code, or the like).

[0069] The block header 404 for each block includes a previous block header hash 428 of the previous block. Thus, block 324 includes a previous block header hash 428 that is the block header hash of block 316. Thus, the order of the blocks in the blockchain 112 may be determined by comparing the previous block header hash 428 in each block with the block header hash 402 calculated for each block.

[0070] In addition, the block header 404 may include a block body hash 430 and a timestamp 432 corresponding to a time at which the block was created, as well as other possible information not shown in this example. In some cases, the block body hash 430 may be calculated as a Merkle tree, such as in the case that the blockchain 112 is used to store a large number of transactions. However, in other cases, other techniques may be used for hashing the block body 408, such by using the SHA256 hash algorithm discussed above. In either case, because a hash 430 of the block body 408 is included in the block header 404, and because a block header hash 402 of the block header 404 is used to identify the block, it is not possible to alter the data in the block body 408 without changing the value of the block header hash 402, thereby changing the identifier of the block and providing evidence that the block contents have been altered.

[0071] FIG. 5 illustrates an example blockchain portion 500 according to some implementations herein. In this example, the ninth, tenth, and eleventh blocks of the blockchain 112 of FIG. 3 are illustrated, i.e., block 342 is the ninth block (have a block height of 8), block 352 is the tenth block (having a block height of 9), and block 366 is the eleventh block (having a block height of 10) in the blockchain 112. Further, as discussed above with respect to FIG. 3, the blockchain 112 includes other blocks not shown in FIG. 5.

[0072] In the illustrated example, the block body 408 of block 342 stores the data received from the external system as received data 502. In some examples, metadata 504 about the received data 502 may also be stored in the block body 408, such as the date and time 506 at which the data was received, the source 508 of the data and/or various other types of metadata. Further, the block body 408 for the block 352 includes information 510 related to the communication invoking the smart contract, such as a copy of the communication or instruction invoking the smart contract, the source of the communication, time the communication was received, identifying information about the data to be used, and so forth. In addition, the block body 408 for the block 366 includes information about the executed transaction 512 from execution of the smart contract. For example, the executed transaction 512 may include one or more inputs 514 and one or more outputs 516, the contents of which may depend upon the nature of the smart contract. For example, the input may include a contract participant' s public key, a contract participant' s signature with private key, and other information, such as the input data. Further, the output may include an output value and/or amount, and another contract participant's public key. In addition, the block body 408 may store information 518 about the smart contract execution, such as an identifier of the consensus node that executed the smart contract, a time at which the contract was executed, a log of the execution process, and so forth, as discussed additionally below with respect to FIG. 13.

[0073] FIGS. 6, 8, 10, 12, 14, and 16-19 are flow diagrams illustrating example processes according to some implementations. The processes are illustrated as collections of blocks in logical flow diagrams, which represent a sequence of operations, some or all of which may be implemented in hardware, software or a combination thereof. In the context of software, the blocks may represent computer-executable instructions stored on one or more computer- readable media that, when executed by one or more processors, program the processors to perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures and the like that perform particular functions or implement particular data types. The order in which the blocks are described should not be construed as a limitation. Any number of the described blocks can be combined in any order and/or in parallel to implement the process, or alternative processes, and not all of the blocks need be executed. For discussion purposes, the processes are described with reference to the environments, frameworks and systems described in the examples herein, although the processes may be implemented in a wide variety of other environments, frameworks and systems.

[0074] FIG. 6 is a flow diagram illustrating an example process 600 for adding participating node information to the blockchain according to some implementations. The process 600 may be performed by each consensus node 102, as discussed above with respect to blocks 308 and 310 of FIG. 3. For example, the smart contract audit program 118 may be executed on each consensus node to configure the one or more processors of the consensus node to perform the process 600.

[0075] At 602, the computing device may get consensus node information from a node configuration information data structure. For example, as discussed above, each consensus node may provide the information about itself obtained from its own node configuration information data structure to the master node, which may seek a consensus for adding the information to a block of the blockchain. In some example, the smart contract audit program 118 on each consensus node may configure the one or more processors of the consensus node to perform the process 600.

[0076] At 604, the computing device may determine whether a consensus has been reached. If so, the process goes to block 606; if not, the process goes to block 608.

[0077] At 606, the computing device may add the node information for the node to a new block in the blockchain. As mentioned above, the process 600 may be repeated for each participating node in the consensus system.

[0078] At 608, if a consensus has not been reached, the computing device may wait for a consensus and/or return to block 602.

[0079] FIG. 7 illustrates a consensus node configuration information data structure 216 according to some implementations. In this example, the data structure 216 includes a consensus node identifier (ID) 702, a consensus node location 704, a consensus node owner and/or operator 706, and a consensus node IP address 708. In some examples, each consensus node 102 may have its own node configuration information data structure 216 stored thereon. Furthermore, in some cases, the owner and/or operator 706 may be one of the participants in the smart contract such as one of the users 119 discussed above.

[0080] FIG. 8 is a flow diagram illustrating an example process 800 for adding digital signature and/or smart contract source code to the blockchain according to some implementations. In some examples, the process 800 may be executed by one or more of the consensus nodes 102 or other suitable computing devices. For example, the smart contract audit program 118 may be executed on a consensus node to configure the one or more processors of the consensus node to perform the process 800.

[0081] At 802, the computing device may receive a smart contract and/or digital signature to add to the blockchain. For example, a client may send the smart contract and a digital signature to the consensus nodes to enable execution of the smart contract by the consensus nodes.

[0082] At 804, the computing device may determine whether a consensus has been reached. If so, the process goes to block 806; if not, the process goes to block 808.

[0083] At 806, the computing device may add the source code of the smart contract and/or the digital signature to a new block of the blockchain. In some examples, the smart contract and the digital signature may be added to separate blocks of the blockchain, while in other examples, the smart contract and the digital signature may be added to the same block in the blockchain. Other client information and/or metadata may also be added to the blockchain as discussed above, such as the time when the smart contract or digital signature was received, the source from which the smart contract or digital signature was received, and so forth.

[0084] At 808, if a consensus has not been reached, the computing device may wait for a consensus.

[0085] FIG. 9 illustrates a signature and smart contract source code data structure 900 according to some implementations. In some cases, some or all of the information in the data structure 900 may be added to a block of the blockchain by the smart contract audit program 118. In this example, the data structure 900 includes a source code hash 902, which is a hash value obtained by applying a hash algorithm to the original source code of the smart contract. In addition, the data structure 900 may include a smart contract ID 904, which may be a unique or otherwise individually distinguishable identifier of the deployed smart contract. Additionally, the data structure 900 may include a public key of a contract participant, which may serve as identification information of the contract participant, and which may further serve as a digital signature for the contract participant in some examples.

[0086] As one example, the source code hash 902 may be encrypted using a private key of the contract participant. The public key 906 may be used by the consensus node to decrypt the source code hash. The decrypted source code hash may be compared with an independently determine source code hash of the source code to determine whether they match. Since the encrypted source code hash is encrypted using a private key of the contract participant, the digital signature provides evidence that the encrypted source code hash was encrypted by the contract participant. Further, various other techniques may be used to provide a digital signature for the smart contract, as will be apparent to those of skill in the art having the benefit of the disclosure herein. In some examples, all of the participants to a smart contract may provide the information in the data structure 900. In some examples, the source code hash 902 provided by one participant may be compared with the source code hash 902 provided by the other participant to ensure that both participants signed the same smart contract.

[0087] FIG. 10 is a flow diagram illustrating an example process 1000 for adding external data received from an external system to the blockchain according to some implementations. In some examples, the process 1000 may be executed by one or more of the consensus nodes 102 or other suitable computing devices. For example, the smart contract audit program 118 may be executed on a consensus node to configure the one or more processors of the consensus node to perform the process 1000. [0088] At 1002, the computing device may receive the external data from the external system computing device. For example, the system program on the external system computing device may send the external data to one or more of the consensus nodes in the consensus system.

[0089] At 1004, the computing device may determine whether there is a consensus. If so, the process proceeds to block 1006; if not, the process proceeds to block 1008.

[0090] At 1006, the computing device may add the external data and metadata for the external data to the blockchain. For example, the metadata for the external data may include the time at which the actual data was received, the source from which the external data was received, and/or other information related to the external data.

[0091] At 1008, if a consensus is not reached, the computing device may wait for a consensus.

[0092] FIG. 11 illustrates an external data information data structure 1100 according to some implementations. In this example, the data structure 1100 includes an identifier (ID) 1102 of an external system computing device that sent the external data to the consensus system. In addition, the data structure 1100 may include a time 1104 at which the external data was received from the external system, a data source 1106, and the data itself 1108. For example, the data source may be one or more originators of the data such as a thermometer or other sensor, a stock price index system, a bank transaction source, and so forth. As mentioned above, the information from the data structure 1100 may be included in the body of a blockchain block to enable auditing of the smart contract execution at a later time.

[0093] FIG. 12 is a flow diagram illustrating an example process 1200 for adding transaction information and contract execution information to the blockchain according to some implementations. In some examples, the process 1200 may be executed by one or more of the consensus nodes 102 or other suitable computing devices. For example, the smart contract audit program 118 may be executed on a consensus node to configure the one or more processors of the consensus node to add the smart contract execution information to the blockchain, while the consensus program 116 may configure the one or more processors to add the transaction information to the blockchain.

[0094] At 1202, the computing device may execute the smart contract based on the external data received from the external system. For instance, in some examples, the receipt of the external data may cause invocation of the smart contract. In other examples, an instruction or other communication may invoke the execution of the smart contract. [0095] At 1204, following execution of the smart contract, the computing device may receive, from consensus nodes, transaction information corresponding to the executed smart contract and contract execution information. For example, the transaction information may include the input and the result of execution of the smart contract. The contract execution information may include additional information about the execution of the smart contract, such as the time at which the contract was executed, the consensus nodes that executed the contract, and so forth. For instance, as mentioned above, each consensus node may provide the transaction information and the smart contract execution information to the master node and the master node may seek a consensus for each contract execution results from the consensus nodes.

[0096] At 1206, the computing device may determine whether there is a consensus. If so, the process proceeds to block 1208; if not, the process proceeds to block 1210.

[0097] At 1208, the computing device may add the transaction information and the corresponding smart contract execution information to a block in the blockchain. For example, the transaction information and the corresponding smart contract execution information may be included in the same block in the blockchain, or alternatively, may be included in separate blocks in the blockchain. The process 1200 may be repeated for each result produced by each consensus node.

[0098] At 1210, if a consensus has not been reached, the computing device may wait for a consensus.

[0099] FIG. 13 illustrates an example smart contract execution information data structure 1300 according to some implementations. In this example, the data structure 1300 includes a consensus node identifier (ID) 1302, a time of execution 1304, and an execution log 1306. In some examples, each consensus node 102 may generate this data structure 1300 when executing the smart contract. The information in the data structure 1300 may be added by the smart contract audit program 118 to a block that also includes the corresponding transaction information, as discussed above with reference to FIG. 5, or the information may be included in a block in the blockchain separate from a block that includes the transaction input and output information.

[00100] FIG. 14 is a flow diagram illustrating an example process 1400 for checking participating nodes according to some implementations. In some examples, the process 1400 may be executed by one or more of the consensus nodes 102 or other suitable computing devices. For example, the smart contract audit program 118 may be executed on the master consensus node to configure the one or more processors of the master consensus node to perform the process 1400. The process 1400 is a first example of a process for checking participating nodes. The process 1600 described below is a second example of a process for checking participating nodes that includes a self-auditing management feature to halt the consensus system when one or more audited conditions are not satisfied.

[00101] At 1402, the computing device acting as the master node may send a query to check for the participating consensus nodes in the consensus system. For example, it may occur that a consensus node has failed, a new consensus node has been added, or the like. The master node may refer to the participating node data structure 218 to determine which consensus nodes are currently included in the consensus system. Details of the participating node data structure 218 are discussed below with respect to FIG. 15.

[00102] At 1404, the computing device may determine whether all consensus nodes in the participating node data structure returned a response to the query. If so, the process may proceed to block 1406; if not, the process may proceed to block 1408.

[00103] At 1406, if the computing device determines that the consensus nodes participating in the consensus system is unchanged, then the process may end and the node may proceed to processing a next operation. For example, if the condition of the consensus nodes in the consensus system is unchanged, then the information about the consensus nodes included in the blockchain does not need to be modified.

[00104] At 1408, if not all of the consensus nodes return a positive response to the query, and/or if a new consensus node returns a response, the computing device may update the information for the actively participating consensus nodes in the participating node data structure.

[00105] At 1410, the computing device may update the actively participating node information in the blockchain. For example, as discussed with respect to FIG. 3 at blocks 308 and 310, the node information for the nodes participating in the consensus system may be added to the blockchain. Additionally, if a node is no longer participating in the consensus system, then information that the node is not participating in the consensus may be added to the blockchain.

[00106] At 1412, the computing device may form a revised consensus group. For example, based on the participating node data structure 218, the computing device may determine a new consensus group of consensus nodes. The computing device may then proceed to process a next operation.

[00107] FIG. 15 illustrates an example of the participating node data structure 218 according to some implementations. In this example, the data structure 218 includes a consensus node identifier (ID) 1502, an indicator 1504 as to whether or not the consensus node is active, a consensus node location 1506, a consensus node owner and/or operator 1508, and a consensus node IP address 1510. With respect to the indicator 1504, a first value may indicate that the corresponding node is active in the consensus system, while a second value may indicate that the corresponding consensus node is not currently active in the consensus system. As mentioned above, in some cases, the owner and/or operator 1506 may be one of the participants in the smart contract, such as one of the users 119 discussed above.

[00108] FIG. 16 is a flow diagram illustrating an example process 1600 for checking participating nodes according to some implementations. In some examples, the process 1600 may be executed by one or more of the consensus nodes 102 or other suitable computing devices. For example, the smart contract audit program 118 may be executed on the master consensus node to configure the one or more processors of the master consensus node to perform the process 1600. The process 1600 described below is the second example of a process for checking participating nodes, and includes a self-auditing management feature to halt the consensus system when one or more audited conditions are not satisfied.

[00109] At 1602, the computing device acting as the master node may send a query to check for the participating consensus nodes in the consensus system. For example, it may occur that a consensus node has failed, a new consensus node has been added, or the like. The master node may refer to the participating node data structure 218 to determine which consensus nodes are currently included in the consensus system.

[00110] At 1604, the computing device may determine whether all consensus nodes in the participating node data structure returned a response to the query. If so, the process may proceed to block 1606; if not, the process may proceed to block 1608.

[00111] At 1606, if the computing device determines that the consensus nodes participating in the consensus system is unchanged, then the process may end and the node may proceed to processing a next operation. For example, if the condition of the consensus nodes in the consensus system is unchanged, then the information about the consensus nodes included in the blockchain does not need to be modified.

[00112] At 1608, if not all of the consensus nodes return a positive response to the query, and/or if a new consensus node returns a response, the computing device may determine whether the responding consensus nodes satisfy the rules of the smart contract. If so, the process proceeds to block 1612; if not, the process proceeds to block 1610.

[00113] At 1610, if the responding consensus nodes do not satisfy the smart contract (e.g., do not satisfy one or more rules of the smart contract), the computing device may stop the consensus system and send a notification. For example, the smart contract may specify that an equal number of consensus nodes associated with a first participant to the contract and associated with a second participant to the contract are included in the consensus system. If the number of nodes from each participant becomes uneven, the master node may stop the consensus system and send a notification to the client computing devices to inform the contract participants that the number of participating consensus nodes is not in accordance with the contract. Other rules, such as those discussed herein, or other rules not discussed herein, may be similarly enforced. Several examples of other rules include: 1) all nodes have to agree at the time of consensus; 2) at least one consensus node associated with each participant to the contract has to agree at the time of consensus; and/or the participants to the contract do not care which ones of the participating nodes make a consensus. If the consensus system is halted, the blockchain and all current transaction information may be retained to enable an audit.

[00114] At 1612, if not all of the consensus nodes return a positive response to the query, and/or if a new consensus node returns a response, but the rules of the contract are still met, the computing device may update the information for the actively participating consensus nodes in the participating node data structure 218.

[00115] At 1614, the computing device may update the actively participating node information in the blockchain. For example, as discussed with respect to FIG. 3 at blocks 308 and 310, the node information for the nodes participating in the consensus system may be added to the blockchain. Additionally, if a node is no longer participating in the consensus system, then information that the node is not participating in the consensus may be added to the blockchain.

[00116] At 1616, the computing device may form a revised consensus group. For example, based on the participating node data structure, the computing device may determine a new consensus group of consensus nodes. The computing device may then proceed to process a next operation.

[00117] FIG. 17 is a flow diagram illustrating an example process 1700 according to some implementations. In some examples, the process 1700 may be executed by the consensus nodes 102 actively participating in the consensus system. For example, the consensus program 116 may be executed on each consensus node to configure the one or more processors of the consensus nodes to perform the process 1700.

[00118] At 1702, the computing device may receive an indication that a master node failure has occurred.

[00119] At 1704, the computing device may participate with other consensus nodes in the consensus system in electing a new master node. For example, all consensus nodes in the consensus systems may have a pre-assigned weight, and highest weighted node remaining in the system may be elected as the master. As another example, all of the consensus nodes may have a term and the node with the shortest term remaining in the consensus system may be elected as the master.

[00120] At 1706, the computing device that is elected as master node may perform the process for adding information of the actively participating consensus nodes to the blockchain. For example, the new master node may perform the process discussed above with respect to blocks 308 and 310 of FIG. 3.

[00121] FIG. 18 is a flow diagram illustrating an example process 1800 according to some implementations. In some examples, the process 1800 may be executed by the auditing computing device 106 by execution of the auditing program 132. As mentioned above, in some examples the execution of the auditing computing auditing program 132 may be based on a periodic execution requirement, may be in response to a request from one of the contract participants, or the like.

[00122] At 1802, the computing device may determine a list of information for the audit, such as auditing information that is expected to be included in the blockchain for satisfying an auditing certification requirement. For example, the auditing program may obtain the smart contract, and may determine the auditing information and the applicable rules 134 for the execution of the smart contract in the consensus system.

[00123] At 1804, the computing device may receive a copy of the current blockchain from one or more of the consensus nodes. In some examples, the computing device may receive copies of the current blockchain from multiple consensus nodes to compare the multiple blockchains to one another to ensure that all blockchains are consistent.

[00124] At 1806, the computing device may determine whether the list of auditing information for the audit is met by the information in the blockchain. For example, the auditing program may determine whether the consensus nodes participating in the consensus system are properly identified in the blockchain, whether the smart contract is included in the blockchain along with digital signatures of the participating clients, and whether the external data and information about invocation of the smart contract are included in the blockchain. The auditing program may also determine whether information about the execution of the smart contract and the transaction information are included in the blockchain. If the information included in the blockchain meets the list of auditing information for the audit, the process proceeds to block 1808; if not the process proceeds to block 1810.

[00125] At 1808, if the information in the blockchain meets the list of auditing information for the audit, the computing device may send a notification that the requirement for the audit certification is met. For example, the computing device may send the notification to the client computing devices to inform the participants to the smart contract that one or more requirements for the audit certification have been met.

[00126] At 1810, if the information in the blockchain does not meet the list of auditing information for the audit, the computing device may send a notification that the requirement for the audit certification is not met. For example, the computing device may send the notification to the client computing devices to inform the participants to the smart contract that one or more of the requirements for the audit certification have not been met, and may further provide information as to one of more deficiencies of the information included in the blockchain. In some examples, in response, the participants to the smart contract may halt execution of the consensus system until the system can be revised to store the proper auditing information in the blockchain.

[00127] FIG. 19 is a flow diagram illustrating an example process 1900 according to some implementations. In some examples, the process 1900 may be executed by one or more of the consensus nodes 102 or other suitable computing devices. For example, the smart contract audit program 118 may be executed on a consensus node to configure the one or more processors of the consensus node to perform at least a portion of the process 1900.

[00128] At 1902, the computing device may receive an indication and consensus to execute the smart contract. For instance, the consensus system may have received external data or other instruction to cause execution of the smart contract and, further, there may be a consensus that the smart contract is to be executed by the consensus nodes.

[00129] At 1904, prior to executing the smart contract, the computing device may determine whether the blockchain includes the specified node information of the participating nodes. If so, the process proceeds to block 1906; if not, the process proceeds to block 1914.

[00130] At 1906, if the requirements of block 1904 are met, the computing device may determine whether the smart contract information and the digital signature information are included in the blockchain. If so, the process proceeds to block 1908; if not, the process proceeds to block 1914.

[00131] At 1908, if the requirements of block 1906 are met, the computing device may determine whether the external data information and/or smart contract invocation information is included in the blockchain. If so, the process proceeds to block 1910; if not, the process proceeds to block 1914.

[00132] At 1910, if the requirements of block 1908 are met, the computing device may proceed with execution of the smart contract. [00133] At 1912, the computing device may add transaction information and smart contract execution information to the blockchain. In some cases, blocks 1910 and 1912 may be executed according the process 1200 of FIG. 12 and/or blocks 356-364 and 370 of FIG. 3.

[00134] At 1914, if the response to any of blocks 1904, 1906, or 1908 is "no", the computing device may send a notification to the client computing devices to inform the contract participants that the blockchain does not include the expected auditing information. In some examples, in response, the client device may suspend execution of the consensus system until the cause of the discrepancy is addressed.

[00135] The example processes described herein are only examples of processes provided for discussion purposes. Numerous other variations will be apparent to those of skill in the art in light of the disclosure herein. Further, while the disclosure herein sets forth several examples of suitable frameworks, architectures and environments for executing the processes, the implementations herein are not limited to the particular examples shown and discussed.

Furthermore, this disclosure provides various example implementations, as described and as illustrated in the drawings. However, this disclosure is not limited to the implementations described and illustrated herein, but can extend to other implementations, as would be known or as would become known to those skilled in the art.

[00136] Various instructions, processes, and techniques described herein may be considered in the general context of computer-executable instructions, such as program modules stored on computer-readable media, and executed by the processor(s) herein. Generally, program modules include routines, programs, objects, components, data structures, executable code, etc., for performing particular tasks or implementing particular abstract data types. These program modules, and the like, may be executed as native code or may be downloaded and executed, such as in a virtual machine or other just-in- time compilation execution environment. Typically, the functionality of the program modules may be combined or distributed as desired in various implementations. An implementation of these modules and techniques may be stored on computer storage media or transmitted across some form of communication media. Thus, the index arrangement herein may be implemented on physical hardware, may be used in virtual implementations, may be used as part of overall deduplication system on either physical or virtual machine, and/or may be as a component for other deduplication implementations (e.g., SAN) or in some non-deduplication environments, such as large scale memory indexing. [00137] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.