Blockchain-based accountable distributed computing system

Abstract

A method and system for detecting and resolving failures in a distributed computing system implemented as a permissioned blockchain network is disclosed. The method for detecting failures includes compiling and executing a smart contract common to all of the nodes of the permissioned blockchain network. The smart contract is configured to perform at least one of a set of operations including: (1) adding a transaction including a log showing an exchange of messages between the nodes of the permissioned blockchain network; (2) detecting malicious behavior of a node in reaching consensus; and (3) revoking access of the node when malicious behavior is detected. Furthermore, when malicious behavior (and a corresponding malicious node) is detected, a consensus is reached among the networked computers of the permissioned blockchain network by executing a distributed computing program.

Description

[Technical field]

[0001] The present disclosure relates generally to distributed computing systems, and more particularly to methods and systems for detecting and resolving failures in a blockchain-based accountable distributed computing system. [Background technology]

[0002] A distributed computing system is a collection of networked computers distributed across different geographic locations. The components of a distributed computing system may include multiple nodes, each node being a networked computer, which communicate with each other by exchanging messages to achieve a common goal, such as performing a computation (e.g., an ATM transaction). In some scenarios, a consensus must be reached by these components in order for a critical computation to be performed by the distributed computing system. This in turn relies on two important properties within a distributed computing system: trust between components and robustness against component failures. Components need to trust that other components are not acting maliciously. Without trust, it would be impossible for the distributed computing system to reach consensus or perform critical computations. In such cases, at best, components may discard suspicious messages or experience recoverable errors from malicious inputs, and at worst, components may be rendered inoperable by malicious inputs from trusted components acting maliciously.

[0003] Similarly, distributed computing systems contain many more components than centralized systems and therefore must be robust to the components. The need for trust in distributed computing systems is the source of many vulnerabilities that malicious actors attempt to exploit.

[0004] One well-known solution to ensure that a distributed system (such as the distributed computing system described above) is tolerant to and allows computation to proceed in the presence of malicious participants or component failures is known to those skilled in the art as BFT (Byzantine Fault Tolerance). While BFT techniques aim to make distributed systems recover faster from Byzantine failures, another approach to improve the robustness of distributed systems is to eliminate the components causing Byzantine failures. This is known as accountability, and is a property of distributed systems to make it possible to detect, identify, and isolate malicious participants in a distributed system. Accountability can bring other benefits, such as assigning non-repudiable responsibility to participants of a distributed system(s), especially if the participant is one of the malicious participants, further increasing transparency within such systems. Accountability further relies on the auditability of the system, and solutions known in the art to the problem of malicious participants in a system and to ensure accountability result in a rather complex implementation and are computationally expensive to implement.

[0005] Accountability consists of three characteristics: Failure Prevention: Dissuade malicious behavior by making it more costly. Fault Tolerance: Detecting and isolating failures, and preventing them from propagating to other parts of a system. Eliminate the disruption: Remove the malicious actor from the system to limit their impact on the rest of the system.

[0006] To achieve accountability, each participant's actions must be auditable. Auditability of a system requires secure, tamper-resistant, transparent audit logs (also referred to interchangeably as secure logging) and the ability to monitor processes within components. Although strict requirements for audit logs are intended to increase the trustworthiness of audit logs, many prior art solutions rely on centralized methods to store and access these audit logs. This is a drawback, as it shifts the trust issue from the audit logs themselves to the custodians of the audit logs. Some prior art methods for ensuring secure logging include the secure storage of audit data, such as audit logs, using digital ledgers. In this way, the audit data is transparent to the members and secured by the components of the distributed computing system themselves.

[0007] A digital ledger is a record of transactions stored in a computer. Transactions represent state changes of a system. Thus, a digital ledger represents the state of a system such as a financial system or the state of a distributed system in general. A digital ledger can be implemented in a centralized system that keeps a record of all transactions and modifies this record if another system does not agree with the record that the system itself has, without the need to create an audit trail of the changes made by the centralized system. Another way is a decentralized or distributed way that can record transactions and implement a method to determine consensus among multiple systems. This is useful because it provides a deterrent that prevents any particular system, including a distributed system, from acting selfishly and modifying the ledger in a way that undermines the trust of the distributed system. This in itself can increase users' trust in the distributed computing system and is useful for that reason.

[0008] An example of a digital ledger technology is a blockchain network. A blockchain is an append-only data structure that consists of multiple blocks linked together using a linked list structure or similar structure. A block is a container of digital information and consists of a header, metadata, and a list of transactions. The header and metadata may include information about the software version, cryptographic hashes used to compress the amount of data for storage, timestamps, etc. A transaction is a list of all transactions of a digital token, possibly hashed to reduce the amount of data for storage. A block lists all transactions from one user to another. Transactions between users are carried out by transactions between the users' corresponding digital addresses.

[0009] The data structure of the blockchain facilitates a distributed system of nodes that comprise the blockchain network to operate as one computer, enabling decentralized computation. While computations in a centralized system are rarely logged or audited, the results of decentralized computations are recorded on the blockchain in the form of blockchain transactions, improving trust in the computations. In the context of the blockchain, a computer program that describes a decentralized computation is known as a smart contract.

[0010] In the context of a network blockchain, a smart contract may be defined as an executable computer program that specifies a set of rules, data, and relationships that must be enforced when the smart contract is executed. Smart contracts are immutable in that they cannot be manipulated once they are added to the distributed ledger architecture of a defined blockchain network. Furthermore, when a node of the blockchain network invokes a smart contract, a transaction occurs, and these transactions are recorded on the blockchain network. In some embodiments, a collection of related smart contracts is referred to as a chaincode. The chaincode is used to deploy related smart contracts on the blockchain network.

[0011] One example of a blockchain network is the Bitcoin network. Blockchain networks known in the art suffer from high transaction latency, low throughput, and high computational costs associated with auditing the calculations performed by various nodes when compared to centralized networks.

[0012] Another example of a blockchain network is a permissioned blockchain network, hereafter referred to interchangeably as a permissioned blockchain. A permissioned blockchain network requires checking the access rights of each node that wants to be part of the permissioned blockchain network. A permissioned blockchain network generally includes a control layer that operates on top of the blockchain network. Participants of a permissioned blockchain network can be easily removed from the network by simply revoking their permissions. In a permissioned blockchain network, smart contracts must be recognized by all members of the permissioned blockchain network. Thus, smart contracts operate as trusted network services within a permissioned blockchain network and can be used as a tool to ensure fault tolerance and removal capabilities for nodes in the permissioned blockchain network. A node may include a networked computer with all the capabilities of a fully functional computing system. These capabilities include, among others, a fully running general-purpose operating system.

