Blockchain-enabled networked computer, fault detection method in distributed system, and non-transitory computer readable storage medium

Abstract

A method and system for fault detection and fault removal in a distributed computing system implemented as a permissioned blockchain network is disclosed. The fault detection method includes the steps of compiling and executing a smart contract common to all nodes of the permissioned blockchain network. The smart contract is configured to perform at least one of a series of operations including: (1) appending transactions including a log indicating message exchanges between nodes of the permissioned blockchain network, (2) detecting malicious behavior of a node upon consensus, and (3) revoking access of the node upon detection of the malicious behavior. Further, upon detection of the malicious behavior (and corresponding malicious node), consensus is reached among the networked computers of the permissioned blockchain network by executing a distributed computing program.

Description

Technical Field

[0001] This disclosure generally relates to distributed computing systems, and more specifically, to methods and systems for detecting and removing faults in blockchain-based accountable distributed computing systems. Background Technology

[0002] A distributed computing system is a networked group of computers distributed across geographically disparate locations. Components of a distributed computing system can include multiple nodes, each a single networked computer, and these nodes communicate with each other through message exchange to achieve common goals, such as performing computations (e.g., ATM transactions). In some scenarios, for a distributed computing system to perform any critical computations, the components must reach consensus. This, in turn, relies on two important characteristics within a distributed computing system: trust between components and robustness to component failures. Components need to trust that other components are not acting maliciously. Without trust, a distributed computing system cannot reach consensus or perform critical computations. In such a situation, at best, a component might discard suspicious messages or encounter recoverable errors from malicious input; at worst, a component might fail due to malicious input from a trusted component that has acted maliciously.

[0003] Similarly, distributed computing systems must be robust to their components because they contain a greater number of components than centralized systems. This need for trust in distributed computing systems is a source of vulnerability that many malicious actors attempt to exploit.

[0004] A known solution for ensuring that a distributed system (such as the distributed computing system discussed above) tolerates the failure of a malicious actor or component and ensures the progress of computation in the distributed system in the presence of such a malicious actor or component is known to those skilled in the art as Byzantine Fault Tolerance (BFT). While the BFT approach aims to make distributed systems more resilient to Byzantine failures, another way to increase the robustness of a distributed system is to remove the component that caused the Byzantine failure. This is known as accountability, and it is a property of distributed systems that enables the detection, identification, and isolation of malicious actors within the distributed system. Accountability provides additional advantages, such as assigning undeniable responsibility to the participants of the distributed system, especially when one of the participants is a malicious actor, and further enhances transparency within the system. Accountability also relies on the auditability of the system, and in solutions known in the art, addressing the problem of malicious actors in the system and ensuring accountability involves considerable complexity and incurs high computational costs.

[0005] Accountability includes the following three characteristics: Fault prevention: Deter malicious behavior by increasing the cost of malicious actions.

[0006] Fault tolerance: The detection and isolation of faults and the prevention of their spread to other parts of the system.

[0007] Fault removal: Removing misbehaving actors from the system to limit their impact on the rest of the system.

[0008] To achieve accountability, the actions of each participant must be auditable. System auditability requires security, tamper resistance, tamper evidentiary protection, and transparent audit logs (also interchangeably referred to as secure logging), as well as the ability to observe processes within components. While the stringent requirements of audit logs are designed to increase trust within them, many existing solutions rely on a centralized approach to the storage and access of these logs. This is a drawback because it shifts the trust issue from the audit logs themselves to the administrator of those logs. Some existing technological approaches to ensuring secure logging involve using a digital ledger to protect and store audit data such as audit logs. In this way, audit data is transparent to members and protected by components of the distributed computing system itself.

[0009] A digital ledger is a record of transactions stored in a computer. Transactions represent changes in the state of a system. Therefore, a digital ledger represents the state of a system such as a financial system or a distributed system in general. A digital ledger can be implemented in a centralized system that stores and modifies all transactions without requiring another system to agree on its own record and without creating an auditable trace of changes made by the centralized system. Another approach is a decentralized or distributed approach that allows for the storage of transaction records and the implementation of a method for determining consensus among multiple systems. This is useful because it deters any particular system, including distributed systems, from operating selfishly and altering the ledger in ways that harm the distributed system. This in itself increases user trust in distributed computing systems and can be useful for that reason.

[0010] An example of digital ledger technology is a blockchain network. A blockchain is an append-only data structure consisting of blocks linked together using a linked list structure or a similar structure. A block is a container for digital information, including a header, metadata, and a list of transactions. The header and metadata may contain information such as the software version, a cryptographic hash used to compress the amount of data needed for storage, and timestamps. A transaction is a list of all transactions involving digital tokens and can potentially be hashed to reduce the amount of data required for storage. A block lists all transactions from one user to another. Transactions between users are facilitated through transactions between the users' corresponding digital addresses.

[0011] The blockchain data structure allows a distributed system, including nodes in a blockchain network, to act as a single computer, thus enabling decentralized computing. Since computations within centralized systems are rarely recorded and audited, recording the results of decentralized computing on the blockchain as blockchain transactions increases trust in the computation. Computer programs that describe decentralized computing in the context of blockchain are called smart contracts.

[0012] In the context of blockchain networks, smart contracts can be defined as executable computer programs that define a set of rules, data, and relationships that must be enforced when the smart contract is executed. Smart contracts are immutable; once added to the distributed ledger architecture of the blockchain network in which they are defined, they cannot be manipulated. Furthermore, invocation of a smart contract by a node on the blockchain network results in transactions recorded on the blockchain network. In some implementations, a set of related smart contracts is called chain code, which is used to deploy related smart contracts on the blockchain network.

[0013] An example of a blockchain network is the Bitcoin network. When compared to centralized networks, blockchain networks known in the art suffer from higher latency, lower throughput, and higher computational costs associated with the auditing of computations performed by various nodes.

[0014] Another example of a blockchain network is a permissioned blockchain network (also interchangeably referred to below as a permissioned blockchain), which requires checking the access rights of individual nodes that wish to become part of the permissioned blockchain network. Permissioned blockchain networks typically contain a control layer that runs on top of the blockchain network. Participants can be easily removed from the network by simply revoking their permissions. In a permissioned blockchain network, smart contracts must be approved by all members of the network. Therefore, smart contracts act as trusted network services within the permissioned blockchain network and can be used as a tool to ensure the fault tolerance and remediation capabilities of nodes within the network. A node can include a networked computer, which may include all the capabilities of a full-featured computing system. These capabilities, in particular, include a fully operational general-purpose operating system.

