MMOG User Participation Based Decentralized Consensus Scheme and Proof of Participation Analysis on the Bryllite Blockchain System

Abstract

Proof of Work (PoW) based blockchains have limitations in throughput, time consumption, and energy efficiency. In these systems, a miner will consume significant time and resources to obtain a reward for contributing to the blockchain. To overcome these limitations, recent research on blockchains are focused on accelerating the speed, scalability, and enhancing the security level. By enhancing specific procedures of blockchain system, the level of data integrity supported by the blockchain can become more robust, and efficient. In this paper, a new blockchain consensus model based on the Bryllite Consensus Protocol (BCP) is proposed to support a hyper-connected massively multiplayer online game (MMOG) ecosystem. The BCP scheme enables users to participate directly in new consensus processes through a Proof of Participation (PoP) algorithm. In this model, the consensus algorithm has a simpler form while maintaining high security level. In addition, because the BCP scheme gives users an equal chance to make a contribution to the blockchain, rewards are distributed in an equal fashion, which motivates user participation. The analysis of the proposed scheme is applied to the Bryllite consortium blockchain system (homed in Hong Kong), which is a new blockchain network developed for international game industries, gamers, and game events.

1. Introduction

Blockchain is a distributed ledger system that ensures data integrity, which was initially proposed in a paper on Bitcoin by Satoshi Nakamoto [1]. A blockchain used for Bitcoins would need to maintain a decentralized database structure without being under the control of acentralized organization by sharing a ledger with mining nodes. To maintain data integrity, each node stores the same block and uses data chaining and hash functions. The method used to reliably determine the node that generated the block is based on the consensus algorithm. In the Proof of Work (PoW) consensus algorithm, mining nodes use SHA-256 to find a hashoutput value less than the target hash value corresponding to a predefined difficulty level. Then, the mining node that finds the corresponding hash value is selected to generate a block that is added to the blockchain. The difficulty of the hash calculation is adjusted so that one block is generated every 10 minutes for a Bitcoin, while all other competing mining nodes waste a huge amount of electric energy due to the computation process of the hash calculation. Meanwhile, with the continuous development of blockchain technology, the application range has expanded in to fields such as finance, game industry, and social network services (SNSs). Especially, the application of blockchains in the game industry can help build a hyper-connected game ecosystem for various massively multiplayer online games (MMOGs) supported by a common blockchain service network. In networks supporting MMOGs, thereare numerous users and MMOG service providers, therefore, network scalability is essential [2]. Blockchain technology is now being linked across various industries, and consensusalgorithms such as PoW are inefficient and unsuitable to satisfy user quality of service (QoS) requirements in networks supporting MMOGs, which need quick transactions. Therefore, in this paper, a novel proof of participation (PoP) consensus mining scheme based on userparticipation is proposed, and is applied to the Bryllite game blockchain system and its performance is analyzed [3].

The unique features of the proposed blockchain algorithm are characterized by the following two aspects. First, not only the miners but also the users (clients) can participate in the consensus process and receive a compensation. This motivates the user to join the block chainnetwork. Second, only one hash computation needs to be conducted for each user during the PoP process, which is opposing to the repetitive hash computations that were conducted by allminers in the PoW mechanism. In addition, the probability of receiving individual users block rewards is fairly equal, which promotes continuous monitoring and participation to the block chain by its users.

In this paper, the proposed PoP based consensus algorithm is named the Bryllite Consensus Protocol (BCP). The following sections of this paper are organized as follows. Section 2 presents the taxonomy of blockchain consensus algorithms, the system model of the BCP is provided in section 3, the BCP algorithm’s analysis is in section 4, the simulation results and discussion are in section 5, and the paper is concluded in section 6.

2. Taxonomy of Blockchain Consensus Algorithms

In this section, the characteristics of blockchains and the corresponding consensus algorithms are described. Blockchains can be classified into permissionless or permissioned depending on the network purpose.

Fig. 1. Overall process of the BCP PoP

2.1 Permission-less Blockchain

In a permissionless blockchain, there are no specific restrictions to participate in the network. Since network members are not pre-validated, a strict consensus algorithm is used to verify untrusted distributed ledgers of participants [4]. PoW is a typical consensus algorithm used in permissionless blockchains. When PoW is used, block miners solve the SHA-256 based crypto puzzle consuming an enormous amount of hash calculations, which is a means of defending against well-known Sybil attacks [5]. This expensive method of consensus is amechanism triggered by the nature of the network that any user can participate in the block chain without permission. Such blockchains are typically classified as a public block chain, thus, public blockchains are generally permissionless blockchains. Permissionsless blockchains are focused on decentralization, in which Bitcoin and Ethereumare represenative examples.