[0013] Modern general-purpose operating systems are monolithic kernels with APIs (application programming interfaces) that provide high-level virtual interfaces known as syscalls on the underlying computer hardware. Monolithic kernels serve two purposes: to free programmers from having to worry about the low-level details of the underlying hardware, and to provide security to a computing system by ensuring that processes running on the kernel do not interfere with other processes or the kernel itself. Processes running on top of the kernel form a user space, which includes a portion of memory allocated for running applications and libraries, and are given access to the kernel through syscalls. Meanwhile, kernels such as monolithic kernels reside in a portion of memory known as kernel space. In addition to providing syscalls, modern kernels provide users with mechanisms for incorporating profiling and event logging, or for enabling observability within the kernel, in the form of APIs known as kernel instrumentation. Examples of monolithic kernels include major operating systems such as Linux® and OpenBSD®. In particular, in the context of distributed computing systems, the functionality of the monolithic kernel in providing a secure and trusted environment for executing programs, with restricted or privileged access to system resources through syscalls, has not been thoroughly explored.

[0014] Until now, there has been no way to introduce accountability in a distributed computing system without a trusted node responsible for logging and monitoring audit data from the participants or nodes of the distributed computing system (again, pulling the whole system into a centralized framework) without the need to elevate the privileges of some nodes in the network. And the problem of accountability remains in that only nodes with elevated privileges are responsible for maintaining trust in the network. The problem of accountability is also one of non-repudiation. Each node in a distributed computing system needs to be uniquely identifiable in order to be accountable, trusted, and non-repudiatably responsible for its actions.

[0015] Therefore, there is a need for an efficient system for controlling the operation of nodes or systems in an optimal or feasible manner and for enforcing security, auditability, accountability and trust in distributed computing system architectures. Summary of the Invention

[0016] It is an object of some embodiments to provide a distributed computing system that is robust and fault-tolerant, and that can also ensure accountability, trust, and auditability of transactions and individual participants.

[0017] To this end, some embodiments of the present disclosure take into account the benefits of secure logging of audit data, tamper resistance, and verifiability, access control, and decentralized architecture that permissioned blockchain networks provide. In addition, various embodiments disclosed herein take advantage of the benefits that smart contracts provide in identifying, isolating, and preventing malicious participants from posing a threat to the integrity of the entire distributed computing system, and the use of permissioned blockchain architecture allows the revocation of privileges (such as both read-related and write-related privileges) of malicious participants to achieve the goal of resolving the fault. Some embodiments also take advantage of kernel-level instrumentation through the use of syscalls to further uniquely identify malicious nodes and provide better transparency and auditability of the entire system.

[0018] Some embodiments provide a blockchain-based method for introducing accountability into a distributed computing system by enabling identification of faulty systems, fault detection, and removal of malicious participants in the distributed computing system without the need to elevate network privileges possessed by some nodes of the system.

[0019] Various embodiments provide systems and methods based on three components: (1) utilizing smart contracts as trusted network services; (2) utilizing participant classification; and (3) authorizing participants in a distributed computing system through permissioning techniques provided by a permissioned blockchain network.

[0020] Some embodiments are based on the recognition that smart contracts in a permissioned blockchain network are trusted services within the permissioned blockchain network that do not require elevating the network privileges of nodes because they must be shared among participants as source code. This trust allows smart contracts to be used as a mechanism to record audit data for publication on the permissioned blockchain network that is trusted by all participants. Per-participant audit data is obtained by utilizing kernel-level instrumentation provided by APIs that allow users to monitor and log processes and data structures in the kernel. This contributes to failure prevention, as logging and publishing audit data that is trusted by all participants would be costly for malicious behavior.

[0021] Some embodiments are based on the realization that in a blockchain system, each transaction must be signed by a private key belonging to the participant. This, in addition to the design decision to utilize a permissioned blockchain framework, can be used to satisfy fault tolerance properties, since the identities of participants in a permissioned blockchain network must be recorded in the system. This allows for non-repudiable assignment of responsibility for misconduct. Finally, resolving faults is easy in a permissioned blockchain system, since violating or malicious nodes can be easily removed by revoking their permission to participate in the blockchain network (e.g., a permissioned blockchain network).

[0022] Some embodiments are based on the realization that utilizing a permissioned blockchain network to audit node behavior as an authority management framework for nodes in a distributed system significantly increases both the trust and robustness of the distributed system that would not be possible if computations were performed on top of the blockchain network.

[0023] Some embodiments are based on the recognition that publishing a verifiable record of the activity of nodes in a distributed computing system requires less computation than repeating the computation on every node in the blockchain network. Thus, the systems and methods disclosed herein can provide significant savings in computational costs and improved efficiency for providing a robust, accountable, secure, and trustworthy distributed computing system.

[0024] According to some embodiments, a system and method are provided for implementing a distributed computing system with fault detection and resolution capabilities. The distributed computing system comprises at least one blockchain-enabled networked computer. The at least one blockchain-enabled networked computer is in communication with one or more distinct networked computers through a permissioned blockchain network. The blockchain-enabled networked computer comprises general system components including at least one processor, a memory, an operating system stored in the memory, and one or more instructions stored in the memory executable by the at least one processor to perform various operations. The memory may be divided into a kernel space and a user space. The memory may further store instructions that, when executed by the at least one processor, cause the networked computer to compile and execute a smart contract. The smart contract may be a computer program common to all networked computers that are part of the permissioned blockchain network. The smart contract includes a set of rules used to define a set of behaviors. The set of operations includes at least one of the following, or a combination of: adding a transaction to the permissioned blockchain network (where the transaction includes a log indicating messages are being exchanged between networked computers having access to the permissioned blockchain network), detecting malicious behavior of the networked computers when reaching consensus with other participants in the permissioned blockchain network, and revoking access of the networked computers to the permissioned blockchain network upon detecting malicious behavior. The detection of malicious behavior is based on kernel instrumentation of the networked computers enabled by the smart contract.Furthermore, once a smart contract is compiled and executed, a distributed program is executed to reach consensus with other networked computers that have access to the permissioned blockchain network.

[0025] Some embodiments are based on the recognition that different networked computers that are participants in a permissioned blockchain network can be classified into at least one of two types of participants: (1) observers and (2) operators. Observers are participants or nodes in a permissioned blockchain network that can be required to run at least one blockchain node to replicate the blockchain including audit data from participants in a particular (sub)network. Observers participate in the consensus process by proposing one or more transactions to the permissioned blockchain network. The other type of node is an operator node, which actively participates in the consensus process by executing transactions.

[0026] Some embodiments are based on the recognition that smart contracts are configured to detect malicious behavior of nodes in the permissioned blockchain network based on analysis of one or more audit logs generated by networked computers in response to execution of the smart contracts and corresponding transactions in the permissioned blockchain network.

