Patent Description:
A mesh network is a network topology that includes nodes (i.e. bridges, switches, internet-of-things (IoT) devices, and other infrastructure devices) that are interconnected directly and non-hierarchically to other nodes and interact to communicate within the mesh. The interconnected format of the nodes allows for multiple nodes to participate in the relay of information.

Mesh networks may be formed from multiple types of devices and different devices may provide different services within the mesh network. In some cases, the client devices within the mesh network may be connected in an ad hoc fashion, with communication within the mesh network being provided, in part, in a decentralized fashion. <CIT> discloses a multi-framework managed blockchain service. <CIT> discloses a chain mesh network for decentralized transaction systems. <CIT> discloses a leaderless, parallel and toplogy aware protocol for achieving consensus with recovery from failure of all nodes in a group.

According to an aspect of the present disclosure there is provided a method of operating a network according to any one of accompanying Claims <NUM> to <NUM>.

According a further aspect of the present disclosure there is provided an apparatus according to any one of accompanying Claims <NUM> to <NUM>.

According to a still further aspect of the present disclosure there is provided a non-transitory computer-readable storage medium according to accompanying Claim <NUM>.

The described embodiments and the advantages thereof may best be understood by reference to the following description taken in conjunction with the accompanying drawings. These drawings in no way limit any changes in form and detail that may be made to the described embodiments without departing from the scope of the described embodiments.

Internet-of-things (IoT) devices have become increasingly ubiquitous and, as a result, various solutions have been proposed to communicate with and between large networks of IoT devices. IoT devices can have various types of software and/or hardware configurations. By networking the IoT devices together, functionalities performed by one of the IoT devices may be provided as a service to other IoT devices that lack that functionality. For example, some IoT devices may have a particular type of processing functionality (such as authentication or password management) that may be provided to other IoT devices in the network.

In some embodiments, the IoT devices may be interconnected together as node devices in a mesh network. The mesh network may be non-hierarchical with various interconnections formed between the node devices as they join and leave the mesh network. In some mesh networks, the respective power states of the node devices of the network may be transient. For example, the node devices may have relatively limited power capability, and may activate to perform a task and then deactivate. For example, some node devices may activate to process a particular event, and then go dormant to save power.

These characteristics of such devices can be problematic in mesh networks in which consensus-based decisions are being made, such as in a blockchain. In such consensus operations, a subset, typically greater than <NUM>%, of the node devices must agree for a given operation to be considered valid (e.g., adding a block to a blockchain). These consensus operations are often performed to provide Byzantine fault tolerance. Byzantine fault tolerance refers to an ability of a network (or other distributed system) to make decisions despite a lack of guarantees about the availability (or reliability) of those participating in the decision making process. There are a number of mechanisms to provide Byzantine fault tolerance among node devices of a network, but many of mechanisms utilize some type of consensus operation, in which a majority decision of the node devices is assumed to be valid.

Such a consensus operation, however, can become unwieldy or unreliable if more than a third of the node devices have failed (or are unreliable). (See, e.g.,<NPL>. ) Such a limitation can cause problems in certain types of mesh networks, such as those including IoT devices, in which the node devices may be routinely offline (e.g., for power conservation) and may not always be present during a consensus operation. This can make it difficult to incorporate non-hierarchical decision making, such as that used for blockchain operations, in a mesh network.

Aspects of the disclosure address the above-noted and other deficiencies by providing a mesh network architecture with the ability to generate proxy node devices in a mesh network to accommodate offline node devices. In some embodiments, an administration device may participate in the network and have a view of the overall network at any given time. When the administration device detects that a node device has gone offline, which may be, e.g., for power or network reasons, the administration device may create a pseudo node device (also referred to herein as a proxy device) and propose the pseudo node device for participation in any consensus operations that would have involved the offline node device. The pseudo node device may participate in consensus operations, such as blockchain operations, in lieu of the offline node device. The administration device may maintain a mapping between the real node device and the pseudo node device, such that when the real node device comes back online, the pseudo node device will be removed to bring the network back to equilibrium. The embodiments of the present disclosure provide resiliency for the mesh network and can, in some embodiments, be adapted to trigger when the members of the chain fall below a threshold percentage to save on resources. In some embodiments, a time duration before a pseudo node device will be generated and/or removed from the network may be configurable to avoid route flapping issues due to node devices connecting and disconnecting in a short time. In some embodiments, the generation of the pseudo node device may include the generation of various types of auditing information, which may allow other members of the mesh network to become aware that a membership issue exists. Embodiments of the present disclosure provide a mechanism by which mesh networks including IoT, or other types of power-transient, devices may still support consensus type operations, such as those performed in blockchain configurations, without having to sacrifice the power-savings or dynamic configuration of the mesh network.

<FIG> depicts a high-level component diagram of an illustrative example of a mesh network architecture <NUM>, in accordance with one or more aspects of the present disclosure. Although the discussion with respect to <FIG> describes a mesh network, other network architectures (e.g., non-mesh) are possible without deviating from the scope of the present disclosure, and the implementation of a computer system utilizing examples of the disclosure are not necessarily limited to the specific architecture depicted by <FIG>.

As shown in <FIG>, mesh network architecture <NUM> includes a plurality of computing devices, including an administration device <NUM> and a plurality of node devices <NUM>. For convenience of description, only three node devices <NUM>, including a first node device 150A, a second node device 150B, and a third node device 150C are illustrated, but it will be understood that additional node devices <NUM> may be present without deviating from the scope of the present disclosure.

<FIG> and the other figures may use like reference numerals to identify like elements. A letter after a reference numeral, such as "150A," indicates that the text refers specifically to the element having that particular reference numeral. A reference numeral in the text without a following letter, such as "<NUM>," refers to any or all of the elements in the figures bearing that reference numeral.

The administration device <NUM> and node devices <NUM> include one or more processing devices <NUM>, memory <NUM>, which may include volatile memory devices (e.g., random access memory (RAM)), non-volatile memory devices (e.g., flash memory) and/or other types of memory devices, and one or more network interfaces <NUM>. In certain implementations, memory <NUM> may be non-uniform access (NUMA), such that memory access time depends on the memory location relative to processing device <NUM>. It should be noted that although, for simplicity, a single processing device <NUM> is depicted in each of the administration device <NUM> and node devices <NUM> depicted in <FIG>, other embodiments of the administration device <NUM> and node devices <NUM> may include multiple processing devices, storage devices, or other devices.

Processing device <NUM> may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. Processing device <NUM> may also include one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Different ones of the administration device <NUM> and node devices <NUM> may have different types of processing device <NUM>.

The administration device <NUM> and node devices <NUM> may be a server, a mainframe, a workstation, a personal computer (PC), a mobile phone, a palm-sized computing device, a virtual instance of a computing device, etc. In some embodiments, one or more of the administration device <NUM> and node devices <NUM> may be an IoT device. In some embodiments, one or more of the administration device <NUM> and node devices <NUM> may be a nanotech device. In some embodiments, nanotech devices may have a longest dimension that is less than <NUM>. For clarity, some components of the administration device <NUM> and node devices <NUM> are not shown.