2.2 Permissioned Blockchain

In a permissioned blockchain, the distributed ledger is confirmed by pre-validated users. Since the trust of the participants is guaranted, there is less motivation to use a resource consuming consensus algorithm such as PoW. The block mining process is performed using a bounded asynchronous consensus algorithm, where the Practical Byzantine Fault Tolerance (PBFT) is arepresentative example [6]. Such schemes are much faster than permissionless consensusalgorithms, such as PoW, but these schemes have the disadvantage that the message complexity increases signifincantly when the network is expanded [7]. Therefore, Byzantine Fault Tolerance (BFT) based consensus algorithms experience scalability issues. Consortiumor private blockchains belong to the category of permissioned blockchains. In particular, theseconsortium blockchains appear in the form of a prospective blockchain that are mainly used invarious service chain models by many companies [8-10].

3. BCP System Model

The Bryllite Consensus Protocol (BCP) has been proposed to serve as a new type of block chain network for the game industry ecosystem, enabling cryptocurrency exchange between companies, conferences, consortiums, and gamers. The BCP system architecture can be classified into four major components as shown in Fig. 1.1) Master Node (MN): A mining node that participates in the consensus of the Bryllite block chain. One MN is assigned to each game.

2) Game Client: A game user that plays the game(s).

3) Game Server: A game server will manage the local game database, and also store and manage the transactions that occur during the game(s). However, game servers do not belong to the blockchain network, instead they interact with the Bryllite block chainnetwork via the bridge service node described below.

4) Bridge Service Node: The bridge service node manages bidirectional communication between the MN and game servers. It also manages the asymmetric keys (i.e., publicand private keys) of the game client.

BCP consists of two steps: PoP and Majority Voting. In the PoP process, each MN selects arepresentative game client with a minimum hash value. In the Majority Voting process, each MN proposes a hash value for its representative game client, and the MN that proposes the lowest output hash value is chosen as the block generation node, which will receive a mining compensation for its contribution. Transactions from users are propagated in the network and accumulated in the transaction pool (e.g., Mempool in Bitcoin). In the proposed block chain model, each MN generates a candidate block based on the consensus interval (T), and the winning miner is selected by the PoP based on majority vote, which decides the block to connect to the blockchain.

3.1 Proof of Participation (PoP)

The overall process of the PoP is described in the following, which is based on an individual MN. The symbols and abbreviations used in the text are summarized in Table 1.

Table 1. Symbols and Abbreviation

A) Background Key Management Process

A game client will register to the game server to participate in a game. Then the servergenerates a private key using the private key generator (PKG), which is returned to the user. The generated public and private key set of the entire user is managed by the bridge servicenode. When a client registers or deletes its own account, the same process is performed in the bridge service node.

B) Block Header (BH) Distribution

A MN will generate a BH Ψ for use in each round of the consensus and send it to the bridgeservice node. The block header contains the block version, previous block hash, the Merkleroot hash (i.e., combined hash value of the transactions), time-stamp, Tx count (i.e., maximum transaction count in one block), and gamer signature. The gamer signature consists of asignature and public key. Initially, the gamer signature is set to null and it will be signed by the client in the PoP process. The structure of the block header is shown in Fig. 1. First, the bridgeservice node sends the received block header to the game server, which is represented in (1). The game server k sends to the active game client , ∈ , where (k, i) denotes client i of game k in (2).

(1)

, ∈ (2)

C) Client signature

After the active client receives the that has the gamer signature space as null, the clienthashes the received ΒΗ through the hash function H(⋅) based on SHA256, which has strong collision resistance. Each game client generates a signature using its private key (SK) with ahash value in the ΒΗ (H( )). The public key generator (PKG) can create a large scale ofrandom unique numbers to be used in assignment to many game clients. In (3), the signature of game client i is represented as , = ( ( ), , ). The ith game client update pair of the signature and public key is denoted as ( , , , ) in the gamer signature space in (4). Finally, the client will send , to the MN, where in (5), , represents the signed blockheader of client i in game k.

, = ( ( ), , ) (3)

, = ∪ ( , + , ) (4)∑ , = 1

∈ ( , )

⎯⎯ (5)

D) Selection Representative Client