[0027] Some embodiments are based on the recognition that malicious behavior occurs when a networked computer communicates different values ​​of a message to various different nodes or networked computers connected to a permissioned blockchain network.

[0028] Some embodiments are based on the recognition that smart contracts may be distributed to nodes of a permissioned blockchain network in the form of at least one of source code files and trusted binary files.

[0029] It is an objective of some embodiments to deploy the smart contract as part of a kernel instrumentation activity performed on a networked computer. The kernel instrumentation is performed by logging the results of an audit of various different types of syscall requests made with the smart contract, which are then published on the permissioned blockchain network. If the logs indicate malicious modification of user space programs (identified by inspecting audit data associated with one or more types of syscall requests), malicious participants in the permissioned blockchain network are identified and isolated.

[0030] Furthermore, in some embodiments, malicious participants are removed from the permissioned blockchain network by revoking all permissions associated with the malicious participants. [Brief description of the drawings]

[0031] [Figure 1A] FIG. 1 illustrates a block diagram illustrating an architecture of a permissioned blockchain system for detecting and resolving failures, according to some embodiments of the present disclosure. [Figure 1B] FIG. 1 illustrates a block diagram of a permissioned blockchain system including a variety of different types of nodes, according to some embodiments of the present disclosure. [Figure 1C] FIG. 1 illustrates a block diagram of a permissioned blockchain system including light client nodes in accordance with some embodiments of the present disclosure. [Figure 1D] FIG. 1 illustrates a block diagram of a permissioned blockchain system with smart contracts in accordance with some embodiments of the present disclosure. [Figure 2A] FIG. 2 illustrates a block diagram illustrating separation of user space and kernel space, in accordance with some embodiments of the present disclosure. [Figure 2B] 2B shows a detailed block diagram illustrating the user space and kernel space components shown in FIG. 2A in accordance with some embodiments of the present disclosure. [Figure 2C] FIG. 2 shows a detailed block diagram illustrating instrumentation technology used to audit kernel space data in accordance with some embodiments of the present disclosure. [Diagram 3] FIG. 1 illustrates a high-level block diagram of a permissioned blockchain system in accordance with some embodiments of the present disclosure. [Figure 4] FIG. 1 illustrates a high-level block diagram of an organizational blockchain system in accordance with some embodiments of the present disclosure. [Diagram 5] FIG. 1 illustrates a detailed block diagram of various different nodes in a permissioned blockchain system, in accordance with some embodiments of the present disclosure. [Figure 6] FIG. 1 illustrates a detailed block diagram of various different nodes in a permissioned blockchain system, in accordance with some embodiments of the present disclosure. [Figure 7] FIG. 1 illustrates a flow diagram of various different nodes in a permissioned blockchain system, in accordance with some embodiments of the present disclosure. [Figure 8] 1 illustrates an environment for detecting and resolving faults in a distributed computing system according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0032] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to one skilled in the art that the present disclosure may be practiced without these specific details. In other instances, devices and methods are shown in block diagram form in order to avoid obscuring the disclosure.

[0033] As used herein and in the appended claims, the terms "for example," "for instance," and "such as," as well as the verbs "comprising," "having," "including," and other verb forms thereof, when used in conjunction with a list of one or more components or other items, should be construed as open-ended, meaning that the list should not be considered to exclude other additional components or other items. The term "based on" means based, at least in part, on. Moreover, it is to be understood that the phraseology and terminology used herein are for purposes of description and should not be considered limiting. The headings used herein are for convenience only and do not have any legal or limiting effect.

[0034] FIG. 1A illustrates a block diagram illustrating an architecture of a permissioned blockchain system 100 for detecting and resolving faults, according to some embodiments of the present disclosure. The system 100 includes one or more blockchain networks, such as blockchain network 112 and blockchain network 120. The system 100 further includes a plurality of nodes, such as node 114, node 116, node 118, and node 122. The node 114, node 118, and node 122 are associated with the blockchain network 120. The node 116 is associated with and is part of the blockchain network 112. Each of the plurality of nodes may be a networked computer. Furthermore, each of the networked computers may be a blockchain-enabled networked computer.

[0035] As shown in FIG. 1A, a node can be part of more than one network. For example, node 114 is part of blockchain network 112 and blockchain network 120. Those skilled in the art will appreciate that for convenience of the specific embodiments described herein, networks 112 and 120 are depicted as blockchain networks. The term blockchain refers to a network architecture that implements a distributed computing network, having decentralized control of operations and transactions therein and requiring the distributed computing network. Thus, nodes 114, 116, 118, and 122 can be nodes of such a distributed computing network. A specific type of distributed computing network is a blockchain network with all enabling technologies. Furthermore, in some embodiments, the blockchain network is a permissioned blockchain network, having an access layer above the blockchain layer, which defines the various permissions available to the various different nodes that are part of the permissioned blockchain network.

[0036] The permissioned blockchain network architecture itself has many advantages, such as providing a trust-based, secure distributed computing architecture that provides secure logging capabilities for audit logs associated with nodes on the permissioned blockchain network by using a separate blockchain backbone. At the same time, the permissioned blockchain architecture provides fault tolerance, failure prevention, and failure resolution capabilities, making it a highly accountable architecture for implementing distributed (decentralized) computing systems.

[0037] Nodes in the permissioned blockchain system 100 may be referred to as participants in the system and may be divided into two broad categories: observers and operators. In addition, there are also ordering nodes and light clients in the permissioned blockchain system 100, as described later in the description of the various embodiments provided herein.

[0038] Observers are nodes that do not necessarily create transactions, but are responsible for detecting, identifying, and eliminating malicious participants in the system. Observers also contribute towards reaching consensus in the permissioned blockchain system 100 and can replicate the blockchain backbone of the permissioned blockchain system 100. Observers audit the participants of the permissioned blockchain system 100 through the blockchain backbone. In FIG. 1A, node 114 is an observer node that runs one node that is part of two blockchain sub-networks 112 and 120. Observers improve the fault tolerance of the permissioned blockchain system 100 by detecting failures in the permissioned blockchain system 100 and also by identifying malicious participants in the permissioned blockchain system 100.

[0039] The other type of node in the permissioned blockchain system 100 is an operator. An operator is a node that creates transactions for inclusion in a blockchain system, such as the permissioned blockchain system 100. An operator node must prove that it is a trustworthy operator node by recording its actions on the permissioned blockchain system 100 for public auditing using smart contracts. Operators also improve the fault tolerance of the permissioned blockchain system 100 by reporting their own audit data to the permissioned blockchain system 100. Referring to FIG. 1A, nodes 116, 118, and 122 are operator nodes that are connected to the blockchain (sub)networks 112 and 120.