In some embodiments, the administration device <NUM> and the node devices <NUM> may be directly or indirectly communicatively coupled through one or more of the network interfaces <NUM>. For example, the administration device <NUM> and one or more of the node devices <NUM> may be coupled to each other (e.g., may be operatively coupled, communicatively coupled, may communicate data/messages with each other) via network <NUM>. Network <NUM> may be a public network (e.g., the internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), or a combination thereof. In one embodiment, network <NUM> may include a wired or a wireless infrastructure, which may be provided by one or more wireless communications systems, such as a WIFI® hotspot connected with the network <NUM> and/or a wireless carrier system that can be implemented using various data processing equipment, communication towers (e.g., cell towers), etc. The network <NUM> may carry communications (e.g., data, message, packets, frames, etc.) between the various components of the administration device <NUM> and one more of the node devices <NUM>.

The administration device <NUM> and the node devices <NUM> may include a plurality of network interfaces <NUM>. The network interfaces <NUM> may communicate with a plurality of network types. The variety of network interfaces <NUM> may allow for various configurations of network connectivity between the administration device <NUM> and the node devices <NUM>.

For example, administration device <NUM> may include a first network interface 180X. The first network interface 180X may communicate with and/or within the network <NUM>. One or more of the node devices <NUM>, e.g., first node device 150A and a third node device 150C, may also include the first network interface 180X. Thus, the first node device 150A may be capable of communicating with the administration device <NUM> over network <NUM> using the first network interface 180X.

A second node device of the node devices <NUM>, e.g., second node device 150B, may not include the first network interface 180X. Thus, the second node device 150B may not be capable of directly communicating over network <NUM>. Instead, the second node device 150B may be communicatively coupled to the network <NUM> through a second network interface 180Z that is coupled to the first node device 150A (e.g., as a point-to-point connection). That is to say that the first node device 150A may serve as a relay for communications between the second node device 150B and the network <NUM>. For example, the second node device 150B may be capable of communicating with the administration device <NUM> through the second network interface 180Z between the first and second node devices 150A, 150B and through the first network interface 180X between the first node device 150A and the administration device <NUM> (over network <NUM>). In some embodiments, the first and/or second network interface 180X, 180Z may include a wireless technology, such as WIFI®, Bluetooth, Home radio frequency (Home RF), to name a few examples.

The administration device <NUM>, the first node device 150A, the second node device 150B, the third node device 150C and the network connections therebetween may form the mesh network <NUM>. The mesh network <NUM> may provide an interconnected and non-hierarchical network between members of the mesh. Devices (e.g., node devices <NUM>) may join or leave the mesh network <NUM>, and communication between members of the mesh over various network connections of the mesh may be dynamically routed responsive to changes in the mesh configuration.

The node devices <NUM> perform one or more services within the mesh network <NUM>. As used herein, a "service" provided by the node device <NUM> refers to a task or other technical activity performed by the node device <NUM> on behalf of or for another node device <NUM> or other device external to the mesh network <NUM>. A service may include computer program logic utilized to provide the specified task or technical activity. Thus, a service can be implemented in hardware, firmware, and/or software. In one embodiment, services are stored on a non-transitory storage device (i.e., a computer program product), loaded into a memory, and executed by one or more processing devices. In some embodiments, the service may be provided by execution of computer instruction code on processing device <NUM>. Examples of services include, but are not limited to, a blockchain service, an authentication service, a storage service, a gateway service, a processing service, a power management service, a web server service, and/or a packaging service. The above examples of services are merely examples, and are not intended to limit the present disclosure. One of ordinary skill in the art will recognize that other types of services may be provided within the mesh network <NUM> without deviating from embodiments of the present disclosure.

In some embodiments, one or more of the node devices <NUM> is configured to perform a consensus operation. An example of a consensus operation is an operation that is associated with a task and/or a decision and that requires a threshold number of approvals from node devices <NUM> within the network <NUM> before the task may be performed and/or the decision approved. As an example, a consensus operation may be used to approve whether a particular node device <NUM> may join the mesh network <NUM>. As another example, if the node devices <NUM> are part of a blockchain configuration, a consensus operation may be performed to approved tasks and/or decisions related to the blockchain, such as the addition of a new block.

In some embodiments, the threshold for the consensus operation may be greater than <NUM>% of the node devices <NUM>. The consensus operation involves the exchange of votes <NUM> on the mesh network <NUM>. The votes <NUM> may be in the form of data structures that are transmitted and propagated within the mesh network <NUM>, and the vote <NUM> indicates a status of approval or disapproval by the node device <NUM> of a proposed operation. The vote <NUM> of one node device <NUM> may be visible by other ones of the node devices <NUM>. Thus, a node device <NUM> that is a member of the consensus operation may both vote (e.g., by transmitting vote <NUM> to the mesh network <NUM>) as well as see the votes <NUM> of other members of the mesh network <NUM>. In a consensus operation, each of the node devices <NUM> may separately make a decision on the consensus operation based on the votes <NUM> that it receives. For example, if the majority of the votes <NUM> received by the node device <NUM> indicate approval, the consensus operation may be approved. In such a way, a non-hierarchical decision may be made based on the consensus votes <NUM> that are received without a decision being mandated from another source.

As previously discussed, if some of the node devices <NUM> are unavailable to provide a vote <NUM>, it may be difficult, or impossible, to reach consensus. For example, the stability of the consensus vote may be jeopardized if one-third or more of the available node devices <NUM> are unavailable. Looking at the example of <FIG>, if a single one of the node devices <NUM>, say the third node device 150C, is no longer present or responding, then a vote of the remaining node devices <NUM> will be either <NUM>% approval (e.g., unanimous) or <NUM>% (less than a majority). While a consensus can be reached, it must be unanimous, while consensus (e.g., a majority) could be reached with less than unanimity if the third node device 150C were present/responding. As the number of node devices <NUM> of the mesh network <NUM> increases, the stability of the consensus operation increases. However, the consensus operation may nonetheless be vulnerable of more than one-third of the node devices <NUM> are unavailable.

In some embodiments, the mesh network <NUM> may be formed from node devices <NUM> which frequently leave the mesh network <NUM>, either by disconnecting (e.g., in a mobile network) or powering off (e.g., for node devices <NUM> that may conserve power by powering off, such as an IoT device). In this and similar circumstances, it may be difficult to maintain a consensus operation, as the one-third (or greater) of the node devices that would preferably be available for the consensus operation may be present at one moment and then gone from the mesh network <NUM>.