[0015] Modern general-purpose operating systems are monolithic kernels, which provide a high-level virtual interface called system calls (syscalls) as an application programming interface (API) on top of the underlying computer hardware. Monolithic kernels serve a dual purpose: to free programmers from worrying about the low-level details of the underlying hardware, and to provide security to the computing system by ensuring that processes running on top of the kernel do not interfere with other processes or the kernel itself. Processes running on top of the kernel form user space and include a portion of memory allocated for running applications and libraries, as well as access to the kernel via system calls. On the other hand, kernels such as monolithic kernels reside in a portion of memory called kernel space. In addition to providing system calls, modern kernels also provide users with mechanisms for incorporating performance profiling and event logging, or enabling observability within the kernel, in the form of an API called kernel instrumentation. Examples of monolithic kernels include major operating systems such as Linux® and OpenBSD®. The capabilities of monolithic kernels in providing a secure and trusted environment for program execution, and in providing restricted or privileged access to system resources via system calls, have not been fully explored, especially in the context of distributed computing systems.

[0016] To date, there is no way to introduce accountability in distributed computing systems without requiring some nodes to have elevated privileges within the network, and without a trusted node responsible for logging and monitoring audit data from participants or nodes in the distributed computing system (which again moves the entire system towards a centralized framework). Moreover, the accountability problem still exists even with nodes having elevated privileges solely responsible for maintaining trust within the network. The accountability problem is also part of non-repudiation. Each node in a distributed computing system needs to be uniquely identifiable in order to be accountable, trustworthy, and have non-repudiable responsibility for its actions.

[0017] Therefore, there is a need for an efficient system that controls the operation of nodes or systems in an optimal and feasible manner to provide enhanced security, auditability, accountability, and trust in distributed computing system architectures. Summary of the Invention

[0018] One aim of some implementations is to provide a robust and fault-tolerant distributed computing system that also ensures accountability, trust, and auditability of transactions and individual participants.

[0019] Therefore, some embodiments of this disclosure are based on the considerations of auditing data, access control, and the advantages of a decentralized architecture in terms of secure records, tamper resistance, and verifiability provided by permissioned blockchain networks. Furthermore, the various embodiments disclosed herein leverage the advantages of smart contracts in identifying, isolating, and preventing malicious actors from threatening the integrity of the overall distributed computing system, and the use of a permissioned blockchain architecture enables the revocation of privileges (such as read and write privileges) of malicious actors to achieve fault removal. Some embodiments also utilize kernel-level instrumentation through the use of system calls to further uniquely identify malicious nodes and provide better transparency and auditability of the overall system.

[0020] Some implementations provide a blockchain-based approach to bring accountability into a distributed computing system without requiring any elevated network privileges on some nodes of the system, by enabling the identification, fault detection, and removal of malicious actors in the distributed computing system.

[0021] Various implementations provide systems and methods based on three components: (1) using smart contracts as trusted network services, (2) using participant categorization, and (3) authorizing participants within a distributed computing system via permissioned blockchain networks.

[0022] Some implementations are based on the principle that smart contracts in a permissioned blockchain network must be shared as source code among participants, and are therefore trusted services within the network, where nodes do not require elevated network privileges. Because of this trust, smart contracts can be used as a mechanism to record audit data for publication on a permissioned blockchain network trusted by all participants. Audit data for each participant is obtained through kernel-level instrumentation provided by an API that allows users to observe and record processes and data structures within the kernel. This aids in fault prevention, as the recording and publication of audit data trusted by all participants increases the cost of malicious behavior.

[0023] Some implementations are based on the principle that, in a blockchain system, each transaction must be signed with a private key belonging to a participant. Beyond the design decisions of using a permissioned blockchain framework, this can also be used to satisfy fault tolerance characteristics, since participants in a permissioned blockchain network must have their identities recorded in the system; this enables undeniable accountability for misconduct. Finally, fault removal in a permissioned blockchain system is straightforward, as nodes can be easily removed by revoking their permission to participate in the blockchain network (such as a permissioned blockchain network) if they violate the rules or act maliciously.

[0024] Some implementations are based on the understanding that using permissioned blockchain networks to audit node operations and as a permission control framework for nodes within a distributed system greatly increases both the trust and robustness of the distributed system, which would be impossible if computation were performed on top of the blockchain network.

[0025] Some implementations are based on the understanding that publishing a verifiable record of node activity within a distributed computing system is less computationally intensive than performing repetitive computations on every node within a blockchain network. Therefore, the systems and methods disclosed herein offer significant savings in computational cost and enhanced efficiency, enabling the provision of robust, accountable, secure, and trustworthy distributed computing systems.

[0026] According to some embodiments, a system and method are provided for implementing a distributed computing system with fault detection and remediation capabilities. The distributed computing system includes at least one blockchain-enabled networked computer that communicates with one or more different networked computers via a permissioned blockchain network. The blockchain-enabled networked computer includes general-purpose system components including at least one processor, memory, an operating system stored in the memory, and one or more instructions stored in the memory that can be executed by the at least one processor to perform various operations. The memory can be partitioned into kernel space and user space. The memory may also store instructions that, when executed by the at least one processor, cause the blockchain-enabled networked computer to compile and execute smart contracts. The smart contracts may be computer programs shared by all networked computers that are part of a permissioned blockchain network. Smart contracts include a set of rules used to define a series of operations, which include at least one or a combination of the following: attaching a transaction to a permissioned blockchain network, wherein the transaction includes a log instructing the exchange of messages between networked computers accessing the permissioned blockchain network; detecting malicious behavior by networked computers enabling the blockchain when consensus is reached with other participants in the permissioned blockchain network; and revoking a networked computer's access to the permissioned blockchain network when malicious behavior is detected. The detection of malicious behavior is based on kernel instrumentation of the networked computers enabling the blockchain, which are enabled by the smart contract. Furthermore, once the smart contract has been compiled and executed, a distributed program is executed to reach consensus with other networked computers accessing the permissioned blockchain network.

[0027] Some implementations are based on the understanding that different networked computers participating in a permissioned blockchain network can be categorized into at least one of two types of participants: (1) observers and (2) operators. Observers are participants or nodes in a permissioned blockchain network who may need to run at least one blockchain node to replicate the blockchain containing audit data from participants in a particular (sub)network. Observers participate in the consensus process by proposing one or more transactions for the permissioned blockchain network. The other type of node is the operator node, which actively participates in the consensus process by making transactions.

[0028] Some implementations are based on the understanding that smart contracts are configured to detect malicious behavior of nodes in a permissioned blockchain network based on the analysis of one or more audit logs, which are generated by a networked computer enabling the blockchain in response to the execution of the smart contract and the corresponding transactions on the permissioned blockchain network.

