Building trusted public blockchain networks based on participants' digital social behavior

A method is disclosed including receiving a request for changing a privilege of a peer of the public blockchain network, in response to receiving the request for changing the privilege, automatically submitting a trust query to a trust verification entity, receiving from the trust verification entity, a trust score associated with the peer, comparing the received trust score to a pre-determined threshold, determining, based on the comparison, that the trust score is greater than the pre-determined threshold, in response to determining that the trust score is greater than the pre-determined threshold, automatically voting that the request be granted, receiving votes of other privileged peers of the public blockchain network, determining that a number of the votes for granting the request is sufficient to grant the request, and in response to determining that the number of votes is sufficient, automatically executing the requested changing of the privilege of the peer.

BACKGROUND

The present disclosure relates generally to blockchain networks and the automated process for approving changes to privileges of peers within a blockchain network.

When a new peer joins a public blockchain network, the new peer is often given only limited rights or powers to alter or perform other actions on the blockchain network. For example, the new peer may be prevented from performing any actions that may modify or alter the blockchain and may instead only be allowed to read the blockchain. This type of peer with such limited rights may sometimes be referred to as an unprivileged peer. A privileged peer of the blockchain network on the other hand may submit new transactions to the blockchain, execute transactions on the blockchain, or perform other similar actions. A privileged peer may also be responsive for granting privileges to unprivileged peers. For example, a privileged peer may be able to upgrade a non-privileged peer to a privileged peer or to provide an unprivileged peer with additional rights or powers in the blockchain network.

BRIEF SUMMARY

The system, method, and computer program product described herein provide automated approval of changes to privileges of peers of a public blockchain network.

In an aspect of the present disclosure, a method is disclosed including receiving, by a privileged peer of a public blockchain network, a request for changing a privilege of a peer of the public blockchain network, in response to receiving the request for changing the privilege, automatically submitting, by the privileged peer, a trust query for the peer to a trust verification entity, receiving, by the privileged peer, from the trust verification entity, a trust score associated with the peer, comparing, by the privileged peer, the received trust score to a pre-determined threshold, determining, based on the comparison, that the trust score is greater than the pre-determined threshold, in response to determining that the trust score is greater than the pre-determined threshold, automatically voting, by the privileged peer, that the request be granted, and receiving, by the privileged peer, votes of other privileged peers of the public blockchain network. The received votes are based on trust scores received by the other privileged peers from at least one trust verification entity in response to trust queries submitted by the other privileged peers responsive to a receipt of the request by the other privileged peers. The method further includes determining, by the privileged peer, that a number of the votes for granting the request is sufficient to grant the request, and in response to determining that the number of votes is sufficient, automatically executing, by the privileged peer, the requested changing of the privilege of the peer.

In aspects of the present disclosure, apparatus, systems, and computer program products in accordance with the above aspect may also be provided. Any of the above aspects may be combined without departing from the scope of the present disclosure.

DETAILED DESCRIPTION

In a typical blockchain network, a privileged peer may decide to grant privileges to an unprivileged peer or other peers based on any individual criteria that the privileged peer decides to follow. For example, a privileged peer may decide to upgrade an unprivileged peer because the privileged peer knows the unprivileged peer, has a business association with the unprivileged peer, or for any other reason. In some cases, a privileged peer may be required to “vet” the unprivileged peer before approving the unprivileged peer for additional privileges or even privileged status within the blockchain network. Such a vetting may require significant time and effort on the part of the privileged peer either reviewing documents, tracking the unprivileged peer's history, or other similar vetting processes which may become a significant burden on the privileged peer.

