Self-auditing blockchain

Abstract

A processor may collect process information associated with peer nodes of a self-auditing blockchain. The processor may generate an imprint from the process information. The processor may compare the imprint from the peer node with an imprint consensus to detect errors. The errors may indicate that the peer node has been compromised.

Description

Technical Field

[0001] The present disclosure generally relates to the field of blockchain storage, and more particularly to identifying whether peer nodes in a blockchain have been affected by an attack.

[0002] Blockchain networks are often built on the principle of trust. To maintain trust, the data maintained by a blockchain network must be accurate. Therefore, it is of utmost importance to identify potential errors caused by malicious activities related to the blockchain network while ensuring that trust is maintained.

Summary of the Invention

[0003] Embodiments of the present disclosure include a method, a system, and a computer program product for self-auditing a blockchain network. A processor can collect process information from peer nodes in a self-auditing blockchain. The processor can generate an imprint from the process information of the peer nodes. The processor can compare the imprint of the peer nodes with a consensus imprint to detect one or more errors. These one or more errors may indicate that the peer nodes have been put at risk.

[0004] The above summary is not intended to describe every illustrated embodiment or every implementation of the present disclosure.

Brief Description of the Drawings

[0005] The drawings included in the present disclosure are incorporated herein and form a part hereof. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The drawings are only examples of specific embodiments and do not limit the present disclosure.

[0006]

Figure 1A

[0007]

Figure 1B

[0008]

Figure 2A

[0009]

Figure 2B

[0010]

Figure 2C

[0011]

Figure 3

[0012]

Figure 4A

[0013]

Figure 4B

[0014]

Figure 5

[0015] The embodiments described in this specification are subject to various modifications and alternative forms, and specific details thereof are shown by way of example in the drawings and will be described in detail. However, it should be understood that the specific embodiments described are not to be construed in a limiting sense. Rather, the present invention is directed to all modifications, equivalents, and alternatives falling within the scope of the present disclosure.

Mode for Carrying Out the Invention

[0016] Aspects of the present disclosure generally relate to blockchain network security, and more particularly to configuring peer nodes within a blockchain network to perform a self-audit function while maintaining the trust of peers. Private blockchain networks are capable of sharing highly confidential information. This confidential information often needs to be protected at any cost, but due to the nature of some blockchain networks (e.g., peer-to-peer based blockchain networks), this confidential information can be exposed to malicious attackers (e.g., hackers). Due to the nature of the blockchain, generally, peer nodes cannot control security monitoring. As the blockchain becomes more well-known, hackers are becoming more active in finding ways to endanger existing applications rather than using conventional hacking methods (e.g., introducing viruses into blockchain servers). Such hacking activities are very difficult to detect and may remain undetected for a long time.

[0017] The embodiments described herein address blockchain concerns related to identifying whether applications (e.g., hacking) expose piano nodes to risk and where such hacking is originating. Attempts have been made to identify hacking within blockchain piano nodes, but such attempts often require access to shared confidential information maintained by the blockchain and erode trust within the blockchain network.

[0018] It will be readily understood that the simple components widely described herein and shown in the drawings can be arranged and designed within a wide variety of different configurations. Accordingly, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system, represented in the accompanying drawings, is not intended to limit the scope of the claimed application but merely represents selected embodiments.

[0019] The simple features, structures, or characteristics described throughout this specification can be combined or removed in any suitable manner in one or more embodiments. For example, throughout this specification, when phrases such as "exemplary embodiments", "some embodiments", or other similar phrases are used, it means that the specific features, structures, or characteristics described in relation to those embodiments can be included in at least one embodiment. Thus, throughout this specification, when phrases such as "exemplary embodiments", "in some embodiments", "in other embodiments", or other similar phrases appear, it does not necessarily mean that they all refer to the same group of embodiments, and the features, structures, or characteristics described can be combined or removed in any suitable manner in one or more embodiments. Further, in the drawings, if there is a connection between elements, it allows for one-way and / or two-way communication whether the illustrated connection is a one-way arrow or a two-way arrow. Also, if there is a device shown within the drawings, it can be a different device. For example, if a mobile device sending information is shown, it is also possible to use a wired device to send that information.

[0020] Furthermore, although the term "message" may be used in the description of embodiments, this application can be applied to many types of networks and data. Additionally, in exemplary embodiments, although specific types of connections, messages, and signaling may be shown, this application is not limited to specific types of connections, messages, and signaling.

[0021] A method, system, and computer program product are described herein for utilizing a self-auditing blockchain to determine whether a peer node has been hacked and where in an application (e.g., process information) a hacking or error has occurred while maintaining trust within a blockchain network. It is possible to keep confidential and secret information highly secure, and no party (e.g., organization or peer node) is responsible for determining whether other peer nodes have been affected by hacking, so trust within the blockchain network can be maintained.

[0022] In some embodiments, the method, system, and / or computer program product utilize a decentralized database (such as a blockchain) that is a distributed storage system including a plurality of nodes that communicate with each other. The decentralized database includes an append-only immutable data structure similar to a distributed ledger that can maintain records among parties that do not trust each other. These untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify the database records unless a consensus is reached among the distributed peers. For example, the peers may execute a consensus protocol to validate blockchain storage transactions, group these storage transactions into multiple blocks, and construct a hash chain across these blocks. In this process, the ledger is formed by ordering the storage transactions as necessary to maintain integrity.

[0023] In various embodiments, it is possible to use permissioned and / or permissionless blockchains. Public or permissionless blockchains allow anyone to participate without a specific identity (e.g., while maintaining anonymity). Public blockchains include native cryptocurrencies and can use consensus based on various protocols such as proof of work. On the other hand, permissioned blockchain databases provide secure interaction among groups of entities that share a common purpose, such as companies that exchange funds, goods, and (private) information, but do not fully trust each other.

[0024] Furthermore, in some embodiments, the method, system, and / or computer program product can be adapted to a decentralized storage scheme and utilize a blockchain that operates any programmable logic referred to as a "smart contract" or "chain code". In some cases, there may be dedicated chain codes for management functions and parameters, which are referred to as system chain codes. The method, system, and / or computer program product can further utilize smart contracts, which are trusted distributed applications that leverage the tamper-proof characteristics of the blockchain database and the underlying agreement among nodes, and these are referred to as endorsements or endorsement policies. Blockchain transactions related to this application can be "endorsed" before being committed to the blockchain, and unendorsed transactions are ignored.

[0025] With an endorsement policy, the chain code can specify the endorsers of a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to a peer specified in the endorsement policy, the transaction is executed by that peer, thereby generating a purely theoretical transaction result. If enough peers that satisfy the endorsement policy produce the same execution result, that transaction is considered to be endorsed. After endorsement, the transaction enters an ordering phase, where a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into multiple blocks. Conventionally used consensus protocols include the First In First Out (FIFO) protocol and the leader-follower protocol (e.g., the crash fault tolerance protocol).