[0040] In some embodiments, the permissioned blockchain system 100 may include a distributed system in which participants who do not completely trust each other can participate trustfully. An example of this is an intra-organizational network consisting of a corporation and its subsidiaries (further illustrated in FIG. 1B).

[0041] FIG. 1B illustrates a block diagram of a permissioned blockchain system 126 including various different types of nodes, according to some embodiments of the present disclosure. The permissioned blockchain system 126 includes multiple participants (or nodes) that belong to an organization represented by box 138 (sometimes referred to as an “organization” 138). Box 136 further represents a parent organization consisting of two nodes, an observer node 124 and a regular or operator node 128, that send audit data to the permissioned blockchain system 126. The nodes 124 and 128 are both within the parent organization 136 and therefore can communicate with each other. The organization 138 also includes a child organization 134 consisting of two nodes 130 and 132 whose operations are audited and sent to the permissioned blockchain system 126. FIG. 1B illustrates only one possible environment for the permissioned blockchain system 100 of FIG. 1A. Another possible example (not shown) includes real-time automatic auditing of a subset of the participants of the permissioned blockchain system 100 that can be trusted by all participants. Each participant in the permissioned blockchain system 100 can be one of the four types described above: observer, operator, ordering, and light client. Operators and observers were previously described in conjunction with Figure 1A. Light clients are described below in the description of Figure 1C.

[0042] 1C illustrates a block diagram of a permissioned blockchain system 140 including light client nodes, according to some embodiments of the disclosure. The permissioned blockchain system 140 includes two light client nodes, such as light client 142 and light client 144. The light client 144 further includes an embedded device 146.

[0043] The light clients 142 and 144 may include any modern computer, such as an embedded computer, a laptop, a mobile phone, a smartphone, a tablet, a smart watch, a wearable computer, a point of sale (POS) terminal, a kiosk, a routing device, a monitoring terminal in a power plant, an electronic meter, etc. Some embodiments are based on the recognition that many modern computers are embedded devices with limited computing power, such as the light client 144 associated with the embedded device 146, and therefore cannot store a complete copy of the blockchain of which they are a part. However, using these embodiments and the architecture of the permissioned blockchain system 140, even these light systems with low computing power will be fully trusted, secure, and efficiently monitored for malicious behavior. This is possible thanks to the combination of smart contracts and kernel instrumentation technology implemented in the permissioned blockchain system 100 (i.e., the permissioned blockchain system 140) disclosed in various embodiments described herein.

[0044] 1D illustrates a block diagram of a permissioned blockchain system 148 including a smart contract 152, according to some embodiments of the present disclosure. The permissioned blockchain system 148 includes a node 150. The node 150 may be a blockchain-enabled networked computer and may communicate with other networked computers (not shown herein). The node 150 may be configured to compile and execute a smart contract 152 as part of an audit procedure for the node 150. The smart contract 152 may be associated with a process 154. The smart contract 152 may be configured to detect malicious behavior associated with the node 150 based on analysis of one or more audit logs generated by the node 150 in response to the execution of the smart contract 152 and corresponding permissioned blockchain network 148 transactions.

[0045] To that end, smart contract 152 is configured to detect malicious behavior of node 150 when node 150 communicates different values ​​of the same message to different other nodes (or networked computers) that have access to the permissioned blockchain network 148.

[0046] Various embodiments allow for the deployment of smart contracts 152 on the permissioned blockchain network 148 by distributing the source code of the smart contracts 152 or trusted binary files associated with the compiled smart contracts 152 to the members (e.g., nodes 150) of the permissioned blockchain network 148. Once the source code of the smart contracts 152 is distributed to all nodes of the permissioned blockchain network 148, each of the nodes may locally compile the smart contracts 152. This ensures that the smart contracts operate as a trusted, transparent, tamper-resistant, and robust tool to ensure the fault tolerance of the permissioned blockchain network 148. This is because the smart contracts 152 themselves are immutable. Thus, malicious behavior involving deviations from acceptable rules, permissions, or permitted operations on the permissioned blockchain network 148 will occur at a lower level (e.g., at the kernel level) and will be much more costly.

[0047] Furthermore, the process 154 may be audited using a smart contract 152 associated with the process 154 by defining a set of rules that dictate acceptable data types, operations, dependencies, and packaging information for data associated with the process 154. Thus, each invocation of the process 154 may also invoke the smart contract 152 and execute its corresponding rules. Deviations from the rules may be identified by performing instrumentation at the kernel level of the node 150 and logged on the permissioned blockchain network 148. By auditing this logged information, malicious attempts on the part of the node 150 may be detected. Thus, the node 150 may be identified and quarantined, and further, the permissions associated with the node 150 may be revoked to completely remove the malicious node from the permissioned blockchain network 148.

[0048] In some embodiments, smart contract 152 contains rules for network-based policy enforcement that defines the correct configuration of nodes by triggering local events, the responses to which are recorded on the blockchain based on the rules specified in smart contract 152.

[0049] To that end, node 150 may be at least one operator node or observer node (where the functionality of an operator node and an observer node has been described above). If node 150 is an observer node, node 150 may be configured to replicate a blockchain consisting of all permissioned (sub)networks of which it is a member. As described above in conjunction with FIG. 1A, node 150 may be part of one or more permissioned blockchain (sub)networks. If node 150 is part of more than one permissioned blockchain (sub)network, each of these permissioned blockchain (sub)networks will have at least one observer node in common with another sub-network.

[0050] In some embodiments, node 150 is configured as an operator node and provides audit details of its operations by submitting (in response to execution of smart contracts 152) kernel instrumentation data of node 150 that deployed smart contracts 152 upload to the permissioned blockchain network 148.

[0051] In some embodiments, when node 150 is configured as an operator node, node 150 is further associated with a physical terminal configured to enable human interaction, and further where smart contract 152 is configured to grant authorizations to a human operator on behalf of the organization, as described in more detail in FIG. 6 and the associated discussion.

[0052] Various embodiments further provide that the node 150 is configured to exchange messages with other nodes in the permissioned blockchain network 148 to coordinate the actions of all nodes that are part of the permissioned blockchain network 148. This coordination then occurs to reach a consensus among all nodes in the permissioned blockchain network 148 regarding the current state of the permissioned blockchain network 148 according to a distributed computing program commonly known as a consensus algorithm. One example of a consensus algorithm that the permissioned blockchain network 148 may utilize to reach a consensus is the Practical Byzantine Fault Tolerant (PBFT) algorithm, in which a node is configured to receive confirmations regarding the validity of the node's transactions from all other nodes in the permissioned blockchain network 148. A consensus is then reached based on the total number of confirmations received by the nodes.