In some cases, multiple privileged peers of the blockchain network may be required to vet an unprivileged peer and together make a determination on whether the unprivileged peer should be given additional privileges. Given the distributed nature of public blockchain networks where individual peers typically have no other contact with other peers, such a vetting process may incur significant usage of resources and time where, for example, some required privileged peers may not act on the vetting in a timely manner or may simply ignore a request for more privileges entirely. Accordingly, approving an unprivileged peer for additional privileges within a public blockchain network may become burdensome on the individual privileged peers that are required to vet the unprivileged peer while achieving a consensus of some or all of the privileged peers on the blockchain network to give the unprivileged peer additional privileges may be difficult or impossible to achieve.

The present disclosure solves these issues by providing a mechanism for automatically determining whether or not to grant a peer additional privileges in a public blockchain network based on digital social behavior of the peer.

With reference now toFIG. 1, a system100according to the present disclosure is illustrated. In some aspects, system100includes a computing device110, and a social media platform150.

Computing device110includes at least one processor112, memory114, at least one network interface116, a display118, an input device120, and may include any other features commonly found in a computing device. In some aspects, computing device110may, for example, be a computing device associated with a peer of a public blockchain. In some aspects, computing device110may include, for example, a personal computer, laptop, tablet, smart device, smart phone, smart watch, or any other similar computing device associated with the peer. For example, a user may use the computing device110to participate in the public blockchain as the peer.

Processor112may include, for example, a microcontroller, Field Programmable Gate Array (FPGAs), or any other processor that is configured to perform various operations. Processor112may be configured to execute instructions as described below. These instructions may be stored, for example, in memory114.

Memory114may include, for example, computer readable media or computer readable storage media in the form of volatile memory, such as random access memory (RAM) and/or cache memory or others. Memory114may include, for example, other removable/non-removable, volatile/non-volatile storage media. By way of non-limiting examples only, memory114may include a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Network interface116is configured to transmit and receive data or information to and from a social media platform150or any other computing device via wired or wireless connections. For example, network interface116may utilize wireless technologies and communication protocols such as Bluetooth®, WIFI (e.g., 802.11a/b/g/n), cellular networks (e.g., CDMA, GSM, M2M, and 3G/4G/4G LTE), near-field communications systems, satellite communications, via a local area network (LAN), via a wide area network (WAN), or any other form of communication that allows computing device110to transmit or receive information to or from social media platform150.

Display118may include any display device that is configured to display information to a user of computing device110. For example, in some aspects, display118may include a computer monitor, television, smart television, or other similar displays. In some aspects, display118may be integrated into or associated with computing device110, for example, as a display of a laptop, smart phone, smart watch, or other smart wearable devices, as a virtual reality headset associated with computing device110, or any other mechanism for displaying information to a user. In some aspects, display118may include, for example, a liquid crystal display (LCD), an e-paper/e-ink display, an organic LED (OLED) display, or other similar display technologies. In some aspects, display118may be touch-sensitive and may also function as an input device120.

Input device120may include, for example, a keyboard, a mouse, a touch-sensitive display118, a keypad, a microphone, or other similar input devices or any other input devices that may be used alone or together to provide a user with the capability to interact with computing device110.

Social media platform150includes a processor152, memory154, and a network interface156that may include similar functionality as processor112, memory114, and network interface116. In some aspects, social media platform150may, for example, be any computing device, server, or similar system that is configured to interact with or provide data to computing device110. In some aspects, for example, social media platform150may include social media web sites or applications, back end processing, or other similar devices associated with one or more social media providers, e.g., Facebook®, Twitter®, Instagram®, or any other social media provider. In some aspects, social media platform150may be any data repository storing data about users of social media or about users of a public blockchain network.

With reference now toFIGS. 2-8, a method200for automatically approving changes to privileges of peers within a public blockchain network will now be described.

FIG. 3illustrates a public blockchain network300including peer A, peer B, and peer C. Public blockchain network300may also include any number of other peers. Computing device110may be associated with any of peers A-C. For example, each of peers A-C may be associated with a respective computing device110. Peer A may communicate with peer B, e.g., via a communications network connection302, peer B may communicate with peer C, e.g., via a communications network connection304, and peer C may communicate with peer A, e.g., via a communications network connection306. For example, peers A-C may communicate with each other or the public blockchain network300using the network interfaces116of their respective computing devices110. In some aspects, for example, peers A-C may communicate via the internet.