[0026] In some embodiments, the method, system, and / or computer program product are available for nodes, which are communication entities of a blockchain system. A "node" can perform a logical function in that multiple different types of nodes can be executed on the same physical server. Nodes are grouped within a trust domain and associated with logical entities that control them in various ways. Nodes can include various types, such as client nodes or submitting client nodes that submit transaction calls to an endorser (e.g., a peer) and broadcast a transaction proposal to an ordering service (e.g., an ordering node).

[0027] Other types of nodes receive the transactions submitted by the client that have been ordered (e.g., from an ordering service), cause those transactions to be committed, and are peer nodes that can maintain the state and a copy of the ledger of blockchain transactions. A peer may or may not have the role of an end - service. An ordering service node or an orderer is a node that executes an ordering service, which receives a stream of endorsed transactions from a client and emits a stream of ordered transactions. The ordering service node executes a communication service for all peer nodes, commits / approves transactions, and implements a delivery guarantee such as broadcasting to each of the peer nodes in the system when modifying the world state of the blockchain. This delivery guarantee is another name for the first blockchain transaction that usually includes control and setup information.

[0028] In some embodiments, the method, system, and / or computer program product can utilize a ledger that is a sequential listing of all tamper - resistant records of the state transitions of the blockchain. State transitions can result from chain code calls (e.g., transactions) submitted by participating parties (such as client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participating party (such as a peer node) can maintain a copy of the ledger. As a result of a transaction, a set of asset key - value pairs can be committed to the ledger as one or more operations such as creation, update, and deletion. The ledger includes a blockchain (also referred to as a chain) that is used to store immutable records in blocks in sequence. The ledger also includes a state database that maintains the current state of the blockchain.

[0029] In some embodiments, the methods, systems, and / or computer program products described herein are capable of utilizing a chain that is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions, where N is equal to or greater than 1. The block header includes the hash of the transactions of the block, as well as the hash of the header of the previous block. In this way, all the transactions in the ledger can be ordered and cryptographically linked in sequence. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents all the transactions on the chain that occurred prior to it, thereby enabling all peer nodes to be consistent and in a trusted state. The chain can be stored on a peer node file system (e.g., local, attached storage, cloud, etc.), thereby efficiently supporting the append-only nature of the blockchain workload.

[0030] The current state of the immutable ledger represents the latest value for all keys included in the chain transaction log. Since the current state represents the latest key values recognized by the channel, it may also be referred to as the world state. Chain code calls execute transactions against the current state data of the ledger. To make these chain code interactions efficient, the latest values of the keys can be stored in a state database. The state database may simply be an indexed view within the chain's transaction log, and thus it can be regenerated from the chain at any time. The state database can be automatically restored (or generated as needed) upon startup of the peer node and prior to transactions being accepted.

[0031] Blockchain differs from traditional databases in that it is a decentralized, immutable, and secure storage rather than a central storage, where nodes can share changes to records in the storage. Some characteristics unique to blockchain and useful for implementing blockchain include, but are not limited to, immutable ledger, smart contract, security, privacy, decentralization, consensus, endorsement, and accessibility. These will be further described in this specification. According to various aspects, the system described in this specification is implemented by immutable accountability, security, privacy, recognized decentralization, availability of smart contracts, endorsement, and accessibility that are unique and specific to blockchain.

[0032] Specifically, blockchain ledger data is immutable and provides an efficient way to identify inconsistencies within the blockchain network. Also, using encryption within the blockchain provides security and builds trust. Smart contracts manage the state of assets and complete the life cycle. An exemplary blockchain is permissioned and decentralized. Thus, each end user may have their own copy of the ledger for access. Multiple organizations (and peers) can come on board the blockchain network. Key organizations can act as endorsing peers to validate the execution results, read sets, and write sets of smart contracts. In other words, the unique characteristics of blockchain result in an efficient implementation of processing private transactions within the blockchain network.

[0033] One advantage of the exemplary embodiments is to improve the functionality of a computing system by implementing a way to process private transactions within a blockchain network. Through the blockchain system described herein, a computing system (or a processor within the computing system) can execute the functionality for a self-auditing blockchain network received from one or more client applications that utilize the blockchain network by providing access to capabilities such as distributed ledgers, peers, encryption techniques, MSP, event handling, etc. Also, the blockchain enables the creation of a business network and allows any user or organization to be on-boarded for participation. Thus, the blockchain is not merely a database. The blockchain has the ability to create a network of users and on-boarded / off-boarded organizations for the purpose of collaborating and executing service processes in the form of smart contracts (which may be related to one or more assets).

[0034] The exemplary embodiments provide a number of advantages over conventional databases. For example, through the blockchain, these embodiments provide immutable accountability, security, privacy, permitted decentralization, smart contract availability, endorsement, and accessibility that are unique and specific to the blockchain.

[0035] Conventional databases do not lead all parties to the network, do not provide trusted collaboration, and do not provide efficient storage of digital assets, so they cannot be used to implement the exemplary embodiments. Conventional databases do not provide tamper-proof storage and do not preserve the digital assets stored. As a result, the proposed embodiments described herein that utilize a blockchain network cannot be implemented in a conventional database.

[0036] If a conventional database is used to implement the exemplary embodiments, these exemplary embodiments should suffer from unwanted drawbacks such as search capabilities, lack of security, and slowdown of transactions. Therefore, the exemplary embodiments provide specific solutions to the problems in the technology / field of auditing (e.g., self-auditing) of blockchain networks.

[0037] Referring now to FIG. 1A, a blockchain architecture 100 according to an embodiment of the present disclosure is shown. In some embodiments, the blockchain architecture 100 may include a particular blockchain element, for example, a group of blockchain nodes 102. The blockchain nodes 102 may include one or more blockchain nodes, for example, peers 104 to 110 (these four nodes are shown only as examples). These nodes participate in several activities, such as the addition and validation process (consensus) of blockchain transactions. One or more of the peers 104 to 110 can endorse and / or recommend transactions based on an endorsement policy and can provide an ordering service for all the blockchain nodes 102 within the blockchain architecture 100. The blockchain nodes can initiate blockchain authentication and attempt to write to the blockchain immutable ledger stored in the blockchain layer 116, and a copy of that ledger can also be stored on the underlying physical infrastructure 114. This blockchain configuration may include one or more applications 124, which access the stored program / application code 120 (e.g., chain code, smart contract, etc.), are linked to an application programming interface (API) 122 to execute it, and the program / application code can be created according to the customized configuration required by the participants, maintain its own state, control its own assets, and receive external information. This can be deployed as a transaction and installed on all the blockchain nodes 104 to 110 through appending to the distributed ledger.

[0038] The blockchain-based or platform 112 may include various layers of blockchain data, services (such as cryptographic credit services, virtual execution environments, etc.), and the underlying physical computer infrastructure that can be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 116 may present an interface that processes program code and provides access to the virtual execution environment necessary to engage the physical infrastructure 114. The cryptographic credit service 118 may verify transactions such as asset exchange transactions and may be used to keep information private.

[0039] The blockchain architecture 100 of FIG. 1A can process and execute program / application code 120 via one or more interfaces presented by the blockchain platform 112 and services provided by the blockchain platform. The code 120 can control blockchain assets. For example, the code 120 can store and transfer data and can be executed by peers 104 to 110 in the form of smart contracts and associated chain codes, and these smart contracts and associated chain codes are accompanied by conditions or other code elements for which they are to be executed. As a non-limiting example, smart contracts can be created to execute resource transfers, resource generation, etc. It is also possible to use the smart contracts themselves to specify authentication and access requirements and rules related to the use of ledgers. For example, group transaction information 126 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 116. The result 128 can include a plurality of linked shared documents (e.g., each linked shared document records the issuance of a smart contract for group transaction information 126, etc.). The physical infrastructure 114 can be utilized to retrieve any of the data or information described herein.

[0040] Smart contracts can be created with high-level applications and programming languages and then written into the blocks within a blockchain. A smart contract can include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that is executable in response to conditions related to the smart contract being met. By executing a smart contract, trusted modifications can be initiated to the state of the digital blockchain ledger. Modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated across the distributed network of blockchain peers via one or more consensus protocols.

[0041] Smart contracts can write data to the blockchain in the format of key-value pairs. Further, smart contract code can read values stored within the blockchain and use them in application operations. Smart contract code can write the outputs of various logical operations to the blockchain. This code can be used to create temporary data structures within a virtual machine or other computing platform. The data written to the blockchain can be made public and / or encrypted and maintained as private. Temporary data used / generated by a smart contract is held in memory by the provided execution environment and then deleted once the data required by the blockchain is identified.

[0042] The chain code can include the code interpretation of the smart contract, along with additional features. As described herein, the chain code can be program code deployed on a computing network, in which computing network, the chain code is executed and validated simultaneously by chain validators during a consensus process. The chain code receives a hash and extracts from the blockchain a hash related to a data template created by using a pre-stored feature extractor. When the hash of the hash identifier and the hash created from the stored identifier template data match, the chain code sends an authentication key to the requested service. The chain code can write to blockchain data related to cryptographic details (e.g., thereby approving a group of transactions, identifying a conflict between one or more of the transactions within the group of transactions, etc.).

[0043] Figure 1B shows an example of a conventional blockchain transaction flow 150 between nodes of a blockchain according to an exemplary embodiment. Referring to Figure 1B, the transaction flow may include a transaction proposal 191 sent by an application client node 160 to one or more endorser nodes 181 (e.g., in some embodiments, the transaction proposal 191 may be a transaction verification request and / or a conflict verification request). The endorser 181 can verify the client signature and execute a chaincode function to initiate a transaction. The output may include a chaincode result, a set of key / value versions (read set) read within the chaincode, and a set of key / values written to the chaincode (write set). If permitted, a proposal response 192 is returned to the client 160 along with an endorsement signature. The client 160 collects the endorsements as a transaction payload 193 and broadcasts it to the ordering service node 184. The ordering service node 184 then delivers the ordered transactions as blocks to all peers 181 through 183 on the channel. Before entrusting to the blockchain, each peer 181 through 183 may validate the transaction. For example, the peer can check the endorsement policy to ensure that the result is signed by the specified peer with the correct assignment and that the signature is authenticated against the transaction payload 193.

[0044] Referring again to FIG. 1B, client node 160 starts transaction 191 by constructing and sending a request to endorser peer node 181. Client 160 may include an application that utilizes a supported software development kit (SDK), which generates transaction proposal 191 using the available APIs. This proposal is a request to trigger chaincode functions to enable reading data from and / or writing data to the ledger (e.g., writing a new key-value pair for an asset). The SDK packages transaction proposal 191 into a properly configured format (e.g., a protocol buffer over a remote procedure call (RPC)), incorporates the client's cryptographic credentials, and can create a signature specific to transaction proposal 191.

[0045] In response, endorser peer node 181 can verify that (a) transaction proposal 191 is properly formed, (b) no transaction has been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (client 160 in this example) is properly authorized to perform the proposed action on that channel. Endorser peer node 181 may receive the input of transaction proposal 191 as an argument to the triggered chaincode function. The chaincode is then executed against the current state database to create a transaction result including a response value, a read set, and a write set. However, the ledger is not updated at this point. In some embodiments, a set of values is returned as proposal response 192 to client 160's SDK along with the endorser peer node 181's signature, and the client parses the payload consumed by the application.

[0046] In response, the application of client 160 inspects / verifies the endorser signature and compares the proposal responses to determine whether the proposal responses are the same. If the chaincode only performs ledger queries, the application inspects the query response and generally does not submit the transaction to the ordering service node 184. If the client application intends to submit a transaction to the ordering service node 184 to update the ledger, the application determines whether the specified endorsement policy is satisfied (e.g., whether the transaction verification requirements have been accepted) before submission. Here, the client may include only one of the multiple parties to the transaction. In this case, each client may have its own endorser node, and each endorser node needs to endorse the transaction. In this architecture, even if the application chooses not to inspect the response or transfers an unendorsed transaction, the endorsement policy is enforced by the peers and supported in the commit validation phase.

[0047] After the inspection is successful, at step 193, client 160 collects the endorsements as a transaction and broadcasts the transaction proposal 191 and response within the transaction message to the ordering node 184. The transaction may include a read / write set, the endorser signature, and the channel ID. The ordering node 184 does not need to inspect the entire content of the transaction to perform its operation. Instead, the ordering node 184 simply receives the transactions from all channels in the network, orders them per channel, and can also create a block of transactions per channel.

[0048] The blocks of transactions are delivered from the ordering node 184 to all peer nodes 181 - 183 on the channel. The transactions 194 within the block are validated to ensure that any endorsement policy is met, and that once the read set is generated by the execution of the transaction, there are no changes to the ledger state for the read set variables. The transactions within the block are tagged as either valid or invalid. Further, in step 195, each peer node 181 - 183 appends the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. An event is issued to notify the client application that the transaction (call) has been immutably appended to the chain, and whether the transaction has been validated or invalidated. The blockchain ledger is updated with the validated transactions and their associated values, and the invalidated transactions are committed, but depending on the invalidated transaction values, the blockchain ledger may not be updated.

[0049] Referring to FIG. 2A, an exemplary self-auditing blockchain network 200 is shown for auditing and identifying potential malicious activities (e.g., worms and viruses) within a piano node 202 according to an embodiment of the present disclosure. Malicious activities are generally referred to herein as errors and / or hacking hereinafter, and can take various malware forms, including, but not limited to, viruses, worms, spyware, or any combination thereof. The embodiments disclosed herein often refer to the self-auditing blockchain network 200 as a permissioned blockchain consortium (e.g., a Hyperledger Fabric blockchain network), but the self-auditing blockchain network 200 can also be configured to function within any type of blockchain consortium (e.g., a permissionless blockchain) having piano nodes or nodes that provide similar role functions. The self-auditing blockchain network 200 enables various peers within the blockchain consortium to determine whether malware / errors (e.g., hacking and / or unauthorized / malicious activities) are affecting one or more of the piano nodes without jeopardizing the trust within the blockchain consortium. The embodiments discussed herein enable methods related to the real-time detection of malicious activities and the location identification of where malicious activities are affecting the integrity of the blockchain consortium.

[0050] In an embodiment, the self-auditing blockchain network 200 can include piano nodes 202 and imprint policies 203. The piano nodes 202 can be configured to include an imprint collection module 204, an auditing module 206, and a hacking location identification module 208. In some embodiments (e.g., those shown in FIG. 2A), the auditing module 206 and the hacking location identification module 208 are configured separately from the imprint collection module 204, while in other embodiments, the auditing module 206 and the hacking location identification module 208 are sub-components of the imprint collection module 204. Various embodiments for each module (e.g., the imprint collection module 204, the auditing module 206, and the hacking location identification module 208) will be discussed herein. Generally, each participating piano node (e.g., piano node 202) includes: i) an imprint collection module 204, which is configured to generate an imprint (e.g., imprint 220) specific to the piano node in which this particular module is housed and collect imprints generated by other participating piano nodes; ii) an auditing module 206, which is configured to identify a consensus from among the collected imprints and compare each imprint with the consensus imprint; and iii) a hacking location identification module 208, which is configured to receive from the auditing module 206 an imprint that does not match the consensus imprint and identify where in the process information of the piano node the hacking occurred.

