Adjustable and blended consensus mechanism for blockchain validation

Abstract

A method for blending consensus protocols and weighting nodes in a blockchain network includes determining a current state of a blockchain network, comparing the current state of the blockchain network to a set of predetermined conditions, identifying a predetermined condition that matches the current state of the blockchain network, and applying a blend of consensus protocols that correspond to the predetermined condition.

Description

ADJUSTABLE AND BLENDED CONSENSUS MECHANISMFOR BLOCKCHAIN VALIDATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the priority benefit of U.S. Provisional Patent Application No. 63 / 634,782, filed April 16, 2024, which is incorporated herein by reference in its entirety.TECHNICAL FIELD

[0002] This specification generally relates to an adjustable and blended consensus mechanism for performing validation of blocks in a blockchain, such as a mechanism that includes aspects of a Proof of Stake (PoS) protocol and a Proof of Authority (PoA) protocol.BACKGROUND

[0003] A blockchain is a distributed ledger to which blocks of records are added over time. The blocks can be securely linked together through cryptographic hashes, with each block including a cryptographic hash of the previous block, a timestamp, and transaction data. Thus, blockchain transactions are generally irreversible in that the data in a given block cannot be altered once it is added to the blockchain, without also altering subsequent blocks.

[0004] A blockchain can be implemented through a peer-to-peer network of nodes that each run the same blockchain software, and that are each capable of independently verifying blockchain transactions. Each node can maintain a copy of the blockchain, with no centralized copy existing, and with data quality being maintained through replication. As transaction data enters the network, the data can be periodically grouped into a block for verification, and the network of nodes can form a consensus of whether the new block should be added to the blockchain.

[0005] Various consensus protocols can be used when adding new blocks to the blockchain. A Proof of Stake (PoS) protocol involves selecting a node to add a new block of transactions to the blockchain and a group of nodes for validating the addednode, based on a staked amount of cryptocurrency that are associated with each of the participating nodes. With a Proof of Authority (PoA) protocol, block generating and validating nodes are selected based on a vetting process that ensures that operators of the participating nodes are trustworthy.SUMMARY

[0006] This document generally describes computer systems, processes, program products, and devices for blending consensus protocols and weighting nodes in a blockchain network. In general, a current state of a blockchain network is determined, and off-chain information is optionally received from one or more information oracles. The current state of the blockchain network (possibly in view of the off-chain information) is compared to predetermined conditions specified in weighting condition data, a predetermined condition is identified that matches the current state of the blockchain network, and a blend of consensus protocols that correspond to the predetermined condition is applied. The applied blend of consensus protocols (e.g., a blend of a Proof of Stake (PoS) consensus protocol and a Proof of Authority (PoA) consensus protocol) can be used by the blockchain network when validating blocks, until such time that a change is detected in the blockchain network that warrants a change in the blend of consensus protocols.

[0007] In general, both the PoS consensus protocol and the PoA protocol may be considered as Sybil resistance mechanisms that protect against Sybil attacks, in which a malicious actor creates numerous fake identities to gain control over a blockchain network. For the PoS consensus protocol, weights are determined for various validator nodes, in proportion to an amount of cryptocurrency (e.g., a number of tokens) staked in association with each validator node. For the PoA consensus protocol, a trusted authority can determine weights for various validator nodes. Through a consensus mechanism blending process, validator nodes of multiple different consensus groups (e.g., including both nodes that might be selected under the PoS consensus protocol, and nodes that might be selected under the PoA consensus protocol), can be assigned appropriate weights based on current network conditions. An underlying consensus mechanism (e.g., a system / process that facilitates agreement on the validity oftransactions and current state of a blockchain), for example, can use the assigned weights as inputs to determine which decisions are to be accepted, which blocks are to be finalized, and so forth.

[0008] In some implementations, a method for blending consensus protocols and weighting nodes in a blockchain network includes determining a current state of a blockchain network, comparing the current state of the blockchain network to a set of predetermined conditions, identifying a predetermined condition that matches the current state of the blockchain network, and applying a blend of consensus protocols that correspond to the predetermined condition.

[0009] Other implementations of this aspect include corresponding computer systems, and include corresponding apparatus and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods. A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

[0010] These and other implementations can include any, all, or none of the following features. The current state of the blockchain can be defined at least in part by a number of authority nodes that are currently connected to the blockchain network and that are configured to participate in a proof of authority consensus protocol. The current state of the blockchain network can be defined at least in part by a number of validator nodes that are currently connected to the blockchain network and that are configured to participate in a proof of stake consensus protocol. The current state of the blockchain network can be defined at least in part by a total amount of cryptocurrency that is currently being staked by validator nodes that are currently connected to the blockchain network. A change to the blockchain network can be detected that impacts the current state of the blockchain network. Comparing the current state of the blockchain network to the set of predetermined conditions can be performed in response to detecting the change to the blockchain network. The change to the blockchain network that impactsthe current state of the blockchain network can include detecting a change in a number of authority nodes that are currently connected to the blockchain network, detecting a change in a number of validator nodes that are currently connected to the blockchain network, and / or detecting a change in a total amount of cryptocurrency that is currently being staked by validator nodes that are currently connected to the blockchain network. Comparing the current state of the blockchain network can be performed at the end of an epoch of the blockchain network. The blend of consensus protocols can include a blend of a proof of stake consensus protocol and a proof of authority consensus protocol. Applying the blend of consensus protocols that correspond to the predetermined condition can include accessing a slot data structure that includes a plurality of slots, with each slot being configured to maintain a reference to a respective node of the blockchain network. The plurality of slots can include a first portion of slots that are reserved for nodes of a first consensus group, and a second portion of slots that are reserved for nodes of a second consensus group. The first portion of slots and the second portion of slots can be allocated according to a weighting determination that is associated with predetermined condition. A respective node that belongs to the first consensus group can be assigned to each of the slots in the first portion of slots, according to a selection process for the first consensus group. A respective node that belongs to the second consensus group can be assigned to each of the slots in the second portion of slots, according to a selection process for the second consensus group. The first consensus group can include proof of stake nodes, and the second consensus group can include proof of authority nodes. The selection process for the first consensus group can include an auction-based process, and the selection process for the second consensus group can include a non-auction-based process. One or more slots that reference nodes of the blockchain network that are to participate in a consensus protocol for adding a block to a blockchain of the blockchain network can be randomly selected from the slot data structure. Each of the slots can have an equal probability of being selected. The slot data structure can be maintained in memory of each node of the blockchain network. The systems, devices, program products, and processes described throughout this document can, in some instances, provide one or more of the following advantages. A blockchain network can dynamically adjust to changing conditions, and can apply asuitable blend of consensus protocols based on current conditions that exist in the network. Thus, the most beneficial aspects of multiple different protocols can be leveraged at appropriate times, ensuring optimal network security and performance. A fixed slotting architecture provides a computationally efficient mechanism for handling the weighting of nodes in a blended consensus mechanism. Further, during consensus, each slot of the fixed slotting architecture has an equal probability of selection, thus simplifying a node selection process.

[0011] Other features, aspects and potential advantages will be apparent from the accompanying description and figures.DESCRIPTION OF DRAWINGS

[0012] FIG. l is a conceptual diagram of an example system for determining an adjustable and blended consensus mechanism for blockchain validation.

[0013] FIGS. 2A-2D depict examples of blending consensus protocols and weighting nodes in a blockchain network.