To avoid disruptions to consensus operations, the administration device <NUM> maintains and/or creates a plurality of proxy devices <NUM>. The proxy devices <NUM> are configured to act as pseudo node devices to provide proxy votes <NUM> for a consensus operation. The proxy votes <NUM> are orchestrated by the administration device <NUM> to replace a failed or otherwise non-responsive node device <NUM>.

In some embodiments, the proxy device <NUM> may be a containerized application running on the administration device <NUM> or other system in the mesh network <NUM>. In some embodiments, the proxy device <NUM> may be a virtual machine running on the administration device <NUM> or other system in the mesh network <NUM>. In some embodiments, the proxy device <NUM> may be a separate node device <NUM> that is a spare or otherwise idle node device <NUM>.

In some embodiments, the administration device <NUM> and the proxy devices <NUM> may (e.g., may be operatively coupled, communicatively coupled, may communicate data/messages with each other) via administrative network <NUM>. The administrative network <NUM> allows the administration device <NUM> to provide voting instructions to the proxy device <NUM>. In some embodiments, the administrative network <NUM> may be an encrypted or otherwise secured network interface.

The proxy devices <NUM> are configured to receive an instruction from the administration device <NUM> (e.g., over the administrative network <NUM>) for how to vote in a particular consensus operation, and provide a proxy vote <NUM> accordingly. For example, the proxy devices <NUM> may receive an instruction from the administration device <NUM> over the administrative network <NUM> and may provide a proxy vote 194A onto network <NUM>, e.g., so that the proxy vote <NUM> may be seen by the other node devices <NUM>. Each of the proxy devices <NUM>, when operational, may be capable of providing a separate proxy vote <NUM>. Thus, a proxy device 120A may be capable of providing a proxy vote 194A to the network <NUM>, a proxy device 120B may be capable of providing a proxy vote 194B to the network <NUM>, and so on.

The proxy votes <NUM> may be seen by the other node devices <NUM> and be acted upon as if they came from another node device <NUM>. In some embodiments, the proxy votes <NUM> may be indistinguishable (e.g., be a same data structure) as the votes <NUM>. In some embodiments, the proxy votes <NUM> may contain additional data indicating that they are a proxy vote <NUM> and, in some embodiments, for which node device <NUM> the proxy vote <NUM> is intended. The proxy devices <NUM> may allow the administration device <NUM> to provide proxy votes <NUM> to the network so that consensus operation may continue.

The administration device <NUM> activate proxy devices <NUM> responsive to determining that one or more of the node devices <NUM> is non-responsive and/or that a consensus operation has begun. In some embodiments, the processing device <NUM> of the administration device <NUM> may execute code instructions, such as proxy monitor <NUM>, to monitor the mesh network <NUM> for the need of a proxy device <NUM>. For example, the administration device <NUM> may monitor the status of each of the node devices <NUM> to determine if the node device <NUM> is no longer responding to network communication and/or has left the mesh network <NUM>. For example, the administration device <NUM> may send a query or other network transmission to a particular node device <NUM> to determine if the node device <NUM> responds. In some embodiments, the administration device <NUM> may be configured to receive a regular signal (e.g., a "heartbeat") from each node device <NUM>, and may consider the node device <NUM> to be unavailable if the regular signal is not received when expected. The administration device <NUM> may track the status of each of the node devices <NUM> of the mesh network <NUM> over time.

In some embodiments, the administration device <NUM> may activate a corresponding proxy device <NUM> as soon as it is determined that a node device <NUM> is offline, but the embodiments of the present disclosure are not limited to this configuration. In some embodiments, the administration device <NUM> may delay activating a proxy device <NUM> until the number of available node devices <NUM> falls below a threshold percentage. For example, proxy devices <NUM> may be activated if <NUM>% or more of the node devices <NUM> of the mesh network <NUM> become unavailable. By waiting until a threshold percentage of the node devices <NUM> have gone offline, the administration device <NUM> may delay interfering with consensus operations until the number of absent node devices <NUM> threaten to impact the efficiency of the consensus operation (e.g., greater than one-third of the node devices <NUM> are absent). In some embodiments, the administration device <NUM> may alternately or additionally wait for a defined time duration to elapse after determining that a node device <NUM> is unavailable before activating a proxy device <NUM>. This may avoid or reduce premature substitution of a proxy device <NUM> due to a node device <NUM> connecting and disconnecting in a short time.

Responsive to a consensus operation, the administration device <NUM> establishes or otherwise enable one of the proxy devices <NUM> to provide a proxy vote <NUM> for a node device <NUM> that is no longer responding to network communication. In some embodiments, enabling the proxy device <NUM> may include activating a container containing executable code configured to receive instructions on how to vote and to transmit a proxy vote <NUM> to the mesh network <NUM>. In some embodiments, enabling the proxy device <NUM> may include activating or otherwise starting a virtual machine. In some embodiments, enabling the proxy device <NUM> may include activating or otherwise starting a spare node device <NUM> to perform the proxy voting. The administration device <NUM> may maintain a mapping (e.g., as a data structure) between an activated proxy device <NUM> and the inactive/absent node device <NUM> to which it corresponds. In some embodiments, the administration device <NUM> may transmit or otherwise provide an indication to the other node devices <NUM> of the mesh network <NUM> that one or more proxy devices <NUM> will join the mesh network <NUM> and/or the consensus operation.

The proxy device <NUM> provides a proxy vote <NUM> according to instructions provided by the administration device <NUM>. For example, the administration device <NUM> may listen on the mesh network <NUM> to the votes <NUM> being provided by the present node devices <NUM>. The administration device <NUM> may wait to determine whether a consensus is forming among the present node devices <NUM> before providing instructions to the proxy device(s) <NUM>. For example, because the administrations device <NUM> is tracking the status of the node devices <NUM> that are present in the mesh network <NUM>, the administration device <NUM> may wait until votes <NUM> are transmitted by a threshold percentage of the present node devices <NUM> before providing instructions to the proxy devices <NUM> (e.g., via administrative network <NUM>).

As an example, the administration device <NUM> may wait until greater than <NUM>%, greater than <NUM>%, or greater than <NUM>% of the present node devices <NUM> have provided a vote <NUM> before providing instructions to the proxy devices <NUM> that indicate whether the proxy devices <NUM> should approve or disapprove the consensus operation via their proxy vote <NUM>. In some embodiments, the administration device <NUM> will operate to minimize disruption to the consensus operation that may be due to the proxy devices <NUM>. For example, the administration device <NUM> may determine, after reaching the threshold number of votes <NUM>, whether a majority of the received votes <NUM> favor approval or disapproval of the consensus operation. For example, if a majority of the transmitted votes <NUM> within the mesh network <NUM> opt for approval, then the administration device <NUM> may provide instructions to the proxy devices <NUM> to transmit proxy votes <NUM> voting for approval. Otherwise (e.g., less than a majority of the transmitted votes <NUM> within the mesh network <NUM> opt for approval), the administration device <NUM> may provide instructions to the proxy devices <NUM> to transmit proxy votes <NUM> voting for disapproval. In this way, the administration device may allow the proxy devices <NUM> to support an already evolving decision of the mesh network <NUM>, while providing enough votes to allow the consensus operation to complete.