[0053] Some embodiments disclosed herein are based on the understanding that observer nodes help reach consensus by proposing transactions to all nodes in the permissioned blockchain network 148. Moreover, transactions proposed by observer nodes are subject to auditing and recording of audit results on the permissioned blockchain network 148 according to a common set of rules specified in a smart contract, such as smart contract 152.

[0054] Various embodiments provide that smart contracts 152 are stored on a node 150 as part of the node's application space and are further deployed as part of the node's kernel instrumentation, as will be described in further detail in conjunction with Figures 2A-2C.

[0055] FIG. 2A illustrates a block diagram illustrating the separation of user space 200 and kernel space 202 associated with node 150, according to some embodiments of the present disclosure.

[0056] The user space 200 includes a portion of the memory of the node 150 (a computing unit having a memory and a processor) that stores user programs such as application programs, application data, APIs, software or code libraries, stored procedures, algorithms, computer instructions, and user files. The user programs in the user space 200 are generally written in any of the well-known high-level languages ​​such as C#, C++, Java, Python, Solidity, JavaScript, and the like. The user space 200 also includes various processes, such as business processes or network interface processes, that define algorithms and logical instructions to perform one or more functions. These functions are application-specific functions. One type of user program in the user space 200 is a smart contract 204 (corresponding to the smart contract 152 shown in FIG. 1D). The smart contract 204 defines enforceable rules that are executed when the smart contract 204 is executed. The execution of the smart contract 204 may then invoke one or more processes that require access to system (operating system) resources. System resources are stored in a portion of memory separate from user space 200 (known as kernel space 202 ).

[0057] Kernel space 202 defines a portion of memory in which the core of node 150 in the form of an operating system and its associated programs is stored. Kernel space 202 stores specialized programs that enable the cooperation of various system resources, such as hardware and file systems. Kernel space 202 may include specialized programs and data, such as device drivers, memory managers, input / output managers, process managers, and the like. Typically, kernel space programs are written in a low-level language, such as C.

[0058] System resources contained in kernel space 202 may be accessed by processes in user space 200 by special requests sent to kernel space 202 in the form of system calls, or syscalls. Each resource access requires a separate syscall. Furthermore, each syscall and its associated system resources may be monitored by utilizing special techniques known as kernel-level instrumentation technologies. Kernel-level instrumentation technologies enable, among other things, code observability, collection of performance metrics, and tracing of security-related events, as will be described in further detail in conjunction with Figures 2A and 2B.

[0059] FIG. 2B shows a detailed block diagram illustrating the components of user space 200 and kernel space 202 shown in FIG. 2A.

[0060] As can be seen in FIG. 2B, no process 206 in user space 200 can access system resources 210 stored within kernel space 202 except through one or more syscalls.

[0061] Various embodiments described herein provide for auditing of syscalls based on rules specified in a smart contract 204, which is a deployed smart contract associated with a permissioned blockchain system 212 (corresponding to the permissioned blockchain system described above in Figures 1A-1D). The auditing of syscalls is performed based on any of the instrumentation technologies known in the art. Figures 2B and 2C show well-known instrumentation technologies 208 that may be used for illustration purposes in various embodiments described herein.

[0062] The instrumentation technologies 208, shown in detail in Figure 2C, include kernel audit 214, probes 216, trace points 218, and Berkley packet filters 220. For purposes of illustration, only four instrumentation technologies 208 are shown in Figure 2C. Any number of instrumentation technologies may be added to the list of instrumentation technologies 208 without departing from the scope of this disclosure.

[0063] Kernel Audit 214 includes an audit subsystem, which is a pre-built rules-based framework for system auditing and security functions. The kernel audit 214 subsystem is configured to capture a wide range of system events and their associated metadata, including (but not limited to) file system auditing, syscall auditing, trusted database access, and attempts to import / export functions and other predefined events. The subsystem includes 1) a kernel component for generating audit records, 2) a user space daemon for logging the audit records to a local file or an external server, and 3) a set of user space tools for inspecting and processing the audit logs.

[0064] Probes 216 are dynamic instrumentation enablers that allow the kernel to modify assembly-level code in kernel space (Kprobes) or user space (Uprobes) at runtime by attaching breakpoints and handler functions. Probes are configured to log the state of the operating system of node 150 and its processes.

[0065] Tracepoints 218 include a system for monitoring instrumentation where hooks are inserted at key locations in the code that call functions that can be specified during runtime. Tracepoints 218 are activated when a particular code path is reached and the corresponding kernel API exposes a predefined event.

[0066] BPF (Berkeley Packet Filter) 220 is a set of technologies for system-level instrumentation. Implementing BPF requires three key components: 1) an in-kernel virtual machine with its own virtual instruction set known as BPF bytecode; 2) a kernel runtime consisting of an interpreter, a verifier for the safety of BPF programs, and a Just In Time (JIT) compiler for converting BPF bytecode into native instructions; and 3) a custom key-value data structure known as BPF mapping for data sharing between kernel space 202 and user space 200. BPF helps monitor kernel module loading, process crashes, page fault errors, spurious usage, SSH authentication, cipher initialization, shell commands, etc.

[0067] Various instrumentation technologies 208 disclosed herein enable auditing of one or more syscalls, such that invocations of one or more syscall requests are automatically logged by the smart contract 204 for publication on the permissioned blockchain network 212.

[0068] Thus, the smart contract 204 is deployed as part of the kernel instrumentation (using any of the kernel instrumentation technologies 208 described above) of the node 150, where malicious modification of programs in the user space 200 may be detected by inspecting the permissioned blockchain network 212, which includes audit data related to one or more types of system call requests.

[0069] If node 150 is identified as a malicious node based on an inspection of the audit data submitted by node 150, node 150's permission to access the permissioned blockchain network 212 may be revoked. Thus, using the permissioned blockchain network 212 architecture, smart contracts 204, and kernel instrumentation technology 208 in the manner described above allows for fault detection, fault rectification, and secure logging capabilities, making node 150 and the entire system associated with the permissioned blockchain network 212 a highly accountable system.

[0070] 3 illustrates a high-level block diagram of a permissioned blockchain system 300 according to some embodiments of the present disclosure. Various embodiments described herein provide an accountable distributed system based on a permissioned blockchain network 300. The main components of such a system are the permissioned blockchain network 300, smart contracts 302, and underlying participant nodes 304.

[0071] The underlying participant nodes 304 are one or more networked computers that are blockchain-enabled. Each of the participant nodes 304 can be part of one or more blockchain (sub)networks. Furthermore, each of the participant nodes 304 can be one of four types of nodes: observer, operator, ordering, and light client. Importantly, these participant nodes 304 are categorized as operators and observers.