[0051] The embodiments disclosed herein often refer to a single piano node (e.g., piano node 202), but the self-auditing blockchain network 200 can include any number of similarly configured piano nodes. These embodiments generally illustrate the self-auditing blockchain network 200 at the piano node level and should not be considered a blockchain consortium having only one piano node. In an embodiment, the self-auditing blockchain network 200 and the embodiments disclosed herein are applicable to each piano node (e.g., piano node 202) within a blockchain consortium. In these embodiments, each piano node is similarly configured (e.g., as disclosed with reference to piano node 202) to perform an effective self-audit that is consistent across the entire blockchain. As mentioned herein, the self-auditing blockchain network 200 can be configured within a permissioned blockchain consortium. A permissioned blockchain can be configured to have multiple organizations, and each of these organizations can have one or more piano nodes within its respective data center.

[0052] In some embodiments, the self-auditing blockchain network 200 can include an imprint policy 203. In embodiments having an imprint policy 203, the imprint policy 203 can include the standards and conditions that each peer node 202 constituting the self-auditing blockchain network 200 must comply with and enforce when executing a self-auditing function (e.g., imprint generation, etc.). Although the imprint policy 203 will be discussed in more detail herein, the imprint policy 203 provides the conditions that each peer node 202 must follow to ensure that the results of the self-auditing function are reproducible and are applied consistently among all of the peer nodes 202 within the blockchain network. For example, the imprint policy 203 provides the conditions and rules (e.g., what data / information constitutes the process information 212 discussed with reference to FIG. 2B) that each peer node 202 must follow to generate an imprint, and can specify how a consensus imprint is determined and how the peer node 202 and / or the self-auditing blockchain network 200 will react when one or more errors (e.g., hacking) are identified within the imprint of the peer node 202.