The MN receives the block headers that include the signature and PK pairs sent by all usersconnected to the game. Using , , the signature , can be decrypted to H( ), which is the value sent by client i that represents , , ( ), , . The MN can identify the signature from all clients if , , ( ), , = ( ) is satisfied. For a signature that has beenverified, client ∗ with the minimum hash value is designated as the representative of , as defined in (6). In addition, the signed block header of client ∗ (i. e. , ∗) is the representative block header of , as presented in (7).

∗ = min ( , ) (6) 

∗ = , ∗ (7)

Each node compares the ( , ) values of all clients created in each game and sets the blockheader that has the lowest hash as the representative ΒΗ of each game. The overall PoP processis described in Pseudocode 1. In the PoP process, MNs present their ΒΗ in every round, and the users sign the ΒΗ and returns it to the MN. Since the ΒΗ information received from the MN is fixed, there is only one possible signed block that the user can submit, depending on its private key. Thus, users cannot attempt mining to achieve a smaller hash value, which is why there is no mining process computation burden in the BCP scheme. In addition, it needs to benoted that if a malicious user attempts to perform a Sybil attack in the BCP PoP process, it will be nearly impossible, as the bridge server node will easily notice irregular user accountchanges (based on multiple keys being used) and can easily apply user authentication procedures along with gamer profile status checks (e.g., game log monitoring, minimum duration of game playing time, etc.) to prevent Sybil attacks.

3.2 Majority Voting

In the majority voting process, each MN broadcasts its representative ΒΗ and votes for theminimum hash output. After verifying which ΒΗ has the minimum hash value, that block isselected and added to the blockchain, and a reward is given to the provider of that block. Whensending and receiving a ΒΗ or when voting, pairs of public keys (PKs) and private keys (SKs) of each MN ( ,) are used in the certification process.

A) Propose

In the Propose phase, the MNs broadcast their representative ΒΗ. Each MN selects arepresentative client ∗ and delegate ΒΗ ∗. The MNs of each game k signs ∗ with its own private key, , and propagates it to all other MNs, as presented in (8).

∑ = 1(∗ , )⎯⎯⎯⎯⎯⎯⎯⎯⎯ & sum; = 1

(8)

Next, each MN receives all block headers from other MNs satisfying , & lowast; ,=∗. Then, MN k creates its own ΒΗ set = { ∗| = 1,⋯ , }.

B) Vote

After receiving the BH in the Propose phase, in the Vote phase, each MN will find a ΒΗ thathas the minimum hash value, as presented in (9), and denote it as the voted candidate of (i.e., ). After the candidate is determined, each MN re-broadcasts its candidate value to allother nodes, as presented in (10).

Fig. 2. Example of a majority voting process based on the Propose, Vote, and Commit phase

= min ∗{ ( ∗) ∈ } (9)

(10)

In the same way, each MN receives all candidate BHs from other MNs satisfying, , = . Then, the MN k generates its own voting candidate set == 1,⋯ , . For example, if 1 determines the candidate to be 2∗ in the voting step, then 1

= 2∗. Since each node selects a candidate ΒΗ based on the minimum hash value in, the selected by each node should be equal if there is no malicious situation. Based on the assumption that more than half of the miners are honest, and the PKI system is secure, the voting decision is made using the majority rule. If the value of ∗ in set of node k exceedsthe majority, this ensures that the majority of MNs have identified ∗ as the minimum hash value in this round. If { ∗ | ∗ ∈ , for ∃ } > is satisfied, then & lowast; will represent ∗.

C) Commit

In the Commit phase, all MNs verify the block candidate’s integrity and finally determine the block that will be connected to the blockchain. The MN that had proposed the final candidate & Beta;Η ∗ broadcasts the total block data including the transaction list to all other MNs. Afterreceiving the blockchain data, every node verifies the previous block hash and gamer signature in the block. If the block is valid, the MN suggests that this block is valid and broadcasts averification message ( ) to all other nodes. If not, it broadcasts a message claiming that this block is not valid ( ). These procedures are expressed in (11).

∑ = 1( )⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ & sum; = 1

(11)

After receiving the message whether this block is valid or invalid, MNs make a final decision. MN k will store the msg received from the other nodes in its message set . If the number of exceeds more than half, then the transaction is confirmed, and the MNs connect that block to their own blockchain. The algorithm of the majority voting process is described in Pseudocode 2. Finally, the representative user of the MN that proposed the minimum hash value in the majority voting process receives a block compensation.