[0014] FIG. 3 is a flow diagram of an example technique for blending consensus protocols and weighting nodes in a blockchain network.

[0015] FIG. 4 is a schematic diagram that shows an example of a computing system.

[0016] Like reference symbols in the various drawings indicate like elements.DETAILED DESCRIPTION

[0017] This document describes technology that can blend consensus protocols and that can determine node weightings in a blockchain network. In general, a current state of a blockchain network is determined, and off-chain information is optionally received from one or more information oracles. The current state of the blockchain network (possibly in view of the off-chain information) is compared to predetermined conditions specified in weighting condition data, a predetermined condition is identified that matches the current state of the blockchain network, and a blend of consensus protocols that correspond to the predetermined condition is applied. The applied blend of consensus protocols can be used by the blockchain network when validating blocks,until such time that a change is detected in the blockchain network that warrants a change in the blend of consensus protocols.

[0018] FIG. 1 is a conceptual diagram of an example system 100 for determining an adjustable and blended consensus mechanism for blockchain validation. In the present example, the system 100 includes a blockchain network including a plurality of computing nodes 110 that communicate and exchange data over network(s) 150 (e.g., including one or more LANs (local area networks), WANs (wide area networks), and / or the Internet), and that operate in concert to maintain a blockchain 120. One or more of the computing nodes 110 (e.g., network server(s) 1 lOn, which can be a regular node of the blockchain network, or can be a master node that is operated by an entity that is responsible for the blockchain network) can be used to perform operations for adjusting a blended consensus operation of the blockchain network. Optionally, at least some of the computing nodes 110 (e.g., network server(s) 1 lOn) can receive off-chain information from information sources (e.g., oracle(s) 140) that are not directly involved in maintaining the blockchain 120 (e.g., are not directly connected to the blockchain network), for use determining a suitable adjustment of the blended consensus mechanism.

[0019] The computing nodes 110 of the blockchain network (including the network server(s) 1 lOn) can each represent various forms of servers, including but not limited to network servers, web servers, application servers, or other suitable computing servers. Each of the nodes 110 can include one or more processors, memory devices, and storage devices. In the present example, the nodes 110 are configured as a peer-to- peer network, in which nodes can be flexibly added to or removed from the network over time. Each of the nodes 110 in the peer-to-peer blockchain network, for example, can directly communicate with other network nodes, and can participate in network functions, such as executing code (e.g., blockchain application software, smart contracts, etc.), broadcasting and validating blockchain transactions, generating new blocks of transactions, verifying generated blocks, and so forth. Further, each of the nodes 110 can maintain a separate copy of the blockchain 120, to ensure decentralization, robustness, and persistence of the blockchain network.

[0020] The blockchain 120, for example, can include a series of consecutively added and linked blocks (e.g., blocks 120a-n), with each block including one or more transactions that occurred in the blockchain over consecutive time windows of substantially similar durations (e.g., a fraction of a second, several seconds, or several minutes, depending on the type and configuration of the blockchain). Each block in the blockchain 120 can be linked to a previous block through a cryptographic hash. For example, block 120b can include a cryptographic hash of block 120a, block 120c can include a cryptographic hash of block 120b, block 120d can include a cryptographic hash of block 120c, and so forth, such that the data in a given block cannot be altered once it is added to the blockchain 120, without altering subsequent blocks.

[0021] In general, a consensus mechanism is a protocol that brings the nodes of a blockchain network into agreement on generating a new block of transactions, and adding the newly added block to a blockchain. For example, when a time window for adding a new block of transactions to the blockchain 120 (e.g., a block time) has elapsed, a consensus mechanism (e.g., a Proof of Stake (PoS) protocol, a Proof of Authority (PoA) protocol, or a blend of a PoS / PoA protocols) can be used by the nodes 110 of the blockchain network to select, from a group of eligible validator nodes (e.g., the nodes 1 lOa-z or a subset of the nodes), a single block generation node that is permitted to generate a new block of transactions, and multiple validator nodes that can individually validate the newly generated block. If consensus is reached among the validator nodes that the newly generated block is valid (e.g., a majority, a supermajority, a weighted majority, or another sort of consensus as specified by the consensus mechanism), the block can be finalized and added to the blockchain 120. Block generation nodes (and optionally, other validator nodes) can generally be rewarded with an amount of cryptocurrency for their roles in facilitating transactions and maintaining the blockchain network.

[0022] In the present example, the blockchain 120 can be associated with various code and data that can be used for determining and executing an adjustable and blended consensus mechanism for blockchain validation. For example, the blockchain 120 can include authority nodes data 122, staking nodes data 124, weighting code 126, and weighting condition data 128. As another example, the authority nodes data 122,staking nodes data 124, weighting code 126, and weighting condition data 128 can be maintained off the blockchain 120, and accessible to a master node that is operated by an entity that is responsible for the blockchain network (e.g., network server(s) 1 lOn).

[0023] The authority nodes data 122 can include information for implementing a Proof of Authority (PoA) consensus protocol. In general, a PoA consensus protocol can involve selecting block generation nodes (and optionally, validator nodes for a newly generated block) from a relatively small pool of eligible validator nodes that may or may not each be associated with a staked amount of cryptocurrency. For example, a vetting process can be performed to ensure that operators of particular validator nodes of the nodes 110 are trustworthy. The vetting process, for example, can include determining the real-world identity of a node operator, performing an assessment of whether the operator is a reputable individual (e g., based on a background check, etc ), and assigning the node operator a reputation score based on the performed assessment. As another example, the vetting process can include determining whether the node operator also operates a validator node on a blockchain network other than the present blockchain network, evaluating the performance of the operator’s validator node on the other blockchain network, and assigning a reputation score based on the evaluated performance. After performing the vetting process and assigning an initial reputation score, for example, the node operator’s reputation score can subsequently be adjusted over time based on the performance of the validator node (e.g., uptime, network connection quality, generated blocks that are confirmed by other validator nodes, etc.), with positive performance resulting in a positive adjustment of the node operator’s score, and with negative performance resulting in a negative adjustment of the node operator’ s reputation score.

[0024] The staking nodes data 124 can include information for implementing a Proof of Stake (PoS) consensus protocol. In general, a PoS consensus protocol can involve selecting block generation nodes (and optionally, validator nodes for a newly generated block) from a relatively large pool of validator nodes that are each associated with a staked amount of cryptocurrency. For example, a minimum amount of staked cryptocurrency can be specified through a configuration of the blockchain network for a node to be eligible as a validator node. As another example, a probability of a nodebeing selected from a pool of eligible validator nodes can be proportional to an amount of cryptocurrency staked by the node.

[0025] In general, the PoA consensus protocol can provide a simpler implementation, faster transactions, and more centralized control, whereas the PoS consensus protocol can provide better decentralization and can offer participation in blockchain network operations to a larger pool of eligible validator nodes. Since acquiring and staking cryptocurrency on a blockchain network can involve significant financial resources (and since a node may potentially be penalized through the loss of staked cryptocurrency for unreliable actions on the blockchain, such as excessive downtime, poor network connection quality, generated blocks that are not confirmed by other validator nodes, etc.), the PoS consensus protocol may generally be suitable for blockchain networks in which acquiring a significant portion of the staked cryptocurrency (and thus potentially gaining network control) is difficult due to practical limitations. On the other hand, the PoA consensus protocol may generally be suitable for permissioned blockchain networks, or newly established blockchain networks in which a significant amount of cryptocurrency is not yet being staked throughout a wide pool of eligible validator nodes.