In some embodiments, the proxy devices <NUM> may be deactivated within a short time period after providing a proxy vote <NUM>. For example, the administration device <NUM> may deactivate the proxy device <NUM> within thirty seconds, or within a minute, after the proxy vote <NUM>. In some embodiments, a proxy device <NUM> may be reactivated, when the appropriate thresholds are met, for each consensus operations, but the embodiments of the present disclosure are not limited thereto. In some embodiments, the proxy device <NUM> may remain active while its corresponding node device <NUM> remains inactive/offline.

Though the prior example provided a discussion in which the decision of the administration device <NUM> was based on a simple majority of transmitted votes <NUM>, the embodiments of the present disclosure are not limited thereto. In some embodiments, the administration device <NUM> may utilize a higher threshold of approval votes for its instructions. For example, the administration device <NUM> may wait for at least <NUM>% of a threshold number of transmitted votes <NUM> within the mesh network <NUM> to opt for approval before providing instructions to the proxy devices <NUM> to transmit proxy votes <NUM> voting for approval. A higher threshold of approval votes may tend to reduce changes (e.g., by disapproving consensus operations) when a higher number of node devices <NUM> are not available unless a clear consensus has already been made apparent.

<FIG> is a schematic diagram illustrating an example scenario of an activation of one or more proxy devices <NUM>, in accordance with one or more aspects of the present disclosure. In <FIG>, an administration device <NUM> is illustrated in communication with a mesh network <NUM>. The mesh network <NUM> includes a plurality of node devices <NUM> (e.g., node devices 150A-<NUM>). As described herein, the plurality of node devices <NUM> may be coupled directly and/or indirectly within the mesh network <NUM>. The plurality of node devices <NUM> may each include one or more network interfaces (e.g., network interfaces <NUM> in <FIG>). In <FIG>, one or more of the node devices <NUM> may be running a service, such as a web server service and/or a blockchain service. As illustrated in <FIG>, various ones of the node devices <NUM> may be interconnected with one another and, in some embodiments, one or more of the node devices <NUM> may relay network transmissions of others of the node devices <NUM>. For example, in the example of <FIG>, the node device 150D may relay transmissions from the node device 150F to the network <NUM>.

Referring to <FIG> and <FIG>, the administration device <NUM> may execute a proxy monitor <NUM> (see <FIG>) that monitors a state of the node devices <NUM> and whether a consensus operation has proceeded. For example, the administration device <NUM> may monitor the node devices <NUM> to determine if one or more of the node devices <NUM> has gone offline. In the scenario illustrated in <FIG>, the administration device <NUM> may detect that two node devices <NUM> are offline or otherwise non-responsive: node device 150F and node device <NUM>. The administration device <NUM> may detect the node devices <NUM> are offline by failing to receive responses from queries to the node devices <NUM>, failing to receive a heartbeat signal from the node device <NUM>, querying neighbor node devices <NUM>, or other techniques understood by those of ordinary skill in the art. In some embodiments, the administration device <NUM> may monitor the number of node devices <NUM> that are offline to determine if the number of offline node devices <NUM> exceeds a particular threshold, such as <NUM>% of the available node devices <NUM>, <NUM>% of the available node devices <NUM>, or other threshold value.

The administration device <NUM> may determine that a consensus operation has begun. In some embodiments, the consensus operation may be announced via a transmission on the mesh network <NUM>. In some embodiments, the administration device <NUM> detects the votes <NUM> associated with the consensus operation on the mesh network <NUM>.

The administration device <NUM> activates one or more proxy devices <NUM> responsive to the consensus operation and/or responsive to determining that a threshold number of node devices <NUM> have been removed from the mesh network <NUM>, and may map one or more of the proxy devices <NUM> to the absent node devices <NUM>. For example, for the scenario illustrated in <FIG>, the administration device <NUM> may map a first proxy device 120A to absent/non-responsive node device 150F and a second proxy device 120B to absent/non-responsive node device <NUM>.

The administration device <NUM> may continue to monitor votes <NUM> on the mesh network <NUM>. As illustrated in <FIG>, the administration device <NUM> may receive network transmissions including votes 192A, 192B, and 192C from node devices 150A, 150B, and 150C, respectively.

If the administration device <NUM> determines that a threshold number of votes <NUM> have been received, the administration device <NUM> forms a consensus instruction <NUM> from the received votes <NUM>. The consensus instruction <NUM> may indicate whether the consensus operation should be approved or disapproved. For example, if a majority of the received votes <NUM> indicate that the consensus operation should be approved, the consensus instruction <NUM> may indicate approval (e.g., a "yes" vote). Similarly, if less than a majority of the received votes <NUM> indicate that the consensus operations should be approved, the consensus instruction <NUM> may indicate disapproval (e.g., a "no" vote).

The administration device <NUM> may transmit the consensus instructions <NUM> to one or more of the plurality of node devices <NUM> that are mapped to inactive/absent node devices <NUM>. For example, the administration device <NUM> may transmit the consensus instructions <NUM> over an administrative network <NUM>, which may be a secured network.

The activated proxy devices <NUM> (e.g., proxy devices 120A and 120B in the example of <FIG>) receive the consensus instructions <NUM>. Responsive to the consensus instructions <NUM>, the proxy devices <NUM> provide a proxy vote <NUM> for the on-going consensus operation. For example, in <FIG>, proxy device 120A may transmit proxy vote 194A and proxy device 120B may transmit proxy vote 194B to the mesh network <NUM>. As described herein, the proxy votes <NUM> may be received by other node devices <NUM> of the mesh network <NUM> and treated as valid votes for the consensus operation.

In some embodiments, the administration device <NUM> may continue to monitor the node devices <NUM> to determine if a node device <NUM> that was previously identified as unavailable becomes available again. In such a case, the administration device <NUM> may determine which of the proxy node devices <NUM> is mapped to the now-available node device <NUM>, and deactivate that proxy node device <NUM>. This may be done to avoid multiple votes (e.g., a vote <NUM> and a proxy vote <NUM>) that correspond to a same node device <NUM>.

By monitoring the state of the node devices <NUM> and any on-going consensus operations, the administration device <NUM> may be able to detect scenarios in which the consensus operation is likely to fail or otherwise be challenged due to the absence of particular node devices <NUM>, even though the absence may be due to normal operations of the node devices <NUM>. By activating and controlling the proxy devices <NUM>, the administration device <NUM> may support the on-going consensus operation while reducing an impact that the proxy devices <NUM> and the absent node devices <NUM> have on the consensus operation.