[0053] In embodiments, the peer node 202 can include an imprint collection module 204. The imprint collection module 204 can be located within the operating system kernel of the peer node 202. In these embodiments where the imprint collection module 204 is implemented within the operating system kernel of the peer node 202, the imprint collection module 204 is protected and is ensured to be prevented from being accessed by application programs or other less critical components of the operating system of the peer node 202 that may be affected by malware / errors (e.g., hacking). In embodiments, the imprint collection module 204 can collect process information from the peer node 202.

[0054] In some of these embodiments, the process information can be stored in one or more process address spaces within the address space of the operating system kernel, while in other embodiments, it is possible to store the process information in one or more process address spaces outside the operating system kernel of the piano node 202. In embodiments where the process information is stored in one or more process address spaces outside the operating system kernel, the imprint collection module can be configured to collect the process information from the relevant process address spaces. The piano node 202 can also use any type of computer security technology, such as address space layout randomization (ASLR), to reduce or eliminate the vulnerability to memory corruption. Using such computer security technologies ensures that an attacker cannot conceal or hide their malicious activities while the self-auditing blockchain network 200 is performing the auditing function.

[0055] An attacker refers to a party that hacks into the self-auditing blockchain network 200 and perpetuates malware. The attacker may be related to parties outside the blockchain consortium, but such parties or activities may originate from malicious peer nodes within the self-auditing blockchain network 200. Attackers often attempt to disrupt various aspects of the blockchain by keeping their malicious activities secret. Generally, the longer the malicious activities that occur remain secret, the higher the likelihood of the attacker achieving their desired goals. In an embodiment, through ASLR or other similar computer security techniques, the address space related to the process information 212 (e.g., including executable code, stack, HEAP, and / or libraries) can be randomly arranged, making it more difficult for the attacker to predict a specific address space. For example, if an attacker, such as a malicious peer node 202 from among a group of peer nodes 202, can predict the address space of the process information 212 related to the peer node 202, the attacker (e.g., the malicious peer node 202) can identify which process information 212 represents a process that has not been hacked (e.g., process information not affected by errors / hacking or malicious activities), and create a fake imprint that mimics an imprint (e.g., 220) that does not indicate that hacking has occurred. Therefore, by making the address space more difficult to predict, the self-auditing blockchain network 200 can execute the self-auditing function and ensure that each participating peer node 202 trusts the results related to self-auditing. In an embodiment, the imprint collection module 204 can grasp the ASLR configuration by connecting to the runtime loader related to the peer node 202.

[0056] In an embodiment, the piano node 202 can use the collected process information and the imprint collection module 204 to generate an imprint (e.g., the imprint 220 shown in FIG. 2B) representing different process information (e.g., the process information 212 shown in FIG. 2B) collected by the imprint collection module 204. The imprint can represent the process information collected during the validity period of the piano node 202, or can represent the process information collected during a specific period. In an embodiment, the imprint policy 203 can tell how often the process information is collected by each piano node 202. For example, the imprint policy 203 can provide a condition that the process information is collected after a specific duration or after the piano node 202 has collected a specific number of process information entries (e.g., an imprint is generated after 10 or 100 different process information entries). The imprint can be generated in various ways, and the generation of the imprint in some exemplary embodiments is discussed with reference to FIG. 2B.