[0026] The weighting code 126 and the weighting condition data 128 can together be used to configure an adjustable and blended consensus mechanism for performing validation of blocks in a blockchain. For example, the weighting code 126 and the weighting condition data 128 can be implemented through a smart contract specified on the blockchain 120 and executed by one or more of the nodes 110 of the blockchain. As another example, the weighting code 126 and the weighting condition data 128 can be off-chain, and a master node that is operated by an entity that is responsible for the blockchain network (e.g., network server(s) 1 lOn) can execute the weighting code 126 in view of the weighting condition data 128. Configuring the adjustable and blended consensus mechanism through execution of the weighting code 126 and in view of the weighting condition data 128 can generally involve determining a current state of a blockchain network, optionally receiving off-chain information from one or more oracles 140, comparing the current state of the blockchain network (possibly in view of the off-chain information) to predetermined conditions specified in the weightingcondition data 128, identifying a predetermined condition that matches the current state of the blockchain network, and applying a blend of consensus protocols that correspond to the predetermined condition. The applied blend of consensus protocols (e.g., a blend of a PoS consensus protocol and a PoA consensus protocol) can be used by the blockchain network when validating blocks, until such time that a change is detected in the blockchain network that warrants a change in the blend of consensus protocols. Thus, the system 100 can dynamically adjust to changing conditions of a blockchain network in real time, and can apply suitable blends of consensus protocols based on current conditions - thereby leveraging the most beneficial aspects of different protocols and ensuring optimal network security and performance.

[0027] FIG. 1 also shows an example illustrative process for determining an adjustable and blended consensus mechanism for blockchain validation in the system 100, as represented in example stages (A) to (E). Stages (A) to (E) may occur in the illustrated sequence, or they may occur in a sequence that is different than in the illustrated sequence, and / or two or more stages (A) to (E) may be concurrent. In some examples, one or more stages (A) to (E) may be repeated multiple times when determining an adjustable and blended consensus mechanism.

[0028] During stage (A) (e.g., including stage (Ai) and / or stage (A2)), various updates to a blockchain network can occur that may impact one or more consensus protocols used by the blockchain network. In general, updates to a blockchain network (e.g., updates 160, 162) can occur over time, as nodes join the blockchain network, as nodes leave the blockchain network, as nodes experience a change in status (e.g., being added to or removed from a pool of eligible validator nodes, successfully completing a vetting process for becoming an authority node for participation in a PoA protocol, experiencing an adjustment in a reputation score, increasing or decreasing a staked amount of cryptocurrency, or another sort of change). As updates occur, data that reflects the updates can be added to the blockchain 120 such that the nodes 110 of the blockchain network can appropriately respond the changes and adjust the blended consensus mechanism being used within the blockchain network.

[0029] During stage (Ai), for example, update 160 can occur that impacts a Proof of Authority (PoA) protocol used by the blockchain network. Updates that impact thePoA protocol generally include events that indicate that an authority node (e.g., a node that has been vetted as an eligible validator node in a PoA protocol) has joined or left the blockchain network, events that indicate that an operator of a regular node has successfully passed a vetting process and that the regular node is being promoted to an authority node, events that indicate that an operator’s reputation score has dropped below a threshold value and that the operator’s authority node is being demoted to a regular node, and other relevant events. In the present example, the update 160 can include an indication that an authority node (e.g., node 110c) has joined the blockchain network, which currently includes other authority nodes (e.g., nodes 110a and 110b) that may participate in a PoA protocol for performing consensus operations.

[0030] During stage (A2), for example, an update 162 can occur that impacts a Proof of Stake (PoS) protocol used by the blockchain network. Updates that impact the PoS protocol generally include events that indicate that an eligible validator node (e.g., a node that is associated with a staked amount of cryptocurrency in the blockchain network) has joined or left the blockchain network, events that indicated that an amount of cryptocurrency currently being staked by an eligible validator note has increased or decreased, and other relevant events. In the present example, the update 162 can include an indication that, in addition to currently staked validator nodes 1 lOx, 1 lOy, and 1 lOz, additional staked validator nodes 1 lOu, 1 lOv, and 1 lOw have joined the blockchain network and may participate in a PoS protocol for performing consensus operations.

[0031] During stage (B), a network change 164 can be detected by one or more nodes 110 of the blockchain network. In general, network changes can be detected in response to updates (e.g., updates 160, 162) having occurred and / or can be detected during a polling process that occurs at suitable recurring intervals (e.g., every minute, every ten minutes, every hour, every four hours, every day, every epoch, or another interval). In the present example, network server(s) 1 lOn (e.g., a staked validator node and / or authority node of the blockchain network, or a master node that is operated by an entity that is responsible for the blockchain network) can detect the network change 164 that reflects the updates 160, 162.

[0032] During stage (C), network weightings 166 can be evaluated and possibly modified by one or more nodes 110 of the blockchain. In general, the networkweightings 166 can include a consensus protocol weighting for each of the multiple different consensus protocols used by the blockchain network, and a node weighting for each of the nodes that contribute to each respective protocol. The consensus protocol weighting can correspond to a proportional amount of control over the blockchain network that is collectively given to nodes that participate in a particular consensus protocol, and the node weightings can correspond to proportional amounts of control that are given to particular nodes that participate in the particular consensus protocol.

[0033] In some implementations, the node weightings can be used to select a block generation node and / or one or more validator nodes that are to participate in a consensus process. For example, the node weightings can be expressed as percentage values that correspond to likelihoods that particular nodes will be selected, and a random number generator can be used to select the node(s).

[0034] In some implementations, the node weightings can be used to determine whether a generated block passes validation consensus. For example, the node weightings of various different nodes that indicate that a generated block is valid can be aggregated when performing a validation consensus process, and the generated block can be finalized when the aggregated node weightings meet a predetermined threshold value (e.g., a 51% aggregated node weighting, a 65% aggregated node weighting, or another suitable value). Thus, some nodes can be given more control over the blockchain network than other nodes, according to their respective node weightings.

[0035] Referring now to FIG. 2A, an example of blending consensus protocols and weighting nodes in a blockchain network is depicted. In general, nodes can be weighted differently according to a current condition of the blockchain network, which can change over time. In the present example, and as shown with respect to a weighting determination 200c, under “Condition C” (e.g., a state of the blockchain network that existed before the addition of authority node 110c and staked validator nodes 1 lOu, 1 lOv, and 1 lOw), nodes that participate in a Proof of Authority (PoA) protocol were collectively given a 50% weight, and nodes that participate in a Proof of Stake (PoS) protocol were collectively given a 50% weight. The portion of network control that was given to nodes that participate in the PoA protocol (e.g., 50%) can either be distributed evenly among all connected authority nodes (e.g., with a possibility of nocryptocurrency being staked by any of the authority nodes), or can be distributed among the authority nodes according to an amount of cryptocurrency staked by each of the connected authority nodes. In the present example, each of the authority nodes that had been participating in the PoA protocol (e.g., node 110a and 110b) each had a same number of staked tokens (e.g., 10 tokens) and are thus were each assigned a 25% control of the blockchain network. The portion of network control that was given to nodes that participate in the PoS protocol (e.g., 50%) can generally be distributed among the staked validator nodes according to a proportion of cryptocurrency staked by each of the validator nodes, relative to a total amount staked among all connected validator nodes. In the present example, the staked validator nodes that had been participating in the PoS protocol (e.g., nodes 1 lOx, 1 lOy, and 1 lOz) respectively had 20 tokens, 20 tokens, and 10 tokens staked, are thus were proportionally assigned a 20%, 20%, and 10% control of the blockchain network. As another example, an amount of time that the cryptocurrency has been staked can be used as a factor for determining node weights, with a determined weight being generally proportional to the amount of time the cryptocurrency has been staked.