[0029] Some implementations are based on the premise that malicious behavior occurs when a networked computer enabling the blockchain attempts to send different values ​​of messages to different nodes or networked computers connected to a permissioned blockchain network.

[0030] Some implementations are based on the idea that smart contracts can be distributed to nodes of a permissioned blockchain network in the form of at least one of source code files or trusted binary files.

[0031] One implementation aims to deploy smart contracts as part of kernel instrumentation activities that execute on networked computers enabling blockchain. Kernel instrumentation is performed by logging the results of audits executed by different types of system call requests using smart contracts, and then publishing that log on the permissioned blockchain network. Malicious actors on the permissioned blockchain network are identified and isolated when the logs indicate malicious modifications to user-space programs identified by examining audit data associated with one or more types of system call requests.

[0032] Furthermore, in some implementations, malicious actors are removed from the permissioned blockchain network by revoking all permissions associated with them. Attached Figure Description

[0033] Figure 1A A block diagram illustrating the architecture of a permissioned blockchain system for fault detection and removal is shown, according to some embodiments of the present disclosure.

[0034] Figure 1B Block diagrams illustrating permissioned blockchain systems including different types of nodes according to some embodiments of this disclosure are provided.

[0035] Figure 1C A block diagram illustrating a permissioned blockchain system including lightweight client nodes according to some embodiments of this disclosure is shown.

[0036] Figure 1D A block diagram illustrating a permissioned blockchain system including smart contracts according to some embodiments of this disclosure is shown.

[0037] Figure 2A A block diagram illustrating the separation between user space and kernel space is shown according to some embodiments of this disclosure.

[0038] Figure 2B Examples of some embodiments according to this disclosure are shown. Figure 2A Detailed block diagrams of the components in the user space and kernel space are shown.

[0039] Figure 2CDetailed block diagrams illustrating instrumentation technology used for auditing kernel space data are shown, according to some embodiments of this disclosure.

[0040] Figure 3 A high-level block diagram of a permissioned blockchain system according to some embodiments of this disclosure is illustrated.

[0041] Figure 4 A high-level block diagram illustrating an organized blockchain system according to some embodiments of this disclosure is shown.

[0042] Figure 5 Detailed block diagrams illustrating different nodes in a permissioned blockchain system according to some embodiments of this disclosure are shown.

[0043] Figure 6 Detailed block diagrams illustrating different nodes in a permissioned blockchain system according to some embodiments of this disclosure are shown.

[0044] Figure 7 A flowchart illustrating a fault detection and reversal method in a licensed blockchain system according to some embodiments of the present disclosure is provided.

[0045] Figure 8 An environment for detecting and removing faults in a distributed computing system, according to some embodiments of the present disclosure, is illustrated. Detailed Implementation

[0046] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of this disclosure. However, those skilled in the art will understand that this disclosure can be practiced without requiring these specific details. In other instances, apparatus and methods are shown in block diagram form to avoid obscuring the disclosure.

[0047] The terms “for example,” “e.g.,” and “such as,” as well as the verbs “comprising,” “having,” “including,” and other verb forms thereof, as used in this specification and claims, when used in conjunction with a list of one or more components or other items, are to be construed as open-ended, meaning that the list is not considered to exclude other additional components or items. The term “based on” means at least partially based on. Furthermore, it should be understood that the language and terminology used herein are for descriptive purposes and should not be construed as limiting. Any headings used in this specification are merely for convenience and have no legal or restrictive effect.

[0048] Figure 1AA block diagram illustrating the architecture of a permissioned blockchain system 100 for fault detection and remediation, according to some embodiments of the present disclosure, is shown. System 100 includes one or more blockchain networks, such as blockchain network 112 and blockchain network 120. System 100 also includes multiple nodes, such as node 114, node 116, node 118, and node 122. Nodes 114, 118, and 122 are associated with blockchain network 120. Node 116 is associated with and is part of blockchain network 112. Each of the multiple nodes can be a networked computer. Furthermore, each of the networked computers can be a blockchain-enabled networked computer.

[0049] like Figure 1A As illustrated, a node can be part of more than one network. For example, node 114 is part of both blockchain network 112 and blockchain network 120. Those skilled in the art will understand that networks 112 and 120 are shown as blockchain networks only for the purposes of the specific embodiments described herein. The term "blockchain" refers to a network architecture that implements a distributed computing network with decentralized control over operations and transactions within and involving the distributed computing network. Therefore, nodes 114, 116, 118, and 122 can be nodes of such a distributed computing network (one particular type of which is a blockchain network) with all its enabling technologies. Furthermore, in some embodiments, the blockchain network is a permissioned blockchain network with an access layer on top of the blockchain layer, which defines various permissions available to different nodes that are part of the permissioned blockchain network.

[0050] Permissioned blockchain network architectures offer numerous advantages, such as providing a secure logging facility for audit logs associated with nodes on the network through the use of a separate blockchain backbone, and providing a trust-based and secure distributed computing architecture. Furthermore, permissioned blockchain architectures offer fault tolerance, fault prevention, and fault removal capabilities, making them a highly accountable architecture for implementing distributed (decentralized) computing systems.

[0051] Nodes in the permissioned blockchain system 100 can be referred to as participants in the system and can be divided into two broad categories: observers and operators. Additionally, the permissioned blockchain system 100 may also have ordering nodes and lightweight clients, as discussed below in the descriptions of the various implementations provided herein.

[0052] Observers are nodes that do not create transactions, but are responsible for detecting, identifying, and removing malicious participants in the system. Observers also contribute to consensus in the Permissioned Blockchain System 100 and can replicate the main blockchain of the Permissioned Blockchain System 100, through which observers audit the participants of the Permissioned Blockchain System 100. Figure 1A In this context, node 114 is an observer node that operates as a single node within two blockchain sub-networks, 112 and 120. Observers increase the fault tolerance of the permissioned blockchain system 100 by detecting faults in the permissioned blockchain system 100 and by identifying malicious actors in the permissioned blockchain system 100.

[0053] Other types of nodes in the permissioned blockchain system 100 are operators. Operators are nodes that construct transactions included in a blockchain system such as the permissioned blockchain system 100. Operator nodes need to prove their trustworthiness by recording their operations on the permissioned blockchain system 100 for public auditing through smart contracts. Operators also increase the fault tolerance of the permissioned blockchain system 100 by reporting their audit data to the permissioned blockchain system 100. (See also...) Figure 1A Nodes 116, 118, and 122 are operator nodes connected to blockchain (sub)networks 112 and 120.

[0054] In some implementations, the permissioned blockchain system 100 may include a distributed system in which participants who do not fully trust each other can trust and participate. An example is an intra-organizational network comprised of a company and its affiliates, which... Figure 1B Further examples are provided below.