[0057] Figure 2B provides an exemplary embodiment showing how the imprint collection module 204 can generate an imprint (e.g., imprint 220) according to an embodiment of the present disclosure. As shown in Figure 2B, the imprint collection module 204 can collect process information 212 from the process address space 210. The process address space 210 can represent an address space and process information (e.g., process information 212) collected from inside the operating system kernel of the peer node 202, outside the operating system kernel of the peer node 202, or any combination thereof. The process information 212 can generally refer to information and data generated as a result of the peer node 202 executing the block chain function of the routine and can include any type of data / information (e.g., conditioned by the imprint policy 203). The process information 212 can include any type of data / information, but this data / information is often of a type that is affected when hacking (e.g., an error) occurs. In an embodiment, the imprint 220 can be generated using any type of process information 212 as contemplated herein or can be generated from a smaller number of types of process information 212 than all of the available types of process information 212. For example, in some embodiments, the process information 212 can include types of process information such as code, libraries, transaction metadata, and data stored in other memory storage areas (e.g., HEAP) within the operating system of the peer node 202, while in other embodiments, the imprint collection module 204 can generate the imprint 220 using only one type of process information 212, such as a specific type of code (e.g., an executable code segment). In some embodiments, the code can refer to and may include both executable code segments (e.g., code 0, code 1, code 2) and data code segments, while in other embodiments, the collected process information 212 can be, or may include, an executable code segment or a data code segment.In an embodiment, when generating an imprint, conditions regarding which data / information should be regarded as process information 212 and which data / information should be ignored can be provided to the piano node 202 by the imprint policy 203. Without this consistency, each piano node 202 within the self-auditing blockchain network 200 may rely on its own definition of the process information 212 independently of other peers and incorporate different data / information into the imprint 220. Continuing with this example, if each piano node uses different data / information to generate an imprint, each piano node may create a different imprint. If each imprint generated by the piano node 202 is different, it is not possible to identify a consensus among the generated imprints and the self-auditing function cannot be executed.

[0058] In an embodiment, the imprint collection module 204 can generate the imprint 220 using one or more hashing iterations. As is well known to those skilled in the art, hashing generally refers to applying a hash function to a character string (e.g., the process information 212) and converting that character string into a shorter value or a fixed-length value representing the original string. Using the example shown in Figure 2B, if code 0 and code 1 within the process address space 210 contain exactly the same character string and both code 0 and code 1 are hashed with the same hash function, each resulting hash process information 214 is identical. However, in this example where they are identical, if code 0 and code 1 differ from each other by only one or more characters, the two resulting hash process information 214 should be different. The imprint collection module 204 can be configured to use any available hash function or combination of hash functions.

[0059] In FIG. 2B, the imprint collection module 204 can be configured to generate a Merkle tree 216 and a Merkle root 218 by hashing the pages of the process information 214 in chunks. The imprint 220 obtained as a result of what is generated by the imprint collection module 204 can vary in complexity, but the imprint 220 should represent all of the process information 212 being collected. Thus, in some embodiments, the imprint 220 can simply be the Merkle root 218. In other embodiments, the imprint 220 can include a list of the hashed pages including the generated Merkle tree 216, or a subset of the generated Merkle tree 216 ordered in a particular sequence. The imprint 220 shown in FIG. 2B shows an imprint ordered in a particular sequence. For example, as shown in FIG. 2B, the imprint 220 can include a combination of components ordered in a particular sequence. The imprint 220 may begin with the Merkle root 218, followed by the individual page chunks for each generation that have been hashed.

[0060] In some embodiments, each imprint 220 may end with one or more metadata. This metadata may include data / information related to imprint generation and / or process information 212. In these embodiments, this metadata may include information on how the first imprint was generated. For example, this metadata may include a timestamp on when the imprint 220 was generated, a counter to distinguish different imprints generated by the same piano node, how different pages of the process information 212 are arranged, and information related to how many different process information 212 were initially collected by the piano node 202 before the imprint 220 was generated. In some embodiments, this metadata may be used by the auditing module 206 and the hacking location identification module 208 to identify and find where hacking / errors occurred. In embodiments, conditions related to which hash function should be used to generate the imprint 220, which hashed components (e.g., Merkle root 218 and / or Merkle tree 216) within the imprint 220 should be used, how each component should be ordered if there are more than one hashed components, or any combination of these, may be provided to each piano node 202 by the imprint policy 203.

[0061] In an embodiment, the imprint collection module 204 and the auditing module 206 can be configured to function jointly to perform an auditing function. In an embodiment, the imprint collection module 204 can ensure that the generated imprint 220 is secure against attackers by using various encryption modes. For example, the imprint collection module 204 can use a random symmetric key to encrypt the imprint 220. By encrypting the imprint 220, the imprint collection module 204 can suppress or prevent an attacker from monitoring the imprint of a healthy piano node (e.g., a non-hacked piano node) and from creating an imprint that is a replica of the imprint of a healthy piano node to conceal the attacker's activities. In an embodiment, the imprint collection module 204 can be configured to generate a first message. In these embodiments, the imprint collection module 204 can configure the first message to include the encrypted imprint and a signature identifying which piano node 202 among all the piano nodes in the blockchain network created the imprint (e.g., imprint 220). Once generated, the imprint collection module 204 can commit the first message to the blockchain.

[0062] As discussed herein, embodiments are often viewed from the perspective of a piano node (e.g., piano node 202), but each piano node within a blockchain network (e.g., self-auditing blockchain network 200) performs similar actions. Thus, each piano node causes the blockchain to commit a first message that includes at least an encrypted imprint representing its respective process information (e.g., process information 212) and a signature that is unique to the piano node and can be used for identification. By causing each piano node 202 to commit its respective first message to the blockchain, the self-auditing blockchain network 200 can maintain a log of imprints that is resistant to attackers and available for later use.

[0063] After each first message from each piano node within the self-auditing blockchain network 200 has been committed to the blockchain, the imprint collection module 204 of each piano node 202 creates a second message. In an embodiment, the second message can include the signature of a particular piano node and the encryption key (e.g., a random symmetric key) used to encrypt the imprint (e.g., imprint 220) within the first message. In an embodiment, each piano node 202 then causes this second message to be committed to the blockchain. In this configuration where the first message is committed to the blockchain first and cannot be changed, there is a record of the imprint that is only decryptable after the second message of each piano node has been committed. Such a configuration ensures that a piano node and / or an attacker cannot change its original imprint to hide its own hacking / error or malicious activity from the self-auditing blockchain network 200.