In the example illustrated inFIG. 3, each of peers A-C is a privileged peer in the public blockchain network300. For example, a privileged peer may be responsible for granting privileges to new peers who join the network. Privileged peers may also submit network transactions which unprivileged peers do not have the authority to execute. In the example provided inFIGS. 3-8, peers A-C may be the only privileged peers on the public blockchain network300.

As illustrated inFIG. 3, peer D is not yet part of the public blockchain network300network. As with peers A-C, peer D may also be associated with a computing device110and may be configured to communicate with one or more of peers A-C, or blockchain network300using the network interface116of the associated computing device110.

Referring now toFIGS. 2 and 4, at202, a peer D joins the public blockchain network300as an unprivileged peer. For example, as part of the public blockchain network300, a communications network connection308may be established between peer A and peer D, a communications network connection310may be established between peer B and peer D, and a communications network connection312may be established between peer C and peer D. As an unprivileged peer, peer D is only able to view the contents of the public blockchain network300and submit a ‘privileged peer request’ transaction to the public blockchain network300. In some aspects, a ‘privileged peer request’ transaction may be a request by peer D for additional privileges in the public blockchain network300. For example, the ‘privileged peer request’ may request additional privileges such as, e.g., write privileges to the blockchain, or other similar privileges. In some aspects, the ‘privileged peer request’ may be a request to become a privileged peer in the public blockchain network300. For example, peer D may request to become a privileged peer, similar to peers A-C.

In some aspects, the ‘privileged peer request’ transaction may contain identifying information associated with an account on a social media platform. In some aspects, for example, the identifying information may be an e-mail address.

At204, peer D submits the ‘privileged peer request’ transaction to the public blockchain network300. For example, the ‘privileged peer request’ transaction may be submitted directly to each of peers A, B, and C, or may be submitted to another node of public blockchain network300and forwarded to peers A, B, and C or any other privileged peer. In some aspects, the ‘privileged peer request’ may be submitted to a subset of the privileged peers on the public blockchain network300. In some aspects, the ‘privileged peer request’ may be submitted to a randomly selected subset of privileged peers.

With reference now toFIGS. 2 and 5, at206, peers A, B, and C receive the ‘privileged peer request’ transaction. In response to receiving the ‘privileged peer request’ transaction, peers A, B, and C may initiate a trust query for peer D at208. For example, each of peers A-C may initiate trust queries502,504, and506, respectively querying a social media platform150. Social media platform150as used herein may be replaced with any other data source or trust verifying entity without departing from the scope of the present disclosure. The trust queries502,504, and506may be used by peers A-C to determine a score for how trustworthy the requesting peer such as, e.g., peer D, is by evaluating their social media accounts or using another trust verification source. For example, trust queries may be submitted by peers A-C to one or more social media platforms150.

In some aspects, for example, one or more of peers A-C may submit the trust query to the same social media platform150. In some aspects, each of peers A-C may submit the trust query to a different social media platform. In some aspects, one or more of peers A-C may submit the trust query to a first social media platform150while others of peers A-C may submit the trust query to at least one other social media platform150. In some aspects, for example, peers A-C may automatically initiate trust queries502-506in response to a received ‘privileged peer request’.

With reference now toFIGS. 2 and 6, at210, in response the trust queries502-506, social media platforms150or other data sources may return trust scores602,604, and606to peers A-C for the requesting peer, e.g., peer D. For example, as illustrated inFIG. 6, a trust score of 95/100 may be received by peer A, a trust score of 85/100 may be received by peer B, and a trust score of 77/100 may be received by peer C. An example system for generating trust scores in a social network is disclosed in U.S. Pat. No. 9,342,560, the entire contents of which are incorporated herein by reference.