[0055] Figure 1B A block diagram illustrating a permissioned blockchain system 126 comprising different types of nodes according to some embodiments of the present disclosure is shown. The permissioned blockchain system 126 includes multiple participants (or nodes) belonging to an organization (also referred to as "organization 138") represented by bounding box 138. Furthermore, bounding box 136 (also referred to as "parent organization 136") represents a parent organization consisting of two nodes: an observer node 124 and a regular or operator node 128 that submits audit data to the permissioned blockchain system 126. Nodes 124 and 128 are able to communicate with each other because they are both within the parent organization 136. Organization 138 also includes a subordinate organization 134 consisting of two nodes 130 and 132, whose operations are audited and submitted to the permissioned blockchain system 126. Figure 1B Only examples are shown for use Figure 1AThis is one type of enabling environment for the permissioned blockchain system 100. Another enabling example (not shown in the figure) includes real-time and automated auditing of a subset of participants in the permissioned blockchain system 100 who can be trusted by all participants. Each participant in the permissioned blockchain system 100 can be one of the four types described above: such as observers, operators, orderers, and lightweight clients mentioned earlier. The preceding has already combined... Figure 1A It describes the operator and the observer. In Figure 1C The lightweight client is described in the following description.

[0056] Figure 1C A block diagram illustrating a permissioned blockchain system 140 including lightweight client nodes according to some embodiments of the present disclosure is shown. The permissioned blockchain system 140 includes two lightweight client nodes, such as lightweight client 142 and lightweight client 144. Lightweight client 144 also includes an embedded device 146.

[0057] Lightweight clients 142 and 144 can include any modern computer, such as embedded computers, laptops, mobile phones, smartphones, tablets, smartwatches, wearable computers, point-of-sale (POS) terminals, kiosks, routing devices, monitoring terminals at power plants, electronic watches, etc. Some implementations are based on the fact that many modern computers are embedded devices with limited computing power, such as the lightweight client 144 associated with embedded device 146, which prevents them from storing a complete copy of the blockchain to which they are part. However, using the implementation and architecture of permissioned blockchain system 140, even these lightweight systems with low computing power can monitor any malicious activity completely reliably, securely, and efficiently. This is made possible by the combination of kernel instrumentation techniques and smart contracts implemented in the permissioned blockchain system 100 (or equivalently, permissioned blockchain system 140) disclosed in the various implementations described herein.

[0058] Figure 1DA block diagram illustrating a permissioned blockchain system including a smart contract 152 according to some embodiments of the present disclosure is shown. The permissioned blockchain system includes a node 150, which may be a networked computer enabling the blockchain and capable of communicating with other networked computers (not shown). Node 150 may be configured to compile and execute the smart contract 152 as part of an audit procedure for node 150. The smart contract 152 may be associated with process 154. The smart contract 152 may be configured to detect malicious activity associated with node 150 based on analysis of one or more audit logs generated by node 150 in response to the execution of the smart contract 152 and corresponding transactions on the permissioned blockchain network 148.

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

[0060] Various implementations enable the deployment of smart contract 152 on permissioned blockchain network 148 by distributing the source code of smart contract 152 or a trusted binary file associated with the compiled smart contract 152 to members of the permissioned blockchain network 148, such as node 150. When the source code of smart contract 152 is distributed to all nodes of the permissioned blockchain network 148, each node can then locally compile smart contract 152. This ensures that the smart contract acts as a trusted, transparent, tamper-proof, and robust tool for ensuring the fault tolerance of the permissioned blockchain network 148. This is because smart contract 152 itself is immutable, so any malicious behavior associated with deviations from the acceptable rules, permissions, or operations permitted on the permissioned blockchain network 148 occurs at a lower level (such as at the kernel level), significantly increasing its cost.

[0061] Furthermore, a smart contract 152 associated with process 154 can be used to audit process 154 by defining a set of rules that define the acceptable data types, operations, dependencies, and encapsulation information of the data associated with process 154. Therefore, each invocation of process 154 can also invoke the execution of smart contract 152 and its corresponding rules. Any deviation from the rules can be identified by executing instrumentation at the kernel level of node 150 and recorded on the permissioned blockchain network 148. Auditing this recorded information detects attempts at malicious behavior concerning node 150. Therefore, node 150 is identified and isolated, and furthermore, the permission associated with node 150 can be revoked to completely remove the malicious node from the permissioned blockchain network 148.

[0062] In some implementations, smart contract 152 includes rules for network-based policy enforcement, which define the appropriate configuration of nodes by triggering local events. Responses to these triggers are recorded on the blockchain based on the rules specified in smart contract 152.

[0063] Therefore, node 150 can be at least one operator node or observer node (wherein the functions of operator nodes and observer nodes have been discussed previously). When node 150 is an observer node, node 150 can be configured to replicate the blockchain of all permissioned (sub)networks where the observer node is a member. Node 150 can be part of one or more permissioned blockchain (sub)networks, as described above. Figure 1A As disclosed. When node 150 is part of more than one permissioned blockchain (sub) network, each of these permissioned blockchain (sub) networks has at least one public observer node with another sub-network.

[0064] In some implementations, node 150 is configured as an operator node to provide audit details of its operations by submitting kernel instrumentation data of the node (in response to the execution of its smart contract 152), which is uploaded to the permissioned blockchain network 148 via the deployed smart contract 152.

[0065] In some implementations, when node 150 is configured as an operator node, node 150 is also associated with a physical terminal configured to allow human interaction, and further, in this node, smart contract 152 is configured to grant permissions as a human operator of the organization. This will... Figure 6 This is discussed in detail in the description of its related aspects.

[0066] Various implementations also provide that 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 is performed sequentially according to a distributed computing procedure commonly referred to as a consensus algorithm to reach a consensus among all nodes in the permissioned blockchain network 148 regarding the current state of the permissioned blockchain network 148. An example of a consensus algorithm that can be used by the permissioned blockchain network 148 to reach consensus is the Practical Byzantine Fault Tolerance (PBFT) algorithm, in which nodes are configured to receive confirmations from all other nodes in the permissioned blockchain network 148 regarding the validity of the node's transactions. Consensus is then reached based on the total number of confirmations received from the nodes.

[0067] Some of the implementation methods disclosed herein are based on the understanding that observer nodes help reach consensus by proposing transactions for all nodes in the permissioned blockchain network 148. Moreover, the transactions proposed by the observer nodes are audited on the permissioned blockchain network 148 and the audit results are recorded in accordance with a set of public rules specified in smart contracts (such as smart contract 152).

[0068] Various implementations provide the option to store smart contract 152 on node 150 as part of the node's application space and also as part of the kernel instrumentation of node 150. This will combine Figures 2A to 2C Further detailed discussion.