Pseudocode 2. Majority voting process

As example of the majority voting process is described in Fig. 2. In this Figure, three MNs1, 2, and 3 perform a majority voting process. In the Propose phase, all MNs broadcast their representative block header 1∗, 2∗, and 3∗. In this example, the hash of 2∗ is a global minimum hash value. Then, in the Vote phase, each MN votes to elect the ΒΗ that has theminimum hash value. But, there may be cases in which a node has problems in communication or a node may intentionally vote maliciously (to hinder the blockchain process) on a ΒΗ that does not have the minimum hash value. In this example, 3 votes for its own representative & Beta;Η. However, because 2∗ is selected by the majority rule vote decision in this example. In the Commit phase, the validity of the block generated by 2 is checked, where if it is valid, Ξ2(i.e., the block generated by 2) is connected to its own blockchain.

An advantage of the BCP scheme is that it depends on a majority vote mechanism. Incomparison, the PBFT algorithm (for asynchronous blockchain networks) has an obligation toselect a leader, where more than two-thirds of nodes have to be honest to ensure a successfulconsensus [4]. In the BCP model, the block message transmitted by each MN during the consensusprocess includes the signature of each MN's private/public key. Therefore, message modulations isimpossible unless the entire blockchain is hacked and manipulated. In addition, the BCP model does not need a leader election process, therefore, it does not have to satisfy the strict consensus bound of PBFT. Rather, the PoP model is a competitive-based algorithm, such as PoW, which selects a block generatorbased on the minimum hash value, but is more economical. In the BCP model, if an attempt tomanipulate the selection process to make a malicious miner to be selected as the block generator, the number of false game users participating in the game must be increased rapidly. However, this can be prevented by periodic checking of the game log (e.g., play time, user identification) within the gameserver by the network management system.

4. Analysis of the BCP Algorithm

The proposed system has the following stable and fairness properties.

Lemma 1. There is practically only one minimum hash output value, which is determined on arandom basis in the BCP process. 

Proof. The output hash value is ( ∗) and the client’s SK and PK are fixed. However, MNs have different Merkle root hashes depending on their combination of transactions, and the hash of a ΒΗ per round for each MN are randomly determined. In other words, the output hash values of each MN are all different because hash values have a very low collision probability based on the generalized birthday problem of a n bit hash function. In (12), P (N, n) is the probability that among N inputs that are independent (which are n bits each and given that k ≪ 2 ), at least two will have the same hash output.

(12)

If a hash algorithm such as SHA-256 or SHA-512 is used, the collision resistance of the security requirement is satisfied. In addition, based on the avalanche effect of the hash output [11], the probability that any hash output will be the minimum among all N participants is 1/N.

∎Lemma 2. Clients participating in each game receive a fair block generation reward. 

Proof. Let X , 1 denote the event that client i of game k ( , ) will be selected as the minimum hash in the PoP, and X , 2 denotes the corresponding event majority voting process. Then, the probability of X , 1 is (X , 1 ) =by Lemma 1. The probability of X , 2 is expressed as (X , 2 )=∑ = 1, where m is the total number of game servers. Let the block generation reward be R, then the expected reward of client , can be expressed as (11).

(13)

Therefore, regardless of which user participates in which game, all clients participating in each game has the same expected reward, which is a new fairness property. ∎

4.1 Complexity and scalability analysis

In this section, the complexity analysis of BCP and delegated mining blockchains are provided. Since users can receive block rewards through PoP, scalability analysis in reference to anincrease in number of users is important. In addition, since BCP is aimed at a highly-connectedecosystem of MMOGs, it is essential to consider connection of multiple games. As the number of users increases, the number of MNs will correspondingly increase. To overcomecomplexity issues due to an increasing number of blockchain miners, Delegated Proof of Stake (DPOS) based algorithms (e.g., EOS [12]) confine mining nodes to maintain scalability in block chains. Therefore, the message complexity of delegated mining is also anlyzed. The analysis of the existing system and the model using delegated mining are summarized inlemmas 3 and 4, respectively.

Lemma 3. The message complexity M(n) in each consensus round is (3 2 − 3 − 1). 