With reference now toFIGS. 2 and 7, at212, each of peers A-C checks the respective received trust score602-606to determine whether the requesting peer, e.g., peer D, can be trusted. For example, peers A-C may compare the received trust score602-606to a pre-determine threshold. For example, the pre-determined threshold may be 50/100, 75/100, or any other threshold value. In some aspects, for example, the pre-determine threshold may be based on the social media platform from which the trust score is received. For example, trust scores received from a first social media platform150may be compared to a first pre-determined threshold, e.g., 50/100, while trust scores received from a second social media platform150may be compared to a second pre-determined threshold, e.g., 75/100.

In some aspects, for example, a pre-determined set of trust query targets, e.g., social medial platforms150, may be pre-defined in the public blockchain network300along with associated pre-determined thresholds. For example, the pre-determined set of trust query targets and pre-determined thresholds may be defined as a transaction in the first block of the public blockchain network or in any other block. In some aspects, for example, the privileged peers may vote on adding a new social media platform150to the set of trust query targets.

Each of peers A, B and C may compare the received trust scores602-606to the pre-determined threshold, e.g., 50/100, to determine if the received trust score is greater than the pre-determined threshold. If the received score is determined to be greater than the pre-determined threshold, the peer A-C may vote that Peer D should be trusted at214. If the received score is determined to be less than the pre-determined threshold, the peer A-C may vote that Peer D should not be trusted at216. For example, if the pre-determined threshold is 50/100, peer A may compare the received trust score602of 95/100 to the pre-determined threshold of 50/100 and determine that the received trust score for peer D is greater than the pre-determined threshold. Peer A may then vote that peer D should be trusted. In some aspects, the vote may be for or against granting the requested privileges to peer D. In some aspects, for example, peers A-C may automatically vote for or against peer D based on the comparison to the pre-determined threshold.

With reference now toFIGS. 2 and 8, at218, the results of the votes are checked to determine whether enough votes for or against trusting peer D have been cast. For example, if a majority of voting peers, e.g., privileged peers A-C, vote that peer D should be trusted, peer D is granted privileged peer status in the public blockchain network300or is granted the requested additional privileges at220. Otherwise, peer D remains an unprivileged peer and no additional privileges are granted at222.

In some aspects, the trust query process described above may be publicly available on the public blockchain network300. For example, the ‘privileged peer request’ transaction may be a transaction added to the blockchain. As another example, transaction details of the trust query and the received trust score may also be added to the blockchain.

In some aspects, a ‘privileged peer request’ transaction may be automatically initiated for any unprivileged peers on the blockchain. For example, the trust scores for unprivileged peers may be periodically checked to determine whether the unprivileged peer may be granted privileged status or additional privileges without requiring the unprivileged peers to submit the ‘privileged peer request’ transaction themselves.

In some aspects, a ‘privileged peer request’ transaction or similar transaction may be initiated for privileged peers. For example, trust scores of privileged peers may be checked to determine whether the privileged peer should remain as a privileged peer. In some aspects, for example, a privileged peer may lose privileged status if a sufficient number of trust scores are less than an associated pre-determined threshold, e.g., if enough peers vote against trusting the privileged peer. This may be a self policing mechanism for the public blockchain network300where privileged peers that should no longer be trusted may be removed from the public blockchain network300.

In some aspects, if enough peers vote for trusting the privileged peer, the privileged peer may be given additional privileges. For example, the privileged peer may become a super privileged peer with privileges that allow the super privileged peer to enforce rules against regular privileged peers or perform other similar actions. In some aspects, the pre-determined threshold score or number of votes required to elevate a privileged peer to a super-privileged peer may be higher than the pre-determined threshold score or number of votes required to elevate an unprivileged peer to a privileged peer. Likewise, in some aspects, the pre-determined threshold score or number of votes required to maintain a status as a privileged peer may be lower than the pre-determined threshold score or number of votes required to elevate an unprivileged peer to a privileged peer.