[0069] Figure 2A A block diagram illustrating the separation between kernel space 202 and user space 200 associated with node 150 is shown according to some embodiments of the present disclosure.

[0070] User space 200 includes a portion of the memory of node 150 (which is a computing component with memory and a processor) that stores user programs, such as applications, application data, APIs, software or code libraries, stored procedures, algorithms, computer instructions, user files, etc. User programs in user space 200 are typically written in any of the known high-level languages, such as C#, C++, Java, Python, Solidity, JavaScript, etc. User space 200 also includes various processes that define algorithms and logical instructions for performing one or more functions, such as business processes or network interface processes. These functions are dedicated. One type of user program in user space 200 is a smart contract 204 (which is equivalent to...). Figure 1D (Smart contract 152 shown). Smart contract 204 defines enforceable rules that are executed when smart contract 204 is executed. Execution of smart contract 204 may instruct one or more processes 206 that require access to system (operating system) resources. System resources 210 are stored in a separate portion of memory, separate from user space 200, referred to as kernel space 202.

[0071] Kernel space 202 defines a portion of memory where the core of node 150 is stored in the form of the operating system and its associated programs. Kernel space 202 stores specialized programs that enable interfacing with various system resources, such as hardware and file systems. Kernel space 202 can include specialized programs and data, such as device drivers, memory managers, I / O managers, process managers, etc. Typically, kernel space programs are written in low-level languages ​​such as C.

[0072] System resources 210 contained in kernel space 202 can be accessed from processes in user space 200 through dedicated requests sent to kernel space 202 using system calls or syscalls. Each resource access requires a separate system call. Furthermore, each system call and its associated system resources can be monitored using a specialized technique known as kernel-level instrumentation. Kernel-level instrumentation enables code observability, performance metric collection, and tracking of security-related events, among other things. This combines... Figure 2A and Figure 2B Let's discuss this in more detail.

[0073] Figure 2B Examples are shown Figure 2A Detailed block diagrams of the components of the illustrated user space 200 and kernel space 202.

[0074] As from Figure 2B It can be seen that any process 206 in user space 200 can only access system resources 210 stored in kernel space 202 through one or more system calls.

[0075] The various implementations described herein provide auditing of system calls based on rules specified in smart contract 204, which is associated with the permissioned block system 212 (which is equivalent to the previous one). Figures 1A to 1D The deployed smart contracts associated with the permissioned blockchain system described herein. Auditing of system calls is accomplished using any of the instrumentation techniques known in the art. Figure 2B and Figure 2C Some known instrumentation techniques 208, which are considered for exemplary purposes in the various embodiments described herein, are depicted.

[0076] Figure 2C The instrumentation techniques 208 detailed in the diagram include: kernel auditing 214, probe 216, trace point 218, and Berkley packet filter 220. For illustrative purposes, Figure 2C Only four instrumentation techniques 208 are described. Any number of instrumentation techniques may be added to the list of instrumentation techniques 208 without departing from the scope of this disclosure.

[0077] Kernel Auditing 214 includes an auditing subsystem, a pre-configured rules-based framework for system auditing and security functions. The Kernel Auditing 214 subsystem is configured to capture a wide range of system events and their associated metadata (including, but not limited to, file system auditing, system call auditing, trusted database access), attempt import / export functions, and other predefined events. This subsystem includes: 1) kernel components for generating audit logs, 2) a user-space daemon for logging audit logs to local files or external servers, and 3) a set of user-space tools for inspecting and processing the audit logs.

[0078] Detector 216 is a dynamic instrumentation enabler, in which the kernel modifies assembly-level code in kernel space (kprobe) or user space (uprobe) at runtime by attaching breakpoints and handler functions. The detector is configured to record the state of the operating system of node 150 and its processes.

[0079] Trace point 218 includes a system for observing instrumentation, where an exception branch (hook) that calls a function that can be specified at runtime is inserted into a critical location within the code. When a specific code path is reached, trace point 218 is activated, and the corresponding kernel API exposes some predefined events.

[0080] Berkley Packet Filter (BPF) 220 is a set of technologies for system-level instrumentation. The implementation of BPF requires three key components: 1) an in-kernel virtual machine, whose own virtual instruction set is called BPF bytecode; 2) a kernel runtime, which consists of an interpreter, a BPF program security verifier, and a just-in-time (JIT) compiler for translating BPF bytecode into native instructions; and 3) a custom key-value data structure called the BPF map, used for data sharing between kernel space 202 and user space 200. BPF helps monitor kernel module loading, process crashes, page faults, pseudo-uses, SSH authentication, password initialization, shell commands, and more.

[0081] The various instrumentation techniques 208 disclosed herein enable the auditing of one or more system calls, allowing smart contracts 204 to automatically record calls to one or more types of system call requests for publication on a permissioned blockchain network 212.

[0082] Therefore, smart contract 204 is deployed as part of the kernel instrumentation of node 150 (using any of the kernel instrumentation techniques 208 described above), wherein malicious modifications to the program in user space 200 can be detected by inspecting a permissioned blockchain network 212 containing audit data associated with one or more types of system call requests.

[0083] Based on the examination of the submitted audit data, if node 150 is identified as malicious, its permission to access the permissioned blockchain network 212 can be revoked. Therefore, the use of the permissioned blockchain network 212 architecture, smart contract 204, and kernel instrumentation technology 208 in the manner described above enables fault detection, fault removal, and security logging facilities, making the overall system associated with node 150 and the permissioned blockchain network 212 highly accountable.

[0084] Figure 3 A high-level block diagram of a permissioned blockchain system according to some embodiments of this disclosure is illustrated. The 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.

[0085] The underlying participant node 304 is one or more networked computers that enable the blockchain. Each node in participant node 304 can be part of one or more blockchain (sub)networks. Moreover, each node in participant node 304 can be one of four types of nodes, such as observer, operator, orderer, and lightweight client. Crucially, participant node 304 is categorized into operators and observers.

[0086] Observers correspond to a class of participant nodes 304 that do not have processes requiring auditing, and therefore they do not create transactions that need to be added to the permissioned blockchain network 300. Instead, observers run nodes to replicate the blockchain for auditing participants in the replicated blockchain network. Observer nodes perform functions, including but not limited to, increasing the redundancy and security of the permissioned blockchain network 300 through auditing, detecting and removing malicious participants from the permissioned blockchain network 300, and running a sorting service to attach to the blockchain based on transactions provided by smart contract 302. Observer nodes provide advantages such as increasing the overall fault tolerance of the permissioned blockchain network 300 and also increasing the overall fault prevention capabilities of the permissioned blockchain network 300, because observer nodes are also configured to remove malicious participants from the permissioned blockchain network 300 by revoking their access privileges.