[0036] With the network change 164 (shown in FIG. 1), for example, the current state of the blockchain network can be such that a different blend of consensus protocols may now be appropriate. When evaluating the weightings (e.g., during stage (C), shown in FIG. 1), the network server(s) 1 lOn can compare the current state of the blockchain network to each of the predetermined conditions defined in the weighting condition data 128 (e.g., Conditions A-E, also shown in FIG. 1).

[0037] In some implementations, the predetermined conditions can include one or more conditions that are related to the nodes that are currently present in a pool of nodes that are available for possible selection for participation in a consensus protocol. For example, a number of authority nodes that are currently connected to the blockchain network, a number of eligible validator nodes that are currently connected to the blockchain network, a total amount cryptocurrency that is currently being staked among connected nodes, an amount of time the cryptocurrency has been staked, a distribution of cryptocurrency that is staked across connected nodes, a total amount of time that the blockchain network has been operating, and / or other suitable factors can be used definethe current state of the blockchain network and can be compared against the weighting condition data 128. As a more specific example, the weighting condition data 128 can specify multiple staking ratio tiers that indicate a percentage of circulating tokens currently being staked (e.g., 10%, 20%, 30%, etc.), with each staking ratio tier being associated with a different relative weighting of PoA and PoS nodes. In general, a staking ratio tier that indicates a greater percentage of staked tokens can be associated with a greater relative weighting of a collective group of PoS nodes, whereas a staking ratio tier that indicates a lesser percentage of staked tokens can be associated with a lesser relative weighting of the collective group of PoS nodes. If a network change has occurred that warrants a different blend of consensus protocols, the change can be determined and node weightings can be appropriately updated.

[0038] In the present example of FIG. 2A, and as shown with respect to a weighting determination 200d, a number of authority nodes has increased (e.g., with the addition of authority node 110c), a number of staked validator nodes has also increased (e.g., with the addition of staked validator nodes 1 lOu, 1 lOv, and 1 lOw), and a total number of staked tokens has increased from 70 to 750. Thus, in the present example, a different network condition exists (e.g., “Condition D”), and different consensus protocol weightings can apply to the current network condition. For the current network condition (e.g., “Condition D”), nodes that participate in a Proof of Authority (PoA) protocol are collectively given a 30% weight, and nodes that participate in a Proof of Stake (PoS) protocol are collectively given a 70% weight. Further, the portion of network control that is given to nodes that are currently participating in the PoA protocol (e.g., 30%) can either be distributed evenly among the authority nodes (e.g., with a possibility of no cryptocurrency being staked by any of the authority nodes), or can be distributed among the authority nodes according to a proportion of cryptocurrency staked by each of the authority nodes. In the present example, node 110a has ten staked tokens (and thus receives 5% control), node 110b also has ten staked tokens (and thus also receives 5% control), and node 110c has forty staked tokens (and thus receives 20% control). The portion of network control that is given to nodes that participate in the PoS protocol (e.g., 70%) can generally be distributed among the staked validator nodes according to a proportion of cryptocurrency staked by each of the validator nodes. Inthe present example, the staked validator nodes that are currently participating in the PoS protocol (e.g., nodes HOu, HOv, HOw, HOx, I lOy, and HOz) respectively have 150 tokens, 200 tokens, 200 tokens, 120 tokens, 20 tokens, and 10 tokens, are thus are respectively assigned a 15%, 20%, 20%, 12%, 2%, and 1% control of the blockchain network. The impact of the updated weighting determination in the present example is to effectively increase the collective amount of network control given to staked validator nodes as the number of participating nodes and / or the amount of staked cryptocurrency increases. However, if the number of staked validator nodes and / or the amount of staked cryptocurrency were to decrease at a later point in time, the collective network control could shift back to the authority nodes.

[0039] Referring now to FIGS. 2B-2C, another example of blending consensus protocols and weighting nodes (including a fixed slotting architecture for weighting nodes) is shown. In general, for a blockchain network in which a blended consensus mechanism is used, when the weight of a node of one consensus group is changed (and / or when nodes are added to or removed from a validator pool for one consensus group), the weight of nodes of the other consensus group is also to be adjusted, in order to maintain a target collective weight for nodes of each consensus group. For a blockchain network that uses a blended consensus mechanism that involves both Proof of Authority (PoA) nodes and Proof of Stake (PoS) nodes, for example, the PoS nodes can each be assigned a weight that is proportional to an amount of tokens staked by the respective PoS node. Weights for the PoA nodes can be set to appropriate values such that a collective weight of the PoA nodes meets a target value that reflects a percentage of network control to be given to the PoA nodes in view of a current state of the blockchain network. However, if any of the PoS nodes were to increase or decrease an amount of staked tokens, and / or if a number of PoS nodes were to change, the collective weight of the PoS nodes would also change, thus potentially leading to a change in the percentage of network control given to the collective PoS nodes and the collective PoA nodes - unless the weight of each PoA node were to be also adjusted to compensate for the change in collective weight of the PoS nodes. The fixed slotting architecture described herein provides a computationally efficient mechanism for handling the weighting of nodes in a blended consensus mechanism, such that the weight of nodes ofa first consensus group are not recomputed in response to a change in weight of nodes of a second consensus group, while maintaining a target percentage of control given to nodes of each consensus group.

[0040] In the present example of FIG. 2B, a slot data structure 210 includes a set of slots, with each slot being configured to maintain a reference to a blockchain node (e.g., node identification data) that is eligible for selection for participation in a consensus protocol. The slot data structure 210, for example, can be implemented as a data structure (e.g., an array, a fixed size set, a map, or another suitable sort of data structure) that is configured to map slots (e.g., data structure elements) to validator node identifiers, and that is maintained in memory of the validator nodes of a blockchain network and / or that is persisted on-chain. The slot data structure 210 in the present example includes twenty slots, however other examples may include fewer slots or more slots (e.g., hundreds or thousands of slots). In general, blockchain nodes of multiple different consensus groups (e.g., two or more) can be selected, according to the selection criteria of their respective groups, for inclusion in one or more slots of a slot data structure. For example, the active validator nodes of a blockchain network can periodically (e.g., once per epoch, which can be defined as a number of rounds of consensus that may be performed in an amount of time such as several hours or days) execute code to assign nodes to the slots of the slot data structure 210. During consensus, each slot in the slot data structure 210 has an equal probability of selection, thus simplifying a node selection process.

[0041] Continuing the present example of FIG. 2B, for a current weighting determination (e.g., weighting determination 200d, shown in FIG. 2A), a group of PoA nodes 212 can be assigned a portion of the slots in the slot data structure 210 (e g., 30%, or six out of the twenty slots), and a group of PoS nodes 214 can be assigned another portion of the slots in the slot data structure 210 (e.g., 70%, or fourteen out of the twenty slots). The PoA nodes 212, for example, can be non-staking nodes that have each been vetted and that are each to have an equal probability of participation in consensus in the blockchain network. Thus, in the present example, each of the PoA nodes 212 (e.g., Node A, Node B, and Node C) can be assigned two of the six slots. The PoS nodes 214, for example, can be nodes that are each associated with an amount of tokens staked onthe blockchain network, and that are each to participate in consensus in the blockchain network with a frequency that corresponds to the amount of staked tokens (e.g., with nodes having a relatively greater amount of staked tokens having a greater probability of participating in consensus in a given round, and with nodes having a relatively lesser amount of staked tokens having a lesser probability of participating in consensus in a given round).