Though <FIG> illustrates an embodiment in which the proxy devices <NUM> are shown as separate from the administration device <NUM>, this is only for convenience of illustration. In some embodiments, the proxy devices <NUM> may be executing on the administration device <NUM>. For example, in some embodiments, the proxy devices <NUM> may be containers (e.g., containerized applications) executing on the administration device <NUM>. In embodiments in which the proxy devices <NUM> are executing on the administration device <NUM>, the administrative network <NUM> may be an internal network and/or communication path of the administration device <NUM>.

Embodiments of the present disclosure may be useful in multiple scenarios, such as in blockchain environments. <FIG> is a schematic diagram illustrating an example scenario of an activation of one or more proxy devices <NUM> in a blockchain environment, in accordance with one or more aspects of the present disclosure. A description of elements of <FIG> that have been previously described will be omitted for brevity.

Referring to <FIG>, the mesh network <NUM> may be, or be part of, an implementation of a blockchain <NUM>. A blockchain <NUM> is a linked list of records <NUM>, often referred to as blocks <NUM>, that are linked together, in part, using cryptography. Each block <NUM> contains a cryptographic hash of the previous block <NUM>, a timestamp, and transaction data. As blocks <NUM> each contain information about the block <NUM> previous to it, they form a chain, with each additional block <NUM> reinforcing the ones before it. Therefore, blockchains <NUM> are resistant to modification of their data because once recorded, the data in any given block <NUM> cannot be altered retroactively without altering all subsequent blocks <NUM>.

Referring to <FIG> and <FIG>, a plurality of node devices <NUM> may be interconnected and/or grouped into a blockchain <NUM>. Each of the node devices <NUM> may include a copy of the linked list of the blocks <NUM> of the blockchain <NUM>. For example, as illustrated in <FIG>, the blockchain <NUM> may include node devices 150A, 150B, 150C, 150D, and 150E. The number of node devices <NUM> in the blockchain <NUM> illustrated in <FIG> is merely an example, and is not intended to limit the embodiments of the present disclosure.

The plurality of node devices <NUM> may be coupled directly and/or indirectly connected within the mesh network <NUM>. The plurality of node devices <NUM> may each include one or more network interfaces (e.g., similar to network interfaces <NUM> in <FIG>). The node devices <NUM> are connected in a non-hierarchical peer-to-peer network as part of the blockchain <NUM>.

In some embodiments, the blockchain <NUM> may be provided as a distributed ledger that may be managed by a peer-to-peer network, such as mesh network <NUM>, where node devices <NUM> collectively adhere to a protocol to communicate and validate new blocks <NUM>. The blockchain <NUM> may include a plurality of linked blocks <NUM>. Each of the node devices <NUM> may include a copy of the linked list of blocks <NUM> of the block chain <NUM>. For example, as illustrated in <FIG>, the blockchain <NUM> may include blocks 355A, 355B, and 355C. The number of blocks <NUM> in the blockchain <NUM> illustrated in <FIG> is merely an example, and is not intended to limit the embodiments of the present disclosure.

The various node devices <NUM> of the mesh network <NUM> use consensus, such as consensus votes <NUM> to validate whether a new block <NUM> may be added to the blockchain <NUM>. The consensus votes <NUM> may be used to determine whether the new block <NUM> is valid. For example, a consensus algorithm may be used to allow all of the node devices <NUM> of the blockchain <NUM> to reach a common agreement about the present state of the distributed ledger. In this way, consensus algorithms achieve reliability in the blockchain <NUM>. For example, the consensus algorithm ensures that every new block <NUM> that is added to the blockchain <NUM> is agreed upon by a subset of the node devices <NUM> in the blockchain <NUM> to be valid. In some embodiments, the subset may be all, some, or a majority of the node devices <NUM> of the blockchain <NUM>, but is typically greater than <NUM>%.

In some embodiments, the common agreement about the present state of the blockchain <NUM>, including common agreement to add a new block <NUM> to the blockchain <NUM> may be a consensus operation in which the embodiments of the present disclosure may be employed. For example, an operation to add a new block <NUM> to the blockchain <NUM> may spawn a vote among members of the blockchain <NUM>. Each of the members (e.g., the node devices <NUM>) of the blockchain <NUM> may transmit their vote <NUM> as to the addition of the new block <NUM> to the other members (e.g., the other node devices <NUM>) of the blockchain <NUM>. The administration device <NUM> may monitor the vote (e.g., by receiving votes <NUM> transmitted by the node devices <NUM>).

As previously described with respect to <FIG> and <FIG>, the administration device <NUM> may also monitor the status of the node devices <NUM> of the blockchain <NUM>. Upon determining that a threshold number of node devices <NUM> have become unavailable (e.g., one node device <NUM>, greater than <NUM>% of the node devices <NUM>, greater than <NUM>% of the node devices <NUM>, etc.), the administration device <NUM> activates one or more of the proxy devices <NUM>. The administration device <NUM> may maintain a mapping between the activated proxy devices <NUM> and the disabled/unavailable node devices <NUM> which they are intended to represent. As described herein, activating a node device <NUM> may include executing a containerized application, executing a virtual machine, and/or activating a spare node device <NUM>. In some embodiments, as part of activating the proxy device <NUM>, the administration device <NUM> may raise a special transaction request of the blockchain <NUM>, which may be transmitted to the node devices <NUM> of the blockchain <NUM>, to allow the proxy device <NUM> to become a peer on the blockchain <NUM>. In some embodiments, the request to add the proxy device <NUM> as a peer may be accompanied by an audit record that indicates the proxy device <NUM> is a transient addition to the blockchain <NUM> due to an offline node device <NUM>. This audit record may allow the addition of the proxy device <NUM> to be performed in a transparent and open manner than can be documented by an audit of the blockchain <NUM>.

Once the proxy devices <NUM> are accepted as part of the blockchain <NUM>, the vote of the proxy device <NUM> may be controlled by the administration device <NUM> as described with respect to <FIG> and <FIG>. For example, the administration device <NUM> may monitor the votes <NUM> of the node devices <NUM> of the blockchain <NUM>, such as vote 192A of node device 150A illustrated in <FIG>, to determine the status of the consensus operation. Based on the status of the consensus operation (e.g., by monitoring whether a consensus is forming among the voting node devices <NUM> based on the votes <NUM> received/monitored by the administration device <NUM>), the administration device <NUM> provides instructions (e.g., consensus instructions <NUM> of <FIG>) to the activated proxy device(s) <NUM> to direct their proxy vote <NUM>, such as proxy vote 194A of proxy device 120A illustrated in <FIG>.

By utilizing the proxy devices <NUM>, the administration device <NUM> may allow for a consensus operation, such as the addition of a new block <NUM> to the blockchain <NUM>, to proceed despite the transient nature of the node devices <NUM> that may be included in the blockchain <NUM>. This allows for a more robust and resilient blockchain <NUM> that may allow the incorporation of new types of node devices <NUM> while maintaining the integrity of the blockchain <NUM>.