[0072] Observers represent a classification of participant nodes 304 that do not have processes that require auditing, and therefore do not create transactions that need to be added to the permissioned blockchain network 300. Instead, observers run nodes to replicate the blockchain and audit participants in the replicated blockchain network. Observer nodes perform functions including, but not limited to, improving redundancy and security of the permissioned blockchain network 300 through auditing, detecting and removing malicious participants from the permissioned blockchain network 300, and performing ordering services to add to the blockchain according to transactions provided by the smart contract 302. Observer nodes provide the advantage of improving the fault tolerance of the entire permissioned blockchain network 300 and improving the ability to prevent failures of the entire permissioned blockchain network 300, because observer nodes are also configured to remove malicious participants from the permissioned blockchain network 300 by revoking their privileges in the permissioned blockchain network 300.

[0073] The other major classification of nodes in the permissioned blockchain network 300 is operators. Operators are nodes that have processes that require auditing. This can be accomplished by recording the actions of operator nodes with respect to the permissioned blockchain network 300 based on rules specified in smart contracts 302. Additionally, the actions of operator nodes are audited using kernel instrumentation technology 208 as described in FIG. 2C.

[0074] To make the permissioned blockchain network 300 an accountable (distributed) system, the participant nodes 304 of the permissioned blockchain network 300 may include at least one observer node.

[0075] Various embodiments disclosed herein provide authority management functionality for all nodes on the permissioned blockchain network 300. The authority management functionality includes at least one process-related authorization, node-related authorization, and human interface-related authorization, or a combination thereof.

[0076] Process-related permissions include identifying whether a process in the kernel possesses proper permissions to access system resources using kernel instrumentation technologies 208, as outlined above in conjunction with Figure 2B, and are implemented by any of the kernel instrumentation technologies 208 described above.

[0077] Node-related permissions include checking whether a node is authorized to participate in a distributed computing system such as the permissioned blockchain network 300. This is done by the blockchain network framework requirement that nodes with sufficient permissions are accepted by all participants and nodes without sufficient permissions cannot participate. Additionally, node-related permissions are recorded in a number of network configuration files available to nodes in the permissioned blockchain network 300.

[0078] Human interface related permissions include permissions related to human operators interacting with nodes through physical interface terminals. This is required in scenarios where computing devices or networked computers associated with the permissioned blockchain network 300 are trusted but shared among multiple human operators, who may not all be trustworthy. Thus, human interface related permissions ensure that permissions assigned to human operators interacting with networked computers are not tied to the networked computer setup and can be changed in real time by the organization (of which the networked computer or node is a part). This may be achieved by utilizing LDAP (Lightweight Directory Access Protocol), which will be described in more detail in conjunction with FIG. 6.

[0079] As described in the figures and associated description below, the architecture of the permissioned blockchain network 300 may be implemented using a number of different scenarios.

[0080] FIG. 4 illustrates a high-level block diagram of an organizational blockchain system 400 according to some embodiments of the present disclosure. The organizational blockchain system 400 includes a permissioned blockchain network as part of the organizational blockchain system 400, and has multiple nodes or blockchain-enabled networked computers associated with the organizational blockchain system 400. FIG. 4 illustrates four such nodes: a parent node 404 and associated ordering service 404a, and one or more child nodes, node 402, node 406, and node 408. Those skilled in the art will appreciate that the particular number of nodes shown in the system is for illustrative purposes only. Any number of nodes may be associated with the organizational blockchain system 400 without departing from the scope of the present disclosure.

[0081] A parent node 404 may be associated with a parent organization and operates as an ordering node that executes an ordering service 404a to order audits of other nodes (such as child nodes 402, 406, and 408) associated with the organizational blockchain system 400. The node 404's interaction with the organizational blockchain system 400 may be read-only. The parent node 404 may also be configured to synchronize a full copy of the organizational blockchain system 400 by participating in a consensus algorithm associated with the organizational blockchain system 400 by proposing transactions. The consensus algorithm ensures that all nodes of the organizational blockchain system 400 agree on the current state of the organizational blockchain system 400.

[0082] Additionally, child nodes may correspond to child organizations, such as subsidiaries of a parent organization, and need to be monitored. Each of the child nodes may be able to read and write to the organization's blockchain system 400. Nodes 402 and 406 may be configured to operate as operator nodes and have their processes audited through a combination of smart contract and kernel instrumentation technologies described above, and are configured to actively participate in the consensus algorithm by generating transactions that include the audit data.

[0083] Additionally, as shown in FIG. 4, for example, child node 408 may communicate with the organization's blockchain system 400 through child node 406 if the child node 408 is a light-client device that is not capable of running a full blockchain-enabled node.

[0084] The functionality of the various nodes and services associated with the blockchain framework may be implemented through the use of APIs and code libraries as would be known to one of ordinary skill in the art.

[0085] FIG. 5 illustrates another block diagram of a scenario illustrating various different nodes in a permissioned blockchain system 500, according to some embodiments of the present disclosure. The permissioned blockchain system 500 may be associated with one or more nodes, such as node 502 and node 504. Node 502 may be an operator node that executes a process 506 that needs to be audited. Invocation of the process 506 may further lead to invocation of a chaincode 508 on node 502 and a chaincode 512 on node 504. As previously discussed, a chaincode is a set or collection of related smart contracts. Then, with the rules defined in the chaincode 508 and the chaincode 512, the transactions of the nodes 502 and 504 may be monitored at the kernel level by utilizing well-known kernel instrumentation technologies (some of which were previously described in FIG. 2C). Furthermore, invocation of the chaincode 508 may lead to invocation of the chaincode 510, which may lead to invocation of the chaincode 512, which may lead to invocation of the chaincode 514, the results of which may be recorded on the permissioned blockchain system 500. Additionally, the results of invocations of chaincode 508 and chaincode 512 (in the form of audit results using kernel instrumentation technology) may be recorded on the permissioned blockchain system 500.

[0086] Invoking associated chaincode on the permissioned blockchain system 500 in the manner illustrated in Figure 5 may provide cross-chaincode invocation capabilities, which may further enable automation of some of the auditing capabilities using smart contracts and chaincode. Thus, using the exemplary embodiment described in Figure 5, the permissioned blockchain system 500 may be used to provide semi-automated or fully automatic fault detection and accountable distributed computing systems.

[0087] Another possible embodiment implementation of an accountable and fault-tolerant distributed computing system is illustrated in Figure 6. Figure 6 illustrates authority management for collaboration with a human permissioned blockchain network 300 as briefly disclosed in Figure 3.