[0087] Another major category of nodes in the permissioned blockchain network 300 is operators. Operators are nodes with processes that require auditing. This is achieved by recording the actions of operator nodes on the permissioned blockchain network 300 based on the rules specified in smart contract 302. Furthermore, as... Figure 2CThe described method uses kernel instrumentation technology 208 to audit the operations of the operator node.

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

[0089] The various implementations disclosed herein provide permission management functionality for all nodes on the permissioned blockchain network 300. This permission management functionality includes at least one process-related permission, node-related permission, and human-machine interface-related permission, or a combination thereof.

[0090] Process-related permissions include using kernel instrumentation technology 208 to identify whether a process within the kernel has the appropriate permissions to access system resources. This is combined with... Figure 2B An overview has been provided. This is achieved through any of the kernel instrumentation techniques 208 described earlier.

[0091] Node-related permissions include checking whether a node is permitted to participate in a distributed computing system such as the Permissioned Blockchain Network 300. This is achieved through the following requirement of the blockchain network framework: nodes with sufficient permissions are approved by all participants, while nodes lacking sufficient permissions are not allowed to participate. Furthermore, node-related permissions are recorded in multiple network profiles available to nodes within the Permissioned Blockchain Network 300.

[0092] Human-machine interface (HMI) related permissions include permissions associated with human operators who interface with nodes via physical interface terminals. This is necessary in scenarios where the computing device or networked computer associated with the permissioned blockchain network 300 is trusted, but shared among multiple human operators who may not all be trusted. Therefore, HMI related permissions ensure that permissions assigned to human operators interacting with the networked computer do not depend on the networked computer's settings and can be changed in real-time by the organization (of which the networked computer or node is part). This can be achieved through the use of a lightweight directory access protocol (LDAP). This will be combined with... Figure 6 Further detailed description.

[0093] The architecture of the permissioned blockchain network 300 can be implemented in several different scenarios, as will be discussed in the following figures and their associated descriptions.

[0094] Figure 4 A high-level block diagram of an organizational blockchain system 400 according to some embodiments of the present disclosure is illustrated. The organizational blockchain system 400 includes a permissioned blockchain network as part of the organizational blockchain system 400, the permissioned blockchain network having a plurality of nodes or networked computers that enable blockchain associated with the organizational blockchain system 400. Figure 4Four such nodes are illustrated: a parent node 404 and its associated sorter service 404a, and one or more child nodes: node 402, node 406, and node 408. Those skilled in the art will understand that the specific 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 this disclosure.

[0095] Parent node 404 can be associated with a parent organization that acts as the orderer node running the orderer service 404a, used to order the audits of other nodes (such as child nodes 402, 406, and 408) associated with the organization's blockchain system 400. The interaction between parent node 404 and the organization's blockchain system 400 can be read-only. Furthermore, parent node 404 can be configured to synchronize a complete copy of the organization's blockchain system 400 by participating in the consensus algorithm associated with the organization's blockchain system 400 through proposing transactions. The consensus algorithm ensures that all nodes of the organization's blockchain system 400 agree on the current state of the organization's blockchain system 400.

[0096] Furthermore, child nodes can be associated with sub-organizations that need to be monitored (such as subsidiaries of the parent organization). Each child node is capable of reading and writing to the organization's blockchain system 400. Nodes 402 and 406 act as operating nodes, configured to receive their auditing processes through a combination of smart contracts and kernel instrumentation techniques described above, and are also configured to actively participate in the consensus algorithm by generating transactions containing audit data.

[0097] In addition, such as Figure 4 For example, when node 408 is a lightweight client device that is not capable of running a full blockchain-enabled node, node 408 can communicate with the organization's blockchain system 400 through node 406.

[0098] The functionality of various nodes and services related to the blockchain framework can be implemented through the use of APIs and code repositories, which is known to those skilled in the art.

[0099] Figure 5Another block diagram illustrating a scenario of different nodes in a permissioned blockchain system 500 according to some embodiments of this disclosure is provided. 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 running a process 506 that requires auditing. Calls to process 506 may further result in calls to chaincode 508 on node 502 and chaincode 512 on node 504. As already discussed, chaincode is a collection or group of associated smart contracts. Transactions of nodes 502 and 504 can then be monitored at the kernel level using any known kernel instrumentation techniques, as already described in the preceding... Figure 2C The document describes several kernel instrumentation techniques. Furthermore, a call to chaincode 508 can lead to a call to chaincode 510, and a call to chaincode 512 can lead to a call to chaincode 514, the results of which can be logged on the permissioned blockchain system 500. Additionally, the results of calls to chaincodes 508 and 512 (in the form of results audited using kernel instrumentation techniques) can be logged on the permissioned blockchain system 500.

[0100] by Figure 5 The illustrated approach allows for cross-chaincode invocation capabilities in the relevant chaincode calls on the permissioned blockchain system 500, which can further automate some of the auditing functions within the auditing functionality enabled by smart contracts and chaincode. Therefore, using... Figure 5 The exemplary implementations discussed may use the permissioned blockchain system 500 to provide fault detection and accountable distributed computing systems in a semi-automated or fully automated manner.

[0101] Figure 6 This diagram illustrates another possible implementation of an accountable and fault-tolerant distributed computing system, showing an example of its use. Figure 3 The brief public disclosure of permissioned blockchain network 300's human interfacing permissions management.

[0102] Figure 6 Detailed block diagrams of different nodes in a permissioned blockchain system 600 for human interaction permission management, according to some embodiments of the present disclosure, are illustrated.

[0103] The permissioned blockchain system 600 can be accessed by a human operator 604, who may be authorized or unauthorized to access the permissioned blockchain system 600. On the other hand, a node 602 can be granted access to the permissioned blockchain system 600. To authenticate the human operator 604 to access the permissioned blockchain system 600, a computing terminal 608 (such as a Raspberry Pi (RPi) enabled terminal shown here for illustrative purposes) can be used to run a credential service 606 such as LDAP. The result of authentication or verification is then logged on the permissioned blockchain system 600. The human operator's permission can be restored or revoked accordingly.

[0104] Therefore, permissioned blockchain systems 600 can be used as accountable distributed systems capable of fault detection, fault prevention, and fault removal with low computational costs and efficient security mechanisms such as smart contracts and kernel instrumentation.

[0105] Figure 7 A flowchart illustrating a method 700 for performing fault detection and fault removal in a permissive permissioned blockchain network, according to some embodiments of the present disclosure, is provided.