<FIG> is a component diagram of an example of a device architecture <NUM>, in accordance with one or more aspects of the disclosure. The device architecture <NUM> includes administration device <NUM>, processing device <NUM>, and memory <NUM> of <FIG> and, as such, a duplicate description thereof will be omitted.

A proxy monitor <NUM> of the administration device <NUM> may monitor a plurality of node devices <NUM> described herein with respect to <FIG>. The administration device <NUM> detects, e.g., by the processing device <NUM>, the availability of the node devices <NUM> of a mesh network <NUM> to determine if one or more of the node devices <NUM> has become unavailable. A node device <NUM> may be considered unavailable, for example, if the node device <NUM> is not responding to network communications from the administration device <NUM> and/or other node devices <NUM> of the mesh network <NUM>.

The administration device <NUM> may determine (e.g., by the proxy monitor <NUM>) that a number of the node devices <NUM> that are unavailable has exceeded an availability threshold <NUM>. Responsive to detecting that the availability threshold <NUM> has been exceeded, the administration device <NUM> activates one or more proxy devices <NUM> to correspond the one or more node devices <NUM> that have been detected as being unavailable.

The administration device <NUM> may monitor and/or detect a consensus operation on the mesh network <NUM>. Detecting the consensus operation may include detecting one or more vote transmissions <NUM> on the mesh network <NUM>. Responsive to detecting the consensus operation, the administration device <NUM> controls the proxy device <NUM> to provide a proxy vote transmission <NUM> to the mesh network <NUM>. In some embodiments, the contents of the proxy vote transmission <NUM> (e.g., whether to approve or disapprove) is based on the vote transmissions <NUM> monitored by the administration device <NUM>. The administration device <NUM> directs the proxy device <NUM> to provide a proxy vote transmission <NUM> that is in accordance with a consensus of the vote transmissions <NUM> observed by the administration device <NUM>.

Administration device <NUM> includes a memory <NUM> that is operatively coupled to processing device <NUM>. In some embodiments, memory <NUM> may include volatile memory devices (e.g., random access memory (RAM)), non-volatile memory devices (e.g., flash memory) and/or other types of memory devices.

<FIG> is a flow diagram of a method <NUM> of monitoring a consensus operation of a mesh network <NUM>, in accordance with one or more aspects of the disclosure. Method <NUM> may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, a processor, a processing device, a central processing unit (CPU), a system-on-chip (SoC), etc.), software (e.g., instructions running/executing on a processing device), firmware (e.g., microcode), or a combination thereof. In some embodiments, at least a portion of method <NUM> may be performed by administration device <NUM> and/or the proxy monitor <NUM> of at least <FIG>.

With reference to <FIG>, method <NUM> illustrates example functions used by various embodiments. Although specific function blocks ("blocks") are disclosed in method <NUM>, such blocks are examples. It is appreciated that the blocks in method <NUM> may be performed in an order different than presented, and that not all of the blocks in method <NUM> may be performed.

Method <NUM> begins at block <NUM>, where the processing logic, responsive to detecting an unavailability of a first node device of a plurality of node devices of a network, activates a proxy device to correspond to the first node device. The plurality of node devices may be, for example, similar to the node devices <NUM> discussed herein with respect to <FIG>. The network may be, for example, similar to mesh network <NUM> discussed herein with respect to <FIG>. The proxy device may be, for example, similar to proxy device <NUM> discussed herein with respect to <FIG>. In some embodiments, activating the proxy device may be accompanied by transmitting a transaction request on the network that indicates the proxy device corresponds to the first node device.

In some embodiments, detecting the unavailability of the first node device may include attempting to contact the first node device over the network, or querying a status of the first node device from one or more of the plurality of node devices. In some embodiments, activating the proxy device may be performed responsive to determining that a number of the plurality of node devices that are unavailable exceeds a defined availability threshold, such as availability threshold <NUM> discussed herein with respect to <FIG>. In some embodiments, the defined availability threshold may be greater than twenty-five percent of the plurality of node devices. In some embodiments, activating the proxy device may be performed responsive to determining that a duration that the first node device has been unavailable has exceed a defined time duration.

At block <NUM>, the processing logic, detects a consensus operation among the plurality of node devices. The consensus operation includes a plurality of vote transmissions within the network. The vote transmission may be, for example, similar to the votes <NUM> discussed herein with respect to <FIG>. In some embodiments, the network may be or include a blockchain and the consensus operation may be to an operation to add a block to the blockchain, such as that discussed herein with respect to blockchain <NUM> and block <NUM> of <FIG>. In some embodiments, detecting the consensus operation among the plurality of node devices includes examining an approval status of each of the plurality of vote transmissions.

At block <NUM>, the processing logic controls the proxy device to provide a proxy vote transmission as part of the consensus operation. The proxy vote transmission may be similar to proxy vote <NUM> discussed herein with respect to <FIG>. In some embodiments, controlling the proxy device includes transmitting a proxy vote transmission comprising an approval of the consensus operation if a count of the plurality of vote transmissions received and/or monitored by the processing logic that indicate approval exceeds a defined vote threshold and transmitting a proxy vote transmission comprising a disapproval of the consensus operation if the count of the plurality of vote transmissions received and/or monitored by the processing logic that indicate approval does not exceed the defined vote threshold.

As described herein, an administration device <NUM> may monitor a mesh network <NUM> to determine if one or more of the node devices <NUM> have become unavailable. The administration device <NUM> may determine the status of the node device <NUM> directly (e.g., by attempting a communication or other interaction and waiting for a response), but the embodiments of the present disclosure are not limited thereto. In some embodiments, the administration device <NUM> may additionally, or alternatively, query others of the node devices <NUM> to determine the status of a particular node device.

<FIG> are schematic views of a mesh network <NUM> that illustrate scenarios for determining the availability of a node device <NUM>, in accordance with some embodiments of the present disclosure. The mesh network <NUM> of <FIG> includes administration device <NUM>, node devices <NUM>, and network <NUM> of <FIG> and, as such, a duplicate description thereof will be omitted.

Referring to <FIG>, the interconnected nature of the mesh network <NUM> may provide various paths with which the administration device <NUM> may communicate with a given node device <NUM>. In the example of <FIG>, a node device 150F is illustrated as having a connection to the administration device <NUM> through other node devices 150C, 150D. As an example, a first node device 150C may have a wireless (e.g., WIFI) or wired network connection to network <NUM>, and a second node device 150D may have a wired or wireless connection to the first node device <NUM>. For example, the second node device 150D may be connected to the first node device 150C via a wireless protocol, such as Bluetooth. Similarly, a third node device 150F may have a wired or wireless connection to the second node device 150D.