[0042] In the present example of FIG. 2B, a total amount of staked weight (e.g. an amount of staked tokens) can be seven hundred, with Node U staking one hundred fifty tokens (e.g. 21% of the staked weight), Node V staking two hundred tokens (e.g., 29% of the staked weight), Node W staking two hundred tokens (e.g., 29% of the staked weight), Node X staking one hundred twenty staked tokens (e.g., 17% of the staked weight), Node Y staking twenty tokens (e.g., 3% of the staked weight, and Node Z staking ten tokens (e.g., 1% of the staked weight). Each of the slots in the present example that are reserved for PoS nodes (e.g., slots 7-20) corresponds to approximately 7% of the staked weight - thus, Node U is assigned three slots, Node V is assigned four slots, Node W is assigned four slots, and Node X is assigned three slots (e.g., by assigning the PoS nodes to PoS slots in proportion to the staking weight percentages of the nodes, with possible rounding). It is to be noted in the present example that neither Node Y nor Node Z has been assigned to a slot, as the staking weight percentages of these nodes is insufficient to warrant a slot assignment (e.g., with the staking weight percentages of these nodes being significantly under 7% of the staked weight, which is the percentage that is sufficient for assignment to a slot in the present example).Through the assignment of slots based on the staking weight percentages of the PoS nodes 216, for example, the amount of tokens needed for consensus participation can have a dynamically adjusted minimum amount rather than fixed minimum amount, with low-staking nodes potentially being removed from participation in a consensus protocol in response to an increase in a total amount of tokens staked by other nodes across the blockchain network.

[0043] Referring now to FIG. 2C, the example of blending consensus protocols and weighting nodes (including the fixed slotting architecture for weighting nodes) is continued. In the present example of FIG. 2C, a slot data structure 220 (e.g., similar tothe slot data structure 210, shown in FIG. 2B) is updated to reflect a change in one or more potential validator nodes of the blockchain network. For example, a group of PoA nodes 222 can remain unchanged from the group of PoA nodes 212 (shown in FIG. 2B), whereas a group of PoS nodes 224 can reflect one or more changes relative to the group of PoS nodes 214 (also shown in FIG. 2A). In general, changes to a group of nodes can include the addition of one or nodes, the removal of one or more nodes, and / or a change in weight associated with one or more nodes. The change to the group of PoS nodes 214, for example, include an increased staking weight for Node V (e.g., from two hundred tokens to three hundred tokens), an increased staking weight for Node X (e.g., from one hundred twenty tokens to one hundred fifty tokens), and a decreased staking weight for Node Z (e.g., from ten tokens to zero tokens, which results in the node being removed from the group of PoS nodes 224). The net change in staking weight for the PoS nodes in the present example is an increase from seven hundred tokens (as shown in FIG. 2B) to eight hundred twenty tokens (as shown in FIG. 2C).

[0044] Continuing the present example of FIG. 2C, at least a portion of the node reference data in the slot data structure 220 is updated. In response to detecting the change to the group of PoS nodes 224, for example, a portion of the slots in the slot data structure 220 that are reserved for PoS nodes can be updated, without updating the portion of the slots in the slot data structure 220 that are reserved for PoA nodes. In the present example, the reference data in the slot data structure 220 can be updated to reflect the updated staking weight percentages for the group of PoS nodes 224, with Nodes U and X each again being associated with three slots, with Node V (which had undergone a staking weight percentage increase from 29% to 37%) now being associated with five slots (up from four), and with Node W (which had not undergone an absolute staking weight change, but had undergone a staking weight percentage decrease from 29% to 24% due to changes in staking weight by other nodes) now being associated with three slots (down from four). As shown in the present example, the updates to the portion of the slots in the slot data structure 220 that are reserved for PoS nodes can be performed independently of the portion of the slots in the data structure 220 that are reserved for PoA nodes. In the present example, no adjustments in weighting of the PoA nodes is needed to be performed, as the designated percentage ofcontrol delegated to the group of PoA nodes 222 is seamlessly maintained through the fixed slotting architecture. Thus, changes to the weighting of the group of PoS nodes 224 (which is based on token staking amounts and is generally more frequent in comparison to the relatively stable group of PoA nodes 222) can be accomplished without rebalancing weights for all of the nodes, thereby conserving processing resources of the validator nodes and decreasing processing times for handling network changes.

[0045] Referring now to FIG. 2D, another example of blending consensus protocols and weighting nodes is shown, including a fixed slotting architecture for weighting nodes, and including an auction-based selection process for at least some of (or optionally, all of) the nodes that are to be included in a pool of nodes that are available for potential selection for participation in a consensus protocol. An auctionbased selection process, for example, can be used instead of (or in addition to) a staking- based (e.g., a PoS) selection process, such that winning bids can be used to gain participation in a consensus protocol rather than a staked amount of tokens. In the present example of FIG. 2D, a slot data structure 230 (e g., similar to the slot data structures 210 and 220 of respective FIGS. 2B and 2C) is configured to maintain references to various blockchain nodes that are available for selection in a consensus protocol. Similar to the slot data structures 210 and 220 of respective FIGS. 2B and 2C, for example, the slot data structure 230 includes twenty slots, however other examples may include fewer slots or more slots. In the present example (and similar to the previous examples), a portion of the slots (e.g., 30%, or six out of the twenty slots) are reserved for PoA nodes belonging to a group of PoA nodes 232 (e.g., Node A, Node B, and Node C), and another portion of the slots (e.g., 70%, or fourteen out of the twenty slots) are reserved for a group of auction winning nodes 234 that are selected for inclusion in one or more of the slots based on the results of an auction.

[0046] In general, an auction can be periodically performed (e.g., once per epoch, or at another suitable frequency) by receiving bids (e.g., an amount of tokens) in association with various potential validator nodes, with the nodes that are associated with the winning bids being selected for inclusion in the slots. Token amounts for winning bids can appropriately disposed of or transferred (e.g., burned, transferred to aparticular account, distributed to validator nodes that participate in a consensus protocol during the epoch, etc.), for example, whereas token amounts for losing bids can be returned to the entities that placed the bids. The group of PoA nodes 232 in the present example and their weightings (e.g., an equal weighting for each node, or another sort of weighting scheme) are likely to be stable over multiple epochs, whereas the group of auction winning nodes 234 is likely to change from epoch to epoch. As in the other examples of blending consensus protocols and weighting nodes, the updates to the portion of the slots in the slot data structure 230 that are reserved for the group of auction winning nodes 234 can be performed independently of the portion of the slots in the slot data structure 230 that are reserved for PoA nodes.

[0047] Continuing the present example of FIG. 2D, various nodes can each be associated with one or more corresponding bids for inclusion in a slot in slot data structure 230. After the bids have been submitted (e.g., through a smart contract of the blockchain network), auction code can be executed (e.g., by the validator nodes of the blockchain network), and the nodes corresponding to the winning bids can be selected for representation in the slots in the slot data structure 230 that are reserved for the auction winning nodes. In some implementations, each node can be associated with a single bid and may potentially be represented in a single slot (e.g., if the single bid is a winning bid), whereas in other implementations, each node can be associated with multiple separate bids and may potentially be represented in multiple different slots. In the present example, Node U is associated with separate bids of ten tokens, seven tokens, five tokens, and three tokens, with the bids of ten, seven, and three tokens being winning bids, and with the bid of three tokens being a losing bid. Thus, in the present example, Node U is represented (e.g., through node identification data) in three different slots (e.g., slot seven, slot eleven, and slot 16). Similarly, Node V, Node X, Node Y, Node W, Node Q, Node R, and Node S in the present example are each represented in one or more slots of the slot data structure 230 due to being associated with one or more winning bids (e.g., the top X number of bids, where X is the number of available slots - in this case, the top fourteen bids, or bids of at least four tokens). In the present example, nodes that are not associated with any winning bids (e.g., bids of under fourtokens) are not associated with any of the slots in the slot data structure 230 that are reserved for the auction winning nodes.

[0048] While the examples of FIGS. 2B, 2C, and 2D each show a fixed slotting architecture for weighting nodes, in which two different consensus protocols are blended, it is to be appreciated that any number of different consensus protocols can be blended through use of the fixed slotting architecture. In general, use of the fixed slotting architecture can involve specifying a total number of slots to be included in the data structure, reserving a respective portion of the slots to include representations of nodes that belong to each consensus group, and performing a selection operation (e.g., direct assignment for PoA, proportional weight-based selection for PoS, auction-based selection, etc.) to select particular nodes from each consensus group, and associating slots with the selected nodes. Modifying the control percentages of different consensus groups for participation in an overall consensus protocol, for example, can simply involve modifying the portion of slots in the fixed slotting architecture that are reserved for each consensus group.

[0049] In some implementations, off-chain information can be used as a factor in evaluating consensus protocol weightings for each of the multiple different consensus protocols used by the blockchain network. Referring again to FIG. 1, during stage (D), off-chain information 168 can optionally be received from the oracle(s) 140 (e.g., network servers, web servers, application servers, or other suitable computing servers that provide the off-chain information 168). In general, the off-chain information 168 is information that cannot be directly determined by the blockchain network by analyzing the on-chain state of the blockchain 120, but can be useful in determining appropriate consensus protocol weightings. For example, the oracle(s) 140 can reference one or more cryptocurrency exchanges to determine a current value in a fiat currency of the cryptocurrency that is currently being staked by the validator nodes in the blockchain network. In the present example, the current value in fiat currency can be compared to the weighting condition data 128 to determine a current condition of the blockchain that exists, and to determine which consensus protocol weighting to apply when blending the different consensus protocols and weighting individual nodes. In general, a higher fiat value of staked cryptocurrency can trigger a greater proportional weighting of a Proof ofStake (PoS) protocol, whereas a lower fiat value can trigger a lesser proportional weighting of the PoS protocol, and a shift to a Proof of Authority (PoA) protocol.

[0050] As shown in the present example, the weighting condition data 128 includes a sliding scale of consensus protocol weightings, with different weights being given to collective nodes that participate in a Proof of Authority (PoA) protocol, and collective nodes that participate in a Proof of Stake (PoS) protocol, according to current conditions of the blockchain network. For example, a 90 / 10 PoA / PoS blend can be applied when “Condition A” exists, a 70 / 30 PoA / PoS blend can be applied when “Condition B” exists, a 50 / 50 PoA / PoS blend can be applied when “Condition C” exists, a 30 / 70 PoA / PoS blend can be applied when “Condition D” exists, and a 10 / 90 PoA / PoS blend can be applied when “Condition E” exists. Other examples can be more or less granular, with an option of a PoA protocol or a PoS protocol being solely used under some conditions.

[0051] During stage (E), updated weightings 170 can be provided for applying on the blockchain network. For example, the weightings 170 can be added to the blockchain 120 and / or can be provided as off-chain configuration data that is referenced by validator nodes of the blockchain network, and can be referenced by the blockchain nodes 110 when selecting one or more nodes for participating in a consensus protocol for generating a new block (and optionally, for validating newly generated blocks). For implementations in which a fixed slotting architecture is employed for weighting nodes, for example, node selection can include executing a random number generator that is configured to generate random number that ranges across the number of slots in the fixed slotting architecture, with each slot having an equal probability of selection. In the present example, the updated weightings 170 can include the weighting determination 200d, which specifies that PoA nodes are to collectively have 30% control of the blockchain network, and that PoS nodes are to collectively have 70% control of the blockchain network. As conditions change in the blockchain network over time, the weighted blending of consensus protocols used by the network can change, to appropriately adapt to the changing conditions. Although the present example relates to an automated blending of consensus protocols and weighting nodes in a blockchain network, it will be understood that in other examples, an entity that is responsible for theblockchain network can manually select an appropriate blending of consensus protocols, and provide the manual selection for implementation on the blockchain network.

[0052] FIG. 3 is a flow diagram of an example technique 300 for blending consensus protocols and weighting nodes in a blockchain network. The example technique 300 can be performed by any of a variety of appropriate computing devices, such as by the computing nodes 110 of the blockchain network described throughout this document. Additionally, the example technique 300 can be performed as part of the process stages (A)-(E) that are described above with respect to FIG. 1, and will be described as such for clarity.

[0053] A current state of a blockchain network is determined (302). For example, during stage (B), one or more nodes 110 of a blockchain network can determine a current state of the blockchain network, that reflects a detected network change (e.g., network change 164), and that is based on various network updates that may occur over time (e.g., the authority update 160 and the staking update 162).

[0054] The current state of the blockchain network is compared to a set of predetermined conditions (304), and a predetermined condition that matches a current state of the blockchain network is identified (306). For example, during stage (C), the one or more nodes 110 of the blockchain network can compare the blockchain network’s current state to various conditions specified in the weighting condition data 128, and can identify a predetermined condition (also described with respect to FIG. 2A) that matches the blockchain network’s current state. Optionally, the comparison can involve off- chain information 168 received from one or more oracles 140 (e.g., during stage (D)).

[0055] A blend of consensus protocols that correspond to the predetermined condition is applied (308). For example, during stage (E), the one or more nodes 110 can apply the updated weightings 170 for use in selecting nodes for participation in a consensus protocol of the blockchain network. Optionally, a fixed slotting architecture is employed (310). For example, the one or nodes 110 can employ any of the slotting architectures described with respect to FIGS. 2B-2D to weight nodes of various different consensus groups (e.g., PoA nodes, PoS nodes, etc.) for selection.

[0056] One or more nodes of the blockchain network are selected for participation in a consensus mechanism (312). For example, the one or more nodes 110can select, from a pool of available nodes (e.g. the nodes 110), a set of validator nodes that are to perform a consensus protocol for validating and adding a new block to the blockchain 120. The nodes 110, for example, can include nodes of the various different consensus groups (e.g., PoA nodes, PoS nodes, etc.).

[0057] FIG. 4 is a schematic diagram that shows an example of a computing system 400 that can be used to implement the techniques described herein. The computing system 400 includes one or more computing devices (e.g., computing device 410), which can be in wired and / or wireless communication with various peripheral device(s) 480, data source(s) 490, and / or other computing devices (e.g., over network(s) 470). The computing device 410 can represent various forms of stationary computers 412 (e.g., workstations, kiosks, servers, mainframes, edge computing devices, quantum computers, etc.) and mobile computers 414 (e g., laptops, tablets, mobile phones, personal digital assistants, wearable devices, etc.). In some implementations, the computing device 410 can be included in (and / or in communication with) various other sorts of devices, such as data collection devices (e.g., devices that are configured to collect data from a physical environment, such as microphones, cameras, scanners, sensors, etc.), robotic devices (e.g., devices that are configured to physically interact with objects in a physical environment, such as manufacturing devices, maintenance devices, object handling devices, etc.), vehicles (e.g., devices that are configured to move throughout a physical environment, such as automated guided vehicles, manually operated vehicles, etc.), or other such devices. Each of the devices (e.g., stationary computers, mobile computers, and / or other devices) can include components of the computing device 410, and an entire system can be made up of multiple devices communicating with each other. For example, the computing device 410 can be part of a computing system that includes a network of computing devices, such as a cloud-based computing system, a computing system in an internal network, or a computing system in another sort of shared network. Processors of the computing device (410) and other computing devices of a computing system can be optimized for different types of operations, secure computing tasks, etc. The components shown herein, and their functions, are meant to be examples, and are not meant to limit implementations of the technology described and / or claimed in this document.

[0058] The computing device 410 includes processor(s) 420, memory device(s) 430, storage device(s) 440, and interface(s) 450. Each of the processor(s) 420, the memory device(s) 430, the storage device(s) 440, and the interface(s) 450 are interconnected using a system bus 460. The processor(s) 420 are capable of processing instructions for execution within the computing device 410, and can include one or more single-threaded and / or multi-threaded processors. The processor(s) 420 are capable of processing instructions stored in the memory device(s) 430 and / or on the storage device(s) 440. The memory device(s) 430 can store data within the computing device 410, and can include one or more computer-readable media, volatile memory units, and / or non-volatile memory units. The storage device(s) 440 can provide mass storage for the computing device 410, can include various computer-readable media (e.g., a floppy disk device, a hard disk device, a tape device, an optical disk device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations), and can provide date security / encryption capabilities.

[0059] The interface(s) 450 can include various communications interfaces (e.g., USB, Near-Field Communication (NFC), Bluetooth, WiFi, Ethernet, wireless Ethernet, etc.) that can be coupled to the network(s) 470, peripheral device(s) 480, and / or data source(s) 490 (e.g., through a communications port, a network adapter, etc.). Communication can be provided under various modes or protocols for wired and / or wireless communication. Such communication can occur, for example, through a transceiver using a radio-frequency. As another example, communication can occur using light (e.g., laser, infrared, etc.) to transmit data. As another example, short-range communication can occur, such as using Bluetooth, WiFi, or other such transceiver. In addition, a GPS (Global Positioning System) receiver module can provide location- related wireless data, which can be used as appropriate by device applications. The interface(s) 450 can include a control interface that receives commands from an input device (e.g., operated by a user) and converts the commands for submission to the processors 420. The interface(s) 450 can include a display interface that includes circuitry for driving a display to present visual information to a user. The interface(s) 450 can include an audio codec which can receive sound signals (e.g., spokeninformation from a user) and convert it to usable digital data. The audio codec can likewise generate audible sound, such as through an audio speaker. Such sound can include real-time voice communications, recorded sound (e.g., voice messages, music files, etc.), and / or sound generated by device applications.

[0060] The network(s) 470 can include one or more wired and / or wireless communications networks, including various public and / or private networks. Examples of communication networks include a LAN (local area network), a WAN (wide area network), and / or the Internet. The communication networks can include a group of nodes (e.g., computing devices) that are configured to exchange data (e.g., analog messages, digital messages, etc.), through telecommunications links. The telecommunications links can use various techniques (e.g., circuit switching, message switching, packet switching, etc.) to send the data and other signals from an originating node to a destination node. In some implementations, the computing device 410 can communicate with the peripheral device(s) 480, the data source(s) 490, and / or other computing devices over the network(s) 470. In some implementations, the computing device 410 can directly communicate with the peripheral device(s) 480, the data source(s), and / or other computing devices.

[0061] The peripheral device(s) 480 can provide input / output operations for the computing device 410. Input devices (e.g., keyboards, pointing devices, touchscreens, microphones, cameras, scanners, sensors, etc.) can provide input to the computing device 410 (e.g., user input and / or other input from a physical environment). Output devices (e.g., display units such as display screens or projection devices for displaying graphical user interfaces (GUIs)), audio speakers for generating sound, tactile feedback devices, printers, motors, hardware control devices, etc.) can provide output from the computing device 410 (e.g., user-directed output and / or other output that results in actions being performed in a physical environment). Other kinds of devices can be used to provide for interactions between users and devices. For example, input from a user can be received in any form, including visual, auditory, or tactile input, and feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback).