[0064] In an embodiment, each piano node 202 is configured to have an auditing module 206, but in order to perform an auditing function, it is often necessary to access only one piano node. In an embodiment, the auditing module 206 may be configured to recover an encrypted imprint from a first message related to all piano nodes (e.g., piano node 202) within the self-auditing blockchain network 200. In some embodiments, the auditing module 206 may be configured to verify that each imprint was generated by a trusted piano node. In these embodiments, the auditing module 206 can verify the signature that identifies the peer. In some embodiments, if the auditing module 206 is not verified, the verification request is resubmitted, but in other embodiments, the auditing module 206 may be configured to issue an alert to other elements of the self-auditing blockchain network 200 that a piano node has participated in the blockchain network without permission. When each piano node within the self-auditing blockchain network 200 is verified, the auditing module 206 may be configured to collect each random symmetric key used to encrypt each imprint from the imprint collection module 204 of each piano node, or to collect each random symmetric key from a second message. In an embodiment, when the auditing module 206 uses the collected keys to decrypt each imprint (e.g., from a set of first messages), the auditing module 206 can analyze the generated imprints of each piano node 202. In these embodiments, the auditing module 206 can analyze each imprint and associated metadata to determine whether a consensus imprint exists within the set of imprints. A consensus imprint can be identified when the population of imprints has exactly the same imprint. In an embodiment, the imprint policy 203 may further include what is eligible to be a consensus imprint. For example, the imprint policy 203 may identify a simple majority or an absolute majority of identical imprints generated from various peers as the consensus imprint.In an embodiment, when the auditing module 206 determines that one or more imprints do not match the consensus imprint, those imprints are submitted to the hacking location identification module 208.

[0065] Referring to FIG. 2C, an example of the hacking location identification module 208 according to an embodiment of the present disclosure is shown. In an embodiment, the hacking location identification module 208 may be configured to compare the consensus imprint 222 with the identified non-matching imprint 226. In these embodiments, the hacking location identification module 208 can extend both the consensus imprint 222 and the non-matching imprint 226 and reconstruct the respective Merkle trees associated with each imprint (e.g., the consensus Merkle tree 224 and the non-matching Merkle tree 228). In an embodiment, the hacking location identification module 208 can compare the consensus Merkle tree 224 and the non-matching Merkle tree 228 to identify which hash (e.g., a leaf / branch of the Merkle tree) is different. If the hash in the non-matching Merkle tree 228 is the same as the hash in the consensus Merkle tree 224, there is no indication that hacking / error has occurred. However, if the hash of the non-matching Merkle tree 228 is different from the corresponding hash of the consensus Merkle tree 224, this indicates that there is a difference in which process was executed on that particular piano node. In an embodiment, when a hacking / error is identified and located, a report can be generated that identifies the hacking / error and where the hacking occurred. In some embodiments, this report can be sent only to the piano node identified as having hacking, while in other embodiments, the report can also be sent to one or more other piano nodes within the self-auditing blockchain network (e.g., a report identifying multiple hackings / errors in the process information of a single piano node).

[0066] Referring now to FIG. 3, a flowchart illustrates an exemplary method 300 for self-auditing a blockchain network according to an embodiment of the present disclosure. In some embodiments, method 300 may be performed by one or more peer nodes within a blockchain network (e.g., blockchain network 200).

[0067] In some embodiments, method 300 begins at operation 302, where a processor collects process information from peer nodes within the blockchain network. Method 300 proceeds to operation 304, where the processor forms an imprint from the process information of the peer nodes. Method 300 proceeds to operation 306, where the processor compares the imprint of the peer nodes to a consensus imprint to detect one or more hackings / errors. Method 300 proceeds to operation 308, where the processor determines whether a peer node has been hacked.

[0068] In some embodiments, as illustrated, method 300 may end after operation 308.

[0069] In some embodiments discussed below, for simplicity, one or more operations of method 300 are not shown along with additional operations / steps performed by the processor. Thus, in some embodiments, the processor may use the imprint to identify where in the process information an error of an at-risk peer has occurred. In some embodiments, generating an imprint from process information may include the processor hashing the process information from the peer nodes to generate a Merkle tree. The processor can generate the Merkle tree. The processor may configure the Merkle tree to form an imprint of the peer nodes.

[0070] In some embodiments, the processor can encrypt the imprint to form an encrypted imprint. The processor can generate a first message. The first message can include the encrypted imprint and a signature. The signature can identify the peer node associated with the imprint. The processor can cause the first message to be committed to the blockchain.

[0071] In some embodiments, the processor can generate a second message. The second message can include one or more keys for decrypting the encrypted imprint to reform the imprint. The processor can cause the second message to be committed to the blockchain.

[0072] In some embodiments, the processor can verify the signature of the peer node associated with the first message. The processor can collect one or more keys from the second message. The processor can use the one or more keys from the second message to decrypt the encrypted imprint of the first message.

[0073] In some embodiments, detecting an error by comparing the imprint with an imprint consensus can be included in the process of determining the imprint consensus. Determining the imprint consensus can include identifying a group of peer nodes having the same imprint.

[0074] In some embodiments, the processor can analyze the imprint consensus. The processor can identify process information associated with an imprint that does not exactly match the imprint consensus. The processor can generate a report. The report can include where an error is located within the process information.

[0075] This disclosure includes a detailed description of cloud computing, but it should be understood that the implementations of the teachings described herein are not limited to cloud computing environments. Rather, embodiments of the present disclosure can be implemented in conjunction with any other type of computing environment, whether currently known or developed in the future.

[0076] Cloud computing is a service delivery model that enables convenient on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0077] The following are the characteristics.

[0078] On-demand self-service: A cloud consumer can unilaterally provision computing capabilities, such as server time and network storage, automatically as needed, without the need for human interaction with a service provider.

[0079] Broad network access: Capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs (registered trademarks)).

[0080] Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, and dynamic allocation and reallocation of various physical and virtual resources are performed according to demand. Consumers generally have partial independence in that they cannot control or have knowledge of the exact portions of the resources provided, although it may be possible to specify portions at a higher level of abstraction (e.g., country, state, or data center).

[0081] Rapid scalability: The ability can be provisioned quickly, elastically, and in some cases automatically, and can scale out immediately, or be released quickly and scale in immediately. For consumers, in many cases, it feels like there is an unlimited amount of capacity available for provisioning, and any amount can be purchased at any time.

[0082] Measured service: The cloud system automatically controls and optimizes resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage is monitored, controlled, and reported, thus providing transparency to both the provider and the consumer of the services utilized.

[0083] The following is the service model.

[0084] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on cloud infrastructure. The applications are accessible from various client devices through a client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, which includes the network, servers, operating systems, storage, or even individual application capabilities. However, limited user-specific application configuration settings may be an exception.

[0085] Platform as a Service (PaaS): The ability provided to consumers is to deploy the applications created or acquired by consumers on cloud infrastructure, which are created using the programming languages and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, which includes the network, servers, operating systems, or storage, but can control the deployed applications and, in some cases, the application hosting environment configuration.