[0106] Figure 7 Method 700 includes: in step 702, compiling and executing a smart contract associated with a permissioned blockchain network. For example, refer to... Figure 2B and Figure 2C The permissioned blockchain network 212 can be associated with node 150, which can receive a trusted binary file or source code file associated with smart contract 204. If smart contract 204 is in the form of a source code file, it can be compiled and then executed. In some implementations, smart contract 204 itself is in the form of an executable file and does not need to be compiled. Execution of smart contract 204 results in the implementation of a set of rules specified in smart contract 204. This set of rules can be associated with a series of operations for performing at least one or a combination of the following: (1) appending data to the permissioned blockchain network 212, wherein the transaction includes a log indicating the exchange of messages between networked computers or nodes accessing the permissioned blockchain network 212; (2) detecting malicious behavior of a networked computer (such as node 150) upon reaching consensus, wherein the detection is performed based on the kernel instrumentation of the networked computer; and (3) revoking the networked computer's access to the permissioned blockchain network 212 upon detecting malicious behavior.

[0107] In step 704, audit data for the networked computer (such as node 150) is generated by auditing system calls to node 150 using any of the kernel instrumentation techniques in kernel instrumentation technique 208, thereby completing the detection of malicious behavior. Furthermore, the audit results are stored in the permissioned blockchain network 212 through append-only data operations used for auditing the audit data logs. Once the audit data logs are submitted in this manner, in step 706, any malicious behavior concerning node 150 can be detected, and node 150's permission can be revoked if necessary.

[0108] Figure 7 The described method 700 can be implemented in any distributed computing system to ensure the accountability, fault tolerance, and reliability of the overall distributed computing system.

[0109] Figure 8 An example of a working environment 800 for detecting and removing faults in a distributed computing system according to some embodiments of this disclosure is illustrated. The working environment 800 corresponds to a power plant 804, which can act as a parent node running a sorting service for sorting audits of different entities connected to the power plant 804 via a permissioned blockchain network 802. These different entities may include consumers 808, industrial units 812, and a distribution network 816. Each entity in consumers 808, industrial units 812, and distribution network 816 can be connected to the permissioned blockchain network 802 via a computing system running full nodes or lightweight nodes (such as a blockchain-enabled networked computer). Furthermore, each entity is configured to receive separate copies of its smart contracts from the permissioned blockchain network 802: smart contract 810 for consumer 808, smart contract 814 for industrial unit 812, smart contract 818 for distribution network 816, and smart contract 806 for power plant 804. Each smart contract may take the form of an immutable trusted binary file or source code file. In addition, some implementations are based on the understanding that copies of smart contracts on all nodes can be made available to all nodes.

[0110] In addition, each smart contract specifies rules for monitoring and auditing each of the consumer 808, industrial unit 812, and distribution network 816. For example, the rules may cover the use of power units, metering of power consumption and attempts to tamper with metering units, sanctioning of power units used for industrial consumption, the allowable cap on the number of units distributing power through the grid, and compliance with government and regulatory requirements.

[0111] When implementing the smart contracts 810, 814, and 818, kernel-level instrumentation of the associated computing terminal can be used to audit various types of nodes, and the audit results are recorded on the permissioned blockchain network 802. Furthermore, different nodes can then be configured to reach a consensus on the authenticity of each node, and based on the audit results and consensus, each node can be allowed to restore its connection to the permissioned blockchain network 802 and continue to access the electricity generated by the power plant 804; otherwise, if their connection fails the audit process, their connection can be temporarily disabled.

[0112] Therefore, the various implementations described herein provide secure, tamper-proof, efficient, reliable, and cost-effective accountable distributed computing systems. These implementations provide digital management to make physical (computation) auditable and accountable. Furthermore, the fact that the various technologies described herein can be easily implemented as complete embedded blockchain nodes using lightweight clients makes the overall system efficient, scalable, and cost-effective. Moreover, in many permissioned blockchains, the client is a trusted binary shared among various participating nodes acting as a trusted lightweight blockchain client.

[0113] The above description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of this disclosure. Rather, the above description of the exemplary embodiments will provide those skilled in the art with enabling descriptions for implementing one or more exemplary embodiments. Various changes to the function and arrangement of the elements are contemplated without departing from the spirit and scope of the disclosed subject matter set forth in the appended claims.

[0114] Specific details are set forth in the foregoing description to provide a thorough understanding of the embodiments. However, those skilled in the art will understand that these embodiments can be practiced without these specific details. For example, systems, processes, and other elements of the disclosed subject matter may be shown as components in block diagram form to avoid obscuring these embodiments with unnecessary detail. In other cases, well-known processes, structures, and techniques may be shown without unnecessary detail to avoid obscuring these embodiments. Moreover, the same reference numerals and designations in the various figures denote the same elements.

[0115] Furthermore, each implementation can be described as a process, depicted as a flowchart, block diagram, data flow diagram, structural diagram, or block diagram. Although a flowchart can describe operations as sequential processes, many operations can be executed in parallel or simultaneously. Additionally, the order of operations can be rearranged. A process may terminate upon completion of its operations, but may have additional steps not discussed or included in the diagram. Moreover, not all operations in any particular described process may occur in all implementations. A process may correspond to a method, function, procedure, subroutine, subroutine, etc. When a process corresponds to a function, the termination of that function may correspond to the function returning to the calling function or the main function.

[0116] Furthermore, the implementation of the disclosed subject matter can be carried out at least partially, manually, or automatically. It can be performed, or at least assisted by, manual or automatic implementation using machines, hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, program code or code segments that perform the necessary tasks can be stored in a machine-readable medium. The processor can perform the necessary tasks.

[0117] The various methods or processes outlined herein can be encoded into software that can be executed on one or more processors employing any of a variety of operating systems or platforms. Furthermore, such software can be written using any of a variety of suitable programming languages ​​and / or programming or scripting tools, and can also be compiled into executable machine language code or intermediate code that executes on a framework or virtual machine. In various implementations, the functionality of program modules can typically be combined or distributed as needed.

[0118] The embodiments of this disclosure can be embodied as methods for which examples have been provided. Actions performed as part of the method can be ordered in any suitable manner. Therefore, even though actions are shown as sequential in the exemplary embodiments, embodiments can be constructed that perform actions in a different order than illustrated, which may include performing some actions simultaneously. Although this disclosure has been described with reference to specific preferred embodiments, it is to be understood that various other changes and modifications can be made within the spirit and scope of this disclosure. Therefore, aspects of the appended claims cover all such changes and modifications that fall within the true spirit and scope of this disclosure.

Claims