[0062] The data source(s) 490 can provide data for use by the computing device 410, and / or can maintain data that has been generated by the computing device 410 and / or other devices (e.g., data collected from sensor devices, data aggregated from various different data repositories, etc.). In some implementations, one or more data sources can be hosted by the computing device 410 (e.g., using the storage device(s) 440). In some implementations, one or more data sources can be hosted by a different computing device. Data can be provided by the data source(s) 490 in response to a request for data from the computing device 410 and / or can be provided without such a request. For example, a pull technology can be used in which the provision of data is driven by device requests, and / or a push technology can be used in which the provision of data occurs as the data becomes available (e.g., real-time data streaming and / or notifications). Various sorts of data sources can be used to implement the techniques described herein, alone or in combination.

[0063] In some implementations, a data source can include one or more data store(s) 490a. The database(s) can be provided by a single computing device or network (e.g., on a file system of a server device) or provided by multiple distributed computing devices or networks (e.g., hosted by a computer cluster, hosted in cloud storage, etc.). In some implementations, a database management system (DBMS) can be included to provide access to data contained in the database(s) (e.g., through the use of a query language and / or application programming interfaces (APIs)). The database(s), for example, can include relational databases, object databases, structured document databases, unstructured document databases, graph databases, and other appropriate types of databases.