[0088] FIG. 6 illustrates a detailed block diagram of various different nodes in a permissioned blockchain system 600 for human collaborative authority management, according to some embodiments of the present disclosure.

[0089] The permissioned blockchain system 600 may be accessed by a human operator 604. The human operator 604 may or may not be authorized to access the permissioned blockchain system 600. Meanwhile, the node 602 may be authorized to access the permissioned blockchain system 600. To authenticate the human operator 604 to access the permissioned blockchain system 600, a credential service 606 such as LDAP may be executed using a computing terminal 608 such as an RPi (Raspberry Pi) enabled terminal (shown here for illustrative purposes). The result of the authentication or audit is then recorded on the permissioned blockchain system 600. The authorization of the human operator may be reinstated or revoked accordingly.

[0090] Thus, the permissioned blockchain system 600 functions as an accountable distributed system that can detect, prevent, and resolve failures with low computational cost and highly efficient security mechanisms such as smart contracts and kernel instrumentation.

[0091] FIG. 7 illustrates a flow diagram of a method 700 showing different steps for detecting and resolving failures in an accountable, permissioned blockchain network, according to some embodiments of the present disclosure.

[0092] At step 702, the method 700 of FIG. 7 includes compiling and executing a smart contract associated with the permissioned blockchain network. For example, with reference to FIG. 2B and FIG. 2C, the permissioned blockchain network 212 may be associated with a node 150 that may receive a trusted binary file or a source code file associated with the smart contract 204. If the smart contract 204 is in the form of a source code file, it may be compiled and then executed. In some embodiments, the smart contract 204 is in the form of an executable file itself and does not need to be compiled. Execution of the smart contract 204 results in the enforcement of a set of rules specified in the smart contract 204. The set of rules may relate to a set of actions to perform at least one or a combination of the following: 1) adding data having transactions, including logs showing message exchanges between networked computers or nodes having access to the permissioned blockchain network 212, to the permissioned blockchain network 212; (2) detecting malicious behavior of a networked computer, such as node 150, when reaching consensus (wherein the detection is performed based on kernel instrumentation of the networked computer); and (3) revoking the networked computer's access to the permissioned blockchain network 212 upon detecting malicious behavior.

[0093] At step 704, detection of malicious activity is performed by generating audit data of a networked computer such as node 150 based on auditing syscalls of node 150 utilizing any kernel instrumentation technology 208. Furthermore, the results of this audit are stored in the permissioned blockchain network 212 by append-only data operations on the audit data log. Once the audit data log is submitted in this manner, at step 706, malicious activity on the part of node 150 can be detected and, if necessary, node 150's permissions can be revoked.

[0094] The method 700 of FIG. 7 can be implemented in any distributed computing system to ensure accountability, fault tolerance, and reliability across the distributed computing system.

[0095] FIG. 8 illustrates a working environment 800 for detecting and resolving faults in a distributed computing system according to some embodiments of the present disclosure. The working environment 800 corresponds to a power plant 804. The power plant 804 may act as a parent node that executes an ordering service to order audits of different entities connected to the power plant 804 through a permissioned blockchain network 802. These different entities may include a consumer 808, a factory 812, and a distribution grid 816. Each of the entities 808, 812, and 816 may be connected to the permissioned blockchain network 802 through a computing system that executes a full node or a lightweight node in the form of a blockchain-enabled networked computer or the like. Moreover, each entity is configured to receive an individual copy of a smart contract from the permissioned blockchain network 802, smart contract 810 for the customer 808, smart contract 814 for the factory 812, and smart contract 818 for the distribution grid 816. Each smart contract may be in the form of one of a trusted binary file or a source code file and is immutable. Furthermore, some embodiments are based on the recognition that the copies of the smart contracts of all nodes may be common to all nodes.

[0096] Moreover, each smart contract specifies rules for monitoring and auditing each of the nodes 808, 812, and 816. For example, the rules may relate to the use of power supply units, metering of power consumption and attempts to tamper with the metering units, acceptance of power supply units for consumption in factories, allowable caps on the number of units of electricity distributed through the grid, compliance with government and regulatory regimes, etc.

[0097] Once each of the smart contracts 810, 814, and 818 is in place, each type of node may be audited using kernel-level instrumentation of the associated computing terminal, and the results of the audit may be recorded on the permissioned blockchain network 802. Furthermore, the different nodes may then be configured to reach a consensus on the authenticity of each of the nodes, and according to the results of the audit and the consensus, each of the nodes may be allowed to resume connection with the permissioned blockchain network 802 and continue to have access to the electricity generated by the power plant 804. Otherwise, the node's connection may be temporarily banned if it fails to pass the audit procedure.

[0098] Thus, the various embodiments described herein provide a secure, tamper-resistant, efficient, reliable, cost-effective and accountable distributed computing system. The various embodiments allow for the physical (computing) to be auditable and accountable through digital management. Furthermore, the various techniques described herein can be implemented with light clients as easily as fully embedded blockchain nodes, making the overall system highly efficient, scalable and cost-effective. Also, in many permissioned blockchains, the client is a trusted binary shared among the various participating nodes, acting as a trusted lightweight blockchain client.

[0099] The above description provides only exemplary embodiments and does not limit the scope, applicability, or configuration of the present disclosure. Rather, the description of the exemplary embodiments provides one of ordinary skill in the art with an enabling description for implementing one or more exemplary embodiments. It is contemplated that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the subject matter as set forth in the appended claims.

[0100] Specific details have been set forth in the above description to provide a thorough understanding of the embodiments. However, those skilled in the art will appreciate that the embodiments may be practiced without these specific details. For example, systems, processes, and other elements of the disclosed subject matter may be illustrated as components in block diagrams so as not to obscure the embodiments in unnecessary detail. In other instances, well-known processes, structures, and techniques may be illustrated without unnecessary detail so as not to obscure the embodiments. Furthermore, the same reference numbers and symbols may refer to the same elements in the various drawings.

[0101] Also, each embodiment may be described as a process and illustrated as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may show operations as a sequential process, many of the operations may be performed in parallel or simultaneously. In addition, the order of operations may be rearranged. A process may terminate when its operations are completed, but may have additional steps not included in the drawings. Furthermore, not all operations included in the specifically described process may be performed in all embodiments. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, and the like. When a process corresponds to a function, the end of the function may correspond to the function returning to a calling function or a main function.

[0102] Moreover, at least some of the embodiments of the disclosed subject matter may be implemented manually or automatically. The manual or automatic implementation may be performed or at least assisted by use of machine, hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored on a machine-readable medium. A processor(s) may perform the necessary tasks.

[0103] The various methods or steps outlined herein may be coded as software executable on one or more processors using any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages ​​and / or programming or scripting tools, or may be compiled as executable machine language code or intermediate code that runs on a framework or virtual machine. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments.