In some embodiments, administration device <NUM> may communicate, or attempt to communicate, with the third node device 150F by relaying messages between the first and second node devices 150C, 150D. If the third node device 150F fails to respond to the administration device <NUM>, the third node device 150F may be marked as unavailable. In some embodiments, the administration device <NUM> may broadcast or otherwise transmit a status request <NUM> on the mesh network <NUM>. The node devices <NUM> may respond with their particular status by transmitting a response status message <NUM>. For example, as illustrated in <FIG>, the first node device 150C and the second node device 150D may provide or otherwise transmit status messages 620C and 620D, respectively, in response to the request message <NUM>. The administration device <NUM> may infer, based on a lack of status message <NUM>, that the third node device 150F is unavailable.

In some embodiments, the administration device <NUM> may determine the availability of the third node device <NUM> by querying the other node devices <NUM>. For example, the administration device <NUM> may propagate or otherwise broadcast the request <NUM> to the node devices <NUM> to request an update on the status of the third node device 150F. The request may provide an address (e.g., an IP address or MAC address) or other identifying information of the third node device 150F. The node devices <NUM> may respond with status messages <NUM> as in the prior example, but the status messages <NUM> may include the status of the third node device 150F. For example, both the first node device 150C and the second node device 150D may attempt to communicate with the third node device 150F, and may provide the results of their attempts (e.g., as to whether the third node device 150F is available or unavailable) via status messages 620C and 620D, respectively. The administration device <NUM> may analyze the status messages <NUM> to determine if the node device <NUM> (e.g., the third node device 150F) is available and/or responsive. In some embodiments, the administration device <NUM> may weigh a response from a node device <NUM> that is fewer network hops away from the node device <NUM> in question higher than status messages <NUM> provided from node devices <NUM> that are further away. In the example illustrated in <FIG>, the administration device <NUM> may weigh the status message 620D from the third node device 150D higher in its analysis than the status message 620C from the second node device 150C. For example, if the second node device 150C indicates that the third node device 150F is non-responsive and/or unavailable, but the third node device 150D indicates that the third node device 150F is responsive and/or available, the administration device <NUM> may determine that the third node device 150F is responsive and/or available.

In some embodiments, determining the availability of a node device <NUM> itself may be performed as a consensus operation. For example, as illustrated in <FIG>, the administration device <NUM> may request a consensus operation from the node devices <NUM> as to whether the third node device 150F is available for participation in the mesh network <NUM>. Each of the individual node devices <NUM> may make their own individual determination (e.g., by performing their own attempts to contact the node device <NUM> in question), and respond to the consensus operation with a vote transmission <NUM>. The administration device <NUM> may review the vote transmissions <NUM> to determine if there is a consensus that a node device <NUM> (e.g., the third node devices 150F in <FIG>) is unavailable. If the node devices <NUM> of the mesh network <NUM> reach a consensus that the node device <NUM> in question (e.g., the third node devices 150F in <FIG>) is unavailable (e.g., a majority of the node devices <NUM> agree that the node device <NUM> in question is unavailable), the administration device <NUM> can proceed with determining whether a proxy device <NUM> should be activated, as described herein. For some embodiments, such as the blockchain embodiments described herein for example, the consensus operation that the node device <NUM> is unavailable may be saved for auditing purposes (e.g., as part of the blockchain). In this way, the reasons for the activation of the proxy device <NUM> are transparent. For example, in some embodiments, the node devices <NUM> of the mesh network <NUM> may require a consensus operation to agree that a node device <NUM> is unavailable before one or more proxy devices <NUM> may be added to the mesh network <NUM> for the purposes of voting in further consensus operations.

Method <NUM> begins at block <NUM>, where the processing logic detects a consensus operation among a plurality of node devices. The plurality of node devices may be, for example, similar to the node devices <NUM> discussed herein with respect to <FIG>. The network may be, for example, similar to mesh network <NUM> discussed herein with respect to <FIG>. In some embodiments, activating the proxy device may be accompanied by transmitting a transaction request on the network that indicates the proxy device corresponds to the first node device.

The consensus operation includes a plurality of vote transmissions within the network. The vote transmission may be, for example, similar to the votes <NUM> discussed herein with respect to <FIG>. In some embodiments, the network may be or include a blockchain and the consensus operation may be to an operation to add a block to the blockchain, such as that discussed herein with respect to blockchain <NUM> and block <NUM> of <FIG>. In some embodiments, detecting the consensus operation among the plurality of node devices includes examining an approval status of each of the plurality of vote transmissions.

At block <NUM>, the processing logic, responsive to determining that a number of active node devices of the plurality of node devices is less than a defined threshold of available devices, activates a plurality of proxy devices. The proxy device may be, for example, similar to proxy device <NUM> discussed herein with respect to <FIG>. In some embodiments, activating the proxy device may be accompanied by transmitting a transaction request on the network that indicates the proxy device corresponds to the first node device.

In some embodiments, detecting the unavailability of the first node device may include attempting to contact the first node device over the network, or querying a status of the first node device from one or more of the plurality of node devices. In some embodiments, the defined threshold of the available devices may be less than seventy-five percent of the plurality of node devices. In some embodiments, activating the proxy device may be performed responsive to determining that a duration of unavailability of the first node device has exceed a defined time duration.

At block <NUM>, the processing logic directs a proxy vote of the proxy devices based on a count of received vote transmission from the plurality of node devices. The proxy vote may be similar to proxy vote <NUM> discussed herein with respect to <FIG>. In some embodiments, directing the proxy device includes transmitting instructions to the proxy device to transmit a proxy vote transmission comprising an approval of the consensus operation if a count of the plurality of vote transmissions that indicate approval exceeds a defined vote threshold and transmitting instructions to the proxy device to transmit a proxy vote transmission comprising a disapproval of the consensus operation if the count of the plurality of vote transmissions that indicate approval does not exceed the defined vote threshold.

Method <NUM> begins at block <NUM>, where the processing logic monitors a plurality of node devices of a blockchain. The plurality of node devices may be, for example, similar to the node devices <NUM> discussed herein with respect to <FIG>. The blockchain may be, for example, similar to blockchain <NUM> discussed herein with respect to <FIG>.

At block <NUM>, the processing logic detects a consensus operation among the members of the blockchain. The consensus operation may include a plurality of vote transmissions within the network. The vote transmission may be, for example, similar to the votes <NUM> discussed herein with respect to <FIG>. In some embodiments, detecting the consensus operation among the plurality of node devices includes examining an approval status of each of the plurality of vote transmissions.

At block <NUM>, the processing logic detects an unavailability of a first node device of a plurality of node devices included in the consensus operation. In some embodiments, detecting the unavailability of the first node device may include attempting to contact the first node device over the network, or querying a status of the first node device from one or more of the plurality of node devices.

At block <NUM>, the processing logic activates a proxy device to correspond to the first node device. In some embodiments, activating the proxy device may be performed responsive to determining that a number of the plurality of node devices that are unavailable exceeds a defined availability threshold, such as availability threshold <NUM> discussed herein with respect to <FIG>. In some embodiments, the defined availability threshold may be greater than twenty-five percent of the plurality of node devices. In some embodiments, activating the proxy device may be performed responsive to determining that the unavailability of the first node device has exceed a defined time duration.