[0064] In some implementations, a data source can include one or more blockchains 490b. A blockchain can be a distributed ledger that includes blocks of records that are securely linked by cryptographic hashes. Each block of records includes a cryptographic hash of the previous block, and transaction data for transactions that occurred during a time period. The blockchain can be hosted by a peer-to-peer computer network that includes a group of nodes (e.g., computing devices) that collectively implement a consensus algorithm protocol to validate new transaction blocks and to add the validated transaction blocks to the blockchain. By storing data across the peer-to-peer computer network, for example, the blockchain can maintain data quality (e.g., through data replication) and can improve data trust (e.g., by reducing or eliminating central data control).

[0065] In some implementations, a data source can include one or more machine learning systems 490c. The machine learning system(s) 490c, for example, can be used to analyze data from various sources (e.g., data provided by the computing device 410, data from the data store(s) 490a, data from the blockchain(s) 490b, and / or data from other data sources), to identify patterns in the data, and to draw inferences from the data patterns. In general, training data 492 can be provided to one or more machine learning algorithms 494, and the machine learning algorithm(s) can generate a machine learning model 496. Execution of the machine learning algorithm(s) can be performed by the computing device 410, or another appropriate device. Various machine learning approaches can be used to generate machine learning models, such as supervised learning (e.g., in which a model is generated from training data that includes both the inputs and the desired outputs), unsupervised learning (e.g., in which a model is generated from training data that includes only the inputs), reinforcement learning (e.g., in which the machine learning algorithm(s) interact with a dynamic environment and are provided with feedback during a training process), or another appropriate approach. A variety of different types of machine learning techniques can be employed, including but not limited to convolutional neural networks (CNNs), deep neural networks (DNNs), recurrent neural networks (RNNs), and other types of multi-layer neural networks. With respect to the technology described herein, the training data can include data that represents blockchain conditions (e.g., a number of eligible validation nodes, a staked amount of cryptocurrency, etc ), blockchain network performance over time, and possible malicious operations that are performed by blockchain nodes. The machine learning model that results from the machine learning algorithm(s) can be used to identify a particular consensus protocol that provides improved performance under a particular set of blockchain conditions. Use of the machine learning model can provide the benefit of an automated selection of an appropriate blending of consensus protocols in response to various different blockchain conditions.