[0086] Infrastructure as a Service (IaaS): The capabilities provided to consumers are to provision processing, storage, networking, and other basic computing resources, where the consumer can deploy and run any software that may include an operating system and applications. The consumer does not manage or control the underlying cloud infrastructure but can control the operating system, storage, deployed applications, and, in some cases, selectively control certain networking components (e.g., host firewalls) in a limited manner.

[0087] The deployment models are as follows.

[0088] Private cloud: The cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0089] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with common concerns (e.g., mission, security requirements, policies, and regulatory compliance considerations). This can be managed by an organization or a third party and can exist on-premises or off-premises.

[0090] Public cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0091] Hybrid cloud: A cloud infrastructure that combines two or more clouds (private, community, or public), which remain distinct entities but are linked by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load distribution across clouds).

[0092] Cloud computing environments are service-oriented, emphasizing statelessness, loose coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0093] FIG. 4A shows a cloud computing environment 410. As shown, the cloud computing environment 410 includes one or more cloud computing nodes 400 that can communicate with local computing devices (e.g., a personal digital assistant (PDA (registered trademark)) or cellular telephone 400A, a desktop computer 400B, a laptop computer 400C, and / or an automotive computer system 400N, etc.) used by cloud consumers. The nodes 400 can communicate with each other. They can be physically or virtually grouped (not shown) within one or more networks such as a private cloud, community cloud, public cloud, or hybrid cloud as described above, or combinations thereof.

[0094] As a result, the cloud computing environment 410 can provide infrastructure, platform, and / or software as services, and for those services, cloud consumers do not need to maintain resources on local computing devices. The types of computing devices 400A to 400N shown in FIG. 4A are only for illustration purposes, and it should be understood that the computing nodes 400 and the cloud computing environment 410 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0095] FIG. 4B shows a set of functional abstraction layers provided by the cloud computing environment 410 (FIG. 4A). It should be understood in advance that the components, layers, and functions shown in FIG. 4B are only for illustration purposes, and the embodiments of the present disclosure are not limited thereto. As shown below, the following layers and corresponding functions are provided.

[0096] The hardware and software layer 415 includes hardware components and software components. Examples of hardware components include mainframe 402; RISC (Reduced Instruction Set Computer) architecture-based server 404; server 406; blade server 408; storage device 411; and network and networking components 412. In some embodiments, the software components include network application server software 414 and database software 416.

[0097] The virtualization layer 420 provides an abstraction layer. From the abstraction layer, examples of the following virtual entities can be provided: virtual server 422; virtual storage 424; virtual network 426 including a virtual private network; virtual applications and operating systems 428; and virtual clients 430.

[0098] In one example, the management layer 440 may provide the functions described below. In resource provisioning 442, dynamic procurement of computing resources and other resources used to execute tasks within a cloud computing environment is performed. In measurement and pricing 444, cost tracking is performed when resources are utilized within a cloud computing environment, and invoicing or billing is performed for the consumption of these resources. In one example, these resources may include application software licenses. In security, authentication for cloud consumers and tasks, as well as protection for data and other resources, is performed. In user portal 446, consumers and system administrators are given access to the cloud computing environment. In service level management 448, allocation and management of cloud computing resources are performed so that required service levels are met. In service level agreement (SLA) formulation and fulfillment 450, pre-provisioning and procurement of cloud computing resources that are expected to be required in the future according to the SLA are performed.

[0099] In the workload layer 460, multiple function examples are provided. The cloud computing environment can be utilized for those functions. Examples of workloads and functions that can be provided from this layer include mapping and navigation 462; software development and life cycle management 464; virtual classroom education provision 466; data analysis processing 468; transaction processing 470; and self-audit 472.

[0100] FIG. 5 shows a high-level block diagram of an exemplary computer system 501 according to an embodiment of the present disclosure, which can be used to implement one or more of the methods, tools, and modules, and any related functions described herein (e.g., using one or more processor circuits or computer processors of a computer). In some embodiments, the main components of computer system 501 may include one or more CPUs 502, a memory subsystem 504, a terminal interface 512, a storage interface 516, an I / O (input / output) device interface 514, and a network interface 518, all of which can be coupled directly or indirectly for communication between components via a memory bus 503, an I / O bus 508, and an I / O bus interface unit 510.

[0101] Computer system 501 may include one or more general-purpose programmable central processing units (CPUs) 502A, 502B, 502C, and 502D (collectively referred to herein as CPU 502). In some embodiments, computer system 501 may include multiple processors specific to relatively large systems, while in other embodiments, computer system 501 may be a single CPU system. Each CPU 502 can execute instructions stored in memory subsystem 504 and may include one or more levels of on-board cache.

[0102] System memory 504 may include a computer system readable medium in the form of volatile memory such as random access memory (RAM) 522 or cache memory 524. Computer system 501 may further include other removable / non-removable volatile / non-volatile computer system storage media. By way of example only, a storage system 526 for reading from and writing to a non-volatile magnetic medium such as a “hard drive” may be provided. Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), or an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media may be provided. Further, memory 504 may include flash memory, such as a flash memory stick drive or flash drive. The memory device may be connected to memory bus 503 by one or more data media interfaces. Memory 504 may comprise at least one program product including a set of program modules (e.g., at least one program module) configured to execute the functions of various embodiments.

[0103] One or more programs / utilities 528, each having at least one set of program modules 530, may be stored in memory 504. Programs / utilities 528 may include a hypervisor (also referred to as a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of these operating systems, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. Programs 528 and / or program modules 530 generally execute the functions or methodologies of various embodiments.

[0104] Memory bus 503 is shown in FIG. 5 as a single bus structure that provides a direct communication path among CPU 502, memory subsystem 504, and I / O bus interface 510. However, in some embodiments, memory bus 503 may include a plurality of different buses or communication paths, which may be arranged in any of various forms such as point-to-point links in a hierarchical star or mesh configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Further, although I / O bus interface 510 and I / O bus 508 are each shown as a single unit, in some embodiments, computer system 501 may include a plurality of I / O bus interface units 510, a plurality of I / O buses 508, or both. Further, a plurality of I / O interface units are shown that separate I / O bus 508 from various communication paths extending to various I / O devices, but in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0105] In some embodiments, computer system 501 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 501 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or network router, or any other suitable type of electronic device.

[0106] Note that FIG. 5 is intended to show the representative main components of an exemplary computer system 501. However, in some embodiments, individual components may have a higher or lower complexity than those represented in FIG. 5, components other than those shown in FIG. 5, or components in addition to them may exist, and the number, type, and configuration of such components may vary.

[0107] As discussed in more detail herein, it is contemplated that some, or all, of the operations of some of the embodiments of the methods described herein may be performed in an alternative order, or may not be performed at all, and that multiple operations may occur simultaneously, or as part of a larger process.