1. A networked computer for forming a single enabled blockchain in an accountable distributed computing system, the accountable distributed computing system having different networked computers accessing a permissioned blockchain network, the single enabled blockchain networked computer comprising: At least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the single blockchain-enabled networked computer to: The processor compiles and executes a smart contract, wherein the smart contract includes a set of rules that configure the processor to: 1) attach transactions to the permissioned blockchain network, the transactions including logs of message exchanges between a networked computer enabling the single blockchain and different networked computers accessing the permissioned blockchain network; 2) use the logs to detect malicious behavior by the networked computer enabling the single blockchain when consensus is reached with the different networked computers accessing the permissioned blockchain network, wherein the detection is performed based on the kernel instrumentation of the networked computer enabling the single blockchain; and 3) revoke the networked computer enabling the single blockchain from accessing the permissioned blockchain network when the malicious behavior is detected. A distributed computing program is executed, configured to reach the consensus with different networked computers accessing the permissioned blockchain network. The distributed computing program configures the processor to exchange messages with the different networked computers accessing the permissioned blockchain network using a communication protocol independent of the protocol of the permissioned blockchain network. The smart contract is configured to detect malicious behavior when a networked computer enabling the single blockchain sends different values ​​of the same message to different networked computers accessing the permissioned blockchain network.

2. The single networked computer enabling blockchain according to claim 1, wherein, The smart contract is configured to detect malicious activity based on the analysis of one or more audit logs, which are generated by the networked computer of the single enabled blockchain in response to the execution of the smart contract and the corresponding transactions on the permissioned blockchain network.

3. The single networked computer enabling blockchain according to claim 1, wherein, The single networked computer enabling the blockchain is configured as an observer node or operator node within the permissioned blockchain network.

4. The single networked computer enabling blockchain according to claim 1, wherein, The deployment of the smart contract on the permissioned blockchain network occurs by distributing at least one of the source code of the smart contract or a trusted binary file associated with the compiled smart contract to members of the permissioned blockchain network.

5. The single networked computer enabling blockchain according to claim 1, wherein, The smart contract is deployed as part of the kernel instrumentation of the single networked computer that enables the blockchain, such that the smart contract automatically records calls to one or more types of system call requests for publication on the permissioned blockchain network.

6. The single networked computer enabling blockchain according to claim 5, wherein, Malicious alterations to userspace programs are detected by examining the permissioned blockchain network, which contains audit data associated with one or more of the aforementioned types of system call requests.

7. The single networked computer enabling blockchain according to claim 1, wherein, The networked computer that enables the single blockchain is an observer node, which is configured to replicate the blockchain across all permissioned blockchain networks in which the observer node is a member.

8. The single networked computer enabling blockchain according to claim 7, wherein, The networked computer enabling the single blockchain accesses multiple permissioned blockchain networks, including the permissioned blockchain network itself and another permissioned blockchain network, to ensure that the permissioned blockchain network and the other permissioned blockchain network have at least one public observer node.

9. The single networked computer enabling blockchain according to claim 1, wherein, The networked computer enabling the blockchain is an operator node, which is configured to provide audit details of its operations by submitting kernel instrumentation data, which is uploaded to the permissioned blockchain network via a deployed smart contract.

10. The networked computer enabling a single blockchain according to claim 9, wherein, The operator node is configured to run the smart contract in trusted binary form to write the log to the permissioned blockchain network, or the operator node is associated with a physical terminal configured to allow human interaction, and further, the smart contract is configured to enable an organization to provide permissioned services.

11. A method for fault detection in a distributed system having multiple networked computers, said multiple networked computers accessing a permissioned blockchain network and coordinating their actions to reach consensus by exchanging messages with each other, wherein, The plurality of networked computers includes different networked computers and a single blockchain-enabled networked computer, the single blockchain-enabled networked computer including at least one processor, wherein the at least one processor is coupled to stored instructions implementing the method, wherein the instructions, when executed by the processor, perform the steps of the method, the method including the following steps: Compile and execute a smart contract that is common to the plurality of networked computers accessing the permissioned blockchain network for fault detection, wherein the smart contract is configured to: 1) attach a transaction to the permissioned blockchain network, the transaction including a log of message exchanges instructing between the networked computer enabling the single blockchain and the different networked computers accessing the permissioned blockchain network; 2) use the log to detect malicious behavior of the networked computer enabling the single blockchain when consensus is reached with the different networked computers accessing the permissioned blockchain network, wherein the detection is performed based on the kernel instrumentation of the networked computer enabling the single blockchain; and 3) revoke the networked computer enabling the single blockchain from accessing the permissioned blockchain network when the malicious behavior is detected; and A distributed computing program is executed, configured to reach the consensus with different networked computers accessing the permissioned blockchain network. The distributed computing program configures the processor to exchange messages with the different networked computers accessing the permissioned blockchain network using a communication protocol independent of the protocol of the permissioned blockchain network. The smart contract is configured to detect malicious behavior when a networked computer enabling the single blockchain sends different values ​​of the same message to different networked computers accessing the permissioned blockchain network.

12. The method according to claim 11, wherein, The smart contract is deployed as part of the kernel instrumentation of the single networked computer that enables the blockchain, such that the smart contract automatically records calls to one or more types of system call requests for eventual publication on the permissioned blockchain network.

13. The method according to claim 12, wherein, Malicious alterations to userspace programs are detected by examining the permissioned blockchain network, which contains audit data associated with one or more of the aforementioned types of system call requests.

14. A non-transitory computer-readable storage medium having a program executable by a processor, the program being used to perform a method for fault detection in a distributed system having multiple networked computers, the multiple networked computers accessing a permissioned blockchain network and coordinating their actions to reach consensus by exchanging messages with each other, wherein, The plurality of networked computers includes different networked computers and a single networked computer that implements the method, which includes the following operations: Compile and execute a smart contract, which is common to the plurality of networked computers accessing the permissioned blockchain network for fault detection, wherein the smart contract is configured to: 1) attach a transaction to the permissioned blockchain network, the transaction including a log of message exchanges instructing between the networked computer with the single enabled blockchain and the different networked computers accessing the permissioned blockchain network; 2) use the log to detect malicious behavior of the networked computer with the single enabled blockchain when consensus is reached with the different networked computers accessing the permissioned blockchain network, wherein the detection is performed based on the kernel instrumentation of the networked computer with the single enabled blockchain; and 3) revoke the networked computer with the single enabled blockchain from accessing the permissioned blockchain network when the malicious behavior is detected; and A distributed computing program is executed, configured to reach the consensus with different networked computers accessing the permissioned blockchain network. The distributed computing program configures its processor to exchange messages with the different networked computers accessing the permissioned blockchain network using a communication protocol independent of the protocol of the permissioned blockchain network. The smart contract is configured to detect malicious behavior when a networked computer enabling the single blockchain sends different values ​​of the same message to different networked computers accessing the permissioned blockchain network.

Images