[0104] The embodiments of the present disclosure may be implemented as a method, examples of which have been provided. The operations performed as part of the method may be appropriately ordered. Thus, embodiments may be constructed in which operations are performed in an order different from that illustrated, and may include performing some operations simultaneously, even though the illustrated embodiments show sequential operations. Although the present disclosure has been described with reference to certain preferred embodiments, it will be understood that various other adaptations and modifications may be made within the spirit and scope of the present disclosure. It is therefore the object of the appended claims to cover all such variations and modifications that fall within the spirit and scope of the present disclosure.

Claims

1. 1. A blockchain-enabled networked computer for forming an accountable distributed computing system with distinct networked computers having access to a permissioned blockchain network, the blockchain-enabled networked computer comprising at least one processor and a memory storing instructions that, when executed by the at least one processor, cause the networked computer to: configuring the processor to compile and execute a smart contract, the smart contract including a set of rules, to (1) add transactions to the permissioned blockchain, the transactions including a log showing message exchanges between the networked computers having access to the permissioned blockchain network; (2) detect malicious behavior of the networked computers in reaching a consensus based on kernel instrumentation of the networked computers; (3) revoke the access of the networked computers to the permissioned blockchain network upon detecting the malicious behavior, or any combination thereof; The networked computer further comprises: A networked computer running a distributed computing program configured to reach consensus with the networked computers having access to the permissioned blockchain network.

2. 10. The networked computer of claim 1, wherein the networked computer is configured to exchange messages with the networked computers that have access to the permissioned blockchain network using a communications protocol independent of a protocol of the permissioned blockchain network.

3. 10. The networked computer of claim 1, wherein the networked computer is configured to exchange messages with the networked computers having access to the permissioned blockchain network using a communication protocol that relies on a protocol of the permissioned blockchain network.

4. 10. The networked computer of claim 1 , wherein the smart contract is configured to detect malicious behavior based on analysis of one or more audit logs generated by the networked computer in response to execution of the smart contract and the corresponding transactions on the permissioned blockchain network.

5. 2. The networked computer of claim 1, wherein the smart contract is configured to detect the malicious behavior when the networked computer communicates different values ​​of a same message to different networked computers that have access to the permissioned blockchain network.

6. 10. The networked computer of claim 1, wherein the networked computer is configured to be at least one of an observer node or an operator node in the permissioned blockchain network.

7. 2. The networked computer of claim 1, wherein the smart contract is deployed on the permissioned blockchain network by distributing at least one of source code of the smart contract or a trusted binary file associated with a compiled smart contract to members of the permissioned blockchain network.

8. 2. The networked computer of claim 1, wherein the smart contract is deployed as part of the kernel instrumentation of the networked computer and invocations of one or more syscall requests are automatically logged by the smart contract for publication on the permissioned blockchain network.

9. 10. The networked computer of claim 8, wherein the smart contract is deployed as part of kernel instrumentation of the networked computer, and malicious modification of user space programs is detected by inspecting the permissioned blockchain network with audit data related to one or more types of system call requests.

10. 2. The networked computer of claim 1, wherein the networked computer is an observer node, the observer node being configured to replicate the blockchain of all permissioned (sub)networks of which the observer node is a member.

11. 11. The networked computer of claim 10, wherein the networked computer has access to multiple permissioned blockchain networks and ensures that a sub-network has at least one observer node in common with another sub-network.

12. 2. The networked computer of claim 1, wherein the networked computer is an operator node, and the operator node provides audit details of its operation by submitting kernel instrumentation data uploaded to the permissioned blockchain network by the deployed smart contracts.

13. 13. The networked computer of claim 12, wherein the operator nodes are configured to execute the smart contracts in the form of trusted binaries and write logs to the permissioned blockchain network.

14. 13. The networked computer of claim 12, wherein the operator nodes correspond to physical terminals configured to enable human interaction, and further wherein the smart contracts are configured to provide permissioned services for an organization.

15. 1. A method for detecting failures in a distributed system having distinct networked computers having access to a permissioned blockchain network, the distinct networked computers coordinating their operations by exchanging messages to reach a consensus, the distinct networked computers including at least one blockchain-enabled networked computer having at least one processor, the at least one processor coupled to stored instructions implementing the method, the instructions, when executed by the processor, performing steps of the method, the steps including: The method includes the steps of: compiling and executing a smart contract common to all of the networked computers having access to the permissioned blockchain network to detect failures, the smart contract being configured to: (1) add transactions to the permissioned blockchain network, the smart contract including a log showing message exchanges between the networked computers having access to the permissioned blockchain network; (2) detect malicious behavior of the at least one networked computer in reaching consensus; and (3) revoke the access to the permissioned blockchain network of the at least one networked computer upon detecting the malicious behavior, the steps further including:

20. The method of claim 19, further comprising: executing a distributed computing program configured to reach a consensus with the networked computers having access to the permissioned blockchain network.

16. 16. The method of claim 15, wherein the smart contract is configured to detect malicious behavior by analyzing logs of the transactions of the permissioned blockchain network.

17. 16. The method of claim 15, wherein the smart contract is configured to detect the malicious behavior when the at least one networked computer communicates different values ​​of a same message to different networked computers having access to the permissioned blockchain network.

18. 16. The method of claim 15, wherein the smart contract is deployed as part of kernel instrumentation of the at least one networked computer, and invocations of one or more syscall requests are automatically logged by the smart contract for eventual publication on the permissioned blockchain network.

19. 20. The method of claim 18, wherein the smart contract is deployed as part of kernel instrumentation of the at least one networked computer, and malicious modification of user space programs is detected by inspecting the permissioned blockchain network with audit data related to one or more types of system call requests.

20. 1. A non-transitory computer-readable storage medium containing a program for performing a method for detecting failures in a distributed system having distinct networked computers having access to a permissioned blockchain network, the program being executable by a processor, the distinct networked computers coordinating their operations by exchanging messages to reach a consensus, the distinct networked computers including at least one blockchain-enabled networked computer implementing the method, the method comprising: and compiling and executing a smart contract common to all of the networked computers having access to the permissioned blockchain network to detect failures, the smart contract being configured to: (1) add transactions to the permissioned blockchain network, the smart contract including a log showing message exchanges between the networked computers having access to the permissioned blockchain network; (2) detect malicious behavior of the at least one networked computer in reaching consensus; and (3) revoke the access to the permissioned blockchain network of the at least one networked computer upon detecting the malicious behavior, the method further comprising: A non-transitory computer-readable storage medium comprising: a network that is configured to communicate with the networked computers having access to the permissioned blockchain network;

Images