Patent ID: 12244731

DETAILED DESCRIPTION

All identically numbered reference characters correspond to each other so that a duplicative description of each reference character in the drawings may be omitted.

According to one embodiment, illustrated inFIG.1, a user10sends a transaction (or contract) to current Leader Clan101. The Leader Clan must achieve a majority agreement to produce a valid threshold signature, in which a majority of the Tribal Leaders agree on the transaction's validity and sign together on the same data to form a valid aggregated (combined) group signature11, otherwise the transaction is discarded12.

To determine whether to affirm the transaction, each Node within the Tribe sends each other their partial group signature on the transaction to all other nodes of the Leader Clan. All active and valid nodes know the population of the other nodes in the network and which Tribe and Clan each node belongs to for the current Cycle.

Once threshold, e.g. ⅔+1, of the nodes in the Clan collect enough signatures, a final valid signature is produced. As long as ⅔+1 of the nodes of the clans, i.e. 9 out of 13 nodes, come together (and any combination of 9 out of 13 partial signatures are combined together signing the same message) the outcome final signature, despite which actual of the 9 of 13 nodes participated, will always be the same and easily verifiable.

If in agreement, the Leader Clan will send the transaction data and their group threshold signature to the selected Oracle Clan, this signifies Leader Clan agreement on the validity of the transaction data transmitted 102.

The Oracle Clan must reach threshold agreement on 1) Leader Clan threshold signature, 2) which Tribes should be assigned this transaction, and 3) which Clans within the randomly selected Tribes should be assigned this transaction13. This random selection process for which RSIP Clans is through a deterministic verifiable random function. If Oracles are unable to come to an agreement, the transaction is ultimately rejected14.

Upon reaching a threshold agreement, the Oracle Clans broadcast the transaction data and the Leader and Oracle Clan's valid group threshold signature to the randomly determined RSIP Clans of a majority of Tribes, for example a random 5 out of 7 Tribes103.

RSIP Clans from the randomly selected Tribes check the transaction data and Leader and Oracle Clan's group threshold signatures to verify all the transactions and signatures are valid15a-g. This is accomplished, for example, by comparing the transaction data to their local copy of the database state, which all nodes possess, and by checking the transaction hash or BatchID compared to one's local copy of the Tribal Map, which is the knowledge of which nodes are part of which Clan, Tribe, and currently active role in the network for the cycle. RSIP Clans can thereby ensure the correct Oracles and Tribal Leaders were deterministically assigned this transaction based on the hash of said transactions and the accompanying cryptographic signatures. RSIP Clan nodes themselves seek to achieve a group majority threshold agreement on the transactions' validity as well as verify that the correct Leader and Oracles achieved a valid threshold signature13.

Each RSIP Clan upon agreement sends their threshold signatures back to the Oracles104, who wait for a tunable predicate of, for example 5 out of 5, RSIP Clans to respond back with their group threshold signatures. If the tunable predicate is not met, the Oracles may signal back (request) more Tribes and Clans to re-run the transaction thereby auto-scaling the amount of Clans involved in validating the transaction104. If RSIP Clans are not able to reach a threshold majority agreement, then they will not be able to produce a valid group signature to send to the Oracles, which will signal an anomaly to the Oracles (e.g., something is awry) and initiate auto-scaling procedures. The auto-scaling procedure can be performed as needed by the system, e.g., multiple times for each transaction.

Assuming the RSIP Clans respond to the Oracles with their valid group threshold signatures (before or after auto-scaling), the Oracles must achieve threshold agreement that enough and the correct RSIP Clans have achieved a group threshold signature on the transaction and that the correct Tribal Leaders and Oracles signatures are accurate in relation to the transaction ID or Batch ID16. If in agreement, they send the RSIP group threshold signatures back to the Leader Clans, along with their own majority group signature and the transaction ID or Batch ID105. If the Oracles are unable to come to a valid majority affirmative agreement, the transaction may be rejected14.

The Leader Clan that originated the transaction then must achieve a final group threshold signature on the transaction and verify the correctness of the RSIP and Oracles signatures17.

If final agreement of the validity of the transactions and the group signatures of the Oracle and RSIP Clans is reached, then the Tribal Leaders will broadcast the database state changes accompanied with their aggregate signature, the Batch or Transaction ID, and all of the signatures of Leader, Oracle, and RSIP Clans that were deterministically randomly assigned to validate this transaction106. These signatures can be aggregated further into a final single aggregate signature if desired, while still remaining cryptographically deterministic and unforgeable. If the Tribal Leaders are unable to come to a threshold majority agreement on the validity of the transaction data or the received threshold signatures, the transactions may be rejected18.

The last step of the protocol is that all of the nodes that receive an incoming state change request need to check the accompanying signatures from the Tribal Leaders, Oracle, and RSIP Clans in comparison to the transaction data and their Tribal Map to verify that the transaction has gone through the correct channels and set of nodes towards seeking consensus and that the required Clans have been able to produce valid threshold signatures.

If the database state change requests and associated signatures and data validate, nodes following the protocol individually accept the state changes and update their database values also storing the aggregate signatures that accompanied the state changes19, and the transaction is complete and further propagated until all honest nodes make the appropriate updates.

If, however, the signatures or aggregate signature on batch do not validate, the nodes can reject the state changes20.

In the normal case, in Unity Protocol Consensus only a fraction, e.g. 5%, of the nodes at any given time are responsible to validate specific transaction data, while still maintaining a high degree of security. This enables greater load balancing, concurrency, and parallel process than other more linearized consensus protocols.

According to another embodiment, illustrated inFIG.2, a user (1) sends a transaction to current Tribal Leaders (2). The Tribal Leaders reach agreement on the transaction or batch of transaction and send them to the Oracle Clan(s) (3).

The Tribal Leaders validate the transaction (4) and if a threshold of them agree, they achieve a Unity Event (achieves consensus on the Tribal Leader Level) (5).

The Oracles randomly sample the nodes in the different Tribes (6). These RSIP nodes vote on the transaction's validity and share their results to each other and to the Oracles who compare the results of all the RSIP nodes from different tribes to one another (7).

If the threshold of nodes are able to achieve consensus, then the Oracles send back the signatures of the RSIP nodes, their signature, and the transaction ID back to the Tribal Leaders, who verifies the signatures against their copy of the blockchain which contains the membership information of the network for this cycle, and if verified, signs the transaction with their private key with the other prior signatures to generate a new aggregate signature which is then broadcast to the network for all nodes to save (8).

The system, for example, can be used in any system that requires distributed consensus, e.g., it can be the consensus engine in a blockchain and may be used in distributed or decentralized system to achieve majority decisions by first sampling the network and then proceeding with the branching logic as necessary to gain a sentiment analysis of the system, while not requiring all nodes in the network to participate in the procedure and still achieving an accurate view of the network status with high probability.

The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present subject matter. The general architecture may be configured and altered to enable flexible solutions. To achieve the goals of improved security and speed, for example, different parameters can be altered based on desired security requirements.

Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the subject matter. Thus, the present subject matter is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various aspects and embodiments disclosed are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.