Proof. In the Propose phase, each MN broadcasts its representative block header to the othern-1 nodes. Therefore, the total message complexity of the Propose phase is ( ( − 1)). In the Vote phase, each MN selects and broadcasts the ΒΗ that has the minimum hash among thereceived BHs during the Propose phase. Thus, the message complexity becomes ( ( − 1)). In the Commit phase, the majority voted node ( ) broadcasts a block to the other n-1 nodes, and each node broadcasts the verification results back through the network, resulting in amessage complexity of (n − 1) and (( − 1)2), respectively. Therefore, the total message complexity in each consensus round is ( ( − 1) + ( − 1) + ( − 1) + ( − 1)2) = (3 2 − 3 − 1) .

∎

Lemma 4. The message complexity of BCP in delegation mode is (2 2 + ( − 3) − 1), where d is the number of delegated miner nodes. 

Proof. In delegation mode, d delegation nodes are selected from n MNs. The selected d nodesonly participate in the consensus process of BCP. The (n-d) MNs that do not participate inconsensus should broadcast their representative ΒΗ to the d mining nodes. Therefore, the complexity of this process is (( − ) ). The d mining nodes compare the received (n-d) different ΒΗ hash values and select the ΒΗ that has the minimum value as the representative & Beta;Η. Next, the consensus process proceeds among the d mining nodes, therefore, the complexity is given as (3 2 − 3 − 1) based on lemma 3. As a result, the final complexity in delegation mode is given by ( − 2 + 3 2 − 3 − 1) = (2 2 + ( − 3) − 1). In addition, the inequality (2 2 + ( − 3) − 1) ≤ (3 2 − 3 − 1) always holds if ≤ .∎

The message complexity graph is shown in Fig. 3. Each performance curve segmentrepresents the message complexity by changing the ratio of the delegation node while keeping n constant. The message complexity is proportional to the delegation percentage, and the message complexity increases as the number of MNs increases.

Fig. 3. Message complexity of delegated mining

5. Simulation Result and Discussion

In this section, the TPS and latency simulation of the BCP algorithm is analyzed based on the Bryllite blockchain [13]. First, the TPS of the BCP algorithm was analyzed. The system wasset such that one block could be generated per consensus period T. In BCP, a transaction has a fixed size of 128 bytes. Therefore, if the block size is 128 KB, the maximum number of transactions that can be contained in one block is 1024. Therefore, dividing this by the period T (30 seconds) results in 1024/30 = 34. Therefore, the maximum TPS according to the blocksizes 128 KB, 256 KB, 512 KB, 1 MB, 2 MB, and 4 MB is determined as 34, 68, 136, 273, 546, and 1092, respectively. The maximum TPS and average TPS are shown in Table 2.

Next, the latency is analyzed. The latency is defined as the total time required for the BCPalgorithm to reach consensus and successfully generate a block to add on to the blockchain. Generally, if the BCP algorithm verifies the MN with the minimum hash value within T seconds, the consensus process succeeds. Otherwise, consensus fails and the overall TPSperformance drops. Therefore, latency is an indicator of the performance against the networkscalability, and each cycle of operation aims for completion within the time limit of T seconds. The experiment results of the average latency based on an increasing number of nodes is presented in Fig. 4. The results show the trend of how the latency increases as the number of MNs increase from 50 to 500. The MN serves the role of block validator in the BCP algorithmand each MN serves one game each. If the block sizes are 512 KB and 1 MB, the averagelatency corresponds to about 18 seconds. When the block size is expanded to 4 MB, the average latency grows up to 25 seconds for the case of 500 MNs. When the block sizes arelarger, the transaction time increases proportionally, as it takes more time to verify and committo a block. Instead, if the block Commit process is completed within the consensus period T, then the TPS increases because more transactions can be processed. The experiment results in Table 2 show how the average TPS increases in proportion to the block size. However, the difference between maximum and average TPS also increases as the block size increases. Thisis because the latency increases as the block size increases. If the maximum latency exceedsthe consensus period T, the consensus will be continued in the next round, which will result in the average TPS value decreasing. Therefore, the block size and latency are in a trade-offrelation. In addition, approximately up to 500 games can be connected in the PoP based block chain under the time limit T set in the experiments.

Fig. 4. Latency experiment results based on number of MNs

Table 2. TPS experiment results based on block size

6. Conclusions

In this paper, the BCP blockchain system is proposed, which is uses the PoP instead of the PoW mechanism. The BCP system model was implemented on the new Bryllite block chaininternational game network. The proposed BCP scheme encourages user participation to the block chain network by giving block rewards to individual users in a fair fashion. Future work will focus on building more secure and flexible fast blockchains to support massive usernetworks, game companies, and gamers that need instantaneous real-time transactions.