At block <NUM>, the processing logic controls the proxy device to participate in the consensus operation as a member of the blockchain. The proxy vote transmission may be similar to proxy vote <NUM> discussed herein with respect to <FIG>. In some embodiments, controlling the proxy device includes directing the proxy device to transmit a proxy vote transmission comprising an approval of the consensus operation if a count of the plurality of vote transmissions that indicate approval exceeds a defined vote threshold and directing the proxy device to transmit a proxy vote transmission comprising a disapproval of the consensus operation if the count of the plurality of vote transmissions that indicate approval does not exceed the defined vote threshold.

<FIG> is a block diagram of an example computing device <NUM> that may perform one or more of the operations described herein, in accordance with one or more aspects of the disclosure. Computing device <NUM> may be connected to other computing devices in a LAN, an intranet, an extranet, and/or the Internet. The computing device may operate in the capacity of a server machine in client-server network environment or in the capacity of a client in a peer-to-peer network environment. The computing device may be provided by a personal computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single computing device is illustrated, the term "computing device" shall also be taken to include any collection of computing devices that individually or jointly execute a set (or multiple sets) of instructions to perform the methods discussed herein.

The example computing device <NUM> includes a processing device (e.g., a general purpose processor, a PLD, etc.) <NUM>, a main memory <NUM> (e.g., synchronous dynamic random access memory (DRAM), read-only memory (ROM)), a static memory <NUM> (e.g., flash memory and a data storage device <NUM>), which may communicate with each other via a bus <NUM>.

Processing device <NUM> may be provided by one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. In an illustrative example, processing device <NUM> may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. Processing device <NUM> may also include one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device <NUM> may execute the operations described herein, in accordance with one or more aspects of the present disclosure, for performing the operations and steps discussed herein.

Computing device <NUM> may further include a network interface device <NUM> which may communicate with a network <NUM>. The computing device <NUM> also may include a video display unit <NUM> (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device <NUM> (e.g., a keyboard), a cursor control device <NUM> (e.g., a mouse) and an acoustic signal generation device <NUM> (e.g., a speaker). In one embodiment, video display unit <NUM>, alphanumeric input device <NUM>, and cursor control device <NUM> may be combined into a single component or device (e.g., an LCD touch screen).

Data storage device <NUM> includes a computer-readable storage medium <NUM> on which may be stored one or more sets of instructions <NUM> that may include instructions for a network monitoring component, e.g., proxy monitor <NUM> for carrying out the operations described herein, in accordance with one or more aspects of the present disclosure. Instructions <NUM> may also reside, completely or at least partially, within main memory <NUM> and/or within processing device <NUM> during execution thereof by computing device <NUM>, main memory <NUM> and processing device <NUM> also constituting computer-readable media. The instructions <NUM> may further be transmitted or received over a network <NUM> via network interface device <NUM>.

While computer-readable storage medium <NUM> is shown in an illustrative example to be a single medium, the term "computer-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable storage medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform the methods described herein. The term "computer-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media.

Unless specifically stated otherwise, terms such as "detecting," "activating," "controlling," "directing", "determining," or the like, refer to actions and processes performed or implemented by computing devices that manipulates and transforms data represented as physical (electronic) quantities within the computing device's registers and memories into other data similarly represented as physical quantities within the computing device memories or registers or other such information storage, transmission or display devices. Also, the terms "first," "second," "third," "fourth," etc., as used herein are meant as labels to distinguish among different elements and may not necessarily have an ordinal meaning according to their numerical designation.

Examples described herein also relate to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computing device selectively programmed by a computer program stored in the computing device. Such a computer program may be stored in a computer-readable non-transitory storage medium.

The methods and illustrative examples described herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used in accordance with the teachings described herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear as set forth in the description above.

The above description is intended to be illustrative, and not restrictive. Although the present disclosure has been described with references to specific illustrative examples, it will be recognized that the present disclosure is not limited to the examples described. The scope of the disclosure should be determined with reference to the following claims.

It will be further understood that the terms "comprises", "comprising", "includes", and/or "including", when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Therefore, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "and/or" includes any and all combination of one or more of the associated listed items.

Various units, circuits, or other components may be described or claimed as "configured to" or "configurable to" perform a task or tasks. In such contexts, the phrase "configured to" or "configurable to" is used to connote structure by indicating that the units/circuits/components include structure (e.g., circuitry) that performs the task or tasks during operation. As such, the unit/circuit/component can be said to be configured to perform the task, or configurable to perform the task, even when the specified unit/circuit/component is not currently operational (e.g., is not on). The units/circuits/components used with the "configured to" or "configurable to" language include hardware--for example, circuits, memory storing program instructions executable to implement the operation, etc. Reciting that a unit/circuit/component is "configured to" perform one or more tasks, or is "configurable to" perform one or more tasks, is expressly intended not to invoke <NUM> U. <NUM>, sixth paragraph, for that unit/circuit/component. Additionally, "configured to" or "configurable to" can include generic structure (e.g., generic circuitry) that is manipulated by software and/or firmware (e.g., an FPGA or a general-purpose processor executing software) to operate in manner that is capable of performing the task(s) at issue. "Configured to" may also include adapting a manufacturing process (e.g., a semiconductor fabrication facility) to fabricate devices (e.g., integrated circuits) that are adapted to implement or perform one or more tasks. "Configurable to" is expressly intended not to apply to blank media, an unprogrammed processor or unprogrammed generic computer, or an unprogrammed programmable logic device, programmable gate array, or other unprogrammed device, unless accompanied by programmed media that confers the ability to the unprogrammed device to be configured to perform the disclosed function(s).

Claim 1:
A method, at a processing device, of operating a network comprising:
responsive to detecting an unavailability of at least a first node device (150A) of a plurality of node devices (150A-C) of a network (<NUM>), activating a proxy device (<NUM>) to correspond to the first node device;
detecting a consensus operation among the plurality of node devices (150A-C), wherein the consensus operation comprises a plurality of vote (<NUM>) transmissions within the network (<NUM>); and characterised by
controlling, by the processing device (<NUM>), the proxy device (<NUM>) to provide a proxy vote (<NUM>) transmission as part of the consensus operation,
detecting the consensus operation among the plurality of node devices (150A-C) comprises examining an approval status of each of the plurality of vote transmissions; and wherein,
controlling the proxy device (<NUM>) to provide the proxy vote transmission as part of the consensus operation comprises:
responsive to determining that a count of the plurality of vote transmissions that indicate approval exceeds a defined vote threshold, transmitting instructions to the proxy device (<NUM>) to transmit a proxy vote transmission comprising an approval of the consensus operation; and
responsive to determining that the count of the plurality of vote transmissions that indicate approval does not exceed the defined vote threshold, transmitting instructions to the proxy device (<NUM>) to transmit a proxy vote transmission comprising a disapproval of the consensus operation.