[0108] The present disclosure may be a system, method, and / or computer program product integrated at any possible technical detail level. The computer program product may include a computer-readable storage medium (or multiple computer-readable storage media) having computer-readable program instructions for causing a processor to execute aspects of the present disclosure.

[0109] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile discs (DVDs), memory sticks, floppy disks, punch cards, mechanically encoded devices such as raised structures within grooves in which instructions are recorded, and any suitable combination of the foregoing. In this specification, a computer-readable storage medium itself is not considered to be a transitory signal such as a radio wave or other electromagnetic wave propagating freely, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0110] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing devices, or may be downloaded from an external computer or an external storage device via a network, such as, for example, the Internet, a local area network, a wide area network, and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each respective computing / processing device.

[0111] The computer-readable program instructions for performing the operations of the present disclosure may be source code or object code written in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, integrated circuit configuration data, or object-oriented programming languages such as Smalltalk® or C++, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer as a stand-alone software package, may be executed in part on the user's computer, may be executed in part on the user's computer and in part on a remote computer, or may be executed entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may utilize the state information of the computer-readable program instructions to execute the computer-readable program instructions to personalize the electronic circuit in order to perform aspects of the present disclosure.

[0112] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0113] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus for generating a machine, such that the instructions executed via the computer processor or other programmable data processing apparatus create means for implementing the functions / acts specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions for implementing the function / act specified in one or more blocks of the flowchart and / or block diagram.

[0114] Alternatively, the computer-readable program instructions may be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to create a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0115] Flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions that include one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may be performed in an order different from that noted in the drawings. For example, two blocks shown in succession may in fact be implemented as one step, may be executed simultaneously, substantially simultaneously, partially or wholly in time overlap, or, in some cases, these blocks may be executed in the reverse order depending on the functions involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a special-purpose hardware-based system that performs the specified function or operation, or a combination of special-purpose hardware and computer instructions.

[0116] The description of the various embodiments of the present disclosure is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, the practical application of the technology found in the marketplace, or the technical improvement thereof, or to enable others skilled in the art to understand the embodiments disclosed herein. The present disclosure has been described with respect to specific embodiments, but it is expected that modifications and variations thereof will become apparent to those skilled in the art. Accordingly, the following claims are intended to be construed to cover all modifications and variations that fall within the true scope of the present disclosure.

Claims

1. A method for self - auditing a blockchain, comprising: collecting, by a processor, process information related to a peer node; generating an imprint from the process information using one or more hashings; determining an imprint consensus, wherein the step of determining the imprint consensus includes identifying that a group of peer nodes have the same imprint; and comparing the imprint from the peer node with the imprint consensus to detect an error, wherein the error indicates that the peer node is at risk. A method comprising the above.

2. further comprising identifying, using the imprint, where in the process information the error of the peer node at risk has occurred. The method according to claim 1, further comprising the above.

3. The step of generating the imprint from the process information further comprises: hashing the process information from the peer node to generate a Merkle tree; generating the Merkle tree; and configuring the Merkle tree to form the imprint of the peer node. The method according to claim 1 or 2, further comprising the above.

4. encrypting the imprint to form an encrypted imprint; generating a first message, wherein the first message includes the encrypted imprint and a signature, and the signature identifies the peer node associated with the imprint; and committing the first message to the self - auditing blockchain. The method according to any one of claims 1 to 3, further comprising **Claim 5** generating a second message, wherein the second message includes one or more keys for decrypting the encrypted imprint to reform the imprint; and causing the second message to be committed to the self-auditing blockchain The method according to claim 4, further comprising **Claim 6** verifying the signature of the piano node associated with the first message; collecting the one or more keys from the second message; and decrypting the encrypted imprint of the first message using the one or more keys from the second message The method according to claim 5, further comprising **Claim 7** analyzing the imprint consensus; identifying process information associated with the imprint that does not fully match the imprint consensus; and generating a report, wherein the report includes where the error is located within the process information The method according to claim 1, further comprising **Claim 8** A system for a self-auditing blockchain, comprising a memory; and a processor in communication with the memory, the processor being configured to collect process information associated with a piano node; generate an imprint from the process information using hashing one or more times; Determining an imprint consensus, where determining the imprint consensus includes identifying that a group of peer nodes have the same imprint; and Comparing the imprint from the peer node with the imprint consensus to detect an error, where the error indicates that the peer node is at risk, A system configured to perform an operation having. **Claim 9** The processor is further configured to perform an operation having identifying where in the process information the error of the peer node at risk occurs using the imprint, The system according to claim 8. **Claim 10** Generating the imprint from the process information is Hashing the process information from the peer node to generate a Merkle tree; Generating the Merkle tree; and Configuring the Merkle tree to form the imprint of the peer node The system according to claim 8 or 9, further comprising. **Claim 11** The processor is Encrypting the imprint to form an encrypted imprint; Generating a first message, where the first message includes the encrypted imprint and a signature, where the signature identifies the peer node associated with the imprint; and Committing the first message to the self-auditing blockchain The system according to any one of claims 8 to 10, further configured to perform an operation having. **Claim 12** The processor is Generating a second message, wherein the second message includes one or more keys for decrypting the encrypted imprint and reforming the imprint; and Causing the second message to be committed to the self-auditing blockchain The system according to claim 11, further configured to perform an operation having the above.

13. The processor Verifying the signature of the piano node associated with the first message; Collecting the one or more keys from the second message; and Using the one or more keys from the second message to decrypt the encrypted imprint of the first message The system according to claim 12, further configured to perform an operation having the above.

14. The processor Analyzing the imprint consensus; Identifying the process information associated with the imprint that does not fully match the imprint consensus; and Generating a report, wherein the report includes where the error is located within the process information The system according to claim 8, further configured to perform an operation having the above.

15. A computer program for a self-auditing blockchain, comprising program instructions executable by a processor to cause the processor to perform functions, the functions being Procedures for collecting process information related to piano nodes; Procedures for generating an imprint from the process information using hashing one or more times; A procedure for determining an imprint consensus, where the procedure for determining the imprint consensus includes a procedure for identifying that a group of peer nodes have the same imprint; and A procedure for detecting an error by comparing the imprint from the peer node with the imprint consensus, where the error indicates that the peer node is at risk, A computer program having the above. **Claim 16** The function is The computer program according to claim 15, further having a procedure for using the imprint to identify where in the process information the error of the peer node at risk occurred. **Claim 17** The function is A procedure for encrypting the imprint to form an encrypted imprint; A procedure for generating a first message, where the first message includes the encrypted imprint and a signature, and the signature identifies the peer node associated with the imprint; and A procedure for committing the first message to the self-auditing blockchain The computer program according to claim 15 or 16, further having the above. **Claim 18** The function is A procedure for generating a second message, where the second message includes one or more keys for decrypting the encrypted imprint to reform the imprint; and A procedure for committing the second message to the self-auditing blockchain The computer program according to claim 17, further having the above.

Images