[0066] Various implementations of the systems and techniques described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. A computer program product can be tangibly embodied in an information carrier (e.g., in a machine-readable storage device), for execution by a programmable processor. Various computer operations (e.g., methods described in this document) can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, by a computer to perform a certain activity or bring about a certain result. A computer program can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program product can be a computer- or machine-readable medium, such as a storage device or memory device. As used herein, the terms machine-readable medium and computer-readable medium refer to any computer program product, apparatus and / or device (e.g., magnetic discs, optical disks, memory, etc.) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term machine-readable signal refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0067] Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and can be a single processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data.Generally, a computer can also include, or can be operatively coupled to communicate with, one or more mass storage devices for storing data files. Such devices can include magnetic disks (e.g., internal hard disks and / or removable disks), magneto-optical disks, and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data can include all forms of non-volatile memory, including by way of example semiconductor memory devices, flash memory devices, magnetic disks (e.g., internal hard disks and removable disks), magneto-optical disks, and optical disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).

[0068] The systems and techniques described herein can be implemented in a computing system that includes a back end component (e.g., a data server), or that includes a middleware component (e g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). The computer system can include clients and servers, which can be generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0069] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of the disclosed technology or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular disclosed technologies. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment in part or in whole. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described herein as acting in certain combinations and / or initially claimed as such, one or more features from a claimed combination can insome cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination. Similarly, while operations may be described in a particular order, this should not be understood as requiring that such operations be performed in the particular order or in sequential order, or that all operations be performed, to achieve desirable results. Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method for blending consensus protocols and weighting nodes in a blockchain network, the computer-implemented method comprising: determining a current state of a blockchain network; comparing the current state of the blockchain network to a set of predetermined conditions; identifying a predetermined condition that matches the current state of the blockchain network; and applying a blend of consensus protocols that correspond to the predetermined condition.

2. The computer-implemented method of claim 1, wherein the current state of the blockchain is defined at least in part by a number of authority nodes that are currently connected to the blockchain network and that are configured to participate in a proof of authority consensus protocol.

3. The computer-implemented method of claim 1, wherein the current state of the blockchain network is defined at least in part by a number of validator nodes that are currently connected to the blockchain network and that are configured to participate in a proof of stake consensus protocol.

4. The computer-implemented method of claim 1, wherein the current state of the blockchain network is defined at least in part by a total amount of cryptocurrency that is currently being staked by validator nodes that are currently connected to the blockchain network.

5. The computer-implemented method of claim 1, further comprising: detecting a change to the blockchain network that impacts the current state of the blockchain network, wherein comparing the current state of the blockchain network tothe set of predetermined conditions is performed in response to detecting the change to the blockchain network.

6. The computer-implemented method of claim 5, wherein the change to the blockchain network that impacts the current state of the blockchain network comprises one or more of (i) detecting a change in a number of authority nodes that are currently connected to the blockchain network, (ii) detecting a change in a number of validator nodes that are currently connected to the blockchain network, and (iii) detecting a change in a total amount of cryptocurrency that is currently being staked by validator nodes that are currently connected to the blockchain network.

7. The computer-implemented method of claim 1, wherein comparing the current state of the blockchain network is performed at the end of an epoch of the blockchain network.

8. The computer-implemented method of claim 1, wherein the blend of consensus protocols includes a blend of a proof of stake consensus protocol and a proof of authority consensus protocol.

9. The computer-implemented method of claim 1, wherein applying the blend of consensus protocols that correspond to the predetermined condition comprises: accessing a slot data structure that includes a plurality of slots, with each slot being configured to maintain a reference to a respective node of the blockchain network, wherein the plurality of slots includes a first portion of slots that are reserved for nodes of a first consensus group, and a second portion of slots that are reserved for nodes of a second consensus group, wherein the first portion of slots and the second portion of slots are allocated according to a weighting determination that is associated with predetermined condition; and assigning, to each of the slots in the first portion of slots, a respective node that belongs to the first consensus group, according to a selection process for the first consensus group; and assigning, to each of the slots in the second portion of slots, a respective node thatbelongs to the second consensus group, according to a selection process for the second consensus group.

10. The computer-implemented method of claim 9, wherein the first consensus group includes proof of stake nodes, and the second consensus group includes proof of authority nodes.

11. The computer-implemented method of claim 9, wherein the selection process for the first consensus group includes an auction-based process, and the selection process for the second consensus group includes a non-auction-based process.

12. The computer-implemented method of claim 9, further comprising: randomly selecting, from the slot data structure, one or more slots that reference nodes of the blockchain network that are to participate in a consensus protocol for adding a block to a blockchain of the blockchain network, wherein each of the slots has an equal probability of being selected.

13. A system for blending consensus protocols and weighting nodes in a blockchain network, the system comprising a plurality of computer nodes, each computer node comprising: one or more processors, memory, and storage devices storing instructions that, when executed, cause the one or more processors to perform operations comprising: determining a current state of a blockchain network; comparing the current state of the blockchain network to a set of predetermined conditions; identifying a predetermined condition that matches the current state of the blockchain network; and applying a blend of consensus protocols that correspond to the predetermined condition.

14. The system of claim 13, the operations further comprising: detecting a change to the blockchain network that impacts the current state of the blockchain network, wherein comparing the current state of the blockchain network to the set of predetermined conditions is performed in response to detecting the change to the blockchain network.

15. The system of claim 13, wherein comparing the current state of the blockchain network is performed at the end of an epoch of the blockchain network.

16. The system of claim 13, wherein the blend of consensus protocols includes a blend of a proof of stake consensus protocol and a proof of authority consensus protocol.

17. The system of claim 13, wherein applying the blend of consensus protocols that correspond to the predetermined condition comprises: accessing a slot data structure that includes a plurality of slots, with each slot being configured to maintain a reference to a respective node of the blockchain network, wherein the plurality of slots includes a first portion of slots that are reserved for nodes of a first consensus group, and a second portion of slots that are reserved for nodes of a second consensus group, wherein the first portion of slots and the second portion of slots are allocated according to a weighting determination that is associated with predetermined condition; and assigning, to each of the slots in the first portion of slots, a respective node that belongs to the first consensus group, according to a selection process for the first consensus group; and assigning, to each of the slots in the second portion of slots, a respective node that belongs to the second consensus group, according to a selection process for the second consensus group.

18. The system of claim 17, the operations further comprising: randomly selecting, from the slot data structure, one or more slots that reference nodes of the blockchain network that are to participate in a consensus protocol for addinga block to a blockchain of the blockchain network, wherein each of the slots has an equal probability of being selected.

19. The system of claim 17, wherein the slot data structure is maintained in memory of each of the computer nodes.

Images